ITUB20154590A1

ITUB20154590A1 - Procedimento di esecuzione di programmi in un sistema elettronico per applicazioni in sicurezza funzionale comprendente una pluralita' di processori, relativo sistema e prodotto informatico

Info

Publication number: ITUB20154590A1
Application number: ITUB2015A004590A
Authority: IT
Inventors: Riccardo Mariani
Original assignee: Yogitech S P A
Priority date: 2015-10-13
Filing date: 2015-10-13
Publication date: 2017-04-13
Also published as: US20180349259A1; WO2017064623A1; DE112016004678T5; US10761916B2

Description

"Procedimento di esecuzione di programmi in un sistema elettronico per applicazioni in sicurezza funzionale comprendente una pluralità di processori, relativo sistema e prodotto informatico"

TESTO DELLA DESCRIZIONE

Campo tecnico

La presente descrizione si riferisce a tecniche di esecuzione di programmi nel contesto di sistemi elettronici per applicazioni in cui è richiesta la sicurezza funzionale (functional safety). Il sistema elettronico descritto si basa su una architettura comprendente un singolo processore o una pluralità di processori (CPU).Le tecniche descritte prevedono di

operare una scomposizione del programma da eseguire tramite detta architettura in una pluralità di sottoprogrammi paralleli;

assegnare ciascun sotto-programma parallelo per 1'esecuzione ad un rispettivo modulo di elaborazione del sistema, in particolare un processore fisico o macchina virtuale associata ad uno di detti processori,

eseguire, periodicamente secondo una frequenza di ciclo del programma durante il normale funzionamento di detta architettura, operazioni di auto verifica atte a soddisfare gli obiettivi di sicurezza funzionale.

Varie forme di attuazione possono essere applicate alla sicurezza funzionale . In particolare varie forme di attuazione hanno applicazione in sistemi elettronici nel campo della robotica industriale e dei controlli industriali , e nel campo tecnico dei sistemi elettronici per applicazioni automobilistiche di assistenza al conducente e guida parzialmente o completamente automatica.

Sfondo tecnologico

Le normative di sicurezza funzionale come la IEC 61508, la ISO 13849 e la ISO 26262 contengono reguisiti per la rilevazione di guasti potenzialmente pericolosi in sistemi elettronici integrati . Ad esempio, nella normativa ISO 26262, uno dei reguisiti è definito come la metrica di probabilità di guasti casuali (Probabilistic Metr ic for HW random failures o PMHF), che in prima approssimazione è definito per un dato modello di fallimento F come il prodotto tra la probabilità di guasto di base (λ), la distribuzione di tale probabilità su tale modello di fallimento (AF) , il complemento a uno della frazione di guasti che sono sicuri (1—s) ed il complemento a uno della copertura diagnostica dei guasti che non sono sicuri (1—k).

Per guasti sicuri si intendono guasti che comportano che la missione del programma eseguito sul dispositivo elettronico non venga influenzata oppure venga influenzata in modo sicuro, ossia la missione termina con uno stato noto senza pericolo per la sicurezza funzionale (detto "safe state") .

I processori di un sistema di elaborazione a singolo processore o multiprocessore sono tra gli elementi più critici di tali sistemi elettronici integrati e la loro complessità cresce con 1'avanzare dello stato dell'arte.

Rispetto ai processori, tali normative (ad esempio la ISO 26262-5 Annex D Tabella D.4) riportano varie tecniche possibili al fine di ottenere dei valori di copertura diagnostici dei guasti che non sono sicuri, indicati con k, che siano il più alti possibile.

Tali tecniche hanno trovato diverse realizzazioni nello stato dell'arte.

Architetture come ad esempio guelle descritte nel brevetto US 6 233 702 o nel brevetto US 7 472 051 richiedono obbligatoriamente una modifica dello hardware del processore al fine di garantire la sicurezza funzionale per realizzare una forma completa o ridotta di ridondanza del processore.

Architetture come ad esempio guelle descritte nel brevetto US 5513319 prevedono che un elemento indipendente (watchdog) sia sollecitato periodicamente dal processore ad intervalli di tempo prefissati . Tuttavia la sicurezza funzionale che possono garantire è limitata in guanto solo una ridotta percentuale dei guasti del processore può essere rilevata con un tale metodo - essenzialmente quelli che causano una differenza sostanziale nel flusso di programma.

Scopo e sintesi

Le forme di attuazione gui descritte hanno lo scopo di migliorare le potenzialità dei procedimenti secondo la tecnica nota come discussi in precedenza, in particolare rendere possibile il raggiungimento di un'alta copertura diagnostica su architetture complesse come i moderni multiprocessori, limitando altresì 1'obiettivo di copertura per il singolo processore e limitando o rimuovendo la necessità di modifiche dello hardware.

Varie forme di attuazione raggiungono tale scopo grazie ad un procedimento avente le caratteristiche richiamate nelle rivendicazioni che seguono. Varie forme di attuazione possono riferirsi anche a un architettura così come possono riferirsi ad un prodotto informatico, caricabile nella memoria di almeno un computer (ad es. un terminale in una rete) e comprendente porzioni di codice software adattate per eseguire i passi del procedimento nel momento in cui il programma viene eseguito su almeno un computer. Come gui utilizzato, tale prodotto informatico è inteso essere equivalente ad un mezzo leggibile da computer contenente istruzioni per controllare il sistema informatico in modo da coordinare 1'esecuzione del procedimento secondo 1'invenzione . Il riferimento ad "almeno un computer" è inteso sottolineare la possibilità per la presente invenzione di essere implementata in una forma modulare e/o distribuita. Le rivendicazioni formano una parte integrale degli insegnamenti tecnici gui somministrati in relazione all'invenzione.

Varie forme di attuazione possono prevedere che il procedimento comprenda operazioni di auto verifica che includono

operazioni di auto verifica diagnostica, ossia che eseguono test sul processore e confrontano il risultato con valori precalcolati durante la fase di progetto,

operazioni di auto verifica di valori di sistema misurati sull'architettura (a puro titolo di esempio, la tensione e la temperatura) e confrontano il risultato con degli intervalli attesi di riferimento, operazioni di autoverifica applicativo comprendenti operazioni di auto verifica comprendenti 1'esecuzione periodica nella pluralità di programmi paralleli di cosi dette "condizioni d'uso" (ossia operazioni dedicate ad esempio di controllo di flusso e/o di incapsulamento dei dati con codici di protezione e/o ripetizione di specifici porzioni di sotto-programmi) e/o 1 'esecuzione periodica di circuiterie di Logic Built-in Self-Test (LBIST), e dette operazioni di auto verifica comprendono di generare rispettivi dati di auto verifica relativi alle operazioni di auto verifica e di eseguire operazioni di controllo su detti dati di auto verifica,

scambiare detti dati di auto verifica in continua tramite un protocollo di messaggi con un ulteriore modulo di controllo indipendente,

eseguire almeno parte dette operazioni di controllo in detto ulteriore modulo di controllo indipendente, eseguire detta operazione di scomposizione del programma in una pluralità di sotto-programmi paralleli in modo da rispettare un obiettivo di probabilità di guasto che è funzione di un valore di copertura determinato da dette operazioni di auto verifica diagnostica, di un valore di copertura determinato delle operazioni di auto verifica di valori di sistema misurati sull'architettura, di un valore di copertura determinato dalle operazioni di autoverifica applicativa.

La descritta procedura di scomposizione dei programmi ed il partizionamento delle operazioni di autoverifica nelle dette tre separate operazioni (autoverifica tramite test diagnostici, autoverifica tramite monitoraggio dei valori di sistema e autoverifica applicativo) permette il miglioramento rispetto alla tecnica nota. In particolare: la tripartizione permette di distribuire gli obiettivi in modo ottimizzato, ossia abbassando 1'obiettivo per le operazioni che - per il particolare tipo di sistema al quale il metodo descritto viene applicato richiederebbero un elevato sforzo di progettazione o modifiche dello hardware per essere raggiunte ed invece alzandole per quelle operazioni che in tale contesto risultano più agevoli;

la possibilità di operare 1' autoverifica dei programmi nel tempo obiettivo con 1'esecuzione di condizioni d'uso e/o LBIST permette, nel caso di sistemi con in cui le risorse computazionali sono già in gran parte utilizzate, di ottenere lo stesso risultato di copertura senza penalizzare ulteriormente le prestazioni computazionali del sistema.

Breve descrizione delle figure

Varie forme di attuazione saranno ora descritte, a puro titolo di esempio, con riferimento alle figure annesse, in cui:

- la Figura 1 mostra uno schema a blocchi di una forma realizzativa di un architettura multiprocessore di un sistema elettronico configurata per implementare il procedimento qui descritto;

- la Figura 2 mostra un diagramma rappresentativo di una funzione in sicurezza impiegata dal procedimento qui descritto;

- la Figura 3 mostra uno schema di livelli software dell'architettura multiprocessore configurata per implementare il procedimento qui descritto;

la Figura 4 e la Figura 5 mostrano diagrammi rappresentativi di pacchetti impiegati da un protocollo di comunicazione implementato dall'architettura multiprocessore;

- la Figura 6 mostra uno schema a blocchi di un modulo di controllo che coopera con 1'architettura multiprocessore per implementare il procedimento qui descritto;

- la Figura 7 mostra schematicamente un programma di test eseguita dall'architettura multiprocessore qui descritta;

- la figura 8 mostra uno schema logico rappresentativo di un esempio di implementazione logica di un'operazione di scomposizione del procedimento qui descritto;

- la figura 9 mostra uno schema di principio di un implementazione del sistema su System On Chip, con multiprocessore simmetrico a due core;

- la figura 10 mostra uno schema di principio di un implementazione del sistema su due componenti, un System On Chip e un dispositivo esterno;

la figura 11 mostra un diagramma schematico illustrativo del funzionamento di operazioni di autoverifica secondo il procedimento qui descritto;

- la figura 12 mostra uno schema logico di modalità di combinazione tra operazioni di autoverifica;

- la figura 13 mostra uno schema logico di impiego di operazioni di autoverifica in diverse configurazioni d'uso;

- la figura 14 mostra una forma realizzativa variante dello schema di livelli software dell'architettura multiprocessore configurata per implementare il procedimento qui descritto:

- la figura 15 mostra una ulteriore forma realizzativa variante dello schema di livelli software dell'architettura multiprocessore configurata per implementare il procedimento qui descritto.

Descrizione dettagliata

Nella descrizione che segue vengono forniti numerosi dettagli specifici al fine di consentire la massima comprensione delle forme di attuazione esemplificative. Le forme di attuazione possono essere messe in pratica con o senza dettagli specifici, oppure con altri procedimenti, componenti, materiali, etc. In altre circostanze, strutture materiali od operazioni ben noti non sono mostrati o descritti in dettaglio per evitare di mettere in ombra aspetti delle forme di attuazione. Il riferimento nel corso di guest a descrizione ad "una forma di attuazione" significa che una particolare peculiarità, struttura o caratteristica descritta in connessione con la forma di attuazione è compresa in almeno una forma di attuazione. Dungue, il ricorrere della frase "in una forma di attuazione" in vari punti nel corso di guesta descrizione non è necessariamente riferito alla stessa forma di attuazione. Inoltre, le particolari peculiarità, strutture o caratteristiche possono essere combinate in un gualungue modo conveniente in una o più forme di attuazione.

Le intestazioni ed i riferimenti sono gui forniti solo per convenienza del lettore e non definiscono la portata od il significato delle forme di attuazione.

La Figura 1 illustra un'architettura di elaborazione con sicurezza funzionale di un sistema elettronico integrato per applicazioni in sicurezza funzionale. Tale sistema elettronico può essere, come detto, ad esempio sistemi elettronici per applicazioni automobilistiche di assistenza al conducente e guida parzialmente o completamente automatica, che comprende un architettura di elaborazione che opera in sicurezza funzionale.

Tale architettura comprende un sistema di elaborazione a multiprocessore . Su tale sistema di elaborazione a multiprocessore, indicato complessivamente con il riferimento 10, è cioè implementato un sistema di sicurezza funzionale basato sulla realizzazione di più canali di elaborazione e controllo. Per canale, nel contesto della sicurezza e in particolare dell'IEC 61508 si intende un elemento o gruppo di elementi che implementano indipendentemente una funzione, specificamente una funzione SF in sicurezza funzionale, o safety function (si veda IEC 61508-4, 3.3.6). Può essere ad esempio un microprocessore, una virtual machine, o anche altro elemento.

Il sistema di elaborazione a multiprocessore 10 comprende una pluralità di moduli processori 11. Tali moduli processori 11 comprendono principalmente delle CPU (Central Program Unit) indipendenti, ossia dei cosiddetti core. Come dettagliato più avanti, un modulo processore in un sistema multi-core (come anche in un sistema singlecore) può riferirsi nella presente descrizione anche a una macchina virtuale generata da software di virtualizzazione su uno di tali core. Con riferimento alle Figure 1 e 3, per modulo processore 11 si intende gui dungue uno di una pluralità di core CI..Cm del multiprocessore 10 oppure anche una di pluralità di macchine virtuali Vl...Vn implementati su uno o più di tali core Cl...Cm.

Il multiprocessore 10 può essere architetturalmente realizzato in modi diversi che comprendono sia le architetture omogenee (guelle in cui i vari core 11 di elaborazione sono uguali) sia eterogenee (guelle in cui i core 11 di elaborazione sono diversi), architetture a memoria condivisa piuttosto che a memoria distribuita che comunicano mediante scambio di messaggi Dal punto di vista della realizzazione fisica sono possibili molteplici soluzioni che vanno da un maggior grado d'integrazione, dove i core 11 sono realizzati nello stesso circuito integrato, a un minor grado, dove i core 11 del multiprocessore 10 sono realizzati su circuiti integrati diversi o su moduli diversi e separati.

In guest'ambito, nell'esempio di Figura 1 è rappresentata un'architettura che comprende uno solo di tali multiprocessori 10 comprendente a sua volta la pluralità di moduli processori 11. Su tale multiprocessore 10 sono eseguite le funzioni applicative, ossia i programmi P, ad esempio di controllo o di assistenza alla guida in un autoveicolo, e le funzioni di sicurezza funzionale SF finalizzate alla auto verifica dell'integrità del sistema e al rilevamento di possibili guasti o malfunzionamenti che possono verificarsi nella logica e le memorie a stato solido dei multiprocessori 10 stessi o in loro sotto parti.

Oltre al multiprocessore 10, 1'architettura con sicurezza funzionale rappresentata in Figura 1 prevede un'unità di elaborazione indipendente rappresentata dal modulo di controllo 15, che è configurato per analizzare, elaborare e confrontare il contenuto di flussi di messaggi di monitoraggio e controllo MC provenienti dai diversi programmi operanti nel multiprocessore 10 che implementano tali operazioni di auto verifica, eseguite dai processori 11 del multiprocessore 10 al fine di realizzare un monitoraggio della loro sicurezza funzionale e di rilevare possibili malfunzionamenti che possano verificarsi nella logica che li compone, oppure più in generale nel flusso di esecuzione di sottoprocessi ΡΙ.,.Ρη, in cui il programma P viene scomposto per essere eseguito da rispettivi moduli processori 11.

Il multiprocessore 10 e il modulo di controllo 15 comunicano attraverso mezzi di comunicazione 12, che consentono ai diversi moduli processori 11 del multiprocessore 10 di inviare e ricevere tali messaggi di monitoraggio e controllo MC da e verso 1'unità di elaborazione e confronto, ossia il modulo di controllo 15, che può a sua volta rispettivamente ricevere e inviare messaggi, ad esempio allarmi, verso il multiprocessore 10.

Come detto in Figura 1 è rappresentato per semplicità un solo multiprocessore 10, ma in realtà 1'architettura può prevedere più processori o multiprocessori che scambiano i messaggi di monitoraggio e controllo attraverso rispettivi mezzi di comunicazione 12 con il modulo di controllo 15 Il procedimento gui descritto si applica a tutte gueste possibili configurazioni di un multiprocessore 10 sul guai e venga eseguita una funzione in sicurezza funzionale, indicata con SF in Figura 2. Per funzione in sicurezza funzionale si intende una funzione che opera nell'ambito di un sistema per il guaie è richiesto il rispetto dei reguisiti di sicurezza funzionale di cui agli standard precedentemente citati. In tale Figura 2 è infatti indicata una funzione in sicurezza SF che viene eseguita all'interno di un processo software, un programma P, che deve essere eseguito dal multiprocessore 10. In Figura 2 il programma P nel suo complesso, che è un processo che viene eseguito ciclicamente, è rappresentato tramite una corona circolare che indica 1'esecuzione ciclica nel tempo t di esecuzione con un tempo di ciclo Tcyc. La funzione in sicurezza funzionale SF occupa un segmento temporale di tale programma P, ossia un settore di tale corona circolare, la funzione in sicurezza SF essendo in generale una parte del programma P, ed essendo guindi eseguita per un tempo di esecuzione in sicurezza T3minore del tempo di ciclo TcyC. In Figura 2 è anche indicato come durante 1'esecuzione della funzione in sicurezza SF, ossia durante il tempo di esecuzione in sicurezza T3, vengono scambiati messaggi di monitoraggio e controllo MC, in particolare con un modulo di controllo indipendente 15.

Come indicato in Figura 1, il procedimento gui descritto prevede di scomporre il programma P in sottoprogrammi ΡΙ.,.Ρη paralleli che vengono, nell'architettura di Figura 1, implementati ciascuna su un core 11. Anche se in Figura 1 è mostrato un multiprocessore, i sottoprogrammi ΡΙ.,.Ρη possono essere suddivisi anche se il sistema di elaborazione provvede un singolo processore, ad esempio tramite tecniche di virtualizzazione . Una soluzione tecnica disponibile nel campo dei sistemi operativi per multiprocessori è la tecnologia di virtualizzazione che consente appunto la virtualizzazione dello hardware sul guaie vengono eseguiti i programmi applicativi su un singolo core, o, come illustrato nel seguito, anche sui core 11 del multiprocessore 10 (si faccia per esempio riferimento ai moduli cosiddetti Hypervisor o virtual machine monitor). Nel paradigma di utilizzo delle tecnologie di virtualizzazione il programma P viene scomposto in una pluralità di processi paralleli ΡΙ.,.Ρη che possano essere eseguiti ciascuno da una macchina virtuale Vl..Vn in modo da ottenere un'esecuzione parallela e funzionalmente eguivalente al programma P di partenza che comprende la funzione in sicurezza SF.

La scomposizione in sotto programmi ΡΙ.,.Ρη da assegnare alle differenti virtual machine o core è guidata nei sistemi noti da considerazioni di tipo funzionale relativo alle funzioni dello specifico programma P. Come viene meglio descritto nel seguito, il procedimento gui descritto prevede invece di operare tale scomposizione in sotto processi ΡΙ.,.Ρη in funzione del rispetto di determinati vincoli di copertura rispetto alla presenza di guasti di tipo random che sono richiesti dalle normative di sicurezza funzionale richiesti nei campi applicativi industriale e automobilistico . Tali vincoli sono guindi indicati in generale come funzioni f(k) di un livello di copertura k richiesto dalla norma.

1/architettura in sicurezza funzionale di Figura 1 è configurata inoltre per eseguire nell'ambito della funzione in sicurezza SF operazioni di verifica, meglio dettagliate in Figura 3 che in generale comprendono

operazioni Astidi auto verifica diagnostica, che eseguono test diagnostici, tramite 1'esecuzione di librerie di autoverifica 50 STL, associate ai processori 11, come indicato in figura 3.

operazioni Asy3di auto verifica di valori di sistema misurati sull' architettura, anch'esse preferibilmente nell'ambito dell'esecuzione delle librerie di autoverifica 50 STL,

operazioni Achkdi verifica applicativo Tali operazioni possono essere operazioni di confronto tra sotto-programmi ΡΙ.,.Ρη, tramite moduli software di confronto applicazioni 60, descritti con riferimento a Figura 3, e nel seguito della descrizione. Tuttavia, come descritto con riferimento in particolare a figura 11 e 14, nel procedimento secondo 1'invenzione, è previsto di operare tale autoverifica a livello applicativo per operazioni di verifica tramite 1'esecuzione periodica di condizioni d'uso Acoue/o 1'esecuzione periodica di test LBIST Abst-In Figura 2 sono a questo proposito indicate le librerie di autoverifica 50 STL (Self Test Library) e i moduli di software di verifica applicativo 60, associati a ciascuno dei core 11 e implementanti ciascuno le tre tipologie di operazioni di autoverifica Asti, Achk, Asy3. Come detto, preferibilmente le librerie di autoverifica 50 STL comprendono software sia per eseguire sia le operazioni di auto verifica diagnostica A3tisia le operazioni Asy3di auto verifica di valori di sistema misurati sull' architettura, ma in forme varianti le operazioni Asy3di auto verifica di valori di sistema possono essere eseguite tramite un modulo software separato e dedicato.

Tali tre tipologie di operazioni di auto verifica A3ti, A3ys, AChkcomprendono di generare al multiprocessore 10 dei dati di auto verifica, ossia rispettivamente dati di autoverifica D3ti, dati di sistema D3y3, dati di auto verifica dell'applicazione Dchk- Come accennato e meglio dettagliato in figura 3, è inoltre previsto di generare tali dati di auto verifica D3ti, D3y3Dchkin moduli software rappresentati dalle librerie di autoverifica diagnostica 50 e dai moduli software di verifica applicazioni 60, e di inviarli nei messaggi di monitoraggio e controllo MC perché vengano eseguite operazioni di controllo su detti dati di auto verifica D3ti, Dchk, tramite moduli rappresentati in Figura 2 come moduli logici 51, 61 compresi nel modulo di controllo 15 .

Sempre in Figura 1 sono mostrati i sistemi di comunicazione 12 utilizzati per lo scambio dei messaggi di monitoraggio e di controllo MC fra i moduli processori componenti il multiprocessore 10 e il modulo di controllo 15 . Tali canali di comunicazione possono essere composti di segmenti di tipo punto-punto, oppure costruiti in modo gerarchico e possibilmente con accesso multiplo a un supporto fisico condiviso, quale, nell'esempio mostrato, un bus di comunicazione . La determinazione del contenuto dei messaggi di monitoraggio e controllo MC da scambiare avviene tramite 1'esecuzione delle operazioni di auto verifica A3ti, A3y3, Ach3⁄4oltre che altre operazioni dettagliate nel seguito, e 1'invio dei messaggi di monitoraggio e controllo MC stessi avviene durante intervalli di tempo regolari in cui i moduli processore 11 componenti il multiprocessore 10 vengono distolti dall' esecuzione dei rispettivi programmi applicativi ΡΙ.,.Ρη, ottenuti dalla scomposizione del programma P, cui sono normalmente dedicati per la maggior parte del tempo e vengono dedicati all'esecuzione di codice speciale , ossia il codice dei programmi delle librerie di autoverifica 50 STL . In particolare, i messaggi di monitoraggio e controllo MC vengono generati a diversi livelli gerarchici , ossia layer , dell'organizzazione del software in esecuzione nel multiprocessore 10, come meglio dettagliato nel seguito. Lo scambio di messaggi di monitoraggio e controllo MC fra il sistema multiprocessore 10 e il modulo di controllo 15 avviene secondo un protocollo di comunicazione PL anch'esso meglio dettagliato nel seguito.

Secondo un aspetto principale del procedimento qui descritto, è previsto di eseguire 1'operazione di scomposizione del programma P in una pluralità di sottoprogrammi paralleli ΡΙ.,.Ρη in modo da rispettare un obiettivo di probabilità di guasto, indicato con g per il caso generale e con gl2 nell'esempio a due processori sotto riportato, che è funzione per ciascun sottoprogramma ΡΙ.,.Ρη di un rispettivo valore di copertura k3tideterminato da dette operazioni di verifica autodiagnostica A3ti, di un rispettivo valore di copertura ksysdeterminato delle operazioni di autoverifica A3y3di valori misurati sull' architettura multiprocessore 10, di un valore di copertura kchkdeterminato dalle operazioni Achkdi verifica applicazione .

La copertura in termini di Diagnostic Coverage (DC) o di Safe Failure Fraction (SFF - ci si riferisca in proposito alla normativa di sicurezza IEC615G8) di ogni componente 1'architettura di sicurezza in Figura 1 - in particolare per la parte di programma software delle operazioni di autoverifica diagnostica A3ti(librerie di autoverifica 50 STL), viene determinata in funzione delle seguenti caratteristiche del sistema:

- livello di integrità o livello di SIL (Safety Integrity Level ) obiettivo da raggiungere per il sistema, in particolare a due canali . Questo si traduce in un reguisito di copertura k che deve essere rispettato dal sistema;

frequenza del ciclo base fcycdelle operazioni e intervallo di test diagnostico, o DTI (Diagnostic Test Interval ). A questo riguardo, come mostrato in figura 2, il programma P nel suo complesso viene eseguito ciclicamente con un tempo di ciclo Tcyce quindi frequenza del ciclo base f La funzione in sicurezza SF occupa un segmento temporale di tale programma P per un tempo di esecuzione in sicurezza Ts minore del tempo di ciclo Tcyc.

- numero e tipo dei controlli effettuati , in particolare nell'architettura considerata, dal modulo di controllo 15 sui risultati delle operazioni di autoverifica A3tinell'unità di tempo. Il tempo di esecuzione in sicurezza T3è una funzione del vincolo di copertura f(k) richiesto dalla normativa di sicurezza.

Inoltre, come anche dettagliato nel seguito, 1'operazione di scambio di dati è eseguita con una seguenza di messaggi in cui una guantità di dati g ed una frequenza f sono scelti secondo un ulteriore funzione di detto obiettivo di probabilità di guasto g da rispettare.

Come passo addizionale può essere previsto di verificare che i valori obiettivo di copertura k determinati in funzione di detto obiettivo di probabilità di guasto g siano stati effettivamente raggiunti tramite iniezione di guasti in simulazione, ad esempio secondo guanto descritto nel brevetto EP 1980 964 Al a nome della Richiedente.

Viene ora descritta in dettaglio 1'operazione di scomposizione del programma P in una pluralità di sottoprogrammi paralleli ΡΙ.,.Ρη secondo una funzione di un obiettivo di probabilità di guasto g da rispettare.

Al fine di ottenere la minore probabilità di guasto g senza modifiche hardware e con il minimo impatto sul programma P, inteso sia come dimensione della memoria programma che come tempo di esecuzione, il procedimento descritto prevede infatti la scomposizione del programma P in due o più programmi indipendenti PI, P2...Pn.

L'architettura con sicurezza funzionale descritta è impostata in funzione di un obiettivo di probabilità di guasto g e guindi in funzioni di valori di copertura k da ottenere. Esempi specifici si riferiscono nel seguito sostanzialmente a un sistema a due canali, ovvero dove il programma P è scomposto in due processi PI e P2 operanti su due core C1...C2 o due virtual machine V1...V2 che forniscono due canali di risultati.

Prendendo dunque ad esempio il caso di una scomposizione in due programmi PI, P2 ed assumendo per semplicità che i due programmi indipendenti PI, P2 vengano eseguiti in due moduli processori identici 11 con la stessa probabilità di guasto di base λ uguale ad 1 e con la stessa distribuzione di modelli di guasto Λ uguale ad 1, la probabilità di guasto del sistema multi processore composto dai processori 1 e 2 può essere descritta come:

gl2< {1-β)<2>*{1-si)*{1-kl)*(1-s2)*{1-k2)*texp+β*{1-sl2)*{l-kl2) (1)

dove kl, k2 indicano la copertura ai guasti rispettivamente per i due processori , siano ad esempio Gl e C2, che eseguono i due programmi PI e P2, si, s2 indicano la frazione dei guasti sicuri dei due processori CI , C2 che eseguono i due programmi PI e P2, β è la frazione dei guasti che possono causare un guasto di modo comune tra i due processori CI, C2, kl2 è la copertura ai guasti che può causare un guasto di modo comune tra i due processori CI, C2, s12 la frazione dei guasti sicuri a comune tra i due processori CI , C2 e texp il tempo di esposizione del primo guasto . Il tempo texp è definito dalla tipologia di utilizzo del sistema e dal tipo di modello di guasto, e al limite può essere pari al tempo di vita del sistema. Dato un sotto -programma Pi , avendo assunto la probabilità di guasto di base λ uguale ad 1 e la distribuzione di modelli di guasto λ uguale ad 1, la coppia di valori si, ki, frazione guasti sicuri del relativo processore e copertura ai guasti, ne identifica sostanzialmente la probabilità di guasto .

La relazione (1) definita in precedenza per 1'obiettivo di probabilità di guasto gl2 dei due sottoprogrammi indipendenti Pi e P2 è determinata tramite l'aritmetica della Fault Tree Analysis (FTA) (si veda ad esempio ISO 26262-10 Annex B), ossia corrisponde (si veda figura 8) a determinare la probabilità di guasto dei due sottoprogrammi Pi e P2 connessi da una funzione logica di tipo AND ed in cui il rispettivo hardware, su cui ciascun programma è eseguito, è collegato ad una probabilità di guasto molto bassa . Quindi , la relazione (1) esprime la probabilità di guasto risultante media , ossia 1'obiettivo di probabilità di guasto, approssimativamente come prodotto delle rispettive probabilità per il tempo di esposizione t.

E' perciò possibile estendere facilmente la relazione (1) per un numero arbitrario di programmi indipendenti : ad esempio, nel caso di tre programmi , l'AND a tre ingressi può essere scomposta in due AND a due ingressi e guindi costruire la formula risultante utilizzando la formula prima descritta per due programmi Pi e P2.

In altre parole il valore di probabilità di guasto dei sotto programmi ΡΙ.,.Ρη rispetto a un obiettivo di probabilità di guasto g da rispettare è calcolato considerando i sottoprogrammi ΡΙ.,.Ρη come ingressi di una porta AND avente tanti ingressi guanti i sottoprogrammi , scomponendo tale porta AND in porte AND a due ingressi e calcolando 1' obiettivo di probabilità in funzione del prodotto delle probabilità di guasto all'uscita di ciascuna porta AND a due ingressi e del tempo di esecuzione Sempre tramite 1'aritmetica delle FTA, la probabilità di guasto gl2 è completata da una somma (ossia una funzione logica di tipo OR) con un termine di modo comune β*fisi2 )* (1—kl2) che tiene conto dei guasti CCF.

Dunque, il calcolo di detto obiettivo di probabilità di guasto g comprende considerare i sottoprogrammi ΡΙ.,.Ρη come ingressi di una funzione logica AND AG avente tanti ingressi quanti i sottoprogrammi PI....Pn, scomporre tale funzione logica AND (AG) in funzioni logiche AND a due ingressi aventi come ingressi le coppie che si possono comporre fra detti sottoprogrammi ΡΙ.,.Ρη, calcolare il prodotto delle probabilità di guasto, ossia le coppie ki, si, all'uscita di ciascuna porta AND a due ingressi, moltiplicato per il complemento della frazione dei guasti di modo comune β e del tempo di esposizione texp, calcolare detto obiettivo di probabilità g in funzione del risultato dell' operazione precedente sommato a un valore ottenuto applicando funzioni OR a guasti di modo comune, ossia le coppie kij, sij fra tutte le coppie ij di sottoprogrammi Pl...Pn, moltiplicato per la frazione dei guasti di modo comune β.

La figura 8 rappresenta tramite un circuito logico che illustra 1'operazione di calcolo dell'obiettivo probabilità g implementando le funzioni logiche secondo quanto appena discusso . Con AG è indicata la porta AND a n ingressi, scomponibile in porte a due ingressi secondo quanto indicato, che riceve come ingresso per ciascun sottoprogramma Pi la copertura ki e la frazione di guasti sicuri Si (nell'esempio della formula (1) kl, si e k2, s2). L'uscita è moltiplicata per l-β, complemento della frazione dei guasti che possono causare un guasto di modo comune. La porta AND (come previsto nell'aritmetica FTA) prevede il prodotto con il tempo di esposizione . Con OG sono indicate delle porte OR multi ingresso che per due sottoprogrammi Pi e Pj ricevono come ingresso la copertura ai guasti di modo comune Kij e la frazione sij dei guasti sicuri a comune (nell'esempio K12 , s12). L'uscita è moltiplicata per β, frazione dei guasti che possono causare un guasto di modo comune . Una porta OGT esegue poi la somma delle uscite delle porte AG e OG per dare la forma generale , g, dell' obiettivo di guasto gl2 della formula (1).

Una delle caratteristiche distinguenti del procedimento è che le coperture ai guasti kl , k2 e kl2 vengono definite come la combinazione di tre contributi: ksti, ossia la frazione di copertura garantita dall' esecuzione delle operazioni di autoverifica Asti(libreria di autoverifica 50, in particolare in cooperazione con il modulo 51 sul modulo 15);

kchk, ossia la frazione di copertura garantita dalla verifica applicazione sull' esecuzione dei programmi PI e P2 in un tempo obiettivo T - tipicamente calcolato come corrispondente al Process Safety Time (PST) o Fault Tolerant Time Interval (FTTI), ossia operazione di autoverifica Achk(nel componente di confronto 60 , in particolare in cooperazione con il modulo 61 sul modulo di controllo 15 );

ksys, ossia la frazione di copertura garantita dal confronto dei dati di sistema Dsy3, ottenuti dall'operazione di autoverifica A3y3(preferibilmente sempre in cooperazione fra moduli del multiprocessore 10 e del modulo 15) tra parametri di sistema dell'architettura multiprocessore 10 come la temperatura e la tensione elettrica dei processori Gl , C2 su cui vengono eseguiti i programmi PI e P2 e valori di riferimento o valori limite, ossia range Ratt-In particolare si ha, che, per la copertura kl, k2 dei programmi PI e P2 e la copertura di modo comune kl2 si ha che :

kl k3tiikcll3⁄4ksy3, k2 k3ti2kcllkksys, kl2 kstii2CJ kcllkO k3y3, (2)

1/ operatore unione u indica che le due coperture sono combinate secondo le regole dell'insiemistica in funzione della loro singola copertura dei guasti.

1/ obiettivo di copertura delle librerie di autoverifica k3tn associata alla libreria 50 inserita nel programma che viene eseguito nel processore CI, k3ti2 associata alla libreria 50 inserita nel programma che viene eseguito nel processore C2 e k3tn2 associata alla libreria 50 inserita nel programma che viene eseguito nel processore CI e/o processore C2 per coprire i guasti a comune - e guindi la loro struttura e la loro programmazione - è determinata al fine di raggiungere 1'obiettivo della probabilità di guasto gl2 in funzione dei parametri β, t e si, s2 e s12.

In definitiva, dungue il procedimento prevede di provvedere nell' architettura in sicurezza tre diversi tipi di operazioni di autoverifica A3ti, Ach3⁄4, A3y3cui sono associate coperture k3ti, kchk, k3y3e, dato un numero di sottoprogrammi ΡΙ.,.Ρη in cui si scompone il programma P in sicurezza funzionale, per ogni tipo di operazione di autoverifica A3tio Achko A3y3, associare tale operazione di autoverifica A3tio Achko Asyga ciascun sottoprogramma ΡΙ.,.Ρη e/o processore 11 definendo i parametri dell'operazione di autoverifica A3tio Achko A3y3in modo che i valori di copertura k3tio kchko k3y3risultanti rispettino, insieme a quelli derivati dalle altre due tipologie di operazioni di autoverifica secondo quanto espresso nella relazione (1), 1'obiettivo di probabilità di guasto g definito per il sistema .

Secondo un ulteriore aspetto del procedimento qui descritto le menzionate operazioni di

autoverifica Astisecondo le librerie di autoverifica 50 definite con rispettive coperture di autoverifica k3tn, ksti2 e kstii2 per i due processori CI e C2.

verifica Achkdi applicazione dei programmi Pi e P2, con copertura applicativa kChk,'

confronto Asystra dati di verifica di sistema , dei processori Cl, C2 su cui vengono eseguiti i programmi Pi e P2, e range attesi Ratt, che individua la copertura di sistema k3y3

sono eseguite non interamente al multiprocessore 10, ma completate in sequenza tramite un ulteriore elemento indipendente rispetto al multiprocessore 10, il modulo di controllo 15, si occupa di portare a compimento. Ciò avviene tramite uno scambio di dati (i messaggi MC) fra il multiprocessore 10 e il modulo di controllo 15.

La corrispondenza delle coperture k3tn, k3ti2, k3tn2, kchk<e>k3y3rispetto ai valori obiettivo determinati come sopra descritto è verificata tramite iniezioni di guasti in simulazione.

Dunque, il procedimento qui descritto prevede di operare in un contesto di sistemi elettronici con sicurezza funzionale che eseguono un dato programma P, dove la scomposizione in sottoprogrammi del programma P ed il partizionamento delle operazioni di autoverifica in tre separate operazioni, autoverifica A3titramite test diagnostici, autoverifica A3y3tramite monitoraggio dei valori di sistema e autoverifica Achktramite verifica dell'applicazione, secondo una relazione, la relazione (1), che lega 1'obiettivo di guasto alle coperture dei sottoprogrammi, a loro volta definiti in funzione delle coperture ksti, kchk, k3y3delle tre operazioni di autoverifica A3ti, AChk, A3y3, permettono di identificare con precisione gli obiettivi di copertura da assegnare a ciascuna delle tre operazioni di autoverifica, permettendo altresì di distribuire gli obiettivi in modo ottimizzato.

L'architettura descritta con riferimento a figura 1 provvede inoltre di eseguire tali operazioni di autoverifica in cooperazione con un modulo esterno, il modulo di controllo 15, tramite un protocollo di comunicazione PL per scambiare messaggi di monitoraggio e controllo MC . Per modulo esterno si intende gui un modulo esterno ai processori il, anche se tale modulo può essere compreso nel circuito integrato in cui sono realizzati i processori . Il procedimento descritto prevede cioè operazioni di auto verifica che, rispetto a operazioni di auto verifica eseguite nei sistemi noti , che generano e controllano i dati di auto verifica nello stesso sistema di elaborazione singolo o multiprocess ore, prevede di generare i dati di auto verifica al sistema di elaborazione singolo o multiprocess ore , ma di completare 1'operazione di verifica eseguendo il controllo tramite un elemento indipendente separato, il modulo di controllo 15.

Al fine di meglio dettagliare questo e altri aspetti, la Figura 3 rappresenta schematicamente un modello di astrazione di una forma realizzativa della soluzione descritta, attraverso una gerarchia di layer fisici e software , di tipo ISO/OS I, rappresentativa anche del protocollo di comunicazione PL.

Tale protocollo di comunicazione PL è implementato a livelli gerarchici in cui i messaggi a livello applicativo (L4 in figura 3) sono incapsulati nel protocollo PL implementato dal programma P e a più basso livello (livello L2 in figura 3 ) vengono aggiunti i messaggi relativi all' autoverifica 50 STL. Come mostrato in figura 3, il modulo di controllo 15 implementa il protocollo di comunicazione PL in modo speculare rispetto a tali livelli gerarchici . Tale protocollo di PL dispone i messaggi di monitoraggio e controllo MC in una trama gerarchica che consente 1' incapsulamento di differenti pacchetti relativi a differenti identificativi ID di differenti moduli processori 11 e il loro instradamento all'interno del modulo di controllo 15 verso le unità di elaborazione preposte alla loro analisi e confronto, come meglio rappresentato con riferimento alla Figura 6. Nel seguito, con VC si indicano i canali logici che indirizzano un layer specifico di sistema, con 1'identificativo ID si indirizzano i canali fisici riferiti ad un elemento di elaborazione , core fisico Cl...Cm o macchina virtuale Vl...Vm. In particolare nel protocollo PL un messaggio MC, di tipo a pacchetto, comprende i seguenti campi per valori numerici:

campi dedicati alla gerarchizzazione dei messaggi MC in funzione dei canali logici VC di appartenenza;

campi per la sequenza cardinale e temporale dei pacchetti dei messaggi MC

campo di comandi per il modulo di controllo 15 campo di payload contenente il dato rispetto al guaie il modulo di controllo 15 deve completare 1'operazione di auto verifica.

Il modulo di controllo 15 è inoltre configurato per eseguire un controllo d'integrità del contenuto del messaggio MC mediante un algoritmo che consente la rivelazione e/ o la correzione di errori. Preferibilmente si impiega 1'algoritmo CRC32 come algoritmo per la rivelazione di errori (in Figura 7 è implementato nel modulo 112a).

Venendo più in dettaglio alla rappresentazione dei livelli gerarchici fisici e software in Figura 3, con LI è indicato un layer o livello fisico di esecuzione hardware, corrispondente al multiprocessore 10, che comprende una molteplicità di core Cl...Cm e un modulo ingressi/uscite IO. Questo è tipicamente implementato da uno o più circuiti integrati .

Con L2 è indicato un livello supervisore L2, rappresentato da un modulo di gestione delle macchine virtuali 17, un componente software comunemente indicato come Hypervisor , che ha la funzione di virtualizzare lo hardware esistente del livello fisco LI mettendo a disposizione a un livello di virtualizzazione L3 un numero n di macchine virtuali Vl...Vn con relativo sistema operativo tali che possano essere utilizzate come unità indipendenti, le cosiddette guest virtual machine . Il modulo di gestione delle macchine virtuali 17 garantisce che le varie macchine virtuali Vl...Vn e i corrispondenti sottoprogrammi Pl...Pn, in cui si determina di scomporre, ad esempio manualmente , il programma P abbiano determinate caratteristiche necessarie al programma P. Tale operazione di scomposizione può alternativamente anche non essere tutelata, o tutelata tramite modifiche dell' applicazione stessa o meglio del suo sistema operativo . Nel campo applicativo della sicurezza funzionale tali caratteristiche tipicamente includono la garanzia della esecuzione in real-time e della non interferenza della esecuzione di processi diversi . Come accennato, il procedimento gui descritto prevede invece che tali caratteristiche tengano conto solo o anche di un obiettivo di probabilità di guasto g. In generale si indicano un numero n di macchine virtuale pari a guello dei sottoprocessi ΡΙ.,.Ρη in cui viene scomposto il programma P, dove, nell' esempio preferito n=2 . Poiché si possono ottenere più macchine virtuali su uno stesso core, il numero m di core è preferibilmente minore o uguale a n. Il modulo di gestione delle macchine virtuali 17 gui descritto comprende una componente software corrispondente alle librerie di test di autoverifica 50 STL (Self Test Library) , che , come accennato, e introducono un test dell' integrità funzionale di ognuno dei core Cl...Cm, nonché delle periferiche che costituiscono lo hardware ad esso sottostante , ossia il livello fisico LI, in modo da garantire che eventuali guasti di tipo random che dovessero verificarsi in tale hardware sottostante vengano rivelati con una predefinita percentuale di copertura k. Vi può essere una sola libreria 50 nel caso di multiprocessore omogeneo . Le modalità con cui un componente software , gui il componente della libreria 50 STL (o i componenti della libreria 50 nel caso di multiprocessore non-omogeneo) , viene integrato nel modulo di gestione delle macchine virtuali 17 sono di per sé note al tecnico del settore. Il componente della libreria 50 STL può essere facilmente integrato nel modulo di gestione delle macchine virtuali 17 , in guanto i moduli di tale tipo, ad esempio gli Hypervisor , che vengono forniti con i sistemi di virtualizzazione noti, tipicamente presentano all' utente delle interfacce che consentono 1'integrazione di componenti aggiuntivi , pertanto è possibile integrare il componente della libreria 50 STL come componente aggiuntivo, come mostrato in Figura 3.

Un livello applicativo L4 corrisponde al livello dei sottoprogrammi ΡΙ.,.Ρη in cui è scomposto il programma P, implementati sulle macchine virtuali Vl...Vn. A guesto livello applicativo L4 è associato un modulo o componente software, in particolare uno per ogni processo ΡΙ.,.Ρη, di verifica applicazioni 60 , specificamente detto ASL (Application Safety Layer) , che in generale provvede 1'operazione di verifica generante i dati di verifica applicazione Dchkad esempio tramite il confronto fra i risultati intermedi dei canali, o, la verifica del rispetto di condizioni d'uso o la verifica dell'esecuzione dei test LBIST . Più specificamente, come detto nel procedimento qui descritto, il modulo o componente software in particolare uno per ogni processo ΡΙ.,.Ρη, di confronto applicazioni 60 ottiene i dati di verifica applicazione Dchkche vengono poi controllati e confrontati al modulo di controllo 15.

In Figura 3 il modulo di controllo 15 è rappresentato come componente hardware , dettagliato in Figura 6, tuttavia esso può anche essere implementato come software in modo equivalente, con differenze di costo/prestazione del componente risultante . A puro titolo di esempio, il modulo di controllo 15 può essere realizzato come un programma eseguito da un ulteriore processore.

I messaggi di monitoraggi e controllo MC scambiati con il modulo di controllo 15 per completare le operazioni di autoverifica AstiA3y3Achksi dividono in due distinte tipologie :

messaggi contenenti dati che sono indipendenti dalle caratteristiche del programma P eseguito dal microprocessore 10 . Sono questi ad esempio i dati di auto verifica sistema D3y3delle operazioni di auto verifica A3y3dei valori di sistema misurati sull'architettura, che includono misure di tensione e/o temperatura dei core Cl...Cm del multiprocessore 10, nonché dati di auto verifica D3tirelativi a risultati intermedi di calcoli eseguiti in accordo a una delle specifiche procedure di autoverifica diagnostica delle librerie di autoverifica 50;

messaggi che riportano dati relativi alla verifica applicazione , e che sono guindi dipendenti dal programma P 0 applicazione medesimo o dati relativi alla verifica del rispetto delle condizioni d'uso o alla verifica dell' esecuzione dei test LBIST. Sono guesti i dati di verifica applicazione Dchkgenerati da operazioni Achkdi confronto fra i sotto-programmi ΡΙ.,.Ρη, tramite moduli software di confronto applicativo 60.

Il modulo di controllo 15 completa le operazioni di autoverifica Asti, A3y3, Achkiniziate al multiprocessore 10, tramite cooperazione e scambio dei messaggi MC, contenenti 1 corrispondenti dati di verifica D3tie Dchk, con i corrispondenti componenti logici di verifica 51 e componenti logici di confronto applicativo 61 compresi nel modulo di controllo 15. Come mostrato in Figura 6, tale separazione è di tipo logico, tuttavia i componenti 51 e 61 possono essere implementati tramite un medesimo insieme di moduli hardware . Ciò avviene ad esempio come segue:

- il modulo di controllo 15 completa le operazioni di autoverifica diagnostica Astioperando il confronto, nel modulo logico 51 dei dati di autoverifica D3tirelativi a risultati intermedi di calcoli eseguiti sui core Cl...Cm del multiprocessore 10 in accordo a una delle specifiche procedure di autoverifica diagnostica delle librerie di autoverifica 50 con un insieme di valori pre-calcolati e attesi D3tiamemorizzati in tale modulo di controllo 15 e rileva eventuali fallimenti di modo comune CCF. Eventuali differenze fra tali dati di autoverifica D3tie 1' insieme di valori pre-calcolati e attesi D3tiaindicano 1'effetto di un guasto (permanente o transiente) nella logica o nello stato dei core Cl...Cm del multiprocessore 10;

- parallelamente, il modulo di controllo 15 operando il confronto continuo nel modulo logico 61 di dati di verifica applicativo Dchkprodotti in modo indipendente da una coppia di moduli processore 11, siano macchine virtuali o core, realizza di fatto una funzione di controllo fra i due canali di sicurezza corrispondenti;

- il modulo di controllo 15 completa con un controllo anche 1'operazione AsySdi auto verifica di valori di sistema misurati sull'architettura controllando se i dati di auto verifica di sistema Dsyssono all'interno di range attesi Ratt, del pari memorizzati nel modulo di controllo 15.

Il modulo di controllo 15 opera tali controlli sui messaggi di monitoraggio e controllo MC secondo ad esempio i seguenti criteri per il confronto:

considera il solo ordine di arrivo dei messaggi MC e la loro appartenenza al ciclo considerato per il confronto. Non viene guindi preferibilmente considerato un tempo assoluto di arrivo dei singoli messaggi MC, anche se in forme alternative di realizzazione esso può essere considerato;

il modulo di controllo 15 è configurato per permettere 1'interposizione di messaggi MC da diverse sorgenti, ossia da diversi elementi processori 11, in guesto caso due, fatto salvo 1'ordine all'interno delle seguenze da ognuno dei due moduli processori 11, come indicato in precedenza; il modulo di controllo 15 applica le proprie verifiche su base ciclica completando le verifiche per ognuno dei cicli definiti dal tempo di ciclo Tcyc.

Vengono ora descritte più in dettaglio le librerie di test di autoverifica 50 STL e i complementari moduli logici 51.

Le librerie di test di autoverifica 50 STL hanno la funzione duplice di:

implementare 1'operazione di verifica rappresentata dall'auto-verifica diagnostica Astidel sistema di elaborazione multiprocessore 10. Tale autoverifica Astisi ottiene tipicamente per confronto di risultati di calcolo, i dati di verifica Dsti, elaborati nel momento della verifica stessa dal multiprocessore 10, con risultati corretti pre-calcolati e memorizzati, i risultati attesi Dstia, in modo da verificare che il multiprocessore 10 calcoli correttamente ed esegua in modo corretto le seguenze di programma sottopostegli. Tali risultati di calcolo D3tisono tipicamente ottenuti dalla seguenza di operazioni di tipo aritmetico, logico e d'indirizzamento in modo da coinvolgere nel modo più completo, esteso ed esaustivo le diverse parti circuitali del microprocessore 11. Come detto nel procedimento e architettura gui descritti le operazioni di confronto con i valori attesi Dgtiasono implementate in cooperazione con un modulo di elaborazione esterno, il modulo di controllo 15 (ossia con la cooperazione dei moduli 50 e 51 nella rappresentazione gerarchica di Figura 3);

misurare dati di auto verifica di sistema Dgy3, ossia misurare parametri globali, relativi al funzionamento e/o alle condizioni di funzionamento di ciascun microprocessore . Preferibilmente sono misurate grandezze come la tensione di funzionamento del microprocessore e la temperatura di sistema oppure interna al microprocessore. Questa funzione ha particolare rilevanza nell'individuazione di situazioni di possibile fallimento dei microprocessori e in particolare situazioni che possano determinare fallimenti di modo comune nei microprocessori. Tali dati di verifica di sistema Dsyg, come detto, preferibilmente sono anche ricavati tramite programmi corrispondenti compresi nelle librerie 50 STL, anche se possono essere in librerie separate e controllati, rispetto a range attesi Ratt, nei moduli logici 51. .

In particolare e relativamente alle operazioni autoverifica diagnostica A3tiche forniscono i dati di autoverifica D3ti, il codice di auto-verifica è tipicamente composto da un insieme di segmenti di test (test segments), indicati con 202 e descritti più in dettaglio in Figura 7.

Tali segmenti di test sono preferibilmente specializzati per testare una o più unità funzionali del microprocessore, del sistema di elaborazione multiprocessore 10 in questo caso, in accordo agli obiettivi di un'analisi di tipo Failure Modes Effects and Diagnostic Analysis (FMEDA) condotta a livello di circuito integrato e, in particolare, sui singoli core Cl...Cm, o singoli processori. Tale FMEDA può essere eseguita, ad esempio, seguendo la procedura descritta nella domanda di brevetto EP 1 980 964 Al a nome della Richiedente. L'obiettivo complessivo dei segmenti di test che compongono la libreria 50 STL di ognuno dei core Cl...Cm è di raggiungere un livello di copertura, specificamente di autoverifica kstio di sistema k3y3, tale da soddisfare il vincolo di copertura f(k) prestabilito sulla totalità della logica componente il core Cl...Cm. Questo è usualmente un problema estremamente difficile per microprocessori con architettura avanzata (con pipeline profonda, superscalari, multi-issue) e la cui difficoltà cresce fortemente all'aumentare della complessità del microprocessore oggetto dell'autodiagnostica. La normativa di sicurezza funzionale di competenza al settore applicativo definisce i reguisiti minimi per 1'integrità del sistema e dei vari componenti del sistema.

Quindi i vari segmenti che compongono la libreria 50 devono essere progettati per raggiungere nel loro insieme, sull'interezza del microprocessore, o core, un valore obiettivo di copertura k3titale da permettere di raggiungere - tramite una procedura di calcolo come quella descritta di seguito con la formula 1) - un livello di integrità maggiore o uguale a quanto previsto dalla normativa di sicurezza di riferimento.

I programmi della libreria di autoverifica diagnostica 50 sono tipicamente organizzati in forma modulare per ragioni di espandibilità rispetto alle varie unità funzionali del microprocessore da verificare e la specializzazione di unità più semplici, i test segment 202, su ognuna delle unità funzionali del microprocessore.

In Figura 7 è rappresentato a questo proposito schematicamente un programma di autodiagnostica della libreria di autoverifica 50, indicato con 200. Dei test segment 202 compresi nel programma 200 vengono invocati, indicando 1'identificativo ID# di un test segment da eseguire, da uno strato software indicato come test interface 201 che realizza 1'interfaccia verso il software che invoca il programma di autodiagnostica della libreria 50 su base ciclica e regolare. Il test segment 202 replica inviando una signature pass/fail.

La struttura di un test segment 202 è ancora di tipo modulare organizzata per stadi successivi, e comprende un preambolo 203 e un epilogo 204 tipicamente scritti in un linguaggio di alto livello (ANSI-C) ovvero indipendentemente dall'architettura del microprocessore oggetto dell'autoverifica. Il preambolo 202 e 1'epilogo 204 sono dedicati alle funzioni d'interfaccia verso lo strato superiore alla gestione delle variabili globali e ai risultati del test che devono essere gestiti con tecniche che consentano da rivelazione di un errore che affiggesse il risultato del test nel momento in cui guesto viene trattato da guesti moduli software.

Il cuore del test segment 202 è rappresentato da una serie di moduli 206 scritti in codice di basso livello, di solito assembler, specifico per 1'architettura del microprocessore, indicati in figura come ASM core code. Questi moduli 206 sono le parti che eseguono effettivamente 1'autoverifica in guanto stimolano in modo mirato le varie unità logiche e aritmetiche e seguenziali del microprocessore in modo da attivare e rendere osservabile un eventuale guasto del microprocessore stesso. I vari moduli 206 in codice a basso livello possono essere gestiti da routine 205 scritte in linguaggio ad alto livello. Il test segment 202 comprende un calcolatore di signature 207 per generare le signature fai1/pass al termine dei controlli tramite i moduli 205 e 206. I test segment 202 comprendono una pluralità di moduli 206 in codice a basso livello per ottenere un obiettivo di copertura rispetto ai guasti, dato un determinato insieme di fallure mode, o modalità di guasto, definite dall'analisi della sicurezza.

Viene ora discussa la distribuzione delle operazioni di autoverifica, specificamente di guelle di autoverifica diagnostica A3ti, fra le librerie di test di autoverifica 50 STL sui processori 11 e i componenti logici 51 sul modulo di controllo 15.

Il funzionamento delle librerie di test di autoverifica 50 STL è basato sulla capacità di un microprocessore di testare se stesso eseguendo seguenze di codice tali da sollecitare al massimo il contributo delle diverse logiche che lo compongono e producendo risultati intermedi che, opportunamente accumulati in modo che eventuali errori nei risultati intermedi non possano cancellarsi , producano poi delle firme che , guando confrontate con gli stessi valori pre-calcolati assumendo assenza di guasti, diano la più alta confidenza di rilevare un eventuale guasto che dovesse aver afflitto la logica oggetto del test . La capacità di attivare e rilevare il guasto dipende sia dalla capacità del test della libreria 50 di attivare il guasto e dal metodo numerico utilizzato per accumulare i risultati intermedi in modo che un'eventuale differenza nei risultati intermedi non possa essere cancellata durante il processo di accumulazione . Per chiarezza, si possono avere diverse tipologie di risultati prodotti dalle librerie di test di autoverifica 50 STL al microprocessore , risultati intermedi, accumuli e firme, gli ultimi due essendo sovente, secondo le implementazioni, la medesima cosa. L'accumulazione è tipicamente necessaria per ridurre il numero di risultati intermedi che altrimenti non sarebbe gestibile . Nel seguito per semplicità si farà riferimento ai risultati intermedi , comprendendo in tale definizione tutte e tre le tipologie di risultato sopra indicate .

La rivelazione dell'attivazione del guasto nel singolo microprocessore può avvenire attraverso due distinti meccanismi:

a) rivelazione del software di autoverifica stesso che tramite confronto dei dati di autoverifica D3tidiversi da quelli pre-calcolati, ossia i risultati attesi D3tìa, determina 1'errore e in modo programmatico adotta delle contromisure segnalando 1'errore rilevato. Questo è il caso tipico in cui un guasto non affligge la logica deputata al controllo del flusso di esecuzione del programma, ma solo la parte di calcolo aritmetico/logico dei dati;

b) stimolazione determinata dall'esecuzione del test 50, congiuntamente al verificarsi di un guasto, determina un errore nella sequenza di esecuzione del programma P tale da violare degli estremi di controllo sul tempo di esecuzione t sorvegliati da un watchdog esterno che segnala 1'errore. Questo è il caso tipico in cui un guasto affligge la logica deputata al controllo del flusso di esecuzione del programma. Si noti che il watchdog può essere un componente dedicato del sistema oppure un altro core che operando un controllo incrociato riesce a rilevare un erroneo comportamento funzionale o temporale nell'esecuzione del test 50 sul microprocessore considerato.

In tale ambito, le librerie di test di autoverifica 50 STL indicate in Figura 3 generano dati di autoverifica D3tiche comprendono dati relativi al processo di autoverifica ovvero risultati intermedi (o parziali, accumulazioni di risultati intermedi oppure risultati del confronto fra risultati intermedi e valori attesi) che vengono inviati a un modulo esterno, il modulo di controllo 15, che provvede al confronto incrociato fra i dati di autoverifica D3ti(meccanismo a) )e al controllo del flusso di esecuzione (assolvendo in questo modo alle funzioni del watchdog esterno nel contesto del meccanismo b) di stimolazione dei test STL, come descritto sopra).

Le librerie di test di autoverifica 50 STL generano inoltre i valori misurati , incluse configurazioni di sistema, ossia i dati di sistema Dsys.

Le librerie di test di autoverifica 50 generano corrispondenti messaggi MC contenenti tali dati di autoverifica Dstie di sistema D^s, al modulo di controllo 15 che elabora, tramite i componenti logici 51, tali messaggi generati dalle librerie 50 di test STL in esecuzione sui core fisici Cl...Cm del multiprocessore 10.

Tali elaborazioni ai componenti logici 51 sono configurate per eseguire le seguenti operazioni:

operare un controllo incrociato sui dati di autoverifica D3ti,

sia implementando un controllo di flusso di esecuzione (intra-channel ) sui risultati del confronto operati dai microprocessori Cl...Cm

sia operando un controllo incrociato (interchannel) dei risultati parziali ottenuti dall'elaborazione dei test delle librerie 50 su ciascuno dei microprocessori Cl...Cm.

operare un controllo di corretta esecuzione temporale verificando che i risultati del confronto ovvero i risultati parziali siano inviati e ricevuti all'interno di finestre temporali predeterminate (caratterizzate da una latenza massima e minima) e secondo un ordine prefissato. Questo consente di poter rilevare eventuali errori nell' esecuzione del flusso come indicato in precedenza come meccanismo di rivelazione degli errori nel flusso di esecuzione del test 50 STL che necessita dell'ausilio di un componente esterno;

operare un controllo di corretta appartenenza dei valori misurati Dsysall'interno di intervalli predefiniti di variabilità per le grandezze oggetto di misura (tipicamente tensione di esercizio e temperatura). In aggiunta possono essere effettuati controlli di consistenza delle configurazioni di sistema acguisite dalle librerie di test 50 e che sono rappresentative dello stato del sistema durante 1'esecuzione.

La violazione di uno dei controlli operati appena descritti implica da parte del modulo di controllo 15 la generazione di un allarme AL, come indicato in Figura 6, e la messa in atto delle contromisure necessarie all'applicazione di sicurezza. Tali funzioni di generazione allarmi inviano allarmi a un modulo 16, che è un modulo che controlla risorse di sistema nel sistema 10, e può ad esempio operare un reset o rimuovere la tensione di alimentazione o comungue forzare il raggiungimento di uno stato sicuro del sistema.

Un esempio di flusso di operazioni associate alla libreria di autoverifica 50 è il seguente:

Repeat forever{

ricevere dati da tutti i programmi delle librerie di autodiagnostica che vengono eseguite sul multiprocessore 10, sul livello supervisore o direttamente su ciascuno dei core fisici,)

suddividere e organizzare data secondo il core, canale virtuale e tipo;

allineare i risultati intermedi corrispondenti di ciascun programma delle librerie 50. Verificare il massimo skew fra risultati intermedi corrispondenti e la latenza massima ;

eseguire un controllo incrociato fra i risultati intermedi delle librerie 50 e rilevare errori;

raccogliere le misure da core differenti. Verificare il massimo skew fra risultati intermedi corrispondenti e la latenza massima

eseguire verifica dei range e individuare violazioni

Come indicato anche in Figura 6 con riferimento al modulo 116, il modulo di controllo 15 esegue controlli multipli di valore , ordine, tempo (latenza, skew e tempo assoluto d<f>arrivo usando timestamp) e range (nel modulo 114 con comparatore . In particolare , sono eseguiti i seguenti controlli sui dati di autoverifica Dsti, Dchk, D3y3:

• il controllo di valore verifica che i risultati intermedi siano gli stessi o l'esecuzione delle condizioni d'uso o dei test LBIST sia rispettata;

• il controllo d'ordine verifica che 1'ordine dei messaggi sia corretto secondo dei contatori nel messaggio;

• il controllo dei tempi d'arrivo paragona il tempo di arrivo del messaggio rispetto a un tempo minimo e massimo atteso nell'ambito del corrente ciclo di esecuzione e/o al corrispondente messaggio da un altro core;

• il controllo dei range verifica che il valore misurato appartenga al range Rattpredefinito.

Ogni violazione dei controlli è gestita dal modulo di controllo 15 che segnala un errore , e guindi innesca allarmi verso il modulo 16.

Vengono ora descritte più in dettaglio componenti software di confronto applicativo 60 e i complementari moduli logici 61 al modulo di controllo 15.

Dunque , come indicato in Figura 3, nei sottoprogrammi Pl...Pn eseguiti sulle macchine virtuali Vl...Vn sono presenti i componenti software di confronto applicativo 60 che implementano lo Application Safety Layer , ossia procedure di rilevamento di risultati parziali dell'elaborazione dei sottoprogrammi ΡΙ.,.Ρη, oppure esecuzione di condizioni d'uso oppure esecuzione di test LBIST. Tali componenti software di confronto 60 operano anche 1'accumulo di tali risultati parziali e rilevano differenze sul risultati accumulati (per esempio 1'accumulo di un CRC) dal programma in sicurezza SF. Tali componenti software di confronto applicativo 60 operano anche 1'organizzazione dei dati dei risultati accumulati e delle differenze, o delle condizioni d'uso o dei test LBIST in trame di dati applicazione Dchksecondo il protocollo PL anch'esso oggetto del procedimento qui descritto .

Come già indicato, anche i componenti di confronto applicativo 60 hanno corrispondenti componenti logici di confronto applicativo 61 nel modulo di controllo 15. Sui dati di verifica applicativo Dchkil modulo di controllo 15 opera dei confronti incrociati , in particolare verificando la congruenza delle informazioni in base ai valori dei dati di verifica applicazione Dchk, al loro ordine e al tempo d'orologio riportato nei pacchetti di dati di verifica applicazione Dchkgenerati dai componenti confronto applicativo 60 .

Viene ora ulteriormente dettagliato il protocollo di comunicazione PL. L'organizzazione delle operazioni di autoverifica A3ti, A3y3, Achk, prevede di definire diverse tipologie d' insiemi di messaggi nell'ambito del protocollo PL in dipendenza dai livelli L2...L4 di software che hanno generato il messaggio e la finalità del messaggio stesso.

Si definiscono quindi i seguenti canali logici (Virtual Channel) VC. Ognuno dei canali logici VC trasporta messaggi provenienti al più da due canali fisici diversi indicati come IDO e IDI:

VCO: Safety VC, canale logico di sicurezza originato al livello applicazione L4 dal programma in sicurezza SF (canali fisici con identificativo IDO e IDI);

VC1: Supervisor VC, canale logico originato dal livello supervisore L2 o dal livello applicazione L4, a seconda dell'implementazione (canali fisici con identificativo IDO);

VC2: Q&S, canale logico qualità e servizio, originato dal livello supervisore L2 o dal livello L3 di macchina virtuale e sistema operativo, secondo 1'implementazione, che esegue operazione di mantenimento sul sistema (Quality and Service) (canali fisici con identificativo IDO e IDI).

Nella forma realizzativa preferita con due canali fisici si ha che

i canali logici VCO e VC2 supportano due canali fisici IDO e IDI, che sono in questo canali di sicurezza;

il canale logico VC1 supporta solo un canale fisico, IDO.

Tale definizione dei canali logici VC si riflette in una particolare caratteristica del modulo di controllo 15 per cui è possibile configurare controlli e allarmi programmabili per ciascuna delle categorie degli insiemi di messaggi.

In una forma di realizzazione preferita del modulo di controllo 151'ordine di trasmissione dei differenti canali logici VC è predeterminato e fisso, per esempio VCO, VC1 e VC2. La Figura 4 mostra un esempio di una possibile realizzazione del protocollo di comunicazione PL che viene riflesso dalla logica di confronto del modulo di controllo 15 . E' in particolare mostrato il canale di comunicazione in cui sono inviati, nell'ambito di un intervallo di test diagnostico DTI , i canali logici VCO, VC1, VC2 DTI secondo il protocollo di comunicazione PL:

canale logico VCO , per i canali fisici IDO,IDI, trasporta i dati della funzione in sicurezza funzionale SF, ossia i dati di verifica applicativo Dch3⁄4, di cui si verifica la consistenza ai componenti 61 del modulo di controllo 15 (messaggi omologhi appartenenti ai canali IDO e IDI sono confrontati 1' uno con 1'altro e il confronto deve fornire il risultato corretto, ovvero dati ad esempio eguali a meno di differenze, guali differenze di codifica. I dati potrebbero essere infatti codificati in modo diverso (per esempio compìementati in un canale) per ridurre la probabilità di errori a comune;

canale logico VC1, per il canale fisico IDO, trasporta i dati di autoverifica, D3ti, della libreria di autoverifica diagnostica 5 0 provenienti dal livello supervisore L2;

canale logico VC2, per i canali fisici IDO, IDI, trasporta i valori misurati , ossia i dati di verifica sistema D3y3, guali valore di temperature, tensione, ecc..

Sempre con riferimento alla Figura 4 si noti che il tempo totale di trasmissione sul canale di comunicazione dei messaggi MC non deve eccedere 1'intervallo di test diagnostico DTI del sistema in guanto la trasmissione deve avvenire in modo continuo e con lo stesso tempo di ciclo Tcycdel programma P nel caso peggiore.

I controlli eseguiti dal modulo di controllo 15 sulle sequenze Sg di messaggi sono descritti nel diagramma di Figura 5. Nella prima riga è indicato il livello di layer, L, e 1'elemento interessato, modulo processore Gl o C2, oppure modulo supervisore 17. I messaggi MC marcati con gli identificativi IDO e IDI sono incapsulati in diversi insiemi di messaggi Sg (Sgl e Sg2) e inclusi all'interno dei differenti canali logici VC. Essi sono sottoposti a due tipi di controlli da parte del modulo di controllo 15:

controllo intra- canale ITC (non rappresentati in Figura 5): applicati a messaggi che appartengono allo stesso canale logico VC e allo stesso identificativo ID; controllo inter-canale INTC: applicati a messaggi MC che appartengono a canali logici VC diversi . Ad esempio primo messaggio Sgl 0,0 di IDO confrontato con il primo messaggio Sql 0,1 di IDI, secondo messaggio Sql 2,0 di IDO confrontato con il secondo messaggio Sq 2,1 di IDI, ecc...). Tali controlli inter-canale INTC vengono eseguiti in aggiunta e a livello superiore rispetto ai controlli intracanale ITC che hanno come oggetto la consistenz a dei messaggi provenienti da ognuno dei canali.

E' importante sottolineare che la Figura 5 rappresenta i messaggi in accordo alla loro origine e non la sequenza temporale con cui questi vengono trasmessi .

La struttura del protocollo di comunicazione PL descritto e dei controlli che vengono effettuati sugli insiemi dei messaggi trova diretto riscontro nell' architettura funzionale del modulo di controllo 15 fino alla sua micro-architettura implementativa , come mostrato con riferimento a Figura 6.

Come accennato, sono possibili realizzazioni sia di tipo software per il modulo di controllo 15 sia di tipo hardware con logica dedicata per esempio in un dispositivo FPGA oppure in un ASIC.

La Figura 6 mostra le funzioni principali integrate nel modulo di controllo 15.

Il livello di descrizione di Figura 6 riflette unità hardware dedicate, ma può egualmente riflettere unità funzionali usate per darne per esempio una realizzazione come embedded software in un modulo a processore separato dal multiprocessore 10 piuttosto che come hardware dedicato in un dispositivo FPGA oppure ASIC. A puro titolo di esempio, la figura 9 mostra una possibile implementazione dell'architettura proposta su un "System On Chip" (SoC) 1000 , in particolare con multiprocessore simmetrico a due core, in cui due processori il sono contenuti in una "hard macro" 1010 mentre il modulo di controllo 15 è un modulo software eseguito su un processore ridondante implementato in una porzione programmabile 1020 (FPGA) del System On Chip 1000.

Tornando alla figura 6, con 112 è indicata un interfaccia bus verso il bus di comunicazione 12, che comprende un modulo di configurazione e status interfaccia 112c, dei buffer 112b per i messaggi dei differenti canali, ID0 e IDI. Comprende inoltre un modulo 112a per il controllo di CRC sui pacchetti in arrivo.

Con 113 è indicato un modulo di temporizzazione, per controllare le tempistiche, in particolare il mantenimento degli estremi di controllo sul tempo di esecuzione.

Con 114 è indicato un modulo per le verifiche intercanale, operazioni INTC, che comprende un comparatore 114a per paragonare inter-canale i dati dei canali e un iniettore di fault hardware 114b.

Con 116 è indicato un modulo per le verifiche intracanale, operazioni ITC, che comprende moduli 116a, 116b, 116c per verificare il tempo di arrivo, 1'ordine e il valore dei dati in arrivo.

I dati sono forniti a tali moduli 114 e 116 da un modulo 115 di distribuzione dei messaggi, che comprende preferibilmente un modulo DMA (Direct Memory Access) 116a e un modulo controllore dei messaggi 116b.

Con 111 è indicato un controllore d'errore, che, tramite un router di eventi programmabile provvede a inviare allarmi al modulo 16. Le informazioni e i segnali relativi ai dati e agli allarmi che derivano da condizioni anomale rilevate dai confronti fra i canali fisici IDO e IDI o rispetto agli intervalli di valori attesi o ai risultati pre-calcolati, nei moduli 114 e 116, sono tenute separate (dal punto di visto logico, elettrico e fisico) così come richiesto dagli standard di sicurezza di riferimento (si faccia riferimento per esempio a IEC61508 safety design recommendations). Sempre con riferimento a Figura 6 gli allarmi sono indicati con linea tratteggiata. Le sorgenti di allarme indicate sono relative al rilevamento di anomalie nei seguenti confronti:

controlli inter-canale INTC (modulo 114), guesto tipo di confronti include confronto di valori, ad esempio il attesi uguali e calcolati da diversi core del multiprocessore e confronto di valori attesi pre-calcolati. Genera un allarme inter-canale ALintc.

controlli intra-canale ITC (modulo 116), guesto tipo di confronti include confronti rispetto a valori attesi pre-calcolati ovvero verifica rispetto a un intervallo predefinito di riferimento (per esempio di temperatura o di tensione di funzionamento). Genera un allarme intra-canale ALitc.

controlli sulle temporizzazioni (modulo 113), ad esempio sul mantenimento degli estremi di controllo sul tempo di esecuzione. Generano un allarme temporizzazione Alt;

anomalie nella struttura e composizione del messaggio dal punto di vista formale. Nell'esempio considerato il fallimento di un controllo di tipo CRC (Cycllc Redundant Check) eseguito dal modulo CRC 112a sul testo di un messaggio in ingresso all'interfaccia 112, che genera un allarme ALc.

Infine il modulo di controllo 15 comprende un modulo 117 di iniezione dei fault.

Come si può comprendere dalla descrizione di Figura 6, i moduli logici 51 e 61 non sono implementati separatamente, ma le funzioni necessarie a ciascuno di tali moduli logici sono eseguite sostanzialmente dai moduli 114, 116 e 113.

Sempre a puro titolo di esempio, la figura 10 mostra una possibile implementazione dell'architettura proposta su una combinazione di due componenti separati, un "System On Chip" (SoC) 1030 , in particolare con multiprocessore simmetrico a quattro moduli processori 11 mentre il modulo di controllo 15 è un modulo software eseguito su un processore ridondante 1050 implementato in un ASIC o FPGA 1040 che si interfaccia con il SoC 1030 tramite interfaccia PCI 1060.

Per quanto riguarda il calcolo dell'obiettivo di copertura derivante da operazioni di autoverifica Achk, 1'obiettivo di copertura applicativo kchknel caso di confronto dei risultati intermedi, ad esempio, è determinata come funzione della quantità di dati q scambiati ad ogni confronto rispetto alla quantità totale e come periodo dello scambio dei dati t (il cui inverso è la frequenza di scambio dati f) rispetto ad un tempo obiettivo T - tipicamente calcolato come corrispondente al Process Safety Time (PST) o Fault Tolerant Time Interval (FTTI) delle norme di sicurezza funzionale sopra citate:

kchk= min (1, q*T/t) (3)

Il periodo dello scambio dei dati t corrisponde al tempo di esecuzione in sicurezza Ts.

Dalle relazioni (1) e (2) risulta che le coperture kl, k2 , kl2 dipendono dal valore della copertura di confronto kchk, e che 1'obiettivo di probabilità di guasto è funzione di kl , k2, kl2. Pertanto, risulta anche che , dato un obiettivo di probabilità di guasto g, i valori della quantità di dati q scambiati e della frequenza f di scambio dei dati sono dimensionati in modo che la copertura di confronto kchkassuma un valore tale che, inserito nelle equazioni (1) e (2) , sia rispettato 1' obiettivo di probabilità di guasto g.

Il procedimento qui descritto è diretto tuttavia a applicazioni per il quale può essere necessario disporre di tutta la potenza di calcolo dei processori disponibili . Di conseguenza, il procedimento secondo 1'invenzione prevede di eseguire le operazioni di autoverifica diagnostica Asti, che eseguono test autodiagnostici e le operazioni di auto verifica A3y3di valori di sistema misurati, secondo quanto descritto fino ad ora. Tali operazioni di auto verifica diagnostica A3tie operazioni di auto verifica A^ di valori di sistema misurati individuano rispettivi obiettivi di copertura k3tie ksys, che, inserite ad esempio in equazioni come 1'equazione (2) determinano la copertura dei programmi Pl...Pn. Dati i contributi degli obiettivi di copertura k3tie k3y3, il contributo rimanente kchk, ossia 1'obiettivo di copertura garantito dalla verifica applicazione , per rispettare 1'obiettivo di probabilità di guasto g, viene ottenuto impiegando operazioni AChkdi autoverifica applicativa meno onerose dal punto di vista della potenza di calcolo.

Secondo una prima forma realizzativa tali operazioni Achkdi autoverifica applicativa meno onerose dal punto di vista della potenza di calcolo comprendono operazioni Acoudi verifica dell'esecuzione periodica delle condizioni d'uso. Il vantaggio di operare con le condizioni d'uso invece che con i programmi intermedi è che tipicamente (come mostrato in figura H A) le operazioni di autoverifica applicativa Achktramite confronto di programmi intermedi forniscono una copertura applicativa kchksignificativamente sovrapposta a guella di k3tie guindi comportano uno "spreco" di risorse computazionali . Al contrario, la copertura dalle operazioni Acoudi verifica dell'esecuzione periodica delle condizioni d'uso,è determinata per limitare tale sovrapposizione (si veda ad esempio la figura 11B ) e guindi limitare lo spreco di risorse di calcolo.

Dungue, le operazioni di autoverifica applicativa Achkcomprendono operazioni Acoudi autoverifica dell'esecuzione periodica di condizioni d'uso, relative al fatto che ai programmi Pi, Ρ≤, ...Pn(o ad un sottoinsieme di essi) è richiesto di rispettare determinate condizioni d'uso (CoU), tali che , guando esse siano rispettate almeno una volta nell'arco del Process Safety Time (PST) o Fault Tolerant Time Interval (FTTI) delle norme di sicurezza funzionale sopra citate , garantiscano un corrispondente obiettivo di copertura kcoutale che rispetti la seguente condizione:

kgtikl k kchkki k3n (4 ossia la condizione che 1 'unione delle coperture dovute all' autodiagnostica kstied alla copertura per condizioni d'uso kcousia uguale all'unione delle coperture date dall'operazione di autoverifica applicativa AChke dall'operazione di autodiagnostica k3ti.

A titolo di esempio, tali condizioni d'uso possono essere raggruppate in due classi:

"Class 1" - condizione d'uso che i programmi includano un controllo del flusso di programma, tecnica nota allo stato dell'arte;

"Class 2" - condizione d'uso che i programmi includano una o più delle tecniche note sotto riportate:

controllo di coerenza dei dati, ad esempio confrontando dati provenienti da diversi ingressi del processore;

incapsulamento dei dati con un codice, ad esempio tipo CRC;

esecuzione periodica di un test utilizzando dei pattern dati fissi;

ripetizione periodica di porzioni dei sottoprogrammi.

A puro titolo di esempio e per chiarire ulteriormente il significato delle "condizioni d'uso", si riporta gui sotto la descrizione dettagliata di una condizione d'uso CoU di classe 2 (relativa a 1'incapsulamento dei dati con codice):

"In ciascun FTTI, il programma deve spostare tra processore e la memoria almeno un pacchetto dati contenente almeno guattro dati a 64-bit, tale da essere memorizzato in almeno guattro indirizzi consecutivi di memoria . L'indirizzo sorgente, guello destinatario e il numero complessivo di byte trasferiti devono essere multipli di 64 byte. Il dato deve essere incapsulato con un codice (ad esempio di tipo CRC). Il codice è contenuto con il dato.

Quando il pacchetto è letto, il programma deve rigenerare il CRC e confrontarlo con quello contenuto della parola letta".

Si noti come la descrizione contiene le parole "almeno" e "deve essere", che quindi rappresentano delle "condizioni" che chi scrive il programma dovrà rispettare. Si noti anche come la descrizione contiene la parola "in ciascun FTTI " indicando quindi la periodicità.

Pertanto dalla descrizione dettagliata di una condizione d'uso CoU di classe 2 sopra riportata si estraggono ad esempio, fra le altre, le condizioni CN1, CN2, CN3:

CN1= "spostare tra processore e la memoria almeno un pacchetto dati contenente almeno quattro dati a 64-bit" CN2=" pacchetto [...] tale da essere memorizzato in almeno quattro indirizzi consecutivi di memoria

CN3= "L<1>indirizzo sorgente, quello destinatario e il numero complessivo di byte trasferiti devono essere multipli di 64 byte",

ciascuna associata a una condizione di periodicità, ossia 1'esecuzione in ciascun periodo FTTI.

Relativamente alle operazioni di autoverifica di condizioni d'uso Acou, la soluzione qui descritta prevede anche una tecnica per facilitare la verifica che tali condizioni d'uso siano effettivamente contenute nei programmi PI, P2, Pn .

Con riferimento anche alla figura 7, tale tecnica consiste nel fatto che:

• ciascun programma PI, P2, Pn, ogni qual volta esegue una condizione d'uso Cou, la segnala (tramite una apposita variabile) alla test interface 201;

• la test interface 201 è configurata tramite programmazione per conoscere guante condizioni d'uso devono essere soddisfatte almeno una volta nell'arco del Process Safety Time (PST) o Fault Tolerant Time Interval (FTTI) delle norme di sicurezza funzionale sopra citate;

• sulla base di gueste informazioni, la test interface 201 segnala se il numero delle condizioni d'uso soddisfatte almeno una volta nell'arco del Process Safety Time (PST) o Fault Tolerant Time Interval (FTTI), è pari al numero programmato, fornendo tali informazioni come dato di autoverifica DChk, più un dato di autoverifica per le condizioni d'uso DCou-In figura 14 a guesto proposito è mostrata una possibile variante semplificata dell'architettura in sicurezza funzionale di figura 3, in cui ciascun programma PI, P2, Pn, ogni guai volta esegue una condizione d'uso Cou, la segnala attraverso i moduli software di confronto applicazioni 60 alle librerie di autoverifica diagnostica 50, che comprendono la test interface 201. La test interface 201 invia poi il corrispondente dato di autoverifica per le condizioni d'uso DCoU nei messaggi di monitoraggio e controllo MC verso l'unità di elaborazione e confronto, ossia il modulo di controllo 15. Qui è previsto nella forma realizzativa di figura 4, per semplicità, di impiegare i soli componenti logici di verifica 51 per controllare anche i dati di autoverifica per le condizioni d'uso DCoU. Le operazioni di autoverifica Acou possono comungue essere implementate anche tramite 1'architettura completa di Figura 3.

Secondo una ulteriore forma realizzativa tali operazioni Achkdi autoverifica applicativa meno onerose dal punto di vista della potenza di calcolo comprendono operazioni di verifica dell 'esecuzione periodica di test LBIST (Logicai Built-In Test) Abst.

Anche in questo la copertura dalle operazioni di tipo LBIST Abstpermette di evitare la sovrapposizione dovuta al confronto di programmi intermedi illustrata con riferimento a figura 11B e quindi limitare lo spreco di risorse di calcolo .

Dunque, le operazioni di autoverifica applicativa Achkcomprendono operazioni Abstverifica di esecuzione di test LBIST, relative al fatto che all'hardware del processore è richiesta 1 'accensione periodica di circuiti cosidetti di "LBIST" (Logic built-in self -test), noti di per sé al tecnico del settore, tali che quando essi sono messi in funzione almeno una volta nell'arco del Process Safety Time (PST) o Fault Tolerant Time Interval (FTTI) delle norme di sicurezza funzionale sopra citate, garantiscano una copertura di autoverifica BIST kbsttale che:

k3tiLJ kb3tkchkti ksti(5)

ossia una condizione secondo la quale 1'unione delle coperture dovute all' autodiagnostica k3tied alla copertura per LBIST kbstè uguale all'unione delle coperture date dall 'operazione di autoverifica Achkdall'operazione di autodiagnostica k3ti-Per quanto riguarda le operazioni di autoverifica LBIST Abstche generano corrispondenti dati di autoverifica Dbstda controllare al modulo 15, la soluzione qui descritta prevede che:

ciascun programma Pi, P2, Pn, ogni qual volta decide che è il momento opportuno per essere interrotto (ad esempio perché la funzione che esso realizza non è utilizzata in quel specifico momento dell'applicazione), segnala al corrispondente livello fisico LI che 1'operazione LBIST può essere iniziata;

a questo punto il corrispettivo circuito hardware che realizza il test LBIST, ad esempio il circuito 41 indicato in Figura 15 e descritto nel seguito (tipicamente una macchina di tipo LFSR o MISR, nota di per sé al tecnico del settore), viene attivato e - dopo un certo tempo - genera il risultato di test LBIST Dbstper il core in questione; tale risultato (sotto forma ad esempio di segnalazione "go/no-go") viene passato alla test interface 201;

sulla base di queste informazioni, la test interface 201 segnala se tutte le operazioni di autoverifica LBIST Abstsono state eseguite e con quale esito, fornendo tali informazioni come dato di autoverifica Dchksul MC più eventualmente un dato di autoverifica per le condizioni d'uso Dcou.

In figura 15 a questo proposito è mostrata una possibile variante semplificata dell'architettura in sicurezza funzionale di figura 3, in cui ciascun programma PI, P2, Pn, ogni qual volta ritiene di poter eseguire 1'operazione di autoverifica LBIST, lo segnala attraverso i moduli software di confronto applicazioni 60 al livello L4 al corrispettivo livello LI in cui risiede un circuito di LBIST 41. Una volta che il circuito LBIST 41 ha completato la sua operazione, lo segnala alle librerie di autoverifica diagnostica 50, che comprendono la test interface 201. La test interface 201 invia poi il corrispondente dato di autoverifica Dbstnei messaggi di monitoraggio e controllo MC verso 1'unità di elaborazione e confronto, ossia il modulo di controllo 15. Qui è previsto nella forma realizzativa di figura 15, per semplicità, di impiegare i soli componenti logici di verifica 51 per controllare anche i dati di autoverifica per le condizioni d'uso Dbst- Le operazioni di autoverifica LBIST Abstpossono comungue essere implementate anche tramite 1' architettura completa di Figura 3.

Si sottolinea inoltre , che , per avere maggiore flessibilità, in forme varianti di realizzazione è anche possibile combinare operazioni di autoverifica di confronto Acoue Abstin modo da garantire la seguente eguazione:

ksti LJ kbsttl keoo kchktJ kgtl (6)

Tale eguazione (6) può essere soddisfatta in due modi, come mostrato in figura 12:

date diverse modalità di guasto FM1, FM2,..., FMn, combinando le tre operazioni corrispondenti A3ti, Acoue Abstin modo "congiunto" (figura 12A), ossia ciascuna modalità di guasto FM1 , FM2,..., FMn risulta coperta da tutte e tre le coperture garantite da ciascuna operazione;

combinando le tre operazioni, A3ti, Acoue Abst, in modo "disgiunto" (figura 12B), ossia ciascuna modalità di guasto FM1 , FM2,..., FMn risulta coperta da una (o al massimo due ) delle tre coperture garantite da ciascuna operazione - ad esempio da k3ti+ kbste disgiuntamente da kcou, oppure da k3ti+ kbste disgiuntamente da kcou.

Il vantaggio del modo disgiunto è che, ad esempio, le operazioni di autoverifica per LBIST, Abstsono più invasive (richiedono un aumento dell'area di silicio del dispositivo e/o un lungo tempo di esecuzione in funzione del numero di test da eseguire ) e guindi può convenire limitare tale operazioni solo per alcune modalità di guasto o fallure mode - e concentrare le operazioni di autodiagnosi A3tie di rispetto delle condizioni d'uso Acousu altre modalità di guasto . In questo modo si riduce 1<1>impatto (il numero dei test che i circuiti LBIST devono eseguire è minore) e quindi il costo relativo all'utilizzo delle operazioni di autoverifica per confronto LBIST Ab3t-Poiché anche le operazioni Acoudi autoverifica di condizioni d'uso possono essere invasive rispetto ai programmi (richiedono di rispettare alcune condizioni d'uso che potrebbero essere, per alcuni programmi , onerose da realizzare e/o da verificare ), può convenire limitare tale operazioni solo per alcune modalità di guasto e concentrare le operazioni di autoverifica tramite autodiagnostica Astie di autoverifica per LBIST Ab3tsu altre modalità di guasto. In questo modo si riduce 1 'impatto e quindi il costo relativo all 'utilizzo delle operazioni di autoverifica di condizioni d'uso Acou.

Da notare che 1 'introduzione delle operazioni di autoverifica per condizioni d'uso Acoue LBIST Ab3tpermette anche di facilitare la realizzazione di soluzioni multiprocessore a "livello di integrità mista", ossia soluzioni per le quali il requisito di copertura per ciascun processore sia diverso in relazione al programma da eseguire .

A titolo di esempio di questa proprietà della soluzione descritta, come mostrato in figura 13 , si consideri un sistema multi-processore come quella di figura 10 , composto da quattro core 11, due dei quali, quelli che eseguono i sottoprogrammi PI e P2. hanno uno stesso requisito di livello di integrità LSI, ad esempio SIL2 o ASILB rispetto alle norme di sicurezza funzionale sopra citate , mentre il core 11 che esegue il programma P3 ha un livello di integrità mista inferiore LS2, ad esempio SILI o ASILA rispettivamente, mentre il core 11 che esegue il sottoprogramma P4 non è destinato a programmi critici per la sicurezza, e guindi non ha un reguisito di livello di integrità, indicato con NLS in figura. In guesto scenario, la soluzione descritta permette in modo molto flessibile di:

• utilizzare una combinazione di operazioni A3tidi auto verifica diagnostica, di autoverifica Achkcon verifica di risultati intermedi, di autoverifica di misura A3y3oppure A3tidi auto verifica diagnostica, autoverifica di misura A3y3, autoverifica di esecuzione fra condizioni d'uso Acoue autoverifica LBIST Ab3tper i processori 11 che eseguono i sottoprogrammi PI e P2 associati a un valore di coverage k più alto derivante dal valore di SIL o ASIL LSI;

• utilizzare una combinazione di operazioni di auto verifica diagnostica A3ti, Acoue A^ o A3ti, Abste A^ per il processore 11 che esegue il sottoprogramma P3 a un valore di coverage k più basso derivante dal valore di SIL o ASIL LS2;

• utilizzare, per il solo controllo di interferenza (ossia accesso non richiesto del sottoprogramma P4 alle risorse dei sottoprogrammi PI, P2, e P3) operazioni Astidi auto verifica diagnostica per il processore 11 che esegue il sottoprogramma P4.

Dungue è previsto più in generale che, data una pluralità di moduli di elaborazione 11 cui sono assegnati rispettivi sotto-programmi paralleli ΡΙ.,.Ρη per 1'esecuzione, guando un sottoinsieme di detti programmi, in guesto caso P3, ha un livello di integrità (LS2) inferiore a guello di un altro sottoinsieme di detti programmi (LSI), si utilizzi una combinazione di dette operazioni di auto verifica che comprendono le operazioni di auto verifica diagnostica A3ti, che eseguono test autodiagnostici, operazioni di auto verifica A3y3di valori di sistema misurato, operazioni di auto verifica Achtdi verifica applicazione comprendenti esecuzione di condizione d'uso Acouo esecuzione di LBIST Abstper il sottoinsieme di programmi, cioè P3, che ha un livello di integrità LS2 inferiore.

Dungue, dalla descrizione risultano chiari i vantaggi dell'invenzione .

Il procedimento e architettura descritti permettono vantaggiosamente di soddisfare determinati reguisiti di sicurezza funzionale per un sistema multi-canale o singolo canale anche altamente integrato in un multiprocessore su singolo circuito integrato.

La descritta procedura di scomposizione dei programmi ed il partizionamento delle operazioni di autoverifica in tre separate operazioni, autoverifica tramite test diagnostici, autoverifica tramite monitoraggio dei valori di sistema e autoverifica applicativa tramite combinazione dell'esecuzione di condizioni d'uso e/o LBIST, nonché la corrispondente formula 1) permette di identificare con precisione gli obiettivi di copertura da assegnare a ciascuna delle tre operazioni di autoverifica, permettendo altresì di distribuire gli obiettivi in modo ottimizzato, ossia abbassando 1'obiettivo per le operazioni che - per il particolare tipo di sistema al guaie il metodo descritto viene applicato - richiederebbero un elevato sforzo di progettazione per essere raggiunte ed invece alzandole per quelle operazioni che in tale contesto risultano più agevoli .

La soluzione descritta permette inoltre di mitigare il problema dei fallimenti CCF (Common Cause Failures) attraverso l<f>introduzione di un elemento, rappresentato sostanzialmente da un modulo di controllo, ossia un modulo indipendente a timer elettronico, sollecitato periodicamente dal processore ad intervalli di tempo prefissati per eseguire le descritte tre differenti operazioni di auto verifica con una data periodicità o frequenza .

Ciò in particolare avviene operando nelle operazioni di verifica:

- una funzione di controllo sia temporale che di valore e di sequenza : imponendo dei controlli sul verificarsi di eventi predefiniti all'interno di finestre temporali predefinite e nel rispetto di sequenze predefinite ; verifica di valori numerici corrispondenti alle dette operazioni di auto verifica diagnostica, determinati o comunque calcolati dai processori ;

- rivelazione dell' occorrenza di fallimenti CCF nei processori mediante confronto di valori calcolati dai processori, oppure misurati tramite sensori disponibili nei processori o in generale nel multiprocessore , rispetto a valori corretti pr ecalcolati corrispondenti alle dette operazioni di auto verifica dei valori di sistema;

- implementazione di protocolli di determinazione dell' integrità dei processori basati su un controllo incrociato (cross-checking) , corrispondenti alle dette operazioni ai auto verifica dei risultati intermedi dei programmi.

A questo riguardo si ribadisce come le realizzazioni circuitali altamente integrate e omogenee dei multiprocessori siano quelle che garantiscono le più alte prestazioni e il minor costo del sistema, ma allo stesso tempo sono prone a problemi di fallimenti di modo comune CCF, che sono tanto più importanti e difficili da prevenire e/o rivelare quanto più le architetture sono appunto omogenee e altamente integrate. La presenza di fallimenti di modo comune CCF è il motivo principale per cui questo tipo di soluzioni architetturali e realizzative, non sono largamente utilizzate nel mondo delle applicazioni soggette alla normativa di sicurezza in campo automobilistico e industriale con conseguente perdita del beneficio economico che potrebbe essere realizzato

La soluzione descritta permette inoltre di combinare il software di controllo di macchine virtuali (ad esempio Hypervisor) con programmi software dedicati che implementano le dette operazioni di auto verifica e che mediante il loro utilizzo congiunto consentono di soddisfare i requisiti necessari a raggiungere i livelli di integrità di sicurezza funzionale richiesti nei campi applicativi industriale e automobilistico.

La soluzione descritta permette inoltre (come mostrato con riferimento alle formule 5) e 6)) di dosare le diverse operazioni di autoverifica al fine di ottenere la massima sicurezza funzionale con il minimo costo in termini di prestazioni o di complessità dell'hardware.

Il procedimento e architettura descritti permettono inoltre un monitoraggio logico e temporale, in particolare ottimizzato per i sistemi multicore con supporto per il controllo in cross-checking fra core;

implementazione di diagnostica sia per architetture con voting lool che con voting loo2;

monitoraggio di informazione relativa allo hardware del multicore (stato, temperatura, stato di alimentazione, ecc),

automonitoraggio

sistema in accordo con la specifica IEC 61508 2nd ed. in grado di venire integrato in sistemi SIL2 e SIL3 interfaccia standard da impiegare con il software; reazione configurabile;

possibilità di ottimizzazione per la tecnologia di implementazione scelta (FPGA o ASIC)

Naturalmente, fermo restando il principio dell'invenzione, i dettagli e le forme di attuazione possono variare, anche in modo rilevante, rispetto a guanto gui descritto a puro titolo di esempio, senza discostarsi dall'ambito di protezione. Tale ambito di protezione è definito dalle rivendicazioni annesse.

Nell'architettura di sicurezza considerata a titolo il modulo di controllo 15 può essere affiancato a un modulo voter che viene comunemente utilizzato nelle architetture multicanale per confrontare in modo continuo le uscite dei canali prima che gueste vengano utilizzate dal programma, o dagli attuatori, valutando secondo le tecniche di voting 1'uscita in sicurezza da fornire al programma. Una porta OR può ricevere 1'uscita del modulo di controllo 15 e 1'uscita del voter e provvedere a rilevare eventuali differenze fra tali uscite. Il rilevamento di una differenza determina una condizione di rilevamento di guasto che forza il sistema al raggiungere o mantenere un "safe state " così come definito per il programma che viene eseguito.

Il termine libreria è stato impiegato nella descrizione per definire i moduli software di programmi di autoverifica diagnostica, ma può essere applicato anche ai moduli di autoverifica dei dati di sistema (che come detto possono essere compresi nella stessa libreria di autoverifica diagnostica) e ai moduli di autoverifica di confronto fra risultati intermedi dei sotto-programmi.

Tali librerie o moduli software comprendenti i programmi di autoverifica possono essere ad esempio memorizzati in una memoria flash disponibile sullo scheda o integrato che comprende il sistema di elaborazione e caricati poi in memoria RAM dei moduli di elaborazione. Quantunque, il procedimento qui descritto sia riferito a un sistema di elaborazione, in particolare a multiprocessore, e modulo di controllo, le operazioni di scomposizione in sottoprogrammi di per sé si applicano anche al solo sistema di elaborazione, senza modulo di controllo indipendente, ossia forma oggetto della presente descrizione anche un procedimento di esecuzione di programmi in un sistema elettronico per applicazioni in sicurezza funzionale comprendente un sistema di elaborazione a singolo processore o multiprocessore, comprendente operare una scomposizione di un programma comprendente una funzione in sicurezza funzionale da eseguire tramite detto sistema in una pluralità di sottoprogrammi paralleli ; assegnare ciascun sotto-programma parallelo per 1'esecuzione ad un rispettivo modulo di elaborazione del sistema, in particolare un processore di detta architettura multiprocessore o macchina virtuale associata ad uno di detti processori, operare nel sistema, periodicamente secondo una frequenza di ciclo del programma durante il normale funzionamento di detto sistema, nell'ambito di detta funzione in sicurezza funzionale operazioni di auto verifica associate a ciascuno di detti sotto-programmi e ai corrispondenti moduli di elaborazione sui quali sono eseguiti, in cui dette operazioni di auto verifica comprendono operazioni di auto verifica diagnostica, che eseguono test autodiagnostici, operazioni di auto verifica di valori di sistema misurati, operazioni di auto verifica di confronto tramite opportuna combinazione dell'esecuzione di condizioni d'uso e/o LBIST, e dette operazioni di auto verifica comprendono di generare rispettivi dati di auto verifica relativi alle operazioni di auto verifica e di eseguire operazioni di controllo su detti dati di auto verifica, eseguire detta operazione di scomposizione del programma in una pluralità di sottoprogrammi paralleli ottenendo un obiettivo di copertura per ciascuna di dette operazioni di autoverifica associata a un rispettivo sotto-programma modulo di elaborazione, in modo tale che rispetti un obiettivo di probabilità di guasto dato.

Si noti che il termine "condizione d'uso" indica il fatto che le cosiddette operazioni dedicate devono essere inserite nel programma principale dall'utilizzatore scrivente il programma, in quantità e caratteristiche sufficienti a raggiungere gli obiettivi di copertura (come vedremo in seguito). Quindi tali operazioni rappresentano per 1'utilizzatore una "condizione" necessaria all'utilizzo del sistema elettronico nel campo della sicurezza funzionale.

Claims

RIVENDICAZIONI 1. Procedimento di esecuzione di programmi (P) in un sistema elettronico per applicazioni in sicurezza funzionale comprendente un sistema di elaborazione a singolo processore o multiprocessore (10) e un ulteriore modulo di controllo (15) indipendente, comprendente operare una scomposizione di un programma (P) comprendente una funzione in sicurezza funzionale (SF) da eseguire tramite detto sistema (10) in una pluralità di sotto-programmi paralleli (ΡΙ.,.Ρη); assegnare ciascun sotto -programma parallelo (ΡΙ.,.Ρη) per 1'esecuzione ad un rispettivo modulo di elaborazione (11) del sistema, in particolare un processore (Cl...Cm) di detta architettura multiprocessore (10) o macchina virtuale (Vl...Vn) associata ad uno di detti processori (Cl...Cm), operare nel sistema (10), periodicamente secondo una freguenza di ciclo (fcyC) del programma (P) durante il normale funzionamento di detto sistema (10), nell'ambito di detta funzione in sicurezza funzionale (SF) operazioni di auto verifica (A3ti, A3y3, Acht) associate a ciascuno di detti sotto-programmi (ΡΙ.,.Ρη) e ai corrispondenti moduli di elaborazione (11) sui guali sono eseguiti, caratterizzato dal fatto che dette operazioni di auto verifica (A3ti, A3y3, Achk) comprendono operazioni di auto verifica diagnostica (A3ti), che eseguono test autodiagnostici , operazioni di auto verifica (Asys) di valori di sistema misurati, operazioni di auto verifica (Achk) applicativa comprendenti operazioni di verifica di esecuzione di condizioni d'uso (Acou) e/o esecuzione di test LBIST (Abst) e dette operazioni di auto verifica (A3ti, A3y3, Achk) comprendono di generare rispettivi dati di auto verifica (D3ti, D3y3Dchk)) relativi alle operazioni di auto verifica (A3ti, Asys, Achk) e di eseguire operazioni di controllo (51, 61) su detti dati di auto verifica (D3ti,D3y3Dchk)), scambiare detti dati di auto verifica (D3ti, DsygDchk)) in continua tramite un protocollo (PL) di messaggi (MC) con l'ulteriore modulo di controllo (15) indipendente, eseguire almeno parte di dette operazioni di controllo (51, 61) in detto ulteriore modulo di controllo (15), eseguire detta operazione di scomposizione del programma (P) in una pluralità di sotto-programmi paralleli (Pl...Pn) ottenendo un obiettivo di copertura (k3ti, k^ , kchk) per ciascuna di dette operazioni di autoverifica (A3ti, , AChk) associata a un rispettivo sotto-programma (ΡΙ.,.Ρη) modulo di elaborazione (11), in modo tale che rispetti un obiettivo di probabilità di guasto (gl2; g) dato.
2. Procedimento secondo la rivendicazione 1, caratterizzato dal fatto che detto obiettivo di probabilità di guasto (gl2; g) dato è funzione di un valore di copertura (k3ti) determinato da dette operazioni di auto verifica diagnostica (A3ti), di un valore di copertura (ksys) determinato delle operazioni di auto verifica (Asys) di valori di sistema misurati sul sistema di elaborazione (10), di un valore di copertura (kchk) determinato dalle operazioni di auto verifica (Achk) applicativa comprendenti operazioni di verifica di esecuzione di condizioni d'uso (ACOu) e/o esecuzione di test LBIST (Abst)-
3. Procedimento secondo la rivendicazione 1, caratterizzato dal fatto che un calcolo di detto obiettivo di probabilità di guasto (gl2;g) comprende considerare detti sottoprogrammi (ΡΙ.,.Ρη) come ingressi di una funzione logica AND (AG) avente tanti ingressi guanti i sottoprogrammi (ΡΙ.,.Ρη), scomporre tale funzione logica AND (AG) in funzioni logiche AND a due ingressi aventi come ingressi le coppie che si possono comporre fra detti sottoprogrammi (ΡΙ.,.Ρη), calcolare il prodotto delle probabilità di guasto all' uscita di ciascuna porta AND a due ingressi, moltiplicato per il complemento della frazione dei guasti di modo comune (β) e del tempo di esposizione (texp) calcolare detto obiettivo di probabilità (g) in funzione del risultato dell'operazione precedente sommato a un valore ottenuto applicando funzioni OR a guasti di modo comune fra le coppie di sottoprogrammi (PI...Pn), moltiplicato per la frazione dei guasti di modo comune (β).
4. Procedimento secondo una delle rivendicazioni da 1 a 3, caratterizzato dal fatto che dette probabilità di guasto dei sottoprogrammi (ΡΙ.,.Ρη) sono valutate come funzione dell' unione fra detto valore di copertura (k3ti) determinato da dette operazioni di auto verifica diagnostica (A3ti) per ciascun sottoprogramma (ΡΙ.,.Ρη), detto valore di copertura (ksys) determinato delle operazioni di auto verifica (A3y3) di valori di sistema misurati sull' architettura (10), e detto valore di auto copertura (kchk) determinato dalle operazioni di auto verifica (Achk) applicativa comprendenti operazioni di verifica di esecuzione di condizioni d'uso (Acou) e/o esecuzione di test LBIST (Ab3t).
5. Procedimento secondo una delle rivendicazioni precedenti , caratterizzato dal fatto che detto sistema (10) implementa un modulo di gestione macchine virtuali (17) che genera macchine virtuali (Vl...Vn) sulle quali possono essere eseguiti detti sottoprogrammi (ΡΙ.,.Ρη).
6. Procedimento secondo una delle rivendicazioni precedenti , caratterizzato dal fatto che detta operazione di eseguire almeno parte di dette operazioni di controllo (51, 61) in detto ulteriore modulo di controllo (15), comprende di operare il confronto, di dati di auto verifica diagnostica (D3ti) relativi a risultati intermedi di calcoli eseguiti sui processori (Cl...Cm) del sistema di elaborazione a singolo processore o multiprocessore (10) secondo le operazioni di auto verifica diagnostica (D3ti), con un insieme di valori pre-calcolati e attesi (D3tia) memorizzati, operare il confronto di dati di auto verifica applicazione (Dchk,· ) prodotti da operazioni di auto verifica (Achk) applicativa comprendenti operazioni di verifica di esecuzione di condizioni d'uso (Acou) e/o esecuzione di test LBIST (Ab3t)), operare il confronto di dati di verifica di sistema (D3y3) rispetto a range attesi (Ratt) memorizzati.
7. Procedimento secondo la rivendicazione precedente , caratterizzato dal fatto che detto ulteriore modulo di controllo (15), è configurato per eseguire sui dati di autoverifica (D3ti, Dchk, D3y3) un controllo di valore per verificare che dati di auto verifica applicazione (Dchk) e/o di auto verifica diagnostica (D3ti) siano gli stessi o corretti; un controllo dei campi di valori , o range , per verifica che il valore di un dato di autoverifica misurato sul sistema (D3y3) appartenga a un campo di valori (Ratt) predefinito un controllo d'ordine verificare che 1'ordine dei messaggi sia corretto; un controllo di tempi d'arrivo dei messaggi.
8. Procedimento secondo una delle rivendicazioni precedenti, caratterizzato dal fatto che detta operazione di scambiare detti dati di verifica (D3ti, DsygDchk) )in continua tramite un protocollo (PL) di messaggi (MC) con 1'ulteriore modulo di controllo (15) indipendente comprende di organizzare i messaggi (MC) in canali logici (VC) secondo un livello gerarchico (L) che origina detti messaggi (MC) e secondo un canale fisico (IDO, IDI) che origina detti messaggi (MC).
9. Procedimento secondo la rivendicazione 8, caratterizzato dal fatto che detta operazione di eseguire almeno parte di dette operazioni di controllo (51, 61) in detto ulteriore modulo di controllo (15), comprende di eseguire operazioni di controllo intra-canale (ITC) applicate a messaggi che appartengono allo stesso canale logico (VC) e allo stesso canale fisico (ID); controllo inter-canale (INTC) applicati a messaggi (MC) che appartengono a canali logici (VC) diversi.
10. Procedimento secondo la rivendicazione 1, caratterizzato dal fatto che data una pluralità di moduli di elaborazione (11) cui sono assegnati rispettivi sottoprogrammi parallelo (ΡΙ.,.Ρη) per l'esecuzione, un sottoinsieme di detti programmi (P3) avendo un livello di integrità (LS2) inferiore a guello di un altro sottoinsieme di detti programmi (LSI), impiegare utilizzare una combinazione di dette operazioni di auto verifica (A3ti, A3y3, AChk)che comprendono dette operazioni di auto verifica diagnostica (A3ti ), che eseguono test autodiagnostici , operazioni di auto verifica (Asyg )di valori di sistema misurato, auto verifica (Achk)applicativa comprendenti operazioni 1'esecuzione di condizioni d'uso (Acou)e/o esecuzione di LBIST (Atot), per detto sottoinsieme di detti programmi (P3) avendo un livello di integrità (LS2) inferiore.
11. Procedimento secondo la rivendicazione 1, caratterizzato dal fatto che, date diverse modalità di guasto (FM1, FM2, FMn) comprende di impiegare per ciascuna modalità di guasto una combinazione che comprende operazioni appartenenti alle operazioni di auto verifica diagnostica (A3ti), che eseguono test autodiagnostici, operazioni appartenenti alle auto verifica (Achk)applicativa comprendenti operazioni 1'esecuzione di condizioni d'uso (Acou)e/o esecuzione di LBIST (Abst), o impiegare per ciascuna modalità di guasto (FM1, FM2, FMn) una combinazione che manca di almeno fra una operazioni appartenenti alle operazioni di auto verifica diagnostica (Asti), che eseguono test autodiagnostici, operazioni appartenenti alle auto verifica (Achk)applicativa comprendenti operazioni 1'esecuzione di condizioni d'uso (Acou)e/o esecuzione di LBIST (Ab3t)-
12. Procedimento secondo la rivendicazione 1, caratterizzato dal fatto che dette operazioni di auto verifica (Achk)applicativa sono operazioni di verifica di esecuzione di condizioni d'uso (Acou)
13. Procedimento secondo la rivendicazione 1, caratterizzato dal fatto che dette operazioni di auto verifica (Achk )applicativa sono operazioni di verifica di esecuzione di test LBIST (Abst)
14. Procedimento di esecuzione di programmi (P) in un sistema elettronico per applicazioni in sicurezza funzionale comprendente un sistema di elaborazione a singolo processore o multiprocessore (10) , comprendente operare una scomposizione di un programma (P) comprendente una funzione in sicurezza funzionale (SF) da eseguire tramite detto sistema (10) in una pluralità di sotto-programmi paralleli (ΡΙ.,.Ρη); assegnare ciascun sotto -programma parallelo (ΡΙ.,.Ρη) per 1'esecuzione ad un rispettivo modulo di elaborazione (11) del sistema, in particolare un processore (Cl...Cm) di detta architettura multiprocessore (10) o macchina virtuale (Vl...Vn) associata ad uno di detti processori (Cl...Cm), operare nel sistema (10), periodicamente secondo una freguenza di ciclo (fcyC) del programma (P) durante il normale funzionamento di detto sistema (10), nell'ambito di detta funzione in sicurezza funzionale (SF) operazioni di auto verifica (A3ti, A3y3, Achk) associate a ciascuno di detti sotto-programmi (ΡΙ.,.Ρη) e ai corrispondenti moduli di elaborazione (11) sui guali sono eseguiti, caratterizzato dal fatto che dette operazioni di auto verifica (A3ti, A3y3, AChk) comprendono operazioni di auto verifica diagnostica (A3ti), che eseguono test autodiagnostici , operazioni di auto verifica (A^ ) di valori di sistema misurati, operazioni di auto verifica (AChk) applicativa comprendenti operazioni di verifica di esecuzione di condizioni d'uso (Acou) e/o esecuzione di test LBIST (Abst) e dette operazioni di auto verifica (A3ti, A3y3, Achk) comprendono di generare rispettivi dati di auto verifica (D3ti, D3y3Dchk)) relativi alle operazioni di auto verifica (A3ti, Asys, Achk) e di eseguire operazioni di controllo (51, 61) su detti dati di auto verifica (D3ti,D3y3Dchk)), eseguire detta operazione di scomposizione del programma (P) in una pluralità di sotto-programmi paralleli (Pl...Pn) ottenendo un obiettivo di copertura (A3ti, Asys, Achk) per ciascuna di dette operazioni di autoverifica (Asti, Aays, Achk) associata a un rispettivo sotto-programma (ΡΙ.,.Ρη) modulo di elaborazione (11), in modo tale che rispetti un obiettivo di probabilità di guasto (gl2; g) dato.
15. Sist ema elettronico con sicurezza funzionale comprendente un sistema di elaborazione a singolo processore o multiprocessore (10) e un ulteriore modulo di controllo (15) indipendente , configurata per eseguire i passi del procedimento secondo una delle rivendicazioni da 1 a 13.
16. Prodotto informatico caricabile nella memoria di almeno un elaboratore, il prodotto informatico comprendendo porzioni di codice software adattate per eseguire i passi del procedimento secondo una delle rivendicazioni da 1 a 14 nel momento in cui il programma viene eseguito su almeno un computer .