Corso SIL Valvoliere IMQ - Progettazione SW

Sicurezza Funzionale per
l’Automazione Industriale
Realizzazione del SW
per Sistemi
Si t i di Si
Sicurezza
Sicurezza Funzionale 1
Elenco contenuti
¾ Tipi di SW secondo IEC 61508

¾ Generalità del SW Quality Management System
¾ Modello di sviluppo del SW
¾ Fasi: specifica dei requisiti,… validazione
¾ Tecniche e metodi per lo sviluppo SW
Tipologie di Software
¾ Software
S ft specifico
ifi del
d l prodotto
d tt
¾ Sistema operativo
¾ Software embedded (Firmware)
¾ Software applicativo
¾ Strumenti
¾ Compilatori
¾ T l di programmazione
Tools i
¾ Tools di testing
¾ Gestione della configurazione
Terminologia (tipologie di SW)
SOFTWARE EMBEDDED
SW parte del sistema fornito dal costruttore e non accessibile
all’utente finale. Solitamente definito come Firmware o System SW.
SOFTWARE APPLICATIVO
SW specifico per l’applicazione utente. In generale, contiene
sequenze logiche, limiti ed espressioni per controllare ingressi ed
uscite, calcoli e decisioni necessarie per soddisfare i requisiti di
sicurezza funzionale. Si veda FVL e LVL.
SOFTWARE DI UTILITY
Strumenti SW per la creazione, modifica e documentazione di
programmi applicativi ed embedded. Non sono richiesti per il
funzionamento di un Sistema di Sicurezza.
Terminologia (SW)
FIXED PROGRAM LANGUAGE (FPL)
Linguaggio in cui ll’utente
utente si limita a configurare solo alcuni parametri (ad
es., range del trasmettitore di pressione, livelli di allarme, indirizzi di rete)
LIMITED VARIABILITY LANGUAGE (LVL)

Tipo di linguaggio progettato per essere comprensibile agli utilizzatori del
settore di processo, e fornisce le potenzialità per combinare funzioni di
libreria predefinite, specifiche per l’applicazione, per implementare le
Specifiche dei Requisiti di Sicurezza (SRS)
NOTA 1: esempi di LVL sono diagrammi a scala, diagrammi a blocchi
funzionali, diagrammi funzionali sequenziali
FULL VARIABILITY LANGUAGE (FVL)

Tipo di linguaggio progettato per essere comprensibile ai programmatori di
computer; fornisce le potenzialità per implementare una grande varietà di
applicazioni
NOTA 3: esempi di FVL:, C, C++, Pascal, Assembler, Java, SQL
Tipologie di Software
¾ EN 61508-3
¾ SW embedded o FVL utilizzato da costruttori
costruttori, progettisti
progettisti,
integratori e utilizzatori di Sistemi di Sicurezza
¾ EN 62061 / EN 13849-1:
¾ Requisiti per SW embedded (con richiamo alla EN 61508);
conformità completa alla EN 61508 per la EN 62061 e per la EN
13849-1 PL e, richiesto SIL 3
¾ SW applicativo sviluppato per sistemi a variabilità limitata o
programmi fissi: requisiti maggiormente qualitativi: non è
richiesta la rispondenza a tecniche e misure in maniera così
precisa come per SW embedded
Generalità
¾ Il SW con zero dif

difetti
tti è iimpossibile
ibil da
d ottenere
tt e
garantire
¾ Occorrono una programmazione strutturata una verifica
attenta e continua
¾ Tutto deve essere pianificato e verificato:
• Documenti di specifica
• Documenti di progetto
• Documenti di Test
¾ Si fa tutto lungo il percorso, non solo alla fine!
EN 61508
61508--3: configurazione
Management System
La gestione della versione deve includere tra l’altro:

1. Documentazione SW:
Specifiche dei Requisiti di Sicurezza
Pianificazione
Documenti di progetto
Piano di verifica e validazione
Rapporti di verifica
Istruzioni di processo, documentazioni per l’utente
2 Codice SW:
2.
Codice sorgente
Librerie
Sistema operativo
Strumenti Software
Dati di configurazione
Fasi del modello di sviluppo SW
1. Specifiche dei requisiti di sicurezza SW

2. Progetto dell’architettura SW
3. Pianificazione della validazione
4. Selezione dei linguaggi e degli strumenti di
programmazione
5. Sviluppo modulare e programmazione strutturata
g
6. Verifiche ed integrazioni ((SW,, SW/HW))
7. Validazione
IEC 61508: Sequenze della

realizzazione del SW
Sequenza in base alla 61508-6:

1. Specifica dei requisiti di sicurezza e parti relative alla
pianificazione della sicurezza
2. Definizione dell’architettura SW
3. Verifica della concordanza tra architettura SW e HW
4. Pianificazione della verifica e della validazione SW
5. Progetto, sviluppo e verifica del SW
6. Integrazione del SW nell’HW
7. Sviluppo di metodi operativi e di modifica, validazione parallela
8. Consegna del SW e relativa documentazione all’ingegneria di
sistema
9. Modifiche e manutenzione del SW
IEC 61508: Relazioni HW-SW
Campo di
Specifica requisiti Architettura applicazione
di sicurezza E/E/PES E/E/PES II parte
Requisiti di sicurezza HW
Campo di
applicazione Requisiti del Hardware di Hardware
III parte SW elettronica non
programmabile programmabile
Progettazione
e sviluppo P
Progetto
tt P
Progetto
tt
del SW e sviluppo di e sviluppo di
elettronica elettronica
programmabile non programmabile
Integrazione (HW e SW)

Integrazione
dell’elettronica programmabile E/E/PES
IEC 61508-
61508-3:
Modello di sviluppo SW (Modello a V)
Specifica
p Specifica
p Validazione
requisiti requisiti Esecuzione SW
sicurezza sicurezza validazione validato
E/E/PES SW
9.6
9.1 9.1
Architettura Architettura Verifica integrazione

E/E/PES SW su livello sistema
9.3 9.4
Progetto Verifica
sistema SW integrazione moduli
93
9.3 93
9.3
Progetto Verifica
Risultato modulo modulo
Verifica 9.3 9.3
9.3 Par. Norma

Codifica
9.3
Applicazione tecniche e misure
HR Highly Recommended:
La tecnica o misura è molto consigliata. Se questa tecnica o misura
non è utilizzata, allora deve essere dettagliato il motivo razionale per il
suo non utilizzo.
R Recommended:
La tecnica o misura è consigliata. È richiesta almeno una delle
tecniche o misure del gruppo ombreggiato in grigio.
- Neutral:
La
a tecnica
ec ca o misura
su a non
o ha
a raccomandazioni
acco a da o p pro
o o co
contro
o l’essere
esse e
utilizzata.
NR Not Recommended:
La tecnica o misura è decisamente non consigliata. Se questa tecnica
o misura è utilizzata, allora deve essere dettagliato il motivo razionale
per il suo utilizzo.
Efficacia di tecniche e misure
Mandatory La tecnica o misura è richiesta e deve essere usata il più efficacemente

possibile
ibil (efficacia
( ffi i elevata).
l t )
High La tecnica o misura deve essere usata fino al punto necessario per
fornire elevata efficacia contro guasti sistematici.
Medium La tecnica o misura deve essere usata fino al punto necessario per
fornire almeno media efficacia contro guasti sistematici.
Low La tecnica o misura deve essere usata fino al p

punto necessario p
per
fornire almeno bassa efficacia contro guasti sistematici.
Modelli di specifica di requisiti
Sistema di sicurezza Sistema non di sicurezza
Sistema di sicurezza HW HW non di sicurezza
SW di sicurezza SW non di sicurezza
SW correlato alla sicurezza

e non correlato alla sicurezza
Funzioni correlate alla sicurezza:

¾ C
Controllo
ll ingressi
i i e uscite
i correlati
l i alla
ll sicurezza
i
¾ Tests off-line
¾ Tests on-line (RAM, input/outputs, …)
¾ Reset watchdog
¾ Controllo tensione alimentazione
¾ …
Altre funzioni:
¾ Vi
Visualizzazione
li i
¾ Risultati di prova
¾ Ingressi e uscite non correlati alla sicurezza
¾ …
IEC 61508-
61508-3:
9.1 - Specifica dei requisiti
Riferimento: IEC 61508-3 Cap. 7.2.2.11
1. Specifica dei requisiti di sicurezza SW
1.1 Funzioni che permettono all’EUC
all EUC di raggiungere e mantenere uno stato di
sicurezza
1.2 Funzioni connesse con il riconoscimento, la visualizzazione e l’elaborazione di
guasti HW (PE)
guasti di sensori ed attuatori
guasti SW (Auto-monitoraggio)
1.5 Funzioni per le verifiche periodiche on-line delle funzioni di sicurezza
1.6 Funzioni per le verifiche periodiche off-line delle funzioni di sicurezza
1.7 Funzioni che garantiscono che il SIS possa essere modificato in modo sicuro
1.8 Interfacce alle funzioni non rilevanti per la sicurezza
1.9 Requisiti che si riferiscono alla capacità ed al comportamento nel tempo
1.10 Interfacce tra SW e SIS
2. Requisiti integrità di sicurezza SW

2.1 Classificazione SIL per tutti i requisiti citati in 1
IEC 61508-
61508-3: Tecniche e misure
A.1 - Specifica requisiti di sicurezza SW
Tecniche / Misure Rif. SIL 1 SIL 2 SIL 3 SIL 4
Strumenti
St ti computer-
t
aided per la
1 B.2.4 R R HR HR
definizione delle
specifiche
2a Metodi semi-formali Tab. B.7 R R HR HR
Metodi formali, per

es. CCS, CSP, HOL,
2b LOTOS OBJ,
LOTOS, OBJ C24
C.2.4 0 R R HR
Temporal Logic, VDM
eZ
Note:
Lettere come “a”, “b” indicano misure alternative
“Ref.” richiama il punto relativo della IEC 61508-7 (“Tab…” => 61508-3)
R: raccomandato, HR: richiesto, NR: da non utilizzare (!)
0: nessuna raccomandazione a favore oppure contro l’utilizzo
IEC 61508-
61508-3: Tecniche e misure
B.7 - Metodi semi-formali
Tecniche / Misure Rif. SIL 1 SIL 2 SIL 3 SIL 4
Diagrammi a blocco
1 v.d. R R HR HR
g
logici/funzionali
Diagrammi di
2 v.d. R R HR HR
sequenze
Diagrammi di flusso
3 C.2.2 R R R R
dati
Diagrammi
4 B.2.3.2 R R HR HR
transizione di stato
5 Reti Time-Petri B.2.3.3 R R HR HR
Decision / Truth
6 C.6.1 R R HR HR
tables
Note:
1 e 2 sono descritti nella IEC 61131-3: 1993: Controllori programmabili – parte 3: linguaggi di
programmazione
Controllo guasti
nella progettazione HW e SW
¾ Controllo di flusso del pprogramma

g ((logico
g e time-based))
¾ Controlli di validità (controlli on-line)
¾ Test con HW ridondante
¾ Interfaccia di prova standard
¾ Protezione del codice
¾ Diversità HW
Tipi di guasti RAM
¾ Stuck-at ‘1’ / ‘0’

La cella RAM è bloccata alta o bassa
¾ Stuck-at open
Modello di guasto per circuiti CMOS, considerato come Open
Gate. Lo stato della transizione dipende dallo stato dei circuiti
adiacenti
¾ Guasti di transizione
Le celle possono variare in una sola direzione (ad es
es., 0→1
0→1, ma
non 1→0)
¾ Guasti adiacenti
Influenza di un valore da celle adiacenti
¾ Guasti di ritardo
Guasto a causa di variazioni temporali
Esempio: Galpat Test
Step 1. Write: Ci←0 for i=0,1,…n-1

Step 2. For i=0,1,…n-1
Read: Ci(=0)
Write: Ci ←1
For all j≠i
Read: Cj(=0) (verifica che nessuna cella sia disturbata)
Read: Ci(=1) (verifica che il bit di prova sia corretto)
Write: Ci←0
Step 3. Repeat Steps 1 & 2, cambiando tra loro uni e zeri
n: numero delle celle di memoria

Ck k-esima cella di memoria
IEC 61508-3: Misure & Tecniche –
A.7 Validazione sicurezza SW
A.7 – Validazione Sicurezza Software
Tecniche / misure* Rif. SIL1 SIL2 SIL3 SIL4
1. Verifiche probabilistiche C.5.1 --- R R HR
2. Simulazione / modellizzazione Tab. B.5 R R HR HR
B.5.1
3. Prove funzionali e black-box B.5.2 HR HR HR HR
Tab. b.3
* È necessario selezionare metodi, misure e tecniche appropriate secondo il livello di integrità di sicurezza

A.9 Verifica
A.9 - Verifica del software
1. Dimostrazione formale C.5.13 --- R R HR
2. Verifiche statistiche C.5.1 --- R R HR
B.6.4
3. Analisi statistiche R HR HR HR
Tab. B.8
B.6.5
4. Analisi dinamiche e verifiche R HR HR HR
Tab. B.2
5. Metriche della complessità del software C.5.14 R R R R
Modulo SW e verifiche integrazione Si veda Tab. A.5
Prove di integrazione dell’elettronica
dell elettronica programmabile Si veda Tab
Tab. A
A.6
6
Prove sistema SW (validazione) Si veda Tab. A.7
B.8 Analisi statica
B.8 – Analisi statica
1. Analisi dei valori limite C.5.4 R R HR HR
2. Check lists B.2.5 R R R R
3. Analisi flusso di controllo C.5.9 R HR HR HR
4. Analisi flusso di dati C.5.10 R HR HR HR
5. Verifica manutenzione guasti C.5.5 R R R R
6. Ispezione Fagan C.5.15 --- R R HR
7. Analisi percorsi aggiuntivi C.5.11 --- --- R R
8. Esecuzione simbolica C.5.12 R R HR HR
9. Verifica walkthrough e di progetto C.5.18 HR HR HR HR

B.2 Analisi dinamica
B.2 – Analisi e prove dinamiche
1. Esecuzione "test cases" secondo analisi valore di C.5.4 R HR HR HR
confine
2. Esecuzione "test cases" secondo previsione guasti C.5.5 R R R R
3. Esecuzione "test cases" secondo implementazione
C.5.6 --- R R R
guasti (propagazione errore)
4. Modello capacità del sistema C.5.20 R R R HR
5. Classi equivalenti e verifica con zona limitata di input C.5.7 R R R HR
6. Verifiche dipendenti dalla struttura C.5.8 R R HR HR
Nota: l’analisi del “test case” sarà eseguita in base al livello del sistema ed è basata sulla specifica e/oppure specifica
e codice
IEC 61508-3:
9.2 Pianificazione della validazione
Input: specifica requisiti SW
Compiti & Scopi: progetto di una pianificazione
pianificazione, che preveda la possibilità di
provare (verificare) l’adeguatezza del SW e dei suoi requisiti in condizioni
reali
Risultati: piano di validazione SW
Requisiti:
¾ Documentazione, quando e chi esegue la validazione
¾ Identificazione dei possibili stati del sistema, inclusi struttura,
collocazione, Teach-in, stati operativi, di modifica, di anormalità
prevedibili… di fine funzionamento
¾ Metodi di validazione: manuale/automatico, statico/dinamico,
analitico/statistico
¾ Metriche per la valutazione di appropriati metodi di validazione, incl. criteri
superamento/non superamento per tutte le parti SW
¾ Regole per la valutazione dei risultati
IEC 61508-3: 9.3 Progettazione e sviluppo

– Fasi del modello di sviluppo del SW
1. Architettura
2. Strumenti e linguaggi di programmazione
3. Dettaglio della progettazione e sviluppo del sistema
4. Dettaglio della progettazione e sviluppo di singoli
moduli
5. Codifica di singoli moduli
6. Verifica del modulo
7. Verifica dell’integrazione
IEC 61508
61508--3: 9.3 Progettazione &
sviluppo – Generale
Tecniche adeguate
g alla SIL:
¾ Astrazione, modularità: riduzione della complessità
¾ Metodi di presentazione per funzioni e strutture di dati,
scorrere di dati tra moduli, dipendenze temporali
(sequenza e coincidenza)
¾ Considerare la verifica e la modificabilità durante la
progettazione
¾ I componenti e gli strumenti SW, che non verranno
verificati e convalidati dovranno essere “proven in use”
IEC 61508
61508--3: Misure & Tecniche –
A.2 Architettura SW (1)
A.2 – Progettazione e sviluppo Software: Progettazione architettura SW

1 Rilevazione dei guasti e diagnosi C.3.1 --- R HR HR
2 Codici di rilevazione e correzione guasti C.3.2 R R R HR
3a Controllo della plausibilità
C.3.3 R R R HR
(asserzione guasti)
3b Strumenti esterni di controllo C.3.4 --- R R R
3c Programmazione differenziata C.3.5 R R R HR
3d Blocchi di rigenerazione C.3.6 R R R R
3e Ripristino ritardato C.3.7 R R R R
3f Ripristino anticipato C.3.8 R R R R
3g Ripristino per tentativi ripetuti C.3.9 R R R HR
3h Memorizzazione relativa ai casi eseguiti C.3.10 --- R R HR
IEC 61508
A.2 Architettura SW (2)
A.2 – Progettazione e sviluppo Software: Progettazione architettura SW

4 Degradazione “lenta” C.3.11 R R HR HR
5 Intelligenza artificiale – correzione dei guasti C.3.12 --- NR NR NR
6 Riconfigurazione dinamica C.3.13 --- NR NR NR
7a Metodi strutturati inclusi, per esempio, JSD, MASCOT, C.2.1 HR HR HR HR
SADT e Yourdon
7b Metodi semi-formali Tab B.7 R R HR HR
7c Metodi formale incluso, per esempio, CCS, CSP, HOL, C.2.4 --- R R HR
OBJ,, LOTOS,, temporary
p y logic,
g , VDM e Z
8 Computer-aided tools per la definizione delle specifiche B.2.4 R R HR HR
* È necessario selezionare metodi, Misure e tecniche appropriate secondo il livello di integrità di sicurezza
IEC 61508
A.3 Strumenti e linguaggi
A.3 – Progettazione e sviluppo del Software: strumenti di supporto e linguaggi

di programmazione
i
1 Linguaggio di programmazione appropriato C.4.6 HR HR HR HR
2 Linguaggio di programmazione fortemente C.4.1 HR HR HR HR
standardizzato
3 Sottoinsieme del linguaggio C.4.2 --- --- HR HR
4a Strumenti certificati C.4.3 R HR HR HR
4b Strumenti: aumentata sicurezza derivante dall’uso C.4.4 HR HR HR HR
5a Traduttore certificato C.4.3 R HR HR HR
5b Traduttore: sicurezza aumentata derivante dall’uso C.4.4 HR HR HR HR
6 Libreria di moduli e componenti software verificati ed C.4.5 R HR HR HR
affidabili
* Metodi e misure alternative o equivalenti devono essere segnate da una lettera dietro al numero. Solo uno dei metodi
e delle misure alternative deve essere soddisfatto.
IEC 61508-
61508-3: Linguaggi appropriati
di programmazione (riassunto)
Linguaggio di programmazione SIL 1 SIL 2 SIL 3 SIL 4

1 Ad
Ada HR HR R R
2 Ada with subset HR HR HR HR
3 MODULA-2 HR HR R R
4 MODULA-2 with subset HR HR HR HR
5 PASCAL HR HR R R
6 PASCAL with subset HR HR HR HR
7 FORTRAN 77 R R R R
8 FORTRAN 77 with subset HR HR HR HR
9 C R --- NR NR
10 C with subset and coding standard and use of static analysis tools HR HR HR HR
11 PL/M R --- NR NR
12 PLM with subset and coding standard HR R R R
13 Assembler R R --- ---
14 Assembler with subset and coding standard R R R R
IEC 61508
A.4 Concetto & codifica
A.4 – Progettazione e sviluppo del Software: progetto dettagliato

(progettazione del sistema software, progettazione e codifica di moduli software)
1a Metodi strutturati, ivi inclusi ad es. JSD, MASCOT, C.2.1 HR HR HR HR
SADT e Yourdon
1b Metodi semi-formali Tab. B.7 R HR HR HR
1c Metodi formali, ivi inclusi ad es. CCS, CSP, HOL,
C.2.4 --- R R HR
LOTOS, OBJ, temporal logic, VDM e Z
2 Strumenti di progettazione computer-aided B.3.5 R R HR HR
3 Programmazione di protezione C.2.5 --- R HR HR
4 Approccio modulare Tab. B.9 HR HR HR HR
5 Norme, istruzioni di progetto e di codifica Tab. B.1 R HR HR HR
6 Programmazione strutturata C.2.7 HR HR HR HR
7 Uso di moduli e componenti software testati ed affidabili C.2.10
(se disponibili) R HR HR HR
C.4.5
* È necessario selezionare misure e tecniche appropriate secondo il livello di integrità di sicurezza
IEC 61508
A.4 Concetto & codifica
Linguaggio di programmazione: alto livello, altamente standardizzato
Sistema operativo: solo se necessario, preferibilmente senza interrupt
Codifica:
¾ Programmazione di protezione con rispetto alle linee guida di
programmazione
¾ Ridondanza di dati (CRC…) e funzioni (diversità,…)
¾ Controllo
C ll SW edd HW (l
(logicamente,
i temporalmente)
l )
¾ Preferibilmente oggetti non dinamici
¾ Codice deducibile dalla specifica dei requisiti usando la documentazione
(rintracciabilità)
IEC 61508
B.9 Modularizzazione
B.9 – Approccio modulare

1 Limite nella dimensione del modulo Software C.2.9 HR HR HR HR
2 Occultamento di informazioni/incapsulamento C.2.8 R HR HR HR
3 Limite al numero dei parametri C.2.9 R R R R
4 Un ingresso e una uscita in sottoprogrammi e funzioni C.2.9 HR HR HR HR
5 Interfacce completamente definite C.2.9 HR HR HR HR
Nota: per informazioni su tutte queste tecniche, ad eccezione di 2, si veda C.2.9 della IEC 61508-7
* Un solo metodo probabilmente non è sufficiente
sufficiente. Devono essere considerati tutti i metodi appropriati
appropriati.
IEC 61508
B.1 Linee guida
B.1 – Regole di progetto e codifica SW (menzionata nella Tab. A 4)

1 Uso di standard di codifica C.2.6.2 HR HR HR HR
2 No Oggetti dinamici C.2.6.3 R HR HR HR
3a No Variabili dinamiche C.2.6.3 --- R HR HR
3b Verifica on line dell’installazione di variabili dinamiche C.2.6.4 --- R HR HR
4 Uso limitato di interrupt C.2.6.5 R R HR HR
5 Uso limitato di puntatori C.2.6.6 --- R HR HR
6 Uso limitato di “variabili ricorsive” C.2.6.7 --- R HR HR
7 Non fare salti incondizionati nel programma in più alti C.2.6.2 R HR HR HR
livelli di linguaggio
Nota: le misure 2 e 3a non devono essere applicate se viene usato un compilatore che assicuri che una quantità
sufficiente di memoria venga stanziata per tutti gli oggetti e le variabili dinamiche prima del tempo di esecuzione, o che
inserisca controlli del tempo di esecuzione per la corretta collocazione on line della memoria.
* Tecniche e misure appropriate devono essere selezionate in funzione del livello di integrità di sicurezza.
Tecniche/misure alternative o equivalenti sono indicate da una lettera dopo il numero. Solo una delle tecniche/misure
alternative o equivalenti devono essere soddisfatte.
Norme di Programmazione e
Codifica
Vantaggi per lo sviluppo del SW:

¾ Aumento della leggibilità, miglioramento intelligibilità
¾ Porta a moduli SW gestibili e comprensibili
¾ Semplice per futuri sviluppi, specialmente per parti terze
¾ Software manutenibile
¾ Facilmente modificabile
¾ In generale:
• Non esiste una norma di programmazione valida in linea generale
• Le linee guida di programmazione non devono complicare il processo
• Troppe restrizioni sono controproducenti
• Deve essere adattato all’azienda e al processo di sviluppo
IEC 61508-
61508-3: Metodi & Tecniche –
A.4 Programmazione di dettaglio
A.4 - Progettazione e sviluppo Software: Programmazione di dettaglio

1a Metodi strutturati, ad esempio JSD, MASCOT, SADT, E C.2.1 HR HR HR HR
Yourdon
1b Metodi semi-formali Tab. B.7 R HR HR HR
1c Metodi formali, ad esempio CCS, CSP, HOL, LOTOS,
C.2.4 -- R R HR
OBJ, VDM, Z
2 Strumenti di programmazione Computer-aided B.3.5 R R HR HR
3 Programmazione difensiva C.2.5 -- R HR HR
4 Approccio modulare Tab. B.9 HR HR HR HR
5 Norme di programmazione e codifica Tab. B.1 R HR HR HR
6 Programmazione strutturata C.2.7 HR HR HR HR
7 Utilizzo di moduli e componenti SW verificati/validati C.2.10 R HR HR HR
C.4.5
* Una tecnica/misura numerata deve essere selezionata in base al livello di integrità di sicurezza
Programmazione difensiva
¾ Ridurre la complessità del codice ⇒ minor possibilità di bachi e di

problemi di sicurezza
¾ Revisione del codice sorgente
¾ Fasi di Test
¾ Validazione Input/Output
¾ Tutto il codice è pericoloso, tutti i dati sono importanti
Verifica SW
¾ Si fanno esperimenti
p con il comportamento
p del p
programma
g allo
scopo di scoprire eventuali errori
• Si campionano i comportamenti
• Come ogni risultato sperimentale, fornisce indicazioni parziali relative al
particolare esperimento
⇒Il programma è effettivamente provato solo per quei dati
¾ Il test è una tecnica dinamica rispetto alle verifiche statiche fatte dal
compilatore
Verifica SW
¾ Test esaustivo ((esecuzione per

p tutti i p
possibili ingressi)
g ) dimostra la
correttezza del SW
• Se un programma calcola un valore in base a un valore di ingresso tra
1e10, il test esaustivo consiste nel provare tutti i valori: per le 10
esecuzioni diverse si verifica se il risultato è quello atteso
¾ Impossibile da realizzare in generale:
¾ Se programma legge 3 ingressi interi tra 1e1000 e calcola un valore, il
test esaustivo richiederebbe 109 esecuzioni!
⇒per programmii b banalili sii arriva
i a tempii di esecuzione
i iimpossibili
ibili
¾ Program testing can be used to show the presence of bugs, but

never to show their absence! (Dijkstra 1972)
¾ Trovare dati di test che massimizzino la probabilità di trovare errori.
Criteri di prova SW
¾ È cruciale la scelta di opportuni

pp valori ((dati o casi di test)) "sufficienti
a convincerci" che il programma è corretto
• Esempio, eseguiamo il programma con i valori 1, 10 e 5
¾ In base a che cosa si determinano i casi di test?

• Test black-box o funzionale
• Test white-box o strutturale
¾ E quando?
• Idealmente, nel momento in cui si scrive la specifica del modulo
• In base a quali criteri?
Test Funzionale
¾ Combinare i vari casi alternativi espressi da una specifica
//@ post result == x && x>=y && x>=z ||
//@ result == y && y>=x && y>=z ||
//@ result == z && z>=x && z>=y;
static int maxOfThree (int x, int y, int z) {
¾ Ci sono tre alternative: il massimo è x, è y, o è z
¾ Casi di test ricavabili da postcondizione:
• Un caso in cui il massimo è x, p. es. (5,3,0)
• Un caso in cui il massimo è yy, pp. es
es. (7
(7,11,2)
11 2)
• Un caso in cui il massimo è z, p. es. (7,10,12)
//@ post result <==> x è primo
static boolean isPrime (int x)
¾ Scegliere dati di test primi e non primi. Es. 5 e 8
¾ Verificare non solo il comportamento normale, anche le eccezioni
Test con valori limite
¾ Se l’input può stare in un intervallo, collaudare gli estremi
dell’intervallo e combinare i valori limite
¾ Esempi:
• valori estremi per i numeri (max. int ammissibile)
• sqrt con radicando = 0
• stringa: vuota o di 1 carattere
• array: array vuoto o di un elemento
• elaborazioni con array: considerare valori estremi degli indici
• Triangoli
g identificati da vertici:
tre punti allineati
due punti coincidenti
tre punti coincidenti
triangolo rettangolo
un vertice nell’origine o sugli assi
• ….
IEC 61508-
61508-3: 9.3 Progettazione &
Sviluppo / Verifica del modulo
Inputs: specifiche di verifica modulo, codice sorgente, rapporto di
verifica codice
Compiti & Scopi: verifica della funzionalità e dell’integrità in funzione

della SIL, evidenziata dall’avverarsi delle reazioni desiderate e
dall’assenza di quelle indesiderate
Risultato: rapporto di verifica modulo, modulo verificato
Requisiti:
¾ Documentazione di tutti i risultati delle verifiche dei moduli
¾ Conservazione delle regole per la valutazione dei risultati (cfr.
programmazione della validazione)
IEC 61508-
A.5 Verifica & integrazione moduli
A.5 - Progettazione e sviluppo Software: Verifica ed integrazione dei moduli

software
ft
1 Verifica statistica C.5.1 --- R R HR
2 Analisi e verifiche dinamiche B.6.5 R HR HR HR
Tab. B.2
3 Registrazione ed analisi dati C.5.2 HR HR HR HR
4 Verifiche di funzione e “black box” B.5.1 HR HR HR HR
B.5.2
Tab. B.3
5 Verifiche della prestazione C.5.20 R R HR HR
Tab. B.6
6 Verifiche di interfaccia C.5.3 R R HR HR
Nota 1: il modulo SW e la verifica di integrazione sono attività di verifica (si veda tab. A.9)
Nota 2: tecniche e misure appropriate devono essere selezionate in base al livello di integrità di sicurezza.
* Una tecnica/misura numerata deve essere selezionata in base al livello di integrità di sicurezza
IEC 61508-
A.5 Verifica & integrazione moduli
¾ Metodi adeguati
g di verifica
¾ Verifica dati e risultati con registrazioni relative
¾ Verifica statistica che quantifichi la probabilità di guasto:
• Possibile solo con strumenti, per via dell’elevato numero di diverse
configurazioni di prova necessarie
• Normalmente non ci sono garanzie per alte probabilità di guasto
¾ Analisi dinamica:
• Verifica dell’integrazione HW-SW su un prototipo (B.6.5)
• Verifica del programma in running mode (tab
(tab. B
B.2)
2)
¾ Strumenti di verifica normalmente necessari a causa
della quantità di dati, analisi di codice
Verifica moduli SW
¾ Esecuzione di “Black-Box” Testing

• Verifica di tutte le ramificazioni e percorsi in un modulo
• Verifica di tutti i salti condizionati e routine in un modulo
• Le condizioni di ramificazione sono corrette? (ad es. ≥ o >)
• Prove con dati in tutto l’intervallo permesso
• Prove con dati nell’intervallo non permesso
• Verifica dell’integrità di variabili locali per interrupts e richiami di
subroutine
• Correzione di g guasti rilevati
¾ Metodi
• Walk-through con supporto di emulatori circuitali
• Operazioni real-time con breakpoints
¾ Documentazione (dell’esecuzione delle prove e dei risultati)
• Risultati e loro valutazione
Verifica Integrazione moduli SW
¾ Verifica integrazione
g moduli SW
• Principi di integrazione
• Tipi di prove da eseguire
• Casi di prova e dati di prova
• Criteri di prova
• Procedure per azioni correttive in caso di fallimento di una prova
¾ Documentazione (dell’esecuzione delle prove e dei

risultati)
IEC 61508
61508--3: Metodi & Tecniche –
B.2 Verifiche dinamiche
B.2 - Verifiche ed analisi dinamiche (menzionate nelle Tab. A.5 ed A.9)

1 Esecuzione di differenti "test cases” in relazione alle C.5.4 R HR HR HR
analisi di valori limite
2 Esecuzione di differenti "test cases” in relazione alle C.5.5 R R R R
previsioni di guasti
3 Esecuzione di differenti "test cases” in relazione alla

C.5.6 --- R R R
implementazione di guasti
4 Performance modelling C.5.20 R R R HR
5 Classi equivalenti e verifica con zona input limitata C.5.7 R R R HR
6 Verifiche in base alla struttura C.5.8 R R HR HR
Nota: l’analisi per le diverse configurazioni di prova è a livello del sottosistema ed è basato sulla specifica e/o specifica
e codice
IEC 61508
61508--3: Metodi & Tecniche –
B.3 Verifica delle funzioni
B.3 - Verifiche funzionali e “black box” (menzionata nelle Tab. A.5, A.6 e A.7)
1 Esecuzione di differenti "test cases” in relazione ai B.6.6.2 --- --- R R
diagrammi di causa/effetto
2 Prototipazione C.5.17 --- --- R R
3 Analisi valori limite C.5.4 R HR HR HR

4 Classi equivalenti e verifica partizione input C.5.7 R HR HR HR
5 Simulazione di processo C.5.18 R R R R
Nota 1: l’analisi
l analisi per le diverse configurazioni di prova è a livello del sistema del software ed è basato solo sulla
specifica
Nota 2: la completezza della simulazione dipende dal livello di integrità della sicurezza, dalla complessità ed
applicazione
IEC 61508
61508--3: Metodi & Misure – B.6
Verifica delle prestazioni
B.6 – Verifica delle prestazioni (menzionata nelle Tab. A.5 ed A.6)

1 Prove di stress C.5.21 R R HR HR
2 Tempi di risposta e utilizzazione della memoria C.5.22 HR HR HR HR
3 Requisiti di prestazione C.5.19 HR HR HR HR

Verifica Integrazione HW + SW
¾ Verifica integrazione HW + SW
• Principi
p di integrazione
g
• Tipi di prove da eseguire
• Ambiente di prova, strumenti, configurazione e programmi
• Casi di prova e dati di prova
• Criteri di prova
• Procedure per azioni correttive in caso di fallimento di una prova
• Analisi dell’impatto in caso di modifiche
¾ Documentazione (dell’esecuzione delle prove e dei

risultati)
IEC 61508
61508--3: Misure & tecniche – A6
Integrazione PE
A.6 - Integrazione di elettronica programmabile (Hardware e Software)

1 Verifica funzionale e “black box” B.5.1 HR HR HR HR
B.5.2
Tab. B.3
2 Prove di prestazione C.5.20 R R HR HR
Tab. B.6
Nota 1 – L’integrazione elettronica programmabile è un’attività di verifica (si veda tab. A.9)
Nota 2 - Misure e tecniche appropriate devono essere selezionate in base al livello di integrità di sicurezza
* È necessario selezionare un certo numero di misura e tecnica secondo il livello di integrità di sicurezza
IEC 61508-
61508-3: Misure & tecniche – A8
Modifica
A.8 – Modifiche

1 Analisi impatto C.5.23 HR HR HR HR
2 Nuova verifica dei moduli software modificati C.5.23 HR HR HR HR
3 Nuova verifica dei moduli software interessati C.5.23 R HR HR HR
4 Rivalidazione dell’intero sistema C.5.23 --- R HR HR
5 Gestione della configurazione software C.5.24 HR HR HR HR
6 Registrazione ed analisi dati C.5.2 HR HR HR HR
* Un certo numero di tecnica/misura deve essere selezionato in base al livello di integrità di sicurezza
Misure e tecniche appropriate devono essere selezionate in base al livello di integrità di sicurezza
IEC 61508-
61508-3: Misure & tecniche – A7
Validazione
A.7 – Validazione del software rispetto alla sicurezza

1 Verifica statistica C.5.1 --- R R HR
2 Simulazione/modellizzazione Tab. B.5 R R HR HR
3 Verifica funzionale e “black box” B.5.1 HR HR HR HR
B.5.2
Tab. B.3
* Un certo numero di tecnica/misura deve essere selezionato in base al livello di integrità di sicurezza
Nota: Misure e tecniche appropriate devono essere selezionate in base al livello di integrità di sicurezza
IEC 61508
61508--3: Misure & tecniche – B5
modellizzazione
B.5 – Modellizzazione

1 Diagrammi flusso dati C.2.2 R R R R
2 Diagrammi di transizione di stato B.2.3.2 --- R HR HR
3 Metodi formali C.2.4 --- R R HR
4 Modellizzazione esecuzione C.5.20 R HR HR HR
5 Reti Time Petri B.2.3.3 --- R HR HR
6 Esecuzione di prototipi C.5.17 R R R R
7 Diagrammi di struttura C23
C.2.3 R R R HR
Nota: se una tecnica specifica non è elencata nella tabella, non deve essere supposta la sua mancata considerazione.
Bisogna conformarsi a questa norma
* Misure e tecniche appropriate devono essere selezionate in base al livello di integrità di sicurezza
IEC 61508-
61508-3: Misure & tecniche –
A.10 Valutazione della sicurezza
A.10 – Valutazione sicurezza funzionale
Valutazioni / tecniche* Rif. SIL1 SIL2 SIL3 SIL4

1 Checklists B.2.5 R R R R
2 Tabelle decisionali/della verità C.6.1 R R R R
3 Complessità metrica del software C.5.14 R R R R
4 Analisi guasti Tab. B.4 R R HR HR
5 Analisi dei guasti per causa comune di diversi software C.6.3 --- R HR HR
(se diversi software sono effettivamente usati)
6 Diagrammi di affidabilità C.6.5 R R R R
* Misure e tecniche appropriate devono essere selezionate in base al livello di integrità di sicurezza
IEC 61508
61508--3: Misure & tecniche –
B.4 Analisi dei rischi
B.4 – Analisi dei rischi
Valutazioni / tecniche* Rif. SIL1 SIL2 SIL3 SIL4

1a Diagrammi causa/effetto B.6.6.2 R R R R
1b Analisi albero eventi B.6.6.3 R R R R
2 Analisi albero guasti B.6.6.5 R R HR HR
3 FMEDA B.6.6.4 R R HR HR
5 Simulazione Monte-Carlo C.6.6 R R R R
* Misure e tecniche appropriate devono essere selezionate in base al livello di integrità di sicurezza. Tecniche e misure
alternative o equivalenti sono indicate da una lettera successiva al numero. Solo una delle tecniche e misure
alternative o equivalenti deve essere soddisfatta
soddisfatta.
IEC 61508-
61508-3: Riassunto in 12 punti
1. QMS con g gestione della modifica da p parte di p

personale
qualificato
2. Modello di sviluppo documentato
3. Specifica requisiti strutturati con interfacce
documentate HW-SW
4. Modellizzazione con metodi strutturati
5 Progetto strutturato
5.
Sistema, sottosistema, modulo, funzione/scopo
Modello per le verifiche on-line e off-line
Verifiche su tutti i livelli
IEC 61508-
6. Linguaggi di Programmazione, Strumenti, Sistemi

O
Operativi
ti i
P: livello elevato, strong typing, linee guida
S: IDE (integrato), supporto di verifica, metrica SW, analisi
statiche & dinamiche
O: solo se necessario, “proven in use”, possibilmente senza
interrupt
7. Codifica
Programmazione
g difensiva a seguito
g a direttive di
programmazione
Ridondanza dati (CRC…) e funzioni (diversità…)
Monitoraggio SW ed HW (logico, cronologico)
Codice deducibile dalla specifica dei requisiti utilizzando la
documentazione (rintracciabilità)
IEC 61508-
8. Verifica
B
Basata
t su specifica
ifi requisito
i it e progetto
tt
Da piccola (funzione) a grande (sottosistema)
Almeno “black box”
Test di sollecitazione e verifiche temporali
Usare strumenti di verifica
9. Validazioni in condizioni reali
Così come in condizioni estreme (temperatura, volume dati)
Anche con input non corretto (prove simulate)
10 Documentazione per ciascuno scopo: manuale di produzione ed
10.
installazione, ivi inclusi i dati di configurazione, manuale utente, modifica
e smaltimento
11. Ispezione formale di documenti importanti
12. Valutazione indipendente di sicurezza funzionale
IEC 61508
61508--3: Applicazione per
piccoli progetti
¾ Fusione di fasi differenti

¾ Fusione di differenti documenti
¾ Progettazione basata su progetti conclusi con successo, il che
significa riutilizzo di:
• Strutture di documenti, linee guida/direttive di documenti
• Linguaggi di programmazione, ambienti di sviluppo…
• Progetto, verifica, documentazione, strumenti
EN 13849-
13849-1:
Requisiti di sicurezza del software
Modello a V semplificato del ciclo di vita di sicurezza del software
Specifica delle
funzioni di sicurezza Specifica del software Software validato
Validazione Validazione
correlato alla sicurezza
Progettazione
Prove di integrazione
del sistema
Progettazione
Prove del modulo
del modulo
Risultato
Verifica Codifica
EN 13849-
13849-1:
SOFTWARE INCORPORATO CORRELATO ALLA SICUREZZA (SRESW)
Per il SRESW per componenti con PLr da a fino a d, si devono applicare le

misure di base seguenti:
¾ ciclo di vita di sicurezza del software con attività di verifica e validazione;
¾ documentazione di specifica e progettazione;
¾ progettazione modulare e strutturata e codifica;
¾ controllo dei guasti sistematici (vedere punto G.2);
¾ in caso di utilizzo di misure basate sul software per il controllo di guasti
hardware casuali,
casuali verifica della corretta implementazione;
¾ prove funzionali, per esempio prove a scatola nera;
¾ attività del ciclo di vita di sicurezza del software appropriate dopo le
modifiche.
EN 13849-
13849-1:
SOFTWARE INCORPORATO CORRELATO ALLA SICUREZZA (SRESW)

Per il SRESW per componenti con PLr c oppure d, d si devono applicare le
misure aggiuntive seguenti:
¾ sistema di gestione del progetto e della qualità comparabile per esempio a
IEC 61508 o ISO 9001;
¾ documentazione di tutte le attività pertinenti durante il ciclo di vita di
sicurezza del software;
¾ specifica strutturata con progettazione e requisiti di sicurezza;
¾ utilizzo di linguaggi di programmazione idonei e strumenti computerizzati
affidabili;
¾ programmazione modulare e strutturata, separazione in software non
correlato alla sicurezza, dimensioni limitate dei moduli con interfacce
interamente definite, utilizzo di norme di progettazione e di codifica;
¾ verifica della codifica mediante walk-through/revisione con analisi del flusso
di controllo;
¾ prove funzionali estese, per esempio prove a scatola grigia, prove
prestazionali o simulazione; Sicurezza Funzionale 67
EN 13849-
13849-1:
SOFTWARE APPLICATIVO CORRELATO ALLA SICUREZZA (SRASW)
Per il SRASW per componenti con PLr da a fino a e, si devono applicare le

misure di base seguenti:
¾ ciclo di vita dello sviluppo con attività di verifica e validazione;
¾ documentazione di specifica e progettazione;
¾ programmazione modulare e strutturata;
¾ prove funzionali;
¾ attività di sviluppo appropriate dopo le modifiche.
EN 13849-
13849-1:
Per il SRASW per componenti con PLr da c fino a e, sono richieste o

raccomandate le misure aggiuntive seguenti con efficacia crescente (efficacia
inferiore per PLr c, efficacia media per PLr d, efficacia superiore per PLr e).
a) La specifica del software correlato alla sicurezza deve essere sottoposta a

revisione e messa a disposizione di ogni persona coinvolta nel ciclo di vita
e deve contenere la descrizione di:
1) funzioni di sicurezza con PL richiesto e modalità di funzionamento associate;
2) criteri prestazionali, per esempio tempi di reazione;
3) architettura
hit tt h d
hardware con interfacce
i t f di segnale
l esterne;
t e
4) rilevamento e controllo di guasti esterni.
EN 13849-
13849-1:
b) La selezione di strumenti, librerie, linguaggi:
1) strumenti idonei affidabili: Si devono utilizzare caratteristiche tecniche in grado di
rilevare condizioni che potrebbero causare errori sistematici (come errato
abbinamento di tipo di dati, ambigua allocazione di memoria dinamica,
interfacce dichiarate incomplete, ricorsione, aritmetica dei puntatori). I controlli
dovrebbero essere effettuati soprattutto durante la compilazione e non solo
durante l’esecuzione. Gli strumenti dovrebbero utilizzare subset del linguaggio o
linee guida per la codifica o almeno supervisionare o guidare lo sviluppatore che
li utilizza;
2) quando ragionevole o praticabile, si dovrebbero utilizzare librerie di blocchi di
funzioni (FB) validate – librerie legate alla sicurezza fornite dal produttore dello
strumento ((altamente raccomandate p per PL = e)) o librerie specifiche
p
dell’applicazione validate e in conformità alla presente parte della ISO 13849;
3) si dovrebbe utilizzare un idoneo subset LVL adatto per un approccio modulare,
per esempio un subset accettato di linguaggi IEC 61131-3. I linguaggi grafici
(schema di blocchi di funzioni, diagramma a scala) sono altamente
raccomandati.
EN 13849-
13849-1:
c) La progettazione del software deve presentare:

1) metodi semi-formali
semi formali per descrivere i dati e il flusso di controllo,
controllo per esempio
diagramma di stato o grafico di flusso del programma;
2) programmazione modulare e strutturata prevalentemente realizzata mediante
blocchi di funzioni derivanti da librerie di blocchi di funzioni validate legate alla
sicurezza;
3) blocchi di funzioni con dimensioni di codifica limitate;
4) esecuzione dei codici all’interno del blocco di funzioni che dovrebbe avere un
punto di ingresso e un punto di uscita;
5) modello di architettura a tre stadi, Ingressi ÆElaborazioneÆUscite (vedere
figura 7 e appendice J);
6) assegnazione di un’uscita di sicurezza a un’unica posizione di programma; e
7) utilizzo di tecniche per rilevare guasti esterni e per la programmazione difensiva
all’interno dei blocchi di ingressi, elaborazione e uscite che determini uno stato
di sicurezza.
EN 13849-
13849-1:
d) Quando un SRASW e un non-SRASW sono combinati in un componente:

1) SRASW e non-SRASW
non SRASW devono essere codificati in blocchi di funzioni differenti
con collegamenti dati ben definiti;
2) non deve esserci alcuna combinazione logica di dati legati alla sicurezza e non
legati alla sicurezza che potrebbe portare a una declassazione dell’integrità dei
segnali legati alla sicurezza, per esempio, combinando segnali legati alla
sicurezza e segnali non legati alla sicurezza mediante un "OR" logico il cui
risultato controlli i segnali legati alla sicurezza.
e) L’implementazione/codifica software:
1) il codice deve essere leggibile, comprensibile e poter essere sottoposto a prova
e, a causa di questa simbologia si dovrebbero utilizzare variabili (invece di
indirizzi hardware espliciti);
2) si devono utilizzare linee guida di codifica giustificate o accettate (vedere anche
appendice J);
3) si dovrebbero utilizzare i controlli dell’integrità dei dati e della plausibilità (per
esempio controlli di intervalli) disponibili nel livello applicativo (programmazione
difensiva);
EN 13849-
13849-1:
4) il codice dovrebbe essere sottoposto a prova mediante simulazione;
5) la verifica dovrebbe avvenire mediante controllo e analisi del flusso di dati per
PL = d oppure e.
f) Le prove:
1) il metodo di validazione appropriato è costituito da prove a scatola nera del
comportamento funzionale e dei criteri prestazionali (per esempio prestazioni a
tempo);
2) per PL = d oppure e, si raccomanda l’esecuzione del caso di prova dall’analisi
dei valori limite;
3) si raccomanda una pianificazione delle prove che dovrebbe includere casi di
prova con i criteri di completamento e gli strumenti richiesti;
4) le prove degli I/O devono garantire che i segnali legati alla sicurezza siano
utilizzati correttamente all’interno del SRASW.
EN 13849-
13849-1:
g) La documentazione:
1) tutte le attività di modifica e relative al ciclo di vita devono essere documentate;
2) la documentazione deve essere completa, disponibile, leggibile e comprensibile;
3) la documentazione dei codici all’interno del testo sorgente deve contenere
intestazioni dei moduli con entità legale, descrizione funzionale e degli I/O,
versione e versione delle librerie di blocchi di funzioni utilizzate e sufficienti
commenti delle reti/righe di dichiarazione e affermazione.
PARAMETRIZZAZIONE BASATA SU SOFTWARE

L’integrità di tutti i dati utilizzati per la parametrizzazione deve essere mantenuta. Ciò si
deve ottenere applicando misure per:
¾ controllare l’intervallo di ingressi validi;
¾ controllare la corruzione dei dati prima della trasmissione;
¾ controllare gli effetti degli errori dal processo di trasmissione dei parametri;
¾ controllare gli effetti di una trasmissione dei parametri incompleta; e
¾ controllare gli effetti di guasti e avarie hardware e software dello strumento utilizzato
per la parametrizzazione.

Corso SIL Valvoliere IMQ - Progettazione SW

Caricato da

Informazioni sul documento

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

Corso SIL Valvoliere IMQ - Progettazione SW

Caricato da

Copyright:

Formati disponibili

Sicurezza Funzionale per

¾ Tipi di SW secondo IEC 61508

Terminologia (tipologie di SW)

LIMITED VARIABILITY LANGUAGE (LVL)

FULL VARIABILITY LANGUAGE (FVL)

¾ Il SW con zero dif

La gestione della versione deve includere tra l’altro:

1. Specifiche dei requisiti di sicurezza SW

IEC 61508: Sequenze della

Sequenza in base alla 61508-6:

Integrazione (HW e SW)

Architettura Architettura Verifica integrazione

9.3 Par. Norma

Efficacia di tecniche e misure

Mandatory La tecnica o misura è richiesta e deve essere usata il più efficacemente

Low La tecnica o misura deve essere usata fino al p

Sistema di sicurezza Sistema non di sicurezza

Sistema di sicurezza HW HW non di sicurezza

SW di sicurezza SW non di sicurezza

SW correlato alla sicurezza

Funzioni correlate alla sicurezza:

2. Requisiti integrità di sicurezza SW

2a Metodi semi-formali Tab. B.7 R R HR HR

Metodi formali, per

5 Reti Time-Petri B.2.3.3 R R HR HR

¾ Controllo di flusso del pprogramma

¾ Stuck-at ‘1’ / ‘0’

Esempio: Galpat Test

Step 1. Write: Ci←0 for i=0,1,…n-1

n: numero delle celle di memoria

IEC 61508-3: Misure & Tecniche –

IEC 61508-3: Misure & Tecniche –

IEC 61508-3: 9.3 Progettazione e sviluppo

A.2 – Progettazione e sviluppo Software: Progettazione architettura SW

A.2 – Progettazione e sviluppo Software: Progettazione architettura SW

A.3 – Progettazione e sviluppo del Software: strumenti di supporto e linguaggi

Linguaggio di programmazione SIL 1 SIL 2 SIL 3 SIL 4

A.4 – Progettazione e sviluppo del Software: progetto dettagliato

Linguaggio di programmazione: alto livello, altamente standardizzato

Sistema operativo: solo se necessario, preferibilmente senza interrupt

B.9 – Approccio modulare

Tecniche / misure* Rif. SIL1 SIL2 SIL3 SIL4

B.1 – Regole di progetto e codifica SW (menzionata nella Tab. A 4)

Vantaggi per lo sviluppo del SW:

A.4 - Progettazione e sviluppo Software: Programmazione di dettaglio

Tecniche / misure* Rif. SIL1 SIL2 SIL3 SIL4

¾ Ridurre la complessità del codice ⇒ minor possibilità di bachi e di

¾ Test esaustivo ((esecuzione per

¾ Program testing can be used to show the presence of bugs, but

¾ È cruciale la scelta di opportuni

¾ In base a che cosa si determinano i casi di test?

Compiti & Scopi: verifica della funzionalità e dell’integrità in funzione

Risultato: rapporto di verifica modulo, modulo verificato

A.5 - Progettazione e sviluppo Software: Verifica ed integrazione dei moduli

¾ Esecuzione di “Black-Box” Testing

Verifica Integrazione moduli SW

¾ Documentazione (dell’esecuzione delle prove e dei

B.2 - Verifiche ed analisi dinamiche (menzionate nelle Tab. A.5 ed A.9)

3 Esecuzione di differenti "test cases” in relazione alla

3 Analisi valori limite C.5.4 R HR HR HR

B.6 – Verifica delle prestazioni (menzionata nelle Tab. A.5 ed A.6)

Tecniche / misure* Rif. SIL1 SIL2 SIL3 SIL4

3 Requisiti di prestazione C.5.19 HR HR HR HR

¾ Documentazione (dell’esecuzione delle prove e dei