Legal information

Copyright DB Netz AG, licensed under CC-BY SA 3.0 DE (see full text in CC-BY-SA-3.0-DE)

8. Modelling Rules for Risk Model


8.1. Overall

IDRule
RSK-100

In order to ensure consistency within the project, British English is to be used at all times.

Refer to the Cambridge Dictionary for further information.

RSK-101

Images and/or diagrams that are to be used in the descriptions of Capella model elements shall be created and maintained on the following Confluence page:

Images for Capella model element descriptions

RSK-102

Description Links for model elements shall be used in all model element descriptions.

E.g. if a certain description refers to a defined model element, the name of the model element being referred to shall be copied (as a Description Link) and pasted (as a Link) in the corresponding description field.

Exception: model elements defined as abstract concepts or terms, which serve solely as a form of documenting information external to the project, shall be excluded from this rule.

8.2. Risk Elements

8.2.1. Operational Risk Model

8.2.1.1. General Rules



RSK-001

The Risk model is defined in a state machine with the following possible risk state types:

  • Feared event state = Accident state OR Business loss state OR Security loss state
  • Not allowed state = Hazardous state OR Business risk state OR Security threat state
  • Allowed state = Safe state OR Non business risk state OR Non security threat state
RSK-002Naming convention for states of the risk state model: Sentence case - the first letter of the first word in a sentence is capitalised, except words like abbreviations or standardised terms which have own (externally-defined) naming conventions.
RSK-009The name of the allowed state shall comply to the following pattern: NOT(<name of not allowed state>)
RSK-003Where an abstract concept is mentioned in the description of a state, this is done by using a hyperlink to the abstract concept, rather than plain text.
RSK-004The risk state type is set as an applied property value to each created state.
RSK-005

The name and the description of the feared event state is aligned with the list of project-specific appropriate standard definitions.

Where standard definitions are not clear, the description of the state is reworded to make it clear.

In both cases, a reference to the source of the standard definition is given.

If there are further attributes needed to detail the definition of a state, the state can have additional applied property values for each attribute.

The description of the "not allowed state" and "allowed state" is expressed in purely physical terms referring to the actual objects that are about to cause the harm and agnostic to any system implementation.

Example:

  • Obstacle of critical mass within kinematic envelope AND within minimum achievable stopping distance of train unit travelling at critical speed
  • Train unit delayed by more than 1 hour
RSK-006

The guard condition for each transition is created as a constraint.

AND

Each constraint has an applied property value that defines the deviation type, which is selected from the standard list of deviation types (guided words) defined in the corresponding process step.

AND

The naming convention is according to the following format (same text in name of the constraint and owned specification):

Deviation<unique number>:<specific deviation description>

Unique number should be provided by tool chain.

RSK-007

The trigger of each needed transition is the interaction that causes the change of the risk states when it deviates or the interaction which mitigates the deviation.

The interaction and the constraint is linked by using the constrained elements connection.

RSK-008

A transition has no name or description.

Note: unique identification numbers will be provided by tool chain.


8.2.1.2. Safety Elements


RSE-010

The accident state has an applied property for initial severity.

The initial severity of the accident is set as a property of the accident state, to the worst-case severity level expected when there are no severity reduction measures in place.

Severity category is set according to the definitions from RAMS Experts in the model:

  • Catastrophic
  • Critical
  • Marginal
  • Insignificant
RSE-020

The accident state has an applied property for residual severity.

Note: This is not set to a value at the point the accident is created. This is the Severity category for the accident state after mitigation transitions have been defined.


8.2.1.3. Business Elements

IDRule
BSE-010

The business loss has a property for initial severity.

The initial severity of the accident is set as a property of the business loss, to the worst-case severity level expected when there are no severity reduction measures in place.

Severity levels are set according to the following definitions from RAMS Experts:

<< to be defined with System RAMS Manager SM-4338 - Getting issue details... STATUS >>

BSE-020

The business loss has a property for residual severity.

Note: this is not set to a value at the point the business loss is created.

8.2.1.4. Security Elements

IDRule
SCE-010

to be defined


8.2.2.  System level fault tree

8.2.2.1.  System level deviation

SDev-010

Each system level deviation is logically combined into a parent deviation.

8.3. Diagram Types and Viewpoints

8.3.1. Generel Rules

GRV-010

Each diagram shall be named according to following convention:

[<Capella diagram type abbreviation>][<Viewpoint number>] <Subject of view> [<Viewpoint name>]

Capella diagram type abbreviation: abbreviation indicating the type of the diagram with the following possible values:

  • O.STM - Operational State Machine (Default in Capella [MSM])

Viewpoint number: number given to the viewpoint based on the ARCH process

Subject of view: Operational risk state model diagram:

  • <Feared event name | Not allowed state name>
  • Shall be written in sentence case - the first letter of the first word in a sentence is capitalised

Examples:

[S.STM][AMOD-030] Collision of a rolling stock with obstacle | Obstacle in the path of an approaching train unit [Accident and hazard state model]

GRV-020

Optional rule: a diagram has a visible note as a short text description consisting of the following three parts:

  • Status: initial draft, group reviewed, design reviewed
  • Version: version of the diagram, there is only a version after the first design review
  • Reference: references to resources on which the diagram was created/built
GRV-030

If a note is used on a diagram, it should include the name of the person responsible and the date of creation.

Note: if after the design review there is still a need for the note, the name can be removed.

8.3.2. Operational Risk Viewpoints

8.3.2.1. General Rules

IDRules
GRO-010The states of a risk model have the following colours: <Feared event state> = red, <Not allowed state> = yellow, <Allowed state> = green.
GRO-020

For one <Feared event state>, there exists on the diagram one <Not allowed state> and for each <Not allowed state> there exists one <Allowed state>.

GRO-030The property value for the risk state type is shown on the diagram.
GRO-040

There exist at least two reflexive transitions on the diagram

  • <Not allowed state> to <Not allowed state> (reflexive, probability set to 0 → Float property value is shown on the diagram)
  • <Feared event state> to <Feared event state> (reflexive, probability set to 1 → Float property value is shown on the diagram))
GRO-050For the <Feared event state>, there exists one decision node (Feared event state entry gate) with a transition to the <Feared event state>.
GRO-060For the <Not allowed state>, there exist one decision node (Not allowed state entry gate) with a transition to the <Not allowed state>.
GRO-070For the <Allowed state>, there exist two decision nodes (Allowed state persistence gate; Not allowed state recovery gate) both have a transition to the <Allowed state>.
GRO-080For the <Feared event state> the selected severity category is shown on the diagram.
GRO-090

There exists at least one transition, with the deviation constraint as guard condition and the interaction at which the deviation can occur as trigger on the diagram between:

  • <Allowed state> entry to <Not allowed state>
  • <Not allowed state> entry to <Feared event state>
  • <Not allowed state>recovers to <Allowed state>
  • <Allowed state> persists in <Allowed state>
GRO-110

Successful mitigation transition is colored in green on the diagram

AND

Mitigation failure transition is colored in red on the diagram

GRO-130If several transitions have an "AND" dependency, this is shown on the diagram with a join pseudo state.
GRO-140If several transitions have an "OR" dependency, this is shown on the diagram with a decision node.
GRO-150If an additional join pseudo state or decision node is used in the diagram there exists always one transition to a corresponding state gate.
GRO-160The sum of all outgoing transitions from a risk state on the diagram has a probability of 1.

GRO-170

The property values which define the probability for each deviation is shown on the diagram.

8.3.2.2. AMOD-030 Accident and hazard state model

030-130

General rules apply only but with:

  • Feared event state = Accident state
  • Not allowed state = Hazardous state
  • Allowed state = Safe state

8.3.2.3. AMOD-130 Business loss and risk state model

130-020

General rules apply only but with:

  • Feared event state = Business loss state
  • Not allowed state = Business risk state
  • Allowed state = Non business risk state

8.3.2.4. AMOD-131 Security loss and threat state model

131-020

General rules apply only but with:

  • Feared event state = Security loss state
  • Not allowed state = Security threat state
  • Allowed state = Non security threat state

8.3.3.  System level fault model viewpoints

8.3.3.1.  System level fault tree


SFT-010There shall be at least one fault tree for a system capability per operational deviation.