Sei sulla pagina 1di 136

N O R M A I T A L I A N A CEI

Norma Italiana

CEI EN 50128
Data Pubblicazione Edizione
2002-04 Prima
Classificazione Fascicolo
9-72 6421
Titolo
Applicazioni ferroviarie, tranviarie, filoviarie e metropolitane
Sistemi di telecomunicazione, segnalamento ed elaborazione -
Software per sistemi ferroviari di comando e di protezione

Title
Railway applications
Communications, signalling and processing systems - Software for
railway control and protection systems
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

APPARECCHIATURE ELETTRICHE PER SISTEMI DI ENERGIA E PER TRAZIONE

NORMA TECNICA

COMITATO
ELETTROTECNICO CNR CONSIGLIO NAZIONALE DELLE RICERCHE • AEI ASSOCIAZIONE ELETTROTECNICA ED ELETTRONICA ITALIANA
ITALIANO Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
SOMMARIO
La presente Norma specifica le procedure ed i requisiti tecnici per lo sviluppo del software, per impiego
nelle applicazioni ferroviarie con livello di sicurezza superiore allo 0.

DESCRITTORI • DESCRIPTORS
Ferrovie • Railways; Tranvie • Tramways; Filovie • Trolley buses; Metropolitane • Underground; Software •
Software;

COLLEGAMENTI/RELAZIONI TRA DOCUMENTI


Nazionali (UTE) CEI EN 50126:2000-03;
Europei (IDT) EN 50128:2001-03;
Internazionali

Legislativi

INFORMAZIONI EDITORIALI
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

Norma Italiana CEI EN 50128 Pubblicazione Norma Tecnica Carattere Doc.

Stato Edizione In vigore Data validità 2002-6-1 Ambito validità Europeo


Varianti Nessuna
Ed. Prec. Fasc. Nessuna

Comitato Tecnico 9-Trazione


Approvata dal Presidente del CEI in Data 2002-3-13
CENELEC in Data 2000-11-1
Sottoposta a inchiesta pubblica come Documento originale Chiusa in data 2000-7-31

Gruppo Abb. 3 Sezioni Abb. B


ICS 29.280; 45.060.10;
CDU

LEGENDA
(UTE) La Norma in oggetto deve essere utilizzata congiuntamente alle Norme indicate dopo il riferimento (UTE)
(IDT) La Norma in oggetto è identica alle Norme indicate dopo il riferimento (IDT)

© CEI - Milano 2002. Riproduzione vietata.


Tutti i diritti sono riservati. Nessuna parte del presente Documento può essere riprodotta o diffusa con un mezzo qualsiasi senza il consenso scritto del CEI.
Le Norme CEI sono revisionate, quando necessario, con la pubblicazione sia di nuove edizioni sia di varianti.
È importante pertanto che gli utenti delle stesse si accertino di essere in possesso dell’ultima edizione o variante.
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
Europäische Norm • Norme Européenne • European Standard • Norma Europea
EN 50128

Applicazioni ferroviarie, tranviarie, filoviarie e metropolitane


Sistemi di telecomunicazione, segnalamento ed elaborazione -
Software per sistemi ferroviari di comando e di protezione

Railway applications
Communications, signalling and processing systems - Software for
railway control and protection systems
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

Applications ferroviaires
Système de signalisation, de télécommunication et de traitement -
Logiciels pour systèmes de commande et de protection ferroviaire

Bahnanwendungen -
Telekommunikationstechnik - Signal- technik und
Datenverarbeitungssysteme - Software für Eisenbahnsteuerungs- und
Überwachungssysteme

CENELEC members are bound to comply with the I Comitati Nazionali membri del CENELEC sono tenu-
CEN/CENELEC Internal Regulations which stipulate ti, in accordo col regolamento interno del CEN/CENE-
the conditions for giving this European Standard the LEC, ad adottare questa Norma Europea, senza alcuna
status of a National Standard without any alteration. modifica, come Norma Nazionale.
Up-to-date lists and bibliographical references con- Gli elenchi aggiornati e i relativi riferimenti di tali Nor-
cerning such National Standards may be obtained on me Nazionali possono essere ottenuti rivolgendosi al
application to the Central Secretariat or to any Segretariato Centrale del CENELEC o agli uffici di
CENELEC member. qualsiasi Comitato Nazionale membro.
This European Standard exists in three official ver- La presente Norma Europea esiste in tre versioni uffi-
sions (English, French, German). ciali (inglese, francese, tedesco).
A version in any other language and notified to the Una traduzione effettuata da un altro Paese membro,
CENELEC Central Secretariat has the same status as sotto la sua responsabilità, nella sua lingua nazionale
the official versions. e notificata al CENELEC, ha la medesima validità.
CENELEC members are the national electrotechnical I membri del CENELEC sono i Comitati Elettrotecnici
committees of: Austria, Belgium, Czech Republic, Nazionali dei seguenti Paesi: Austria, Belgio, Dani-
Denmark, Finland, France, Germany, Greece, Iceland, marca, Finlandia, Francia, Germania, Grecia, Irlanda,
Ireland, Italy, Luxembourg, Netherlands, Norway, Islanda, Italia, Lussemburgo, Norvegia, Olanda, Por-
Portugal, Spain, Sweden, Switzerland and United togallo, Regno Unito, Repubblica Ceca, Spagna,
Kingdom. Svezia e Svizzera.

© CENELEC Copyright reserved to all CENELEC members. I diritti di riproduzione di questa Norma Europea sono riservati esclu-
sivamente ai membri nazionali del CENELEC.

C E N E L E C
Comitato Europeo di Normalizzazione Elettrotecnica Secrétariat Central: Comité Européen de Normalisation Electrotechnique
European Committee for Electrotechnical Standardization rue de Stassart 35, B - 1050 Bruxelles Europäisches Komitee für Elektrotechnische Normung
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
CONTENTS INDICE
Rif. Topic Argomento Pag.

INTRODUCTION INTRODUZIONE 1

1 SCOPE CAMPO D’APPLICAZIONE 4

2 NORMATIVE REFERENCES RIFERIMENTI NORMATIVI 5

3 DEFINITIONS DEFINIZIONI 6
3.1 Assessment ....................................................................................... Valutazione ........................................................................................ 6
3.2 Assessor ............................................................................................. Valutatore ............................................................................................ 6
3.3 Availability ........................................................................................ Disponibilità ...................................................................................... 6
3.4 Commercial off-the-shelf (COTS) software ...................... Software disponibile commercialmente (COTS) ............ 6
3.5 Design authority ............................................................................ Autorità per il progetto ............................................................... 6
3.6 Designer ............................................................................................ Progettista ........................................................................................... 6
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

3.7 Element .............................................................................................. Elemento ............................................................................................. 7


3.8 Error ..................................................................................................... Errore .................................................................................................... 7
3.9 Failure ................................................................................................. Mancato funzionamento .............................................................. 7
3.10 Fault ..................................................................................................... Guasto .................................................................................................. 7
3.11 Fault avoidance .............................................................................. Tecnica per evitare i guasti ........................................................ 7
3.12 Fault tolerance ................................................................................ Tolleranza ai guasti ........................................................................ 7
3.13 Firmware ........................................................................................... Firmware ............................................................................................. 7
3.14 Generic software ........................................................................... Software generico ........................................................................... 7
3.15 Implementer .................................................................................... Implementatore ................................................................................ 7
3.16 Product ............................................................................................... Prodotto ............................................................................................... 7
3.17 Programmable logic controller (PLC) ................................. Controllore a logica programmata (PLC) .......................... 8
3.18 Reliability ........................................................................................... Affidabilità .......................................................................................... 8
3.19 Requirements traceability .......................................................... Tracciabilità dei requisiti ............................................................. 8
3.20 Risk ...................................................................................................... Rischio .................................................................................................. 8
3.21 Safety ................................................................................................... Sicurezza ............................................................................................. 8
3.22 Safety authority .............................................................................. Autorità per la sicurezza .............................................................. 8
3.23 Safety-related software ............................................................... Software in sicurezza .................................................................... 8
3.24 Software ............................................................................................. Software ............................................................................................... 8
3.25 Software life-cycle ........................................................................ Ciclo di vita del software ............................................................ 8
3.26 Software maintainability ............................................................ Manutenibilità del software ....................................................... 8
3.27 Software maintenance ................................................................ Manutenzione del software ...................................................... 9
3.28 Software safety integrity level ................................................. Livello di integrità della sicurezza del software .............. 9
3.29 System safety integrity level .................................................... Livello di integrità della sicurezza del sistema ................. 9
3.30 Traceability ....................................................................................... Tracciabilità ........................................................................................ 9
3.31 Validation .......................................................................................... Validazione ........................................................................................ 9
3.32 Validator ............................................................................................ Validatore ............................................................................................ 9
3.33 Verification ....................................................................................... Verifica ................................................................................................. 9
3.34 Verifier ................................................................................................ Verificatore ......................................................................................... 9

4 OBJECTIVES AND CONFORMANCE OBIETTIVI E CONFORMITÀ 9

5 SOFTWARE SAFETY INTEGRITY LIVELLI DI INTEGRITÀ DELLA SICUREZZA


LEVELS DEL SOFTWARE 10
5.1 Objective ........................................................................................... Obiettivi ............................................................................................ 10
5.2 Requirements .................................................................................. Requisiti ............................................................................................ 11

NORMA TECNICA
CEI EN 50128:2002-04
Pagina iv
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
6 PERSONNEL AND RESPONSIBILITIES PERSONALE E RESPONSABILITÀ 12
6.1 Objective ............................................................................................ Obiettivi ............................................................................................ 12
6.2 Requirements ................................................................................... Requisiti ............................................................................................. 12

7 LIFECYCLE ISSUES AND DOCUMENTATION RISULTATI E DOCUMENTAZIONE DEL CICLO DI VITA 14


7.1 Objectives .......................................................................................... Obiettivi ............................................................................................ 14
7.2 Requirements ................................................................................... Requisiti ............................................................................................. 14

8 SOFTWARE REQUIREMENTS SPECIFICATION SPECIFICA DEI REQUISITI DEL SOFTWARE 18


8.1 Objectives .......................................................................................... Obiettivi ............................................................................................ 18
8.2 Input documents ............................................................................ Documenti d’ingresso ................................................................ 18
8.3 Output documents ........................................................................ Documenti di uscita .................................................................... 18
8.4 Requirements ................................................................................... Requisiti ............................................................................................. 18

9 SOFTWARE ARCHITECTURE ARCHITETTURA DEL SOFTWARE 20


9.1 Objectives .......................................................................................... Obiettivi ............................................................................................ 20
9.2 Input documents ............................................................................ Documenti d’ingresso ................................................................ 20
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

9.3 Output documents ........................................................................ Documenti di uscita .................................................................... 20


9.4 Requirements ................................................................................... Requisiti ............................................................................................. 20

10 SOFTWARE DESIGN AND PROGETTAZIONE ED IMPLEMENTAZIONE


IMPLEMENTATION DEL SOFTWARE 22
10.1 Objectives .......................................................................................... Obiettivi ............................................................................................ 22
10.2 Input documents ............................................................................ Documenti d’ingresso ................................................................ 23
10.3 Output documents ........................................................................ Documenti di uscita .................................................................... 23
10.4 Requirements ................................................................................... Requisiti ............................................................................................. 23

11 SOFTWARE VERIFICATION AND TESTING VERIFICA E PROVA DEL SOFTWARE 26


11.1 Objective ............................................................................................ Obiettivi ............................................................................................ 26
11.2 Input documents ............................................................................ Documenti d’ingresso ................................................................ 26
11.3 Output documents ........................................................................ Documenti di uscita .................................................................... 26
11.4 Requirements ................................................................................... Requisiti ............................................................................................. 27

12 SOFTWARE/HARDWARE INTEGRATION INTEGRAZIONE SOFTWARE/HARDWARE 30


12.1 Objectives .......................................................................................... Obiettivi ............................................................................................ 30
12.2 Input documents ............................................................................ Documenti d’ingresso ................................................................ 30
12.3 Output documents ........................................................................ Documenti di uscita .................................................................... 30
12.4 Requirements ................................................................................... Requisiti ............................................................................................. 30

13 SOFTWARE VALIDATION VALIDAZIONE DEL SOFTWARE 32


13.1 Objective ............................................................................................ Obiettivi ............................................................................................ 32
13.2 Input documents ............................................................................ Documenti d’ingresso ................................................................ 32
13.3 Output documents ........................................................................ Documenti di uscita .................................................................... 32
13.4 Requirements ................................................................................... Requisiti ............................................................................................. 32

14 SOFTWARE ASSESSMENT VALUTAZIONE DEL SOFTWARE 34


14.1 Objective ............................................................................................ Obiettivi ............................................................................................ 34
14.2 Input documents ............................................................................ Documenti d’ingresso ................................................................ 34
14.3 Output documents ........................................................................ Documenti di uscita .................................................................... 34
14.4 Requirements ................................................................................... Requisiti ............................................................................................. 34

15 SOFTWARE QUALITY ASSURANCE ASSICURAZIONE DELLA QUALITÀ DEL SOFTWARE 35


15.1 Objectives .......................................................................................... Obiettivi ............................................................................................ 35
15.2 Input documents ............................................................................ Documenti d’ingresso ................................................................ 35
15.3 Output documents ........................................................................ Documenti di uscita .................................................................... 36

NORMA TECNICA
CEI EN 50128:2002-04
Pagina v
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
15.4 Requirements ................................................................................... Requisiti ............................................................................................. 36

16 SOFTWARE MAINTENANCE MANUTENZIONE DEL SOFTWARE 38


16.1 Objective ............................................................................................ Obiettivi ............................................................................................ 38
16.2 Input documents ............................................................................ Documenti d’ingresso ................................................................ 38
16.3 Output documents ........................................................................ Documenti di uscita .................................................................... 39
16.4 Requirements ................................................................................... Requisiti ............................................................................................. 39

17 SYSTEMS CONFIGURED BY SISTEMI CONFIGURATI CON DATI


APPLICATION DATA DELL’APPLICAZIONE 40
17.1 Objectives .......................................................................................... Obiettivi ............................................................................................ 40
17.2 Input documents ............................................................................ Documenti d’ingresso ................................................................ 41
17.3 Output documents ........................................................................ Documenti di uscita .................................................................... 41
17.4 Requirements ................................................................................... Requisiti ............................................................................................. 41

ANNEX/ALLEGATO
A CRITERIA FOR THE SELECTION OF TECHNIQUES AND CRITERI PER LA SCELTA DI TECNICHE E
MEASURES PROVVEDIMENTI 58
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

ANNEX/ALLEGATO
B BIBLIOGRAPHY OF TECHNIQUES BIBLIOGRAFIA DELLE TECNICHE 70

NORMA TECNICA
CEI EN 50128:2002-04
Pagina vi
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
FOREWORD PREFAZIONE
This European Standard was prepared by SC La Presente Norma Europea è stata preparata dal
9XA, Communication, signalling and processing SC 9XA, Communication, signalling and process-
systems, of Technical Committee CENELEC TC ing systems, del Comitato Tecnico CENELEC 9X,
9X, Electrical and electronic applications for Electrical and electronic applications for railways.
railways.
The text of the draft was submitted to the for- Il testo del progetto è stato sottoposto al voto for-
mal vote and was approved by CENELEC as male ed è stato approvato dal CENELEC come
EN 50128 on 2000/11/01. Norma Europea EN 50128 in data 01/11/2000.
The following dates were fixed: Sono state fissate le date seguenti:
 latest date by which the EN has to be imple-  data ultima entro la quale la EN deve essere
mented at national level by publication of recepita a livello nazionale mediante pubbli-
an identical national standard or by en- cazione di una Norma nazionale identica o
dorsement mediante adozione
(dop) 2001/11/01 (dop) 01/11/2001
 latest date by which the national standards  data ultima entro la quale le Norme nazio-
conflicting with the EN have to be with- nali contrastanti con la EN devono essere ri-
drawn tirate
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

(dow) 2003/11/01 (dow) 01/11/2003

This European Standard should be read in con- La presente Norma Europea dovrebbe essere letta
junction with EN 50126: “Railway applications - congiuntamente alla EN 50126: “Railway applica-
The specification and demonstration of Reliabil- tions - The specification and demonstration of Re-
ity, Availability, Maintainability and Safety liability, Availability, Maintainability and Safety
(RAMS)” and EN 50129: “Railway applications - (RAMS)” e alla EN 50129: “Railway applications -
Safety related electronic systems for signalling”. Safety related electronic systems for signalling”.

Annexes designated “normative” are part of the Gli Allegati indicati come “normativi” sono parte
body of the standard. integrante della Norma.
Annexes designated “informative” are given for Gli Allegati indicati come “informativi” sono dati
information only. solo per informazione.
In this standard, annex A is normative and an- Nella presente Norma, l’Allegato A è normativo
nex B is informative. e l’Allegato B è informativo.

NORMA TECNICA
CEI EN 50128:2002-04
Pagina vii
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

NORMA TECNICA
CEI EN 50128:2002-04
Pagina viii
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
INTRODUCTION INTRODUZIONE

This Standard is part of a group of related Stand- La presente Norma fa parte di un gruppo di Nor-
ards. The others are EN 50126 “Railway applica- me correlate. Le altre sono la EN 50126 “Applica-
tions - The specification and demonstration of zioni ferroviarie - La specificazione e la dimostra-
Reliability, Availability, Maintainability and Safety zione di Affidabilità, Disponibilità, Manutenibilità
(RAMS)” and EN 50129 “Railway applications - e Sicurezza (RAMS)” e la EN 50129: “Applicazioni
Safety related electronic systems for signalling”. ferroviarie - Sistemi elettronici in sicurezza per il
EN 50126 addresses system issues on the widest segnalamento”. La EN 50126 tratta i problemi di
scale, while EN 50129 addresses the approval sistema su più ampia scala, mentre la EN 50129
process for individual systems which may exist tratta i processi di approvazione di singoli sistemi
within the overall railway control and protection che possono essere presenti nell’intero sistema
system. This Standard concentrates on the meth- ferroviario di controllo e protezione. La presente
ods which need to be used in order to provide Norma si concentra sui metodi che è necessario
software which meets the demands for safety in- usare al fine di fornire software che soddisfi ai re-
tegrity which are placed upon it by these wider quisiti di integrità della sicurezza che sono deter-
considerations. minati da queste più ampie considerazioni.
This Standard owes much of its direction to earli- La presente Norma deve molti dei suoi orientamenti
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

er work done by Working Group 9 of IEC/TC 65. al lavoro iniziale compiuto dal WG 9 dell’IEC/TC 65.
The work of WG 9 resulted in a generic standard Dal lavoro del WG 9 è risultata una norma generica
for software for safety systems which is now part per il software dei sistemi in sicurezza che ora fa par-
of IEC 61508. A particular aspect of the work by te della IEC 61508. Un aspetto particolare del lavoro
WG 9 is its inclusion of Software Integrity Level del WG 9 è l’introduzione del Livello 0 di Integrità
0, which covers non-safety software, as well as del Software, che riguarda il software non in sicurez-
Software Integrity Levels 1 to 4, which cover za, e dei Livelli di Integrità del Software da 1 a 4, che
safety-related and safety-critical software. This riguardano il software con caratteristiche di sicurezza
Standard also covers all five Software Integrity e quello critico per la sicurezza. Anche la presente
Levels. Norma tratta tutti i cinque Livelli di Integrità del Sof-
tware.
Account has also been taken of the work of the Si è tenuto anche conto del lavoro dell’Institution
Institution of Railway Signal Engineers (the of Railway Signal Engineers (l’IRSE), in particolare
IRSE), in particular its Technical Report Number del suo Technical Report Number 1, che trattava
1, which addressed the same topic. lo stesso argomento.
The key concept of this European Norm is that of Il concetto chiave della presente Norma Europea
levels of software safety integrity. The more dan- è quello dei livelli di integrità della sicurezza del
gerous the consequences of a software failure, the software. Più pericolose saranno le conseguenze
higher the software safety integrity level will be. di un malfunzionamento del software, più elevato
sarà il livello di integrità del software.
This European Standard has identified tech- La presente Norma Europea ha identificato tecni-
niques and measures for 5 levels of software che e provvedimenti per i 5 livelli di integrità del-
safety integrity where 0 is the minimum level la sicurezza del software, dove 0 è il livello mini-
and 4 the highest level. Four of these levels, 1 mo e 4 il livello più elevato. Quattro di questi
to 4, refer to safety-related software, whilst level livelli, da 1 a 4, fanno riferimento al software in
0 refers to non safety-related software. This lev- sicurezza, mentre il livello 0 fa riferimento al sof-
el has been included as normative in order to tware non in sicurezza. Questo livello è stato in-
allow a smooth transition between software de- trodotto come normativo al fine di consentire una
velopments for non-safety related systems and transizione graduale tra gli sviluppi del software
those for safety-related systems. The required per sistemi non in sicurezza e quelli per i sistemi
techniques and measures for each software in sicurezza. Le tecniche e i provvedimenti per
safety integrity level and for the non safety-re- ciascun livello di integrità della sicurezza del sof-
lated level are shown in the tables. In this ver- tware e per il livello non di sicurezza sono mo-
sion, the required techniques for level 1 are the strati nelle tabelle. In questa versione, le tecniche
same as for level 2, and the required techniques richieste per il livello 1 sono le stesse del livello 2,
for level 3 are the same as for level 4. This Eu- e le tecniche richieste per il livello 3 sono le stes-
ropean Standard does not give guidance on se del livello 4. La presente Norma Europea non
which level of software integrity is appropriate fornisce una guida circa il livello di integrità del
for a given risk. This decision will depend upon software appropriato per un dato rischio. Questa
the many factors including the nature of the ap- decisione dipenderà da molti fattori fra cui la na-
plication, the extent to which other systems car- tura dell’applicazione, la misura con la quale altri

CEI EN 50128:2002-04 NORMA TECNICA


136 CEI EN 50128:2002-04
Pagina 1 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
ry out safety functions and social and economic sistemi adempiono funzioni di sicurezza e fattori
factors. sociali ed economici.
It is the function of EN 50126 and EN 50129 to È funzione della EN 50126 e della EN 50129 spe-
specify the safety functions allocated to soft- cificare le funzioni di sicurezza assegnate al sof-
ware. tware.
This European Standard specifies those meas- La presente Norma Europea specifica quei prov-
ures necessary to achieve these requirements. vedimenti necessari a conseguire questi requisiti.
The process is illustrated in Figure 1. Il processo è illustrato in Figura 1.

EN 50126 and EN 50129 require that a systemat- La EN 50126 e la EN 50129 richiedono che sia
ic approach be taken to: adottato un approccio sistematico per:
i) identifying hazards, risks and risk criteria; i) identificare pericoli, rischi e criteri di rischio;
ii) identifying the necessary risk reduction to ii) identificare la riduzione di rischio necessaria a
meet the risk criteria; soddisfare i criteri di rischio;
iii) defining an overall System Safety Require- iii) definire una Specifica dei Requisiti di Sicurez-
ments Specification for the safeguards neces- za del Sistema per le contromisure necessarie
sary to achieve the required risk reduction; a conseguire la riduzione di rischio richiesta;
iv) selecting a suitable system architecture; iv) scegliere un’adatta architettura di sistema;
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

v) planning, monitoring and controlling the v) pianificare, sorvegliare e controllare le attività


technical and managerial activities neces- tecniche e di gestione necessarie a trasforma-
sary to translate the System Safety Require- re la Specifica dei Requisiti di Sicurezza del
ments Specification into a Safety-Related Sistema in un Sistema in Sicurezza che abbia
System of a validated safety performance una prestazione di sicurezza (o integrità della
(or safety integrity). sicurezza) validata.

As decomposition of the specification into a de- Quando ha luogo una scomposizione della speci-
sign comprising safety-related systems and ficazione in un progetto che comprende sistemi e
components takes place, further allocation of componenti in sicurezza, viene eseguita un’ulte-
safety integrity levels is performed. Ultimately riore assegnazione dei livelli di integrità della si-
this leads to the required software safety integri- curezza. Alla fine ciò porta ai richiesti livelli di in-
ty levels. tegrità della sicurezza del software.
The current state-of-the-art is such that neither L’attuale stato dell’arte è tale che né l’applicazione
the application of quality assurance methods dei metodi di assicurazione della Qualità (i cosid-
(so-called fault avoiding measures) nor the ap- detti provvedimenti per evitare difetti [fault avoi-
plication of software fault tolerant approaches ding measures]) né l’applicazione di software con
can guarantee the absolute safety of the system. approcci tolleranti il difetto [fault tolerant] posso-
There is no known way to prove the absence of no garantire l’assoluta sicurezza del sistema. Non
faults in reasonably complex safety-related soft- vi è alcun modo noto di comprovare l’assenza di
ware, especially the absence of specification difetti in un software in sicurezza ragionevolmen-
and design faults. te complesso, specialmente l’assenza di difetti di
specificazione e di progettazione.
The principles applied in developing high integri- I principi applicati nello sviluppo di software ad ele-
ty software include, but are not restricted to: vata integrità comprendono, ma non sono limitati a:
 top-down design methods;  metodi di progettazione top-down;
 modularity;  modularità;
 verification of each phase of the develop-  verifica di ogni fase del ciclo di vita di svilup-
ment lifecycle; po;
 verified modules and module libraries;  moduli verificati e librerie di moduli;
 clear documentation;  documentazione chiara;
 auditable documents; and  documenti revisionabili; e
 validation testing.  prove di validazione.

These and related principles must be correctly Questi principi e quelli collegati devono essere ap-
applied. This standard specifies the level of as- plicati correttamente. La presente norma specifica il
surance required to demonstrate this at each livello di confidenza richiesto per dimostrarlo per
software safety integrity level. ogni livello di integrità della sicurezza del software.
After the System Safety Requirements Specifica- Dopo che è stata ottenuta o prodotta la Specifica
tion, which identifies all safety functions allocat- dei Requisiti di Sicurezza del Sistema, che identifi-
ed to software and determines the system safety ca tutte le funzioni di sicurezza attribuite al sof-
integrity level, has been obtained or produced, tware e che determina il livello di integrità della

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 2 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
the functional steps in the application of this sicurezza del sistema, i passi funzionali nell’appli-
European Standard are shown in Figure 2 and cazione della presente Norma Europea sono mo-
are as follows: strati nella Figura 2 e sono i seguenti:
i) define the Software Requirements Specifica- i) definire la Specifica dei Requisiti del Software
tion and in parallel consider the software e in parallelo considerare l’architettura sof-
architecture. the software architecture is tware. L’architettura software è dove viene
where the basic safety strategy is developed sviluppata la strategia di sicurezza di base per
for the software and the software safety in- il software ed il livello di integrità della sicu-
tegrity level (clauses 5, 8 and 9); rezza del software (art. 5, 8 e 9);
ii) design, develop and test the software ac- ii) progettare, sviluppare e provare il software
cording to the Software Quality Assurance secondo il Piano di Assicurazione della Quali-
Plan, software safety integrity level and the tà del Software, il livello di integrità della sicu-
software lifecycle (clause 10); rezza del software e il ciclo di vita del softwa-
re (art. 10);
iii) integrate the software on the target hard- iii) integrare il software nell’hardware cui è desti-
ware (clause 12); nato (art. 12);
iv) validate the software (clause 13); iv) validare il software (art. 13);
v) if software maintenance is required during v) se è richiesta la manutenzione del software
operational life then re-activate this Europe- durante la vita operativa va applicata nuova-
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

an Standard as appropriate (clause 16). mente la presente Norma Europea in modo


appropriato (art. 16).

A number of activities run across the software de- Numerose attività sono attivate durante lo svilup-
velopment. These include verification (clause 11), po del software. Esse comprendono la verifica
assessment (clause 14) and quality assurance (art. 11), la valutazione (art. 14) e l’assicurazione
(clause 15). qualità (art. 15).
Requirements are given for systems which are Vengono stabiliti requisiti per sistemi che sono
configured by application data (clause 17). configurati dai dati dell’applicazione (art. 17).
Requirements are also given for the competen- Vengono stabiliti anche requisiti per la competen-
cy of staff involved in software development za del gruppo di lavoro coinvolto nello sviluppo
(clause 6). del software (art. 6).
The standard does not mandate the use of a par- La norma non impone l’uso di un particolare ciclo
ticular software development lifecycle. However di vita di sviluppo del software. Tuttavia vengono
a recommended lifecycle and documentation set dati un ciclo di vita raccomandato e un insieme di
are given (clause 7 and Figures 3 and 4). documentazioni (art. 7 e Figure 3 e 4).
Tables have been formulated ranking various Sono state elaborate tabelle che classificano varie
techniques/measures against the 5 software tecniche/provvedimenti per i 5 livelli di integrità
safety integrity levels. The tables are in an- della sicurezza del software. Le tabelle sono
nex A. Cross-referenced to the tables is a bibli- nell’Allegato A. Vi è una bibliografia correlata con
ography giving a brief description of each tech- le tabelle che da una breve descrizione di ogni
nique/measure with references to further tecnica/provvedimento con riferimento ad ulterio-
sources of information. The bibliography is in ri fonti di informazione. La bibliografia è nell’Alle-
annex B. gato B.

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 3 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
1 SCOPE CAMPO D’APPLICAZIONE

1.1 This European Standard specifies procedures La presente Norma Europea specifica le procedure e
and technical requirements for the development i requisiti tecnici per lo sviluppo di sistemi elettroni-
of programmable electronic systems for use in ci a logica programmabile, utilizzati nelle applicazio-
railway control and protection applications. It is ni ferroviarie di controllo e protezione. Essa è utiliz-
aimed at use in any area where there are safety zata in qualsiasi settore dove vi sono implicazioni
implications. These may range from the very riguardanti la sicurezza. Queste possono variare da
critical, such as safety signalling to the non-criti- quelle molto critiche, come la sicurezza per il segna-
cal, such as management information systems. lamento, a quelle non critiche, come i sistemi per la
These systems may be implemented using dedi- gestione di informazioni. Questi sistemi possono es-
cated microprocessors, programmable logic sere implementati usando microprocessori dedicati,
controllers, multiprocessor distributed systems, controllori a logica programmata, sistemi distribuiti a
larger scale central processor systems or other multiprocessore, sistemi a processore centrale di di-
architectures. mensioni più ampie o altre architetture.

1.2 This European Standard is applicable exclusive- La presente Norma Europea è applicabile esclusi-
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

ly to software and the interaction between soft- vamente al software e all’interazione tra il softwa-
ware and the system of which it is part. re e il sistema del quale esso fa parte.

1.3 Software safety integrity levels above zero are Livelli di integrità della sicurezza del software su-
for use in systems in which the consequences periori allo 0 sono utilizzati in sistemi nei quali le
of failure could include loss of life. Economic or conseguenze di un mancato funzionamento po-
environmental considerations, however, may trebbero comportare la perdita di vite umane.
also justify the use of higher software safety in- Considerazioni economiche o ambientali posso-
tegrity levels. no, tuttavia, giustificare anche l’uso di livelli più
alti di integrità della sicurezza del software.

1.4 This European Standard applies to all software La presente Norma Europea si applica a tutto il
used in development and implementation of rail- software usato nello sviluppo ed nell’implementa-
way control and protection systems including: zione di sistemi ferroviari di controllo e protezio-
ne, compreso:
application programming; programmazione applicativa;
operating systems; sistemi operativi;
support tools; strumenti (tools) di supporto;
firmware. firmware.

Application programming comprises high level La programmazione applicativa comprende, pro-


programming, low level programming and spe- grammazione ad alto livello, programmazione a
cial purpose programming (for example: Pro- basso livello e programmazione per usi speciali
grammable Logic Controller ladder logic). (per esempio: Controllori a Logica programmabile
a logica ladder.

1.5 The use of standard, commercially available Nella presente Norma Europea viene anche defi-
software and tools is also addressed in this Eu- nito l’uso di software e di strumenti standard di-
ropean Standard. sponibili in commercio.

1.6 This European Standard also addresses the re- La presente Norma Europea definisce anche i re-
quirements for systems configured by applica- quisiti per i sistemi configurati mediante dati ap-
tion data. plicativi.

1.7 This European Standard is not intended to ad- La presente Norma Europea non intende definire ar-
dress commercial issues. These should be ad- gomenti commerciali. Questi dovrebbero essere trat-
dressed as an essential part of any contractual tati come una parte indispensabile di ogni accordo
agreement. All the clauses of this European contrattuale. Tutti gli articoli della presente Norma
Standard will need careful consideration in any Europea necessiteranno di attenta considerazione in
commercial situation. ogni situazione commerciale.

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 4 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
1.8 This European Standard is not intended to be Non è previsto che la presente Norma Europea
retrospective. It therefore applies primarily to sia retroattiva. Essa si applica quindi principal-
new developments and only applies in its en- mente a nuovi sviluppi e si applica nella sua inte-
tirety to existing systems if these are subjected rezza ai sistemi esistenti solo se questi sono sog-
to major modifications. For minor changes, only getti a modifiche importanti. Per modifiche
clause 16 applies. minori, si applica solo l’art.16.

2 NORMATIVE REFERENCES RIFERIMENTI NORMATIVI

This European Standard incorporates by dated La presente Norma Europea incorpora, tramite riferi-
or undated reference, provisions from other menti datati e non datati, indicazioni provenienti da
publications. These normative references are altre pubblicazioni. Questi riferimenti normativi
cited at the appropriate places in the text and sono citati, dove appropriato, nel testo, e le Pubbli-
the publications are listed hereafter. For dated cazioni sono elencate di seguito. Per i riferimenti da-
references, subsequent amendments to or revi- tati, le successive modifiche o revisioni di ognuna di
sions of any of these publications apply to this tali pubblicazioni si applicano alla presente Norma
European Standard only when incorporated in Europea solo quando incluse in essa da una modifi-
it by amendment or revision. For undated refer- ca o revisione. In caso di riferimenti non datati, si
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

ences the latest edition of the publication re- applica l’ultima edizione della Pubblicazione indica-
ferred to applies (including amendments). ta (comprese le modifiche).

Pubblicazione Titolo Norma CEI


Publication Title CEI Standard
EN 50126 Applicazioni ferroviarie, tranviarie, filotranviarie, metropolitane - La specifica- 9-58
zione e la dimostrazione di Affidabilità, Disponibilità, Manutenibilità e Sicu-
rezza (RAMS)
Railway applications - The specification and demonstration of Reliability, Availability,
Maintainability and Safety (RAMS)
EN 50129(1) Applicazioni ferroviarie, tranviarie, filoviarie e metropolitane - Sistemi elettro- 9-55
nici di sicurezza per il segnalamento
Railway applications - Safety related electronic systems for signalling
EN 50159-1 Applicazioni ferroviarie, tranviarie, filoviarie e metropolitane - Sistemi di tele- 9-66
comunicazione, segnalamento ed elaborazione
Parte 1: Comunicazioni di sicurezza in sistemi di trasmissione di tipo chiuso
Railway applications - Communication, signalling and processing systems
Part 1: Safety-related communication in closed transmission systems
EN 50159-2 Applicazioni ferroviarie, tranviarie, filoviarie e metropolitane - Sistemi di tele- 9-66/2
comunicazione, segnalamento ed elaborazione
Parte 2: Comunicazioni di sicurezza in sistemi di trasmissione di tipo aperto
Railway applications - Communication, signalling and processing systems
Part 2: Safety-related communication in open transmission systems
EN ISO 9001 Sistemi qualità – Modello di assicurazione qualità nel progetto/sviluppo, pro- —
duzione, installazione ed esercizio
Quality systems - Model for quality assurance in design/development, production,
installation and servicing
EN ISO 9000-3 Gestione della qualità e norme di assicurazione qualità – Parte 3: Linee guida —
per l’applicazione della ISO 9001:1994 allo sviluppo, fornitura, installazione e
manutenzione del software dei calcolatori
Quality management and quality assurance standards – Part 3: Guidelines for the
application of ISO 9001:1994 to the development, supply, installation and maintenance
of computer software
(1) In fase di progetto.
At draft stage

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 5 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
3 DEFINITIONS DEFINIZIONI

For the purposes of this European Standard, the Per gli scopi della presente Norma Europea, si ap-
following definitions apply. For terms not de- plicano le seguenti definizioni. Per i termini che
fined here, the following references should be qui non sono definiti, dovrebbero essere consul-
consulted in order of priority: tati, in ordine di priorità, i seguenti riferimenti:

EN ISO 8402 Gestione della qualità e assicurazione qualità – Vocabolario


Quality management and quality assurance – Vocabulary
IEC 60050-191 Capitolo 191 del Vocabolario Elettrotecnico Internazionale: Fidatezza e qualità del servizio
International Electrotechnical Vocabulary of Chapter 191: Dependability and quality of service
IEEE 610.12 IEEE glossario standard della terminologia dell’ingegneria del software
IEEE standard glossary of software engineering terminology
ISO/IEC 2382 Vocabolario della Tecnologia dell’Informazione
Information Technology Vocabulary
ISO/IEC 9126 Tecnologia dell’Informazione – Valutazione di Prodotto del Software – Caratteristiche di
qualità e linee guida per il loro uso
Information Technology – Software Product Evaluation – Quality characteristics and guidelines for
their use
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

3.1 Assessment Valutazione


Process of analysis to determine whether the De- Processo di analisi per determinare se l’Autorità
sign Authority and the Validator have achieved a per il Progetto e il Validatore hanno ottenuto un
product that meets the specified requirements prodotto che rispetta i requisiti specificati e formu-
and to form a judgement as to whether the prod- lare un giudizio se il prodotto è adatto allo scopo
uct is fit for its intended purpose. stabilito.

3.2 Assessor Valutatore


Person or agent appointed to carry out the as- Persona o agente designato per eseguire la valu-
sessment. tazione.

3.3 Availability Disponibilità


Ability of a product to be in a state to perform a La capacità di un prodotto di essere nella condi-
required function under given conditions at a zione di eseguire una funzione richiesta sotto de-
given instant of time or over a given time inter- terminate condizioni in un dato istante o in un
val, assuming the required external resources dato intervallo di tempo, assumendo che siano
are provided. fornite le risorse esterne richieste.

3.4 Commercial off-the-shelf (COTS) software Software disponibile commercialmente (COTS)


Software defined by market-driven need, com- Software definito da necessità imposte dal merca-
mercially available and whose fitness for pur- to, disponibile commercialmente e la cui idoneità
pose has been demonstrated by a broad spec- allo scopo è stata dimostrata da un ampio spettro
trum of commercial users. di utilizzatori commerciali.

3.5 Design authority Autorità per il progetto


Body responsible for the formulation of a de- Ente responsabile per la formulazione di una so-
sign solution to fulfil the specified requirements luzione progettuale che soddisfi i requisiti specifi-
and for overseeing the subsequent develop- cati e per sovrintendere i conseguenti sviluppi e
ment and setting to work of a system in its in- messa in opera di un sistema nel suo ambiente
tended environment. previsto.

3.6 Designer Progettista


One or more persons assigned by the Design Una o più persone designate dall’Autorità per il
Authority to analyse and transform specified re- Progetto ad analizzare e trasformare i requisiti
quirements into acceptable design solutions specificati in soluzioni progettuali accettabili che
which have the required safety integrity. abbiano l’integrità della sicurezza richiesta.

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 6 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
3.7 Element Elemento
Part of a product that has been determined to Parte di un prodotto che è stato stabilito essere
be a basic unit or building block. An element un’unità di base o un blocco costruttivo. Un ele-
may be simple or complex. mento può essere semplice o complesso.

3.8 Error Errore


Deviation from the intended design which Deviazione dal progetto previsto che potrebbe
could result in unintended system behaviour or determinare un comportamento non previsto del
failure. sistema od un mancato funzionamento.

3.9 Failure Mancato funzionamento


Deviation from the specified performance of a Deviazione di un sistema dalla prestazione speci-
system. A failure is the consequence of a fault ficata. Un mancato funzionamento è la conse-
or error in a system. guenza di un guasto o di un errore in un sistema.

3.10 Fault Guasto


Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

Abnormal condition that could lead to an error condizione anormale che potrebbe portare ad un
or a failure in a system. A fault can be random errore o ad un mancato funzionamento in un siste-
or systematic. ma. Un guasto può essere casuale o sistematico.

3.11 Fault avoidance Tecnica per evitare i guasti


Use of design techniques which aim to avoid Utilizzo di tecniche di progetto che mirano ad evi-
the introduction of faults during the design and tare l’introduzione di guasti durante il progetto e
construction of the system. la costruzione del sistema.

3.12 Fault tolerance Tolleranza ai guasti


Built-in capability of a system to provide contin- Capacità intrinseca di un sistema di fornire presta-
ued correct provision of service as specified, in zione continua e corretta di servizio come specifi-
the presence of a limited number of hardware cato, in presenza di un limitato numero di guasti
or software faults. hardware o software.

3.13 Firmware Firmware


Ordered set of instructions and associated data Serie ordinata di istruzioni e di dati associati memo-
stored in a way that is functionally independent rizzati in modo funzionalmente indipendente dalla
of main storage, usually in a ROM. memoria principale, comunemente in una ROM.

3.14 Generic software Software generico


Generic software is software which can be used Il software generico è un software che può essere
for a variety of installations purely by the provi- usato per varie installazioni, fornendo unicamente
sion of application-specific data. i dati per la specifica applicazione.

3.15 Implementer Implementatore


One or more persons assigned by the Design Una o più persone designate dall’Autorità per il Pro-
Authority to transform specified designs into getto a trasformare progetti specifici nella loro rea-
their physical realisation. lizzazione fisica.

3.16 Product Prodotto


Collection of elements, interconnected to form Insieme di elementi, interconnessi per formare un
a system, sub-system or item of equipment, in a sistema, sottosistema o elemento di una apparec-
manner which meets the specified require- chiatura, tale da soddisfare i requisiti specificati.
ments. In this European Standard, a product Nella presente Norma Europea, un prodotto può
may be considered to consist entirely of ele- consistere interamente di elementi di software o
ments of software or documentation. di documentazione.

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 7 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
3.17 Programmable logic controller (PLC) Controllore a logica programmata (PLC)
Solid-state control system which has a user pro- Sistema di comando a stato solido che ha una me-
grammable memory for storage of instructions moria programmabile dall’utente per la memoriz-
to implement specific functions. zazione di istruzioni che implementano funzioni
specifiche.

3.18 Reliability Affidabilità


Ability of an item to perform a required func- Capacità di un’elemento di eseguire una funzione
tion under given conditions for a given period richiesta in condizioni stabilite per un dato perio-
of time. do di tempo.

3.19 Requirements traceability Tracciabilità dei requisiti


Objective of requirements traceability is to en- L’obiettivo della tracciabilità dei requisiti è quello
sure that all requirements can be shown to have di assicurare che si possa dimostrare che sono
been properly met. stati propriamente soddisfatti tutti i requisiti.

3.20 Risk Rischio


Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

Combination of the frequency, or probability, Combinazione della frequenza, o probabilità, e


and the consequence of a specified hazardous della conseguenza di un evento pericoloso speci-
event. ficato.

3.21 Safety Sicurezza


Freedom from unacceptable levels of risk. Libertà da un inaccettabile livello di rischio.

3.22 Safety authority Autorità per la sicurezza


Body responsible for certifying that the safe- Ente responsabile a certificare che il sistema di si-
ty-related system is fit for service and complies curezza è adatto per il servizio e si conforma con i
with relevant statutory and regulatory safety re- pertinenti requisiti di sicurezza statuti e regolamen-
quirements. tati.

3.23 Safety-related software Software in sicurezza


Software which carries responsibility for safety. Software che comporta responsabilità per la sicu-
rezza.

3.24 Software Software


Intellectual creation comprising the programs, Creazione intellettuale comprendente programmi,
procedures, rules and any associated documen- procedure, regole ed ogni documentazione asso-
tation pertaining to the operation of a system. ciata pertinente al funzionamento di un sistema.
Note/Nota Software is independent of the media used for transport. Il software è indipendente dal mezzo di comunicazione usato
per la trasmissione.

3.25 Software life-cycle Ciclo di vita del software


Activities occurring during a period of time that Attività che si verificano durante il periodo di tem-
starts when software is conceived and ends po che inizia quando il software è concepito e fini-
when the software is no longer available for sce quando il software non è più disponibile per
use. The software lifecycle typically includes a l’uso. Il ciclo di vita del software comprende tipica-
requirements phase, development phase, test mente una fase dei requisiti, una fase di sviluppo,
phase, integration phase, installation phase and una fase di prova, una fase di integrazione, una
a maintenance phase. fase di installazione e una fase di manutenzione.

3.26 Software maintainability Manutenibilità del software


Capability of a system to be modified to correct Attitudine di un sistema di essere modificato per
faults, improve performance or other attributes, correggere guasti, migliorare prestazioni o altri at-
or adapt it to a different environment. tributi, o adattarlo ad un diverso ambiente.

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 8 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
3.27 Software maintenance Manutenzione del software
Action, or set of actions, carried out on software Azione, o serie di azioni, svolte sul software dopo
after its acceptance by the final user. The aim is la sua accettazione da parte dell’utente finale. Lo
to improve, increase and/or correct its function- scopo è quello di migliorare, aumentare, e/o cor-
ality. reggere la sua funzionalità.

3.28 Software safety integrity level Livello di integrità della sicurezza del software
Classification number which determines the Numero di classificazione che determina le tecni-
techniques and measures that have to be ap- che e i provvedimenti che devono essere applica-
plied in order to reduce residual software faults ti al fine di ridurre i guasti residui del software ad
to an appropriate level. un livello opportuno.

3.29 System safety integrity level Livello di integrità della sicurezza del sistema
Number which indicates the required degree of Numero che indica il grado di confidenza richie-
confidence that a system will meet its specified sto che un sistema soddisferà le sue specificate
safety features. caratteristiche di sicurezza.
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

3.30 Traceability Tracciabilità


Degree to which a relationship can be estab- Parametro con il quale può essere stabilita una re-
lished between two or more products of a de- lazione tra due o più prodotti di un processo di
velopment process, especially those having a sviluppo, specialmente quelli che hanno tra loro
predecessor/successor or master/subordinate un rapporto precedente/successivo o principa-
relationship to one another. le/subordinato.

3.31 Validation Validazione


Activity of demonstration, by analysis and test, Attività di dimostrazione, attraverso analisi e pro-
that the product meets, in all respects, its speci- ve, che il prodotto soddisfa, in tutti gli aspetti, i
fied requirements. suoi requisiti specificati.

3.32 Validator Validatore


Person or agent appointed to carry out valida- Persona o agente incaricato di svolgere la valida-
tion. zione.

3.33 Verification Verifica


Activity of determination, by analysis and test, Attività che determina, attraverso analisi e prove,
that the output of each phase of the life-cycle che l’uscita di ogni fase del ciclo di vita soddisfa i
fulfils the requirements of the previous phase. requisiti della fase precedente.

3.34 Verifier Verificatore


Person or agent appointed to carry out verification. Persona o agente incaricato di svolgere la verifica.

4 OBJECTIVES AND CONFORMANCE OBIETTIVI E CONFORMITÀ

4.1 In each of the following clauses, the objectives In ognuno dei seguenti articoli sono dettagliati gli
and requirements of the clause are detailed. obiettivi e i requisiti del articolo.

4.2 To conform to this European Standard it shall Per essere conformi alla presente Norma Europea
be shown that each of the requirements have deve essere dimostrato che è stato soddisfatto
been satisfied to the software safety integrity ogni requisito relativo al livello definito per l’inte-
level defined and therefore the clause objective grità della sicurezza del software e che pertanto
has been met. l’obiettivo del articolo è stato soddisfatto.

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 9 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
4.3 Where a requirement is qualified by the words Ove un requisito è qualificato dalle parole “Nella
“To the extent required by the software safety misura in cui è richiesta dal livello di integrità del-
integrity level”, this indicates that a range of la sicurezza del software”, questo indica che può
techniques and measures can be used to satisfy essere usata una gamma di tecniche e provvedi-
that requirement. menti per soddisfare tale requisito.

4.4 Where 4.3 applies the tables detailed in this Eu- Quando si applica l’art. 4.3 le tabelle dettagliate
ropean Standard should be used to assist in the nella presente Norma Europea dovrebbero essere
selection of techniques and measures appropri- usate come ausilio nella scelta di tecniche e prov-
ate to the software safety integrity level. vedimenti adatti al livello di integrità della sicu-
rezza del software.

4.5 If a technique or measure is ranked as highly Se una tecnica o provvedimento è classificato come
recommended (HR) in the tables then the ra- altamente raccomandato (HR) nelle tabelle allora il
tionale for not using that technique should be motivo per cui non è stata usata tale tecnica dovreb-
detailed and recorded either in the Software be essere dettagliato e riportato nel Piano di Assicu-
Quality Assurance Plan or in another document razione della Qualità del Software o in altro docu-
referenced by the Software Quality Assurance mento al quale si fa riferimento nel Piano di
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

Plan. This is not necessary if an approved com- Assicurazione della Qualità del Software. Questo non
bination of techniques given in the correspond- è necessario se è usata una combinazione approvata
ing table is used. di tecniche definita nella tabella corrispondente.

4.6 If a technique or measure is proposed to be Se viene proposto di usare una tecnica o provve-
used that is not contained in the tables then its dimento che non è contenuto nelle tabelle allora
effectiveness and suitability in meeting the par- la sua efficacia e idoneità a soddisfare il particola-
ticular requirement and overall objective of the re requisito e l’obiettivo generale del articolo
clause shall be justified and recorded in either deve essere giustificata e registrata nel Piano di
the Software Quality Assurance Plan or in an- Assicurazione della Qualità del Software o in altro
other document referenced by the Software documento richiamato dal Piano di Assicurazione
Quality Assurance Plan. della Qualità del Software.

4.7 Compliance with the requirements of a particu- La conformità con i requisiti di una particolare arti-
lar clause and their respective techniques and colo e con le corrispondenti tecniche e provvedi-
measures detailed in the tables shall be as- menti definite nelle tabelle devono essere valutate
sessed by the inspection of documents required tramite l’ispezione dei documenti richiesti dalla
by this standard, other objective evidence, au- presente norma, altre evidenze oggettive, eseguen-
diting and the witnessing of tests. do verifiche ispettive e assistendo alle prove.

4.8 This European Standard requires the use of a La presente Norma Europea richiede l’uso di un in-
package of techniques and their correct applica- sieme di tecniche e la loro corretta applicazione.
tion. These techniques are required from the ta- Queste tecniche sono richieste dalle tabelle e det-
bles and detailed in the bibliography. tagliate nella bibliografia.

5 SOFTWARE SAFETY INTEGRITY LEVELS LIVELLI DI INTEGRITÀ DELLA SICUREZZA DEL


SOFTWARE

5.1 Objective Obiettivi


To describe the assignment of software safety Descrivere l’assegnazione dei livelli di integrità
integrity levels to the software. della sicurezza del software.

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 10 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
5.2 Requirements Requisiti

5.2.1 There shall be produced, in accordance with Devono essere prodotti, in accordo con la
EN 50126 and EN 50129: EN 50126 e la EN 50129:
 System Requirements Specification;  Specifica dei Requisiti di Sistema;
 System Safety Requirements Specification;  Specifica dei Requisiti di Sicurezza del Sistema;
 System Architecture Description;  Descrizione dell’Architettura del Sistema;
 System Safety Plan;  Piano di Sicurezza del Sistema;

which include: che comprendono:


 safety functions;  funzioni di sicurezza;
 configuration or architecture of the system;  configurazione o architettura del sistema;
 hardware reliability requirements;  requisiti di affidabilità dell’hardware;
 safety integrity requirements.  requisiti di integrità della sicurezza.

The software safety integrity level shall be spec- Il livello di integrità della sicurezza del software
ified through following the general process for deve essere specificato seguendo completamente il
obtaining a safety integrity level identified in processo generale identificato nella in EN 50126,
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

EN 50126. per ottenere un livello di integrità della sicurezza.

5.2.2 The required software safety integrity level shall Il livello di integrità della sicurezza del software ri-
be decided on the basis of the level of risk asso- chiesto deve essere deciso sulla base del livello di
ciated with the use of the software in the sys- rischio associato all’uso del software nel sistema e
tem and the system safety integrity level. del livello di integrità della sicurezza del sistema.

5.2.3 Without further precautions, the software safety Senza ulteriori precauzioni, il livello di integrità della
integrity level shall be, as a minimum, identical sicurezza del software deve essere, come minimo,
to the system safety integrity level. However, if identico al livello di integrità della sicurezza del si-
mechanisms exist to prevent the failure of a stema. Tuttavia, se esiste un meccanismo che per
software module from causing the system to go impedire il mancato funzionamento di un modulo
to an unsafe state, the software safety integrity software provochi il passaggio ad uno stato non si-
level of the module may be reduced. curo del sistema, il livello di integrità della sicurezza
del software del modulo può essere ridotto.

5.2.4 Risks which shall be taken into account are I rischi di cui si deve tenere conto sono quelli as-
those associated with the following hazard con- sociati alle seguenti conseguenze pericolose:
sequences:
 loss of human life or lives;  perdita della vita o di vite umane;
 injuries to or illness of persons;  ferite o malattie per le persone;
 environmental pollution; and  inquinamento ambientale; e
 loss of or damage to property.  perdita o danneggiamento di beni.

5.2.5 Risk may be quantified but it is not possible to Il rischio può essere quantificato, ma non è possibi-
specify the software safety integrity in the same le specificare l’integrità della sicurezza del software
manner. Therefore for this European Standard allo stesso modo. Pertanto per la presente Norma
the software safety integrity shall be specified as Europea l’integrità della sicurezza del software deve
one of the following five levels: essere specificata con uno dei seguenti 5 livelli:

Livello di integrità della Descrizione dell’integrità della


sicurezza del software sicurezza del software
Software safety integrity level Description of software safety integrity
Molto Alta
4
Very High
Alta
3
High
Media
2
Medium
Bassa
1
Low
Non in sicurezza
0
Non safety-related

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 11 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
5.2.6 The software safety integrity level shall be spec- Il livello di integrità della sicurezza del software
ified in the Software Requirements Specification deve essere specificato nella Specifica dei Requisiti
(clause 8). If different software components del Software (art. 8). Se diversi componenti del sof-
have different software safety integrity levels, tware hanno diversi livelli di integrità della sicurez-
these shall be specified in the Software Archi- za, questi devono essere specificati nella Specifica
tecture Specification (clause 9). dell’Architettura del Software (art. 9).

6 PERSONNEL AND RESPONSIBILITIES PERSONALE E RESPONSABILITÀ

6.1 Objective Obiettivi


To ensure that all personnel who have respon- Assicurare che tutto il personale responsabile del
sibilities for the software are competent to dis- software abbia la competenza per assumere que-
charge those responsibilities. ste responsabilità.

6.2 Requirements Requisiti


Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

6.2.1 As a minimum, the supplier and/or developer Il fornitore e/o lo sviluppatore ed il cliente, devo-
and the customer shall implement the relevant no come minimo implementare le parti della
parts of EN ISO 9001, in accordance with the EN ISO 9001 pertinenti, in accordo con le linee
guidelines contained in EN ISO 9000-3. guida contenute nella EN ISO 9000-3.

6.2.2 Except at software safety integrity level zero, Salvo che per il livello zero di integrità della sicurez-
the safety process shall be implemented under za del software, il processo di sicurezza deve essere
the control of an appropriate safety organisation implementato sotto il controllo di una idonea orga-
which is compliant with the “Safety Organisa- nizzazione per la sicurezza che sia conforme al pa-
tion” sub-clause in the “Evidence of Safety Man- ragrafo “Organizzazione per la Sicurezza” nel artico-
agement” clause of EN 50129. lo “Evidenza della Gestione della Sicurezza” della
EN 50129.

6.2.3 All personnel involved in all the phases of the Tutto il personale coinvolto in tutte le fasi del Ci-
Software Lifecycle, including management activ- clo di Vita del Software, comprese le attività di ge-
ities, shall have the appropriate training, experi- stione, deve avere l’adeguata istruzione, compe-
ence and qualifications. tenza e qualifica.

6.2.4 It is highly recommended that the training, expe- È altamente raccomandato che l’addestramento,
rience and qualifications of all personnel in- l’esperienza e le qualificazioni di tutto il personale
volved in all the phases of the Software Lifecycle, coinvolto in tutte le fasi del Ciclo di Vita del Sof-
including management activities, be justified with tware, comprese le attività di gestione, siano mo-
respect to the particular application, except at tivate con riferimento alla specifica applicazione,
software safety integrity level zero. fatta eccezione per il livello zero di integrità della
sicurezza del software.

6.2.5 The justification contained in 6.2.4 shall be re- La motivazione prevista in 6.2.4 deve essere ripor-
corded in the Software Quality Assurance Plan, tata nel Piano di Assicurazione della Qualità del
and shall include evidence of competency in Software, e deve contenere, in modo adeguato,
the following areas, as appropriate: l’evidenza della competenza nelle seguenti aree:
i) engineering appropriate to the application i) ingegneria per il settore di applicazione;
area;
ii) software engineering; ii) ingegneria del software;
iii) computer-systems engineering; iii) ingegneria dei sistemi computerizzati;
iv) safety engineering; iv) ingegneria della sicurezza;
v) legal and regulatory framework. v) contesto legislativo e regolamentare.

6.2.6 An independent assessor for the software shall Deve essere nominato un valutatore indipendente
be appointed. See also 6.2.10 and 14.4.1. per il software. Vedere anche 6.2.10 e 14.4.1.

6.2.7 The assessor shall be given authority to perform Al valutatore deve essere data l’autorità per ese-
the assessment of the software. guire la valutazione del software.

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 12 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
6.2.8 Throughout the Software Lifecycle, the parties Per tutto il Ciclo di Vita del Software, le parti coin-
involved shall be independent, to the extent re- volte devono essere indipendenti nella misura ri-
quired by the software safety integrity level, in chiesta per il livello di integrità della sicurezza del
accordance with Figure 5, which shall be inter- software, in accordo con la Fig. 5, che deve esse-
preted as follows. re interpretata come segue.
At all software safety integrity levels, the Asses- Per tutti i livelli di integrità della sicurezza del softwa-
sor shall be approved by the Safety Authority re, il Valutatore deve essere riconosciuto dalla Autori-
and independent from the supplier except in tà per la Sicurezza ed essere indipendente dal forni-
the circumstances defined in 6.2.10. tore salvo che nelle circostanze definite in 6.2.10.
The Designer/Implementer, Verifier and Valida- Il Progettista/implementatore, il Verificatore e il Va-
tor can all belong to the same company but the lidatore possono appartenere tutti alla medesima
following rules for minimum independence società, ma per ottenere un minimo di indipenden-
shall be complied with: za devono essere rispettate le seguenti regole:
At software safety integrity level 0: Per il livello 0 di integrità della sicurezza del software:
There are no constraints; the Designer/Imple- Non vi sono restrizioni; il Progettista/Imple-
menter, Verifier and Validator can all be the mentatore, il Verificatore e il Validatore posso-
same person. no essere tutti la medesima persona.
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

At software safety integrity level 1 & 2: Per il livello 1 e 2 di integrità della sicurezza del sof-
tware:
The Verifier and Validator can be the same Il Verificatore e il Validatore possono essere la me-
person but they shall not be the Designer/Im- desima persona, ma non devono essere il Progetti-
plementer. However, the Designer/Imple- sta/Implementatore. Tuttavia, il Progettista/Imple-
menter, Verifier and Validator can all report mentatore, il Verificatore e il Validatore possono
through the Project Manager. tutti relazionare attraverso il Project Manager.

At software safety integrity level 3 & 4 there are Per il livello 3 e 4 di integrità della sicurezza del
two permissible arrangements: software vi sono due soluzioni ammesse:
a) The Verifier and Validator can be the same a) Il Verificatore ed il Validatore possono essere la
person but they shall not also be the Design- medesima persona, ma non devono anche esse-
er/Implementer. In addition, the Verifier and re il Progettista/Implementatore. Inoltre, il Verifi-
Validator shall not all report through the catore e il Validatore non devono relazionare at-
Project Manager as the Designer/Implementer traverso il Project Manager, come deve fare il
does and they shall have the authority to pre- Progettista/Implementatore, e devono avere
vent the release of the product. l’autorità per impedire il rilascio del prodotto.
b) The Designer/Implementer, Verifier and b) Il Progettista/Implementatore, il Verificatore e
Validator must all be separate persons. The il Validatore devono essere persone distinte. Il
Designer/Implementer and Verifier can re- Progettista/Implementatore e il Verificatore
port through the Project Manager, whereas possono relazionare attraverso il Project Ma-
the Validator shall not and the Validator nager, mentre il Validatore non deve ed il Va-
shall have the authority to prevent the re- lidatore deve avere l’autorità per impedire il
lease of the product. rilascio del prodotto.

6.2.9 The parties responsible for the various clauses Le parti responsabili per le varie articoli sono le
are as follows: seguenti:
Specifica del Software (art. 8) Progettista
Software Requirements Specification (clause 8) Designer
Specifica di Prova dei Requisiti del Software (art. 8) Validatore
Software Requirements Test Specification (clause 8) Validator
Architettura del Software (art. 9) Progettista
Software Architecture (clause 9) Designer
Progetto e Sviluppo del Software (art. 10) Progettista
Software Design and Development (clause 10) Designer
Verifica e Prova del Software (art. 11) Verificatore
Software Verification and Testing (clause 11) Verifier
Integrazione Software/Hardware (art. 12) Progettista
Software/Hardware Integration (clause 12) Designer
Validazione del Software (art. 13) Validatore
Software Validation (clause 13) Validator
Valutazione del Software (art. 14) Valutatore
Software Assessment (clause 14) Assessor

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 13 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
6.2.10 At the discretion of the Safety Authority, the As- A discrezione dell’Autorità per la Sicurezza, il Va-
sessor may be part of the supplier’s organisation lutatore può far parte dell’organizzazione del for-
or of the customer’s organisation but, in such nitore, o dell’organizzazione del cliente, ma in
cases, the Assessor shall tale caso, il Valutatore deve
 be authorised by the Safety Authority;  essere autorizzato dall’Autorità per la Sicurezza;
 be totally independent from the project  essere totalmente indipendente dal gruppo di
team; progetto;
 report directly to the Safety Authority.  relazionare direttamente alla Autorità per la
Sicurezza.

7 LIFECYCLE ISSUES AND DOCUMENTATION RISULTATI E DOCUMENTAZIONE DEL CICLO DI


VITA

7.1 Objectives Obiettivi

7.1.1 To structure the development of the software Strutturare lo sviluppo del software in fasi ed atti-
into defined phases and activities. vità definite.
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

7.1.2 To record all information pertinent to the soft- Registrare tutte le informazioni riguardanti il sof-
ware throughout the lifecycle of the software. tware nel corso del ciclo di vita del software.

7.2 Requirements Requisiti

7.2.1 A lifecycle model for the development of soft- Per lo sviluppo del software deve essere scelto un
ware shall be selected. It shall be detailed in the modello di ciclo di vita. Esso deve essere definito
Software Quality Assurance Plan in accordance nel Piano di Assicurazione della Qualità del Sof-
with clause 15 of this European Standard. For tware in accordo con l’art. 15 della presente Nor-
example, two lifecycle models are shown in ma Europea. Due modelli di ciclo di vita sono
Figures 3 and 4. mostrati come esempio, nelle Figure 3 e 4.

7.2.2 Quality Assurance procedures shall run in paral- Le procedure di Assicurazione Qualità devono
lel with lifecycle activities and use the same ter- svolgersi in parallelo con le attività del ciclo di
minology. vita ed usare la medesima terminologia.

7.2.3 All activities to be performed during a phase Tutte le attività che devono essere eseguite durante
shall be defined prior to the phase commencing. una fase devono essere definite prima dell’inizio
Each phase of the software lifecycle shall be di- della fase. Ogni fase del ciclo di vita del software
vided into elementary tasks with a well defined deve essere divisa in compiti elementari con ingres-
input, output and activity for each of them. si, uscite ed attività ben definite per ognuna di esse.

7.2.4 The Software Quality Assurance Plan shall de- Il Piano di Assicurazione della Qualità del Softwa-
scribe which verification steps and reports are re deve descrivere quali passi di verifica e quali
required. rapporti sono richiesti.

7.2.5 All documents shall be structured to allow contin- Tutti i documenti devono essere strutturati per
ued expansion in parallel with the design process. consentire uno sviluppo continuo in parallelo con
il processo di progettazione.

7.2.6 Traceability of documents shall be provided for La tracciabilità dei documenti deve essere prevista in
by each document having a unique reference modo che ogni documento abbia un unico numero
number and a defined and documented rela- di riferimento ed una relazione definita e documen-
tionship with other documents. Each term, ac- tata con gli altri documenti. Ogni termine, acronimo
ronym or abbreviation shall have the same o abbreviazione deve avere lo stesso significato in
meaning in every document. If, for historical ogni documento. Se, per motivi storici, questo non è
reasons, this is not possible, the different mean- possibile, devono essere elencati i diversi significati
ings shall be listed and the references given. e devono essere dati i riferimenti.
In addition, each document except documents Inoltre, ogni documento, eccetto i documenti per
for COTS software (see 9.4.5) or previously de- il software COTS (vedere 9.4.5) o per il software

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 14 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
veloped software (see 9.4.6) shall be written ac- sviluppato in precedenza (vedere 9.4.6) deve es-
cording to the following rules: sere scritto secondo le seguenti regole:
a) it shall contain or implement all applicable a) deve contenere o implementare tutte le con-
conditions and requirements of the prede- dizioni ed i requisiti applicabili del documen-
cessor document with which it has a hierar- to predecessore con il quale ha una relazione
chical relationship; gerarchica;
b) it shall not contradict the predecessor docu- b) non deve contraddire il documento predeces-
ment; sore;
c) each term, acronym or abbreviation shall c) ogni termine, acronimo o abbreviazione deve
have the same meaning in every document; avere lo stesso significato in ogni documento;
d) each item or concept shall be referred to by d) ogni elemento (item) o concetto deve essere
the same name or description in every doc- referenziato con lo stesso nome o descrizione
ument. in ogni documento.

7.2.7 The contents of all documents shall be recorded I contenuti di tutti i documenti devono essere ri-
in a form appropriate for manipulation, portati in forma adatta per manipolazioni, elabo-
processing and storage. razioni e memorizzazzioni.

7.2.8 To the extent required by the software safety in- Nella misura in cui è richiesto dal livello di inte-
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

tegrity level, the documents listed in the Docu- grità della sicurezza del software, devono essere
ments Cross Reference Table (see below) shall prodotti i documenti elencati nella Tabella dei Ri-
be produced. ferimenti Incrociati dei Documenti (vedere sotto).

7.2.9 Depending upon the size, complexity and life- In relazione alla dimensione, complessità e ciclo
cycle of the software being developed, the di vita del software che deve essere sviluppato,
number of separate documents required to be varierà il numero di documenti diversi che è ri-
produced will vary. Some documents may be chiesto siano prodotti. Alcuni documenti posso-
combined (providing there is no loss of the re- no essere uniti (purché non ci sia perdita dei ri-
quired detail in the process). For large projects chiesti dettagli nel processo). Per grandi progetti
it may be necessary to sub-divide the documen- può essere necessario suddividere la documen-
tation listed (in a hierarchical manner) into a tazione elencata (in modo gerarchico) in un cer-
number of more manageable child documents. to numero di documenti discendenti più maneg-
Documents which have been produced by in- gevoli. Documenti che sono stati prodotti da
dependent teams or entities shall not be com- entità o gruppi di lavoro indipendenti non devo-
bined into a single document. no essere combinati in un unico documento.

7.2.10 The relationship between the various documents La relazione tra i vari documenti identificati
identified in clause 7 can also be defined by us- nell’art. 7 può essere definita anche usando una
ing a DCRT (a Document Cross Reference Ta- DCRT (una Tabella dei Riferimenti Incrociati dei
ble). For each document listed in the “Docu- Documenti). Per ogni documento elencato nella co-
ments” column, the phase and clause associated lonna “Documenti”, la fase e l’articolo associati con
with its creation can be found by reading hori- la sua creazione possono essere trovati leggendo
zontally and vertically from the cell containing orizzontalmente e verticalmente dalla cella conte-
the symbol “ ”. The phases in which it is used nente il simbolo “ ”. Le fasi nelle quali esso viene
can be found by reading vertically from the cells usato possono essere trovate leggendo verticalmen-
marked with the symbol “ ♦ ”. The clause or oth- te dalle celle segnate con il simbolo “ ♦ “. L’articolo
er reference to the definition of the document o altro riferimento riguardante la definizione del
can be found in the “Where defined” column. documento possono essere trovati nella colonna
Where a clause is given, the following clauses “Dove definito”. Dove viene indicato un articolo,
should also be checked as they may contain fur- devono essere verificati anche gli articoli che se-
ther information. It should be noted that the ref- guono poiché essi possono contenere ulteriori in-
erence for the Software Configuration Manage- formazioni. Da notare che il riferimento per il Piano
ment Plan is shown in brackets because that di Gestione della Configurazione del Software è ri-
clause simply references EN ISO 9001. portato tra parentesi perché questo articolo cita
solo la EN ISO 9001.

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 15 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
DOCUMENTS CROSS-REFERENCE TABLE

clause 8 9 10 11 12 13 14 15 16
title SRS SA SDD SVer S/H I SVal Ass Q Ma
PHASES DOCUMENTS where defined
(*) = in parallel withother
phases

SYSTEM INPUTS ♦ ♦ ♦ System Requirements Specification EN 50129 annex B.2.3

♦ ♦ ♦ ♦ ♦ ♦ System Safety Requirements


Specification
EN 50129 annex B.2.4

♦ ♦ System Architecture Description EN 50129 annex B.2.1

System Safety Plan EN 50129


EN 50126

SW PLANNING (*) ♦ ♦ ♦ ♦ ♦ ♦ Sw Quality Assurance Plan 15.4.3

♦ ♦ Sw Configuration Management Plan (15.4.2)


Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

♦ ♦ Sw Verification Plan 11.4.1

♦ ♦ Sw Integration Test Plan 11.4.5

♦ ♦ Sw/Hw Integration Test Plan 12.4.1

♦ Sw Validation Plan 13.4.3

♦ Sw Maintenance Plan 16.4.3

Data Preparation Plan 17.4.2.1


Data Test Plan 17.4.2.4

SW REQUIREMENTS ♦ ♦ ♦ ♦ ♦ ♦ Sw Requirements Specification 8.4.1

Application Requirements 17.4.1.1


Specification

♦ ♦ ♦ ♦ Sw Requirements Test Specification 8.4.13

Sw Requirements Verification 11.4.11


Report

SW DESIGN ♦ ♦ ♦ ♦ ♦ Sw Architecture Specification 9.4.1

♦ ♦ ♦ ♦ Sw Design Specification 10.4.3

Sw Arch. and Design Verification 11.4.12


Report

SW MODULE DESIGN ♦ ♦ ♦ ♦ Sw Module Design Specification 10.4.3

♦ ♦ ♦ ♦ Sw Module Test Specification 10.4.14

Sw Module Verification Report 11.4.13

CODE ♦ ♦ ♦ ♦ Sw Source Code

♦ ♦ Sw Source Code Verification Report 11.4.14

MODULE TESTING ♦ Sw Module Test Report 10.4.14

SW INTEGRATION Sw Integration Test Report 11.4.15


Data Test Report 17.4.2.4

SW/HW INTEGRATION Sw/Hw Integration Test Report 12.4.8

VALIDATION(*) Sw Validation Report 13.4.10

ASSESSMENT (*) Sw Assesment Report 14.4.9

MAINTENANCE Sw Change Records 16.4.9


Sw Maintenance Records 16.4.8

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 16 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
Tabella DEI RIFERIMENTI INCROCIATI dei Documenti

Articolo 8 9 10 11 12 13 14 15 16
titolo SRS SA SDD SVer S/HI SVal Ass Q Ma
FASI DOCUMENTI Dove definiti
(*) = in parallelo con al-
tre fasi

INGRESSI DEL SISTEMA


♦ ♦ ♦ Specifica dei Requisiti di Sistema EN 50129 Allegato B.2.3

Specifica dei Requisiti di Sicurezza


♦ ♦ ♦ ♦ ♦ ♦ EN 50129 Allegato B.2.4
del Sistema
Descrizione dell’Architettura del Si-
♦ ♦ stema
EN 50129 Allegato B.2.1

Piano di Sicurezza del Sistema EN 50129


EN 50126
Piano di Assicurazione della Qualità 15.4.3
PIANIFICAZIONE SW(*) ♦ ♦ ♦ ♦ ♦ ♦ del Sw
Piano di Gestione della Configurazio- (15.4.2)
♦ ♦ ne del Sw
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

♦ ♦ Piano di Verifica del Sw 11.4.1

Piano di Prova di Integrazione del Sw 11.4.5


♦ ♦
Piano di Prova di Integrazione
♦ ♦ Sw/Hw
12.4.1

♦ Piano di Validazione del Sw 13.4.3

♦ Piano di Manutenzione del Sw 16.4.3

Piano di Preparazione dei Dati 17.4.2.1


Piano di Prova dei Dati 17.4.2.4

REQUISITI SW
♦ ♦ ♦ ♦ ♦ ♦ Specifica dei Requisiti del Sw 8.4.1

Specifica dei Requisiti dell’Applica- 17.4.1.1


zione

♦ ♦ ♦ ♦ Specifica di Prova dei Requisiti del Sw 8.4.13

Rapporto di Verifica dei Requisiti Sw 11.4.11

PROGETTAZIONE SW
♦ ♦ ♦ ♦ ♦ Specifica dell’Architettura del Sw 9.4.1

♦ ♦ ♦ ♦ Specifica della Progettazione del Sw 10.4.3

Rapporto di Verifica dell’Architettura 11.4.12


e della Progettazione del Sw
Specifica della Progettazine del Mo-
PROGETTAZIONE ♦ ♦ ♦ ♦ dulo
10.4.3
MODULO SW
♦ ♦ ♦ ♦ Specifica di Prova del Modulo Sw 10.4.14

Rapporto di Verifica del Modulo Sw 11.4.13

CODICE
♦ ♦ ♦ ♦ Codice Sorgente del Sw

Rapporto di Verifica del Codice Sor- 11.4.14


♦ ♦ gente del Sw
Rapporto di Prova del Modulo Sw
PROVA MODULO
♦ 10.4.14

INTEGRAZIONE SW Rapporto di Prova di Integrazione 11.4.15


del Sw
Rapporto di Prova dei Dati 17.4.2.4

INTEGRAZIONE SW/HW Rapporto di Prova di Integrazione 12.4.8


Sw/Hw
VALUDAZIONE (*) Rapporto di Validazione del Sw 13.4.10

VALUTAZIONE (*) Rapporto di Valutazione del Sw 14.4.9

MANUTENZIONE Registrazioni delle Variazioni del Sw 16.4.9


Registrazioni della Manutenzione 16.4.8
del Sw

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 17 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
8 SOFTWARE REQUIREMENTS SPECIFICATION SPECIFICA DEI REQUISITI DEL SOFTWARE

8.1 Objectives Obiettivi

8.1.1 To describe a document which defines a com- Elaborare un documento che definisca un insieme
plete set of requirements for the software meet- completo di requisiti per il software soddisfacen-
ing all System Requirements to the extent re- do tutti i Requisiti del Sistema nella misura in cui
quired by the Software safety Integrity level. è richiesto dal livello di integrità della sicurezza
It serves the purpose of a comprehensive docu- del Software. Ciò ha lo scopo di disporre di un
ment for each software engineer and makes it documento esauriente per ogni ingegnere del sof-
unnecessary for him to screen for requirements tware e non rendere necessario che egli selezioni
in any other document. i requisiti in qualche altro documento.

8.1.2 To describe the Software Requirements Test Descrivere la Specifica di Prova dei Requisiti del
Specification. Software.

8.2 Input documents Documenti d’ingresso


Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

1) System Requirements Specification 1) Specifica dei Requisiti del Sistema


2) System Safety Requirements Specification 2) Specifica dei Requisiti di Sicurezza del Sistema
3) System Architecture Description 3) Descrizione dell’Architettura del Sistema
4) Software Quality Assurance Plan 4) Piano di Assicurazione della Qualità del Software

8.3 Output documents Documenti di uscita


1) Software Requirements Specification 1) Specifica dei Requisiti del Software
2) Software Requirements Test Specification 2) Specifica di Prova dei Requisiti del Software

8.4 Requirements Requisiti

8.4.1 The Software Requirements Specification shall La Specifica dei Requisiti del Software deve esprime-
express the required properties of the software re le proprietà richieste al software che deve essere
being developed, not the procedures to devel- sviluppato, non le procedure per svilupparlo. Que-
op them. These properties, which are all (ex- ste proprietà che sono tutte definite (ad eccezione
cept safety) defined in ISO/IEC 9126, shall in- della sicurezza) nella ISO/IEC 9126, devono com-
clude: prendere:
 functionality (including capacity and re-  funzionalità (compresa la capacità e la presta-
sponse time performance); zione di risposta al tempo);
 reliability and maintainability;  affidabilità e manutenibilità;
 safety (including safety functions and their  sicurezza (comprese le funzioni di sicurezza e
associated software safety integrity levels); i loro associati livelli di integrità della sicurez-
za del software);
 efficiency;  efficienza;
 usability;  usabilità;
 portability.  portabilità.

The software safety integrity level shall be de- Il livello di integrità della sicurezza del software
rived as defined in clause 5 and recorded in the deve essere ricavato come definito nell’art. 5 e regi-
Software Requirements Specification. strato nella Specifica dei Requisiti del Software.

8.4.2 To the extent required by the software safety in- Nella misura in cui è richiesto dal livello di inte-
tegrity level the Software Requirements Specifi- grità della sicurezza del software la Specifica dei
cation shall be expressed and structured in such Requisiti del Software deve essere espressa e
a way that it is strutturata in modo tale che sia
i) complete, clear precise, unequivocal, verifi- i) completa, chiara precisa, inequivocabile, veri-
able, testable, maintainable and feasible, ficabile, che si possa provare, manutenibile e
fattibile,
ii) traceable back to all documents mentioned ii) tracciabile a ritroso verso tutti i documenti
under 8.2. menzionati in 8.2.

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 18 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
8.4.3 The Software Requirements Specification shall La Specifica dei Requisiti del Software deve com-
include modes of expression and descriptions prendere modi di esprimersi e descrizioni che sia-
which are understandable to the responsible no comprensibili al personale responsabile coin-
personnel involved in the whole life cycle of volto nell’intero ciclo di vita del sistema.
the system.

8.4.4 The Software Requirements Specification shall La Specifica dei Requisiti del Software deve iden-
identify and document all interfaces with any tificare e documentare tutte le interfacce con ogni
other systems, either within or outside the altro sistema, sia all’interno che all’esterno
equipment under control, including operators, dell’apparecchiatura sotto controllo, compresi gli
wherever a direct connection exists or is operatori, ovunque esista o sia pianificato un col-
planned. legamento diretto.

8.4.5 All relevant modes of operation shall be de- Tutti i modi associati al funzionamento devono
tailed in the Software Requirements Specifica- essere dettagliati nella Specifica dei Requisiti del
tion. Software.

8.4.6 All relevant modes of behaviour of the pro- Tutti i modi associati al comportamento dell’elet-
grammable electronics, in particular failure be- tronica programmabile, in particolare comporta-
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

haviour, shall be detailed in the Software Re- menti di mancato funzionamento, devono essere
quirements Specification. dettagliati nella Specifica dei Requisiti del Software.

8.4.7 Any constraints between the hardware and the Ogni vincolo tra hardware e software deve essere
software shall be identified and documented in identificato e documentato nella Specifica dei Re-
the Software Requirements Specification. quisiti del Software.

8.4.8 The Software Requirements Specification shall La Specifica dei Requisiti del Software deve indica-
indicate the degree of software self-checking re il grado di autodiagnosi del software e il grado
and the specified degree of hardware checking stabilito di controllo dell’hardware da parte del sof-
by the software. Software self-checking consists tware. L’autodiagnosi del Software consiste nella ri-
of the detection and reporting by the software levazione e nella presentazione da parte del sof-
of its own failures and errors. tware dei propri mancati funzionamenti ed errori.

8.4.9 The Software Requirements Specification shall La Specifica dei Requisiti del Software deve com-
include requirements for the periodic testing of prendere i requisiti delle prove periodiche delle
functions to the extent required by the System funzioni nella misura in cui è richiesto dalla Spe-
Safety Requirements Specification. cifica dei Requisiti di Sicurezza del Sistema.

8.4.10 The Software Requirements Specification shall La Specifica dei Requisiti del Software deve com-
include requirements to enable all safety func- prendere i requisiti per consentire che tutte le
tions to be testable during overall system opera- funzioni di sicurezza possano essere provate du-
tion to the extent required by the System Safety rante il funzionamento generale del sistema nella
Requirements Specification. misura in cui è richiesto dalla Specifica dei Requi-
siti di Sicurezza del Sistema.

8.4.11 When the software is required to perform func- Quando è richiesto che il software esegua funzio-
tions especially those related to achieving the ni, in special modo quelle connesse con il rag-
required system safety integrity level, then these giungimento del livello richiesto di integrità della
shall be clearly identified in the Software Re- sicurezza del sistema, queste devono essere chia-
quirements Specification. ramente identificate nella Specifica dei Requisiti
del Software.

8.4.12 When the software is required to perform Quando è richiesto che il software esegua funzio-
non-safety functions then these shall be clearly ni non in sicurezza queste devono essere chiara-
identified in the Software Requirements Specifi- mente identificate nella Specifica dei Requisiti del
cation. Software.

8.4.13 A Software Requirements Test Specification shall Una Specifica di Prova dei Requisiti del Software
be developed from the Software Requirements deve essere sviluppata dalla Specifica dei Requisi-
Specification. This test specification shall be used ti del Software. Questa specifica di prova deve es-
for verification of all the requirements as de- sere usata per la verifica di tutti i requisiti descritti
scribed in the Software Requirements Specifica- nella Specifica dei Requisiti del Software ed anche

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 19 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
tion and also as a description of the tests to be come una descrizione delle prove che devono es-
performed on the completed software. sere eseguite sul software ultimato.

8.4.14 The Software Requirements Test Specification La Specifica di prova dei Requisiti del Software
shall identify for each required function the test deve identificare, per ogni funzione richiesta, i
cases including: casi di prova, comprendendo:
i) the required input signals with their se- i) i segnali d’ingresso richiesti con le loro se-
quences and their values; quenze ed i loro valori;
ii) the anticipated output signals with their se- ii) i segnali di uscita previsti con le loro sequen-
quences and their values; ze e i loro valori;
iii) the acceptance criteria, including perform- iii) i criteri di accettazione, compresi gli aspetti di
ance and quality aspects. prestazione e qualità.

8.4.15 Traceability to requirements shall be an impor- La tracciabilità dei requisiti deve essere una im-
tant consideration in the validation of a safe- portante considerazione nella validazione di un
ty-related system and means shall be provided sistema in sicurezza e devono essere previsti mez-
to allow this to be demonstrated throughout all zi per permettere che essa sia dimostrata attraver-
phases of the lifecycle. so tutte le fasi del ciclo di vita.
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

8.4.16 Any untraceable material shall be shown to Si deve dimostrare che qualsiasi documentazione
have no bearing upon the safety or integrity of non tracciabile non deve avere relazione con la
the system. sicurezza o con l’integrità del sistema.

9 SOFTWARE ARCHITECTURE ARCHITETTURA DEL SOFTWARE

9.1 Objectives Obiettivi

9.1.1 To develop a software architecture that achieves Sviluppare un’architettura del software che realiz-
the requirements of the Software Requirements zi i requisiti della Specifica dei Requisiti del Sof-
Specification to the extent required by the soft- tware nella misura in cui è richiesto dal livello di
ware safety integrity level. integrità della sicurezza del software.

9.1.2 To review the requirements placed on the soft- Prendere in esame i requisiti assegnati al software
ware by the system architecture. dall’architettura di sistema.

9.1.3 To identify and evaluate the significance of Identificare e valutare l’importanza dell’interazio-
Hardware/Software interactions for safety. ne Hardware/Software per la sicurezza.

9.1.4 To choose a design method if one has not been Scegliere un metodo progettuale se non ne è stato
previously defined. definito uno in precedenza.

9.2 Input documents Documenti d’ingresso


1) Software Requirements Specification 1) Specifica dei Requisiti del Software
2) System Safety Requirements Specification 2) Specifica dei Requisiti di Sicurezza del Sistema
3) System Architecture Description 3) Descrizione dell’Architettura del Sistema
4) Software Quality Assurance Plan 4) Piano di Assicurazione della Qualità del Software

9.3 Output documents Documenti di uscita


Software Architecture Specification Specifica dell’Architettura del Software

9.4 Requirements Requisiti

9.4.1 The proposed software architecture shall be es- L’architettura software proposta deve essere stabi-
tablished by the software supplier and/or devel- lita dal fornitore del software e/o da chi lo svilup-
oper and detailed in the Software Architecture pa e dettagliata nella Specifica dell’Architettura
Specification. del Software.

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 20 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
9.4.2 The Software Architecture Specification shall La Specifica dell’Architettura del Software deve
consider the feasibility of achieving the Soft- considerare la fattibilità nel realizzare la Specifica
ware Requirements Specification at the required dei Requisiti del Software per il livello di integrità
software safety integrity level. della sicurezza del software richiesto.

9.4.3 The Software Architecture Specification shall iden- La Specifica dell’Architettura del Software deve
tify, evaluate and detail the significance of all identificare, valutare e dettagliare l’importanza di
hardware/software interactions. As required by tutte le interazioni hardware/software. Come ri-
EN 50126 and EN 50129, the preliminary studies chiesto dalla EN 50126 e dalla EN 50129, gli studi
concerning the interactions between hardware preliminari concernenti l’interazione tra hardware
and software shall have been recorded in the Sys- e software devono essere registrati nella Specifica
tem Safety Requirements Specification. dei Requisiti di Sicurezza del Sistema.

9.4.4 The Software Architecture Specification shall La Specifica dell’Architettura del Software deve
identify all software components and for these identificare tutti i componenti software e per que-
components identify: sti componenti identificare:
i) whether these components are new, exist- i) se questi componenti sono nuovi, esistenti o
ing or proprietary; proprietari;
ii) whether these components have been pre- ii) se questi componenti sono stati precedente-
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

viously validated and if so their validation mente validati ed in caso affermativo le loro
conditions; condizioni di validazione;
iii) the software safety integrity level of the iii) il livello di integrità della sicurezza del sof-
component. tware del componente.

9.4.5 The use of COTS software shall be subject to L’utilizzo di software COTS deve essere soggetto
the following restrictions: alle seguenti restrizioni:
i) for software safety integrity level 0, the use i) Per livello di integrità della sicurezza del sof-
of the COTS software shall be accepted tware 0, l’utilizzo del software COTS deve es-
with no further precautions; sere accettato senza ulteriori precauzioni;
ii) if COTS software is to be used at software ii) Se il software COTS viene usato per i livelli di
safety integrity levels 1 or 2, it shall be in- integrità della sicurezza del software 1 o 2,
cluded in the software validation process; esso deve essere inserito nel processo di vali-
dazione del software;
iii) if COTS software is to be used at software iii) Se il software COTS viene usato per i livelli di
safety integrity levels 3 or 4, the following integrità della sicurezza del software 3 o 4,
precautions shall also be taken: devono essere prese anche le seguenti pre-
cauzioni:
a) the COTS software shall be included in a) il software COTS deve essere incluso nel-
the validation testing; le prove di validazione;
b) an analysis of possible failures shall be b) deve essere eseguita un’analisi dei possi-
carried out; bili mancati funzionamenti;
c) a strategy shall be defined to detect fail- c) deve essere definita una strategia per rile-
ures of the COTS software and to pro- vare i mancati funzionamenti del software
tect the system from these failures; COTS e per proteggere il sistema da que-
sti mancati funzionamenti;
d) the protection strategy shall be the sub- d) la strategia di protezione deve essere sog-
ject of validation testing; getta a prove di validazione;
e) error logs shall exist and shall be evalu- e) devono esistere registrazioni degli errori
ated; (error logs) ed esse devono essere valutate;
f) as far as practicable, only the simplest f) per quanto praticabile, devono essere usate
functions of the COTS software shall be solo le funzioni più semplici del software
used. COTS.

9.4.6 If previously developed software is to be used Se il software sviluppato in precedenza viene uti-
as part of the design then it shall be clearly lizzato come parte del progetto allora esso deve
identified and documented. The Software Archi- essere chiaramente identificato e documentato. La
tecture Specification shall justify the software’s Specifica dell’Architettura del Software deve giu-
suitability in satisfying the Software Require- stificare l’idoneità del software a soddisfare la
ments Specification and the software safety in- Specifica dei Requisiti del Software ed il livello di
tegrity level. The effects of any changes to the integrità della sicurezza del software. Gli effetti di
software on the rest of the system must be care- ogni variazione del software sul resto del sistema
fully considered in order to decide whether devono essere attentamente considerati al fine di

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 21 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
they require a re-inspection and re-assessment. decidere se essi richiedono una nuova ispezione
There shall be evidence that interface specifica- ed una nuova valutazione. Ci deve essere eviden-
tions to other modules which are not being za che le specifiche di interfaccia con altri moduli
re-verified, re-validated and re-assessed are be- che non sono stati nuovamente verificati, validati
ing followed. e valutati siano state seguite.

9.4.7 Whenever possible existing verified software Ogni volta che è possibile devono essere utilizzati
modules developed according to this standard nel progetto i moduli software esistenti, verificati,
shall be used in the design. sviluppati secondo la presente norma.

9.4.8 The Software Architecture shall minimise the L’Architettura Software deve minimizzare la parte
safety part of the application. in sicurezza dell’applicazione.

9.4.9 Where the software consists of components of Ove il software sia composto da componenti
different software safety integrity levels then all aventi diversi livelli di integrità della sicurezza del
of the software components shall be treated as software, tutti i componenti software devono es-
belonging to the highest software safety integri- sere trattati come se appartenessero al più alto li-
ty level unless there is evidence of independ- vello di integrità della sicurezza del software, sal-
ence between the higher software safety integri- vo che vi sia evidenza dell’indipendenza tra i
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

ty level components and the lower software componenti di più alto livello di integrità della si-
safety integrity level components. This evidence curezza del software e i componenti di livello più
shall be recorded in the Software Architecture basso. Questa evidenza deve essere registrata nel-
Specification. la Specifica dell’Architettura del Software.

9.4.10 The Software Architecture Specification shall La Specifica dell’Architettura del Software deve
identify the strategy for the software develop- identificare la strategia di sviluppo del software
ment to the extent required by the software nella misura in cui è richiesto dal livello di integri-
safety integrity level. The Software Architecture tà della sicurezza del software. La Specifica
Specification shall be expressed and structured dell’Architettura del Software deve essere scritta e
in such a way that it is: strutturata in modo tale che sia:
i) complete, clear, precise, unequivocal, verifi- i) completa, chiara, precisa, inequivocabile, ve-
able, testable, maintainable and feasible, rificabile, che si possa provare, manutenibile
e realizzabile.
ii) traceable back to the Software Require- ii) tracciabilerispetto allaSpecifica dei Requisiti
ments Specification. del Software.

9.4.11 The Software Architecture Specification shall La Specifica dell’Architettura del Software deve
justify the balance taken between the strategies giustificare il bilanciamento assunto tra le strate-
of avoiding faults and handling faults. gie per evitare i guasti e per gestire i guasti.

9.4.12 The Software Architecture Specification shall La Specifica dell’Architettura del Software deve
justify that the techniques and measures chosen giustificare che le tecniche e i provvedimenti scel-
form a set which satisfies the Software Require- ti costituiscano un’insieme che soddisfi la Specifi-
ments Specification at the required software ca dei Requisiti del Software per il livello di inte-
safety integrity level. grità della sicurezza del software richiesto.

10 SOFTWARE DESIGN AND IMPLEMENTATION PROGETTAZIONE ED IMPLEMENTAZIONE DEL


SOFTWARE

10.1 Objectives Obiettivi

10.1.1 To design and implement software of a defined Progettare ed implementare il software di livello
software safety integrity level from the Software di integrità della sicurezza definito dalla Specifica
Requirements Specification and the Software dei Requisiti del Software e dalla Specifica dell’Ar-
Architecture Specification. chitettura del Software.

10.1.2 To achieve software which is analysable, testa- Realizzare un software che sia analizzabile, sotto-
ble, verifiable and maintainable. Module testing ponobile a prova, verificabile e manutenibile. An-
is also included in this phase. As verification che le prove del modulo sono comprese in questa

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 22 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
and test will be a critical element in the valida- fase. Poiché la verifica e le prove saranno ele-
tion, particular consideration shall be given to menti critici per la validazione, si deve prestare
verification and test needs throughout the de- particolare attenzione alle verifiche ed alle prove
sign and development, in order to ensure the necessarie in ogni momento del progetto e dello
resultant system and its software will be readily sviluppo, al fine di assicurare che il sistema risul-
testable from the outset. tante ed il suo software sia prontamente sottopo-
nibile a prova fin dall’inizio.

10.1.3 To select a suitable set of tools, including lan- Selezionare un adeguato insieme di strumenti (to-
guages and compilers, for the required software ols), compresi linguaggi e compilatori, per il livello
safety integrity level, over the whole lifecycle of di integrità della sicurezza del software richiesto,
the software which assists verification, valida- per l’intero ciclo di vita del software che aiuta la ve-
tion, assessment and maintenance. rifica, validazione, valutazione e manutenzione.

10.1.4 To carry out software integration. Attuare l’integrazione del software.

10.2 Input documents Documenti d’ingresso


1) Software Requirements Specification 1) Specifica dei Requisiti del Software
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

2) Software Architecture Specification 2) Specifica dell’Architettura del Software


3) Software Quality Assurance Plan 3) Piano di Assicurazione della Qualità del Software

10.3 Output documents Documenti di uscita


1) Software Design Specification 1) Specifica della Progettazione del Software
2) Software Module Design Specification 2) Specifica della Progettazione del Modulo Sof-
tware
3) Software Module Test Specification 3) Specifica di Prova del Modulo Software
4) Software Source code and supporting docu- 4) Codice sorgente del Software e documenta-
mentation zione di supporto
5) Software Module Test Report 5) Rapporto di Prova del Modulo Software

10.4 Requirements Requisiti

10.4.1 The Software Requirements Specification and La Specifica dei Requisiti del Software e la Specifi-
the Software Architecture Specification shall be ca dell’Architettura del Software devono essere di-
available, although not necessarily finalised, pri- sponibili, anche se non necessariamente comple-
or to the start of the design process. tamente definiti, prima dell’inizio del processo di
progettazione.

10.4.2 The size and complexity of the software devel- La dimensione e la complessità del software svi-
oped shall be kept to a minimum. luppato devono essere mantenute al minimo.

10.4.3 The Software Design Specification shall de- La Specifica di progettazione del Software deve de-
scribe the software design based on a decom- scrivere il progetto del software sulla base di una
position into modules with each module having sua decomposizione in moduli, con ogni modulo
a Software Module Design Specification and a dotato di Specifica della progettazione del Modulo
Software Module Test Specification. Software e Specifica di Prova del Modulo Software.

10.4.4 The Software Design Specification shall address: La Specifica della progettazione del Software deve
trattare:
i) software components traced back to soft- i) componenti software tracciati a ritroso verso
ware architecture and their safety integrity l’architettura software e loro livello di integrità
level; della sicurezza;
ii) interfaces of software components with the ii) interfacce dei componenti software con l’am-
environment; biente;
iii) interfaces between the software components; iii) interfacce tra i componenti software;
iv) data structure; iv) struttura dei dati;
v) partitioning of requirements on components; v) suddivisione dei requisiti nei componenti;
vi) main algorithms and sequencing; vi) algoritmi principali e sequenze;
vii) diagrams. vii) diagrammi.

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 23 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
10.4.5 The Software Module Design Specifications Le Specifiche di Progetto del Modulo Software de-
shall address (one Software module Design vono trattare (una Specifica della progettazione
Specification per module): del modulo Software per ogni modulo):
i) identification of all lowest software compo- i) identificazione di tutti i componenti software di
nents (called modules in the present stand- livello più basso (chiamati moduli nella presen-
ard) traced back to the upper level; te norma) tracciati verso il livello superiore;
ii) their detailed interfaces with environment ii) le loro interfacce dettagliate con l’ambiente e
and other modules with detailed inputs and gli altri moduli con ingressi e uscite dettaglia-
outputs; ti;
iii) their safety integrity level; iii) il loro livello di integrità della sicurezza;
iv) detailed algorithms and data structures. iv) gli algoritmi e le strutture dei dati dettagliati.

Each Software Module design Specification Ogni Specifica di progettazione del Modulo Sof-
should be self consistent and allow coding of tware dovrebbe essere autoconsistente e consen-
the corresponding module. tire la codifica del modulo corrispondente.

10.4.6 Each software module shall be readable, under- Ogni modulo software deve essere leggibile,
standable and testable. comprensibile e sottoponibile a prova.
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

10.4.7 A suitable set of tools, including design meth- Devono essere scelti, per il livello di integrità della
ods, languages and compilers shall be selected sicurezza del software richiesto, per l’intero ciclo di
for the required software safety integrity level vita del software, un adeguato insieme di strumenti,
over the whole lifecycle of the software. compresi metodi di progettazione, linguaggi e com-
pilatori.

10.4.8 When applicable, automatic testing tools and Quando applicabili, devono essere usati strumenti
integrated development tools shall be used. (tools) di prova automatici e strumenti (tools) di svi-
This shall take account of the needs of the Veri- luppo integrato. Questi devono tenere in considera-
fier and Validator. zione le necessità del Verificatore e del Validatore.

10.4.9 To the extent required by the software safety in- Nella misura in cui è richiesto dal livello di integrità
tegrity level, the programming language select- della sicurezza del software, il linguaggio di pro-
ed shall have a translator/compiler which has grammazione scelto deve avere un traduttore/com-
one of the following: pilatore che possiede una tra le cose seguenti:
i) a “Certificate of Validation” to a recognised i) un “Certificato di Validazione” basato su una
National/International standard; norma Nazionale/Internazionale riconosciuta;
ii) an assessment report which details its fit- ii) un rapporto di valutazione che specifichi che
ness for purpose; è adatto allo scopo;
iii) a redundant signature control based process iii) un processo basato sul controllo di firma ri-
that provides detection of the translation er- dondante che fornisce l’individuazione degli
rors. errori di traduzione.

10.4.10 The language chosen shall meet the following Il linguaggio scelto deve soddisfare i seguenti re-
requirements: quisiti:
i) the language chosen shall contain features i) il linguaggio scelto deve contenere caratteristi-
that facilitate the identification of program- che che facilitino l’identificazione degli errori di
ming errors; programmazione;
ii) the language chosen shall support features ii) il linguaggio scelto deve supportare caratteri-
that match the design method. stiche in armonia con il metodo di progetta-
zione.

10.4.11 When 10.4.10 cannot be satisfied then a justifica- Quando la 10.4.10 non può essere soddisfatta, deve
tion for any alternative language detailing its fit- essere registrata nella Specifica dell’Architettura del
ness for purpose shall be recorded in the Soft- Software o nel Piano di Assicurazione della Qualità
ware Architecture Specification or Software del Software una giustificazione per ogni linguaggio
Quality Assurance Plan. alternativo dettagliando la sua idoneità all’uso.

10.4.12 Coding standards shall be developed and used for Per lo sviluppo di tutto il software, devono essere
the development of all software. These shall be sviluppati ed usati standard di codifica. Questi de-
referenced in the Software Quality Assurance vono trovare riferimento nel Piano di Assicurazio-
Plan (see 15.4.5). ne della Qualità del Software (vedere 15.4.5).

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 24 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
10.4.13 The coding standards shall specify good pro- Gli standard di codifica (programmazione) devono
gramming practice, proscribe unsafe language specificare una buona pratica di programmazione,
features and describe procedures for source proibire caratteristiche del linguaggio non sicure e
code documentation. As a minimum, each soft- descrivere procedure per la documentazione del co-
ware module shall contain in the source code dice sorgente. Come minimo, ogni modulo software
the information defined in the following deve contenere nel codice sorgente le informazioni
(non-exhaustive) list: definite nel seguente elenco (non esaustivo):
 author;  autore;
 configuration history;  storia della configurazione;
 short description.  breve descrizione.

The use of a standard form for this information Si raccomanda l’uso di un formato standard per
is recommended. It should be the same for all queste informazioni. Dovrebbe essere lo stesso
the modules. per tutti i moduli.

10.4.14 Software Module Testing: Each module shall Prove del Modulo Software: Ogni modulo deve ave-
have a Software Module Test Specification re una Specifica di Prova del Modulo Software con
which the module shall be tested against. These la quale deve essere provato il modulo. Queste
tests shall show that each module performs its prove devono dimostrare che ogni modulo ese-
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

intended function. The Software Module Test gue le funzioni per esso volute. La Specifica di
Specification shall define the required degree of Prova del Modulo Software deve definire il grado
test coverage. richiesto di copertura della prova.
A Software Module Test Report shall be pro- Deve essere prodotto un Rapporto di Prova del
duced and shall include the following features: Modulo Software e deve comprendere i seguenti
aspetti:
i) a statement of the test results and whether i) una dichiarazione dei risultati della prova e se
each module has met the requirements of ogni modulo ha soddisfatto i requisiti della sua
its Software Module Design Specification; Specifica di Progettazione del Modulo Software;
ii) a statement of test coverage shall be provid- ii) per ogni modulo deve essere fornita una di-
ed for each module, showing that all source chiarazione di copertura della prova, dimo-
code instructions have been executed at strando che tutte le istruzioni di codice sor-
least once; gente sono state eseguite almeno una volta;
iii) it shall be in a form that is auditable; iii) deve essere in un formato tale da consentire
la verifica ispettiva;
iv) test cases and their results shall be recorded iv) i casi di prova e i loro risultati devono essere
in a machine readable form for subsequent registrati in una forma leggibile dalla macchi-
analysis; Tests should be repeatable and be na per successive analisi; Le prove dovrebbe-
performed by automatic means, if practica- ro essere ripetibili e essere eseguite con mez-
ble. zi automatici, se fattibile.
Checking that the module has correctly satisfied Il controllo che il modulo ha correttamente soddi-
its test specification is a verification activity, see sfatto la sua specifica di prova è un’attività di veri-
clause 11. fica, vedere l’art. 11.

10.4.15 In accordance with the required software safety In accordo con il livello di integrità della sicurezza
integrity level the design method chosen shall del software richiesto il metodo di progettazione
possess features that facilitate: scelto deve possedere caratteristiche che facilitano:
i) abstraction, modularity and other features i) astrazione, modularità e altre caratteristiche che
which control complexity; controllano la complessità;
ii) the clear and precise expression of ii) la chiara e precisa espressione di
 functionality;  funzionalità;
 information flow between components,  flusso di informazioni tra componenti;
 sequencing and time related informa-  sequenza ed informazioni relazionate con
tion; il tempo;
 concurrency;  concorrenzialità;
 data structure and properties;  struttura dei dati e proprietà;
iii) human comprehension; iii) comprensione per l’uomo;
iv) verification and validation. iv) verifica e validazione.

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 25 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
10.4.16 The design method chosen shall possess features Il metodo di progettazione scelto deve possedere
that facilitate software maintenance. Such features caratteristiche che facilitino la manutenzione del
shall include modularity, information hiding and software. Tali caratteristiche devono comprendere
encapsulation. modularità, information hiding ed encapsulation.

10.4.17 The integration of software modules shall be the L’integrazione dei moduli software deve essere il
process of progressively combining individual and processo di combinare progressivamente moduli
previously tested modules of software into a software singoli e provati precedentemente in un
composite whole (or into a number of compos- unico insieme (o in una serie di sottosistemi) in
ite sub-systems) in order that the module inter- modo che le interfacce del modulo ed il software
faces and the assembled software may be ade- assemblato possano essere adeguatamente prova-
quately proven prior to system integration and ti prima della integrazione di sistema e della rela-
test. tiva prova.

10.4.18 Within the context of this standard, and to a de- Nel contesto della presente norma, e per un grado
gree appropriate to the specified software safety adeguato al livello di integrità della sicurezza del
integrity level, traceability shall particularly ad- software specificato, la tracciabilità deve riguarda-
dress: re particolarmente:
i) traceability of requirements to the design or i) tracciabilità dei requisiti verso la progettazione o
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

other objects which fulfil them; altri oggetti che li soddisfano;


ii) traceability of design objects to the imple- ii) tracciabilità degli oggetti della progettazione
mentation objects which instantiate them. verso gli oggetti dell’implementazione che li
realizzano.

The output of the traceability process shall be Il risultato del processo di tracciabilità deve essere
the subject of formal configuration management. oggetto di gestione della configurazione formale.

11 SOFTWARE VERIFICATION AND TESTING VERIFICA E PROVA DEL SOFTWARE

11.1 Objective Obiettivi


To the extent required by the software safety in- Nella misura in cui è richiesta dal livello di integrità
tegrity level, to test and evaluate the products of della sicurezza del software, provare e valutare i
a given phase to ensure correctness and con- prodotti di una data fase per assicurare correttezza e
sistency with respect to the products and stand- consistenza nei confronti dei prodotti e delle norme
ards provided as input to that phase. stabilite come dati di ingresso per quella fase.

11.2 Input documents Documenti d’ingresso


1) System Requirements Specification 1) Specifica dei Requisiti del Sistema
2) System Safety Requirements Specification 2) Specifica dei Requisiti di Sicurezza del Sistema
3) Software Requirements Specification 3) Specifica dei Requisiti del Software
4) Software Requirements Test Specification 4) Specifica di Prova dei Requisiti del Software
5) Software Architecture Specification 5) Specifica dell’Architettura del Software
6) Software Design Specification 6) Specifica della progettazione del Software
7) Software Module Design Specification 7) Specifica della progettazione del Modulo Sof-
tware
8) Software Module Test Specification 8) Specifica di Prova del Modulo Software
9) Software Source code and supporting docu- 9) Codice Sorgente del Software e documenta-
mentation zione di supporto
10) Software Quality Assurance Plan 10) Piano di Assicurazione della Qualità del Software
11) Software Module Test Report 11) Rapporto di Prova del Modulo Software

11.3 Output documents Documenti di uscita


1) Software Verification Plan 1) Piano di Verifica del Software
2) Software Requirements Verification Report 2) Rapporto di Verifica dei Requisiti del Software
3) Software Architecture and Design Verifica- 3) Rapporto di Verifica dell’Architettura e della
tion Report progettazione del Software
4) Software Module Verification Report 4) Rapporto di Verifica del Modulo Software

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 26 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
5) Software Source Code Verification Report 5) Rapporto di Verifica del Codice Sorgente del
Software
6) Software Integration Test Plan 6) Piano di Prova di Integrazione del Software
7) Software Integration Test Report 7) Rapporto di Prova di Integrazione del Software

11.4 Requirements Requisiti

11.4.1 A Software Verification Plan shall be created in Deve essere creato un Piano di Verifica del Sof-
order that verification activities may be properly tware affinché le attività di verifica possano essere
directed and that particular design or other veri- opportunamente orientate e affinché possa essere
fication needs may be suitably provided for. adeguatamente provveduto a progetti particolari
During development (and depending upon the o altre necessità di verifica. Durante lo sviluppo
size of the system) the plan may be sub-divided (e in relazione alla dimensione del sistema) il pia-
into a number of child documents and be natu- no può essere suddiviso in una serie di documen-
rally added to, as the detailed needs of verifica- ti figlio che naturalmente possono essere aggiunti,
tion become clearer. mentre divengono più chiare le dettagliate neces-
sità di verifica.
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

11.4.2 The Software Verification Plan shall document Il Piano di Verifica del Software deve documentare
all the criteria, techniques and tools to be uti- tutti i criteri, le tecniche e gli strumenti (tools) da uti-
lised in the verification process for that phase. lizzare nel processo di verifica per quella fase.

11.4.3 The Software Verification Plan shall describe the Il Piano di Verifica del Software deve descrivere le
activities to be performed to ensure correctness attività da eseguire per assicurare correttezza e
and consistency with respect to the products consistenza nei confronti dei prodotti e delle nor-
and standards provided as input to that phase. me fornite come dati d’ingresso per quella fase.

11.4.4 The Software Verification Plan shall address the Il Piano di Verifica del Software deve trattare quan-
following: to segue:
i) the selection of verification strategies and i) la scelta delle strategie e delle tecniche di verifi-
techniques. To avoid undue complexity in ca. Per evitare eccessive complessità nella valu-
the assessment of the verification and test tazione della verifica e dell’attività di prova, do-
activity, preference should be given to the vrebbe essere data preferenza alla scelta di casi
selection of test cases and methods etc., di prova e metodi, ecc., che siano di per se
which are in themselves readily analysable; prontamente analizzabili;
ii) the selection and utilisation of the software ii) la scelta e l’utilizzo di dispositivi di prova sof-
test equipment; tware;
iii) the selection and documentation of verifica- iii) la scelta e la documentazione delle attività di
tion activities; verifica;
iv) the evaluation of verification results gained; iv) la valutazione dei risultati di verifica ottenuti;
v) the evaluation of the reliability requirements; v) la valutazione dei requisiti di affidabilità;
vi) the roles and responsibilities of those in- vi) i ruoli e le responsabilità di quanti coinvolti
volved in the test process; nel processo di prova;
vii) the degree of test coverage required to be vii) il grado di copertura della prova che si richie-
achieved. de sia raggiunto.

11.4.5 The Software Integration Test Plan shall docu- Il Piano di Prova di Integrazione del Software
ment the following: deve documentare quanto segue:
i) test cases and test data; i) casi di prova e dati di prova;
ii) types of tests to be performed; ii) tipi di prove da eseguire;
iii) test environment, tools, configuration and iii) ambiente di prova, strumenti (tools), configu-
programs; razione e programmi;
iv) test criteria on which the completion of the iv) criteri di prova in base ai quali sarà giudicato
test will be judged. il completamento delle prove.

11.4.6 In each development phase it shall be shown In ogni fase di sviluppo deve essere mostrato che
that the functional, reliability, performance and sono soddisfatti i requisiti di funzionalità, affidabi-
safety requirements are met. lità, prestazione e sicurezza.

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 27 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
11.4.7 Verification shall be carried out by an independ- La verifica deve essere svolta da una parte indi-
ent party to the extent required by the software pendente nella misura in cui è richiesto dal livello
safety integrity level as defined in Figure 5. di integrità della sicurezza del software come defi-
nito in Fig. 5.

11.4.8 Testing which is not fully documented and is La prova che non è completamente documentata ed
performed by the designer prior to verification è eseguita dal progettista prima della verifica non
shall not be regarded as part of the verification. deve essere considerata una parte della verifica.

11.4.9 The results of each verification shall be retained I risultati di ogni verifica devono essere conservati
in a form defined or referenced in the Software in un formato definito o referenziati nel Piano di
Verification Plan such that it is auditable. Verifica del Software in modo da poter essere sot-
toposti a verifica ispettiva.

11.4.10 After each verification activity a verification report Dopo ogni attività di verifica deve essere prodotto
shall be produced stating either that the software un rapporto di verifica che dichiari se il software
has passed the verification or the reasons for the ha superato la verifica o i motivi del fallimento. I
failures. The verification reports shall address rapporti di verifica devono trattare quanto segue:
the following:
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

i) items which do not conform to the Software i) elementi (items) che non sono conformi alla
Requirements Specification, Software De- Specifica dei Requisiti del Software, alla Specifi-
sign Specification or Software Module De- ca della progettazione del Software o alle Speci-
sign Specifications; fiche di Progetto del Modulo Software;
ii) items which do not conform to the Software ii) elementi (items) che non sono conformi al
Quality Assurance Plan; Piano di Assicurazione della Qualità del Sof-
tware;
iii) modules, data, structures and algorithms iii) moduli, dati, strutture e algoritmi che si adat-
poorly adapted to the problem; tano poco al problema;
iv) detected errors or deficiencies; iv) errori rilevati o difetti;
v) the identity and configuration of the items v) l’identità e la configurazione degli elementi
verified. (items) verificati.

11.4.11 Software Requirements Verification: Once the Verifica dei Requisiti del Software: Una volta che è
Software Requirements Specification has been stata stabilita la Specifica dei Requisiti del Softwa-
established, verification shall address: re la verifica deve trattare:
i) the adequacy of the Software Requirements i) l’adeguatezza della Specifica dei Requisiti del
Specification in fulfilling the requirements Software nel soddisfare i requisiti definiti nella
set out in the System Requirements Specifi- Specifica dei Requisiti del Sistema, nella Specifi-
cation, the System Safety Requirements ca dei Requisiti di Sicurezza del Sistema e nel
Specification and the Software Quality As- Piano di Assicurazione della Qualità del Softwa-
surance Plan; re;
ii) the adequacy of the Software Requirements ii) l’adeguatezza della Specifica di Prova dei Re-
Test Specification as a test of the Software quisiti del Software come prova della Specifi-
Requirements Specification; ca dei Requisiti del Software;
iii) the internal consistency of the Software Re- iii) la consistenza interna della Specifica dei Re-
quirements Specification. quisiti del Software.

The results shall be recorded in a Software Re- I risultati devono essere registrati nel Rapporto di
quirements Verification Report. Verifica dei Requisiti del Software.

11.4.12 Software Architecture and Design Verification: Af- L’Architettura del Software e la Verifica della proget-
ter the Software Architecture Specification and tazione: dopo che sono state definite la Specifica
the Software Design Specification have been es- dell’Architettura del Software e la Specifica della
tablished, verification shall address: Progettazione del Software la verifica deve trattare:
i) the adequacy of the Software Architecture i) l’adeguatezza della Specifica dell’Architettura
Specification and the Software Design Spec- del Software e della Specifica della Progettazio-
ification in fulfilling the Software Require- ne del Software nel soddisfare la Specifica dei
ments Specification; Requisiti del Software;
ii) the adequacy of the Software Design Speci- ii) l’adeguatezza della Specifica della Progetta-
fication for the Software Requirements zione del Software alla Specifica dei Requisiti
Specification with respect to consistency del Software riguardo a consistenza e comple-
and completeness; tezza;

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 28 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
iii) the adequacy of the Software Integration iii) l’adeguatezza del Piano di Prova di Integrazione
Test Plan as a set of test cases for the Soft- del Software come un insieme di casi di prova
ware Architecture Specification and the per la Specifica dell’Architettura del Software e
Software Design Specification; la Specifica della Progettazione del Software;
iv) the internal consistency of the Software Ar- iv) la consistenza interna dell’Architettura e delle
chitecture and Design Specifications. Specifiche di Progettazione del Software.

The results shall be recorded in a Software Ar- I risultati devono essere registrati in un Rapporto
chitecture and Design Verification Report. dell’Architettura del Software e di Verifica della
Progettazione.

11.4.13 Software Module Verification: After each Software Verifica del Modulo Software: dopo che ogni Speci-
Module Design Specification has been estab- fica della Progettazione del Modulo Software è stata
lished, verification shall address: definita, la verifica deve trattare:
i) the adequacy of the Software Module De- i) l’adeguatezza della Specifica della Progettazione
sign Specification in fulfilling the Software del Modulo Software nel soddisfare la Specifica
Design Specification; della Progettazione del Software;
ii) the adequacy of the Software Module Test ii) l’adeguatezza della Specifica di Prova del Mo-
Specification as a set of test cases for the dulo Software come insieme di casi di prova
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

Software Module Design Specification; per la Specifica della Progettazione del Modu-
lo Software;
iii) the decomposition of the Software Design iii) la scomposizione della Specifica della Proget-
Specification into software modules and the tazione del Software in moduli software e le
Software Module Design Specifications with Specifiche di Progettazione del Modulo Sof-
reference to tware con riferimento a
 feasibility of the performance required,  fattibilità delle prestazioni richieste,
 testability for further verification,  possibilità di prova per ulteriori verifiche,
 readability by the development and ver-  leggibilità da parte del gruppo di sviluppo
ification team, and e verifica, e
 maintainability to permit further evolu-  manutenibilità per ottenere ulteriori svi-
tion; luppi;
iv) the adequacy of the Software Module Test iv) l’adeguatezza dei Rapporti di Prova dei Mo-
Reports as a record of the tests carried out duli Software come registrazione delle prove
in accordance with the Software Module eseguite in accordo con la Specifica di Prova
Test Specification. del Modulo Software.

The results shall be recorded in a Software I risultati devono essere registrati in un Rapporto
Module Verification Report. di Verifica del Modulo Software.

11.4.14 Software Source Code Verification: To the extent Verifica del Codice Sorgente del Software: nella mi-
demanded by the software safety integrity level sura in cui è richiesto dal livello di integrità della
the Software Source Code shall be verified to sicurezza del software il Codice Sorgente del Sof-
ensure conformance to the Software Module tware deve essere verificato per assicurare confor-
Design Specification and the Software Quality mità alla Specifica di Progettazione del Modulo
Assurance Plan. This shall include a check to Software e al Piano di Assicurazione della Qualità
determine whether the coding standards have del Software. Questo deve comprendere una veri-
been applied correctly. fica per stabilire se gli standard di codifica (pro-
grammazione) sono stati applicati correttamente.
The results shall be recorded in a Software I risultati devono essere registrati in un Rapporto
Source Code Verification Report. di Verifica del Codice Sorgente del Software.

11.4.15 A Software Integration Test Report shall be pro- Un Rapporto di Prova di Integrazione del Softwa-
duced as follows: re deve essere prodotto come segue:
i) a Software Integration Test Report shall be i) deve essere prodotto un Rapporto di Prova di In-
produced stating the test results and wheth- tegrazione del Software che dichiari i risultati del-
er the objectives and criteria of the Software le prove e dove sono stati soddisfatti gli obiettivi
Integration Test Plan have been met. If e i criteri del Piano di Prova di Integrazione del
there is a failure, the reasons for the failure Software. Se vi è un mancato funzionamento, de-
shall be recorded; vono essere registrati i motivi del mancato fun-
zionamento;

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 29 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
ii) the Software Integration Test Report shall ii) il Rapporto di Prova di Integrazione del Sof-
be in a form that is auditable; tware deve essere in un formato che ne con-
senta la verifica ispettiva;
iii) test cases and their results shall be record- iii) i casi di prova e i loro risultati devono essere
ed, preferably in machine readable form for registrati, preferibilmente in forma leggibile
subsequent analysis; dalla macchina per analisi successive;
iv) tests should be repeatable and be per- iv) le prove dovrebbero essere ripetibili ed esse-
formed by automatic means,if practicable; re eseguite con mezzi automatici, se possibile;
v) the identity and configuration of the items v) l’identità e la configurazione degli elementi
verified. (items) verificati.

11.4.16 For software/hardware integration, see 12.4.8. Per l’integrazione software/hardware, vedere 12.4.8.

12 SOFTWARE/HARDWARE INTEGRATION INTEGRAZIONE SOFTWARE/HARDWARE

12.1 Objectives Obiettivi


Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

12.1.1 To demonstrate that the software and the hard- Dimostrare che il software e l’hardware interagi-
ware interact correctly to perform their intend- scono correttamente per eseguire le loro previste
ed functions. funzioni.

12.1.2 To combine the software and hardware, ensur- Mettere insieme il software e l’hardware, assicu-
ing their compatibility, to meet the System Safe- rando la loro compatibilità, per soddisfare la Spe-
ty Requirements Specification and the require- cifica dei Requisiti di Sicurezza del Sistema e i Re-
ments of the intended software safety integrity quisiti del livello previsto di integrità della
level. sicurezza del software.

12.2 Input documents Documenti d’ingresso


1) System Requirements Specification 1) Specifica dei Requisiti del Sistema
2) System Safety Requirements Specification 2) Specifica dei Requisiti di Sicurezza del Sistema
3) System Architecture Description 3) Descrizione dell’Architettura del Sistema
4) Software Requirements Specification 4) Specifica dei Requisiti del Software
5) Software Requirements Test Specification 5) Specifica di prova dei Requisiti del Software
6) Software Architecture Specification 6) Specifica dell’Architettura del Software
7) Software Design Specification 7) Specifica della Progettazione del Software
8) Software Module Design Specification 8) Specifica della progettazione del Modulo Sof-
tware
9) Software Module Test Specification 9) Specifica di Prova del Modulo Software
10) Software Source code and supporting docu- 10) Codice Sorgente del Software e documentazio-
mentation ne di supporto
11) Hardware documentation 11) Documentazione Hardware

12.3 Output documents Documenti di uscita


1) Software/Hardware Integration Test Plan 1) Piano di Prova di Integrazione Software/Hard-
ware
2) Software/Hardware Integration Test Report 2) Rapporto di Prova dell’Integrazione Softwa-
re/Hardware

12.4 Requirements Requisiti

12.4.1 For software safety integrity levels greater than Per livelli di integrità della sicurezza del software
zero, a Software/Hardware Integration Test Plan maggiori di zero, sarà creato, all’inizio del ciclo di
will be created early in the development lifecy- vita dello sviluppo, un Piano di Prova di Integra-
cle, in order that integration activities may be zione Software/Hardware, in modo che le attività
properly directed and that particular design or di integrazione possano essere orientate in modo
other integration needs may be suitably provid- appropriato e che il progetto specifico o altre ne-
ed for. During development (and depending cessità di integrazione possano essere previste in

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 30 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
upon the size of the system) the plan may be modo idoneo. Durante lo sviluppo (e in relazione
subdivided into a number of child documents alla dimensione del sistema) il piano può essere
and be naturally added to, as the hardware and suddiviso in più documenti figlio ed essere natu-
software designs evolve and the detailed needs ralmente aggiuntimentre i progetti hardware e
of integration become clearer. software evolvono e divengono più chiare le ne-
cessità dettagliate di integrazione.

12.4.2 The Software/Hardware Integration Test Plan Il Piano di Prova di Integrazione Software/Hard-
shall document the following: ware deve documentare quanto segue:
i) test cases and test data; i) casi di prova e dati di prova;
ii) types of tests to be performed; ii) tipi di prove da eseguire;
iii) test environment including tools, support iii) ambiente di prova, comprendente strumenti,
software and configuration description; and software di supporto e descrizione della con-
figurazione; e
iv) test criteria on which the completion of the iv) criteri di prova per mezzo dei quali sarà sti-
test will be judged. mata la completezza della prova.

12.4.3 The Software/Hardware Integration Test Plan Il Piano di Prova di Integrazione Software/Hard-
shall distinguish between those activities which ware deve distinguere tra quelle attività che pos-
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

can be carried out by the developer on his sono essere eseguite da chi sviluppa nel suo am-
premises and those that require access to the biente e quelle che richiedono di accedere
user’s site. all’ambiente dell’utilizzatore.

12.4.4 The Software/Hardware Integration Test Plan Il Piano di Prova di Integrazione Software/Hard-
shall distinguish between the following activities: ware deve fare distinzione tra le seguenti attività:
i) merging of software onto the target hard- i) allocazione del software nell’hardware a cui è de-
ware; stinato;
ii) system integration; ii) integrazione del sistema;

12.4.5 Tools and facilities identified in the Soft- Strumenti e supporti identificati nel Piano di Prova
ware/Hardware Integration Test Plan should be di Integrazione Software/Hardware dovrebbero es-
available at the earliest practicable time. sere disponibili per quanto possibile fin dall’inizio.

12.4.6 During Software/Hardware Integration any Durante l’Integrazione Software/Hardware ogni


modification or change to the integrated system modifica o cambiamento al sistema integrato deve
shall be subject to an impact study which shall essere soggetto ad uno studio dell’impatto che
identify all modules impacted and the necessary deve identificare tutti i moduli coinvolti e le ne-
reverification activities. cessarie attività di riverifica

12.4.7 Test cases and their results shall be recorded, I casi di prova e i loro risultati devono essere regi-
preferably in machine readable form for subse- strati, preferibilmente in forma leggibile da mac-
quent analysis. chine per successive analisi.

12.4.8 A Software/Hardware Integration Test Report Un Rapporto di Prova di Integrazione Softwa-


shall be produced as follows: re/Hardware deve essere prodotto come segue:
i) Software/Hardware Integration Test Report i) Il Rapporto di Prova di Integrazione Softwa-
shall state the test results and whether the re/Hardware deve riportare i risultati di prova e
objectives and criteria of the Software/Hard- se gli obiettivi e i criteri del Piano di Prova di In-
ware Integration Test Plan have been met. tegrazione Software/Hardware sono stati soddi-
If there is a failure, it shall be recorded; sfatti. Se vi è un mancato funzionamento, questo
deve essere registrato;
ii) the Software/Hardware Integration Test Re- ii) Il Rapporto di Prova dell’Integrazione Softwa-
port shall be in a form that is auditable; re/Hardware deve essere in un formato che
ne consenta la verifica ispettiva;
iii) test cases and their results shall be record- iii) I casi di prova e i loro risultati devono essere
ed, preferably in amachine-readable form registrati, preferibilmente in forma leggibile
for subsequent analysis; da macchine per successive analisi;
iv) the Software/Hardware Integration Test Re- iv) Il Rapporto di Prova dell’Integrazione Softwa-
port shall also contain evidence that the re/Hardware deve anche contenere l’attestazio-
Verifier is satisfied with the adequacy of the ne che il Verificatore è soddisfatto per l’adegua-
Software/Hardware Integration Test Report tezza del Rapporto di Prova dell’Integrazione
as a record of the tests carried out in ac- Software/Hardware inteso come raccolta delle

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 31 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
cordance with the Software/Hardware Inte- prove eseguite in accordo con il Piano di Prova
gration Test Plan; di Integrazione Software/Hardware;
v) the Software/Hardware Integration Test Re- v) Il Rapporto di Prova dell’Integrazione Softwa-
port shall document the identity and config- re/Hardware deve documentare l’identità e la
uration of all items involved. configurazione di tutte gli elementi coinvolte.

13 SOFTWARE VALIDATION VALIDAZIONE DEL SOFTWARE

13.1 Objective Obiettivi


To analyse and test the integrated system to en- Analizzare e provare il sistema integrato per assi-
sure compliance with the Software Require- curare la conformità con la Specifica dei Requisiti
ments Specification with particular emphasis on del Software con particolare enfasi per gli aspetti
the functional and safety aspects according to funzionali e di sicurezza considerando il livello di
the Software Safety integrity level. integrità della sicurezza del Software.

13.2 Input documents Documenti d’ingresso


Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

1) Software Requirements Specification 1) Specifica dei Requisiti del Software


2) All Hardware and Software Documentation 2) Tutta la Documentazione Hardware e Software
3) System Safety Requirements Specification 3) Specifica dei Requisiti di Sicurezza del Sistema

13.3 Output documents Documenti di uscita


1) Software Validation Plan 1) Piano di Validazione del Software
2) Software Validation Report 2) Rapporto di Validazione del Software

13.4 Requirements Requisiti

13.4.1 Analysing and testing shall be the main valida- L’analisi e le prove devono essere le principali at-
tion activity. tività di validazione.

13.4.2 Simulation and modelling may be used to sup- La simulazione e la modellazione possono essere
plement the validation process. usate per completare il processo di validazione.

13.4.3 A Software Validation Plan shall be established Un Piano di Validazione del Software deve essere
and detailed in suitable documentation. stabilito e dettagliato in una appropriata docu-
mentazione.

13.4.4 The Software Validation Plan shall be devel- Il Piano di Validazione del Software deve essere
oped, performed and results evaluated by an sviluppato, eseguito ed i risultati valutati da una
independent party to the extent required by the parte indipendente nella misura in cui è richiesto
software safety integrity level. dal livello di integrità della sicurezza del software.

13.4.5 If required by the software safety integrity level, Se richiesto dal livello di integrità della sicurezza
the scope and contents of the Software Validation del software, lo scopo e i contenuti del Piano di
Plan shall be agreed with the assessor. This agree- Validazione del Software devono essere concor-
ment shall also make a statement concerning the dati con il valutatore. Questo accordo deve preve-
presence of the assessor during testing. dere anche una dichiarazione riguardante la pre-
senza del valutatore durante le prove.

13.4.6 The Software Validation Plan shall include a Il Piano di Validazione del Software deve com-
summary justifying the validation strategy cho- prendere una premessa che giustifichi la strategia
sen. The justification shall include considera- di validazione scelta. La giustificazione deve com-
tion, according to the required software safety prendere considerazioni, secondo il livello di in-
integrity level, of: tegrità della sicurezza del software richiesto, circa:
i) manual or automated techniques or both; i) tecniche manuali o automatiche, o entrambe;
ii) static or dynamic techniques or both; ii) tecniche statiche o dinamiche o entrambe;
iii) analytical or statistical techniques or both. iii) tecniche analitiche o statistiche o entrambe.

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 32 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
13.4.7 The Software Validation Plan shall identify the steps Il Piano di Validazione del Software deve identifica-
necessary to demonstrate the adequacy of the: re i passi necessari a dimostrare l’adeguatezza della:
 Software Requirements Specification;  Specifica dei Requisiti del Software;
 Software Architecture Specification;  Specifica dell’Architettura del Software;
 Software Design Specification;  Specifica della Progettazione del Software;
 Software Module Design Specification;  Specifica della Progettazione del Modulo Sof-
tware;

in fulfilling the safety requirements set out in nel soddisfare i requisiti di sicurezza prestabiliti
the System Safety Requirements Specification. nella Specifica dei Requisiti di Sicurezza del Siste-
The Validator shall check that the verification ma. Il Validatore deve controllare che il processo
process is complete. di verifica è completo.

13.4.8 Measurement equipment used for validation Le apparecchiature di misura usate per la validazione
shall be calibrated appropriately. Any tools, devono essere tarate in modo appropriato. Deve es-
hardware or software, used for validation shall sere dimostrato che ogni strumento, hardware o sof-
be shown to be suitable for the purpose. tware, usato per la validazione è adatto allo scopo.

13.4.9 The software shall be exercised by simulation Il software deve essere stimolato attraverso la si-
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

of input signals present during normal opera- mulazione dei segnali d’ingresso presenti durante
tion, anticipated occurrences and undesired il normale funzionamento, eventi anticipati e con-
conditions requiring system action. dizioni non desiderate che richiedono azioni del
sistema.

13.4.10 The results of the validation shall be document- I risultati della validazione devono essere docu-
ed in the Software Validation Report in an audit- mentati nel Rapporto di Validazione del Software
able form. in un formato che ne consenta la verifica ispettiva.

13.4.11 Once hardware/software integration is finished, Una volta che l’integrazione hardware/software è
a Software Validation Report shall be produced finita, deve essere prodotto un Rapporto di Valida-
as follows: zione del Software come segue:
i) it shall state whether the objectives and cri- i) deve dichiarare se gli obiettivi e i criteri del
teria of the Software Validation Plan have Piano di Validazione del Software sono stati
been met. If there is a failure, it shall be re- soddisfatti. Se vi è un mancato funzionamento,
corded; questo deve essere registrato;
ii) it shall state the tests results and whether ii) deve dichiarare i risultati delle prove e se l’inte-
the whole software on its target machine ro software sulla sua macchina definitiva soddi-
fulfils the requirements set out in the Soft- sfa i requisiti stabiliti nella Specifica dei Requisiti
ware Requirements Specification; del Software;
iii) an evaluation of the test coverage on the re- iii) deve essere fornita una valutazione della coper-
quirements of the Software Requirements tura delle prove rispetto ai requisiti della Speci-
Specification shall be provided; fica dei Requisiti del Software;
iv) the Software Validation Report shall be in a iv) il Rapporto di Validazione del Software deve es-
form that is auditable; sere in un formato che ne consenta la verifica
ispettiva;
v) test cases and their results shall be recorded v) i casi di prova e i loro risultati devono essere re-
in a machine readable form for subsequent gistrati in una forma leggibile da macchine per
analysis; successive analisi;
vi) tests should be repeatable and be per- vi) le prove dovrebbero essere ripetibili ed essere
formed by automatic means, if practicable. eseguite, se possibile, con mezzi automatici.

13.4.12 The Software Validation Report shall document Il Rapporto di Validazione del Software deve do-
the identity and configuration of all: cumentare l’identità e la configurazione di tutto:
i) the hardware and software used; i) l’hardware e il software usato;
ii) the equipment used; ii) le apparecchiature usate;
iii) the equipment’s calibration; iii) la taratura delle apparecchiature;
iv) the simulation models used; iv) i modelli di simulazione usati;
v) the discrepancies found; v) le discrepanze trovate;
vi) the corrective actions performed. vi) le azioni correttive eseguite.

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 33 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
13.4.13 Any discrepancies found, including detected er- Ogni discrepanza trovata, compresi gli errori sco-
rors, shall be clearly identified in a separate sec- perti, deve essere chiaramente identificata in una
tion of the Software Validation Report and in- sezione separata del Rapporto di Validazione del
cluded in any release note which accompanies Software e inserita in ogni nota sulla versione che
the delivered software. accompagna il software consegnato.

13.4.14 The software shall be tested against the Soft- Il software deve essere provato in base alla Speci-
ware Requirements Test Specification. These fica di Prova dei Requisiti del Software. Queste
tests shall show that all of the requirements in prove devono dimostrare che tutti i requisiti della
the Software Requirements Specification are Specifica dei Requisiti del Software sono corretta-
correctly performed. mente eseguiti.
The results shall be recorded in a Software Vali- I risultati devono essere registrati in un Rapporto
dation Report. di Validazione del Software.

14 SOFTWARE ASSESSMENT VALUTAZIONE DEL SOFTWARE

14.1 Objective Obiettivi


Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

To evaluate that the lifecycle processes and Valutare che i processi del ciclo di vita e i prodotti
products resulting are such that the software is risultanti sono tali che il software è del livello di
of the defined software safety integrity level and integrità della sicurezza del software definito ed è
is fit for its intended application. adatto per l’applicazione voluta.

14.2 Input documents Documenti d’ingresso


1) System Safety Requirements Specification 1) Specifica dei Requisiti di Sicurezza del Sistema
2) All Hardware and Software Documentation 2) Tutta la documentazione Hardware e Software

14.3 Output documents Documenti di uscita


Software Assessment Report Rapporto di Valutazione del Software

14.4 Requirements Requisiti

14.4.1 For software of safety integrity level zero: Per il software di livello di integrità della sicurezza zero:
i) the Assessor shall only be required to con- i) al Valutatore deve solo essere richiesto di con-
firm that this is the appropriate software fermare che questo è il livello appropriato di
safety integrity level; integrità della sicurezza del software;
ii) it is also possible to agree this level between ii) è anche possibile concordare questo livello tra
the supplier and the user at the time of ten- il fornitore e l’utente al momento dell’offerta.
dering.

14.4.2 Software with a Software Assessment Report Software con un Rapporto di Valutazione del Sof-
from another Assessor does not have to be an tware di un altro Valutatore non deve essere og-
object for an entirely new assessment. The sec- getto di una valutazione interamente nuova. Il se-
ond Assessor shall check that the software is of condo Valutatore deve verificare che il software
the required software safety integrity level and ha il livello di integrità della sicurezza del softwa-
that it is fit for its intended application on the re richiesto e che è adatto all’applicazione previ-
intended target computer. sta sull’elaboratore di destinazione previsto.

14.4.3 The Assessor shall have access to the design Il Valutatore deve avere accesso al processo di
and development process and all project related progettazione e di sviluppo e a tutta la documen-
documentation. tazione relativa al progetto.

14.4.4 The assessment of the software shall be carried La valutazione del software deve essere eseguita
out by an Assessor who is independent from da un Valutatore che è indipendente dal gruppo
the design team. di progetto.

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 34 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
14.4.5 The Assessor shall assess that the software of Il Valutatore deve valutare che il software del si-
the system is fit for its intended purpose and re- stema è adatto allo scopo voluto e che risponde
sponds correctly to safety issues derived from correttamente alle condizioni di sicurezza che de-
the System Safety Requirements Specification. rivano dalla Specifica dei Requisiti di Sicurezza
del Sistema.

14.4.6 To the extent required by the software safety in- Nella misura in cui è richiesto dal livello di integrità
tegrity level, the Assessor shall decide if appro- della sicurezza del software, il Valutatore deve deci-
priate methods have been selected and applied dere se sono stati scelti ed applicati ad ogni fase del
at each phase of the software lifecycle. ciclo di vita del software metodi appropriati.

14.4.7 If required by the software safety integrity level, Se richiesto dal livello di integrità della sicurezza
the Assessor shall agree the scope and contents del software, il Valutatore deve concordare lo sco-
of the Software Validation Plan. This agreement po e i contenuti del Piano di Validazione del Sof-
shall also make a statement concerning the tware. Questo accordo deve anche produrre una
presence of the Assessor during testing. dichiarazione riguardo alla presenza del Valutato-
re durante le prove.

14.4.8 The Assessor may ask for additional verification Il Valutatore, se lo decide, può chiedere ulteriore
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

and validation work if he so chooses. lavoro di verifica e validazione.

14.4.9 The Assessor shall produce a report for each re- Il Valutatore deve produrre per ogni riesame un
view which shall detail his assessment results. rapporto che deve dettagliare i risultati della sua
valutazione.

14.4.10 If, in the opinion of the Assessor, the software is Se, a giudizio del Valutatore, il software è adatto
fit for its intended application, the final Software all’applicazione prevista, il Rapporto finale di Vali-
Assessment Report shall include a statement as dazione del Software deve includere una dichiara-
to the software safety integrity level achieved by zione circa il livello di integrità della sicurezza del
the software. software raggiunto dal software.

14.4.11 When the software is not fit for its purpose or has Quando il software non è adatto al suo scopo o
not achieved the required software safety integrity non ha raggiunto il livello di integrità della sicu-
level then the Assessor shall only report the rezza del software richiesto, il Valutatore deve
non-conformities in the Software Assessment solo riportare le non conformità nel Rapporto di
Report and shall not give any technical solution. Valutazione del Software e non deve dare alcuna
soluzione tecnica.

15 SOFTWARE QUALITY ASSURANCE ASSICURAZIONE DELLA QUALITÀ DEL SOFTWARE

15.1 Objectives Obiettivi

15.1.1 To identify, monitor and control all those activi- Identificare, sorvegliare e controllare tutte quelle
ties, both technical and managerial, which are attività, sia tecniche che gestionali, che sono ne-
necessary to ensure that the software achieves cessarie per assicurare che il software raggiunga
the quality required. This is necessary to pro- la qualità richiesta. Questo è necessario per forni-
vide the required qualitative defence against re la richiesta difesa qualitativa nei confronti dei
systematic faults and to ensure that an audit trail guasti sistematici e per assicurare che possa esse-
can be established to allow verification and val- re stabilito un percorso di verifiche ispettive per
idation activities to be undertaken effectively. permettere di intraprendere efficacemente le atti-
vità di verifica e validazione.

15.1.2 To provide evidence that the above activities Fornire evidenza che le attività di cui sopra sono
have been carried out. state eseguite.

15.2 Input documents Documenti d’ingresso


All the documents available at each stage of the Tutti i documenti disponibili in ogni fase del ciclo
lifecycle di vita.

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 35 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
15.3 Output documents Documenti di uscita
1) Software Quality Assurance Plan 1) Piano di Assicurazione della Qualità del Software
2) Software Configuration Management Plan 2) Piano di Gestione della Configurazione del
Software

All the above plans shall be issued at the begin- Tutti i piani di cui sopra devono essere prodotti
ning of the project and updated during the life- all’inizio del progetto ed aggiornati nel corso del
cycle. ciclo di vita.

15.4 Requirements Requisiti

15.4.1 The supplier and/or developer shall have and Il fornitore e/o il realizzatore devono avere ed
use as a minimum a Quality Assurance System adottare, come minimo, un Sistema di Assicurazio-
compliant with EN ISO 9000 series, to support ne della Qualità conforme alle norme della serie
the requirements of this European Standard. EN ISO 9000, per supportare i requisiti della pre-
EN ISO 9001 accreditation is highly recom- sente Norma Europea. È altamente raccomandato
mended. che sia conseguita la certificazione EN ISO 9001.
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

15.4.2 As a minimum, the supplier and/or developer Come minimo, il fornitore e/o il realizzatore ed il
and the customer shall implement for the soft- cliente devono implementare per lo sviluppo del
ware development the relevant parts of EN ISO software, le rispettive parti della EN ISO 9001, in
9001, in accordance with the guidelines con- accordo con le linee guida contenute nella
tained in EN ISO 9000-3. EN ISO 9000-3.

15.4.3 The supplier and/or developer shall prepare Il fornitore e/o il realizzatore devono preparare e
and document, on a project by project basis, a documentare, progetto per progetto un Piano di
Software Quality Assurance Plan to implement Assicurazione della Qualità del Software per imple-
the requirements of 15.4.1 and 15.4.2 of this Eu- mentare i requisiti degli art. 15.4.1 e 15.4.2 della
ropean Standard, which shall be expressed in presente Norma Europea, che devono essere
measurable terms wherever possible. espressi, ove possibile, in termini misurabili.

15.4.4 The Software Quality Assurance Plan shall have Il Piano di Assicurazione della Qualità del Softwa-
a paragraph specifying details about its own up- re deve prevedere un paragrafo che specifichi i
dating throughout the project: frequency, re- dettagli relativi al suo aggiornamento nel corso
sponsibility, method. del progetto: frequenza, responsabilità, metodo.

15.4.5 All activities, actions, documents, etc. required Tutte le attività, azioni, documenti, ecc. richiesti da
by all the sections of EN ISO 9000-3 and of this tutte le sezioni della EN ISO 9000-3 e della presen-
European Standard (annex A included) shall be te Norma Europea (Allegato A compreso) devono
specified or referenced in the Software Quality essere specificate o richiamate nel Piano di Assicu-
Assurance Plan and tailored to the specific de- razione della Qualità del Software ed essere adatta-
velopment. None of the lists in EN ISO 9000-3 te allo sviluppo specifico. Nessun elenco della
shall be presumed to be exhaustive. EN ISO 9000-3 deve essere considerato esaustivo.
As a minimum, except at software safety integri- Come minimo, eccetto che per il livello di integri-
ty level zero, the following items shall also be tà della sicurezza del software zero, devono esse-
specified or referenced in the Software Quality re anche specificate o richiamate nel Piano di As-
Assurance Plan. sicurazione della Qualità del Software le seguenti
indicazioni.
This is to ensure that all the safety aspects in Ciò serve ad assicurare che tutti gli aspetti di sicu-
the Software with respect to the required Soft- rezza del Software nei confronti del livello di inte-
ware Safety integrity level will be covered. grità della sicurezza del Software richiesto, saranno
coperti.
The present list is not exhaustive: Il presente elenco non è esaustivo:
i) definition of the life-cycle model definition i) definizione del modello del ciclo di vita defini-
of each phase including: zione di ogni fase comprendendo:
 activities and elementary tasks;  attività e compiti elementari;
 entry and exit criteria;  criteri di ingresso e di uscita;
 inputs and outputs of each phase;  ingressi ed uscite di ogni fase;
 major quality activities in each phase;  principali attività della qualità in ogni fase;

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 36 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
 organisational unit responsible for each  responsabile dell’unità organizzativa per
activity and elementary task; ogni attività e compito elementare;
ii) requirements traceability; ii) tracciabilità dei requisiti;
iii) documentation structure traceability; iii) tracciabilità della struttura della documentazione;
iv) documentation associated with the develop- iv) documentazione associata allo sviluppo, verifi-
ment, verification and validation, operation ca e validazione, utillizzazione e manutenzione
and maintenance of software; del software;
v) system integration procedures; v) procedure di integrazione del sistema;
vi) coding standards to be used; vi) standard di codifica da usare;
vii) assessment of previous validation tests; vii) valutazione delle prove di validazione prece-
denti;
viii) the definition of the metrics (quantitative viii) definizione delle metriche (misure quantitative)
measures) to be carried out on both the prod- da adottare sia per il prodotto che per il proces-
uct and the process. For the software product so. Per le metriche adottate per il prodotto sof-
metrics carried out, reference shall be made to tware, si deve fare riferimento alle caratteristi-
the quality characteristics and evaluation che di qualità e alle linee guida di valutazione
guidelines defined by ISO/IEC 9126. definite nella ISO/IEC 9126.

15.4.6 As a minimum, configuration management shall Come minimo, la gestione della configurazione
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

be carried out in accordance with the guidelines deve essere eseguita in accordo con le linee guida
contained in EN ISO 9000-3. contenute nella EN ISO 9000-3.
Each software document shall be placed under Ogni documento software deve essere sottoposto
configuration control before the release of its first al controllo di configurazione prima del rilascio
approved version. The software source code shall della sua prima versione approvata. Il codice sor-
be placed under configuration control before the gente del software deve essere sottoposto al con-
commencement of documented module testing. trollo della configurazione prima dell’inizio delle
prove di modulo documentate.
It shall not be possible to make any unauthor- Non deve essere possibile eseguire alcun cambia-
ised changes to any item under Configuration mento non autorizzato per ogni elemento sotto il
Management Control. Precautions shall be tak- Controllo di Gestione della Configurazione. Si de-
en to prevent or detect errors occurring in ma- vono prendere precauzioni per impedire o rileva-
chine readable code during storage, transfer, re errori che si verificano nel codice leggibile dal-
transmission or duplication. la macchina durante la memorizzazione, il
trasferimento, la trasmissione o la duplicazione.
Configuration Management shall not be limited La Gestione della Configurazione non deve essere
to the strict product development and mainte- limitata allo stretto sviluppo e manutenzione del
nance, but it shall also cover the environment prodotto, ma deve anche coprire l’ambiente utiliz-
used during the full lifecycle. This extension, zato durante tutto il ciclo di vita. Questa estensione,
necessary for the reproducibility of the develop- necessaria per la riproducibilità dello sviluppo e per
ment and for the maintenance activities, shall in- le attività di manutenzione, deve comprendere i file
clude computer configuration files, assemblers, di configurazione dell’elaboratore, gli assemblatori,
compilers, debuggers and all the other used i compilatori, i programmi per localizzare e rimuo-
tools. vere gli errori e tutti gli altri strumenti usati.

15.4.7 The adequacy and results of Software Verifica- Devono essere esaminati l’adeguatezza e i risultati
tion Plans shall be examined. del Piano di Verifica del Software.

15.4.8 The supplier and/or developer shall establish, Il fornitore e/o il costruttore devono stabilire, do-
document and maintain procedures for External cumentare e manutenere le procedure per il Con-
Supplier Control, including: trollo dei Fornitori Esterni, compresi:
 methods to ensure that software provided  metodi per assicurare che il software fornito
by external suppliers adheres to established da fornitori esterni sia aderente ai requisiti
requirements. Previously developed soft- stabiliti. Il software sviluppato in precedenza
ware shall be assured to be compliant with deve essere conforme al livello di integrità
the required software safety integrity level della sicurezza del software richiesto e alla fi-
and dependability. New software shall be datezza. Il software nuovo deve essere svilup-
developed and maintained in conformity pato e manutenuto in conformità al Piano di
with the Software Quality Assurance Plan of Assicurazione della Qualità del Software del
the Supplier or with a specific Software Fornitore o allo specifico Piano di Assicura-
Quality Assurance Plan prepared by the ex- zione della Qualità del Software preparato dal
ternal supplier in accordance with the Soft- fornitore esterno in accordo con il Piano di

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 37 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
ware Quality Assurance Plan of the Suppli- Assicurazione della Qualità del Software del
er; Fornitore;
 methods to ensure that the requirements  metodi per assicurare che i requisiti forniti al
provided to the External Software Supplier Fornitore di Software Esterno siano adeguati e
are adequate and complete. completi.

15.4.9 The supplier and/or developer shall establish, Il fornitore e/o il costruttore devono stabilire, do-
document and maintain procedures for Problem cumentare e mantenere procedure per il Rappor-
Reporting and Corrective Actions. These proce- to su Problemi ed Azioni Correttive. Queste pro-
dures, as part of the Quality Assurance System, cedure, come parte del Sistema di Assicurazione
shall implement the relevant parts of EN ISO 9001, Qualità, devono implementare le relative parti
especially covering at least the following aspects: della EN ISO 9001, coprendo specialmente, alme-
no i seguenti aspetti:
 define the documentation needed for prob-  definire la documentazione necessaria per il
lem reporting and/or corrective actions, rapporto su problemi e/o azioni correttive,
with the aim of giving feedback to the re- con lo scopo di darne conto ai gestori respon-
sponsible management; sabilì;
 define analysis of the information collected  definire l’analisi delle informazioni raccolte nei
in the problem reports to identify its causes; rapporti sui problemi per identificarne le cause;
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

 define the practices to be followed for re-  definire la prassi da seguire per emettere rap-
porting, tracking and resolving problems porti, tracciare e risolvere problemi identificati
identified both during the development sia durante la fase di sviluppo che durante
phase and during software maintenance; quella di manutenzione del software;
 define preventive actions to deal with prob-  definire le azioni preventive per trattare i pro-
lems to a level corresponding to the re- blemi ad un livello corrispondente a quello ri-
quired software safety integrity level; chiesto dal livello di integrità della sicurezza
del software;
 define the specific organisational responsi-  definire le responsabilità specifiche dell’orga-
bilities with regard to development and nizzazione con riguardo allo sviluppo e alla
software maintenance; manutenzione del software;
 define how to apply controls to ensure that  definire come applicare i controlli per assicu-
corrective actions are taken and that they rare che le azioni correttive siano intraprese e
are effective; che esse siano efficaci;
 define the forms to be used;  definire i moduli da usare;
 define the requirements for re-test, re-verifi-  definire i requisiti per ripetere le prove, la ve-
cation, re-validation and re-assessment. rifica, la validazione e la valutazione.

As a minimum, problem reporting and correc- Come minimo, il rapporto dei problemi e la ge-
tive action management shall be applied in the stione delle azioni correttive devono essere appli-
software lifecycle starting immediately after cati nel ciclo di vita iniziando immediatamente
Software Integration and before the starting of dopo l’Integrazione del Software e prima di inizia-
formal Software Validation, also covering the re la formale Validazione del Software, coprendo
whole phase of Software Maintenance. anche l’intera fase di Manutenzione del Software.

16 SOFTWARE MAINTENANCE MANUTENZIONE DEL SOFTWARE

16.1 Objective Obiettivi


To ensure that the software performs as re- Assicurare che il software operi come previsto,
quired, preserving the required software safety mantenendo il livello di integrità della sicurezza
integrity level and dependability when making del software richiesto e la fidatezza quando si
corrections, enhancements or adaptations to the pongono in atto correzioni, miglioramenti, o adat-
software itself. tamenti del software stesso.

16.2 Input documents Documenti d’ingresso


All documents Tutti i documenti

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 38 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
16.3 Output documents Documenti di uscita
1) Software Maintenance Plan 1) Piano di Manutenzione del Software
2) Software Change Records 2) Registrazioni dei Cambiamenti del Software
3) Software Maintenance Record 3) Registrazione delle Manutenzioni del Software

16.4 Requirements Requisiti

16.4.1 As a minimum, maintenance shall be carried Come minimo, la manutenzione deve essere ese-
out in accordance with the guidelines contained guita in accordo con le linee guida contenute nel-
in EN ISO 9000-3. la EN ISO 9000-3.
In addition, the following requirements con- Inoltre, devono essere soddisfatti i seguenti requi-
cerning software maintenance shall also be met. siti concernenti la manutenzione del software.

16.4.2 Maintainability shall be designed into the soft- La manutenibilità deve essere progettata nel Siste-
ware system, in particular, by following the re- ma software, in particolare, seguendo i Requisiti
quirements of clause 10 of this European Stand- dell’art. 10 della presente Norma Europea. Dovreb-
ard. ISO/IEC 9126 should also be employed in be essere impiegata anche la ISO/IEC 9126 al fine
order to require and verify a minimum level of di richiedere e verificare un livello minimo di ma-
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

maintainability. nutenibilità.

16.4.3 Procedures for the maintenance of software Le procedure di manutenzioni del software devo-
shall be established and recorded in the Soft- no essere stabilite e registrate nel Piano di Manu-
ware Maintenance Plan. These procedures shall tenzione del Software. Queste procedure devono
also include: comprendere anche:
i) control of error reporting, error logs, main- i) rapporto sul controllo degli errori, raccolta de-
tenance records, change authorisation and gli errori, registrazioni della manutenzione, au-
software/system configuration; torizzazione di modifiche e configurazione sof-
tware/sistema;
ii) verification, validation and assessment; and ii) verifica, validazione e valutazione; e
iii) definition of the Authority which approves iii) definizione dall’Autorità che approva i cambia-
the changed software. menti del software.
16.4.4 The maintenance activities shall be audited Le attività di manutenzione devono essere sotto-
against the Software Maintenance Plan, at inter- poste a verifica ispettiva a fronte del Piano di Ma-
vals defined in the Software Quality Assurance nutenzione del Software, ad intervalli definiti nel
Plan. Piano di Assicurazione della Qualità del Software.

16.4.5 Maintenance shall be performed with the same La manutenzione deve essere eseguita con il me-
level of expertise, tools, documentation, plan- desimo livello di competenza, strumenti, documen-
ning and management as the initial develop- tazione, pianificazione e gestione, dello sviluppo
ment of the system. This shall apply also to iniziale del sistema. Questo si deve applicare an-
configuration management, change control, che alla gestione della configurazione, al controllo
document control, and independence of in- delle modifiche, al controllo della documentazione
volved parties. ed all’indipendenza delle parti coinvolte.

16.4.6 This European Standard is not intended to be La presente Norma Europea non è previsto che sia
retrospective. It therefore applies primarily to retroattiva. Essa si applica pertanto soprattutto a
new developments and only applies in its en- nuovi sviluppi e si applica nella sua interezza solo a
tirety to existing systems if these are subjected quei sistemi esistenti che sono soggetti a modifiche
to major modifications. For software safety in- importanti. Per il livello di integrità della sicurezza
tegrity level 3 or 4, the contracting entities shall, del software 3 o 4, le entità contraenti devono deci-
before starting work on any change, decide dere, prima di iniziare il lavoro per qualsiasi modifi-
whether the maintenance actions are to be con- ca, se le attività di manutenzione devono essere
sidered as major or minor or whether the exist- considerate più o meno importanti o se i metodi di
ing maintenance methods for the system are ad- manutenzione esistenti per il sistema sono adeguati.
equate. For software safety integrity levels 0, 1 Per livelli di integrità della sicurezza del software 0,
or 2, the same decision shall be taken by the 1 o 2, la medesima decisione deve essere presa dal
supplier. fornitore.

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 39 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
16.4.7 External supplier control, problem reporting Il controllo dei fornitori esterni, il rapporto sui
and corrective actions shall be managed with problemi e sulle azioni correttive devono essere
the same criteria specified in the relevant para- gestiti con i medesimi criteri specificati nei relativi
graphs of the Software Quality Assurance paragrafi dell’articolo dell’Assicurazione della
clause. Qualità del Software.

16.4.8 A Software Maintenance Record shall be estab- Deve essere stabilito e deve essere mantenuto un
lished for each Software Item before its first re- registro di Manutenzione del Software per ogni
lease, and it shall be maintained. In addition to elemento di Software prima della sua prima ver-
the requirements of EN ISO 9000-3 for “Mainte- sione. Oltre ai Requisiti della EN ISO 9000-3 per
nance Records and Reports”, this Record shall “Registri e Rapporti di Manutenzione”, questo re-
also include: gistro deve comprendere anche:
i) references to all the Software Change i) riferimenti a tutti i Registri di modifica del Sof-
Records for that Software Item; tware per quell’elemento Software;
ii) change consequence information; ii) informazioni sulle conseguenze delle modifi-
che;
iii) test cases for components, including revali- iii) casi di prova dei componenti, compresa rivali-
dation and regression testing data; and dazione e dati delle prove di regressione; e
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

iv) software configuration history. iv) storia della configurazione del software.

16.4.9 A Software Change Record shall be established Deve essere stabilito per ogni attività di manuten-
for each maintenance activity. This record shall zione un registro delle Modifiche del Software.
include: Questo registro deve comprendere:
i) the modification or change request; i) la modifica o la richiesta di modifica;
ii) an analysis of the impact of the mainte- ii) un’analisi dell’impatto dell’attività di manutenzio-
nance activity on the overall system, includ- ne sul sistema generale, comprendente l’hardwa-
ing hardware, software, human interaction re, il software, l’interazione dell’uomo e l’am-
and the environment and possible interac- biente e le possibili interazioni;
tions;
iii) the detailed specification of the modifica- iii) la specifica dettagliata della modifica o cambia-
tion or change; and mento; e
iv) revalidation, regression testing and re-as- iv) rivalidazione, prove di regressione e rivalutazio-
sessment of the modification or change to ne della modifica o cambiamento nella misura
the extent required by the software safety in cui è richiesto dal livello di integrità della si-
integrity level. The responsibility for revali- curezza del software. La responsabilità della ri-
dation can vary from project to project, ac- validazione può variare da progetto a progetto,
cording to the software safety integrity lev- secondo il livello di integrità della sicurezza del
el. Also the impact of the modification or software. Anche l’impatto della modifica o del
change on the process of revalidation can cambiamento sul processo di rivalidazione può
be confined to different system levels (only essere ristretto a livelli di sistema diversi (solo
changed modules, all identified affected moduli cambiati, tutti i moduli influenzati iden-
modules, the complete system). Therefore tificati, il sistema completo). Pertanto il Piano di
the Software Validation Plan shall address Validazione del Software deve trattare entrambi
both problems, according to the software i problemi, secondo il livello di integrità della si-
safety integrity level. The degree of inde- curezza del software. Il grado di indipendenza
pendence of revalidation shall be the same della rivalidazione deve essere lo stesso di quel-
as that for validation. lo per la validazione

17 SYSTEMS CONFIGURED BY APPLICATION SISTEMI CONFIGURATI CON DATI


DATA DELL’APPLICAZIONE

17.1 Objectives Obiettivi

17.1.1 A characteristic feature of railway control and Un aspetto caratteristico dei sistemi di controllo e
protection systems is the need to design each protezione ferroviari è la necessità di progettare
installation to meet the individual requirements ogni installazione per soddisfare i requisiti indivi-
for a specific application. A system configured duali per una specifica applicazione. Un sistema
by application data allows type-approved ge- configurato da dati di applicazione permette di usa-
neric software to be used, with the individual re un software generico di tipo approvato, con i re-
requirements for each installation defined as quisiti specifici per ogni installazione definita come

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 40 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
data (application specific data). This data is nor- dati (dati specifici dell’applicazione). Questi dati
mally in the form of tabular information or an sono normalmente nella forma di informazione ta-
application specific language which is interpret- bellare o in un linguaggio specifico dell’applicazio-
ed by the generic software. ne che è interpretato dal software generico.

17.1.2 For a safety critical system, the high level of re- Per un sistema critico per la sicurezza, l’elevato livel-
sources required to develop software to achieve lo di risorse richieste per sviluppare il software per
the required system safety integrity level for the soddisfare il livello di integrità della sicurezza richie-
system makes the adoption of a system config- sto per il sistema rende vantaggiosa l’adozione di un
ured by application data very attractive because sistema configurato dai dati dell’applicazione perché
it allows the re-use of generic software. Howev- consente il riutilizzo di software generico. Tuttavia,
er, as the safe operation of the system is likely poiché il funzionamento sicuro del sistema è verosi-
to depend on the correctness of the data, the milmente dipendente dalla correttezza dei dati, le
procedures used for development of the data procedure usate per lo sviluppo dei dati devono an-
must also be to an appropriate system safety in- ch’esse essere di un appropriato livello di integrità
tegrity level. della sicurezza del sistema.

17.1.3 The sections below describe the requirements Le sezioni sottostanti descrivono i requisiti della
of this European Standard for the initial devel- presente Norma Europea per lo sviluppo iniziale
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

opment of the generic software for a system del software generico per un sistema configurato
configured by application data, and for the sub- dai dati dell’applicazione, e per il successivo svi-
sequent development of each set of installa- luppo di ogni insieme di dati specifici dell’appli-
tion-specific data. cazione.

17.2 Input documents Documenti d’ingresso


1) Software Requirements Specification 1) Specifica dei Requisiti del Software
2) Software Architecture Specification 2) Specifica dell’Architettura del Software

17.3 Output documents Documenti di uscita


1) Application Requirements Specification 1) Specifica dei Requisiti dell’Applicazione
2) Data Preparation Plan 2) Piano di Preparazione dei Dati
3) Data Test Plan 3) Piano di Prova dei Dati
4) Data Test Report 4) Rapporto di Prova dei Dati

17.4 Requirements Requisiti

17.4.1 Data Preparation Lifecycle Ciclo di Vita della Preparazione dei Dati
Figure 6 illustrates a lifecycle for an application La figura 6 illustra un ciclo di vita per un’applica-
making use of hardware and generic software, zione che utilizza hardware e software generico,
together with application-specific data. The con i dati specifici dell’applicazione. Le fasi del ci-
phases of the lifecycle are as follows. clo di vita sono le seguenti.

17.4.1.1 Application Requirements Specification Specifica dei Requisiti dell’Applicazione


The requirements for the application shall be I Requisiti per l’applicazione devono essere defini-
defined. This shall include requirements which ti. Questi possono comprendere requisiti che sono
are specific to the individual installation (e.g. specifici per la singola installazione (ad esempio
track layout, signal locations, speed limits), and piano schematico, disposizione dei segnali, limiti
standards which the application must comply di velocità), e norme alle quali l’applicazione deve
with (e.g. signalling principles, system safety in- conformarsi (ad esempio, principi del segnalamen-
tegrity levels). to, livelli di integrità della sicurezza del sistema).

17.4.1.2 Overall Installation Design Progettazione Generale dell’Installazione


The system architecture shall be defined, and L’architettura del sistema deve essere definita, e la
the quantity and type of the generic compo- quantità e il tipo dei componenti generici da usa-
nents to be used shall be specified. Those com- re devono essere specificati. Quei componenti
ponents which contain software shall have che contengono software devono essere sviluppa-
been developed in conformance with this Euro- ti in conformità con la presente Norma Europea.
pean Standard. The functions specified in the Le funzioni specificate nei requisiti devono essere
requirements shall be allocated to the compo- allocate nei componenti, e deve essere definita la

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 41 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
nents, and the physical location of each compo- localizzazione fisica di ogni componente.
nent shall be defined.

17.4.1.3 Data Preparation Preparazione dei Dati


The data preparation process shall include the Il processo di preparazione dei dati deve com-
production of specific information (e.g. control prendere la produzione di specifiche informazioni
tables), production of the data source code and (ad esempio, tabelle di controllo), la generazione
its compilation, checking and other verification del codice sorgente dei dati e la sua compilazio-
activities, and testing of the application data. ne, il controllo e le altre attività di verifica, e la
prova dei dati dell’applicazione.

17.4.1.4 Integration and Acceptance Integrazione e Accettazione


For some systems the application data will be Per alcuni sistemi i dati dell’applicazione saranno
integrated with the generic hardware and soft- integrati con l’hardware e il software generico per
ware for a factory test before installation on site. una prova in fabbrica prima dell’installazione sul si-
This may not be necessary where a sufficient to. Questo può non essere necessario se si può ot-
degree of confidence can be obtained by other tenere un sufficiente grado di confidenza con altri
means. The equipment shall then be installed mezzi. Le apparecchiature devono quindi essere in-
on site, and integration tests carried out on the stallate sul sito, ed eseguite le prove di integrazione
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

new equipment. Finally the system shall be con le nuove apparecchiature. Infine il sistema deve
commissioned as a fully operational system, essere consegnato come sistema completamente
and a final acceptance process shall be carried funzionante, e deve essere eseguito un processo fi-
out on the complete installation. nale di accettazione sull’installazione completa.

17.4.1.5 Validation and Assessment Validazione e Valutazione


Validation and assessment activities shall audit Le attività di validazione e di valutazione devono
the performance of each stage of the life-cycle. eseguire una verifica ispettiva della prestazione di
in ogni fase del ciclo di vita.

17.4.2 Data Preparation Procedures and Tools Procedure di Preparazione dei Dati e Strumenti (tools)
For each new type of system configured by ap- Per ogni nuovo tipo di sistema configurato dai dati
plication data, specific data preparation proce- dell’applicazione, devono essere sviluppate proce-
dures and tools shall be developed to allow the dure di preparazione di dati specifici e strumenti per
data preparation lifecycle specified in 17.4.1 to permettere di applicare all’installazione del nuovo
be applied to installations of the new system. sistema il ciclo di vita della preparazione dei dati
Development of these procedures and tools specificato in 17.4.1. Lo sviluppo di queste procedu-
shall be carried out in accordance with this Eu- re e strumenti deve essere eseguito in accordo con
ropean Standard in parallel with the generic la presente Norma Europea in parallelo al software
software and hardware for the system. The veri- generico e all’hardware per il sistema. Le attività di
fication, validation and assessment activities verifica, validazione e valutazione devono assicurare
shall ensure that the data preparation tools and che gli strumenti di preparazione dei dati e il sof-
the generic software are compatible. tware generico siano compatibili.

17.4.2.1 At the Software Design phase for the system con- Nella fase di Progettazione del Software per il siste-
figured by application data, a Data Preparation ma configurato dai dati dell’applicazione, deve esse-
Plan shall be produced to define a documenta- re predisposto un Piano di Preparazione dei Dati
tion structure for the data preparation process. per definire una struttura della documentazione per
These documents shall be related to the data il processo di preparazione dei dati. Questi docu-
preparation lifecycle model described in 17.4.1. menti devono essere riferiti al modello del ciclo di
The plan shall specify the data preparation pro- vita di preparazione dei dati descritto in 17.4.1. Il
cedures and tools to be used to meet the re- piano deve specificare le procedure di preparazione
quired system safety integrity levels. The plan dei dati e gli strumenti da usare per ottenere i livelli
shall specify the requirements for the independ- di integrità della sicurezza del sistema richiesti. Il
ence between staff carrying out verification, val- piano deve specificare i requisiti per l’indipendenza
idation and design tasks. tra il personale che esegue compiti di verifica, vali-
dazione e progettazione.

17.4.2.2 The Data Preparation Plan shall allocate a safety Il Piano di Preparazione dei Dati deve assegnare
integrity level to any hardware or software tools un livello di integrità della sicurezza ad ogni stru-
used in the data preparation lifecycle. This safe- mento, hardware o software, usato nel ciclo di
ty integrity level shall be derived from the re- vita di preparazione dei dati. Questo livello di in-

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 42 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
quired system safety integrity level and the de- tegrità della sicurezza deve essere derivato dal li-
gree to which the output of each tool is vello di integrità della sicurezza richiesto per il si-
checked by other manual or automated proce- stema e dal grado con il quale i dati in uscita di
dures. ogni strumento sono verificati con altre procedure
automatiche o manuali.

17.4.2.3 Where possible the Data Preparation Plan shall Ove possibile il Piano di Preparazione dei Dati
call for notations for specifying requirements deve richiamare annotazioni per specificare requi-
and design which are familiar to applications siti e progettazione che sono familiari agli ingegne-
engineers, e.g. standard signalling plans and ri delle applicazioni, ad esempio, piani di segnala-
control tables. Where new notations are intro- mento normalizzati e tabelle di controllo. Ove sono
duced, the necessary user documentation must introdotte nuove notazioni, deve essere fornita la
be provided and training shall also be provided necessaria documentazione per l’utente e deve es-
where appropriate. sere anche fornita l’istruzione se necessario.

17.4.2.4 The verification, test, validation and assessment I rapporti di verifica, prova, validazione e valuta-
reports required to demonstrate that the data zione richiesti per dimostrare che la preparazione
preparation has been carried out in accordance dei dati è stata eseguita in accordo con il piano
with the plan can be standardised in the form of può essere standardizzata nella forma di liste di
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

checklists to minimise the workload in produc- riscontro per minimizzare il carico di lavoro nella
ing documentation for each installation. This in- produzione di documentazione per ogni installa-
formation shall be contained in the Data Test zione. Queste informazioni devono essere conte-
Plan and the results shall be recorded in the nute nel Piano di Prova dei Dati e i risultati devo-
Data Test Report. no essere registrati nel Rapporto di Prova dei dati.

17.4.2.5 All data and associated documentation shall be Tutti i dati e la documentazione associata deve es-
subject to the configuration management require- sere soggetta ai requisiti della gestione della confi-
ments of section 15 of this standard. The configu- gurazione della Sezione 15 della presente norma.
ration management records shall list the version of Le registrazioni della gestione della configurazione
generic software with which the data has been devono elencare la versione del software generico
designed to operate, and the versions of the tools con la quale i dati sono stati progettati ad operare,
used in the data preparation process. e le versioni degli strumenti usati nel processo di
preparazione dei dati.

17.4.3 Software Development Sviluppo del Software


Development of the generic software to be Lo sviluppo del software generico da usare in un
used in a system configured by application data sistema configurato dai dati dell’applicazione deve
shall comply with the requirements in clauses 1 essere conforme ai requisiti degli art. da 1 a 16
to 16 of this standard. The following additional della presente norma. Devono essere osservati an-
requirements shall also be observed. che i seguenti requisiti supplementari.

17.4.3.1 During the Software Requirements Specification Durante la fase della Specificazione dei Requisiti del
phase, those functions which make use of appli- Software, devono essere identificate quelle funzioni
cation data in each system and subsystem shall be che fanno uso dei dati dell’applicazione in ogni siste-
identified. The system safety integrity level allocat- ma e sottosistema. Il livello di integrità della sicurezza
ed to each sub-system will determine the stand- del sistema assegnato ad ogni sottosistema determi-
ards to be applied to the subsequent development nerà le norme da applicare allo sviluppo successivo
of the data for all installations of the system. dei dati per tutte le installazioni del sistema.

17.4.3.2 During the Software Design phase the detailed in- Durante la fase di Progettazione del Software devo-
terfaces between the generic software and appli- no essere specificate le interfacce dettagliate tra il
cation data shall be specified, unless this has al- software generico e i dati di applicazione, salvo
ready been specified at an earlier phase of the che queste non siano già state specificate in una
lifecycle, for example as a result of a require- precedente fase del ciclo di vita, per esempio
ment to use an existing application specific lan- come risultato di un requisito ad usare uno speci-
guage. fico linguaggio di un’applicazione esistente.

17.4.3.3 During the Software Module Design phase a rigid Durante la fase di Progetto del Modulo Software
separation between program code and data shall deve essere imposta una rigida separazione tra co-
be enforced, i.e. it shall be possible to recompile dice del programma e dati, per esempio deve es-
and update either the generic software or the sere possibile ricompilare e aggiornare sia il sof-

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 43 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
data without needing to update the other, un- tware generico che i dati senza dover aggiornare
less there has been a change to the defined in- l’altro, salvo che non vi sia stato un cambiamento
terface between the software and data. Like- nella interfaccia definita tra il software e i dati.
wise, application specific data should be Ugualmente, i dati specifici dell’applicazione do-
separated from other data. vrebbero essere separati da altri dati.

17.4.3.4 During the Software Maintenance phase, the Durante la fase di Manutenzione del Software, le
change control procedures must ensure that any procedure di controllo delle modifiche devono assi-
amendment to the generic software may only be curare che ogni modifica del software generico
installed after it has been established that either possa essere installata solo dopo che è stato stabi-
the revised software is compatible with the lito che o il software revisionato è compatibile
original data, or the data has been revised as con i dati originali, o i dati sono stati rivisti per
necessary. quanto necessario.

17.4.3.5 Care must be taken in the Software Verification Si deve aver cura di assicurare che nel processo di
process and Software Validation phase in order to Verifica del Software e nella fase di Validazione del
assure that all relevant combinations of data are Software vengano considerate tutte le combina-
considered. zioni pertinenti dei dati.
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

17.4.3.6 The generic software shall be designed to de- Il software generico deve essere progettato per ri-
tect corrupted configuration data where this is levare, quando ciò è fattibile, i dati di configura-
feasible. zione corrotti.

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 44 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

– BLANK PAGE – – PAGINA BIANCA –

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 45 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

Fig. 1 Integrity Levels for Safety-Related Systems

Frequency of

Pagina 46 di 128
NORMA TECNICA
Hazardous Event

CEI EN 50128:2002-04
System Software
Safety Safety
Integrity Integrity
Increasing Level
Level
Frequency
4 4

Risk level: Required 3 3


No Risk
Protective 2 2
Consequence of Features Reduction
Hazardous Event 1 1
0 0

Increasing
Consequence

SAFETY INTEGRITY LEVELS


4 - Very high

RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE


EQUIPMENT 3 - High
2 - Medium
UNDER CONTROL
1 - Low
0 - Non-safety

Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

Livelli di Integrità per Sistemi in Sicurezza

Frequenza
dell’Evento Pericoloso

Livello di Integrità Livello di Integrità di


di Sicurezza del Sicurezza del
Sistema Software
Frequenza
Crescente
4 4
Livello di ri- Riduzione 3 3
schio: Assenza del Rischio
di Caratteristi- Richiesta 2 2
Conseguenze che protettive
dell’Evento Pericoloso 1 1
0 0

Conseguenza
crescente

LIVELLI DI INTEGRITÀ DI SICUREZZA

RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE


4 – Molto Alto
APPARECCHIATURA 3 – Alto
SOTTO CONTROLLO 2 – Medio
2 – Basso
0 – Non in Sicurezza

Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
Pagina 47 di 128
CEI EN 50128:2002-04
NORMA TECNICA
Fig. 2 Software Safety Route Map

Obtain System Requirements Specification,


System Safety Requirements Specification
System Architecture Description and
System Safety Plan for the system

Identify all the safety functions allocated


to the software

Review all safety functions allocated


to the software and determine the
Software Safety Integrity Level
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

Produce the Software Requirements Spec


and the Software Architecture Specification

Design, develop and verify/test the


software according to the Software
Quality Assurance Plan, Software Safety
Integrity Level and the Software Lifecycle

Perform the Software Validation and


hand over to system engineers

Operational life of the system

Software Maintenance

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 48 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
Percorso della Sicurezza del Software

Ottenere per il sistema: la Specifica dei Requisiti


del Sistema, la Specifica dei Requisiti di Sicurezza
del Sistema, la Descrizione dell’Architettura del Si-
stema e il Piano di Sicurezza del Sistema

Identificare tutte le funzioni di sicurezza assegnate


al software

Esaminare tutte le funzioni di sicurezza assegnate


al software e determinare il Livello di Integrità di
Sicurezza del Software
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

Produrre la Specifica dei Requisiti del Software e


la Specifica dell’Architettura del Software

Progettare, sviluppare e verificare/provare il sof-


tware secondo il Piano di Assicurazione Qualità
del Software, il Livello di Integrità della Sicurezza
del Software ed il Ciclo di Vita del Software

Eseguire la validazione del Software e consegnare-


agli ingegneri di sistema

Vita operativa del sistema

Manutenzione del Software

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 49 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
Fig. 3 Development Lifecycle 1

DESIGN DOCUMENT VERIFICATION PHASE

System Requirements Specification


System Safety Requirements Spec
System Architecture Description System Development
System Safety Plan
System Verification

Software Requirements Software Requirements


Test Specification Specification
Software Requirements
Software Requirements Verification

Software Architecture Specification

Software Architecture Verification

Software Design
Software Integration Software Design
Plan Specification
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

Software Design Verification

Software Module Software Module


Software Module Design
Test Specification Design Specification

Software Module Verification

Software Source Code


Code
and supporting documentation

Code Verification

Software Module Test Report

Software Testing

Software Integration Test Report

Software/Hardware Integration
Software/Hardware Integration
Test Report
Software Validation Software Validation

System integration and test


System Integration
documents

System Validation System Validation Phase

System intallation documents

Site Support

System maintenance documents

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 50 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
Ciclo di vita dello Sviluppo 1

DOCUMENTAZIONE DI PROGETTO VERIFICA FASE


Specifica dei Requisiti del Sistema
Specifica dei Requisiti di Sicurezza del Sistema
Descrizione dell’Architettura del Sistema Sviluppo del Sistema
Piano di Sicurezza del Sistema
Verifica del Sistema

Specifica di Prova dei Specifica dei Requisiti


Requisiti del Software del Software
Requisiti del Software

Verifica dei Requisisti del Software


Specifica dell’Architettura
del Software
Verifica dell’Architettura del Software

Piano di Integrazione Specifica di Progettazione


del Software del Software Progettazione del Software
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

Verifica del Progetto del Software

Specifica di Prova del Specifica di Progettazione


Modulo Software del Modulo Software Progettazione del Modulo
Software

Verifica del Modulo Software


Codice Sorgente del Software e
documentazione di supporto Codice

Verifica del codice


Rapporto di Prova del Modulo
Software

Prova del Software


Rapporto di Prova di Integrazione
del Software

Rapporto di Prova dell’Integrazio-


ne Software/Hardware Integrazione Software/Hardware

Validazione del Software Verifica del Sistema

Integrazione del sistema e docu- Integrazione del Sistema


mentazione di prova

Validazione del sistema Fase di Validazione del Sistema


Documentazione d’installazione
del sistema

Supporto in Sito

Documentazione di manutenzio-
ne del sistema

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 51 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
Fig. 4 Development Lifecycle 2

Software Maintenance Phase


System Development Phase
Software Maintenance Records
System Requirements Specification
Software Change Records
System Safety Requirements Specification
System Architecture Description
Software Assessment Phase
System Safety Plan
Software Assessment Report

Software Requirements Spec Phase


Software Validation Phase
Software Requirements Specification Software Validation Report
Software Requirements Test Specification
Software Requirements Verification Report

Software/hardware Integration Phase

Software/hardware Integration
Test Report
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

Software Planning Phase


Software Integration Phase
Software Architecture & Design Phase
Software Development Plan
Software Quality Assurance Plan Software Architecture Specification
Software Integration Test Report
Software Config Management Plan Software Design Specification
Software Verification Plan
Software Integration Test Plan
Software Architecture and Design
Software/hardware Integration Test Plan
Verification Report
Software Validation Plan
Software Maintenance Plan

Software Module Testing Phase


Software Module Design Phase
Software Module Test Report
Software Module Design Spec
Software Module Test Spec

Software Module Verification Report

Code Phase

Software Source Code & Supporting Documentation

Software Source Code Verification Report

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 52 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
Ciclo di vita di Sviluppo 2

Fase di Manutenzione del Software


Fase di Sviluppo del Sistema Registrazioni della Manutenzione del Software
Specifica dei Requisiti del Sistema Registrazioni dei Cambiamenti del Software
Specifica dei Requisiti di Sicurezza del Sistema
Descrizione dell’Architettura del Sistema
Fase di Valutazione del Software
Piano di Sicurezza del Sistema
Rapporto di Valutazione del Software

Fase di Specifica dei requisiti del Software Fase di Validazione del Software
Specifica dei Requisiti del Software Rapporto di Validazione del Software
Specifica di Prova dei Requisiti del Software
Rapporto di Verifica dei Requisisti del Software Fase di Integrazione Software/
Hardware
Rapporto di Prova dell’Integrazione
Software/Hardware
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

Fase di Pianificazione del Software Fase di Integrazione del Software


Fase di Progettazione ed
Piano di Sviluppo del Software Architettura Software
Piano di Assicurazione della Qualità del Specifica dell’Architettura del Software
Software Rapporto di Prova dell’Integrazione
Specifica della Progettazione del del Software
Piano di Gestione della Configurazione Software
del Software
Piano di Verifica del Software Architettura del Software e Rapporto
Rapporto di Prova dell’Integrazione del di Verifica del Progetto
Software
Piano di Prova dell’Integrazione Softwa-
re/Hardware
Piano di Manutenzione del Software
Fase di Prova del Modulo Software
Fase di Progettazione del Modulo Software
Rapporto di Prova del Modulo Software
Specifica della Progettazione del Modulo
Software
Specifica di Prova del Modulo Software

Rapporto di Verifica del Modulo Software

Fase di Codifica

Codice Sorgente del Software e Documentazione di Supporto


Rapporto di verifica del Codice Sorgente del Software

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 53 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
Fig. 5 Independence Versus Software Integrity Level

ASS'R

LEVEL 0 DI, VER, VAL

ASS'R

LEVELS 1 & 2
DI VER, VAL
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

PRJ MGR ASS'R

LEVELS 3 & 4
DI VER, VAL

OR

PRJ MGR ASS'R

LEVELS 3 & 4
DI VER VAL

KEY: = Can be the same person

= Can be the same company

DI = Designer/Implementer VER = Verifier VAL = Validator

ASS'R = Assessor PRJ MGR = Project Manager

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 54 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
Indipendenza in relazione al Livello di Integrità del
Software

ASS'R
LIVELLO 0 DI, VER, VAL

ASS'R

LIVELLI 1 & 2
DI VER, VAL
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

PRJ MGR ASS'R


LIVELLI 3 & 4
DI VER, VAL

PRJ MGR ASS'R

LIVELLI 3 & 4
DI VER VAL

SIGNIFICATO DELLE
ABBREVIAZIONI = Può essere la medesima persona

= Può essere la medesima società

DI = Progettista/Implementatore VER = Verificatore VAL = Validatore

ASS’R = Valutatore PRJ MNG = Responsabile del progetto

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 55 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
Fig. 6 Relationship between Generic System Develop-
ment and Application Development

Generic System Plant Application


Design and Engineering
Development

Requirements Plant
Specification Specification

Verification Verification

Sys tem Installation


Design Design
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

Verification Verification
System Plant
Validation Validation
and and
Certification Implementation Certification Production

Verification Verification

Sys tem Installation


Integration Testing

Verification Verification

Sys tem Acceptance &


Approval Commissioning

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 56 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
Relazione tra Sviluppo del Sistema Generico e Svi-
luppo dell’Applicazione

Progettazione e Sviluppo Ingegneria dell’Applicazione


del Sistema Generico di Impianto

Specifica dei Specifica


Requisiti dell’Impianto

Verifica Verifica

Progettazione Progettazione
del Sistema dell’Installazione

Validazione
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

Verifica Certificazione
e Certifica- Verifica
e Validazione
zione del dell’Impianto
Sistema
Implementazione Produzione

Verifica Verifica

Integrazione Prova
del Sistema dell’Installazione

Verifica Verifica

Approvazione
Accettazione
del Sistema
& Consegna

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 57 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
ANNEX/ALLEGATO
normative
A normativo CRITERIA FOR THE SELECTION OF CRITERI PER LA SCELTA DI TECNICHE E
TECHNIQUES AND MEASURES PROVVEDIMENTI
Each of clauses 7 to 16 of this European Stand- Ciascuna degli art. da 7 a 16 di questa Norma Eu-
ard has an associated clause table to illustrate ropea ha una tabella associata all’articolo per illu-
the means of achieving conformance. There ex- strare i mezzi per raggiungere la conformità. Vi
ist lower level tables, the detailed tables, which sono tabelle di livello inferiore, le tabelle di detta-
expand upon certain entries in the clause ta- glio, che approfondiscono certe voci nelle tabelle
bles. For example, Semi Formal Methods in the degli articoli. Per esempio, la tabella dei Metodi
clause 8 table is expanded upon in the detailed Semi-Formali dell’art. 8 viene approfondita nella
Table D.7. There also exists an informative an- tabella di dettaglio D.7. Vi è anche un Allegato B
nex B which is referred to from the clause ta- informativo che fa riferimento alle tabelle dei ca-
bles. pitoli.
With each technique or measure in the tables Nelle tabelle vi è un requisito, associato ad ogni tec-
there is a requirement for each software safety nica o provvedimento, per ogni livello di integrità di
integrity level (SWSIL), 1 to 4 and also for the sicurezza del software (SWSIL), da 1 a 4 e anche per
non safety-related level 0. In this version of the il livello 0 non di sicurezza,. In questa versione del
document, the requirements for software safety documento, i requisiti per i livelli di integrità di sicu-
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

integrity levels 1 and 2 are the same for each rezza del software 1 e 2 sono gli stessi per ogni tec-
technique. Similarly, each technique has the nica. Similmente, ogni tecnica ha gli stessi requisiti
same requirements at software safety integrity per i livelli di integrità di sicurezza del software 3 e
levels 3 and 4. These requirements can be: 4. Questi requisiti possono essere:

“M” questo simbolo significa che è obbligatorio l’uso di una tecnica;


this symbol means that the use of a technique is mandatory;
“HR” questo simbolo significa che la tecnica o il provvedimento sono Altamente Raccomandati
per questo livello di integrità di sicurezza. Se questa tecnica o provvedimento non è usata la
ragione per la quale non si usa dovrebbe essere dettagliata nel Piano di Assicurazione Qua-
lità del Software o in altro documento richiamato dal Piano di Assicurazione della Qualità
del Software;
this symbol means that the technique or measure is Highly Recommended for this safety integrity level. If
this technique or measure is not used then the rationale behind not using it should be detailed in the
Software Quality Assurance Plan or in another document referenced by the Software Quality Assurance
Plan;
“R” questo simbolo significa che la tecnica o il provvedimento è Raccomandato per questo livel-
lo di integrità di sicurezza. Questo, rispetto a “HR” è un livello inferiore di raccomandazione
e tali tecniche possono essere combinate per formare parte di un pacchetto;
this symbol means that the technique or measure is Recommended for this safety integrity level. This is a
lower level of recommendation than an “HR” and such techniques can be combined to form part of a
package;
“-” questo simbolo significa che la tecnica o il provvedimento non hanno raccomandazioni pro
o contro il loro uso;
this symbol means that the technique or measure has no recommendation for or against being used;
“NR” questo simbolo significa che la tecnica o il provvedimento è Non Raccomandato per questo
livello di integrità di sicurezza. Se questa tecnica o provvedimento è usata, la ragione per la
quale si usa dovrebbe essere dettagliata nel Piano di Assicurazione della Qualità del Softwa-
re o in altro documento richiamato dalPiano di Assicurazione della Qualità del Software.
this symbol means that the technique or measure is positively Not Recommended for this safety integrity
level. If this technique or measure is used then the rationale behind using it should be detailed in the
Software Quality Assurance Plan or in another document referenced by the Software Quality Assurance
Plan.

The combination of techniques or measures are La combinazione di tecniche o provvedimenti


to be stated in the Software Quality Assurance deve essere dichiarata nel Piano di Assicurazione
Plan or in another document referenced by the della Qualità del Software o in altro documento
Software Quality Assurance Plan with one or richiamato dal Piano di Assicurazione della Quali-
more techniques or measures being selected tà del Software selezionando una o più tecniche o
unless the notes attached to the table makes provvedimenti da selezionare, salvo che note in-
other requirements. These notes can include serite nella tabella prevedano altri requisiti. Que-
reference to approved techniques or approved ste note possono contenere riferimenti a tecniche
combinations of techniques. If such techniques consentite o a combinazioni di tecniche consenti-
or combinations of techniques are used, then te. Se sono usate tali tecniche o combinazioni di
the Assessor shall accept them as valid and shall tecniche, allora il Valutatore deve accettarle come
only be concerned that they have been correct- valide e deve solo essere preoccupato che esse si-

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 58 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
ly applied. If a different set of techniques is ano correttamente applicate. Se viene usata una
used and can be justified, then the Assessor diversa serie di tecniche e può essere giustificata,
may find this acceptable. il Valutatore può considerare questo accettabile.

Clause Tables Tabelle degli articoli

Tab. A.1 Lifecycle Issues and Documentation (clause 7) Argomenti del Ciclo di Vita e Documentazione
(art. 7)

DOCUMENTAZIONE SWSILO SWSIL1 SWSIL2 SWSIL3 SWSIL4


DOCUMENTATION
1. Documenti di Pianificazione del Software
R HR HR HR HR
Software Planning Documents
2. Documenti dei Requisiti S/W
R HR HR HR HR
S/W Requirements Documents
3. Documenti della Progettazione S/W
— HR HR HR HR
S/W Design Documents
4. Documenti del Modulo S/W
— HR HR HR HR
S/W Module Documents
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

5. Codice Sorgente & Documentazione R HR HR HR HR


Source Code & Documentation
6. Rapporti di Prova S/W
— HR HR HR HR
S/W Test Reports
7. Rapporto di Prova dell’Integrazione S/W & H/W
— HR HR HR HR
S/W & H/W Integration Test Report
8. Rapporto di Validazione S/W
R HR HR HR HR
S/W Validation Report
9. Rapporto di Valutazione S/W
— HR HR HR HR
S/W Assessment Report
10. Registrazioni di Manutenzione S/W
R HR HR HR HR
S/W Maintenance Records
Requisito
Requirement
La conformità con la EN ISO 9000-3 implica la produzione di documentazione adeguata per tutti i Livelli di
Integrità di Sicurezza del Software. Per Livello di Integrità di Sicurezza del Software 0 il progettista deve sce-
gliere tipi adeguati di documenti.
Compliance with EN ISO 9000-3 implies the production of adequate documentation for all Software Safety Integrity Levels.
For Software Safety Integrity Level 0, the designer shall choose suitable types of document.

Tab. A.2 Software Requirements Specification (clause 8) Specifica dei Requisiti del Software (art. 8)

TECNICA/PROVVEDIMENTO Ref SWSILO SWSIL1 SWSIL2 SWSIL3 SWSIL4


TECHNIQUE/MEASURE
1. Metodi Formali comprendenti per esempio CCS, CSP,
HOL, LOTOS, OBJ, Logica Temporale, VDM, Z e B B.30 R R HR HR
Formal Methods including for example CCS, CSP, HOL, —
LOTOS, OBJ, Temporal Logic, VDM, Z and B
2. Metodi Semi-Formali
D.7 R R R HR HR
Semi-Formal Methods
3. Metodologia Strutturata comprendente per esem-
pio JSD, MASCOT, SADT, SDL, SSADM, e Yourdon B.60 R HR HR HR HR
Structured. Methodology including for example JSD, MAS-
COT, SADT, SDL, SSADM, and Yourdon.
Requisiti
Requirements
1. La Specifica dei Requisiti del Software richiederà sempre una descrizione del problema in linguaggio natura-
le ed ogni necessaria notazione matematica riferita all’applicazione.
The Software Requirements Specification will always require a description of the problem in natural language and any
necessary mathematical notation that reflects the application.
2. La tabella riferisce requisiti addizionali per la definizione della specifica in modo chiaro e preciso. Una o più
di queste tecniche devono essere scelte per soddisfare il Livello di Integrità di Sicurezza del Software da
usare.
The table reflects additional requirements for defining the specification clearly and precisely. One or more of these tech-
niques shall be selected to satisfy the Software Safety Integrity Level being used.

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 59 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
Tab. A.3 Software Architecture (clause 9) Architettura del Software (art. 9)

TECNICA/PROVVEDIMENTO Ref SWSILO SWSIL1 SWSIL2 SWSIL3 SWSIL4


TECHNIQUE/MEASURE
1. Programmazione Difensiva
B.15 — R R HR HR
Defensive Programming
2. Rilevamento guasto & Diagnosi B.27 — R R HR HR
Fault Detection & Diagnosis
3. Codici di Correzione Errore B.20 — — — — —
Error Correcting Codes
4. Codici Rilevamento Errore B.20 — R R HR HR
Error Detecting Codes
5. Programmazione di Asserzione delmancato fun-
zionamento B.25 — R R HR HR
Failure Assertion Programming
6. Tecnica della valigetta di sicurezza (Safety bag)
B.54 — R R R R
Safety Bag Techniques
7. Programmazione Diversificata B.17 — R R HR HR
Diverse Programming
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

8. Blocco di Recupero (Recovery Block)


B.50 — R R R R
Recovery Block
9. Recupero all’indietro (Backward Recovery) B.5 — NR NR NR NR
Backward Recovery
10. Recupero in avanti (Forward Recovery) B.32 — NR NR NR NR
Forward Recovery
11. Meccanismo di ripetizione per il Recupero dal
Guasto B.53 — R R R R
Re-try Fault Recovery Mechanisms
12. Memorizzazione dei Casi Eseguiti
B.39 — R R HR HR
Memorising Executed Cases
13. Intelligenza Artificiale- Correzione del guasto B.1 — NR NR NR NR
Artificial Intelligence - Fault Correction
14. Riconfigurazione dinamica del software B.18 — NR NR NR NR
Dynamic Reconfiguration of software
15. Analisi dell’Effetto dell’Errore Software B.26 — R R HR HR
Software Error Effect Analysis
16. Analisi dell’Albero dei Guasti B.28 R R R HR HR
Fault Tree Analysis
Requisiti
Requirements
1. Le combinazioni consentite delle tecniche per i Livelli 3 e 4 di Integrità di Sicurezza del Software devono
essere le seguenti:
Approved combinations of techniques for Software Safety Integrity Levels 3 and 4 shall be as follows:
a 1, 7 e una da 4, 5 o 12
1, 7 and one from 4, 5 or 12
b 1, 4 e 5
1, 4 and 5
c 1, 4 e 12
1, 4 and 12
d 1, 2 e 4
1, 2 and 4
e 1 e 4, e una tra 15 e 16
1 and 4, and one of 15 and 16
2. Con l’eccezione delle voci 3, 9, 10, 13 e 14, una o più di queste tecniche devono essere scelte per soddisfa-
re i requisiti per i Livelli di Integrità di Sicurezza del Software 1 e 2.
With the exception of entries 3, 9, 10, 13 and 14, one or more of these techniques shall be selected to satisfy the require-
ments for Software Safety Integrity Levels 1 and 2.
3. Alcune di queste indicazioni possono essere definite a livello di sistema.
Some of these issues may be defined at the system level.
4. I codici di correzione dell’errore possono essere usati in accordo con i requisiti della EN 50159-1 ed EN 50159-2.
Error correcting codes may be used in accordance with the requirements of EN 50159-1 and EN 50159-2.

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 60 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
Tab. A.4 Software Design and Implementation (clause 10) Progettazione del Software ed Implementazione
(art. 10)

TECNICA/PROVVEDIMENTO Ref SWSILO SWSIL1 SWSIL2 SWSIL3 SWSIL4


TECHNIQUE/MEASURE
1. Metodi Formali comprendenti ad esempio CCS, CSP,
HOL, LOTOS, OBJ, Logica Temporale, VDM, Z e B B.30 — R R HR HR
Formal Methods including for example CCS, CSP, HOL,
LOTOS, OBJ, Temporal Logic, VDM, Z and B
2. Metodi Semi Formali
D.7 R HR HR HR HR
Semi-FormaI Methods
3. Metodologia Strutturata comprendente ad esem-
pio JSD, MASCOT, SADT, SDL, SSADM e Yourdon. B.60 R HR HR HR HR
Structured. Methodology including for example JSD, MAS-
COT, SADT, SDL, SSADM and Yourdon.
4. Approccio Modulare
D.9 HR M M M M
Modular Approach
5. Standard di Progettazione di Codifica D.1 HR HR HR M M
Design and Coding Standards
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

6. Programmi Analizzabili B.2 HR HR HR HR HR


Analysable Programs
7. Linguaggio di Programmazione Fortemente Tipizzato B.57 R HR HR HR HR
Strongly Typed Programming Language
8. Programmazione Strutturata B.61 R HR HR HR HR
Structured Programming
9. Linguaggio di Programmazione D.4 R HR HR HR HR
Programming Language
10. Sottoinsieme del Linguaggio B.38 — — — HR HR
Language Subset
11. Traduttore Validato B.7 R HR HR HR HR
Validated Translator
12. Traduttore Provato con l’Uso B.65 HR HR HR HR HR
Translator Proven in Use
13. Libreria di Moduli e Componenti Affidabili/Verificati B.40 R R R R R
Library of Trusted/Verified Modules and Components
14. Prove Funzionali/ a Scatola Chiusa (Black-box) D.3 HR HR HR M M
Functional/ Black-box Testing
15. Prove di Prestazione D.6 — HR HR HR HR
Performance Testing
16. Prove sulle Interfacce B.37 HR HR HR HR HR
Interface Testing
17. Registrazione e Analisi dei Dati B.13 HR HR HR M M
Data Recording and Analysis
18. Logica Fuzzy B.67 — — — — —
Fuzzy Logic
19. Programmazione Orientata all’Oggetto B.68 — R R R R
Object Oriented Programming
Requisiti
Requirements
1. Deve essere scelto un’insieme di tecniche secondo il livello di integrità di sicurezza del software.
A suitable set of techniques shall be chosen according to the software safety integrity level.
2. Per il livello di integrità di sicurezza del software 3 o 4, l’insieme consentito di tecniche deve comprendere
una delle tecniche 1, 2 o 3, insieme ad una delle tecniche 11 o 12. Le restanti tecniche devono essere trat-
tate ancora secondo le rispettive raccomandazioni.
At software safety integrity level 3 or 4, the approved set of techniques shall include one of techniques 1, 2 or 3, together
with one of techniques 11 or 12. The remaining techniques shall still be treated according to their recommendations.

NORMA TECNICA
CEI EN 50128:2002-04
Pagina 61 di 128
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano
RIPRODUZIONE SU LICENZA CEI AD ESCLUSIVO USO AZIENDALE
Tab. A.5 Verification and Testing (clause 11) Verifica e Prove (art. 11)

TECNICA/PROVVEDIMENTO Ref SWSILO SWSIL1 SWSIL2 SWSIL3 SWSIL4


TECHNIQUE/MEASURE
1. Prova Formale B.31 — R R HR HR
Formal Proof
2. Prove Probabilistiche