certificazione software e cenelec nella pratica …tullio/cs/dispense_2005/20050301.pdf · cei en...

68
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2004/5 Anno Accademico 2004/5 La Certificazione del Software La Certificazione del Software 1 1 RAILWAY EVOLUTION Certificazione Software e Certificazione Software e CENELEC nella pratica aziendale CENELEC nella pratica aziendale Parte I – 1/2 Febbraio 2005 Presentazione relatore e azienda Presentazione relatore e azienda La Certificazione La Certificazione qualità, processo, prodotto qualità, processo, prodotto La Certificazione del Software La Certificazione del Software Misurare la Qualità del Software Misurare la Qualità del Software Processi di sviluppo per il Software Processi di sviluppo per il Software Software “certificabile” Software “certificabile” Parte II – 1/2 Marzo 2005 Ingegneria della Sicurezza Ingegneria della Sicurezza Sistemi in sicurezza Sistemi in sicurezza Il Software nel ciclo di vita di Sistema Il Software nel ciclo di vita di Sistema Il Software e la sicurezza Il Software e la sicurezza Meccanismi di sicurezza realizzati dal software Meccanismi di sicurezza realizzati dal software

Upload: phungnhi

Post on 23-Aug-2018

262 views

Category:

Documents


6 download

TRANSCRIPT

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