De SMS para AWS: opções de tecnologia de controle específicas do projeto

A postagem é voltada para pessoas que estão pensando em criar o primeiro sistema de gestão. Especialistas experientes podem estar interessados ​​na visão "de cima para baixo" de várias tecnologias de controle da "Internet das Coisas", conclusões e uma breve previsão na conclusão.







Tarefa



Nós, da Synergy Team, projetamos e fabricamos controladores industriais. Eles são projetados para contabilidade de recursos, gerenciamento de instalações de energia e outras aplicações comumente chamadas de Internet das Coisas (IoT). Freqüentemente, nossos clientes não precisam apenas de controladores. Eles precisam de uma solução completa que inclua um sistema de controle.



E este sistema deve estar próximo do ideal: rápido, leve e confiável. Mas, de acordo com a conhecida anedota, é impossível cumprir todos esses requisitos simultaneamente. Precisamos buscar um equilíbrio dependendo da tarefa que tentamos fazer.





Neste post, nos limitamos à classe de tarefas quando os controladores IoT estão conectados diretamente ao sistema de controle ( IoT diretamente conectado ). Portanto, nossa tarefa é desenvolver um sistema de gestão que deve:

  • transferir dados de sensores conectados a controladores,
  • enviar eventos (por exemplo, sobre aumento de temperatura, abertura de porta, perda de comunicação, etc.),
  • transmitir comandos de controle para atuadores,


Se o sistema consiste em um grande número de objetos e / ou executa tarefas críticas, ele deve adicionalmente:

  • monitorar constantemente a presença de comunicação com objetos,
  • colete estatísticas sobre o seu trabalho,
  • atualizar as configurações e software dos controladores (mediante solicitação);
  • ser protegido de acesso não autorizado. Para empresas estatais e privadas de grande porte, o sistema também deve atender à legislação de trabalho com infraestrutura crítica de informação (CII). Em particular, os requisitos de 187-FZ, FSB, FSTEC, ordens do Ministério das Telecomunicações e Comunicações de Massa, etc.


Gestão sem servidor dedicado



Para diversos objetos, o problema é simplesmente resolvido com o controle da rede GSM por meio de comandos ou chamadas SMS. Essa abordagem era popular no início de 2010 e seus prós e contras são descritos, por exemplo, aqui . Para a maioria dos sistemas sérios, essa abordagem está perdendo sua relevância hoje.





Um pouco mais complicado é o controle “manual” dos controladores via IP dedicado via WEB ou linha de comando (CLI). Os controladores devem estar permanentemente conectados à rede, ter endereços IP estáticos "brancos" ou "cinza". Como alternativa, você pode usar IP dinâmico com vinculação a nomes de domínio estáticos usando tecnologia DynDNS ou similar . Isso funciona bem se houver poucos objetos e nenhum requisito especial de confiabilidade.



Desvantagens:

  • , WEB () ;
  • IP ;
  • , NAT;
  • IP . , GSM APN ;
  • , «»;
  • ().


Para demonstrações rápidas, controle sobre vários objetos, basta utilizar o controle por IP, SMS ou chamadas telefônicas.



Não consideramos aqui a situação em que o despachante está rodando no mesmo computador e o sistema de controle está instalado, pois consideramos isso um caso degenerado do próximo item.



Gerenciamento de servidor dedicado



Nos demais casos, é necessário um servidor com IP dedicado, por meio do qual se conectarão controladores, despachantes e sistemas de terceiros.



Se os controladores transmitem dados apenas na direção do servidor, por exemplo, hidrômetros ou os dispositivos de navegação mais simples (rastreadores), uma conexão unidirecional é suficiente. Neste caso, os controladores precisam apenas saber o IP do servidor.



Em nossa tarefa, a troca de dados bidirecional é necessária para atualizar o software do controlador e transmitir comandos. Para organizar tal troca, você deve:

  • leitura periódica de configurações ou comandos do servidor por iniciativa do controlador (aceitável se você não precisar de uma resposta rápida aos comandos), ou
  • usando IP estático ou nomes de domínio nos controladores para que o servidor possa "alcançá-los" por conta própria, ou
  • , . , MQTT, EGTS ( ). IP. , .






Quando se trata de um sistema de controle baseado em uma solução comprovada e confiável, o SCADA é a primeira coisa a lembrar. E isso é plenamente justificado quando se trata da automação da produção ou de uma grande instalação de energia. Em suma, quando o sistema contém um grande número de sensores e atuadores de vários tipos. Tais sistemas requerem o desenvolvimento de diagramas mnemônicos e algoritmos de interação de equipamentos exclusivos para cada objeto, o que é perfeitamente pensado no SCADA.



Se você precisa monitorar e / ou gerenciar objetos do mesmo tipo (como na tarefa proposta), então o uso do SCADA pode tornar a solução muito "pesada" devido à complexidade da configuração, laboriosidade de adicionar objetos padrão e requisitos aumentados para desempenho do servidor. É melhor usar um dos sistemas de caixa especializados no mercado que seja mais adequado para a tarefa. Por exemplo:

  • sistema de monitoramento e gerenciamento de equipamentos de rede - Sistema de gerenciamento de rede (SNMP, TR-069, CLI);
  • sistema de medição automatizado de calor, eletricidade, gás, água. Para resumir - ASKUE;
  • sistema de rastreamento de navegação para objetos móveis com controle de sistemas de bordo;
  • sistema de controle de clima (ventilação, ar condicionado e aquecimento) - HVAC;
  • sistema inteligente de casa / escritório / edifício;
  • : , () , ;
  • - , ..


Esses sistemas freqüentemente se sobrepõem à funcionalidade uns dos outros. Por exemplo, com base em ASKUE é possível implementar o controle de iluminação externa, e com base na "Casa Inteligente" para controlar o clima e o acesso. A expansão da funcionalidade dos sistemas "vivos" está em andamento. Novas APIs estão surgindo para a integração de produtos in a box às soluções do cliente, bem como suporte para funções personalizadas em software in a box. Uma grande vantagem dos produtos in a box é o fato de poderem ser comprados e colocados no seu servidor, tendo recebido uma solução alienada que funciona em um circuito fechado de clientes.



Se você tem planos de vender seu próprio sistema no mercado livre, precisa entender que um concorrente pode crescer fora do fornecedor de software in a box de hoje amanhã. Além disso, o uso de sistemas de caixa acarreta riscos adicionais como:

  • aumento no preço das licenças,
  • controle fraco sobre o sistema (não há código-fonte, mesmo se houver, é extremamente difícil de manter),
  • muitos sistemas só podem ser usados ​​como serviço em nuvem, o que pode ser inaceitável para projetos grandes e / ou governamentais.


Desenvolvimento baseado em plataformas IoT



Se o uso de software in a box não for possível, seria uma boa ideia desenvolver em uma das plataformas IoT populares . Essas plataformas contêm módulos universais necessários em qualquer sistema IoT para:

  • registro e exclusão de dispositivos IoT,
  • autenticação segura de dispositivos IoT e manutenção da comunicação com eles,
  • trabalhar com dados (bancos de dados otimizados para diferentes tarefas),
  • registro de usuários e gestão de direitos de acesso,
  • formação de análises com base nos dados coletados,
  • geração de notificações para usuários (SMS, e-mail, mensagens push, ...),
  • armazenar os dados mais recentes lidos de dispositivos IoT,
  • realizando várias ações em eventos,
  • visualização de dados, etc.


A arquitetura do sistema na plataforma IoT é praticamente independente de seu tamanho. Todas as tarefas relacionadas ao balanceamento de carga, eliminando "freios" do banco de dados e funções "pesadas" são realizadas pela plataforma. Além disso, o lado do servidor do aplicativo é rapidamente montado a partir de "cubos" - microsserviços. Tanto o tempo de comercialização quanto o custo da solução, que depende diretamente do pagamento do trabalho dos programadores, são reduzidos.



Um sistema em uma plataforma IoT pode ser desenvolvido em um mínimo de tempo. Sua arquitetura não mudará muito com o aumento do tamanho.



Prós de desenvolvimento em uma plataforma IoT baseada em nuvem:

  • . AWS . . .
  • , , , MQTT- – . , .
  • IoT . ( ) ( IoT ).
  • .
  • a tarefa de desenvolvimento principal pode ser terceirizada. No futuro, a solução poderá dar suporte não apenas aos desenvolvedores do sistema original, como costuma ser o caso. Afinal, as plataformas IoT têm suporte técnico poderoso, são bem documentadas e o número de desenvolvedores que podem trabalhar com elas está crescendo constantemente.


Desvantagens:



  • os componentes das plataformas IoT operam apenas nas instalações de seus proprietários, criam um sistema completamente alienável que funcionará no data center do cliente, possivelmente em casos raros;
  • o custo de usar uma plataforma IoT para grandes projetos pode ser maior do que o custo de alugar máquinas virtuais em um data center;
  • a migração de uma plataforma IoT para outra envolve a alteração de uma quantidade razoável de código. Embora agora haja uma tendência de padronização de API;
  • nem todas as plataformas IoT são implantadas em data centers na Rússia, o que torna impossível usá-las no interesse de clientes governamentais.


Desenvolvimento totalmente próprio



Se as deficiências das soluções anteriores são críticas, você precisa desenvolver sua própria solução. E não importa o quão bom seja o plano, as primeiras versões do sistema serão tortas.



As soluções próprias são frequentemente implementadas com base em sistemas de código aberto como ThingsBoard, OpenSCADA, MajorDoMo, Home Assistant, iobroker, Nokia glial. Para projetos pequenos, eles podem ser muito "pesados" devido a:

  • longo tempo de desenvolvimento e custos financeiros correspondentes. Normalmente, a contagem é em pessoa-anos;
  • conforme o número de objetos aumenta, gargalos surgirão na forma de bancos de dados lentos, coletores, geradores de relatórios, etc., para cuja resolução será necessário alterar a arquitetura e complementá-la com balanceadores e recursos duplicados;
  • custos de administração contínua e suporte técnico.


Ao mesmo tempo: O

desenvolvimento próprio é justificado tanto para ordens do governo, ou projetos com planos ambiciosos e grandes orçamentos, ou quando independência e segurança são críticas.



Se você precisar de uma demonstração rápida ( MVP ), ela pode ser feita em uma plataforma IoT ou software in a box, adotando abordagens testadas pelo tempo, enquanto desenvolve sua própria solução grande em paralelo.



Conclusão



Com base na análise de diferentes sistemas, propomos o seguinte algoritmo de seleção de sistema de controle.







Para demonstrações e pequenos projetos IoT para diversos objetos, você pode usar o controle direto sobre IP, SMS ou através de chamadas GSM. Caso contrário, é necessário um sistema de nível superior. O uso do SCADA é justificado em automação industrial e em grandes instalações de energia. Para contabilidade de recursos, gerenciamento de equipamentos de rede, rastreamento, segurança, "casa inteligente", etc. é conveniente usar uma solução em caixa da especialização necessária. Desenvolver sistemas em plataformas IoT é mais difícil, mas oferece mais perspectiva e flexibilidade. Soluções em plataformas IoT estrangeiras são seriamente limitadas em escala e áreas de aplicação na Rússia. O mais difícil é o desenvolvimento totalmente próprio. E isso se justifica apenas para as ordens do governo e os projetos mais ambiciosos.Ao mesmo tempo, para demonstrações rápidas e práticas recomendadas de cópia, será útil fazer um projeto de design na plataforma IoT em paralelo com seu próprio desenvolvimento.



Finalmente, queremos compartilhar uma pequena previsão:



  • em plataformas de nuvem IoT, vale a pena aguardar o aparecimento de templates pré-configurados para "Smart Home", ASKUE, NMS, ACS, etc. Isso simplificará ainda mais o uso de plataformas IoT e atrairá um público ainda maior.
  • os desenvolvedores tradicionais de SCADA e outras soluções in a box oferecerão mais ferramentas para desenvolvedores externos que se provaram em plataformas IoT. É improvável que as soluções de caixa fechada resistam à concorrência do mercado.
  • As plataformas IoT domésticas para clientes públicos e privados de grande porte serão desenvolvidas de forma ainda mais ativa.
  • As APIs de diferentes plataformas IoT se tornarão mais semelhantes com o tempo. Por causa disso, a transição de uma plataforma IoT para outra será simplificada.


Na próxima postagem mais técnica, falaremos sobre nosso projeto de monitoramento de sistemas de comunicação na plataforma AWS e controladores GIC .



Certifique-se de escrever nos comentários se perdermos algo importante. Um dos objetivos do nosso blog é obter feedback construtivo.



All Articles