EMB_59

73 / 84

73
ANALISI CODICE | SOFTWARE
EMBEDDED 59 • FEBBRAIO • 2016
lavoro, analisi e test del codice atti a identificarle,
diventa ora come non mai fondamentale,
soprattutto considerando la complessità
crescente e la varietà delle architetture hardware
e dei protocolli di comunicazione.
Uno dei problemi maggiori nella scrittura e
analisi del software, nell’attuale quadro di
complessità tecnologica, resta garantire la
conformità del codice con le norme e gli standard
di safety stabiliti dalle principali associazioni
e consorzi di costruttori, come le linee guida
definite da
MISRA C, ad esempio,
viene introdotto come un “limitato sottoinsieme
di un linguaggio strutturato standardizzato”
come richiesto dalle linee guida MISRA 1994 per
i sistemi automotive sviluppati per soddisfare i
requisiti SIL (Safety Integrity Level) 2 e oltre.
MISRA C, nella versione aggiornata del 2004
(MISRA C: 2004, o MISRA C2) si identifica come
“le linee guida per l’uso del linguaggio C nei
sistemi critici”. Una versione ancora più recente
è MISRA C: 2012, pubblicato nel marzo 2013 e
contenente riferimenti allo standard ISO 26262.
Quest’ultimo, in particolare, pubblicato nel 2011
è in crescente diffusione a livello internazionale,
e vuol rappresentare una risposta più efficace
all’esplosione esponenziale delle linee di codice
(100 milioni) nei sistemi automotive, che rende
sostanzialmente impossibile ottenere una
perfetta qualità. ISO 26262 è infatti incentrato
su un modello risk-based, che
valutando il rischio residuo a
livello qualitativo, determina le
misure da attuare per ridurlo
quanto ragionevolmente possibile
(ALARP - as low as reasonably
practicable). In vari casi, per
analizzare la conformità del codice
con questi standard, i moderni tool
sono d’ausilio ai team di sviluppo
nella determinazione delle migliori
pratiche di programmazione e nella
previsione di eventuali errori e
difetti del software.
Oltre ai vincoli di safety, da tenere
sotto controllo sono i requisiti di
security, seguendo le relative linee
guida. Questi requisiti possono
includere l’attuazione di misure di ’hardening’
per irrobustire la sicurezza e riservatezza delle
comunicazioni wireless, come quelle tramite
reti radiomobili e Bluetooth, o garantire la
solidità del software automotive e del sistema di
infotainment del veicolo contro attacchi mirati
a destabilizzarlo o a prenderne il controllo. Un
altro aspetto delicato attiene poi alla cifratura
dei dati che accedono alle rete interna del veicolo.
In tutte queste operazioni, oggi, disporre di una
’cassetta degli attrezzi’ equipaggiata con i corretti
strumenti software risulta di valido aiuto nelle
attività di analisi del codice sorgente, di controllo
del suo funzionamento in tempo reale, o nelle
prove di simulazione su un determinato target
hardware.
Eseguiti tutti i controlli relativi ai requisiti
di safety e security, resta poi da verificare che
il codice soddisfi anche tutti i requisiti base di
qualità e affidabilità richiesti per il software
embedded in generale. Infine va aggiunto che,
di certo, l’instaurazione di buone pratiche, e
dell’abitudine dei team di progettazione ad
eseguire le varie attività di analisi dei requisiti
di safety, security e qualità del codice embedded
in ambienti IDE (integrated development
environment) con tool condivisi, concorrono a
efficientare e velocizzare il processo di sviluppo
e produzione del codice, in linea con le attuali
esigenze di business e time-to-market dei
prodotti.
Fig. 3 - PRQA da lungo tempo fornisce tool suite per l’ana-
lisi e prevenzione dei difetti del codice embedded nei sistemi
safety-critical