Alla som utvecklar inom fordonsindustrin känner igen stämplarna i varje kravspecifikation: QM, ASIL-A, ASIL-B, ASIL-C, ASIL-D. Förkortningen står för « Automotive Safety Integrity Level » och kommer från ISO 26262 — standarden för funktionssäkerhet i vägfordon. Mellan QM och ASIL-D sträcker sig ett universum av processarbete, dokumentationsomfång och utvecklingskostnader.
I praktiken är ASIL-B den vanligaste nivån för seriemässiga styrenheter. Motorstyrningar, bromselektronik, kameraförbehandling, batterihantering — mycket av detta är ASIL-B. Och det är precis här det blir konkret för C-utvecklaren.
Den här artikeln beskriver vad ASIL-B faktiskt har inneburit i projekt jag har deltagit i — bortom standardcitaten. Ingen teori, utan snubbelstenarna och det som räknas i en revision.
Vad ASIL-B kräver enligt standarden
ISO 26262-6 (Product Development at the Software Level) definierar tabeller med « highly recommended », « recommended » och « no recommendation » per aktivitet och ASIL-nivå. För ASIL-B betyder det i korthet:
- Kodningsregler: MISRA-C är i praktiken obligatoriskt (tabell 1 i standarden: « highly recommended »)
- Statisk kodanalys: highly recommended
- Kodgranskning: highly recommended, med granskare med lämplig kompetens
- Enhetstester med branch coverage: highly recommended (statement coverage ensamt räcker inte)
- Integrationstester: highly recommended
- Felinjektion: recommended
- Defensiv programmering: highly recommended
Och — viktigt — varje verktyg som används och kan påverka koden (kompilator, kodgenerator, testramverk) måste kvalificeras eller klassificeras enligt ISO 26262-8. Mer om det nedan.
MISRA-C: den underskattade dörrvakten
MISRA-C är inte C-utvecklarens fiende — även om de cirka 170 reglerna och direktiven i nuvarande MISRA-C:2012 känns överväldigande i början. De flesta reglerna är helt enkelt rimliga: inga implicita konverteringar, inga goto-hopp bakåt, ingen skuggning av variabelnamn, ingen dynamisk minnesallokering.
Det som gör saken svår i praktiken är något annat: MISRA skiljer mellan Required, Advisory och Mandatory. Och varje avsteg kräver en formell deviation — ett skriftligt motiverat, granskat och av säkerhetsansvarig godkänt enskilt fall.
« Vi hade omkring 400 deviations vid projektavslut. Var och en krävde en motivering, en analys av säkerhetspåverkan och en medunderskrift. Det är inte papperstjat — det är riktigt arbete. »
Typiska fallgropar:
- Regel 10.x (implicita konverteringar): nästan oundvikligt vid bitmanipulation. Varje rad av typen
uint8_t a = b & 0x0F;granskas kritiskt. - Regel 11.x (pointer-konverteringar): hårdvaruåtkomst kräver nästan alltid pointer-casting. Lösbart, men måste dokumenteras.
- Regel 21.3 (ingen dynamisk minnesallokering): ofta överraskande — även statiska strukturer med pointers flaggas ibland om livscykeln inte är tydligt dokumenterad.
Praktisk rekommendation
Den som planerar ASIL-B-kod från grunden bör ha MISRA i åtanke från början. Att i efterhand göra en befintlig kodbas MISRA-konform är tre till fem gånger dyrare än att göra det rätt från början. Verktyg som Polyspace, LDRA eller Helix QAC kontrollerar automatiskt — men ingen regel är 100 % automatiskt kontrollerbar. Vissa regler kräver mänskligt omdöme.
Statisk analys är mer än en grön bock
Standarden kräver statisk analys — ofta missförstått som « kör MISRA-checkern ». ISO 26262 menar i själva verket betydligt mer:
- Control-flow-analys: hitta alla onåbara kodvägar.
- Data-flow-analys: hitta variabler som används men inte initieras.
- Abstrakt tolkning: hitta potentiella array-overflows, division med noll, heltalsöverskott.
- Semantisk analys: hitta race conditions i avbrott, databeroenden mellan moduler.
Verktyg som Polyspace Code Prover gör de första tre punkterna formellt bevisbara — inte bara heuristiska. Verktyget går igenom alla möjliga exekveringsvägar och färgar varje operator grön (säker), röd (fel) eller orange (ej avgörbart). Orange är fienden: varje ställe måste analyseras manuellt.
Från praktiken
En Polyspace-körning på en medelstor motorstyrkomponent kan ta flera timmar. Analysen identifierar typiskt 50–200 orange punkter per 10 000 rader kod. Varje måste bedömas: är det ett verkligt fel, eller saknar verktyget bara tillräcklig kontext?
De flesta orange punkter visar sig vara falska positiva. Men varje körning hittar också 2 eller 3 verkliga fel som ingen kodgranskning och inget enhetstest skulle ha upptäckt.
Testtäckning: statement coverage räcker inte
ASIL-B kräver enligt ISO 26262-6 tabell 12 minst branch coverage på enhetsnivå. För ASIL-C och ASIL-D tillkommer MC/DC-täckning (Modified Condition/Decision Coverage).
Skillnaden är viktig:
| Täckningstyp | Vad som kontrolleras | ASIL-nivå |
|---|---|---|
| Statement Coverage | Varje instruktion körs minst en gång | QM, A |
| Branch Coverage | Varje gren (if/else) gås igenom i båda riktningar | B |
| MC/DC | Varje villkor i en kombination påverkar resultatet oberoende | C, D |
Ett litet exempel för att tydliggöra:
if (sensor_ok && (rpm > 1000)) {
utlos_atgard();
}För Statement Coverage räcker ett testfall där båda villkoren är sanna och utlos_atgard() anropas.
För Branch Coverage behövs dessutom ett testfall där det sammanlagda villkoret är falskt — oavsett vilken av de två delarna som fäller avgörandet.
För MC/DC måste man visa att båda delvillkoren påverkar resultatet oberoende av varandra. I det här fallet krävs tre testfall. Vid kombinationer med fem eller sex delvillkor exploderar antalet nödvändiga testfall.
Praktisk följd
ASIL-B-enhetstester är omfattande men hanterbara. Verktyg som Cantata, VectorCAST eller TestWell CTC++ instrumenterar koden och mäter täckning på objektkodsnivå. Man behöver typiskt 3–5 testfall per funktion.
Steget till ASIL-D (filhållningsassistans, airbagutlösning) blir smärtsamt: 8–20 testfall per funktion, många med kreativa indata för att täcka MC/DC-luckor.
Defensiv programmering: vad betyder det konkret?
ISO 26262 kräver defensiv programmering utan att säga exakt vad det är. I fordonspraktiken har några mönster etablerats:
Kontrollera indata
void satt_rpm(uint16_t rpm)
{
if (rpm > MAX_RPM) {
rpm = MAX_RPM; /* begränsa i stället för att misslyckas */
/* Valfritt: felminnespost */
}
/* ... */
}Inte utlös en assertion — det stoppar fordonet. I ASIL-B-kod maskeras felaktig indata oftast och loggas valfritt.
Rimlighetskontroller vid körning
uint32_t las_temperatursensor(void)
{
uint32_t t_raw = adc_read(TEMP_KANAL);
if ((t_raw < TEMP_MIN_RAW) || (t_raw > TEMP_MAX_RAW)) {
satt_fel(FEL_TEMP_SENSOR);
return TEMP_DEFAULT; /* reservvärde */
}
return t_raw;
}Inga oändliga loopar
Varje while(1)-loop (utom i huvudschemaläggaren) behöver en timeout-räknare. Varje do..while en ren utgång.
Watchdog inte bara i början och slutet
Klassiskt nybörjarfel: watchdog-triggers före och efter huvudtasken. Bättre: inuti långa operationer med flera triggerpunkter, så att en fastnad task upptäcks.
Verktygskvalificering: det ofta förbisedda arbetet
Varje verktyg vars utmatning går in i produkten måste bedömas enligt ISO 26262-8. Det gäller:
- Kompilatorer (GCC, IAR, Green Hills)
- Kodgeneratorer (Simulink Embedded Coder, TargetLink)
- Assemblers, linkers, debuggers
- Statiska analysverktyg
- Testramverk
- Versionshantering (Git, PTC Integrity)
Klassificeringen sker via TCL (Tool Confidence Level) 1, 2 eller 3. En kompilator når typiskt TCL3 — högsta nivån — och måste antingen vara kvalificerad (av leverantören, med safety manual) eller säkras genom kompenserande åtgärder (disassembly-jämförelse, omvänd kompilering).
Kostnadsdrivare nummer ett
Att underskatta verktygskvalificeringen är den vanligaste kostnadsdrivaren i ASIL-projekt. Att upptäcka mitt i utvecklingen att den valda kompilatorn inte har ett kvalificerat build tvingar antingen till byte (miljoner euro) eller till omfattande kompenserande åtgärder.
Praktisk rekommendation: innan första kodraden, lista verktygskedjan och begär kvalificeringsdokumentation från leverantörerna. Det är ingen formalitet — det är projektkritiskt.
Från ett verkligt projekt
Jag minns en mekaniskt inriktad fordonsleverantör som traditionellt levererar mekaniska komponenter och hade beslutat att själv utveckla styrprogramvaran till sin parkeringsspärraktuator. Mjukvaruteamet satt i Detroit, USA. Utvecklingen gick enligt plan i månader — tills det strax före milstolpeleveransen till den europeiska slutkunden plötsligt kom upp frågan om kompilatorns safety manual.
Svaret: den C-kompilator som användes i Detroit var inte kvalificerad för ISO 26262. Ingen TCL-klassning från leverantören, ingen safety manual, ingen dokumenterad lista över kompilatorproblem relevanta för säkerhetskrav. Paniken var enorm. Parkeringsspärren är ingen sekundär funktion — den är säkerhetskritisk, eftersom en oönskad frigivning med stillastående fordon i lutning kan leda till oavsiktlig fordonsrörelse.
Det som till slut gjordes var det klassiska paketet av kompenserande åtgärder: disassembly-jämförelse av utvalda nyckelfunktioner, ytterligare integrationstester med förstärkt felinjektion, dokumenterad verktygsanvändningsanalys. Allt för att ingen i projektstarten hade ställt den enkla frågan: « Är vår kompilator verkligen kvalificerad för den ASIL vi måste leverera? »
Lärdomen: om ni är ett mekanikhus som utvecklar programvara för första gången, behandla inte verktygskvalificeringen som en detalj. Och om utvecklingen fördelas på flera geografiska platser, se till att slutkundens processkrav är kända och följda på varje plats.
Vad som konkret skiljer ASIL-B från QM
Många nybörjare frågar: « Vad är skillnaden mellan QM-kod och ASIL-B-kod? Samma C-kod gör samma sak. » Tekniskt stämmer det. Organisatoriskt är det natt och dag:
| Aktivitet | QM | ASIL-B |
|---|---|---|
| Kravspårbarhet | rekommenderad | obligatorisk (verktygsunderstödd) |
| Kodgranskning | rekommenderad | obligatorisk, dokumenterad, definierad granskarkompetens |
| MISRA-C-efterlevnad | nice-to-have | obligatorisk, formella deviations |
| Enhetstest-täckning | statement | branch |
| Verktygskvalificering | ej krav | obligatoriskt |
| Felinjektion på HW-nivå | nej | rekommenderad |
| Dokumentation per LOC | 1× | 5–10× |
Faktorn i sista raden är ingen överdrift: dokumentationen som produceras runt själva koden i ett ASIL-B-projekt överstiger kodvolymen flera gånger om. Safety Plan, Safety Case, HAZOP-analys, FMEA, valideringsplan, verifieringsplan, integrationsplan, testrapporter — varje av dessa dokument är ingen blankett utan ett eget verk.
Vad jag råder nybörjare
- Läs standarden. Inte helt, men ISO 26262-6 (Software Development) och -8 (Supporting Processes) tillhör grundutrustningen. Den som bara läser kravspecifikationen förstår inte varför den ser ut som den gör.
- Inför MISRA-C tidigt. På projektets första dag, inte efter första integrationstestet.
- Fastställ verktygskedjan vid projektstart. Kompilatorversion, build-server, statiskt analysverktyg — beslut som knappt går att återkalla senare.
- Tester är obligatoriska, inte valfria. Den som sparar testningen « till projektets slut » kommer inte att leverera projektet. Tester skrivs tillsammans med koden.
- Etablera en granskningskultur. Granskningar är ingen formalitet. En säkerhetsrevisor granskar protokollen noga: ställdes verkliga frågor, eller sattes bara bockar?
- Kraven är ankaret. Utan rena, länkbara krav finns ingen Safety Case. DOORS eller Polarion är standard här.
Slutsats
ASIL-B är inte svårt — det är omfattande. Den som inte ser mervärdet uppfattar processen som en plåga. Den som en gång har sett statisk analys hitta en verklig race condition som hade orsakat en olycka i fält förstår varför standarden är så detaljerad.
Under 35 år i fordonsutveckling har jag lärt mig: kvalitet kommer inte från tester i slutet, utan från process, verktyg och disciplin genom hela utvecklingen. ISO 26262 är mindre ett hinder än en checklista över saker jag skulle förvänta mig för god fordonskod även utan standarden.
Det största steget för nybörjaren är inte koden — det är att förstå att ASIL-B är kvalitet, och kvalitet har ett pris: i timmar, i dokumentation och i åtagandet för varje enskilt steg. I gengäld får man kod man kan lita på. Och i fordonsvärlden är det värt priset.