Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,31 @@

# Dependability Analysis

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.
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:

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.
2. **Analyse effects and causes** — document the effect on the system and decompose to root causes using a Fault Tree Analysis (FTA).
3. **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](https://eclipse-score.github.io/process_description/main/process_areas/safety_analysis/guidance/fault_models_guideline.html#id1)

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`

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -93,15 +93,56 @@ tuple CompReqId {
// Safety Analyses
///////////////////////////////

enum GuideWord "HAZOP-style guide words used to categorise the nature of a failure mode." {
TooEarly "The function or signal occurs earlier than expected."
TooLate "The function or signal occurs later than expected."
Wrong "The function produces an incorrect value or signal."
enum GuideWord "HAZOP-style guide words used to categorize failure mode." {

// -------------------------------------------------------------------------
// Message fault models (MF_01_xx)
// -------------------------------------------------------------------------

// MF_01_01: message is not received
// MF_01_06: message is not sent
// EX_01_04: loss of execution [shared with Execution]
LossOfFunction "The function is completely absent when it should be active."

// MF_01_04: message not received correctly by all recipients
// EX_01_06: processing not complete (infinite loop) [shared with Execution]
PartialFunction "The function is active but only partially fulfils its purpose."

// MF_01_05: message is corrupted
Corrupted "Data or message content is incorrect due to corruption during transmission or storage, distinct from a functional logic error."

// MF_01_07: message is unintended sent
UnintendedFunction "The function is active when it should not be."
ExceedingFunction "The function operates beyond its specified bounds."

// -------------------------------------------------------------------------
// Time constraint fault models (CO_01_xx)
// Note: TooEarly / TooLate also apply to message timing (MF_01_02, MF_01_03)
// -------------------------------------------------------------------------

// CO_01_01: minimum constraint boundary is violated
// MF_01_03: message received too early
TooEarly "The function or signal occurs earlier than expected."

// CO_01_02: maximum constraint boundary is violated
// MF_01_02: message received too late
TooLate "The function or signal occurs later than expected."

// -------------------------------------------------------------------------
// Execution fault models (EX_01_xx)
// -------------------------------------------------------------------------

// EX_01_01: process calculates wrong result(s)
Wrong "The function produces an incorrect value or signal due to a logic error."

// EX_01_02: processing too slow
DelayedFunction "The function is active but with an unacceptable delay."

// EX_01_03: processing too fast
ExceedingFunction "The function operates beyond its specified bounds."

// EX_01_05: processing changes to arbitrary process
ArbitraryExecution "Processing deviates from its specified behaviour and executes in an unpredictable or non-deterministic manner."

}

type FailureMode "A potential failure of a system function, described using a HAZOP guide word." extends ScoreReq.RequirementSafety {
Expand Down
Loading