Gateway Inteligente e Computação de Borda para Ponte Rolante OPC UA

O sistema de gateway inteligente e computação de borda da ponte rolante é o elo crítico entre a camada de equipamentos e a camada de informação — realiza conversão de protocolos, aquisição de dados, computação de borda e continuidade de transmissão offline entre o PLC e o inversor de frequência e os sistemas MES, SCADA e a plataforma em nuvem. A Kelude, com base no gateway industrial de borda Siemens IOT2050 e na sua plataforma proprietária de dados de borda, desenvolveu uma arquitetura padronizada para aquisição de dados e conversão de protocolos em pontes rolantes, suportando conversão em tempo real entre cinco protocolos: PROFINET, OPC UA, Modbus TCP, MQTT e REST API. Um único gateway pode adquirir simultaneamente dados operacionais de 8 pontes rolantes, com latência de processamento de borda inferior a 50 ms e zero perda de dados na continuidade de transmissão offline. Este artigo aborda sistematicamente esta prática de engenharia, desde a seleção de hardware, configuração da pilha de protocolos e modelação de dados até à implementação e manutenção.

Seleção de hardware para gateway de borda industrial e arquitetura de sistema

O componente central do sistema de aquisição de dados da ponte rolante é o gateway de borda industrial, instalado no painel de controle da ponte rolante ou numa estação de controlo local adjacente, ligado à rede da oficina na camada superior e diretamente ao PLC da ponte rolante através da interface PROFINET na camada inferior. Na sua solução padronizada, a Kelude adota o gateway de borda industrial Siemens IOT2050 como plataforma de hardware principal, equipado com processador ARM Cortex-A72 de quatro núcleos (1,5 GHz) e 4 GB de RAM DDR4, integrando duas portas Ethernet RJ45 Gigabit, duas portas USB 3.0 e uma ranhura para cartão SD industrial, executando o Siemens Industrial Edge e Edge Apps baseados em contentores Linux. O IOT2050 suporta operação em temperatura alargada de -20°C a 60°C, com Grau de Proteção IP20, adequado para instalação em calha DIN no quadro de comando.

A arquitetura do sistema adota uma implantação em três camadas: borda, borda e nuvem. A camada de dispositivos na extremidade inclui o PLC S7-1500, o inversor de frequência G120, o módulo de interface do encoder e o conjunto de sensores em cada painel de controle da ponte rolante — o PLC publica dados operacionais para o gateway através do ciclo PROFINET IO (10ms), e o inversor G120 publica a velocidade de rotação do motor, corrente, temperatura e códigos de falha através do perfil de driver PROFINET. A camada de borda implanta um gateway IOT2050, executando quatro Edge Apps principais: servidor OPC UA (agregando dados UA de todos os nós PLC), mecanismo de conversão de protocolo (PROFINET, OPC UA, Modbus, MQTT), unidade de processamento de dados na borda (fila de cache + retomada de transferência + compressão de dados) e módulo de segurança de dados (criptografia TLS + lista de controle de acesso). A camada de nuvem inclui o sistema de execução de manufatura MES, a plataforma de monitoramento SCADA e o painel de operação e manutenção com Gêmeo Digital, comunicando-se com o gateway de borda através de cliente OPC UA ou broker MQTT.

Configuração do servidor OPC UA e modelagem de nós de dados

OPC UA é o protocolo de comunicação central que conecta o PLC da ponte rolante aos sistemas superiores. A Kelude Indústrias Pesadas projetou um modelo de informação padronizado para pontes rolantes no servidor OPC UA do gateway de borda, agrupando e nomeando os nós de dados do sistema de controle da ponte rolante de acordo com a especificação complementar OPC UA for Machinery (IEC 62541-100), garantindo consistência na estrutura de dados entre diferentes pontes rolantes, sem necessidade de adaptação individual para cada equipamento nos sistemas MES e SCADA.

O modelo de informação é dividido em quatro níveis hierárquicos. O primeiro nível é o nível de site (Site), correspondendo à oficina ou edifício industrial — o caminho do nó "/Site/Workshop_01" contém a coleção de todas as pontes rolantes daquela oficina. O segundo nível é o nível de área (Area), correspondendo ao agrupamento de pontes rolantes no mesmo vão ou posição de trabalho — o caminho do nó "/Area/Bay_A" contém as 3 pontes rolantes daquele vão. O terceiro nível é o nível de dispositivo (Device), correspondendo a uma ponte rolante individual — o caminho do nó "/Device/Crane_01" contém todos os dados agrupados daquele equipamento. O quarto nível é o nível de bloco funcional (Function), correspondendo às unidades funcionais do sistema de controle da ponte rolante — incluindo o grupo de controle de movimento Motion (com modo de operação, posição alvo, posição real, velocidade, estado de aceleração), o grupo de inversores Drive (com corrente do motor de cada mecanismo, velocidade de rotação, temperatura, estado operacional, código de alarme), o grupo de freios Brake (com estado aberto/fechado dos dois freios, corrente eletromagnética, contagem de desgaste, flag de dessincronização), o grupo de estado de segurança Safety (com estados STO/SLS/SBC/SDI, contagem de acionamentos de parada de emergência, registo de eventos de segurança) e o grupo de diagnóstico Diagnosis (com tempo de operação do sistema, fila de códigos de falha, carimbo de data/hora do PLC).

A nomeação dos nós de dados segue o formato camelCase, com cada nó incluindo definição de tipo de dados e descrição. Motion.ActualPosition (Int32, unidade mm), Motion.Speed (Real, unidade m/s), Drive.Current_A (Real, unidade A), Brake.Status_A (Boolean, True = aberto / Brake fechado), Brake.UnsyncCount (UInt16), Safety.STO_Active (Boolean), Safety.EventCount (UInt32). Durante a implantação em campo, os 26 nós OPC UA padrão de cada ponte rolante são submetidos a mapeamento de endereços e validação de tipos de dados; após o mapeamento, a ferramenta UA Expert é utilizada para verificar a legibilidade e a correção dos tipos de dados de todos os nós.

Camada de conversão de protocolos: PROFINET para OPC UA/Modbus/MQTT

A conversão de protocolos é a função central do gateway de borda. O PLC da ponte rolante publica dados no gateway em ciclo de tempo real PROFINET IO (10ms). O motor de conversão de protocolos do gateway analisa os dados PROFINET IO para um formato de dados interno unificado e, em seguida, reencapsula-os conforme os requisitos de destino de cada protocolo. O gateway executa simultaneamente três saídas de protocolo: servidor OPC UA, servidor Modbus TCP e cliente MQTT, servindo respetivamente os sistemas MES, SCADA e a plataforma em nuvem.

Configuração da saída OPC UA. O servidor OPC UA do gateway é desenvolvido com base na stack de código aberto open62541, suportando o protocolo binário OPC UA (porta padrão 4840) e o protocolo HTTPS (porta 443). A política de segurança do servidor está configurada como assinatura e encriptação Basic256Sha256 (SecurityMode=SignAndEncrypt). A autenticação de clientes utiliza o modo de lista branca de certificados X.509 — apenas clientes OPC UA cujos certificados estejam na lista de confiança do gateway podem ligar-se e ler dados. O servidor publica os 26 nós padrão da ponte rolante mencionados anteriormente. O cliente UA (por exemplo, o Cliente OPC UA do sistema MES) descobre toda a estrutura de nós através da operação Browse e, em seguida, lê os dados em tempo real em modo de subscrição, com um intervalo de amostragem mínimo suportado de 50ms.

Configuração da saída Modbus TCP. O gateway mapeia os dados padrão da ponte rolante para a tabela de registradores Modbus, com endereços atribuídos sequencialmente a partir de 40001 — 40001~40006 correspondem aos 6 registradores do grupo funcional Motion, 40007~40014 aos 8 registradores do grupo funcional Drive, 40015~40019 aos 5 registradores do grupo funcional Brake e 40020~40023 aos 4 registradores do grupo funcional Safety. Cada registrador ocupa 2 bytes; dados de 32 bits (como Real, Int32) ocupam dois registradores consecutivos. O sistema SCADA, atuando como Master Modbus TCP (porta padrão 502), faz polling cíclico aos endereços dos registradores; um único comando de leitura pode obter dados em lote de segmentos de endereços consecutivos, reduzindo a sobrecarga de rede.

Configuração da saída MQTT. A unidade de processamento de dados de borda do gateway liga-se, como cliente MQTT, ao Broker MQTT da plataforma em nuvem (por exemplo, EMQX ou VerneMQ, porta padrão 8883), utilizando comunicação encriptada TLS. Os tópicos MQTT são concebidos de acordo com a hierarquia dos equipamentos da ponte rolante, usando uma estrutura de três níveis: topic/workshop_id/crane_id/function/parameter, por exemplo, "krunde/workshop01/crane_01/motion/position". A publicação de dados utiliza QoS=1 para garantir entrega pelo menos uma vez. A carga útil dos dados é encapsulada em formato JSON, contendo três campos: timestamp, valor e qualidade. A frequência típica de publicação MQTT é de 1s/vez, com um volume de dados de cerca de 200 bytes/vez/ponte rolante. O tráfego de rede para 8 pontes rolantes em operação simultânea é de aproximadamente 1.6KB/s.

Processamento de dados de borda e retoma após desconexão

A recolha fiável dos dados operacionais da ponte rolante depende da cache local de dados e do mecanismo de retoma após desconexão do gateway de borda. O ambiente de rede industrial — especialmente as interrupções de roaming WiFi causadas pelo movimento da ponte rolante ao longo do trilho ou a interferência harmónica dos inversores de frequência na oficina — pode provocar interrupções breves na ligação entre o gateway e a plataforma em nuvem. Para este efeito, a plataforma de dados de borda da Kelude concebeu um mecanismo de cache em anel e de retoma após desconexão.

A camada de cache de dados utiliza uma arquitetura de cache de dois níveis: memória + cartão SD. O primeiro nível é um buffer circular em memória (Ring Buffer), com capacidade para 10000 registos de dados (considerando 200 bytes por registo, ocupa cerca de 2MB de memória). A latência de escrita na cache de memória é inferior a 1ms, implementada através do modelo produtor-consumidor — as threads de saída OPC UA/Modbus/MQTT atuam como consumidores, lendo dados da cache e reencaminhando-os; após o reencaminhamento bem-sucedido, o registo é marcado como processado. O segundo nível é uma cache de ficheiros em cartão SD. Quando a interrupção da rede causa um acumular de dados que excede o limiar de memória (padrão de 80%), a unidade de processamento de dados de borda escreve automaticamente os dados acumulados em ficheiros de cache no cartão SD. A capacidade da cache SD depende do tamanho do cartão (recomenda-se um cartão SD industrial de 32GB). Para um máximo de 7 dias de cache, seriam necessários cerca de 1.2GB de espaço; um cartão SD de 32GB pode armazenar mais de 180 dias de dados operacionais da ponte rolante.

A estratégia de retoma após desconexão é dividida em três cenários. Interrupção curta (≤30 segundos): a cache de memória é suficiente para armazenar os dados acumulados; após a recuperação da rede, a ligação TCP das threads de saída do protocolo é restabelecida automaticamente, enviando rapidamente os dados em cache por ordem de timestamp. Interrupção média (30 segundos a 2 horas): após o esgotamento da memória, os dados são transferidos automaticamente para a cache de ficheiros no cartão SD; após a recuperação da rede, o módulo de sincronização de ficheiros para retoma analisa os ficheiros de cache não enviados no cartão SD e carrega-os a uma taxa de 500 registos por segundo (uma necessidade de largura de banda ascendente de cerca de 212KB/s, que uma rede de oficina de 10Mbps pode suportar). Interrupção longa (≥2 horas): quando a cache do cartão SD está cheia (o número de ficheiros em cache atinge o limiar de alerta), a plataforma de borda executa automaticamente uma política de eliminação de cache — elimina os registos mais antigos por timestamp (FIFO) e, simultaneamente, aciona um alerta local enviado para o painel de operação da ponte rolante para notificar o pessoal de manutenção. Após a recuperação da rede, o gateway reporta o intervalo de timestamps dos registos em falta ao sistema MES, que decide se é necessário recolher dados complementares do histórico do PLC.

Segurança de dados e controlo de acessos

A segurança dos dados da plataforma de dados de borda da ponte rolante segue a norma de segurança cibernética industrial ISA/IEC 62443. As medidas de segurança estão divididas em três camadas: segurança de transmissão, controlo de acessos e registos de auditoria.

A camada de segurança de transmissão ativa a encriptação TLS 1.3 em todos os links de comunicação externos. O servidor OPC UA está configurado com comunicação encriptada e assinada Basic256Sha256, desativando ligações não encriptadas (SecurityPolicy=None é proibido). O cliente MQTT utiliza TLS para ligar ao Broker MQTT, com verificação de certificado do servidor através de validação de cadeia CA — o gateway vem pré-instalado com o certificado CA da fábrica, sendo proibidas ligações com certificados autoassinados. Como o protocolo Modbus TCP não suporta encriptação nativamente, é utilizado um túnel VPN (WireGuard) para estabelecer um canal encriptado entre o gateway de borda e o servidor SCADA, com os pacotes Modbus a serem transmitidos dentro do túnel. O túnel VPN utiliza autenticação por chave pré-partilhada (PSK), com rotação da chave a cada 90 dias.

A camada de controlo de acessos implementa um modelo de controlo de acessos baseado em funções (RBAC), dividido em três níveis de função: Admin, Operator e Viewer. Cada função tem permissões de acesso distintas sobre os nós de dados e operações do sistema. O controlo de acessos é aplicado tanto ao nível do servidor OPC UA como ao nível do gateway local, garantindo que apenas utilizadores autorizados podem aceder ou modificar dados sensíveis.

A camada de registos de auditoria regista todas as operações de acesso e modificação de dados, incluindo timestamp, utilizador, endereço IP de origem, tipo de operação e nós afetados. Os registos são armazenados localmente no gateway e enviados periodicamente para o sistema MES para arquivo centralizado, garantindo a rastreabilidade completa das operações e conformidade com os requisitos da norma ISA/IEC 62443.

Os certificados OPC UA dos três perfis são carregados e vinculados na interface de gestão web do gateway. Quando um cliente UA estabelece ligação, o gateway valida o campo Common Name do certificado do cliente para determinar o perfil e aplicar as permissões correspondentes. O controlo de acesso MQTT é implementado através de regras ACL. Cada cliente MQTT é autenticado por nome de utilizador e palavra-passe, e as regras ACL definem os tópicos MQTT que o cliente pode publicar ou subscrever.

A camada de registo de auditoria regista todos os eventos de acesso a dados. Cada ligação e desconexão de cliente OPC UA, cada subscrição/cancelamento de subscrição de cliente MQTT, e cada pedido de leitura Modbus TCP que exceda 20 vezes/segundo (acionando a limitação de velocidade da ligação) — tudo é registado no ficheiro de registo de auditoria do gateway. O formato do registo inclui carimbo de data/hora, endereço IP de origem, tipo de protocolo, tipo de operação e resultado da operação. O registo de auditoria é rotacionado automaticamente, com um período de retenção de 90 dias. Os ficheiros de registo são armazenados encriptados e só podem ser descarregados e visualizados pelo perfil Admin através da interface de gestão web do gateway.

Implementação, Teste e Gestão de Manutenção

A implementação e o teste do gateway de borda para pontes rolantes seguem um procedimento padronizado. Primeiro passo: instalação do hardware — o IOT2050 é montado no trilho DIN do Quadro de Comando (ocupando 4 larguras de módulo padrão). O gateway é ligado ao switch de rede PROFINET da oficina através de um cabo de rede blindado CAT6A, e à rede de escritório da oficina (para upload MQTT e gestão remota) através de outro cabo de rede. A Alimentação Elétrica do gateway é de 24 V DC, proveniente da Fonte Chaveada do Quadro de Comando, com um Filtro EMC (corrente nominal 0,5 A) instalado na entrada de energia.

Segundo passo: implementação do ambiente de software de borda — as imagens Edge App são enviadas remotamente para o IOT2050 através da plataforma Siemens Industrial Edge Management (IEM). A ordem de implementação das Apps é: ambiente de execução base (Docker e configuração de rede), App de servidor OPC UA, App de motor de conversão de protocolo, App de processamento de dados de borda, App de módulo de segurança de dados. Após a implementação de cada App, um script de autoverificação valida o estado do contentor e o estado da porta de escuta. Para a solução nacional, os ficheiros de configuração Docker Compose e as imagens são enviados via SSH, e a implementação é feita com um único comando docker-compose up -d.

Terceiro passo: verificação da comunicação OPC UA — o UA Expert é utilizado para ligar ao servidor OPC UA do gateway (porta padrão 4840). O certificado de cliente emitido pela CA é importado, e a função Browse é verificada para percorrer todos os 26 nós padrão. Uma operação de leitura é executada em cada nó para confirmar a exatidão do tipo de dados e do intervalo de valores. A função Subscription do UaExpert é usada para subscrever o nó Motion.Position (intervalo de amostragem 50 ms), observando se a atualização de dados em tempo real é estável e verificando se a taxa de perda de pacotes da subscrição é ≤ 0,1%.

Quarto passo: verificação do relatório de dados — num terminal de cliente de teste MQTT, é feita a subscrição do tópico "krunde/workshop01/+/motion/position" para observar se o formato JSON dos dados publicados pelo gateway está correto. O Modbus Slave é utilizado para simular a leitura do Sistema SCADA nos endereços de registrador 40001~40023, verificando se os valores dos dados correspondem aos exibidos no lado do PLC. Teste de desconexão de rede: o cabo de rede da rede operacional do gateway é removido durante 30 segundos, verificando se o ficheiro de cache no cartão SD é criado automaticamente. Após a restauração da rede, o módulo de retomada de ponto de interrupção envia automaticamente os dados em cache, e o sistema MES confirma zero perda de dados e continuidade dos carimbos de data/hora.

Quinto passo: configuração da gestão de manutenção — na interface de gestão web do gateway (HTTPS://192.168.x.x:8443), são configuradas regras de alerta: timeout de ligação do cliente OPC UA (padrão 30 segundos) aciona alerta por e-mail; perda de heartbeat do Broker MQTT (sem PINGRESP por 60 segundos) aciona alerta; utilização da cache do cartão SD superior a 80% aciona alerta; utilização da CPU do gateway continuamente superior a 80% por 5 minutos aciona alerta. Todos os alertas são enviados para o e-mail do engenheiro de manutenção via SMTP. Simultaneamente, a luz indicadora LED no Painel de operação local (verde = normal / vermelho = alerta / amarelo = manutenção) fornece indicação de estado no local.

Perguntas Frequentes (FAQ)