4. Model artifacts in safety cases

A safety case is an argument, but it is an argument built out of artifacts. The claim that a system is acceptably safe is only as credible as the evidence attached to it, and in modern practice most of that evidence is model-based. Behavioral models, fault trees, FMEA tables, and simulation models are not merely analysis outputs produced along the way; they are evidence nodes in the traceability graph, each with inputs, assumptions, a producing tool, a version, and a defined relationship to the requirements and hazards it addresses. Treating them as nodes rather than documents is what makes the safety case auditable.

The central difficulty is that these four artifact types have fundamentally different semantics. A behavioral model describes what the system is supposed to do; a fault tree describes how it can fail; an FMEA table enumerates failure modes at component granularity; a simulation model produces time-domain evidence about whether a requirement holds under specific conditions. If traceability links are drawn without respecting these semantics, the resulting graph looks complete but proves nothing. The sections below examine each artifact type as an evidence node, then show how they connect.

Behavioral models as the reference semantics

A behavioral model — a Stateflow chart, a Simulink subsystem, an AADL or SysML state machine, or a formal specification — defines the intended behavior against which hazards and test conditions are interpreted. As an evidence node, its traceable attributes are the model identifier, the version or commit hash, the configuration parameters that affect behavior (sample time, solver settings, variant selections), and the requirements it satisfies. The critical traceability link runs from each requirement to the specific model element that implements it, not merely to the model file. A link from "REQ-BRK-014: brake pressure shall ramp within 200 ms" to BrakeController.slx is too coarse to audit; the link must terminate at the ramp-rate limiter block and its parameterization.

Behavioral models also carry the assumptions that later artifacts inherit. If the model assumes a 10 ms task period, then every fault tree gate and every simulation run that depends on that model is only valid under the same assumption. Recording these as explicit assumption nodes — linked to the model and to every downstream artifact that relies on them — is what allows an assessor to detect when a change invalidates a whole subtree of evidence.

Fault tree models as deductive evidence

A fault tree is a deductive argument: a top event (usually a hazard) is decomposed through Boolean gates into basic events. As an evidence node, the fault tree's traceable attributes include the top event identifier, the gate structure, the basic events with their failure rate sources, the cut sets, and the quantification method. The traceability links are of two kinds. Upward, the top event must link to a hazard in the hazard log. Downward, each basic event must link to the component or failure mode it represents — and here the FMEA table becomes the natural partner, because a basic event such as "pressure sensor stuck-at-low" should resolve to a specific FMEA row rather than to a free-text description.

Quantification introduces a second layer of traceability that is frequently lost. If the top event probability is computed as 3.2×10⁻⁹ per hour, that number depends on the basic event rates, the mission time, the assumption of independence between cut sets, and the treatment of common-cause failures. Each of these is an input that must be versioned alongside the tree. When a supplier updates a failure rate from 1×10⁻⁶ to 2×10⁻⁶ per hour, the traceability graph should propagate the change to every tree and every claim that consumed the old value.

FMEA tables as inductive, component-level evidence

Where the fault tree deduces from hazard to cause, the FMEA table induces from component to effect. Its rows are the finest-grained evidence nodes in most safety cases: each row names a component, a failure mode, a local effect, a system-level effect, a severity, a detection method, and a mitigating measure. Traceability from an FMEA row runs in three directions — to the design element (part number, schematic reference, software unit), to the hazard or fault tree basic event it supports, and to the verification activity that demonstrates the detection or mitigation actually works.

The most common traceability defect in FMEA tables is orphaned mitigation. A row states "detected by plausibility check" but no link exists to the test case or simulation run that exercises the check under the relevant failure mode. The mitigation is asserted, not evidenced. A well-formed FMEA node therefore carries a mandatory link to verification evidence for every claimed detection or control.

Simulation models as condition-bound evidence

Simulation models produce the evidence that is most sensitive to conditions, and therefore the most valuable to trace precisely. A simulation run is only evidence for a claim if the test conditions are recorded: input stimulus, initial state, environmental parameters, solver and step size, and the pass/fail criterion. The traceable node is not the model file but the run — a specific configuration producing a specific result. This is where the course's central theme, traceability from test conditions to models, becomes concrete: the simulation node links backward to the behavioral model version and forward to the requirement it verifies, with the test conditions as an explicit intermediate node.

Connecting the four artifact types

The four artifact types form a coherent evidence structure when linked through shared identifiers rather than through prose. The diagram below shows the canonical connection pattern: requirements anchor behavioral models; behavioral models and FMEA rows jointly feed fault trees; simulation runs bind behavioral models to test conditions and verify both requirements and FMEA mitigations.

Practical construction: a worked traceability slice

Consider a brake-by-wire controller. The requirement REQ-BRK-014 states that commanded brake pressure shall reach 90% of target within 200 ms. The behavioral model BrakeController.slx v3.4.1 implements this through a ramp-rate limiter whose parameter max_ramp_kPa_per_ms is set to 12. The FMEA row FM-07 records that a stuck-at-low pressure sensor is detected by a plausibility check comparing commanded and measured pressure with a 40 kPa threshold over 20 ms. The fault tree FT-BRK-02 takes "unintended loss of brake pressure" as its top event and uses FM-07 as a basic event with rate 1×10⁻⁶ per hour. The simulation run executes the model with stimulus profile S-12 across 0–40 °C and records 4.1% overshoot against a 5% limit.

To make this slice auditable, the engineer records the following links in the traceability repository:

With this structure in place, a change to the ramp parameter immediately surfaces the affected simulation runs and the claim they support. A supplier failure-rate update propagates to FT-BRK-02 and to any claim that cites its probability. An assessor reviewing REQ-BRK-014 can walk from the requirement to the implementing block, to the run that exercised it under stated conditions, and to the fault tree and FMEA rows that address its failure behavior — without reading a single narrative paragraph.

The discipline that makes this work is consistency of node identity across tools. A requirement identifier, a model element path, an FMEA row key, a fault tree basic-event name, and a simulation run identifier must each be stable and unique, and the links between them must be stored as data rather than described in documents. When that holds, the four artifact types stop being separate deliverables and become what a safety case actually needs: a connected, challengeable, and re-verifiable body of evidence.