ISO 26262 nella pratica — Cosa significa davvero ASIL-B per il codice C embedded

Chi lavora nel settore automotive conosce i timbri su ogni capitolato: QM, ASIL-A, ASIL-B, ASIL-C, ASIL-D. La sigla sta per « Automotive Safety Integrity Level » e proviene dall'ISO 26262 — la norma per la sicurezza funzionale dei veicoli stradali. Tra QM e ASIL-D si estende un universo di carichi di processo, volume documentale e costi di sviluppo.

Nella pratica, ASIL-B è il livello più frequente per le centraline in produzione di serie. Centraline motore, elettronica freni, pre-elaborazione videocamera, gestione batteria — molto di tutto questo è ASIL-B. Ed è proprio qui che le cose diventano concrete per lo sviluppatore C.

Questo articolo descrive cosa ASIL-B ha realmente significato nei progetti a cui ho partecipato — al di là delle citazioni della norma. Niente teoria, ma le difficoltà pratiche e ciò che conta durante un audit.

Cosa richiede ASIL-B dalla norma

L'ISO 26262-6 (Product Development at the Software Level) definisce tabelle con « highly recommended », « recommended » e « no recommendation » per ogni attività e livello ASIL. Per ASIL-B significa in sintesi:

• Regole di codifica: MISRA-C è praticamente obbligatorio (tabella 1 della norma: « highly recommended »)
• Analisi statica del codice: highly recommended
• Revisione del codice: highly recommended, con revisori qualificati
• Test unitari con branch coverage: highly recommended (lo statement coverage da solo non basta)
• Test di integrazione: highly recommended
• Iniezione di guasti: recommended
• Programmazione difensiva: highly recommended

E — importante — ogni strumento utilizzato che possa influenzare il codice (compilatore, generatore di codice, framework di test) deve essere qualificato o classificato secondo ISO 26262-8. Ne riparlerò più avanti.

MISRA-C: il guardiano sottovalutato

MISRA-C non è nemico dello sviluppatore C — anche se le circa 170 regole e direttive dell'attuale MISRA-C:2012 all'inizio sembrano schiaccianti. La maggior parte delle regole è semplicemente ragionevole: niente conversioni implicite, niente goto all'indietro, niente shadowing di variabili, niente allocazione dinamica.

Ciò che rende difficile la cosa nella pratica è altro: MISRA distingue tra Required, Advisory e Mandatory. E ogni deroga richiede una deviation formale — un caso singolo motivato per iscritto, rivisto e firmato dal responsabile della sicurezza.

« In un progetto avevamo circa 400 deviation alla chiusura. Ognuna richiedeva una giustificazione, un'analisi dell'impatto sulla sicurezza e una controfirma. Non è burocrazia — è vero lavoro. »

Trappole tipiche:

• Regola 10.x (conversioni implicite): quasi inevitabile nelle manipolazioni di bit. Ogni riga del tipo uint8_t a = b & 0x0F; viene esaminata criticamente.
• Regola 11.x (conversioni di puntatori): l'accesso hardware richiede quasi sempre cast di puntatori. Risolvibile, ma va documentato.
• Regola 21.3 (niente memoria dinamica): spesso sorprendente — anche strutture statiche con puntatori vengono talvolta segnalate se il ciclo di vita non è documentato con cura.

Raccomandazione pratica

Chi pianifica codice ASIL-B da zero deve considerare MISRA fin dall'inizio. Rendere retroattivamente conforme MISRA un codice esistente costa da tre a cinque volte di più che farlo bene fin dall'inizio. Strumenti come Polyspace, LDRA o Helix QAC verificano automaticamente — ma nessuna regola è verificabile al 100% in automatico. Alcune regole richiedono giudizio umano.

L'analisi statica è più di un segno di spunta verde

La norma richiede analisi statica — spesso fraintesa come « eseguire il checker MISRA ». In realtà ISO 26262 intende molto di più:

• Control-Flow Analysis: trova tutti i percorsi di codice irraggiungibili.
• Data-Flow Analysis: trova variabili usate ma non inizializzate.
• Interpretazione astratta: trova potenziali overflow di array, divisioni per zero, overflow di interi.
• Analisi semantica: trova race condition negli interrupt, dipendenze di dati tra moduli.

Strumenti come Polyspace Code Prover rendono i primi tre punti formalmente dimostrabili — non solo euristici. Lo strumento percorre tutti i possibili percorsi di esecuzione e colora ogni operatore in verde (sicuro), rosso (errore) o arancione (non decidibile). L'arancione è il nemico: ogni singolo punto va analizzato manualmente.

Copertura di test: lo statement coverage non basta

ASIL-B richiede secondo ISO 26262-6 tabella 12 almeno la branch coverage a livello di unit. Per ASIL-C e ASIL-D si aggiunge la MC/DC coverage (Modified Condition/Decision Coverage).

La differenza è importante:

Un piccolo esempio per chiarire:

if (sensore_ok && (rpm > 1000)) {
    attiva_azione();
}

Per lo Statement Coverage basta un test in cui entrambe le condizioni sono vere e attiva_azione() viene chiamata.

Per la Branch Coverage serve inoltre un test in cui la condizione complessiva è falsa — indipendentemente da quale delle due parti fa pendere la bilancia.

Per MC/DC occorre dimostrare che entrambe le sotto-condizioni influenzano il risultato indipendentemente. Servono tre casi di test. Con combinazioni di cinque o sei sotto-condizioni il numero di casi di test esplode.

Conseguenza pratica

I test unitari ASIL-B sono corposi ma gestibili. Strumenti come Cantata, VectorCAST o TestWell CTC++ strumentano il codice e misurano la copertura a livello di object code. Servono tipicamente 3–5 casi di test per funzione.

Il salto ad ASIL-D (assistente al mantenimento di corsia, attivazione airbag) diventa doloroso: 8–20 casi di test per funzione, molti con input creativi per chiudere le lacune MC/DC.

Programmazione difensiva: cosa significa concretamente?

L'ISO 26262 richiede programmazione difensiva senza dire esattamente cosa sia. Nella pratica automotive si sono affermati alcuni pattern:

Verificare i parametri d'ingresso

void imposta_rpm(uint16_t rpm)
{
    if (rpm > MAX_RPM) {
        rpm = MAX_RPM;   /* clamp invece di fallire */
        /* Opzionale: registrazione nella memoria guasti */
    }
    /* ... */
}

Non scatenare un'assertion — quello porta il veicolo a fermarsi. In codice ASIL-B l'input errato viene solitamente mascherato e opzionalmente registrato.

Controlli di plausibilità a runtime

uint32_t leggi_sensore_temperatura(void)
{
    uint32_t t_raw = adc_read(TEMP_CANALE);

    if ((t_raw < TEMP_MIN_RAW) || (t_raw > TEMP_MAX_RAW)) {
        imposta_guasto(GUASTO_SENSORE_TEMP);
        return TEMP_DEFAULT;   /* valore di ripiego */
    }
    return t_raw;
}

Niente cicli infiniti

Ogni ciclo while(1) (tranne nello scheduler principale) ha bisogno di un contatore di timeout. Ogni do..while di un'uscita pulita.

Watchdog non solo all'inizio e alla fine

Errore classico del principiante: trigger del watchdog prima e dopo il task principale. Meglio: all'interno delle operazioni lunghe, con più punti di trigger, così un task bloccato viene rilevato.

Qualificazione degli strumenti: lo sforzo spesso trascurato

Ogni strumento il cui output confluisce nel prodotto deve essere valutato secondo ISO 26262-8. Questo riguarda:

• Compilatori (GCC, IAR, Green Hills)
• Generatori di codice (Simulink Embedded Coder, TargetLink)
• Assemblatori, linker, debugger
• Strumenti di analisi statica
• Framework di test
• Gestione versioni (Git, PTC Integrity)

La classificazione avviene tramite il TCL (Tool Confidence Level) 1, 2 o 3. Un compilatore raggiunge tipicamente TCL3 — il livello massimo — e deve essere qualificato (dal produttore, con safety manual) oppure garantito da misure compensative (decompilazione, confronto disassembly).

Da un progetto reale

Ricordo un fornitore automotive di stampo meccanico, che tradizionalmente fornisce componenti meccanici e aveva deciso di sviluppare internamente il software di comando del proprio attuatore del blocco di parcheggio. Il team software era a Detroit, negli Stati Uniti. Lo sviluppo è proceduto in tempo per mesi — finché, poco prima della consegna al cliente europeo, è sbucata all'improvviso la domanda sul safety manual del compilatore.

La risposta: il compilatore C utilizzato a Detroit non era qualificato per ISO 26262. Nessun TCL dal produttore, nessun safety manual, nessun elenco documentato di problemi del compilatore rilevanti per i requisiti di sicurezza. Il panico è stato enorme. Il blocco di parcheggio non è una funzione secondaria — è critico per la sicurezza, perché un rilascio indesiderato su un veicolo fermo in pendenza può causare un movimento non voluto.

Alla fine è stato messo in atto il classico pacchetto di misure compensative: confronto disassembly di funzioni chiave selezionate, test di integrazione aggiuntivi con iniezione di guasti rafforzata, analisi documentata dell'uso dello strumento. Tutto perché all'inizio del progetto nessuno aveva posto la domanda semplice: « Il nostro compilatore è effettivamente qualificato per l'ASIL che dobbiamo consegnare? »

La lezione: se siete un'azienda meccanica che sviluppa software per la prima volta, non trattate la qualificazione degli strumenti come un dettaglio. E se distribuite lo sviluppo su più sedi geografiche, assicuratevi che i requisiti di processo del cliente finale siano conosciuti e praticati in ogni sede.

Cosa distingue concretamente ASIL-B da QM

Molti principianti chiedono: « Qual è la differenza tra codice QM e codice ASIL-B? Lo stesso codice C fa la stessa cosa. » Tecnicamente è vero. Organizzativamente è giorno e notte:

Il fattore dell'ultima riga non è esagerato: la documentazione prodotta attorno al codice vero e proprio in un progetto ASIL-B supera di molto il volume del codice. Safety Plan, Safety Case, analisi HAZOP, FMEA, piano di validazione, piano di verifica, piano di integrazione, report di test — ognuno di questi documenti non è un modulo ma un'opera a sé.

Cosa consiglio ai principianti

1. Leggete la norma. Non per intero, ma ISO 26262-6 (Software Development) e -8 (Supporting Processes) fanno parte dell'equipaggiamento base. Chi legge solo il capitolato non capisce perché il capitolato è così.
2. Introducete MISRA-C presto. Al primo giorno di progetto, non dopo il primo test di integrazione.
3. Fissate la toolchain a inizio progetto. Versione del compilatore, build server, strumento di analisi statica — decisioni difficilmente reversibili.
4. I test sono obbligatori, non opzionali. Chi rimanda i test « alla fine del progetto » non consegnerà il progetto. I test si scrivono insieme al codice.
5. Stabilire una cultura di review. Le review non sono formalità. L'auditor di sicurezza esamina i verbali: sono state poste domande vere o solo apposti segni di spunta?
6. I requisiti sono l'ancora. Senza requisiti puliti e collegabili non c'è Safety Case. DOORS o Polarion sono lo standard.

Conclusione

ASIL-B non è difficile — è laborioso. Chi non ne vede il valore aggiunto percepisce il processo come un'imposizione. Chi ha visto una volta l'analisi statica trovare una vera race condition che avrebbe causato un incidente sul campo capisce perché la norma è così dettagliata.

In 35 anni di sviluppo automotive ho imparato: la qualità non nasce dai test a fine progetto, ma da processo, strumenti e disciplina lungo tutto lo sviluppo. L'ISO 26262 è meno un ostacolo che una checklist di cose che mi aspetterei per un buon codice automotive anche senza la norma.

Il salto più grande per il principiante non è il codice — è capire che ASIL-B è qualità, e la qualità ha un prezzo: in ore, in documentazione e nell'impegno di ogni singolo passo. In cambio si ottiene codice su cui si può contare. E nel mondo automotive vale il prezzo.