LA NECESSITÀ DI UN ATTUATORE “INTELLIGENTE”.

L’evoluzione del sistema segnalamento ferroviario verso gli standard ERTMS/ETCS prevede la comunicazione su rete pubblica aperta, la conformità ai protocolli vitali e la digitalizzazione dell’infrastruttura di comunicazione con gli enti di campo. Cosa sono gli enti di campo? Segnali, passaggi a livello, deviatoi, ecc. La digitalizzazione dell’infrastruttura di comunicazione viene gestita da attuatori Object Controller (OC).

Gli OC, classificati come prodotti SIL4 (safety critical), devono processare e inviare verso il campo i comandi ricevuti dall’apparato Centrale Computerizzato (l’Interlocking Kernel – IXL).

Fino a poco tempo fa, gli OC fungevano solamente da interfacce fra l’IXL e gli enti di campo ma oggi, grazie al progresso tecnologico, sono in grado di gestire una porzione della linea ferroviaria calcolando le “Equazioni Booleane[1]” che ne determinano il governo. Un OC si interfaccia con gli enti di campo, con gli altri OC, con l’IXL e con RBC (Radio Block Center) tramite il protocollo vitale standardizzato (PVS – Protocollo Vitale Standard).

[1] Le equazioni booleane sono l’astrazione della tratta ferroviaria di competenza del IXL che consente di determinare lo stato futuro di ciascun ente in funzione dello stato attuale di tutti gli altri enti al contorno.

CONTROLLO CENTRALIZZATO VS CONTROLLO DECENTRALIZZATO.

Il CTC (Centralized Traffic Control) è un sistema per la regolazione operativa della circolazione ferroviaria costituito dal nucleo di elaborazione centrale IXL, ubicato nel Posto Centrale (una sort di control room), e da un insieme di dispositivi per la gestione di tutti gli enti di stazione e di linea, collegati al Posto Centrale.

Ciclicamente, IXL invia i comandi verso gli enti di piazzale (segnali, deviatoi, passaggi a livello) e riceve lo stato dei vari dispositivi, tra cui la presenza o meno di un treno su una determinata sezione di binario.

Queste informazioni sono rappresentate da variabili logiche contenute in Equazioni Booleane che vengono elaborate dall’IXL più volte al secondo determinando, ad esempio, se un convoglio può o meno muoversi su una specifica tratta ferroviaria. Per quantificare: IXL può dover gestire il calcolo di 100.000 equazioni, che coinvolgono un totale di 100.000 variabili in ingresso e 100.000 in uscita, ogni 250 millisecondo.

All’aumentare della complessità della linea, il numero di equazioni può crescere fino a saturare i limiti computazionali dell’IXL. Pertanto, diventa auspicabile una gestione locale e non più centralizzata delle linee. È così che nasce il controllo decentralizzato dei treni (Decentralized Architecture), cioè la suddivisione della linea in partizioni più piccole in cui gli OC sono i responsabili della regolazione della circolazione e fanno le veci del IXL: l’OC diventa “intelligente”.

Un altro vantaggio del controllo locale è l’efficienza: la diminuzione dei tempi di risposta del sistema sono più brevi. Un esempio? La chiusura di un passaggio a livello (PL): se la logica è già presente nell’attuatore, quello che acquisisce i controlli, invece di inviarli al calcolatore centrale perché vengano elaborati e aspettare i comandi relativi, li processa direttamente e attua i comandi.

IL MODULO DI COMUNICAZIONE DELL’ATTUATORE.

Nell’ambito della validazione dell’attuatore, l’intelligenza risiede nel modulo di comunicazione del OC (Figura 1). Permette la comunicazione sia con l’IXL/RBC (tramite interfaccia di rete ethernet) sia con le altre schede dello stesso OC (tramite il CAN BUS). Le altre schede evidenziate in blu (schede#1… N) in Figura 1 sono i moduli di gestione dei segnali (SGN), dei deviatoi (DVT), dei passaggi a livello (PL) etc. Al modulo di comunicazione è anche in carico il calcolo delle Equazioni Booleane.

Il software del modulo di comunicazione, progettato su architettura 2oo2, è composto da una parte vitale (safety critical – SIL 4) e da una parte non vitale (ad esempio la diagnostica) come esemplificato in Figura 1 segregate tra di loro.

IL COINVOLGIMENTO DI NIER.

NIER ha supportato un cliente per oltre 3 anni in tutte le fasi del Ciclo a V del prodotto Object Controller (OC), sempre in stretto legame con i team di Design, Safety e V&V. Le fasi principali del progetto sono state 4.

1. Analisi e individuazione delle problematiche safety

È stata effettuata analisi, tracciatura e mitigazione dei rischi contrari alla sicurezza (ovvero, se per ogni guasto contrario alla sicurezza non fosse prevista una contromisura, le conseguenze potrebbero essere catastrofiche), identificati nei seguenti documenti:

• Preliminary Hazard Analysis (PHA) – identifica tutti gli hazard valutandone livelli di rischio e contromisure.
• Hazard Analysis (HA) – individua sia i requisiti di sicurezza, sia le condizioni applicative di sicurezza nel caso in cui le mitigazioni non siano sufficienti. Gli strumenti sono FMECA (Failure Mode, Effects & Criticality Analysis) e CCF (Common Cause Failure).
• Hazard Log (HL) – traccia tutte le attività relative all’identificazione e gestione di Hazard e contromisure. È riportata la copertura dei requisiti di sicurezza e dei requisiti di sistema con i test eseguiti.

2. Test su Target: verifica dei protocolli di comunicazione

Sono state svolte le attività di test sui protocolli vitali (PVS), non vitali e sulla comunicazione di interfaccia con il sistema di diagnostica.

Il set up iniziale dell’ambiente in laboratorio, propedeutico ai test, ha lo scopo di riprodurre l’architettura reale nell’ambiente simulato. In questa fase solitamente si eseguono:

• Cablaggi ed interconnessioni specifiche dell’EUT (Equipment Under Test);
• Configurazione delle reti di comunicazione tra EUT e gli altri apparati di sistema;
• Configurazione degli apparati di diagnostica e dei dispositivi di campo controllati dall’EUT.

L’attività di test si è svolta così, con riferimento all’Ambiente in Figura 2:

• Esecuzione dei test funzionali (precedentemente progettati e formalizzati in un piano di test) tramite:
  • simulatori multiprotocollo corredati da tool di simulazione progettati per l’attività specifica;
  • ispezione statica per la verifica della corretta implementazione dei protocolli;
  • error injection per la verifica del comportamento dinamico dei protocolli (corruzione del contenuto dei messaggi, mancato invio dei messaggi, errori a livello fisico ecc.) e della corretta gestione dei valori di tolleranza.
• Implementazione di strumenti (tramite linguaggi di scripting) per la semi-automatizzazione dell’analisi dei log di rete;
• Supporto al team di design nella fase di debug/bug fixing delle anomalie (CR) riscontrate durante la fase di test.

Nel caso di comunicazione non vitale[2] l’attività di test è stata fatta per garantire al personale di stazione di poter:

• Monitorare la corretta comunicazione su protocolli non vitali tra il modulo di comunicazione e gli enti di piazzale
• Verificare lo stato degli apparati fisicamente connessi al modulo di comunicazione
• Gestire la raccolta degli errori provenienti dagli apparati di campo, per poterne verificare in particolare:
  • Attività: si monitorano informazioni come le tensioni elettriche applicate, il valore delle temperature di esercizio, la condizione operativa delle interfacce ecc.
  • Status Health (stato di funzionamento): si monitorano eventuali condizioni di degrado o malfunzionamento.

[2] Per comunicazione non vitale si intende l’insieme di informazioni fornite dalla scheda o dagli apparati di campo ad essa connessa, che veicolano i singoli comandi/controlli non vitali o che trasportano informazioni relative alla diagnostica (stato delle interfacce, tensioni elettriche, temperature ecc.).

3. Test su Target: interfacciamento apparati di campo

Un’ulteriore fase di test per Object Controller consiste nella verifica funzionale della sua integrazione con tutti gli altri apparati costituenti il sistema. Il laboratorio di test (Figura 2) è organizzato in modo da includere alcuni enti reali, in particolare segnali luminosi, comandati dalle relative schede di interfaccia (SGN).

Le attività svolte sono state:

• Verifica dell’interfacciamento tra il modulo di comunicazione e i Segnali Reali, sia in condizioni nominali che di degrado/malfunzionamento.
• Controllo degli apparati di campo: sono stati verificati tutti i sistemi ed allarmi relativi alla attività e allo Status Health.

4. Attività di Verifica e Safety

Sono stati verificati i documenti rilasciati sia dal Design che dal team V&V. Le attività eseguite da NIER in questa fase sono state le seguenti:

• Specifica del Sistema e del Software:  redazione dei report di verifica per specifica requisiti di sistema (SyRS), specifica dei requisiti di architettura (SyAD), PHA, specifica dei test funzionali (RITD), specifica dei requisiti e dell’architettura del software (SwRS e SwAD) in accordo con le normative CENELEC (EN 50126, EN 50128 ed EN 50129) e Safety Plan. Inoltre, NIER ha verificato la corretta implementazione delle funzioni Software SIL4 tramite ispezione del codice sorgente in Software Safety Verification Report (SwSV). Per quantificare, SyRS e SyAD contengono più di 950 requisiti.
• Specifica ed Esecuzione dei test funzionali: verifica dell’adeguata copertura dei requisiti tramite i test funzionali (specificati in RITD) e dell’esecuzione dei test stessi (oltre 330 Test case), controllando completezza e correttezza nei risultati ottenuti rispetto a quelli attesi.
• Validazione del Sistema: stesura del Validation Report di sistema (VR) che raccoglie i risultati della validazione di tutte le attività svolte fornendo le evidenze che il prodotto è stato sviluppato in conformità alle normative (EN 50129) e Safety Plan.
• Stesura di Risk Analysis secondo Common Safety Method (CSM)[3]: in accordo al regolamento 402/2013, è stata fatta l’analisi di tutte le modifiche implementate nel modulo di comunicazione, dovute sia all’implementazione di nuove funzionalità, sia alle CR emerse nelle fasi di Test e validazione. Abbiamo definito l’impatto sulla sicurezza, i criteri di accettazione del rischio ed il metodo adottato per la dimostrazione del livello del rischio.

[3] L’attività copre la direttiva europea “COMMISSION IMPLEMENTING REGULATION (EU) on the common safety method for risk evaluation and assessment and repealing Regulation (EC) No 352/2009” e l’aggiornamento “COMMISSION IMPLEMENTING REGULATION (EU) amending Implementing Regulation (EU) No 402/2013 on the common safety method for risk evaluation and assessment”.

CONCLUSIONI.

Con una meticolosa gestione del processo di Verifica e Validazione, NIER ha supportato il cliente nel raggiungimento dei seguenti obiettivi:

• Identificare i bug di sistema a vario livello: di specifica, di requisiti, di implementazione, funzionale e di performance con l’individuazione delle non conformità. Sono state analizzate e convalidate più di 390 CR sollevate durante tutto il ciclo di vita del EUT;
• Valutare l’usabilità e l’affidabilità dell’EUT nelle diverse situazioni operative;
• Prendere in carico e chiudere più di 900 punti aperti in fase di assessment.

I punti chiave della “soluzione” fornita da NIER sono stati:

• Interfacciamento continuo e tempestivo con i diversi stakeholders del progetto;
• Proattività verso il cliente con soluzioni e approcci innovativi (sviluppo tool di simulazione, automazione ed analisi risultati) alimentata da una forte esperienza di dominio maturata sul campo.