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
ID | Rule |
---|---|
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: |
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:
|
RSK-002 | Naming 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-009 | The name of the allowed state shall comply to the following pattern: NOT(<name of not allowed state>) |
RSK-003 | Where 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-004 | The 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:
|
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:
|
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
ID | Rule |
---|---|
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
ID | Rule |
---|---|
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:
Viewpoint number: number given to the viewpoint based on the ARCH process Subject of view: Operational risk state model diagram:
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:
|
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
ID | Rules |
---|---|
GRO-010 | The 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-030 | The property value for the risk state type is shown on the diagram. |
GRO-040 | There exist at least two reflexive transitions on the diagram
|
GRO-050 | For the <Feared event state>, there exists one decision node (Feared event state entry gate) with a transition to the <Feared event state>. |
GRO-060 | For the <Not allowed state>, there exist one decision node (Not allowed state entry gate) with a transition to the <Not allowed state>. |
GRO-070 | For 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-080 | For 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:
|
GRO-110 | Successful mitigation transition is colored in green on the diagram AND Mitigation failure transition is colored in red on the diagram |
GRO-130 | If several transitions have an "AND" dependency, this is shown on the diagram with a join pseudo state. |
GRO-140 | If several transitions have an "OR" dependency, this is shown on the diagram with a decision node. |
GRO-150 | If an additional join pseudo state or decision node is used in the diagram there exists always one transition to a corresponding state gate. |
GRO-160 | The 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:
|
8.3.2.3. AMOD-130 Business loss and risk state model
130-020 | General rules apply only but with:
|
8.3.2.4. AMOD-131 Security loss and threat state model
131-020 | General rules apply only but with:
|
8.3.3. System level fault model viewpoints
8.3.3.1. System level fault tree
SFT-010 | There shall be at least one fault tree for a system capability per operational deviation. |