81 / 92
81
EMBEDDED
66 • NOVEMBRE • 2017
SAFETY SECURITY |
SOFTWARE
sviluppo di un prodotto dovrebbe integrare azioni
di rafforzamento della protezione a tutti i livelli e
À
i già severi requisiti di sicurezza funzionale.
Cosa succede quando l’attenzione è rivolta so-
lamente sullo sviluppo del software? Più in par-
ticolare, quali sono le scelte possibili per uno
sviluppatore con il compito di programmare
un’applicazione safety critical e che deve garanti-
re che quell’applicazione sia anche protetta, oltre
che sicura? Supponendo che siano state applicate
tutte le possibili misure nei requisiti e fasi di pro-
gettazione, è il momento di scegliere la modalità
] À
elevata integrità.
Approccio “safety critical”
La sicurezza funzionale fa riferimento a due prin-
cipali famiglie di standard correlate con l’organiz-
zazione del ciclo di vita del software: IEC61508 e
gli standard derivati e DO178B/C con i documenti
correlati, come il DO330.
IEC61508 riguarda la sicurezza funzionale di si-
stemi safety-related di tipo elettrico, elettronico ed
elettronico programmabile (EEPE).
Esso copre rischi causati da avarie delle funzioni
-
to a qualsiasi sistema safety-related che contenga
un dispositivo EEPE, il suo campo d’azione è piut-
tosto ampio. Quasi tutti gli standard di sicurezza
dei principali settori non collegati con l’Avionica
sono derivati da IEC61508.
DO178C e i documenti collegati, DO330, DO331,
DO332 e DO333, formano gli standard per ap-
plicazioni avioniche. DO178C è obbligatoria per
qualsiasi progetto di avionica commerciale che vo-
À
}}
DO178C è più focalizzato sul software rispetto
IEC61508; il livello di sicurezza del software (o
IDAL – item development assurance level) è de-
terminato dall’analisi del rischio e dalla valutazio-
ne della sicurezza e mappato su cinque livelli, da
} K
À U K
U
`
Y<
À
criticità del codice è stata ampiamente analizzata
9 À
À
sviluppo.
Safety integrity levels (SIL) in IEC61508, Automo-
tive SIL (ASIL) in ISO26262, software SIL (SSIL)
in EN50128 o IDAL in DO178C, sono tutti esempi
K
9 À
del rischio necessaria per una funzione, in base
9 À
da intraprendere per assicurare che tale livello sia
raggiunto.
Quasi tutti gli standard di sicurezza funzionale
riconosciuti prescrivono l’adozione di standard di
À
!7"
!
-
bene non ci sia alcuna indicazione autorevole su
9
À
-
rezza funzionale, uno dei principali riferimenti in
questo ambito è MISRA C.
ISO26262-6 riconosce per il linguaggio C che MI-
SRA C copre molti dei metodi richiesti per il sof-
tware unit design e l’implementazione, e la sua
diffusione raggiunge tutte le principali applicazio-
ni safety critical, quali macchinari, medicali, ener-
gia nucleare e ferroviario.
Con DO178B/C, la situazione non è molto diver-
\
À
-
zione e documentazione del processo di sviluppo
del software. Il set base della documentazione e
lifecycle artefacts richiesti comprende una ricca e
À
À
À
!
À
?7!_} À
sottoinsieme del linguaggio di destinazione (tar-
get). Questo evita o limita l’utilizzo di funzioni e
costrutti che potrebbero portare a un comporta-
Fig. 1 - Stima del numero dei dispositivi IoT in-
stallati per settore applicativo (Fonte: Business
Insider Intelligence)