Skip to Content
Extração de Dados de FábricaVisão Geral

Extração de Dados de Fábrica

Um chão de fábrica real é uma colcha de retalhos. Controladores de diferentes fabricantes, diferentes gerações e diferentes protocolos ficam lado a lado — um Siemens S7 em um skid, um CLP Allen-Bradley no seguinte, medidores de energia e drives de frequência variável Modbus na subestação, sensores IO-Link na linha de embalagem, máquinas-ferramenta CNC na oficina e controladores BACnet operando o HVAC do edifício. Quase nada disso foi projetado para compartilhar dados com qualquer outra coisa.

A tarefa da extração de dados de fábrica é obter medições confiáveis, nomeadas e com registro de data e hora de todos esses equipamentos e levá-las a um único lugar — sem refazer a fiação da planta, substituir controladores ou reescrever programas de CLP. Na prática, isso significa falar o protocolo nativo de cada dispositivo, transformar registradores e tags brutos em valores de engenharia nomeados com unidades, anexar um sinal de qualidade para que você saiba se uma leitura é confiável e fazer isso de forma robusta no edge mesmo quando a rede cai.

O IronFlock resolve isso com uma família de apps coletores leves, implantados no edge — um por família de protocolo. Cada um roda como um container Docker comum em qualquer gateway Linux, descobre automaticamente o que pode, normaliza endereços brutos em valores nomeados, faz buffer durante interrupções e transmite tudo para o banco de dados de séries temporais do seu projeto. Cada coletor é configurado inteiramente no navegador e vem com um modo de demonstração, para que você possa avaliar a experiência completa antes de conectar qualquer hardware.

A realidade do brownfield

Não existe um único protocolo que cubra uma fábrica. A pergunta prática é sempre “qual coletor lê o meu equipamento?” A tabela abaixo mapeia o equipamento que você provavelmente encontrará para o coletor que o atende.

Equipamento que você encontraráProtocolo típicoColetor a usar
Siemens S7-1200/1500/300/400, Allen-Bradley Logix, qualquer servidor OPC UA, além de dispositivos ModbusS7comm, EtherNet/IP, OPC UA, ModbusIndustrial Collector
Masters IO-Link e os sensores inteligentes por trás deles (ifm, Balluff, Pepperl+Fuchs)IO-Link sobre HTTP / OPC UA / MQTTIO-Link Collector
Medidores de energia, VFDs, compressores de ar, inversores, qualquer controlador baseado em registradoresModbus TCP / RTUModbus Collector
Máquinas-ferramenta CNC e equipamentos de chão de fábrica (HAAS, Mazak, DMG Mori, Fanuc, Okuma)MTConnectMTConnect Collector
HVAC, chillers, iluminação, medidores de energia, sistemas de gestão predialBACnet/IPBACnet Collector

Modbus e OPC UA funcionam hoje, assim como IO-Link, MTConnect e BACnet. Os drivers Siemens S7 (S7comm) e Allen-Bradley (EtherNet/IP) do Industrial Collector são alimentados pelo motor Apache PLC4X e estão sendo validados em diversos dispositivos — controladores S7-1200/1500 já podem ser lidos hoje por meio de seu servidor OPC UA integrado.

Onde os coletores do IronFlock compartilham uma abordagem

Qualquer que seja o protocolo coletado, todos os cinco apps funcionam da mesma forma por baixo dos panos. Eles gravam nas mesmas tabelas de banco de dados por projeto (gateways, assets, datapoints, measurements, assetstatus), fazem buffer das leituras localmente e as encaminham em ordem quando o link upstream com a plataforma retorna, isolam cada dispositivo para que uma máquina inacessível nunca trave as outras, e são configurados ao vivo no navegador sem arquivos de configuração ou reinicializações. Isso vale independentemente de como o IronFlock é implantado — nuvem gerenciada, nuvem privada ou um appliance on-premises totalmente offline. Cada página abaixo repete essas características compartilhadas para que se sustente por conta própria.

Limites conhecidos

Alguns equipamentos legados ainda não têm um caminho direto. Allen-Bradley MicroLogix / SLC legados (PCCC sobre DF1), células somente Profibus sem uma porta Ethernet sobressalente, pacotes operados apenas a partir de um DCS da planta e equipamentos sem nenhum controlador digital (somente cabeados) precisam de um gateway, uma ponte de protocolo ou um retrofit de sensores. Se você não tem certeza se seu equipamento é coberto, entre em contato — se um dispositivo fala Modbus ou OPC UA, ele quase certamente funciona hoje, e novos drivers e pacotes de perfis são adicionados mediante solicitação.

Os coletores

  • Industrial Collector — um app para todo o chão de fábrica: Siemens S7, Allen-Bradley, Modbus e OPC UA lado a lado, com um catálogo de perfis de equipamentos pré-mapeados.
  • IO-Link Collector — masters IO-Link e sensores inteligentes com descoberta automática e decodificação automática de IODD sobre HTTP, OPC UA ou MQTT.
  • Modbus Collector — a maneira mais leve de ler a enorme base instalada de medidores, drives e controladores Modbus.
  • MTConnect Collector — máquinas-ferramenta CNC e equipamentos de chão de fábrica sobre o padrão aberto MTConnect, com descoberta sem configuração.
  • BACnet Collector — automação predial, HVAC e sistemas de energia sobre BACnet/IP, com descoberta automática de rede e de pontos.

Para onde vão os dados

Cada coletor armazena suas leituras no banco de dados privado de séries temporais do seu projeto, onde ficam imediatamente disponíveis para o restante da plataforma: consulte-as e modele-as via Data Backend, visualize-as ao vivo em Dashboards IoT e boards SCADA, e monitore-as com o app Alarmes para notificações por SMS/e-mail. Para colocar dispositivos online e instalar esses apps, consulte Gerenciamento de Dispositivos e Gerenciamento de Apps.

Da coleta ao insight: um padrão típico de implementação

A extração é a fundação, não o objetivo. Ninguém quer registradores e tags — as plantas querem números de OEE, alertas antecipados antes que um fuso falhe, energia por peça, um relatório de turno que se escreve sozinho. Por isso, a implantação típica do IronFlock vem em duas camadas que permanecem claramente separadas:

Camada 1 — coletar. Instale os apps coletores que correspondem ao seu equipamento nos gateways ao lado dele e mapeie suas máquinas no navegador. A partir desse ponto, medições nomeadas, com registro de data e hora e com sinalização de qualidade se acumulam continuamente no banco de dados padronizado do seu projeto — todo projeto recebe o mesmo, de modo que um coletor se comporta de forma idêntica onde quer que seja instalado, e o dono do projeto ganha um ponto central para inspecionar tudo o que está sendo coletado. Dentro dele, os dados de cada app vivem em seu próprio esquema isolado: um ativo único e crescente que pertence a você, privado por app por padrão.

Camada 2 — consumir. Instale (ou construa) os apps que transformam essas medições em decisões, e deixe que eles leiam os dados dos coletores por meio do acesso a dados entre apps:

  • Um app de dashboard OEE pronto para uso consome estados de máquina e contadores de produção e entrega disponibilidade, desempenho e qualidade por linha — ao vivo na parede, sem uma única reunião de integração.
  • Um app de manutenção preditiva treina com meses de histórico de vibração, corrente e temperatura que os coletores já reuniram, e então pontua o fluxo ao vivo para sinalizar o rolamento que começou a desviar.
  • Análises de energia cruzam o consumo dos medidores Modbus com os contadores de produção das máquinas para reportar energia por peça, desperdício em carga ociosa e risco de pico de carga.
  • Apps de relatórios e qualidade leem as mesmas tabelas para preencher automaticamente livros de turno, registros de lote e trilhas de auditoria.
  • Um runtime Node-RED (ou qualquer bancada geral) declara que consome todos os dados do projeto com um único curinga e, então, descobre as tabelas disponíveis em tempo de execução — de modo que um engenheiro pode conectar fluxos por todos os coletores e apps de análise do chão de fábrica sem escrever uma integração para cada um.

Cada app consumidor declara de quais dados dos coletores precisa — uma lista específica, ou - app: "*" para tudo — e você aprova ou revoga esse acesso por projeto com um interruptor — sempre somente leitura. Como todo coletor do IronFlock grava o mesmo esquema de tabelas (gateways, assets, datapoints, measurements, assetstatus), um app consumidor escrito para um coletor funciona com todos eles: o dashboard OEE não se importa se os estados de máquina chegaram via S7, Modbus, MTConnect ou IO-Link.

O resultado é uma arquitetura que cresce com você em vez de prendê-lo: comece com um coletor em uma linha, adicione apps de análise quando estiver pronto, troque ou estenda qualquer camada de forma independente — e, se os apps de prateleira não servirem, construa seu próprio consumidor sobre os dados que você já coleta.

Last updated on