Progetto. Sistema Controllo Marcia Treno. SCMT SottoSistema di Bordo. SCMT SottoSistema di Terra

Transcript

1 Sistema Controllo Marcia Treno SCMT SottoSistema di Bordo SCMT SottoSistema di Terra Principio di funzionamento (molto) schematico: SST comunica a SSB stato e distanza del prossimo segnale SSB imposta la curva di frenatura : velocità limite in funzione della distanza per poter arrestare il treno prima del segnale Se il macchinista non mantiene il treno nella curva di frenatura, il SSB attiva la frenatura automatica 26

2 Sistema di segnalamento LEU LEU ACEI LEU LEU L ACEI comanda gli aspetti dei segnali e la posizione dei deviatoi tenendo conto Delle informazioni riportate dal campo da sensori e circuiti di binario Degli itinerari impostati dal personale di servizio Dall ACEI sono derivate le condizioni che pilotano i LEU Ciascun LEU comanda le BOE dei Punti Informativi Sulla base delle condizioni il LEU seleziona il telegramma da inviare alle Boe Alcune Boe non sono comandate dai LEU, ma trasmettono un telegramma fisso Alcuni LEU sono dislocati in stazione, altri lungo la linea 27

3 Schema di base di SST Modulo GPS Alimentatori Encoder (LEU) FED Verso PDP Boe Eurobalise Alimentazione da garitta di blocco Ingressi Encoder Linea diagnostica Alimentatori BUS sistema N BUS sistema R Connessione BOE Alimentazione di sistema Linea diagnostica PDP Linea GPS Moduli condizionamento Boe Ingressi da garitta di blocco Ogni Encoder (LEU) può pilotare 4 Boe commutate Ogni LEU ha fino a 16 input vitali dall ACEI I LEU sono raggruppati in Armadi di Stazione e di Linea Il LEU è data driven, ovvero ha una Tabella di Configurazione con le associazioni Inputs telegrammi I moduli FED hanno le funzionalità di monitoraggio e diagnostica del sistema. I FED datano le informazioni diagnostiche mediante collegamento a GPS 28

4 Preliminary Hazard Analysis a livello SCMT Hazard dovuti alle comunicazioni SST SSB (non esaustivo) SSB non riceve il telegramma La Boa non trasmette il telegramma SSB riceve un telegramma alterato La boa trasmette un telegramma alterato La boa trasmette un telegramma integro, ma inconsistente con lo stato del segnale Contromisure (non esaustivo) Ridondanza delle Boe : ogni punto informativo (PI)) è formato da almeno due Boe Una delle due Boe può essere fissa, ma comunque è utile per individuare il PI In mancanza di input dal LEU la Boa commutata trasmette un telegramma fisso restrittivo Gestione degli appuntamenti : Ciascun PI informa SSB sulla distanza del prossimo punto informativo La funzione di misura della distanza di SSB (odometria( odometria) ) è realizzata al massimo livello di integrità Se il treno non incontra il PI dove previsto, SSB passa in modalità degradata (velocità limitata) ta) La funzioni di acquisizione degli ingressi e di selezione del telegramma da inviare alla Boa da parte del LEU sono funzioni di sicurezza da realizzare al massimo livello di integrità ità La codifica dei telegrammi prevede complessi meccanismi di checksum per individuare alterazioni durante la trasmissione/ricezione 29

5 Progetto Semplificazioni accettabili Non si considera la complessità della codifica dei telegrammi li rappresentiamo come stringhe di caratteri stampabili distinguibili tra loro senza alcun CRC. Non si considera il raggruppamento di LEU in Armadi di Stazione e di Linea - ai fini del progetto, consideriamo un singolo LEU che pilota 4 Boe. Non si considera l apparato di diagnostica, ovvero FED e le relative connessioni non li rappresentiamo nel modello. I requisiti di performance sono meno restrittivi di quelli reali ci diamo temporizzazioni che permettono di seguire l evoluzione del modello con stampe di controllo. Limitiamo il modello ad un singolo programma (Ada) in cui i vari apparati sono rappresentati da task che ne riproducono la funzione in particolare, le due sezioni di apparato 2oo2 saranno rappresentate da due istanze di un task type. 30

6 Requisiti 1. Il LEU gestisce 16 ingressi vitali (VIN) (collegati all ACEI) 2. Il LEU pilota 4 Boe commutate a ciascuna delle quali invia periodicamente un telegramma (TLG) 3. Il LEU ha una tabella di configurazione (TCONF) che associa combinazioni dei VIN a TLG. TCONF contiene un numero limitato di combinazioni, tutte le altre sono illegali. In caso di combinazione illegale viene selezionato un TLG di default LEU. TCONF deve avere un TLG corrispondente alla combinazione con tutti i VIN uguali a zero. 4. Inizialmente tutti i VIN sono a zero e sono considerati stabili. Il LEU seleziona il TLG corrispondente. 5. Il LEU acquisisce periodicamente i VIN e in caso di variazioni li analizza per determinarne la stabilità. Ciascun singolo VIN è considerato instabile dal momento in cui commuta e viene considerato nuovamente stabile quando mantiene il suo valore per almeno 3 cicli di analisi consecutivi. 6. Quando tutti i VIN risultano nuovamente stabili, il LEU scandisce TCONF e seleziona il nuovo TLG da inviare a ciascuna Boa. 7. Fino a quando non esiste una nuova combinazione stabile dei VIN il LEU continua ad inviare il TLG selezionato in precedenza 8. Ad ogni istante, ciascuna BOA ha un TLG corrente, che è quello che trasmetterebbe al treno. 9. Ciascuna Boa ha un suo TLG di default BOA, diverso dal TLG di default LEU. 10. Inizialmente il TLG corrente è il TLG di default BOA. Quando la Boa riceve un TLG dal LEU questo diventa il TLG corrente. Se per un certo periodo il LEU non manda telegrammi il TLG di default Boa diventa nuovamente il TLG corrente 11. Le funzioni di analisi degli input e di selezione del telegramma devono essere eseguite in sicurezza. 31

7 Software Applicativo Progetto Con questo termine indichiamo il software che modella l ACEI, il LEU e le Boe. Complessivamente occorrono 4 task per modellare le Boe e 2 task per modellare le due sezioni dell apparato in sicurezza LEU. È importante osservare che i 2 task LEU modellano UN SOLO apparato LEU che, dovendo realizzare funzioni in sicurezza viene implementato con 2 canali 2oo2 in sicurezza composita. Nella realtà, il LEU è realizzato con 2 schede microprocessore che acquisiscono gli stessi dati di input e li sottopongono alla stessa elaborazione in modo indipendente. I canali consolidano (votano) i risultati intermedi e finali della elaborazione scambiandoseli mediante linee seriali Nella modellazione, invece, occorre un task aggiuntivo per realizzare la votazione. È necessario per evitare che i task LEU si chiamino a vicenda con rischio di deadlock. Per LEU e Boe si utilizzano array di istanze di task type. Occorre utilizzare le funzionalità del linguaggio per far si che ciascuna istanza sia in grado di autoidentificarsi in modo univoco Un ulteriore task realizza un simulatore di ambiente in grado di modellare il comportamento dell ACEI. Permette di fornire i VIN ai LEU, modificandoli nel tempo Si lascia alla implementazione il grado di sofisticazione del simulatore. Chi vuole e può lo realizzerà in modo interattivo, magari con una interfaccia grafica 32

8 Le frecce indicano rendez-vous e loro direzione Software Applicativo - schema LEU1 Put_TLG BOA1 Get_VIN SIM Vote VOTER BOA2 Put_TLG BOA3 Put_TLG Per semplificare, LEU1 manda i TLG a BOA1 e BOA2, mentre LEU2 manda i TLG a BOA3 e BOA4 LEU2 Put_TLG BOA4 33

9 Fault Injection (1) Progetto Utilizzando solo strumenti Software non si riescono a simulare fault di ogni genere. Quello che si riesce ad ottenere è essenzialmente la simulazione di guasti in RAM, transitori e (limitatamente) permanenti. Anche in questo caso occorre della collaborazione da parte del software applicativo, che deve essere strutturato in funzione delle esigenze di fault-injection Occorre fare in modo che le variabili su cui lavora il software applicativo siano visibili anche al software di fault-injection. Questo significa violare volutamente le protezioni del linguaggio. Il software applicativo è strutturato in un certo numero di task: quelle che sarebbero state le variabili locali di un task T saranno invece dichiarate nella specifica di un package, accessibile solo a T e al task che esegue la fault-injection Le variabili sono riunite in un oggetto di un opportuno tipo record. Nella stessa parte dichiarativa, si dichiara un array di byte delle stesse dimensioni e lo si alloca allo stesso indirizzo dell oggetto record. In questo modo il task di FI può rovinare i dati sia in modo mirato che in modo random. Notare che si simula un guasto transitorio, che provoca un effetto solo se avviene tra il momento in cui il dato viene scritto e quello in cui viene letto. Per questo motivo il task di FI deve essere più prioritario dei task applicativi e deve agire ad una frequenza elevata per sperare di interrompere il task applicativo durante la sua elaborazione 34

10 Fault Injection (2) Progetto Per simulare un guasto permanente in RAM, occorre un meccanismo più complesso. In questo caso il task applicativo non deve aggiornare direttamente il dato, ma attraverso un sottoprogramma. Il sottoprogramma avrà del codice che, quando si vuole simulare il guasto, altera il dato ogni volta che viene scritto Per modellare più fedelmente la realtà, la Boa non è soggetta a fault-injection. La Boa reale è un oggetto concettualmente semplice e ad alta affidabilità. Inoltre una corruzione del TLG nella Boa verrebbe diagnosticato dal SSB utilizzando i codici di rilevamento errore che, per semplicità, non utilizziamo Se il linguaggio utilizzato è Ada, i controlli inseriti automaticamente dal compilatore per supportare il controllo forte sui tipi costituiscono una valida programmazione difensiva. Per rendere il progetto più significativo, si raccomanda di applicare ovunque il pragma SUPPRESS. Da questo deriva che non sarà utilizzato l exception handling. La necessaria programmazione difensiva verrà codificata esplicitamente nel software applicativo Il software di fault-injection potrà avere un livello di sofisticazione arbitrario, per esempio interfaccia grafica su window differente da quella del simulatore di ambiente, oppure una semplice interfaccia testuale. 35

11 Fault Injection - schema FI LEU data Le frecce indicano accesso ai dati LEU1 LEU2 36

12 Software Applicativo - dichiarazioni Type T_LEU is range 1..2; Type T_BOA is range 1..4; Type T_TLG is STRING (1..10); Type T_VIN is range ; Type T_BYTE is range ; Type T_CONF_ROW is record the_vin : T_VIN; the_tlg : T_TLG; End record; Type T_CONF_ARRAY is array (TBD) of T_CONF_ROW Type T_CONF is record the_default : T_TLG; the_array : T_CONF_ARRAY; End record; type T_CONF_TABLE is array (T_BOA) of T_CONF Type T_LEU_data is record -- campi per contenere quelle che dovrebbero -- essere le variabili locali di un task LEU the_conf : T_CONF_TABLE := (); End record; Package Visible_data is THE_LEU_DATA : array (T_LEU) of T_LEU_data; THE_FI_DATA : array (TBD) of T_BYTE; -- TBD dimensionato in modo da avere lo stesso -- size di THE_LEU_DATA pragma pack (THE_FI_DATA ); for THE_FI_DATA address use THE_LEU_DATA address End Visible_data; 37

13 Software Applicativo il votatore Occorre stabilire quali dati consolidare. I task LEU potranno votare uno o più dati, ad esempio la combinazione di VIN acquisita, l indice del telegramma selezionato (per ciascuna Boa), il telegramma stesso (per ciascuna Boa) In base a questa scelta si determina l interfaccia del task VOTER, con uno o più modelli di rendez-vous a seconda di quanti dati e di che tipo si vuole consolidare. Si consiglia di iniziare con un solo dato consolidato e poi migliorare In ogni caso i punti di ingresso rendez-vous dovranno essere strutturati come entry family di indice T_LEU in modo da poter controllare che entrambi i task LEU hanno effettuato la chiamata (in quale ordine non è significativo) Le primitive del votatore non dovranno confrontare direttamente i valori, ma piuttosto restituire a ciascun task LEU il valore fornito dall altro task. Poi i task LEU eseguiranno entrambi il confronto. Di conseguenza il primo task LEU che esegue il rendez-vous dovrà essere bloccato fino a quando non lo esegua anche l altro. Poi entrambi dovranno essere rilasciati consegnandogli il valore passato dall alto task. In questo modo i task LEU vengono sincronizzati come effetto collaterale. Si può pensare anche ad un time-out: se il secondo LEU non arriva, si rilascia il primo consegnando un valore non significativo. Se opportuno il VOTER può essere un protected record piuttosto che un task. 38

14 Monitoring Progetto È necessario un meccanismo di Monitoring per evidenziare se la fault-injection raggiunge il risultato di provocare un malfunzionamento non diagnosticato Per questo occorre avere un software che prevede il risultato corretto delle elaborazioni e lo confronta con quanto prodotto dal sistema sottoposto a fault-injection In pratica, il software di monitoring coincide con il software applicativo del LEU per quanto riguarda la previsione del risultato, poi ha una sezione per il confronto Il termine di paragone è costituito essenzialmente dai telegrammi trasmessi istante per istante dalle Boe a fronte delle variazioni degli input Il software di monitoring non dovrebbe mai trovare differenze, in quanto i malfunzionamenti dovrebbero essere sempre catturati dai meccanismi di sicurezza; se vengono individuate delle differenze, questo significa che i meccanismi hanno fallito Occorre però tenere conto del fatto che il telegramma corretto per una nuova configurazione dei VIN appare sulla Boa dopo un certo tempo, dovuto alla analisi di stabilità eseguita dal software del LEU Il software di monitoring può essere vantaggiosamente inserito nel software di simulazione di ambiente 39

15 Monitoring - schema Get_VIN SIM MON LEU1 Current_ TLG BOAn Put_TLG Il Monitor deve tener conto del fatto che una nuova combinazione dei VIN viene attuata solo quando è giudicata stabile, quindi deve dare il tempo ai LEU di eseguire la serie di analisi necessaria prima di aspettarsi di trovare il nuovo TLG sulla Boa Per questo potrebbe essere necessaria una qualche sincronizzazione Per supportare il monitoring occorre che il thread BOA renda disponibile un secondo punto di sincronizzazione per leggere il telegramma corrente. Questo fatto può rendere più complesso gestire il time-out sulla chiamata a Get_TLG da parte del task LEU, allo scadere del quale il telegramma corrente diventa il telegramma di default BOA. Se non si trova una soluzione si può mettere la variabile che contiene il telegramma corrente non nel task Boa ma in una posizione accessibile direttamente dal Monitor (ma attenzione agli accessi concorrenti, occorre evitarli regolando le priorità) 40

16 Alcune note finali Il task SIM deve essere sempre disponibile al rendez-vous per fornire i VIN ai LEU, però deve anche essere capace di far variare i VIN secondo lo schema desiderato, interattivamente o utilizzando una lista di valori da scorrere automaticamente. Considerare la possibilità di utilizzare più di un task oppure un task e un protected record. I task LEU oltre alle votazioni possono avere altre tecniche di protezione, tipo defensive programming, oppure possono associare un checksum alla tabella di configurazione e ri-calcolarlo periodicamente. In ogni caso occorre un meccanismo di shut-down da utilizzare in caso di rilevazione di un errore. Potrebbe essere semplicemente utilizzato lo statement di abort : il LEU che trova l errore lo usa prima per abortire l altro LEU e poi su se stesso. Si possono considerare altri meccanismi. Per rendere più semplice la messa a punto del software e poi la simulazione, conviene investire inizialmente un po di tempo per realizzare un meccanismo che permette ai vari task del sistema di eseguire operazioni di input/output su finestre dedicate. Occorre sfruttare le caratteristiche dell ambiente di sviluppo e le sue connessioni con il sistema operativo della macchina host. Una alternativa può essere interfacciare Ada con altri linguaggi (C++, Visual Basic) che hanno librerie dedicate allo scopo. 41