Test del software dei circuiti di sicurezza integrati

di Alexandru Forrai e Takaharu Ueda

Questo articolo tratta dei test del software hardware-in-the-loop (HIL) applicati ai sistemi di sicurezza elettronici programmabili (PESS) utilizzati negli ascensori per passeggeri. Lo sviluppo di PESS con applicazione in ascensori e scale mobili è iniziato nei primi anni 2000. I limitatori di velocità elettronici, il rilevamento del movimento incontrollato della cabina e due cabine dell'ascensore in un vano sono esempi di applicazioni in cui i PESS sono già in uso o possono essere utilizzati in soluzioni commerciali. Sebbene non sostituiranno i sistemi di sicurezza meccanica esistenti nel prossimo futuro, possono migliorare la sicurezza dei passeggeri e portare a una riduzione dei costi.

Chiamati anche "sistemi di sicurezza integrati", i PESS hanno due parti principali: hardware e software. Questi non sono separabili e sono ugualmente importanti. L'hardware deve essere sviluppato per soddisfare il Safety Integrity Level (SIL) richiesto. In questo senso, viene calcolata la probabilità del loop di sicurezza di guasti all'ora dovuti a guasti hardware casuali e viene valutato il livello SIL.

Poiché anche i circuiti di sicurezza integrati si basano sul software, discuteremo principalmente dello sviluppo software sistematico, concentrandoci sui test del software HIL. Uno degli obiettivi principali del software è ridurre i guasti sistematici utilizzando un ciclo di sviluppo del software adeguato. I guasti del software appartengono alla categoria dei guasti sistematici, sebbene possano apparire casuali.

Il circuito di sicurezza può avere molte applicazioni nel settore utilizzando solo pochi semplici componenti hardware, come un termistore, un relè o un interruttore di finecorsa. Tuttavia, ci sono applicazioni che non possono essere disattivate immediatamente in caso di emergenza, che richiedono un circuito di sicurezza intelligente. Tali circuiti di sicurezza possono essere realizzati utilizzando hardware/software integrato e devono essere sviluppati secondo gli standard di sicurezza rilevanti del settore come IEC 61508.

La struttura di un semplice loop di sicurezza integrato è mostrata nella Figura 1. Ha tre componenti principali: sensore, sistema di sicurezza integrato e attuatore. Quando viene attivata la funzione di sicurezza, l'apparecchiatura viene commutata in uno stato sicuro o spenta. Potrebbe essere necessaria un'architettura a doppio canale del circuito di sicurezza per ottenere un SIL più elevato.

In molte applicazioni industriali si desidera un circuito di sicurezza intelligente in grado di distinguere tra gravità dei guasti e livelli di emergenza.^[1] Per esempio:

• Se si verifica un errore minore, viene emesso un avviso e il processo può ancora essere eseguito per un periodo di tempo limitato.^[2]
• Se si verifica un errore grave, viene emesso un avviso e il processo passa a una modalità sicura e viene eseguito per un periodo di tempo limitato.^{[3 e 4]}
• Se viene attivata la funzione di sicurezza o viene premuto il pulsante di emergenza, il processo passa a uno stato sicuro o viene immediatamente disattivato.^{[5 e 6]}

Tali sistemi di sicurezza intelligenti possono essere realizzati utilizzando software embedded. Pertanto, il corretto funzionamento dei sistemi di sicurezza dipende dal corretto funzionamento (senza errori) del software.

Nella maggior parte dei casi, il processo di sviluppo del software segue un cosiddetto "modello a V" (Figura 2). Ad ogni fase di progettazione corrisponde una fase di verifica (test).

Collaudo

Oggi il software è presente in tutti i principali settori industriali e svolge un ruolo importante nella nostra vita quotidiana. In alcune applicazioni, il software non è critico per la sicurezza, quindi il suo guasto non metterà in pericolo la vita. Nelle applicazioni in cui il software è critico per la sicurezza, deve essere sviluppato secondo gli standard del settore. Nonostante sia stato ampiamente testato, il fallimento è ancora possibile. Pertanto, i test svolgono un ruolo importante nello sviluppo del software. Il rilevamento precoce degli errori del software può far risparmiare sui costi e ridurre significativamente i tempi di sviluppo.

Poiché lo sviluppo del software è solitamente un processo iterativo (i requisiti possono cambiare o potrebbero essere definiti nuovi requisiti), si consiglia vivamente di applicare l'automazione dei test. Per ogni nuova versione del software devono essere rieseguiti i test precedenti (test di regressione) per assicurarsi che le nuove modifiche non abbiano introdotto errori. L'automazione dei test presenta diversi vantaggi, come ad esempio:

• È possibile completare più test in meno tempo.
• Molti casi di test possono essere eseguiti senza l'intervento umano.
• I casi di test sono preziosi; una volta creati, possono essere riutilizzati.

I metodi di test del software sono raggruppati in diverse categorie in base a criteri diversi. I metodi di test, a seconda che il software in prova venga eseguito o meno, possono essere suddivisi in due categorie: statici e dinamici.

Test statici

Il test statico è un metodo con cui viene ispezionato il codice del software, ma il codice non viene eseguito. Si tratta principalmente di un controllo della sintassi del codice e/o di una revisione manuale del codice o del documento per trovare errori.^[7]

Le revisioni del codice, l'ispezione del codice e la procedura dettagliata rientrano nella categoria dei test statici. Le ispezioni formali del codice sono probabilmente lo strumento più importante per ridurre rapidamente i bug del software. L'ispezione del codice si basa sull'espressione "due teste sono meglio di una". Per esempio:

• IBM ha riscontrato che l'ispezione ha fornito un aumento del 23% della produttività e una riduzione del 38% dei bug rilevati dopo il test dell'unità.^[7]
• Hewlett-Packard ha scoperto che era improbabile che l'80% degli errori rilevati durante l'ispezione venisse rilevato dai test.^[7]

Sebbene l'ispezione del codice possa richiedere fino al 20% in più, il debug può ridursi di un ordine di grandezza. Non c'è modo migliore per trovare i bug che attraverso le ispezioni del codice.^[7]

Test dinamici

Il test dinamico è un metodo di test del software mediante il quale il software sottoposto a test viene rispettato ed eseguito. Il termine si riferisce al lavoro con il software: fornire valori di input e verificare se l'output è come previsto. Test unitari, test di integrazione, test di sistema e test di accettazione sono alcune delle sue metodologie. Inoltre, a seconda che la struttura interna del codice software sia accessibile, le metodologie di test sono suddivise in test black-box e white-box.

Test della scatola nera

Il test della scatola nera è un metodo di test del software che non richiede una conoscenza specifica della struttura interna del codice del software. I casi di test sono derivati ​​in base a requisiti e specifiche definiti. Questi test possono essere eseguiti a tutti i livelli di test del software: unità, integrazione, sistema e accettazione. Nella maggior parte dei casi, si tratta di un test funzionale, quindi viene utilizzato principalmente a livelli di test più elevati, sebbene venga eseguito anche a livello di test di unità.

Test White-Box

Il test white-box è un metodo di test del software che richiede l'accesso e la conoscenza della struttura interna del codice del software. Il codice è strumentato e il tester del software sceglie gli input per esercitare i percorsi attraverso il codice e determina l'output corretto. Nella maggior parte dei casi, ciò avviene a livello di unità, ma è possibile eseguirlo anche a livello di integrazione e di sistema. È un metodo molto efficace per rilevare errori software, ma potrebbe non rilevare requisiti mancanti o parti non implementate delle specifiche.

Panoramica dei test

Il test del software è un processo lungo e costoso. Allo scopo di rendere efficaci i test del software, devono essere definite strategie di test e devono essere utilizzate per derivare casi di test (suite). Inoltre, le metriche di test del software (come la copertura del codice) devono essere utilizzate per analizzare l'adeguatezza delle suite di test definite. Il modello di copertura del codice definisce le parti di un'implementazione che devono essere eseguite durante i test. La copertura è una metrica (normalmente espressa in percentuale), definita come rapporto tra le parti di codice eseguite e le parti definite da eseguire, secondo il modello di copertura. Per derivare la copertura del test, il codice deve essere strumentato: richiederà l'accesso alla struttura interna del codice software.

Se rappresentiamo il software come un grafico orientato (Figura 3), possiamo mostrare che è meglio testare due percorsi software 50 volte ciascuno piuttosto che testare un solo percorso 100 volte. Se pensiamo al software embedded in tempo reale, come quello che gira in ascensori e scale mobili, possiamo osservare che la maggior parte dei test dell'unità e del software di integrazione non avviene in tempo reale.

I test del software in tempo reale vengono solitamente eseguiti a livello di test del sistema in una fase avanzata dello sviluppo, ad esempio nella torre di test dell'ascensore. Sarebbe auspicabile eseguire e ripetere tali test in una fase precedente per ridurre i tempi di sviluppo e aumentare la qualità del software. Pertanto, ci concentreremo sui test del software HIL.

Test del software HIL

L'idea di base di HIL è sostituire il sistema reale con un modello di impianto in tempo reale (Figura 4), che è in esecuzione sull'hardware in tempo reale. In altre parole, il nostro ascensore nella torre di prova viene sostituito da un modello di ascensore in tempo reale in esecuzione sull'hardware. Il sistema embedded in prova (che, nel nostro caso particolare, è il loop di sicurezza integrato), collegato all'HIL può essere testato allo stesso modo della torre di test reale. Pertanto, i test eseguiti utilizzando HIL dovrebbero essere molto simili ai test eseguiti nel sistema reale.^{[8 e 9]}

Ovviamente, i test eseguiti nell'HIL non possono sostituire

i test eseguiti nella torre di test, ma possono consentire una facile esecuzione e ripetizione di test simili in una fase precedente di sviluppo. I test HIL si collocano a metà tra integrazione e test di sistema e appartengono alla categoria dei test funzionali/black-box testing.

Poiché i modelli di copertura del codice sono principalmente definiti nei metodi di test white-box, nel caso di HIL, tale modello di copertura non è disponibile. Nonostante ciò, sarebbe molto utile definire anche un modello di copertura del test nei test HIL. Pertanto, introduciamo la metrica di test del software HIL tramite un esempio, considerando il sistema di sicurezza di un ascensore mostrato in Figura 5. L'ascensore è azionato da un motore e se viene superato il limite di velocità eccessiva (linea tratteggiata in Figura 5), ​​il la funzione di sicurezza viene attivata: il motore viene spento, i relè di sicurezza aprono la linea di sicurezza e i freni vengono rilasciati. La velocità durante il normale funzionamento per diversi valori di posizione è contrassegnata dalla linea continua. Il limite di velocità eccessiva è definito per diversi valori di posizione, quindi il nostro circuito di sicurezza integrato assomiglia fondamentalmente a un limitatore di velocità e a un rallentamento del terminale uniforme.

Una possibile struttura dell'anello di sicurezza integrato è mostrata nella Figura 6, dove le informazioni su velocità e posizione sono fornite da un encoder a doppio canale. Una struttura hardware simile^[4] e timer di sicurezza^[2] sono annotati per riferimento.

Le informazioni sulla velocità sono rappresentate su 2 byte e le informazioni sulla posizione sono su 4 byte e inviate al sistema di sicurezza integrato utilizzando il protocollo di comunicazione di sicurezza CANopen. Due interruttori di prossimità, indicati con finecorsa 1 e finecorsa 2, che forniscono informazioni sulle due posizioni estreme, sono cablati al sistema di sicurezza integrato. Il sistema di sicurezza integrato contiene due relè di sicurezza, che aprono la linea di sicurezza se viene attivata la funzione di sicurezza o viene rilevato un errore nel circuito di sicurezza.

Il diagramma di transizione di stato, con gli stati principali del circuito di sicurezza, è mostrato nella Figura 7. Per semplicità, il circuito di sicurezza presentato qui è completamente indipendente dal sistema di controllo dell'ascensore/scala mobile. Ciò significa che non è un circuito di sicurezza intelligente: anche un piccolo guasto interno attiverà un arresto di emergenza, che potrebbe non essere desiderato nella pratica.

Il diagramma di transizione di stato presentato nella Figura 7 ci consente di rappresentarlo come un grafico orientato (Figura 8). Questo ci consentirà di introdurre una metrica di test del software (copertura del percorso di transizione di stato) anche in caso di test HIL. Se si esercitano tutti i percorsi (Figura 8, in basso) considerando l'insieme degli eventi/errori, si può affermare che i test HIL raggiungono il 100% di copertura dei test. Il grafo orientato è molto semplice, avendo solo due percorsi. Tuttavia, nel caso di un circuito di sicurezza intelligente, diventerà più complicato e la metrica di test introdotta per i test HIL avrà senso. Nei test funzionali (HIL rientra in questa categoria), il diagramma di transizione di stato è noto, sebbene il codice del software non sia accessibile.

Configurazione sperimentale HIL

Un ambiente di test HIL semplice ed economico è stato costruito attorno all'hardware Compact RIO™ di National Instruments (Figura 9). Un modello di ascensore semplificato è implementato in tempo reale sull'hardware. L'utente interagisce con l'HIL tramite un'interfaccia utente grafica che viene eseguita su un personal computer.

Alcuni dei principali requisiti imposti all'ambiente di test HIL sono:

• Riprodurre le normali condizioni di funzionamento dell'ascensore
• Creare condizioni di velocità eccessiva
• Iniettare diversi errori (Figura 10) nel circuito di sicurezza

Automatizza i test

I seguenti errori iniettati dovrebbero essere considerati durante il test del circuito di sicurezza. I guasti interni del circuito di sicurezza integrato, come il guasto del watchdog-timer, la deriva della frequenza dell'unità di elaborazione centrale e il guasto del timer di sicurezza, possono essere iniettati tramite HIL solo se l'hardware del circuito di sicurezza consente l'accesso a questi dispositivi. Gli errori di memoria possono essere iniettati solo se è possibile modificare il software dell'anello di sicurezza; pertanto, questo non è considerato un tipico test HIL.

Alcuni risultati sperimentali sono mostrati nelle Figure 11 e 12. In quest'ultimo, la condizione di sovravelocità viene rilevata dall'anello di sicurezza e viene generato un arresto di emergenza (segnale di attivazione del freno a sinistra).

Conclusione

HIL è un ambiente di test di sistemi embedded efficace in generale, per i circuiti di sicurezza embedded in particolare. È ampiamente utilizzato in diversi settori industriali, l'industria automobilistica è uno dei primi in questo senso. Nel nostro caso – a seconda della complessità e dell'accuratezza del modello in tempo reale – può essere realizzato un cosiddetto “ascensore virtuale in un pozzo virtuale”.

Il circuito di sicurezza integrato presentato, tramite parametrizzazione del software, può essere applicato a un'ampia gamma di ascensori, con diverse velocità nominali e diverse lunghezze di corsa. L'ambiente di test HIL è uno strumento molto efficace per testare un circuito di sicurezza di questo tipo per i seguenti motivi:

• L'intera gamma di applicazioni può essere testata efficacemente.
• Diversi difetti possono essere iniettati facilmente e in modo più efficiente.
• Gli scenari di test, che sono difficili da realizzare nella torre di test, possono essere facilmente realizzati in HIL.
• I test possono essere ripetuti facilmente.
• I problemi di progettazione e gli errori del software possono essere rilevati in una fase iniziale e la qualità del software può essere migliorata.
• Il tempo di convalida del software si riduce, il che significa minori costi di sviluppo e minori costi per l'innovazione.

Referenze
[1] R. Isermann: “Sistemi meccatronici - Prodotti innovativi con controllo integrato.” Control Engineering Practice 16, p. 14-29, Elsevier (2008).
[2] L. Al-Sharif, K. Seaborne e D. Austin: "Sistemi di frenatura per scale mobili intelligenti a base elettrica". Atti Elevcon 2010, A. Lustig (Ed.) p. 1-15 (2010).
[3] A. Chida, T. Matsuoka, K. Okamoto e T. Kugiya: "Sviluppo di un sistema di sicurezza elettronico per ascensori". Atti Elevcon 2006, A. Lustig (Ed.) p. 1-9 (2006).
[4] R. Kondo, H. Kigawa, T. Ueda, M. Shibata, J. Hashimoto, A. Chida e H. Marumo: "Sviluppo del sistema di controllo dei freni per ascensori". Atti Elevcon 2010, A. Lustig (Ed.) p. 194-203 (2010).
[5] M. Erndl: "Uso di sistemi elettronici per componenti di sicurezza negli ascensori". Atti di Elevcon, A. Lustig (Ed.) p. 68-78 (2008).
[6] H. Koenig: "Funzionamento sicuro di un azionamento per ascensori senza contattori motore". Atti Elevcon 2010, A. Lustig (Ed.) p. 186-193 (2010).
[7] J. Ganssle: L'arte di progettare sistemi embedded -- 2a ed. Elsevier Inc. (2008).
[8] M. Schlager, R. Obermaisser e W. Elmenreich: "Un framework per test hardware-in-the-loop di un'architettura integrata, in tecnologie software per sistemi embedded e ubiquitari." Appunti delle lezioni di informatica, Springer, vol. 4761, pag. 159-170 (2007).
[9] A. Forrai: Progettazione di sistemi di controllo embedded - Un approccio basato su modelli. Springer Verlag (2012).