KORA Productivity: OEE por turno sem intervenção manual do chefe de linha

O OEE de turno que o chefe de linha preenche à mão às 23h40, antes de bater o cartão, é ficção. Arredonda paragens, esquece microparagens, e a "qualidade" é sempre 100% porque ninguém conta o retrabalho que já saiu da linha. Quem leu os artigos anteriores sabe porquê o OEE conta e o quê medir. Falta o nível operacional: como é que o número aparece no Digital Twin do turno sem que ninguém o escreva. Neste artigo, isso é resolvido em detalhe técnico — da aquisição de sinal ao fecho de turno automático.

Tese não-óbvia primeiro: o maior inimigo de um OEE fiável não é o PLC inacessível nem a máquina antiga. É o operador que preenche. Qualquer sistema que dependa de alguém confirmar "a linha parou às 14h12 por avaria" vai herdar o viés dessa pessoa — e o viés é sempre para cima. A arquitetura certa remove a mão humana da medição de disponibilidade e desempenho, e deixa o humano apenas a classificar a causa da paragem, nunca a sua existência.

Há uma segunda razão, mais política, para separar medição de codificação. Numa confeção perto de Famalicão com 90 costureiras e três turnos, o número de OEE acaba sempre por chegar à conversa do prémio de produtividade. No momento em que o operador percebe que o que escreve afeta o que recebe, a folha de turno deixa de ser um instrumento de medição e passa a ser um instrumento de negociação. A única defesa é retirar-lhe a caneta do fator que ele tem interesse em distorcer. Deixe-lhe a classificação da causa — essa até ajuda, porque ninguém conhece melhor a máquina do que quem a opera oito horas por dia.

1. Arquitetura recomendada

A regra que não se negoceia: a deteção de estado da máquina (a correr / parada) tem de ser automática; a codificação da causa pode ser semi-manual. Separar estas duas coisas é a decisão de arquitetura mais importante de todo o projeto. Tudo o resto — o broker, o terminal, o dashboard — é consequência desta escolha. Quem a inverte, deixando a deteção à pessoa e automatizando só o relatório, constrói um sistema caro para produzir ficção mais depressa.

Antes de desenhar camadas, vale a pena olhar para o parque real. Em Portugal, uma fração relevante das PME industriais ainda não tem qualquer captura de dados em tempo real no chão-de-fábrica. O que existe, na maioria dos casos, é um ERP financeiro e de vendas e uma folha de cálculo que alguém preenche no fim do mês. A distância entre esse ponto de partida e um OEE fiável não se vence com um grande projeto de uma só vez — vence-se por camadas, cada uma a entregar valor isolado.

As três camadas

• Aquisição — sensor digital no sinal de ciclo da máquina, ou leitura direta do PLC via OPC-UA. Onde não há PLC acessível (muita máquina de confeção e de corte no Vale do Ave tem 20 anos), um sensor indutivo no veio ou uma pinça amperimétrica no motor resolvem 80% dos casos.
• Edge — concentrador local que agrega sinais, carimba o tempo, deteta transições de estado e publica por MQTT para o broker. É aqui que vive a lógica de "parou mais de N segundos = microparagem".
• Aplicação — KORA Productivity consome os eventos, calcula OEE em tempo real, apresenta nos terminais industriais e fecha o turno. A ligação ao ERP MULTI traz a ordem de fabrico, o artigo, a quantidade-objetivo e o tempo de ciclo teórico.

Se o OEE precisa do chefe de linha para existir, não é um indicador — é uma opinião com decimais.

Porque é que a camada edge não é opcional

A tentação de poupar o concentrador local — ler o sinal e mandar tudo para a nuvem ou para o servidor central — aparece em quase todas as reuniões de arranque. Resista-lhe. A camada edge faz três coisas que a aplicação central não pode fazer com a mesma fiabilidade: carimba o tempo no instante exato da transição, aplica a lógica de microparagem sem depender da latência da rede, e continua a funcionar quando a ligação ao servidor cai.

Esse último ponto é decisivo numa fábrica portuguesa típica. A rede industrial não foi desenhada por ninguém — cresceu. Um switch aqui, um cabo ali, Wi-Fi onde não chegava cabo. Quando o Wi-Fi do armazém sobrecarrega às 15h, a ligação oscila. Se a deteção de estado vivesse no servidor central, cada oscilação produziria buracos na linha temporal que mais tarde seriam interpretados como paragens fantasma. Com o edge a bufferizar localmente, a oscilação perde-se no caminho mas os dados ficam intactos — o concentrador reenvia quando a ligação voltar, sem perder uma transição.

Timestamp na origem, não na chegada

O carimbo temporal faz-se no edge, no momento da transição, nunca quando a mensagem chega à aplicação. Numa rede industrial com jitter, a diferença entre carimbar na origem e carimbar à chegada pode ser de segundos — e segundos, multiplicados por centenas de microparagens por turno, tornam-se minutos de disponibilidade fantasma. O relógio do edge sincroniza por NTP contra um servidor interno.

Vale a pena quantificar. Uma linha de costura com troca frequente de peça acumula facilmente 200 a 400 micro-eventos por turno. Se cada um carregar um erro de carimbo de um segundo e meio por causa do jitter da rede, está a introduzir entre cinco e dez minutos de incerteza na disponibilidade de cada turno. Num cálculo em que a diferença entre 64% e 67% de OEE decide se a linha cumpre a cadência contratada com a casa-mãe, cinco minutos de ruído não são detalhe — são a margem inteira. Carimbar na origem elimina essa fonte de erro de raiz, por desenho, sem necessidade de calibração posterior.

Um broker, não uma arquitetura de ponto-a-ponto

O MQTT impõe-se por um motivo concreto: desacopla produtores de consumidores. O edge publica o estado da máquina num tópico; quem quiser consumir — o KORA Productivity, um dashboard, um registo de auditoria — subscreve esse tópico sem que o edge precise de saber que existe. Quando amanhã quiser acrescentar um sistema de manutenção preditiva que também lê os eventos de paragem, acrescenta um subscritor. Não toca no edge, não toca na máquina, não para a produção.

A alternativa — cada sistema a ligar-se diretamente a cada máquina — produz um emaranhado que ninguém consegue manter. Numa unidade com quarenta máquinas e três sistemas consumidores, são cento e vinte ligações diretas a gerir, versus quarenta publicadores e três subscritores num broker. A matemática é implacável e explica por que razão o padrão MQTT com broker central em DMZ industrial se tornou o consenso de facto na Indústria 4.0.

2. Parâmetros, métricas e thresholds

O OEE clássico é o produto de três fatores: Disponibilidade × Desempenho × Qualidade. O que distingue uma implementação séria de um dashboard bonito é a definição dos limiares. Sem limiares explícitos, o número é indefensável numa auditoria de produtividade.

O número de referência de mercado que importa aqui: as paragens não planeadas custam às 500 maiores empresas do mundo cerca de 1,4 biliões de dólares por ano, o equivalente a 11% da faturação — acima dos 8% estimados em 2019/2020 (Siemens, 2024). Quem não mede a disponibilidade com rigor não vê onde esse dinheiro desaparece.

Decompor os três fatores antes de os multiplicar

Multiplicar os três fatores sem olhar para cada um isoladamente é o erro que esvazia a maioria dos dashboards de OEE. Um OEE de 65% pode esconder realidades operacionais opostas: uma linha com 95% de disponibilidade, 72% de desempenho e 95% de qualidade tem um problema de cadência, não de avarias. Outra linha com 70% de disponibilidade, 98% de desempenho e 95% de qualidade tem um problema de paragens. A ação corretiva é completamente diferente — e o número agregado não lhe diz qual.

Um OEE agregado é uma anestesia. Quem decide age sobre os três fatores separados — nunca sobre o produto deles.

Microparagens: onde o OEE português morre

Numa linha de confeção com troca de cor e de talhe a toda a hora, o inimigo não é a avaria grande — é a soma de paragens de 40 segundos que ninguém regista. Definir o limiar de microparagem demasiado alto (digamos 2 minutos) esconde essa perda no fator desempenho; demasiado baixo (3 segundos) enche o sistema de eventos triviais. O ponto de equilíbrio situa-se entre 20 e 30 segundos para máquina de costura, mais baixo para corte automático.

A física do posto de trabalho determina o limiar. Uma costureira que acaba uma peça, a pousa, pega na seguinte e a posiciona debaixo da agulha gasta normalmente entre dez e vinte segundos — isso é ciclo de trabalho, não paragem. Se o limiar de microparagem for inferior a esse tempo de manipulação natural, o sistema vai registar cada troca de peça como micro-evento e inundar a análise de falsos positivos. Por isso a calibração tem de nascer da observação do posto, com cronómetro, não de um valor copiado de um manual genérico.

No corte automático a lógica inverte-se. Uma mesa de corte CNC tem ciclos longos e previsíveis; qualquer paragem de poucos segundos entre nestes é anómala e merece registo. Aqui o limiar desce para cinco ou dez segundos. A conclusão operacional é que o limiar de microparagem não é um parâmetro global da fábrica — é um parâmetro por recurso, e tentá-lo uniformizar para simplificar a configuração é trocar correção por conveniência.

Thresholds por setor: uma tabela não serve todos

O calçado de Felgueiras e a injeção plástica da Marinha Grande vivem em regimes de produção incompatíveis. Na linha de calçado, a troca entre modelos de uma coleção com oitocentos a mil e duzentos SKU muda o tempo de ciclo a cada ordem; o setup é frequente e o limiar de paragem registável tem de distinguir a troca legítima da avaria. Na injeção, o ciclo é estável por horas a fio, mas uma microparagem de três segundos pode significar uma cavidade a falhar — e isso contamina diretamente o fator qualidade através do scrap.

Por isso a configuração de referência da tabela acima é um ponto de partida, nunca um destino. A primeira semana de produção com o sistema instalado serve para calibrar, observando onde os eventos se acumulam e ajustando os limiares até que o número de eventos por turno seja gerível pelo operador e, ao mesmo tempo, capture a perda real. Essa semana de afinação é parte do projeto, não um extra opcional.

3. Configuração prática

O payload que o edge publica deve ser mínimo e autossuficiente. Carimbo na origem, identificação de recurso, estado e a ordem ativa. A causa fica a null até o operador a codificar no terminal.

// Evento de transição de estado publicado pelo edge via MQTT
// tópico: fabrica/linha03/maquina12/estado
{
  "ts": "2026-02-18T14:12:07.412Z",  // carimbo NA ORIGEM, UTC
  "recurso": "MAQ-12",
  "linha": "L03",
  "estado": "PARADA",                // A_CORRER | PARADA | SETUP
  "ordem_fabrico": "OF-2026-00847",
  "causa": null,                     // preenchida depois no terminal
  "duracao_prev_s": null
}

Repare na escolha de UTC no carimbo. Parece detalhe académico até à primeira mudança de hora de verão. Carimbar em hora local produz, à passagem da hora, ou uma hora duplicada ou uma hora inexistente na linha temporal — e o turno da noite dessa madrugada fica com um OEE impossível de reconciliar. Carimbe sempre em UTC no edge e converta para hora local apenas na apresentação. É gratuito fazê-lo bem à partida e caríssimo corrigir depois com dados já acumulados.

Do lado da aplicação, a definição do turno e dos limiares vive em configuração, nunca hardcoded. Um turno mal parametrizado é a origem silenciosa de 90% das reclamações de "o OEE está errado".

# Configuração de turno e limiares (ilustrativo)
turno_tarde:
  inicio: "14:00"
  fim:    "22:00"
  pausas:                 # tempo planeado — NÃO conta como paragem
{ inicio: "17:00", fim: "17:20" }
  microparagem_s: 25      # abaixo disto = perda de desempenho
  paragem_registavel_s: 120
  pede_causa: true        # dispara codificação no terminal
  fecho_automatico: true  # fecha turno sem intervenção do chefe de linha

A codificação da causa no terminal segue lógica Poka-Yoke: lista curta de causas por recurso, botões grandes, sem teclado. O operador não escolhe se houve paragem — isso o sistema já sabe — só porquê. Reduz o atrito e, mais importante, elimina a tentação de não declarar.

O terminal industrial e o chão-de-fábrica real

O terminal onde o operador classifica a causa tem de sobreviver ao ambiente. Numa tinturaria do Vale do Ave há humidade, vapor e mãos com produto químico; num pavilhão de corte há cotão suspenso que entope qualquer ventoinha. O ecrã tem de ser tátil capacitivo que funcione com luva, montado à altura certa, com botões grandes o suficiente para serem acertados sem parar o que se está a fazer. Um terminal lento, pequeno ou mal colocado é a razão número um para que a codificação de causa acabe toda em "Outros".

A regra prática: se classificar uma paragem demora mais de cinco segundos, o operador vai escolher o botão mais à mão em vez do botão certo. O desenho da interface não é cosmético — é o que determina a qualidade da informação de perdas que vai alimentar todas as decisões seguintes. Botões grandes, poucas opções, resposta instantânea.

Causas de paragem: curtas, reais, revistas

A lista de causas por recurso deve nascer de uma conversa com quem opera a máquina, não de um catálogo genérico. Seis a oito causas que descrevam o que realmente acontece naquele posto: "falta de linha", "quebra de agulha", "troca de bobina", "avaria do motor", "falta de peças a montante", "mudança de modelo". Quando as causas correspondem à linguagem do chão-de-fábrica, o operador reconhece-se nelas e classifica com honestidade.

A ficha técnica do artigo é a única fonte legítima do tempo de ciclo teórico. Tudo o resto é o encarregado a defender o seu turno.

4. Integrações e dependências

O OEE só vale alguma coisa quando o tempo de ciclo teórico e a quantidade-objetivo vêm do ERP, e as peças boas são reconciliadas contra o armazém. Sem isso, cai-se no erro descrito em MES sem integração ERP: ilhas de dados que o COO paga duas vezes.

A reconciliação com rastreabilidade lote-a-lote fecha o ciclo: as peças que a linha declarou boas têm de bater com o que entra em armazém de produto acabado. Quando não bate, há retrabalho não declarado — e é exatamente aí que o fator Qualidade do OEE deixa de ser 100%.

O tempo de ciclo teórico não é um número, é um processo

Puxar o ciclo teórico do ERP pressupõe que a ficha técnica do artigo está correta e atualizada. Em muitas fábricas não está — foi preenchida há anos, nunca mais foi tocada, e reflete uma máquina ou um método que já não existe. Quando a implementação de OEE expõe estas fichas desatualizadas, cria-se uma tensão produtiva: o desempenho aparece acima de 100% de forma sistemática, sinal inequívoco de que o ciclo teórico é mais lento do que a realidade.

Essa descoberta é um dos benefícios colaterais mais valiosos do projeto. Forçar a revisão das fichas técnicas do artigo melhora o custeio, melhora o planeamento e melhora a cotação a clientes. A integração entre KORA Productivity e ERP MULTI não é apenas um canal de dados — é o mecanismo que torna visível a divergência entre o que a fábrica acha que faz e o que faz de facto.

Multi-planta: quando a OF ativa tem de viajar em tempo real

Num grupo com várias unidades — a casa-mãe em Guimarães, a subcontratação em Barcelos, o acabamento em Vizela — a ordem de fabrico ativa muda de posto várias vezes ao dia. Se o terminal de uma máquina não sabe em tempo real qual a OF que está a correr, atribui a produção à ordem errada e o OEE por artigo torna-se ficção. O Multi Connect garante que a OF ativa é empurrada para cada recurso no instante em que é lançada, mantendo a coerência entre o planeamento central e a leitura do chão-de-fábrica distribuído.

Do evento ao BI: fechar o ciclo da decisão

O KORA Productivity calcula e mostra o OEE em tempo real no terminal, mas a decisão de gestão vive no histórico. É em Qlik Sense que o diretor industrial compara o OEE do turno da manhã com o da noite, do artigo A com o artigo B, do recurso 12 com o recurso 15. Sem esse histórico analisável, o OEE em tempo real serve o operador mas não serve a estratégia. A ponte entre os dois níveis — operacional e decisório — é o que separa um projeto de captura de dados de um projeto de melhoria de produtividade.

Segurança e segregação de rede

A rede OT (chão-de-fábrica) não fala diretamente com a rede IT. O broker MQTT fica numa DMZ industrial, com TLS, e o acesso remoto para manutenção passa por VPN. Isto não é zelo excessivo: a Diretiva NIS2 (Diretiva UE 2022/2555), transposta para o direito nacional, alargou as obrigações de cibersegurança a muitas empresas industriais de média dimensão que antes nem se consideravam alvo. ISO 27001 como baseline de gestão de segurança da informação deixou de ser luxo de multinacional.

O ponto que muitos diretores industriais subestimam: ligar máquinas à rede para capturar OEE aumenta a superfície de ataque. Uma linha de produção parada por ransomware custa muito mais do que a perda de disponibilidade que o OEE mede. A segregação OT/IT, o TLS no broker e o acesso remoto controlado não são burocracia de auditoria — são a condição para que o projeto de digitalização não se transforme na porta de entrada de um incidente. A ENISA tem vindo a documentar o crescimento consistente de ataques dirigidos a ambientes industriais, e a transposição nacional da NIS2 coloca a responsabilidade por esta segregação diretamente sobre a gestão.

5. Armadilhas operacionais

O que separa um projeto que entrega de um que apodrece em piloto permanente são estes detalhes. Todos vistos em produção, todos anonimizados.

• Pausa planeada contada como paragem. O turno tem pausa de 20 minutos; se não a declarar como tempo planeado, o OEE desce artificialmente e a linha perde a fé no número à primeira semana. Parametrize as pausas no turno, como no snippet acima.
• Tempo de ciclo teórico "otimista" vindo da linha. Quando o ciclo teórico é o que o encarregado acha, o fator desempenho fica perto de 100% e esconde a perda real. Puxe-o sempre da ficha técnica do artigo no ERP.
• Relógios dessincronizados entre edges. Dois concentradores com 4 segundos de desvio produzem sobreposições e buracos na linha temporal. NTP interno obrigatório, auditado semanalmente.
• Sinal de ciclo que conta duas vezes. Um sensor indutivo mal posicionado dispara no avanço e no recuo do veio — contagem dupla, OEE acima de 100%. Debounce no edge e validação contra a reconciliação de armazém.
• Codificação de causa que o operador despacha num só botão. Se "Outros" é a causa mais usada, a análise de perdas é inútil. Limite a lista a 6–8 causas reais por recurso e reveja mensalmente quais o operador evita.
• Fecho de turno dependente do chefe de linha. O fecho_automatico existe por uma razão: às 23h40 o número que se escreve à mão é o número que convém. Automatize o fecho e force a codificação das paragens durante o turno, não no fim.
• Troca de artigo sem refletir no ciclo teórico. Numa linha multi-referência de calçado com 800+ SKU, mudar de modelo muda o ciclo. Se a ordem de fabrico ativa não acompanhar, o desempenho fica absurdo. A integração Multi Connect tem de empurrar a OF ativa em tempo real.
• Setup não distinguido de paragem. Uma troca rápida (SMED) é trabalho de valor, não avaria. Trate o estado SETUP à parte, senão penaliza-se quem faz bem a mudança de série.

Se a causa de paragem mais frequente for "Outros", não tem um problema de máquinas — tem um problema de confiança no sistema.

A armadilha do piloto eterno

A mais cara de todas as armadilhas não aparece na lista acima porque não é técnica — é de gestão de projeto. O piloto que corre bem em duas linhas e nunca escala para as restantes vinte é o destino de uma percentagem significativa dos projetos de OEE. As causas são conhecidas: ninguém atribuiu responsabilidade clara pela expansão, o retorno das duas linhas-piloto não foi medido de forma a justificar o investimento seguinte, ou o entusiasmo inicial esbarrou na resistência das linhas que não participaram no piloto.

A defesa é definir, à partida, o critério de sucesso do piloto em termos mensuráveis e a data de decisão de expansão. "Se em oito semanas o OEE medido estiver dentro de três pontos da reconciliação com o armazém, expandimos para o pavilhão inteiro." Sem esse critério e essa data, o piloto torna-se um estado permanente confortável — mede alguma coisa, ninguém se compromete com mais, e o investimento em sensores das outras linhas fica congelado para sempre.

A resistência do chefe de armazém e do encarregado

Qualquer rollout que mexa com o ritmo do chão-de-fábrica encontra resistência previsível. O chefe de armazém no corredor Lousada/Paços não larga o rádio por mais de duas horas para uma formação, e tem razão — a operação não pára porque há um projeto novo. O encarregado que preenchia o OEE à mão perde, com a automação, uma margem de manobra que lhe era útil. Ignorar esta política interna é a forma mais segura de garantir que o sistema é tecnicamente perfeito e operacionalmente sabotado.

A abordagem que funciona reconhece a competência de quem já lá está. O encarregado com quinze anos de conhecimento daquela linha é o melhor aliado para calibrar limiares e desenhar a lista de causas — se for envolvido como especialista e não imposto como alvo de controlo. O número de OEE não é uma arma contra ele; é um instrumento que lhe tira de cima a tarefa chata de preencher folhas e lhe dá argumentos para pedir a manutenção ou o abastecimento que ele sempre soube que faziam falta.

6. Decisão técnica final

Sem hedging. A arquitetura certa depende da dimensão e do parque de máquinas, não do orçamento de software.

Regra de ouro transversal: comece pela deteção automática de estado e só depois sofistique a codificação de causas. Uma implementação que mede disponibilidade real em seis linhas vale mais do que um Digital Twin completo que nunca sai do piloto. E não espere pelo PLC perfeito — o sensor indutivo de 40 euros resolve o essencial enquanto o investimento em APS e planeamento fino amadurece.

Faseamento por retorno, não por ambição

A sequência de implementação que entrega resultado cedo tem uma lógica de retorno, não de completude. Primeira fase: deteção automática de estado e cálculo de disponibilidade e desempenho nas linhas mais críticas — as que fazem gargalo ou as que servem o cliente mais exigente. Esta fase entrega, sozinha, visibilidade sobre onde a capacidade se perde, e paga-se depressa.

Segunda fase: codificação de causas com Poka-Yoke e integração do ciclo teórico do ERP, para transformar a visibilidade em análise de perdas acionável. Terceira fase: reconciliação de qualidade com o armazém e histórico em BI, fechando o triângulo do OEE. Só depois, e apenas se a complexidade o justificar, faz sentido avançar para orquestração de planeamento fino com APS. Inverter esta ordem — começar pela ambição do Digital Twin completo — é a receita do piloto eterno descrito acima.

Onde o financiamento ajuda e onde atrapalha

Os instrumentos PT2030, PRR, COMPETE 2030 e Norte 2030 financiam investimento em digitalização industrial, e um projeto de captura de OEE encaixa nas tipologias de Indústria 4.0 que estes programas apoiam. O risco não está na elegibilidade — está no calendário. Um projeto desenhado para o ritmo do incentivo tende a comprar sensores a mais, a abranger linhas de uma vez para maximizar a despesa elegível, e a esbarrar depois na capacidade real de absorção do chão-de-fábrica. O relatório técnico fica bonito, a execução fica refém do prazo de reporte.

A disciplina que recomendamos: desenhe o faseamento pelo retorno operacional e encaixe o financiamento nesse faseamento, nunca o contrário. Um incentivo bem aproveitado acelera um plano que já fazia sentido; um incentivo mal aproveitado financia um plano que a fábrica não consegue digerir.

Contexto nacional que torna isto urgente: em 2025, apenas 53,7% das empresas em Portugal usavam ERP e 45% faziam análise de dados (INE, 2025). A captura de dados em tempo real no chão-de-fábrica ainda é exceção — e com a produtividade por hora trabalhada em cerca de 67% da média da UE (Eurostat, 2022), cada ponto de OEE recuperado conta. Num setor como o têxtil e vestuário, que vale cerca de 11% do VAB e 20% do emprego da indústria transformadora (ATP), com dois terços da produção destinada à exportação, a diferença entre medir e adivinhar o OEE é a diferença entre cumprir ou falhar a entrega à casa-mãe.

O que a casa-mãe passou a exigir

A pressão que acelera estes projetos raramente nasce dentro da fábrica — vem de fora, do cliente que subcontrata. As casas-mãe internacionais que colocam produção no Norte do país deixaram de pedir só preço e prazo; pedem rastreabilidade, dados de produção e, cada vez mais, prova de conformidade com os critérios da Estratégia da UE para os Têxteis Sustentáveis e Circulares. A fábrica que mede o seu OEE com rigor tem, de borla, grande parte da infraestrutura de dados que estas exigências requerem — rastreabilidade de lote, tempos de produção, histórico por artigo. A que adivinha o OEE vai ter de construir tudo isso à pressa quando o comprador perguntar, normalmente com o pedido já na mesa e o prazo a correr.

7. Como a INFOS implementa

Implementamos KORA Productivity a partir do que a fábrica tem, não do que gostaríamos que tivesse: sinal de ciclo por sensor onde o PLC é mudo, OPC-UA onde o parque é moderno, edge com carimbo na origem e publicação MQTT. Ligamos ao ERP MULTI para que o ciclo teórico e a ordem de fabrico venham da fonte certa, reconciliamos contagens com o armazém e levamos o histórico ao Qlik Sense para análise por turno, artigo e recurso. O chefe de linha deixa de preencher OEE — passa a lê-lo. E a decisão de custeio industrial ganha, finalmente, um denominador em que se pode confiar.

O método de trabalho reflete trinta e cinco anos a implementar software em indústria portuguesa: começamos com uma avaliação técnica do parque de máquinas e da rede, desenhamos uma prova de conceito numa ou duas linhas representativas, e só depois de a reconciliação bater com o armazém é que propomos a expansão. Envolvemos o encarregado e o chefe de linha desde o primeiro dia — não como alvos do sistema, mas como donos do conhecimento que o calibra. É assim que um projeto de OEE deixa de ser um dashboard que ninguém consulta e passa a ser o número em que a fábrica baseia decisões de turno, de manutenção e de custeio.

Fontes

• Siemens, True Cost of Downtime 2024 — estimativa de custo das paragens não planeadas nas 500 maiores empresas globais.
• INE — Instituto Nacional de Estatística, Sociedade da Informação e do Conhecimento — Inquérito à Utilização de TIC nas Empresas, 2025 (utilização de ERP e análise de dados).
• Eurostat — Produtividade do trabalho por hora trabalhada, 2022.
• ATP — Associação Têxtil e Vestuário de Portugal — peso do setor no VAB, no emprego industrial e na exportação.
• Diretiva (UE) 2022/2555 (NIS2) — requisitos de cibersegurança para entidades essenciais e importantes.
• ENISA — Agência da União Europeia para a Cibersegurança — tendências de ameaças a ambientes industriais.
• ISO/IEC 27001 — sistema de gestão de segurança da informação.

Perguntas frequentes

O que é o OEE de turno que o chefe de linha preenche manualmente?

É o registo manual de disponibilidade, desempenho e qualidade que o chefe de linha completa antes de sair, geralmente às 23h40. O artigo considera-o "ficção" porque arredonda paragens, esquece microparagens e ignora retrabalho já saído da linha, introduzindo sempre viés para cima nos números.

Qual é o maior problema de um OEE que depende do operador?

O viés humano. Quando o operador percebe que os números que escreve afetam o seu prémio de produtividade, a folha de turno deixa de ser um instrumento de medição e passa a ser um instrumento de negociação. O operador tem interesse em distorcer os dados que o prejudicam.

Como se separa a medição da codificação no sistema KORA?

A deteção automática de estado da máquina (a correr ou parada) é feita por sensores e PLC, nunca manualmente. A codificação da causa da paragem pode ser semi-manual, deixando o operador apenas a classificar o motivo, não a sua existência. Assim remove-se o viés da medição.

Quais são as três camadas da arquitetura recomendada?

Aquisição: sensor ou leitura do PLC que capta o sinal de ciclo. Edge: concentrador local que agrega sinais, carimba tempo e deteta transições de estado. Aplicação: KORA Productivity que consome eventos, calcula OEE em tempo real e fecha o turno automaticamente.

Por que razão a camada edge não é opcional?

O edge carimba o tempo no instante exato da transição, aplica lógica de microparagem sem depender da latência da rede, e continua a funcionar quando a ligação ao servidor cai. Numa fábrica com rede industrial instável, o edge bufferiza dados localmente e reenvia quando a conexão volta, evitando paragens fantasma.

Qual é a diferença entre carimbar o tempo na origem ou à chegada?

Carimbar na origem (no edge, no momento da transição) elimina erros causados pelo jitter da rede. Numa linha com 200 a 400 micro-eventos por turno, erros de carimbo à chegada podem introduzir cinco a dez minutos de incerteza na disponibilidade, afetando decisões críticas sobre cumprimento de cadência.

Porque é que o MQTT é melhor que uma arquitetura ponto-a-ponto?

O MQTT desacopla produtores de consumidores. O edge publica eventos num tópico; qualquer sistema (KORA, dashboard, manutenção preditiva) subscreve sem o edge precisar saber que existe. Permite adicionar novos sistemas sem tocar na máquina ou parar a produção.