ISO 26262 en ISO 21434 voor zware nul-emissievoertuigen: Functionele veiligheid en cybersecurity naast elkaar

Dit artikel doorloopt de twee standaarden zoals gezien door een zware, emissievrije integratiepartner: wat elke norm vereist, hoe ze in de praktijk samenwerken en waar co-ontwikkeling de meeste invloed toevoegt.

ISO 26262 is een internationale norm voor functionele veiligheid in elektrische en elektronische systemen van auto's. Het biedt een gestructureerd kader voor het identificeren, beoordelen en beheersen van risico's gedurende de hele levenscyclus van een product. Het doel is om de veiligheid van deze systemen te waarborgen en het aantal ongevallen te verminderen.

ISO 26262 (huidige editie: 2018, tweede editie) definieert de functionele veiligheidslevenscyclus voor E/E-systemen in wegvoertuigen tot 3,5 ton, met expliciete uitbreidingen naar zware voertuigen in Deel 1 Clausule 1 van de tweede editie. De levenscyclus begint met een itemdefinities, loopt door Hazard Analysis and Risk Assessment (HARA), kent Automotive Safety Integrity Level (ASIL) classificaties toe, leidt technische veiligheidsvereisten af, valideert deze door middel van testen en analyses, en gaat door naar productie en exploitatie via een safety case.

ASIL is het centrale concept. Het is geen absolute veiligheidsbeoordeling; het is een kwantificering van hoe rigoureus het ontwikkelingsproces moet zijn voor een bepaald risico. ASIL A is de lichtste, ASIL D de strengste. De meeste aan de tractie gerelateerde functies voor zware bedrijfsvoertuigen vallen onder ASIL C of D; HMI-functies neigen naar ASIL A of QM (kwaliteitsbeheerd, geen ASIL).

ISO 21434 is de norm voor cybersecuritytechniek in de automobielindustrie. ECE R155 is de regelgeving voor cybersecurity in voertuigen. Beide zijn cruciaal voor veilige en beveiligde connectiviteit in moderne auto's.

ISO 21434 (2021) definieert de levenscyclus van cybersecurity-engineering voor wegvoertuigen. De structuur ervan is vergelijkbaar met ISO 26262: concept, ontwikkeling, productie, gebruik, buitengebruikstelling. Waar 26262 HARA heeft, heeft 21434 TARA (Threat Analysis and Risk Assessment). Waar 26262 ASIL heeft, heeft 21434 CAL (Cybersecurity Assurance Level).

ISO 21434 is geen directe verordening. De verordening is ECE R155, die een Cybersecurity Management System (CSMS) vereist voor elk voertuig dat vanaf juli 2024 (nieuwe typen) of juli 2026 (alle productietypen) de EU-markt betreedt. Naleving van ISO 21434 is de standaardroute om het CSMS aan te tonen. ECE R156 spiegelt deze voor het beheer van software-updates, waarbij een systeem voor software-updatebeheer (SUMS) wordt verplicht voor updates via de lucht.

Waar de twee standaarden elkaar overlappen

De twee standaarden zijn geschreven door verschillende werkgroepen, maar met bewuste kruisverwijzingen. Ze delen meer dan ze verschillen. De overlap is het meest zichtbaar op vier punten in de levenscyclus.

Een OEM die de twee levenscycli afzonderlijk uitvoert, zal ongeveer 9 maanden na het opstarten van een zwaar programma ontdekken dat de twee teams tegenstrijdige vereisten hebben opgesteld voor dezelfde ECU. De oplossing is structureel: organiseer een enkele workshop voor HARA en TARA over hetzelfde item, in dezelfde week, met beide teams in de ruimte.

Waar ze conflicteren, en hoe ze op te lossen

De overlap is echt, maar niet naadloos. Drie conflictpatronen komen vaak voor.

Conflict 1: fail-safe versus veilige toestand

ISO 26262 vereist dat het systeem bij detectie van een storing een gedefinieerde veilige toestand (vaak koppelvermindering, isolatie open, remmen toegepast) binnengaat. ISO 21434 vereist dat het systeem bij detectie van een cybersecurity-evenement een veilige toestand binnengaat, wat soms betekent dat het moet blijven functioneren terwijl het waarschuwt. De twee toestanden kunnen verschillend zijn, en op een zwaar platform is de veilige toestand soms riskant in cybersecurity-termen (het stilleggen van een voertuig op een openbare weg creëert een ander aanvalsoppervlak).

Oplossing: Definieer een uniforme state machine in de architectuurfase, met expliciete overgangen tussen de veilige toestand en de beveiligde toestand, en documenteer de afweging in zowel de veiligheids- als de cybersecuritygevallen.

Conflict 2: integriteit bijwerken

ISO 26262 vereist dat elke wijziging aan veiligheidsrelevante software een regressietestcyclus triggert die evenredig is met de getroffen ASIL. ISO 21434 en ECE R156 vereisen dat cybersecurity patches binnen de gestelde termijnen de vloot bereiken. De twee vereisten trekken aan tegenovergestelde uiteinden: grondige hervalidatie versus snelle implementatie.

Resolutie: vooraf gekwalificeerde updatekanalen met vooraf gebouwde regressietestpakketten, zodat een patch binnen enkele uren kan worden uitgebracht en toch voldoet aan de bewijsvereisten van 26262.

Conflict 3: ASIL versus CAL

ASIL en CAL lijken op papier op elkaar, maar ze beoordelen verschillende zaken. Een functie kan ASIL D (hoogste veiligheidsintegriteit) en CAL 2 (gemiddelde cybersecurity-borging) zijn, of ASIL B en CAL 4. Hardwarebudgetallocatie aan een van beide kan de architectuur in verschillende richtingen trekken.

Resolutie: een geïntegreerd risicoregister waarin elke functie één keer wordt weergegeven, met zowel ASIL als CAL, en waarbij het hogere van de twee als drijfveer voor de ontwikkeldisciplines wordt gebruikt. Dit vermijdt twee parallelle architecturen.

Wat verandert er specifiek voor zware emissievrije voertuigen?

Zware emissievrije programma's voegen drie concrete verschillen toe ten opzichte van werk aan ISO 26262 / 21434 voor personenauto's.

• HV-batterij als ASIL D-component. Batterijisolatieverlies is een gevaar met potentieel voor brand en elektrocutie. De meeste zware programma's classificeren monitoring van batterijisolatie op ASIL D, wat redundante detectie en een ontwikkelproces met hoge mate van zorgvuldigheid vereist.
• Laadinterface als cyberbeveiligingsaanvalsflank. Elke plug-in interface (CCS2, MCS) is een potentieel toegangspunt. ISO 15118 introduceert TLS-beveiligd Plug and Charge, maar het certificaatbeheer op de schaal van een vloot is een CSMS-onderwerp, geen onderwerp van het laadprotocol.
• Off-highway bedrijfsmodi. Veel zware platforms hebben modi voor niet-openbare wegen (bouwplaats, mijn, haven). HARA-afbakening moet beide omvatten. Sommige gevaren die verwaarloosbaar zijn op een openbare weg, zijn cruciaal in een haven (waar een volledig beladen elektrische reachstacker een schip kan beschadigen).

De rol van de integratiepartner

Functionele veiligheid en cybersecurity omvatten concept, ontwikkeling, validatie en productie. De integratiepartner voegt specifiek op drie punten waarde toe.

1. Workshop itemdefinitie: co-auteur het document dat zowel HARA als TARA omvat, zodat het voor beide doeleinden geschikt is.
2. HARA + TARA parallel: Faciliteer de workshop, documenteer gelijktijdig gevaren en bedreigingen, identificeer gedeelde mitigerende maatregelen.
3. Technische veiligheid + cybersecurity casus: stel het bewijs samen in het formaat dat zowel ECE R155 als het technisch dossier van de WVTA verwachten.

OEM's die dit intern proberen te doen voor het eerste zware emissievrije programma, eindigen bijna altijd met twee parallelle documentatieketens, elk met hiaten. Een integratiepartner die dit voor eerdere programma's heeft uitgevoerd, levert één keten met kruisverwijzingen waar nodig.

Tijdlijn: waar 26262 en 21434 landen in een typisch zwaar programma

Een 36-maanden durend zwaar emissievrij programma, van concept tot typegoedkeuring, structureert het veiligheids- en cybersecuritywerk doorgaans als volgt. De datums zijn illustratief, maar de volgorde is consistent over de programma's.