Atualmente, os servidores de coleta de dados de porta serial MOXA Nport e similares são o padrão de fato no campo de sistemas de construção que transmitem ou recebem dados via interfaces RS-232, RS-485 e RS-422.
Medidores de eletricidade, válvulas controladas e válvulas de portão, medidores de vazão, sensores de vibração, dispositivos de telemecânica.
Tudo o que pode gerar dados ou ser controlado remotamente e possui uma interface RS-232, RS-485 e RS-422 - funciona através desses conversores.
O objetivo geral de seu uso é geralmente o seguinte: encaminhar as interfaces RS-232, RS-485 e RS-422 por meio de uma rede local existente, conectar um dispositivo ou dispositivo que possui uma das interfaces seriais a um PC (servidor, SCADA) via Ethernet, conectar-se ao dispositivo ter uma interface serial via Internet para controle remoto, etc.
Os preços desses conversores não são muito altos; modelos mais jovens podem ser emprestados por US $ 100-200. Porém, considerando que centenas ou até milhares podem ser instalados em qualquer produção automatizada de tais dispositivos, está surgindo um petisco para os “substitutos de importação” domésticos.
Vou tentar ajudá-los hoje.
O que vamos fazer?
Primeiramente, entenderemos a teoria de como ela é organizada por dentro.
Em segundo lugar, isolamos a funcionalidade mínima para iniciar o trabalho no modo Real Com (ou seja, para encaminhar a porta COM virtual para o dispositivo via Ethernet).
Em terceiro lugar, por uma questão de interesse, analisaremos o protocolo para pesquisar e configurar o dispositivo através do utilitário NPort Administration Suite. Obteremos um entendimento completo de como criar um análogo pin-to-pin de um pedaço de ferro que pode ser preso no lugar do MOXA Nport existente, enquanto recebemos suporte total do driver e software nativos.
E, finalmente, vamos tentar calcular quantos índios escreveram o código de firmware MOXA.
Parte 1. Introdutória
Portanto, temos um assunto de teste em nossa tabela (na verdade, havia vários deles, portanto, não se surpreenda se você vir identificadores de modelo diferentes e endereços MAC diferentes no artigo)
Possui uma porta Ethernet e duas portas RS-422 / RS-485 - isso é fisicamente.
E no plano do programa - no dispositivo estão abertos:
Porta UDP 4800 - é responsável pela captura de pacotes de pesquisa de dispositivos e envia dados sobre o próprio dispositivo ao utilitário de configuração.
Porta TCP 4900 - recebe comandos de configuração do dispositivo. A hora, o nome, o endereço IP, o modo de operação, as configurações de velocidade e porta do dispositivo e outros parâmetros básicos podem ser configurados por essa porta, que pode ser configurada pela interface principal do utilitário NPort Administration Suite:
Porta TCP 80 - é responsável pela operação da interface WEB
As portas TCP 966, 967 (e 968, 969 para 4 dispositivos de porta) são portas de controle de transmissão. Eles executam comandos para abrir / fechar a porta COM correspondente, definir a velocidade da porta, enviar dados, monitorar a plenitude do buffer de transmissão / recepção, etc. A porta 966 é responsável pela operação da primeira porta, respectivamente.
As portas TCP (por padrão) 950, 951 e (e 952, 953 para 4 dispositivos de porta) são portas de transferência direta de dados. Ou seja, o que deve aparecer diretamente na porta RS-232/485/422 do dispositivo é transmitido para a porta de dados. Somente o controle de fluxo de dados nessa porta vai para 966, 967, 968, 969 portas, respectivamente.
Espero que a imagem geral de entender o funcionamento do dispositivo na minha cabeça tenha se desenvolvido. Vamos para a próxima parte:
Parte 2. Emule o MOXA
Certamente já ficou claro para muitos que, para fingir ser o MOXA Nport na configuração mínima, é necessário criar um servidor TCP em seu próprio hardware em 2 portas: 966 para controle de transmissão e 950 para transmissão direta de dados. Naturalmente, você precisará responder e processar corretamente as solicitações de driver na porta 966, mas, como mostra a análise do wireshark, não há muitas solicitações e elas são as mais simples.
Para não sobrecarregar o texto do artigo com cálculos que descrevem as solicitações e respostas, preparei e publiquei separadamente, na forma de um arquivo pdf, uma descrição de todas as solicitações, respostas e parâmetros transmitidos analisados.
Download: Descrição do protocolo de análise do MOXA.pdfOu seja, esse conjunto de conhecimentos permite implementar um dispositivo que pode ser emparelhado com um driver nativo e transmitir dados como MOXA. Metade do trabalho está concluída, mas há um ponto - como alterar a configuração? Seria ótimo usar o utilitário nativo do NPort Administration Suite para esses fins.
Parte 3. Pesquise e encontre
As duas primeiras partes descreveram o que precisa ser feito, mas não havia uma palavra sobre como obter dados para a implementação dos protocolos.
Nesta parte, nos aprofundamos um pouco e vemos como a análise da troca foi realizada.
Sabemos que a porta UDP 4800 está aberta no dispositivo, vamos conectar o dispositivo, executar o NPort Administration Suite, o Wireshark e ver o que acontece ao procurar dispositivos com o utilitário nativo.
Nós olhamos para os pacotes enviados:
Vemos que o NPort Administration Suite envia uma transmissão para o endereço 255.255.255.255, ou seja, espera que o pacote voe pela rede.
O pacote de carga útil contém dados:
01 00 00 08 00 00 00 00, : 01 00 – 00 08 – Big Endian. 00 00 00 00 –
Esse pedido é enviado várias vezes, aparentemente na esperança de que pelo menos um deles atinja o objetivo.
Todos os MOXs respondem a esta solicitação.
Especificamente, nossa resposta:
81 00 00 18 00 00 00 00 12 03 00 80 32 03 00 90 e8 26 4a ab c0 a8 7f fe 81 00 – 00 18 – (24) 00 00 00 00 – 12 03 00 80 32 03 – MOXA Nport device, NPort 5232. MOXA Nport device. NPort Administrator. 00 90 e8 26 4a ab – MAC MOXA Nport device c0 a8 7f fe – IP MOXA Nport device ( 192.168.127.254 )
Parece que tudo é simples e elementar, confunde apenas o valor 12 03 00 80 32 03, responsável pela interpretação de um modelo de dispositivo específico.
Mas, como esse valor é verificado em relação a alguma referência de referência, significa que deve ser armazenado em algum lugar.
Depois de estudar um pouco o diretório do software, descobrimos que no NPort Administrator Suite v1.22 esses valores estão armazenados no arquivo C: \ Arquivos de Programas \ NPortAdminSuite \ bin \ dsci.dll
Depois de ficar sentado com o Wireshark e o dispositivo por vários dias, obtemos um log completo de trocas e uma compreensão de quais códigos de função recebem resposta. Por conveniência, tudo o que é encontrado é descrito no mesmo arquivo pdf, cujo link é indicado no artigo anterior.
Para uma melhor compreensão da imagem - lembrarei apenas que o UDP 4800 recebe informações primárias sobre o dispositivo, todos os parâmetros que requerem configuração e instalação são configurados por meio de solicitações para a porta TCP 4900.
Depois de processar corretamente todas as solicitações recebidas das portas 4800 e 4900, podemos fingir ser um dispositivo, para que nem o software nativo perceba o problema.
Parte 4. Contando os índios *
Ao analisar o protocolo, tive a sensação de que diferentes partes do protocolo de troca foram escritas por pessoas diferentes, o significado das funções e sua interpretação são muito diferentes.
Então, por exemplo:
Os códigos de função da porta UDP 4800 começam com:
01 00 .. .. 81 00 .. .. 10 00 .. .. 90 00 .. .. 16 00 .. .. 96 00 .. .. 29 00 .. .. a9 00 .. ..
Os códigos de função da porta TCP 4900 começam com:
00 01 .. .. 00 01 .. .. 02 01 .. .. 02 01 .. ..
e assim por diante
Os códigos de função das portas TCP 966, 967, 968, 969 começam com:
10 .. .. 10 4f 4b 11 .. .. 11 4f 4b
e assim por diante
Ou seja, é usado um identificador de byte único da função e não um byte duplo como antes.
Então, a propósito, surgiu um momento engraçado. Nas portas 966, 967, 968, 969, a resposta aos parâmetros de configuração sempre consiste em 3 bytes.
O primeiro é o número da função e os 2 restantes são 4f 4b ou há uma olhada na tabela ASCII - “O” “K”
Bem, tudo bem com ele, vá em frente.
O segundo recurso visto é um hash de Big e Little Endian dentro da mesma resposta.
Exemplo de resposta:
9a 00 00 24 00 00 00 00 01 52 00 80 9a 52 00 90 e8 3b 89 9c 75 00 04 00 01 00 0f 00 09 00 17 00 36 00 00 00 9a 00 – 00 24 – (36) 00 00 00 00 – 01 52 00 80 9a 52 – MOXA Nport device 00 90 e8 3b 89 9c - MAC MOXA Nport device 75 00 - : 1900 + (1900 + 117 = 2017) 04 00 - : 1 - 01 00 – 0f 00 – (15) 09 00 – (9) 17 00 – (23) 36 00 – (36) 00 00 –
O tamanho do pacote é codificado de uma maneira, e todos os valores numéricos (ano, mês, dia ...) de outra. A partir disso, podemos concluir que o processamento da parte do usuário a partir de 75 00 04 00 ....... foi escrito por outro programador.
Para resumir: Pelo menos 3 pessoas diferentes escreveram o protocolo de troca, 1 escreveu o processamento da parte do usuário dos dados e pelo menos 1 escreveu o manipulador da interface WEB. De acordo com meus cálculos, cerca de 5 programadores trabalharam no projeto.
Quanto você contou?
* Nesse caso, o termo "hindu" significa um funcionário que cumpre suas obrigações com alimentos e hipotecas, capaz de codificar daqui e antes do almoço, sem se aprofundar nos planos globais da empresa empregadora.
PS Este artigo foi escrito em materiais que estavam em desenvolvimento em 2017, muitos dados contêm datas precisamente este ano. Os protocolos foram examinados dentro da estrutura de um rascunho de trabalho, mas desde que a mente venceu o marketing e o assunto não foi além do estágio de um único protótipo de trabalho. Publico todos os desenvolvimentos deste projeto em domínio público, pois acredito que essas informações serão úteis para a comunidade de desenvolvedores.
PPS Artigo original como sempre no meu
blog pessoal