Monitoramento industrial

Plataforma de OEE — eficiência global de equipamento — que lê telemetria de máquina no chão de fábrica e devolve indicador em tempo real para quem opera. Se eu pudesse levar um projeto só para uma conversa, seria este.

Por que este projeto é diferente para mim

Trabalhei oito anos e oito meses na operação industrial deste grupo, montando produto, antes de entrar em tecnologia. Quando fui construir o sistema que mede aquele chão de fábrica, eu já sabia quais perguntas o operador faz, o que ele consegue preencher no meio do turno e o que ele nunca vai preencher. Isso não se levanta em entrevista de requisito.

O problema

Três coisas ao mesmo tempo.

Volume. Máquina emite evento continuamente, e indicador de eficiência é uma interpretação desses eventos. Guardar isso em tabela relacional comum funciona por algumas semanas, e depois a consulta do painel começa a demorar.

Interpretação. O que conta como parada planejada muda por linha, por produto e por tipo de parada: o que numa linha é parada planejada, em outra é falha. Com a regra no código, cada ajuste vira demanda de desenvolvimento, e a operação simplesmente para de pedir.

Rede. Conectividade de chão de fábrica cai por interferência, cobertura irregular entre galpões e equipamento competindo pelo mesmo espectro. Sistema que exige conexão para registrar apontamento é contornado com papel, e aí o dado que chega ao indicador é ficção.

O que eu construí

• Ingestão de telemetria por MQTT, protocolo de dispositivo e não de aplicação: mensagem pequena, conexão persistente, tolerância a rede instável
• Série temporal em TimescaleDB, hypertable sobre PostgreSQL, com janela de retenção e agregação contínua, para o painel responder rápido sobre janela longa
• Motor de regras configurável pela operação, onde quem define o que conta como parada é quem opera, na tela, sem deploy
• Atualização em tempo real por SignalR, com o painel mudando quando a máquina muda de estado
• PWA com estado local e sincronização, para o terminal continuar operando sem rede e reconciliar depois
• Frontend completo, do mesmo autor do backend

Decisões que eu defendo

Offline como requisito, decidido antes de escrever o cliente. Não é um recurso que se acrescenta na segunda fase: funcionar offline é uma premissa que atravessa cada tela, e tratá-la depois teria custado uma reescrita. A política de conflito adotada foi última escrita vence, pelo carimbo de tempo do terminal, com sincronização em lote e resultado individual por operação. O raciocínio completo, incluindo a fraqueza que essa política tem, está em ADR 3 — Operação offline como requisito de arquitetura.

Regra de negócio na mão do negócio. O motor configurável deu mais trabalho do que codificar as regras conhecidas na época. Pagou-se na primeira semana de uso, quando a operação quis contar uma parada de forma diferente e resolveu sozinha.

Banco especializado desde o começo. Começar em tabela comum e migrar depois teria custado a reescrita do modelo de consulta inteiro.

Resultado

Indicador de eficiência em tempo real no lugar de planilha preenchida de memória depois do turno, com a interpretação sob controle de quem opera.

Limite

O sistema é recente e roda numa operação só. Não tenho quilometragem de TimescaleDB em escala nem de tuning avançado, e a classe de bug mais difícil do PWA — a que só aparece na transição entre offline e online — continua sendo a que mais custa.

Stack

.NET 10 · MQTT · TimescaleDB sobre PostgreSQL · SignalR · React PWA · Kubernetes

Ver também

ADR 3 — Operação offline como requisito de arquitetura · Trajetória · Dados e persistência · Frontend React e TypeScript