Cei en 50128

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
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.
Europäische Norm • Norme Européenne • European Standard • Norma Europea
EN 50128

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
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
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
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
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
8 SOFTWARE REQUIREMENTS SPECIFICATION SPECIFICA DEI REQUISITI DEL SOFTWARE 18

8.2 Input documents ............................................................................ Documenti d’ingresso ................................................................ 18
8.3 Output documents ........................................................................ Documenti di uscita .................................................................... 18
9 SOFTWARE ARCHITECTURE ARCHITETTURA DEL SOFTWARE 20


10 SOFTWARE DESIGN AND PROGETTAZIONE ED IMPLEMENTAZIONE

IMPLEMENTATION DEL SOFTWARE 22
11 SOFTWARE VERIFICATION AND TESTING VERIFICA E PROVA DEL SOFTWARE 26

12 SOFTWARE/HARDWARE INTEGRATION INTEGRAZIONE SOFTWARE/HARDWARE 30

13 SOFTWARE VALIDATION VALIDAZIONE DEL SOFTWARE 32

14 SOFTWARE ASSESSMENT VALUTAZIONE DEL SOFTWARE 34

15 SOFTWARE QUALITY ASSURANCE ASSICURAZIONE DELLA QUALITÀ DEL SOFTWARE 35

NORMA TECNICA
CEI EN 50128:2002-04
Pagina v
16 SOFTWARE MAINTENANCE MANUTENZIONE DEL SOFTWARE 38

17 SYSTEMS CONFIGURED BY SISTEMI CONFIGURATI CON DATI

APPLICATION DATA DELL’APPLICAZIONE 40
ANNEX/ALLEGATO
A CRITERIA FOR THE SELECTION OF TECHNIQUES AND CRITERI PER LA SCELTA DI TECNICHE E
MEASURES PROVVEDIMENTI 58
ANNEX/ALLEGATO
B BIBLIOGRAPHY OF TECHNIQUES BIBLIOGRAFIA DELLE TECNICHE 70
NORMA TECNICA
CEI EN 50128:2002-04
Pagina vi
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
(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
NORMA TECNICA
CEI EN 50128:2002-04
Pagina viii
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
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
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;
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
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-
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
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-
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
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
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
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
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
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

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
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

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
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.
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
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
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
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,
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
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À

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.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
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.
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
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.
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.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
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-
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
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)

♦ ♦ 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
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
♦ ♦ 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
8 SOFTWARE REQUIREMENTS SPECIFICATION SPECIFICA DEI REQUISITI DEL SOFTWARE
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

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.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
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-
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.
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.
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
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.
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.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.


Software Architecture Specification Specifica dell’Architettura del Software
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
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.
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-
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 provare 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
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
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.
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.
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.
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.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
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.

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


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.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
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.
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
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-
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
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
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

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.

4) Software Requirements Test Specification 4) Specifica di Prova dei Requisiti 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
9) Software Source code and supporting docu- 9) Codice Sorgente del Software e documenta-
mentation zione di supporto
11) Software Module Test Report 11) Rapporto di Prova del Modulo Software

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
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.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 verificati figlio che naturalmente possono essere aggiunti,
tion become clearer. mentre divengono più chiare le dettagliate neces-
sità di verifica.
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
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:
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
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
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
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.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.

5) Software Requirements Test Specification 5) Specifica di prova dei Requisiti 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
10) Software Source code and supporting docu- 10) Codice Sorgente del Software e documentazio-
mentation ne di supporto
11) Hardware documentation 11) Documentazione Hardware

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.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
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.
shall distinguish between those activities which ware deve distinguere tra quelle attività che pos-
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.
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
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

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.


2) All Hardware and Software Documentation 2) Tutta la Documentazione Hardware e Software

1) Software Validation Plan 1) Piano di Validazione del Software
2) Software Validation Report 2) Rapporto di Validazione del Software
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
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-
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
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

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.

2) All Hardware and Software Documentation 2) Tutta la documentazione Hardware e Software

Software Assessment Report Rapporto di Valutazione del Software
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
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
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.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.

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
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.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.
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
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
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
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;
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

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.

All documents Tutti i documenti
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 38 di 128
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.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-
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 conca, 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
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
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.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
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
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.


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.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
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
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 documentare 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
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
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
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.
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
– BLANK PAGE – – PAGINA BIANCA –
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 45 di 128
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

EQUIPMENT 3 - High
2 - Medium
UNDER CONTROL
1 - Low
0 - Non-safety
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

4 – Molto Alto
APPARECCHIATURA 3 – Alto
SOTTO CONTROLLO 2 – Medio
2 – Basso
0 – Non in Sicurezza
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
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
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
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
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
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
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
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
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
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
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
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
Fig. 5 Independence Versus Software Integrity Level
ASS'R
LEVEL 0 DI, VER, VAL
ASS'R
LEVELS 1 & 2
DI VER, VAL
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
Indipendenza in relazione al Livello di Integrità del
Software
ASS'R
LIVELLO 0 DI, VER, VAL
ASS'R
LIVELLI 1 & 2
DI VER, VAL
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
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
System Plant
Validation Validation
and and
Certification Implementation Certification Production
Sys tem Installation

Integration Testing
Sys tem Acceptance &

Approval Commissioning
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 56 di 128
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
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
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-
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
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
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
Tab. A.3 Software Architecture (clause 9) Architettura del Software (art. 9)

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
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
Tab. A.4 Software Design and Implementation (clause 10) Progettazione del Software ed Implementazione
(art. 10)

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
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
Tab. A.5 Verification and Testing (clause 11) Verifica e Prove (art. 11)

TECHNIQUE/MEASURE
1. Prova Formale B.31 — R R HR HR
Formal Proof
2. Prove Probabilistiche B.47 — R R HR HR
Probabilistic Testing
3. Analisi Statistica D.8 — HR HR HR HR
Static Analysis
4. Analisi Dinamica e Prove D.2 — HR HR HR HR
Dynamic Analysis and Testing
5. Metriche B.42 — R R R R
Metrics
6. Matrice di Tracciabilità B.69 — R R HR HR
Traceability Matrix
7. Analisi dell’Effetto dell’Errore Software B26 — R R HR HR
Requisiti
Requirements
1. Per il Livello di Integrità di Sicurezza del Software 3 o 4, le combinazioni di Tecniche consentite devono es-
sere:
For Software Safety Integrity Level 3 or 4, the approved combinations of techniques shall be:
a 1e4
1 and 4
b 3e4
3 and 4
o c) 4, 6 e 7
or 4, 6 and 7
2. Per il Livello di Integrità di Sicurezza del Software 1 o 2 le Tecniche consentite devono essere 1 o 4.
For Software Safety Integrity Level 1 or 2, the approved technique shall be 1 or 4.
Tab. A.6 Software/Hardware Integration (clause 12) Integrazione Software/Hardware (art. 12)

TECHNIQUE/MEASURE
1. Prove funzionali ed a Scatola Chiusa (Black-box) D.3 HR HR HR HR HR
Functional and Black-box Testing
2. Prove di Prestazione D.6 — R R HR HR
Performance Testing
Requisiti
Requirements
1. Per il livello di integrità di sicurezza del software 0 , sarà consentita la tecnica 1.
For software safety integrity level 0, technique 1 shall be the approved technique.
2. Per il livello di integrità di sicurezza del software 1, 2, 3 o 4, sarà consentita la combinazione di tecniche
1 e 2.
For software safety integrity level 1, 2, 3 or 4, the approved combination of techniques shall be 1 and 2.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 62 di 128
Tab. A.7 Software Validation (clause 13) Validazione del Software (art. 13)

TECHNIQUE/MEASURE
1. Prove Probabilistiche B.47 — R R HR HR
Probabilistic Testing
2. Prove di Prestazione D.6 — HR HR M M
Performance Testing
3. Prove Funzionali ed a Scatola Chiusa (Black-box) D.3 HR HR HR M M
Functional and Black-box Testing
4. Modellazione D.5 — R R R R
Modelling
Prescrizioni
Requirement
1. Per il Livello di Integrità di Sicurezza del Software 1, 2, 3 o 4, una combinazione di Tecniche consentite sarà
2 e 3.
For Software Safety Integrity Level 1, 2, 3 or 4, an approved combination of techniques shall be 2 and 3.
Tab. A.8 Clauses to be assessed Articoli da valutare
ARTICOLI DA VALUTARE Articolo SWSILO SWSIL1 SWSIL2 SWSIL3 SWSIL4

CLAUSE TO BE ASSESSED Clause
1. Livelli di Integrità di Sicurezza S/W 5 HR HR HR HR HR
S/W Safety Integrity Levels
2. Personale & Responsabilità 6 — R R HR HR
Personnel & Responsibility
3. Ciclo di vita & Documentazione 7 — HR HR HR HR
Lifecycle & Documentation
4. Spec. Requisiti S/W 8 R HR HR HR HR
S/W Requirements Spec.
5. Architettura S/W 9 — R R HR HR
S/W Architecture
6. Progettazione & Sviluppo 10 — R R HR HR
Design & Development
7. Verifica 11 — HR HR HR HR
Verification
8. Integrazione S/W/H/W 12 — R R HR HR
S/W/H/W Integration
9. Validazione S/W 13 — HR HR HR HR
S/W Validation
10. Assicurazione Qualità 15 — HR HR HR HR
Quality Assurance
11. Manutenzione 16 — HR HR HR HR
Maintenance
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 63 di 128
Tab. A.9 Software Assessment (clause 14) Valutazione Software (art. 14) Tecniche di Valutazione
Assessment Techniques
ASSESSMENT TECHNIQUE Ref SWSILO SWSIL1 SWSIL2 SWSIL3 SWSIL4

ASSESSMENT TECHNIQUE
1. Liste di controllo B.8 HR HR HR HR HR
Checklists
2. Analisi Statica del Software
R HR HR HR HR
Static Software Analysis
B.14
B.42
D.8
3. Analisi Dinamica del Software
Dynamic Software Analysis
D.2 — R R HR HR
D.3
4. Diagrammi causa conseguenza
B.6 R R R R R
Cause Consequence Diagrams
5. Analisi dell’Albero degli Eventi B.23 — R R R R

Event Tree Analysis
6. Analisi dell’Albero dei Guasti B.28 R R R HR HR
Fault Tree Analysis
7. Analisi dell’Effetto dell’Errore Software B.26 — R R HR HR
8. Analisi dei mancati funzionamenti di Causa Comune B.10 — R R HR HR
Common Cause Failure Analysis
9. Modelli di Markov B.41 — R R R R
Markov Models
10. Diagramma a Blocchi dell’Affidabilità B.51 — R R R R
Reliability Block Diagram
11. Prova sul Campo Prima della Messa in Servizio — R HR HR HR HR
Field Trial Before Commissioning
Requisito
Requirement
1. Deve essere scelta una o più di queste tecniche per soddisfare il Livello di Integrità di Sicurezza del Softwa-
re che deve essere usato.
One or more of these techniques shall be selected to satisfy the Software Safety Integrity Level being used.
Tab. A.10 Software Quality Assurance (clause 15) Assicurazione della Qualità del Software (art. 15)
TECNICA/PROVVEDIMENTO Articolo o
TECHNIQUE/MEASURE Clause or SWSILO SWSIL1 SWSIL2 SWSIL3 SWSIL4
Ref
1. Accreditato alla EN ISO 9001
15 R HR HR HR HR
Accredited to EN ISO 9001
2. Conforme con la EN ISO 9000-3 15 M M M M M
Compliant with EN ISO 9000-3
3. Sistema Qualità della Società 15 M M M M M
Company Quality System
4. Gestione della Configurazione del Software B.56 M M M M M
Software Configuration Management
Tab. A.11 Software Maintenance (clause 16) Manutenzione del Software (art. 16)

TECHNIQUE/MEASURE
1. Analisi dell’Impatto B.35 R HR HR M M
Impact Analysis
2. Registrazione e Analisi dei Dati B.13 HR HR HR M M
Data Recording and Analysis
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 64 di 128
Detailed Tables Tabelle Dettagliate
Tab. A.12 Design and Coding Standards (D.1) Standard di Progettazione e di Codifica (D.1)
Referenced by clause 10 Riferimento all’art. 10

TECHNIQUE/MEASURE
1. Esiste lo Standard di Codifica B.16 HR HR HR HR HR
Coding Standard Exists
2. Guida allo stile di Codifica B.16 HR HR HR HR HR
Coding Style Guide
3. Nessun Oggetto Dinamico B.16 — R R HR HR
No Dynamic Objects
4. Nessuna Variabile Dinamica B.16 — R R HR HR
No Dynamic Variables
5. Uso Limitato di Puntatori B.16 — R R R R
Limited Use of Pointers
a) Uso Limitato di Ricorsioni B.16 — R R HR HR
Limited Use of Recursion
6. Nessun Salto Incondizionato

B.16 — HR HR HR HR
No Unconditional Jumps
Requisito
Requirement
1. È accettato che le tecniche 3, 4 e 5 possano essere presenti come parte di un compilatore o traduttore vali-
dato.
It is accepted that techniques 3, 4 and 5 may be present as part of a validated compiler or translator.
2. Deve essere scelto un’insieme adatto di tecniche secondo il livello di integrità di sicurezza del software.
Tab. A.13 Dynamic Analysis and Testing (D.2) Analisi e Prova Dinamiche (D.2)
Referenced by clauses 11 and 14 Riferimento all’art. 11 e 14

TECHNIQUE/MEASURE
1. Esecuzione del Caso di Prova dall’Analisi del Valo-
re limite B.4 — HR HR HR HR
Test Case Execution from Boundary Value Analysis
2. Esecuzione del Caso di Prova dalla Supposizione
di Errori B.21 R R R R R
Test Case Execution from Error Guessing
3. Esecuzione del Caso di Prova dalla Semina di Errori
B.22 — R R R R
Test Case Execution from Error Seeding
4. Modellazione delle Prestazioni B.45 — R R HR HR
Performance Modelling
5. Classi di Equivalenza e Prove di Partizione dei dati
di Ingresso B.19 — R R HR HR
Equivalence Classes and Input Partition Testing
6. Prove Basate sulla Struttura
B.58 — R R HR HR
Structure-Based Testing
Requisiti
Requirements
1. L’analisi per i casi di prova è a livello di sottosistema ed è basata sulla specifica e/o sulla specifica ed il codice.
The analysis for the test cases is at the sub-system level and is based on the specification and/or the specification and the
code.
2. Deve essere scelto un insieme adatto di tecniche secondo il livello di integrità di sicurezza del software.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 65 di 128
Tab. A.14 Functional/Black Box Test (D.3) Prove Funzionali/ a Scatola Chiusa (Black-box) (D.3)
Referenced by clauses 10,12, 13 and 14 Riferimento all’art. 10,12, 13 e14

TECHNIQUE/MEASURE
1. Esecuzione del Caso di Prova dai Diagrammi Causa
Conseguenza B.6 — — — R R
Test Case Execution from Cause Consequence Diagrams
2. Prototipazione/Animazione
B.49 — — — R R
Prototyping/Animation
3. Analisi del Valore limite B.4 R HR HR HR HR
Boundary Value Analysis
4. Classi di Equivalenza e Prova di Partizione dei dati di
Ingresso B.19 R HR HR HR HR
Equivalence Classes and Input Partition Testing
5. Simulazione di Processo
B.48 R R R R R
Process Simulation
Requisiti
Requirements
1. La completezza della simulazione dipenderà dall’ampiezza del livello di integrità di sicurezza del software,
dalla complessità e dall’applicazione.
The completeness of the simulation will depend upon the extent of the software safety integrity level, complexity and application.
2. Deve essere scelto un’insieme adatto di tecniche secondo il livello di integrità di sicurezza del software.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 66 di 128
Tab. A.15 Programming Languages (D.4) Linguaggi di Programmazione (D.4)

TECHNIQUE/MEASURE
1. ADA B.62 R HR HR R R
2. MODULA-2 B.62 R HR HR R R
MODULA-2
3. PASCAL B.62 R HR HR R R
4. Fortran 77 B.62 R R R R R
5. “C” or C++ (senza restrizioni) B.62 R — — NR NR
“C” or C++ (unrestricted)
6. Sottoinsieme di C o C++ con standard di codifica B.62
R R R R R
Subset of C or C++ with coding standards B.38
7. L/M B.62 R R R NR NR
8. BASIC B.62 R NR NR NR NR
9. Assembler B.62 R R R — —
10. Diagrammi a Scala B.62 R R R R R

Ladder Diagrams
11. Blocchi Funzionali B.62 R R R R R
Functional Blocks
12. Lista delle Dichiarazioni B.62 R R R R R
Statement List
Requisiti
Requirements
1. Per il livello di Integrità di Sicurezza del Software 3 e 4 quando è usato un sottoinsieme dei linguaggi 1, 2, 3
e 4 la raccomandazione cambia a HR.
At Software Safety Integrity Level 3 and 4 when a subset of languages 1, 2, 3 and 4 are used the recommendation changes to HR.
2. Per certe applicazioni i linguaggi 7 e 9 possono essere i soli disponibili. Per il livello di Integrità di Sicurezza
del Software 3 e 4 se non è disponibile una opzione Altamente raccomandata è fortemente consigliato che
ci sia un sottoinsieme di questi linguaggi ed un preciso insieme di standard di codifica per innalzare la rac-
comandazione ad ‘R’.
For certain applications the languages 7 and 9 may be the only ones available. At Software Safety Integrity Level 3 and 4
where a Highly recommended option is not available it is strongly recommended that to raise the recommendation to “R”
there should be a subset of these languages and that there should be a precise set of coding standards.
3. Per informazioni sulla valutazione di idoneità di un linguaggio di programmazione vedere la voce nella bi-
bliografia di “Linguaggi di Programmazione Adatti”, B.62.
For information on assessing the suitability of a programming language see entry in the bibliography for “Suitable Pro-
gramming Language” B.62.
4. Se un linguaggio specifico non è nella tabella, non è automaticamente escluso. Esso dovrebbe essere co-
munque conforme a B.62.
If a specific language is not in the table, it is not automatically excluded. It should, however, conform to B.62.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 67 di 128
Tab. A.16 Modelling (D.5) Modellazione (D.5)

TECHNIQUE/MEASURE
1. Diagrammi di Flusso dei Dati
B.12 — R R R R
Data Flow Diagrams
2. Macchine a Stato Finito
Finite State Machines
3. Metodi FormaIi
B.30 — R R HR HR
FormaI Methods
4. Modellazione delle Prestazioni
B.45 — R R HR HR
Performance Modelling
5. Reti di Petri temporali
Time Petri Nets
6. Prototipazione/Animazione
B.49 — R R R R
Prototyping/Animation
7. Diagrammi Strutturati
B.59 — R R HR HR
Structure Diagrams
Requisiti
Requirement
1. Deve essere scelto un’insieme adatto di tecniche secondo il livello di integrità di sicurezza del software..
Tab. A.17 Performance Testing (D.6) Prove di Prestazione (D.6)

Referenced by clauses 10, 12 and 13 Riferimento all’art. 10, 12 e 13

TECHNIQUE/MEASURE
1. Prove di sovraccarico (Avalanche /Stress)
B.3 — R R HR HR
Avalanche/Stress Testing
2. Tempi di risposta e vincoli di Memoria
Response Timing and Memory Constraints
3. Requisiti di Prestazione
Performance Requirements
Requisiti
Requirement
Deve essere scelto un’ insieme adatto di tecniche secondo il livello di integrità di sicurezza del software.
Tab. A.18 Semi-Formal Methods (D.7) Metodi Semi-Formali (D.7)


TECHNIQUE/MEASURE
1. Diagr. Dei Blocchi Logici /Funzionali — R R R HR HR
Logic/Function Block Diags
2. Diagrammi di Sequenza — R R R HR HR
Sequence Diagrams
3. Diagrammi di Flusso dei dati B.12 R R R R R
Data flow Diagrams
4. Macchine a Stati Finiti/ Diagrammi di Transizione
dello stato B.29 — R R HR HR
Finite State Machines/State Transition Diagrams
5. Reti di Petri temporali
B.64 — R R HR HR
Time Petri Nets
6. Tavole di Decisione /di Verità B.14 R R R HR HR
Decision/Truth Tables
Requisiti
Requirement
Deve essere scelto un’ insieme adatto di tecniche secondo il livello di integrità di sicurezza del software.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 68 di 128
Tab. A.19 Static Analysis (D.8) Analisi Statica (D.8)

TECHNIQUE/MEASURE
1. Analisi del Valore limite B.4 — R R HR HR
Boundary Value Analysis
2. Liste di controllo B.8 — R R R R
Checklists
3. Analisi del Flusso di controllo B.9 — HR HR HR HR
ControI Flow Analysis
4. Analisi del Flusso dei Dati B.11 — HR HR HR HR
Data Flow Analysis
5. Supposizione di Errore B.21 — R R R R
Error Guessing
6. lspezioni di Fagan B.24 — R R HR HR
Fagan lnspections
7. Analisi di circuito ingannevole B.55 — — — R R
Sneak Circuit Analysis

8. Esecuzione Simbolica B.63 — R R HR HR
Symbolic Execution
9. Analisi di Percorso (Walkthroughs) / Riesame della
progettazione B.66 HR HR HR HR HR
Walkthroughs/Design Reviews
Requisiti
Requirement
Deve essere scelto un’ insieme adatto di Tecniche secondo il livello di integrità di sicurezza del software.
Tab. A.20 Modular Approach (D.9) Approccio– Modulare (D.9)


TECHNIQUE/MEASURE
1. Dimensione del Modulo Limitata B.43 HR HR HR HR HR
Module Size Limited
2. Occultamento/Incapsulamento delle informazioni B.36 R HR HR HR HR
Information Hiding/Encapsulation
3. Limite del Numero dei Parametri B.43 R R R R R
Parameter Number Limit
4. Punti ad Una Sola Entrata /Una Sola Uscita nelle
Subroutine e nelle Funzioni B.43 R HR HR HR HR
One Entry/One Exit Point in Subroutines and Functions
5. Interfaccia Completamente definita
B.43 HR HR HR M M
Fully Defined Interface
Requisiti
Requirement
Deve essere scelto un’insieme adatto di tecniche secondo il livello di integrità di sicurezza del software.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 69 di 128
ANNEX/ALLEGATO
informative
B informativo BIBLIOGRAPHY OF TECHNIQUES BIBLIOGRAFIA DELLE TECNICHE
B.1 AI Fault Correction (Referenced by clause 9) Correzione del Guasto AI (Riferimento all’art. 9)
Aim Scopo
To be able to react to possible hazards in a very Essere in grado di reagire a possibili pericoli in un
flexible way by introducing a mix (combina- modo molto flessibile introducendo un mix (combi-
tion) of methods and process models and some nazione) di metodi e modelli di processo ed alcuni
kind of on-line safety and reliability analysis. tipi di analisi di sicurezza e affidabilità in linea.
Description Descrizione
In particular fault forecasting (calculating In particolare la previsione guasti (calcolo degli
trends), fault correction, maintenance and su- andamenti), la correzione guasti, le azioni di ma-
pervisory actions may be supported by nutenzione e di supervisione possono essere sup-
AI-based systems in a very efficient way in di- portate dai sistemi basati su AI in un modo molto
verse channels of a system, since the rules efficace in diversi canali di un sistema, poiché le
might be derived directly from the specifica- regole possono essere derivate direttamente dalle
tions and checked against these. Certain com- specifiche e possono essere verificate in base a
mon faults which are introduced into specifica- queste. Certi guasti comuni che sono introdotti
tions by implicitly already having some design nelle specifiche implicitamente avendo già in
and implementation rules in mind may be mente alcune regole di progetto e di implementa-
avoided effectively by this approach, especially zione, possono essere evitati in modo efficace
when applying a combination of models and con questo approccio, specialmente quando si
methods in a functional or descriptive manner. applica una combinazione di modelli e metodi in
un modo funzionale e descrittivo.
The methods are selected such that faults may I metodi sono selezionati in modo tale che i gua-
be corrected and the effects of failures be mini- sti possono essere corretti ed essere minimizzati
mised, in order to meet the desired safety and gli effetti delle avarie, in modo da ottenere la si-
reliability. curezza e l’affidabilità desiderate.
B.2 Analysable Programs (Referenced by Programmi Analizzabili (Riferimento

clause 10) all’art. 10)
Aim Scopo
To design a program in a way that program Progettare un programma in modo che sia facil-
analysis is easily feasible. The program behav- mente eseguibile la sua analisi. Il comportamento
iour must be testable completely on the basis of del programma lo si deve poter provare in modo
the analysis. completo sulla base dell’analisi.
The intention is to produce programs which are L’intenzione è di produrre programmi che siano
easy to analysis using static analysis methods. In facilmente analizzabili usando metodi di analisi
order to achieve this, the rules of structured statica. A tale fine, devono essere seguite le rego-
programming should be followed, for instance: le della programmazione strutturata, per esempio:
the module control flow should be com- il flusso del controllo del modulo dovrebbe
posed of structured constructs, that is se- essere composto da costrutti strutturarti, cioè
quences, iterations and selection. sequenze, iterazioni e selezioni.
the modules should be small. i moduli dovrebbero essere piccoli.
the number of possible paths through a il numero dei possibili percorsi attraverso il
module is small. modulo è piccolo.
the individual program parts have to be de- le parti individuali del programma devono es-
signed so that they are decoupled as far as sere progettate in modo che esse possano es-
possible. sere il più possibile disaccoppiate.
the relation between the input and output le relazioni tra i parametri d’ingresso e di usci-
parameters should be as simple as possible. ta dovrebbero essere le più semplici possibili.
complex calculations should not be used as non dovrebbero essere usati calcoli complessi
the basis of branching and loop decisions. come base delle decisioni di diramazione e di
costrutti iterativi
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 70 di 128
branch and loop decisions should be simply le decisioni di diramazione e dei costrutti ite-
related to the module input parameters. rativi dovrebbero essere semplicemente cor-
relate con i parametri d’ingresso del modulo.
boundaries between different types of map- i confini tra i diversi tipi di mappatura devono
pings shall be simple. essere semplici.
References: Riferimenti:
Verification - The Practical Problems. B.J.T. Verification - The Practical Problems. B.J.T. Webb
Webb and D.J. Mannering, SARSS 87, Nov. 1987, and D.J. Mannering, SARSS 87, Nov. 1987, Altrin-
Altrincham, England, Elsevier Applied Science, cham, England, Elsevier Applied Science, ISBN
ISBN 1-85166-167-0, 1987. 1-85166-167-0, 1987.
An Experience in Design and Validation of Soft- An Experience in Design and Validation of Sof-
ware for a Reactor Protection System.S. Bolo- tware for a Reactor Protection System.S. Bologna,
gna, E. de Agostino et. al., IFAC Workshop, SA- E. de Agostino et. al., IFAC Workshop, SAFE-
FECOMP 1979, Stuttgart, 16-18 May1979, COMP 1979, Stuttgart, 16-18 May1979, Pergamon
Pergamon Press 1979. Press 1979.
B.3 Avalanche/Stress Testing Prove di sovraccarico (Avalanche/Stress)

(Referenced by D.6) (Riferimento a D.6)
Aim Scopo
To burden the test object with an exceptionally Gravare l’oggetto della prova con un carico di la-
high workload in order to show that the test ob- voro eccezionalmente elevato per dimostrare che
ject would stand normal workloads easily. l’oggetto della prova potrebbe sopportare facil-
mente carichi di lavoro normali.
There are a variety of test conditions which can Vi sono una varietà di condizioni di prova che
be applied for avalanche/stress testing. Some of possono essere applicate per le prove a valan-
these test conditions are listed below: ga/da sforzo. Alcune di queste condizioni di pro-
va sono elencate nel seguito:
if working in a polling mode then the test se si lavora in una modalità di interrogazione
object gets much more input changes per ciclica, l’oggetto della prova riceve molti più
time unit as under normal conditions; cambiamenti d’ingresso per unità di tempo
che in condizioni normali;
if working on demands then the number of se si lavora su domanda, il numero delle do-
demands per time unit to the test object is mande per unità di tempo all’oggetto della
increased beyond normal conditions; prova è aumentato oltre le condizioni normali;
if the size of a database plays an important se la dimensione della base dei dati gioca un
role then it is increased beyond normal ruolo importante, essa è aumentata oltre le
conditions; condizioni normali;
influential devices are tuned to their maxi- dispositivi influenti sono sintonizzati alla loro
mum speed or lowest speed respectively; massima velocità o rispettivamente alla loro
velocità più bassa;
for the extreme cases, all influential factors, nei casi estremi, tutti i fattori d’influenza, per
as far as is possible, are put to the boundary quanto possibile, sono posti nelle condizioni
conditions at the same time. limite contemporaneamente.
Under these test conditions the time behaviour In queste condizioni di prova può essere valutato
of the test object can be evaluated. The influ- il comportamento nel tempo dell’oggetto di pro-
ence of load changes can be observed. The cor- va. Può essere osservata l’influenza dei cambia-
rect dimension of internal buffers or dynamic menti di carico. Possono essere verificate le cor-
variables, stacks etc can be checked. rette dimensioni dei buffer interni o delle variabili
dinamiche, stack ecc.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 71 di 128
B.4 Boundary Value Analysis (Referenced by D.2, Analisi del Valore limite (Riferimento a D.2,
D.3 and D.8) D.3 e D.8)
Aim Scopo
To remove software errors occurring at parame- Rimuovere gli errori del software che si verificano
ter limits or boundaries. attraverso parametri ai confini o ai limiti.
The input domain of the program is divided into a Il dominio d’ingresso del programma è diviso in
number of input classes. The tests should cover una serie di classi d’ingresso. Le prove dovrebbe-
the boundaries and extremes of the classes. The ro coprire i limiti e gli estremi delle classi. Le pro-
tests check that the boundaries in the input dove verificano che i limiti nel dominio d’ingresso
main of the specification coincide with those in della specifica coincidano con quelli nel program-
the program. The use of the value zero, in a direct ma. L’uso del valore zero, in una traduzione sia
as well as in an indirect translation, is often er- diretta che indiretta è spesso incline all’errore e ri-
ror-prone and demands special attention: chiede una attenzione particolare:
zero divisor; divisore zero;
blank ASCII characters; caratteri ASCII di spazio;
empty stack or list element; stack vuoto o elemento di elenco;

null matrix; matrice nulla;
zero table entry. inserimento di tabella zero.
Normally the boundaries for input have a direct Normalmente i confini per l’ingresso hanno una
correspondence to the boundaries for the out- corrispondenza diretta con i confini del campo di
put range. Test cases should be written to force uscita. I casi di prova dovrebbero essere scritti per
the output to its limited values. Consider also, if forzare l’uscita ai suoi valori limite. Va considerato
it is possible to specify a test case which causes anche, se è possibile, specificare un caso di prova
output to exceed the specification boundary che preveda che l’uscita superi i valori di confine
values. specificati.
If output is a sequence of data, for example a Se l’uscita è una sequenza di dati, per esempio una
printed table, special attention should be paid tabella stampata, deve essere prestata un’attenzione
to the first and the last elements and to lists particolare al primo e all’ultimo elemento e ad elen-
containing none, 1 and 2 elements. chi che contengono elementi nulli, 1 e 2.
The Art of Software Testing. G. Myers, Wiley & The Art of Software Testing. G. Myers, Wiley &
Sons, New York, USA, 1979. Sons, New York, USA, 1979.
B.5 Backward Recovery (Referenced by clause 9) Recupero all’indietro (Backward Recovery)

(Riferimento all’art. 9)
Aim Scopo
To provide correct functional operation in the Fornire operazioni funzionali corrette in presenza
presence of one or more faults. di uno o più guasti.
If a fault has been detected, the system is reset Se è stato rilevato un guasto, il sistema è ripristi-
to an earlier internal state, the consistency of nato ad uno stato interno precedente, la coerenza
which has been proven before. This method del quale è stata prima provata. Questo metodo
implies saving of the internal state frequently at implica che sia salvato lo stato interno in modo
so-called well defined checkpoints. This may be frequente in cosiddetti punti di controllo ben defi-
done globally (for the complete database) or in- niti. Questo può essere fatto in modo globale (per
cremental (changes only between checkpoints). la completa base dei dati) o in modo incrementa-
Then the system has to compensate for the le (cambiamenti solo tra punti di controllo). Poi il
changes which have taken place in the mean- sistema deve compensare i cambiamenti che han-
time by using journalling (audit trail of actions), no avuto luogo nel frattempo usando registrazioni
compensation (all effects of these changes are (percorsi ispettivi delle azioni), compensazione
nullified) or external (manual)interaction. (tutti gli effetti di questi cambiamenti sono annul-
lati) o interazione esterna (manuale).
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 72 di 128
B.6 Cause Consequence Diagrams (Referenced by Diagrammi Causa Conseguenza (Riferimento
clause 14 and D.3) all’art. 14 e a D.3)
Aim Scopo
To model, in a diagrammatic form, the se- Modellare, in forma di diagramma, le sequenze
quence of events that can develop in a system degli eventi che si possono sviluppare in un siste-
as a consequence of combinations of basic ma come conseguenza della combinazione di
events. eventi di base.
It can be regarded as a combination of fault-tree Può essere considerata come una combinazione
and event-tree analysis. Starting from a critical dell’analisi dell’albero dei guasti e dell’albero de-
event, a cause-consequence graph is traced gli eventi. Partendo da un evento critico, viene
backwards and forwards. In the backwards di- tracciato a ritroso ed in avanti un grafico cau-
rection it is equivalent to a fault tree with the sa-conseguenza. Nella direzione a ritroso è equi-
critical event as the given top event. In the for- valente ad un albero dei guasti con l’evento criti-
ward direction the possible consequences aris- co come top event. Nella direzione in avanti sono
ing from an event are identified. The graph can identificate le possibili conseguenze che hanno
contain vertex symbols which describe the con- origine da un evento. Il grafico può contenere
ditions for propagation along different branches simboli di vertice che descrivono le condizioni
from the vertex. Time delays can also be includ- per la propagazione lungo i diversi rami dal verti-
ed. These conditions can also be described with ce. Possono essere anche inseriti ritardi di tempo.
fault trees. The lines of propagation can be Queste condizioni possono essere anche descritte
combined with logical symbols, to make the di- con alberi dei guasti. Le linee di propagazione
agram more compact. A set of standard symbols possono essere combinate con simboli logici, per
are defined for use in cause consequence dia- rendere il diagramma più compatto. Per l’impiego
grams. The diagrams can be used to compute in diagrammi causa conseguenza sono definiti
the probability of occurrence of certain critical una serie di simboli normalizzati. I diagrammi
consequences. possono essere usati per calcolare la probabilità
di accadimento di certe conseguenze critiche.
The Cause Consequence Diagram Method as a The Cause Consequence Diagram Method as a
Basis for Quantitative Accident Analysis.D.S. Basis for Quantitative Accident Analysis.D.S. Niel-
Nielsen, Riso-M-1374, 1971. sen, Riso-M-1374, 1971.
B.7 Certified Tools and Certified Translators Strumenti e Traduttori Certificati (Riferimento
(Referenced by clause 10) all’art. 10)
Aim Scopo
Tools are necessary to help developers in the Strumenti sono necessari per aiutare i progettisti,
different phases of software development. nelle diverse fasi dello sviluppo del software. Ove
Wherever possible tools should be certified so possibile gli strumenti dovrebbero essere certifica-
that some level of confidence can be assumed ti in modo che si possa assumere un certo livello
regarding the correctness of the outputs. di fiducia circa la correttezza delle uscite.
A certified tool is one which has been deter- Uno strumento è certificato quando è stato stabilito
mined to be of a particular quality. The certifi- che è di particolare qualità. La certificazione di uno
cation of a tool will generally be carried out by strumento viene generalmente eseguita da un ente
an independent, often national, body, against indipendente, spesso nazionale, sulla base di una
independently set criteria, typically national or serie di criteri indipendenti, tipicamente da norme
international standards. Ideally, the tools used nazionali o internazionali. Idealmente, gli strumenti
in all development phases (definition, design, usati nelle fasi di sviluppo (definizione, progettazio-
coding, testing and validation) and those used ne, codifica, prova e validazione) e quelli usati nella
in configuration management, should be subject gestione della configurazione, dovrebbero essere
to certification. To date only compilers (transla- soggetti a certificazione. Attualmente solo i compila-
tors) are regularly subject to certification proce- tori (traduttori) sono regolarmente soggetti a proce-
dures; these are laid down by national certifica- dure di certificazione; queste sono elaborate da enti
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 73 di 128
tion bodies and they exercise compilers di certificazione nazionale che provano i compilatori
(translators) against international standards. (traduttori) in base a norme internazionali come
such as those for Ada and Pascal. quelle per Ada e Pascal.
Pascal Validation Suite. UK distributor: BSI Pascal Validation Suite. UK distributor: BSI Quality
Quality Assurance, PO Box 375, Milton Keynes, Assurance, PO Box 375, Milton Keynes, MK14
MK14 6LL. 6LL.
Ada Validation Suite. UK distributor: National Ada Validation Suite. UK distributor: National
Computing Centre (NCC), Oxford Road., Man- Computing Centre (NCC), Oxford Road., Manche-
chester England. ster England.
B.8 Checklists (Referenced by clause 14 and D.8) Liste di controllo (Riferimento all’art. 14 e a D.8)
Aim Scopo
To provide a stimulus to critical appraisal of all Fornire uno stimolo alla valutazione critica di tutti
aspects of the system rather than to lay down gli aspetti di un sistema anziché elaborare prescri-
specific requirements. zioni specifiche.
A set of questions to be completed by the per- Una serie di domande che devono essere comple-
son performing the checklist. Many of the ques- tate dalla persona che affronta la lista di controllo.
tions are of a general nature and the Assessor Molte domande sono di natura generale ed il Va-
must interpret them as seems most appropriate lutatore deve interpretarle come appare più adat-
to the particular system being assessed. to allo specifico sistema che deve essere valutato.
To accommodate wide variations in software Per conciliare le ampie variazioni nel software e
and systems being validated, most checklists nei sistemi da validare, la maggior parte delle liste
contain questions which are applicable to many di controllo contengono domande che sono appli-
types of system. As a result there may well be cabili a molti tipi di sistemi. Come risultato, nella li-
questions in the checklist being used which are sta di controllo che deve essere usata, vi possono
not relevant to the system being dealt with and essere domande che non sono pertinenti con il si-
which should be ignored. Equally there may be stema di cui si tratta e che dovrebbero essere igno-
a need, for a particular system, to supplement rate. Per contro può esservi una necessità, per un
the standard checklist with questions specifical- particolare sistema, di integrare la lista di controllo
ly directed at the system being dealt with. standard con domande specificamente orientate al
sistema che deve essere considerato.
In any case it should be clear that the use of In ogni caso dovrebbe essere evidente che l’uso di
checklists depends critically on the expertise liste di controllo dipende in modo critico dall’espe-
and judgement of the engineer selecting and rienza e dal giudizio dell’ingegnere che seleziona ed
applying the checklist. As a result the decisions applica la lista. Ne deriva che le decisioni prese
taken by the engineer, with regard to the check- dall’ingegnere, nei confronti della/e lista/e di verifi-
list(s) selected, and any additional or superflu- ca scelta/e, e le domande aggiunte o superflue, do-
ous questions, should be fully documented and vrebbero essere interamente documentate e giustifi-
justified. The objective is to ensure that the ap- cate. L’obbiettivo è quello di assicurare che
plication of the checklists can be reviewed and l’applicazione delle liste di controllo possa essere
that the same results will be achieved unless riesaminata e che possano essere raggiunti gli stessi
different criteria are used. risultati salvo che siano usati criteri diversi.
The object in completing a checklist is to be as Nel completare una lista di controllo l’obbiettivo
concise as possible. When extensive justifica- deve essere quello di essere i più concisi possibi-
tion is necessary this should be done by refer- le. Quando è necessaria un’ ampia giustificazione
ence to additional documentation. Pass, Fail questa dovrebbe esser data facendo riferimento a
and Inconclusive, or some similar restricted set documentazione aggiuntiva. Valido, Fallito e Non
of tokens should be used to record the results Conclusivo, o una serie ristretta di indicazioni si-
for each question. This conciseness greatly sim- mili dovrebbe essere usata per registrare i risultati
plifies the process of reaching an overall condi ogni domanda. Questa sinteticità semplifica no-
clusion as to the results of the checklist assess- tevolmente il processo per ottenere una conclu-
ment. sione generale riguardo ai risultati della valutazio-
ne della lista di controllo.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 74 di 128
Programmable Electronic Systems in Safety Re- Programmable Electronic Systems in Safety Rela-
lated Applications. Health and Safety Executive, ted Applications. Health and Safety Executive,
Her Majesty’s Stationary Office, London 1987. Her Majesty’s Stationary Office, London 1987.
Guidelines for the Assessment of the Safety and Guidelines for the Assessment of the Safety and
Reliability of High Integrity Industrial Computer Reliability of High Integrity Industrial Computer
Systems. EWICS TC7, WP 489, 6th October 1987. Systems. EWICS TC7, WP 489, 6th October 1987.
Sons, New York, USA 1979. Sons, New York, USA 1979.
Software for computers in the safety systems of Software for computers in the safety systems of
nuclear power stations. IEC 60880, 1986. nuclear power stations. IEC 60880, 1986.
B.9 Control Flow Analysis (Referenced by D.8) Analisi del Flusso di Controllo (Riferimento a D.8)
Aim Scopo
To detect poor and potentially incorrect pro- Rilevare strutture di programma scadenti e poten-
gram structures. zialmente non corrette.
Control Flow Analysis identifies suspect areas of L’Analisi del Flusso di Controllo identifica aree so-
code which do not follow good programming spette del codice che non seguono una buona
practice. The program is analysed to form a di- pratica di programmazione. Il programma è ana-
rected graph which can be analysed for: lizzato per formare un grafico orientato che può
essere indirizzato per:
inaccessible code, for instance, uncondi- codice inaccessibile, per esempio, salti incon-
tional jumps which leaves blocks of code dizionati che rendono irraggiungibili i blocchi
unreachable; di codice;
knotted code, which is well structured code codice di nodi, che è un codice ben struttura-
whose control graph is reducible by succes- to il cui controllo grafico è riducibile per suc-
sive graph reductions to a single node. cessive riduzioni del grafico ad un singolo no-
Poorly structured code can only be reduced do. Un codice poco strutturato può essere
to a knot composed of several nodes. ridotto solamente ad un nodo composto di
più nodi.
RXVP80 - The Verification and Validation System RXVP80 - The Verification and Validation System
for FORTRAN. Users Manual. General Research for FORTRAN. Users Manual. General Research
Corporation, Santa Barbara, California, USA. Corporation, Santa Barbara, California, USA.
Information Flow and Data Flow of While Pro- Information Flow and Data Flow of While Pro-
grams. J.F. Bergeretti and B.A. Carre, ACMTrans. grams. J.F. Bergeretti and B.A. Carre, ACMTrans.
on Prog. Lang. and Syst., 1985. on Prog. Lang. and Syst., 1985.
B.10 Common Cause Failure Analysis (Referenced Analisi dei mancati funzionamenti di Causa
by clause 14) Comune (Riferimento all’art.14)
Aim Scopo
To identify potential failures in redundant sys- Identificare mancati funzionamenti potenziali in
tems or redundant sub-systems which would sistemi o sottosistemi ridondanti che indebolireb-
undermine the benefits of redundancy because bero i benefici della ridondanza a seguito del pre-
of the appearance of the same failures in the re- sentarsi, nello stesso tempo, delle medesime ava-
dundant parts at the same time. rie nelle parti ridondanti.
Computer systems intended to take care of the Sistemi computerizzati progettati per trattare la sicu-
safety of a plant often use redundancy in hard- rezza di un impianto, usano spesso la ridondanza
ware and majority voting. This technique is used dell’hardware con votazione di maggioranza. Que-
to avoid random component failures, which sta tecnica è usata per evitare mancati funzionamen-
would tend to prevent the correct processing of ti casuali di componenti, che tenderebbero ad impe-
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 75 di 128
data in a computer system. dire di processare correttamente i dati in un sistema
computerizzato.
However, some failures can be common to Tuttavia, alcuni mancati funzionamenti possono
more than one component. For example, if a essere comuni a più di un componente. Per
computer system is installed in one single esempio, se un sistema computerizzato è installa-
room, shortcomings in the air-conditioning, to in un’unica stanza, una deficienza dell’impianto
might reduce the benefits of redundancy. The di condizionamento, potrebbe ridurre il beneficio
same is true for other external effects on the della ridondanza. Lo stesso vale per altri effetti
computer system such as: fire, flooding, electro- esterni sul sistema computerizzato come: fuoco,
magnetic interference, plane crashes, and earth- allagamento, interferenze elettromagnetiche, inci-
quakes. The computer system may also be af- denti aerei e terremoti. Il sistema computerizzato
fected by incidents related to operation and può essere influenzato anche da incidenti relativi
maintenance. It is essential, therefore, that ade- al funzionamento ed alla manutenzione. È essen-
quate and well documented procedures are ziale, pertanto, che siano previste procedure ben
provided for operation and maintenance. Exten- documentate e adeguate per funzionamento e la
sive training of operating and maintenance per- manutenzione. È essenziale anche l’addestramen-
sonnel is also essential. to approfondito del personale addetto al funzio-
namento ed alla manutenzione.
Internal effects are also major contributors to Anche gli effetti interni sono tra i maggiori respon-
Common-Cause Failures (CCF). They can stem sabili dei mancati funzionamenti di Causa Comune
from design errors in common or identical com- (CCF). Essi possono derivare da errori di progetto
ponents and their interfaces, as well as ageing in componenti comuni o identici e nelle loro inter-
of components. CCF-Analysis has to search the facce, così come l’invecchiamento dei componenti.
system for such potential common failures. L’analisi CCF deve ricercare nei sistemi tali avarie
Methods of CCF-Analysis are general quality comuni potenziali. I metodi dell’Analisi CCF sono il
control, design reviews, verification and testing controllo della qualità generale, la revisione del
by an independent team, and analysis of real in- progetto, la verifica e le prove da parte di un grup-
cidents with feedback of experience from simi- po di lavoro indipendente, e l’analisi di incidenti
lar systems. The scope of the analysis, however, reali con il riscontro dell’esperienza in sistemi simi-
goes beyond hardware. Even if “diverse soft- li. Lo scopo dell’analisi, tuttavia, va oltre l’hardwa-
ware” is used in difficult chains of a redundant re. Anche se viene usato “software diversificato” in
computer system, there might be some commo- catene difficili di sistemi computerizzati ridondanti,
nality in the software approaches which could vi può essere qualche comunanza negli approcci
give rise to CCF. Errors in the common specifi- software che potrebbe accrescere le CCF. Errori
cation, for example. nelle specifiche comuni, ad esempio.
When CCF’s do not occur exactly at the same Quando le CCF non si verificano esattamente nel
tine, precautions can be taken by means of medesimo periodo di tempo, possono essere prese
comparison methods between the redundant precauzioni mediante metodi comparativi tra le ca-
chains which should lead to detection of a fail- tene ridondanti che condurrebbero al rilievo di un
ure before this failure is common to all chains. mancato funzionamento prima che tale mancato
CCF analysis should take this technique into ac- funzionamento sia comune a tutte le catene. L’Ana-
count. lisi CCF dovrebbe tenere conto di tale tecnica.
Review of Common Cause Failures. I.A. Watson, Review of Common Cause Failures. I.A. Watson,
UKAEA, Centre for Systems Reliability, Wigshaw UKAEA, Centre for Systems Reliability, Wigshaw
Lane, WA3 4NE, England, NCSR R 27, July 1981. Lane, WA3 4NE, England, NCSR R 27, July 1981.
Common-Mode Failures in Redundancy Sys- Common-Mode Failures in Redundancy Systems.
tems. I.A. Watson and G.T. Edwards Nuclear I.A. Watson and G.T. Edwards Nuclear Technolo-
Technology Vol, 46, De. 1979. gy Vol, 46, De. 1979.
Programmable Electronic Systems in Safety Re- Programmable Electronic Systems in Safety Rela-
lated Applications. Health and Safety Executive, ted Applications. Health and Safety Executive,
Her Majesty’s Stationary Office. Her Majesty’s Stationary Office.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 76 di 128
B.11 Data Flow Analysis (Referenced by D.8) Analisi del Flusso dei Dati (Riferimento a D.8)
Aim Scopo
To detect poor and potentially incorrect pro- Rilevare strutture di programma insufficienti e po-
gram structures. tenzialmente non corrette.
Data Flow Analysis combines the information L’Analisi del Flusso dei Dati combina le informa-
obtained from the control flow analysis with in- zioni ottenute dall’analisi del flusso di controllo
formation about which variables are read or con informazioni che indicano quali variabili
written in different portions of code. The analy- sono lette o scritte in diverse porzioni del codice.
sis can check for: Le analisi possono verificare:
variables that are read before they are writ- variabili che sono lette prima di essere scritte.
ten. This is very likely to be an error, and is Questo molto probabilmente è un errore, ed
certainly bad programming practice; è certamente una cattiva pratica di program-
mazione;
variables that are written more than once variabili che sono scritte più di una volta senza
without being read. This could indicate essere lette. Questo potrebbe indicare omissio-
omitted code; ne di codice;

variables that are written but never read. variabili che sono scritte ma mai lette. Questo
potrebbe indicare ridondanza di codice.
This could indicate redundant code. There is an Vi è un’estensione dell’analisi del flusso dei dati
extension of data flow analysis known as infor- conosciuta come analisi del flusso di informazio-
mation flow analysis, where the actual data ni, dove i flussi di dati reali (sia entro che tra le
flows (both within and between procedures) procedure) sono confrontati con la progettazione
are compared with the design intent. This is determinata. Questo è normalmente implementa-
normally implemented with a computerised to con uno strumento computerizzato ove i flussi
tool where the intended data flows are defined dei dati determinati sono definiti con un com-
using a structured comment that can be read by mento strutturato che può essere letto dallo stru-
the tool. mento.
RXVP80 - The Verification and Validation System RXVP80 - The Verification and Validation System
for FORTRAN. Users Manual. General Research for FORTRAN. Users Manual. General Research
Corporation, Santa Barbara, California, USA. Corporation, Santa Barbara, California, USA.
Information Flow and Data Flow of While Pro- Information Flow and Data Flow of While Pro-
grams. J.F. Bergeretti and B.A. Carre, ACMTrans. grams. J.F. Bergeretti and B.A. Carre, ACMTrans.
on Prog. Lang. and Syst., 1985. on Prog. Lang. and Syst., 1985.
B.12 Data Flow Diagrams (Referenced by D.5 and Diagrammi di Flusso dei Dati (Riferimento a
D.7) D.5 e D.7)
Aim Scopo
To describe the data flow through a program in Descrivere il flusso dei dati attraverso un pro-
a diagrammatic form. gramma in forma di diagramma.
Data Flow Diagrams document how data input I Diagrammi di Flusso dei Dati documentano
is transformed to output, with each stage in the come l’ingresso di dati è trasformato in uscita, con
diagram representing a distinct transformation. ogni fase nel diagramma che rappresenta una di-
stinta trasformazione.
Data flow diagrams are made up of three com- I diagrammi del flusso dei dati sono costituiti da
ponents: tre componenti:
1. annotated arrows - represent data flow in 1. frecce annotate - rappresentano il flusso dei
and out of the transformation centres with dati in entrata e in uscita dai centri di trasfor-
the annotations specifying what the data is; mazione con le annotazioni che specificano
ciò che il dato è;
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 77 di 128
2. annotated bubbles - represent transforma- 2. pallogrammi annotati – rappresentano centri
tion centres with the annotation specifying di trasformazione con le annotazioni che spe-
the transformation; cificano la trasformazione;
3. operators (AND, XOR) - These operators 3. operatori (AND, XOR) – Questi operatori
are used to link the annotated arrows. sono usati per collegare le frecce annotate.
Data flow diagrams describe how an input is I diagrammi di flusso dei dati descrivono come un
transformed to an output. They do not, and ingresso è trasformato in uscita. Essi non com-
should not, include control information or se- prendono, e non dovrebbero comprendere, infor-
quencing information. Each bubble can be con- mazioni di controllo o informazioni di sequenza.
sidered as a stand alone black box which, as Ogni pallogramma può essere considerato come
soon as its inputs are available, transforms them una scatola nera (black box) indipendente che,
to its outputs. non appena i suoi ingresso sono disponibili, li tra-
sforma nelle sue uscite.
One of the principle advantages of data flow di- Uno dei principali vantaggi dei diagrammi di flus-
agrams is that they show transformations with- so dei dati è quello di mostrare le trasformazioni
out making any assumptions about how these senza fare alcuna assunzione circa il modo in cui
transformations are implemented. le trasformazioni sono implementate.
The preparation of data flow diagrams is best La preparazione dei diagrammi del flusso di dati è
approached by considering system inputs and affrontata meglio considerando gli ingressi del siste-
working towards system outputs. Each bubble ma e arrivando verso le uscite del sistema. Ogni pal-
must represent a distinct transformation - its logramma deve rappresentare una trasformazione
output should, in some way, be different from distinta – la sua uscita dovrebbe, in qualche modo,
its input. There are no rules for determining the essere diversa dal suo ingresso. Non vi sono regole
overall structure of the diagram and construct- per determinare la struttura generale del diagramma
ing a data flow diagram is one of the creative e la costruzione di un diagramma di flusso dei dati è
aspects of system design. Like all design, it is an uno degli aspetti creativi della progettazione del si-
iterative process with early attempts refined in stema. Come tutta la progettazione, è un processo
stages to produce the final diagram. iterativo con tentativi iniziali raffinati per fasi per
produrre il diagramma finale.
Software Engineering. I. Sommerville, Addi- Software Engineering. I. Sommerville, Addi-
son-Wesley 1982. ISBN 0-201-13795-X. son-Wesley 1982. ISBN 0-201-13795-X.
B.13 Data Recording and Analysis (Referenced by Registrazione e Analisi dei Dati (Riferimento
clauses 10 and 16) all’art. 10 e 16)
Aim Scopo
To record all data, decisions and rationale in the Registrare tutti i dati, le decisioni e le ragioni del
software project to allow for easier verification, progetto software per permettere una più facile
validation, assessment and maintenance. verifica, validazione, valutazione e manutenzione.
Detailed records are maintained during a Durante un progetto sono mantenute dettagliate
project, both on a project and individual basis. registrazioni, sia sulla base del progetto che su
For instance, an engineer would be required to base individuale. Per esempio, ad un ingegnere
keep records which could include dovrebbe essere richiesto di tenere registrazioni
che potrebbero comprendere
effort expanded on individual modules, sforzo sviluppato sui singoli moduli,
testing performed on each module, prove eseguite su ogni modulo,
decisions and their rationale, decisioni e loro ragioni,
achievement of project milestones, raggiungimento di pietre miliari del progetto,
problems and their solutions. problemi e loro soluzioni.
During and at the conclusion of the project Durante e alla conclusione del progetto, queste
these records can be analysed to establish a registrazioni possono essere analizzate per stabili-
wide variety of information. In particular data re un’ampia varietà di informazioni. In particolare
recording is very important for the maintenance la registrazione dei dati è molto importante per la
of computer systems as the rationale for certain manutenzione dei sistemi computerizzati, poiché
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 78 di 128
decisions made during the development project la ragione di certe decisioni prese durante lo svi-
is not always known by the maintenance engi- luppo del progetto non è sempre nota agli inge-
neers. gneri della manutenzione.
B.14 Decision Tables (Truth Tables) (Referenced by Tavole di Decisioni/di Verità (Riferimento
clause 14 and D.7) all’art. 14 e a D.7)
Aim Scopo
To provide a clear and coherent specification Fornire una specifica chiara e coerente ed una
and analysis of complex logical combinations analisi delle combinazioni logiche complesse e
and relationships. loro relazioni.
These related methods use two dimensional ta- Questi metodi correlati usano due tabelle bidi-
bles to concisely describe logical relationships mensionali per descrivere in modo conciso le re-
between Boolean program variables. lazioni logiche tra le variabili di programma boo-
leane.
The conciseness and tabular nature of both La sinteticità e la natura tabellare dei due metodi
methods makes them appropriate as a means of li rende adatti come mezzo di analisi di combina-
analysing complex logical combinations ex- zioni logiche complesse espresse in codice.
pressed in code.
Both methods are potentially executable if used Entrambi i metodi sono potenzialmente eseguibili
as specifications. se usati come specifica.
B.15 Defensive Programming (Referenced by Programmazione Difensiva (Riferimento

Aim Scopo
To produce programs which detect anomalous Produrre programmi che rilevano flusso di con-
control flow, data flow or data values during trollo, flusso di dati o valori di dati anomali nel
their execution and react to these in a predeter- corso della loro esecuzione e che reagiscono a
mined and acceptable manner. questi in modo predeterminato ed accettabile.
Many techniques can be used during program- Durante la programmazione possono esser usate
ming to check for control or data anomalies. molte tecniche per verificare le anomalie del con-
These can be applied systematically throughout trollo o dei dati. Queste possono essere applicate
the programming of a system to decrease the per tutto il corso della programmazione di un si-
likelihood of erroneous data processing. stema per ridurre la probabilità di processare dati
in modo scorretto.
Two overlapping areas of defensive techniques Si possono identificare due aree sovrapposte di tec-
can be identified. Intrinsic error-safe software is niche difensive. Il software intrinsecamente privo di
designed to accommodate its own design short- errori è progettato per conciliare le proprie deficien-
comings. These shortcomings may be due to ze di progettazione. Queste deficienze possono es-
plain error of design or coding, or to erroneous sere dovute ad un puro errore di progettazione o di
requirements. The following lists some of the codifica, o a requisiti sbagliati. Nel seguito sono
defensive techniques: elencate alcune tecniche difensive:
variables should be range checked; le variabili dovrebbero essere verificate nel
loro campo di variazione;
where possible, values should be checked ove possibile, dovrebbe essere verificata la
for plausibility; credibilità dei valori;
parameters to procedures should be type, i parametri per le procedure dovrebbero esse-
dimension and range checked at procedure re verificati come tipo, dimensione e campo
entry. di variazione in sede di introduzione della
procedura.
These first three recommendations help to en- Queste prime tre raccomandazioni aiutano ad
sure that the numbers manipulated by the pro- assicurare che i numeri manipolati dal program-
gram are reasonable, both in terms of the pro- ma siano ragionevoli, sia in termini di funzione
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 79 di 128
gram function and physical significance of the del programma che di significato fisico delle va-
variables. riabili.
Read-only and read-write parameters I parametri di sola lettura e di lettura - scrittu-
should be separated and their access ra dovrebbero essere separati e il loro accesso
checked. Functions should treat all parame- verificato. Le funzioni dovrebbero trattare tutti
ters as read-only. Literal constants should i parametri come sola lettura. Costanti letterali
not be write-accessible. This helps detect non dovrebbero essere accessibili in scrittura.
accidental overwriting or mistaken use of Questo aiuta nel rilievo di sovrascrittura acci-
variables. dentale o nell’errato uso delle variabili.
Error tolerant software is designed to “expect” Il software che tollera errori è progettato “in pre-
failures in its own environment or use outside visione” di mancati funzionamenti nel suo proprio
nominal or expected conditions, and behave in ambiente o per l’uso al di fuori delle condizioni
a predefined manner. Techniques include the nominali o previste, e comportarsi in modo pre-
following: definito. Le tecniche comprendono quanto segue:
input variables and intermediate variables per le variabili d’ingresso e le variabili inter-
with physical significance should be medie con significato fisico, dovrebbe essere
checked for plausibility; verificata la credibilità;
the effect of output variables should be dovrebbe essere verificato l’effetto delle variabili
checked, preferably by direct observation of in uscita, preferibilmente per diretta osservazione

associated system state changes; dei cambiamenti di stato del sistema associato;
the software should check its configuration. il software dovrebbe verificare la propria con-
This could include both the existence and figurazione. Questo potrebbe comprendere
accessibility of expected hardware and also l’esistenza e l’accessibilità dell’hardware pre-
that the software itself is complete. This is visto ed anche che il software stesso sia com-
particularly important for maintaining integ- pleto. Questo è particolarmente importante
rity after maintenance procedures. per mantenere l’integrità dopo le procedure
di manutenzione.
Some of the defensive programming techniques Alcune delle tecniche di programmazione difensiva
such as control flow sequence checking, also come la verifica di sequenza del flusso di controllo
cope with external failures. copre anche i mancati funzionamenti esterni.
Dependability of Critical Computer Systems - Dependability of Critical Computer Systems - Part
Part 1. E.F. Redmill (ed) Elsevier Applied Sci- 1. E.F. Redmill (ed) Elsevier Applied Science 1988.
ence 1988.
Dependability of Critical Computer systems - Dependability of Critical Computer systems - Part
Part 2. E.F. Redmill (ed) Elsevier Applied Sci- 2. E.F. Redmill (ed) Elsevier Applied Science 1988.
ence 1988.
Software Engineering Aspects of Real-time Pro- Software Engineering Aspects of Real-time Pro-
gramming Concepts. E. Schoitsch, Computer gramming Concepts. E. Schoitsch, Computer Phy-
Physics Communications 41 (1986) North Hol- sics Communications 41 (1986) North Holland,
land, Amsterdam. Amsterdam.
B.16 Design and Coding Standards (Referenced by Standard di Progettazione e di Codifica

D.1) (Riferimento a D.1)
Aim Scopo
To ensure a uniform layout of the design docu- Assicurare una organizzazione uniforme dei do-
ments and the produced code, enforce egoless cumenti di progettazione e del codice prodotto,
programming and to enforce a standard design imporre una programmazione spersonalizzata e
method. un metodo di progettazione standardizzato.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 80 di 128
The rules to be adhered to are agreed at the Le regole alle quali uniformarsi sono concordate
outset of the project between the participants. all’inizio del progetto tra i partecipanti. Queste re-
These rules must comprise as a minimum gole devono comprendere come minimo
the development method and the related metodo di sviluppo e corrispondenti standard
coding standards to be followed, for exam- di codifica da seguire, per esempio JSP, MA-
ple JSP, MASCOT, Petri-Nets etc; SCOT, reti di Petri ecc.;
details of modularisation, for example, in- dettagli di modularizzazione, per esempio,
terface shapes, module sizes; condizioni delle interfacce, dimensioni del
modulo;
use of encapsulation, inheritance and poly- uso di incapsulamento, ereditarietà e polimorfi-
morphy, in case of object oriented languages; smo, nel caso di linguaggi orientati all’oggetto;
use or avoidance of certain language con- usare od evitare certi costrutti di linguaggio
structs, for example GOTO, EQUIVALENCE, per esempio GOTO, EQUIVALENCE, oggetti
dynamic objects, dynamic data, recursion, dinamici, dati dinamici, ricorrenza, puntatori,
pointers, exits etc.; and uscite ecc.; e
the what, where and how to comment. cosa, dove e come commentare.
These rules are made to allow for ease of devel- Queste regole sono create per permettere facilità
opment, verification, assessment and mainte- di sviluppo, verifica, valutazione e manutenzione.

nance. Therefore they shall address the availa- Pertanto esse devono rivolgersi agli strumenti di-
ble tools, in particular analysers and reverse sponibili, in particolare agli strumenti analizzatori
engineering tools. e agli strumenti di reverse engineering.
B.17 Diverse Programming (Referenced by Programmazione Diversificata (Riferimento

Aim Scopo
Detect and mask residual software design faults Rilevare e mascherare guasti residui della progetta-
during execution of a program, in order to pre- zione del software durante l’esecuzione di un pro-
vent safety critical failures of the system, and to gramma, al fine di prevenire mancati funzionamenti
continue operation for high reliability. critici per la sicurezza del sistema, e dare continuità
di funzionamento ad elevata affidabilità.
In diverse programming a given program speci- Nella programmazione diversificata una determi-
fication implemented N times in different ways. nata specifica di programma è implementata N
The same input values are given to the N ver- volte in modi differenti. Alle N versioni vengono
sions, and the results produced by the N ver- dati i medesimi valori d’ingresso, e vengono con-
sions are compared. If the result is considered frontati i risultati prodotti dalle N versioni. Se il ri-
to be valid, the result is transmitted to the com- sultato è considerato valido, questo viene tra-
puter outputs. smesso alle uscite del computer.
The N versions can run in parallel on separate Le N versioni possono essere eseguite in parallelo
computers, alternatively all versions can be run su computer separati, in alternativa tutte le versioni
on the same computer and the results subjected possono essere eseguite sul medesimo computer ed
to an internal vote. Different voting strategies i risultati possono essere soggetti a voto interno. Sul-
can be used on the N versions depending on le N versioni possono essere usate diverse strategie
the application requirements. di voto in relazione ai requisiti dell’applicazione.
If the system has a safe state, then it is feasi- se il sistema ha uno stato sicuro, è possibile ri-
ble to demand complete agreement (all N chiedere l’accordo completo (tutte le N versioni
agree) otherwise a fail-safe output value is concordano) altrimenti è usato un valore di uscita
used. For simple trip systems the vote can sicuro. Per sistemi che non hanno ritorno il voto
be biased in the safe direction. In this case può essere indirizzato nella direzione sicura. In
the safe action would be to trip if either ver- questo caso l’azione sicura dovrebbe essere di
sion demanded a trip. This approach typi- scattare se entrambe le versioni richiedessero
cally uses only two versions (N=2). uno scatto. Questo approccio usa tipicamente
solo due versioni (N=2).
For systems with no safe state, majority vot- per sistemi con nessun stato sicuro, possono
ing strategies can be employed. For cases essere usate strategie di voto maggioritario.
where there is no collective agreement, Per casi in cui non vi è accordo comune, pos-
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 81 di 128
probabilistic approaches can be used in or- sono essere usati approcci probabilistici al
der to maximise the chance of selecting the fine di massimizzare la possibilità di scegliere
correct value, for example, taking the mid- il valore corretto, per esempio, prendendo il
dle value, temporary freezing of outputs un- valore medio, congelamento temporaneo del-
til agreement returns etc. le uscite fino al ritorno di accordo ecc.
This technique does not eliminate residual soft- Questa tecnica non elimina i guasti residui della
ware design faults, but it provides a measure to progettazione del software, ma fornisce un prov-
detect and mask before they can affect safety. vedimento per rilevarli e mascherarli prima che
essi possano influenzare la sicurezza.
Dependable Computing: From Concepts to De- Dependable Computing: From Concepts to Desi-
sign Diversity. A. Avizienis, J.C. Laprie, Proc gn Diversity. A. Avizienis, J.C. Laprie, Proc IEEE,
IEEE, Vol 74, 5, May 1986. Vol 74, 5, May 1986.
A Theoretical Basis for the Analysis of Multi-ver- A Theoretical Basis for the Analysis of Multi-ver-
sion Software subject to Co-incident Failures. sion Software subject to Co-incident Failures.
D.E. Eckhardt and L.D. Lee, IEEE Trans. SE-11, D.E. Eckhardt and L.D. Lee, IEEE Trans. SE-11, No
No 12, 1985. 12, 1985.
B.18 Dynamic Reconfiguration (Referenced by Riconfigurazione dinamica (Riferimento

Aim Scopo
To maintain system functionality despite an in- Conservare la funzionalità del sistema nonostante
ternal fault. un guasto interno.
The logical architecture of the system has to be L’architettura logica del sistema deve essere tale
such that it can be mapped onto a subset of the che essa possa essere mappata su un sottoinsieme
available resources of the system. The architec- di risorse disponibili del sistema. L’architettura ne-
ture needs to be capable of detecting a failure cessita di essere in grado di rilevare un mancato
in a physical resource and then remapping the funzionamento in una risorsa fisica e quindi map-
logical architecture back onto the restricted re- pare nuovamente l’architettura logica verso le ri-
sources left functioning. Although the concept sorse limitate che rimangono funzionanti. Per
is more traditionally restricted to recovery from quanto il concetto sia tradizionalmente ristretto al
failed hardware units, it is also applicable to ripristino di unità hardware malfunzionanti, esso
failed software units if there is sufficient è applicabile anche ad unità software malfunzio-
“run-time redundancy” to allow a software nanti se vi è sufficiente “ridondanza nel tempo di
re-try or if there is sufficient redundant data to esecuzione” da consentire un nuovo tentativo del
make the individual and isolated failure a little software, o se vi sono dati ridondanti sufficienti
import. da rendere di scarsa importanza il mancato fun-
zionamento individuale ed isolato.
Although traditionally applied to hardware, this Benché tradizionalmente applicata all’hardware,
technique is being developed for application to questa tecnica è sviluppata per applicazioni sof-
software and, thus, the total system. It must be tware e, quindi all’intero sistema. Essa deve esse-
considered at the first system design stage. re presa in considerazione nella prima fase la di
progettazione del sistema.
Critical Issues in the Design of a Reconfigureable Critical Issues in the Design of a Reconfigureable
Control Computer. H. Schmid, J. Lam,R. Naro and Control Computer. H. Schmid, J. Lam,R. Naro and
K. Weir, FTCS 14 June 1984 IEEE 1984. K. Weir, FTCS 14 June 1984 IEEE 1984.
Assigning Processes to Processors: A Fault-toler- Assigning Processes to Processors: A Fault-tole-
ant Approach. June 1984 G. Kar and rant Approach. June 1984 G. Kar and C.N.Nikola-
C.N.Nikolaou, Watson Research Centre, York- ou, Watson Research Centre, Yorktown
town
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 82 di 128
B.19 Equivalence Classes and Input Partition Classi di Equivalenza e Prova di Partizione dei dati
Testing (Referenced by D2 and D.3) d’ingresso (Riferimento a D2 e D.3)
Aim Scopo
To test the software adequately using a mini- Provare il software in modo adeguato usando un
mum of test data. The test data is obtained by minimo di dati di prova. I dati di prova sono otte-
selecting the partitions of the input domain re- nuti scegliendo le partizioni del dominio d’ingres-
quired to exercise the software. so richieste per sollecitare il software.
This testing strategy is based on the equivalence Questa strategia di prova è basata sulla relazione
relation of the inputs, which determines a parti- di equivalenza degli ingressi, che determina una
tion of the input domain. partizione del dominio dell’ingresso.
Test cases are selected with the aim of covering Sono scelti dei casi di prova con lo scopo di trat-
all subsets of this partition. At least one test case tare tutti i sottoinsiemi di questa partizione. Alme-
is taken from each equivalence class. no un caso di prova è preso da ogni classe di
equivalenza.
There are two basic possibilities for input parti- Vi sono due possibilità basilari per la partizione
tioning which are: d’ingresso, che sono:

equivalence classes may be defined on the le classi di equivalenza possono essere defini-
specification. The interpretation of the spec- te nella specifica. L’interpretazione della spe-
ification may be either input oriented, for cifica può essere, sia orientata all’ingresso,
example the values selected are treated in per esempio i valori scelti sono trattati nel
the same way or output oriented, for exam- medesimo modo, o orientati all’uscita, per
ple the set of values leading to the same esempio l’insieme di valori che conducono al
functional result; and medesimo risultato funzionale; e
equivalence classes may be defined on the le classi di equivalenza possono essere defini-
internal structure of the program. In this te nella struttura interna del programma. In
case the equivalence class results are deter- questo caso i risultati della classe di equiva-
mined from static analysis of the program, lenza sono determinati dall’analisi statica del
for example the set of values leading to the programma, per esempio l’insieme di valori
same path being executed. che conducono al medesimo percorso che
deve essere eseguito.
Sons, New York, USA, 1979. Sons, New York, USA, 1979.
B.20 Error Detecting and Correcting Codes Codici di Correzione e di Rilevamento

(Referenced by clause 9) dell’Errore (Riferimento all’art. 9)
Aim Scopo
To detect and correct errors in sensitive infor- Rilevare e correggere errori con informazioni si-
mation. gnificative.
For an information of n bits, a coded block of k Per informazioni a n bit è generato un blocco co-
bits is generated which enables errors to be de- dificato di k bit che rende possibile il rilievo e la
tected and corrected. Different types of code in- correzione degli errori. I diversi tipi di codice
clude: comprendono:
hamming codes; codici hamming;
cyclic codes; codici ciclici;
polynomial codes. codici polinomiali.
The Technology of Error Correcting Codes. E.R. The Technology of Error Correcting Codes. E.R.
Berlekamp, Proc. of the IEEE, 68, 5, 1980. Berlekamp, Proc. of the IEEE, 68, 5, 1980.
A Short Course on Error Correcting Codes. A Short Course on Error Correcting Codes. N.J.A.
N.J.A. Sloane, Springer-Verlag, Wien, 1975. Sloane, Springer-Verlag, Wien, 1975.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 83 di 128
B.21 Error Guessing (Referenced by D.2 and D.8) Supposizione di Errore (Riferimento a D.2 e
D.8)
Aim Scopo
To remove common programming errors. Eliminare gli errori di programmazione comuni.
Testing experience and intuition combined with L’esperienza nelle prove e l’intuizione unita alla co-
knowledge and curiosity about the system un- noscenza e alla curiosità circa il sistema in prova
der test may add some uncategorised test cases può portare all’aggiunta di qualche caso di prova
to the designed test case set. Special values or che non rientra nelle categorie dell’insieme di prove
combinations of values may be error-prone. progettate. Valori speciali o combinazioni di valori
Some interesting test cases may be derived from possono essere inclini all’errore. Alcuni casi di pro-
inspection checklists. It may also be considered va interessanti possono essere derivati dall’ispezione
whether the system is robust enough. Can the delle liste di controllo. Può anche essere esaminato
buttons be pushed on the front-page too fast or se il sistema è abbastanza robusto. I pulsanti sul
too often? What happens if two buttons are pannello frontale possono essere spinti troppo rapi-
pushed simultaneously? damente o troppo spesso? Che cosa succede se due
pulsanti sono premuti simultaneamente?
B.22 Error Seeding (Referenced by D.2) Semina di Errori (Riferimento a D.2)
Aim Scopo
To ascertain whether a set of test cases is ade- Accertare se una serie di casi di prova è adeguata.
quate.
Some known error types are inserted in the pro- Sono inseriti alcuni tipi di errori nel programma e
gram, and the program is executed with the test il programma viene quindi eseguito con i casi di
cases under test conditions. If only some of the prova nelle condizioni di prova. Se vengono tro-
seeded errors are found, the test case set is not vati solo alcuni degli errori seminati, l’insieme dei
adequate. The ratio of found seeded errors to casi di prova non è adeguato. Il rapporto degli er-
the total number of seeded errors is an estimate rori seminati trovati rispetto al numero totale degli
of the ratio of found real errors to total number errori seminati è una stima del rapporto degli er-
errors. This gives a possibility of estimating the rori effettivi trovati sul numero totale degli errori.
number of remaining errors and thereby the re- Questo da una possibilità di stimare il numero de-
maining test effort. gli errori che rimangono e quindi il residuo impe-
gno per le prove.
Errori seminati trovati Errori effettivi trovati

Found seeded errors Found real errors
—————————— = ——————————
Numero totale degli erro- Numero totale degli
ri seminati errori effettivi
Total number of Total number of
seeded errors real errors
The detection of all the seeded errors may indi- Lo scoprire tutti gli errori seminati può indicare, sia
cate either that the test case set is adequate, or che l’insieme dei casi di prova è adeguato, sia che
that the seeded errors were too easy to find. gli errori seminati sono stati trovati troppo facil-
The limitations of the method are that in order, mente. I limiti del metodo sono dovuti al fatto per
to obtain any usable results, the error types as ottenere qualche risultato utile, sia i tipi di errore
well as the seeding positions must reflect the che le posizioni di semina devono rispecchiare la
statistical distribution of real errors. distribuzione statistica degli errori effettivi.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 84 di 128
B.23 Event Tree Analysis (Referenced by clause 14) Analisi dell’Albero degli Eventi (Riferimento
all’art. 14)
Aim Scopo
To model, in a diagrammatic form, the se- Modellare, in forma di diagramma, la sequenza
quence of events that can develop in a system degli eventi che si possono sviluppare in un siste-
after an initiating event, and thereby indicate ma dopo un evento iniziale, indicando così come
how serious consequences can occur. possono verificarsi serie conseguenze.
On the top of the diagram is written the se- Alla sommità del diagramma sono indicate le con-
quence conditions that are relevant in the de- dizioni della sequenza che sono attinenti nello
velopment following the initiating event which sviluppo successivo l’evento iniziale che è l’ob-
is the target of the analysis. Starting under the biettivo dell’analisi. Partendo dall’evento iniziale
initiating event, one draws a line to the first si disegna una linea verso la prima condizione
condition in the sequence. There the diagram della sequenza. Qui il diagramma si dirama in
branches off into a “yes” and a “no” branch, de- rami “si” e “no”, descrivendo come gli sviluppi fu-
scribing how the future developments depend turi dipendono dalle condizioni. Per ciascuno di
on the condition. For each of these branches, questi rami si continua verso la condizione se-
one continues to the next condition in a similar guente in modo simile. Non tutte le condizioni
way. Not all conditions are, however, relevant tuttavia, sono attinenti per tutti i rami. Si continua
for all branches. One continues to the end of verso la fine della sequenza, e ogni ramo dell’al-
the sequence, and each branch of the tree con- bero così costruito rappresenta una possibile con-
structed in this way represents a possible conse- seguenza. L’albero degli eventi può essere usato
quence. The event tree can be used to compute per calcolare la probabilità delle varie conseguen-
the probability of the various consequences ze basate sulla probabilità e sul numero delle
based on the probability and number of condi- condizioni della sequenza.
tions in the sequence.
Event Trees and their Treatment on PC Comput- Event Trees and their Treatment on PC Compu-
ers. N. Limnious and J.P. Jeannette, Reliability ters. N. Limnious and J.P. Jeannette, Reliability En-
Engineering, Vol. 18, No. 3 1987. gineering, Vol. 18, No. 3 1987.
B.24 Fagan Inspections (Referenced by D.8) Ispezioni di Fagan (Riferimento a D.8)
Aim Scopo
To reveal errors in all phases of the program Rilevare errori in tutte le fasi dello sviluppo del
development. programma.
A “formal” audit on quality assurance docu- Una ispezione “formale” su documenti di assicu-
ments aimed at finding errors and omissions. razione qualità con lo scopo di trovare errori ed
The inspection process consists of five phases; omissioni. Il processo di ispezione consiste in cin-
Planning, Preparation, Inspection, Rework and que fasi, Pianificazione, Preparazione, Ispezione,
Follow up. Each of these phases has its own Modifica e Rafforzamento. Ciascuna di queste fasi
separate objective. The complete system devel- ha il proprio separato obbiettivo. Deve essere
opment (specification, design, coding and test- ispezionato lo sviluppo completo del sistema
ing) must be inspected. (specifica, progettazione, codifica e prova).
Design and Code Inspections to Reduce Errors Design and Code Inspections to Reduce Errors in
in Program Development. M.E. Fagan, IBM Sys- Program Development. M.E. Fagan, IBM Systems
tems Journal, No. 3, 1976. Journal, N3, 1976.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 85 di 128
B.25 Failure Assertion Programming (Referenced Programmazione di Asserzione del mancato
by clause 9) funzionamento (Riferimento all’art. 9)
Aim Scopo
To detect residual software design faults during Rilevare i malfunzionamenti residui della proget-
execution of a program, in order to prevent tazione del software durante l’esecuzione di un
safety critical failures of the system and to con- programma, con il fine di impedire mancati fun-
tinue operation for high reliability. zionamenti del sistema e continuare operativa-
mente con elevata affidabilità.
The assertion programming method follows the Il metodo di programmazione di asserzione segue
idea of checking a pre-condition (before a se- l’idea di verificare una precondizione (prima che
quence of statements is executed, the initial una sequenza di comandi sia eseguita, viene veri-
conditions are checked for validity) and a ficata la validità delle condizioni iniziali) e una
post-condition (results are checked after the ex- postcondizione (i risultati vengono verificati dopo
ecution of a sequence of statements). If either l’esecuzione di una sequenza di comandi). Se, o
the pre-condition or the post-condition is not la precondizione, o la postcondizione non sono
fulfilled, the processing stops with an error. soddisfatte, il processo si arresta con un errore.
For example, Per esempio,
assert <pre-condition>; asserisce <precondizione>;
action 1; azione 1;
: :
: :
action x; azione x;
assert <post-condition>; asserisce <post-condizione>;
A Discipline of Programming. E.W. Dijkstra, A Discipline of Programming. E.W. Dijkstra, Pren-
Prentice Hall, 1976. tice Hall, 1976.
The Science of Programming. D. Gries, Spring- The Science of Programming. D. Gries, Sprin-
er-Verlag, 1981. ger-Verlag, 1981.
Software Development - A Rigorous Approach. Software Development - A Rigorous Approach.
C.B. Jones, Prentice-Hall, 1980. C.B. Jones, Prentice-Hall, 1980.
B.26 SEEA - Software Error Effect Analysis (Ref’d SEEA - Analisi dell’Effetto dell’Errore Software
by clause 9, 11 & 14) (Riferimento all’art. 9, 11 & 14)
Aim Scopo
To identify software modules, their criticality; to Identificare i moduli software, la loro criticità;
propose means for detecting software errors proporre mezzi per rilevare errori del software e
and enhancing software robustness; to evaluate migliorare la robustezza del software; valutare
the amount of validation needed on the various l’ammontare delle necessità di validazione nelle
software components. varie componenti del software.
The analysis is done in three phases: L’analisi è eseguita in tre fasi:
Vital software modules identification; Identificazione dei moduli software vitali;
Determination of the depth of the analysis Determinazione della profondità dell’analisi
(at the level of a single instruction line, a (a livello di una linea di istruzione singola, di
group of instructions, a module, etc...) un gruppo di istruzioni, di un modulo,
needed for each software module, from its ecc.....) richiesta, per ciascun modulo softwa-
specification. re, dalla sua specifica.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 86 di 128
Software error analysis Analisi dell’errore software
The result of this phase is a table listing the Il risultato di questa fase è una tabella che
following information: elenca le seguenti informazioni:
module name; nome del modulo;
error considered; errore considerato;
consequences of the error at the mod- conseguenze dell’errore a livello del mo-
ule level; dulo;
consequences at the system level; conseguenze a livello del sistema;
violated safety criterion; criterio di sicurezza violato;
error criticality; criticità dell’errore;
proposed error detection means; mezzi di rilievo dell’errore proposti;
violated criterion if the detection means criterio violato se sono implementati i
is implemented; mezzi di rilievo;
residual criticality if the detection means criticità residua se sono implementati i
is implemented. mezzi di rilievo.
Synthesis Sintesi
The synthesis identifies the remaining un- La sintesi identifica gli scenari non sicuri rima-
safe scenarios and the validation effort nenti e lo sforzo di validazione necessario
needed given the criticality of each module. data la criticità di ciascun modulo.
SEEA, being an in-depth analysis carried out by Poiché la tecnica SEEA è un’analisi in profondità
an independent team, is a powerful bug-finding eseguita da un gruppo indipendente, è un meto-
method. do potente per trovare errori di programmazione.
Railway fixed equipment and rolling stock. Data Railway fixed equipment and rolling stock. Data
processing. Software dependability - Adapted processing. Software dependability - Adapted
methods for software safety analysis, French methods for software safety analysis, French stan-
standard NF F 71-013, December 1990. dard NF F 71-013, December 1990.
IRSE International Technical Committee Report IRSE International Technical Committee Report
No. 1 No. 1
*SAFETY SYSTEM VALIDATION with regard to *SAFETY SYSTEM VALIDATION with regard to
cross acceptance of signalling systems by the cross acceptance of signalling systems by the rai-
railways* lways*
P. THIREAU P. THIREAU
*Méthodologie d’Analyse des Effets des Erreurs *Méthodologie d’Analyse des Effets des Erreurs
Logiciel (AEEL) appliquée à l’étude d’un logiciel Logiciel (AEEL) appliquée à l’étude d’un logiciel
de haute sécurité.* de haute sécurité.*
5th International Conference on Reliability and 5th International Conference on Reliability and
Maintainability. Maintainability.
Biarritz - France - 1986 Biarritz - France - 1986
D. J. REIFER D. J. REIFER
*Software failures modes and effects analysis* *Software failures modes and effects analysis*
Transaction on reliability IEE - Vol. R28 No. 3 Transaction on reliability IEE - Vol. R28 No. 3
August 79 - Pages 247/249 August 79 - Pages 247/249
J. R. FRAGOLA and J. F. SPAMM J. R. FRAGOLA and J. F. SPAMM
*The software error effects analysis, a qualitative *The software error effects analysis, a qualitative
design tool* design tool*
IEEE Symposium Computer on Software Relia- IEEE Symposium Computer on Software Reliabili-
bility ty
1973 - pages 90/93 1973 - pages 90/93
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 87 di 128
B.27 Fault Detection and Diagnosis (Referenced by Rilievamento Guasto e Diagnosi (Riferimento
Aim Scopo
To detect faults in a system, which might lead Rilevare malfunzionamenti in un sistema che po-
to a failure, thus providing the basis for coun- trebbero condurre ad un mancato funzionamento,
termeasures in order to minimise the conse- fornendo pertanto le basi per contromisure fina-
quences of failures. lizzate a minimizzare le conseguenze dei mancati
funzionamenti.
Fault detection is the process of checking a sys- Il rilievo del malfunzionamento è il processo di
tem for erroneous states (which are caused, as verifica di esistenza di stati erronei in un sistema
explained before, by a fault within the (sub)sys- (che sono causati, come spiegato in precedenza,
tem to be checked). The primary goal of fault da un malfunzionamento nel sistema/sottosistema
detection is to inhibit the effect of wrong results. da verificare). Il fine primario della rilevazione di
A system which delivers either correct results, or un malfunzionamento è quello di inibire l’effetto
no results at all, is called “self checking”. di risultati sbagliati. Un sistema che produce sia ri-
sultati corretti che nessun risultato affatto, è detto

che “si autocontrolla”.
Fault detection is based on the principles of re- Il rilievo del malfunzionamento è basato sui prin-
dundancy (mainly to detect hardware faults) cipi della ridondanza (principalmente per rilevare
and diversity (software faults). Some sort of vot- malfunzionamenti hardware) e sulla diversità
ing is needed to decide on the correctness of (malfunzionamenti software). Per decidere sulla
results. Special methods applicable are assertion correttezza dei risultati è necessario qualche tipo
programming, N-version programming and the di votazione. Metodi speciali applicabili sono:
safety bag technique and on hardware level by programmazione di asserzione, programmazione
introducing sensors, control loops, error check- con N-versioni e tecnica della safety bag; a livello
ing codes, etc. di hardware introducendo sensori, costrutti iterati-
vi di controllo, codici di verifica dell’errore, ecc.
Fault detection may be achieved by checks in Il rilievo del malfunzionamento può essere conse-
the value domain or in the time domain on dif- guito con verifiche nel dominio del valore o nel do-
ferent levels, especially on the physical (tem- minio del tempo su livelli differenti, specialmente fi-
perature, voltage etc.), logical (error detecting sico (temperatura, tensione, ecc.), logico (codici di
codes), functional (assertions) or external level rilievo dell’errore), funzionale (asserzioni) o a livello
(plausibility checks). The results of these checks esterno (verifiche di accettabilità). I risultati di que-
may be stored and associated with the data af- ste verifiche possono essere memorizzati e associati
fected to allow failure tracking. con dati sui quali hanno influenza per permettere di
seguire le tracce del mancato funzionamento.
Complex systems are composed of subsystems. I sistemi complessi sono composti da sottosistemi.
The efficiency of fault detection, diagnosis and L’efficienza del rilievo del malfunzionamento, della
fault compensation depends on the complexity diagnosi e della compensazione del guasto dipende
of the interactions among the subsystems, dalla complessità delle interazioni tra i sottosistemi,
which influences the propagation of faults. che influenzano la propagazione dei guasti.
Fault diagnosis isolates the smallest subsystem La diagnosi del guasto isola il sottosistema più
that may be identified. Smaller subsystems al- piccolo che possa essere identificato. Il sottosiste-
low a more detailed diagnosis of faults (identifi- ma più piccolo permette una diagnosi più detta-
cation of erroneous states). gliata dei malfunzionamenti (identificazione degli
stati erronei).
B.28 Fault Tree Analysis (Referenced by clauses 9 Analisi dell’Albero dei Guasti (Riferimento
& 14) all’art. 9 & 14)
Aim Scopo
To aid in the analysis of events, or combina- Aiutare nell’analisi degli eventi, o nella combina-
tions of events, that will lead to a hazard or seri- zione degli eventi, che condurranno ad un peri-
ous consequence. colo o ad una seria conseguenza.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 88 di 128
Starting at an event which would be the imme- Partendo da un evento che potrebbe essere la
diate causes of a hazard or serious consequence causa immediata di un pericolo o di una seria
(the “top event”) analysis is carried out along a conseguenza (“l’evento critico”) l’analisi è svilup-
tree path. Combinations of causes are described pata lungo il percorso ad albero. Le combinazioni
with logical operators (and, or, etc). Intermedi- delle cause sono descritte con operazioni logiche
ate causes are analysed in the same way, and so (and, or, ecc.). Le cause intermedie sono analizza-
on back to basic events where analysis stops. te nel medesimo modo, e così via a ritroso fino
agli eventi di base ove l’analisi si arresta.
The method is graphical, and a set of standard- Il metodo è grafico, ed è usato un insieme di sim-
ised symbols are used to draw the fault tree. It boli normalizzati per disegnare l’albero dei guasti.
is mainly intended for the analysis of hardware Esso è destinato principalmente all’analisi dei si-
systems, but there have also been attempts to stemi hardware, ma vi sono stati anche tentativi di
apply this approach to software failure analysis. applicare questo approccio all’analisi del mancato
funzionamento del software.
System Reliability Engineering Methodology: A System Reliability Engineering Methodology: A
Discussion of the State of the Art. J.B. Fusseland Discussion of the State of the Art. J.B. Fusseland
J.S. Arend, Nuclear Safety 20(5), 1979. J.S. Arend, Nuclear Safety 20(5), 1979.
Fault Tree Handbook. W.E. Vesely et. al., Fault Tree Handbook. W.E. Vesely et. al., NU-
NUREG-0942, Division of System Safety Office of REG-0942, Division of System Safety Office of Nu-
Nuclear Reactor Regulation, U.S. Nuclear Regula- clear Reactor Regulation, U.S. Nuclear Regulatory
tory Commission Washington, D.C.20555, 1981. Commission Washington, D.C.20555, 1981.
Reliability Technology. A.E. Greene and A.J. Reliability Technology. A.E. Greene and A.J.
Bourne, Wiley-Interscience, 1972. Bourne, Wiley-Interscience, 1972.
B.29 Finite State Machines/State Transition Macchine a Stati Finiti /Diagrammi di

Diagrams (Ref’d by D.5 & D.7) Transizione dello Stato (Riferimento a D.5 & D.7)
Aim Scopo
To define or implement the control structure of Definire o implementare la struttura di controllo
a system. di un sistema.
Many systems can be defined in terms of their Molti sistemi possono essere definiti nei termini
states, their inputs, and their actions. Thus dei loro stati, dei loro ingressi e delle loro azioni.
when in state S1, on receiving input I a system Perciò quando nello stato S1, al ricevimento
might carry out action A and move to state S2. dell’ingresso I un sistema potrebbe svolgere
By defining a system’s actions for every input in l’azione A e andare nello stato S2. Con la defini-
every state we can define a system completely. zione delle azioni di un sistema per ogni ingresso
The resulting model of the system is called a Fi- in ogni stato possiamo definire un sistema in
nite State Machine. It is often drawn as a modo completo. Il modello risultante del sistema
so-called state transition diagram showing how è chiamato una Macchina a Stati Finiti. Esso è
the system moves from one state to another, or spesso disegnato come un cosiddetto diagramma
as a matrix in which the dimensions are state di transizione di stato che mostra come il sistema
and input and the matrix cells contain the ac- passa da uno stato all’altro, o come una matrice,
tion and new state resulting from receipt of the nella quale le dimensioni sono stati e ingressi e le
input in the given state. celle della matrice contengono l’azione ed il nuo-
vo stato risultante dal ricevimento dell’ingresso in
un determinato stato.
Where a system is complicated or has a natural Quando un sistema è complicato o ha una struttura
structure this can be reflected in a layered FSM. naturale, questo può riflettersi in un FSM a strati.
A specification or design expressed as an FSM Una specifica o una progettazione espressa come
can be checked for completeness (the system un FSM può essere verificata per completezza (un
must have an action and new state for every in- sistema deve avere un’azione e un nuovo stato
put in every state), for consistency (only one per ogni ingresso in ciascun stato), per coerenza
state change is defined for each state/input (è definito un solo cambiamento di stato per ogni
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 89 di 128
pair) and reachability (whether or not it is pos- coppia stato/ingresso) e raggiungibilità (reachabi-
sible to get from one state to another by any se- lity) (se è possibile o no raggiungere uno stato
quence of inputs). These are important proper- dall’altro con qualunque sequenza di ingressi).
ties for critical systems and they can be Queste sono proprietà importanti per sistemi criti-
checked. Tools to support these checks are eas- ci ed esse possono essere verificate. Strumenti per
ily written. Algorithms also exist that allow the supportare queste verifiche sono scritti facilmen-
automatic generation of test cases for verifying te. Esistono anche algoritmi che consentono la
an FSM implementation or for animating an generazione automatica di casi di prova per verifi-
FSM model. care una implementazione FSM o per animare un
modello FSM.
Introduction to the theory of Finite State Ma- Introduction to the theory of Finite State Machi-
chines. A. Gill, McGraw-Hill 1962. nes. A. Gill, McGraw-Hill 1962.
B.30 Formal Methods (Referenced by clause 8, Metodi Formali (Riferimento l’art. 8, 10 e D.5)
clause 10 and D.5)
Aim Scopo
The development of software in a way that is Lo sviluppo di software in modo che sia su basi
based on mathematics. This includes formal de- matematiche. Questo comprende progettazione
sign and formal coding techniques. formale e tecniche di codifica formali.
Formal methods provide a means of developing I metodi formali forniscono i mezzi per sviluppa-
a description of a system at some stage in its re la descrizione di un sistema ad un certo mo-
development specification, design or code. The mento nella sua specifica di sviluppo, progetta-
resulting description takes a mathematical form zione o codice. La descrizione risultante assume
and can be subjected to mathematical analysis una forma matematica e può essere soggetta ad
to detect various classes of inconsistency or in- un’analisi matematica per rilevare varie classi di
correctness. Moreover, the description can in inconsistenza o scorrettezza. Inoltre, in alcuni casi
some cases be analysed by machine with a rig- la descrizione può essere analizzata con una mac-
our similar to the syntax checking of a source china con un rigore simile alla verifica della sin-
program by a compiler, or animated to display tassi di un programma sorgente mediante un
various aspects of the behaviour of the system compilatore, o essere animata per mostrare vari
described. Animation can give extra confidence aspetti del comportamento del sistema descritto.
that the system meets the real requirement as L’animazione può dare ulteriore fiducia che il si-
well as the formally specified requirement. stema soddisfa il requisito reale così come il re-
quisito specificato formalmente.
A formal method will generally offer a notation Un metodo formale generalmente offre un’anno-
(generally some form of discrete mathematics tazione (generalmente vengono usate alcune for-
being used), a technique for deriving a descrip- me di matematica discreta), una tecnica per deri-
tion in that notation, and various forms of anal- vare una descrizione in tale annotazione, e varie
ysis for checking a description for different cor- forme di analisi per verificare una descrizione per
rectness properties. diverse proprietà di correttezza.
Several examples of Formal Methods are described Nella seguente sottosezione di questa bibliografia
in the following subsections of this bibliography. sono descritti esempi vari di Metodi Formali. I
The Formal Methods described are CCS, CSP, HOL, Metodi Formali descritti sono: are CCS, CSP, HOL,
LOTOS, OBJ, Temporal Logic, VDM and Z. LOTOS, OBJ, Logica di Tempo, VDM e Z.
B.30.1 CCS - Calculus of Communicating Systems CCS - Calcolo dei sistemi di comunicazione
Aim Scopo
CCS is a means for describing and reasoning CCS è un mezzo per descrivere e ragionare sul
about the behaviour of systems of concurrent, comportamento dei sistemi di processi di comuni-
communicating processes. cazione concorrenti.
Similar to CSP, CCS is a mathematical calculus Come il CSP, il CCS è un calcolo matematico correla-
concerned with the behaviour of systems. The to con il comportamento dei sistemi. La progettazio-
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 90 di 128
system design is modelled as a network of inde- ne del sistema è modellata come una rete di proces-
pendent processes operating sequentially or in si indipendenti che funzionano in sequenza o in
parallel. Processes can communicate via ports parallelo. I processi possono comunicare attraverso
(similar to CSP’s channels), the communication porte (simili ai canali del CSP) e la comunicazione
only taking place when both processes are ha luogo solo quando entrambi i processi sono
ready. Non-determinism can be modelled. Start- pronti. Il non determinismo può essere modellato.
ing from a high-level abstract description of the Partendo da una descrizione astratta ad elevato livel-
entire system (known as a trace), it is possible lo dell’intero sistema (conosciuta come traccia), è
to carry out a step-wise refinement of the sys- possibile eseguire un procedimento per raffinamenti
tem into a composition of communicating proc- successivi del sistema in una composizione di pro-
esses whose total behaviour is that required of cessi di comunicazione il cui comportamento totale
the whole system. Equally, it is possible to work è quello richiesto dall’intero sistema. Ugualmente, è
in a bottom up fashion, combining processes possibile lavorare in una modalità bottom-up, com-
and deducing the properties of the resulting binando i processi e deducendo le proprietà del si-
system using inference rules related to the com- stema risultante usando regole di interferenza corre-
position rules. late con le regole di composizione.
A Calculus of Communicating Systems. R Milner, A Calculus of Communicating Systems. R Milner,

Report number ECS-LFCS-86-7, Laboratory for Report number ECS-LFCS-86-7, Laboratory for
Foundations of Computer Science, Department of Foundations of Computer Science, Department of
Computer Science, University of Edinburgh, UK. Computer Science, University of Edinburgh, UK.
The Specification of Complex Systems. B Co- The Specification of Complex Systems. B Cohen,
hen, W T Harwood, M I Jackson. Addison-Wes- W T Harwood, M I Jackson. Addison-Wesley,
ley, 1986. 1986.
B.30.2 CSP - Communicating Sequential Processes CSP - Processi Sequenziali di Comunicazione
Aim Scopo
CSP is a technique for the specification of con- Il CSP è una tecnica per la specifica dei sistemi
current software systems, i.e. systems of com- software concorrenti, cioè sistemi di processi di
municating processes operating concurrently. comunicazione che funzionano in concorrenza.
Description Descrizione:
CSP provides a language for the specification of Il CSP fornisce un linguaggio per la specifica di si-
systems of processes and proof for verifying stemi di processi e prova per verificare che l’im-
that the implementation of processes satisfies plementazione dei processi soddisfa le loro speci-
their specifications (described as a trace - per- fiche (descritto come traccia - ammissibile serie di
missible sequences of events). eventi).
A system is modelled as a network of inde- Un sistema è modellato come una rete di processi
pendent processes. Each process is described in indipendenti. Ogni processo è descritto nei termini
terms of all of its possible behaviours. A system di tutti i suoi possibili comportamenti. Un sistema è
is modelled by composing processes sequen- modellato componendo i processi in modo sequen-
tially or in parallel. Processes can communicate ziale o in parallelo. I processi possono comunicare
(synchronise or exchange data) via channels, (sincronizzare o scambiare dati) attraverso canali, e
the communication only taking place when le comunicazioni hanno luogo soltanto quando en-
both processes are ready. The relative timing of trambi i processi sono pronti. La temporizzazione
events can be modelled. relativa degli eventi può essere modellata.
The theory behind CSP was directly incorporat- La teoria di supporto al CSP è stata direttamente
ed into the architecture of the INMOS transput- incorporata nell’architettura del transputer IN-
er, and the OCCAM language allows a MOS, ed il linguaggio OCCAM consente che un
CSP-specified system to be directly implement- sistema specificato come CSP possa essere imple-
ed on a network of transputers. mentato direttamente su una rete di transputers.
Communicating Sequential Processes. C A R Communicating Sequential Processes. C A R Hoa-
Hoare, Prentice-Hall, 1985 re, Prentice-Hall, 1985
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 91 di 128
B.30.3 HOL - Higher Order Logic HOL - Logica di Ordine Superiore (Higher Order Logic)
Aim Scopo
This is a formal language intended as a basis for Questo è un linguaggio formale destinato come
hardware specification and verification. base per la specifica e la verifica dell’hardware.
HOL (Higher Order Logic) refers to a particular HOL (Higher Order Logic) fa riferimento ad una
logic notation and its machine support system, particolare annotazione logica e al suo sistema di
both of which were developed at the University supporto della macchina ed entrambi sono stati
of Cambridge Computer Laboratory. The logic sviluppati al “Computer Laboratory” della universi-
notation is mostly taken from Church’s Simple tà di Cambridge. L’annotazione logica è per lo più
Theory of Types and the machine support sys- presa dalla “Church’s Simple Theory of Types” e il
tem is based upon the LCF (Logic of Computa- sistema di supporto della macchina è basato sul si-
ble Functions) system. stema LCF (Logic of Computable Functions).
HOL: A Machine Orientated Formulation of HOL: A Machine Orientated Formulation of Hi-
Higher Order Logic. M. Gordon, University of gher Order Logic. M. Gordon, University of Cam-
Cambridge Technical Report, Number - 68. bridge Technical Report, Number - 68.
B.30.4 LOTOS LOTOS
Aim Scopo
LOTOS is a means for describing and reasoning LOTOS è un mezzo per descrivere e ragionare sul
about the behaviour of systems of concurrent, comportamento dei sistemi di processi di comuni-
communicating processes. cazione concorrenti.
LOTOS (Language for Temporal Ordering Spec- LOTOS (Language for Temporal Ordering Specifi-
ification) is based on CCS with additional fea- cation) è basato sul CCS con caratteristiche addi-
tures from the related algebras CSP and CIRCAL zionali prese dall’algebra correlata di CSP e CIR-
(Circuit Calculus). It overcomes the weakness of CAL (Circuit Calculus). Esso supera la debolezza
CCS in the handling of data structures and value di CCS nel maneggiare strutture di dati ed espres-
expressions by combining it with a second sioni di valori combinandoli con una seconda
component based on the abstract data type lan- componente basata sul linguaggio ACT ONE per i
guage ACT ONE. The process definition com- tipi di dati astratti. La componente di definizione
ponent of LOTOS could, however, be used with del processo di LOTOS potrebbe, tuttavia, essere
other formalisms for the description of abstract usata con altri formalismi per la descrizione di tipi
data types. di dati astratti.
Reference: Riferimento:
Information Processing Systems - Open Systems Information Processing Systems - Open Systems
Inter-connection - LOTOS - A Formal Descrip- Inter-connection - LOTOS - A Formal Description
tion Technique based on the Temporal Order- Technique based on the Temporal Ordering of
ing of Observational Behaviour. ISO DIS 8807, Observational Behaviour. ISO DIS 8807, July 20,
July 20, 1987. 1987.
B.30.5 OBJ OBJ

Aim Scopo
To provide a precise system specification with Fornire una specifica di sistema precisa con retro-
user feed-back and system validation prior to azione dell’utente e un sistema di validazione pri-
implementation. ma dell’implementazione.
OBJ is an algebraic specification language. Us- OBJ è un linguaggio di specificazione algebrica.
ers specify requirements in terms of algebraic Gli utenti specificano i requisiti in termini di
equation. The behavioural, or constructive, as- equazioni algebriche. Gli aspetti di comportamen-
pects of the system are specified in terms of op- to o costruttivi del sistema sono specificati in ter-
erations acting on abstract data types (ADT). An mini di operazioni che agiscono sui tipi di dati
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 92 di 128
ADT is like an ADA package where the opera- astratti (ADT). Un ADT è come un pacchetto ADA
tor behaviour is visible whilst the implementa- dove il comportamento dell’operatore è visibile,
tion details are “hidden”. mentre i dettagli di implementazione sono “na-
scosti”.
An OBJ specification, and subsequent step-wise Una specifica OBJ, e la successiva implementazio-
implementation, is amenable to the same formal ne per raffinamenti, è riconducibile alle medesi-
proof techniques as other formal approaches. me tecniche di prova formale come altri approcci
Moreover, since the constructive aspects of the formali. Inoltre, dal momento che gli aspetti co-
OBJ specification are machine-executable, it is struttivi della specifica OBJ sono eseguibili dalla
straightforward to achieve system validation macchina, la validazione del sistema è ottenuta
from the specification itself. Execution is essen- direttamente dalla specifica stessa. L’esecuzione è
tially the evaluation of a function by equation essenzialmente la valutazione di una funzione per
substitution (re-writing) which continues until mezzo di sostituzione dell’equazione (riscrittura)
specific output value is obtained. This executa- che continua fino a quando è ottenuto un valore
bility allows end-users of the envisaged system di uscita specifico. Questa eseguibilità consente
to gain a “view” of the eventual system at the all’utente finale del sistema previsto di ottenere
system specification stage without the need to una “panoramica” del sistema definitivo nella fase
be familiar with the underlying formal specifica- di specifica del sistema senza la necessità di avere
tion techniques. familiarità con le tecniche di specifica formali sot-

tostanti.
As with all other ADT techniques, OBJ is only Come con tutte le altre tecniche ADT, OBJ è ap-
applicable to sequential systems, or to sequen- plicabile solo a sistemi sequenziali, o ad aspetti
tial aspects of concurrent systems. OBJ has sequenziali di sistemi concorrenti. OBJ è stato
been widely used for the specification of both ampiamente usato per la specifica di applicazioni
small and large-scale industrial applications. industriali sia in scala ridotta che ampia.
An introduction to OBJ; A language for Writing An introduction to OBJ; A language for Writing
and Testing Specifications. J A Goguen and and Testing Specifications. J A Goguen and JTar-
JTardo, Specification of Reliable Software, IEEE do, Specification of Reliable Software, IEEE Press
Press 1979, reprinted in Software Specification 1979, reprinted in Software Specification Tech-
Techniques, N Gehani, A McGettrick (eds), Ad- niques, N Gehani, A McGettrick (eds), Addi-
dison-Wesley, 1985. son-Wesley, 1985.
Algebraic Specification for Practical Software Algebraic Specification for Practical Software Pro-
Production. C Rattray, Cogan Press, 1987. duction. C Rattray, Cogan Press, 1987.
An Algebraic Approach to the Standardisation An Algebraic Approach to the Standardisation and
and Certification of Graphics Software. R Gnatz, Certification of Graphics Software. R Gnatz, Com-
Computer Graphics Forum 2(2/3), 1983. puter Graphics Forum 2(2/3), 1983.
DTI STARTS Guide. 1987, NCC, Oxford Road, DTI STARTS Guide. 1987, NCC, Oxford Road,
Manchester, UK. Manchester, UK.
B.30.6 Temporal Logic Logica Temporale
Aim Scopo
Direct expression of safety and operational re- Espressione diretta di requisiti di sicurezza e ope-
quirements and formal demonstration that these rativi e dimostrazione formale che queste proprie-
properties are preserved in the subsequent de- tà sono conservate nei passaggi di sviluppo suc-
velopment steps. cessivi.
Standard First Order Predicate Logic contains no Lo Standard First Order Predicate Logic non contie-
concept of time. Temporal logic extends First ne alcun concetto di tempo. La logica temporale
Order logic by adding modal operators (e.g. estende la logica First Order aggiungendo operato-
“Henceforth” and “Eventually”). These opera- ri modali (ad esempio. “Henceforth” (d’ora innan-
tors can be used to qualify assertions about the zi) e “Eventually” (in fine)). Questi operatori pos-
system. For example, safety properties might be sono essere usati per qualificare asserzioni inerenti
required to hold “henceforth”, whilst other de- il sistema. Per esempio, proprietà di sicurezza po-
sired system states might be required to be at- trebbero essere richieste per sostenere “hencefor-
tained “eventually” from some other initiating th”, mentre altri stati del sistema desiderato potreb-
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 93 di 128
state. Temporal formulas are interpreted on se- bero essere richiesti per ottenere “eventually” da
quences of states (behaviours). What constitutes qualche altro inizio di stato. Formule temporali
a “state” depends on the chosen level of de- sono interpretate su sequenze di stati (comporta-
scription. It can refer to the whole system, a menti). Quello che costituisce uno “stato” dipende
system component or the computer program. dal livello di descrizione scelto. Esso può riferirsi
Quantified time intervals and constraints are not all’intero sistema, ad una componente del sistema
handled explicitly in temporal logic. Absolute o al programma del computer. Nella logica tempo-
timing has to be handled by creating additional rale intervalli di tempo quantificati e vincoli non
time states as part of the state definition. sono trattati espicitamente. La temporarizzazione
assoluta deve essere trattata con la creazione di sta-
ti di tempo addizionali come parte della definizio-
ne dello stato.
Temporal Logic of Programs. F Kroger EATCS Temporal Logic of Programs. F Kroger EATCS Mo-
Monographs on Computer Science, Vol 8, nographs on Computer Science, Vol 8, Springer
Springer Verlag, 1987. Verlag, 1987.
Design for Safety using Temporal Logic. J Gor- Design for Safety using Temporal Logic. J Gorski.
ski. SAFECOMP 86, Sarlat France, Pergamon SAFECOMP 86, Sarlat France, Pergamon Press,
Press, October 1986. October 1986.
Logics for Computer Programming. D Gabay. Logics for Computer Programming. D Gabay. Ellis
Ellis Horwood. Horwood.
B.30.7 VDM - Vienna Development Method VDM – Metodo di Sviluppo Vienna

Aim Scopo
The systematic specification and implementa- La specifica e la implementazione sistematica di
tion of sequential programs. programmi sequenziali.
VDM is a mathematically based specification Il VDM è una tecnica di specificazione su base ma-
technique and a technique for refining imple- tematica ed una tecnica di implementazioni per
mentations in a way that allows proof of their raffinamento in un modo che consente la prova
correctness with respect to the specification. della loro correttezza nei confronti della specifica.
The specification technique is model-based in La tecnica di specificazione è basata su modello,
that the system state is modelled in terms of nel senso che lo stato del sistema è modellato in
set-theoretic structures on which are defined in- termini di strutture di insieme teoriche sulle quali
variants (predicates), and operations on that sono definite invarianti (predicati), e operazioni
state are modelled by specifying their pre and su quello stato sono modellate specificando le
post-conditions in terms of the system state. loro pre e post condizioni in termini di stato del
Operations can be proved to preserve the sys- sistema. Le operazioni possono essere provate
tem invariants. per preservare le invarianti del sistema.
The implementation of the specification is done L’implementazione della specifica è eseguita me-
by the reification of the system state in terms of diante la conversione dello stato del sistema in
data structures in the target language and by re- termini di struttura dei dati nel linguaggio previsto
finement of the operations in terms of a pro- e per raffinamento delle operazioni nei termini di
gram in the target language. Reification and re- un programma nel linguaggio previsto (target).
finement steps give rise to proof obligations Gli stadi di conversione e di affinamento suscita-
that establish their correctness. Whether or not no l’obbligo di prove che stabiliscano la loro cor-
these obligations are carried out is a choice rettezza. È una scelta del progettista quella di ese-
made by the designer. guire o meno tali obblighi.
VDM is principally used in the specification Il VDM è principalmente usato nella fase di speci-
stage but can be used in the design and imple- ficazione, ma può essere usato nelle fasi di pro-
mentation stages leading to source code. It can gettazione e di implementazione conducendo al
only be applied to sequential programs or the codice sorgente. Può essere applicato solo a pro-
sequential processes in concurrent systems. grammi sequenziali o a processi sequenziali in si-
stemi concorrenti.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 94 di 128
Software Development - A Rigorous Approach. Software Development - A Rigorous Approach. C
C B Jones. Prentice-Hall, 1980. B Jones. Prentice-Hall, 1980.
Formal Specification and Software Development. Formal Specification and Software Development.
D Bjorner & C B Jones. Prentice-Hall, 1982. D Bjorner & C B Jones. Prentice-Hall, 1982.
Systematic Software Development using VDM. Systematic Software Development using VDM. C
C B Jones. Prentice-Hall, 1986. B Jones. Prentice-Hall, 1986.
The Specification of Complex Systems. B Co- The Specification of Complex Systems. B Cohen,
hen, W T Harwood and M I Jackson. Addi- W T Harwood and M I Jackson. Addison-Wesley,
son-Wesley, 1986. 1986.
B.30.8 Z and B ZeB
Aim Scopo
Z is a specification language notation for se- Il metodo Z è un’annotazione di linguaggio di
quential systems and a design technique that al- specificazione per sistemi sequenziali ed una tec-
lows the developer to proceed from a Z specifi- nica di progettazione che consente allo sviluppa-
cation to executable algorithms in a way that tore di procedere da una specifica Z ad algoritmi
allows proof of their correctness with respect to eseguibili in modo da consentire la prova della
the specification. loro correttezza nei confronti della specifica.
Z is principally used in the specification stage Z è usato principalmente nella fase di specifica-
but a method has been devised to go from zione, ma è stato escogitato un metodo per passa-
specification into a design and an implementare dalla specifica fino a una progettazione ed
tion. It is best suited to the development of data un’implementazione. Esso è più adatto allo svi-
oriented, sequential systems. luppo di sistemi sequenziali ed orientati ai dati.
B is an associated method. Il B è un metodo associato.
Like VDM, the specification technique is mod- Come VDM, la tecnica di specifica è basata su
el-based in that the system state is modelled in modello, nel senso che lo stato del sistema è mo-
terms of set-theoretic structures on which are dellato in termini di strutture di insieme teoriche
defined invariants (predicates), and operations sulle quali sono definite invarianti (predicati), e le
on that state are modelled by specifying their operazioni su questi stati sono modellate specifi-
pre and post-conditions in terms of the system cando le loro pre e post condizioni in termini di
state. Operations can be proved to preserve the stato del sistema. Le operazioni possono essere
system invariants thereby demonstrating their provate per preservare le invarianti del sistema di-
consistency. The formal part of a specification is mostrando così la loro coerenza. La parte formale
divided into schemas which allow the structur- della specifica è suddivisa in schemi che consen-
ing of specifications through refinement. tono la strutturazione delle specifiche tramite affi-
namento.
Typically, a Z specification is a mixture of for- Tipicamente, una specifica di Z è un misto di Z
mal Z and informal explanatory text in natural formale e di testo esplicativo informale in lin-
language. (Formal text on its own can be too guaggio naturale. (Il testo formale, per se stesso
terse for easy reading and often its purpose può essere troppo conciso per una facile lettura e
needs to be explained, while the informal natu- spesso è necessario che sia spiegato il suo fine,
ral language can easily become vague and im- mentre il linguaggio naturale informale può di-
precise). ventare facilmente vago e impreciso).
Unlike VDM, Z is a notation rather than a com- A differenza di VDM, Z è un’annotazione piutto-
plete method. However an associated method sto che un metodo completo. Tuttavia un metodo
(called B) has been developed which can be associato (chiamato B) è stato sviluppato in modo
used in conjunction with Z. The B method is da poterlo usare in associazione con Z. Il metodo
based on the principle of step-wise refinement B è basato sul principio del procedimento per af-
finamenti successivi.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 95 di 128
The Z Notation - A Reference Manual. J M The Z Notation - A Reference Manual. J M Spivey,
Spivey, Prentice Hall, 1988. Prentice Hall, 1988.
Specification Case Studies. Edited by I Hayes, Specification Case Studies. Edited by I Hayes,
Prentice-Hall, 1987. Prentice-Hall, 1987.
Specification of the UNIX Filestore. C Morgan Specification of the UNIX Filestore. C Morgan and
and B Sufrin. IEEE Transactions on Software En- B Sufrin. IEEE Transactions on Software Enginee-
gineering, SE-10, 2 March 1984. ring, SE-10, 2 March 1984.
The B Book - Assigning Programs to Meanings. The B Book - Assigning Programs to Meanings. J
J R Abrial, Cambridge United Press, 1996. R Abrial, Cambridge United Press, 1996.
B.31 Formal Proof (Referenced by clause 11) Prova Formale (Riferimento all’art. 11)
Aim Scopo
Using theoretical and mathematical models and Usando regole e modelli teorici e matematici è
rules it is possible to prove the correctness of a possibile provare la correttezza di un programma
program without executing it. senza eseguirlo.
A number of assertions are stated at various lo- Sono stabilite una serie di asserzioni in varie posi-
cations in the program, and they are used as zioni nel programma, ed esse vengono usate
pre and post conditions to various paths in the come pre e post condizioni per vari percorsi nel
program. The proof consists of showing that the programma. La prova consiste nel mostrare che il
program transfers the preconditions into the programma trasferisce le precondizioni nelle
post-conditions according to a set of logical post-condizioni secondo un’insieme di regole lo-
rules, and that the program terminates. giche, e che il programma termina.
Several Formal Methods are described in this Nella bibliografia sono descritti vari Metodi For-
bibliography, for instance, CCS, CSP, HOL, LO- mali, per esempio, CCS, CSP, HOL, LOTOS, OBJ,
TOS, OBJ, Temporal Logic, VDM and Z. The de- Logica di Tempo, VDM e Z. La loro descrizione
scriptions of these can be found under the sec- può essere trovata nella sezione “Metodi Formali”.
tion “Formal Methods”.
Can Program Proving be made Practical. J. Can Program Proving be made Practical. J. Dahl,
Dahl, Research Report, ISBN 82-90230-26-5 Research Report, ISBN 82-90230-26-5 No33, Oslo,
No33, Oslo, May May
B.32 Forward Recovery (Referenced by Recupero in avanti (Forward Recovery)

clause 9) (Riferimento all’art. 9)
Aim Scopo
To provide correct functional operation in the Fornire attività funzionale corretta in presenza di
presence of one or more faults. uno o più malfunzionamenti.
If a fault has been detected, the current state of Se è stato rilevato un malfunzionamento, lo stato
the system is manipulated to obtain a state, corrente del sistema è manipolato per ottenere
which will be consistent some time later. This uno stato, che sarà coerente nel seguito. Questo
concept is especially suited for real-time sys- concetto è particolarmente adatto per sistemi in
tems with a small database and fast rate of tempo reale con una piccola base dati ed un ele-
change of the internal state. It is assumed, that vato tasso di modifiche dello stato interno. Si as-
at least part of the system state may be imposed sume che almeno parte dello stato del sistema
onto the environment, and only part of the sys- può essere imposto sull’ambiente, e solo parte
tem states are influenced (forced) by the envi- degli stati del sistema sono influenzati (forzati)
ronment. dall’ambiente.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 96 di 128
B.33 Graceful Degradation Degrado Soffice
Aim Scopo
To maintain the more critical system functions Mantenere disponibili le funzioni di sistema più
available despite failures by dropping the less critiche nonostante i mancati funzionamenti, con
critical functions. caduta delle funzioni meno critiche.
This technique gives priorities to the various Questa tecnica dà priorità a varie funzioni da effet-
functions to be carried out by the system. The tuare da parte del sistema. La progettazione pertan-
design then ensures that should there be insuffi- to assicura che se ci fossero risorse insufficienti a
cient resources to carry out all the system func- svolgere tutte le funzioni del sistema, allora le fun-
tions, then the higher priority functions are car- zioni con più alta priorità sono svolte preferendole
ried out in preference to the lower ones. For a quelle con più bassa priorità. Per esempio, funzio-
example, error and event logging functions may ni di registrazione di errori ed eventi possono avere
be lower priority than system control functions. priorità inferiore a quelle delle funzioni di controllo
System control would continue if the hardware del sistema. Il controllo del sistema continuerebbe
associated with error logging were to fail. Fur- se l’hardware associato con la registrazione di errori
ther, should the system control hardware fail, stesse per andare in avaria. Inoltre, se andasse in
but not the error logging hardware, then the er- avaria l’hardware del controllo di sistema, ma non
ror logging hardware would take over the con- l’hardware di registrazione degli errori, allora l’hard-
trol function. This is predominantly applied to ware della registrazione degli errori subentrerebbe
hardware but is applicable to the total system. It nella funzione di controllo. Questo è prevalente-
must betaken into account from the top-most mente applicato all’hardware, ma è applicabile
design phase. all’intero sistema. Di esso si deve tenere conto dalla
fase più in alto della progettazione.
Space Shuttle Software. C.T. Sheridan, Datama- Space Shuttle Software. C.T. Sheridan, Datama-
tion, Vol 24, July 1978 tion, Vol 24, July 1978
The Evolution of Fault-Tolerant Computing. Vol 1 The Evolution of Fault-Tolerant Computing. Vol 1 of
of Dependable Computing and Fault Tolerant Sys- Dependable Computing and Fault Tolerant Systems,
tems, Edited by A. Avizienis, H. Kopetz, and J.C. Edited by A. Avizienis, H. Kopetz, and J.C. Laprie,
Laprie, Springer-Verlag, ISBN 3-211-81941-X, 1987. Springer-Verlag, ISBN 3-211-81941-X, 1987.
Fault Tolerance, Principle and Practices. Vol 3 of Fault Tolerance, Principle and Practices. Vol 3 of
[2] above, T. Anderson and P.A. Lee, Spring- [2] above, T. Anderson and P.A. Lee, Springer-Ver-
er-Verlag, ISBN 3-211-82077-9, 1987. lag, ISBN 3-211-82077-9, 1987.
B.34 Hazard and Operability Study (HAZOP) Studi del Pericolo e di Funzionalità (HAZOP)
Aim Scopo
To establish, by a series of systematic examina- Stabilire, con una serie di esami sistematici delle
tions of the component sections of the compu- sezioni componenti del sistema computerizzato e
ter system and its operation, failure modes della sua funzionalità, i modi di mancato funzio-
which lead to result in potentially hazardous sit- namento che portano al risultato in situazioni po-
uations in the controlled system. tenzialmente pericolose nel sistema controllato.
Typical hazardous events on the controlled sys- Eventi tipici pericolosi nei sistemi controllati sono il
tems are fire, explosion, release of toxic material fuoco, l’esplosione, l’emissione di materiali tossici
(chemical or nuclear) or serious economic loss. (chimici o nucleari) o danni economici importanti.
It is assumed that the hazardous events on the Si assume che gli eventi pericolosi nel sistema da
system being controlled have been identified in controllare siano stati identificati con una indivi-
a separate Hazard Analysis and the conse- duale Analisi dei Pericoli e che le conseguenze
quence of the hazardous events classified into degli eventi pericolosi siano state classificate se-
degrees of seriousness. condo gradi di severità.
The analysis which covers all stages of the L’analisi copre tutti le fasi del ciclo di vita del pro-
project life-cycle, from specification through de- getto, dalla specifica, attraverso la progettazione,
sign to maintenance and modification, and is in- alla manutenzione e alla modifica, ed è previsto
tended to identify at each stage events/failure che identifichi per ogni fase eventi/modi di man-
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 97 di 128
modes which could lead to potential hazards cato funzionamento che potrebbero condurre a
and thus eliminate them. potenziali pericoli e di conseguenza eliminarli.
The analysis is carried out by a team of engi- L’analisi è eseguita da un gruppo di ingegneri (co-
neers (covering computer, instrument, electrical, prendo discipline informatiche, strumentali, elet-
process, safety and operational disciplines) led triche, del processo, la sicurezza e operative) gui-
by a trained specialist in hazard analysis tech- data da uno specialista istruito nelle tecniche
niques in a series of scheduled meetings. dell’analisi del pericolo in una serie di incontri
programmati.
It is important that a fixed time schedule is allo- È importante che sia assegnato nell’ambito del
cated within the project for the meetings; each progetto un programma di incontri con tempi sta-
one scheduled for at least half a day and for ef- biliti; ciascuno programmato per almeno mezza
fectiveness no more than four per week to al- giornata e non più di quattro per settimana per
low for maintaining the flow of accompanying assicurare l’efficienza e per permettere di garanti-
documentation. re il flusso della documentazione associata.
Prior to the study, agreed checklists for the sys- Prima dello studio, devono essere compilate liste
tematic examination will have been compiled di controllo concordate per un esame sistematico
and for each section of the system leading e per ogni parte del sistema devono essere poste
questions such as; What if it happens? How can domande di rilievo quali; Che cosa può accadere?
it happen? When can it happen? Does it matter? Come può accadere se? Quando può accadere? È
are asked. When positive answers are given fur- di interesse?. Quando sono date risposte positive
ther questions are asked, such as; What can be vanno poste ulteriori domande quali: Che cosa
done about it? When must it be done? Is there può essere fatto in merito? Quando deve essere
an alternative? etc. fatto? C’è una alternativa? ecc.
For the first part of the analysis it is suggested Per la prima parte dell’analisi si suggerisce che sia
that the computer installation as a whole is ex- esaminata l’installazione del computer nel suo
amined. The second and subsequent parts in- complesso. La seconda parte e le successive coin-
volve detailed examination of the relevant parts volgono l’esame dettagliato delle parti di rilievo
of the computer systems itself. degli stessi sistemi computerizzati.
At each part or stage of the analysis, the objec- In ogni parte o stadio dell’analisi, l’obbiettivo è
tive is to identify failure modes which lead to quello di identificare i modi di mancato funziona-
potential hazards on the controlled system and mento che conducono a pericoli potenziali sul si-
the degree of their effect. The major component stema controllato ed il grado del loro effetto. Le
parts of the computer system are further sub-di- principali parti componenti del sistema compute-
vided and where necessary subjected to a sepa- rizzato sono ulteriormente suddivise e, ove neces-
rate analysis. sario, soggette ad analisi separata.
At suitable points throughout the systematic In punti adatti per tutta l’analisi sistematica devo-
analysis, action review meetings will be ar- no essere organizzate riunioni di revisione delle
ranged. azioni.
It is essential that comprehensive records of the È essenziale che siano tenute registrazioni esau-
meetings are kept, for they will form a substan- rienti delle riunioni, poiché esse costituiranno una
tial part of the system hazard/safety dossier. parte sostanziale del dossier pericolo/sicurezza
del sistema.
After a number of meetings it is suggested that a Dopo un certo numero di riunioni si suggerisce di
review meeting be held to ensure that actions tenere una riunione di revisione per assicurare
are followed up, modifications suggested dur- che sia stato dato seguito alle azioni, all’inseri-
ing the Study meetings are incorporated into mento delle modifiche suggerite durante le riu-
the study etc. nioni di studio, ecc.
HAZOP and HAZAN. T.A. Kletz, 1986, 2nd Edi- HAZOP and HAZAN. T.A. Kletz, 1986, 2nd Edi-
tion, Institution of Chemical Engineers, 165-171 tion, Institution of Chemical Engineers, 165-171
Railway Terrace, Rugby, CV1 3HQ, UK. Railway Terrace, Rugby, CV1 3HQ, UK.
Reliability and Hazard Criteria for Programma- Reliability and Hazard Criteria for Programmable
ble Electronic Systems in the Chemical Industry. Electronic Systems in the Chemical Industry.
E. Johnson, Proc of “Safety and Reliability of E. Johnson, Proc of “Safety and Reliability of PES”,
PES”, PES 3 Safety Symposium, B.K. Daniels PES 3 Safety Symposium, B.K. Daniels (ed), 28-30
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 98 di 128
(ed), 28-30 May 1986, Guernsey Channel Is- May 1986, Guernsey Channel Islands, Elsevier Ap-
lands, Elsevier Applied Science, 1986. plied Science, 1986.
Reliability Engineering and Risk Assessment. E.J. Reliability Engineering and Risk Assessment. E.J.
Henlty and H. Kumamoto, Prentice Hall,1981. Henlty and H. Kumamoto, Prentice Hall, 1981.
Systems Reliability and Risk Analysis. E.G. Fren- Systems Reliability and Risk Analysis. E.G.
kel, Martinus Nijhogg 1984. Frenkel, Martinus Nijhogg 1984.
B.35 Impact Analysis (Referenced by clause 16) Analisi dell’Impatto (Riferimento all’art. 16)
Aim Scopo
To identify the effect that a change or an en- Identificare l’effetto che una modifica od un mi-
hancement to a software system will have to glioramento ad un sistema software avrà su altri
other modules in that software system as well moduli in quel sistema software, così come su al-
as to other systems. tri sistemi.
Prior to a modification or enhancement being Prima che sia introdotta una modifica od un mi-
performed on the software an analysis shall be glioramento nel software, deve essere eseguita
undertaken to identify the impact of the modifi- una verifica per identificare l’impatto della modifi-
cation or enhancement on the software and to ca o del miglioramento sul software ed anche per
also identify the affected software systems and identificare i sistemi software ed i moduli interes-
modules. sati dal cambiamento.
After the analysis has been completed a deci- Dopo il completamento dell’analisi è richiesta una
sion is required concerning the reverification of decisione circa la riverifica del sistema software.
the software system. This depends on the Questa dipende dal numero dei moduli interessati
number of modules affected, the criticality of dal cambiamento, la criticità dei moduli interessati
the affected modules and the nature of the e la natura del cambiamento. Le decisioni possibi-
change. The possible decisions are: li sono:
i) only the changed module to be reverified; i) solo i moduli modificati sono riverificati;
ii) all identified affected modules are reveri- ii) tutti i moduli interessati dal cambiamento
fied; and sono riverificati; e
iii) the complete system is reverified. iii) il completo sistema è riverificato.
B.36 Information Hiding / Encapsulation Occultamento/Incapsulamento delle

(Referenced by D.9) informazioni (Riferimento a D.9)
Aim Scopo
To increase the reliability and maintainability of Aumentare l’affidabilità e la manutenibilità del
software. software.
Data that is globally accessible to all software I dati che sono globalmente accessibili a tutte le
components can be accidentally or incorrectly componenti del software possono essere modifi-
modified by any of these components. Any cati accidentalmente o in modo scorretto da qua-
changes to these data structures may require lunque di queste componenti. Ogni cambiamento
detailed examination of the code and extensive a queste strutture di dati può richiedere un esame
modifications. dettagliato del codice e delle modifiche estese.
Information hiding is a general approach for L’Occultamento dell’informazione è un approccio
minimising these difficulties. The key data struc- generale per minimizzare queste difficoltà. Le
tures are “hidden” and can only be manipulated strutture dei dati chiave sono “occultate” e posso-
through a defined set of access procedures. no essere manipolate solo attraverso un’insieme
This allows the internal structures to be modi- definito di procedure di accesso. Questo consente
fied or further procedures to be added without che la struttura interna sia modificata o di aggiun-
affecting the functional behaviour of the re- gere ulteriori procedure senza influenzare il com-
maining software. For example, a name directo- portamento funzionale del software rimanente.
ry might have access procedures Insert, Delete Per esempio, una directory stabilita potrebbe ave-
and Find. The access procedures and internal re procedure di accesso Inserisci, Cancella e Tro-
data structures could be re-written (e.g. to use a va. Le procedure di accesso e le strutture dei dati
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 99 di 128
different look-up method or to store the names interni potrebbero essere riscritte (ad esempio per
on a hard disk) without affecting the logical be- usare un metodo diverso di ricerca o per imma-
haviour of the remaining software using these gazzinare i nomi su un disco rigido) senza in-
procedures. fluenzare il comportamento logico del software ri-
manente usando queste procedure.
This concept of an abstract data type is directly Questo concetto di tipo di dato astratto è supporta-
supported in a number of programming lan- to direttamente in molti linguaggi di programma-
guages, but the basic principle can be applied zione, ma il principio di base può essere applicato
whatever programming language is used. a qualsiasi linguaggio di programmazione usato.
Software Engineering: Planning for Change, D A Software Engineering: Planning for Change, D A
Lamb, Prentice Hall, 1988. Lamb, Prentice Hall, 1988.
On the Design and Development of Program On the Design and Development of Program Fa-
Families, D L Parnas, IEEE Trans SE-2, Mar 1976. milies, D L Parnas, IEEE Trans SE-2, Mar 1976.
B.37 Interface Testing (Referenced by clause 10) Prove sulle Interfacce (Riferimento all’art. 10)
Aim Scopo
To demonstrate that interfaces of subprograms Dimostrare che le interfacce di sottoprogrammi
do not contain any errors or any errors that lead non contengono alcun errore o alcun errore che
to failures in a particular application of the soft- conduca a mancati funzionamenti in una partico-
ware or to detect all errors that may be relevant. lare applicazione del software o rilevare tutti gli
errori che possono essere pertinenti.
Several levels of detail or completeness of test- Sono praticabili vari livelli di dettaglio o di com-
ing are feasible. The most important levels are pletezza di prova. I più importanti livelli di prova
testing: sono:
all interface variables at their extreme posi- tutte le variabili di interfaccia nei loro stati
tions; estremi;
all interface variable individually at their ex- individualmente tutte le variabili di interfaccia
treme values with other interface variables ai loro valori estremi con altre variabili di in-
at normal values; terfaccia al valore normale;
all values of the domain of each interface tutti i valori del dominio di ogni variabile di
variable with other interface variables at interfaccia con altre variabili di interfaccia al
normal values; valore normale;
all values of all variables in combination. tutti i valori di tutte le variabili in combinazio-
this may only be feasible for small interfac- ne. Questo può essere fattibile solo per picco-
es; le interfacce;
the specified test conditions relevant to le condizioni di prova specificate relative ad
each call of each subroutine. ogni chiamata di ogni subroutine.
These tests are particularly important if their in- Queste prove sono particolarmente importanti se
terfaces do not contain assertions that detect in- le loro interfacce non contengono asserzioni che
correct parameter values. They are also impor- rilevano valori di parametri scorretti. Esse sono
tant after new configurations of pre-existing importanti anche dopo che sono state generate
subprograms have been generated. nuove configurazioni di sottoprogrammi preesi-
stenti.
B.38 Language Subset (Referenced by clause 10 Sottoinsieme del Linguaggio (Riferimento

and D.4) all’art. 10 e D.4)
Aim Scopo
To reduce the probability of introducing pro- Ridurre la probabilità di introdurre malfunziona-
gramming faults and increase the probability of menti di programmazione ed aumentare la proba-
detecting any remaining faults. bilità di rilevare ogni restante malfunzionamento.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 100 di 128
The language is examined to identify program- Il linguaggio è esaminato per identificare i co-
ming constructs which are either error-prone or strutti di programmazione che sono, o inclini
difficult to analyse, for example, using static all’errore, o difficili da esaminare, per esempio,
analysis methods. A language subset is then de- usando metodi di analisi statica. Un sottoinsieme
fined which excludes these constructs. del linguaggio è quindi definito per escludere
questi costrutti.
B.39 Memorising Executed Cases (Referenced by Memorizzazione dei Casi Eseguiti (Riferimento
Aim Scopo
To force the software to fail safe if it executes Forzare il software nella condizione di fail safe se
an unlicensed path. esegue un percorso non consentito.
During licensing a record is made of all relevant Durante l’autorizzazione, un record è costituito da
details of each program execution. During nor- tutti i dettagli relativi ad ogni esecuzione di pro-
mal operation each program execution is com- gramma. Durante il normale funzionamento cia-
pared with the set of the licensed executions. If scuna esecuzione di programma è confrontata
it differs, a safety action is taken. con l’insieme di esecuzioni autorizzate. Se differi-
sce, è intrapresa un’ azione in sicurezza
The execution record can be the sequence of Il record di esecuzione può essere la sequenza di
the individual decision-to-decision paths (DD- percorsi individuali, decisione per decisione,
paths) or the sequence of the individual access- (DDpaths) o la sequenza di accessi individuali ad
es to arrays, records or volumes, or both. una schiera (arrays), record o volumi o entrambi.
Different methods of storing execution paths Sono possibili diversi metodi di memorizzazione
are possible. Nash-coding methods can be used dei percorsi di esecuzione. Il metodo di codifica
to map the execution sequence onto a single Nash può essere usato per mappare la sequenza
large number or sequence of numbers. During di esecuzione su un unico grande numero o su
normal operation the execution path value must una sequenza di numeri. Durante il normale fun-
be checked against the stored cases before any zionamento il valore del percorso di esecuzione
output operation occurs. deve essere confrontato con i casi memorizzati
prima che si verifichi alcuna operazione di uscita.
Since the possible combinations of deci- Poiché le possibili combinazioni di percorsi, deci-
sion-to-decision paths during one program is sione per decisione, nel corso di un programma è
very large, it may not be feasible to treat pro- molto grande, può non essere fattibile trattare i
grams as a whole. In this case, the technique programmi nella loro interezza. In questo caso, la
can be applied at module level. tecnica può essere applicata a livello di modulo.
Fail-safe Software - Some Principles and a Case Fail-safe Software - Some Principles and a Case
Study. W. Ehrenberger, Proc. SARSS 1987,Al- Study. W. Ehrenberger, Proc. SARSS 1987, Altrin-
tringham, Manchester, UK, Elsevier Applied Sci- gham, Manchester, UK, Elsevier Applied Science,
ence, 1987. 1987.
B.40 Library of Trusted/Verified Modules and Libreria di Moduli e Componenti

Components (Ref’d by clause 10) Affidabili/Verificati (Riferimento all’art. 10)
Aim Scopo
To avoid the need for software modules and Evitare che sia ampiamente rivalidata o riprogetta-
hardware component designs to be extensively ta la progettazione di moduli software e di com-
revalidated or redesigned for each new applica- ponenti hardware per ogni nuova applicazione.
tion. Also to advantage designs which have not Anche per avvantaggiare le progettazioni che non
been formally or rigorously validated but for sono state validate formalmente o rigorosamente,
which considerable operational history is avail- ma per le quali sono disponibili considerevoli
able. esperienze di funzionamento.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 101 di 128
Well designed and structured PESs are made up PES ben progettati e strutturati sono costituiti da
of a number of hardware and software compo- molti componenti hardware e software e moduli
nents and modules which are clearly distinct chiaramente distinti e che interagiscono tra loro in
and which interact with each other in clearly modi chiaramente definiti.
defined ways.
Different PESs designed for differing applica- Differenti PES progettati per diverse applicazioni
tions will contain a number of modules or com- conterranno un numero di moduli o componenti
ponents which are the same or very similar. che sono identici o molto simili. Costruire una li-
Building up a library of such generally applica- breria di tali moduli generalmente applicabili,
ble modules allows much of the resource nec- permette di condividere su più di una applicazio-
essary for validating the designs to be shared by ne le risorse necessarie a validare le progettazio-
more than one application. ni.
Furthermore the use of such modules in multi- Inoltre, l’uso di tali moduli in più applicazioni for-
ple applications provides empirical evidence of nisce l’esperienza empirica di un uso con funzio-
successful operational use. This empirical evi- namento di successo. Questa evidenza empirica
dence justifiably enhances the trust which users legittimamente migliora la fiducia che gli utenti
are likely to have in the modules. avranno probabilmente nei moduli.
B.41 Markov Models (Referenced by clause 14) Modelli di Markov (Riferimento all’art. 14)
Aim Scopo
To evaluate the reliability, safety or availability Valutare l’affidabilità, la sicurezza o la disponibili-
of a system. tà di un sistema.
A graph of the system is constructed. The graph È costruito un grafico del sistema. Il grafico rappre-
represents the status of the system with regard to senta lo stato del sistema con riguardo ai suoi stati di
its failure states (the failure states are represented mancato funzionamento (gli stati di mancato funzio-
by the nodes of the graph). The edges between namento sono rappresentati dai nodi del grafico). I
nodes, which represent the failure events or re- margini tra i nodi, che rappresentano gli eventi di
pair events, are weighted with the corresponding mancato funzionamento o di riparazione, sono pe-
failure rates or repair rates. Note that the failure sati con i corrispondenti tassi di mancato funziona-
events, states and rates can be detailed in such a mento e di riparazione. Da notare che eventi di
way that a precise description of the system is mancato funzionamento, stati e tassi possono essere
obtained, e.g. detected or undetected failures, dettagliati in modo tale da ottenere una precisa de-
manifestation of a larger failure etc. scrizione del sistema, ad esempio, mancati funziona-
menti rilevati e non rilevati, manifestazione di un
mancato funzionamento più grande ecc.
The Markov technique is suitable for modelling La tecnica di Markov è adatta alla modellazione di
redundant systems in which the level of redun- sistemi ridondanti nei quali il livello di ridondan-
dancy varies with time due to component fail- za varia nel tempo a seguito di mancato funziona-
ure and repair. Other classical methods, for ex- mento e riparazione del componente. Altri metodi
ample, FMEA and FTA, cannot readily be classici, per esempio FMEA e FTA, non possono
adapted to modelling the effects of failures essere adattati prontamente per modellare gli ef-
throughout the life-cycle of the system since no fetti dei mancati funzionamenti in ogni momento
simple combinatorial formulae exist for calculat- del ciclo di vita del sistema dato che non esiste al-
ing the corresponding probabilities. cuna formula combinatoria semplice per il calcolo
delle corrispondenti probabilità.
In the simplest cases, the formulae which de- Nei casi più semplici, le formule che descrivono
scribe the probabilities of the system are readily le probabilità del sistema sono già disponibili nel-
available in the literature or can be calculated la letteratura o, possono essere calcolate manual-
manually. In more complex cases, some meth- mente. In casi più complessi, esistono alcuni me-
ods of simplification (absorbing states) exist. todi di semplificazione (stati di assorbimento). Per
For very complex cases results can be calculat- casi molto complessi i risultati possono esser cal-
ed by computer simulation of the graph. colati con la simulazione al computer del grafico.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 102 di 128
The Theory of Stochastic Processes. R.E. Cox The Theory of Stochastic Processes. R.E. Cox and
and H.D. Miller, Methuen and Co. Ltd,London, H.D. Miller, Methuen and Co. Ltd,London, UK,
UK, 1968 1968
Finite MARKOV Chains. J.G. Kemeny and J.L. Snell, Finite MARKOV Chains. J.G. Kemeny and J.L. Snell,
D. Van Nostrand Company Inc.,Princeton, 1959 D. Van Nostrand Company Inc., Princeton, 1959
Reliability Handbook. B.A. Koslov and L.A. Reliability Handbook. B.A. Koslov and L.A.
Ushakov, Holt Rinehart and Winston Inc.,New Ushakov, Holt Rinehart and Winston Inc., New
York 1970 York 1970
The Theory and Practice of Reliable System De- The Theory and Practice of Reliable System Desi-
sign. D.P. Siewiorek and R.S. Swarz, Digital gn. D.P. Siewiorek and R.S. Swarz, Digital Press
Press 1982. 1982.
B.42 Metrics (Referenced by clause 11 and Metriche (Riferimento all’art. 11 e 14)

clause 14)
Aim Scopo
To predict the attributes of programs from prop- Predire gli attributi dei programmi dalle proprietà
erties of the software itself rather than from its del software stesso piuttosto che dal suo sviluppo
development or test history. o dalla storia delle sue prove.
These models evaluate some structural proper- Questi modelli valutano alcune proprietà struttu-
ties of the software and relate this to a desired rali del software e mettono in relazione questo
attribute such as reliability or complexity. Soft- con un attributo desiderato quale affidabilità o
ware tools are required to evaluate most of the complessità. Strumenti software sono richiesti per
measures. Some of the metrics which can be valutare la maggior parte delle misure. Alcune
applied are given below: delle metriche che possono essere applicate sono
stabilite qui sotto:
Graph Theoretic Complexity: this measure complessità Teorica del Grafico (Graph Theo-
can be applied early in the lifecycle to as- retic Complexity): questa misura può essere
sess trade-offs, and is based on the com- applicata all’inizio del ciclo di vita per valuta-
plexity of the program control graph, repre- re gli scambi, ed è basata sulla complessità
sented by its cyclomatic number; del grafico di controllo del programma, rap-
presentata dal suo numero ciclomatico;
number of ways to activate a certain mod- numero di modi per attivare un certo modulo
ule (accessibility): the more a module can (accessibilità): più un modulo può essere ac-
be accessed, the more likely it is to be de- cessibile, più è probabile che sia sottoponibi-
bugged; le a debugging
Software Science: this measure computes Scienza del Software: questa misura calcola la
the program length by counting the number lunghezza del programma contando il nume-
of operators and operands. It provides a ro degli operatori e degli operandi. Essa forni-
measure of complexity and estimates devel- sce una misura di complessità e stima le risor-
opment resources; se di sviluppo;
number of entries and exits per module: numero di entrate ed uscite per modulo: mini-
minimising the number of entry/exit points mizzare il numero dei punti di entrata/uscita è
is a key feature of structured design and una caratteristica chiave della progettazione
programming techniques. strutturata e delle tecniche di programmazione.
A Complexity Measure. T.J. McCabe, IEEE A Complexity Measure. T.J. McCabe, IEEE Trans.
Trans. on Software Engineering, Vol. SE-2, No. on Software Engineering, Vol. SE-2, No. 4, Dec
4, Dec 1976. 1976.
Models and Measurements for Quality Assess- Models and Measurements for Quality Assessmen-
ments of Software. S.N. Mohanty, ACMComput- ts of Software. S.N. Mohanty, ACMComputing Sur-
ing Surveys, Vol 11, No. 3, Sep 1979. veys, Vol 11, No. 3, Sep 1979.
Elements of Software Science. M.H. Halstead, Elements of Software Science. M.H. Halstead, El-
Elsevier, North Holland, New York, 1977. sevier, North Holland, New York, 1977.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 103 di 128
B.43 Modular Approach (Referenced by D.9) Approccio Modulare (Riferimento a D.9)
Aim Scopo
Decomposition of a software systems into small Decomposizione di sistemi software in piccole
comprehensible parts in order to limit the com- parti comprensibili al fine di limitare la complessi-
plexity of the system. tà del sistema.
A Modular Approach or modularisation contains Un Approccio Modulare o modularizzazione con-
several rules for the design, coding and mainte- tiene svariate regole per le fasi di progettazione,
nance phases of a software project. These rules codifica e manutenzione di un progetto software.
vary according to the design method employed Queste regole variano secondo il metodo di pro-
during design. Most methods contain the fol- gettazione impiegato durante lo sviluppo. La mag-
lowing rules: gior parte dei metodi contiene le seguenti regole:
a module shall have a single well defined un modulo deve avere un’ unico e ben defini-
task or function to fulfil; to compito o funzione da soddisfare;
connections between modules shall be lim- il collegamento tra moduli deve essere limita-
ited and strictly defined, coherence in one to e strettamente definito, la coerenza in un
module shall be strong; modulo deve essere elevata;

collections of subprograms shall be built la raccolta di sottoprogrammi deve essere co-
providing several levels of modules; struita prevedendo molti livelli di moduli;
subprogram sizes shall be restricted to some la dimensione dei sottoprogrammi deve esse-
specified value typically 2 to 4 screen sizes; re ristretta ad alcuni valori specificati tipica-
mente da 2 a 4 dimensioni dello schermo;
subprograms shall have a single entry and a i sottoprogrammi devono avere un’entrata
single exit only; sola e una sola uscita;
modules shall communicate with other i moduli devono comunicare con altri moduli
modules via their interfaces. Where global tramite le loro interfacce. Ove sono usate va-
or common variables are used they shall be riabili globali o comuni essi devono essere
well structured, access shall be controlled ben strutturati, l’accesso deve essere control-
and their use shall be justified in each in- lato e il loro uso deve essere giustificato in
stance; ogni situazione;
all module interfaces shall be fully docu- tutte le interfacce dei moduli devono essere
mented; completamente documentate;
each module shall hide something from its ogni modulo deve nascondere qualcosa del
environment; suo ambiente;
any modules interface shall contain the ogni interfaccia dei moduli deve contenere il
minimum number of parameters necessary minor numero di parametri necessari per la
for the modules function; and funzione dei moduli; e
a suitable restriction of parameter number un’idonea restrizione del numero dei parame-
shall be specified, typically 5. tri deve essere specificata, tipicamente 5.
B.44 Monte-Carlo Simulation Simulazione Monte-Carlo
Aim Scopo
To simulate phenomenon of the real world in Simulare fenomeni del mondo reale nel software
the software using random numbers. usando numeri casuali.
Monte-Carlo simulations are used to solve prob- Le simulazioni Monte-Carlo sono usate per risol-
lems. These problems fall into two classes: vere problemi. Questi problemi ricadono in due
classi:
probabilistic, where random numbers are probabilistici, ove i numeri casuali sono usati
used to generate a real world stochastic per generare fenomeni stocastici del mondo
phenomenon; and reale; e
deterministic, which are mathematically deterministici, che sono trasformati matemati-
translated into an equivalent probabilistic camente in un problema probabilistico equi-
problem. valente.
Monte-Carlo simulation injects a random La simulazione Monte-Carlo inserisce una serie di

number streams to simulate noise on an analytic numeri casuali per simulare disturbi in un segnale
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 104 di 128
signal or to add random biases or tolerances. analitico o aggiungere polarizzazioni casuali o tol-
The Monte-Carlo simulation is run to produce a leranze. La simulazione di Monte-Carlo è attuata
large sample from which statistical results are per produrre un ampio campione dal quale sono
obtained. ottenuti risultati statistici.
When using Monte-Carlo simulations care must Quando si usano simulazioni Monte-Carlo si deve
be taken to ensure that the biases, tolerances or aver cura di assicurare che le polarizzazioni, le
noise are reasonable values. tolleranze i disturbi abbiano valori ragionevoli.
A general principle of Monte-Carlo simulations Un principio generale nelle simulazioni Mon-
is to restate and reformulate the problem so that te-Carlo è quello di riesporre e formulare nuova-
the results obtained are as accurate as possible mente il problema in modo che i risultati ottenuti
rather than tackling the problem as initially stat- siano i più accurati possibili piuttosto che affron-
ed. tare il problema come stabilito all’inizio.
B.45 Performance Modelling (Referenced by D.2 Modellazione delle prestazioni (Riferimento a

and D.5) D.2 e D.5)
Aim Scopo
To ensure that the working capacity of the sys- Assicurare che la capacità di lavoro del sistema sia
tem is sufficient to meet the specified require- sufficiente a conseguire i requisiti specificati.
ments.
The requirements specification includes La specifica dei requisiti comprende requisiti di
throughput and response requirements for spe- trattamento e di risposta per funzioni specifiche,
cific functions, perhaps combined with con- combinate magari con vincoli nell’uso delle risor-
straints on the use of total system resources. se totali del sistema. La progettazione del sistema
The proposed system design is compared proposto è confrontata con i requisiti stabiliti da
against the stated requirements by
defining a model of the system processes, definizione di un modello dei processi del si-
and their interactions, stema e delle loro interazioni,
identifying the use of resources by each identificazione dell’uso di risorse da parte di
process, for example, processor time, com- ogni processo, per esempio, tempo del pro-
munications bandwidth, storage devices cessore, larghezza di banda della comunica-
etc), zione, dispositivi di memorizzazione, ecc.,
identifying the distribution of demands identificazione della distribuzione delle richie-
placed upon the system under average and ste poste al sistema nelle condizioni medie e
worst-case conditions, nei casi peggiori,
computing the mean and worst-case calcolo della capacità di trattamento nel caso
throughput and response times for the indi- peggiore e dei tempi di risposta per le funzio-
vidual system functions. ni singole del sistema.
For simple systems, an analytic solution may be Per sistemi semplici, può essere possibile una so-
possible whilst for more complex systems, luzione analitica, mentre per sistemi più comples-
some form of simulation is required to obtain si, è richiesta qualche forma di simulazione per
accurate results. ottenere risultati accurati.
Before detailed modelling, a simpler “resource Prima della modellazione dettagliata, può essere
budget” check can be used which sums the re- usata una verifica più semplice di “budget delle ri-
sources requirements of all the processes. If the sorse” che somma i requisiti delle risorse di tutti i
requirements exceed designed system capacity, processi. Se i requisiti eccedono la capacità del si-
the design is infeasible. Even if the design pass- stema progettato, la progettazione non è realizzabi-
es this check, performance modelling may le. Anche se la progettazione supera questa verifi-
show that excessive delays and response times ca, la modellazione delle prestazioni può mostrare
occur due to resource starvation. To avoid this che si verificano eccessivi ritardi e che occorrono
situation engineers often design systems to use tempi di risposta dovuti alla ristrettezza di risorse.
some fraction (e.g. 50 %) of the total resources Per evitare questa situazione, gli ingegneri spesso
so that the probability of resource starvation is progettano i sistemi usando alcune frazioni delle ri-
reduced. sorse totali (ad esempio il 50%) in modo da ridurre
la probabilità di ristrettezza di risorse.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 105 di 128
B.46 Performance Requirements (Referenced by D.6) Requisiti di Prestazione (Riferimento a D.6)
Aim Scopo
To establish that the performance requirements Stabilire che i requisiti di prestazione di un siste-
of a software system have been satisfied. ma software sono stati soddisfatti.
An analysis is performed of both the system and Viene eseguita un’analisi della specifica dei requi-
the software requirements specifications to siti sia del software che del sistema per identifica-
identify all general and specific, explicit and im- re tutti i requisiti di prestazione, generali e specifi-
plicit performance requirements. ci, espliciti ed impliciti.
Each performance requirement is examined in Ciascun requisito di prestazione è esaminato a
turn to determine turno per determinare
the success criteria to be obtained, i criteri del successo da ottenere,
whether a measure against the success crite- se può essere ottenuta una misura dei criteri
ria can be obtained, di successo,
the potential accuracy of such measurements, la precisione potenziale di tali misurazioni,
the project stages at which the measure- le fasi della progettazione nelle quali possono
ments can be estimated, and essere valutate le misurazioni, e

the project stages at which the measure- le fasi della progettazione nelle quali possono
ments can be made. essere fatte le misurazioni.
The practicability of each performance require- L’attuabilità di ogni requisito di prestazione è

ment is then analysed in order to obtain a list of quindi analizzata al fine di ricavare un elenco di
performance requirements, success criteria and requisiti di prestazione, criteri di successo e misu-
potential measurements. The main objectives are; razioni potenziali. Gli obbiettivi principali sono;
i) each performance requirement is associated i) ogni requisito di prestazione è associato con
with at least one measurement; almeno una misurazione;
ii) where possible, accurate and efficient meas- ii) ove possibile, sono scelte misurazioni accurate ed
urements are selected which can be used as efficienti che possano essere usate, nei limiti del
early in the development process as possible; possibile, agli inizi dello sviluppo del progetto;
iii) essential and optional performance require- iii) sono identificati requisiti di prestazione essen-
ments and success criteria are identified and ziali ed opzionali e criteri di successo, e
iv) where possible, advantage shall be taken of iv) ove possibile, devono essere perseguiti i vantag-
the possibility of using a single measurement gi della possibilità di usare una singola misura-
for more than one performance requirement. zione per più di un requisito di prestazione.
B.47 Probabilistic Testing (Referenced by Prove Probabilistiche (Riferimento

clause 11 and clause 13) all’art. 11 e 13)
Aim Scopo
To gain a quantitative figure about the reliability Ottenere un dato quantitativo circa le proprietà di
properties of the investigated software. This fig- affidabilità del software in osservazione. Questo
ure may address the related levels of confi- dato può indirizzarsi ai livelli correlati di fiducia e
dence and significance and significatività e
i) a failure probability per demand, i) una probabilità di mancato funzionamento per ri-
chiesta,
ii) a failure probability during a certain period ii) una probabilità di mancato funzionamento
of time, and durante un certo periodo di tempo, e
iii) a probability of error containment. iii) una probabilità di limitazione dell’errore.
From these figures other parameters may be de- Da questi dati possono essere derivati altri para-
rived such as metri quali
probability of failure free execution, probabilità di esecuzione priva di mancati
funzionamenti,
probability of survival, probabilità di sopravvivenza,
availability, disponibilità,
MTBF or failure rate, and MTBF o tasso di mancato funzionamento, e
probability of safe execution. probabilità di esecuzione sicura.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 106 di 128
Probabilistic considerations are either based on Le considerazioni probabilistiche sono basate o su
a probabilistic test or on operating experience. una prova probabilistica o su un’esperienza ope-
Usually the number of tests cases of observed rativa. Normalmente il numero dei casi di prova
operating cases is very large. di casi operativi osservati è molto elevato.
In order to facilitate testing, usually automatic Al fine di facilitare le prove, si adottano normal-
aids are taken. They concern the details of test mente ausili automatici. Essi riguardano i dettagli
data provision and test output supervision. dell’acquisizione dei dati di prova e della supervi-
Large tests are run on large host computers with sione del dato in uscita dalla prova. Prove estese
the appropriate process simulation periphery. sono eseguite su grossi computer con opportune
Test data is selected both according to systemat- periferiche di simulazione del processo. I dati di
ic and random view points. The first concern prova sono scelti sia secondo il punto di vista si-
the overall test control, for example, guarantee stematico che casuale. Il primo riguarda il control-
a test data profile. The random selection takes lo della prova in generale, per esempio, garantire
the individual test cases in detail. un profilo dei dati di prova. La scelta casuale con-
sidera nel dettaglio i casi di prova individuali.
Individual test harnesses, test executions and test L’impostazione delle prove individuali, l’esecuzio-
supervisions are determined by the detailed test ne delle prove e la loro supervisione sono deter-
aims as described above. Other important condi- minate dagli scopi delle prove di dettaglio come
tions are given through the mathematical prereq- sopra descritto. Altre importanti condizioni sono
uisites to be fulfilled in order to enable the test date tramite i prerequisiti matematici da soddisfa-
evaluation in view of the intended test aim. re al fine di consentire la valutazione della prova
in vista dello scopo della prova previsto.
Probabilistic figures about the behaviour of any Caratteristiche probabilistiche circa il comporta-
test object may also be derived from operating mento di ogni oggetto della prova può essere de-
experience. Provided the same conditions are rivato anche dall’esperienza operativa. Purché sia-
met, the same mathematics can be applied as no ottenute le medesime condizioni, gli stessi
for the evaluation of test results. algoritmi matematici possono essere applicati per
la valutazione dei risultati di prova.
B.48 Process Simulation (Referenced by D.3) Simulazione di Processo (Riferimento a D.3)
Aim Scopo
To test the function of a software system, to- Provare le funzioni di un sistema software, con le
gether with its interface to the outside world, sue interfacce con il mondo esterno, senza per-
without allowing it to modify the real world in mettergli in alcun modo di modificare il mondo
any way. reale.
The creation of a system, for testing purposes La creazione di un sistema, per soli intendimenti
only, which mimics the behaviour of the system di prova, che imita il comportamento del sistema
to be controlled by the system under test. da controllare mediante il sistema in prova.
The simulation may be software only or a com- La simulazione può essere solo software o una
bination of software and hardware. It must combinazione di software e hardware. Essa deve
provide all the inputs of the system under fornire tutti gli ingressi di dati del sistema in
test which will exist when the system is in- prova che esisteranno quando il sistema è in-
stalled, stallato
respond to outputs from the system in a rispondere alle uscite dal sistema in modo
way which faithfully represents the control- che rappresentino fedelmente l’impianto con-
led plant, trollato,
have provision for operator inputs to pro- avere cura che gli ingressi di dati da parte
vide any perturbations with which the sys- dell’operatore non producano perturbazioni
tem under test is required to cope. al quale il sistema in prova è richiesto che fac-
cia fronte
When software is being tested the simulation Quando il software viene provato la simulazione
may be a simulation of the target hardware with può essere una simulazione dell’hardware previ-
its inputs and outputs. sto con i suoi ingressi e le sue uscite.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 107 di 128
A Software Simulator - An Aid to Plant Commis- A Software Simulator - An Aid to Plant Commis-
sioning. S. Nunns, EWICS TC7. sioning. S. Nunns, EWICS TC7.
Physical Fault Simulation. F. Morillon, EWICS Physical Fault Simulation. F. Morillon, EWICS Do-
Document number WP460. cument number WP460.
B.49 Prototyping/Animation (Referenced by D.3 Prototipazione/Animazione (Riferimento a D.3 e

and D.5) D.5)
Aim Scopo
To check the feasibility of implementing the Verificare la fattibilità di implementare il sistema
system against the given constraints. To com- in base ai vincoli dati. Comunicare l’interpretazio-
municate the specifier’s interpretation of the ne di chi specifica il sistema al cliente, al fine di
system to the customer, in order to locate mis- individuare malintesi.
understandings.
A sub-set of system functions, constraints, and Vengono scelti un sottoinsieme di funzioni del siste-
performance requirements are selected. A pro- ma, vincoli e requisiti di prestazione. È costruito un
totype is built using high level tools. At this prototipo usando strumenti di elevato livello. In
stage, constraints such as the target computer, questa fase, vincoli come il computer stabilito, il lin-
implementation language, program size, main- guaggio di implementazione, la dimensione del pro-
tainability, reliability and availability need not gramma, la manutenibilità, l’affidabilità e la disponi-
be considered. The prototype is evaluated bilità non è necessario che vengano considerate. Il
against the customer’s criteria and the system prototipo è valutato in base ai criteri del cliente e i
requirements may be modified in the light of requisiti del sistema possono essere modificati alla
this evaluation. luce di questa valutazione.
Proc. Working Conference on Prototyping. Na- Proc. Working Conference on Prototyping. Namur
mur Oct 1983, Budde et al, Springer-verlag, 1984. Oct 1983, Budde et al, Springer-verlag, 1984.
Using an executable specification language for an Using an executable specification language for an
information system. S. Urban et. al, IEEE Trans information system. S. Urban et. al, IEEE Trans
Software Engineering, Vol. SE-11 No. 7 July 1985. Software Engineering, Vol. SE-11 No. 7 July 1985.
B.50 Recovery Block (Referenced by clause 9) Blocco di Recupero (Riferimento all’art. 9)
Aim Scopo
To increase the likelihood of the program per- Aumentare la probabilità che il programma ese-
forming its intended function. gua le sue funzioni previste.
Several different program sections are written, Vengono scritte molte sezioni di programma diffe-
often independently, each of which is intended renti, spesso in modo indipendente, ciascuna di
to perform the same desired function. The final queste è inteso realizzi la medesima funzione de-
program is constructed from these sections. The siderata. Il programma finale è costruito in base a
first section, called the primary, is executed first. queste sezioni. La prima sezione, chiamata prima-
This is followed by an acceptance test of the re- ria, è eseguita per prima. Questa è seguita da una
sult it calculates. If the test is passed then the prova di accettazione dei risultati che esse calco-
result is accepted and passed on to subsequent la. Se la prova è superata il risultato è accettato e
parts of the system. If it fails, any side effects of si passa alla parte successiva del sistema. Se la
the first are reset and the second section, called prova va male, alcuni effetti collaterali della prima
the first alternative, is executed. This too is fol- sono ripristinati e la seconda sezione, chiamata la
lowed by an acceptance test and is treated as in prima alternativa, è eseguita. Anche questa è se-
the first case. A second, third or even more al- guita da una prova di accettazione ed è trattata
ternatives can be provided if desired. come nel primo caso. Se desiderato possono es-
sere previste una seconda, una terza o anche più
alternative.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 108 di 128
System Structure for Software Fault Tolerance. System Structure for Software Fault Tolerance. B.
B. Randall, IEEE Trans Software Engineering, Randall, IEEE Trans Software Engineering,
Vol SE-1, No 2, 1975. Vol SE-1, No 2, 1975.
B.51 Reliability Block Diagram (Referenced by Diagramma a Blocchi dell’Affidabilità

Aim Scopo
To model, in a diagrammatic form, the set of Modellare, in forma di diagramma, l’insieme di
events that must take place and conditions eventi che deve aver luogo e di condizioni che
which must be fulfilled for a successful opera- devono essere soddisfatte per il riuscito funziona-
tion of a system or a task. mento di un sistema o un processo.
The target of the analysis is represented as a L’obbiettivo dell’analisi è rappresentata come un
success path consisting of blocks, lines and log- percorso che abbia successo consistente in bloc-
ical junctions. A success path starts from one chi, linee e giunzioni logiche. Un percorso riusci-
side of the diagram and continues via the to parte da un lato del diagramma e continua lun-
blocks and junctions to the other side of the di- go i blocchi e le giunzioni fino all’altro lato del
agram. A block represents a condition or an diagramma. Un blocco rappresenta una condizio-
event, and the path can pass it if the condition ne od un evento, ed il percorso è accettato se la
is true or the event has taken place. If the path condizione è vera o se l’evento ha avuto luogo.
comes to a junction it continues if the logic of Se il percorso arriva alla giunzione, esso continua
the junction is fulfilled. If it reaches a vertex, it se la logica della giunzione è soddisfatta. Se esso
may continue along all outgoing lines. If there raggiunge un vertice, esso può continuare lungo
exists at least one success path through the dia- tutte le linee uscenti. Se esiste almeno un percor-
gram the target of the analysis is operating corso nel diagramma che abbia successo quanto sta-
rectly. bilito dall’analisi è correttamente funzionante
System Reliability Engineering Methodology: A System Reliability Engineering Methodology: A
Division of the State of the Art. J.B. Fusseland Division of the State of the Art. J.B. Fusseland
J.S. Arend, Nuclear Safety 20(5), 1979. J.S. Arend, Nuclear Safety 20(5), 1979.
Fault Tree Handbook. W.E. Vesely et al, Fault Tree Handbook. W.E. Vesely et al, NU-
NUREG-0942, Division of System Safety Office at REG-0942, Division of System Safety Office at Nu-
Nuclear Reactor Regulation, U.S. Nuclear Regula- clear Reactor Regulation, U.S. Nuclear Regulatory
tory Commission, Washington, D.C. 20555, 1981. Commission, Washington, D.C. 20555, 1981.
B.52 Response Timing and Memory Constraints Tempo di Risposta e Vincoli di Memoria
Aim Scopo
To ensure that the system will meets its tempo- Assicurare che il sistema soddisfi i suoi requisiti di
ral and memory requirements. tempo e memoria.
The requirements specification for the system La specifica dei requisiti del sistema e del softwa-
and the software includes memory and re- re comprende i requisiti di memoria e di risposta
sponse requirements for specific functions, per- per le funzioni specifiche, eventualmente combi-
haps combined with constraints on the use of nate con i limiti nell’uso delle risorse totali del si-
total system resources. An analysis is performed stema. È eseguita un’analisi che identificherà le ri-
which will identify the distribution demands un- chieste di distribuzione nelle condizioni medie e
der average and worst case conditions. This nel caso peggiore. Questa analisi richiede stime
analysis requires estimates of the resource us- dell’uso delle risorse e del tempo trascorso per
age and elapsed time of each system function. ciascuna funzione del sistema. Queste stime pos-
These estimates can be obtained in several sono essere ottenute in molti modi, per esempio,
ways, for example, comparison with an existing per comparazione con un sistema esistente o per
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 109 di 128
system or the prototyping and bench-marking prototipazione e per prestazione comparativa di
of time critical systems. sistemi con criticità di tempo.
B.53 Re-Try Fault Recovery Mechanisms Meccanismi di Ripetizione per il Recupero del
(Referenced by clause 9) Guasto (Riferimento all’art. 9)
Aim Scopo
To attempt functional recovery from a detected Tentare il recupero della funzionalità da una con-
fault condition by re-try mechanisms. dizione di rilevamento di malfunzionamento con
meccanismi di ripetizione.
In the event of a detected fault or error condi- Nell’evenienza di un rilevamento di guasto o condi-
tion, attempts are made to recover the situation zione di errore, vengono fatti tentativi per recuperare
by re-executing the same code. Recovery by la situazione rassegnando il medesimo codice. Il ri-
re-try can be as complete as a re-boot and a cupero per ripetizione può essere completo quanto
re-start procedure or a small re-scheduling and le procedure di “re-boot” e quelle di riavviamento
re-starting task, after a software time-out or a oppure con un processo ridotto di riprogrammazio-
task watchdog action. Re-try techniques are ne e riavviamento, dopo un’azione di sospensione
commonly used in communication fault or error del software o un’azione di un processo watchdog.
recovery and re-try conditions could be flagged Le tecniche di ripetizione sono comunemente usate
from a communication protocol error (check nei guasti di comunicazione o recupero di errori e le
sum etc.) or from a communication acknowl- condizioni di ripetizione potrebbero essere segnalate
edgement response time-out. da un errore di protocollo di comunicazione (check
sum, ecc.) o da una interruzione di una risposta di ri-
conoscimento della comunicazione.
The Theory and Practise of Reliable System De- The Theory and Practise of Reliable System Desi-
sign. D.P. Siewiorek and R.S. Schwarz, Digital gn. D.P. Siewiorek and R.S. Schwarz, Digital
Press. Press.
B.54 Safety Bag (Referenced by clause 9) Tecnica della Valigetta di Sicurezza (Safety
Bag) (Riferimento all’art. 9)
Aim Scopo
To protect against residual specification and im- Proteggere da guasti residui di specificazione ed
plementation faults in software which adversely implementazione nel software che influenzano
affect safety. negativamente la sicurezza.
A safety bag is an external monitor, implement- La Safety Bag è un monitor esterno, implementato
ed on an independent computer to a different in un computer indipendente con una specifica
specification. This safety bag is solely con- diversa. Questa Safety Bag è dedicata solamente
cerned with ensuring the main computer per- ad assicurare che il computer principale si com-
forms safe, not necessarily correct, actions. The porti in modo sicuro, non necessariamente con
safety bag continuously monitors the main com- azioni corrette. La Safety Bag sorveglia continua-
puter. The safety bag prevents the system from mente il computer principale. La Safety Bag impe-
entering an unsafe state. In addition if it detects disce al sistema di entrare in uno stato insicuro.
that the main computer is entering a potentially Inoltre se rileva che il computer principale sta en-
hazardous state, the system has to be brought trando in uno stato potenzialmente pericoloso, il
back to a safe state either by the safety bag or sistema deve essere riportato ad uno stato sicuro
the main computer. o dalla Safety Bag o dal computer principale.
Using AI Techniques to Improve Software Safe- Using AI Tecniche to Improve Software Safety.
ty. Proc. IFAC SAFECOMP 88, Sarlat, France, Proc. IFAC SAFECOMP 88, Sarlat, France,
Oct 1986, Pergamon Press 1986. Oct 1986, Pergamon Press 1986.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 110 di 128
B.55 Sneak Circuit Analysis (Referenced by D.8) Analisi del Circuito Ingannevole (Riferimento a D.8)
Aim Scopo
To detect an unexpected path or logic flow Rilevare un percorso inatteso o un flusso logico
within a system which, under certain conditions dentro un sistema che, in certe condizioni inizia
initiates an undesired function or inhibits a de- una funzione indesiderata o inibisce una funzione
sired function. desiderata.
A sneak circuit path may consist of hardware, Il percorso di un circuito ingannevole può consiste-
software, operator actions, or combinations of re in elementi hardware, software, azioni dell’opera-
these elements. Sneak circuits are not the result tore, o in una combinazione di questi elementi. I cir-
of hardware failure but are latent conditions in- cuiti ingannevoli non sono il risultato di mancato
advertently designed into the system or coded funzionamento dell’hardware, ma sono condizioni
into the software programs, which can cause it latenti progettate inavvertitamente nel sistema o co-
to malfunction under certain conditions. dificate nei programmi software, che possono cau-
sare malfunzionamento in certe condizioni.
Categories of sneak circuits are: Categorie di circuiti ingannevolio sono:
Sneak Paths which cause current, energy, or Percorsi ingannevoli che causano il flusso di cor-
logical sequence to flow along an unex- rente, energia o sequenza logica lungo un per-
pected path or in an unintended direction; corso inatteso o in una direzione non prevista;
Sneak Timing in which events occur in an Tempistica ingannevole nella quale si verifica-
unexpected or conflicting sequence; no eventi in una sequenza inattesa o conflit-
tuale;
Sneak Indications which cause an ambigu- Indicazioni ingannevoli che causano una rap-
ous or false display of system operating presentazione ambigua o falsa delle condizioni
conditions, and thus may result in an unde- operative del sistema, e pertanto ne può deri-
sired action by the operator; vare una azione indesiderata dell’operatore;
Sneak Labels which incorrectly or impre- Identificazione ingannevole che identifica in
cisely label system functions, for example, modo scorretto o impreciso funzioni del siste-
system inputs, controls, displays, buses, ma, per esempio, ingressi nel sistema, con-
etc., and thus may mislead an operator into trolli, visualizzazioni, bus, ecc., che pertanto
applying an incorrect stimulus to the sys- possono fuorviare un operatore nell’applicare
tem. uno stimolo non corretto al sistema.
Sneak circuit analysis, relies on the recognition L’analisi dei circuiti ingannevoli, conta sul ricono-
of basic topological patterns with the hardware scimento di modelli topologici di base della strut-
or software structure (e.g. six basic patterns are tura hardware o software (ad esempio per il sof-
identified for software). Analysis takes place tware sono identificati sei modelli di base).
with the aid of a checklist of questions about L’analisi ha luogo con l’aiuto di una lista di con-
the use and relationships between the basic trollo di domande circa l’uso e le relazioni tra i
topological components. componenti topologici di base.
Sneak Analysis and Software Sneak Analysis. Sneak Analysis and Software Sneak Analysis. S.G.
S.G. Godoy and G.J. Engels, J. Aircraft Vol. 15, Godoy and G.J. Engels, J. Aircraft Vol. 15, No. 8,
No. 8, 1978. 1978.
Sneak Circuit Analysis. J.P. Rankin, Nuclear Sneak Circuit Analysis. J.P. Rankin, Nuclear Safety,
Safety, Vol. 14, No. 5, 1973. Vol. 14, No. 5, 1973.
B.56 Software Configuration Management Gestione della Configurazione del Software

(Referenced by clause 15) (Riferimento all’art. 15)
Aim Scopo
Software Configuration management aims to La Gestione della Configurazione Software ha lo
ensure the consistency of groups of develop- scopo di assicurare la coerenza di gruppi di ele-
ment deliverables as those deliverables change. menti dichiarati quando questi cambiano. La ge-
Configuration Management, in general, applies stione della Configurazione, in generale si applica
to both hardware and software development. allo sviluppo sia dell’hardware che del software.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 111 di 128
Software Configuration Management is a tech- La Gestione della Configurazione Software è una
nique used throughout development. In es- tecnica usata in ogni momento dello sviluppo. In
sence, it requires the recording of the produc- sostanza, essa richiede la registrazione della produ-
tion of every version of every “significant” zione di ogni versione di ogni elemento dichiarato
deliverable and of every relationship between “significativo” e di ogni relazione tra diverse versioni
different versions of the different deliverables. di elementi dichiarati differenti. I record risultanti
The resulting records allow the developer to consentono allo sviluppatore di determinare l’effetto
determine the effect on other deliverables of a su altri elementi dichiarati di un cambiamento ad un
change to one deliverable (especially on of its elemento dichiarato (specialmente sui suoi compo-
components). In particular, systems or subsys- nenti). In particolare, sistemi o sottosistemi possono
tems can be reliably re-built from consistent sets essere ricostruiti in modo affidabile da insiemi coe-
of component versions. renti di versioni di componenti.
Configuration Management Practices for Sys- Configuration Management Practices for Systems,
tems, Equipment, Munitions and Computer Pro- Equipment, Munitions and Computer Programs.
grams. MIL-STD-483. MIL-STD-483.
Software Configuration Management. J K Buck- Software Configuration Management. J K Buckle,

le, Macmillan Press, 1982. Macmillan Press, 1982.
Software Configuration Management. W A Software Configuration Management. W A Babi-
Babich, Addison-Wesley, 1986. ch, Addison-Wesley, 1986.
Configuration Management Requirements for Configuration Management Requirements for De-
Defence Equipment. UK Ministry of Defence fence Equipment. UK Ministry of Defence Stan-
Standard 05-57 Issue 1, 1980. dard 05-57 Issue 1, 1980.
B.57 Strongly Typed Programming Languages Linguaggi di Programmazione Fortemente

(Referenced by clause 10) Tipizzati (Riferimento all’art. 10)
Aim Scopo
Reduce the probability of faults by using a lan- Ridurre la probabilità di guasti usando un lin-
guage which permits a high level of checking guaggio che permette un elevato livello di verifica
by the compiler. da parte del compilatore.
Such languages usually allow user-defined data Tali linguaggi consentono normalmente tipi di dati
types to be defined from the basic language definiti dall’utente che devono essere definiti dai tipi
data types (such as INTEGER, REAL). These di dati del linguaggio di base (quali INTEGER, RE-
types can then be used in exactly the same way AL). Questi tipi possono quindi essere usati esatta-
as the basic types, but strict checks are imposed mente nello stesso modo dei tipi di base, ma sono
to ensure the correct type is used. These checks imposte verifiche strette per assicurare che sia usato
are imposed over the whole program, even if il tipo corretto. Queste verifiche sono imposte su
this is built from separately compiled units. The tutto il programma, anche se è costruito partendo da
checks also ensure that the number and the unità compilate separatamente. Le verifiche assicu-
type of procedure arguments match even when rano anche che il numero e il tipo di argomenti del-
referenced from separately compiled modules. la procedura si accordino anche quando riferiti a
moduli compilati separatamente.
Strongly typed languages also support other as- I linguaggi fortemente tipizzati sono di supporto an-
pects of good software engineering practice che ad altri aspetti di buona pratica dell’ingegneria
such as easily analysable control structures (e.g. del software quali strutture di controllo facilmente
IF .. THEN .. ELSE, DO .. WHILE, etc) which analizzabili (ad esempio IF .. THEN .. ELSE, DO ..
lead to well-structured programs. WHILE, ecc.) che conducono a programmi ben
strutturati.
Typical examples of strongly typed languages Tipici esempi di linguaggi tipizzati fortemente
are Pascal, Ada and Modula 2. sono Pascal, Ada e Modula 2.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 112 di 128
Reference Manual for the Ada Programming Reference Manual for the Ada Programming Lan-
Language, ANSI/MIL-STD-815A 1983. guage, ANSI/MIL-STD-815A 1983.
In search of Effective Diversity: a Six Language n search of Effective Diversity: a Six Language
Study of Fault-Tolerant Flight Control Software, Study of Fault-Tolerant Flight Control Software,
A Avizienis, M R Lyu, W Schutz, The Eighteenth A Avizienis, M R Lyu, W Schutz, The Eighteenth
International Symposium on Fault Tolerant International Symposium on Fault Tolerant Com-
Computing, Tokyo, Japan 27-30 June 1988, IEEE puting, Tokyo, Japan 27-30 June 1988, IEEE Com-
Computer Society Press,ISBN 0-8186-0867-6. puter Society Press,ISBN 0-8186-0867-6
B.58 Structure Based Testing (Referenced by D.2) Prove Basate sulla Struttura (Riferimento a D.2)
Aim Scopo
To apply tests which exercise certain subsets of Applicare prove che esercitano alcuni sottoinsie-
the program structure. mi della struttura del programma.
Based on an analysis of the program a set of in- È scelta una serie di dati d’ingresso sulla base
put data is chosen such that a large fraction of dell’analisi del programma in modo che sia sollecita-
selected program elements are exercised. The ta un’ampia frazione di elementi del programma
program elements exercised can vary depend- scelto. Gli elementi del programma esercitato posso-
ing upon the level of rigour required. no variare secondo il livello di rigore richiesto.
Statements: this is the least rigorous test Dichiarazioni: questa è la prova rigorosa mini-
since it is possible to execute all code state- ma poiché è possibile eseguire tutti i comandi
ments without exercising both branches of del codice senza l’attivazione di entrambe le
a conditional statement. ramificazioni di un comando condizionato.
Branches: both sides of every branch Ramificazioni: entrambi i lati di ogni ramifica-
should be checked. This may be impractical zione dovrebbero essere provati. Questo po-
for some types of defensive code. trebbe essere non praticabile per alcuni tipi di
codice difensivo.
Compound Conditions: every condition in a Condizioni Composte: ogni condizione in una
compound conditional branch (i.e. linked ramificazione condizionata composta (ad
by AND/OR is exercised). esempio collegata da AND/OR è esercitata).
LCSAJ: a linear code sequence and jump is LCSAJ: una sequenza di codice lineare e salto
any linear sequence of code statements in- è ogni sequenza lineare di comandi del codi-
cluding conditional jumps terminated by a ce compresi salti condizionali terminati da un
jump. Many potential sub-paths will be in- salto. Molti sottopercorsi potenziali non saran-
feasible due to constraints on the input data no realizzabili per i vincoli sui dati d’ingresso
imposed by the execution of earlier code. imposti dall’esecuzione del codice preceden-
temente.
Data Flow: the execution paths are selected Flusso dei Dati: i percorsi di esecuzione sono
on the basis of data usage for example a scelti in base all’uso dei dati, per esempio un
path where the same variable is both writ- percorso ove la stessa variabile richiami sia
ten and wrote. written che wrote.
Call Graph: a program is composed of sub- Call Graph: un programma è composto da su-
routines which may be invoked from oth- broutine che possono essere chiamate da al-
er subroutines. The call graph is the tree tre subroutine. Il call graph è l’albero delle
of subroutine invocations in the program. chiamate delle subroutine nel programma. Le
Tests are designed to cover all invocations prove sono progettate per trattare tutte le
in the tree. chiamate nell’albero.
Entire Path: execute all possible path Percorso Totale: eseguire tutti i possibili per-
through the code. Complete testing is nor- corsi attraverso il codice. Prove complete non
mally infeasible due to the vary large sono normalmente attuabili per il numero
number of potential paths. molto grande di percorsi potenziali.
Reliability of the Path Analysis Testing Strategy. Reliability of the Path Analysis Testing Strategy.
W. Howden, IEEE Trans Software Engineering, W. Howden, IEEE Trans Software Engineering,
Vol SE 3, 1976. Vol SE 3, 1976.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 113 di 128
B.59 Structure Diagrams (Referenced by D.5) Diagrammi Strutturati (Riferimento a D.5)
Aim Scopo
To show the structure of a program diagram- Mostrare la struttura di un programma mediante
matically. diagramma.
Structure Diagrams are a notation which com- I Diagrammi Strutturati sono un’annotazione che in-
plements Data Flow Diagrams. They describe tegra i Diagrammi di Flusso dei Dati. Essi descrivono
the programming system and a hierarchy of il sistema di programmazione ed una gerarchia delle
parts and display this graphically, as a tree. parti e le rappresentano graficamente come un albe-
They document how elements of a data flow di- ro. Essi documentano come elementi di un diagram-
agram can be implemented as a hierarchy of ma del flusso dei dati possono essere implementati
program units. come una gerarchia delle unità di programma.
A structure chart shows relationships between Una carta strutturata mostra le relazioni tra le uni-
program units without including any information tà di programma senza inserire alcuna informazio-
about the order of activation of these units. They ne sull’ordine di attivazione di queste unità. Esse
are drawn using the following three symbols: sono disegnate usando i tre simboli seguenti:
i) a rectangle annotated with the name of the i) un rettangolo annotato con il nome dell’unità;
unit;
ii) an arrow connecting these rectangles; ii) una freccia che congiunge questi rettangoli;
iii) a circled arrow, annotated with the name of iii) una freccia circolare, annotata con il nome
data passed to and from elements in the del dato passato agli e dagli elementi nella
structure chart. Normally, the circled arrow carta strutturata. Normalmente la freccia circo-
is drawn parallel to the arrow connecting lare è disegnata parallela alla freccia che con-
the rectangles in the chart. giunge i rettangoli nella carta.
From any non trivial data flow diagram, it is Da ogni diagramma di flusso dei dati non privo di
possible to derive a number of different struc- significato, è possibile derivare molte carte di
ture charts. struttura diverse tra loro.
Structure charts derived from data flow dia- Carte di struttura derivate da diagrammi di flusso
grams represent a first level structure of the sys- di dati rappresentano una struttura di primo livel-
tem, where each box on the structure chart rep- lo del sistema, ove ogni rettangolo sulla carta del-
resents a bubble in the data flow diagram. la struttura rappresenta un pallogramma nel dia-
Naturally, deeper levels can be described using gramma del flusso dei dati. Naturalmente, livelli
the same technique. più profondi possono essere descritti usando la
medesima tecnica.
Software Engineering. I. Sommerville, Addi- Software Engineering. I. Sommerville, Addi-
son-Wesley 1982. ISBN 0-201-13795-X. son-Wesley 1982. ISBN 0-201-13795-X.
Structured Design. L.L Constantine and E, Yourdon, Structured Design. L.L Constantine and E, Yourdon,
Englewood Cliffs, New Jersey, Prentice Hall, 1979. Englewood Cliffs, New Jersey, Prentice Hall, 1979.
Reliable Software Through Composite Design. Reliable Software Through Composite Design. G.J
G.J Myers, New York, Van Nostrand, 1975. Myers, New York, Van Nostrand, 1975.
B.60 Structured Methodology (Referenced by Metodologia Strutturata (Riferimento all’art. 8 e

clause 8 and clause 10) 10)
Aim Scopo
The main aim of Structured Methodologies is to Lo scopo principale della Metodologia Strutturata
promote the quality of software development è quello di promuovere la qualità dello sviluppo
by focusing attention on the early parts of the del software focalizzando l’attenzione sulle prime
life-cycle. The methods aim to achieve this fasi del ciclo di vita. I metodi mirano a raggiunge-
through both precise and intuitive procedures re questo attraverso procedure precise, intuitive
and notations (assisted by computers) to identi- ed annotazioni (assistite dai computer) per identi-
fy the existence of requirements and implemen- ficare l’esistenza di requisiti e caratteristiche di im-
tation features in a logical order and a struc- plementazione in un ordine logico ed in modo
tured manner. strutturato.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 114 di 128
A range of Structured Methodologies exist. Esiste una gamma di Metodologie Strutturate. Al-
Some such as SSADM, LBMS are designed for cune, come: SSADM, LBMS sono progettate per
traditional data-processing and transaction l’elaborazione dei dati tradizionale e funzioni di
processing functions, while others (MASCOT, elaborazione delle transazioni, mentre altri (MA-
JSD, real-time Yourdon) are more oriented to SCOT, JSD, Yourdon in tempo reale) sono più
process-control and real-time applications orientati al controllo di processo e alle applicazio-
(which tend to be more safety-critical). ni in tempo reale (che tendono ad essere più criti-
che per la sicurezza).
Structured Methods are essentially “thought I Metodi Strutturati sono essenziali “strumenti di
tools” for systematically perceiving and parti- raffigurazione” per percepire sistematicamente e
tioning a problem or system. Their main fea- realizzare una partizione di un problema o di un
tures are: sistema. Le loro caratteristiche principali sono:
a logical order of thought, breaking a large un ordine logico di raffigurazione, suddivi-
problem into manageable stages; dendo un grosso problema in fasi manegge-
voli;
identification of total system, including the identificazione del sistema totale, comprenden-
environment as well as the required system; do l’ambiente oltre che il sistema richiesto;
decomposition of data and function in the decomposizione di dati e funzioni nel sistema
required system; richiesto;
checklists, i.e. lists of the sort of things that liste di controllo, cioè elenchi di un tipo di
need definition; elementi che richiedono una definizione;
low intellectual overhead - simple, intuitive, basso sforzo/intellettuale - semplice, intuitivo,
pragmatic. pragmatico,.
The supporting notations tend to be precise for Le annotazioni di supporto tendono ad essere
identifying problem and system entities (e.g. precise per identificare entità di problemi e siste-
processes and data flows), but the processing mi (ad esempio flussi di processo e dati), ma le
functions performed by these entities tend to be funzioni di elaborazione eseguite da queste entità
expressed using informal notations. However tendono ad essere espresse usando annotazioni
some methods do make partial use of(mathe- informali. Tuttavia alcuni metodi fanno uso par-
matically) formal notations (for example JSD ziale (matematicamente) di annotazioni formali
makes use of regular expressions: Yourdon, (per esempio il JSD fa uso di espressioni regolari:
SOM and SDL utilise finite state machines). This Yourdon, SOM e SDL utilizzano macchine a stati
precision not only reduces the scope for misun- finiti). Questa precisione, non solo riduce le in-
derstanding, it provides scope for automatic comprensioni, ma fornisce un’elaborazione auto-
processing. matica.
Another benefit of structured notation is their Un altro beneficio dell’annotazione strutturata è la
visibility, enabling a specification or design to sua visibilità, rendendo possibile la verifica intuiti-
be checked intuitively by a user, against his va della specifica o della progettazione da parte
powerful but unstated knowledge. di un’utente, di fronte ad una conoscenza notevo-
le ma non definita.
This bibliography describes some of these Questa bibliografia descrive alcune di queste Me-
Structured Methodologies in more detail, for in- todologie Strutturate con maggior dettaglio, per
stance, Controlled Requirements Expression, esempio, Espressione dei requisiti Controllati, Svi-
Jackson System Development, MASCOT, re- luppo del Sistema Jackson, MASCOT, tempo reale
al-time Yourdon and Structured Analysis and e Analisi Strutturata e Tecnica di Progettazione
Design Technique (SADT). (SADT).
Structured Development for real-time Systems Structured Development for real-time Systems
(3 Volumes) P T Yourdon Press, 1985. (3 Volumes) P T Yourdon Press, 1985.
Essential Systems Analysis. St M McMenamin, F Essential Systems Analysis. St M McMenamin, F
Palmer, Yourdon Inc, 1984. N Y. Palmer, Yourdon Inc, 1984. N Y.
The Use of Structured Methods in the Develop- The Use of Structured Methods in the Develop-
ment of Large Software-Based Avionic Systems. ment of Large Software-Based Avionic Systems.
D J Hatley, Proceedings DASC, Baltimore, 1984. D J Hatley, Proceedings DASC, Baltimore, 1984.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 115 di 128
B.60.1 Controlled Requirements Expression (CORE) Espressione dei Requisiti Controllati (CORE)
Aim Scopo
To ensure that all the requirements are identi- Assicurare che tutti i requisiti siano identificati ed
fied and expressed. espressi.
This approach is intended to bridge the gap be- Questo approccio intende superare il gap tra
tween the customer/end user and the analyst. It cliente/utente finale e l’analista. Non è matemati-
is not mathematically rigorous but aids the com- camente rigoroso ma aiuta il processo di comuni-
munication process - CORE is designed for re- cazione - CORE è progettato per l’espressione dei
quirements expression rather than specification. requisiti piuttosto che per la specificazione. L’ap-
The approach is structured and the expression proccio è strutturato e l’espressione procede attra-
goes through various levels of refinement. The verso vari livelli di raffinamento. Il processo
CORE process encourages a wider view of the CORE incoraggia una visione più ampia del pro-
problem, bringing in a knowledge of the envi- blema, conducendo ad una conoscenza dell’am-
ronment in which the system will be used and biente nel quale il sistema sarà usato e dei diversi
the differing viewpoints of the various types of punti di vista dei vari tipi di utenti. CORE prevede
user. CORE includes guidelines and tactics for linee guida e tattiche per riconoscere scostamenti
recognising departures from the “grand design”. dai “grandi progetti”. Gli scostamenti possono es-
Departures can be corrected or explicitly identi- sere corretti od esplicitamente identificati e docu-
fied and documented. Thus specifications may mentati. Perciò le specifiche possono non essere
not be complete, but unresolved problems and complete, ma sono identificati i problemi irrisolti
high-risk areas are identified and have to be ad- e le aree ad elevato rischio e devono essere tratta-
dressed in the subsequent design. te nella susseguente progettazione.
B.60.2 JSD - Jackson System Development JSD –Sviluppo del Sistema Jakson
Aim Scopo
A development method covering the develop- Un metodo di sviluppo che copre lo sviluppo di
ment of software systems from requirements sistemi software dai requisiti fino alla codifica,
through to code, with special emphasis on re- con enfasi particolare per i sistemi in tempo reale.
al-time systems.
JSD is a staged development process in which JSD è un processo di sviluppo per fasi dove lo
the developer models the real world processes sviluppatore modella i processi del mondo reale
upon which the system functions are to be sui quali le funzioni del sistema devono essere
based, determines the required functions and basate, determina le funzioni richieste e le inseri-
inserts them into the model, and transforms the sce nel modello, e trasforma la specifica risultan-
resulting specification into one that is realisable te in una che è realizzabile nell’ambiente previ-
in the target environment. It therefore covers sto. Pertanto esso copre le tradizionali fasi di
the traditional phases of definition, design and definizione, progettazione ed implementazione,
implementation but takes a somewhat different ma assume in qualche modo una visione diffe-
view from the traditional methods in not being rente rispetto ai metodi tradizionali non essendo
top-down. top-down.
Moreover it places great emphasis on the early Inoltre esso pone molta enfasi sulla fase iniziale di
stage of identifying the entities in the real world identificazione delle entità nel mondo reale che
that are the concern of the system being built sono implicate nel sistema che deve essere costrui-
and on modelling them and what can happen to e che lo modellano e su quanto può verificarsi.
to them. Once this analysis of the “real-world” Allorché questa analisi del “mondo reale” è stata
has been done and a model created, the sys- eseguita e creato un modello, le funzioni richieste
tem’s required functions are analysed to deter- dal sistema sono analizzate per determinare come
mine how they can fit into this real-world mod- esse possono adattarsi in questo modello del mon-
el. The resulting system model is augmented do reale. Il modello di sistema risultante è comple-
with structured descriptions of all the processes tato con descrizioni strutturate di tutti i processi del
in the model and the whole is then transformed modello, ed il complesso viene trasformato in pro-
into programs that will operate in the target grammi che funzioneranno nell’ambiente software
software and hardware environment. ed hardware stabilito.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 116 di 128
An Overview of JSD. J R Cameron, IEEE Trans An Overview of JSD. J R Cameron, IEEE Trans
SE-12 no 2 Feb 1986. SE-12 no 2 Feb 1986.
System Development. M Jackson, Prentice-Hall, System Development. M Jackson, Prentice-Hall,
1983. 1983.
B.60.3 MASCOT MASCOT
Aim Scopo
The design and implementation of real-time La progettazione e l’implementazione di sistemi in
systems. tempo reale.
MASCOT (Modular Approach to Software Con- MASCOT (Approccio Modulare per Costruzione
struction, Operation and Test) is a design meth- Funzionamento e Prova del Software) e un meto-
od supported by a programming system. It is a do di progettazione supportato da un sistema di
systematic method of expressing the structure programmazione. Esso è un metodo sistematico
of real-time system in a way that is independent di esprimere la struttura di un sistema in tempo
of the target hardware or implementation lan- reale in modo indipendente dall’hardware previ-
guage. It imposes a disciplined approach to de- sto e dal linguaggio di implementazione. Esso im-
sign that yields a highly modular structure, en- pone un approccio disciplinato alla progettazione
suring a close correspondence between the che produce una struttura altamente modulare,
functional elements in the design and the con- che assicura una stretta corrispondenza tra gli ele-
struction elements appearing in system integra- menti funzionali nella progettazione gli elementi
tion. A system is designed in terms of a network costruttivi che appaiono nell’integrazione del si-
of concurrent processes that communicate stema. Un sistema è progettato in termini di una
through channels. Channels can be either pools rete di processi concorrenti che comunicano tra-
of fixed data or queues (pipelines of data). Con- mite canali. I canali possono essere sia insiemi di
trol of access to channels is defined independ- dati stabiliti che code (canali di dati). Il controllo
ently of the processes. It is defined in terms of di accesso ai canali è definito in modo indipen-
access mechanisms that also enforce scheduling dente dai processi. Esso è definito in termini di
rules on the processes. Recent versions of MAS- meccanismi di accesso che rafforzano anche la
COT have been designed with Ada implementa- programmazione di regole sui processi. Recenti
tion in mind. versioni di MASCOT sono state progettate avendo
in mente un’implementazione in Ada.
MASCOT supports an acceptance strategy based MASCOT supporta una strategia di accettazione
on the test and verification of single modules basata su prove e verifiche dei singoli moduli e di
and larger collections of functionally related una più ampia raccolta di moduli funzionalmente
modules. A MASCOT implementation is intend- correlati. Una implementazione di MASCOT si in-
ed to be built upon a MASCOT kernel - a set of tende sia costruita su un kernel di MASCOT -
scheduling primitives that underline the imple- un’insieme di primitive programmate che sottoli-
mentation and support the access mechanisms. neano l’implementazione e supportano i meccani-
smi di accesso.
MASCOT 3 User Guide. MASCOT Users Forum, MASCOT 3 User Guide. MASCOT Users Forum,
RSRE, Malvern, England, 1987. RSRE, Malvern, England, 1987.
B.60.4 Real-time Yourdon Yourdon nel Tempo Reale

Aim Scopo
This aims to be a complete software develop- Questo intende essere un metodo di sviluppo del
ment method consisting of specification and de- software completo che consiste in specificazione
sign techniques oriented towards the develop- e tecniche di progettazione orientate allo sviluppo
ment of real-time systems. di sistemi in tempo reale.
The development scheme underlying this tech- Lo schema di sviluppo sottolineando queste tecni-
nique assumes a three phase evolution of a sys- che assume una evoluzione in tre fasi di un siste-
tem being developed. The first phase involves ma da sviluppare. La prima fase coinvolge la co-
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 117 di 128
the building of an “essential model”, one that de- struzione di un “modello essenziale”, che descrive
scribes the behaviour required by the system. il comportamento richiesto al sistema. La seconda
The second involves the building of an imple- coinvolge la costruzione di un modello di imple-
mentation model which describes the structures mentazione che descrive le strutture ed i meccani-
and mechanisms that, when implemented, em- smi che, quando sviluppati, concretizzano il com-
body the required behaviour. The third phase in- portamento richiesto. La terza fase coinvolge la
volves the actual building of the system in hard- costruzione reale del sistema hardware e softwa-
ware and software. The three phases correspond re. Le tre fasi corrispondono grossomodo alle fasi
roughly to the traditional definition, design and tradizionali di definizione, progettazione ed im-
implementation phases but lay greater emphasis plementassimo, ma pongono maggiore enfasi sul
on the fact that at each stage the developer is en- fatto che per ogni fase lo sviluppatore è impegna-
gaged in a modelling activity. to in un’attività di modellazione.
The essential model is in two parts: the environ- Il modello essenziale è in due parti: il modello
mental model containing a definition of the ambientale contiene una definizione dei confini
boundary between the system and its environ- tra il sistema e il suo ambiente e una descrizione
ment and a description of the external events to degli eventi esterni ai quali il sistema deve rispon-
which the system must respond, and the behav- dere, e un modello comportamentale che contie-
ioural model which contains schemas defining ne gli schemi che definiscono la trasformazione
the transformation the system carries out in re- che il sistema esegue in risposta agli eventi e alla
sponse to events and a definition of the data the definizione dei dati che il sistema deve possedere
system must hold in order to respond. per rispondere.
The implementation model also divides into Il modello di implementazione si suddivide inol-
sub-models: in this case covering the allocation tre in due sottomodelli: in questo caso coprendo
of individual processes to processors and of the l’allocazione dei singoli processi sui processori e
decomposition of the processes into modules. la decomposizione dei processi in moduli.
To capture these models the technique com- Per ottenere questi modelli la tecnica mette insie-
bines a number of well-known techniques: da- me un numero di tecniche ben note: diagrammi
ta-flow diagrams, structured English, state tran- di flusso dei dati, inglese strutturato, diagrammi di
sition diagrams and Petri Nets. stato-transizione e Reti di Petri.
Additionally the method contains techniques for Inoltre il metodo contiene tecniche per simulare
simulating a proposed system design either on una progettazione del sistema proposto o sulla
paper or mechanically from the models that are carta o meccanicamente da modelli che sono re-
drawn up. datti.
Structured Development for Real-time Systems Structured Development for Real-time Systems
(3 Volumes) PT Ward and SJ Mellor. Yourdon (3 Volumes) PT Ward and SJ Mellor. Yourdon
Press, 1985. Press, 1985.
B.60.5 SADT- Structured Analysis and Design Technique SADT – Analisi Strutturata e Tecnica di Progettazione
Aim Scopo
To model and identify, in a diagrammatic form Modellare ed identificare, in forma di diagramma
using information flows, the decision making usando flussi di informazione, i processi di deci-
processes and the management tasks associated sione ed i compiti di gestione associati ad un si-
with a complex system. stema complesso.
In SADT, the concept of an Activity-Factor Dia- Nel SADT, il concetto di Diagramma Attività–Fat-
gram plays a central role. An A/F diagram con- tore gioca un ruolo centrale. Un diagramma A/F
sists of activities grouped in so called “action consiste in attività raggruppate in così dette “sca-
boxes”. Each action box has a unique name, tole di azione”. Ciascuna scatola di azione ha un
and is linked to other action boxes by factor re- unico nome, ed è collegata alle altre scatole di
lations (drawn as arrows) which are also given azione da fattori di relazione (disegnati come
unique names. Each action box can be hierar- frecce) ai quali vengono dati nomi unici. Ogni
chically decomposed into subsidiary action scatola di azione può essere gerarchicamente de-
composta in scatole di azione sussidiarie e rela-
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 118 di 128
boxes and relations. There are four types of fac- zioni. Vi sono quattro tipi di fattori: ingressi, con-
tors: inputs, controls mechanisms and outputs: trolli, meccanismi ed uscite:
Input: indicated by an arrow that enters an Ingressi: indicato da una freccia che entra in
action box at the left hand side. Inputs can una scatola di azione dal lato sinistro. Gli in-
represent material or immaterial things and gressi possono rappresentare cose materiali o
they are suitable for manipulation by one or immateriali e sono adatti per manipolare una
more activities in an action box; o più attività in una scatola di azione;
Control: are typically instructions, proce- Controllo: sono tipicamente istruzioni, proce-
dures, choice criteria and so on. Controls dure, criteri di scelta e così via. I controlli gui-
guide the execution of an activity and they dano l’esecuzione di un’attività e sono indicati
are shown by arrows entering the top side da frecce entranti dal lato superiore di una
of an action box; scatola di azione;
Mechanism: is a resource such as person- Meccanismo: è una risorsa quale il personale,
nel, organisational units or equipment, that un’unità dell’organizzazione o apparecchiatu-
is needed for an activity to perform its task; ra, che sono necessari per un’attività per ese-
guire il suo compito;
Output: can denote anything that an activity Uscita: può denotare qualsiasi cosa che è pro-
produces, and it is pictured by an arrow dotta da un’attività, ed è rappresentata da una
leaving an action box at the right hand side. freccia uscente da una scatola di azione dal
lato sinistro.
When activities are strongly related to each other Quando le attività sono fortemente correlate tra
by many factor relations then it perhaps better to loro da relazioni di molti fattori è meglio conside-
consider these activities as an indivisible group rare queste attività come un gruppo indivisibile che
that is contained in one action box which does è contenuto in una scatola di azione che non si
not lend itself to further detailing of its content. presta a dettagliare ulteriormente il proprio conte-
The guiding principle for grouping of activities nuto. Il principio guida per raggruppare le attività
into action boxes is that the resulting boxes are in scatole di azione è quello per cui le scatole risul-
coupled pairwise by only a few factors. tanti siano accoppiate solo da pochi fattori.
The model hierarchy of A/F diagrams is pur- La gerarchia del modello gerarchico dei diagram-
sued until a further detailing of the action boxes mi A/F è portata avanti finché un dettaglio ulterio-
is meaningless. This stage is reached when the re delle scatole di azione è privo di significato.
activities within the boxes are inseparable or Tale fase è raggiunta quando le attività dentro le
when further detailing of the action boxes falls scatole sono inseparabili o quando un ulteriore
outside the scope of the system analysis. dettaglio delle scatole di azione ricade all’esterno
del campo di applicazione dell’analisi del sistema.
Structured Analysis for Requirements Definition, Structured Analysis for Requirements Definition,
DT Ross, KE Schoman Jr, IEEE Trans.Software DT Ross, KE Schoman Jr, IEEE Trans.Software
Eng. Vol SE-3, 1977, 6-15. Eng. Vol SE-3, 1977, 6-15.
Structured Analysis (SA): A language for com- Structured Analysis (SA): A language for commu-
municating ideas, DT Ross, IEEE Trans.Software nicating ideas, DT Ross, IEEE Trans.Software
Eng., Vol SE-3,1, 16-34. Eng., Vol SE-3,1, 16-34.
Applications and Extensions of SADT, DT Ross, Applications and Extensions of SADT, DT Ross,
Computer, April 1985, 25-34. Computer, April 1985, 25-34.
Structured Analysis and Design Technique - Ap- Structured Analysis and Design Technique - Ap-
plication on Safety Systems, W Heins, Risk As- plication on Safety Systems, W Heins, Risk Assess-
sessment and Control Courseware, Module B1, ment and Control Courseware, Module B1, chap-
chapter 11. 1989, Delft University of Technolo- ter 11. 1989, Delft University of Technology,
gy, Safety Science Group, PO Box 5050, 2600 Safety Science Group, PO Box 5050, 2600 GB
GB Delft, Netherlands. Delft, Netherlands.
B.61 Structured Programming (Referenced by Programmazione Strutturata (Riferimento

clause 10) all’art.10)
Aim Scopo
To design and implement the program in a way Progettare ed implementare il programma in modo
which makes practical the analysis of the pro- da rendere pratica l’analisi del programma. Questa
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 119 di 128
gram. This analysis should be capable of dis- analisi potrebbe essere in grado di scoprire il com-
covering all significant program behaviour. portamento significativo di tutti i programmi.
The program should contain the minimum of Il programma dovrebbe contenere il minimo di
structural complexity. Complicated branching complessità strutturale. Ramificazioni complicate
should be avoided. Loop constraints and dovrebbero essere evitate. Vincoli di costrutti ite-
branching should (where possible) be simply rati e di diramazione dovrebbero (ove possibile)
related to input parameters. The program essere semplicemente correlati ai parametri d’in-
should be divided into appropriately small gresso. Il programma dovrebbe essere diviso in
modules, and the interaction of these modules moduli opportunamente ridotti, e le interazioni di
should be explicit. Features of the programming questi moduli dovrebbero essere esplicite. Le ca-
language which encourage the above approach ratteristiche del linguaggio di programmazione
should be used in preference to other features che favorisce l’approccio di cui sopra dovrebbero
which are (allegedly) more efficient, except essere usate in preferenza ad altre caratteristiche
where efficiency takes absolute priority (e.g. che sono (presumibilmente) più efficienti, salvo
some safety-critical systems). quando l’efficienza assume assoluta priorità (ad
esempio alcuni sistemi in sicurezza).
A Discipline of Programming. E W Dijkstra, En- A Discipline of Programming. E W Dijkstra, En-
glewood Cliffs N J, Prentice-Hall, 1976. glewood Cliffs N J, Prentice-Hall, 1976.
Assessing a Class of Software Tools. M A Hen- Assessing a Class of Software Tools. M A Hennell
nell et al, 7th International conference on Soft- et al, 7th International conference on Software
ware Engineering, March 1984, Orlando. Engineering, March 1984, Orlando.
A Software Tool for Top-down Programming. D A Software Tool for Top-down Programming. D C
C Ince, Software - Practice and Experience, Vol Ince, Software - Practice and Experience, Vol 13,
13, No 8, August 1983. No 8, August 1983.
B.62 Suitable Programming Languages Linguaggi di Programmazione Adatti

Aim Scopo
To support the requirements of this Internation- Appoggiare i requisiti di questa Norma Interna-
al Standard as much as possible, in particular, zionale nella maggiore misura possibile, in parti-
defensive programming, strong typing, struc- colare, la programmazione difensiva, i linguaggi
tured programming and possibly assertions. The fortemente tipizzati, la programmazione struttura-
programming language chosen should lead to ta, e le possibilità di asserzioni. Il linguaggio di
easily verifiable code with a minimum of effort programmazione scelto dovrebbe condurre ad un
and facilitate program development, verification codice facilmente verificabile con uno sforzo mi-
and maintenance. nimo e facilitare lo sviluppo di programmi, la ve-
rifica e la manutenzione.
The language should be fully and unambigu- Il linguaggio dovrebbe essere definito in modo
ously defined. The language should be user or completo e senza ambiguità. Il linguaggio do-
problem oriented rather than machine oriented. vrebbe essere orientato all’utente o al problema
Widely used languages or their subsets are pre- piuttosto che alla macchina. I linguaggi di ampio
ferred to special purpose languages. utilizzo o i loro sottoinsiemi sono preferiti ai lin-
guaggi con scopi particolari.
In addition to the already referenced features In aggiunta alle caratteristiche già riferite i lin-
the language should provide for guaggi dovrebbero prevedere
block structure, struttura a blocchi,
translation time checking, verifica del tempo di traduzione,
run time type and array bound checking, verifica del tipo del tempo di esecuzione e di
and accesso a locazioni di memoria riservate, e
parameter checking. verifica del parametro.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 120 di 128
The language should encourage Il linguaggio dovrebbe stimolare
the use of small and manageable modules, l’uso di moduli piccoli e maneggevoli,
restriction of access to data in defined mod- restrizione di accesso ai dati in moduli defini-
ules, ti,
definition of variable sub-ranges, and definizione di variabili sub-ranges, e
any other type of error limiting constructs. ogni altro tipo di errore che limita i costrutti.
It is desirable that the language is supported by È desiderabile che il linguaggio sia supportato da
a suitable translator, appropriate libraries of un adatto traduttore, opportune librerie di moduli
pre-existing modules, a debugger and tools for preesistenti, un debugger e strumenti sia per il
both version control and development. controllo delle versioni che per lo sviluppo.
Features which make verification difficult and Caratteristiche che rendono difficile la verifica e
therefore should be avoided are: che pertanto dovrebbero essere evitate sono:
unconditional jumps excluding subroutine saliti incondizionati che escludono chiamate
calls; di subroutine;
recursion; ripetizioni;
pointers, heaps or any type of dynamic var- puntatori, heaps od ogni tipo di variabile o
iables or objects; oggetto dinamico;
interrupt handling at source code level; gestione delle interruzioni a livello del codice
sorgente;
multiple entries or exits of loops, blocks or ingressi o uscite multiple di costrutti iterativi,
subprograms; blocchi o sottoprogrammi;
implicit variable initialisation or declaration; inizializzazione o dichiarazione di variabile
implicita;
variant records and equivalence; and registrazioni di variante ed equivalenze; e
procedural parameters. parametri procedurali.
Low level languages, in particular assembly lan- I linguaggi di basso livello, in particolare linguag-
guages, present problems due to their machine gi in assembler, presentano problemi dovuti alla
oriented nature. loro natura orientata alla macchina.
B.63 Symbolic Execution (Referenced by D.8) Esecuzione Simbolica (Riferimento a D.8)
Aim Scopo
To show the agreement between the source Mostrare la concordanza tra il codice sorgente e la
code and the specification. specifica.
The program is executed substituting the left Il programma è eseguito sostituendo il lato sini-
hand side by the right hand side in all assign- stro con il lato destro in tutte le assegnazioni. Ra-
ments. Conditional branches and loops are mificazioni condizionate e costrutti iterativi sono
translated into Boolean expressions. The final tradotti in espressioni Booleane. Il risultato finale
result is a symbolic expression for each pro- è un’espressione simbolica per ogni variabile di
gram variable. This can be checked against the programma. Questo può essere verificato nei con-
expected expression. fronti dell’espressione attesa.
Formal Program Verification using Symbolic Exe- Formal Program Verification using Symbolic Exe-
cution. R.B. Dannenberg and G.W. Ernst,IEEE cution. R.B. Dannenberg and G.W. Ernst,IEEE
Trans Software Engineering, Vol. SE-8, No 1, 1982. Trans Software Engineering, Vol. SE-8, No 1, 1982.
Symbolic Execution and Software Testing. J.C. Symbolic Execution and Software Testing. J.C.
King, Comm. ACM, Vol. 19, No 7, 1976. King, Comm. ACM, Vol. 19, No 7, 1976.
B.64 Time Petri Nets (Referenced by D.5 and D.7) Reti di Petri Temporali (Riferimento a D.5 e D.7)
Aim Scopo
To model relevant aspects of the system behav- Modellare aspetti attinenenti al comportamento
iour and to assess and possibly improve safety del sistema e valutare migliorando possibilmente
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 121 di 128
and operational requirements through analysis la sicurezza e i requisiti funzionali tramite l’analisi
and re-design. e la riprogettazione.
Petri nets belong to a class of graph theoretic Le reti di Petri appartengono ad una classe di mo-
models which are suitable for representing in- delli teorici grafici che sono adatti a rappresentare
formation and control flow in systems exhibit- informazioni e flussi di controllo in sistemi esi-
ing concurrency and asynchronous behaviour. stenti che presentano concorrenza e comporta-
mento asincrono.
A Petri net is a network of places and transi- Una rete di Petri è una rete di comunicazione di
tions. The places may be “marked” or “un- luoghi e transizioni. I luoghi possono essere
marked”. A transition is “enabled” when all the “marcati” o “non marcati”. Una transizione è “abi-
input places to it are marked. When enabled, it litata” quando tutti i suoi luoghi di ingresso sono
is permitted (but not obliged) to “fire”. If it fires, marcati. Quando abilitata, è permesso (ma non
the input marks are removed, and each output obbligato) “accendere”. Se acceso, le marcature
place from the transition is marked instead. d’ingresso sono rimosse, ed ogni luogo di uscita
dalla transizione è marcato.
The potential hazards are represented as partic- I pericoli potenziali sono rappresentati come stati
ular states (markings) in the model. Extended particolari (marcature) nel modello. Reti di Petri
Petri nets allow timing features of the system to estese permettono di collocare nel tempo le caratte-
be modelled. Although “classical” Petri nets ristiche del sistema da modellare. Per quanto le reti
concentrate on control flow aspects, several ex- di Petri “classiche” si concentrino sugli aspetti del
tensions have been proposed to incorporate da- flusso di controllo, sono state proposte molte esten-
taflow into the model. sioni per includere il flusso dei dati nel modello.
Net Theory and Applications. W. Brauer (ed), Net Theory and Applications. W. Brauer (ed), Lec-
Lecture Notes in Computer Science, Vol. 84, ture Notes in Computer Science, Vol. 84, Springer
Springer 1980. 1980.
Petri Net Theory and Modelling of Systems. J.L. Petri Net Theory and Modelling of Systems. J.L.
Peterson, Prentice Hall, 1981. Peterson, Prentice Hall, 1981.
Safety Analysis using Petri Nets. N. Leveson and Safety Analysis using Petri Nets. N. Leveson and J.
J. Stolzy, Proc. FTCS 15, Ann Arbor,Michigan, Stolzy, Proc. FTCS 15, Ann Arbor,Michigan, June
June 1985, IEEE 1985. 1985, IEEE 1985.
A Tool for Requirements Specification and Anal- A Tool for Requirements Specification and Analy-
ysis of Real Time Software Based on Timed sis of Real Time Software Based on Timed Petri
Petri Nets. S. Bologna, F. Pisacane, C Ghezzi, D. Nets. S. Bologna, F. Pisacane, C Ghezzi, D. Man-
Mandrioli, Proc. SAFECOMP 88, 9-11Nov. 1988. drioli, Proc. SAFECOMP 88, 9-11Nov. 1988. Fulda
Fulda Fed. Rep. of Germany 1988. Fed. Rep. of Germany 1988.
B.65 Translator Proven In Use (Referenced by Traduttore provato con l’uso (Riferimento
Aim Scopo
To avoid any difficulties due to translator failures Evitare ogni difficoltà dovuta ai mancati funziona-
which can arise during development, verification menti del traduttore che possono sorgere durante
and maintenance of a software package. lo sviluppo, verifica e manutenzione di un pac-
chetto software.
A translator is used, whose correct performance È usato un traduttore la cui corretta prestazione è
has been demonstrated in many projects al- già stata dimostrata in molti progetti. Traduttori
ready. Translators without operating experience senza esperienza di funzionamento o con qualsia-
or with any serious known errors are prohibited. si errore serio noto sono proibiti.
If the translator has shown small deficiencies Se il traduttore ha mostrato piccole deficienze i
the related language constructs are noted down costrutti del linguaggio relativo sono annotati ed
and carefully avoided during a safety related accuratamente evitati nel corso di un progetto in
project. sicurezza.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 122 di 128
Another version to this way of working is to re- Un’altra versione di tale modo di lavorare è di re-
strict the usage of the language to only its com- stringere l’uso del linguaggio alle sole sue caratte-
monly used features. ristiche più comunemente usate.
This recommendation is based on the experi- Tale raccomandazione è basata sull’esperienza di
ence from many projects. It has been shown molti progetti. È stato mostrato che traduttori non
that immature translators are a serious handicap maturi sono un serio handicap per lo sviluppo di
to any software development. They make a qualsiasi software. Essi rendono generalmente
safety-related software development generally non realizzabile lo sviluppo di un software in si-
infeasible. curezza.
It is also known, presently, that no method exits È anche noto che, al momento, non esiste alcun
to prove the correctness for all compiler parts. metodo per provare la correttezza di tutte le parti
del compilatore.
B.66 Walkthroughs/Design Reviews (Referenced Analisi del Percorso (Walkthroughs)/Riesame

by D.8) della progettazione (Riferimento a D.8)
Aim Scopo
To detect errors in some product of the devel- Rilevare errori in alcuni prodotti del processo di
opment process as soon and as economically as sviluppo il più presto ed il più economicamente
possible. possibile.
IEC/TC 56, have published a Guide on Formal Il comitato IEC/TC 56 ha pubblicato una Guida sui
Design Reviews, which includes a general de- Riesami della progettazioni Formali che comprende
scription of formal design reviews, their objec- una descrizione generale del riesame della progetta-
tives, details of the various design review types, zione formale, i suoi obbiettivi, dettagli dei vari tipi di
the composition of a design review team and riesame della progettazione, la composizione del
their associated duties and responsibilities. The gruppo di lavoro per il riesame della progettazione e
IEC document also provides general guidelines le loro relative funzioni e responsabilità. Il documen-
for planning and conducting formal design re- to IEC fornisce anche linee guida generali per pianifi-
views, as well as specific details concerning the care e condurre i riesami della progettazione formali,
role of independent specialists within a design oltre che i dettagli specifici concernenti il ruolo degli
review team. Examples of specialist functions specialisti indipendenti entro il gruppo di riesame
include, amongst others, Reliability, Mainte- della progettazione. Esempi delle funzioni degli spe-
nance Support and Availability. cialisti comprendono, tra l’altro, quelli per l’Affidabili-
tà, il Supporto alla Manutenzione e la Disponibilità.
The IEC recommend that a “formal design re- La IEC raccomanda che un “riesame della progetta-
view shall be conducted for all new prod- zione formale sia eseguito per tutti i nuovi prodot-
ucts/processes, new applications, and revisions ti/processi, per le nuove applicazioni e le revisioni
to existing products and manufacturing process- di prodotti esistenti o processi manifatturieri che in-
es which affect the function, performance, safe- fluenzano la funzione, la prestazione, la sicurezza,
ty, reliability, ability to inspect maintainability, l’affidabilità, la capacità di ispezionare la manuteni-
availability, ability to cost, and other characteris- bilità, la disponibilità, la capacità di spesa e altre ca-
tics affecting the end product/process, users or ratteristiche che influenzano il prodotto/processo fi-
bystanders”. nale, gli utenti o gli soggetti secondari”.
A code walk through consists of a walk through L’analisi del percorso del codice consiste in un grup-
team selecting a small set of paper test cases, po di analisi che sceglie un piccolo insieme di casi
representative sets of inputs and corresponding di prova cartacei, insieme rappresentativi dei dati di
expected outputs for the program. The test data ingresso e delle corrispondenti uscite attese per il
is then manually traced through the logic of the programma. I dati di prova sono quindi tracciati ma-
program. nualmente attraverso la logica del programma.
Sons, New York, 1979. Sons, New York, 1979.
Reliability and Maintainability Guide on Formal Reliability and Maintainability Guide on Formal
Design Review (Draft) International Electrotech- Design Review (Draft) International Electrotechni-
nical Commission, Technical Committee No 56, cal Commission, Technical Committee No 56, Ja-
January 1988. nuary 1988.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 123 di 128
B.67 Fuzzy Logic (Referenced by clause 10) Logica Fuzzy (Riferimento all’art. 10)
Aim Scopo
Fuzzy Logic is a mathematical discipline, based La Logica Fuzzy è una disciplina matematica, ba-
on the fuzzy set theory that allows for degrees of sata sulla teoria dell’insieme fuzzy che valuta i
truth and falseness. It is a generalisation of gradi di vero e falso. È una generalizzazione della
bi-level logic which provides a model for ap- logica a due livelli che fornisce un modello per il
proximate reasoning. It enables the incorpora- ragionamento per approssimazione. Essa consen-
tion of human intelligence into automatic sys- te di introdurre l’intelligenza dell’uomo nei siste-
tems. By acknowledging the difficulty of defining mi automatici. Con il riconoscimento delle diffi-
precise boundaries, Fuzzy Logic reduces the re- coltà di definire confini precisi, la Logica Fuzzy
quired precision, and hence leads to high level riduce la precisione richiesta, e conduce pertanto
and simple solutions which are easy to control. ad elevati livelli e a semplici soluzioni che sono
facili da controllare.
The essential part of a Fuzzy Logic solution is a La parte essenziale di una soluzione a Logica Fuz-
set of linguistic rules (IF - THEN rules) where zy è un’insieme di regole linguistiche (regole IF -
the antecedents and the consequents are associ- THEN) ove gli antecedenti e i conseguenti sono
ated with fuzzy sets. associati con insiemi fuzzy.
EXAMPLE IF speed is fast and distance_to_stop ESEMPIO IF la velocità è rapida e la distanza
is medium THEN accelerator is near dall’arresto è media THEN l’accelerato-
zero and brake is light re è quasi zero ed il freno è ridotto
In this example, “speed” is a linguistic variable Nell’esempio, “la velocità” è una variabile lingui-
characterised by a fuzzy set “fast”, which can be stica caratterizzata da un’insieme fuzzy “rapida”,
interpreted as “speed is above about 70 km/h”. che può essere interpretata come “la velocità è
If speed is less than 60 km/h, the membership circa oltre 70 km/h”. Se la velocità è inferiore a 60
value of “fast” is 0. If speed is above 80 km/h, km/h, il valore associato di “rapida” è 0. Se la ve-
the memberships value of “fast” is 1. If speed is locità è oltre 80 km/h, il valore associato di “rapi-
between 60 and 80 km/h, the membership val- da” è 1. Se la velocità è tra 60 e 80 km/h, il valore
ue of “fast” varies between 0 and 1. associato di “rapido” varia tra 0 e 1.
The decision making logic is based on mathe- La logica di assunzione delle decisioni è basata su
matical classes of operators: the triangular classi matematiche di operatori: le norme e le
norms and triangular co-norms. co-norme triangolari.
Fuzzy Logic rule-based systems differ from oth- I sistemi basati sulle regole della Logica Fuzzy dif-
er expert systems in many ways as: (1) the feriscono dagli altri sistemi esperti in molti modi
small number of rules, (2) the use of forward come: (1) il piccolo numero di regole, (2) il solo
chaining only, (3) non-chaining of inferences uso di concatenamento in avanti, (3) non conca-
(all rules are executed in parallel in one itera- tenamento delle interferenze (tutte le regole sono
tion), (4) the statistically defined rules, (5) the eseguite in parallelo in una iterazione), (4) le re-
speed of execution due to simplicity of the so- gole definite statisticamente, (5) la velocità di ese-
lutions, and (6) the determinism. cuzione dovuta alla semplicità delle soluzioni, e
(6) il determinismo.
During the past few years, Fuzzy Logic has Nei pochi anni trascorsi, la Logica Fuzzy ha trova-
found numerous applications in fields ranging to numerose applicazioni nei campi che spaziano
from finance to earthquake engineering. In par- dalla finanza all’ingegneria dei terremoti. In parti-
ticular, fuzzy control has emerged to control colare, il controllo fuzzy è emerso per controllare
highly non-linear systems, or systems which sistemi altamente non lineari o sistemi la cui de-
mathematical description is unknown or too scrizione matematica è sconosciuta o troppo com-
complex to be treated analytically, or systems in plessa per essere trattata analiticamente, o sistemi
which the available measurements are of poor nei quali le misure disponibili sono di scarsa qua-
quality. lità.
Notable applications of fuzzy logic control in- Notevoli applicazioni del controllo a logica fuzzy
clude aircraft flight control, and power systems comprendono il controllo di volo degli aerei ed il
and nuclear reactor control. More recently, controllo dei sistemi di generazione di energia e
fuzzy control has been applied successfully to dei reattori nucleari. Più recentemente, il control-
automatic train operation systems. lo fuzzy è stato applicato con successo ai sistemi
ATO (automatic train operation).
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 124 di 128
Fuzzy Sets: Zadeh. Information and Control, Fuzzy Sets: Zadeh. Information and Control, 1965,
1965, vol 8, pp338-353 vol 8, pp338-353
Fuzzy Logic in Control Systems: Fuzzy Logic Fuzzy Logic in Control Systems: Fuzzy Logic Con-
Controller, Part I & II. Chuen Chien Lee. IEEE troller, Part I & II. Chuen Chien Lee. IEEE Tran-
Transactions on systems, man, and cybernetics, sactions on systems, man, and cybernetics, vol.
vol. 20, No2, March/April 1990 20, No2, March/April 1990
Industrial Applications of Fuzzy Control: M.Sug- Industrial Applications of Fuzzy Control: M.Suge-
eno Ed., Amsterdam North Holland, 1985 no Ed., Amsterdam Nord Holland, 1985
Automatic Train Operation System by Predictive Automatic Train Operation System by Predictive
Fuzzy Control: Yasunobu, Miyamoto, in Indus- Fuzzy Control: Yasunobu, Miyamoto, in Industrial
trial Applications of Fuzzy Control, M.Sugeno Applications of Fuzzy Control, M.Sugeno Ed., Am-
Ed., Amsterdam North Holland, 1985 sterdam North Holland, 1985
An automatic operation method for control rods An automatic operation method for control rods
in BWR plants: Kinoshita, Fukusaki, Satoh, Mi- in BWR plants: Kinoshita, Fukusaki, Satoh, Mi-
yake, Proc. Specialists Meeting on In-Core In- yake, Proc. Specialists Meeting on In-Core Instru-
strumentation and Reactor Core Assessment. mentation and Reactor Core Assessment. Cadara-
Cadarache, France 1988 che, France 1988

Use of rule-based system for process control. Use of rule-based system for process control.
Bernard. IEEE Contr. Syst. Mag., Vol.8, No.5, Bernard. IEEE Contr. Syst. Mag., Vol.8, No.5,
pp.3-13, 1988 pp.3-13, 1988
B.68 Object Oriented Programming (Referenced by Programmazione Orientata all’Oggetto

Aim Scopo
To enable rapid prototyping, to more easily re- Consentire una rapida prototipazione, per riusare
use existing software components, to achieve più facilmente le componenti software esistenti,
information hiding, to reduce the likelihood of per ottenere l’occultamento dell’informazione, per
errors during the whole lifecycle, to reduce the ridurre la probabilità di errori durante tutto il ciclo
necessary effort during the maintenance phase, di vita, per ridurre l’impegno necessario durante
to break down complex problems into more la fase di manutenzione, per spezzare problemi
easily manageable small problems, to reduce complessi in piccoli problemi gestibili più facil-
the dependencies between software compo- mente, per ridurre le dipendenze tra componenti
nents, to create more easily extendible applica- software, per creare più facilmente applicazioni
tions. estensibili.
Object oriented programming is a fundamental- La programmazione orientata agli oggetti è una
ly new way of thinking about software based via essenzialmente nuova di pensare il software
on abstractions that exist in the real world rath- basata sulle astrazioni che esistono nel mondo re-
er than based on computational abstractions. ale piuttosto che basata su astrazioni di calcolo.
Object oriented programming organises soft- La programmazione orientata agli oggetti organiz-
ware as a collection of objects that incorporate za il software come una collezione di oggetti che
both data structure and behaviour. This is in incorpora sia la struttura che il comportamento
contrast to conventional programming where dei dati. Questo è in contrasto con la programma-
data structure and behaviour are only loosely zione convenzionale dove la struttura dei dati e
connected. comportamento sono solo relativamente connessi.
Object: an object consists of a private data area Oggetto: un oggetto consiste di un’area privata di
and set of operations - so called methods - on dati e di un insieme di operazioni – anche chia-
that object. Methods may be public or private. mati metodi – su quell’oggetto. I metodi possono
No other software component is allowed to essere pubblici o privati. A nessun altro compo-
read or change the private data of an object di- nente software è permesso di leggere o cambiare
rectly. Every other software component has to direttamente i dati privati di un oggetto. Ogni al-
use the public methods on that object to read or tro componente software deve usare i metodi
write data in the private data area of an object. pubblici su quell’oggetto per leggere o scrivere
dati nell’area privata di un oggetto.
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 125 di 128
Object Class: by specifying an object class (of- Classe dell’oggetto: specificando una classe dell’og-
ten in the form of a type definition) you enable getto (spesso nella forma di una definizione di ti-
the instantiation of numerous objects of the po) si rende possibile la replica di numerosi oggetti
same class, i.e., all instantiations have the pri- della medesima classe, cioè, tutte le repliche hanno
vate data area and the methods defined in the l’area dei dati privata e i metodi definiti nella classe
object class. dell’oggetto.
(Multiple) Inheritance: an object class can inher- Ereditarietà (Multipla): una classe dell’oggetto può
it the private data area and the methods of one ereditare l’area di dati privati ed i metodi di una (o
(or more) superclasses (object classes above it più) superclassi (classi di oggetti al di sopra di que-
in the class hierarchy) with being allowed to sta nella gerarchia delle classi) essendo consentito
add some private data, to add some methods or aggiungere alcuni dati privati, per aggiungere alcuni
to modify the implementations of the inherited metodi o modificare le implementazioni dei metodi
methods. Using Inheritance multiple object ereditati. Usando l’ereditarietà multipla possono es-
class trees can be built. sere costruiti alberi di classe dell’oggetto.
Polymorphism: the same operation may behave Polimorfismo: la medesima operazione si può com-
different on different object classes, e.g., the portare in modo diverso in differenti classi di ogget-
write operation for a terminal object writes ti, ad esempio, l’operazione di scrittura per un og-
characters to that terminal and a write operation getto terminale scrive caratteri su quel terminale ed
to a file object writes characters to that file. un’operazione di scrittura su un oggetto archivio
scrive caratteri su quell’archivio.
Object Oriented Software Construction, Bertrand Object Oriented Software Construction, Bertrand
Meyer, England: Prentice Hall International, 1988. Meyer, England: Prentice Hall International, 1988.
Classification as a paradigm for computing, Pe- Classification as a paradigm for computing, Peter
ter Wegner, Technical Report CS-86-11, Brown Wegner, Technical Report CS-86-11, Brown Uni-
University, May 1986. versity, May 1986.
Learning language, Peter Wegner, Byte (Mc- Learning language, Peter Wegner, Byte (Mc-
Graw-Hill publication) March 1989. Graw-Hill publication) March 1989.
All OOPSLA (Object-Oriented Programming All OOPSLA (Object-Oriented Programming Sy-
Systems, Languages and Applications) and stems, Languages and Applications) and ECOOP
ECOOP (European Conference on Object-Ori- (European Conference on Object-Oriented Pro-
ented Programming) conference proceedings. gramming) conference proceedings.
B.69 Traceability (Referenced by clause 11) Tracciabilità (Riferimento all’art. 11)
Aim Scopo
The objective of Traceability is to ensure that all L’obbiettivo della Tracciabilità è quello di assicu-
requirements can be shown to have been prop- rare che si possa mostrare che tutti i requisiti sia-
erly met and that no untraceable material has no stati soddisfatti in modo appropriato e che non
been introduced. sia stato introdotto materiale non rintracciabile.
Traceability to requirements shall be an important La tracciabilità dei requisiti deve essere considerata
consideration in the validation of a system and importante nella validazione del sistema e devono
means shall be provided to allow this to be dem- essere previsti mezzi per consentire che questo sia
onstrated throughout all phases of the lifecycle. dimostrato in tutte le fasi del ciclo di vita.
Traceability shall be considered applicable to La tracciabilità deve essere considerata applicabile
both functional and non-functional require- sia ai requisiti funzionali che a quelli non funzio-
ments and shall particularly address nali e deve trattare in particolare
a) traceability of requirements to the design or a) tracciabilità dei requisiti per la progettazione
other objects which fulfil them, o altri oggetti che la soddisfano,
b) traceability of design objects to the imple- b) tracciabilità degli oggetti della progettazione
mentation objects which instantiate them, con gli oggetti dell’implementazione che li re-
plica,
c) traceability of requirements and design ob- c) tracciabilità dei requisiti e degli oggetti della
jects to the operational and maintenance progettazione con oggetti funzionali e di ma-
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 126 di 128
objects required to be applied in the safe nutenzione che si richiede siano applicati
and proper use of the system, nell’uso sicuro ed appropriato del sistema,
d) traceability of requirements, design, imple- d) tracciabilità di requisiti, progettazione, imple-
mentation, operation and maintenance ob- mentazione, funzionamento e oggetti di ma-
jects, to the verification and test plans and nutenzione, per la verifica e i piani di prova e
specifications which will determine their ac- le specifiche che determineranno la loro ac-
ceptability, cettabilità,
e) traceability of verification and test plans and e) tracciabilità della verifica e dei piani di prova
specifications to the test or other reports e delle specifiche per la prova o altri rapporti
which record the results of their applica- che registrano i risultati della loro applicazio-
tion. ne.
Where requirements, design or other objects are Ove requisiti, la progettazione o altri oggetti sono
instantiated as a number of separate docu- replicati come una serie di documenti separati, la
ments, traceability shall be maintained within tracciabilità deve essere mantenuta nelle strutture
the document structures and in a hierarchical del documento ed in modo gerarchico.
manner.
The output of the Traceability process shall be Il risultato della Tracciabilità deve essere oggetto
the subject of formal Configuration Manage- di Gestione della Configurazione formale.
ment.
Fine Documento
NORMA TECNICA
CEI EN 50128:2002-04
Pagina 127 di 128
La presente Norma è stata compilata dal Comitato Elettrotecnico Italiano
e beneficia del riconoscimento di cui alla legge 1º Marzo 1968, n. 186.
Editore CEI, Comitato Elettrotecnico Italiano, Milano - Stampa in proprio
Autorizzazione del Tribunale di Milano N. 4093 del 24 luglio 1956
Responsabile: Ing. A. Alberici
9 – Trazione
CEI 9-7 CEI EN 50124-1 (CEI 9-65/1)
Relè neutri a corrente continua per impianti fissi di segnala- Applicazioni ferroviarie, tranviarie, filotranviarie, metropolita-
mento e di sicurezza di ferrovie, tranvie e metropolitane ne - Coordinamento degli isolamenti Parte 1: Requisiti base -
Distanze in aria e distanze superficiali per tutta l’apparecchia-
CEI EN 50215 (CEI 9-13)
tura elettrica ed elettronica
Applicazioni ferroviarie, tranviarie, filotranviarie, metropolita-
ne Prove del materiale rotabile dopo il completamento della CEI EN 50124-2 (CEI 9-65/2)
costruzione e prima dell’entrata in servizio Applicazioni ferroviarie, tranviarie, filotranviarie, metropolita-
ne - Coordinamento degli isolamenti Parte 2: Sovratensioni e
CEI 9-21
relative protezioni
Caratteristiche e prove dei sistemi di frenatura elettrodinamici
ed elettromagnetici CEI EN 50159-1 (CEI 9-66/1)
Applicazioni ferroviarie, tranviarie, filoviarie e metropolitane -
CEI 9-22
Sistemi di telecomunicazione, segnalamento ed elaborazione
Guida per la compilazione delle disposizioni per la sicurezza e
Parte 1: Comunicazioni di sicurezza in sistemi di trasmissione

la regolarità dell’esercizio ferroviario Esercizio degli impianti di
di tipo chiuso
trazione elettrica
CEI EN 50159-2 (CEI 9-66/2)
CEI EN 50153 (CEI 9-29)
Applicazioni ferroviarie Materiale rotabile Misure di protezione
Sistemi di telecomunicazione, segnalamento ed elaborazione
contro i pericoli di origine elettrica
Parte 2: Comunicazioni di sicurezza in sistemi di trasmissione
CEI EN 50155 (CEI 9-30) di tipo aperto
Applicazioni ferroviarie Equipaggiamenti elettronici utilizzati
CEI R009-005
sul materiale rotabile
CEI EN 50163 (CEI 9-31) Sistemi di radiocomando a distanza di veicoli di trazione per
Applicazioni ferroviarie Tensioni di alimentazione dei sistemi trasporto merci in trazione multipla
di trazione
CEI EN 50121-1 (CEI 9-35/1)
Compatibilità elettromagnetica Parte 1: Generalità
CEI EN 50121-2 (CEI 9-35/2)
Compatibilità elettromagnetica Parte 2: Emissione dell’intero
sistema ferroviario verso l’ambiente esterno
CEI EN 50121-4 (CEI 9-35/4)
Compatibilità elettromagnetica Parte 4: Emissione ed immuni-
ta’ delle apparecchiature di segnalamento e telecomunicazioni
CEI R009-001
Sistemi di comunicazione, di segnalamento e di processo Tas-
si di guasto pericoloso e livelli di integrità della sicurezza (SIL)
CEI EN 50261 (CEI 9-47)
Montaggio dell’apparecchiatura elettronica
CEI ENV 50129 (CEI 9-55)
Sistemi elettronici di sicurezza per il segnalamento
CEI EN 50126 (CEI 9-58)
Applicazioni ferroviarie, tranviarie, filotranviarie, metropolita-
ne La specificazione e la dimostrazione di Affidabilità, Dispo-
nibilità, Manutenibilità e Sicurezza (RAMS)
CEI EN 50125-1 (CEI 9-60)
Condizioni ambientali per gli equipaggiamenti Parte 1: Equi-
paggiamenti nel materiale rotabile
CEI EN 50239 (CEI 9-62)
Sistemi di radiocomando a distanza di veicoli di trazione per
trasporto merci
125,00
NORMA TECNICA Sede del Punto di Vendita e di Consultazione
CEI EN 50128:2002-04 20134 Milano - Via Saccardo, 9
Totale Pagine 136 tel. 02/21006.1 • fax 02/21006.222
http://www.ceiuni.it
Copia concessa a ANSALDO S.F. SPA e ANSALDO BREDA e-mail: cei@ceiuni.it
in data 02/10/2007 da CEI-Comitato Elettrotecnico Italiano

Cei en 50128

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Cei en 50128

Caricato da

Copyright:

Formati disponibili

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

APPARECCHIATURE ELETTRICHE PER SISTEMI DI ENERGIA E PER TRAZIONE

COLLEGAMENTI/RELAZIONI TRA DOCUMENTI

Norma Italiana CEI EN 50128 Pubblicazione Norma Tecnica Carattere Doc.

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

Comitato Tecnico 9-Trazione

Gruppo Abb. 3 Sezioni Abb. B

© CEI - Milano 2002. Riproduzione vietata.

Applicazioni ferroviarie, tranviarie, filoviarie e metropolitane

1 SCOPE CAMPO D’APPLICAZIONE 4

2 NORMATIVE REFERENCES RIFERIMENTI NORMATIVI 5

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

4 OBJECTIVES AND CONFORMANCE OBIETTIVI E CONFORMITÀ 9

5 SOFTWARE SAFETY INTEGRITY LIVELLI DI INTEGRITÀ DELLA SICUREZZA

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

8 SOFTWARE REQUIREMENTS SPECIFICATION SPECIFICA DEI REQUISITI DEL SOFTWARE 18

9 SOFTWARE ARCHITECTURE ARCHITETTURA DEL SOFTWARE 20

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

10 SOFTWARE DESIGN AND PROGETTAZIONE ED IMPLEMENTAZIONE

11 SOFTWARE VERIFICATION AND TESTING VERIFICA E PROVA DEL SOFTWARE 26

12 SOFTWARE/HARDWARE INTEGRATION INTEGRAZIONE SOFTWARE/HARDWARE 30

13 SOFTWARE VALIDATION VALIDAZIONE DEL SOFTWARE 32

14 SOFTWARE ASSESSMENT VALUTAZIONE DEL SOFTWARE 34

15 SOFTWARE QUALITY ASSURANCE ASSICURAZIONE DELLA QUALITÀ DEL SOFTWARE 35

16 SOFTWARE MAINTENANCE MANUTENZIONE DEL SOFTWARE 38

17 SYSTEMS CONFIGURED BY SISTEMI CONFIGURATI CON DATI

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

CEI EN 50128:2002-04 NORMA TECNICA

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

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

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

2 NORMATIVE REFERENCES RIFERIMENTI NORMATIVI

Pubblicazione Titolo Norma CEI

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

3.1 Assessment Valutazione

3.2 Assessor Valutatore

3.3 Availability Disponibilità

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

3.5 Design authority Autorità per il progetto

3.6 Designer Progettista

3.8 Error Errore

3.9 Failure Mancato funzionamento

3.10 Fault Guasto

3.11 Fault avoidance Tecnica per evitare i guasti

3.12 Fault tolerance Tolleranza ai guasti

3.13 Firmware Firmware

3.14 Generic software Software generico

3.15 Implementer Implementatore

3.16 Product Prodotto

3.18 Reliability Affidabilità

3.19 Requirements traceability Tracciabilità dei requisiti

3.20 Risk Rischio

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

3.21 Safety Sicurezza

3.22 Safety authority Autorità per la sicurezza

3.23 Safety-related software Software in sicurezza

3.24 Software Software

3.25 Software life-cycle Ciclo di vita del software

3.26 Software maintainability Manutenibilità del software

3.30 Traceability Tracciabilità

3.31 Validation Validazione

3.32 Validator Validatore

3.33 Verification Verifica