73 / 84
73
EMBEDDED
MAGGIO
SAFETY&SECURITY |
SOFTWARE
di un prodotto dovrebbe integrare azioni
di rafforzamento della protezione a tutti
i livelli e consentire loro di coesistere in
À
8
-
siti di sicurezza funzionale.
Ma cosa succede quando l’attenzione
è posta solamente sullo sviluppo del
software? Più in particolare, quali sono
le scelte possibili per uno sviluppatore
con il compito di programmare un’appli-
cazione safety critical e con la necessità
per essere certo che quell’applicazione
sia anche protetta, oltre che sicura?
Supponendo che siano state applicate
tutte le possibili misure nei requisiti e
fasi di progettazione, è il momento di
scegliere la modalità per tradurli in un
, À
o e di elevata
integrità.
Approccio “safety critical”
La sicurezza funzionale prevede due principali fa-
miglie di standard cui fare riferimento e che hanno
a che fare con l’organizzazione del ciclo di vita del
software: IEC61508 oltre agli standard derivati, e
DO178B/C con documenti correlati, come il DO330.
IEC61508 riguarda la sicurezza funzionale di si-
stemi safety-related di tipo elettrico, elettronico e
programmable electronic (EEPE).
Esso copre rischi causati da avarie delle funzioni
% "
G
a qualsiasi sistema safety-related che contenga un
dispositivo EEPE, la sua portata è piuttosto ampia.
Quasi tutti gli standard di sicurezza dei principali
settori non collegati con l’Avionica sono derivati da
IEC61508. DO178C, con i suoi documenti collegati,
DO330, DO331, DO332 e DO333 formano gli stan-
dard per applicazioni avioniche. DO178C è obbliga-
toria per qualsiasi progetto di avionica commercia-
À
B++%
DO178C è più focalizzato sul software rispetto
IEC61508; il livello di sicurezza del software (o
IDAL - item development assurance level) è deter-
minato dall’analisi del rischio e dalla valutazione
della sicurezza e mappato su cinque livelli, da A (ca-
À 1 E 0
1%
Per applicazioni sa-
C
À
8
@
stata ampiamente analizzata e ci sono metodi stan-
À
À
per gestire il processo di sviluppo. Safety integrity
levels (SIL) in IEC61508, Automotive SIL (ASIL) in
ISO26262, software SIL (SSIL) in EN50128 o IDAL
in DO178C, sono tutti esempi dello stesso concetto
À
per una funzione, in base all’analisi di rischio e de-
cidere le azioni
À
da intraprendere per assi-
curare che tale livello sia raggiunto.
Quasi tutti gli standard di sicurezza funzionale
riconosciuti prescrivono l’adozione di standard di
À
H)5
. Seb-
bene non ci sia alcuna indicazione autorevole su
À
-
za funzionale, uno dei principali riferimenti in que-
sto ambito è MISRA C.
ISO26262-6 riconosce per il linguaggio C che
MISRA C copre molti dei metodi richiesti per il
software unit design e l’implementazione, e la sua
diffusione raggiunge tutte le principali applicazioni
safety critical, quali macchinari, medicali, energia
nucleare e ferroviario.
Con DO178B/C, la situazione non è molto diversa.
F
À
-
zione e documentazione del processo di sviluppo
del software. Il set base della documentazione e
lifecycle artefacts richiesti comprende una ricca e
À
À @
%
Fig. A – Numero stimato di dispositivi IoT installati suddivisi
per settore applicativo (fonte: Business Insider Intelligence)