You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: bazel/rules/rules_score/docs/user_guide/dependability_analysis.md
+25-1Lines changed: 25 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,7 +13,31 @@
13
13
14
14
# Dependability Analysis
15
15
16
-
The `dependability_analysis` rule is the top-level safety artifact in `rules_score`. It summarizes the dependability analyses (Safety / Security) which were performed for the dependable element.
16
+
The `dependability_analysis` rule summarizes the all the dependability analyses (Safety / Security) for a dependable element. A single element may have multiple dependability analyses.
17
+
18
+
## Overview
19
+
20
+
### Why safety analysis?
21
+
22
+
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.
23
+
24
+
### How FMEA works
25
+
26
+
A Failure Mode and Effects Analysis (FMEA) follows three steps for each public interface of the software module:
27
+
28
+
1.**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.
29
+
2.**Analyse effects and causes** — document the effect on the system and decompose to root causes using a Fault Tree Analysis (FTA).
30
+
3.**Define countermeasures** — for every root cause specify a `ControlMeasure` (or `PreventiveMeasure` / `Mitigation`) and trace it back through the FTA to the failure mode.
31
+
32
+
### Fault models
33
+
34
+
The failure modes to consider are defined by the SCORE process:
35
+
36
+
> [FMEA Fault Models — Process Description](https://eclipse-score.github.io/process_description/main/process_areas/safety_analysis/guidance/fault_models_guideline.html#id1)
37
+
38
+
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.
39
+
40
+
The description below covers the FMEA-based **safety** analysis for a software module.
0 commit comments