Como o streaming de dados de tecnologia operacional para o Databricks permite que agentes de AI compostos raciocinem, otimizem e aconselhem, e não apenas monitorem.
09:14, meio do turno. A enchedora desarma. O gerente de linha tem minutos, não horas, antes que os equipamentos seguintes comecem a ficar sem suprimento. A equipe já sabe o que fazer mecanicamente. As perguntas que demoram mais para ser respondidas são as de planejamento. Ainda conseguimos atingir a meta do turno? É mais barato aumentar a velocidade depois ou pagar hora extra? Essa mesma falha já ocorreu nesta linha antes e como o turno anterior se recuperou?
Os dados para responder a essas três perguntas já existem, espalhados por PLCs, SCADA, MES, ERP e LIMS.
O ProdLine CoPilot foi desenvolvido para essa janela de tempo. Ele lê o estado em tempo real da Databricks Data Intelligence Platform, encaminha a pergunta para um especialista no domínio e executa os cálculos subjacentes (recuperação de cronograma, esgotamento, risco de qualidade). O plano retorna testado contra 1.000 cenários de agendamento, equilibrando compensações de custo, hora extra e serviço. O gerente de linha escolhe. O sistema gera os rascunhos dos artefatos (ordem de serviço, retenção, nota de cronograma) para aprovação.
Uma linha de embalagem típica de CPG (engarrafamento, enlatamento, snacks, cosméticos) possui de 15 a 20 máquinas. Quando uma enchedora ou rotuladora para, os buffers cobrem apenas alguns minutos antes que a linha fique sem suprimento e a produção caia bem abaixo da capacidade nominal. O OEE de classe mundial fica próximo a 85%; muitas fábricas estão mais perto da faixa de 70% a 75%. A 500 caixas/hora em um cronograma de 24/5 com contribuição de €10 por caixa, um ponto de OEE equivale a aproximadamente €300 mil por ano. Reduza uma diferença de 10 pontos em uma linha e você estará na faixa de alguns milhões; em uma fábrica com uma dúzia de linhas, isso se acumula rapidamente.
Os dados para reduzir essa diferença já existem:
Esses sistemas não se comunicam entre si. As pessoas que precisam de respostas (gerentes de linha, líderes de turno, planejadores) geralmente não escrevem SQL.
O padrão é familiar: primeiro os relatórios de fim de turno, a consulta do analista na manhã seguinte e, depois, uma reunião de RCA 24 horas após o ocorrido. Tudo isso enquanto a decisão de recuperação (velocidade, hora extra, CIP) já foi tomada durante o turno.
Transmitir OT para a Databricks não é apenas uma atualização de painel. Unir OT com MES, ERP e LIMS em um lakehouse governado é o que permite que os agentes analisem o estado em tempo real, otimizem sob restrições reais e façam recomendações durante o turno, em vez de depois do ocorrido.
O padrão antigo era estruturar uma infraestrutura complexa do tipo Kafka (brokers, partições, grupos de consumidores) apenas para mover dados da fábrica. O Zerobus Ingest substitui isso. Ele é baseado em push e serverless. Qualquer coisa que possa fazer chamadas gRPC ou REST (gateway de PLC, conector de historiador, dispositivo de borda) insere linhas em tabelas Delta do Unity Catalog.
Sem brokers, sem partições; você escala abrindo mais conexões. Combine-o com as Lakeflow Spark Declarative Pipelines e a arquitetura medalhão padrão Bronze, Silver e Gold para telemetria, sinais de qualidade, eventos e inventário.
O MES, o ERP e o LIMS chegam em uma cadência mais lenta do que a OT de subsegundos (espelhamento, lote ou CDC), mas eles ficam ao lado das tabelas de OT sob um único catálogo governado, em vez de em um warehouse separado.
Uma vez que os dados estão inseridos, as mesmas tabelas alimentam SQL, Genie, AI Search, Model Serving e agentes, com linhagem compartilhada sob o Unity Catalog. Sinais preditivos, recuperação de cronograma e análises seguintes leem a partir dessas tabelas governadas, de modo que cada nova funcionalidade grava na cópia existente em vez de provisionar a sua própria.
O Zerobus + Delta lida com a ingestão em tempo quase real com latência de poucos segundos, governada sob o Unity Catalog. Para a UI em tempo real nesta demonstração, o produtor também grava diretamente no Lakebase: um atalho para obter a sensação de tempo real hoje, não o padrão de longo prazo. A leitura em milissegundos nessas mesmas tabelas Delta é o que o Lakehouse//RT, o data warehouse em tempo real da Databricks no lakehouse, gerenciará.
Muitas fábricas executam relatórios em um lugar e modelos em outro, de modo que a própria linha acaba tendo mais de uma versão da verdade entre os sistemas. Essa divisão quebra os copilotos em tempo de turno:
O Lakehouse na Databricks elimina essa divisão em cada um desses três pontos. Há uma única cópia dos dados (Delta aberto no armazenamento em nuvem, não uma extração separada por carga de trabalho). A governança reside nessa cópia no Unity Catalog, de modo que as permissões do analista e as permissões do agente vêm da mesma fonte. E o streaming, SQL, AI e serving funcionam todos em uma única base, para que o relatório matinal e a tela em tempo real mostrem o mesmo número.
Especialistas e otimizadores leem as mesmas tabelas governadas que seus pipelines mantêm. Não há um banco de dados de AI separado.
O orquestrador é a porta de entrada. Ele aceita uma pergunta em linguagem natural, carrega o estado atual do Unity Catalog (máquinas, eventos, cronograma, inventário, qualidade, restrições) e direciona a intenção para o especialista correto.
Cada chamada lê o estado mais recente do UC antes que o LLM seja iniciado. O sistema recomenda e cria rascunhos de artefatos (chamados, aprovações, notas de turno). A execução permanece com o gerente de linha, qualidade e manutenção.
A memória de conversação curta reside no Lakebase, e o corpus de incidentes anteriores no AI Search. O Model Serving serve os modelos e o MLflow rastreia cada chamada.
Um único agente genérico simplifica demais ou perde o foco. RCA de tempo de parada, inventário e cálculos de cronograma precisam de dados e matemática diferentes. Uma lista de especialistas mant ém cada prompt focado e cada ferramenta direcionada para a pergunta.
Por exemplo, o Downtime Analyst não consome contexto em tabelas de inventário, e o Schedule Optimizer não extrai linhas brutas de verificação de qualidade da mesma forma que o Quality.
| Especialista | O que faz |
|---|---|
| Downtime Analyst | Causa raiz, cascata entre máquinas, prioridade de recuperação; eventos + sensores |
| Quality Specialist | SPC em envase, torque, rótulos, peso da caixa; retenção/liberação; risco bayesiano |
| Supply Chain Advisor | Dezenas de insumos de linha (ex: rótulos, filmes, tampas, adesivos, produtos químicos de processo) — taxas de consumo, esgotamento, urgência de novos pedidos |
| OEE Coach | Perda de disponibilidade / desempenho / qualidade; Pareto; Genie para tendências |
| Schedule Optimizer | Planos de recuperação estocásticos / MILP; compensações: custo, risco de cronograma/serviço, rendimento (throughput) |
| Maintenance Predictor | Anomalias (Z-score, IQR); sinais do tipo RUL; compensações de PM |
| Strategic Advisor | Tendências de múltiplos turnos; roteiro de melhorias; enquadramento de capex/opex; benchmarking |
| Shift Briefing | Leituras de reuniões pré-turno / passagem de turno pós-turno; resumo otimizado para Genie e focado em dispositivos móveis (mobile-first) |
Os especialistas chamam um conjunto pequeno e fixo de ferramentas. O SQL Query e o Genie Space realizam leituras governadas, da mesma forma que o restante da organização. O Calculator executa cálculos de OEE, recuperação e esgotamento em Python (NumPy and Pandas) sobre a telemetria do Databricks SQL. Um Anomaly Detector executa Z-score e intervalo interquartil (IQR) sobre janelas móveis diretamente nessas tabelas. O Plan & Constraints mantém os limites de velocidade por linha, janelas de CIP, regras de troca de formato (changeover) e política de horas extras. O Similar Cases recupera incidentes históricos do Databricks AI Search.
Muitos copilotos de manufatura são apenas camadas finas sobre LLMs. O ProdLine direciona para solucionadores reais (do tipo que as equipes de pesquisa operacional usam), por meio de linguagem natural.
| Otimizador | Método | O que resolve |
|---|---|---|
| Schedule Recovery | MILP (OR-Tools SCIP) | Velocidade, OT, CIP — ideal sob o modelo definido, não uma heurística vaga |
| Stochastic Schedule | SAA + cenários | Plano robusto em toda a variabilidade de OEE / microparadas |
| Production Forecast | Monte Carlo (ex: 1.000 caminhos) | Faixas de conclusão P10/P50/P90 a partir do histórico |
| Quality Risk | CPT bayesiana | Pontuação de risco + direcionadores |
| OEE Loss Analysis | Pareto | Classificação de perdas por magnitude / ROI |
| Multi-Shift Planner | Otimização sequencial | Velocidade entre turnos, OT, CIP, PM |
| RUL Estimator | Extrapolação de tendências | Compensação de tempo de PM |
Nada é executado sem a aprovação de um ser humano. O gerente de linha é o responsável pela recuperação, a equipe de qualidade é responsável pela retenção e liberação, e a manutenção é responsável pela ordem de serviço. O objetivo é reduzir a carga cognitiva de alternar entre planilhas, rádios e painéis, e não remover o gerente de produção.
Ele precisa responder a três perguntas em menos de um minuto: o que está acontecendo, quais são as opções realistas e quanto cada opção custa em termos de rendimento, horas extras, qualidade e serviço.
Etapas de aprovação (por design):
| Função | Aprova |
|---|---|
| Gerente de linha | Recuperação: velocidade, horas extras, cronograma |
| Qualidade | Retenção/liberação, desvios |
| Manutenção | Escopo do trabalho e cronograma |
A demonstração atual cobre o loop de raciocínio e recomendação. O próximo passo é fechar o loop com gravações de retorno (write-backs) no sistema, todas projetadas como rascunhos em vez de controle automático.
A transferência para o CMMS é um rascunho de ordem de serviço (falha diagnosticada, escopo recomendado, tempo estimado, peças necessárias) para o planejador agendar. Para a qualidade, o QMS e o LIMS recebem um registro de desvio pré-preenchido (lote, máquina, IDs de amostra, gravidade, disposição recomendada) que o líder de qualidade revisa e define a disposição. O MES e o sistema de planejamento e programação avançados (APS) recebem um rascunho de atualização do cronograma com ajustes de velocidade, horas extras, alterações de sequência e a justificativa de recuperação, gravados de volta para a execução do turno.
A rastreabilidade segue o mesmo roteiro: cada recomendação armazena suas entradas, premissas, restrições, aprovador e resultado de ponta a ponta, apoiando a passagem de turno e a melhoria contínua.
A parte mais difícil da implementação em várias plantas são os dados, não a IA. Cada planta tem suas próprias máquinas, SOPs e esquemas de LIMS. O que torna a segunda planta um incremento, e não um projeto paralelo, é a camada de streaming subjacente: cada planta adota o mesmo padrão Zerobus, arquitetura de medalhão e governança do Unity Catalog, com suas próprias tabelas e Genie Space sob um namespace dedicado.
Os otimizadores permanecem parametrizados. Uma tabela line_constraints define os limites de velocidade, limites de horas extras, janelas de CIP e transições (changeovers), de modo que alterar os dados altera o comportamento, sem a necessidade de uma nova implantação.
A mesma base financia o próximo caso de uso. Energia e sustentabilidade leem a mesma telemetria, a qualidade do fornecedor se baseia na junção (join) do LIMS e a segurança se baseia no fluxo de eventos. Cada novo projeto é implantado na infraestrutura que o primeiro já pagou, em vez de criar uma plataforma paralela.
Clone o repositório de código e execute databricks bundle deploy em seu próprio workspace. Para usar os dados da sua própria planta, aponte o produtor para o seu historiador em vez do simulador; o Zerobus, o layout de medalhão, as ferramentas de agente e os rascunhos com intervenção humana (human-in-the-loop) permanecem inalterados. Abra prodline_copilot_film.html em um navegador para uma demonstração animada de dois minutos antes de clonar.
Tem interesse em criar seu próprio assistente de monitoramento de linha e gostaria de saber mais? Entre em contato com o representante da sua conta Databricks. Um especialista da Databricks também pode ajudar a planejar a integração de OT, MES, ERP e LIMS em um único lakehouse governado.
Acrônimos usados neste post, em ordem alfabética.
(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original
Assine nosso blog e receba os posts mais recentes diretamente na sua caixa de entrada.