La progettazione di un’architettura di sicurezza in ambito ferroviario.

A cura di Emiliano La Cara & Giovanni Mazza
[ Direttore & Specialist – Area Ingegneria del Software ]

COS’È L’ARCHITETTURA DI SICUREZZA 2oo2.

NIER è stata coinvolta nella progettazione di un’architettura di sicurezza in ambito ferroviario in grado di ospitare una generica applicazione vitale per un sistema di segnalamento.

Lo standard normativo CENELEC EN50129 offre una serie di possibili scelte architetturali e NIER ha optato per un’architettura a Sicurezza Composita (Composite Fail-Safe Architecture) di tipo 2oo2 (2 out of 2). Questa architettura è caratterizzata da due canali di elaborazione che svolgono in parallelo e in maniera indipendente gli stessi calcoli. Se la comparazione dei risultati ottenuti dall’elaborazione dei due canali dà esito positivo, il sistema può determinare la validità dei risultati ottenuti e, quindi, generare dati validi in uscita (Figura 1).

---

In generale, questo tipo di architetture di sicurezza deve essere progettato in modo da garantire le seguenti condizioni:

• il guasto di uno dei due canali di elaborazione (chiamati Flusso A e Flusso B in Figura 1) non deve avere effetti sull’altro canale;
• il guasto di uno dei due canali deve essere rilevato e negato entro un tempo tale da garantire di evitare che si verifichi un guasto contemporaneo sull’altro canale. Negare il guasto significa portare il sistema, grazie al canale ancora integro, in uno stato in cui non sia possibile generare output contrari alla sicurezza;
• non devono essere presenti le cosiddette cause comuni di guasto (Common Cause Failure, CCF). Infatti, in questo caso, anche un singolo guasto, che è però simultaneo su entrambi i canali, causerebbe lo stesso fallimento sul processo di calcolo per entrambi i canali, generando così un output potenzialmente pericoloso (definito “hazard”);
• devono essere rilevati i guasti latenti, ovvero guasti che pur esistendo non possono essere rilevati fino che, combinandosi con altri guasti, si manifestano causando la generazione di un output pericoloso.

La architettura di sicurezza progettata da NIER previene i CCF e gli hazard applicando le seguenti contromisure:

• implementazione di controlli in 2oo2 in grado di rilevare tempestivamente eventuali errori/guasti prima che questi causino la generazione di un output pericoloso. Con controlli in 2oo2 si intende, in generale, la possibilità (fornita dalla architettura di sicurezza stessa) di confrontare i risultati delle elaborazioni (parziali o finali) tra i due canali, prendendo opportune contromisure nel caso in cui questi non siano coerenti;
• segregazione fisica dei canali di elaborazione: i due microprocessori sono isolati galvanicamente e ognuno gestisce solo e soltanto il proprio flusso di elaborazione (CPU A gestisce flusso A, CPU B gestisce flusso B – Figura 1);
• implementazione di tecniche di diversity software per minimizzare la probabilità di CCF: utilizzo di due sistemi operativi differenti (uno su ogni CPU) e due diverse toolchain di compilazione per ciascun canale, per cui il codice dell’applicativo vitale viene compilato (e quindi reso codice macchina) tramite due vie indipendenti.

E la mitigazione dei guasti latenti?

A questo fine abbiamo implementato funzioni di diagnostica vitale (ovvero specifica per le funzioni vitali) capaci di rilevare un errore o un guasto Hw per ogni singolo canale tramite la reciproca verifica 2oo2 di integrità (i.e. coerenza), assicurando così un livello di Diagnostic Coverage[1] (ovvero la misura dell’efficacia della diagnostica implementata nel sistema) conforme alla normativa IEC EN61508-2.

I guasti, infine, vanno trattati a seconda della loro gravità. Essi possono essere critici e non critici:

• i guasti critici causano il fallimento di funzionalità di sicurezza.

Le funzionalità di sicurezza sono tutte quelle per cui un loro malfunzionamento può generare conseguenze disastrose nell’esercizio del sistema (potenziale perdita di vite umane / danni strutturali). Si pensi, per esempio, al pilotaggio a verde (via libera) di un segnale quando questo dovrebbe invece segnalare al macchinista via impedita (rosso) perché la tratta è ancora occupata da un altro convoglio. Lo scontro potrebbe essere catastrofico;

• i guasti non critici non causano il fallimento di funzionalità di sicurezza.

Si pensi, per esempio, ad un allarme diagnostico: il sistema non segnala, erroneamente, una temperatura di esercizio della CPU troppo alta. In questo caso una delle due CPU del sistema potrebbe smettere di funzionare causando indisponibilità, ma senza minare la sicurezza di esercizio.

Nel caso di guasti critici la nostra piattaforma di sicurezza entra in uno stato denominato “stato sicuro” (safe state). In questo stato le interfacce per lo scambio dati verso l’esterno vengono inibite cosicché il sistema non può compiere azioni che ne comprometterebbero il funzionamento in sicurezza (i.e. attivare impropriamente un segnale verde di via libera – vedi sopra).  Il sistema non può uscire in modo autonomo dallo stato sicuro, ma esclusivamente attraverso l’intervento di personale qualificato (Manutentore).

[1] Matematicamente, è il rapporto tra i guasti rilevati e/o controllati da un meccanismo di sicurezza rispetto ai guasti totali

COS’È L’ARCHITETTURA DI RIDONDANZA CALDA.

La piattaforma realizzata possiede inoltre la capacità di gestire un’architettura ridondata che soddisfa i requisiti di disponibilità[1] e manutenibilità[2]. “Detto in poche parole, il sistema oltre ad avere i meccanismi di 2oo2 sopra descritti, è in grado di gestire una ridondanza calda. Come schematizzato in figura 2,” il sistema sarà composto di due sezioni gemelle, ognuna caratterizzata dalla architettura sicura 2oo2. Solo una delle due sezioni sarà in grado di adempiere a tutti i compiti di invio e ricezione messaggi sulla rete di comunicazione (detta sezione in servizio), mentre l’altra sezione rimane in ascolto (detta sezione disponibile) tenendosi pronta a subentrare alla sezione in servizio, senza perdita di funzionalità, qualora in questa ultima si verificasse un guasto.

In questo modo si garantisce la continuità di funzionamento, consentendo nel frattempo un intervento di riparazione della sezione guasta.

[1] Capacità di un sistema di svolgere una funzione richiesta in determinate condizioni ad un dato istante

[2] Capacità di un sistema di essere facilmente ripristinato qualora sia necessario realizzare un intervento di manutenzione

ALGORITMI DI SICUREZZA E CONTROLLI VITALI.

Il suddetto sistema, per garantire la sicurezza, oltre alle scelte architetturali implementa una serie di strategie e algoritmi al fine di mettere a disposizione della applicazione vitale ospitata tutte le funzionalità necessarie. Tali funzionalità sono state concepite e progettate con lo scopo finale di risultare il più possibile trasparenti rispetto all’applicazione ospitata e, quindi, generiche. Questo permette sia di ospitare differenti applicazioni, sia di semplificare lo sviluppo delle stesse, alleggerendole dall’ implementazione di gran parte delle funzioni vitali e delle contromisure di sicurezza e fornendo le risorse hardware e software non vitali di supporto.

Elenchiamo qui di seguito solo alcune di tali funzionalità, a puro scopo informativo:

• controllo della memoria RAM e controllo della corretta sequenza di esecuzione delle routine software e della loro durata temporale (parte della diagnostica vitale);
• controllo dello stato delle interfacce di rete, temperature e tensioni elettriche della CPU (parte della diagnostica non vitale);
• meccanismi per l’allineamento e lo scambio dati tra le due sezioni ridondate (necessarie per gestire lo switch-over Servizio-Disponibile tra le due sezioni);
• la gestione del tempo di ciclo con cui la macchina funziona (ordine delle centinaia di millisecondi) e della sincronizzazione oraria;
• I meccanismi di IPC (Inter-Process Communication), tramite cui si gestisce la comunicazione e la sincronizzazione dei processi di sistema.

L’elenco è ovviamente molto più denso e la descrizione di dettaglio esula dallo scopo di questa short-communication tecnica. Il razionale che sottostà ad una siffatta architettura ed agli algoritmi di sicurezza è che essi sono disegnati in modo tale che soltanto in assenza di guasti possano generare, come risultato della loro esecuzione, contributi parziali che combinati tra loro permettano di ottenere un risultato finale valido, ovvero interpretabile dagli altri componenti del sistema o tale da generare l’attuazione di condizioni permissive (es. segnale verde).

Se i valori generati dagli algoritmi sicuri sono errati, l’output del sistema non è considerato valido e il sistema entra nello stato sicuro mitigando il rischio di generare conseguenze catastrofiche.

CONCLUSIONI.

L’obiettivo di questo progetto è stato quello di creare, dalla progettazione fino all’implementazione, un’architettura a sicurezza composita 2oo2 in grado di ospitare una generica applicazione vitale e capace di svolgere gran parte delle funzioni vitali (implementando le relative contromisure di sicurezza associate) richieste per sistemi ferroviari SIL4. Questo approccio permette di semplificare notevolmente lo sviluppo dell’applicazione vitale stessa. La certezza della disponibilità e manutenibilità del sistema è garantita dalla progettazione del meccanismo di Ridondanza calda.