AS_01_2020

tecnica Automazione e Strumentazione Gennaio/Febbraio 2020 89 CONTROLLO vitabilmente si fanno durante le fasi di debugging e collaudo di ogni sistema programmabile. I forzamenti vengono fatti dalla stazione di ingegneria e con- figurazione, la quale avvisa comunque che ve ne sono di attivi ogni volta che viene compilato il programma. Gli override invece sono altri blocchi funzionali già previsti nell’applicativo sviluppato, con lo scopo di consentire agli ope- ratori di bypassare la funzione di sicurezza qualora fosse neces- sario, come ad esempio accade in alcune fasi di avviamento o di manutenzione. Possono essere messi in override sia gli ingressi (iniziatori) che le uscite verso gli organi di comando (figura 2) ma, dato che lo stesso attuatore può essere coinvolto in più funzioni di sicurezza, i Mos sono fortemente sconsigliati dagli standard IEC di riferimento (IEC61508/511). Il blocco Sys_OVR restituisce ini ogni caso: - un True se c’è almeno un ovveride attivo, - il numero di override attivi, - il numero di override attivi per più di un tempo massimo impostabile, - il numero di ovveride attivi che eccede un numero massimo impostabile, - il numero di ovveride operation abilitate ma non ancora attive, - il numero di override abilitati (ma non ancora attivi) per più di un tempo massimo impostabile, - il numero di ovveride abilitati (ma non ancora attivi) che eccede un numero massimo impostabile. Lo stesso blocco funzione può inoltre disabilitare tutti gli override attivi quando un suo opportuno ingresso passa da False a True. È importante dunque impiegare questo blocco funzione all’interno del programma applicativo per evitare che gli override rimangano attivi oltre al tempo strettamente necessario: non bisogna dimenticare che ogni override attivo annulla una funzione di sicurezza per cui è potenzialmente pericoloso per l’impianto. Dato che l’abilitazione all’at- tivazione dell’override può provenire da un blocco PSWD (che restituisce un True se l’operatore la inserisce uguale a quella impostata nel codice applicativo), è disponibile anche un blocco funzione (Sys_PSWD) che individua quanti bloc- chi password sono stati correttamente ‘superati’ e attiva due diverse uscite se questo numero è superiore a un massimo impostabile o se l’attivazione è vera per più di un tempo impostabile. Inoltre se il suo ingresso UNPW diventa vero il blocco provoca il reset delle uscite di tutti i blocchi PSWD disseminati nell’applicativo. Accesso alla CPU del safety controller Infine, un importante aspetto è quello relativo alla sicurezza nell’accesso alla memoria della CPU e ai sorgenti del pro- gramma applicativo, che risiedono sulla stazione di ingegne- ria e configurazione. Recenti incidenti hanno infatti mostrato quanto i sistemi di sicurezza non siano immuni dagli attacchi informatici che in questo caso si possono tradurre in shutdown di impianto o perdita delle funzioni di sicurezza. Il livello di accesso alla CPU, che deve essere abbassato (sotto pas- sword) per poter fare operazioni di download o forzamenti, può essere completamente bloccato attraverso il blocco Sys_Sec_CTL: se il suo input viene associato a un ingresso digitale hardware col- legato a un selettore a chiave, il livello di accesso alla CPU rimane bloccato anche per chi conosce la password e risulta modificabile solo dal possessore fisico di quella chiave reale. Il blocco Sys_ Secure, invece, restituisce il livello corrente di accesso e consente di resettarlo da logica, riportandolo a quello di associato al regolare esercizio, oppure dopo un tempo massimo impostabile. Nelle applicazioni in ambito IEC61508/511 è buona norma fare uso di questi blocchi funzione e portarne gli output all’atten- zione degli operatori attraverso le interfacce allarmi o attraverso pagine grafiche appositamente sviluppate. Conclusioni L’analisi delle funzioni di sicurezza può risultare più agevole se si fa uso di un pacchetto software opportunamente progettato allo scopo . Ciò è anche richiesto dalle ultime revisioni degli Standard (per esempio IEC61511 Edition 2, 2016) secondo cui l’utente finale deve periodicamente riconfermare che le assunzioni fatte durante le fasi di progettazione siano ancora valide, attraverso la presentazione di dati operativi reali: per esempio, le demand devono essere effettivamente basse come richiede la teoria sulla quale si basano i calcoli del Sil; l’intervento delle Sif deve essere effettivamente inferiore ai ‘process safety time’ ipotizzati. Il pacchetto ExaQuantum/SFM , il componente del data-histo- rian Yokogawa deputato al monitoraggio delle funzioni di sicu- rezza (SFM), è un tool che può produrre tutta una serie di report preconfigurati in merito al numero di attivazioni delle SIF, relati- vamente a quali iniziatori, al numero di override attivi e alla per- centuale di tempo in cui ogni SIF rimane in ovveride... e molti altri (cfr pag. 94). Solo un accorto impiego del safety system consente di non vani- ficare l’investimento fatto e di mantenere la conformità agli Standard di riferimento. Figura 2 - Process Override (POS) e Maintenance Override (MOS)