What H SystSäk 2022 asks of suppliers

H SystSäk 2022 — the Swedish Armed Forces' system safety handbook, version 3.0, in force since September 2022 — is openly published and freely downloadable from FMV's system safety pages, together with supplier guidance and document templates. It organises the work around four roles, three of which meet a typical supplier: the kravställare (the Armed Forces, who set the requirements and ultimately issue the approval), the beställare (FMV, who contracts and directs the work), and the konstruktör — the supplier, who realises the technical system and issues its own formal safety statement. (The fourth, the systemintegratör, secures the interplay in systems-of-systems and sits with FMV or the Armed Forces.) Requirements flow down that chain, and the supplier may add more activities than the beställare required — dropping a selective activity takes a conscious, documented decision in the plan.

Two things about timing matter more than anything else in the handbook. First: the supplier's system safety work begins as soon as the contract is signed — the activities are scoped into the agreement itself, not bolted on before delivery. Second: the handbook notes that a preliminary Systemsäkerhetsplan — the system safety programme plan, SSPP — can be used before contract, to evaluate a potential supplier's understanding of and priority on system safety. Your grasp of this discipline is being assessed while you are still bidding.

The supplier's central document is the SSPP (TASK 102) — part of the agreement, with content and scope governed by the contract. It describes the system and the organisation, the applicable EU and Swedish legislation and standards and how the requirements analysis will be carried out, the tolerable risk level expressed in risk matrices, the chosen paths through the assessment model, which analyses will be performed, how verification and validation are done, how hazards are closed and restrictions handled, how the closing documents are produced — and which system safety requirements the supplier will place on its own sub-suppliers. The supplier may add activities beyond what the beställare required; it may not silently drop them.

Behind the plan sits an activity catalogue in five sections — planning and management, analyses, evaluation, verification, and decisions — largely based on MIL-STD-882E's task structure, with a Swedish fifth section for the formal safety decisions. Each section has mandatory activities and a selective tier, and selectively chosen activities can sometimes be replaced by activities from other standards or the supplier's own equivalents — provided every choice, and every simplification against the activity descriptions, is documented in the SSPP. Working to another established system safety standard is possible on the same terms — the handbook notes the work may need complementing with the unique Swedish activities and a cross-reference list between the standards. Tailoring is allowed; undocumented tailoring is not.

The analyses open with the hazards. The functional hazard analysis (FHA) identifies the safety-critical functions — including those realised in software, which go on to criticality levels handled per H ProgSäk, FMV's 2018 companion handbook for software in safety-critical applications, whose own foreword states the principle plainly: the handbook has no legal status of its own; its requirements become binding when the procuring side places them in the contract. Together with the hazard list (PHL) and hazard analysis (PHA), the FHA then feeds the Systemsäkerhetskravanalys (SRHA, TASK 203), where the supplier turns EU law, Swedish legislation, standards, the contract and its own internal requirements — plus the counters to the identified hazards — into system safety requirements, each one verifiable, because it is picked up again in the verification activity at the end.

From there the chain descends into the levels a supplier actually designs at: subsystem, system, and handling — use, maintenance, storage and transport. And the handbook is precise about what ends up in the risk matrix: only the hazards that could not be closed by the assessment model's other paths are assessed against the tolerable risk level — four consequence classes (I–IV) crossed with six probability classes (A–F, where F is reserved for hazards designed out entirely), with the boundary between red and yellow defining the risk level the Armed Forces can accept. The Armed Forces' general matrices apply unless special reasons exist; a matrix adapted for a product area or a specific system is defined in the Armed Forces' own management plan (SSMP) and reaches the supplier through the requirement documents — the SSPP then restates the tolerable risk level expressed in those matrices.

The handbook's assessment model — the vägvalsmodell — is how a supplier argues that the system is safe enough. Seven paths: statutory requirements, approval by another state, approval by another party, other established standards, design rules, proven systems, and finally the risk matrices for whatever remains. The supplier proposes the paths in its SSPP; changes are agreed with the beställare within the contract and documented. One path is explicitly closed to industry: a supplier cannot invoke another state's approval in its own assessment.

For an automotive-heritage supplier, the fourth path — vägval 4 — is where the existing evidence enters: work to established standards counts, provided the motives for the chosen standards are stated, the applied requirements — including the selected criticality level — are set out, and verification criteria exist with results showing the requirements are met. This is exactly where ISO 26262 and IEC 61508 evidence meets the handbook, together with the cross-reference list we described in the ISO 26262 vs MIL-STD-882E comparison. The handbook also polices the quality of the argument itself: claims that the user cannot be assumed to make certain errors are called out as false arguments that must not occur, and an independent third party's certification against a standard weighs heavier as evidence than self-verification against the same standard.

The evidence spine is the Riskhanteringssystem (HTS — the hazard tracking system, TASK 106) and its risk log — and it is a relay, not a report. The kravställare seeds the log with the commonly occurring hazards, the beställare may supplement it, the supplier adds every hazard identified during development, and at delivery the beställare takes the log over for continued management — before handing it on to the kravställare for the concluding stage, so the log is maintained across all three actors for the system's whole life. Each entry carries the assessment before and after mitigation, the verification method, the acceptance decisions and the current status. A log like that, maintained for decades across organisations, is a configuration-management problem as much as a safety one — the same record discipline our diagnostics platforms are built on.

The closing documents follow from the record. The Systemsäkerhetsrapport (SAR, TASK 301) summarises the work: compliance against legislation and contract, each hazard described, the chosen paths and their motives. Verification (TASK 401) shows the requirements are met and the system answers the need — and feeds the supplier's decision document: the Systemsäkerhetsutlåtande (SCA), the supplier's formal position before delivery that the legislation in force at delivery and the customer's system safety requirements are fulfilled, built from the arguments and evidence of the applied paths. Note the boundary: the supplier states; it never approves. The declaration on top — the Systemsäkerhetsdeklaration (SSD) — is the beställare's, and the approval — the Systemsäkerhetsgodkännande (SSG) — together with the decisions on use at central and local level, belongs to the Armed Forces.

Most of what H SystSäk 2022 asks for is discipline an automotive supplier already has: requirement-driven analysis, severity-graded rigour, verification with evidence, configuration control and a traceable record from hazard to closure. What must be learned is the frame around it — the activity names and their deliverables, the role boundaries, the vägval argumentation, and the Swedish decision chain from SCA to approval. The handbook itself lowers the barrier: it is public, its companion H ProgSäk is public, MIL-STD-882E is public, and FMV publishes supplier guidance and templates for the SSPP, the SAR and the risk log openly. The barrier is not access — it is translation.

That translation is the journey we are on ourselves: we continuously learn from the handbook and shape our delivery model around its activities — how we work with standards sets out where we stand, and the defence overview shows the programmes the discipline comes from. For a supplier weighing the step into Swedish defence, the honest advice is the handbook's own: start the system safety work with the bid, not after the contract — because by the time a preliminary SSPP is on the table, the evaluation of your discipline has already begun.