Dependability Analysis

The dependability_analysis rule summarizes the all the dependability analyses (Safety / Security) for a dependable element. A single element may have multiple dependability analyses.

Overview

Why safety analysis?

Safety analysis is required to systematically identify failures that could violate safety goals and to demonstrate that appropriate countermeasures are in place. In ISO 26262 terms it provides the evidence that residual risk is acceptable.

How FMEA works

A Failure Mode and Effects Analysis (FMEA) follows three steps for each public interface of the software module:

Identify failure modes — apply structured fault models (see below) to each public interface to derive what can cause a violation of a overarching safety goal.
Analyse effects and causes — document the effect on the system and decompose to root causes using a Fault Tree Analysis (FTA).
Define countermeasures — for every root cause specify a ControlMeasure (or PreventiveMeasure / Mitigation) and trace it back through the FTA to the failure mode.

Fault models

The failure modes to consider are defined by the SCORE process:

FMEA Fault Models — Process Description

The fault models cover three categories: messages (send/receive behaviour), time constraints (too early / too late), and execution (wrong result, loss, delay, corruption, non-determinism). The Guideword enum in the ScoreReq model maps each category to a structured label used in the FailureMode records.

The description below covers the FMEA-based safety analysis for a software module.

Bazel Rule `dependability_analysis`

load("@score_tooling//bazel/rules/rules_score:rules_score.bzl",
     "dependability_analysis")

dependability_analysis(
    name = "my_da",
    fmea = [":my_fmea"],
)

Generated targets: <name> — build produces the documentation and traceability report; bazel test validates the full chain.

FMEA

The Failure Mode and Effects Analysis (FMEA) is the core safety analysis method used by dependability_analysis. Each fmea target bundles four types of artifacts that must be linked together:

Artifact	Format	What it represents
Public API Interfaces	PlantUML (from `architectural_design.public_api`)	Interfaces where failures can manifest; referenced by `FailureMode.interface`
Failure Modes	TRLC (`.trlc`)	Effects identified in the FMEA: what can go wrong and its impact
FTA Diagrams	PlantUML (`.puml`)	Fault Tree Analysis: structural decomposition of each failure mode into root causes
Control Measures	TRLC (`.trlc`)	Countermeasures that address the root causes identified in the FTA

The public API connects the architectural view to the safety analysis: FailureMode.interface references an interface name defined in the public_api of the architectural_design target.

The FTA artifacts are linked by a shared naming convention: the TRLC fully-qualified record name (package + record name) must match the alias used in the FTA PlantUML diagram. This is how traceability is established automatically in the report.

Failure Modes (TRLC)

A failure mode is a FailureMode record in the ScoreReq model:

package MySeooc

import ScoreReq

ScoreReq.FailureMode FM_001 {
    guidewords     = [ScoreReq.Guideword.LossOfFunction]
    description   = "Key-value store returns stale data after power loss"
    failureeffect = "Incorrect system state at startup"
    safety        = ScoreReq.Asil.B
    interface     = "KeyValueStore.read"
    version       = 1
}

The TRLC fully-qualified name of this record is MySeooc.FM_001. This name is used as the $TopEvent alias in the FTA diagram.

FTA Diagrams (PlantUML)

Each failure mode gets a Fault Tree Analysis diagram. A dedicated PlantUML metamodel (fta_metamodel.puml) provides the graphical elements — it is located at plantuml/fta_metamodel.puml in the score-tooling repository. Your diagram uses procedure calls from that metamodel; no standard PlantUML shapes are needed.

Every .puml FTA file must begin with !include fta_metamodel.puml so that the procedure definitions are available.

Available procedures

Procedure	Description
`$TopEvent(name, alias)`	The top-level failure mode. `alias` must equal the fully-qualified TRLC name of the corresponding `FailureMode` record (e.g. `MySeooc.FM_001`)
`$IntermediateEvent(name, alias, connection)`	An intermediate cause. `connection` is the alias of the parent node this event feeds into
`$BasicEvent(name, alias, connection)`	A root cause (leaf node). `alias` must equal the fully-qualified TRLC name of the corresponding `ControlMeasure` record. `connection` is the alias of the parent gate
`$AndGate(alias, connection)`	AND gate. All children must occur for the parent to trigger. `connection` is the alias of the parent node
`$OrGate(alias, connection)`	OR gate. Any single child is sufficient to trigger the parent. `connection` is the alias of the parent node
`$TransferInGate(name, alias, connection)`	Transfer-in gate linking to another FTA sub-tree

Linking procedures together

Each element points to its parent via the connection parameter — the arrow goes from the element up to the parent. Build the tree bottom-up:

Declare the $TopEvent first (no connection parameter — it is the root).
Declare gate(s) with connection set to the $TopEvent alias.
Declare $BasicEvent / $IntermediateEvent nodes with connection set to the enclosing gate’s alias.

$TopEvent  ← root, no connection
    └── $OrGate(alias="OG_1", connection="TopEvent.alias")
            ├── $BasicEvent(alias="CM_A", connection="OG_1")
            └── $BasicEvent(alias="CM_B", connection="OG_1")

The $BasicEvent alias IS the fully-qualified TRLC name (Package.RecordName) of the corresponding ControlMeasure record. No separate linking step is needed — the naming convention is the link.

Example FTA diagram

@startuml MySeooc_FTA
!include fta_metamodel.puml

$TopEvent("KVS returns stale data after power loss", "MySeooc.FM_001")

$OrGate("OG_1", "MySeooc.FM_001")

$BasicEvent("Write not flushed to storage", "MySeooc.RC_001", "OG_1")
$BasicEvent("Corruption on unclean shutdown", "MySeooc.RC_002", "OG_1")

@enduml

Control Measures (TRLC)

For each $BasicEvent in your FTA diagram, define a ControlMeasure record whose fully-qualified name matches the event alias:

package MySeooc

import ScoreReq

ScoreReq.ControlMeasure RC_001 {
    description = "The KVS implementation shall use a write-ahead log and
                   flush it synchronously before acknowledging a write"
    safety      = ScoreReq.Asil.B
    version     = 1
}

ScoreReq.ControlMeasure RC_002 {
    description = "On startup, the KVS shall detect and recover from
                   partially written records using the write-ahead log"
    safety      = ScoreReq.Asil.B
    version     = 1
}

The alias MySeooc.RC_001 in the FTA diagram matches the TRLC record RC_001 in package MySeooc. This is how the traceability link is established.

Other measure types

The SCORE requirements model also defines PreventiveMeasure and Mitigation, both extending the same abstract Measure base type as ControlMeasure. Their Bazel and TRLC usage follows the same pattern; the record type name changes but the FTA alias convention (package + record name matching the $BasicEvent alias) is identical.

`fmea` — Bazel Rule

For the complete fmea attribute reference, see fmea in the rule index.

Traceability Validation

Running bazel test //my/package:my_da executes a traceability check that validates the complete chain:

      public_api interface ← FailureMode.interface
                                        |
                                    $TopEvent
                                        |
                                 AND / OR gate(s)
                                        |
                                   $BasicEvent
                                        |
                                  ControlMeasure

The check fails if:

A $TopEvent alias does not match any FailureMode record name
A $BasicEvent alias does not match any ControlMeasure record name
A FailureMode or ControlMeasure is defined but not referenced in any FTA diagram

Fixing a traceability error means ensuring the naming convention is followed precisely: the fully-qualified TRLC name (package + record name, e.g. MySeooc.RC_001) must be used verbatim as the alias in the FTA diagram.

Example

load(
    "@score_tooling//bazel/rules/rules_score:rules_score.bzl",
    "dependability_analysis",
    "fmea",
)

fmea(
    name = "sample_fmea",
    failuremodes = ["//bazel/rules/rules_score/examples/seooc/safety_analysis:sample_fmea_failure_modes.trlc"],
    controlmeasures = ["//bazel/rules/rules_score/examples/seooc/safety_analysis:sample_fmea_control_measures.trlc"],
    root_causes = ["//bazel/rules/rules_score/examples/seooc/safety_analysis:sample_fta.puml"],
    arch_design = "//bazel/rules/rules_score/examples/seooc/design:sample_seooc_design",
)

dependability_analysis(
    name = "sample_dependability_analysis",
    arch_design = "//bazel/rules/rules_score/examples/seooc/design:sample_seooc_design",
    fmea = [":sample_fmea"],
)