Gli Allarmi nei sistemi di controllo

Con l’avvento dei sistemi DCS prima e degli HMI poi, il numero e le tipologie degli allarmi è aumentato esponenzialmente rispetto ai vecchi sistemi quali il Mark II, dove l’”Annunciator“ aveva una quarantina di lampadine di allarme. Nonostante il numero limitato di allarmi si riusciva a “proteggere” un Turbogruppo molto simile a quelli attuali.

Le tecnologie digitali e l’informatica hanno incentivato il proliferare del numero degli allarmi: questo fatto, anche se può sembrare un grande progresso, ha indubbiamente complicato la loro interpretazione da parte degli operatori.

Lo scopo fondamentale di un allarme è di avvisare il responsabile di un sistema, sia esso un turbogruppo o un intero impianto industriale, che esiste una condizione anomala o che si è verificato un certo evento. Generalmente gli allarmi nei sistemi di controllo sono messaggi attivati per segnalare un’anomalia: per esempio, un allarme potrebbe indicare che il livello dell’olio di lubrificazione nel serbatoio ha raggiunto un basso livello

(e quindi richiede un intervento ma non immediato) o il livello molto basso (che richiede un intervento immediato), come invece un allarme può segnalare molto semplicemente l’avvenuta partenza di un ventilatore del sistema di raffreddamento dell’olio di lubrificazione. È evidente che i tre allarmi presi nel nostro esempio rivestono una differente importanza per l’operatore. Un allarme a bassa priorità potrebbe non richiedere il riconoscimento. In alcuni casi invece l’allarme potrebbe “rientrare” nello stato normale senza che sia stato fatto alcun intervento esterno.

Per esempio, quando si raggiunge una temperatura elevata in un cabinato si avrà un allarme e, automaticamente, verrà attivato un ventilatore che, raffreddando l’area monitorizzata, farà rientrare l’allarme di alta temperatura.

Un allarme ad alta o media priorità richiede solitamente il suo riconoscimento (Aknowledge): questo avviene generalmente agendo da HMI. Una volta riconosciuto l’allarme sulla pagina video dedicata, l’indicazione da rossa lampeggiante passerà a rossa fissa. 

Anche se la circostanza che ha generato l’allarme scompare, l’allarme rimane attivo finché non viene riconosciuto (Aknowledge) e ripristinato (Reset).    

L’operatore di un sistema di controllo, sia esso remoto che locale, deve essere in condizione di comprendere il significato e risalire a dove viene generato un qualsiasi allarme ed intraprendere la relativa azione correttiva.

Ogni allarme dovrebbe richiedere un’azione ben definita che possa essere eseguita dall’operatore in un tempo adeguato: il sistema di allarme dovrebbe perciò essere progettato tenendo conto dei limiti umani.

Da studi effettuati, si è trovato che un singolo operatore di centrale, nel normale svolgimento delle sue attività, può gestire in un’ora fino ad un massimo di dieci allarmi.

In caso di una grave emergenza può gestire al massimo dieci allarmi entro dieci minuti: ovviamente dipende anche dalla tipologia di azioni che si rendono necessarie.

Tipologie degli Allarmi

Cerchiamo in primo luogo di dividere gli Allarmi in una serie di classi, in base alla loro “provenienza”. Se analizziamo la struttura HW/SW di un sistema di controllo, vediamo che dal campo fino al display del HMI si “attraversano” tutta una serie di sottosistemi nei quali il segnale viene elaborato, trasmesso e da esso possono essere generati altri allarmi di controllo e di processo.

Le tipologie di allarmi sono comunemente le seguenti:

Dal turbogruppo / impianto

• Sequenza degli eventi (SOE)
• Diretti 
• Votati (ridondanza a 2 e 3 sensori)
• Calcolati dalla strategia di controllo

Diagnostici sensori di campo

• Incongruenza segnali (ridondanza a 2 e 3 sensori)
• Corto circuito
• Circuito aperto
• Fuori campo

Diagnostica sistema di controllo

• Guasto schede I/O
• Guasto CPU
• Guasto Memorie
• Guasto comunicazioni seriali
• Guasto alimentazione
• Errori software

I segnali “diretti” sono quelli relativi ad un singolo sensore in campo.

I segnali “votati” sono quelli ricavati dalla validazione di due o più sensori ridondati connessi allo stesso punto di misura.  

Nel caso di due contatti (doppia ridondanza), se non ci sono guasti, entrambi leggeranno lo stesso stato logico. Nel caso di guasto di uno dei due sensori,

non potendo decidere quale è quello che dice il “vero”, viene presa in considerazione l’indicazione più cautelativa per il macchinario in quella specifica condizione di lavoro.

Se invece i contatti sono tre (tripla ridondanza), la votazione avverrà per maggioranza, ovvero si tollererà un guasto di sensore. Se due contatti sono chiusi ed uno aperto, sarà votato lo stato “chiuso”.

Molto spesso i segnali ridondati hanno una funzione primaria di blocco turbina, per cui rivestono una particolare importanza per l’integrità del turbogruppo.

In tutti e due i casi ora esaminati (semplice e tripla ridondanza), verrà al contempo attivato un allarme di tipo diagnostico che indicherà la discordanza tra i segnali provenienti dal campo, in modo che il sensore guasto possa essere individuato e sostituito alla prima fermata. Nel caso di ridondanza semplice l’individuazione di quale sensore è quello guasto sarà più difficile: sarà necessaria un’indagine più lunga.

Altre tipologie di allarmi diagnostici sui segnali d’ingresso sono quelli relativi al monitoraggio delle linee di collegamento dei sensori in campo alle schede di ingresso uscita: in particolare per alcuni sensori vengono rilevate condizioni di corto circuito o di circuito interrotto.

I segnali di allarme “calcolati”, ovvero quelli derivati da sensori analogici (su cui vengono fatte delle soglie e da essi prodotti uno o più segnali/allarmi logici), oppure derivanti da parti della strategia di controllo.

Per quanto riguarda gli allarmi di diagnostica del sistema di controllo, questi sono generalmente visualizzati a HMI con un allarme riassuntivo. Per gli allarmi dettagliati è normalmente utilizzata una console separata ad uso del manutentore del sistema.

Allarmi Mark Vie

Esaminiamo ora le tipologie degli Allarmi negli Speedtronic Mark VIe e come sono gestite.

In generale nelle sale di controllo moderne, abbiamo almeno 2 postazioni dedicate e distinte per allarmi di processo e allarmi diagnostici. 

Gli allarmi di processo e la sequenza di eventi (SOE), nel caso di Speedtronic, sono gestiti dall’interfaccia HMI (Cimplicity) mentre gli allarmi diagnostici dei moduli di controllo (“core”) e delle schede di ingresso/uscita sono gestiti dalla stazione di lavoro ingegneristica dove gira il programma Toolbox.

Allarmi di processo (Turbogas & Impianto)

Gli allarmi di processo possono essere generati in due modi. 

Il primo è tramite il software applicativo che gira nei processori. I segnali usati per generare questi allarmi sono legati ad un gruppo di allarmi che è continuamente monitorato per un cambiamento di stato da parte del controllore. Gli allarmi di processo sono rilevati dalle schede d’ingresso: l’acquisizione avviene con la stessa frequenza della scansione e gli allarmi risultanti vengono trasmessi al processore dove vengono identificati con una stringa contenete il tempo a cui sono stati rilevati (“time stamped”) assieme ad un codice numerico di identificazione (ID). Sono quindi trasmesse dal controllo al HMI: qui gli allarmi sono ordinati in sequenza temporale, basandosi sul time-stamped ad essi associato e preparati per la loro visualizzazione con CIMPLICITY.

I comandi dal HMI, quale il riconoscimento, ripristino, il blocco e lo sblocco dell’allarme, vengono ritrasmessi al controllore dove viene modificata la condizione logica di quell’allarme.

Allarmi diagnostici  

Gli allarmi diagnostici identificano il modulo/dispositivo guasto in modo che il manutentore sia messo in condizione di ripararlo rapidamente.

L’operatore sul HMI tramite Cimplicity avrà solo un allarme diagnostico riassuntivo: per ottenere i particolari del guasto, dovrà passare alla postazione HMI di diagnostica ed interrogare il Toolbox.

Generalmente gli allarmi di processo basta che si presentino una sola volta per essere attivati, mentre gli allarmi diagnostici generici devono presentarsi due o più volte. Questo è necessario per eliminare falsi allarmi diagnostici dovuti a brevi transitori.  

Oltre alla diagnostica sugli input, ogni scheda ha una sua diagnostica di sistema. Se uno qualunque dei limiti hardware della scheda viene superato, si genera un allarme diagnostico composito, dove oltre al tipo di guasto viene indicato il nome della scheda di I/O e, nei sistemi TMR, anche il processore a cui è associata.

Le schede di I/O, essendo a microprocessore, hanno un “temporizzatore di stallo” che, superato tale limite, genera un segnale di guasto. Questo segnale attiva generalmente un LED rosso sul pannello anteriore della scheda. I temporizzatori di questo “watchdog” sulle schede sono generalmente regolati su un centinaio di millisecondi.

Se una scheda di I/O va in stallo, le uscite vengono portate ad uno stato di sicurezza (che è zero corrispondente alla lettura di un contatto aperto) ed anche i dati di input sono settati nello stesso stato default di sicurezza.  Sul HMI verrà attivato un allarme indicando il modulo di I/O guasto. Se il sistema è di tipo ridondato, l’unità può essere sostituita mentre il turbogas è ancora in marcia ed esercibile. Nel caso invece di guasto di un modulo di I/O è un Simplex, si otterrà la fermata di emergenza.

Coerenza temporale degli allarmi

Come trattato nei precedenti articoli, nel Mark V la strategia di controllo ha blocchi funzionali (segmenti) che vengono eseguiti con differenti tempi di ciclo (Scan Rate) e vengono distribuiti temporalmente con un certo slittamento temporale (Skew) in modo da uniformare il consumo del tempo disponibile del microprocessore numerico.

La frequenza di scansione dei vari blocchi può essere 2, 4, 8, 16  Hz  fino a raggiungere i 32Hz nei Simplex.

Sequenze di monitoraggio, come quelle delle termocoppie, hanno velocità basse mentre il loop di controllo di velocità lo scan rate più elevato.

Nel MK VIe la filosofia è stata accantonata per il miglioramento delle prestazioni dei nuovi microprocessori: tutto viaggia con lo stesso tempo di ciclo di 10 ms.

Si evidenzia che nel MK V un allarme generato da una sequenza appartenente ad un segmento con scan rate 4 Hz può essere riconosciuto in ritardo e quindi risultare successivo ad un allarme rilevato nello stesso frame temporale, ma da una sequenza appartenente ad un segmento con scan rate 32 hz.

È possibile quindi che venga riportata un’errata sequenza di allarmi inducendo l’operatore ad un’errata interpretazione del fenomeno. Il first-out (ovvero il primo allarme non riconosciuto – Aknowledged- della sequenza di allarmi) potrebbe in realtà non essere quello indicato dal sistema di visualizzazione.

Nel MK VI, essendo tutte le sequenze con lo stesso scan rate, non si dovrebbe verificare un fenomeno simile.

Inoltre, i sistemi di backup (overspeed, flame detection, vibration) hanno un loro firmware con scan-rate molto più veloce (128 hz) e quindi le loro azioni protettive possono anticipare di qualche ciclo (leggi ms) le indicazioni riportate a video.

Quando i sistemi di controllo turbina, siano essi Speedtronic o di altro tipo, sono connessi ad altri sistemi (Ex2000, 90-70 Fanuc, antincendio, analizzatore fumi, etc.), la coerenza temporale tra tutti i sistemi non è del tutto assicurata, sia per problemi di gestione dei tempi di rilevamento degli allarmi che differiscono da sistema a sistema, sia perché i segnali tra i quadri sono scambiati con linee di comunicazione seriale, sia per un problema più generale di time synchronization a livello di rete. In generale la risoluzione temporale possibile con una rete Ethernet è di 1/25 di secondo per allarmi ed eventi. Si scende ad 1 millisecondo per la sequenza eventi (SOE) per contatti direttamente letti dalle schede I/O 

I problemi si complicano quando i dati vengono collezionati anche da sistemi di acquisizione/elaborazione del Cliente (DCS, SOE, oscilloperturbografi) che potrebbero avere time stamping con riferimenti temporali assai diversi.

La soluzione ottimale sarebbe di avere un unico sistema di controllo (ad esempio tutti moduli Speedtronic) gestito in modo coordinato da alcuni HMI dedicati e sincronizzati tramite la rete con un sistema di riferimento temporale (Universal Time – UT) via GPS.

Questa sincronizzazione è molto importante specialmente quando si ha a che fare con più stazioni di turbogeneratori dove una perturbazione del carico può influenzare tutta la stabilità della rete di trasmissione elettrica. Il centro di dispacciamento, che coordina tutte le stazioni di generazione dislocate nel territorio nazionale, deve avere il quadro cronologico completo degli eventi di ogni singola centrale di generazione elettrica.

Come si è accennato, requisito fondamentale per ottenere una sequenza allarmi coerente è la sincronizzazione temporale di tutti i sistemi di controllo (turbogas, impianto e HMI) usando dei ricevitori Global Positioning Satellite (GPS). Viene con essi acquisito il riferimento di tempo (Coordinated Universal Time – UTC) con estrema accuratezza e quindi reso disponibile per tutti i dispositivi collegati in rete tramite un protocollo di sincronizzazione temporale dedicato.

Possibili miglioramenti al sistema di visualizzazione allarmi

Per rendere più facile all’operatore e al manutentore in sala controllo la comprensione dei vari segnali di allarme sarebbe possibile una serie di miglioramenti, utilizzando le risorse attualmente disponibili nei sistemi di elaborazione dati.

Oggi nelle sale controllo, gli allarmi non sono documentati in modo conveniente e, anche dove la documentazione degli allarmi esiste, spesso questa non è aggiornata perché è difficile tenere traccia in modo adeguato di tutti i cambiamenti introdotti nel tempo. Frequentemente degli allarmi vengono disabilitati, delle priorità vengono cambiate e i Clienti finali possono aggiungerne altri, editando le sequenze.

Come abbiamo visto in un precedente articolo, la massima capacità di un operatore in caso di situazioni di emergenza è quella di poter gestire una decina di allarmi alla volta. 

Il problema è quello di riuscire a individuare tra tutti gli allarmi che talvolta compaiono a video, quelli più importanti o, in caso di emergenza, l’evento scatenante. 

Per questo si potrebbe pensare di introdurre un software di pre-analisi degli allarmi, utilizzando tecniche ad albero o sistemi esperti.

La prima cosa da fare sarebbe “equalizzare” temporalmente gli allarmi: questo è un argomento poco trattato ma di una certa importanza. Infatti, gli allarmi che vengono presentati a HMI sono frutto molte volte di una preelaborazione che consiste nell’introduzione di filtri temporizzati al fine di evitare falsi allarmi.  In realtà questi tempi di ritardo hanno un’azione deleteria sull’individuazione di “chi ha provocato cosa”.  Prendiamo per esempio un segnale che genera un allarme di basso pressione collettore olio e supponiamo sia “ritardato” di dieci secondi: questo abbassamento di pressione determinerà anche l’abbassamento della pressione dell’olio, rilevato con un allarme da un secondo sensore di pressione, ritardato però di solo cinque secondi.  Il secondo l’allarme maschererebbe quello relativo all’evento in realtà avvenuto per primo.

Un altro tempo di latenza da considerare è quello dovuto allo scambio di dati tra sistemi diversi, con diversi tempi di scansione e di esecuzione. Scambio che, se non supportato da un marcatore temporale (time Tag) associato all’allarme trasmesso, porterebbe ad ulteriori indeterminatezze nell’interpretazione della sequenza di presentazione degli allarmi.

Dopo aver “equalizzato” temporalmente tutti gli allarmi, tenendo conto anche di quelli generati da sequenze più o meno lente, si potrebbe passare alla seconda parte dell’elaborazione. Per ogni allarme si dovrebbe fare una specie di albero del guasto, evidenziando però le cause e gli effetti di ogni allarme.

Ad esempio, se abbiamo una perdita d’olio di lubrificazione, la pressione dell’olio calerà sotto il livello normale, con conseguente allarme. 

Di conseguenza avremo una partenza pompa ausiliaria con un relativo allarme. Se la perdita è di grossa entità non si ripristinerà la pressione: anche quella dell’olio idraulico (derivato dal collettore dell’olio di lubrificazione) avrà lo stesso andamento e le servovalvole da esso servite, non potranno far posizionare correttamente gli attuatori.  Come conseguenza si avrà un Blocco di Emergenza del turbogas.

In questo esempio, oltre agli allarmi relativi ai dispositivi e ai collettori olio elencati, usciranno fuori decine di allarmi relativi a effetti collaterali, conseguenze logiche del malfunzionamento capostipite: allarmi ridondanti e non rilevanti per l’analisi della vera causa dell’incidente.

La cosa ideale sarebbe predisporre una pagina dedicata in cui un software, su richiesta, mostri un diagramma con in cima la causa scatenante e, come una radice di un albero, tutti gli altri allarmi con le ramificazioni indicanti la correlazione e la giusta successione temporale.

Potrebbe essere possibile una rappresentazione grafica animata utilizzando come base i P&ID del turbogas, ripetendo al rallentatore la sequenza degli eventi occorsi.

Per fare ciò occorre avere una chiara visione di tutto il sistema controllato e delle strategie del controllo implementate oltre a mappare in modo scrupoloso i diagrammi di causa/evento possibili nei vari scenari.

Il lavoro sarebbe molto complesso, ma indubbiamente porterebbe benefici per l’operatore in sala controllo.

Il sistema potrebbe essere programmato per dare indicazioni all’operatore per eventuali azioni correttive da intraprendere per fare rientrare un allarme durante il normale esercizio o prima della ripartenza del turbogas in caso di un blocco di emergenza.

Quella qui descritta è solo una possibile implementazione ma non certamente l’unica che potrebbe essere adottata dai costruttori di turbogas. Le limitazioni alla sua attuazione sono gli alti costi iniziali necessari per lo studio degli alberi di allarme e di tutte le loro possibili interazioni. L’utilizzo dell’intelligenza artificiale potrebbe essere in questo di valido aiuto.

Riferimenti

• Anonimo (1999) “Alarm system-A guide to Design, Management and

Procurement”, Pubblicazione EEMUA N191. (EEMUA, 3rd Floor, 20

Long Lane, London, EC1A 9HL, UK. Tel +44-(0)20-7796-1293

• Anonimo (2000), “Better Alarm Handling”, UK Health and Safety

Executive, Chemicals sheet N 6

• Bransby, M.L., e Jenkinson, J. (1998), “The Management of Alarm

Systems”; HSE Books, ISBN 0 7176 1515 4

• Campbell-Brown, D. (2000), “Practical Steps Toward Better

Management of Alarms” Proceedings “Alarm System”, IBC, London

• Campbell-Brown, D. (2002), “Horses for Courses- A Vision for Alarm

Management”, Proc. IBC Conference “Alarm System”, IBC, London

• Hopkins, A. (2000), “Lesson from Longford”, CHH 186468422 4
• Workshop Gestione Allarmi: Migliori Pratiche, Tecniche e Strumenti

Dott. L. Pedditzi