Convergência TI/TO Explicada: Cultura, Arquitetura e uma Camada de Dados Compartilhada

A convergência TI/TO é o processo de colocar a tecnologia da informação (sistemas de negócio, nuvem, analytics) e a tecnologia operacional (CLPs, SCADA, máquinas) sobre uma base comum, para que ambas trabalhem com os mesmos dados. Neste artigo você vai entender por que esses dois mundos se desenvolveram de forma tão diferente, o que realmente precisa mudar no lado técnico e cultural e como um namespace MQTT compartilhado oferece às equipes de TI e TO uma única visão ao vivo da planta, sem comprometer as prioridades de nenhum dos lados.

Dois mundos que se afastaram

A tecnologia operacional nasceu no chão de fábrica. Sua missão é manter um processo físico funcionando com segurança, a cada segundo, por décadas. Um CLP que controla um forno, numa siderúrgica em Minas Gerais ou numa fábrica de cerâmica em Santa Catarina, pode executar o mesmo programa durante quinze anos, e isso é considerado um sucesso. Mudança é risco, e uma parada pode danificar equipamentos ou ferir pessoas.

A tecnologia da informação nasceu no escritório. Sua missão é processar informações de negócio com segurança e eficiência. Os sistemas recebem patches todo mês, são substituídos a cada poucos anos, e uma indisponibilidade custa caro, mas raramente é perigosa. Mudar é normal, e manter-se atualizado faz parte de estar seguro.

Nenhuma das duas visões está errada. Elas são otimizadas para consequências de falha diferentes. A maior parte do atrito em projetos de convergência vem de pessoas aplicando as regras de um mundo ao outro.

O que a convergência TI/TO realmente significa

A convergência costuma ser mal interpretada como "colocar os CLPs na rede corporativa". Essa é a versão que deixa os engenheiros de TO nervosos, e com razão. Feita corretamente, a convergência TI/TO significa três coisas mais específicas:

1. Dados compartilhados. Os dados de produção fluem de forma confiável para os sistemas de negócio, e o contexto de negócio, como ordens e receitas, fica disponível para a operação. O mesmo fluxo pode alimentar dashboards, analytics e um gêmeo digital da linha.
2. Práticas compartilhadas. Segurança, identidade, monitoramento e gestão de mudanças são aplicados de forma consistente, adaptados às restrições de cada lado.
3. Pessoas que colaboram. As equipes entendem as prioridades uma da outra e são donas, juntas, da camada de integração.

O que a convergência não exige é uma rede plana. O modelo Purdue e as zonas da IEC 62443 continuam valendo. A integração acontece em uma fronteira definida, normalmente uma DMZ industrial, e a rede da planta permanece segmentada. Nossa comparação entre o modelo Purdue e a ISA-95 explica como essas camadas se relacionam.

Os blocos técnicos

Dados orientados a eventos em vez de integrações ponto a ponto

A forma tradicional de dar à TI acesso aos dados de TO é uma integração ponto a ponto: o MES consulta o SCADA, o ERP consulta o historiador, uma ferramenta de relatórios lê um banco de dados que o historiador alimenta. Cada ligação é customizada, frágil e pertence a quem a construiu. Adicionar um novo consumidor significa mais uma integração.

A mensageria publish/subscribe muda isso. Cada fonte de TO publica seus dados uma única vez em um broker. Cada consumidor de TI assina o que precisa. O lado de TO nunca precisa saber quem está ouvindo, e o lado de TI nunca precisa de uma conexão para dentro da planta. Se o papel do broker é novidade para você, veja o que um broker MQTT faz.

Um Unified Namespace como linguagem comum

Um broker sozinho não torna os dados compreensíveis. Um Unified Namespace (UNS) acrescenta estrutura: cada valor fica em um topic previsível baseado na hierarquia ISA-95, como connectmq/acme/plant1/assembly/line2/press04/state. O engenheiro de TO reconhece a localização física. O desenvolvedor de TI enxerga uma API estável e documentada. Os dois leem o mesmo topic. Nosso guia sobre como construir um Unified Namespace detalha o projeto.

Conectividade somente de saída

Os gateways de TO se conectam ao broker para fora, via TLS, e os consumidores de TI também se conectam para fora. Nenhuma porta de entrada é aberta para a planta. Essa é a propriedade mais importante para conquistar o apoio da equipe de segurança de TO. O padrão é explicado em detalhes no nosso artigo sobre MQTT em uma DMZ industrial.

Responsabilidade clara pela camada de dados

Alguém precisa ser dono das regras de nomenclatura de topics, das convenções de payload, das credenciais de acesso e da qualidade dos dados. Em organizações maduras, isso se torna uma função de DataOps industrial situada entre TI e TO. Saiba mais na nossa visão geral sobre DataOps industrial.

Exemplo: as duas equipes lendo os mesmos dados ao vivo

Veja como a convergência funciona na prática. Um gateway de TO publica o estado da máquina como retained messages no UNS. Um desenvolvedor de TI escreve algumas linhas de Python para alimentar uma aplicação de negócio com esse estado, sem jamais tocar no CLP ou no gateway.

Teste primeiro no servidor MQTT público (gratuito), que serve para testes e protótipos. Publique um estado retido como o "lado de TO":

mosquitto_pub -h broker.connectmq.com -p 1883 -i ot-sim-$RANDOM -r \
  -t connectmq/demo/itot42/plant1/assembly/line2/press04/state \
  -m '{"state":"RUNNING","order":"WO-1182","ts":"2026-10-16T09:12:00Z"}'

Depois execute o subscriber do "lado de TI":

import json
import uuid
import paho.mqtt.client as mqtt

TOPIC = "connectmq/demo/itot42/plant1/+/+/+/state"

def on_connect(client, userdata, flags, reason_code, properties):
    print("Connected:", reason_code)
    client.subscribe(TOPIC, qos=1)

def on_message(client, userdata, msg):
    parts = msg.topic.split("/")
    area, line, machine = parts[4], parts[5], parts[6]
    data = json.loads(msg.payload)
    # Entrega a um sistema de negócio; aqui apenas imprimimos uma linha
    print(f"{area:10} {line:6} {machine:8} {data['state']:8} order={data.get('order')}")

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id=f"it-app-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_forever()

O subscriber recebe o estado retido imediatamente ao se conectar e, depois, cada mudança no momento em que acontece. O engenheiro de TO pode abrir um MQTT explorer no desktop no mesmo topic e ver exatamente a mesma mensagem. Essa visão compartilhada é como a convergência se parece no dia a dia. Em produção, cada lado usa suas próprias credenciais do broker na porta 8883, e dados reais da planta nunca vão para uma área pública, que qualquer pessoa pode ler.

Passos culturais que fazem a convergência durar

A tecnologia é a metade mais fácil. Estas práticas ajudam no lado humano:

1. Comece por um problema de TO. Escolha um caso de uso que importe para a planta, como paradas não planejadas em uma máquina gargalo. Projetos conduzidos pela TI que só servem a relatórios raramente ganham o apoio da TO.
2. Deixe a TO ser dona da borda. Os engenheiros de automação decidem o que é lido de qual CLP, com que frequência e em qual modo. A TI é dona dos consumidores.
3. Combinem a fronteira. Registrem por escrito onde termina a responsabilidade da TO, normalmente na conexão de saída do gateway, e onde começa a da TI.
4. Usem um único vocabulário. A hierarquia ISA-95 nos nomes de topics dá às duas equipes palavras comuns para sites, áreas, linhas e máquinas.
5. Formem duplas. Coloque um desenvolvedor de TI e um engenheiro de automação no mesmo piloto. Duas semanas trabalhando juntos rendem mais do que qualquer workshop.
6. Respeitem as janelas de mudança. As atualizações de gateways seguem os cronogramas de manutenção da TO, não as "patch Tuesdays" da TI.

Onde um broker MQTT gerenciado ajuda

A camada de dados compartilhada precisa ser segura, estar sempre disponível e receber manutenção, o que é trabalho típico de TI. Rodá-la em hardware da planta joga esse trabalho para a TO, que normalmente não o quer. Um broker MQTT gerenciado é um território neutro onde as duas equipes se encontram. O ConnectMQ detecta automaticamente topics ISA-95 e de Unified Namespace, mostra os dispositivos agrupados por nível ISA-95, decodifica Sparkplug B para as equipes que o utilizam e oferece um explorador de topics ao vivo que tanto um engenheiro de automação quanto um desenvolvedor podem usar. Organizações com regras rígidas de residência de dados podem executar o ConnectMQ BYOC na própria conta de nuvem. Para comparar modelos de hospedagem de forma mais ampla, veja nosso guia de broker MQTT na nuvem e, para o panorama industrial completo, o guia de IoT Industrial com MQTT.

Dê à TI e à TO um único namespace no ConnectMQ

Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito. Publique o estado de uma máquina em uma árvore de topics ISA-95, dê uma credencial a cada equipe e deixe a conversa começar a partir de dados compartilhados, e não de planilhas concorrentes.

Perguntas frequentes

O que é convergência TI/TO em termos simples?

É fazer os sistemas de negócio e os sistemas da planta trabalharem com os mesmos dados, com práticas comuns de segurança e de gestão de mudanças. Não significa unir as redes nem dar à TI o controle dos CLPs.

A convergência TI/TO aumenta o risco cibernético?

Pode aumentar, se for feita achatando as redes. Feita com segmentação, conexões somente de saída por meio de uma DMZ e credenciais por client, ela normalmente melhora a visibilidade e a segurança em comparação com integrações improvisadas.

Por que o MQTT é popular na convergência TI/TO?

Os clients se conectam para fora, até um broker, então nenhuma porta de entrada para a planta é necessária. O modelo publish/subscribe também permite que muitos consumidores de TI usem os mesmos dados de TO sem integrações adicionais.

Quem deve ser dono do Unified Namespace?

Idealmente, uma equipe conjunta ou uma função de DataOps industrial. A TO é dona do que é publicado a partir da borda, a TI é dona dos consumidores, e a equipe conjunta é dona das regras de nomenclatura e dos padrões de payload.