Legal information

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

ARCH.020 Identify & classify operational deviations

SM-2756 - Populate Confluence page for activity definition: ARCH.020 Identify & classify operational deviations Finished

SM-5632 - Update ARCH.020 with security relevant content Created

SM-5634 - Update ARCH.020 with buissness risk relevant content Finished

---------- Tickets from TaskForce ---------------

SM-6201 - Adapt and complete ARCH.020 (if necessary) Created

SM-6428 - Adapt and complete ARCH.020 (w.r.t. negligible transitions and related probabilities) Created

SM-6429 - Adapt and complete ARCH.020 (Calculation for simplification to be added within model) Created

SM-6430 - Adapt and complete ARCH.020 (deviation types and guided words for identifying deviations) Created

SM-6436 - Adapt and complete ARCH.020 (Provide systematic approach to derive deviation tree and implement algortih) Created

SM-6288 - Adapt ARCH.020 "Identify & classify operational deviations" with additions A003 Created

SM-6289 - Adapt ARCH.020 "Identify & classify operational deviations" with additions A004 Created

SM-6290 - Adapt ARCH.020 "Identify & classify operational deviations" with additions A005 Finished

---------- Tickets from TaskForce ---------------

GoalGain confidence that all the deviations having a potential impact on safety, business risk and security are identified.
Requirements met by this process stepCSM-SMS guidance 1.1 b), 3.1.1.1 a)
Inputs

AMOD-027 Operational bare business scenario

AMOD-028 Operational activities and interaction definitions (single operational capability)

AMOD-029 Operational bare business process

AMOD-030 Accident and hazard state model

AMOD-130 Business loss and risk state model

AMOD-131 Security loss and threat state model

Outputs

AMOD-030 Accident and hazard state model (updated)

AMOD-130 Business loss and risk state model (updated)

AMOD-131 Security loss and threat state model (updated)

AMOD-136 Single operational capability deviation analysis report

Methodology



The ARCH.020 step is made of the following sub-steps:

For each operational capability:

1 - Build the risk conditions into the relevant risk state models

Safety risks

The safety risk state models established during ARCH.026, which are relevant to the capability in question are identified. 

Each risk state model is then complemented with the risk conditions necesary to allow a transition from one state to another:

  • transition from safe state to hazardous state (and the complementary self transition of the safe state)
  • transition from hazardous state to accident state (and the complementary transition from hazardous state to safe state)

Business risks

TBD

Security risks

TBD


2 - Relate risk conditions to interactions of the operational capability bare business process

Safety risks

Each safety risk condition in the risk state model must be linked to an interaction in the related operational capability bare business process and shall represent a deviation of that interaction (unwanted behaviour). Such deviation shall include, as far as relevant, any applicable external risk condition identified in the previous sub-step. 

Each deviation must have a type defined. Only the following interaction deviation types shall be considered at this operational level:

  • Not providing the interaction leads to a hazard or an accident  =>Guideword: "1-Not providing"
  • Incorreclly providing (including untimed) the interaction leads to a hazard or an accident  => Guideword "2.-Incorrect "

Remark: If necessary, the bare business process diagrams might have to be adapted so that they align with the risk state model,

Business risks

TBD

Security risks

TBD


3 - Perform the deviation analysis (focus on effects) and consolidate the risk state models (supplement them if needed) 

Perform a bottom-up deviation analysis on the operational capability process to check if all deviations representing a risk condition have been detected and all not-allowed states have been identified in the risk state models.

The primary focus of this task is to identify what deviations in operational interactions can occur during the execution of the bare business process for a specific operational capability. Therefore the primary input is AMOD-029 but AMOD-027 and AMOD-028 may be useful cross-references.

This tasks aims at verifying the exhaustivity of the risk conditions and to further build relationships between deviations of bare business process and the risk state models.

For each identified interaction deviation that could occur:

  • Define the deviation by re-using and filling the predefined constraint template (Deviation Type,DeviationDescription)
  • Identify the state model corresponding to the consequences of the deviation, in terms of hazards and accidents for safety risks,  security losses and threats for security risks, business losses for business risks; determine if the current deviation could cause a transition to a not-allowed state or a transition to a feared event state. 
  • Sketch a schematic diagram to enhance the understanding of the deviation and link it to the description paragraph (any image is possible eg. 3D model defined with 3DTrain-Studio software, schematic drawing)


The activity should be done jointly between the RAMS architect and Security Architect and the system architect.
The system architect is responsible for organising the work but should not attempt to do this alone.


Safety risk

When a deviation is identified as contributing to the occurence of a hazard or an accident :

  • The related accident shall be mentioned in the deviation.  A "safety risk" attribute shall be then allocated to the deviation in question.
  • If no relevant safety risk  state model exists for the deviation, then an additional risk state model shall be created. In this case the Step ARCH.026 shall be revisited  to complement the initial safety risk models with missing hazards identified as a result of the deviation analysis

Each deviation must have a type defined. Only the following interaction deviation types shall be considered at this operational level:

  • Not providing the interaction leads to a hazard or an accident  =>Guideword: "1-Not providing"
  • Incorrectly providing (including untimed) the interaction leads to a hazard or an accident  => Guideword "2.-Incorrect "

In each relevant safety  risk state model:

  • The hazardous state description shall be checked then consolidated/updated considering all the relevant new deviations found in the deviation analysis.
  • Once the hazardous state description is frozen, the new deviations judged as having an impact on safety (i,e linked to a potential accident) shall be allocated either to the safe state to hazardous state transition or to the hazardous state to accident state transition
  • For the safe state to hazardous state  transition and the hazardous state to accident state transition, the combination (AND and OR respectively materialized by a joint and diamond) of the identified deviations shall be defined (by adding a joint or choice connector)
  • Additional necessary risk conditions (not covered by the deviation itself) may be added (e.g. passenger behaviour or other external conditions) by including them into the deviation description. 

The defined combination of deviations shall be checked also against the  generic hazard trees investigated previously (see ARCH.025) . If a risk condition is found to be missing,  this shall be highlighted to the architect who will decide on the potentially needed additional interaction or operation activity.  

Business risk

TBD ...

Security risk

TBD ...


It is possible that new not-allowed states could be identified during this process. Any new states should be fed into a new instance of process step ARCH.026 Define the state model of accidents, hazardous and safe state, ARCH.170 Identify security losses & threats or ARCH.013 Identify risks to business effectiveness (business loss-risk mapping).

Note: a single deviation could cause transitions to multiple not-allowed states, including not-allowed states in different state machines (that is, a single deviation could cause security, safety and business risks all at once)

4 - Finally populate in the risk state models the complementary transitions where they can occur naturally:

  • <not allowed state> recovers to <allowed state> (for situations where the not allowed state clears up by itself)
  • <allowed state> persists in <allowed state> (a transition that allows the modelling of the probability of successful mitigations - and hence completes the state diagram as a hidden Markov model where the sum of all outgoing transitions from a state has probability 1)


ARCH.020 wrt. Safety risks


Tools and non-human resources

Team for Capella

CardinalityOnce per operational capability
Completion criteria

All the needed safety risk models which have been identified during the deviation analysis are available and completed

All the needed business risk model which have been identified during the deviation analysis are available  and completed

The output views conform to their modelling rules

All plausible deviations have been identified and classified in terms of the transitions they could cause

Design review

ARCH.R.1 Operational capability review

ARCH.R.2 Operational review - consolidated

Step done by (Responsible)System architect
Provides input to/assists (Contributes)

RAMS architect

Security architect

Operational concept architect

Uses outputs (Informed)External stakeholders e.g. independent safety assessor