Work items required in ISO 26262, IEC 61508, and ISO 13849

A work item in WCGW is equivalent to a work product. Work items are intentionally untyped so that we can support a breadth of standards without hard-coding their schemas. Inside each work item you build a graph of concept nodes; each node type names the kind of safety information it contains.

This article maps each of the three supported standards (ISO 26262, IEC 61508, ISO 13849) to the twelve WCGW lifecycle phases, showing which concept types you typically produce in each phase.

The key takeaway is practical: create work items for every relevant phase and for every system boundary you are assessing, but start with the smallest set needed to think about functional safety proactively.

WCGW lifecycle phases

Item Definition → HARA → Functional Safety → Technical Safety → System Design → Software Design → Implementation → Verification → Validation → Production → Operation → Decommissioning

Not every standard touches every phase. The tables below call out which phases are active for a given standard and which concept types belong there.

Use one work item per lifecycle phase for the boundary you are assessing. For early proactive thinking, a small set of work items is enough:

• one item definition work item to capture the product and its boundaries,
• one HARA work item to capture hazards, harms, and safety goals,
• one functional safety work item to capture the top-level requirements,
• and one technical safety work item to establish how that boundary is realized.

For example, imagine a simple automated warehouse gate system:

• Item Definition: define "Automated Gate" as the boundary, list sensors, actuators, and external vehicles.
• HARA: capture hazards such as "gate closes on a person" and harms like "crush injury", then derive safety goals.
• Functional Safety: define requirements such as "detect obstruction before closing" and "stop gate motion on fault".
• Technical Safety: define how the gate control is implemented, including redundant sensors, safety-rated motor stops, and safe state logic.

Later, add System Design, Software Design, Verification, Validation, and Operation work items as the project matures and more evidence is needed.

ISO 26262 — Road vehicles (automotive)

Key points:

• ISO 26262 is the only standard that uses Hardware Safety Requirement and Software Safety Requirement as separate concept types — they emerge at System Design and Software Design respectively.
• It also introduces Failure Rate at System Design for hardware metrics and FMEDA.
• Implementation is handled within System Design and Software Design and does not produce its own concept types.

IEC 61508 — General industry (the umbrella standard)

Key points:

• IEC 61508 does not use Hardware Safety Requirement or Software Safety Requirement — everything is a Technical Safety Requirement.
• The Safety Goal carries the SIL target and is the central concept.
• IEC 61508 covers all 12 lifecycle phases, including Decommissioning.

ISO 13849 — Machinery (control systems)

Key points:

• ISO 13849 is the only standard that uses Diagnostic Coverage, Common Cause Failure, and Failure Rate explicitly at the Verification phase for PL calculation.
• Architecture (Category B/1/2/3/4) is surfaced as a first-class concept rather than being buried inside a requirement node.
• Proof Test appears in Production and Operation for periodic proof-test documentation.
• Implementation is handled within System Design and Software Design and does not produce its own concept types.

Side-by-side comparison

How phases map to WCGW templates

See Top 5 Templates for an overview of the most useful templates and how they align to this phase mapping.

In conclusion

Use the WCGW templates to scaffold the concept structure for your standard and lifecycle phase. Each template pre-configures the relevant concept types and relation patterns, leaving you to fill in the domain content.

Start with the minimum viable work item set for the boundary you are analyzing. A single Item Definition work item, a HARA work item, a Functional Safety work item, and a Technical Safety work item are often enough to begin functional safety thinking proactively. Then expand the set by adding items for each phase and each system boundary as your design and evidence build out.

This approach keeps the work manageable while still ensuring the right safety elements are captured early.

Ready to build your safety case? Start a free trial