IT201800007412A1 - Sistema elettronico modulare per la verifica della corretta esecuzione di operazioni eseguite dal sistema stesso - Google Patents

Sistema elettronico modulare per la verifica della corretta esecuzione di operazioni eseguite dal sistema stesso Download PDF

Info

Publication number
IT201800007412A1
IT201800007412A1 IT102018000007412A IT201800007412A IT201800007412A1 IT 201800007412 A1 IT201800007412 A1 IT 201800007412A1 IT 102018000007412 A IT102018000007412 A IT 102018000007412A IT 201800007412 A IT201800007412 A IT 201800007412A IT 201800007412 A1 IT201800007412 A1 IT 201800007412A1
Authority
IT
Italy
Prior art keywords
subsystems
algorithm
inputs
execution
outputs
Prior art date
Application number
IT102018000007412A
Other languages
English (en)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed filed Critical
Priority to IT102018000007412A priority Critical patent/IT201800007412A1/it
Priority to PCT/IB2019/056200 priority patent/WO2020021415A1/en
Publication of IT201800007412A1 publication Critical patent/IT201800007412A1/it

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/18—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits
    • G06F11/182—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits based on mutual exchange of the output between redundant processing components
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
    • G06F11/10—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
    • G06F11/1004—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's to protect a block of data words, e.g. CRC or checksum
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1479—Generic software techniques for error detection or fault masking
    • G06F11/1487—Generic software techniques for error detection or fault masking using N-version programming
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1497—Details of time redundant execution on a single processing unit
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/18—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits
    • G06F11/183—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits by voting, the voting not being performed by the redundant components
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0796—Safety measures, i.e. ensuring safe condition in the event of error, e.g. for controlling element
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/18—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits
    • G06F11/187—Voting techniques
    • G06F11/188—Voting techniques where exact match is not required

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Hardware Redundancy (AREA)
  • Debugging And Monitoring (AREA)

Description

TITOLO
“Sistema elettronico modulare per la verifica della corretta esecuzione di operazioni eseguite dal sistema stesso.“
DESCRIZIONE
Campo di applicazione dell’invenzione
La presente invenzione si riferisce al campo dei sistemi “SIL” (safety integrity level) e più precisamente a tutti quei sistemi nei quali è necessario garantire la certezza di esecuzione delle operazioni. In particolare, la presente invenzione si riferisce ad un sistema elettronico modulare per la verifica della corretta esecuzione di operazioni eseguite dal sistema stesso.
Stato della tecnica
E’ noto che al fine di assicurare un certo grado di affidabilità delle operazioni (normalmente implementate in software) eseguite da un sistema elettronico, questo deve essere strutturato rispettando le norme SIL (Safety Integrity Level) norma IEC 62061.
Il sistema deve cioè essere progettato in maniera tale che ogni guasto abbia una influenza controllata sulla affidabilità e sulla sicurezza di funzionamento del sistema stesso.
Nella progettazione hardware per garantire un determinato grado di affidabilità si usano le tabelle FMEA. La FMEA (Failure Mode and Effect Analysis o Analisi dei modi e degli effetti dei guasti) è una metodologia utilizzata per analizzare le modalità di guasto o di difetto di un processo, prodotto o sistema. Generalmente (ma non necessariamente) l'analisi è eseguita preventivamente e quindi si basa su considerazioni teoriche e non sperimentali.
Valutare l’affidabilità del software invece è molto più difficile: i sistemi oggi in uso hanno problemi di “pesantezza”, complicazione e costi elevati, pertanto sono di attuazione onerosa, in quanto debbono essere basati su strumenti singolarmente certificati (sistemi operativi, compilatori etc …).
Una normale realizzazione prevede un sistema duplicato normalmente alimentato da situazioni di ingresso diverse ed una logica a valle con il compito di confronto e verifica della correttezza delle elaborazioni a monte (detto Voting).
Le limitazione di questa architettura risiedono nella presenza di una parte singola, non controllata, (hardware o software) il cui malfunzionamento implica un malfunzionamento dell’intero sistema.
Sommario dell’invenzione
Scopo della presente invenzione è quello proporre un sistema elettronico modulare per la verifica della corretta esecuzione di operazioni eseguite dal sistema stesso, volto a superare tutti gli inconvenienti suddetti.
Si tratta di un innovativo “software concept”. Il sistema raggiunge l’affidabilità e la sicurezza di funzionamento richiesta tramite una architettura modulare che dà l’evidenza che il sistema di progettazione funziona correttamente tramite il confronto continuo dei risultati delle elaborazioni eseguite in diverse e differenti unità.
Il sistema comprende più unità anche diverse, connesse fra loro da una rete veloce e ciascuna in grado di eseguire tutte le elaborazioni necessarie.
La sicurezza di funzionamento deriva dal fatto che ciascuna unità elabora non solo i propri ingressi ottenendo il proprio stato interno, ma anche gli ingressi ricevuti dalle altre unità con la possibilità di controllare la corretta elaborazione degli stati interni sia propri che delle altre unità.
Ciascuna unità, disponendo di tutti gli stati interni (controllati in termini di correttezza delle elaborazioni), applicando un algoritmo simmetrico, che sarà in seguito descritto, è in grado di ottenere le uscite che sono identiche per tutte le unità.
Aumentando la modularità pertanto si riesce a raggiungere l’affidabilità e la sicurezza di funzionamento richiesti (sotto soglia).
Questa metodologia di realizzazione di progetto può essere considerata una valida alternativa alle metodologie standard di sviluppo software (ad esempio DOD 178 C) in quanto riesce a garantire la certezza di funzionamento in maniera differente e meno onerosa utilizzando una modalità di confronto continuo durante l’esecuzione in funzionamento.
Questa metodologia inoltre rimuove la necessità del Voting eliminando l’unico punto singolo dove risiede la maggior criticità del sistema.
Questo e’ ottenuto grazie al fatto che ciascuna unità elabora i dati con gli ingressi di tutte le unità presenti nel sistema (questo da la possibilità di un confronto byte a byte) e tramite un algoritmo simmetrico riesce a calcolare le uscite simmetriche che sono identiche su ogni unità.
E’ oggetto della presente invenzione un sistema elettronico modulare per la verifica della corretta esecuzione di operazioni eseguite da detto sistema elettronico, caratterizzato dal fatto che comprende:
- un numero N maggiore di 1 di sottosistemi elettronici in parallelo, ognuno atto a:
- ricevere agli ingressi dati esterni,
- eseguire dette operazioni ed emettere il risultato alle sue uscite,
- ricevere ad altri ingressi le uscite degli altri sottosistemi elettronici, - rieseguire dette operazioni su detti ingressi ricevuti dagli altri sottosistemi elettronici ed emettere in uscita i risultati delle riesecuzioni;
- un blocco di elaborazione simmetrica atto a ricevere e confrontare tutte le uscite di detti sottosistemi elettronici, e decidere quale di dette uscite dei sottosistemi elettronici scegliere come valore di detta corretta esecuzione di operazioni che emette all’uscita, in base alla simmetria verificata tra dette uscite.
E’ particolare oggetto della presente invenzione un sistema elettronico modulare per la verifica della corretta esecuzione di operazioni eseguite dal sistema stesso, come meglio descritto nelle rivendicazioni, che formano parte integrante della presente descrizione.
Breve descrizione delle figure
Ulteriori scopi e vantaggi della presente invenzione risulteranno chiari dalla seguente descrizione particolareggiata di un esempio di realizzazione della stessa (e di sue varianti), e con riferimento ai disegni annessi a puro titolo esplicativo e non limitativo, in cui:
nella figura 1 è indicato uno schema logico di massima del “software concept” oggetto della presente invenzione;
nelle figure 2 e 3 è mostrato un esempio di realizzazione del sistema oggetto della presente invenzione;
nella figura 4 è mostrato uno schema a blocchi di un esempio di realizzazione del sistema;
nella figura 5 è mostrato uno schema a blocchi di metodologia di generazione del codice eseguibile (compilazione) nelle varie e diverse unità del sistema.
Gli stessi numeri e le stesse lettere di riferimento nelle figure identificano gli stessi elementi o componenti.
Descrizione di dettaglio di esempi di realizzazione
Con riferimento alle figure, il sistema comprende N sottosistemi posti in parallelo, realizzati tramite strutture di elaborazione e memoria, ad esempio N unità a microprocessore atte a svolgere le medesime operazioni, ma con struttura hardware/software non necessariamente uguale.
Nella figura 1 è indicato uno schema logico di massima del “software concept” oggetto della presente invenzione, in cui sono evidenziate:
Strutture dati:
I: Struttura dati di ingresso
S: Stato del sistema (il valore futuro e’ dipendente da se stesso e gli ingressi del sistema)
OUT: Dati di uscita del sistema (es… velocità da visualizzare, situazioni di allarme, etc …)
Algoritmi:
CP: Algoritmo puramente combinatorio che calcola il successivo valore di S SYM Algoritmo simmetrico puramente combinatorio che calcola il valore di OUT in funzione di tutti gli S (simmetrico perché ogni tipo di permutazione di S non varia l’uscita OUT).
L’architettura I, CP , S e’ ad una macchina a stati finiti, normalmente realizzata tramite una architettura hardware.
In questo caso viene utilizzato un linguaggio software per realizzare questa architettura.
In pratica vi e’ una procedura che prende in ingresso i dati contenuti nella struttura I ed S e calcola i nuovi dati della struttura S, come se fosse una rete combinatoria ma realizzata tramite istruzioni.
Un esempio di realizzazione del sistema è qui di seguito descritto con riferimento alle figure 2 e 3.
Nell’esempio di figura 2 sono presenti quattro sistemi di elaborazione interconnessi (Linux 1, Linux 2, Hercules 1 e Hercules 2) .
Per ottenere i codici eseguibili per sistemi diversi si parte da un unico codice sorgente CR (figura 5) che verrà compilato con diversi sistemi operativi bios e librerie (es Linux, Hercules, Windows) per ottenere diversi codici eseguibili che saranno eseguiti dai diversi processori.
Risulta pertanto che vi è un unico algoritmo di codice sorgente CR che è l’unica parte comune del sistema.
Nulla vieta di poter duplicare l’algoritmo CR e farlo codificare con due procedure diverse per rimuovere l’unico punto singolo.
A questa rete possono aggiungersi ulteriori sottosistemi di tipo noto (Display 1 e Display 2 ed eventuale PC) per visualizzazioni o controlli.
Questi elementi aggiuntivi avranno le medesime funzionalità degli altri, ad esclusione della lettura ingressi. Questi sottosistemi normalmente possono essere utilizzati per la visualizzazione dei dati, tipo il Display ed il PC di debug,
Ciascun sottosistema leggerà gli ingressi, li invierà a tutti gli altri e creerà le uscite simmetriche.
Ciascun sottosistema potrà basarsi su una area dati, di cui un esempio è rappresentato in figura 3, in cui le aree tratteggiate sono quello coinvolte nella variazione dati ed in dettaglio:
● Tratteggio obliquo area o letta o caricata dalla ricezione
● Tratteggio quadrettato area calcolata dall’algoritmo ‘CP’
● Area grigia area calcolata dall’algoritmo ‘OUT’
Si può suddividere il ciclo di elaborazioni in tre Fasi.
Fase 1 - Lettura ingressi, elaborazione e trasmissione
Viene utilizzata l’area personale
In questa fase accadono le seguenti azioni:
1. Lettura ingressi (caricamento area ‘I’);
2. Calcolo stato futuro in funzione di stato presente ed ingresso (calcolo area ‘S’);
3. Trasmissione dati I/S/OUT agli altri processori (l’area personale) (trasmissione area ‘I’ ‘S’ ‘OUT’).
Ognuno dei sottosistemi legge dall’esterno un dato di ingresso I, lo elabora tramite l’algoritmo CP e calcola lo stato futuro S.
Ogni unità esegue le medesime operazioni, predefinite in base alle specifiche necessità elaborative, e descritte nell’algoritmo CP il quale realizza una macchina a stati finiti.
Infatti il valore dello stato S all’istante x+1 è funzione f dello stato all’istante x, e dell’ingresso acquisito in quell’istante secondo la classica relazione:
S(x+1) = f (S(x), I(x)),
L’ingresso I è teoricamente uguale per tutti gli N processori.
Di fatto nella realtà operativa si possono verificare piccole diversità dovute a specifiche situazioni, quali campionamento in istanti diversi tra loro, o variazione di parametri locali del sistema tipo frequenza del quarzo o precisione di eventuali ingressi analogici.
Si noti che queste piccole diversità possono creare dei percorsi divergenti fra gli stati dei vari sottosistemi.
Ogni sottosistema potrà evolvere per il suo percorso (che viene considerato diverso) e vi sarà in seguito un algoritmo SYM che ricaverà uscite identiche per tutti i sottosistemi.
Fase 2 – Ricezione da altri processori, elaborazione, controllo
Questa fase viene attivata ad ogni singola ricezione del pacchetto dati I/S/OUT trasmesso.
Vengono utilizzate le aree ricezione e confronto
In questa fase accadono le seguenti azioni:
1. Copia solo ingressi da ricezione a area confronto (caricamento area ‘I’) 2. Calcolo stato futuro in funzione di stato presente ed ingresso su area confronto (calcolo area ‘S’)
3. Confronto dati fra ricezione e confronto (Confronto aree ‘I’ ‘S’ ‘OUT’)
Si nota che in questo caso vengono copiati esclusivamente gli ingressi del sistema e viene eseguito l’algoritmo CP ottenendo in S lo stato futuro.
Un successivo controllo (Fase 3) verificherà la corretta evoluzione.
In pratica, alla ricezione del messaggio da processore X sono stati eseguiti da tutti i processori i medesimi calcoli che il processore X aveva eseguito localmente nella sua area privata con i medesimi ingressi.
Questa azione controlla che l’evoluzione dello stato S abbia la medesima evoluzione (bit a bit) dallo start del sistema.
Si sottolinea che i processori possono essere di tipo diverso con sistemi operativi diversi ed anche con un codice oggetto diverso, ottenuto però dal medesimo sorgente.
Fase 3 – Ricezioni di tutti, Uscite simmetriche Controllo, Nuove uscite simmetriche Calcolo.
Questa fase viene attivata al termine di tutte le ricezioni dei pacchetti dati I/S/OUT trasmessi.
In questa fase le aree confronto sono già state caricate (ingressi) e verificate (stato e uscite) come da fase 2.
Vengono utilizzate le aree ricezione e confronto e viene creata l’area OUT personale. In questa fase accadono le seguenti azioni:
1. Controllo uscite simmetriche (tutti i campi OUT di area confronto devono essere identici bit a bit al campo OUT personale) (nota: la uscite saranno calcolate nel passo successivo 2), il controllo avverrà nel ciclo successivo).
2. Calcolo delle uscite simmetriche ovvero creazione del nuovo campo OUT nell’area personale che sara’ successivamente trasmesso alla fase 1
3. Attivazione uscite.
4. Controllo che tutti i processori abbiano ricevuto i dati da tutti gli altri per iniziare nuovo ciclo (Uguaglianza di tutte le aree ‘OUT’)
Si nota che il calcolo SYM del nuovo OUT viene fatto dopo il controllo del precedente.
Il campo OUT verrà trasmesso nel punto 1 di tale sequenza.
La prima volta in effetti si confrontano esclusivamente i valori di inizializzazione del campo OUT.
Ovviamente vi sono più possibili alternative per risolvere lo scambio dati.
L’alternativa qui scelta è quella di inviare un solo messaggio per ogni coppia di sottosistemi, contenente tutti i campi I/S/OUT.
Ovviamente sono comunque possibili alternative che ipotizzano lo scambio di più messaggi, per esempio I/S ed OUT separati.
Questa scelta risulta vantaggiosa per sistemi semplici, infatti in questo caso il campo I/S/OUT è circa 130 bytes per cui conviene trasferirlo in un solo messaggio.
Come controindicazione si ha però il fatto che il confronto del campo OUT viene fatto nel passo successivo.
Si nota che l’algoritmo SYM deve dare le medesime uscite per ogni tipo di permutazione degli stati dei processori.
Questo risulta necessario per avere su tutti i sottosistemi le medesime uscite OUT che in questo passo sono verificate bit a bit.
Sommariamente si può dire che la funzione f su definita è realizzata tramite reti combinatorie, alle cui uscite presentano registri in logica sequenziale con memoria, e retroazione all’ingresso.
Ognuno degli N processori / componenti (sottosistemi) riceve dati I dall’esterno, trasmette lo stato di uscita a tutti gli altri ed esegue le stesse operazioni su ognuno degli ingressi, seguendo i suoi modi di agire dati dalla propria costituzione interna, procedendo di fatto in modo plesiocrono, vale a dire quasi sincrono con gli altri. Di fatto si ottiene che ognuno controlla l’elaborazione degli altri, e ricontrolla sé stesso, quindi il sistema si autocontrolla.
In base agli aspetti generali della presente invenzione, con riferimento alla figura 4, sono indicati con CPS1 ……CPSN N sottosistemi posti in parallelo, le cui uscite sono fornite ad un blocco SYM che le elabora in base ad un “algoritmo simmetrico “, in base al quale decide quale delle uscite di CPS1 ……CPSN scegliere e fornire alla propria uscita O. In teoria, dato il reciproco controllo eseguito da CPS1 ……CPSN, gli ingressi di SYM dovrebbero essere tutti uguali, e quindi uguali all’uscita O, nell’ipotesi che le differenze eventuali tra le N uscite derivino da calcoli effettuati correttamente da ognuno.
Di fatto possono esistere differenze, date da diversi fattori, ad esempio guasti intervenuti, da cui l’esigenza della scelta da parte di SYM.
Nel caso di verifica di dissimmetrie, SYM rileva un errore, ad esempio dovuto al fatto che una delle uscite di CPS1 ……CPSN ha un valore troppo dissimile dagli altri, sopra una soglia di tolleranza di diversità, quindi SYM fornirà in uscita uno degli altri valori, e segnalerà l’errore all’esterno, ad esempio bloccando l’esecuzione del programma, oppure scegliendo come valore corretto un valore tra quelli simili, oppure una loro media.
Quindi SYM effettivamente determina quale valore preferire: ad esempio se si calcola la velocità di un treno in rapporto alla massima raggiungibile, allora l’uscita scelta sarà quella di valore massimo tra gli ingressi.
Di seguito viene descritto un esempio di realizzazione dell’invenzione, con maggior dettaglio riferito alla parte software, nell’ipotesi di realizzare un sistema hardware/software, con riferimento alle figure.
In seguito saranno utilizzate le seguenti definizioni:
L’architettura Software realizza un gestore generico di algoritmi (SequenceController) atto a garantire la corretta esecuzione di un algoritmo (CriticalProcess) tramite esecuzione parallela su più sottosistemi hardware/software, sulla base delle seguenti ipotesi:
● Architettura Hardware basata su più processori di tipologia diversa.
● Lettura degli ingressi del sistema da parte di ciascun processore.
● Esecuzione dell’algoritmo (CriticalProcess) su tutti i processori in parallelo, con ingressi diversi.
● Scambio dati fra i vari processori.
● Ri-esecuzione da parte di ciascun processore con i dati di ingresso ricevuti da tutti gli altri, utilizzando il medesimo algoritmo o la medesima funzione.
● Confronto della corretta elaborazione.
● Calcolo di risultati comuni tramite algoritmo simmetrico (SymmPostElab).
Questa sequenza permette l’elaborazione di un algoritmo in maniera virtuale perché viene eseguito e confrontato su processori diversi, con l’eseguibile ottenuto tramite percorsi di compilazione diversi, per cui i risultati del generico algoritmo possono ritenersi corretti anche se non viene certificata la correttezza del compilatore o del sistema operativo o del protocollo di comunicazione.
Un esempio viene illustrato nella figura 5 dove la parte ‘CR’ viene compilata tramite due sistemi operativi e funzioni base diversi ‘LINUX’ ed ‘HERCULES’, come su descritto.
Ogni possibile errore viene rilevato dal gestore dell’algoritmo stesso (SequenceController)
Nell’esempio specifico di realizzazione hardware non limitativo su descritto, partecipano quattro processori, montati su due schede uguali. Ogni scheda equipaggia un μP Hercules ed un μP iMX6 con sistema operativo Linux.
Per quanto concerne la logica di base dell’algoritmo (CriticalProcess), questo deve essere implementato in maniera tale da realizzare una macchina a stati del terzo tipo (ad esempio del tipo noto di macchina di Mealy) dove sono esplicitate le variabili di ingresso e di stato ( I sono gli ingressi , S e’ lo stato , OUT le uscite ).
L’algoritmo (CriticalProcess) prende in ingresso lo stato presente e gli ingressi del sistema e fornisce lo stato futuro.
I vari stati saranno ulteriormente elaborati da SYM (SymmPostElab) ottenendo le uscite (OUT) identiche in tutti i processori.
Queste uscite potranno essere visualizzate dando una informazione coerente e potranno dare luogo ad azioni sulla macchina.
Per quanto concerne la base dati dell’algoritmo, il linguaggio utilizzato nella scrittura del sistema (SequenceController+CriticalProcess+SymmPostElab) è il linguaggio “C”, descrivendo una logica di tipo hardware tramite una scelta opportuna della base dati.
Infatti la base dati è stata raccolta in strutture che contengono le informazioni dei vari campi:
Per esempio le informazioni di un processore sono divise nelle seguenti strutture: struct S_UHL_PROC_DATA
{
struct S_UHL_PROC_INPUT sProcInput ; // 10
struct S_UHL_PROC_STATUS sProcStatus ; // 32
struct S_UHL_PROC_OUTPUT sProcOutput ; // 16
};
L’algoritmo (CriticalProcess) pertanto prenderà le informazioni da sProcInput e sProcStatus e ricaverà i nuovi valori di sProcStatus.
Tutta questa struttura verrà trasmessa via ethernet e sarà ricevuta da tutti gli altri processori.
Pertanto si creera’ un array di strutture di dimensione MAX_PROC pari al numero massimo di processori presenti (notare i campi uProcData e uaOthData[MAX_PROC]. struct S_UHL_TOP_DATA
{
char sGlbStatus ;
char sSpare[3] ;
char sRxStatus[MAX_PROC] ;
union U_UHL_PROC_DATA uProcData ;
union U_UHL_PROC_DATA uaOthData[MAX_PROC] ;
struct U_UHL_ETH_RX_ALL pRxEth[DIM_SEQ_W] ;
};
Nell’array uaOthData[MAX_PROC] si caricheranno al momento della ricezione tutte le elaborazioni di tutti i processori presenti, se stesso compreso.
L’algoritmo (SymmPostElab) utilizzerà le informazioni presenti nell’array uaOthData[MAX_PROC] e creerà il suo campo sProcOutput che poi sarà confrontato byte a byte con i restanti campi.
Come precedentemente detto le informazioni vengono trasferite in binario per ottimizzare la velocità di scambio dati.
Per questa ragione i vari processori devono avere la medesima algebra ovvero essere tutti big endian o little endian ed avere la medesima rappresentazione dei float se questi vengono utilizzati (non e’ il nostro caso).
Normalmente questo non e’ un requisito oggi stringente perché PC , ARM , CORTEX sono tutti little endian e la rappresentazione float double viene definita dalle normative IEEE 754.
Per la comunicazione fra i vari processori può essere utilizzata una piccola rete Ethernet a 100 mBit confinata spazialmente e utilizzante il protocollo tcp-ip.
Pertanto ogni ScanTime circolerà un messaggio tcp-ip per ogni coppia di processori diversi (N*(N-1)): nel nostro caso (4*3).
Il gestore dell’algoritmo (SequenceController) tramite la funzione (fBios2User_LoopCall) dovrà essere chiamato ogni delta T (TicTime) con un tempo sufficientemente piccolo rispetto ai ritardi del sistema che dovrà controllare (ScanTime).
Nel nostro esempio TicTime è di 10 mSec e ScanTime di 100 mSec.
Dovrà inoltre essere chiamato anche ad ogni ricezione di un messaggio Ethernet. Il codice sviluppato dovrà essere inserito in ambienti di compilazione diversi, con sistemi operativi diversi e protocolli di comunicazione diversi, per cui è necessario stabilire una chiara interfaccia fra la parte controllata (SequenceController+CriticalProcess+SymmPostElab) e l’esterno.
Si sottolinea il fatto che quanto sviluppato è di natura “astratta”, perché è scritto in “C” e avrà realtà diverse solo dopo la compilazione creando eseguibili diversi.
Pertanto, anche l’interfaccia in qualche maniera dovrà essere di natura “astratta”. Si riesce in maniera efficace a risolvere questo problema definendo in maniera molto precisa una serie di funzioni che definiscono lo scambio dati fra il presente sistema e l’ambiente esterno.
L’ambiente esterno, poiché contiene tutte le interfacce verso l’hardware, viene chiamato Bios.
Il presente sistema viene chiamato User.
Queste funzioni sono di due tipi:
1. Funzioni da ambiente esterno (Bios) a presente sistema (User)
2. Funzioni da presente sistema (User) a ambiente esterno (Bios) Sono già state identificate due funzioni del primo tipo:
1. fBios2User_LoopCall
2. fBios2User_ReceiveEthernet
Vi sono molteplici funzioni del secondo tipo che dovranno essere tutte presenti nel (Bios) per non creare errori di compilazione.
Queste funzioni sono definite nel file “BiosLib_MultiProc.h”.
I passi fondamentali di funzionamento del gestore dell’algoritmo (SequenceController) sono i seguenti:
● Lettura ingressi dal campo.
● Esecuzione dell’algoritmo applicando gli ingressi letti e calcolo stato futuro.
● Invio ingressi+stato agli altri processori presenti nel sistema.
● Attesa dati dagli altri processori e ricezione degli ingressi e stati degli altri partecipanti.
● Esecuzione dell’algoritmo applicando gli ingressi ricevuti dagli altri processori.
● Confronto byte a byte dello stato ricevuto e lo stato internamente calcolato (questo verifica che le elaborazioni nei processori siano avvenute correttamente).
● Ripetizione per ogni processore presente (compreso esso stesso).
● Esecuzione di un algoritmo simmetrico sui vari risultati di tutti i processori presenti nel sistema per ricavare le uscite da visualizzare, che ovviamente sono identiche su tutti i processori, anche se dipendono da stati diversi, grazie alla simmetria dell’algoritmo finale.
● Controllo della uguaglianza fra i vari risultati dell’algoritmo simmetrico. Questo meccanismo controlla i risultati passo-passo delle elaborazioni eseguite per ogni processore.
In pratica se partecipano quattro processori, ciascuno di loro controllerà le elaborazioni degli altri tre.
Pertanto in ogni processore saranno presenti oltre che il proprio (stato+ingresso) anche tutti quelli degli altri processori.
Questi saranno inizializzati al medesimo valore ed evolveranno passo-passo e si controlleranno ad ogni passo.
Nell’esempio descritto, per comodità un processore invierà i dati anche a se stesso per cui vi saranno 1+4 immagini.
Si sottolinea che i processori sono diversi (nell’esempio due a due) e si stanno confrontando risultati ottenuti tramite codice binario diverso e ricavato da percorsi di compilazione diversi.
Inoltre, gli algoritmi sono eseguiti da processori con sistemi operativi diversi, che trasferiscono i dati tramite degli stack diversi per cui si può ritenere che se è corretto sia l’algoritmo che il suo gestore, nulla di esterno può alterare il funzionamento senza che il sistema se ne accorga.
Risulta sufficiente pertanto certificare (per affidabilità, secondo le procedure SIL) esclusivamente il gestore ed il protocollo ed escludere dalla certificazione il processore, il sistema operativo, lo stack del protocollo ed il compilatore risparmiando così un enorme lavoro.
Si ritiene inoltre che, poiché il confronto viene fatto byte a byte sullo stato intero, la certezza raggiuta possa essere superiore o analoga a quella della massima richiesta SIL.
Ovviamente se si dovessero utilizzare architetture interamente SIL si potrebbe in questa maniera, con il gestore di algoritmi della presente invenzione, raggiungere un grado di sicurezza superiore.
Tutta l’area dati (sia quella descritta in riferimento alla fig 3, sia quella utilizzata dal sequence controller) che viene utilizzata è raccolta in una struttura dati contigua ed è protetta tramite l’uso di un codice di ridondanza ciclica crc (nell’esempio a 32 bit).
Questo crc viene calcolato alla fine della elaborazione dell’algoritmo e controllato all’inizio dello stesso.
Questo controllo fornisce una ulteriore garanzia alla integrità dei dati.
In pratica quando il gestore rilascia il controllo al resto del software, alla sua successiva richiamata controllerà che nessuno abbia alterato il parco dati su cui stava lavorando.
Ci si può in questa maniera accorgere di un errato funzionamento del sistema operativo o stack che in maniera non voluta alteri l’area dati riservata al gestore più algoritmo.
Nel dettaglio:
Le funzioni chiamate da (Bios) a (User) sono sostanzialmente due:
1. fBios2User_LoopCall
2. fBios2User_ReceiveEthernet
Queste funzioni sono presenti nel file “UHL_Entry_Main.c”
Queste funzioni prima di fare qualsiasi operazione calcolano e controllano il ck_sum, in base al criterio crc, e se corretto consentono la successiva elaborazione, altrimenti segnalano errore escludendosi dal servizio.
L’acquisizione di misure potrebbe richiedere l’esecuzione di programmi sotto interrupt.
Ovviamente se questi utilizzassero l’area dati comune altererebbero il crc e creerebbero un errore.
Per questo si utilizza una ulteriore area gestita nella stessa maniera dell’area principale.
Prima della esecuzione dell’interrupt verrà verificato il crc che dopo l’esecuzione della funzione di acquisizione sarà ricalcolato per un ulteriore controllo successivo.
In questa maniera, analogamente all’ambiente main, si controlla l’area dati utilizzati sotto interrupt.
Ovviamente dovrà esistere una funziona chiamata dall’algoritmo principale che fornirà allo stesso il valore risultato dalle misure acquisite.
Per garantire la consistenza dei dati questa funzione deve essere eseguita in maniera atomica.
L’esistenza del crc controlla inoltre l’esecuzione atomica di detta funzione, perché se questa funzione di lettura dovesse essere interrotta dall’interrupt si verificherebbe un errore di crc all’inizio della funzione interrupt stessa.
Nel presente esempio esiste la seguente funzione “Bios to User”:
void fBios2User_Int_DigIn_SlopeEvent( …. )
che fornisce la misura del periodo ad ogni fronte rilevato.
Analogamente potrebbero esserci funzioni similari, chiamate sotto interrupt, atte a fornire in maniera asincrona i dati al sistema (CriticalProcess).
Esiste anche in questo caso una area dati su cui lavora la parte interrupt per eseguire delle misure che saranno considerate ingressi a tutti gli effetti.
Si veda più oltre la descrizione di (Controllo cksum interrupt) per la consultazione del codice.
Come già detto è possibile validare l’algoritmo (CriticalProcess) in un processore qualsiasi, perché si è certi che la sua esecuzione è indipendente dal processore, compilatore, sistema operativo e stack.
Pertanto, per semplicità e riduzione dei costi conviene eseguire il test dell’algoritmo in simulato, per cui nel sistema sarà presente un simulatore che potrà visualizzare in chiaro tutte le variabili di ingresso, stato e uscita per un preciso ed esaustivo controllo.
In questa maniera potranno pertanto essere verificati:
● Tutte le variabili in ingresso PROC_INPUT
● Tutte le variabili di stato PROC_STATUS ed in dettaglio
o Il corretto incremento di TicCounter
o Le uscite locali e gli allarmi locali
o La correttezza dei vari cambiamenti di stato.
o I valori temporanei di gestione
o I corretti incrementi dei temporizzatori.
● Tutte le variabili di uscita PROC_OUTPUT ed in dettaglio:
o Le uscite simmetriche che saranno visualizzate
o Gli allarmi che potranno eseguire azioni sulla macchina
In questo modo si consente quindi una verifica dettagliata del software non solo ai morsetti (intesi come ingressi ed uscite del sistema) ma visualizzando e controllando anche tutti i risultati intermedi.
Nel software sarà inoltre presente un simulatore di ingressi per poter testare l’algoritmo fornendo tutte le variazioni di ingressi desiderate e consentendo quindi di testare il software su PC (off line).
Nel seguito, per maggiore chiarezza saranno descritte o riportate le varie parti di codice che eseguiranno le varie verifiche citate.
Al fine di controllo dell’evoluzione di stato, ad ogni ricezione messaggio saranno eseguite le seguenti operazioni
1. Copia degli ingressi : Gli ingressi ricevuti dal processore X saranno copiati in una sua struttura dedicata: uaOthData[X].
2. Elaborazione Processo Critico : Sarà chiamata la funzione che calcolerà lo stato successivo.
3. Confronto Strutture : Sarà eseguito un confronto byte a byte su tutta l’area dati del processo (struct S_UHL_PROC_DATA)
Questo controllo verifica che il processore X ha eseguito correttamente la funzione di aggiornamento stato.
Per quanto concerne il controllo dell’uguaglianza delle uscite, alla ricezione dei messaggi di tutti i processori saranno eseguite le seguenti operazioni
1. Controllo TicCounter fra tutti i processori controllando che tutti abbiano eseguito i medesimi passi di elaborazione.
2. Calcolo delle proprie PROC_OUTPUT tramite SymmPostElab
3. Confronto byte a byte dei dati in uscita
Per quanto concerne il controllo cksum all’ingresso main (punto di chiamata principale della funzione che scandisce il sequence controller es: fU_GetPointer_MainData ), prima di leggere il pointer dei dati di lavoro viene eseguito un controllo sul corretto crc (a 32 bit).
static tUDtop * fU_GetPointer_MainData (int myProc )
{
tUDtop * pUDtop ;
unsigned int crcComp;
unsigned int crcMem ;
pUDtop = fUser2Bios_Get_pMainData(myProc) ;
crcComp = fU_crc32Gen((pUDtop->uByte),TOP_DATA_STRUCT_LEN,CRC_INIT_PARAM);
crcMem = pUDtop->uField.uTop_CkSumVal ;
if ( crcComp != crcMem )
{
fU_MorteCerta ();
}
return(pUDtop);
}
Per quanto concerne il controllo cksum interrupt, prima di leggere il pointer dei dati di lavoro viene eseguito un controllo sul corretto crc (a 32 bit).
In questo caso il controllo viene eseguito in due punti: sia prima della chiamata interrupt, sia alla chiamata funzione di lettura.
Se una delle due dovesse interrompere l’altra, allora si verificherebbe un errore di crc, per questo entrambe le funzioni devono essere atomiche (ovvero ininterrompibili da procedure interrupt)
Si esegue la seguente routine di controllo alla chiamata dell’interrupt:
void fBios2User_Int_DigIn_SlopeEvent
(
int myProc , // numero del processoe in base al suo indirizzo 0..3 int numInput , // ingresso al quale si riferisce l'evento 0..3
int slope , // fronte di salita o discesa slope up o slope down
unsigned int latchCounterVal // il valore del counter memorizzato nel momento dell'evento
)
//
{
tUDintVel * pUDintVel ; // -> union dati generali
tSDintVel * pSDintVep ; // -> struct dati generali
pUDintVel = fU_GetPointer_IntVel_Data (myProc) ;
pSDintVep = &(pUDintVel->uField.uIntVelData) ; fUEP_Call_IntVel_Accumulate (myProc,pSDintVep,latchCounterVal) ; fU_CalcolaCkSum_PerAbbandonoProcesso (myProc,pUDintVel) ;
}
Si esegue la seguente routine di controllo alla lettura del valore:
unsigned long fMain2Int_Meas_Velocity ( int myProc , ulong sysTic )
{
tUDintVel * pUDintVel ; // -> union dati generali
tSDintVel * pSDintVep ; // -> struct dati generali
volatile unsigned long measVelocity;
fUser2Bios_Enter_Critical();
pUDintVel = fU_GetPointer_IntVel_Data(myProc) ;
pSDintVep = &(pUDintVel->uField.uIntVelData) ;
measVelocity = fUEP_IntMeas_Velocity (myProc,pSDintVep,sysTic) ; fU_CalcolaCkSum_PerAbbandonoProcesso (myProc,pUDintVel) ; fUser2Bios_Exit_Critical();
return (measVelocity) ;
}
Il sistema hardware/software su descritto può avere molteplici applicazioni.
Ad esempio in ambito ferroviario può essere installato sui locomotori di manovra per supervisionare e controllare:
1. Misura della velocità e visualizzazione dell’agente di condotta.
2. Controllo della velocità massima dei movimenti di manovra.
3. Controllo della presenza dell’agente di condotta alla perdita della condizione di fermo.
Il sistema è anche in grado di effettuare le seguenti operazioni non critiche:
1. Registrazione degli eventi e dei parametri relativi alla condotta e ai movimenti di manovra.
2. Collegamento radio terra-bordo.
La presente invenzione può essere vantaggiosamente realizzata tramite un programma per computer che comprende mezzi di codifica per la realizzazione di uno o più passi del metodo, quando questo programma è eseguito su di un computer. Pertanto si intende che l’ambito di protezione si estende a detto programma per computer ed inoltre a mezzi leggibili da computer che comprendono un messaggio registrato, detti mezzi leggibili da computer comprendendo mezzi di codifica di programma per la realizzazione di uno o più passi del metodo, quando detto programma è eseguito su di un computer.
Sono possibili varianti realizzative all'esempio non limitativo descritto, senza per altro uscire dall’ambito di protezione della presente invenzione, comprendendo tutte le realizzazioni equivalenti per un tecnico del ramo.
Gli elementi e le caratteristiche illustrate nelle diverse forme di realizzazione preferite possono essere combinati tra loro senza peraltro uscire dall’ambito di protezione della presente invenzione.
Sono chiari i vantaggi derivanti dall’applicazione della presente invenzione, ad esempio i seguenti.
- elaborazione certa in ambiente non certificato, con riduzione costi, oppure aumento della sicurezza in ambiente certificato;
- mutuo controllo dei dati;
- introduzione di un algoritmo simmetrico per ottenere conclusioni comuni;
- controllo ciclico crc sui dati di lavoro.
Dalla descrizione sopra riportata il tecnico del ramo è in grado di realizzare l’oggetto dell’invenzione senza introdurre ulteriori dettagli costruttivi.

Claims (8)

  1. RIVENDICAZIONI 1. Sistema elettronico modulare per la verifica della corretta esecuzione di operazioni eseguite da detto sistema elettronico, caratterizzato dal fatto che comprende: - un numero N maggiore di 1 di sottosistemi elettronici (CPS1 ……CPSN) in parallelo, ognuno atto a: - ricevere agli ingressi dati esterni (I), - eseguire dette operazioni ed emettere il risultato alle sue uscite, - ricevere ad altri ingressi le uscite degli altri sottosistemi elettronici, - rieseguire dette operazioni su detti ingressi ricevuti dagli altri sottosistemi elettronici ed emettere in uscita i risultati delle riesecuzioni; - un blocco di elaborazione simmetrica (SYM) atto a ricevere e confrontare tutte le uscite di detti sottosistemi elettronici (CPS1 ……CPSN), e decidere quale di dette uscite dei sottosistemi elettronici scegliere come valore di detta corretta esecuzione di operazioni che emette all’uscita, in base alla simmetria verificata tra dette uscite.
  2. 2. Sistema elettronico modulare come nella rivendicazione 1, in cui nel caso di verifica di dissimmetrie dovute ad almeno uno dei valori di dette uscite dissimile dagli altri sopra una soglia di tolleranza di diversità, detto blocco di elaborazione simmetrica (SYM) rileva un errore, e fornisce in uscita uno degli altri valori scelto tra quelli non dissimili, e segnala un errore all’esterno.
  3. 3. Sistema elettronico modulare come nella rivendicazione 2, in cui a seguito di detta segnalazione di errore all’esterno, detto blocco di elaborazione simmetrica (SYM) bloccando l’esecuzione del programma da parte del sistema elettronico modulare, oppure sceglie come valore corretto di uscita un valore tra quelli non dissimili, oppure una loro media.
  4. 4. Sistema elettronico modulare come nella rivendicazione 1, in cui ognuno di detti sottosistemi elettronici (CPS1 ……CPSN) comprende mezzi per leggere dall’esterno il dato di ingresso (I), elaborarlo tramite un algoritmo CP che realizza una macchina a stati finiti, e calcolare lo stato futuro S, il valore dello stato S all’istante x+1 essendo funzione f dello stato all’istante x, e dell’ingresso (I) in quell’istante secondo la relazione: S(x+1) = f (S(x), I(x)), la funzione f realizzando detta esecuzione di operazioni.
  5. 5. Sistema elettronico modulare come nella rivendicazione 1, in cui l’architettura software del sistema realizza un gestore generico di algoritmi (SequenceController) atto a garantire la corretta esecuzione di un algoritmo (CriticalProcess) tramite esecuzione parallela su più sottosistemi hardware/software, sulla base dei seguenti criteri: ● Architettura Hardware basata su più sottosistemi elettronici (CPS1 ……CPSN) di tipologia diversa; ● Lettura degli ingressi del sistema da parte di ciascun sottosistema elettronico; ● Esecuzione di un algoritmo (CriticalProcess) su tutti i sottosistemi elettronici in parallelo, con ingressi diversi; ● Scambio dati fra i vari sottosistemi elettronici; ● Ri-esecuzione da parte di ciascun sottosistema elettronico con i dati di ingresso ricevuti da tutti gli altri, utilizzando il medesimo algoritmo o la medesima funzione; ● Confronto della corretta elaborazione; ● Calcolo di risultati comuni tramite un algoritmo simmetrico (SymmPostElab).
  6. 6. Sistema elettronico modulare come nella rivendicazione 5, in cui detto gestore generico di algoritmi (SequenceController) svolge i seguenti passi: ● Lettura ingressi (I); ● Esecuzione dell’algoritmo applicando gli ingressi letti e calcolo stato futuro; ● Invio ingressi e stato da parte di ogni sottosistema agli altri sottosistemi; ● Attesa dati dagli altri sottosistemi e ricezione degli ingressi e stati degli altri sottosistemi; ● Esecuzione dell’algoritmo applicando gli ingressi ricevuti dagli altri sottosistemi; ● Confronto byte a byte dello stato ricevuto e lo stato internamente calcolato, atto a verificare che le elaborazioni nei sottosistemi siano avvenute correttamente; ● Ripetizione per ogni sottosistema; ● Esecuzione di detto algoritmo simmetrico sui vari risultati di tutti i sottosistemi per ricavare le uscite da visualizzare; ● Controllo della uguaglianza fra i vari risultati dell’algoritmo simmetrico.
  7. 7. Sistema elettronico modulare come nella rivendicazione 6, in cui tutta l’area dati del sistema elettronico modulare è raccolta in una struttura dati contigua ed è protetta tramite un codice di ridondanza ciclica (crc), calcolato alla fine della elaborazione dell’algoritmo e controllato all’inizio dello stesso tramite controllo del ck_sum.
  8. 8. Sistema elettronico modulare come nella rivendicazione 1, comprendente mezzi per ottenere differenti codici eseguibili per detti sottosistemi elettronici (CPS1 ……CPSN) se diversi, partendo da un unico codice sorgente (CR) compilato con diversi sistemi operativi, bios e librerie, detti differenti codici eseguibili essendo eseguiti da detti sottosistemi elettronici (CPS1 ……CPSN) diversi, in modo tale che vi sia un unico algoritmo di codice sorgente (CR) che è l’unica parte comune del sistema.
IT102018000007412A 2018-07-23 2018-07-23 Sistema elettronico modulare per la verifica della corretta esecuzione di operazioni eseguite dal sistema stesso IT201800007412A1 (it)

Priority Applications (2)

Application Number Priority Date Filing Date Title
IT102018000007412A IT201800007412A1 (it) 2018-07-23 2018-07-23 Sistema elettronico modulare per la verifica della corretta esecuzione di operazioni eseguite dal sistema stesso
PCT/IB2019/056200 WO2020021415A1 (en) 2018-07-23 2019-07-19 Modular electronic system for verifying the correct execution of operations performed by the system itself

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
IT102018000007412A IT201800007412A1 (it) 2018-07-23 2018-07-23 Sistema elettronico modulare per la verifica della corretta esecuzione di operazioni eseguite dal sistema stesso

Publications (1)

Publication Number Publication Date
IT201800007412A1 true IT201800007412A1 (it) 2020-01-23

Family

ID=64316649

Family Applications (1)

Application Number Title Priority Date Filing Date
IT102018000007412A IT201800007412A1 (it) 2018-07-23 2018-07-23 Sistema elettronico modulare per la verifica della corretta esecuzione di operazioni eseguite dal sistema stesso

Country Status (2)

Country Link
IT (1) IT201800007412A1 (it)
WO (1) WO2020021415A1 (it)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW202324098A (zh) * 2021-12-07 2023-06-16 財團法人工業技術研究院 錯誤偵測與更正裝置及其方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010044912A1 (en) * 2000-05-22 2001-11-22 Francis Patrick J. Reliable hardware support for the use of formal languages in high assurance systems
US6839868B1 (en) * 1998-10-12 2005-01-04 Centre National D'etudes Spatiales Method for processing an electronic system subjected to transient error constraints and memory access monitoring device
EP1834857A2 (fr) * 2006-03-17 2007-09-19 Alstom Transport S.A. Dispositif de commande sécurisé à diversification pour un système
US7877627B1 (en) * 2008-12-18 2011-01-25 Supercon, L.L.C. Multiple redundant computer system combining fault diagnostics and majority voting with dissimilar redundancy technology
US20160109862A1 (en) * 2014-10-17 2016-04-21 Kabushiki Kaisha Toshiba Multiplex control device

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6839868B1 (en) * 1998-10-12 2005-01-04 Centre National D'etudes Spatiales Method for processing an electronic system subjected to transient error constraints and memory access monitoring device
US20010044912A1 (en) * 2000-05-22 2001-11-22 Francis Patrick J. Reliable hardware support for the use of formal languages in high assurance systems
EP1834857A2 (fr) * 2006-03-17 2007-09-19 Alstom Transport S.A. Dispositif de commande sécurisé à diversification pour un système
US7877627B1 (en) * 2008-12-18 2011-01-25 Supercon, L.L.C. Multiple redundant computer system combining fault diagnostics and majority voting with dissimilar redundancy technology
US20160109862A1 (en) * 2014-10-17 2016-04-21 Kabushiki Kaisha Toshiba Multiplex control device

Also Published As

Publication number Publication date
WO2020021415A1 (en) 2020-01-30

Similar Documents

Publication Publication Date Title
Powell et al. GUARDS: A generic upgradable architecture for real-time dependable systems
US7694250B2 (en) Method for design and verification of safety critical systems
US20210349443A1 (en) Method and apparatus for the computer-aided creation and execution of a control function
Jiang et al. Safety-assured model-driven design of the multifunction vehicle bus controller
Duan et al. Formal modeling and verification of blockchain system
IT201800007412A1 (it) Sistema elettronico modulare per la verifica della corretta esecuzione di operazioni eseguite dal sistema stesso
Svendsen et al. The future of train signaling
SenthilMurugan et al. A literal review of software quality assurance
Chai et al. A Rewriting Based Monitoring Algorithm for TPTL.
Bartocci Sampling-based decentralized monitoring for networked embedded systems
Idirin et al. Implementation details and safety analysis of a microcontroller-based SIL-4 software voter
Cimatti Industrial applications of model checking
Larrucea et al. Modular development and certification of dependable mixed-criticality systems
ter Beek et al. Conditions for compatibility of components: the case of masters and slaves
Rushby Systematic formal verification for fault-tolerant time-triggered algorithms
Larrucea et al. A realistic approach to a network-on-chip cross-domain pattern
Hei et al. Toward developing a decentralized railway signalling system using Petri nets
Bonfiglio et al. Composable Framework Support for Software-FMEA through Model Execution
Sikora et al. Supporting the consistent specification of scenarios across multiple abstraction levels
Ambrosio et al. Systematic generation of test and fault cases for space application validation
Heimdahl et al. NIMBUS: A tool for specification centered development
Hassanpour Using Safety Analysis Techniques To Derive Safety Properties For Formal Verification Of Safety-Critical Systems
Del Bianco et al. Towards UML-based formal specifications of component-based real-time software
Bergenhem et al. A novel modelling pattern for establishing failure models and assisting architectural exploration in an automotive context
Yeung et al. Formal verification of fault-tolerant software design: the CSP approach