Vad H SystSäk 2022 kräver av leverantörer

H SystSäk 2022 styr systemsäkerhetsarbetet i svensk försvarsupphandling. För en leverantör kommer handboken i form av kontraktskrav: en plan, en kedja av analyser, en levande risklogg och ett formellt utlåtande före leverans. Här är arbetet i leveransordning – och var disciplinen från fordonsindustrin bär.

Handboken och dess roller

H SystSäk 2022 – Försvarsmaktens handbok för systemsäkerhet, version 3.0, i kraft sedan september 2022 – är öppet publicerad och fritt nedladdningsbar från FMV:s sidor om systemsäkerhet, tillsammans med vägledning och dokumentmallar för leverantörer. Den organiserar arbetet kring fyra roller, varav tre möter en typisk leverantör: kravställaren (Försvarsmakten, som ställer kraven och i slutändan utfärdar godkännandet), beställaren (FMV, som upphandlar och styr arbetet) och konstruktören – leverantören, som realiserar det tekniska systemet och utfärdar sitt eget formella säkerhetsutlåtande. (Den fjärde, systemintegratören, säkerställer samverkan i system av system och finns hos FMV eller Försvarsmakten.) Kraven flödar nedåt i den kedjan, och leverantören får lägga till fler aktiviteter än beställaren har krävt – att stryka en selektiv aktivitet kräver ett medvetet, dokumenterat beslut i planen.

Två saker om tidpunkt väger tyngre än allt annat i handboken. Den första: leverantörens systemsäkerhetsarbete börjar så snart kontraktet är undertecknat – aktiviteterna avgränsas i själva avtalet, de läggs inte på strax före leverans. Den andra: handboken påpekar att en preliminär Systemsäkerhetsplan – på engelska system safety programme plan, SSPP – kan användas före kontrakt, för att utvärdera en möjlig leverantörs förståelse för och prioritering av systemsäkerhet. Leverantörens grepp om disciplinen bedöms alltså redan i anbudsskedet.

Planen speglar kontraktet: SSPP

Leverantörens centrala dokument är SSPP (TASK 102) – en del av avtalet, med innehåll och omfattning styrda av kontraktet. Den beskriver systemet och organisationen, tillämplig EU-lagstiftning och svensk lagstiftning samt standarder och hur kravanalysen ska genomföras, den tolerabla risknivån uttryckt i riskmatriser, de valda vägarna genom bedömningsmodellen, vilka analyser som ska göras, hur verifiering och validering genomförs, hur riskkällor stängs och restriktioner hanteras, hur slutdokumenten tas fram – och vilka systemsäkerhetskrav leverantören kommer att ställa på sina egna underleverantörer. Leverantören får lägga till aktiviteter utöver dem som beställaren har krävt; den får inte i tysthet stryka några.

Bakom planen finns en aktivitetskatalog i fem avsnitt – planering och ledning, analyser, utvärdering, verifiering och beslut – som till stor del bygger på uppgiftsstrukturen i MIL-STD-882E, med ett svenskt femte avsnitt för de formella säkerhetsbesluten. Varje avsnitt har obligatoriska aktiviteter och en selektiv nivå, och selektivt valda aktiviteter kan ibland ersättas med aktiviteter från andra standarder eller med leverantörens egna motsvarigheter – förutsatt att varje val, och varje förenkling i förhållande till aktivitetsbeskrivningarna, dokumenteras i SSPP. Att arbeta enligt en annan etablerad systemsäkerhetsstandard är möjligt på samma villkor – handboken påpekar att arbetet då kan behöva kompletteras med de unika svenska aktiviteterna och en korsreferenslista mellan standarderna. Anpassning är tillåten; odokumenterad anpassning är det inte.

Analyskedjan

Analyserna börjar med riskkällorna. Funktionsanalysen av riskkällor (FHA, functional hazard analysis) identifierar de säkerhetskritiska funktionerna – även de som realiseras i programvara och som går vidare till kritikalitetsnivåer som hanteras enligt H ProgSäk, FMV:s kompletterande handbok från 2018 för programvara i säkerhetskritiska tillämpningar. Dess eget förord slår fast principen: handboken har ingen egen rättslig status; dess krav blir bindande när den upphandlande parten skriver in dem i kontraktet. Tillsammans med riskkällelistan (PHL, preliminary hazard list) och riskkälleanalysen (PHA, preliminary hazard analysis) matar FHA sedan Systemsäkerhetskravanalysen (SRHA, TASK 203). Där omsätter leverantören EU-rätt, svensk lagstiftning, standarder, kontraktet och sina egna interna krav – plus motåtgärderna mot de identifierade riskkällorna – till systemsäkerhetskrav. Varje krav ska vara verifierbart, eftersom det tas upp igen i verifieringsaktiviteten i slutet.

Därifrån går kedjan ned till de nivåer där en leverantör faktiskt konstruerar: delsystem, system och hantering – användning, underhåll, förvaring och transport. Handboken är också precis om vad som hamnar i riskmatrisen: bara de riskkällor som inte kunde stängas via bedömningsmodellens övriga vägar bedöms mot den tolerabla risknivån – fyra konsekvensklasser (I–IV) mot sex sannolikhetsklasser (A–F, där F är reserverad för riskkällor som har konstruerats bort helt), där gränsen mellan rött och gult definierar den risknivå som Försvarsmakten kan acceptera. Försvarsmaktens generella matriser gäller om inte särskilda skäl finns; en matris anpassad för ett produktområde eller ett specifikt system definieras i Försvarsmaktens egen ledningsplan för systemsäkerhet (SSMP, system safety management plan) och når leverantören via kravdokumenten – SSPP återger sedan den tolerabla risknivån uttryckt i de matriserna.

Vägvalsmodellen: så byggs argumentationen

I handbokens bedömningsmodell – vägvalsmodellen – argumenterar leverantören för att systemet är tillräckligt säkert. Modellen har sju vägar: lagkrav, godkännande av annan stat, godkännande av annan part, andra etablerade standarder, konstruktionsregler, beprövade system och slutligen riskmatriserna för det som återstår. Leverantören föreslår vägarna i sin SSPP; ändringar överenskoms med beställaren inom ramen för kontraktet och dokumenteras. En väg är uttryckligen stängd för industrin: en leverantör kan inte åberopa en annan stats godkännande i sin egen bedömning.

För en leverantör med bakgrund i fordonsindustrin är det den fjärde vägen – vägval 4 – där befintliga belägg kommer in: arbete enligt etablerade standarder räknas, förutsatt att motiven för de valda standarderna anges, att de tillämpade kraven – inklusive vald kritikalitetsnivå – redovisas och att det finns verifieringskriterier med resultat som visar att kraven är uppfyllda. Det är precis här belägg enligt ISO 26262 och IEC 61508 möter handboken, tillsammans med korsreferenslistan som vi beskrev i jämförelsen mellan ISO 26262 och MIL-STD-882E. Handboken granskar också kvaliteten i själva argumentationen: påståenden om att användaren inte kan antas begå vissa fel pekas ut som falska argument som inte får förekomma, och en oberoende tredje parts certifiering mot en standard väger tyngre som belägg än egenverifiering mot samma standard.

Det levande underlaget: risklogg, SAR – och SCA

Ryggraden i underlaget är Riskhanteringssystemet (HTS – hazard tracking system, TASK 106) och dess risklogg – och det är en stafett, inte en rapport. Kravställaren lägger in de vanligt förekommande riskkällorna i loggen, beställaren kan komplettera den, leverantören lägger till varje riskkälla som identifieras under utvecklingen, och vid leverans tar beställaren över loggen för fortsatt hantering – innan den lämnas vidare till kravställaren för slutskedet. Loggen förs alltså av alla tre aktörerna under systemets hela livstid. Varje post innehåller bedömningen före och efter riskreducerande åtgärder, verifieringsmetoden, acceptansbesluten och aktuell status. En sådan logg, som förs i årtionden över organisationsgränser, är lika mycket en fråga om konfigurationsstyrning som om säkerhet – samma dokumentationsdisciplin som våra diagnosplattformar bygger på.

Slutdokumenten följer av underlaget. Systemsäkerhetsrapporten (SAR, TASK 301) sammanfattar arbetet: efterlevnad av lagstiftning och kontrakt, varje riskkälla beskriven, de valda vägarna och motiven för dem. Verifieringen (TASK 401) visar att kraven är uppfyllda och att systemet svarar mot behovet – och utgör underlag för leverantörens beslutsdokument: Systemsäkerhetsutlåtandet (SCA), leverantörens formella ställningstagande före leverans om att den lagstiftning som gäller vid leverans och kundens systemsäkerhetskrav är uppfyllda, byggt på argumenten och beläggen från de tillämpade vägarna. Notera gränsen: leverantören uttalar sig; den godkänner aldrig. Deklarationen ovanpå – Systemsäkerhetsdeklarationen (SSD) – är beställarens, och godkännandet – Systemsäkerhetsgodkännandet (SSG) – liksom besluten om användning på central och lokal nivå tillhör Försvarsmakten.

Med bakgrund i fordonsindustrin

Det mesta av det som H SystSäk 2022 kräver är disciplin som en fordonsleverantör redan har: kravdriven analys, stringens graderad efter allvarlighetsgrad, verifiering med belägg, konfigurationsstyrning och ett spårbart underlag från riskkälla till stängning. Det som måste läras in är ramverket runt omkring – aktiviteternas namn och leveranser, rollgränserna, argumentationen enligt vägvalsmodellen och den svenska beslutskedjan från SCA till godkännande. Handboken sänker själv tröskeln: den är offentlig, den kompletterande H ProgSäk är offentlig, MIL-STD-882E är offentlig, och FMV publicerar öppet vägledning och mallar för leverantörer för SSPP, SAR och risklogg. Hindret är inte tillgång – det är översättning.

Den översättningen är den resa vi själva gör: vi lär oss kontinuerligt av handboken och formar vår leveransmodell kring dess aktiviteter – hur vi arbetar med standarder beskriver var vi står, och försvarsöversikten visar de program som disciplinen kommer från. För en leverantör som överväger steget in i svensk försvarsupphandling är det ärliga rådet handbokens eget: börja systemsäkerhetsarbetet med anbudet, inte efter kontraktet – för när en preliminär SSPP ligger på bordet har utvärderingen av leverantörens disciplin redan börjat.