Um gateway, todas as saídas
O PLCGateway coleta os dados das máquinas uma única vez e os oferece na forma que cada sistema quer: OPC UA para SCADA e historiadores, MQTT para plataformas IoT e a nuvem, Modbus TCP para outros controladores, uma API REST com stream em tempo real para ERP, MES e scripts, e webhooks, e-mail e Telegram para as pessoas e os sistemas que precisam ser avisados quando algo acontece.
Caminhos para tirar os dados
Servidor OPC UA
Todos os dispositivos e valores como nós, com None / Sign / SignAndEncrypt, certificados automáticos, confiança de clientes e contas de usuário.
Saiba mais →Publicador MQTT
Cada tag em <base>/<device>/<tag> como JSON com valor, qualidade, hora e unidade, por mudança ou por intervalo, com TLS, birth e last will; escritas opcionais por tópicos /set.
Servidor Modbus TCP
Todas as tags como um único escravo Modbus: coils e holding registers atribuídos automaticamente ou fixados, ordem de palavras selecionável, mapa de endereços em CSV.
API REST e stream em tempo real
Valores, histórico com agregados, alarmes, números de produção, fontes de dados e escritas via HTTPS com token; Server-Sent Events enviam cada mudança.
Notificações
E-mail via SMTP com STARTTLS, bots do Telegram e webhooks com cabeçalhos personalizados; regras por prioridade, grupo e alarme, resumos para enxurradas de alarmes, novas tentativas e um registro de envios.
Relatórios agendados
Relatórios diários, semanais e por turno com números de produção, estatísticas de alarmes e a seção de energia, como e-mail HTML com anexos CSV.
Fontes de dados
Ordens de serviço, receitas e registros como tabelas que o ERP preenche pela API e as telas leem; importação CSV e coleta via HTTP.
Exemplos do assistente
Um assistente de IA explica qual caminho se encaixa e retorna exemplos prontos para copiar e executar com as suas tags, tópicos e registradores reais.
Saiba mais →MQTT para plataformas IoT e a nuvem
Mosquitto, EMQX, HiveMQ, AWS IoT Core ou Azure IoT Hub por meio de uma bridge, Node-RED, Grafana via Telegraf: assine os tópicos do gateway em vez de fazer polling nos PLCs. O publicador reconecta com atraso crescente, enfileira as mensagens enquanto isso e informa ao broker quando o gateway está online ou ausente.
- MQTT 3.1.1 via TCP ou TLS, QoS 0 ou 1, mensagens retidas
- Payload JSON ou o valor puro, seleção por dispositivo
- Status com contagens de publicadas e recebidas e o último erro
Modbus TCP para os sistemas que só falam Modbus
Um DCS, outro SCADA ou um PLC lê o gateway como um único dispositivo, incluindo tags de protocolos que ele próprio não fala: S7, Mitsubishi, FOCAS, OPC UA, IEC 61850. Booleanos viram coils, números viram holding registers em uma, duas ou quatro palavras; o mapa permanece estável, pode ser fixado e o cliente recebe um CSV dele.
- Códigos de função 1 a 6, 15 e 16, unit id, até 16 clientes
- Escritas desativadas por padrão
- Último valor conhecido enquanto um dispositivo está desconectado
Avise as pessoas e os sistemas
Os canais de notificação transportam alarmes, ordens de serviço de manutenção e relatórios. Uma regra define quais eventos vão para onde: prioridade, grupo, alarmes individuais, eventos de ativação, desativação e reconhecimento, com uma janela de resumo para que uma enxurrada de alarmes vire uma única mensagem. Webhooks enviam JSON com os seus cabeçalhos a sistemas de tickets, ferramentas de chat e APIs internas; envios com falha são repetidos e registrados.
- E-mail (SMTP, STARTTLS / TLS), Telegram, webhook
- Envio de teste com a transcrição do servidor quando algo falha
- Segredos armazenados mascarados, nunca exibidos novamente
Qual caminho para qual sistema
| Sistema | Caminho recomendado | Por quê |
|---|---|---|
| SCADA, historiador, MES com cliente OPC UA | Servidor OPC UA | Padrão da indústria, assinaturas, certificados e contas de usuário |
| Plataforma IoT, nuvem, Node-RED, Grafana | Publicador MQTT | Muitos consumidores, publicação por mudança, sem polling nas máquinas |
| DCS, PLC, SCADA que só fala Modbus | Servidor Modbus TCP | Um único escravo para todas as máquinas, mapa de registradores estável |
| ERP, BI, scripts, dashboards | API REST e stream em tempo real | JSON via HTTPS com token, histórico com agregados, escritas com permissão de operador |
| Sistema de tickets, CMMS, chat, receptor interno | Webhooks e e-mail | Enviados quando ocorrem alarmes, ordens de serviço ou relatórios |
| Planilhas, análises pontuais | Exportações CSV | Lista de tags, mapa Modbus, anexos de relatórios, histórico em CSV |
Integrações: perguntas frequentes
Como um assistente de IA se conecta ao PLCGateway, e o que ele pode fazer com os dados?
Todo produto PLCGateway inclui um servidor MCP (Model Context Protocol) via Streamable HTTP e stdio. Um assistente compatível com MCP se conecta com uma sessão de usuário ou um token e recebe ferramentas para valores, histórico, alarmes, números de produção, energia, manutenção e configuração, cada uma limitada às permissões daquele usuário. Ele pode responder a perguntas a partir de dados ao vivo e históricos, criar rascunhos de telas e relatórios para as pessoas revisarem, configurar dispositivos e tags e entregar ao seu integrador exemplos prontos para cada caminho de integração desta página.
O PLCGateway pode enviar dados para a nuvem?
Sim. O publicador MQTT envia cada valor a um broker via TLS, que é a forma como AWS IoT Core, Azure IoT Hub (por meio de sua bridge MQTT), HiveMQ Cloud, EMQX Cloud e a maioria das plataformas IoT recebem dados. A API REST e os webhooks são a alternativa para serviços baseados em HTTP.
Existe uma API REST?
Sim. Tags, valores atuais, histórico com amostras brutas ou intervalos agregados e incrementos de contadores, alarmes, KPIs de produção, fontes de dados, números de energia e manutenção estão disponíveis como JSON via HTTPS com um token bearer; um stream Server-Sent Events envia cada mudança. Escritas exigem permissão de operador.
Como obtenho os exemplos exatos para o meu integrador?
Conecte um assistente de IA compatível com MCP ao gateway e pergunte: ele lê o guia de integração, verifica o que está ativado e retorna trechos prontos para copiar e executar em curl, Python, Node.js ou C# com os seus nomes de tags, tópicos MQTT, endereços Modbus e node ids OPC UA reais, sem o token.
Outros sistemas podem escrever no PLC por meio do PLCGateway?
Sim, quando permitido: via OPC UA com um nó gravável, via tópicos MQTT /set quando as escritas estão habilitadas, via códigos de função Modbus 5, 6, 15 e 16 quando o servidor permite escritas, e via API REST com permissão de operador. Escritas em tags somente leitura ou em dispositivos desconectados são rejeitadas com um erro claro.
Qual sistema deve ver as suas máquinas?
Conte o que você usa; mostramos o caminho, o payload e os primeiros valores chegando ao seu sistema.