Sensor instalado, dado que ninguém usa: IoT industrial que precisa virar ação

Terça-feira, 3h15, setor de moagem de uma fábrica de tintas e produtos químicos. O moinho de esferas principal para com ruído de rolamento. A equipe de turno chama a manutenção de sobreaviso, que chega às 4h. O rolamento do eixo principal está destruído, o mancal aquecido. Troca de emergência: a linha volta às 14h do mesmo dia, depois de 11 horas parada.

Na quarta, o engenheiro de processos abre o painel do sistema de monitoramento por vibração, instalado há oito meses num projeto-piloto de Indústria 4.0. A curva do mancal começou a subir na sexta-feira anterior. Passou do limite de alerta no sábado. Passou do limite de perigo no domingo. O painel estava aberto num computador da sala de engenharia, que ficou desligado no fim de semana.

O sensor fez o trabalho dele. A fábrica não.

O que isso custa de verdade

O custo da parada é conhecido: 11 horas de moinho, batelada perdida, hora extra da equipe de sobreaviso, rolamento comprado em regime de urgência. Num cenário ilustrativo, algo próximo de R$ 60 mil, numa falha que poderia ter sido uma troca programada de duas horas na segunda-feira.

O custo escondido é o do projeto de IoT. Depois da falha, a diretoria faz a pergunta inevitável: “para que serviu?”. E o projeto que deveria se expandir para os outros ativos críticos perde o crédito.

Há ainda o custo dos dados que já existem e não são usados: o CLP da linha sabe quantas peças fez e quantas vezes parou. Ninguém lê. O apontamento continua à mão, com números que o operador arredonda.

Por que acontece

O sensor foi instalado como projeto de tecnologia, não como parte do processo de manutenção. O dado chega a um painel isolado, que precisa de alguém para olhar e decidir. Esse alguém não está de plantão de madrugada nem no fim de semana.

O painel não conversa com o sistema de manutenção. Alerta não vira ordem de serviço. A leitura não fica no histórico do ativo. O PCM, que programaria a troca, não vê a curva.

E os dados da máquina ficam no CLP porque o sistema de produção nunca foi ligado a ele. Existem dois mundos: o que a máquina sabe e o que a fábrica registra. Eles não batem.

O que fazer a partir de segunda-feira

1. Para cada sensor instalado, escreva quem recebe o alerta e o que faz com ele. Se a resposta for “o painel mostra”, não há processo, há um mostrador.
2. Defina os limites de Normal, Alerta e Perigo para cada ponto monitorado, junto com a ação correspondente. Alerta programa inspeção; Perigo abre O.S. imediata.
3. Leve o alerta a quem pode agir: mensagem no celular do técnico de turno, não e-mail para o engenheiro que trabalha em horário comercial.
4. Liste o que o CLP de cada linha já sabe (contagem, parada, velocidade, alarmes) e compare com o que o apontamento manual registra. A diferença é o tamanho do seu ponto cego.
5. Comece a integrar pela parada: a máquina parou, o evento nasce com hora exata. O operador só informa o motivo. Isso já corrige o apontamento mais importante.
6. Revise mensalmente os alertas: quantos foram gerados, quantos viraram ação, quantos eram falsos. Sensor que só grita é desligado; sensor que evita parada ganha irmãos.

Como fica no ArkhiX

No Arkhi4.0, o sensor não alimenta um painel isolado: alimenta o ativo. Na aba IoT do ativo, cada máquina cadastrada mostra seus pontos monitorados, as leituras e a curva ao longo do tempo, dentro do mesmo registro onde ficam as O.S., o plano de preventiva e o histórico de falhas. A leitura do sensor alimenta a análise de condição, e quando cruza o limite, o alerta vai para quem está de turno, não para um computador desligado.

O Dashboard ao vivo mostra a planta em tempo real: máquinas rodando, paradas, em alerta. Os Eventos da máquina chegam direto do CLP: a máquina parou às 3h15, e não “por volta das 3h”. O operador completa com o Código de parada no terminal, e a hora real fica gravada. A telemetria calcula o OEE com o que a máquina fez, não com o que a folha diz.

Quando o equipamento fala por aqui, o resto da fábrica escuta: a parada de máquina abre O.S., a curva de vibração aparece para o PCM programar a troca, e o histórico do ativo guarda as leituras. O sensor deixa de ser projeto de tecnologia e vira parte do processo.

Checklist

• Cada sensor instalado tem um responsável pelo alerta e uma ação definida?
• Os limites de Normal, Alerta e Perigo estão definidos por ponto monitorado?
• O alerta chega a quem está de turno, inclusive à noite e no fim de semana?
• Alerta de condição vira O.S. sem passar por e-mail?
• Você sabe o que o CLP das suas linhas registra e não é usado?
• A hora da parada vem da máquina ou da memória do operador?
• Os alertas são revisados mensalmente: gerados, tratados, falsos?

Abra o painel do seu último projeto de sensores e veja quando foi a última vez que um alerta virou uma ordem de serviço. Se a resposta for difícil, vale ver como o Arkhi4.0 liga o sensor à ação na sua planta.