Tesi SantoRusso 885-517-Certificazione del software in ... · o UK British Standards Institute (BS)...

Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica tesi di laurea specialistica

Certificazione del software in ambito ferroviario: un caso di studio per un sistema a bordo treno Anno Accademico 2011/2012 relatore Ch.mo prof. Stefano Russo correlatori Ing. Roberto Pietrantuono Ing. Fernanda Buonanno AnsaldoBreda S.p.A. candidato Santo Russo matr. 885/000517

III

Indice

Indice delle figure .............................................................................................................................V Introduzione.......................................................................................................................................6

Capitolo 1 Introduzione alla certificazione software.........................................................................8

1.1 Certificazione .........................................................................................................................8 1.2 Processi ..................................................................................................................................9

1.2.1 Maturità del processo ....................................................................................................10 1.3 Standards..............................................................................................................................11

1.3.1 ISO 9000 .......................................................................................................................12 1.3.2 IEC 61508 .....................................................................................................................12 1.3.3 DO 178B .......................................................................................................................15

1.4 Certificazione in ambito ferroviario: EN 50128 ..................................................................15 1.4.1 Ruoli e struttura dell’organizzazione ............................................................................16 1.4.2 Tecniche prescritte dallo standard 50128......................................................................18 1.4.3 Software requirements specification phase...................................................................19 1.4.4 Software Architecture phase .........................................................................................21 1.4.5 Software Design and Implementation...........................................................................28 1.4.6 Verification and Testing................................................................................................32 1.4.7 Integration .....................................................................................................................36 1.4.8 Overall Software Testing ..............................................................................................36

Capitolo 2 Tecniche di structured methodology..............................................................................37

2.1. SSADM...............................................................................................................................37

2.1.1 Data Flow Diagrams (DFD)..........................................................................................38 2.1.2 Logical Data Modeling (LDM).....................................................................................42 2.1.3 Entity Behaviour Modeling (EBM) ..............................................................................43

2.2 JSD.......................................................................................................................................44 2.2.1 Entity Structure Diagrams (ESD) .................................................................................45 2.2.2 Network Diagrams (ND)...............................................................................................47

2.3 MASCOT.............................................................................................................................48 2.4 Yourdon (YSM) ...................................................................................................................51

2.4.1 Context Diagram...........................................................................................................52 2.4.2 Processo di controllo.....................................................................................................53 2.4.3 Process specifications ...................................................................................................54 2.4.4 Data Dictionary .............................................................................................................54

IV

Capitolo 3 Caso di studio: certificazione di un sistema a bordo treno ............................................56

3.1 Descrizione del caso di studio..............................................................................................56 3.1.1 Metropolitana leggera automatica.................................................................................56

3.2 Applicazione delle tecniche di structured methodology ......................................................58 3.2.1 Data dictionary nel caso di studio .................................................................................66

3.3 Integrazione delle structured methodology con concetti model-based................................71

Conclusioni ......................................................................................................................................73 Sviluppi futuri..................................................................................................................................75 Bibliografia ......................................................................................................................................76

V

Indice delle figure Figura 1 - Modello a V.......................................................................................................................10 Figura 2 - IEC 61508-1 Safety Lifecycle...........................................................................................14 Figura 3 - Legenda DFD ....................................................................................................................38 Figura 4 - Diagramma DFD...............................................................................................................39 Figura 5 - Process Box .......................................................................................................................39 Figura 6 - Entità esterna .....................................................................................................................40 Figura 7 - Data Stores ........................................................................................................................41 Figura 8 - DFD di livello inferiore.....................................................................................................42 Figura 9 - LDM..................................................................................................................................42 Figura 10 - Relazioni, cardinalità e ordinalità....................................................................................43 Figura 11 - Etichette C e R.................................................................................................................43 Figura 12 - ELH diagram...................................................................................................................44 Figura 13 - Struttura parallela ............................................................................................................44 Figura 14 - Esempio di ESD ..............................................................................................................45 Figura 15 - Costrutto sequenza .........................................................................................................45 Figura 16 - Costrutto di selezione ......................................................................................................46 Figura 17 - Costrutto di iterazione .....................................................................................................46 Figura 18 - ESD autovettura ..............................................................................................................46 Figura 19 - Esempio di JSD Network Diagram .................................................................................47 Figura 20 - Diagramma ACP .............................................................................................................48 Figura 21 - Simbolo del channel ........................................................................................................49 Figura 22 - Simbolo del pool .............................................................................................................49 Figura 23 - Simbolo della connection ................................................................................................50 Figura 24 - Simbolo per il device.......................................................................................................50 Figura 25 - Elementi basilari in Yourdon ..........................................................................................51 Figura 26 - Notazione YSM real-time ...............................................................................................52 Figura 27 - Context Diagram .............................................................................................................53 Figura 28 - State transition diagram...................................................................................................53 Figura 29 - Notazione Backus-Naur Form.........................................................................................55 Figura 30 - Piattaforma MLA ............................................................................................................57 Figura 31 - Context Diagram: gestore del telecomando ....................................................................59 Figura 32 - Dfd telecomando .............................................................................................................60 Figura 33 - LT 3 .................................................................................................................................61 Figura 34 - Speed Management 3.2 ...................................................................................................63 Figura 35 - TRaction Block 3.3 .........................................................................................................64 Figura 36 - Generazione comandi LT 3.4 ..........................................................................................65 Figura 37 - Odometro fsm..................................................................................................................71 Figura 38 - State transition diagram- odometro fsm..........................................................................72

Certificazione del software in ambito ferroviario: un caso di studio per un sistema a bordo treno.

6

Introduzione

Lo scopo del presente lavoro di tesi è fornire supporto al processo di sviluppo del software

realizzato da AnsaldoBreda S.p.A., al fine di attenersi alle direttive emanate dall’ente

CENELEC con la normativa EN 50128:2011 dal titolo “Applicazioni ferroviarie,

tranviarie, filoviarie e metropolitane – Sistemi di telecomunicazione, segnalamento ed

elaborazione - Software per sistemi ferroviari di comando e di protezione”.

La maggior parte dei sistemi informatici è costituita dai sistemi embedded, ovvero sistemi

integrati all’interno di beni comuni come forni a microonde o lavatrici, ma soprattutto in

sistemi più complessi e delicati come il sistema che sovrintende alla gestione della

frenatura di un treno oppure un sistema che controlla i motori di un aereoplano. Un guasto

in tali sistemi può arrecare danni alle persone, oltre a notevoli danni economici, e pertanto

tali sistemi vengono denominati safety-critical.

Un sistema safety-critical deve essere progettato avendo come obiettivo primario la

sicurezza. Per i sistemi hardware i principi di progettazione che mirano al raggiungimento

della safety sono già stati ben catalogati all’interno di standards. Per quanto riguarda

invece i principi per la progettazione di software safe, gli standard si stanno affermando

solo da pochi anni [1].

Un prodotto safety-critical può essere certificato da un’ autorità solo se:

o Il processo di sviluppo viene effettuato basandosi su un modello strutturato

(ad esempio il Capability Maturity Model, CMM)

o Ci sono degli standard che sono stati applicati sviluppando il prodotto.


7

Nel primo capitolo si illustrano gli standard internazionali utilizzati nei settori dell’

aviazione civile, dell’elettronica e standard generici non afferenti a nessun settore

industriale; successivamente viene definito il processo di certificazione e i suoi scopi;

viene descritto il processo software modello a V e il modello sulla maturità del processo

Capability Maturity Model.

Lo standard EN 50128 viene descritto nel dettaglio, ponendo enfasi sulle tecniche

prescritte per ciascuna fase del ciclo di vita del software.

Nel secondo capitolo si illustra una panoramica delle tecniche di structured methodology:

SSADM, JSD, MASCOT, Yourdon.

Nel terzo capitolo si mostra con un esempio dettagliato l’applicazione di una metodologia

strutturata (Yourdon) per realizzare la fase di design del software nel caso di studio; sono

riportati i diagrammi di contesto, i diagrammi di flusso, il data dictionary e gli state

transition diagrams realizzati.


8

Capitolo 1 Introduzione alla certificazione software

1.1 Certificazione La certificazione è il processo di emissione di un certificato che indica la conformità con

uno standard, un insieme di linee guida o un altro documento simile. In molti casi il

certificato viene rilasciato sotto forma di una licenza, da parte di un’ autority. Queste

autority sono nella maggior parte dei casi enti governativi, come ad esempio la U.S.

Federal Aviation Administration (FAA) che approva tutti i sistemi progettati per

aereoplani civili negli Stati Uniti d’ America.

Gli obiettivi della certificazione sono:

o Migliorare la safety dei sistemi safety-critical

o Incrementare la consapevolezza delle implicazioni che le performance del

sistema hanno sulla safety

o Applicare gli standard minimi di progettazione e manifattura all’interno

dell’azienda pertinente

o Favorire la creazione di una suddivisione precisa dei compiti e delle

resposabilità aziendali.

I certificati possono essere rilasciati per:

o La struttura di gestione appropriata nell’organizzazione

o I processi e le procedure usati per sviluppare i prodotti


9

o Gli standards

o Il prodotto finale

o Singoli individui come l’utente o l’operatore del sistema

o Gli esperti, che a loro volta possono rilasciare certificati

Il processo di certificazione può variare notevolmente fra industrie differenti e fra nazioni

differenti.

Per i sistemi safety-critical, il processo di certificazione comincia con la fase iniziale

di analisi dei requisiti. Solitamente, una persona denominata “certification liaison” agisce

come la figura di interfaccia fra l’organizzazione che realizza il sistema e l’autorità di

certificazione. È compito del liaison assicurarsi, laddove degli standards specifici sono

obbligatori, che essi verranno incorporati e documentati già nei primissimi stadi del

progetto. Un verification plan sarà prodotto dall’azienda per essere poi approvato

dall’autorità di certificazione.

Durante le varie fasi del progetto saranno prodotti una documentazione appropriata e dei

dati a supporto e verranno sottoposti all’autorità. Generalmente, viene effettuata una serie

di revisioni periodiche e se tutti gli obiettivi del verification plan sono soddisfatti, verrà

rilasciato il certificato.

1.2 Processi Un processo in Ingegneria del Software è un framework per lo sviluppo di un prodotto

software. Un possible modello di processo è il modello a V mostrato nella figura 1.

Il modello descrive lo sviluppo di un sistema, partendo dalla fase iniziale di analisi dei

requisiti e di specifica, seguite dalla fase di design, di implementazione del software, dalla

fase di testing, di certificazione del prodotto e infine dalla fase di esercizio. Per poter

raggiungere un’ elevata qualità e per poter realizzare un prodotto che sia verificabile e

certificabile sono necessarie frequenti iterazioni fra le suddette fasi di sviluppo.


10

Figura 1 - Modello a V

1.2.1 Maturità del processo

Il Capability Maturity Model fu sviluppato nel 1990 dal “Software Engineering Institute”

ed è specificamente indirizzato alla maturità del processo software. Il CMM descrive

cinque livelli distinti di maturità:

o Livello 1 (Initial): rappresenta la maturità di un processo caratterizzato da

risultati non predicibili. Solo pochi processi sono definiti e il successo del

progetto dipende totalmente dallo sforzo individuale [2].

o Livello 2 (managed): rappresenta la maturità di un processo caratterizzato

da performance del progetto che sono ripetibili. Vengono stabiliti processi

di gestione del processo basilari per poter tener traccia dei costi, della

pianificazione e delle funzionalità. A questo livello il processo è

necessariamente disciplinato affinchè i successi precedenti possano essere

ripetuti su progetti che hanno applicazioni similari.

o Livello 3 (defined): rappresenta la maturità di un processo caratterizzato

dal miglioramento delle performance del progetto all’interno


11

dell’organizzazione. Il processo software, sia per le attività di gestione che

per quelle di ingegnerizzazione, è documentato, standardizzato e integrato

all’interno di un processo software standard per l’organizzazione. Tutti i

progetti utilizzano una versione a misura e approvata del processo software

standard dell’organizzazione per sviluppare e manutenere il software.

o Livello 4 (quantitatevely managed): rappresenta la maturità di un processo

caratterizzato dal miglioramento della performance organizzativa. Sono

raccolte misure dettagliate del processo software e della qualità del

prodotto. Sia il processo software che i prodotti sono controllati e capiti

quantitativamente.

o Livello 5 (optimized): rappresenta la maturità di un processo caratterizzato

da una performance organizzativa rapidamente riconfigurabile; il

miglioramento continuo e quantitativo del processo è perseguito tramite

l’applicazione sistematica delle attività di raccolta dei feedback di

processo, l’analisi dei difetti e delle cause che li hanno generati,

l’introduzione di idee e tecnologie innovative.

1.3 Standards Gli standards sono richiesti per legge o per contratto durante lo sviluppo e la certificazione

dei sistemi safety-critical. Nell’Unione Europea, l’ente “European Committee for

Electrotechnical Standardisation” (CENELEC) ha adottato molti standards come Norme

Europee (EN). Gli enti che rilasciano gli standards sono - tra gli altri - :

o International Organisation for Standardization (ISO)

o International Electrotechnical Commission (IEC)

o Institute of Electrical and Electronics Engineers (IEEE)

o European Committee for Electrotechnical Standardisation (CENELEC)

o UK British Standards Institute (BS)

Gli standards possono essere generici, come ISO 9000 e IEC 61508, oppure specifici per

una particolare industria come EN 50128 per il settore ferroviario oppure DO 178B per


12

l’aviazione civile.

1.3.1 ISO 9000

L’International Standardization Organization ha rilasciato la serie degli standards ISO

9000 che trattano la gestione e la garanzia della qualità in generale. ISO 9000 richiede

all’organizzazione di: “dire cosa realizza, realizzare effettivamente quello che dice ed

essere pronta a dimostrarlo”. I tre standards principali sono ISO 9001, ISO 9002, ISO

9003. ISO 9001 si focalizza sulla conformità del prodotto agli standards internazionali

attraverso il ciclo di vita del prodotto. Molta importanza è data agli elementi di design e ai

fattori relativi alla performance. Questo standard è quello più rigoroso della serie 9000.

ISO 9002 non include un componente relativo al design o alla R&D. Si focalizza

sulla produzione, installazione e fase di servizio dei prodotti.

ISO 9003 ricopre la fase di ispezione del prodotto e il testing dei componenti realizzati.

Per lo sviluppo del software è importante la ISO 9000-3 “Guida all’applicazione di ISO

9001 allo sviluppo e manutenzione del software”. Lo standard è stato rilasciato nel 1991 e

una seconda edizione è stata rilasciata nel 1997. Tre aree principali sono ricoperte:

o Struttura della qualità: gestione delle responsabilità, il sistema di qualità,

verifiche della qualità, azioni correttive da intraprendere.

o Attività del ciclo di vita (attività che sono richieste durante le varie fasi

del ciclo di vita), come: revisione del contratto, requisiti, planning dello

sviluppo, planning della qualità, progettazione e implementazione, testing

e validazione, accettazione, riproduzione, consegna e installazione.

o Attività di supporto(attività che non sono relazionate a fasi specifiche del

ciclo di vita), come: gestione della configurazione, controllo dei

documenti, misurazione, supporto ai tools, acquisti, formazione.

1.3.2 IEC 61508

IEC 61508 è uno standard sviluppato dall’Intenational Electrotechnical Commission, un’

organizzazione mondiale composta da omologhi enti nazionali IEC in più di 60 Nazioni


13

nel mondo. IEC prepara e pubblica standards internazionali per tutte le tecnologie

elettriche ed elettroniche. Questi standards sono poi utilizzati come base per una

standardizzazione nazionale e come riferimento per abbozzare i contratti internazionali.

IEC 61508, dal titolo “Functional safety of electrical/electronic/programmable electronic

safety-related (E/E/PE) systems”, è uno standard generico e consiste di sette parti:

o IEC 61508-1: Requisiti generali

o IEC 61508-2: Requisiti per i sistemi safety-critical elettrici/ elettronici/

elettronici programmabili

o IEC 61508-3: Requisiti software

o IEC 61508-4: Definizioni ed abbreviazioni

o IEC 61508-5: Esempi di metodi per la determinazione dei safety integrity

levels

o IEC 61508-6: Lineeguida per l’applicazione di IEC 61508-2 e IEC 61508-

3

o IEC 61508-7: Panoramica delle tecniche e delle misure

Lo standard IEC 61508 mira a:

o Diffondere il potenziale della tecnologia E/E/PE per migliorare sia la

safety che le performance economiche.

o Permettere che avvengano sviluppi tecnologici all’interno di un safety

framework globale.

o Fornire un approccio valido tecnicamente, basato su un sistema, con una

sufficiente flessibilità per il futuro.

o Fornire un approccio basato sui rischi per determinare le performance

richieste dei sistemi safety-critical.

o Fornire uno standard generico che possa essere usato direttamente

dall’industria ma che possa anche aiutare lo sviluppo degli standards nei

vari settori(es. Impianti chimici, medici) o standards di prodotto (es. Drive-

by-wire)

o Fornire uno strumento per gli utenti e i regolatori per guadagnare


14

confidenza quando utilizzano le tecnologie computer-based.

o Fornire i requisiti basati su principi comuni per permettere un

miglioramento nella comunicazione dei requisiti (ad es. Incrementare la

chiarezza di cosa è necessario da specificare)

Di seguito è riportata un’ illustrazione del ciclo di vita atto a garantire la safety, secondo lo

standard 61508:

Figura 2 - IEC 61508-1 Safety Lifecycle

Nella fase 3 “Hazard and risk analysis” l’obiettivo è quello di determinare i pericoli

dell’EUC(Equipment Under Control) che è in operazione, incluso un uso improprio del

sistema. Nella fase 5 “Safety requirements allocation” viene effettuata l’allocazione delle

funzioni di safety al sistema E/E/PE, inclusi i safety integrity levels. Nella fase 13

“Overall safety validation” l’obiettivo è validare che il sistema E/E/PE soddisfi la

specifica dei requisiti globali di safety. Nella fase 16 “Decommisioning” l’obiettivo è di

assicurare che l’aspetto funzionale della safety del sistema sia garantito durante lo

smantellamento o lo smaltimento del prodotto.

Lo standard IEC 61508 non prevede le precauzioni che potrebbero essere necessarie


15

per prevenire che persone non autorizzate danneggino oppure influenzino in maniera

negativa la safety funzionale dei sistemi E/E/PE safety-critical.

1.3.3 DO 178B

DO 178B è ufficialmente un documento-guida che è stato ampiamente accettato come uno

standard internazionale per l’aviazione civile. Fu rilasciato la prima volta negli anni ’80.

L’ultima revisione è stata fatta nel 1992; è compatibile con lo standard ED-12B rilasciato

dall’European Organization for Civil Aviation Electronics (EUROCAE).

L’intento di DO-178B è di descrivere gli obiettivi dei processi del ciclo di vita del

software, descrivere le attività del processo e descrivere la dimostrazione della conformità

allo standard richiesta ai differenti livelli software. I livelli software sono scelti

determinando la gravità delle conseguenze di un guasto sull’aereo e sui suoi passeggeri.

1.4 Certificazione in ambito ferroviario: EN 50128

Lo standard europeo EN 50128 fa parte di un gruppo di standards fra loro correlati. Gli

altri standards sono: EN 50126:1999 “Railway applications – The specification and

demonstration of Reliability, Availability, Maintainability and Safety (RAMS) – Part 1:

Basic requirements and generic process” e lo standard EN 50129:2003 “Railway

applications – Communication, signalling and processing systems – Safety related

electronic systems for signalling”.

Lo standard 50128 fornisce un insieme di requisiti che le fasi di sviluppo,

dispiegamento e manutenzione del software safety-critical (sviluppato per applicazioni

ferroviarie di comando e protezione) devono soddisfare[3]. Questi requisiti inoltre

comprendono anche indicazioni sulla struttura dell’organizzazione, la relazione fra le

organizzazioni e la suddivisione delle responsabilità dei team impegnati nelle fasi di

sviluppo, dispiegamento e manutenzione. Il concetto chiave di questo standard è quello dei

livelli di software safety integrity (SwSIL). Si definiscono cinque livelli di software safety

integrity, dove zero è il livello più basso e quattro è il livello più alto; maggiore è il rischio


16

che risulta da un malfunzionamento software, maggiore sarà il livello di software safety

integrity. Lo standard prescrive le tecniche che devono essere adottate per ciascuno dei

cinque livelli di safety.

1.4.1 Ruoli e struttura dell’organizzazione

Si descrivono i vari attori del processo di certificazione identificati dalla norma 50128:

o Assessor: l’ente che ha il compito di realizzare l’assessment, ovvero il

processo di analisi per determinare se il software realizzato è

effettivamente conforme con i requisiti specificati dallo standard.

o Configuration manager: entità che è responsabile di controllare e gestire le

attività (sia documentali sia implementative) che portano alla produzione

di software. L’attività di configuration management si appoggia sempre su

un data base (base di dati) dove sono memorizzati gli oggetti sottoposti a

controllo di configurazione (i configuration items). La gestione è di tipo

formale, cioè nel processo vengono osservate delle procedure definite in

precedenza, tramite opportuni moduli di gestione.

o Designer: responsabile di analizzare e trasformare i requisiti specificati in

soluzioni progettuali accettabili che abbiano il safety integrity level (SIL)

richiesto.

o Implementer: colui che trasforma le specifiche di design nella loro

realizzazione fisica.

o Integrator: entità che realizza l’integrazione del software.

o Project Manager: entità che conduce la parte amministrativa e tecnica di un

progetto, inclusi gli aspetti legati alla safety.

o Requirements Manager: entità che gestisce la documentazione, l’analisi e

la priorità dei requisiti e di controllare le modifiche effettuate ai

responsabili.

o Tester: l’entità che realizza e pianifica i test.

o Verifier: entità responsabile del processo di esamina, seguito da un


17

giudizio basato sulla dimostrazione che gli elementi prodotti in una

specifica fase dello sviluppo soddisfino i requisiti di quella fase,

rispettando completezza, correttezza e consistenza.

o Validator: entità responsabile del processo di analisi, seguito da un

giudizio basato sulla dimostrazione che un elemento prodotto rispetti le

esigenze dell’utente, in particolar modo riguardo la safety e la qualità e

ponendo enfasi sull’idoneità delle sue operazioni, in conformità al suo

scopo.

Lo standard 50128 prevede che per lo sviluppo di un progetto software SIL 0, l’assessor

sia in un’ organizzazione differente da quella che sviluppa il software; il requirements

manager, il designer e l’implementer possono essere la stessa persona, che dovrebbe

informare il project manager del proprio lavoro; l’integrator, il tester, il verifier e il

validator possono essere la stessa persona, la quale può informare il project manager. Il

project manager ha un’ unico compito. Queste tre entità possono essere nella stessa

azienda che deve essere separata da quella dell’assessor.

Per lo sviluppo di un progetto software SIL 1 o SIL 2, prevede che l’assessor sia in

un’ organizzazione differente da quella che sviluppa il software; il requirements manager,

il designer e l’implementer possono essere la stessa persona, che dovrebbe informare il

project manager; l’integrator e il tester possono essere la stessa persona, che può informare

il project manager; il verifier e il validator possono essere la stessa persona che può

informare il project manager; Il project manager ha un’ unico compito. Queste quattro

entità possono essere nella stessa azienda che deve essere separata da quella dell’assessor.

Per lo sviluppo di un progetto software SIL 3 o SIL 4, l’assessor sia in un’

organizzazione differente da quella che sviluppa il software; il requirements manager, il

designer e l’implementer possono essere la stessa persona, che dovrebbe informare il

project manager; l’integrator e il tester possono essere la stessa persona, che può informare

il project manager; il verifier è separato dal validator, che può informare il project

manager; il validator prende le decisioni in maniera indipendente dal project manager; il


18

project manager ha un’ unico compito. Queste cinque entità possono essere nella stessa

azienda che deve essere separata da quella dell’assessor.

1.4.2 Tecniche prescritte dallo standard 50128

Lo standard 50128 identifica delle fasi principali nel ciclo di vita dello sviluppo del

software: specifica dei requisiti software, architettura del software, progettazione e

implementazione del software, verifica e testing, integrazione, testing globale del

software. Per ciascuna di queste fasi lo standard prescrive un insieme di tecniche e di

misure da adottare o non adottare a seconda del Software Integrity Level. L’utilizzo di una

tecnica e/o di una misura può essere:

o Obbligatorio: la tecnica deve essere per forza utilizzata per quel

determinato SIL.

o Altamente raccomandato: l’utilizzo è altamente raccomandato; se la

tecnica non viene usata, bisogna adeguatamente motivare le ragioni che

hanno indotto ad utilizzare un insieme di tecniche alternative ad essa,

dettagliandole nel documento Software Quality Assurance Plan o in un

altro documento che da esso è referenziato.

o Raccomandato: questo è un livello di raccomandazione minore rispetto al

precedente; le tecniche raccomandate spesso possono essere combinate per

formare un insieme di tecniche da utilizzare.

o Nessuna prescrizione: non c’è nessuna indicazione nè sull’utilizzo nè sul

mancato utilizzo della tecnica/misura.

o Non raccomandato: è bene non utilizzare questa tecnica/misura per quel

determinato SIL. Laddove invece la si voglia comunque utilizzare,

bisogna adeguatamente motivare le ragioni che hanno indotto ad

utilizzarla, dettagliandole nel documento Software Quality Assurance Plan

o in un altro documento che da esso referenziato.

Inoltre per alcune fasi, ci può essere già un insieme di tecniche il cui utilizzo è approvato


19

per un determinato Software Integrity Level.

1.4.3 Software requirements specification phase

Si elencano e illustrano le tecniche prescritte dallo standard 50128 per la fase di specifica

dei requisiti software (si veda come riferimento la Table A.2 – Software Requirements

Specification (7.2) dello standard ). Lo standard prescrive, per la fase di specifica dei

requisiti, l’utilizzo di almeno una delle quattro tecniche di seguito descritte.

Modelling – A.17

La tecnica del modelling prevede la modellazione dei requisiti software tramite l’utilizzo

di: diagrammi del flusso dei dati, diagrammi sul flusso di controllo, macchine a stati finiti

o diagrammi di transizione degli stati, reti di Petri, metodi formali, modellazione della

performance, prototipazione, structure diagrams o UML sequence diagrams.

Per il modelling lo standard prescrive di utilizzare e definire una linea guida; inoltre

specifica che almeno una delle tecniche altamente raccomandate deve essere adottata. Per

SIL 0 non ci sono tecniche altamente raccomandate; per SIL 2 le macchine a stati finiti

(FSM), i diagrammi di transizione degli stati e i sequence diagrams sono altamente

raccomandati.

Per le macchine a stati finiti lo standard indica di specificare se e come viene controllata la

completeness, la consistency e la reachability della stessa; inoltre di specificare se si

utilizzano layered FSM (ossia quando il sistema è complicato si utilizza una FSM generale

da cui si derivano FSM con un maggiore livello di dettaglio).

Structured Methodologies – D.52

Lo standard prescrive l’utilizzo di metodologie strutturate predefinite, ad esempio,

SSADM, Yourdon, JSD, MASCOT, ecc.; queste metodologie sono analizzate

dettagliatamente nel capitolo 2. I metodi strutturati sono essenzialmente un approccio per

poter suddividere in maniera sistematica un problema o un sistema. Gli aspetti principali

di queste metodologie sono:


20

o Identificazione del sistema globale, incluso l’ambiente in cui esso opera

o Decomposizione fra dati e funzioni nel sistema in esame

o Definizione delle checklists, ovvero una lista di cose da fare che

richiedono una specifica

o Un modo logico di pensare, suddividendo un problema esteso in problemi

più piccoli, di complessità gestibile.

Le notazioni utilizzate tendono ad essere precise nell’identificare il problema e le entità

conivolte nel sistema (ad esempio, processi e flussi di dati), ma le funzioni eseguite da

queste entità vengono espresse usando una notazione informale. Alcuni metodi fanno uso

di una notazione formale; questa precisione ha il vantaggio di ridurre eventuali

incomprensioni e fornisce un aiuto per un processing automatico. Un altro beneficio della

notazione strutturata è la sua visibilità, che permette a un utente di poter controllare in

maniera intuitiva un progetto o una specifica.

Decision Tables – D.13

Le truth tables o decision tables sono usate per descrivere relazioni logiche complesse tra

insiemi di variabili booleane, funzioni booleane; quindi anche come specifica dei requisiti,

o supporto alla specifica dei requisiti. La natura tabulare e coincisa di questi due metodi li

rende appropriati come mezzi per analizzare le combinazioni logiche complesse che sono

espresse nel codice.

Formal Methods.

Si tratta di tecniche rigorose, dal punto di vista matematico, per la fase di specifica dei

requisiti, ad esempio per specificare requisiti come relazioni matematiche, con algebre, o

come pre/post condizioni su variabili di ingresso/uscita . Es.: CSP, CCS, HOL, LOTOS,

OBJ, Temporal Logic, VDM, Z Method, B Method and Model Checking. Per alcune

funzioni critiche si potrebbe ipotizzare l’utilizzo di alcune di queste tecniche; in

particolare, una funzione critica può essere espressa con relazioni logico/matematiche tra


21

ingressi-uscite, oppure tramite l’utilizzo di logiche (temporali) del primo ordine. In quest’

ultimo caso se si utilizzano le macchine a stati per specificare un comportamento, il model

checking consiste nel verificare che tale macchina a stati viola (o non viola) una

determinata proprietà (ad esempio non si entra mai in un certo stato) espressa in logica

temporale. Bisogna definire le proprietà da verificare (ma è bene farlo solo per proprietà

base, come assenza di deadlock, terminating code). Questa tecnica è poco usata nella

pratica attualmente a causa dell’enorme complessità dei sistemi reali, e viene limitata solo

ai componenti più critici del sistema.

1.4.4 Software Architecture phase

Si elencano e illustrano le tecniche prescritte dallo standard 50128 per la fase di

architettura del software (si veda come riferimento la Tabella A.3 – Software Architecture

(7.3) dello standard ). Per questa fase lo standard propone un insieme di tecniche già

approvato per SIL 1 e 2, che comprende Defensive Programming, Fully defined interface e

Structured Methodology, inoltre una a scelta tra: Fault Detection & diagnosis, Error

detecting codes, Failure assertion programming, Diverse programming, Memorising

executed cases, Software error effect analysis oppure Modelling.

Modelling – A.17

Già descritta nel paragrafo precedente.



Defensive Programming – D.14

Lo scopo di questa tecnica è quello di produrre programmi che rilevino un flusso di

controllo, un flusso dei dati o un valore di un dato anomalo durante la propria esecuzione e

reagiscano a ciò in maniera accettabile e predeterminata. Questa tecnica è per la maggior

parte afferente alla programmazione, ma un punto nello standard che lega questa tecnica al


22

design è il seguente: “the software should check its configuration. This could include both

the existence and accessibility of expected hardware and also that the software itself is

complete. This is particularly important for maintaining integrity after maintenance

procedures”. In fase di programmazione, prescrive di usare tecniche tra cui:

o Controllare il range di valori che assumono le variabili.

o Se possibile, controllare la plausibilità dei valori.

o All’inizio della procedura(funzione in C) controllare la dimensione, il tipo

e il range dei parametri che vengono passati alla procedura.

o Separazione fra parametri read-only e quelli read-write; controllo sugli

accessi.

o Controllo della plausibilità delle variabili che hanno un significato fisico.

o Codice per la gestione degli errori (che si potrebbe poi testare con test di

robustezza, anche in quel caso con non molto sforzo aggiuntivo)

o Controllo della plausibilità dei puntatori rispetto ai limiti delle memorie

Fault Detection & Diagnosis – D.26

La fault detection è il processo di controllo che il sistema si trovi o meno in uno stato

erroneo. Lo scopo principale di questa tecnica è di inibire gli effeti di risultati inesatti.

Essa è basata sui principi della ridondanza (principalmente per individuare faults di tipo

hardware) e diversità (per individuare faults di tipo software). Un processo di voting è

richiesto per decidere a riguardo della correttezza dei risultati. Altre metodologie speciali

applicabili sono l’assertion programming, N-version programming e la safety bag

technique mentre a livello hardware con l’introduzione di sensori, cicli di controllo, codici

per la correzione degli errori.

La fault detection può essere realizzata attraverso controlli sul dominio dei valori e sul

dominio del tempo a livelli differenti, specialmente al livello fisico (temperatura,

voltaggio), livello logico(error detecting codes ), livello funzionale (con le asserzioni) o a

un livello esterno (con i controlli di plausibilità). I risultati di questi controlli possono

essere memorizzati e associati con i dati coinvolti per permettere una tracciature dei


23

failures.

Siccome i sistemi complessi sono composti da tanti sottosistemi, l’efficienza della fault

detection, della diagnosi e della compensazione dei fault dipende dalla complessità delle

interazioni fra i sottosistemi, che influenza molto la propagazione dei faults.

L’identificazione dell’unità guasta dipende da quanto ogni componente è accoppiato agli

altri: se c’è poca interazione, è più semplice dimostrare che gli errori non si propagano, e

quindi dire con una maggiore confidenza che il componente guasto è quello dove si è

rilevato l’errore. Per cui rientra in questo anche il disaccoppiamento spaziale e il

partitioning.

Error correcting Codes – D.19

Vengono utilizzati codici di hamming, polinomiali, hash, ciclici percorreggere errori.

Error detecting Codes – D.19

Vengono utilizzati Codici di hamming, polinomiali, hash, ciclici per rilevare errori. Gli

error detecting codes devono essere utilizzati in accordo con i requisiti dello standard EN

50159 “Applicazioni ferroviarie, tranviarie, filoviarie e metropolitane - Sistemi di

telecomunicazione, segnalamento ed elaborazione - Parte 1: Comunicazioni di sicurezza in

sistemi di trasmissione di tipo chiuso”

Failure Assertion Programming– D.24

Una sequenza di istruzioni è preceduta e seguita da un assert su una pre-condizione e post-

condizione; se entrambe non vengono rispettate viene segnalato un errore. Esempio: i

contatori up-down; per eseguire una sequenza di statement un numero N di volte si

utilizzano due contatori, uno inizializzato a zero, l’altro a N; ad ogni iterazione si

decrementa un contatore e si incrementa l’altro; prima e dopo ogni iterazione vale la

condizione che la somma dei contatori deve essere uguale a N.

E’ comunque inverosimile che venga usata su ogni istruzione, quindi va definito un

criterio, che potrebbe essere “il codice più critico”.


24

Safety Bag Techniques – D.47

Computer esterno che monitora il computer principale, assicurandosi che non entri in uno

stato non sicuro. Il safety bag ha l’unico compito di assicurare che il computer principale

esegua solo azioni sicure, ma non necessariamente corrette.

Diverse Programming – D.16

Una specifica viene implementata a livello software, N volte in maniera differente. Gli

stessi valori di input sono dati alle N versioni, e i risultati prodotti dalle N versioni sono

confrontati. Se il risultato dell’elaborazione è considerato valido, il risultato è trasmesso ai

computer in output. Le N versioni possono essere eseguite in parallelo su computers

separati, alternativamente tutte le versioni possono essere eseguite sullo stesso computer e

i risultati soggetti a un voto interno. Diverse strategie di voting possono essere usate sulle

N versioni a seconda dei requisiti dell’applicazione.

Se il sistema ha uno stato sicuro, allora è possibile richiedere un accordo completo su tutte

le versioni altrimenti verrà usato un valore di uscita fail-safe.

Per i sistemi che non hanno uno stato safe, possono essere usate strategie di votazione in

cui vince la maggioranza. Per i casi in cui non c’è un accordo collettivo, possono essere

utilizzati approcci probabilistici per massimizzare le possibilità di selezionare un valore

corretto, ad esempio, prendendo il valore medio.

Recovery Block – D.44

Una funzione viene scritta con diverse alternative, in maniera indipendente. Se la prima

alternativa passa il test di accettazione i risultati sono inoltrati alle parti seguenti del

sistema. Altrimenti viene eseguita la seconda alternativa che a sua volta è seguita da un

test di accettazione ed è trattata come nel primo caso. A seconda dell’applicazione può

essere fornita una terza, quarta (o ancora di più) alternativa.

Backward Recovery – D.5


25

Se viene rilevato un fault, il sistema è resettato ad uno stato interno precedente, la

consistenza del quale è stata dimostrata precedentemente. Questo metodo implica un

freuqente salvataggio dello stato interno a determinati checkpoints. Questo può essere

fatto globalmente (per l’intero database) o in maniera incrementale (solo le modifiche tra i

checkpoints).

La tecnica è non raccomandata dallo standard per i livelli da SIL 1 a SIL 4.

Forward Recovery – D.30

Se viene rilevato un fault, lo stato corrente del sistema è manipolato per ottenere uno stato

che sarà consistente successivamente. Questo concetto è particolarmente adatto ai sistemi

real time con database piccoli e un tasso di cambiamento veloce dello stato interno.

La tecnica è non raccomandata dallo standard per i livelli da SIL 1 a SIL 4.

Retry Fault Recovery Mechanisms – D.46

Se viene rilevato un guasto, si tenta di recuperare la situazione tramite la riesecuzione

dello stesso codice. Può essere effettuato un re-boot o semplicemente o un re-scheduling

del task. Funzione per i cosiddetti bug “transienti”, ossia per bug il cui comportamento

dipende da condizioni di attivazione apparentemente non-deterministiche (ad esempio

l’attivazione di un bug dipende dallo scheduling del sistema operativo, per cui ripetendo la

stessa operazione potrebbe non manifestarsi). Le retry vengono implementate allo scadere

di un timeout solitamente.

Memorising Executed Cases – D.36

Durante la fase di licensing vengono memorizzati i dettagli dell’esecuzione del

programma. Nella fase di esercizio ogni esecuzione del programma viene paragonata con

quelle memorizzate; se differisce, deve essere eseguita un’ azione che riporti il sistema in

uno stato safe.

Artificial Intelligence Fault Correction – D.1


26

Vengono utilizzati sistemi come reti bayesiane, reti neurali, etc. per la correzione e la

predizione degli errori.

Non raccommandata dallo standard per i livelli da SIL 1 a SIL 4.

Dynamic Reconfiguration of software – D.17

L’obiettivo di questa tecnica è di mantenere le funzionalità del sistema nonostante

avvenga un fault. L’architettura logica del sistema deve essere tale che possa essere

mappata in un sottoinsieme delle risorse disponibili del sistema. L’architettura deve essere

capace di rilevare un failure in una risorsa fisica e dopo rimappare l’architettura logica

sulle risorse limitate che ancora sono funzionanti. Sebbene il concetto sia tradizionalmente

applicato al recupero da unità hardware guaste, può essere applicato ad unità software, se

c’è una sufficiente ridondanza a tempo di esecuzione per permettere una retry software

oppure se ci sono dati ridondati per isolare il failure. La tecnica è non raccommandata

dallo standard per SIL 2.

Software Error Effect Analysis – D.25

L’analisi consta di tre fasi. Nella prima fase si effettua una identificazione dei componenti

software vitali e si determina quanto sarà profonda(a livello di istruzione, gruppo di

istruzioni) l’analisi necessaria per ogni componente software.

Nella seconda fase si costruisce una tabella in cui si elencano i componenti, gli errori

probabili, le loro conseguenze, la criticità degli errori, una proposta di metodi per rilevare

gli errori. In questo caso errori software.

Infine nell’ultima fase, di sintesi, si identificano gli scenari rimanenti non sicuri e lo sforzo

per la validazione richiesto conoscendo la criticità di ogni modulo.

Graceful Degradation – D.31

Questa tecnica assegna priorità alle varie funzioni che devono essere realizzate dal

sistema. Il progetto così deve assicurare che se ci fossero risorse insufficienti per

realizzare tutte le funzioni del sistema, allora le funzioni con priorità maggiore devono


27

essere eseguite a discapito di quelle con priorità minore. Ad esempio se l’hw che gestisce

il logging degli errori dovesse fallire, le funzioni di controllo del sistema (a maggiore

priorità) devono continuare a funzionare nonostante questo malfunzionamento.

Information Hiding e Information Encapsulation – D.33

Strutture dati fondamentali incapsulate e nascoste, e che possono essere modificate solo

tramite procedure di accesso.

Con i linguaggi come Java o C, raccomandati dallo standard, questo principio si può

applicare, anzi per certi versi è intrinseco; l’utilizzo di prototipi definiti in header files, con

implementazioni separate è un esempio di separazione tra interfaccia e implementazione

tramite cui si può realizzare l’information hiding. L’accesso alle informazioni è reso

possibile da un insieme di operazioni descritte dall’interfaccia (tipicamente negli header

file), e in cui pur cambiando l’implementazione l’interfaccia non cambia.

Fully Defined Interface – D.38

Al paragrafo 7.3.4.19 dello standard si suggerisce che la descrizione delle interfacce

dovrebbe includere: pre/post-condizioni; definizione e descrizione di tutti i valori limite

(boundary) per tutti i dati specificati; comportamento dell’interfaccia quando si supera il

valore limite; comportamento dell’interfaccia quando si raggiunge il valore limite;

esistenza di meccanismi di sincronizzazione fra le funzioni nel caso in cui si manipolano

dati time-critical. Da un lato è certo che questa fase richiede la definizione dell’interfaccia

tra i componenti software e i “confini” del sistema (“A Software Interface Specification for

all Interfaces between the components of the software and the boundary of the overall

software shall be written”), che non sembra includere l’interfaccia tra i singoli

componenti; tuttavia, vedo questa separazione difficile, e poi comunque nella fase

successiva è richiesto “modular approach” che prevede “all module/component interfaces

shall be fully documented”. Fully documented non vuol dire fully defined, però

l’interpretazione dell’assessor potrebbe richiedere una definizione piena nel senso spiegato

sopra. E’ comunque indicata anche in “Component”, che è lo stesso obbligatoria nella fase


28

successiva. Quindi probabilmente conviene affrontare questo punto in maniera esaustiva

per tutti i componenti.

Formal methods – D.28

Già descritta nel paragrafo precedente. Il model checking e/o verifica di pre-post

condizioni (ad es. tramite esecuzione simbolica) potrebbe servire per alcune funzioni

critiche, o proprietà critiche (nel caso del model checking).

Modelling supported by computer aided design and specification tools – TAB. A.17

Tecnica identica al modeling, lo standard differenzia se viene utilizzato o meno un tool di

computer aided design.

1.4.5 Software Design and Implementation

Si elencano e illustrano le tecniche prescritte dallo standard 50128 per la fase di progetto e

implementazione del software (si veda come riferimento la tabella A.4 – Software Design

and Implementation (7.4) dello standard). Per questa fase lo standard propone un insieme

di tecniche già approvato per SIL 1 e 2, che comprende Structured methodology, modular

approach, Components e Design and Coding standards e inoltre una a scelta tra Strongly

typed programming language, Structured Programming e Programming language.

Modelling – A.17




Modular Approach– D.38

Lo scopo è di effettuare una decomposizione del software in parti piccole e comprensibili

per limitare la complessità del software.


29

Un approccio modulare definisce molte regole per le fasi di design, codifica e

manutenzione del software; queste regole variano a seconda della metodologia di design

che viene utilizzata. Molte metodologie contengono i seguenti principi: un componente

deve avere un compito singolo e ben definito; le connessioni fra i moduli devono essere

limitate e strettamente definite, la coerenza in un modulo deve essere forte; le collezioni di

sottoprogrammi devono essere costruite fornendo diversi livelli di componenti; i

sottoprogrammi devono avere un singolo ingresso e una singola uscita; i componenti

devono comunicare tra loro solo tramite le rispettive interfacce e laddove vengano usate

variabili comuni o globali devono essere ben strutturate, l’accesso ad esse deve essere

controllato e il loro uso giustificato appositamente; tutte le interfacce dei componenti

devono essere completamente documentate; è bene avere un numero massimo di cinque

paramteri per ogni componente.

In generale questi principi rappresentano regole per l’alta coesione e il basso

accoppiamento tra moduli; questi principi dovrebbero essere specificati nel processo.

La modularità in fase di analisi vuol dire per grandi linee applicare una decomposizione

della specifica (ad es. funzionale); in fase di design, può voler dire applicare regole sui

moduli per un’alta coesione, un basso accoppiamento, regole di comunicazione tra moduli

(ad es. limitato uso di variabili globali, invio/ricezione di segnali), regole sul numero dei

parametri, e così via. Alcuni di questi sono ripresi anche a livello implementazione (vedi

Tab. A.12 dello standard). In fase di implementazione questa tecnica è strettamente legata

all’information hiding/encapsulation, che consente di avere moduli con corpo nascosto e

interfaccia ben definita (ad es. prototipi).

Design and Coding Standards – A.12 - D.15, D.38

Restrizioni applicate per evitare guasti, come ad esempio uso limitato dei puntatori, non

uso dei “goto”, regole per il casting, uso limitato della ricorsione. Questa tecnica include

anche i principi di un approccio modulare visti in precedenza.

Formal methods – D.28


30


Components – Tab. A.20

Per implementarla si devono rispettare i principi di information hiding/encapsulation

descritti ed utilizzare un approccio modulare alla fase di design, nonché interfacce

completamente definite.

Analysable Programs – D.2

L’intenzione è di produrre programmi che sono facili da analizzare usando metodi di

analisi statica. Per fare ciò, bisogna verificare se il codice che si implementa rispetta le

seguenti indicazioni:

o Il flusso di controllo dei componenti dovrebbe essere composto da costrutti

strutturati: sequenze, iterazioni e selezioni. Dunque programmazione

strutturata, possibilmente senza istruzioni di salto incondizionato.

o I componenti dovrebbero essere “piccoli”.

o Ridotto numero di paths in un componente (ossia bassa complessità

ciclomatica, lo si potrebbe verificare in poco tempo con il tool under

stand).

o Disaccoppiamento fra le varie parti del programma (ricavabile da metriche

di fan-in e fan-out ancora con il tool Understand).

o Relazione semplice fra parametri di input e output.

o Condizioni semplici per la decisione di salti e cicli.

Se si implementano alcuni principi menzionati sopra (modular approach, defined interface,

modularity, structured programming) più qualche altra condizione (vedi D.2) si può dire di

implementare anche questo.

Strongly Typed Programming Language – D.49

Lo scopo di questa tecnica è di ridurre la probabilità dei guasti usando un linguaggio che

permette un alto livello di controllo da parte del compilatore. Questi linguaggi di solito


31

permettono al programmatore di definire tipi usando come base tipi predefiniti del

linguaggio come Integer, Real. Questi tipi possono essere usati nello stesso modo dei tipi

base, ma sono imposti dei controlli molto rigorosi per assicurare l’utilizzo del tipo

corretto. Questi controlli sono imposti sull’intero programma, anche se è costruito a partire

da unità compilate separatamente. I linguaggi strongly typed hanno anche altri aspetti di

buona pratica di ingegneria del software, come strutture di controllo facilmente

analizzabili. Lo standard menziona il Pascal, Ada e Modula-2 come linguaggi strongly

typed.

Structured Programming – D.53

Molto legata ad analysable programs, valgono principi molto simili:

o Evitare diramazioni complicate.

o Condizioni semplici per la decisione di salti e cicli.

o Suddivisione del componente in piccoli moduli e interazione esplicita fra i

moduli.

o Evitare salti incondizionati (goto).

Programming Language – tab. A.15

Lo standard 50128 ammette l’utilizzo di uno dei seguenti linguaggi di programmazione:

Ada, Pascal, Modula-2, C, C++, PL/M, Basic, Assembler, Java, C#. Solamente Ada,

Pascal, Modula-2 sono altamente raccomandati.

Language Subset – D.35

Definizione di un sottoinsieme del linguaggio da utilizzare che vada ad escludere quei

costrutti che sono difficili da analizzare usando l’analisi statica oppure sono maggiormente

soggetti ad errori, ad esempio uso di puntatori e allocazione dinamica; evitare l’uso di

puntatori a void.


32

Object Oriented Programming – D.57

Questa tecnica ha come obiettivi di permettere una prototipazione rapida, di riusare in

maniera più facile i componenti software, di raggiungere l’information hiding, di ridurre la

verosimiglianza degli errori durante l’intero ciclo di vita, di ridurre lo sforzo necessario in

fase di manutenzione, di suddividere i problemi complessi in problemi più piccoli e

gestibili, di ridurre la dipendenza fra i componenti software e di creare applicazioni più

facilmente estendibili.

La programmazione orientata agli oggetti è un nuovo modo di pensare al software

basandosi sulle astrazioni che esistono nella realtà piuttosto che su quelle computazionali.

Il software è organizzato come una collezione di oggetti che incorporano sia le strutture

dati che il comportamento.

Procedural Programming – D.60

La programmazione procedurale è basata sul concetto delle chiamate a procedura. Le

procedure, anche conosciute come routines, subroutines, metodi o funzioni a seconda del

linguaggio utilizzato, contengono una serie di passi computazionali da essere eseguiti.

Qualsiasi procedura può essere chiamata in un determinato punto del programma durante

l’esecuzione dello stesso, a sua volta può richiamare altre procedure.

Metaprogramming – D.59

Programmi che a loro volta scrivono o manipolano altri programmi, oppure che eseguono

parte del lavoro a compile time invece che a run time. Il linguaggio in cui è scritto il

metaprogramma è detto metalinguaggio. Il linguaggio dei programmi che sono manipolati

è detto il linguaggio oggetto. L’abilità di un linguaggio di programmazione di essere il

proprio metalinguaggio è detta riflessione.

1.4.6 Verification and Testing

Si elencano e illustrano le tecniche prescritte dallo standard 50128 per la fase di verifica e


33

testing (si veda come riferimento la tabella A.5 – Verification and Testing (6.2 and 7.3)).

Per questa fase lo standard propone un insieme di tecniche già approvato per SIL 1 e 2:

traceability è obbligatoria ed una a scelta tra analisi statica, analisi dinamica e testing,

testing funzionale/black box.

Traceability – D.58

La tracciabilità ha come obiettivo di assicurare che tutti i requisiti siano propriamente

soddisfatti e che non sia stato prodotto materiale non tracciabile. La tracciabilità dei

requisiti è una considerazione importante nella validazione di un sistema, e può essere

considerata applicabile sia ai requisiti funzionali che non funzionali.

Functional/ Black-box Testing – A.14

Questa tecnica prevede: Boundary value analysis, Equivalence classes and Input partition

testing, Process simulation, test case execution from cause consequence diagrams.

La Boundary value analysis consiste nel suddividere il dominio di input del

programma in un certo numero di classi di input. I tests dovrebbero coprire i confini e gli

estremi delle classi. I tests controllano che i confini nel dominio di input della specifica

coincidono con quelli nel programma. Ad esempio l’uso del valore zero è molto soggetto

ad errori e richiede un’ attenzione particolare. Se è possibile, si specifica un caso di test

che forza l’output ad assumere valori che eccedono i valori limite specificati.

Equivalence classes and input partition testing: questa strategia di test è basata su

una relazione di equivalenza degli inputs, che determina una partizione del dominio di

input. I casi di test sono quindi selezionati con l’obiettivo di coprire tutti i sottoinsiemi

della partizione. Almeno un caso di test deve essere selezionato da ogni classe di

equivalenza.

Process simulation: consiste nella creazione di un sistema, per soli scopi di testing, che

riproduce il comportamento del sistema che deve essere controllato dal sistema testato.

Test case execution from cause consequence diagrams: i test vengono scelti utilizzando i

diagrammi di causa conseguenza, che vengono realizzati a partire da un evento critico.


34

Formal Proof – D.29

Si dimostra tramite regole matematiche la correttezza del programma senza eseguirlo.

Anche in questo caso, vi sono tool di model checking che dal codice estraggono il modello

e ne verificano la correttezza; questa tecnca è abbastanza utilizzata nei sistemi embedded

ed è in diffusione.

Static Analysis – Tab. A.19

Può servire per validare “analysable programs”, come descritto in precedenza.

Dynamic Analysis and testing – Tab. A.13

Boundary value: il dominio di input del programma viene suddiviso in classi; i tests

devono coprire i valori estremi di queste classi. Tipicamente è usata in congiunzione con

input partition testing, e rappresenta il modo classico di fare test funzionale.

Test case from error seeding: iniezione artificiale di guasti, tipicamente usata meccanismi

di fault tolerance; per cui ha senso se si implementa “fault detection and diagnosis” o una

delle tecniche correlate, per validare il meccanismo introdotto.

Metrics – D.37

Le metriche valutano alcune proprietà strutturali del software e le mettono in relazione con

degli attributi come la complessità. Sonor richiesti tools software per fare queste

valutazioni. Alcune metriche possono essere: complessità ciclomatica, numero di modi per

attiavre un componente, complessità di Halstead, numero di punti di uscita/ entrata da un

componente.

Software Error Effect Analysis – D.25



35

Test Coverage for code – Tab. A.21

Viene scelto un insieme dei dati di input per poter coprire la maggior parte degli elementi

del codice; la copertura può essere fatta a livello di statement, di branch, di data flow, di

entire path. La copertura a livello di statement è quella meno rigorosa, perchè è possibile

eseguire tutti gli statement senza eseguire entrambi i rami di uno statement condizionale. Il

test di tutti i possibili path del codice è normalmente infattibile visto il numero enorme di

tutti i potenziali path di esecuzione.

Performance Testing – Tab. A.18 – D.3 – D.45 – D.40

Stress testing: si testa il sistema con un carico di lavoro eccezionalmente alto per mostrare

che il sistema resista facilmente a carichi di lavoro normali. Ci sono una serie di

condizioni che possono essere applicate per fare questo test: incrementare il numero di

modifiche degli input per unità di tempo, incrementare il numero di richieste per unità di

tempo, incrementare la dimensione del database, portare i device più importanti alla loro

massima velocità.

Response timing and memory constraints: lo scopo della tecnica è assicurare che il sistema

rispetterà i suoi requisiti temporali e di memoria. Viene effettuata una’ analisi che

identificherà la distribuzione delle richieste in condizioni normali e nel caso peggiore.

Questa analisi richiede stime dell’utilizzo delle risorse e il tempo richiesto per ogni

funzione del sistema.

Performance requirements: viene effettuata un’ analisi sia del sistema che delle specifiche

dei requisiti software per identificare tutti i requisiti generali e specifici, espliciti ed

impliciti di performance.

Interface Testing – D.34

Dimostrare che le interfacce dei sottoprogrammi non contengono errori o nessun errore

che possa portare a un failure. Vengono testate tutte le variabili di interfaccia alle loro

posizioni estreme; ogni variabile di interfaccia viene testata al suo valore estremo mentre

le altre sono a valori normali; tutti i valori di tutte le variabili in combinazione. Questi test


36

sono importanti soprattutto se non ci sono asserzioni che rilevano valori scorretti dei

parametri.

1.4.7 Integration

Si elencano le tecniche prescritte dallo standard 50128 per la fase di integrazione (si veda

come riferimento la tabella A.6- Integration dello standard).

Functional/ Black-box Testing – Tab A.14


Performance Testing – Tab. A.18


1.4.8 Overall Software Testing

Si elencano le tecniche prescritte dallo standard 50128 per la fase di overall software

testing. Per SIL 1 e 2 lo standard prevede una combinazione di tecniche già approvata che

include: Performance testing e Functional/Black-Box testing.

Performance Testing – Tab. A.18


Functional/ Black-box Testing – Tab A.14


Modelling – Tab. A.17

Già descritta nei paragrafi precedenti.


37

Capitolo 2 Tecniche di structured methodology

In questo capitolo vengono presentate le diverse metodologie di design strutturato note in

letteratura, corredate con esempi di semplice comprensione che ne mostrano la notazione.

2.1. SSADM

SSADM (Structured systems analysis and design method) utilizza una combinazione di tre

tecniche:

Logical Data Modeling - il processo di identificazione, modellazione e documentazione

dei requisiti dei dati del sistema che deve essere progettato. I dati sono separati in entità

(qualsiasi cosa per la quale dobbiamo memorizzare delle informazioni) e relazioni (le

associazioni tra le entità). Molto simile al modello ER usato per la progettazione di

database.

Data Flow Modeling - il processo di identificazione, modellazione e documentazione su

come i dati si muovono all’interno del sistema. Il Data Flow Modeling esamina i processi

(attività che trasformano i dati da una forma in un’ altra), data stores (aree predisposte a

memorizzare informazioni), external entities (entità esterne che ricevono dati dal sistema o

inviano dati al sistema) e i data flows (i percorsi che i dati percorrono).

Entity Behavior Modeling - il processo di identificazione, modellazione e

documentazione degli eventi che influiscono su ogni entità e la sequenza in cui questi


38

eventi occorrono. Denominato anche “Entity Life History”.

Ognuno di questi tre modelli del sistema fornisce un punto di vista differente dello stesso,

e ciascuno di questi punti di vista è richiesto per formare un modello completo del sistema

che deve essere progettato. Possono essere effettuati dei riferimenti incrociati fra le 3

tecniche per assicurare la completezza e precisione dell’intera applicazione[4]. 2.1.1 Data Flow Diagrams (DFD)

I DFD sono utilizzati per descrivere il flusso di informazioni interno al sistema. Il

principio generale dei DFD è che un sistema può essere decomposto in sottosistemi di

livello più basso e questi a loro volta in sottosistemi di livello ancora più basso. Ogni

sottosistema rappresenta un processo o un’ attività in cui vengono processati i dati[5].

Notazioni DFD

Figura 3 - Legenda DFD

I dati sono rappresentati tramite frecce che provengono dai process box e che entrano in

altri process box. Con gli ovali rappresentiamo le entità esterne, con i rettangoli i data

store.

Si riporta di seguito un esempio di DFD:


39

Figura 4 - Diagramma DFD

Nell’esempio, che è un DFD di primo livello, ovvero che descrive l’intero sistema , c’è

un’ interazione del sistema con un’ entità esterna (il customer). I DFD mostrano: i processi

all’interno del sistema, i data store che supportano le operazioni del sistema, il flusso di

informazioni nel sistema, i confini del sistema (linea tratteggiata) e le interazioni con

entità esterne.

Il simbolo che rappresenta i processi è un box, ognuno dei quali ha un id numerico

univoco in alto a sinistra e un nome univoco (un verbo all’imperativo che descrive

l’azione da compiere) nella parte inferiore del box; in alto è indicata la locazione del

processo ovvero dove è realizzata la stessa o da chi è realizzata. I processi trasformano i

dati in ingresso in dati in uscita e per ogni dato in ingresso c’è un corrispondente dato in

uscita.

Figura 5 - Process Box

I data flows vengono rappresentati tramite frecce, ognuna delle quali deve essere

etichettata con un sostantivo; non è possibile per i dati passare da un data store ad un altro


40

senza prima essere elaborati da un process box, inoltre le entità esterne non possono

accedere direttamente ai data stores. Per evitare incomprensioni è meglio evitare l’uso di

frecce bidirezionali.

Entità esterne

Possono essere organizzazioni, macchine o persone che contribuiscono a inviare

informazioni al sistema oppure a riceverle da esso.

Figura 6 - Entità esterna

Il nome dato all’entità esterna rappresenta un tipo e non una specifica istanza del tipo.

Quando si modellano sistemi complessi, si assegna un id univoco ad ogni entità esterna

presente nel DFD. Per rendere il diagramma più leggibile si possono usare entità esterne

duplicate per evitare eventuali linee sovrapposte.

Data stores

I data stores sono locazioni in cui i dati sono memorizzati permanentemente o

temporaneamente.


41

Figura 7 - Data Stores

Possono esserci quattro tipi di data stores:

D= computerised Data (il tipo più comune)

M= Manual (es. documenti cartacei)

T= Transient data file (es. i file temporanei di un programma)

TM= Transient Manual (es. posta tradizionale)

Così come per le entità esterne, è pratica comune avere dei duplicati dei data store per

questioni di leggibilità.

Le frecce entranti nel datastore indicano un’ operazione di scrittura o di

aggiornamento dei dati nel data store; le frecce uscenti indicano un’ operazione di lettura

dallo stesso. Quando non vengono etichettate queste frecce si sottintendono operazioni di

lettura/scrittura, altrimenti si etichettano con i nomi dei dati che vengono effettivamente

letti o scritti.

Livelli del DFD

A partire dal DFD top level si possono ricavare DFD di secondo livello con un maggior

livello di dettaglio. Ogni box del diagramma avrà un identificativo numerico gerarchico

derivato dal DFD padre, nell’angolo in alto a sinistra del box (es. 1.3 per un box di

secondo livello derivato dal box con id 1). Ogni process box di secondo livello può essere


42

a sua volta decomposto in box di terzo livello e così via.

Figura 8 - DFD di livello inferiore

2.1.2 Logical Data Modeling (LDM)

Gli LDM servono per rappresentare le relazioni fra i dati delle tabelle. Sono usati

essenzialmente per la fase di progettazione del database.

Figura 9 - LDM

Ogni entità si riferisce ad un gruppo di dati correlati memorizzati in una tabella di un

DBMS relazionale. Le relazioni illustrano come due entità sono legate fra loro. La

cardinalità specifica quante istanze di un’ entità sono in relazione con un’ istanza di un’

altra entità.


43

L’ordinalità indica se la relazione è obbligatoria oppure opzionale. Praticamente la

cardinalità indica il massimo numero di relazioni mentre l’ordinalità specifica il minimo

numero di relazioni.

Figura 10 - Relazioni, cardinalità e ordinalità

Si usa il simbolo (C) per indicare che tutte le entità figlie sono cancellate se l’entità padre

è cancellata. Si usa il simbolo (R) per indicare che l’entità padre potrebbe non essere

cancellata se il figlio esiste.

Figura 11 - Etichette C e R

2.1.3 Entity Behaviour Modeling (EBM)

I diagrammi EBM (oppure ELH, Entity Life History) rappresentano il ciclo di vita delle

entità all’interno del database.


44

Figura 12 - ELH diagram

Un evento crea, modifica o cancella un’ occorrenza di una o più entità. Gli eventi devono

essere ordinati cronologicamente da sinistra verso destra.

Per illustrare un evento che non è particolarmente significativo per il sistema, si

utilizza la struttura parallela.

Figura 13 - Struttura parallela

I due id numerici che ci sono sotto ogni evento sono degli state indicator, ovvero indicano

lo stato che precede l’evento e quello che lo segue.

2.2 JSD

Jackson System Development (JSD) è un metodo strutturato per la fase di analisi e design


45

simile a SSADM. Utilizza due tipi di diagrammi per modellare un sistema: Entity

Structure Diagrams (ESD) e Network Diagrams (ND).

2.2.1 Entity Structure Diagrams (ESD)

Gli ESDs illustrano la sequenza temporale delle azioni che le entità eseguono all’interno

del sistema. Simile agli Entity Behavior Models già visti in precedenza.

Figura 14 - Esempio di ESD

Un’ entità è un oggetto che agisce nel sistema; la radice dell’albero ESD è una singola

entità.

Le azioni sono effettuate dalle entità e influenzano altre entità. Il costrutto sequenza viene

usato per illustrare azioni che sono eseguite in ordine da sinistra a destra.

Figura 15 - Costrutto sequenza

Il costrutto di selezione viene usato per rappresentare una scelta tra due o più azioni


46

mutuamente esclusive; le azioni vengono marcate con una “o” (opzionali) nell’angolo in

alto a destra.

Figura 16 - Costrutto di selezione

Se un’ azione è ripetuta, si pone un asterisco * nell’angolo in alto a destra. Solitamente c’è

una sola azione nel costrutto di iterazione.

Figura 17 - Costrutto di iterazione

Di seguito è riportato un esempio di ESD semplice applicato ad un’ entità autovettura:

Figura 18 - ESD autovettura


47

2.2.2 Network Diagrams (ND)

I network diagram mostrano l’interazione tra i processi.

Figura 19 - Esempio di JSD Network Diagram

I processi rappresentano funzioni del sistema. Il processo è solitamente connesso ad un’

entità esterna tramite un datastream(D). I datastreams connettono i processi e specificano

che informazione è passata tra loro. Gli state vector (SV) sono un modo alternativo per

connettere i processi; specificano una caratteristica o lo stato dell’entità che viene

modificata dal processo.

Una differenza fondamentale tra datastreams e state vector è la sincronizzazione fra

il processo che scrive i dati e quello che li deve leggere. Nel caso dei datastreams quando

il processo che scrive è pronto, causa la riattivazione del processo che legge. Invece per gli

state-vector, il processo in lettura non viene automaticamente ri-attivato, ma è suo compito

controllare periodicamente lo state-vector per verificare se ci sono nuovi dati da

processare.


48

2.3 MASCOT

MASCOT (Modular Approach to Software Construction, Operation, and Test) ha lo scopo

di definire una piattaforma e un approccio per la definizione, implementazione e

deployment di sistemi multi-tasking e multi-threaded. MASCOT presenta un approccio

per la definizione del comportamento di un sistema a run-time[6]. Il processo di

definizione di un sistema MASCOT avviene con la connessione delle entità nel contesto di

un diagramma ACP (Activities, Channels and Pools).

Figura 20 - Diagramma ACP

Subsystems

I sottosistemi, rappresentati con rettangoli tratteggiati, possono contenere tutte le entità

MASCOT, mentre solo il sottosistema globale può contenere i devices. Il sottosistema

globale è obbligatorio e contiene tutti gli altri sottosistemi. I nomi dei sottosistemi hanno


49

visibilità globale e identificano il template usato per costruire l’entità.

Activity

Le attività, rappresentate da ovali, implementano le funzionalità del sistema e sono

essenzialmente un singolo thread di esecuzione. Le attività interagiscono tra di loro e con i

devices tramite le IDA (Intercommunication Data Areas, un termine usato per identificare

sia i channels che i pools). In MASCOT non c’è il concetto di attività che comunicano

direttamente; qualsiasi attività di sincronizzazione o di scheduling viene effettuata tramite

un accesso all’IDA.

Channel

Figura 21 - Simbolo del channel

I channels funzionano come le pipes: le attività scrivono su un’ estremità e leggono

dall’altra estremità. Ogni channel ha un’ implementazione ad esso associata che definisce

il suo comportamento; questa implementazione è condivisa tra le varie istanze del channel.

Pool

Figura 22 - Simbolo del pool

I pool hanno un funzionamento simile ai data stores. Le attività che scrivono in un pool si

aspettano che i dati persistano così come definisce l’implementazione del pool. Così come

per i channels, anche i pool hanno un’ implementazione condivisa tra le varie istanze.


50

Connection

Figura 23 - Simbolo della connection

Una connessione rappresenta l’accesso di un’ attività ad un IDA (channel o pool). Ogni

connessione ha uno scope che può essere:

o Local: interno al contesto del sottosistema che definisce la connessione.

o Global: interno al contesto del sottosistema globale.

o Container: interno al contesto del sottosistema che contiene il sottosistema

in cui è definita la connessione.

o Argument: in questo caso, il processo di collegare la connessione al

relativo target viene posticipato a runtime.

Device

I devices sono entità che rappresentano un accesso a dei processi o dell’hardware che è

esterno al contesto del sottosistema globale. I sottosistemi possono condividere l’istanza

di un device. Ogni device implementa due connessioni, una read e una write, ma può

anche averne altre in base alla sua implementazione.

Figura 24 - Simbolo per il device


51

2.4 Yourdon (YSM) Lo “Yourdon Structured Method” è stato esteso per i sistemi embedded da Ward e Mellor;

è una metodologia popolare e facilmente comprensibile; ha il vantaggio di poter essere

applicata sia a sistemi piccoli che voluminosi. È supportata da tools come Select-Yourdon

e EasyCase[7].

Anche Yourdon, come SSADM utilizza i data flow diagrams e gli entity-

relationship diagram, ma con notazione leggermente differente per i DFD.

Gli elementi basilari della notazione in Yourdon sono quattro: il terminator, il data

transformation process, il data store e il discrete data flow. Il terminator rappresenta un

elemento nell’ambiente del sistema; agisce come una sorgente dei dati o utilizatore degli

stessi. Il data transformation è un processo di ingresso/uscita, che può notificare

dell’occorrenza di un evento, ad esempio iniziare un flusso di controllo. Il data store è

l’astrazione di un file; esso funge da deposito per i dati che sono soggetti a un ritardo

relativo alla memorizzazione; i valori sono modificati in punti discreti nel tempo e

memorizzati; la lettura non avviene in maniera ordinata ed è non distruttiva. Il flusso di

dati discreto è l’astrazione di una transazione o di un’ altra aggregazione di dati inviati o

ricevuti dal sistema.

Figura 25 - Elementi basilari in Yourdon


52

Per i sistemi real-time, è necessario introdurre elementi addizionali da gestire: control

transformation process, control store e i prompts. Il control transformation process

controlla il comportamento delle trasformazioni dei dati, andandole ad attivare o

disattivare; è un’ astrazione su una porzione della logica di sistema. Il control store

rappresenta un buffer; è un’ astrazione di uno stack (con strategia last-in-first-out oppure

first-in-first-out); la lettura non è ordinata ma è distruttiva; il control store ha una capacità

massima. I prompts sono inizializzati dai processi di controllo e attivano le trasformazioni

dei dati.

Figura 26 - Notazione YSM real-time

2.4.1 Context Diagram

La metodologia Yourdon consiste nella costruzione di un modello del sistema in maniera


53

gerachica identificando diversi livelli di astrazione. Il livello più elevato è noto come

diagramma di contesto. Tipicamente consiste di un singolo blocco di trasformazione dei

dati, alcuni flussi dei dati e/o di controllo e dei terminators. Il nodo di trasformazione dei

dati viene esploso in un diagramma figlio del flusso dei dati (per i diagrammi del flusso

dei dati si veda il paragrafo 2.1.1).

Figura 27 - Context Diagram

2.4.2 Processo di controllo

Le specifiche di controllo sono date tramite i comuni diagrammi “state transition”.

Figura 28 - State transition diagram


54

Le transizioni fra gli stati accadono come conseguenza di eventi di input. Le routine

relative alle azioni producono in uscita flussi di eventi e prompts (FSM di Mealy).

2.4.3 Process specifications

La procedura di decomposizione del sistema continua finchè non viene trovato un livello

laddove le operazioni da eseguire all’interno di un processo di trasformazione non hanno

bisogno di essere suddivise nuovamente. A questo punto si realizza una descrizione dei

singoli processi con l’utilizzo di un Process Specification. Esso consiste di inglese

strutturato, tabelle, formule matematiche e grafici. I costrutti basilari della lingua inglese

sono quattro: concorrenza, sequenza, decisione e iterazione[8].

2.4.4 Data Dictionary

I flussi di dati entranti e uscenti dal sistema sono solitamente non primitivi, cioè

rappresentano gruppi di dati. Questi gruppi vengono decomposti in gruppi sempre più

piccoli man mano che si procede verso il basso nei livelli gerarchici, finchè non si

riducono ad elementi primitivi[9]. Il dizionario specifica gli elementi e la struttura di ogni

gruppo usando una notazione speciale, la Backus-Naur form (BNF), riportata nella tabella

seguente.

Simbolo Descrizione

= Il flusso sulla sinistra è composto dai flussi presenti sulla

destra.

+ Raccoglie i flussi in un gruppo ma non implica un ordinamento

degli stessi

{ } L’espressione inclusa nelle parentesi graffe può occorrere un

certo numero di volte in un’ istanza del flusso. Le parentesi

possono essere indicizzate. {}2 indica zero,una o due

iterazioni. 2{} indica due o più iterazioni. 2{}2 indica


55

esattamente due iterazioni.

[ | ] Una data istanza del flusso conterrà esattamente una delle

opzioni interne alle parentesi

( ) L’espressione all’interno delle parentesi può opzionalmente

apparire in una data istanza del flusso.

* * Racchiude un commento Figura 29 - Notazione Backus-Naur Form

Per ciascun flusso di dati presente nel Data Flow Diagram deve essere presente una

definizione dello stesso nel data dictionary.

Certificazione del software in ambito ferroviario: un caso di studio per un sistema a bordo treno

56

Capitolo 3 Caso di studio: certificazione di un sistema a bordo treno

3.1 Descrizione del caso di studio

L’Iniziativa Software Finmeccanica, avviata nell'aprile del 2006, vede oggi il

coinvolgimento del CINI (Consorzio Interuniversitario Nazionale per l'Informatica), del

Consorzio SESM e di alcune aziende del gruppo Finmeccanica, tra cui appunto

AnsaldoBreda a partire dall'autunno del 2010.

L’unità di Ricerca coordinata dal professor Stefano Russo ha come obiettivo

l'esplorazione delle problematiche relative all’ingegneria del software. In particolar modo

nel triennio 2010-2013 è attiva la seguente linea di ricerca: “Metodologie e strumenti per

l’ingegneria del software applicate alla piattaforma MLA (Metro Leggera Automatica)”.

3.1.1 Metropolitana leggera automatica

La Commissione Europea, mediante le norme UNI 8379 e l'UITP (Associazione

Internazionale del Trasporto Pubblico), ha definito la metropolitana (Rail Rapid Transit)

come un "sistema di trasporto rapido di massa, di alta capacità e frequenza, costituito da

veicoli automotori o mossi da veicoli automotori circolanti su rotaia, ovvero con altra


57

guida vincolante e completamente svincolata da qualsiasi altro tipo di traffico, con regime

di circolazione regolata da segnali ".

Una prima caratterizzazione dell’infrastruttura metropolitana vede la contrapposizione di

due modelli: la metropolitana leggera e quella pesante, che differiscono per: portata,

frequenza delle corse e tipologia di rotabile adoperato.

Figura 30 - Piattaforma MLA

In questa sede ci occuperemo della categoria leggera (Light Rail Transit), definita

dall’UNI 8379 come: "un sistema di trasporto rapido di massa che mantiene le

caratteristiche della metropolitana, ad eccezione della portata oraria, che è prevista

minore, e dei veicoli che, qualora opportunamente attrezzati, possono essere utilizzati su

tratti di linea che, avendo caratteristiche tranviarie, non rientrano nella categoria delle

metropolitane leggere", aggiungendo a questa la definizione fornita dalla International

Light Rail Commission: "la metropolitana leggera è una forma di trasporto su rotaia che

può essere sviluppata per fasi da un tram moderno ad un sistema di trasporto rapido

circolante in sede propria o sotto terra. Ciascuno stadio di sviluppo può essere completo


58

di per sè, ma deve rendere possibile gli sviluppi per passare al successivo". Dunque, la

metropolitana leggera si presenta come un sistema in grado di offrire un servizio

intermedio tra quello tranviario e quello del metrò, da un canto fornendo i vantaggi tipici

dei sistemi su rotaia (elevate capacità, alta produttività, comfort, affidabilità) e dall'altro

introducendo alcune problematiche sostanzialmente relative ai riflessi ambientali derivanti

da viadotti, rampe di accesso alle gallerie o elementi-barriera, e dai fenomeni

d'interferenza con le altre modalità di trasporto in sede promiscua.

3.2 Applicazione delle tecniche di structured methodology

Inizialmente è stato creato il diagramma di contesto (vedi figura 31) che definisce il

confine tra il sistema software preso in analisi e l’ambiente circostante. Il gestore del

telecomando comunica con sei entità esterne: il bus wtb responsabile di inviare i dati ad un

gestore del telecomando remoto e riceverli, i dispositivi del livello treno dai quali riceve il

loro stato e ai quali invia comandi di attuazione (analogamente per i dispositivi di logica di

veicolo e di logica di carrozza), l’IDU alla quale invia messaggi di diagnostica e lo stato

del blocco di trazione e infine riceve lo stato (abilitato/non abilitato) dal banco di manovra.


59

Figura 31 - Context Diagram: gestore del telecomando

Il diagramma di contesto è stato esploso in un diagramma del flusso dei dati di primo

livello (vedi figura 32), dove gestore del telecomando è stato suddiviso in quattro

macrofunzionalità per gestire la complessità del sistema software: gateway, logica di

treno, logica di veicolo, logica di carrozza.


60

Figura 32 - Dfd telecomando

Il gateway ha il compito principale di trasferire i dati tra il bus di veicolo MVB e il bus di

treno WTB. Dal bus WTB riceve i comandi remoti e lo stato dei train set remoti, mentre

invia lo stato del train set locale e i comandi locali. La logica di treno se il banco è

abilitato, invia i comandi locali, lo stato del train set locale e lo stato del banco al gateway,

altrimenti se il banco non è abilitato riceve dal gateway la configurazione del train set, i


61

comandi remoti e lo stato dei train set remoti. Inoltre invia all’IDU lo stato del blocco di

trazione (trb_state). La logica di veicolo invia alla logica di treno lo stato del veicolo,

riceve da quest’ ultima i comandi non sotto chiave di banco e i comandi lv. La logica di

carrozza interagisce con la logica di veicolo inviandole lo stato della carrozza e ricevendo

i comandi lc.

Figura 33 - LT 3

I comandi di attuazione di lc sono inviati ai dispositivi di lc, dai quali si riceve come

feedback lo stato del dispositivo lc.

Il process box 3-LT è stato esploso (vedi figura 33) in sette process box: Espansione stato


62

banco a partire dallo stato del banco genera “effort” e “speed reference in” per il process

box “speed management”; genera “memory reset condition” e “bypass request” per il

blocco di trazione TRB; genera “banco abilitato” che è un valore binario in base al quale il

process box “Scelta r1” sceglierà se ricopiare “comandi remoti” oppure “comandi locali”

su “comandi lv”. Il process box “speed management” analizzando “stato dispositivo lt”,

“effort”, “speed reference in” genera i flussi “command request” e “effort request” per la

generazione dei comandi LT. Il process box “Generazione comandi LT” ricevuta

l’abilitazione “traction enable” genera i “comandi locali” e i “comandi di attuazione di lt”.

Il trb che gestisce la trazione del treno genera i flussi “trb_bypassed”, “trb_activated”,

“trb_memory” e “traction enable”.


63

Figura 34 - Speed Management 3.2

La funzionalità “Speed management” è stata suddivisa in: “Vehicle speed define” che

definisce la velocità del treno, in “Speed limit” che assicura che non venga superata la

massima velocità consentita, in “Speed regulator” che calcola lo sforzo necessario per

mantenere la velocità desiderata, in “ATO management” che gestisce la guida automatica

e in “operative mode”.


64

Il process box TRB (vedi figura 35) è stato suddiviso in: “Bypassable conditions”,

“Traction Block Conditions”, “Srs TRB”. “Bypassable conditions” riceve lo stato del

veicolo e genera il flusso di dati “Bypass_parameters”. “Traction Block Conditions” a

partire dallo stato del veicolo genera condizioni di set e reset per “srs TRB”.

Figura 35 - TRaction Block 3.3

L’ultimo process box della logica di treno che è stato esploso è “Generazione comandi LT

3.4” (vedi figura 36).


65

Figura 36 - Generazione comandi LT 3.4

In questo process box, “AT_Management_LT” sovrintende alla gestione dell’alta tensione

per ciò che concerne la logica di treno, “MT_Management_LT” sovrintende alla gestione

della media tensione per ciò che concerne la logica di treno, “BT_Management_LT”

sovrintende alla gestione della bassa tensione per ciò che concerne la logica di treno,

“Door_Management_LT” sovrintende all’apertura e alla chiusura delle porte per ciò che


66

concerne la logica di treno, “HVAC_Management_LT” sovrintende al condizionamento e

al riscaldamento del treno, “Marcia” genera i comandi per l’unità di controllo della

trazione e lo sforzo che deve effettuare la stessa unità.

3.2.1 Data dictionary nel caso di studio

Successivamente è stato definito un data dictionary per specificare i flussi di dati

composti in flussi di dati elementari per il modulo “telecomando”:

R1_Mvb:

R1_Mvb = r1_mvb_ds1 + r1_mvb_ds2 + r1_mvb_ds3 + r1_mvb_ds4

r1_mvb_ds1 = 32 byte




byte = bit + bit + bit + bit + bit + bit + bit + bit

bit = [0|1]

R2_Mvb:

R2_Mvb = r2_mvb_ds1 + r2_mvb_ds2 + r2_mvb_ds3 + r2_mvb_ds4






bit = [0|1]

MS_LT:

MS_LT = bit + bit

bit = [0|1]


67

R1_LV:

*R1_lv= [R1MVB | R1_MVB_REM]*

R1_LV = r1_lv_ds1 + r1_lv_ds2 + r1_lv_ds4

*il ds3 non è presente volutamente*

r1_lv_ds1 = 32 byte

r1_lv_ds2 = 32 byte

r1_lv_ds4 = 32 byte


bit = [0|1] R1_Mvb_rem:

R1_Mvb_rem = r1_mvb_rem_ds1 + r1_mvb_rem_ds2 + r1_mvb_rem_ds3 +

r1_mvb_rem_ds4

r1_mvb_ rem_ds1 = 32 byte





bit = [0|1] MS_GTW:

MS_GTW = nTS + TCN + UIC + Driving direction

nTS = bit + bit + bit + bit + bit

TCN = bit + bit + bit + bit + bit + bit

UIC = bit + bit + bit + bit + bit

Driving direction = {0|1|2|3}

bit = [0|1]

Stato_banco:

Stato_banco = bit


68

bit = [0|1]

R2_Mvb_rem_I_J:

R2_Mvb_rem_I_J = R2_Mvb_rem_1_J + R2_Mvb_rem_2_J + R2_Mvb_rem_3_J +

+R2_Mvb_rem_4_J

R2_Mvb_rem_1_J = R2_Mvb_rem_1_1 + (R2_Mvb_rem_1_2 + (R2_Mvb_rem_1_3 +

(R2_Mvb_rem_1_4 + (R2_Mvb_rem_1_5 + …+ (R2_Mvb_rem_1_64 ) ) ) ) )

R2_Mvb_rem_2_J = R2_Mvb_rem_2_1 + (R2_Mvb_rem_2_2 + (R2_Mvb_rem_2_3 +(

R2_Mvb_rem_2_4 +( R2_Mvb_rem_2_5 + … + (R2_Mvb_rem_2_64 ) ) ) ) )





R2_Mvb_rem_1_1 = 32 byte






* R2_Mvb_rem_1_N = 32 byte *

* N = num.dei train set remoti. Max: 64 *




69








*tutti gli altri segnali non specificati da 5 a 63 sono a 32 byte*






*tutti gli altri segnali non specificati da 5 a 63 sono a 32 byte*

R2_Mvb_rem_4_64 = 32 byte Data_in:

*non ancora definito il formato dei dati* Data_out: *non ancora definito il formato dei dati* R2_Com:

32 byte


70

Per snellire la notazione sono stati usati dei nomi simbolici, la cui corrispondenza con i

flussi di dati specificati nei diagrammi è esplicitata nella seguente tabella:

N° Segnali Flusso

1 DATA_IN Stato carrozza 2 DATA_OUT Comandi lc 3 R1_LV Comandi LV * [R1MVB | R1_MVB_REM]* 4 R2_LV Stato veicolo 5 R2_COM Comandi non necessariamente sotto chiave di banco 6 MS_LT Stato del banco del Train Set locale 7 OUT_LV Comandi di attuazione della LV 8 INP_LV Stato del dispositivo LV 9 OUT_Lc Comandi di attuazione della Lc

10 INP_Lc Stato del dispositivo Lc 11 R2_MVB Stato del train set locale 12 R1_MVB comandi_LT / stato del train set locale 13 MS_GTW Configurazione del train set 14 R1_MVB_REM Comandi remoti / stato del ts remoto 15 R2_MVB_REM_i_j Stato dei train set remoti non abilitati 16 R2_WTB Stato del train set locale (quando il train set locale non è abilitato)

17 R1_WTB Comandi e stato del train set locale (quando il train set locale è abilitato)

18 R2_WTB_REM_J Stato del train set remoto 19 R1_WTB_REM Comandi/stato del ts remoto abilitato


71

3.3 Integrazione delle structured methodology con concetti model-based La metodologia Yourdon real time prevede ulteriori elementi come il control

transformation process che controlla il comportamento delle trasformazioni dei dati.

Nel caso di studio è stato individuato all’interno del modulo Odometro, un processo

di controllo(vedi figura 37):

Figura 37 - Odometro fsm


72

L’odometro parte operativa calcola, a partire dalla velocità del treno, la distanza percorsa

dallo stesso. Odometro fsm è il processo di controllo individuato che invia un segnale di

reset ad odometro parte operativa.

Successivamente il comportamento di Odometro fsm viene specificato tramite un

diagramma di transizione degli stati (vedi figura 38):

Figura 38 - State transition diagram- odometro fsm


73

Conclusioni

É stata effettuata una fase di analisi del processo di sviluppo del software in

AnsaldoBreda.

Da questa fase di analisi è emerso che ci sono diverse tecniche richieste per SIL 2

che non vengono adottate o parzialmente adottate; insieme ai progettisti di AnsaldoBreda

si è deciso di intervenire sulla fase di design del software.

Sono state presentate diverse tecniche di metodologie strutturate (SSADM, JSD,

Mascot, Yourdon) e la scelta è ricaduta su Yourdon, più vicina al modo di progettare pre-

esistente in AnsaldoBreda che prevede un ampio utilizzo di Matlab, in particolar modo di

Stateflow per la descrizione delle macchine a stati finiti, dalle quali si genera in maniera

automatica il codice sorgente a partire dal modello.

La metodologia Yourdon è stata applicata per descrivere l’architettura del software

sviluppato in azienda. Applicando la suddetta metodologia, il team di progettazione sarà

ora in grado di mostrare al cliente e all’assessor che utilizza una delle tecniche

obbligatorie per lo sviluppo dei futuri moduli software che richiederanno una

certificazione SIL 2.

Sono state infine redatte delle linee guida per poter permettere l’ applicazione della

metodologia a un altro progetto, che si possono racchiudere in tre fasi principali:

• Fase 1: Si costruisce il context diagram che consiste di un unico processo di

trasformazione dei dati che rappresenta il sistema da progettare; esso interagisce

con una o più entità esterne che rappresentano l’ ambiente esterno e con eventuali

data stores.


74

• Fase 2: Il context diagram viene esploso in diagrammi dei flussi dei dati che

rappresentano come i dati fluiscono nel nostro sistema. Ciascun processo di

trasformazione dei dati può essere ulteriormente suddiviso in dfd di livello

gerarchico inferiore. Quando si scende di livello bisogna rispettare la coerenza dei

flussi: se al livello superiore un processo di trasformazione dei dati ha 3 flussi

entranti e 5 flussi uscenti ne dovrà avere altrettanti quando viene esploso al livello

inferiore. Ogni processo di trasformazione deve avere almeno una freccia entrante

e almeno una uscente. La suddivisione in dfd di livello gerarchico inferiore termina

quando si ha la percezione che quel processo di trasformazione dei dati è

abbastanza semplice da poter essere implementato direttamente con il codice. Nei

dfd possono essere identificati oltre ai processi di trasformazione dei dati, anche

processi di controllo rappresentati da cerchi tratteggiati. Questi processi inviano

segnali di controllo ai processi di trasformazione dei dati.

• Fase 3: i processi di controllo (cerchi tratteggiati) non vengono suddivisi in dfd di

livello gerarchico inferiore come viene fatto per i processi di trasformazione dei

dati, ma vengono rappresentati dagli state transition diagram. Le transizioni da uno

stato ad un altro sono scaturite da eventi di input che determinano le relative azioni

da eseguire (in particolar modo settare il valore di un segnale di controllo). I

segnali di controllo sono rappresentati da frecce tratteggiate. A questo punto il

passaggio dagli state transition diagram alle macchine a stati finiti modellate in

stateflow è immediato.


75

Sviluppi futuri

In futuro, affinchè AnsaldoBreda possa sviluppare il software a bordo treno che possa

essere certificato per il livello SIL 2, si potranno esaminare e applicare le tecniche di:

o Defensive programming, per la fase di architettura del software

o Modular approach, components e design and coding standards, per la fase

di software design and implementation

o Black box testing, per la fase di verification and testing

o Performance testing, per la fase di integration testing

o Performance testing e Black box testing, per la fase di overall software

testing

76

Bibliografia

[1] Robert Traussnig, 2004, “Safety-Critical Systems: Processes, Standards and

Certification”

[2] Marc C. Paulk, Bill Curtis, 1993, “Capability Maturity Model for Software”

[3] CENELEC, 2011, “Railway applications - Communication, signalling and

processing systems -Software for railway control and protection systems”

[4] Ashworth C., 1998, “SSADM A Practical Approach”

[5] Tony Drewry, 2005, “Data flow diagrams”

[6] Object Forge, 2003, “MASCOT 2002”

[7] Vijay Kumar Samyal, 2001,“The Yourdon Structured Method”

[8] Edward Yourdon, 2006, “Just Enough Structured Analysis”

[9] J.D. Lomax, 1977, “Data Dictionary Systems”

Tesi SantoRusso 885-517-Certificazione del software in ... · o UK British Standards Institute (BS)...

Documents

Transcript of Tesi SantoRusso 885-517-Certificazione del software in ... · o UK British Standards Institute (BS)...