Un veicolo moderno contiene più di cento unità di controllo elettronico, milioni di righe di codice software e decine di connessioni wireless verso l'esterno. Ogni sistema che controlla sterzata, frenata o stability control può, se malfunziona, causare incidenti gravi. E ogni connessione verso l'esterno è una potenziale porta d'accesso per un attaccante. La sicurezza funzionale e la cybersecurity automotive non sono argomenti da specialisti di nicchia: sono requisiti fondamentali per chiunque operi nella supply chain del veicolo moderno. ISO 26262 e ISO 21434 sono i due standard che definiscono come affrontarli in modo sistematico.
L'auto connessa e i nuovi rischi: il contesto
La complessità elettronica dei veicoli è cresciuta in modo esponenziale. Funzioni un tempo meccaniche — sterzata, frenata, sospensioni — sono oggi gestite da sistemi elettronici complessi. Nel frattempo, la connettività ha trasformato l'auto in un nodo di rete: connessa alla rete cellulare, alle infrastrutture stradali, ad altri veicoli, a sistemi di aggiornamento remoto del software.
Questa trasformazione porta due categorie di rischio distinte. La prima è il rischio di malfunzionamento involontario: un guasto hardware, un bug software, un sensore che fornisce dati errati. La seconda è il rischio di attacco intenzionale: un hacker che sfrutta una vulnerabilità per prendere il controllo di un sistema del veicolo. Nel 2015, i ricercatori Charlie Miller e Chris Valasek dimostrarono che non era uno scenario teorico: riuscirono a prendere il controllo remoto di una Jeep Cherokee in movimento. Quell'episodio segnò un punto di svolta nella consapevolezza del settore.
ISO 26262 e ISO 21434 rispondono rispettivamente a queste due categorie di rischio: la prima gestisce i malfunzionamenti involontari dei sistemi E/E, la seconda gestisce le minacce informatiche intenzionali. Sono complementari, non alternative.
ISO 26262: sicurezza funzionale per sistemi elettronici nell'automotive
La ISO 26262 — Road vehicles — Functional safety — è lo standard internazionale per la sicurezza funzionale nell'automotive. La seconda edizione, del 2018, si applica ai veicoli stradali fino a 3500 kg, con estensioni ad altri segmenti.
Il concetto è preciso: riguarda specificamente i rischi derivanti da malfunzionamenti dei sistemi elettrici ed elettronici (E/E). Un guasto del sensore dell'angolo di sterzata che porta a una risposta inattesa dell'EPS è un problema di functional safety. Un guasto meccanico del finestrino no.
La norma è strutturata in dodici parti che coprono l'intero ciclo di vita del prodotto: vocabolario, gestione della functional safety, fase concept con la definizione degli ASIL, sviluppo di sistema, hardware e software, produzione, analisi di sicurezza e linee guida applicative. Il cuore è la fase di concept safety: si identifica cosa potrebbe andare storto, quanto sarebbe grave e con quale probabilità, e si definiscono i safety goal da rispettare nell'intero sistema.
Il ciclo di sviluppo adottato è il V-Model: sul lato sinistro scendono le fasi di specifica e progettazione; sul lato destro salgono le fasi di verifica e validazione. Ogni livello di specifica ha un corrispondente livello di test — non si può saltare un livello. La tracciabilità bidirezionale dei requisiti è un requisito esplicito della norma: ogni requisito deve essere tracciato fino alla sua implementazione e al test che lo verifica.
ISO 21434: cybersecurity engineering per veicoli
La ISO 21434:2021 — Road vehicles — Cybersecurity engineering — risponde alla domanda complementare: non "cosa succede se un sistema si guasta?", ma "cosa succede se qualcuno lo attacca intenzionalmente?".
La ISO 21434 copre l'intero ciclo di vita del veicolo: gestione della cybersecurity a livello organizzativo (politiche, responsabilità, competenze); gestione del rischio tramite TARA (Threat Analysis and Risk Assessment); sviluppo sicuro del prodotto; cybersecurity nella produzione; operazioni e manutenzione (monitoraggio vulnerabilità, aggiornamenti OTA); dismissione sicura del veicolo e dei dati.
La TARA è il processo centrale: identifica gli asset da proteggere, definisce gli scenari di minaccia usando metodologie come STRIDE, valuta l'impatto in quattro dimensioni (sicurezza, operatività, privacy, reputazione), analizza i percorsi di attacco e stima la fattibilità. Il risultato è il Cybersecurity Assurance Level (CAL, da 1 a 4), che determina il rigore dei controlli da implementare. La TARA va aggiornata durante tutto il ciclo di vita del veicolo, perché il panorama delle minacce evolve continuamente.
UNECE R155 e R156: i regolamenti ONU che rendono obbligatorio l'approccio
UNECE R155 — Cybersecurity Management System. Entrato in vigore per i nuovi modelli omologati in Europa da luglio 2022 e per tutti i veicoli nuovi da luglio 2024, richiede ai costruttori di implementare un Cybersecurity Management System (CSMS) certificato che copra l'intero ciclo di vita del veicolo. La ISO 21434 è lo standard tecnico di riferimento per il CSMS conforme all'R155. Per un costruttore che vende in Europa, è un requisito legale per ottenere l'omologazione.
UNECE R156 — Software Update Management System. Complementare all'R155, si concentra sulla gestione degli aggiornamenti software over-the-air (OTA), garantendo che questo processo avvenga in modo sicuro e controllato.
Per i fornitori Tier 1 e Tier 2, questi regolamenti si traducono in requisiti contrattuali sempre più stringenti: i costruttori trasferiscono i requisiti R155 lungo la supply chain. Se fornisci componenti elettronici per l'automotive e non hai ancora guardato alla ISO 21434, il tuo cliente OEM probabilmente ti porrà questa richiesta prima di quanto pensi.
ASIL e CAL: livelli di rischio a confronto
L'ASIL (Automotive Safety Integrity Level) è il concetto più distintivo della ISO 26262. Classifica il livello di rigore richiesto per lo sviluppo di un sistema, basandosi su tre parametri valutati durante l'Hazard Analysis and Risk Assessment (HARA):
- Severity (S): quanto grave è il danno potenziale? Da S0 (nessun danno) a S3 (morte o danni gravi).
- Exposure (E): quanto spesso il conducente si trova nella situazione a rischio? Da E0 (praticamente mai) a E4 (continuamente).
- Controllability (C): quanto è facile evitare il danno? Da C0 (sempre controllabile) a C3 (difficilmente controllabile).
La combinazione determina l'ASIL: da A (requisiti meno stringenti) a D (requisiti massimi), con un livello QM per i casi senza requisiti specifici di functional safety. Un sistema di frenata autonoma d'emergenza (AEB) è tipicamente ASIL D: il livello massimo, con requisiti severi su hardware (ridondanza, fail-safe), software (MC/DC coverage al 100%, verifica formale) e processo (documentazione rigorosa, revisioni indipendenti). L'ASIL può essere scomposto: due canali ASIL B + ASIL B equivalgono a ASIL D, tecnica ampiamente usata per bilanciare i costi.
Il CAL (Cybersecurity Assurance Level) della ISO 21434 è strutturato in modo analogo: valuta l'impatto di una violazione di cybersecurity e la fattibilità dell'attacco. I quattro livelli CAL (1-4) determinano il rigore dei controlli, dalla documentazione di base fino alla verifica indipendente e ai test di penetrazione avanzati.
Supply chain: cosa cambia per i fornitori Tier 1 e Tier 2
La ISO 26262 e la ISO 21434 non riguardano solo i costruttori: coinvolgono tutta la supply chain.
Per la ISO 26262, il meccanismo è il Distributed Development: le responsabilità di safety tra OEM e fornitori vengono distribuite attraverso il Development Interface Agreement (DIA), che specifica chi è responsabile di quali work products nel processo di sviluppo. Per un fornitore che sviluppa sistemi safety-relevant, questo significa avere processi documentati e conformi, mantenere una catena documentale tracciabile e avere personale formato — idealmente con certificazioni come il TÜV Functional Safety Engineer.
Per la ISO 21434, i requisiti si trasferiscono attraverso i contratti: l'OEM richiede al Tier 1 di avere un CSMS conforme, il Tier 1 lo richiede al Tier 2. Questa cascata di requisiti sta trasformando profondamente il modo in cui si gestisce lo sviluppo dei componenti elettronici in tutta la filiera. Se fornisci qualsiasi componente con contenuto elettronico rilevante per la cybersecurity, ISO 21434 ti riguarda direttamente.
FAQ
La ISO 26262 è obbligatoria per tutti i fornitori automotive?
Non è obbligatoria per legge, ma è diventata un requisito contrattuale de facto per chiunque sviluppi sistemi elettronici safety-relevant per i grandi OEM. Se sviluppi qualsiasi cosa con una ECU o un software che influenza funzioni safety-critical, il tuo cliente ti chiederà quasi certamente la conformità alla ISO 26262.
Qual è la differenza tra ISO 26262 e IEC 61508?
La IEC 61508 è lo standard generale per la functional safety in tutti i settori industriali. La ISO 26262 è derivata dalla IEC 61508, adattata specificamente all'automotive con requisiti calibrati sulle caratteristiche del settore: cicli di vita brevi, grandi volumi, supply chain complessa.
La ISO 21434 è certificabile?
Non esiste uno schema di certificazione organizzativo analogo alla ISO 9001. Quello che esiste è la certificazione del CSMS richiesta dall'UNECE R155, effettuata dagli enti di omologazione con riferimento alla ISO 21434 come standard tecnico.
Come si coordina lo sviluppo tra più fornitori con la ISO 26262?
Attraverso il Development Interface Agreement (DIA): un documento contrattuale che specifica chi è responsabile di quali work products nel processo di sviluppo distribuito, consentendo di distribuire le responsabilità di safety in modo chiaro e verificabile in audit.
Quante risorse servono per implementare la ISO 26262 in una PMI?
Molte PMI sottovalutano l'investimento iniziale. La ISO 26262, soprattutto per ASIL C e D, richiede un cambiamento profondo nei processi di sviluppo, nella documentazione e nelle competenze. Un functional safety manager certificato, strumenti di gestione dei requisiti e un piano di formazione del personale sono il minimo indispensabile.