ISO 26262 i praksis — Hvad ASIL-B virkelig betyder for indlejret C-kode

Enhver, der udvikler i bilindustrien, kender stemplerne på hvert eneste kravspec: QM, ASIL-A, ASIL-B, ASIL-C, ASIL-D. Forkortelsen står for « Automotive Safety Integrity Level » og stammer fra ISO 26262 — standarden for funktionssikkerhed i vejkøretøjer. Mellem QM og ASIL-D strækker sig et univers af procesarbejde, dokumentationsomfang og udviklingsomkostninger.

I praksis er ASIL-B det hyppigste niveau for styreenheder i serieproduktion. Motorstyringer, bremseelektronik, kameraforbehandling, batteristyring — meget af dette er ASIL-B. Og det er netop her, det bliver konkret for C-udvikleren.

Denne artikel beskriver, hvad ASIL-B rent faktisk har betydet i projekter, jeg har deltaget i — ud over standardcitaterne. Ingen teori, men de konkrete snublesten og det, der tæller ved en audit.

Hvad ASIL-B kræver ifølge standarden

ISO 26262-6 (Product Development at the Software Level) definerer tabeller med « highly recommended », « recommended » og « no recommendation » per aktivitet og ASIL-niveau. For ASIL-B betyder det kort:

• Kodningsregler: MISRA-C er praktisk talt obligatorisk (tabel 1 i standarden: « highly recommended »)
• Statisk kodeanalyse: highly recommended
• Kodegennemgang: highly recommended, med passende kvalificerede anmeldere
• Enhedstests med branch coverage: highly recommended (statement coverage alene er ikke nok)
• Integrationstests: highly recommended
• Fejlinjicering: recommended
• Defensiv programmering: highly recommended

Og — vigtigt — ethvert anvendt værktøj, der kan påvirke koden (compiler, kodegenerator, testramme), skal kvalificeres eller klassificeres efter ISO 26262-8. Mere om dette nedenfor.

MISRA-C: den undervurderede dørvogter

MISRA-C er ikke C-udviklerens fjende — selvom de omkring 170 regler og direktiver i den aktuelle MISRA-C:2012 kan virke overvældende i starten. De fleste regler er simpelthen fornuftige: ingen implicitte konverteringer, ingen baglæns goto-spring, ingen skygning af variabelnavne, ingen dynamisk hukommelse.

Det, der gør sagen svær i praksis, er noget andet: MISRA skelner mellem Required, Advisory og Mandatory. Og hver afvigelse kræver en formel deviation — en skriftligt begrundet, gennemgået og af sikkerhedsansvarlig kontrasigneret enkeltsag.

« Vi havde omkring 400 deviations ved projektafslutning. Hver enkelt krævede en begrundelse, en analyse af sikkerhedsmæssig påvirkning og en kontrasignatur. Det er ikke papirarbejde — det er rigtigt arbejde. »

Typiske fælder:

• Regel 10.x (implicitte konverteringer): næsten uundgåeligt ved bitmanipulation. Enhver linje som uint8_t a = b & 0x0F; granskes kritisk.
• Regel 11.x (pointerkonverteringer): hardwareadgang kræver næsten altid pointercasting. Løsbart, men skal dokumenteres.
• Regel 21.3 (ingen dynamisk hukommelse): ofte overraskende — selv statiske strukturer med pointers markeres nogle gange, hvis livscyklussen ikke er klart dokumenteret.

Praktisk anbefaling

Den, der planlægger ASIL-B-kode fra bunden, bør tænke MISRA fra starten. At gøre en eksisterende kodebase MISRA-konform i efterhånden koster tre til fem gange mere end at gøre det rigtigt fra starten. Værktøjer som Polyspace, LDRA eller Helix QAC kontrollerer automatisk — men ingen regel er 100 % automatisk kontrollerbar. Nogle regler kræver menneskelig dømmekraft.

Statisk analyse er mere end et grønt flueben

Standarden kræver statisk analyse — ofte misforstået som « kør MISRA-checkeren ». ISO 26262 mener faktisk betydeligt mere:

• Control-flow-analyse: find alle unåelige kodestier.
• Data-flow-analyse: find variabler, der bruges uden at være initialiseret.
• Abstrakt fortolkning: find potentielle array-overløb, division med nul, heltal-overløb.
• Semantisk analyse: find race conditions i afbrydelser, dataafhængigheder mellem moduler.

Værktøjer som Polyspace Code Prover gør de første tre punkter formelt beviselige — ikke bare heuristiske. Værktøjet gennemgår alle mulige eksekveringsstier og farver hver operator grøn (sikker), rød (fejl) eller orange (kunne ikke afgøres). Orange er fjenden: hvert enkelt sted skal analyseres manuelt.

Testdækning: statement coverage er ikke nok

ASIL-B kræver ifølge ISO 26262-6 tabel 12 mindst branch coverage på enhedsniveau. For ASIL-C og ASIL-D kommer MC/DC-dækning (Modified Condition/Decision Coverage) til.

Forskellen er vigtig:

Et lille eksempel til illustration:

if (sensor_ok && (rpm > 1000)) {
    udlos_handling();
}

Til Statement Coverage er ét testtilfælde nok, hvor begge betingelser er sande, og udlos_handling() kaldes.

Til Branch Coverage kræves desuden et testtilfælde, hvor den samlede betingelse er falsk — uanset hvilken af de to dele der giver udslaget.

Til MC/DC skal det vises, at begge delbetingelser påvirker resultatet uafhængigt. Der kræves tre testtilfælde her. Ved kombinationer med fem eller seks delbetingelser eksploderer antallet af nødvendige testtilfælde.

Praktisk konsekvens

ASIL-B-enhedstests er omfattende, men håndterlige. Værktøjer som Cantata, VectorCAST eller TestWell CTC++ instrumenterer koden og måler dækning på objektkodeniveau. Man har typisk brug for 3–5 testtilfælde per funktion.

Springet til ASIL-D (vognbaneassistent, airbag-udløsning) bliver smertefuldt: 8–20 testtilfælde per funktion, mange med kreative inputværdier for at lukke MC/DC-huller.

Defensiv programmering: hvad betyder det konkret?

ISO 26262 kræver defensiv programmering uden præcist at sige, hvad det er. I bilbranchens praksis har flere mønstre slået igennem:

Tjek inputparametre

void saet_rpm(uint16_t rpm)
{
    if (rpm > MAX_RPM) {
        rpm = MAX_RPM;   /* afgræns i stedet for at fejle */
        /* Valgfrit: fejlhukommelsespost */
    }
    /* ... */
}

Udløs ikke en assertion-fejl — det bringer køretøjet til standsning. I ASIL-B-kode maskeres forkert input som regel og logges eventuelt.

Plausibilitetstjek ved kørsel

uint32_t laes_temperatursensor(void)
{
    uint32_t t_raw = adc_read(TEMP_KANAL);

    if ((t_raw < TEMP_MIN_RAW) || (t_raw > TEMP_MAX_RAW)) {
        saet_fejl(FEJL_TEMP_SENSOR);
        return TEMP_DEFAULT;   /* reserveværdi */
    }
    return t_raw;
}

Ingen uendelige løkker

Hver while(1)-løkke (undtagen i hovedskeduleringen) har brug for en timeout-tæller. Hver do..while en ren udgang.

Watchdog ikke kun i starten og slutningen

Klassisk nybegynderfejl: watchdog-trigger før og efter hovedtasken. Bedre: inde i lange operationer med flere triggerpunkter, så en blokeret task opdages.

Værktøjskvalificering: den ofte oversete indsats

Ethvert værktøj, hvis output indgår i produktet, skal vurderes efter ISO 26262-8. Det gælder:

• Compilere (GCC, IAR, Green Hills)
• Kodegeneratorer (Simulink Embedded Coder, TargetLink)
• Assemblere, linkere, debuggere
• Statiske analyseværktøjer
• Testrammer
• Versionskontrol (Git, PTC Integrity)

Klassificeringen sker via TCL (Tool Confidence Level) 1, 2 eller 3. En compiler når typisk TCL3 — det højeste niveau — og skal enten kvalificeres (af leverandøren, med safety manual) eller sikres ved kompenserende foranstaltninger (disassembly-sammenligning, baglæns oversættelse).

Fra et virkeligt projekt

Jeg husker en mekanisk præget bilunderleverandør, der traditionelt leverer mekaniske komponenter og havde besluttet selv at udvikle styresoftwaren til sin parkeringsbremseaktuator. Softwareteamet sad i Detroit, USA. Udviklingen forløb planmæssigt i måneder — indtil spørgsmålet om compilerens safety manual pludselig dukkede op kort før milepælsleveringen til den europæiske slutkunde.

Svaret: den C-compiler, der blev brugt i Detroit, var ikke kvalificeret til ISO 26262. Ingen TCL-klassificering fra leverandøren, ingen safety manual, ingen dokumenteret liste over compilerproblemer relevante for sikkerhedskrav. Panikken var enorm. Parkeringsbremsen er ikke en sekundær funktion — den er sikkerhedskritisk, fordi utilsigtet frigivelse på et stillestående køretøj på en skråning kan føre til uønsket køretøjsbevægelse.

Det, der til sidst blev gjort, var det klassiske pakke af kompenserende foranstaltninger: disassembly-sammenligning af udvalgte nøglefunktioner, yderligere integrationstests med forstærket fejlinjicering, dokumenteret værktøjsbrugsanalyse. Alt, fordi ingen i projektets start havde stillet det simple spørgsmål: « Er vores compiler egentlig kvalificeret til den ASIL, vi skal levere? »

Læren: Hvis I er et mekanikhus, der laver software for første gang, så behandl ikke værktøjskvalificering som en detalje. Og hvis I fordeler udviklingen på flere geografiske placeringer, så sørg for, at slutkundens proceskrav er kendt og efterlevet på hvert sted.

Hvad der konkret adskiller ASIL-B fra QM

Mange begyndere spørger: « Hvad er forskellen mellem QM-kode og ASIL-B-kode? Den samme C-kode gør det samme. » Teknisk passer det. Organisatorisk er det dag og nat:

Faktoren i sidste række er ikke overdreven: dokumentationen, der produceres omkring selve koden i et ASIL-B-projekt, overstiger kodeomfanget mange gange. Safety Plan, Safety Case, HAZOP-analyse, FMEA, valideringsplan, verifikationsplan, integrationsplan, testrapporter — hvert af disse dokumenter er ikke en formular, men et selvstændigt værk.

Hvad jeg råder begyndere

1. Læs standarden. Ikke helt, men ISO 26262-6 (Software Development) og -8 (Supporting Processes) hører til grundudstyret. Den, der kun læser kravspecifikationen, forstår ikke, hvorfor kravspecifikationen ser sådan ud.
2. Indfør MISRA-C tidligt. På projektets første dag, ikke efter første integrationstest.
3. Fastlæg værktøjskæden ved projektstart. Compiler-version, build-server, statisk analyseværktøj — beslutninger der næsten ikke kan trækkes tilbage senere.
4. Tests er obligatoriske, ikke valgfri. Den, der gemmer testen « til projektets slutning », leverer ikke projektet. Tests skrives sammen med koden.
5. Etabler en review-kultur. Reviews er ikke formaliteter. En sikkerhedsauditør ser nøje på review-protokollerne: blev der stillet rigtige spørgsmål, eller blev der bare sat fluebener?
6. Kravene er ankeret. Uden rene, linkbare krav er der ingen Safety Case. DOORS eller Polarion er standard her.

Konklusion

ASIL-B er ikke svært — det er omfattende. Den, der ikke ser merværdien, oplever processen som chikane. Den, der engang har oplevet, hvordan statisk analyse finder en rigtig race condition, der ville have forårsaget en ulykke i felten, forstår, hvorfor standarden er så detaljeret.

I 35 år i bilbranchen har jeg lært: kvalitet kommer ikke fra tests til sidst, men fra proces, værktøjer og disciplin gennem hele udviklingen. ISO 26262 er mindre en hindring end en checkliste over ting, jeg ville forvente til god bilkode, selv uden standarden.

Det største spring for begynderen er ikke koden — det er at forstå, at ASIL-B er kvalitet, og kvalitet har en pris: i timer, i dokumentation og i forpligtelsen ved hvert enkelt skridt. Til gengæld får man kode, man kan stole på. Og i bilverdenen er det prisen værd.