Certificazione Software e CENELEC nella pratica …tullio/CS/Dispense_2005/20050301.pdf · CEI EN...
Transcript of Certificazione Software e CENELEC nella pratica …tullio/CS/Dispense_2005/20050301.pdf · CEI EN...
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 11
RAILWAY EVOLUTION
Certificazione Software eCertificazione Software eCENELEC nella pratica aziendaleCENELEC nella pratica aziendale
Parte I – 1/2 Febbraio 2005Presentazione relatore e aziendaPresentazione relatore e aziendaLa Certificazione La Certificazione –– qualità, processo, prodottoqualità, processo, prodottoLa Certificazione del SoftwareLa Certificazione del SoftwareMisurare la Qualità del SoftwareMisurare la Qualità del SoftwareProcessi di sviluppo per il SoftwareProcessi di sviluppo per il SoftwareSoftware “certificabile”Software “certificabile”
Parte II – 1/2 Marzo 2005Ingegneria della SicurezzaIngegneria della SicurezzaSistemi in sicurezzaSistemi in sicurezzaIl Software nel ciclo di vita di SistemaIl Software nel ciclo di vita di SistemaIl Software e la sicurezza Il Software e la sicurezza Meccanismi di sicurezza realizzati dal softwareMeccanismi di sicurezza realizzati dal software
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 22
RAILWAY EVOLUTION
Ingegneria della SicurezzaIngegneria della SicurezzaSicurezza intesa come Safety (non Sicurezza intesa come Safety (non Security))
• Il vecchio approccio di analizzare gli incidenti reali e codificare standards di produzione e manuali tecnici per evitare che si ripetano:
•• non da garanzie rispetto a non da garanzie rispetto a nuovi sisteminuovi sistemi
•• non è proponibile per sistemi come non è proponibile per sistemi come centrali nucleari, aereicentrali nucleari, aerei con un gran con un gran numero di passeggeri, numero di passeggeri, treni ad alta velocitàtreni ad alta velocità, dove ogni incidente può avere , dove ogni incidente può avere un costo estremamente alto in termini umani, ambientali ed econoun costo estremamente alto in termini umani, ambientali ed economicimici
•• è antieconomico perché comporta è antieconomico perché comporta riri--lavorazionilavorazioni su sistemi già installati ed su sistemi già installati ed operantioperanti
• Occorre avere la certezza, prima di mettere il sistema in servizio, che esso abbia una probabilità inferiore ad un limite tollerabile (THR, Tolerable Hazard Rate) di provocare un incidente grave
• Occorre quindi un processo che mediante analisi e sperimentazione garantisce, nella fase prototipale e in produzione, che il prodotto è esente da malfunzionamenti inaccettabili anche a fronte di guasti
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 33
RAILWAY EVOLUTION
Ingegneria della SicurezzaIngegneria della SicurezzaUn primo esempio
La mancata analisi dei modi di guasto del sistema può portare problemi di sicurezza o costose soluzioni non ottimali dopo la messa in esercizio
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 44
RAILWAY EVOLUTION
Ingegneria della SicurezzaIngegneria della SicurezzaUn esempio di controllo automatico con componente software
Il software deve chiudere la valvola quando la pressione p supera il valore P1 ed aprirla quando la pressione scende sotto il valore P2Se la valvola non si apre sotto P2 si ha solo un disservizioSe la valvola non si chiude sopra P1 si ha un problema di sicurezzalo stato sicuro del sistema è quello in cui la valvola è stabilmente chiusa
Casi di guasto considerati1. il sensore segna una pressione inferiore
a quella effettiva2. il sensore segna una pressione
superiore a quella effettiva3. la valvola si blocca in chiusura4. la valvola si blocca in apertura
LeggiLeggi pp
pp>P1>P1 Valvola chiusaValvola chiusa
Valvola apertaValvola apertapp<P2<P2
nono
sisi
sisi
nono
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 55
RAILWAY EVOLUTION
Ingegneria della SicurezzaIngegneria della SicurezzaArchitettura in sicurezza : ridondanza delle unità di elaborazione
lettura plettura p
lettura plettura p
elaborazioneelaborazione
elaborazioneelaborazione
attuazioneattuazione
attuazioneattuazione
CPU1CPU1
CPU2CPU2
tt
Sistema 2oo2Sistema 2oo2
ConsolidamentoConsolidamentoinputinput
VerificaVerificaoutputoutput
VotazioniVotazioni
Ma la ridondanza non è efficace a fronte diMa la ridondanza non è efficace a fronte dierrori sistematicierrori sistematici, in particolare del Software, in particolare del Software
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 66
RAILWAY EVOLUTION
Sistemi in SicurezzaSistemi in SicurezzaDefinizioni (CEI EN 50126 - 50129)
Sono sistemi il cui esercizio comporta un livello di rischiorischio di esposizione di persone, ambiente e beni materiali a situazioni pericolosesituazioni pericolose con possibilità di incidentiincidenti dovuti a malfunzionamentimalfunzionamenti causati da errorierrori e/o guastiguasti.
GuastoGuasto ((FaultFault)) : condizione anomala capace di provocare un : condizione anomala capace di provocare un erroreerrore nel sistema. Un guasto nel sistema. Un guasto può essere può essere casualecasuale o o sistematico.sistematico.
Errore Errore ((ErrorError)) : deviazione dalla progettazione preventivata capace di dare lu: deviazione dalla progettazione preventivata capace di dare luogo ad un ogo ad un comportamento non previsto del sistema o ad un malfunzionamento.comportamento non previsto del sistema o ad un malfunzionamento.
MalfunzionamentoMalfunzionamento ((FailureFailure)) : deviazione di un sistema rispetto alle prestazioni : deviazione di un sistema rispetto alle prestazioni specificate. Un malfunzionamento è la conseguenza di un specificate. Un malfunzionamento è la conseguenza di un guastoguasto o di un o di un erroreerrore nel sistema.nel sistema.
Situazione pericolosaSituazione pericolosa ((HazardHazard)) : una situazione fisica con potenzialità di arrecare lesioni : una situazione fisica con potenzialità di arrecare lesioni alle persone. Condizione che può portare ad un alle persone. Condizione che può portare ad un incidenteincidente..
IncidenteIncidente ((AccidentAccident)) : avvenimento o serie di avvenimenti inattesi che provocano mor: avvenimento o serie di avvenimenti inattesi che provocano morti, ti, feriti, la perdita di un sistema oppure di un servizio, oppure dferiti, la perdita di un sistema oppure di un servizio, oppure danni all’ambiente. anni all’ambiente.
RischioRischio ((RiskRisk)) : il : il probabileprobabile tasso di accadimento di una tasso di accadimento di una situazione pericolosasituazione pericolosa che causa che causa danno e la gravità del danno. Combinazione della frequenza o deldanno e la gravità del danno. Combinazione della frequenza o della la probabilitàprobabilità e delle e delle conseguenzeconseguenze di un evento pericoloso specificato.di un evento pericoloso specificato.
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 77
RAILWAY EVOLUTION
Sistemi in SicurezzaSistemi in SicurezzaNormative di riferimento per la certificazione
CEI EN 50126CEI EN 50126 Applicazioni ferroviarie, tranviarie, filotranviarie, metropolitApplicazioni ferroviarie, tranviarie, filotranviarie, metropolitane. La specificazione e ane. La specificazione e la dimostrazione di la dimostrazione di Affidabilità, Disponibilità, Manutenibilità e SicurezzaAffidabilità, Disponibilità, Manutenibilità e Sicurezza (RAMS)(RAMS)
CEI EN 50129CEI EN 50129 Applicazioni ferroviarie, tranviarie, filotranviarie, metropolitApplicazioni ferroviarie, tranviarie, filotranviarie, metropolitane ane -- Sistemi di Sistemi di telecomunicazione, segnalamento ed elaborazione telecomunicazione, segnalamento ed elaborazione -- Sistemi ElettroniciSistemi Elettronici di di sicurezza per il segnalamentosicurezza per il segnalamento
CEI EN 50128CEI EN 50128 Applicazioni ferroviarie, tranviarie, filotranviarie, metropolitApplicazioni ferroviarie, tranviarie, filotranviarie, metropolitane. Sistemi di ane. Sistemi di telecomunicazione, segnalamento ed elaborazione telecomunicazione, segnalamento ed elaborazione -- SoftwareSoftware per sistemi per sistemi ferroviari di comando e di protezioneferroviari di comando e di protezione
CEI EN 50121CEI EN 50121 Applicazioni ferroviarie, tranviarie, filotranviarie, metropolitApplicazioni ferroviarie, tranviarie, filotranviarie, metropolitane ane -- Compatibilità Compatibilità elettromagneticaelettromagnetica
CEI EN 50124CEI EN 50124 Applicazioni ferroviarie, tranviarie, filotranviarie, metropolitApplicazioni ferroviarie, tranviarie, filotranviarie, metropolitane. ane. Coordinamento Coordinamento degli isolamentidegli isolamenti
CEI EN 50159CEI EN 50159--11 Applicazioni ferroviarie, tranviarie, filotranviarie, metropolitApplicazioni ferroviarie, tranviarie, filotranviarie, metropolitane ane -- Sistemi di Sistemi di telecomunicazione, segnalamento ed elaborazione. Parte 1: telecomunicazione, segnalamento ed elaborazione. Parte 1: ComunicazioniComunicazioni di di sicurezza in sistemi di trasmissione di sicurezza in sistemi di trasmissione di tipo chiusotipo chiuso
CEI EN 50159CEI EN 50159--22 Applicazioni ferroviarie, tranviarie, filotranviarie, metropolitApplicazioni ferroviarie, tranviarie, filotranviarie, metropolitane ane -- Sistemi di Sistemi di telecomunicazione, segnalamento ed elaborazione. Parte 2: telecomunicazione, segnalamento ed elaborazione. Parte 2: ComunicazioniComunicazioni di di sicurezza in sistemi di trasmissione di sicurezza in sistemi di trasmissione di tipo apertotipo aperto
Dal 12 Novembre 2002, Dal 12 Novembre 2002, RRete ete FFerroviaria erroviaria IItaliana prescrive le norme seguenti come riferimento taliana prescrive le norme seguenti come riferimento per la certificazione dei prodotti e sistemi elettronici in sicuper la certificazione dei prodotti e sistemi elettronici in sicurezza per il segnalamento ferroviariorezza per il segnalamento ferroviario
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 88
RAILWAY EVOLUTION
Sistemi in sicurezzaSistemi in sicurezzaRuoli di riferimento per sistemi ferroviari
Cliente/GestoreCoincide solitamente con l’autorità ferroviaria
FornitoreL’azienda o l’industria fornitrice del sistema ferroviario o di suoi componenti
Autorità d’ApprovazioneE’ l’ente certificatore o chi da esso designato per la validazione e approvazione del sistema
ValidatoreE’ un valutatore indipendente, responsabile per la validazione del sistema
TUV
V
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 99
RAILWAY EVOLUTION
Sistemi in sicurezzaSistemi in sicurezzaCertificazione di SISTEMA
SIS
Cliente Fornitore
Valutatore(certificatore)
(Validatore)TÜV
VV
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 1010
RAILWAY EVOLUTION
Sistemi in SicurezzaSistemi in SicurezzaChi certifica
The Railway Certification Agency , CERTIFER, is an independent technical body created in 1997 under law of 1901 dealing with associations. The main mission is the evaluation of the conformity in the field of the guided transport. The founder members of CERTIFER are the French national railways (SNCF), Paris City Transport (RATP), French Railway Industries Federation (F.I.F) and the National Institute for Research on Transport and their Safety(INRETS), which where joined by the Public Transports Union (UTP) and French Railroad Network (RFF). So the representativeness and the impartiality of Certifer’s statutory authorities are assured.CERTIFER is accredited by the section ' Certification of products and services ' of the French Committee of Accreditation (COFRAC), following the standard EN 45011 under #5-0023 (field: Certification by exam of type of products to be used in guided transport in the following fields: rolling stock, control - command and signalling, track equipments, infrastructure, energy, systems and railway sets).CERTIFER is Notified Body under number 0942, in conformance with the directive 96/48/CE (interoperability of High Speed European railway system), to the European Commission.CERTIFER realizes the third part products’ certification in following areas : rolling stock, infrastructure, energy, control command and signalling . By this service, CERTIFER gives evidence of the conformity of a product with regard to the repository during a period of determined validity.
Dal sito Certifer http://certifer.asso.fr/
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 1111
RAILWAY EVOLUTION
Sistemi in SicurezzaSistemi in SicurezzaChi certifica
Railcert is a company for the mandatory and voluntary certification of railway products and systems, accredited as Notified Body by the Dutch Ministry of Transport, Public Works and Water Management, in the areas of infrastructure, command and control and energy.
The Dutch Ministry of Transport, Public Works and Water Management has designated Railcertfor the assessment, approval and certification of railway systems and products. This makes us a Notified Body within the meaning of Directive 96/48 and 2001/16. Our accreditation covers the following three subsystems of the high speed and conventional network, together with the associated interoperability aspects: Command and Control, Infrastructure and Energy.
Railcert BV is an independent subsidiary of Holland Railconsult and TÜV Süd. Holland Railconsult has more than 165 years of railway experience, and the TÜV is one of Europe’s largest test and certification bodies. Railcert’s headquarter is in Utrecht, the Netherlands, and the company hasbranch offices in Munich and Braunschweig, Germany.
Dal sito Railcert http://www.railcert.com
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 1212
RAILWAY EVOLUTION
Sistemi in SicurezzaSistemi in SicurezzaChi certifica
Il Consorzio SciroTÜV nasce dalla cooperazione, avviata nell'estate 2000, tra la società di consulenza italiana Sciro SPA. e l'ente di certificazione tedesco TÜV Rheinland Group, in risposta alla sempre crescente domanda, nell’ambito del mercato ferroviario italiano ed internazionale, di servizi di assessment e certificazione di prodotti e sistemi offerti da organismi competenti e qualificati. Il Consorzio SciroTÜV è la prima realtà italiana, nata dall’iniziativa di privati, che si propone sul mercato della certificazione ferroviaria portando in dote una profonda conoscenza del mondo dei trasporti a guida vincolata e delle sue peculiarità tecniche e organizzative. Competenza tecnica, indipendenza di valutazione, imparzialità di giudizio e presenza sul mercato internazionale fanno di SciroTÜV il partner ideale per l’industria, gli operatori di trasporto e i gestori dell’infrastruttura, per la certificazione e la valutazione di sistemi e prodotti per il trasporto a guida vincolata.Nel campo regolamentato europeo, dal 2003 SciroTÜV ha ottenuto il riconoscimento, da parte del Ministero Italiano delle Infrastrutture e dei Trasporti, come Organismo Notificato per la Certificazione di Interoperabilità di componenti e sottosistemi ai sensi delle Direttive Europee 96/48/CE e 2001/16/CE. Tale notifica (n. 1287) è stata ottenuta in data 18/02/03 come pubblicato sulla G.U. n. 40 anno 144.In quanto Organismo Notificato opera su tutto il territorio comunitario.Il Consorzio SciroTÜV è altresì legato a NB RAIL, il gruppo coordinatore degli Enti Notificati per i prodotti ed i sistemi ferroviari, organizzazioni indipendenti responsabili per l’assessment della conformità dei prodotti e dei sistemi stante i requisiti delle Direttive sull’Interoperabilità dei Sistemi Ferroviari dell’Alta Velocità Trans-Europea(96/48/EC) e di quella Convenzionale (2001/16/EC).
Dal sito SciroTÜV http://www.scirotuv.com
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 1313
RAILWAY EVOLUTION
Sistemi in SicurezzaSistemi in SicurezzaEsempi di Notified bodies per l’Italia
Lista non necessariamente esaustiva:RINA è Organismo Notificato dal Ministero delle Infrastrutture e dei Trasporti Italiano (rif. G.U. n. 207 del 4 settembre 2002) per svolgere verifiche di conformità di sottosistemi e di componenti nel settore ferroviario dell’alta velocità, ai sensi del Decreto Legislativo 299/01 di recepimento della Direttiva 96/48/CE (è inoltre attesa la prossima formalizzazione della Notifica sulla Direttiva 01/16/CE riguardante la rete convenzionale ai sensi del Decreto Legislativo 268/04 di recepimento), inclusi tutti gli aspetti di sicurezza.
SciroTÜV è Organismo Notificato dal Ministero delle Infrastrutture e dei Trasporti Italiano (rif. G.U. n. 40 del 18 febbraio 2003) per svolgere verifiche di conformità di sottosistemi e di componenti nel settore ferroviario dell’alta velocità, ai sensi del Decreto Legislativo 299/01 di recepimento della Direttiva 96/48/CE. Prossima formalizzazione della Notifica sulla Direttiva 2001/16/CE riguardante la rete convenzionale ai sensi del Decreto Legislativo 268/04 di recepimento, inclusi tutti gli aspetti di sicurezza.
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 1414
RAILWAY EVOLUTION
Sistemi in sicurezzaSistemi in sicurezzaSistemi ferroviari
Sistema ferroviario
Sistema di segnalamento
Sottosistemi di segnalamento
Componenti e apparecchiature
50126
RAMS50129Sicurezza del sistema
50128 software
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 1515
RAILWAY EVOLUTION
Sistemi in sicurezzaSistemi in sicurezzaDefinizione di R.A.M.S (CEI EN 50129)
•Affidabilità – Reliability : capacità di un’unità di compiere una funzione richiesta, in condizioni stabilite e per un determinato periodo di tempo.
•Disponibilità - Availability : capacità di un prodotto di essere in condizione di eseguire una funzione richiesta nelle condizioni imposte ad un determinato istante oppure durante un determinato intervallo di tempo, supponendo che siano fornite le risorse esterne necessarie.
•Manutenibilità – Maintainability : probabilità che per una data unità, utilizzata in condizioni di impiego stabilite, possa essere svolta, durante un intervallo di tempo stabilito, una data azione di manutenzione attiva, attuata secondo condizioni stabilite, e con l’impiego delle procedure e dei mezzi prescritti.
•Sicurezza – Safety : assenza di livelli intollerabili di rischio di danno.
A queste proprietà dobbiamo in generale aggiungere fattori:• Economici – costi di progetto, produzione, manutenzione• Sociali – impatto del sistema sul livello di vita del cittadino e sul mondo del lavoro• Ambientali – impatto ecologico dei prodotti: deve far parte dell’analisi dei rischi del
prodotto• Politici – per i punti precedenti
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 1616
RAILWAY EVOLUTION
Sistemi in sicurezzaSistemi in sicurezza
Ciclo di vita di sistemi in sicurezza (1)
Concept 1
Risk Analysis 3
Design andImplementation
6
Manufacture 7
System Definition &Application Conditions
2
System Acceptance
10 De-commissioningand Disposal
14
11
MaintenanceOperation and
Installation 8
System Validation(Including Safety Acceptance
and Commissioning)
9System Requirements4
Apportionment of System Requirements
5
Determina i Determina i Requisiti di sicurezzaRequisiti di sicurezza
Include il ciclo Include il ciclo di vita del di vita del SoftwareSoftware
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 1717
RAILWAY EVOLUTION
Sistemi in sicurezzaSistemi in sicurezzaCiclo di vita della Sicurezza (50126 – 50129)
Ciclo di vita della Sicurezza (Safety Life Cycle) insieme aggiuntivo di attività svolte in parallelo al ciclo di vita del sistema per i sistemi correlati con la sicurezza (50129)Piano della Sicurezza (Safety Plan)
un insieme documentato di attività programmate nel tempo, risorsun insieme documentato di attività programmate nel tempo, risorse ed eventi che servono ad attuare la struttura e ed eventi che servono ad attuare la struttura organizzativa, le responsabilità, le procedure, le attività, le organizzativa, le responsabilità, le procedure, le attività, le capacità e le risorse che insieme garantiscono che un capacità e le risorse che insieme garantiscono che un oggetto soddisferà i requisiti di sicurezza dati, relativi ad unoggetto soddisferà i requisiti di sicurezza dati, relativi ad un dato contratto o progetto (50126)dato contratto o progetto (50126)dettagli della attuazione che indicano il modo in cui i requisitdettagli della attuazione che indicano il modo in cui i requisiti di sicurezza del progetto saranno raggiunti (50129)i di sicurezza del progetto saranno raggiunti (50129)
Processo di sicurezza (Safety Process) insieme delle procedure de seguire per consentire l’identificazione e la soddisfazione di tutti i requisiti di sicurezza di un prodotto (50129)Gestione della sicurezza (Safety Management) struttura di gestione che garantisce che il processo di sicurezza viene correttamente attuato (50129)Dossier di sicurezza (Safety Case) la dimostrazione documentata che il prodotto è conforme a specificati requisiti di sicurezza (50126)Integrità della sicurezza (Safety Integrity)
il grado di fiducia assegnato ad un sistema per svolgere soddisfil grado di fiducia assegnato ad un sistema per svolgere soddisfacentemente le funzioni di sicurezza richieste in tutte acentemente le funzioni di sicurezza richieste in tutte le condizioni fissate all’interno di un fissato periodo di tempole condizioni fissate all’interno di un fissato periodo di tempo (50126)(50126)attitudine di un sistema correlato con la sicurezza di compiere attitudine di un sistema correlato con la sicurezza di compiere le sue funzioni di sicurezza in tutte le condizioni le sue funzioni di sicurezza in tutte le condizioni specificate, all’interno di un ambiente operativo specificato edspecificate, all’interno di un ambiente operativo specificato ed entro un definito periodo di tempo (50159)entro un definito periodo di tempo (50159)
Livello di integrità della sicurezza (Safety Integrity Level)uno dei livelli di un insieme definito e discreto di livelli utiuno dei livelli di un insieme definito e discreto di livelli utilizzato per specificare i requisiti di integrità della sicurezzalizzato per specificare i requisiti di integrità della sicurezzadelle funzioni di sicurezza da assegnare ai sistemi connessi condelle funzioni di sicurezza da assegnare ai sistemi connessi con la sicurezza. Il SIL con il valore più alto ha il più alto la sicurezza. Il SIL con il valore più alto ha il più alto livello di integrità della sicurezza (50126)livello di integrità della sicurezza (50126)numero che indica il grado richiesto di confidenza che il sistemnumero che indica il grado richiesto di confidenza che il sistema realizzerà le sue funzioni di sicurezza, tenendo a realizzerà le sue funzioni di sicurezza, tenendo conto dei suoi malfunzionamenti sistematici (50129)conto dei suoi malfunzionamenti sistematici (50129)
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 1818
RAILWAY EVOLUTION
Sistemi in sicurezzaSistemi in sicurezzaAnalisi del Rischio (50126 – 50129)
Analisi delle situazioni pericolose (Hazard Analysis) Il processo di identificazione degli hazard e l’analisi delle cause e la definizione dei requisiti per limitare le conseguenze degli hazard ad un livello tollerabile (50129)Rischio Tollerabile (Tolerable Risk) Il massimo livello di rischio di un prodotto che è accettabile per l’autorità ferroviaria (50126)Stato sicuro (Safe State) Una condizione che continua a preservare la sicurezza (50129)Sicurezza (Safety) Assenza di rischio inaccettabile (50126 – 50129)Registro delle Situazioni Pericolose (Hazard Log) Il documento in cui tutte le attività di gestione della sicurezza, le situazioni pericolose identificate, le decisioni prese e le situazioni adottate vengono registrate o referenziate (50126 - 50129)
Accettabile con/senza l’accordo dell’Autorità FerroviariaTrascurabile
Accettabile con controllo adeguato e con l’Accordo dell’Autorità Ferroviaria.Tollerabile
Deve essere accettato solo quando la riduzione del rischio è impraticabile e con l’accordo dell’Autorità ferroviaria o , laddove occorre l’Autorità Ferroviaria.
Indesiderabile
Deve essere eliminato.Intollerabile
Azioni da applicare nei confronti di ogni categoriaCategorie di rischio
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 1919
RAILWAY EVOLUTION
Sistemi in sicurezzaSistemi in sicurezzaGuasti e Malfunzionamenti
Guasto casualeGuasto casuale (Random Fault) accadimento imprevedibile di un guasto
Guasto sistematicoGuasto sistematico (Systematic Fault) guasto intrinseco nella specificazione, progettazione, fabbricazione, installazione, esercizio e manutenzione di un sistema, sottosistema o apparecchiatura
Tempo di rilevazione di un guastoTempo di rilevazione di un guasto (Fault Detection Time) intervallo di tempo che inizia nel momento in cui avviene un guasto e che finisce quando il guasto è stato rilevato – anche tempo di latenza del guasto
NegazioneNegazione (Negation) imposizione di uno stato sicuro a seguito del rilevamento di un guasto pericoloso
Tempo di NegazioneTempo di Negazione (Negation Time) intervallo di tempo che inizia nel momento in cui l’esistenza di un guasto è rilevata e che finisce quando lo stato sicuro è stato imposto
Malfunzionamento di modo comuneMalfunzionamento di modo comune (Common Cause Failure) malfunzionamento comune per elementi che è previsto siano indipendenti
In sicurezzaIn sicurezza (Fail Safe) concetto incluso nella progettazione di un prodotto, in modo che, nell’eventualità di un guasto, esso entri o rimanga in uno stato di sicurezza
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 2020
RAILWAY EVOLUTION
Sistemi in sicurezzaSistemi in sicurezzaSpecifica dei requisiti di Sicurezza
Specifica Requisiti di Sistema
•• Identificazione e analisi degli Hazard (PHA e HA) Identificazione e analisi degli Hazard (PHA e HA) •• RISK Assessment e Classificazione RISK Assessment e Classificazione •• Allocazione dei SILAllocazione dei SILRequisiti non di
Sicurezza
SPECIFICA DEI REQUISITI DI SICUREZZASPECIFICA DEI REQUISITI DI SICUREZZA
Requisiti di Integrità della Sicurezza
Requisiti Funzionali di Sicurezza
Integrità rispetto al malfunzionamento sistematico
Integrità rispetto al malfunzionamentocasuale
Le specifiche dei requisiti per ciascun sistema, sottosistema, apparecchiatura che ha funzioni di sicurezza devono essere identificate e documentate nelle Specifiche dei Requisiti di Sicurezza (SRS). La specifica dei requisiti di sicurezza può essere incluse inclusa nella specifica dei requisiti funzionali o può essere un documento a parte.
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 2121
RAILWAY EVOLUTION
Sistemi in sicurezzaSistemi in sicurezzaDifesa dai malfunzionamenti sistematici
Pianificazione, progettazione e sviluppo in QualitàCiclo di vita della sicurezza
Eliminazione degli errori di progettazione dell’HardwareEliminazione degli errori di progettazione dell’HardwareEliminazione degli errori di progettazione del SoftwareEliminazione degli errori di progettazione del Software
Test esaustivi dell’Hardware, utilizzando strumenti e tools adeguatiProcedure di collaudo efficaci
Eliminazione di difetti sistematici di progettazione e di produzEliminazione di difetti sistematici di progettazione e di produzioneioneTest esaustivi del Software
Eliminazione degli errori di implementazioneEliminazione degli errori di implementazioneVerifica, Validazione
Controllo dei risultati intermedi della progettazione e sviluppoControllo dei risultati intermedi della progettazione e sviluppoTesting esaustivo a fronte dei Requisiti applicabiliTesting esaustivo a fronte dei Requisiti applicabili
Controlli run-time di congruità del comportamento dell’HardwareRilevazione di malfunzionamenti dovuti a errori di progettazioneRilevazione di malfunzionamenti dovuti a errori di progettazione HardwareHardware
Controlli run time di congruità dei risultati delle elaborazioni SoftwareRilevazione di malfunzionamenti dovuti a errori di progettazioneRilevazione di malfunzionamenti dovuti a errori di progettazione Hardware o SoftwareHardware o Software (ma (ma anche a guasti casuali)anche a guasti casuali)
DiversityRilevazione di errori di progettazioneRilevazione di errori di progettazione (ma solo di quelli che non provocano malfunzionamenti (ma solo di quelli che non provocano malfunzionamenti comuni). Anche Hardware ma tipicamente Software.comuni). Anche Hardware ma tipicamente Software.
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 2222
RAILWAY EVOLUTION
Sicurezza intrinseca (Inherent fail-safety)Queste tecniche permettono di eseguire le funzioni safety-related anche con un singolo elemento a patto che ogni modo di guasto credibile dell’elemento non produca hazard.Può essere usata per certe funzioni all’interno di sistemi ove è applicata la composite e reactive fail-safety ad esempio per assicurare l’indipendenza tra gli elementi o per rinforzare la soluzione di un guasto quando è stato rilevato.
Sicurezza reattiva (Reactive fail-safety)Queste tecniche permettono di eseguire le funzioni safetyQueste tecniche permettono di eseguire le funzioni safety--related mediante un singolo related mediante un singolo elemento, a patto che queste operazioni siano in grado di garantelemento, a patto che queste operazioni siano in grado di garantire una rapida rilevazione ire una rapida rilevazione e correzione del guasto. (per esempio mediante calcolo multiplo e correzione del guasto. (per esempio mediante calcolo multiplo e confronto o e confronto o monitoraggio continuo). In questo caso il check e il rilevamentomonitoraggio continuo). In questo caso il check e il rilevamento della funzione deve della funzione deve essere visto come secondo elemento e deve essere indipendente peessere visto come secondo elemento e deve essere indipendente per evitare cause di r evitare cause di guasto comune.guasto comune.
Sicurezza composita (Composite fail-safety)Con questa tecnica ogni funzione safetyCon questa tecnica ogni funzione safety--related è eseguita da almeno due elementi. related è eseguita da almeno due elementi. Ognuno di questi elementi è indipendente dagli altri per evitareOgnuno di questi elementi è indipendente dagli altri per evitare le cause comuni di guasto.le cause comuni di guasto.Un guasto casuale in un elemento deve essere riconosciuto e risUn guasto casuale in un elemento deve essere riconosciuto e risolto in un tempo olto in un tempo
sufficiente per evitare che un guasto coincidente avvenga nel ssufficiente per evitare che un guasto coincidente avvenga nel secondo elemento.econdo elemento.
Sistemi in sicurezzaSistemi in sicurezzaDifesa dai malfunzionamenti casuali
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 2323
RAILWAY EVOLUTION
Sistemi in sicurezzaSistemi in sicurezzaSicurezza composita – esempio 2oo2
OSCommon SWSpecific SW
µ1
Watchdog HW & synchronization
OSCommon SWSpecific SW
µ2Votation HW(Serial Lines)
Interface to specific HW Interface to specific HW
Specific HW Specific HW
Application SW
I due micro sono sincronizzaticondividendo un segnale di timer (single failure point)Tutti gli input vitali vengono consolidati per votazione prima di passarli al SW ApplicativoTutti i risultati del SW Applicativo sono consolidatiper votazione prima di tradurli in output vitaliGli output vitali possono essere ancora verificati con un votatore hardwareMeccanismo di watchdogCapacità di fault-detection, ma non di fault-toleranceL’affidabilità complessiva è inferiore a quella di un singolo micro
I/O vitali I/O non vitali I/O vitali I/O non vitali
Canale 1 Canale 2
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 2424
RAILWAY EVOLUTION
Sistemi in sicurezzaSistemi in sicurezzaSicurezza composita – esempio 2oo3
OSCommon SWSpecific SW
µ1
Specific HW
I/O vitali I/O non vitali
Canale 1
OSCommon SWSpecific SW
µ2
Specific HW
I/O vitali I/O non vitali
Canale 2
OSCommon SWSpecific SW
µ3
Specific HW
I/O vitali I/O non vitali
Canale 3
Consolidation & Synchronisation LinesI canali sono sincronizzati con un protocollo gestito dal SoftwareTutti gli input vitali vengono consolidati a maggioranza prima di passarli al SW ApplicativoTutti i risultati del SW Applicativo sono consolidati a maggioranza prima di tradurli in output vitaliGli output vitali possono essere ancora verificati con un votatore hardwareLa correttezza di ogni canale viene valutata a maggioranza e un canale in errore può essere escluso dagli altriCapacità di fault-tolerance: al guasto di un canale rimane ancora un 2oo2 in sicurezzaL’affidabilità complessiva è superiore a quella di un singolo micro
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 2525
RAILWAY EVOLUTION
Sistemi in sicurezzaSistemi in sicurezzaLa sicurezza composita non basta . . .
La sicurezza composita implica l’esecuzione multipla e indipendente di una funzione con il confronto del risultato finale
È in grado di rilevare in sicurezza un È in grado di rilevare in sicurezza un malfunzionamentomalfunzionamento presente su un solo canale presente su un solo canale quando il malfunzionamento influenza i valori di output vitalequando il malfunzionamento influenza i valori di output vitaleMA non sempre un non sempre un guastoguasto provoca un provoca un malfunzionamentomalfunzionamento nell’immediato. Il guasto può nell’immediato. Il guasto può rimanere rimanere latentelatente per un periodo anche lungo fino a che non si danno le condizionper un periodo anche lungo fino a che non si danno le condizioni che i che lo attivano e solo allora avviene il malfunzionamentolo attivano e solo allora avviene il malfunzionamentoINOLTREINOLTRE il malfunzionamento può manifestarsi in maniera tale da non infil malfunzionamento può manifestarsi in maniera tale da non influenzare luenzare immediatamente i risultati finali della funzione. Questo prolungimmediatamente i risultati finali della funzione. Questo prolunga ancora il tempo di a ancora il tempo di latenza del guastolatenza del guasto
La presenza di un guasto latente non diagnosticato fa crescere costantemente la probabilità di un guasto nell’altro (in un altro) canale capace di provocare un malfunzionamento concomitante
È fondamentale contenere il più possibile il È fondamentale contenere il più possibile il tempo di latenzatempo di latenza dei guasti, per questo alla dei guasti, per questo alla sicurezza composita occorre sovrapporre tecniche di sicurezza composita occorre sovrapporre tecniche di sicurezza reattivasicurezza reattivaAlcune sfruttano la ridondanza Hardware (votazione degli Alcune sfruttano la ridondanza Hardware (votazione degli inputinput e di e di valori intermedivalori intermedi))Altre si applicano su ciascun canale (Altre si applicano su ciascun canale (diagnostichediagnostiche e e programmazione difensivaprogrammazione difensiva))In ogni caso anticipano il In ogni caso anticipano il rilevamentorilevamento del guasto e la messa in sicurezza del sistema del guasto e la messa in sicurezza del sistema (se 2oo2) oppure l’esclusione di un canale (se 2ooX)(se 2oo2) oppure l’esclusione di un canale (se 2ooX)
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 2626
RAILWAY EVOLUTION
Il Software nel ciclo di vita di SistemaIl Software nel ciclo di vita di SistemaCiclo di vita di sistemi in sicurezza (2)
System Requirements Specification
Hazard Analysis & Risk Assessment
Safety Requirements Specification
System Architecture Design
Hardware Design
Software Design
System Test / Validation
Safety Functional RequirementsSafety Integrity Requirements
Systematic Failure Integrity
Random Failure Integrity
Functional Safety Test / Validation
Quality Management Report Safety Management Report
Technical Safety Report
Integration & Installation Tests
Hardware Validation
Software Validation
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 2727
RAILWAY EVOLUTION
Il Software nel ciclo di vita di SistemaIl Software nel ciclo di vita di Sistema
Contributo del Software alla sicurezza del SistemaContributi positivi
Grande flessibilità nella Grande flessibilità nella realizzazione delle funzioni di sicurezzarealizzazione delle funzioni di sicurezza del sistema. La del sistema. La capacità del software di combinare grandi quantità di informaziocapacità del software di combinare grandi quantità di informazioni in modo ni in modo complesso e controllare dispositivi complicati non ha paragonicomplesso e controllare dispositivi complicati non ha paragoniSupporto alla Supporto alla sicurezza reattivasicurezza reattiva per mezzo di per mezzo di diagnostichediagnostiche sofisticate che non sofisticate che non potrebbero essere realizzate ad hardwarepotrebbero essere realizzate ad hardwareSupporto alla sicurezza composita con Supporto alla sicurezza composita con meccanismi di votazionemeccanismi di votazione più efficaci di più efficaci di quelli realizzabili ad hardwarequelli realizzabili ad hardware
Contributi negativiUtilizzare il Software comporta un investimento rilevante in terUtilizzare il Software comporta un investimento rilevante in termini di costo, mini di costo, ingombro e complessità dell’Hardware, con diminuzione della sua ingombro e complessità dell’Hardware, con diminuzione della sua affidabilitàaffidabilitàLa caratteristica fondamentale del Software di non avere una QuaLa caratteristica fondamentale del Software di non avere una Qualità misurabile e lità misurabile e una funzionalità dimostrabile in modo esaustivo espongono il Sisuna funzionalità dimostrabile in modo esaustivo espongono il Sistema a tema a malfunzionamenti sistematicimalfunzionamenti sistematici di modo comune capaci di rendere inefficace la di modo comune capaci di rendere inefficace la sicurezza compositasicurezza compositaPer questo motivo, il ciclo di vita del Software in sicurezza è Per questo motivo, il ciclo di vita del Software in sicurezza è particolarmente particolarmente onerosooneroso in termini di sviluppo, test, verifica e validazionein termini di sviluppo, test, verifica e validazione
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 2828
RAILWAY EVOLUTION
Il Software nel ciclo di vita di SistemaIl Software nel ciclo di vita di Sistema
Alcuni contributi negativi
Space missions lost due to softwarefailures
Mariner 1 (July 1962)Mariner 1 (July 1962)omission of a hyphen in a computer omission of a hyphen in a computer instructioninstruction
Ariane 501 (June 1996)Ariane 501 (June 1996)unhandled software exceptionunhandled software exception
Titan IVTitan IV--B (April 1999)B (April 1999)incorrect parameter in the attitude control incorrect parameter in the attitude control system system
Mars Climate Orbiter (September Mars Climate Orbiter (September 1999)1999)
failed translation of English units into metric failed translation of English units into metric unitsunits
Mars Polar Lander and Mars Polar Lander and DDeep Space 2 eep Space 2 (December 1999)(December 1999)
causecause uncertain … uncertain … but the testing activity was not adequatebut the testing activity was not adequate
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 2929
RAILWAY EVOLUTION
Il Software nel ciclo di vita di SistemaIl Software nel ciclo di vita di Sistema
Dal sito ANSI – IEC, normativa IEC 61805
ALL PARTS IEC 61508-SER Ed.1.0 b:2004
Part 7: Overview of techniques and measures IEC 61508-7 Ed.1.0 b:2000
Part 6: Guidelines on the application of IEC 61508-2 and IEC 61508-3
IEC 61508-6 Ed.1.0 b:2000
Part 5: Examples of methods for the determination of safety integrity levels
IEC 61508-5 Ed.1.0 b:1998
Part 4: Definitions and abbreviations IEC 61508-4 Ed.1.0 b:1998
Part 3: Software requirements IEC 61508-3 Ed.1.0 b:1998
Part 2: Requirements for electrical/electronic/programmable electronic safety-related systems
IEC 61508-2 Ed.1.0 b:2000
Part 1: General requirements IEC 61508-1 Ed.1.0 b:1998
Functional safety of electrical/electronic/programmable electronic safety-related systems
Document #
CEI EN 50128 è stata derivata da queste normative, adattandole all’ambiente ferroviario
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 3030
RAILWAY EVOLUTION
Il Software nel ciclo di vita di SistemaIl Software nel ciclo di vita di Sistema
Ciclo di vita del Software (SIL > 0)
Fase di Sviluppo del Sistema
Progettazione e Architettura Software
Progettazione dei Moduli Software
Test dei Moduli Software
Codifica
Integrazione del Software
Integrazione Software/Hardware
Validazione del Software
Accettazione del Software
Manutenzione del Software
Specifica dei Requisiti Software
Verifica
Test
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 3131
RAILWAY EVOLUTION
Il Software nel ciclo di vita di SistemaIl Software nel ciclo di vita di SistemaRuoli di riferimento (CEI EN 50128)
Specifica dei Requisiti Sw (art. 8)
Architettura del Sw (art. 9)
Progetto e Sviluppo del Sw (art. 10)
Integrazione Sw /Hw (art. 12)
D
VV
Progettista
Specifica dei Test dei Requisiti SW (art. 8)
Validazione del Sw (art. 13)
VVVerificatore Verifica e Test del Sw (art. 11)
Validatore
Valutazione del Sw (art. 14)TUVValutatore
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 3232
RAILWAY EVOLUTION
Il Software e la sicurezzaIl Software e la sicurezzaTecniche di sicurezza per il Software
3. Codici di Correzione Errore - - - - -
TECNICA / PROVVEDIMENTO SWSIL 0
SWSIL 1
SWSIL 2
SWSIL 3
SWSIL 4
1. Programmazione Difensiva (B.15) - R R HR HR
2. Rilevamento Guasto & Diagnosi (B.27) - R R HR HR
4. Codici di Rilevamento Errore (B.20) - R R HR HR
5. Failure Assertion Programming (B.25) - R R HR HR
6. Tecniche del Safety Bag (B.54) - R R R R
7. Programmazione Diversificata (B.17) - R R HR HR
8. Recovery Block - R R R R
9. Backward Recovery - NR NR NR NR
10. Forward Recovery - NR NR NR NR
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 3333
RAILWAY EVOLUTION
Il Software e la sicurezzaIl Software e la sicurezzaTecniche di sicurezza per il Software
TECNICA / PROVVEDIMENTO SWSIL 0
SWSIL 1
SWSIL 2
SWSIL 3
SWSIL 4
11. Meccanismi di Re-try e Fault Recovery
- R R R R
12. Memorizzazione dei Casi Eseguiti(B.39)
- R R HR HR
13. Intelligenza Artificiale -Correzione del Guasto
- NR NR NR NR
14. Riconfigurazione Dinamica del software
- NR NR NR NR
15. Analisi dell’ Effetto dell’ ErroreSoftware (B.26)
- R R HR HR
16. Analisi dell’ Albero dei Guasti(B.28)
R R R HR HR
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 3434
RAILWAY EVOLUTION
Il Software e la sicurezzaIl Software e la sicurezzaTecniche raccomandate dalla normativa
Combinazioni di tecniche APPROVATE per SwSIL 3 e 4:
a) 1, 7 e una di 4, 5 o 12b) 1, 4 e 5c) 1, 4 e 12d) 1, 2 e 4e) 1 e 4, e una di 15 e 16
Programmazione Difensiva (1)
va SEMPRE applicata in combinazione con almeno una di:
Rilevamento Guasto & Diagnosi (2)(2)
Codici di Rilevamento Errori (4)
Failure Assertion Programming (5)
Programmazione Diversificata (7)
Memorizzazione dei Casi Eseguiti (12)
Analisi dell’ Effetto dell’ Errore Software (15)
Analisi dell’ Albero dei Guasti (16)
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 3535
RAILWAY EVOLUTION
Il Software e la sicurezzaIl Software e la sicurezzaProgrammazione difensiva
Consiste nell’inserire codice supplementare, capace di rilevare flussi anomali di dati e di controllo durante l’esecuzioneControllo del range dei valori delle variabili e dei parametri dei sottoprogrammi
In “C” occorre riprodurre “a mano” i controlli che un compilatorIn “C” occorre riprodurre “a mano” i controlli che un compilatore Ada introduce e Ada introduce automaticamente per realizzare il controllo forte sui tipiautomaticamente per realizzare il controllo forte sui tipi
Controllo della plausibilità dei valori con un significato fisicoControllo della plausibilità dei puntatori rispetto ai limiti delle memorie
Puntatori a sottoprogrammi devono avere un valore plausibile perPuntatori a sottoprogrammi devono avere un valore plausibile per la FLASH o la FLASH o la EPROMla EPROMPuntatori a dati devono avere un valore plausibile per la RAM, cPuntatori a dati devono avere un valore plausibile per la RAM, che spesso si he spesso si può ancora restringere (buffers, stack dei task etc.)può ancora restringere (buffers, stack dei task etc.)
Limitazione del numero massimo di iterazioni previste per un loopLimitazione di accessibilità a dati importanti (es. fornire l’indice di un array di strutture dati anziché il puntatore all’elemento)
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 3636
RAILWAY EVOLUTION
Il Software e la sicurezzaIl Software e la sicurezzaCodici di Rilevazione e Correzione Errore
Generazione e controllo di “firme” associate a blocchi di dati che permettono di rilevare la corruzione dei dati.
Ad ogni informazione di “N” bit viene associato un blocco di “k” bit con un algoritmo opportuno
Sono tipicamente i CRC e i CHECKSUM utilizzati per le comunicazioni
Hanno anche altre applicazioni, come proteggere dai guasti strutture dati di primaria importanza (es, la tabella di schedulazione di un Sistema Operativo. In questo caso la “firma” viene controllata prima di ogni accesso e rigenerata dopo gli accessi in scrittura
Un caso particolare è costituito dai “campi minati”Se esiste una istruzione assembler che blocca il processore, la Se esiste una istruzione assembler che blocca il processore, la memoria di memoria di programma che non contiene il codice eseguibile può essere riempprogramma che non contiene il codice eseguibile può essere riempita con quella ita con quella istruzione, utilizzando l’ambiente di sviluppoistruzione, utilizzando l’ambiente di sviluppoSe per un guasto un puntatore a codice esce dallo spazio del proSe per un guasto un puntatore a codice esce dallo spazio del programma, il canale gramma, il canale si arrestasi arresta
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 3737
RAILWAY EVOLUTION
Il Software e la sicurezzaIl Software e la sicurezzaFailure Assertion programming
Prima della esecuzione di una sequenza di statement si verifica la validità di una pre-condizioneDopo l’esecuzione si verifica la validità di una post-condizioneSe una delle condizioni non risulta vera, si rileva un malfunzionamento
assertassert <<prepre--conditioncondition>;>;Action1;Action1;....Action x;Action x;
assertassert <<postpost--conditioncondition>;>;Esempio: contatori up-down
Per eseguire una sequenza di statement un numero N di volte si uPer eseguire una sequenza di statement un numero N di volte si utilizzano due tilizzano due contatori, uno inizializzato a zero, l’altro a Ncontatori, uno inizializzato a zero, l’altro a NAd ogni iterazione si decrementa un contatore e si incrementa l’Ad ogni iterazione si decrementa un contatore e si incrementa l’altroaltroPrima e dopo ogni iterazione vale la condizione che la somma deiPrima e dopo ogni iterazione vale la condizione che la somma dei contatori deve contatori deve essere uguale a Nessere uguale a N
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 3838
RAILWAY EVOLUTION
Il Software e la sicurezzaIl Software e la sicurezzaRilevamento Guasto & Diagnosi
Questa tecnica comprende il contributo del Software alla sicurezza reattiva e composita
Meccanismi di votazione e relativi meccanismi di comunicazioneMeccanismi di votazione e relativi meccanismi di comunicazioneDiagnostiche dell’hardwareDiagnostiche dell’hardwareStrategie di recupero rispetto ai guasti, gestione delle configuStrategie di recupero rispetto ai guasti, gestione delle configurazioni razioni degradate del sistemadegradate del sistema
Caso molto importante : il software di un sistema Caso molto importante : il software di un sistema 2oo32oo3 a seguito del a seguito del fallimentofallimentodi un canale deve essere in grado di supportare il sistema di un canale deve essere in grado di supportare il sistema 2oo22oo2 risultante, risultante, modificando meccanismi e politiche di gestionemodificando meccanismi e politiche di gestione
Analisi della consistenza di sensori ridondatiAnalisi della consistenza di sensori ridondatiMeccanismi per la autoMeccanismi per la auto--esclusione del canale in caso di guasti non esclusione del canale in caso di guasti non recuperabili o per l’esclusione di un canale da parte degli altrrecuperabili o per l’esclusione di un canale da parte degli altri canalii canali
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 3939
RAILWAY EVOLUTION
Il Software e la sicurezzaIl Software e la sicurezzaProgrammazione diversificata
Può essere usata in concomitanza con la diversity dell’Hardware ridondato
Consiste nel realizzare una funzione Software in N versioni, progettate e sviluppate in modo indipendente. Tutte le versioni della funzione vengono eseguite ed i risultati confrontati
Rileva a run time errori di progettazione software
Permette di rilevare e mascherare errori, non di eliminarli
Non implica necessariamente ridondanza dell’hardwareLe N versioni della funzione possono girare in parallelo su N coLe N versioni della funzione possono girare in parallelo su N computer uguali (o diversi)mputer uguali (o diversi)
Le N versioni della funzione possono essere eseguite in sequenzaLe N versioni della funzione possono essere eseguite in sequenza sullo stesso computersullo stesso computer
Spesso i progettisti adottano soluzioni simili e fanno errori simili, inoltre i sistemi Software embedded hanno requisiti così stringenti da “forzare” determinate soluzioni
I costi di sviluppo del Software diventano molto elevati
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 4040
RAILWAY EVOLUTION
Il Software e la sicurezzaIl Software e la sicurezzaSegregazione di SW a SIL diversi
Sulla stessa CPU possono “girare” in time-sharing:componenti SW che realizzano (parti di) funzioni ad componenti SW che realizzano (parti di) funzioni ad alta integritàalta integrità
componenti SW a livello di integrità minorecomponenti SW a livello di integrità minore
Occorre proteggere la parte in sicurezza da quella “normale” cheha subito un processo di V&V meno esaustivo
Il SW a bassa integrità non deve avere accesso a variabili del SIl SW a bassa integrità non deve avere accesso a variabili del SW ad alta W ad alta integritàintegrità
Il SW ad alta integrità non deve chiamare procedure (in particolIl SW ad alta integrità non deve chiamare procedure (in particolare funzioni) are funzioni) del SW a bassa integritàdel SW a bassa integrità
Se il sistema SW è concorrente, i task a bassa integrità devono Se il sistema SW è concorrente, i task a bassa integrità devono avere avere priorità inferiore rispetto a quelli ad alta integritàpriorità inferiore rispetto a quelli ad alta integrità
L’approccio migliore è comunque la segregazione fisica, allocando sull’Hardware solo Software con lo stesso SIL
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 4141
RAILWAY EVOLUTION
Il Software e la sicurezzaIl Software e la sicurezzaSegregazione di SW a SIL diversi
Un SW embedded ha tipicamente almeno 4 modi operativiBootBoot
Codice, spesso in Assembler, che viene eseguito al reset della sCodice, spesso in Assembler, che viene eseguito al reset della scheda. Inizializza cheda. Inizializza l’hardware di base (CPU, memoria, seriali) e termina mandando inl’hardware di base (CPU, memoria, seriali) e termina mandando in esecuzione il esecuzione il software di uno degli altri modi operativi. Gira tipicamente in software di uno degli altri modi operativi. Gira tipicamente in ROM.ROM.
DownloadDownloadCodice a bassa integrità che serve a caricare nella memoria non Codice a bassa integrità che serve a caricare nella memoria non volatile nuove volatile nuove revisioni del software (di tutti i modi operativi). Gira tipicamrevisioni del software (di tutti i modi operativi). Gira tipicamente in RAM, per poter ente in RAM, per poter caricare anche “se stesso”. caricare anche “se stesso”.
TestTestCodice a bassa integrità per il test dell’hardware in laboratoriCodice a bassa integrità per il test dell’hardware in laboratorio e/o sul campo o e/o sul campo (validazione, collaudo, manutenzione). Gira tipicamente in ROM.(validazione, collaudo, manutenzione). Gira tipicamente in ROM.
NominaleNominaleCodice ad alta integrità che realizza le funzioni nominali, compCodice ad alta integrità che realizza le funzioni nominali, comprese quelle in rese quelle in sicurezza. Il sicurezza. Il downloaddownload del software Nominale deve essere eseguito in sicurezza.del software Nominale deve essere eseguito in sicurezza.
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 4242
RAILWAY EVOLUTION
Il Software e la sicurezzaIl Software e la sicurezzaSegregazione di SW a SIL diversi
BootBoot
NominaleNominale TestTest
Board Support Package (BSP)Board Support Package (BSP)
ProtocolloProtocollo
DownloadDownload
Sistema Sistema OperativoOperativo
4 programmi separatiil Programma di Boot, link della Componente Boot. il Programma di Download, Componenti Download e BSP. il Programma di Test, Componenti Test e BSP. il Programma Nominale, Componenti Nominale, Sistema Operativo, Protocollo e BSP. l’ambiente di sviluppo (compilatore + linker) garantisce che non esistono accessi incrociati a codice e/o dati;tutti i programmi tranne il Nominale sono attivi in momenti in cui il sistema non eroga servizi vitali;programmi che gestiscono i modi operativi sono eseguiti in alternativa;lo stato operativo non può essere commutato a run-time
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 4343
RAILWAY EVOLUTION
Il Software e la sicurezzaIl Software e la sicurezzaCompilatori validati
La normativa richiede che tutti i tools utilizzati per lo sviluppo abbiano comprovate caratteristiche di qualità e integrità, in particolare il traduttore
Traduttore Provato con l’UsoTraduttore utilizzato per un lungo periodo per produrre sistemi Traduttore utilizzato per un lungo periodo per produrre sistemi similisimiliOccorre che siano state raccolte le Occorre che siano state raccolte le nonnon--conformitàconformità riscontrate e le relative riscontrate e le relative contromisurecontromisureQuesto approccio introduce una notevole Questo approccio introduce una notevole rigiditàrigidità rispetto alle innovazionirispetto alle innovazioni
Traduttore ValidatoDovrebbe avere un “Dovrebbe avere un “certificatocertificato” rilasciato da ente indipendente e accreditato” rilasciato da ente indipendente e accreditatoPiù spesso esiste una “Più spesso esiste una “validation suitevalidation suite” rilasciata dal produttore o da ente ” rilasciata dal produttore o da ente terzo, che generalmente dimostra solo la rispondenza allo terzo, che generalmente dimostra solo la rispondenza allo standardstandard del del linguaggio (es. ANSI “C”)linguaggio (es. ANSI “C”)Esistono tool per la generazione automatica di Test Cases per laEsistono tool per la generazione automatica di Test Cases per la verifica di verifica di caratteristiche specifiche del generatore di codice (es. Plum Hacaratteristiche specifiche del generatore di codice (es. Plum Hall)ll)
L’esecuzione sul target dei Test di Modulo fornisce buona confidL’esecuzione sul target dei Test di Modulo fornisce buona confidenza sulla enza sulla corretta generazione del codice corretta generazione del codice
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 4444
RAILWAY EVOLUTION
Il Software e la sicurezzaIl Software e la sicurezzaRun Time Supports
Si integra con il Software applicativo un software di cui non si conosce il livello di qualità e di integritàPuò essere il Sistema Operativo oppure il “motore” di un linguaggio di programmazione concorrente (Ada, Java etc.)
Per il Sistema Operativo, se si hanno i sorgenti, lo si può insePer il Sistema Operativo, se si hanno i sorgenti, lo si può inserire nel ciclo di vita del rire nel ciclo di vita del Software come la parte applicativa. In questo caso conviene modiSoftware come la parte applicativa. In questo caso conviene modificarlo per ficarlo per aumentarne l’integrità (programmazione difensiva etc.) aumentarne l’integrità (programmazione difensiva etc.) In tutti gli altri casi occorre un In tutti gli altri casi occorre un certificatocertificato rilasciato da ente accreditato, ma la rilasciato da ente accreditato, ma la certificazione non dovrebbe essere solo funzionalecertificazione non dovrebbe essere solo funzionaleAltrimenti occorre che il produttore fornisca altre Altrimenti occorre che il produttore fornisca altre evidenzeevidenze della qualità dello sviluppo della qualità dello sviluppo del Software. Implica problemi di riservatezza. In certi casi ildel Software. Implica problemi di riservatezza. In certi casi il produttore si può produttore si può interfacciare direttamente con l’ente certificatore del sistemainterfacciare direttamente con l’ente certificatore del sistema
In generale il Run Time Support fornisce funzionalità “esuberanti” rispetto alle necessità di un Software embedded in sicurezza. Alcune di esse possono essere inadatte e vanno opportunamente limitate (Ravenscar)
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 4545
RAILWAY EVOLUTION
Meccanismi di sicurezza realizzati dal Meccanismi di sicurezza realizzati dal softwaresoftware
Gestione del Watch-dog
Simulatori Boa
Il circuito di watch-dog è un hardware fail-safe (sicurezza intrinseca) che interrompe le alimentazioni dei micro se le forme d’onda (segnale di trigger) in ingresso non sono esattamente allineate. Occorre che i due micro siano sincronizzati.La generazione del trigger tipicamente avviene variando periodicamente il valore di un output digitale.La generazione del trigger non dovrebbe avvenire per mezzo di un interrupt. È desiderabile che il trigger non venga più generato a fronte del malfunzionamento del Software più lieve possibile. Tutte le diagnostiche, quando scattano, possono inibire la generazione del trigger.
sincronismosincronismo
Micro AMicro A Micro BMicro B
votazionivotazioni
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 4646
RAILWAY EVOLUTION
Meccanismi di sicurezza realizzati dal Meccanismi di sicurezza realizzati dal softwaresoftware
Diagnostiche della memoria
Tipi di memorie considerati (rispetto alla CPU del micro)Memorie readMemorie read--onlyonly
ROMROM : tutti i tipi di memoria che possono essere aggiornati con app: tutti i tipi di memoria che possono essere aggiornati con apparecchiature specifiche, arecchiature specifiche, generalmente togliendo il supporto fisico dalla scheda micro.generalmente togliendo il supporto fisico dalla scheda micro.EPROMEPROM : tutti i tipi di memorie che possono essere aggiornate dal sof: tutti i tipi di memorie che possono essere aggiornate dal software che gira sulla tware che gira sulla CPU, ma non a livello di singola locazione. In generale è possibCPU, ma non a livello di singola locazione. In generale è possibile aggiornare ile aggiornare complessivamente un blocco (o settore) per volta. Sono comprese complessivamente un blocco (o settore) per volta. Sono comprese le memorie le memorie FLASHFLASH..
Memorie readMemorie read--writewriteRAM dinamicaRAM dinamica : deve essere periodicamente aggiornata (refresh) dalla CPU.: deve essere periodicamente aggiornata (refresh) dalla CPU.RAM staticaRAM statica : mantiene il contenuto fino a quando il micro è alimentato.: mantiene il contenuto fino a quando il micro è alimentato.RAM non volatileRAM non volatile : ha una batteria tampone e mantiene il contenuto per tutta la : ha una batteria tampone e mantiene il contenuto per tutta la durata della durata della batteria.batteria.
In generale:il Software in sicurezza non dovrebbe essere caricato in RAM, mail Software in sicurezza non dovrebbe essere caricato in RAM, ma dovrebbe “girare” da una dovrebbe “girare” da una memoria readmemoria read--only.only.Le diagnostiche della memoria vanno eseguite allo startLe diagnostiche della memoria vanno eseguite allo start--up e periodicamente a runup e periodicamente a run--time, quindi è time, quindi è opportuno limitare la memoria sulla scheda a quella strettamenteopportuno limitare la memoria sulla scheda a quella strettamente necessarianecessaria
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 4747
RAILWAY EVOLUTION
Meccanismi di sicurezza realizzati dal Meccanismi di sicurezza realizzati dal softwaresoftware
Diagnostiche delle memorie read-only
Sono non distruttivenon distruttive,, avvengono prevalentemente ri-calcolando il checksum di ciascun blocco di memoria e confrontandolo con quello memorizzato al momento del caricamento
Richiedono funzioni di supporto da parte degli ambienti di sviluppo, che devono calcolare i checksum e inserirli nell’immagine di memoria da caricare. Questa azione può essere eseguita da tools non appartenenti all’ambiente di sviluppo che processano il file prodotto dal linker: introducono una ulteriore “incertezza” sulla generazione del software.
Occorrono convenzioni per localizzare i checksum nell’immagine di memoria del programma. Si può avere il checksum di un blocco dopo il blocco stesso, oppure un blocco dedicato a contenere i checksum etc.
Il caricamento delle memorie read-only deve essere eseguito in sicurezza : generalmente viene eseguito in parallelo sui due micro (caso 2oo2) che poi si votano i checksum ri-calcolati ed il risultato del confronto con quelli memorizzati
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 4848
RAILWAY EVOLUTION
Meccanismi di sicurezza realizzati dal Meccanismi di sicurezza realizzati dal softwaresoftware
Diagnostiche delle memorie read-write
Sono necessariamente distruttive, quindi occorre salvare la memoria prima di diagnosticarla e ripristinarla in seguitoSe il programma è concorrente, la diagnostica di un blocco di memoria va eseguita in mutua esclusione con i task che potrebbero utilizzarla. Occorre far eseguire la diagnostica al task più prioritario, oppure bloccare lo schedulatore, oppure disabilitare le interruzioniLe parti di RAM utilizzate dalle procedure di interruzione devono essere diagnosticate disabilitando le interruzioniOccorre considerare attentamente dove sono allocate le strutture dati utilizzate dalla diagnostica per esplorare la RAMLa durata totale della diagnostica della RAM è limitata dal massimo tempo di latenza tollerato per un guasto in base a considerazioni di sistemaIn alcuni casi sono supportate da particolari meccanismi Hardware, doppi banchi di memoria di cui uno in uso e uno in diagnosi. Occorrono funzionalità speciali per gestire lo scambio
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 4949
RAILWAY EVOLUTION
Meccanismi di sicurezza realizzati dal Meccanismi di sicurezza realizzati dal softwaresoftware
Diagnostiche della CPU
Hanno necessariamente una esaustività (ed una efficacia) limitataIn caso di guasto della CPU, generalmente intervengono altri meccanismi di sicurezzaLa diagnostica della CPU è costituita da una o più sequenze di istruzioni assembler che verificano, per quanto possibile, il buon funzionamento
Dell’utilizzo dei registriDell’utilizzo dei registriDei vari modi di indirizzamentoDei vari modi di indirizzamentoDelle operazioni matematiche e logicheDelle operazioni matematiche e logicheDelle istruzioni di salto condizionato e incondizionatoDelle istruzioni di salto condizionato e incondizionato
Occorre notare che in generale ad un guasto della CPU corrisponde la corruzione di più di un registro contemporaneamente, spesso in modo correlato
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 5050
RAILWAY EVOLUTION
Meccanismi di sicurezza realizzati dal Meccanismi di sicurezza realizzati dal softwaresoftware
Diagnostiche dell’hardware di I/OPer applicazioni in sicurezza, esistono versioni “speciali” di hardware convenzionali con funzionalità dedicate. Un esempio sono le schede di I/O che permettono la rilettura degli outpute/o la verifica degli input. In questo caso il SW può realizzare diagnostiche efficaciEsempio per la diagnostica dei circuiti di input
Porta di InputPorta di Input
Circuito per “forzare” Circuito per “forzare” un valore in inputun valore in input
Scheda di Input VitaleScheda di Input Vitale Scheda CPUScheda CPU
SwSw NominaleNominale
SwSw DiagnosticoDiagnosticoForza l’input al valore sicuroForza l’input al valore sicuroInputInput
Inibisce Inibisce acquisizioneacquisizione
Hardware di filtraggio Hardware di filtraggio e conversionee conversione
Verifica il valore dalla portaVerifica il valore dalla porta
Lo scopo è verificare di essere in grado di acquisire un input restrittivoLa diagnostica deve essere abbastanza rapida da non perturbare il funzionamento del software nominaleSe la diagnostica è eseguita da un task con priorità maggiore del task che esegue il software nominale, non è necessaria l’inibizione dell’acquisizione
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 5151
RAILWAY EVOLUTION
Scheda di Output VitaleScheda di Output Vitale
Meccanismi di sicurezza realizzati dal Meccanismi di sicurezza realizzati dal softwaresoftware
Diagnostiche dell’hardware di I/O
Esempio per la diagnostica dei circuiti di outputLo scopo è verificare di essere in grado di emettere un valore restrittivo
Porta di OutputPorta di Output
Circuito di riletturaCircuito di rilettura
Scheda CPUScheda CPU
SwSw NominaleNominale
SwSw DiagnosticoDiagnostico
Scrive nella porta il Scrive nella porta il valore sicurovalore sicuro
OutputOutput
Inibisce Inibisce outputoutput
Hardware di Hardware di condizionamento e condizionamento e
conversioneconversione
Verifica il valore in uscitaVerifica il valore in uscita
La diagnostica deve essere abbastanza rapida da non provocare effetti sul dispositivo comandatoSe la diagnostica è eseguita da un task con priorità maggiore del task che esegue il software nominale, non è necessaria l’inibizione dell’output
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 5252
RAILWAY EVOLUTION
Meccanismi di sicurezza realizzati dal Meccanismi di sicurezza realizzati dal softwaresoftware
Verifica delle deadline
Si applica a sistemi software concorrenti i cui processi sono progettati con attributi real-time precisamente definiti
period
deadline
offset
wcet
Disponendo di un timer indipendente da quello che genera il clock del sistema operativo, è possibile per ogni attivazione di un processo calcolare il tempo assoluto di scadenza della sua deadline e “prenotare” l’attivazione della diagnosticaSe il processo non fa in tempo a resettare il timer come ultima istruzione del suo codice, la diagnostica scatta
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 5353
RAILWAY EVOLUTION
Meccanismi di sicurezza realizzati dal Meccanismi di sicurezza realizzati dal softwaresoftware
α - count
Non tutti i guasti sono permanenti, esiste una vasta gamma di guasti e conseguenti malfunzionamenti transitori. Tipico il caso di un messaggio che si corrompe durante la trasmissione, malfunzionamento rilevato dal controllo del CRC.Se esiste una strategia di gestione che neutralizza il malfunzionamento corrente, per motivi di disponibilità si può evitare di portare il sistema nello stato sicuro.Si gestisce invece un contatore che viene incrementato ad ogni malfunzionamento e decrementato periodicamente (teoricamente in modo esponenziale) in assenzadi malfunzionamenti. Se il contatore raggiunge un valore prefissato, allora ci si porta nello stato sicuroα Valore limiteValore limite
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 5454
RAILWAY EVOLUTION
Meccanismi di sicurezza realizzati dal Meccanismi di sicurezza realizzati dal softwaresoftware
Protocolli di comunicazione in sicurezza
Nei sistemi in sicurezza complessi si fa largo uso di protocolli di comunicazioneI sottosistemi per svolgere le funzioni di primo livello del sistema devono collaborare e di conseguenza devono comunicare. Spesso la “spina dorsale” di un sistema è costituito da un BUS di comunicazione che connette tra loro i sottosistemi. Il BUS è solitamente ridondato per disponibilità o per sicurezza.Esistono svariati standards industriali, definiti per mezzo di livelli (layers) fisici e logici
MIL STD 1553 MIL STD 1553 (DOD)(DOD)PROFIBUS PROFIBUS (Siemens)(Siemens)CAN BUS CAN BUS ((BoschBosch))
Il livello fisico sul BUS è generalmente svolto da hardware dedicato presente su tutte le schede CPU. Gestisce il trasferimento di pacchetti di base e la politica di gestione del traffico sul BUS (es. token-ring).Uno o più livelli logici con caratteristiche di robustezza e integrità sono realizzati dal software
Messaggi a lunghezza fissa per rendere più efficace la rilevazioMessaggi a lunghezza fissa per rendere più efficace la rilevazione di perdite parziali di messaggine di perdite parziali di messaggiMessaggi numerati sequenzialmente per rilevare la perdita totaleMessaggi numerati sequenzialmente per rilevare la perdita totale di messaggidi messaggiGestione di CONNESSIONI realizzate da messaggi di controllo, la Gestione di CONNESSIONI realizzate da messaggi di controllo, la trasmissione di dati avviene trasmissione di dati avviene Meccanismi di CHECKSUM efficaciMeccanismi di CHECKSUM efficaci
Ai livelli logici definiti dal protocollo occorre generalmente aggiungere un livello di sicurezza (safety layer) che tiene conto della possibilità di guasti casuali dell’hardware di supporto
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 5555
RAILWAY EVOLUTION
Meccanismi di sicurezza realizzati dal Meccanismi di sicurezza realizzati dal softwaresoftware
Esempio di safety layer basato su PROFIBUSPROFIBUS è uno standard di comunicazione definito da SIEMENS
Un chip dedicato (Un chip dedicato (ASPC2ASPC2) per la gestione del livello fisico) per la gestione del livello fisicoUn set di messaggi di controllo per la gestione delle Un set di messaggi di controllo per la gestione delle CONNESSIONICONNESSIONIUn insieme di regole per attivazione, controllo, terminazione e Un insieme di regole per attivazione, controllo, terminazione e commutazione di connessioni commutazione di connessioni su un BUS su un BUS ridondatoridondato che collega un numero che collega un numero arbitrarioarbitrario di sottosistemidi sottosistemi
PROFIBUS è un protocollo connection oriented che prevede 3 tipi di messaggiMessaggi di CONTROLLO Messaggi di CONTROLLO (connect, accept, switchover, disconnect, …)(connect, accept, switchover, disconnect, …)
Messaggi di DATIMessaggi di DATIMessaggi LIFE Messaggi LIFE (inviati in mancanza di altre comunicazioni per un tempo predefi(inviati in mancanza di altre comunicazioni per un tempo predefinito)nito)
PROFIBUS prevede 1 collegamento Nominale ed un numero arbitrario di collegamenti di Riserva per disponibilità. Nell’esempio si considera una sola Riserva
Bus Nominale
Bus Riserva
Sottosistema 1 Sottosistema N
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 5656
RAILWAY EVOLUTION
Meccanismi di sicurezza realizzati dal Meccanismi di sicurezza realizzati dal softwaresoftware
Esempio di safety layer basato su PROFIBUS
CRCCA1A2DT
CRCCA1A2CM
Bus NominaleBus Nominale
Bus RiservaBus Riserva
Sottosistema che inizia Sottosistema che inizia la connessionela connessione
Sottosistema che Sottosistema che accetta la connessioneaccetta la connessione
Per comunicare occorre Per comunicare occorre stabilire una connessione stabilire una connessione
su su ciascunciascun BusBus
Ai messaggi del Ai messaggi del livello livello logicologico ( es Connect) ( es Connect)
corrispondono sequenze di corrispondono sequenze di scambi di messaggi del scambi di messaggi del
livello fisico livello fisico (CR, CC etc.)(CR, CC etc.)
Lo stato di ciascuna Lo stato di ciascuna connessione è definito da connessione è definito da
una FSM, lo stato una FSM, lo stato dell’insieme delle due dell’insieme delle due
connessione è definito da connessione è definito da una terza FSMuna terza FSM
I messaggi di I messaggi di datidatitransitano solo sulla transitano solo sulla
connessione Nominale, connessione Nominale, sulla connessione di sulla connessione di
Riserva transitano solo Riserva transitano solo messaggi LIFE (CM)messaggi LIFE (CM)
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 5757
RAILWAY EVOLUTION
Meccanismi di sicurezza realizzati dal Meccanismi di sicurezza realizzati dal softwaresoftware
Esempio di safety layer basato su PROFIBUS
Bus A
Bus B
SL A
SW applicativo
Sottosistema Y
SW applicativo
Sottosistema X
SL BSL A
CM CM
SL B
All’inizio non ci sono connessioniAll’inizio non ci sono connessioni
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 5858
RAILWAY EVOLUTION
Meccanismi di sicurezza realizzati dal Meccanismi di sicurezza realizzati dal softwaresoftware
Esempio di safety layer basato su PROFIBUS
Bus A
Bus B
SL A
SW applicativo
Sottosistema Y
SW applicativo
Sottosistema X
SL BSL A
CM CM
SL B
Il nodo X inizia la connessioneIl nodo X inizia la connessione
ConnectConnect
CRCR
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 5959
RAILWAY EVOLUTION
Meccanismi di sicurezza realizzati dal Meccanismi di sicurezza realizzati dal softwaresoftware
Esempio di safety layer basato su PROFIBUS
Bus A
Bus B
SL A
SW applicativo
Sottosistema Y
SW applicativo
Sottosistema X
SL BSL A
CM CM
SL B
Il nodo Y rispondeIl nodo Y rispondeCCCC
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 6060
RAILWAY EVOLUTION
Meccanismi di sicurezza realizzati dal Meccanismi di sicurezza realizzati dal softwaresoftware
Esempio di safety layer basato su PROFIBUS
Bus A
Bus B
SL A
SW applicativo
Sottosistema Y
SW applicativo
Sottosistema X
SL BSL A
CM CM
SL B
Continua l’esecuzione della Continua l’esecuzione della ConnectConnectA1A1
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 6161
RAILWAY EVOLUTION
Meccanismi di sicurezza realizzati dal Meccanismi di sicurezza realizzati dal softwaresoftware
Esempio di safety layer basato su PROFIBUS
Bus N
Bus B
SL A
SW applicativo
Sottosistema Y
SW applicativo
Sottosistema X
SL BSL A
CM CM
SL B
Ultimo Ultimo stepstep della connessionedella connessione A2A2
EndEndConnectionConnection
EndEndConnectionConnection
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 6262
RAILWAY EVOLUTION
Meccanismi di sicurezza realizzati dal Meccanismi di sicurezza realizzati dal softwaresoftware
Esempio di safety layer basato su PROFIBUS
Bus N
Bus B
SL A
SW applicativo
Sottosistema Y
SW applicativo
Sottosistema X
SL BSL A
CM CM
SL B
Le applicazioni possono comunicareLe applicazioni possono comunicare
DTDT
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 6363
RAILWAY EVOLUTION
Meccanismi di sicurezza realizzati dal Meccanismi di sicurezza realizzati dal softwaresoftware
Esempio di safety layer basato su PROFIBUS
Bus N
Bus B
SL A
SW applicativo
Sottosistema Y
SW applicativo
Sottosistema X
SL BSL A
CM CM
SL B
Inizia la connessione di RiservaInizia la connessione di Riserva
StartStartConnectionConnection
CRCR
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 6464
RAILWAY EVOLUTION
Meccanismi di sicurezza realizzati dal Meccanismi di sicurezza realizzati dal softwaresoftware
Esempio di safety layer basato su PROFIBUS
Bus N
Bus R
SL A
SW applicativo
Sottosistema Y
SW applicativo
Sottosistema X
SL BSL A
CM CM
SL B
Si stabilisce la connessione di RiservaSi stabilisce la connessione di Riserva
EndEndConnectionConnection
CC, A1, A2CC, A1, A2
EndEndConnectionConnection
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 6565
RAILWAY EVOLUTION
Meccanismi di sicurezza realizzati dal Meccanismi di sicurezza realizzati dal softwaresoftware
Esempio di safety layer basato su PROFIBUS
Bus N
Bus R
SL A
SW applicativo
Sottosistema Y
SW applicativo
Sottosistema X
SL BSL A
CM CM
SL B
CMCM
DTDT
Funzionamento nominale. In seguito possono aversi Funzionamento nominale. In seguito possono aversi disconnessionidisconnessioni, , switchswitch--overover etc.etc.
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 6666
RAILWAY EVOLUTION
Meccanismi di sicurezza realizzati dal Meccanismi di sicurezza realizzati dal softwaresoftware
Esempio di safety layer basato su PROFIBUS
System SWµA
Application SW
System SWµB
Application SW
IPC
PFa PFb
Il sistema non funziona ancora con un alto livello di integrità della sicurezza: non ha protezioni contro i guasti casuali. Per difendersi dai guasti casuali si ricorre alla tecnica della sicurezza composita
Ogni sottosistema è realizzato con architettura ridondata 2oo2Ogni sottosistema è realizzato con architettura ridondata 2oo2Esistono delle linee di comunicazione tra le due CPU per scambioEsistono delle linee di comunicazione tra le due CPU per scambio dati e votazionidati e votazioniI due micro sono sincronizzati (condividono un segnale HW)I due micro sono sincronizzati (condividono un segnale HW)In assenza di guasti, lo stato complessivo dei due micro coincidIn assenza di guasti, lo stato complessivo dei due micro coincide, incluso lo stato del protocolloe, incluso lo stato del protocollo
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 6767
RAILWAY EVOLUTION
Meccanismi di sicurezza realizzati dal Meccanismi di sicurezza realizzati dal softwaresoftware
Esempio di safety layer basato su PROFIBUS
SL ASL A SL BSL B
CMCM
SW ApplicativoSW Applicativo
Event HandlerEvent Handler
SL ASL A SL BSL B
CMCM
SW ApplicativoSW Applicativo
Event HandlerEvent Handler
Micro 1Micro 1 Micro 2 Micro 2
IPCIPC
Nominal
Reserve
Sottosistema X
SL ASL A SL BSL B
CMCM
SW ApplicativoSW Applicativo
Event HandlerEvent Handler
SL ASL A SL BSL B
CMCM
SW ApplicativoSW Applicativo
Event HandlerEvent Handler
Micro 1Micro 1 Micro 2Micro 2
IPCIPC
Sottosistema Y
Event handlerEvent handler localizza il Software che gestisce la ridondanza, il resto non localizza il Software che gestisce la ridondanza, il resto non cambiacambia
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5Anno Accademico 2004/5
La Certificazione del SoftwareLa Certificazione del Software 6868
RAILWAY EVOLUTION
Meccanismi di sicurezza realizzati dal Meccanismi di sicurezza realizzati dal softwaresoftware
Esempio di safety layer basato su PROFIBUS
SL ASL A SL BSL B
CMCM
SW ApplicativoSW Applicativo
Event HandlerEvent Handler
SL ASL A SL BSL B
CMCM
SW ApplicativoSW Applicativo
Event HandlerEvent Handler
Micro 1Micro 1 Micro 2 Micro 2
IPCIPC
Nominal
Reserve
Sottosistema X
SL ASL A SL BSL B
CMCM
SW ApplicativoSW Applicativo
Event HandlerEvent Handler
SL ASL A SL BSL B
CMCM
SW ApplicativoSW Applicativo
Event HandlerEvent Handler
Micro 1Micro 1 Micro 2Micro 2
IPCIPC
Sottosistema Y
I messaggi in arrivi sono duplicati e processati in doppia, poi I messaggi in arrivi sono duplicati e processati in doppia, poi si vota lo stato delle FSMsi vota lo stato delle FSM