Lo sviluppo software di apparati ferroviari “Safety-Related”

Il corso è progettato per produrre competenze operative, non soltanto consapevolezza normativa. Al termine delle sette mezze giornate il partecipante è in grado di intervenire concretamente su tutto il ciclo di vita del software safety-related: dalla derivazione dei requisiti di sicurezza a livello di sistema fino alla qualificazione dei tool e alla chiusura delle evidenze di verifica.

In particolare, alla fine del percorso il partecipante sa:

1. Ricostruire la catena della sicurezza. Collegare un hazard di sistema al requisito di integrità della singola funzione software, attraverso l’analisi dei rischi e l’allocazione delle funzioni: è il presupposto per difendere qualsiasi scelta progettuale davanti a un valutatore indipendente.
2. Ripartire un THR in TFFR e derivarne il SIL. Distribuire il Tolerable Hazard Rate tra funzioni indipendenti e cooperanti, distinguendo i casi in cui l’indipendenza è dimostrabile da quelli in cui va dichiarata come ipotesi da verificare.
3. Impostare il SwQAP e i piani collegati. Definire piano di qualità del software, di verifica, di validazione e di gestione della configurazione, con gate review dotate di criteri di ingresso e di uscita verificabili e non puramente formali.
4. Scrivere SRAC effettivamente utilizzabili. Formulare Safety-Related Application Conditions univoche, tracciate all’hazard che le origina e complete di destinatario, metodo di verifica ed evidenza attesa: è il punto su cui si concentra più spesso l’osservazione degli enti di verifica.
5. Calcolare diagnostic coverage e Safe Failure Fraction. Partire da una FMEA di componente per arrivare ai parametri quantitativi che giustificano la copertura diagnostica dichiarata e, con essa, l’architettura adottata.
6. Scegliere e giustificare un’architettura rispetto al SIL target. Valutare configurazioni alternative, definizione dello stato sicuro, tolleranza ai guasti e partizionamento delle funzioni safety, motivando il compromesso tra sicurezza, disponibilità e costo.
7. Redigere un coding standard e motivare adozioni e deroghe MISRA C. Tradurre le raccomandazioni normative in regole verificabili in modo automatico e documentare ogni deviazione con la relativa analisi di impatto.
8. Rendere una release identificabile e riproducibile byte per byte. Governare configurazione, toolchain e compilazione deterministica in modo che il binario consegnato sia ricostruibile in modo identico anche a distanza di anni.
9. Progettare una campagna di test con la metrica di copertura adeguata al SIL. Selezionare tipologie di prova (component, integration, hardware/software, validazione) e criteri di copertura, mantenendo la tracciabilità bidirezionale tra requisiti, test ed esiti.
10. Classificare i tool secondo T1, T2 e T3 e definirne il livello di qualificazione. Riconoscere quando uno strumento può introdurre un errore nel prodotto finale o non rilevarlo, e predisporre la corrispondente evidenza di qualificazione.

Il filo conduttore dei dieci risultati è la tracciabilità: ogni scelta di architettura, di linguaggio, di test o di strumento deve poter essere ricondotta a un requisito di sicurezza e sostenuta da un’evidenza documentale. Chi conclude il corso non dispone soltanto di un quadro delle norme applicabili, ma è in grado di costruire e difendere il Safety Case che le sintetizza.

Per orientare correttamente le aspettative è utile chiarire anche il perimetro esterno del corso: che cosa il percorso deliberatamente non si propone di fare. Il taglio è quello di un corso di metodo e di pratica progettuale, centrato su ciò che il software safety-related richiede di scrivere, calcolare, verificare e consegnare.

In particolare:

• Non è un corso di certificazione. Non rilascia qualifiche riconosciute da organismi di certificazione né abilitazioni di ruolo, e non sostituisce la lettura diretta delle norme: fornisce le chiavi per interpretarle e applicarle, ma il testo normativo resta il riferimento contrattuale.
• Non è un corso di programmazione. La lezione dedicata a Rust spiega per quali ragioni il linguaggio è entrato nel discorso normativo e quali garanzie offre rispetto alle classi di errore tipiche del C, ma non ha l’obiettivo di formare sviluppatori Rust: la sintassi e l’addestramento al linguaggio richiedono un percorso dedicato.
• Non è un corso sui prodotti. I tool citati durante le lezioni sono esempi di categoria funzionale, utili a capire che cosa serve in una toolchain qualificata e come classificarla secondo T1, T2 e T3; non costituiscono raccomandazioni commerciali né confronti tra fornitori.
• Non è un corso teorico sulla safety. Le basi concettuali vengono richiamate quando servono a rendere comprensibili le scelte progettuali, ma il baricentro resta operativo: che cosa si scrive, che cosa si calcola e che cosa si consegna al committente e al valutatore indipendente.

Partner del corso è la società di ingegneria NIER con oltre 25 anni di esperienza nello sviluppo e nella verifica di sistemi software safety-critical, operante in settori caratterizzati da elevati requisiti di sicurezza e affidabilità, tra cui ferroviario, automotive, industria, life sciences e nucleare.

L’azienda combina competenze ingegneristiche avanzate con un solido presidio dei temi HSE&Q (Health, Safety, Environment & Quality), supportando organizzazioni che operano in contesti tecnologicamente complessi e regolati.

L’area Software Engineering supporta organizzazioni che sviluppano sistemi critici, contribuendo alla progettazione, realizzazione e validazione di software conforme ai principali standard internazionali di functional safety. Le attività sono svolte secondo normative quali EN 50716 (che sostituisce le precedenti EN 50128 e EN 50657) per il software ferroviario, EN 50126 per il ciclo di vita RAMS e EN 50129 per la dimostrazione della sicurezza dei sistemi di segnalamento, ISO 26262 per l’automotive, IEC 62304 per il software medicale, IEC 60880 per i sistemi nucleari e IEC 61508 / ISO 13849 per applicazioni industriali e di automazione.

Le competenze dell’area coprono l’intero ciclo di vita del software safety-critical: ingegneria dei requisiti, progettazione architetturale, sviluppo software embedded, integrazione, verifica e validazione indipendenti del software, con particolare attenzione alle metodologie e alle pratiche richieste dagli standard di sicurezza. In questo ambito NIER applica tecniche di Model-Based Development, sviluppo embedded in C, C++ e Rust secondo linee guida di qualità e sicurezza (tra cui MISRA C), e metodologie strutturate di verifica basate su analisi statica e dinamica del codice, test automatici e verifica della copertura dei test.

Un ambito di particolare specializzazione riguarda i sistemi ferroviari e di segnalamento, inclusi sistemi ERTMS/ETCS, per i quali NIER sviluppa componenti software e moduli applicativi, supporta attività di configurazione e gestione dei dati di sistema, integrazione con sistemi di controllo e sottosistemi di segnalamento esistenti e svolge attività di verifica e validazione indipendente.

L’azienda possiede inoltre competenze nello sviluppo di protocolli di comunicazione e tool safety-related classificabili come T2/T3, quali compilatori dati, configuratori di sistema, generatori di codice e simulatori di protocolli, strumenti fondamentali nei processi di sviluppo, configurazione e verifica dei sistemi safety-critical.

Accanto alle attività di software engineering, NIER presidia anche gli aspetti di RAMS e sicurezza del sistema, supportando i clienti nelle analisi di affidabilità e sicurezza e nella dimostrazione della sicurezza, fino alla predisposizione del Safety Case.

Il corso è rivolto a tutte le figure professionali coinvolte, a vario livello e titolo, nello sviluppo di apparati ferroviari safety-related, operanti negli ambiti di (elenco non esaustivo):

• progettazione
• sviluppo software
• safety management
• verifica e validazione
• system engineering
• quality assurance
• gestione di progetto

Il corso è inoltre aperto a tutti coloro che desiderano approfondire le tematiche trattate.

Non sono richieste competenze tecniche pregresse: i contenuti sono strutturati per essere accessibili a tutti, indipendentemente dal background di partenza.