ISO 26262 jämfört med MIL-STD-882E: samma disciplin, två världar

Av de två är MIL-STD-882 fyra decennier äldre. Den växte fram ur de amerikanska robotprogrammen i början av 1960-talet, blev militär standard 1969, och dagens utgåva — MIL-STD-882E, utgiven 2012 och uppdaterad genom ett ändringsmeddelande 2023 — är det amerikanska försvarsdepartementets standardpraxis för systemsäkerhet, åberopad genom avtal: en hänvisning binder den obligatoriska kärnan, medan aktivitetsbeskrivningarna binder först när de pekas ut var för sig i avtalet. ISO 26262 är fordonsindustrins eget svar, först publicerad 2011 och utvidgad 2018 till tolv delar som täcker alla serieproducerade vägfordon utom mopeder: en anpassning av IEC 61508 till fordon, som ingen upphandlande myndighet åberopar — den binder i egenskap av teknikens nivå, den standard en tillverkare förväntas hålla, och förs ned genom leverantörskedjan via avtal mellan kund och leverantör i stället för genom offentlig upphandling.

Den djupare skillnaden ligger i vad respektive standard tittar på. MIL-STD-882E definierar säkerhet direkt utifrån skada: en olyckshändelse är oavsiktlig död, personskada, arbetssjukdom, skada på eller förlust av utrustning eller egendom, eller skada på miljön — och en risk är varje verkligt eller möjligt förhållande som kan leda dit, vare sig det är ett komponentfel, ett osäkert samspel eller ett energirikt material. ISO 26262 definierar funktionssäkerhet som frånvaro av oacceptabel risk orsakad av faror som uppstår genom felaktigt beteende hos elektriska och elektroniska system — och stannar där: skada på egendom eller miljö, och faror som inte beror på att elektroniken beter sig fel, ligger utanför dess omfattning. Den ena standarden täcker ett systems hela förmåga att orsaka skada; den andra täcker vad som händer när elektroniken avviker från sin avsedda funktion.

MIL-STD-882E bedömer varje risk längs två axlar. Konsekvens: katastrofal, kritisk, marginell eller försumbar — graderad efter följd, från dödsfall eller oåterkallelig miljöskada ned till beloppsgränser. Sannolikhet: frekvent (A) ned till osannolik (E), plus eliminerad (F) för risker som konstruerats bort helt. De två kombineras till en riskbedömningskod — 1A är en frekvent katastrof — och koden placerar risken på en nivå: hög, allvarlig, medel eller låg. Det är en bedömning av själva olycksrisken, gjord per risk och omprövad genom systemets liv.

ISO 26262 ställer i stället tre frågor, i sin risk- och farebedömning: hur allvarlig skulle skadan bli (S0–S3), hur sannolik är den trafiksituation där den kan uppstå (exponering, E0–E4), och skulle en förare eller någon annan rimligen kunna avvärja den (kontrollerbarhet, C0–C3)? Svaren kombineras till en ASIL-nivå — A till D, eller QM när kvalitetssystemet ensamt räcker. ASIL D uppstår ur exakt en kombination: livshotande skada, situation med hög sannolikhet, ingen möjlighet att avvärja. Och det avgörande: ASIL-nivån graderar inte flottans kvarvarande risk — den graderar hur noggrant utvecklingsarbetet måste bedrivas, den fäster vid ett säkerhetsmål och ärvs av varje krav som härleds ur det.

Det är här översättningen mellan världarna oftast går fel. Exponering är sannolikheten för trafiksituationen, inte för felet — en annan storhet än MIL-STD-882E:s olyckssannolikhet — och kontrollerbarhet saknar helt motsvarighet i försvarsmatrisen. Någon officiell översättning mellan ASIL-nivåer och 882E:s risknivåer finns inte, och en SAE-artikel från 2025 om att dra nytta av ISO 26262 för efterlevnad av MIL-STD-882E säger det rakt ut: det finns ingen direkt överensstämmelse mellan de två standardernas risknivåer. Jämförelsetabeller kan vara nyttiga att samtala kring; de innebär inte likvärdighet.

När det gäller mjukvara når de två standarderna samma slutsats från motsatta håll. MIL-STD-882E säger det uttryckligen: att fastställa sannolikheten för fel i en enskild mjukvarufunktion är i bästa fall svårt och kan inte baseras på historiska data — alltså kan mjukvarurisk inte vila på konsekvens och sannolikhet allena. I stället korsas konsekvensen med mjukvarans styrkategori — hur stor kontroll mjukvaran utövar över systemet — vilket ger ett kriticitetsindex för mjukvara, SwCI 1 till 5, och varje index föreskriver uppgifter på en bestämd noggrannhetsnivå: analys av krav, arkitektur, konstruktion och kod, plus säkerhetsspecifik provning, med avtagande djup när kriticiteten sjunker. Standarden är tydlig med att den matrisen inte är en riskbedömning — och lika tydlig med följden av att hoppa över den: utebliven noggrannhet på SwCI 1 dokumenteras som ett högt bidrag till systemrisken och läggs fram för programmet att fatta beslut om.

Del 6 av ISO 26262 gör samma sak, fast med helt andra begrepp. Mjukvara bär inga sannolikhetsmål — kvantitativa värden finns bara för slumpmässiga hårdvarufel — och integriteten köps i stället genom ASIL-graderade metodtabeller, där varje teknik graderas per ASIL som starkt rekommenderad, rekommenderad eller utan rekommendation: låg komplexitet, språkdelmängder och stark typning för alla; de tyngre analyserna och täckningskriterierna reserverade för C och D. Olika ordval, samma ingenjörsmässiga sanning: man kan inte provköra fram sannolikhet i mjukvara, så kriticiteten får köpa noggrannhet i processen.

MIL-STD-882E:s bevisryggrad är ett riskhanteringssystem i sluten slinga: en levande dokumentation med bestämt minimiinnehåll — risker, tillhörande olyckshändelser, riskbedömningar, åtgärder, status, verifiering av riskreduktion och varje beslut om att acceptera risk. I svensk försvarspraxis dyker samma instrument upp som TASK 106 i H SystSäk 2022: en riskhanteringsprocess med löpande uppföljning och en samlad bild av alla identifierade risker, dokumenterad i en risklogg som följer systemet genom hela dess liv.

ISO 26262 sammanställer i stället en säkerhetsargumentation — ett resonemang som visar att funktionssäkerhet uppnåtts, byggt successivt av livscykelns arbetsprodukter och kontrollerat genom bekräftande åtgärder: granskningar, en funktionssäkerhetsrevision och en funktionssäkerhetsbedömning, med graderade oberoendekrav på vem som får utföra dem. Dokumentation kontra argumentation är en verklig filosofisk skillnad — men en argumentation utan tillförlitlig dokumentation faller ihop, och en risklogg som inte kan säga vilken mjukvara och konfiguration som faktiskt finns ute bevisar ingenting. Båda världarna landar i samma beroende: att veta exakt vad som kör var, under konfigurationsstyrning, genom systemets hela liv — den livscykeldisciplin vi beskrev i artikeln om försvarsdiagnostik.

I försvarsvärlden accepteras kvarvarande risk av en namngiven instans — innan människor, utrustning eller miljö utsätts för en känd risk måste den formellt accepteras på den nivå som det amerikanska försvarsdepartementets 5000-serie anvisar: ju högre risk, desto mer seniort beslutsfattande, och användarsidans företrädare ska formellt instämma innan allvarliga och höga risker accepteras. Att acceptera risk är en styrningshandling med namnunderskrift, och riskdokumentationen är vad underskriften hänvisar till.

ISO 26262 innehåller ingen statlig accepterande instans någonstans. Slingan sluts inne hos tillverkaren: funktionssäkerhetsbedömningen avgör om objektet uppnår funktionssäkerhet, och beslutet att frisläppa för produktion är organisationens eget. Fordonsvärldens regulatoriska tänder sitter någon annanstans — i typgodkännandet enligt UNECE-reglementena — och ISO 26262 binder som den nivå en tillverkare mäts mot. För en leverantör som rör sig mellan världarna är det här den praktiska skillnaden: i försvaret levererar du bevis in i någon annans acceptansbeslut; i fordonsindustrin bygger och äger du argumentationen själv. Båda kräver samma underliggande dokumentation.

Sverige lägger till ett eget lager. H SystSäk 2022 — Försvarsmaktens handbok för systemsäkerhet — bygger sin aktivitetsuppsättning till stor del på MIL-STD-882E: avsnitten speglar standardens aktivitetsserier — planering, analys, värdering, verifiering — med ett svenskt femte avsnitt för de formella säkerhetsbesluten, dess anpassade riskmatriser ligger nära standardens tabeller, och de kvantitativa sannolikhetsintervallen A–F stämmer exakt. Handboken säger också vad som gäller när en leverantör kommer med en annan bakgrund: om systemsäkerhetsarbetet bedrivs enligt en annan etablerad standard kan det behöva kompletteras med bland annat de unika svenska aktiviteterna och en korsreferenslista mellan standarderna. Den korsreferenslistan är, i miniatyr, precis den översättning den här artikeln beskriver.

För en organisation formad av fordonsindustrins funktionssäkerhet bär det mesta av muskelminnet över: konsekvensdriven noggrannhet, disciplin i verifiering och validering, konfigurationsstyrning och spårbarhet från krav till levererat system. Det som måste läras in är resten: den bredare olycksdefinitionen som räknar utrustning och miljö som följder, styrningen kring formell riskacceptans, och den svenska aktivitetsuppsättningen från systemsäkerhetsplan till TASK 106. Det är den resa vi själva är på — vi lär oss kontinuerligt av de ramverk som styr det här området, och hur vi arbetar med standarder beskriver var vi står. Frågan en utvärderare bör ställa till varje leverantör som rör sig mellan världarna är inte vilken standard de lärt sig utantill, utan om deras dokumentation — av risker, versioner, konfigurationer och verifieringar — skulle klara en granskning i båda världarna.