Software safety case voor militaire systemen volgens MIL-STD-882

Door Corvus Intelligence Engineering Team · Over het team →

25 juni 2026 12 min leestijd

Een systeem dat zonder software safety case opereert, opereert op vertrouwen — vertrouwen dat de gevaaranalyse volledig was, dat de ontwerpbeperkingen correct zijn en dat het verificatiebewijs toereikend is. Voor een commercieel product is dat vertrouwen verdedigbaar. Voor een militair systeem waarvan de foutmodi energetische vrijkomingen, verlies van het platform of friendly fire omvatten, niet. MIL-STD-882E, de standaard van het Department of Defense voor System Safety, biedt het gestructureerde proces waarmee dat vertrouwen wordt vervangen door gedocumenteerd, beoordeeld en geaccepteerd bewijs. De software safety case is het artefact dat dat bewijs vastlegt en het argument voert dat het resterende risico aanvaardbaar is.

Dit artikel is een praktijkgids voor het bouwen van een software safety case onder MIL-STD-882E. Het behandelt de taakstructuur van de standaard en de softwarespecifieke bepalingen, de gevaaranalyseketen van voorlopige identificatie tot software hazard analysis (SwHA), de afleiding van Software Safety Requirements (SSR's) uit gevaaroorzaken, de ontwerpbeperkingen die die eisen implementeren, het verificatiebewijs dat hun correcte implementatie aantoont, en het risicoacceptatieproces dat de case sluit. Ingenieurs die nieuw zijn in defensieveiligheidsprogramma's vinden hier een kaart van het terrein; ervaren praktijkmensen vinden een referentie voor de specifieke uitvoer en herleidbaarheid die overheidsbeoordelaars verwachten.

MIL-STD-882E-overzicht: systeemveiligheid van concept tot afstoting

MIL-STD-882E definieert systeemveiligheid als een geplande, gedisciplineerde aanpak om gevaren te identificeren en te beheren gedurende de levenscyclus van een systeem — van conceptverkenning tot afstoting. De standaard organiseert zijn eisen in taken, gegroepeerd in vijf categorieën: Program Management and Control, Design Requirements, Supportability, Training en Assessments. De contracterende activiteit selecteert taken die passen bij het risicoprofiel van het programma en legt ze vast in de Statement of Work. De aannemer voert die taken uit en levert de resultaten als Contract Data Requirements List-items.

Voor software-intensieve militaire systemen domineren vijf taken de engineeringinspanning:

Taak 205 — Software Safety Requirements Analysis: identificatie van alle veiligheidskritische softwarefuncties en afleiding van Software Safety Requirements om vastgestelde gevaaroorzaken te beheersen.
Taak 206 — Software Safety Design Analysis: analyse van het softwareontwerp om te verifiëren dat veiligheidseisen correct zijn toegewezen en dat ontwerpbeslissingen geen nieuwe gevaaroorzaken introduceren.
Taak 301 — Safety Assessment: een op mijlpalen gebaseerde beoordeling of het resterende risico aanvaardbaar is, gedocumenteerd in een Safety Assessment Report (SAR).
Taak 302 — Test and Evaluation Safety: ervoor zorgen dat veiligheidsbeperkingen aanwezig zijn vóór elke testactiviteit met gevaarlijke energie of operationele modi.
Taak 303 — System Safety Program Reviews: formele beoordelingen waarin de System Safety Working Group (SSWG) de gevaarstatus, open risico-items en bewijs van effectiviteit van beperkingen presenteert aan het programmakantoor.

De risicomatrix in het hart van MIL-STD-882E zet Ernst af tegen Waarschijnlijkheid. Ernst loopt van Catastrophic (Category I: dood, verlies van het systeem, ernstige milieuschade) via Critical (Category II: ernstig letsel, grote systeemschade) en Marginal (Category III: licht letsel, lichte systeemschade) naar Negligible (Category IV: minder dan licht letsel of schade). Waarschijnlijkheid loopt van Frequent (waarschijnlijk vaak voor te komen gedurende de levensduur van het systeem) via Probable, Occasional en Remote naar Improbable. Elke cel in de resulterende matrix van 4×5 draagt een Hazard Risk Index (HRI) die bepaalt wie het resterende risico moet accepteren nadat beperkingen zijn toegepast.

De HRI is geen wiskundig product — het is een ordinale rangschikking die is gedefinieerd door de risicomatrix van het programma, die het SSPP vaststelt. Een Catastrophic/Frequent-gevaar (HRI 1) vereist acceptatie door de Milestone Decision Authority; een Negligible/Improbable-gevaar (HRI 20) is acceptabel op werkgroepniveau. De praktische consequentie voor software-ingenieurs is dat de analyseproducten die zij opleveren — gevaarwerksheets, SwHA-rijen, SSR's, verificatierecords — rechtstreeks doorwerken in een risicobeheerproces met gedefinieerde bevoegdheidsniveaus. Gaten in de analyse laten het risico op een onbepaald niveau achter dat geen autoriteit kan accepteren.

Voorlopige gevaaranalyse: veiligheidskritische softwarefuncties vinden

De Preliminary Hazard Analysis (PHA) wordt vroeg in de systeemontwikkeling uitgevoerd, doorgaans voordat de gedetailleerde eisen zijn vastgesteld, op basis van functionele decompositie van het systeem en documentatie over het operationele concept. Het doel is gevaren op systeemniveau te identificeren, initiële ernst- en waarschijnlijkheidsbeoordelingen toe te wijzen en vast te stellen welke systeemfuncties — hardware, software, mens of procedure — bijdragen aan elke gevaar. De PHA vereist geen gedetailleerde ontwerpkennis; zij werkt op het niveau van 'wat kan dit systeem doen dat mensen, materieel of het milieu kan schaden?'

PHA-invoer omvat doorgaans:

Systeemconcept of operations (CONOPS) en operationele scenario's
Functionele systeem-eisen en architectuur op het hoogste niveau
Inventaris van energiebronnen en gevaarlijke stoffen
Interface-definities (met aangrenzende systemen, met operators, met het milieu)
Historische gevaargegevens van vergelijkbare systemen

PHA-uitvoer omvat een gevuld Hazard Log met unieke gevaaridentifiers, gevaarbeschrijvingen in natuurlijke taal, initiële HRI-beoordelingen en een lijst van bijdragende functies. Voor een vuurleidingssysteem kan de PHA 'Onbedoelde wapenafgifte' identificeren als een Catastrophic-gevaar (Category I) en als bijdragende functies noemen: de inzetautorisatiesoftware, het commandokanaal voor wapenafgifte, de inschakelinterlocklogica en de operatorinterface. Die lijst van bijdragende functies is het startpunt voor alle latere softwareveiligheidsanalyses.

Het onderscheid tussen een gevaar en een foutmodus is hier van belang. Een gevaar is een conditie met potentieel voor schade — 'onbedoelde wapenafgifte' is een gevaar. Een foutmodus is een mechanisme waarop een component kan falen — 'spurious activering van de FIRE_COMMAND-uitvoer' is een foutmodus. De PHA identificeert gevaren; latere analyses identificeren de foutmodi die eraan bijdragen. Het door elkaar halen van de twee in het gevaarlogboek is de meest voorkomende structurele fout in vroege-programmaveiligheidsanalyse, en die werkt door in SwHA-tabellen die moeilijk te herleiden zijn.

De bijdrage van software aan systeemgevaren is kwalitatief anders dan die van hardware. Een hardwarecomponent heeft een fysiek faalpercentage dat kan worden geschat uit velddata of versnelde tests. Softwaredefecten zijn deterministisch: bij specifieke invoer produceert een defecte functie altijd de verkeerde uitvoer. Software slijt niet, en heeft geen zinvolle mean time between failures in dezelfde zin als een relais of een klep. De waarschijnlijkheid die wordt toegewezen aan een softwarebijdrage aan een gevaar is daarom een oordeel over de kans dat de software een defect bevat dat relevant is voor dat gevaar, gewogen met de kans dat de specifieke invoercondities die het zouden activeren in de operatie optreden. Dit oordeel wordt gevoed door softwarecomplexiteit, de strengheid van het ontwikkelproces en de diepte van het testen — niet door empirische faaldata.

Software hazard analysis: software aan gevaren koppelen

Software Hazard Analysis (SwHA) is de taak die het gevaarlogboek op systeemniveau verbindt met specifiek softwaregedrag. Voor elke gevaar in de PHA die een softwarefunctie als bijdrager noemt, vraagt de SwHA: wat moet de software onjuist doen (of nalaten) opdat dit gevaar optreedt? Het antwoord noemt softwarefoutmodi op, die de causale ketens worden die SSR's moeten aanpakken.

Softwarefoutmodi vallen in vijf canonieke categorieën:

Onjuiste uitvoer: de functie wordt uitgevoerd en produceert een uitvoer, maar de uitvoerwaarde is onjuist — een commando buiten het geldige bereik, een statusvlag die is gezet terwijl die leeg zou moeten zijn, of een rekenresultaat met een rekenfout.
Geen uitvoer (weglating): de functie produceert geen uitvoer waarvan het systeem afhankelijk is — een watchdog die stopt met resetten, een gezondheidsmonitor die een fout niet meldt, een veiligheidsinterlock die het inhibit-signaal niet activeert.
Late uitvoer: de functie produceert de juiste uitvoer, maar niet binnen het vereiste tijdvenster — een schending van een realtimebeperking die ertoe leidt dat het systeem doorgaat met een verouderde of ontbrekende invoer.
Spurious uitvoer: de functie produceert een uitvoer die niet is gevraagd of die optreedt op een moment waarop die niet geldig is — een ongevraagd commando dat een actuator activeert tijdens een modus waarin dat commando gevaarlijk is.
Uitvoer naar de verkeerde bestemming: de functie routeert een geldige uitvoer naar een onjuiste interface — een commando dat voor het ene subsysteem is bedoeld, wordt door een routerings- of adresfout aan een ander geleverd.

De structuur van de SwHA-werksheet volgt een standaardpatroon. Elke rij komt overeen met één (gevaar, softwarefunctie, foutmodus)-tripel. De kolommen leggen vast: de gevaaridentifier, de gevaarbeschrijving, de naam van de softwarefunctie, de foutmoduscategorie, het effect van de foutmodus op de systeemgevaar, de ernst van de resulterende schade, de waarschijnlijkheid (als kwalitatieve beoordeling), de HRI en de afgeleide SSR-identifier die deze rij aanpakt. Een SwHA-tabel voor een flight control system kan enkele honderden rijen hebben; voor een eenvoudigere commando- en contterminal misschien dertig tot zestig.

Herleidbaarheid is de operationele kwaliteitsmaatstaf van SwHA. Elke PHA-gevaar met een softwarebijdrage moet in de SwHA voorkomen. Elke softwarefunctie die in de PHA is vermeld, moet ten minste één SwHA-rij hebben. Elke SwHA-rij moet naar ten minste één SSR verwijzen. En elke SSR moet herleidbaar zijn tot ten minste één SwHA-rij. Herleidbaarheidsgaten die tijdens overheidsveiligheidsbeoordelingen worden ontdekt, zijn de meest voorkomende oorzaak van SwHA-herwerk in de beoordelingscyclus.

De SwHA identificeert ook software-eisen die veiligheidsfuncties dienen niet omdat zij een gevaar direct voorkomen, maar omdat zij een veiligheidsmonitor in staat stellen een voorloper van een gevaar te detecteren. Deze monitoringeisen zijn even belangrijk als directe beheersingseisen — een monitor die stil faalt, ontneemt het systeem de mogelijkheid om vóór een gevaar naar de veilige toestand over te gaan. Ze vereisen dezelfde SSR-formulering en verificatiestrengheid als directe inhibit-eisen. Zie ook: formele verificatie voor defensiesoftware voor technieken die wiskundig de afwezigheid van specifieke foutmodi in veiligheidskritische modules kunnen aantonen.

Identificatie van veiligheidskritische functies en Software Safety Requirements

Een veiligheidskritische softwarefunctie is elke functie waarvan de foutmodus in de SwHA als bijdrager aan een Catastrophic- of Critical-gevaar voorkomt. De identificatie van veiligheidskritische functies is de voorwaarde voor de toewijzing van extra ontwerpstrengheid: hogere codecoveragedoelen, verplichte peer review, onafhankelijke verificatie en formele analyse.

De Software Criticality Index (SCI) formaliseert dit. Elke veiligheidskritische functie krijgt een kritiekeitscategorie op basis van het worst-case-gevolg van een fout: Category I (Catastrophic), Category II (Critical), Category III (Marginal), Category IV (Negligible). De SCI stuurt de selectie van softwareveiligheidseisen en de verificatiediepte per functie. Een Category I-functie — bijvoorbeeld de finale autorisatiecontrole vóór een wapenafgiftelcommando — rechtvaardigt de strengste behandeling die het programma kan toepassen. Een Category IV-functie — een diagnostische logschrijver — rechtvaardigt geen van de extra strengheid.

Software Safety Requirements (SSR's) worden rechtstreeks uit SwHA-rijen afgeleid. Voor elke vastgestelde foutmodus specificeert de SSR het softwaregedrag dat die foutmodus voorkomt, detecteert of mitigeert. De canonieke SSR-vormen zijn:

Positieve beperking: 'De software moet de SAFE_STATE-uitvoer activeren binnen 50 ms na detectie van verlies van een geldige heartbeat van de primaire sensor.' (Pakt aan: late/geen-uitvoer-foutmodus in de sensormonitorfunctie.)
Negatieve beperking: 'De software mag WEAPONS_RELEASE_COMMAND niet activeren tenzij ARM_CONFIRMED, TARGET_VALIDATED en OPERATOR_AUTHORIZED alle ten minste 500 ms continu zijn geactiveerd.' (Pakt aan: spurious-uitvoer-foutmodus in de afgifteautorisatiefunctie.)
Bereikbeperking: 'De bevolen azimuthuitvoer moet binnen ±180 graden liggen. Elke berekende waarde buiten dit bereik moet de software in de FAULT_HOLD-toestand laten gaan zonder het commando uit te voeren.' (Pakt aan: onjuiste-uitvoer-foutmodus in de vuurleidingsrekenfunctie.)
Monitoringeis: 'De software moet de bevolen stuwkracht met de gemeten stuwkracht vergelijken op elke cyclus van 10 ms en THRUST_FAULT_FLAG zetten als het verschil drie opeenvolgende cycli 15% overschrijdt.' (Maakt detectie van gevaarvoorlopers mogelijk.)

Elke SSR krijgt een unieke identifier (bijvoorbeeld SSR-FC-007), wordt toegewezen aan een specifieke softwarecomponent in de architectuur en ingevoerd in de herleidbaarheidsmatrix die hem koppelt aan zijn bovenliggende SwHA-rijen. Tijdens het gedetailleerde ontwerp moet elke SSR verder worden toegewezen aan een specifieke eis in de Software Requirements Specification (SRS) of het Software Design Document (SDD). De SRS/SDD-eis erft het SSR-merkteken, waardoor geautomatiseerde herleidbaarheidstools de veiligheidsaanwijzing kunnen doorgeven door de eisenhiërarchie en in de testgevalselectie.

SSR's die niet door test of analyse kunnen worden geverifieerd, wijzen op een architectuurprobleem. Als het veiligheidsgedrag niet onafhankelijk kan worden bevestigd, exposeert de softwarearchitectuur de relevante staat niet voor observatie, of is de SSR geformuleerd in termen die niet meetbaar zijn. Beide problemen moeten worden opgelost voordat het ontwerp doorgaat naar implementatie. Een SSR zonder uitvoerbare verificatiemethode is geen veiligheidsbeperking — het is een intentieverklaring.

Softwareontwerpbeperkingen voor veiligheid

Ontwerpbeperkingen zijn de architectuur- en implementatiepatronen die het door SSR's vereiste softwaregedrag betrouwbaar maken in aanwezigheid van fouten. Elke ontwerpbeperking wordt geselecteerd op basis van de foutmodus die zij aanpakt en de ernst van de gevolgen van die foutmodus. Er is geen universeel patroon — de passende beperking hangt af van de systeemarchitectuur en de specifieke gevaaroorzaak die wordt gemitigeerd.

De meest breed toepasbare patronen in militaire software zijn:

Watchdog supervision. Een hardware- of onafhankelijke softwarewatchdog vereist dat de veiligheidskritische applicatie bij elke verwerkingscyclus actief een resetsignaal activeert. Het nalaten van de reset — omdat de applicatie is gecrasht, in een oneindige loop terechtkwam of anderszins niet meer reageert — laat de watchdog time-outen en dwingt een overgang naar de veilige toestand af. De veilige toestand is door hardware gedefinieerd: uitvoeren ontkrachten, inhibits zetten, kleppen sluiten. De watchdog hoeft niet te begrijpen waarom de applicatie faalde; hij hoeft alleen te weten dat de normale werking is gestopt.

Positive-arming-sequenties. Gevaarlijke commando's vereisen dat meerdere onafhankelijke inschakelcondities tegelijk zijn vervuld voordat het commando kan worden gegeven. Geen enkele softwarefout, enkele sensorstoring of enkele operatorfout kan alle condities tegelijk vervullen. Het klassieke voorbeeld is een wapeninschakel- en afgiftesequentie: inschakelen vereist een aparte hardware-armingcircuit, een software-autorisatietoestand, een nabijheids- of doelvoorwaarde en een operatorbevestiging, alle binnen een tijdvenster. Het wegnemen van een van deze ontneemt de mogelijkheid om te vuren.

Fail-safe toestandsmachines. Veiligheidskritische besturingslogica is geïmplementeerd als een expliciete eindige toestandsmachine met een gedefinieerde veilige standaardtoestand. Elke invoer die een ongeldige toestandsovergang zou veroorzaken, wordt naar de veilige toestand geleid in plaats van naar ongedefinieerd gedrag. De toestandsmachine is zo ontworpen dat stroomverlies, verlies van communicatie of verlies van sensorgeldigheid allemaal uitkomen op de veilige toestand — er is geen pad van een foutconditie naar een gevaarlijk commando. Overweeg een vereenvoudigd voorbeeld voor een interlockcontroller:

typedef enum {
 STATE_INIT,
 STATE_STANDBY,
 STATE_ARMED,
 STATE_ENGAGE,
 STATE_SAFE /* standaard-/fouttoestand */
 } InterlockState;
 
 /* Elke onbekende invoer of ongeldige overgang gaat naar STATE_SAFE */
 InterlockState transition(InterlockState current, Event ev) {
 switch (current) {
 case STATE_STANDBY:
 if (ev == EVT_ARM_CONFIRMED) return STATE_ARMED;
 break;
 case STATE_ARMED:
 if (ev == EVT_ENGAGE_AUTHORIZED) return STATE_ENGAGE;
 if (ev == EVT_DISARM) return STATE_STANDBY;
 break;
 /* Alle andere gevallen vallen door naar de veilige toestand */
 default: break;
 }
 return STATE_SAFE;
 }
            

Plausibiliteitsmonitoring. Een onafhankelijk monitorproces vergelijkt uitvoercommando's met fysieke beperkingen. Een bevolen acceleratie die de gedocumenteerde maximale capaciteit van het voertuig overschrijdt, is onwaarschijnlijk en kan wijzen op een rekenfout of gecorrumpeerde invoer. De monitor onderschept en blokkeert het onwaarschijnlijke commando, logt de gebeurtenis en waarschuwt het gezondheidsbeheerssysteem. De monitorlogica moet onafhankelijk zijn van de rekenlogica — als beide hetzelfde algoritme gebruiken, treft een systematisch defect beide identiek en biedt de monitor geen bescherming.

Defensieve invoervalidatie. Elke veiligheidskritische functie valideert haar invoer tegen gedefinieerde geldige bereiken voordat die wordt verwerkt. Invoer buiten het geldige bereik leidt niet tot berekening op ongeldige data — zij leidt ertoe dat de functie een foutconditie activeert en een gedefinieerd foutafhandelingspad betreedt. De validatielogica moet niet alleen bereikcontroles omvatten, maar ook temporele geldigheid (is dit de meest recent bemonsterde waarde of een verouderde uitlezing?), brongeldigheid (kwam deze waarde van de verwachte afzender?) en consistentie (komt deze waarde overeen met bevestigende sensoren binnen tolerantie?).

Elke ontwerpbeperking wordt gedocumenteerd in het Software Design Document met een expliciete kruisverwijzing naar de SSR die zij implementeert. Het ontwerpbeoordelingsproces omvat een verificatie dat elke SSR een geïdentificeerde ontwerpbeperking heeft, en dat elke ontwerpbeperking is beargumenteerd als toereikend voor de foutmodus die zij aanpakt. Beperkingen die toereikend zijn voor Marginal-gevaren zijn mogelijk niet toereikend voor Critical-gevaren — het toereikendheidsargument moet specifiek zijn voor de ernst van de gevolgen.

Veiligheidsverificatiebewijs

Veiligheidsverificatiebewijs is de set records die aantoont dat elke SSR correct is geïmplementeerd in de geleverde software. De bewijsbasis moet toereikend zijn voor een gekwalificeerde beoordelaar — de overheidsveiligheidsingenieur, de veiligheidsbeoordelingsraad of de risicoacceptatieautoriteit — om te concluderen dat de software zich gedraagt zoals de safety case claimt. Bewijs dat aanwezig is maar niet herleidbaar tot SSR's, of herleidbaar tot SSR's maar onvoldoende om hun implementatie aan te tonen, sluit de safety case niet.

De primaire bewijsstypen voor softwareveiligheidsverificatie zijn:

Veiligheidsspecifieke testgevallen. Voor elke SSR worden een of meer testgevallen afgeleid die het vereiste gedrag rechtstreeks uitoefenen. De testgevallen zijn geconstrueerd uit de SwHA-foutmodi: als de SwHA-rij 'spurious activering van FIRE_COMMAND tijdens SAFE-modus' als gevaaroorzaak identificeert, past het overeenkomstige testgeval de specifieke invoercondities toe die nodig zouden zijn om dit gedrag te activeren en verifieert dat de uitvoer niet wordt geactiveerd. Testen op afwezigheid van gevaarlijk gedrag is veeleisender dan testen op aanwezigheid van correct gedrag — de testingenieur moet redeneren over alle invoerpaden die de veiligheidsfunctie kunnen bereiken en bevestigen dat geen ervan een gevaarlijke uitvoer produceert.

Code coverage voor veiligheidskritische modules. Coveragemetrics geven vertrouwen dat de testsuite de codepaden uitoefent die de SSR's implementeren. Het coveragedoel voor veiligheidskritische modules (Category I- en II-functies onder de SCI) is doorgaans 100% branch coverage als minimum, met Modified Condition/Decision Coverage (MC/DC) vereist voor functies die autorisatielogica met meerdere voorwaarden implementeren. Een branch-coveragerapport dat ongeteste branches in een veiligheidskritische module toont, is een open bevinding — ofwel is de ongeteste branch dode code die moet worden verwijderd, ofwel ontbreekt een testgeval. Coveragedata zonder een overeenkomstige SSR-herleidbaarheidskaart vormen geen veiligheidsverificatiebewijs — het bewijs zit in de koppeling tussen gedekte code en de SSR's die die code implementeert. Zie ook: softwaretesten van militaire systemen voor een volledige behandeling van de testmethodologie voor defensieprogramma's.

Software FMEA. Een software Failure Modes and Effects Analysis past de FMEA-methode toe op softwaremodules in plaats van hardwarecomponenten. Voor elke functie in een veiligheidskritische module legt de FMEA vast: het doel van de functie, de foutmodi (met de vijf canonieke categorieën uit de SwHA), het effect van elke foutmodus op de softwareuitvoer, het effect op de systeemgevaar, het detectiemechanisme (watchdog, monitor, test, operatorobservatie) en de compenserende beperking in het ontwerp. Software FMEA is het meest waardevol als kruiscontrole op de SwHA — als de FMEA een foutmodus identificeert met gevaarlijke gevolgen die niet in de SwHA voorkomt, heeft ofwel de SwHA een gat of de FMEA een valse positieve die moet worden beoordeeld. Beide uitkomsten verbeteren de safety case.

Codebeoordelingsverslagen. Peer review van veiligheidskritische code met een veiligheidsspecifiecke checklist genereert bewijs dat gekwalificeerde ingenieurs de implementatie hebben onderzocht op naleving van SSR's en ontwerpbeperkingen. De checklistitems moeten direct aansluiten op de vereiste ontwerppatronen — 'watchdog-reset wordt elke cyclus aangeroepen', 'alle invoer wordt gevalideerd vóór gebruik', 'toestandsmachine heeft geen ongedefinieerde overgangen'. Beoordelingsverslagen identificeren gevonden defecten en hun disposition; een beoordeling met nul bevindingen op een complexe veiligheidskritische module is ofwel een teken van een uitzonderlijk schone implementatie, ofwel van een onvoldoende streng beoordelingsproces, en de programsaveiligheidsingenieur moet tussen de twee kunnen onderscheiden.

Het integreren van deze bewijsstypen in de DevSecOps voor defensiepijplijnen vereist dat veiligheidsspecifieke testgevallen, coveragetools en FMEA-werksheets configuratiebeheerd zijn naast de broncode die zij verifiëren. Een testresultaat zonder configuratiebaseline die precies identificeert welke versie van de software is getest, is niet reproduceerbaar bewijs en kan niet worden ingediend in een Safety Data Package. Elk bewijsartefact vereist een documentnummer, een revisie, een datum en een koppeling naar de softwareconfiguratie-itembaseline die het dekt.

Samenstellen van de safety case en acceptatie van resterend risico

De safety case is een gestructureerd argument dat het geleverde softwaresysteem aanvaardbaar veilig is voor het beoogde gebruik. De claim is niet dat de software vrij is van defecten of dat alle risico is geëlimineerd — dergelijke claims zijn niet haalbaar en niet wat MIL-STD-882E vereist. De claim is dat: alle redelijkerwijs voorzienbare gevaren zijn geïdentificeerd; beperkingen zijn toegepast die elke gevaar tot een aanvaardbaar risiconiveau terugbrengen; de beperkingen zijn geverifieerd als correct geïmplementeerd; en de resterende risico's die na de beperkingen overblijven, zijn beoordeeld en geaccepteerd door de bevoegde autoriteit.

De documentstructuur van de safety case volgt een claim-argument-evidence-hiërarchie. Goal Structuring Notation (GSN) wordt vaak gebruikt om deze hiërarchie te visualiseren, hoewel de notatie niet verplicht is — de structuur moet aanwezig zijn, of die nu in GSN-vorm is uitgedrukt of niet. Een typische structuur op het hoogste niveau voor een software safety case van een vuurleidingssysteem:

G1: De vuurleidingssoftware is aanvaardbaar veilig voor gebruik
 in [gedefinieerde operationele context]
 
 A1: Argument over geïdentificeerde gevaren:
 alle gevaren zijn ofwel geëlimineerd, beheerst,
 of geaccepteerd als resterend risico
 
 G2: Alle Catastrophic-gevaren met softwarebijdrage
 zijn beheerst tot HRI <= 9
 E1: SwHA-werksheet rev D (CDRL AA-012)
 E2: SSR-herleidbaarheidsmatrix rev C (CDRL AA-014)
 E3: Veiligheidstestrapport rev B (CDRL AA-019)
 
 G3: Alle Critical-gevaren met softwarebijdrage
 zijn beheerst tot HRI <= 13
 E4: Software FMEA rev A (CDRL AA-021)
 E5: Codebeoordelingsverslagen (CDRL AA-022)
 
 A2: Resterende risico's beoordeeld en geaccepteerd volgens SSPP
 Sectie 4.3 bevoegdheidsmatrix
 E6: Ondertekende HRDR's voor de gevaren H-003, H-007, H-011
            

Het Safety Data Package (SDP) is de verzameling artefacten die als bewijs voor de safety case aan het programmakantoor wordt geleverd. De inhoud is vastgelegd in het System Safety Program Plan als een lijst van CDRL's met leverdata die zijn gekoppeld aan programmamijlpalen. Typische SDP-inhoud:

System Safety Program Plan (SSPP)
Preliminary Hazard Analysis (PHA)-rapport
Subsystem Hazard Analysis (SSHA)-rapporten
Software Hazard Analysis (SwHA)-werksheets
Lijst van Software Safety Requirements (SSR) en herleidbaarheidsmatrix
Software Safety Design Analysis (Taak 206)-rapporten
Software FMEA-werksheets
Veiligheidskritische softwaretestgevallen en testresultaten
Codecoveragerapporten voor veiligheidskritische modules
Codebeoordelingsverslagen voor veiligheidskritische modules
Hazard Risk Decision Reports (HRDR's) voor geaccepteerde resterende risico's
Safety Assessment Report (SAR)

Acceptatie van resterend risico is de formele handeling waarbij de risicoacceptatieautoriteit erkent dat een gevaar is beheerst tot een niveau dat boven de acceptabele drempel van het programma blijft, het bewijs beoordeelt dat de beperkingen toereikend en correct zijn geïmplementeerd, en de verantwoordelijkheid aanvaardt voor het resterende risico. Het Hazard Risk Decision Report is het instrument voor deze handeling. De HRDR beschrijft de gevaar, de toegepaste beperkingen, de resterende HRI na de beperkingen, het bewijs dat de beoordeling van de resterende HRI ondersteunt, en een aanbeveling. De bevoegde autoriteit ondertekent de HRDR en zet die daarmee om van een aanbeveling in een formeel risicoacceptatierecord.

Het safety case is een levend document. Telkens wanneer de software wordt gewijzigd — eisen veranderen, defecten worden gecorrigeerd, interfaces evolueren — moet het safety case worden beoordeeld om vast te stellen of de wijziging gevolgen heeft voor een hazard, een SSR, een ontwerpbeheersing of een bewijsitem. Een wijziging die de waarschijnlijkheid of ernst van een aanvaard residuaal risico verhoogt, vereist een nieuwe HRDR, ondertekend door de bevoegde autoriteit. Een wijziging die een nieuwe hazardoorzaak introduceert, vereist een SwHA-update en mogelijk een nieuwe SSR. Configuratiebeheer van de safety case-artefacten is daarom even belangrijk als configuratiebeheer van de broncode — een verouderd safety case dat de huidige softwarebaseline niet weerspiegelt, is in het geheel geen safety case.

De meest voorkomende faalmodus van softwaresafetyprogramma's is niet ontoereikende analyse — het is ontoereikende opvolging. De SwHA wordt uitgevoerd, de SSR's worden opgesteld, de ontwerpbeheersingen worden geïmplementeerd, en daarna gaat de testplanning verder zonder systematisch verband tussen de SSR's en de testgevallen. De coveragedata wordt verzameld zonder kaart naar de veiligheidscritische modules. De FMEA wordt na de codereview geschreven in plaats van ervoor. Het resultaat is een verzameling afzonderlijk plausibele artefacten die niet tot een coherent argument samenkomen. De taak safety case-assembly is waar deze breuken zichtbaar worden — en ze aanpakken vóór programmareviews in plaats van tijdens die reviews is het verschil tussen een verdedigbaar safetyprogramma en een dure herwerkcyclus.

Veelgestelde vragen

Wat is MIL-STD-882E en hoe verschilt het van eerdere revisies?

MIL-STD-882E, uitgegeven in 2012, is de huidige revisie van de DoD-standaard voor System Safety. De belangrijkste wijzigingen ten opzichte van MIL-STD-882D zijn strengere taal over software-systeemveiligheidstaken — met name Taak 205 (Software Safety Requirements Analysis) en Taak 206 (Software Safety Design Analysis) — en de toevoeging van expliciete taakbeschrijvingen voor energiesystemen en autonome systemen. De 882E-revisie verscherpte ook de eis voor software hazard analysis (SwHA) om elke gevaaroorzaak te herleiden tot een specifieke softwarecomponent of -gedrag, in plaats van software als een monolithische black box te behandelen. De risicomatrix behoudt dezelfde ernstcategorieën (Catastrophic, Critical, Marginal, Negligible) en waarschijnlijkheidscategorieën (Frequent, Probable, Occasional, Remote, Improbable) uit eerdere revisies, maar 882E vereist expliciet dat de Hazard Risk Index (HRI) de middelentoewijzing stuurt in alle programmafases, van concept tot en met afstoting.

Wat is een softwaresafety case en hoe verschilt die van een systemsafetyplan?

Een systeemveiligheidsplan (SSP) beschrijft het proces dat wordt gevolgd om veiligheid te beheren over de levenscyclus van een programma — wie welke analyses uitvoert, op welke mijlpalen, en hoe resultaten worden gedocumenteerd. Een software safety case is een op bewijs gebaseerd argument dat een specifiek softwareartefact aanvaardbaar veilig is voor de beoogde operationele context. De safety case beantwoordt de vraag: gegeven wat we weten over het gedrag van deze software, kunnen we met bewijs aantonen dat het resterende risico aanvaardbaar is? Hij structureert bewijs in een claim-argument-evidence-hiërarchie: veiligheidsclaims op het hoogste niveau (bijvoorbeeld 'de vuurleidingssoftware zal geen wapenafgifte opdrachten tenzij aan alle inzetcriteria is voldaan'), ondersteunende argumenten (gevaaranalyse, ontwerpbeperkingen, verificatieresultaten) en bewijsitems (testrapporten, codebeoordelingsverslagen, FMEA-werksheets). Het onderscheid is van belang omdat een programma zijn SSP perfect kan volgen en toch een zwakke safety case kan opleveren als de analyse oppervlakkig is of de bewijsbasis dun.

Welke MIL-STD-882E-taken zijn verplicht voor een software-intensief wapensysteem?

MIL-STD-882E schrijft geen taken universeel voor — de contracterende activiteit selecteert taken die passen bij het programmarisico. Voor software-intensieve wapensystemen bij Milestone B en later zijn de taken die programmakantoren het meest consistent eisen: Taak 101 (System Safety Program Plan), Taak 201 (Preliminary Hazard Identification), Taak 202 (Preliminary Hazard Analysis), Taak 203 (Subsystem Hazard Analysis), Taak 205 (Software Safety Requirements Analysis), Taak 206 (Software Safety Design Analysis), Taak 301 (Safety Assessment), Taak 302 (Test and Evaluation Safety) en Taak 303 (System Safety Program Review). De taken 205 en 206 zijn de primaire softwarespecifieke taken. Taak 207 (Health Hazard Assessment) is doorgaans ook vereist voor systemen met mens-interfacecomponenten. De Statement of Work (SOW) en Contract Data Requirements List (CDRL) van het programma specificeren welke taken zijn gecontracteerd.

Hoe werkt de MIL-STD-882-risicomatrix in de praktijk?

De MIL-STD-882E-risicomatrix zet Ernst (vier rijen: Catastrophic, Critical, Marginal, Negligible) af tegen Waarschijnlijkheid (vijf kolommen: Frequent, Probable, Occasional, Remote, Improbable) om voor elke geïdentificeerde gevaar een Hazard Risk Index (HRI) te produceren. De resulterende matrix van 20 cellen is doorgaans kleurgecodeerd: High risk (HRI 1–5) vereist een risicoacceptatiebevoegdheid op programmaniveau, vaak de PM of hoger; Serious risk (HRI 6–9) vereist acceptatie door engineeringmanagement; Medium risk (HRI 10–17) vereist acceptatie op engineeringniveau; Low risk (HRI 18–20) is aanvaardbaar met documentatie. De praktische uitdaging is dat de schatting van Waarschijnlijkheid voor nieuwe softwaregedragingen subjectief is — software heeft geen faalpercentages in de traditionele betrouwbaarheidszin, omdat softwaredefecten deterministisch zijn bij specifieke invoer. De meeste programma's gebruiken kwalitatieve waarschijnlijkheidstoewijzingen op basis van softwarecomplexiteit, testdiepte en vertrouwen in ontwerpbeperkingen in plaats van statistische faaldata.

Wat is Software Hazard Analysis (SwHA) en welke invoer vereist die?

Software Hazard Analysis (SwHA) is een gestructureerd proces dat systeemniveau-gevaren die zijn geïdentificeerd in de Preliminary Hazard Analysis (PHA) of Subsystem Hazard Analysis (SSHA) herleidt tot specifiek softwaregedrag dat die gevaren kan veroorzaken of bijdragen eraan. SwHA-invoer omvat het systeemgevaarlogboek, de functionele architectuur (welke functies software-geïmplementeerd zijn), de software requirements specification (SRS), interface control documents (ICD's) en operationele modi en toestanden. Voor elke systeemgevaar vraagt het SwHA-team: welke softwarefuncties zouden, als ze falen of zich misdragen, deze gevaar kunnen initiëren, eraan bijdragen of niet kunnen mitigeren? Voor elke dergelijke softwarefunctie identificeert het de foutmodi (onjuiste uitvoer, geen uitvoer, late uitvoer, spurious uitvoer) en herleidt die tot specifieke software-eisen of ontwerpelementen. De uitvoer is een SwHA-werksheet die elke gevaaroorzaak koppelt aan een softwarecomponent, een foutmodus en een afgeleide softwareveiligheidseis.

Hoe worden Software Safety Requirements (SSR's) afgeleid uit gevaarsanalyse?

Software Safety Requirements (SSR's) worden afgeleid door elke gevaaroorzaak die in de SwHA is geïdentificeerd te onderzoeken en te vragen: wat moet de software doen (of nalaten) om deze oorzaak te elimineren, de waarschijnlijkheid te verkleinen of de gevolgen te beperken? Elke SSR is een beperking van softwaregedrag die rechtstreeks een gevaaroorzaak aanpakt. Voorbeelden: 'De software mag de FIRE_COMMAND-uitvoer niet activeren tenzij het system_armed-signaal ten minste 500 ms continu is geactiveerd' (pakt een foutmodus van spurious uitvoer aan); 'De software moet binnen 100 ms na detectie van een sensor_validity_fault naar SAFE_STATE overgaan' (pakt een oorzaak van niet-mitigeren aan). SSR's worden toegewezen aan specifieke softwarecomponenten in de SRS en moeten bidirectioneel herleidbaar zijn tot de gevaaroorzaken die ze hebben gegenereerd. Tijdens verificatie moet elke SSR worden getest of geanalyseerd om aan te tonen dat die correct is geïmplementeerd. SSR's die niet kunnen worden geverifieerd, worden opnieuw onderzocht om vast te stellen of ze uitvoerbaar zijn of dat de gevaar een hardwarebeperking vereist.

Welke fail-safe-ontwerppatronen zijn het meest toepasbaar op militaire software?

De meest breed toepasbare fail-safe patronen in militaire software zijn: (1) De-energize-to-safe — de veilige toestand wordt bereikt door stroom of een commandosignaal weg te nemen, zodat stroomverlies of communicatiefout standaard naar veilig gaat in plaats van naar een ongedefinieerde toestand; (2) Positive arming — wapens en hoge-energiesystemen vereisen meerdere onafhankelijke inschakelcondities, die allemaal tegelijk moeten zijn vervuld, in plaats van te vertrouwen op één inhibit; (3) Watchdog supervision — een hardware- of softwarewatchdog vereist dat de veiligheidskritische applicatie die actief reset bij elke verwerkingscyclus; het nalaten van de reset activeert een overgang naar de veilige toestand; (4) Plausibility monitoring — onafhankelijke monitorlogica vergelijkt uitvoercommando's met fysieke beperkingen (bijvoorbeeld bevolen acceleratie vs. voertuigcapaciteit) en overrulet onwaarschijnlijke commando's; (5) Voted redundancy — twee-van-drie- of twee-van-vier-stemarchitecturen voorkomen dat één softwarefout een onveilige uitvoer produceert. De keuze van welk patroon past hangt af van de aangepakte foutmodus en de architectuurbeperkingen van het systeem.

Welke codecoveragedoelen zijn vereist voor veiligheidscritische software onder MIL-STD-882?

MIL-STD-882E specificeert geen codecoveragemetrics direct — coveragedoelen worden doorgaans vastgelegd in het Software Development Plan (SDP) of afgeleid uit de toepasselijke softwarestandaard die het contract noemt (bijvoorbeeld DO-178C voor boordsystemen, IEC 61508 voor grondsystemen). Onder DO-178C vereist Level A 100% Modified Condition/Decision Coverage (MC/DC) — elke voorwaarde in elke beslissing moet de beslissingsuitkomst onafhankelijk beïnvloeden. Level B vereist Decision Coverage (100% branch coverage). Voor MIL-STD-882 Category I-software (Catastrophic severity) die niet onder DO-178C valt, onderhandelen programmakantoren doorgaans minimale coveragedoelen met de aannemer in het System Safety Program Plan: gebruikelijke doelen zijn 100% statement- en branch coverage voor veiligheidskritische modules, met MC/DC vereist voor functies die rechtstreeks veiligheidseisen implementeren. FMEA op softwaremodules, gecombineerd met coveragemetrics, levert een vollediger beeld van het bewijs dan coverage alleen.

Wat is de structuur van een softwaresafety case-document?

Een software safety case is doorgaans gestructureerd als een Goal Structuring Notation (GSN)-argument of een equivalente gestructureerde claimhiërarchie. De structuur op het hoogste niveau is: (1) Systeemcontext — operationele omgeving, veiligheidsgrens en aannames over operatorgedrag en fysieke interfaces; (2) Veiligheidsclaims — één claim op het hoogste niveau per systeemveiligheidsdoel, afgeleid van de baseline van veiligheidseisen; (3) Ondersteunende argumenten — ontbonden deelclaims die elk veiligheidsdoel koppelen aan ontwerpbeperkingen, softwareveiligheidseisen en verificatiebewijs; (4) Bewijsitems — testrapporten, codebeoordelingsverslagen, FMEA-werksheets, updates van gevaaranalyses en registers van resterende risico's, elk gerefereerd vanuit het argument dat zij ondersteunen; (5) Verklaring van resterend risico — een formele lijst van geaccepteerde resterende risico's, hun HRI en de autoriteit die ze heeft geaccepteerd. Het safety case-document is een levend artefact dat bij elke programmamijlpaal wordt bijgewerkt en wordt ingediend als onderdeel van het Safety Data Package bij het programmakantoor.

Wie is bevoegd om residuaal risico te aanvaarden onder MIL-STD-882E?

MIL-STD-882E definieert de bevoegdheid voor risicoacceptatie op basis van de Hazard Risk Index. Voor High risk (HRI 1–5) is de acceptatiebevoegdheid de Milestone Decision Authority (MDA) of Component Acquisition Executive — een vlagofficier of Senior Executive Service-niveau. Voor Serious risk (HRI 6–9) de Program Executive Officer (PEO) of equivalent. Voor Medium risk (HRI 10–17) de Program Manager (PM). Voor Low risk (HRI 18–20) de System Safety Working Group (SSWG) of gedelegeerde engineeringautoriteit. In de praktijk stelt het systeemveiligheidsteam van de aannemer voor elke gevaar met High of Serious risk een Hazard Risk Decision Report (HRDR) op, waarin de gevaar, de toegepaste beperkingen, het resterende risico en een aanbeveling worden gedocumenteerd. Het overheidsprogrammakantoor beoordeelt en ondertekent de HRDR, die daarna een formeel risicoacceptatierecord wordt in het Safety Data Package.

Wie is bevoegd om resterend risico te accepteren onder MIL-STD-882E?