Embedded

EMBEDDED

56 • maggio • 2015

software

CODING GUIDELINE

hanno avviato la procedura di impostazione del-

le condizioni sotto le quali permettere specifiche

deroghe dalla piena conformità a MISRA.

La spinta a questo lavoro è quella di definire un

set di deroghe dalle regole che siano strettamen-

te vincolate allo scopo. Un importante primo

stadio è quello di categorizzare le motivazioni di

massima per una deviazione dalla regola di non

conformità.

tegorizzazione del

le ragioni di deroga

Suddividendo le deviazioni nelle seguenti cate-

gorie, le difficoltà pratiche relative alla confor-

mità appaiono più evidenti. Inoltre, questa ca-

tegorizzazione vigila sulle deroghe inadeguate

e sull’indebolimento degli intenti della codifica

standard.

Performance:

potrebbe sembrare strano e non

intuitivo suggerire le prestazioni come motivo

per non seguire delle buone pratiche di codifica,

ma la seguente situazione presa dalla realtà è la

dimostrazione dell’esigenza:

Quale parte del sistema di controllo del

motore del veicolo, una variabile di tem-

porizzazione necessita di essere accu-

mulata a intervalli regolari. Il codice,

correttamente formulato per soddisfare

MISRA-C:2012 Rule 10.6 (value not to be

assigned to a wider type, legge:

extern uint16_t qty, time_step;

uint32_t prod = ( uint32_t ) qty * ( uint32_t

) time_step;

I cast assicurano che gli operandi 16-bit

non andranno in overflow nella moltipli-

cazione 32-bit per questo compiler. Tut-

tavia, il compiler esegue questa opera-

zione utilizzando la modalità “shift and

add” di long multiplication piuttosto che

la modalità IMUL (signed multiplica-

tion) con cui è equipaggiata. I fornitori

di compiler anno chiarito che la modali-

tà IMUL si verifica soltanto in conversio-

ni implicite, richiedendo all’espressione

di leggere:

uint32_t prod = qty * time_step; // deviate

from Rule 10.6

Permettendo una implicita conversione

in questo caso, il funzionamento del ci-

clo IMUL singolo clock è garantito, in-

vece che l’esecuzione dei ~100 peggiori

casi di clock cycle del precedente, quindi

giustificando una deviazione controllata

sulla base delle performance.

Codice esterno (terze parti):

questa catego-

ria include librerie comuni, codice autogenerato,

e moduli di codice interno ereditato o anche solo

una funzione complessa che comprenda un al-

goritmo di applicazione chiave. I maintainer di

librerie di dominio pubblico, dato il loro ampio

ambito di applicazione, raramente hanno moti-

vazione ad adeguarsi a MISRA o ad altri stan-

dard di codifica. Il Codice autogenerato, a meno

che non soddisfi uno standard di sicurezza fun-

zionale come ISO 26262, intrinsecamente con-

terrà probabilmente delle violazioni a MISRA.

Il codice ereditato potrebbe predatare l’adozio-

ne di MISRA nel progetto. L’analisi di impatto

di possibili rifacimenti per adeguarsi alle re-

gole MISRA potrebbe essa stessa essere causa

di preoccupazioni. Il safety case in tutte queste

situazioni si basa sulla dipendenza “qualificato

attraverso l’uso” in combinazione con altre spe-

cifiche misure di qualità.

Build Configuration:

una caratteristica pe-

culiare delle applicazioni dei fornitori automo-

bilistici è quella di rendere disponibile molte

varianti di una singola base di codice in funzio-

ne delle necessità del cliente. Piuttosto che un

controllo a livello di generazione di queste con-

segne, meccanismi di configurazione vengono

distribuiti per controllare l’esecuzione delle spe-

cifiche funzionalità per ogni variante. Di conse-

guenza, l’adeguamento a MISRA può risentirne

in termini di ridondanza del codice, invarianza

delle espressioni, e questioni complessivamente

collegate.

Accesso all’hardware:

al fine di accedere ai

registri, risolvere interrupt di controllo e memo-

ria assoluta, gli sviluppatori embedded devono