Numa fábrica de malhas no Vale do Ave com três turnos e doze teares circulares, o supervisor regista paragens num caderno de capa preta. O caderno existe há oito anos. O PLC de cada tear gera eventos em tempo real — mas ninguém os lê. Segundo dados da Siemens (2024), as paragens não planeadas custam às 500 maiores empresas do mundo o equivalente a 11% da faturação anual. Em Portugal, onde a produtividade por hora trabalhada era cerca de 67% da média da UE em 2022 (Eurostat), o custo de ignorar esses eventos é proporcionalmente mais alto — porque a margem para absorver ineficiência é menor.
A integração de PLCs via OPC-UA com o KORA Productivity não é uma questão de modernização. É uma questão de soberania sobre os dados de produção. Enquanto os eventos ficarem presos no firmware do equipamento, a fábrica não tem OEE — tem uma estimativa. E uma estimativa não serve para responder a um comprador internacional que exige dados de conformidade por lote, nem para cumprir os requisitos de monitorização de redes OT que o DL 65/2025 impõe às entidades industriais abrangidas pela NIS2.
O que se segue é uma descrição técnica e operacional das opções reais de integração, dos trade-offs por perfil de fábrica e do que falha quando a implementação é apressada — incluindo os erros que os manuais de integração não documentam porque só se tornam visíveis três meses depois do go-live.
Porquê OPC-UA e não uma ligação direta ao PLC
A questão não é tecnológica — é política. Cada fabricante de PLCs (Siemens, Schneider, Mitsubishi, Omron, Allen-Bradley) tem o seu protocolo proprietário. Uma ligação direta implica um driver específico, uma versão de firmware específica e, muitas vezes, um contrato de suporte com o fabricante do equipamento. Quando a fábrica tem equipamento de três gerações diferentes — e em Portugal é a norma, não a exceção —, a proliferação de drivers torna-se ingerível. A equipa de TI passa a depender do fornecedor do equipamento para cada novo indicador que a produção quer monitorizar.
OPC-UA (IEC 62541) resolve isto com um modelo de informação unificado e orientado a objetos, com segurança nativa (autenticação por certificado X.509, encriptação TLS 1.2/1.3) e independência de plataforma. O servidor OPC-UA corre junto ao equipamento; o cliente OPC-UA — neste caso, o KORA Productivity — subscreve os nós de dados que lhe interessam. A fábrica deixa de negociar com o fornecedor do PLC cada vez que quer um novo indicador. Essa é a diferença estrutural.
A integração OPC-UA não é um projeto de TI. É uma decisão de arquitetura que define quem controla os dados da produção nos próximos dez anos — a fábrica ou o fornecedor do equipamento.
O que o OPC-UA transporta que outros protocolos não transportam
Modbus RTU/TCP transporta valores numéricos brutos. MQTT transporta mensagens leves mas sem semântica. OPC-UA transporta contexto: o nó Tear_07/Estado/Paragem não é apenas um bit — é um objeto com tipo, unidade de medida, timestamp com resolução de 100 ns, histórico e metadados de qualidade. Quando a rastreabilidade de lote é exigida por um cliente de vestuário que subcontrata produção em Portugal para marcas europeias, esse contexto é a diferença entre um relatório de conformidade e um ficheiro Excel com datas aproximadas. A distinção importa: o comprador aceita um relatório; rejeita o Excel.
OPC-UA vs. alternativas: comparação técnica
| Protocolo | Semântica de dados | Segurança nativa | Suporte multi-vendor | Adequação a MES/ERP | Complexidade de implementação |
|---|---|---|---|---|---|
| OPC-UA | Alta (modelo de objetos) | Sim (X.509 + TLS) | Alta | Alta | Média-alta |
| Modbus TCP | Nenhuma (registos brutos) | Não | Alta | Baixa (requer mapeamento manual) | Baixa |
| MQTT | Baixa (payload livre) | Opcional (TLS) | Alta | Média (depende de schema) | Baixa-média |
| PROFINET | Média | Limitada | Baixa (Siemens-centric) | Média | Alta |
| Driver proprietário | Alta (se bem mapeado) | Variável | Nenhuma | Alta (mas frágil) | Alta + lock-in |
O que mudou para isto ser relevante agora
Três forças convergiram nos últimos 36 meses. Os PLCs de nova geração — mesmo em fábricas de média dimensão — saem de fábrica com servidor OPC-UA integrado: Siemens S7-1500, Schneider Modicon M340/M580, Omron NX/NJ. Não é necessário hardware adicional. O custo de um gateway OPC-UA industrial para PLCs mais antigos desceu o suficiente para tornar a retrofitting economicamente viável para equipamento dos anos 2000. E a Diretiva NIS2, transposta para Portugal pelo DL 65/2025, exige que infraestruturas industriais críticas implementem controlos que incluem explicitamente a segregação de redes OT/IT — o OPC-UA, com o seu modelo de segurança por certificado, é a resposta técnica mais limpa a esse requisito.
Estas três forças não actuam de forma independente. Uma fábrica têxtil que precisa de segregar a rede OT para cumprir o NIS2 tem, nesse momento, o argumento técnico e regulatório para substituir o Modbus sem autenticação por OPC-UA com TLS. O projeto de conformidade financia a modernização da arquitetura de dados. Quem não aproveitar esta janela vai pagar duas vezes: primeiro pela conformidade, depois pela integração.
O impacto do NIS2 na arquitetura OT
A Diretiva NIS2 não obriga a OPC-UA. Obriga a controlos de acesso, encriptação em trânsito e monitorização de eventos em redes operacionais. Uma fábrica que ainda usa Modbus sem autenticação entre o PLC e o servidor de recolha de dados está, tecnicamente, em incumprimento dos requisitos de segurança NIS2 para entidades do setor industrial. O OPC-UA com autenticação por certificado e TLS resolve isso estruturalmente — não como remendo, mas como arquitetura. Para aprofundar os controlos técnicos exigidos, leia NIS2 em profundidade: controlos técnicos para a fábrica portuguesa.
O estado real da digitalização em Portugal
Em 2025, apenas 53,7% das empresas em Portugal utilizavam ERP e 45% faziam análise de dados (INE, 2025). A captura de dados em tempo real no chão de fábrica é ainda menos comum. O setor têxtil e de vestuário representa cerca de 20% do emprego da indústria transformadora nacional (ATP) e cerca de dois terços da sua produção destina-se à exportação — o que significa que a pressão dos compradores internacionais para dados de conformidade e rastreabilidade não é uma tendência futura. É uma exigência presente, em contratos que já estão assinados.
Arquiteturas reais: três opções técnicas com trade-offs
Não existe uma única forma de integrar PLCs via OPC-UA com um sistema de captura de produção. A escolha depende da geração do equipamento, da infraestrutura de rede disponível e da tolerância ao risco de paragem durante a implementação. As três opções seguintes cobrem a maioria dos perfis de fábrica portuguesa — e cada uma tem um ponto de falha específico que convém conhecer antes de começar.
Opção A — PLC com servidor OPC-UA nativo
Para PLCs de geração recente (pós-2015, tipicamente). O servidor OPC-UA está integrado no firmware do controlador. A configuração resume-se a ativar o servidor, definir os nós a expor e configurar os certificados de segurança. O KORA Productivity liga-se diretamente como cliente OPC-UA. A latência fica tipicamente abaixo dos 100 ms para eventos de estado, não é necessário hardware adicional no chão de fábrica e o risco de paragem durante a configuração é baixo porque pode ser feita em modo online. A limitação que os manuais raramente mencionam: o número de nós expostos pode estar limitado por licença de firmware — e descobrir esse limite depois de ter mapeado 200 variáveis é um contratempo que atrasa o projeto em semanas.
Opção B — Gateway OPC-UA (retrofit para PLCs antigos)
Para PLCs dos anos 1990–2010 com Modbus RTU, Profibus ou protocolos proprietários. Um gateway industrial — hardware dedicado ou software em PC industrial — faz a conversão de protocolo e expõe um servidor OPC-UA. Fabricantes como Kepware, Matrikon ou Softing têm gateways com suporte a centenas de drivers. O gateway permite integrar equipamento legado sem substituição, o que é determinante em fábricas de vestuário no Norte onde as máquinas de costura têm PLCs dos anos 2000 que ainda funcionam e não vão ser substituídas. O ponto de atenção: o gateway é um ponto único de falha se não tiver redundância configurada, e a manutenção adicional — firmware do gateway, licenças de driver — é um custo recorrente que o orçamento inicial tende a subestimar.
Opção C — Edge computing com OPC-UA aggregator
Para fábricas com múltiplas células de produção ou múltiplos pisos. Um servidor OPC-UA agregador recolhe dados de vários PLCs — nativos ou via gateway — e expõe um único endpoint ao KORA Productivity. Reduz o tráfego de rede e permite processamento local (filtros, agregações, deteção de anomalias) antes de enviar para o servidor central. A arquitetura é mais resiliente: o edge continua a recolher dados mesmo sem ligação ao servidor central, o que é relevante em fábricas com ligações de rede instáveis entre pisos. Adequada para fábricas com mais de 20 PLCs ou com redes segmentadas por zona, e compatível com os requisitos de segregação OT/IT do NIS2. A contrapartida é a maior complexidade de configuração e manutenção — dois sistemas a gerir em vez de um.
Matriz de decisão por perfil de fábrica
| Perfil de fábrica | Geração do equipamento | Nº de PLCs | Arquitetura recomendada | Prazo típico de implementação | Risco principal |
|---|---|---|---|---|---|
| Têxtil/malhas, 1 piso, equipamento misto | 2005–2020 | 5–15 | Gateway OPC-UA por célula | 8–14 semanas | Mapeamento de variáveis incorrecto |
| Calçado, linha de montagem, PLCs recentes | 2015–presente | 3–8 | OPC-UA nativo | 4–8 semanas | Licenças de firmware |
| Metal/plástico, múltiplas células, injecção | Misto (1995–2022) | 15–50 | Edge aggregator + gateways | 16–24 semanas | Segmentação de rede OT/IT |
| Vestuário, confecção, equipamento antigo | 1995–2010 | 2–10 | Gateway OPC-UA ou terminais industriais KORA | 6–12 semanas | PLCs sem suporte a protocolo standard |
| Distribuição industrial, linhas de picking automático | 2010–presente | 8–20 | OPC-UA nativo + edge | 10–16 semanas | Integração com WMS existente |
O que falha na prática — e os manuais não dizem
O projecto de integração OPC-UA não falha na camada de protocolo. Falha no mapeamento de variáveis — quando ninguém na fábrica sabe o que o endereço
DB47.DBX12.3significa em termos de processo.
O erro mais comum não é técnico — é organizacional. O PLC tem centenas de variáveis internas. O integrador configura o servidor OPC-UA e expõe todas elas. O sistema de captura começa a receber dados. Mas ninguém mapeou quais as variáveis que correspondem a "paragem por falta de material", "paragem por avaria", "ciclo em curso" ou "peça rejeitada". O resultado é um servidor OPC-UA a funcionar e um dashboard de OEE com valores que ninguém confia. Esse descrédito é difícil de recuperar — a equipa de produção volta ao caderno de capa preta e o projecto fica tecnicamente ativo mas operacionalmente morto.
O problema do timestamp distribuído
Numa fábrica com dez PLCs de fabricantes diferentes, cada controlador tem o seu relógio interno. Se esses relógios não estiverem sincronizados via NTP (Network Time Protocol), os eventos de produção chegam ao KORA Productivity com timestamps inconsistentes. Um tear que parou às 14:32:07 pode aparecer no sistema como tendo parado às 14:31:54 — uma diferença de 13 segundos que, para análise de SMED ou cálculo de OEE por turno, introduz erros sistemáticos que se acumulam ao longo de semanas. Configure NTP em todos os PLCs antes de ligar o servidor OPC-UA. Não é opcional e não é um passo de afinação — é um pré-requisito.
Segurança de certificados em ambiente industrial
O OPC-UA usa certificados X.509 para autenticação mútua entre cliente e servidor. Em ambiente de escritório, a gestão de certificados é rotina. Em ambiente industrial, é frequentemente ignorada — com uma sequência de eventos que se repete com regularidade preocupante. O integrador configura o servidor OPC-UA em modo "sem segurança" durante os testes, para simplificar. O projecto termina. O modo de segurança nunca é ativado. A fábrica fica com um servidor OPC-UA acessível sem autenticação na rede OT — exatamente o cenário que o NIS2 quer eliminar. Audite o modo de segurança de cada servidor OPC-UA como condição de aceitação do projecto, não como verificação posterior.
Largura de banda e polling vs. subscrição
OPC-UA suporta dois modelos de recolha de dados: polling (o cliente pergunta periodicamente) e subscrição (o servidor notifica quando o valor muda). Polling com intervalos curtos em muitos nós pode saturar a rede OT de uma fábrica têxtil que usa switches não geridos de 100 Mbps partilhados com terminais de produção. Use sempre o modelo de subscrição com deadband configurado — o servidor só notifica quando o valor muda além de um limiar definido. Para sinais analógicos como temperatura ou tensão, um deadband de 0,5% elimina 80 a 90% do tráfego desnecessário sem perda de informação relevante. É uma configuração de cinco minutos que evita um problema de rede que demora dias a diagnosticar.
Integração com o KORA Productivity: o que acontece depois do OPC-UA
O OPC-UA é a camada de transporte. O valor está no que o KORA Productivity faz com os dados depois de os receber. A integração não termina quando o cliente OPC-UA começa a receber valores — termina quando esses valores produzem indicadores operacionais confiáveis que chegam ao Qlik Sense e ao ERP MULTI sem intervenção manual.
Mapeamento de eventos para ordens de produção
Um evento OPC-UA ("Tear_07 parou") não tem, por si, contexto de negócio. O KORA Productivity associa esse evento à ordem de produção ativa no tear naquele momento, ao operador registado, ao artigo em curso e ao turno. Este mapeamento é o núcleo da integração — e é ondo processo completo está descrito em KORA Productivity no chão de fábrica: do papel ao OEE validado.
Regras de classificação de paragens
O OPC-UA entrega um bit de estado: "parado" ou "em marcha". A classificação da causa da paragem — avaria mecânica, falta de material, setup, paragem planeada — é feita por regras configuradas no KORA Productivity, com confirmação opcional pelo operador via terminal industrial. Sem esta classificação, o OEE é um número. Com ela, é um diagnóstico. A configuração dessas regras segue uma sequência que não deve ser alterada:
- Defina a lista de causas de paragem com o responsável de produção — não com o integrador de TI. As causas têm de corresponder à linguagem do chão de fábrica, não à taxonomia do manual do sistema.
- Configure regras automáticas para paragens com duração inferior a 2 minutos (micro-paragens) — são classificadas automaticamente sem intervenção do operador.
- Para paragens superiores ao limiar configurado, o terminal industrial solicita ao operador a seleção da causa. O timeout deve ser curto — 30 a 60 segundos — para não interromper o fluxo de trabalho.
- Reveja as regras ao fim de 30 dias de operação. Os primeiros dados reais revelam sempre causas não previstas na configuração inicial — e ignorar essa revisão significa que o sistema continua a classificar incorrectamente durante meses.
Integração a montante: do OEE ao ERP
Os dados de produção capturados via OPC-UA alimentam o ERP MULTI com quantidades produzidas, tempos de ciclo reais e consumos de material confirmados por pesagem ou contagem automática. Isto fecha o ciclo entre o planeamento (ordens de produção emitidas pelo ERP) e a execução (confirmada pelo KORA via OPC-UA). A integração bidirecional está descrita em detalhe em KORA Productivity: controlo do chão de fábrica em tempo real.
O que funciona na prática
Padrão 1 — Implementação faseada por célula de produção
A tentação é ligar todos os PLCs de uma vez. O risco é proporcional. O padrão que funciona começa por uma única célula de produção — as máquinas mais críticas em termos de OEE — e estabiliza a integração durante quatro a seis semanas antes de expandir. Numa fábrica de injecção plástica no corredor Aveiro–Marinha Grande, isso pode significar começar pelas quatro prensas com maior taxa de paragem e só depois avançar para o resto da linha. Quando a expansão acontece, a equipa já conhece os erros típicos de mapeamento, já tem a sincronização NTP validada e já sabe quais as causas de paragem que faltavam na lista inicial. O tempo ganho na fase de expansão compensa largamente o tempo "perdido" na fase de estabilização.
Padrão 2 — Separação física da rede OT
Em fábricas têxteis do Vale do Ave com redes planas — todos os dispositivos na mesma VLAN —, a integração OPC-UA é o momento certo para implementar a segmentação OT/IT exigida pelo NIS2. O servidor OPC-UA fica na rede OT; o cliente KORA Productivity fica na rede IT; a comunicação passa por uma DMZ industrial com firewall configurada para permitir apenas o porto OPC-UA (4840/TCP por omissão) com autenticação por certificado. Esta arquitetura não atrasa o projecto — define-o corretamente desde o início. Fazê-lo depois do go-live implica reconfigurar endereçamentos, certificados e regras de firewall com o sistema em produção. É possível, mas custa o dobro do tempo.
Padrão 3 — Validação cruzada com dados manuais durante a transição
Durante as primeiras semanas após a ativação da integração OPC-UA, mantenha o registo manual em paralelo. Não por desconfiança no sistema — mas porque a comparação entre o que o operador regista e o que o PLC reporta revela discrepâncias que são, invariavelmente, erros de mapeamento ou de configuração. Numa fábrica de calçado em Felgueiras, este período de validação cruzada pode revelar que o sensor de "peça produzida" conta ciclos de prensa — incluindo ciclos a vazio durante o setup — e que o contador de peças boas precisa de uma regra de exclusão adicional. Sem a validação cruzada, este erro só seria detetado meses depois, quando o OEE acumulado não correspondesse à produção real faturada.
O registo manual paralelo não é um sinal de desconfiança no sistema digital. É o único método que garante que o sistema digital está a medir o que a fábrica pensa que está a medir.
Como medir o sucesso pós-implementação
A integração OPC-UA não tem um indicador único de sucesso. Tem uma sequência de validações que devem ser feitas em fases distintas — e que, se saltadas, transformam um projecto tecnicamente funcional num projecto operacionalmente inútil.
- Semana 1–2: Verifique a completude dos dados — percentagem de eventos de produção capturados automaticamente vs. registados manualmente. O objetivo é acima de 95% de captura automática para os PLCs integrados.
- Semana 3–4: Valide a consistência dos timestamps — compare o log do PLC com o log do KORA Productivity para os mesmos eventos. Desvios superiores a 1 segundo indicam problema de sincronização NTP.
- Mês 2: Compare o OEE calculado pelo KORA com o OEE calculado manualmente para o mesmo período. Uma diferença superior a 3 pontos percentuais indica erro de mapeamento ou de classificação de paragens.
- Mês 3: Verifique se os dados de produção confirmados pelo KORA correspondem às quantidades faturadas no ERP MULTI. Este é o teste de integração end-to-end mais rigoroso — e o único que a direção financeira vai aceitar como prova de que o sistema funciona.
- Trimestral: Audite os certificados OPC-UA — validade, rotação, lista de clientes autorizados. Um certificado expirado num servidor OPC-UA de produção pode causar uma paragem de recolha de dados silenciosa que só é detetada quando o dashboard fica em branco.
O lead time de uma integração bem feita
Uma implementação de integração OPC-UA com o KORA Productivity, para uma fábrica com 8 a 15 PLCs de geração mista, demora tipicamente entre 10 e 16 semanas do primeiro levantamento à aceitação em produção. Projectos que prometem menos de 8 semanas para este perfil estão a saltar a fase de validação cruzada ou a deixar a configuração de segurança para depois. Ambas as omissões criam problemas que custam mais a corrigir do que o tempo que pouparam. O prazo não é uma variável de negociação — é uma consequência da complexidade real do mapeamento de variáveis e da validação de dados.
Para fábricas do setor têxtil ou do setor do calçado que estão a avaliar esta integração, o artigo KORA Productivity no chão de fábrica: do papel ao OEE validado descreve o processo completo da captura de dados à validação do indicador. E se a questão é como a mobilidade industrial se estende do chão de fábrica ao armazém, Mobilidade industrial no armazém: KORA Inventory vs. papel fecha esse ciclo.
Os dados de produção ou pertencem à fábrica ou continuam presos no firmware do equipamento. Não há meio-termo técnico — só decisões de arquitetura que foram ou não foram tomadas.
Fontes
- Siemens, The True Cost of Downtime 2024, Siemens AG, 2024.
- INE — Instituto Nacional de Estatística, Inquérito à Utilização de Tecnologias da Informação e da Comunicação nas Empresas 2025, INE, 2025.
- Eurostat, Labour productivity per hour worked, base de dados Eurostat (código: TEC00116), dados de 2022.
- ATP — Associação Têxtil e Vestuário de Portugal, Estatísticas do Setor Têxtil e Vestuário, ATP, 2025/2026.
- IEC 62541 — OPC Unified Architecture, International Electrotechnical Commission, edição vigente.
- Diretiva (UE) 2022/2555 do Parlamento Europeu e do Conselho (NIS2), Jornal Oficial da União Europeia, 2022; transposta para Portugal pelo Decreto-Lei 65/2025.
Perguntas frequentes
O que é OPC-UA e por que razão é importante para a minha fábrica?
OPC-UA é um protocolo de comunicação que permite aos sistemas de produção (como PLCs) partilharem dados de forma segura e padronizada. Diferencia-se por transportar não apenas valores numéricos, mas contexto completo: tipo de dado, unidade de medida, timestamp preciso e histórico. Isto é essencial quando precisa de rastreabilidade de lote ou conformidade regulatória.
Qual é a diferença entre OPC-UA e Modbus ou MQTT?
Modbus transporta apenas valores brutos sem segurança nativa. MQTT é leve mas sem semântica estruturada. OPC-UA oferece um modelo de objetos unificado, segurança nativa com certificados X.509 e encriptação TLS, e funciona com equipamento de múltiplos fabricantes. Para relatórios de conformidade, OPC-UA é a única opção aceitável por clientes internacionais.
Preciso de hardware adicional para implementar OPC-UA?
Depende da idade do seu equipamento. PLCs modernos (Siemens S7-1500, Schneider M580, Omron NX) já incluem servidor OPC-UA integrado. Para equipamento mais antigo, existe a opção de gateway OPC-UA industrial, cuja viabilidade económica melhorou significativamente nos últimos três anos.
Como é que o NIS2 afeta a minha decisão sobre OPC-UA?
O Decreto-Lei 65/2025 exige que infraestruturas industriais críticas implementem controlos de acesso, encriptação em trânsito e monitorização de eventos. Modbus sem autenticação está em incumprimento destes requisitos. OPC-UA com certificados e TLS resolve estes controlos estruturalmente, não como remendo temporário.
Por que razão não posso usar ligações diretas ao PLC em vez de OPC-UA?
Ligações diretas exigem um driver específico para cada fabricante de PLC. Quando a fábrica tem equipamento de três gerações diferentes — situação comum em Portugal —, a proliferação de drivers torna-se ingerível. Além disso, fica dependente do fornecedor para cada novo indicador que queira monitorizar. OPC-UA elimina essa dependência.
Qual é o impacto real de não ter acesso aos dados do PLC em tempo real?
Sem integração OPC-UA, os eventos de paragem ficam presos no firmware do equipamento. Isto significa que não tem OEE real, apenas uma estimativa. Não consegue responder a compradores internacionais que exigem dados de conformidade por lote, nem cumprir requisitos de monitorização regulatória. O custo desta ineficiência é proporcionalmente maior em Portugal.
Qual é o timing ideal para implementar OPC-UA na minha fábrica?
Três fatores convergiram recentemente: PLCs novos incluem OPC-UA integrado, o custo de gateways para equipamento antigo desceu, e o NIS2 exige controlos de segurança que OPC-UA resolve. Se precisa de conformidade NIS2, use esse projeto para financiar a modernização da arquitetura de dados. Adiar implica pagar duas vezes: primeiro pela conformidade, depois pela integração.
