Três sonhos para uma fábrica diferente

Existem três coisas que qualquer pessoa que já tenha colocado em funcionamento uma máquina industrial se perguntou pelo menos uma vez. Três coisas que não se dizem em voz alta porque parecem utopias. Este artigo as coloca em fila.

Uma cena, só para começar

Turno da noite, setor X. Uma linha para. O painel HMI mostra um código: E-1423. O manual está em um armário a três edifícios de distância. O técnico que conhece aquela máquina está de férias. O operador tem dois caminhos: chamar o serviço de assistência — que responde talvez pela manhã — ou tentar adivinhar. Em todo o mundo industrializado, cenas como esta se repetem centenas de vezes por noite.

O problema não é que falta um manual. Manuais existem demais. O problema é que a máquina sabe muito bem do que precisa — o sensor de pressão está dizendo há trinta segundos que algo está errado — mas não consegue falar uma língua que o operador entenda, e quando consegue falá-la, conta o problema em vez da solução. "Pressão fora da faixa" não é uma frase útil às três da noite. "Verifique a válvula V12 do circuito de ar, provavelmente travou" é.

É a partir daqui que parte o trabalho que estamos a fazer. Não um novo PLC. Não um HMI mais bonito. Uma forma diferente de pensar sobre o que deve ser, em 2026, o software que faz mover uma máquina. E três ideias fixas — chamem-lhes sonhos — que estamos a tentar manter unidas.

Sonho número um: automatizar sem programar

A automação industrial, como é feita hoje, requer uma figura muito particular: alguém que saiba programar numa linguagem — a família IEC 61131-3, com os seus dialetos ladder, function block, structured text — que não se usa praticamente em mais lado nenhum no mundo do software. Quem sabe essas linguagens é raro, é caro, e está quase sempre com três semanas de atraso.

O paradoxo é que quem conhece realmente a máquina muitas vezes não é o programador. É o chefe de departamento, o técnico de manutenção experiente, o integrador que instalou vinte instalações semelhantes. Estas pessoas sabem o que a máquina deve fazer. Não têm nenhuma vontade de aprender uma linguagem de programação nascida nos anos '90 para o explicar.

A ideia é inverter a cadeia. Os desenvolvedores de software escrevem componentes reutilizáveis — controle de movimento, gerenciamento de sensores, sequências operacionais — uma única vez, em linguagens modernas e de propósito geral. O integrador de máquinas não os programa: os compõe, especificando por voz ou por escrito o que a máquina deve fazer. Um modelo linguístico de grande porte — um LLM — atua como tradutor: recebe a especificação funcional do integrador e a transforma em uma configuração executável, montando os componentes já escritos e testados.

Não é a fantasia de "a IA que escreve o código por você". É algo mais modesto e mais realista: a IA que lê sua especificação e escolhe, entre componentes certificados, como combiná-los. O código crítico — aquele que move um eixo com um ciclo de 5 milissegundos — continua a ser escrito por um ser humano, em uma linguagem que garanta determinismo e confiabilidade. Mas esse código é escrito uma vez para todas e reutilizado cem vezes.

Sonho número dois: a máquina que sabe de si

Hoje, as máquinas falam pouco e mal. Um alarme é um código numérico. Um diagnóstico é uma série de LEDs. Um log é um arquivo binário que apenas o fabricante sabe abrir. O conhecimento de como funciona aquela máquina, com aquelas tolerâncias, após aqueles dois mil ciclos, está na cabeça de uma pessoa, ou em um PDF em algum lugar.

O segundo sonho é que seja a máquina a se conhecer. Não em sentido místico — em sentido muito concreto: a documentação técnica, os parâmetros de processo, os casos de falha típicos, os procedimentos de intervenção não estão mais em um armário ou em um servidor documental separado, mas dentro da própria máquina, legíveis pelo seu próprio software. E quando algo não vai, a máquina não diz "erro 1423". Diz "a válvula V12 provavelmente emperrou, você deveria verificá-la; enquanto isso, posso prosseguir em modo degradado a 60% da velocidade".

A diferença é entre um objeto passivo que sinaliza e um objeto ativo que propõe. O primeiro deixa o problema para o operador. O segundo o enfrenta junto com ele.

Isto requer duas coisas pouco comuns. Primeiro, que o conhecimento da máquina — historicamente guardado em manuais, esquemas elétricos, desenhos CAD e na cabeça de técnicos — seja formalizado e integrado no sistema. Segundo, que o sistema tenha um interlocutor capaz de manter uma conversa: novamente, um LLM, usado aqui não para gerar código, mas para traduzir sintomas em ações compreensíveis, na língua de quem está em frente ao painel.

Mais uma vez, não é magia. É documentação escrita melhor, indexada melhor, e uma interface conversacional por cima. Mas muda tudo para quem faz o turno da noite.

Sonho número três: o software que roda em qualquer lugar

O terceiro sonho é o mais técnico e, paradoxalmente, o mais político. Hoje a automação industrial é um mundo de ecossistemas fechados. Cada grande fabricante de CLP tem a sua linguagem, o seu ambiente de desenvolvimento, o seu hardware, os seus drivers, a sua rede de revendedores. Mudar de fornecedor significa reescrever tudo.

A ambição aqui é construir um sistema de software que rode em hardware genérico — um mini-PC industrial, um controlador embarcado, um servidor no porão — escolhendo o hardware com base no orçamento e no desempenho necessário, não com base em qual marca de CLP ganhou a negociação. Um sistema operativo Linux em versão real-time, placas de comunicação baseadas em padrões abertos (EtherCAT em todos), componentes de software em linguagens modernas para as partes determinísticas e em linguagens mais ágeis para aquelas que não o são.

A regra, e aqui é onde a utopia se torna concreta: o hardware deve impactar o desempenho, nunca a confiabilidade. A mesma lógica, numa máquina menos potente, deve funcionar da mesma forma — apenas mais lentamente. Se o tempo de ciclo passar de 5 para 10 milissegundos, o eixo move-se com a mesma precisão mas a metade da velocidade. Nunca "quase igual". Nunca "funciona exceto naquele caso". Mesmo sistema, as mesmas decisões, as mesmas garantias.

Esta é a parte em que engenheiros experientes começam a rir. Sabem muito bem que o tempo real é difícil, que o Linux não nasceu como um sistema de tempo real, que os LLM não rodam em um Raspberry Pi, que misturar linguagens diferentes no mesmo stack tem mais armadilhas do que prometem os tutoriais. Eles têm razão. Mas a direção é essa, e os blocos de construção para construí-la — as extensões de tempo real do kernel Linux, stacks EtherCAT open source maduros, LLMs que começam a rodar em hardware modesto — existem, hoje, pela primeira vez todos juntos.

Por que "utopia"

Utopia é uma palavra honesta. Nenhuma dessas três coisas é, hoje, um produto finalizado. A primeira requer LLMs confiáveis o suficiente para serem usados em um contexto produtivo, e estamos nos primeiros passos. A segunda requer um trabalho enorme de formalização do conhecimento industrial, que hoje é quase todo informal. A terceira requer a construção de alternativas abertas contra ecossistemas fechados que têm vinte anos de vantagem.

Mas os três sonhos juntos, se colocados em fila, desenham uma direção precisa: uma automação em que o hardware é commodity, o software é reutilizável, o conhecimento é incorporado na máquina, e a figura do programador PLC — hoje gargalo de uma indústria inteira — não desaparece, mas se move para onde realmente serve, ou seja, para escrever os componentes básicos de uma vez por todas.

Nos artigos que se seguirão, contaremos as peças que estamos construindo deste quebra-cabeça. Uma de cada vez, sem prometer que o quebra-cabeça esteja completo. Não está. Mas o desenho começa a ser visível.