Implementazione di un sistema di sicurezza del personale per un impianto di accelerazione di particelle

Il Thomas Jefferson National Accelerator Facility (JLab) è un laboratorio nazionale dell’ufficio scientifico del dipartimento dell'energia degli Stati Uniti. È sede del Continuous Electron Beam Accelerator Facility (CEBAF), che produce un fascio di elettroni utilizzato per condurre ricerche fondamentali in fisica nucleare. Dall'inizio alla fine, gli elettroni percorrono fino a cinque giri e mezzo attorno al circuito progettato dall'impianto, accelerando fino a 12 miliardi di elettronvolt (12 GeV).

Per garantire che i rischi per il personale che lavora nella struttura siano stati ridotti al minimo “quanto più basso ragionevolmente ottenibile” (ALARA), il JLab Safety Systems Group (SSG) progetta, gestisce e mantiene un sistema di sicurezza del personale ingegnerizzato (PSS). Il PSS è responsabile di una serie di funzioni di sicurezza, tra cui la prevenzione dell'esposizione diretta alle radiazioni ionizzanti immediate.

Il PSS aiuta il personale a controllare l'accesso alle aree in cui potrebbero sussistere rischi per la sicurezza. Ad esempio, all'interno del sistema di tunnel dell'acceleratore sussistono diversi rischi significativi per la sicurezza mentre il fascio è in funzione. Tra questi rientrano radiazioni ionizzanti e non ionizzanti, radiazioni laser e conduttori elettrici ad alta tensione esposti sugli elettromagneti utilizzati per far ricircolare il fascio attorno agli archi del tunnel (Figura 1). Nel caso peggiore, l'esposizione immediata alle radiazioni ionizzanti può provocare una dose letale nel giro di pochi minuti. Il PSS aiuta il personale a garantire che i lavoratori siano sgomberati dalle aree del sistema di tunnel dell'acceleratore prima dell'entrata in funzione del fascio e che i membri del personale non siano fisicamente in grado di accedere a tali aree fino al completamento dell'operazione.

Il PSS è attualmente sottoposto a un importante aggiornamento che prevede la riscrittura da zero di tutte le funzioni software. Per sviluppare il software per il PSS abbiamo selezionato un linguaggio grafico da IEC 61131 denominato Function Block Diagramming (FBD).

Progettazione Model-Based con Simulink^® svolge un ruolo centrale nei workflow di implementazione e verifica che utilizziamo per sviluppare il software PSS. Tutte le funzioni del PSS vengono prima modellate in Simulink e poi simulate utilizzando casi di test generati da Simulink Design Verifier™. Abbiamo scelto Simulink per questo lavoro perché fornisce un modo maturo, veloce e ben supportato per modellare le funzioni grafiche necessarie e quindi verifica che i progetti siano logicamente corretti prima dell'implementazione. Inoltre, Simulink Design Verifier ci consente di raggiungere, tra gli altri requisiti, una copertura di test del 100% di tutte le funzioni del programma e quindi di dimostrare che i progetti sono sicuri.

È un vantaggio significativo avere la possibilità di completare tutte le attività richieste per il ciclo di vita di progettazione, test e sicurezza, tra cui test funzionali, controllo degli errori aritmetici (ad esempio violazioni dell'intervallo di numeri interi) e analisi della copertura, in un unico ambiente.

Sfide di portata e complessità

Il PSS è progettato per rilevare e rispondere a due ampie categorie di rischi di livello di integrità della sicurezza 3: violazioni del controllo degli accessi e violazioni del controllo dei raggi. Si tratta sostanzialmente di due facce della stessa medaglia. Sebbene gli eventi scatenanti siano diversi, entrambi i tipi di violazione comportano la perdita di separazione tra le persone e il raggio. In caso di violazione del controllo degli accessi, se delle persone entrano in un'area di esclusione all'interno della struttura, tutti i pericoli devono essere eliminati entro pochi secondi (vale a dire prima che le persone raggiungano i livelli inferiori dei tunnel). In caso di violazione del controllo del raggio, il raggio potrebbe essere deviato verso un'area accessibile o su un dispositivo di arresto del raggio che fornisce isolamento per un'area accessibile. In quest'ultimo scenario, data l'elevata potenza del raggio (1 milione di watt), il raggio deve essere spento in appena pochi millisecondi.

La sfida di progettare e verificare il PSS è aggravata dalla complessità e dalle dimensioni del sistema. Il PSS è composto da oltre 2.200 canali I/O (inclusi sensori e attuatori) distribuiti nei nove segmenti della struttura. I segmenti sono separati l'uno dall'altro da cancelli e porte interbloccate. Il PSS per ogni segmento comprende un sistema di sicurezza a doppia ridondanza basato su PLC di sicurezza serie 1500 di Siemens^®.

Complessivamente, il sistema contiene 18 PLC di sicurezza distribuiti e 200 canali di comunicazione tra PLC, utilizzati per lo scambio di dati. Per ogni ciclo di clock, i dati provenienti da circa 2.000 sensori vengono letti e ritrasmessi al centro di controllo principale tramite cavi in fibra ottica per l'elaborazione. Una volta calcolati, i risultati vengono inviati nuovamente sul campo per controllare i vari dispositivi di allarme e di spegnimento. L'intero ciclo si completa in pochi millisecondi e avviene ininterrottamente. Circa il 50% del codice all'interno del PSS viene utilizzato per scopi diagnostici e di automonitoraggio (ad esempio, rilevamento di guasti).

Qualsiasi sistema di controllo di questa portata richiederebbe un notevole investimento ingegneristico. Ma i sistemi di sicurezza possono costare da 3 a 10 volte di più rispetto ai sistemi non di sicurezza quando implementano la stessa funzionalità. L'utilizzo del linguaggio FBD per i PLC di sicurezza Siemens ha impedito l'utilizzo di Simulink PLC Coder™ per generare testo strutturato IEC 61131 direttamente dai nostri modelli Simulink . Invece, tutti i blocchi funzionali sono stati prima progettati e verificati in Simulink, prima di essere reimplementati manualmente utilizzando il linguaggio Function Block Diagram in TIA Portal (l'ambiente di sviluppo integrato di Siemens utilizzato per lo sviluppo e l'implementazione dei PLC) (Figura 2).

Estensione e miglioramento del workflow tradizionale

Data la portata e la complessità del PSS, avevamo bisogno di capire come ottimizzare il workflow di sviluppo esistente. Nel workflow tradizionale, una volta definito il comportamento di un blocco funzionale in Simulink, sarebbe necessario definire casi di test in Simulink, inclusi vettori di input (stimoli) e vettori di output (obiettivi). I casi di test verrebbero eseguiti utilizzando Simulink Test™ e la copertura del test misurata utilizzando Simulink Coverage™ (Figura 3, Percorso 1).

Questo approccio presenta due problemi fondamentali. In primo luogo, il compito di generare manualmente casi di test per ogni funzione può richiedere molto tempo, anche per ingegneri di test esperti. In secondo luogo, se i test non raggiungono il 100% di copertura per la funzione sottoposta a test, può essere spesso molto difficile determinare se ciò sia dovuto a un errore di progettazione nella funzione stessa o a una carenza nel metodo di test per cui sarebbe necessario definire ed eseguire più test.

Per risolvere questi problemi, abbiamo utilizzato Simulink Design Verifier per generare automaticamente casi di test (utilizzando metodi formali) che raggiungono una copertura del 100%. In questo modo si elimina la necessità di definire manualmente i casi di test. Si risolve anche il problema di come rilevare errori di progettazione nella funzione sottoposta a test. Se Simulink Design Verifier non riesce a raggiungere una copertura del 100%, evidenzia la posizione dell'errore di progettazione nella funzione stessa. Questo workflow rappresenta un miglioramento sostanziale rispetto al metodo tradizionale (Figura 3, percorso 2a).

Sebbene l'utilizzo di Simulink Design Verifier offra notevoli vantaggi, introduce una nuova attività da svolgere. Nel metodo tradizionale, l'ingegnere addetto ai test solitamente progetta implicitamente il comportamento funzionale desiderato (obiettivi) nei casi di test man mano che vengono sviluppati. Se i test vengono superati, si dice che la funzione si comporta correttamente. Tuttavia, quando si utilizzano generatori automatici di casi di test, gli algoritmi formali non hanno alcuna conoscenza di ciò che è considerato un comportamento logico corretto. Per questo motivo, è necessario rivedere i casi di test (e i risultati corrispondenti) generati da Simulink Design Verifier per verificarne la correttezza comportamentale, ovvero rivedere i test generati per verificare che la funzione si comporti come previsto.

Ciò può essere fatto esaminando direttamente i casi di test (insieme ai risultati previsti) utilizzando diagrammi temporali oppure simulando i casi di test e osservando i risultati della simulazione basati sul tempo sul modello stesso. Entrambe le opzioni possono essere piuttosto complicate e soggette a errori, soprattutto quando le funzioni hanno molti input e output. Tali test richiedono un tecnico esperto con Simulink installato e possono essere soggetti a cecità di revisione quando ci sono molte funzioni da verificare.

Poiché eravamo interessati a far eseguire le nostre revisioni di progettazione da un gruppo in un ambiente in stile riunione, stiamo sviluppando un concetto chiamato Behavioral Verification Checklists per verificare la correttezza comportamentale delle funzioni del nostro software. Abbiamo creato uno script MATLAB^® che converte i casi di test Simulink in un formato procedurale per renderli più rapidi e facili da leggere e interpretare rispetto ai diagrammi temporali tradizionali (Figura 3, percorso 2b).

Uno sguardo più da vicino alle checklist di verifica comportamentale

Un aspetto centrale del nostro nuovo workflow è la possibilità per gli ingegneri di verificare la correttezza comportamentale dei blocchi funzionali utilizzando checklist anziché leggere diagrammi temporali o eseguire simulazioni. Questi metodi possono spesso richiedere molto tempo ed essere soggetti a errori, soprattutto quando il numero di I/O è elevato. Per risolvere questo problema, sono state sviluppate delle checklist di verifica comportamentale concise e facilmente leggibili, incentrate sulle informazioni a cui i revisori sono maggiormente interessati. Gli ingegneri possono utilizzare queste checklist in modo indipendente o in gruppo per valutare ciascun blocco funzionale e il modo in cui risponde alle variazioni degli stimoli di input (Tabella 1), anche se non utilizzano regolarmente Simulink o non lo hanno installato. Ciò consente il coinvolgimento di un maggior numero di esperti in materia nel processo di revisione della progettazione e riduce il carico di lavoro dell'ingegnere addetto ai test. Poiché i risultati vengono esaminati offline da più persone, aumenta la probabilità di rilevare errori logici. Le checklist vengono generate automaticamente utilizzando script MATLAB da casi di test Simulink, che a loro volta vengono generati automaticamente utilizzando Simulink Design Verifier.

Importazione di casi Simulink Test nel portale TIA

Nella sezione finale del nostro workflow, reimplementiamo e testiamo i blocchi funzionali nel nostro ambiente PLC di destinazione. Iniziamo utilizzando un secondo script MATLAB per convertire i casi di test Simulink in file di casi di test Siemens (che sono file di testo con estensione .TAT) (Figura 4). Traduciamo anche i progetti dei blocchi funzionali da Simulink al portale TIA. Infine, eseguiamo i casi di test convertiti sul codice PLC utilizzando Siemens PLCSIM e Test Suite Advanced per garantire l'equivalenza sul target.

TEST_CASE “TEST_OUTPUT_TEST_CASE_1”
 
PROPERTY
AUTHOR : “METCALF”
VERSION : “1.0”
COMMENT : “Test Case 1 for TEST_OUTPUT function block.”
SCOPE : “PSS_PLC”
END_PROPERTY
 
VAR
TEST_INITIAL_CONDITIONS : TEST_OUTPUT_IDB.TEST_INITIAL_CONDITIONS := FALSE;
TEST_CONFIGURED : TEST_OUTPUT_IDB.TEST_CONFIGURED := TRUE;
TEST_REQUESTED : TEST_OUTPUT_IDB.TEST_REQUESTED := FALSE;
TEST_CONTINUOUS_CONDITIONS : TEST_OUTPUT_IDB.TEST_CONTINUOUS_CONDITIONS := TRUE;
MINIMUM_TEST_DURATION : TEST_OUTPUT_IDB.MINIMUM_TEST_DURATION := T#74ms;
TEST_OUTPUT : TEST_OUTPUT_IDB.TEST_OUTPUT;
END_VAR
 
STEP : “STEP_1”
RUN(CYCLES := 1);
ASSERT.Equal(TEST_OUTPUT,FALSE);
RUN(CYCLES := 399);
END_STEP
 
STEP : “STEP_2”
TEST_CONFIGURED := FALSE;
TEST_CONTINUOUS_CONDITIONS := FALSE;
MINIMUM_TEST_DURATION := T#0ms;
RUN(CYCLES := 1);
ASSERT.Equal(TEST_OUTPUT,FALSE);
RUN(CYCLES := 199);
END_STEP
 
STEP : “STEP_3”
TEST_REQUESTED := TRUE;
RUN(CYCLES := 1);
ASSERT.Equal(TEST_OUTPUT,FALSE);
RUN(CYCLES := 199);
END_STEP
. . . 
. . . 
. . . 
END_TEST_CASE

Figura 4. Parte di un caso di test Siemens generato da uno script MATLAB da un caso di test Simulink.

Distribuzione e applicazione del workflow ad altri progetti

I sistemi di sicurezza ad alta integrità come il PSS richiedono workflow di sviluppo rigorosi per ridurre al minimo il rischio che errori software possano causare conseguenze pericolose e potenzialmente persino catastrofiche. Quando si duplicano componenti software su unità di elaborazione ridondanti, tali rischi vengono ulteriormente moltiplicati, poiché qualsiasi errore diventa una causa comune (CC). Per queste ragioni, la norma IEC 61508 pone grande enfasi sulla prevenzione dell'introduzione di guasti sistematici nei sistemi di sicurezza tramite software. Con la progettazione Model-Based e il nostro nuovo workflow, abbiamo ottenuto un aumento della nostra capacità sistematica—come definito nella norma IEC 61608—a un livello che fornisce un livello molto elevato di garanzia che abbiamo implementato un sistema sicuro e privo di errori.

Siamo attualmente nelle fasi finali dell'implementazione del PSS aggiornato negli ultimi segmenti dell'acceleratore rimasti (Figura 5), con una data di completamento prevista per l'autunno del 2024. Dopo aver completato il PSS, una delle nostre prossime priorità di sviluppo sarà l'aggiornamento del nostro sistema Beam Loss Monitoring (BLM), che fa parte del nostro sistema di protezione delle macchine. Per questo progetto intendiamo utilizzare un workflow molto simile a quello utilizzato per il PSS. Tuttavia, dato che l'obiettivo del sistema BLM sarà un FPGA, prevediamo di utilizzare HDL Coder™ per generare codice HDL sintetizzabile direttamente dai nostri modelli Simulink ed evitare quasi del tutto la codifica manuale sull'obiettivo. Ci auguriamo inoltre di utilizzare le funzionalità Hardware-In-the-Loop di HDL Verifier™ per semplificare e accelerare il nostro workflow di verifica e validazione sui dispositivi.