Arquitetura de sistemas
Fronteiras entre MES, ERP e SCADA: desenhe as linhas pela titularidade dos objetos, não pelo departamento
A resposta direta para dividir as fronteiras entre MES, ERP e SCADA é confirmar, objeto por objeto, quem cria, quem modifica, quem executa, quem retém e quem reconcilia. O ERP normalmente é responsável pelos recursos empresariais e pelo planejamento do negócio; o MES, pela execução no chão de fábrica e pela coordenação do processo; o SCADA, pela supervisão do processo dos equipamentos, alarmes e histórico; o PLC e os controles relacionados à segurança permanecem em sistemas de controle validados. As fronteiras são desenhadas a partir de objetos, estados, tempo e responsabilidades, e não adivinhadas a partir de nomes de software.
As três camadas de sistema respondem a perguntas diferentes
O ERP se preocupa com o que produzir, quais recursos são necessários e como os resultados do negócio são contabilizados; o MES, com como uma ordem de produção executa em linhas e postos específicos e como o progresso e as anormalidades são coordenados; o SCADA, com o estado atual do equipamento, a variação das grandezas de processo e como alarmes e histórico podem ser reproduzidos.
Essas responsabilidades se cruzam, mas cruzar não significa armazenar repetidamente o mesmo estado. Uma ordem de produção pode ser planejada e mantida pelo ERP, decomposta e executada com status de chão de fábrica no MES e exibida no SCADA apenas como contexto de tarefa relacionado ao equipamento. Os campos e estados guardados por cada sistema devem ser explícitos, sem reescrita bidirecional arbitrária do mesmo campo.
| Camada | Responsabilidade primária típica | Não deve ser assumido como seu | Escala de tempo-chave |
|---|---|---|---|
| ERP e demais sistemas corporativos | Planejamento, pedidos, materiais e dados mestres ligados ao financeiro | Controle de equipamento em milissegundos e aquisição bruta de processo | Pedidos, turnos, dias e períodos contábeis |
| MES: execução no chão de fábrica | Execução de ordens, passagens por posto, prevenção de erros, rastreabilidade e coordenação do chão de fábrica | Substituir todo o planejamento do negócio ou o controle de segurança de baixo nível | Ordens de produção, lotes, postos e eventos |
| SCADA: supervisão de processo | Status em tempo real, tendências de processo, alarmes e telas de operação | Custeio corporativo e todos os fluxos de execução | Sinais em tempo real, eventos de processo e tendências históricas |
| PLC e controle de equipamentos | Lógica do equipamento, movimento e intertravamentos de controle validados | Dados mestres corporativos e coordenação de negócios entre oficinas | Ciclos de controle e intertravamentos imediatos |
Use uma matriz de titularidade de objetos para eliminar o todos são responsáveis
A matriz de titularidade deve cobrir ao menos ordens de produção, materiais, produtos ou lotes, versões de processo, equipamentos, resultados de qualidade e calendários de planejamento. Para cada objeto, liste o criador, o identificador único, os estados modificáveis, os assinantes a jusante e as regras de exclusão ou de cancelamento.
Por exemplo, o ERP pode manter os códigos de material, o MES pode reter as fotografias necessárias à execução e o consumo por lote, e o SCADA pode usar apenas o contexto de equipamento necessário. Se a substituição temporária de material é permitida no chão de fábrica, ela deve ser aprovada e devolvida por um fluxo de negócio explícito; operadores não podem editar dados mestres diretamente em qualquer camada.
| Objeto de negócio | Exemplo comum de titularidade | Uso a jusante | Exceção que deve ser acordada |
|---|---|---|---|
| Ordem de produção | Criada pelo ERP e decomposta para execução pelo MES | O SCADA obtém o contexto da tarefa atual | Cancelamento, inserção urgente, mudança de quantidade e falha no retorno de conclusão |
| Materiais e lotes | Titularidade de dados mestres corporativos e do armazém conforme o cenário atual | O MES registra prevenção de erros, emissão e relações de lote | Substituição, devoluções, desdobramentos, fusões e identidade ausente |
| Versão de processo | Sistema responsável pelo processo ou fluxo controlado | O MES valida a versão em execução; o equipamento recebe parâmetros aprovados | Vigência de versão, reversão e ajuste temporário no chão de fábrica |
| Qualidade do produto | Titularidade do julgamento de qualidade conforme o fluxo | O MES vincula o processo gerador e o destino | Retrabalho, reinspeção, concessão e cancelamento de resultado |
| Status do equipamento | O SCADA ou a camada de aquisição registra os fatos brutos | OEE e MES usam estados de negócio mapeados | Desconexão, deriva de relógio, revisão manual e conflitos de estado |
APS, WMS e QMS não devem ser presumidos como partes do MES
O APS foca em planejamento e programação com restrições, o WMS em estoques, locais e operações de armazenagem, e o QMS no planejamento da qualidade, na inspeção e nos fluxos de qualidade. Podem trabalhar intimamente com o MES, mas a decisão de construí-los como sistemas independentes depende do cenário existente, da complexidade do negócio e das fronteiras de responsabilidade; o MES não contém inerentemente todas as capacidades.
A ORPAON pode realizar, no contexto de um projeto, algoritmos de programação da produção, interfaces com WMS, rastreabilidade de qualidade e trabalhos de integração ou customização correlatos; isso não implica a existência de produtos APS, WMS ou QMS independentes e maduros. Cada proposta deve declarar item por item se a capacidade é atendida pelo sistema existente do cliente, por um sistema terceiro ou pelo escopo de customização deste projeto, em vez de usar a expressão tudo integrado para encobrir lacunas.
- Fronteira de planejamento: quem considera restrições de capacidade e de material, quem aprova o plano e quem trata inserções urgentes no chão de fábrica.
- Fronteira de armazenagem: quem gerencia locais e o saldo de estoque, e quem executa chamados de material, entrega e devolução.
- Fronteira de qualidade: quem mantém as especificações de inspeção, quem decide o destino e a liberação, e quem registra o processo gerador.
- Fronteira de manutenção: quem é dono dos fluxos de manutenção preventiva e reparo; Andon e OEE fornecem apenas os eventos necessários.
- Fronteira analítica: quem retém os dados brutos de processo, quem calcula os indicadores de negócio e quem é dono das versões de definição.
O desenho de interfaces precisa de contratos, compensação e reconciliação
Uma interface é mais que uma lista de campos. Ela precisa de momento de disparo, identificadores únicos de mensagem ou de chamada, regras de idempotência, tempo limite, novas tentativas, sequenciamento, permissões, códigos de erro e um ponto de compensação manual. O envio de ordens e o retorno de conclusão, em especial, devem evitar execução duplicada e estados perdidos.
A reconciliação faz parte do circuito da interface. Os sistemas devem comparar quantidades, estados e versões dos objetos críticos nos dois lados e exibir as diferenças; qual lado pode continuar durante uma queda de rede e a sequência de retransmissão após a recuperação devem ser decididas em conjunto pelo negócio e pelo risco de controle.
| Item de contrato | O que deve ser definido | Tratamento correto na falha |
|---|---|---|
| Gatilhos e idempotência | Quando enviar e como evitar duplicatas | Consultar por chave de negócio única ou repetir com segurança |
| Estado e sequência | Transições de estado permitidas e se as mensagens são ordenadas | Rejeitar transições ilegais e manter uma fila pendente |
| Tempo limite e nova tentativa | O projeto define o tempo limite de falha e o número de tentativas | Distinguir resultado desconhecido de falha confirmada, evitando repetição cega |
| Versão e vigência | Quando dados mestres e versões de processo se tornam utilizáveis | Bloquear versões ainda não vigentes ou já canceladas |
| Reconciliação e compensação | Quem detecta diferenças e quem tem autorização para tratá-las | Preservar registros de discrepância, aprovações e trilha de auditoria completa |
Valide as fronteiras com uma cadeia de negócio ponta a ponta
Não desenhe todo o diagrama de arquitetura antes de procurar um uso. Escolha uma cadeia de negócio representativa, como envio de ordem, verificação de material, execução no equipamento, julgamento de qualidade e retorno de conclusão, e marque passo a passo a titularidade dos objetos, as mudanças de estado e o tratamento de exceções para revelar as fronteiras reais.
Os testes devem cobrir, além do caminho normal, tempo limite de interface, mensagens duplicadas, cancelamento de dados mestres, retrabalho no chão de fábrica, desconexão de equipamento e registro manual posterior. As fronteiras só estão implementadas quando os caminhos anormais também têm responsáveis e métodos de recuperação.
- Levantar o cenário atual: sistemas existentes, versões, interfaces, donos dos dados e restrições de operação.
- Construir a matriz de objetos: confirmar a titularidade item por item, sem substituir nomes de departamentos pela responsabilidade do sistema.
- Definir interfaces mínimas: apoiar primeiro a cadeia de negócio escolhida e evitar sincronizar todos os dados de uma vez.
- Ensaiar caminhos anormais: validar nova tentativa, compensação, reconciliação, desconexão e autorização manual.
- Formalizar o contrato operacional: incluir monitoramento, plantão, mudanças e gestão de versões na aceitação e na operação.
Evite as falácias da plataforma única, do tempo real para tudo e da sincronização bidirecional
Plataforma tudo em um não significa que um único sistema deva exercer todas as funções, e sincronização em tempo real não significa que todo dado exija transmissão em milissegundos. Pedidos de negócio, execução de lotes e sinais rápidos de processo têm escalas de tempo e requisitos de consistência diferentes; misturá-los cria complexidade desnecessária.
A sincronização bidirecional não é o padrão ótimo. Permitir que vários lados modifiquem livremente o mesmo objeto estimula loops de atualização e responsabilidade difusa. Um padrão mais seguro é titularidade explícita, publicação unidirecional e escrita de retorno controlada, com aprovação e auditoria para cada exceção.
- Não substituir nomes de software por definições de responsabilidade.
- Não medir a completude da interface pela quantidade de campos.
- Não fazer o SCADA assumir diretamente transações corporativas não avaliadas.
- Não deixar o MES emitir ações de alto risco por cima das fronteiras de controle e de segurança estabelecidas.
- Não descrever capacidades APS, WMS, QMS ou TPM ainda não decididas como produtos existentes padrão.
Fronteiras claras tornam a integração sustentável
Fronteiras sólidas entre ERP, MES e SCADA nascem da titularidade de objetos e estados, e não dos rótulos de mercado dos softwares. Definir quem cria, quem modifica, quem executa e quem reconcilia antes de desenhar telas e interfaces reduz a construção duplicada e a sobrescrita mútua.
Na implementação, valide caminhos normais e anormais com uma cadeia de negócio ponta a ponta e identifique, item por item, quem provê cada capacidade adjacente de APS, WMS e QMS. A colaboração entre sistemas assim formada é mais fácil de aceitar, operar e evoluir do que uma vaga promessa de plataforma única.
Perguntas frequentes
Se MES e ERP guardam as ordens de produção, isso é construção duplicada?
Necessariamente não. O ERP pode manter a visão de planejamento e de negócio, enquanto o MES mantém a decomposição de execução, o avanço por posto e o status do chão de fábrica. O essencial é definir os campos, os estados e as direções de sincronização de cada um, e não permitir que os dois lados modifiquem o mesmo objeto sem regras.
O SCADA pode substituir diretamente o MES?
Em geral, não como substituição simples. O SCADA se destaca na supervisão do processo e no histórico, e o MES em ordens, passagens por posto, prevenção de erros, lotes e coordenação de negócio. Cenários pequenos podem combinar funções selecionadas, mas a titularidade das transações de execução e da consistência dos dados ainda precisa ser explícita.
O ERP também precisa receber todos os dados de equipamento em tempo real?
Normalmente não. O ERP precisa de resultados de conclusão, consumo ou status confirmados por definição de negócio. Os dados brutos de alta velocidade podem permanecer na camada de aquisição ou de histórico, com o MES ou serviços de dados fornecendo os resumos necessários.
Um WMS ou QMS existente precisa ser substituído por módulos do MES?
A substituição não deve ser o padrão. Avalie primeiro se o sistema existente atende aos requisitos de titularidade e de interface; se interfaces estáveis sustentam a colaboração, reconstruir por mera uniformidade visual é desnecessário. Qualquer substituição exige avaliação separada de migração, processo e riscos operacionais.
