Vamos começar com ferro
Uma vez eu trabalhei em uma fábrica, onde eles esculpiram todos os tipos de eletrônicos, não muito complicados, e às vezes se enquadravam na definição de "Internet das coisas". Na maioria dos casos, todos os tipos de sensores para sistemas de segurança: fumaça, ruído, penetração, incêndio e muito mais. O sortimento de produtos era amplo, os lotes às vezes eram inferiores a 500 peças e quase para cada produto eu tinha que fazer um acessório de teste separado - na verdade, apenas uma caixa de lata na qual o produto era colocado em testes, era pressionada por uma tampa e, por baixo, agulhas de contato eram pressionadas para pontos de contato em uma placa de circuito impresso, algo como isto:
Assim, foi possível se comunicar fisicamente com o dispositivo. O protocolo de comunicação que tínhamos era bastante comum na indústria - RS232 (porta COM, um tipo de UART). Todos os tipos de dispositivos controlados simples para testar o produto final também foram colocados na caixa. Todas essas instrumentações auxiliares foram controladas da mesma maneira. Toda a estrutura era muito frágil e todos os tipos de problemas faziam parte da rotina diária.
A gama de problemas era muito ampla - contatos ruins, inverteu a polaridade durante a instalação, problemas com o produto testado, com dispositivos de controle e medição, com agulhas de contato, com o código de teste ... mas você nunca sabe! Mas era necessário testar constantemente, e se os testes começassem a aparecer em algum lugar, um dos engenheiros precisava pisar na linha e começar a verificar tudo manualmente.
Primeiro, o Docklight foi lançado - um bom utilitário para "comunicação" através de portas COM, mas tinha muitas limitações. E aqui estamos nos aproximando da essência do assunto.
Por que o Docklight não combina comigo?
Bem, vamos lá.
- O primeiro problema é que o Docklight é executado apenas no Windows. Portanto, a instalação do "centro nervoso" na forma de RaspberryPi, que conectaria todos os dispositivos, ou algo assim, poderia ser esquecida. Eu tive que instalar o NUC - a solução mais barata nessa situação. Pesado, bastante grande, e não o mais barato. A propósito, quando esses Equipamentos de Teste foram arrastados de um lugar para outro, as NUCs lutaram muito, muito (embora eu admita que o design delas seja bastante sólido).
- O segundo - o acesso remoto podia ser realizado apenas através do compartilhamento de área de trabalho - era mais lento mesmo através da rede local e, mesmo através da Internet, era completamente inútil.
- Terceiro, cada dispositivo tinha seu próprio conjunto de comandos e o Docklight podia carregar um arquivo com uma lista de comandos. Se, por exemplo, você tiver que compartilhar uma lista semelhante com alguém do departamento, envie um email com o arquivo ou ... envie um link para o arquivo na pasta compartilhada! Naturalmente, cada instalação do Docklight exigia esses arquivos localmente, e tudo isso tinha que ser feito dezenas (senão centenas de vezes) manualmente - para cada NUC, cada engenheiro arrastava suas listas de comandos favoritas e convenientes. E no quintal de 2019, deixe-me lembrá-lo ...
- Quarto, o Docklight não permite associar automaticamente uma porta COM a um nome de dispositivo: por exemplo, o Windows, quando você conecta a fonte de alimentação, se comunica com o dispositivo via COM12. Se você deseja "puxar as cordas" manualmente, no Docklight você precisa abrir o COM12. Como podemos descobrir que se trata apenas da fonte de alimentação e não, digamos, do SwitchBoard? Bem, você pode procurar o gerenciador de dispositivos todas as vezes e tentar não esquecer qual dispositivo está conectado a qual porta. Ao mesmo tempo, ninguém garante que, se você simplesmente retirar o dispositivo e conectá-lo novamente, a porta anterior permanecerá com esse dispositivo. Em resumo, toda vez que você precisar fazer isso manualmente. E acredite, no final do dia minha cabeça estava girando com isso.
- Quinto, cada porta precisava de uma cópia separada do programa e, é claro, todas as operações precisavam ser realizadas individualmente para cada dispositivo e, embora o Docklight suporte scripts, não há interação entre as instâncias individuais.
Próximo. Nenhuma integração com qualquer outro produto foi fornecida. Parece um pouco, mas aqui está uma situação em que o calor ficou branco: o teste caiu e precisamos descobrir o porquê. Primeiro de tudo, você precisa se conectar aos dispositivos e verificar se eles estão mortos. Vamos ao gerenciador de dispositivos, olhamos em qual porta nosso dispositivo está, abrimos o Docklight, iniciamos a comunicação com nossa porta ... Erro. Droga! Esqueci de interromper o serviço que está instalado na NUC e mantém todas as portas. Exclusivo, você sabe. Ok, desaceleramos o serviço, abrimos a porta, carregamos o arquivo com os comandos do dispositivo, enviamos os comandos, obtemos (ou não) as respostas, resolvemos o problema. Executamos o teste novamente, ele trava novamente ... Oh, caramba, esqueci de fechar o Docklight e reiniciar o serviço. Tudo parece não ter erros. Mas isso é pelas próximas duas horas, até que algo dê errado novamente. E acredite, era necessário resolver esses problemas com mais frequência do que gostaríamos.
Bem, e claro, sobre quaisquer extensões, adicione. não pode haver nenhum recurso ou algo parecido - o produto está fechado e gravado por um longo tempo (parece que eles não estão mais especialmente desenvolvidos), não há personalização.
Bem, eu decidi fazer algo meu, mas corrigindo (ou melhorando) a situação com os problemas descritos.
Aconteceu algo como o Zabbix, mas com nitidez para uma situação específica.
Então qual é a diferença?
Talvez faça sentido começar com uma descrição geral da arquitetura e depois entrar em detalhes.
O esquema é assim:
Temos um agente que funciona na estação à qual nossos dispositivos estão fisicamente conectados. O Agent foi escrito em Python, portanto, funciona sem problemas no Windows, Linux e você pode finalizá-lo com segurança para uso no RaspberryPi e em dispositivos similares. O programa é extremamente pouco exigente para os recursos e muito estável. O agente está constantemente conectado através do Websocket ao servidor (back-end) e recebe todas as configurações de porta e seus parâmetros a partir daí, durante a inicialização e durante as atualizações. O agente possui sua própria GUI para configurações e monitoramento. Nesse caso (talvez a conexão tenha sido perdida, talvez a licença tenha expirado).
Próximo. O servidor (também conhecido como back-end) sai da janela de encaixe (e, portanto, simplesmente roda não apenas na amazon ou no Google Cloud, mas também em qualquer máquina não tão poderosa em uma LAN com Linux a bordo). Está escrito no Django em conjunto com o Redis (para suportar websockets). Ele armazena todas as configurações e fornece comunicação entre a GUI do usuário (apenas uma página escrita no ReactJS) e através do Agent - com nossos dispositivos. Comunicação bidirecional, totalmente assíncrona. Todas as configurações são armazenadas no Postgres e Mongo.
Bem, e, talvez, a parte mais importante do sistema seja o próprio cliente (simplesmente, uma página em um navegador, escrita para o ReactJS para maior dinamismo).
Sim, o design visual está longe de ser perfeito, mas isso é corrigível.
Bem, isso pode ser completado, acrescentarei apenas algumas palavras sobre o status do projeto e a demonstração.
- Este é um alfa bem cedo, projetado para demonstrar mais provavelmente possíveis comodidades e verificar o nível de interesse.
- Reproduzir uma demonstração - aqui
Para fazer login
nome de usuário: operator_0
senha: 123456789
Selecionamos QA_Test e qualquer estação (esta é apenas uma tentativa de simular a estrutura da empresa - as portas estão conectadas às estações, são divididas em departamentos e cada escritório tem sua própria estrutura)
Em princípio, se houver interesse, adicionarei suporte para https e criarei assemblies do agente para diferentes plataformas, além de adicionar todos os outros recursos.
Ficarei feliz em receber comentários e sugestões. Críticas são bem-vindas!