Al centro della progettazione del sistema di controllo ci sono standard, standard e standard

Sebbene le migliori pratiche per qualsiasi sistema di controllo abbiano al centro il perseguimento di un approccio standardizzato alla configurazione del software applicativo, la sfida di progettare un sistema da zero è certamente un compito arduo.

Come dice il famoso proverbio, i tre fattori più importanti nella vendita di immobili sono la posizione, la posizione e la posizione. Per i sistemi di controllo distribuito (DCS) utilizzati per controllare processi sofisticati in molti settori, l'equivalente può essere facilmente riassunto come "standard, standard e standard". Un sistema DCS funge da fulcro delle operazioni di un'azienda di lavorazione e controlla e monitora variabili chiave quali flusso, temperature applicate, pressione, livello e trasporto/movimentazione dei materiali. L'HMI del DCS raccoglie tutti i dati dalle apparecchiature di produzione e li presenta all'operatore in un modo altamente "fattorato dall'uomo". Tuttavia, esistono infinite variabili legate al tipo di attrezzatura, al materiale in lavorazione, alle azioni dell'operatore e al sistema di controllo. Il DCS deve quindi essere progettato per gestire in modo prevedibile i disturbi comuni e attesi, nonché le anomalie impreviste. Sfortunatamente, progettare un'applicazione DCS da zero è come fissare un foglio di carta bianco; può essere configurato in quasi ogni modo immaginabile. Si tratta di un’arma a doppio taglio che può portare a un sistema robusto che fornisce un controllo preciso e prevedibile se eseguito con attenzione, oppure potrebbe portare a perdita di prodotto, interruzioni del processo e persino problemi di sicurezza se eseguito in modo inadeguato.

Ogni configurazione dell'applicazione dovrebbe iniziare con una filosofia di progettazione ben definita. La maggior parte delle applicazioni DCS vengono create e gestite da team di ingegneri, quindi dovrebbero remare tutti nella stessa direzione. I migliori risultati possono essere ottenuti solo quando tutti i contributori all'applicazione complessiva di controllo del processo seguono le stesse migliori pratiche e tecniche. In caso contrario, il risultato sono errori di processo involontari e un sistema difficile da mantenere. Ogni ingegnere che contribuisce all'applicazione dovrebbe sforzarsi di scrivere la propria logica allo stesso modo. Le pratiche standard utilizzate dovrebbero essere ben documentate e insegnate a tutti i responsabili del sistema di controllo. In effetti, sarebbe un'indicazione appropriata di un'applicazione DCS ben progettata se gli ingegneri dei sistemi di controllo non riuscissero a identificare il programmatore specifico osservando la logica del programma o osservandone l'esecuzione. Un'area specifica della progettazione DCS che illustra i vantaggi di una filosofia consolidata e condivisa è la gestione degli allarmi. Nell'automazione dei processi, un allarme è definito come un mezzo acustico e/o visibile per indicare all'operatore un malfunzionamento dell'apparecchiatura, una deviazione del processo o una condizione anomala che richiede una risposta da parte dell'operatore. Sistemi di gestione degli allarmi progettati e mantenuti in modo inadeguato possono sopraffare gli operatori con chiacchiere e allarmi fastidiosi in condizioni normali e ondate di allarmi debilitanti quando emergono stati anomali. Quando ciò accade, può essere difficile per gli operatori accertare e intervenire sugli allarmi più critici, contribuendo a situazioni anomale, perdita di produzione e persino incidenti gravi. Recentemente, organizzazioni come ANSI (American National Standards Institute) e ISA (International Society of Automation) hanno pubblicato linee guida aggiornate relative alla gestione degli allarmi. Lo standard ANSI/ISA 18.2 affronta l'intero ciclo di vita della gestione degli allarmi, dalla progettazione e configurazione fino al monitoraggio delle prestazioni, all'auditing e all'applicazione per tutta la vita dell'applicazione di controllo. Fondamentalmente, ciò che il comitato ISA ha stabilito è che un allarme dovrebbe essere utilizzato solo se richiede la risposta di un operatore, e questa è probabilmente la prima cosa che la maggior parte degli impianti di lavorazione viola. Usano gli allarmi per tutti i tipi di notifiche, avvisi e promemoria. Le principali aziende di automazione dei processi hanno incorporato un approccio più basato su standard per lo sviluppo delle applicazioni, concentrandosi sulla differenziazione degli allarmi che richiedono attenzione immediata da notifiche, avvisi e messaggi meno urgenti. Ad esempio, il DCS Valmet D3 è progettato per soddisfare o superare i requisiti delineati nell'ISA-18.2, anche se con una terminologia leggermente diversa. Ciò include la limitazione degli allarmi, il supporto della definizione delle priorità degli allarmi, la classificazione degli allarmi e la gestione dinamica degli allarmi.