Allarmi macchina: come li “pulite” per ottenere cause reali di fermo e qualità?

[irene]

Ciao,

stiamo raccogliendo allarmi CNC (codici + testo).
Problema: troppi allarmi “rumore”, e spesso non dicono la vera causa (es. porta aperta dopo fermo, non prima).

Come fate a trasformare allarmi in dati utili per:
- downtime cause
- qualità (anomalie correlate)
- manutenzione?

[fabio]

Noi facciamo una “mappa allarmi”:
- codice allarme -> categoria (qualità, fermo, sicurezza, manutenzione)
- severità
- regole di deduplica (stesso allarme ripetuto 20 volte = 1 episodio con durata)

Altrimenti è ingestibile.

[admsistenet]

Pattern pratico:

- trasforma stream allarmi in “episodi” (start/end) con durata
- ignora quelli non correlati a stop (o mettili in categoria “info”)
- collega episodio a stato macchina (RUN/STOP/SETUP)

Così ottieni “cause stop” vere, non solo codici.

[irene]

Come gestite il caso “allarme successivo” (porta aperta dopo stop)?
Sembra la causa ma è solo conseguenza.

[fabio]

Noi scegliamo la “root cause” così:

- se STOP inizia alle 10:00
- prendiamo l’allarme più vicino PRIMA dello stop (finestra 30s)
- gli allarmi dopo li trattiamo come conseguenza

E lasciamo comunque la lista completa per audit.

[admsistenet]

Esatto: correlazione con stati.
Con:
- stato macchina (RUN/STOP/SETUP)
- eventi stop (manuale/automatico)
- episodi allarme

derivi root cause con regole e migliori nel tempo (approccio incrementale).

[irene]

E per manutenzione predittiva: usate questi dati per aprire ticket automatici?

[fabio]

Sì, ma con cautela:

- prima: dashboard e soglie (es. rotture utensile > X/giorno)
- poi: ticket semi-automatico con proposta
- infine: automatico solo per casi certi

Altrimenti apri troppi ticket “rumore”.

[admsistenet]

Chiusura:

mappa allarmi -> episodi -> correlazione con stato -> root cause.
È il modo giusto per trasformare “log rumorosi” in informazioni utilizzabili per OEE, qualità e manutenzione.