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.066 Identify system level deviations

SM-2808 - Populate Confluence page for activity definition: ARCH.066 Identify system level deviations IN PEER REVIEW

GoalManage the risks (safety, security, business) that are caused by the system or the actors deviating from designed behaviour
Requirements met by this process step

EN 50126 7.4.2.1 1) and 2)

ISO 15288 6.4.3.3 b) 3

Inputs
Outputs

AMOD-071 System failure modes and effects analysis

AMOD-004 Fault tree (per operational deviation)

Methodology

The primary focus of this task is to identify what deviations in functional exchanges can occur during the execution of the functional chain for a specific system capability. 

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.

Exclusion

Some system-level functional exchanges are placeholders for real-world physics and effects (generally these are the exchanges emerging from the "plant" placeholder functions as defined by the pattern for system function definition). These should not be considered for deviation analysis at this level, because they should already have been identified and assessed at operational level in most cases. It may be necessary to return to operational level if a gap is discovered.

Deviation analysis at system level focuses on functional exchanges between the other functions in the control loop pattern (or other designed-in system functions, where the pattern is not used).  These are all considered to be "control actions" within the meaning defined by texts on system-theoretic process analysis (STPA).

That encompasses:

  • reference values incoming from actors, whether human or machine
  • human-perceptible states
  • required states
  • estimated states
  • sensed states
  • (possibly in a few cases) actual external input states

but generally not external output states.

For every functional exchange in the system functional chain (but see exclusion):

Determine which of the following deviations could occur on the functional exchanges:

  1. Not providing the functional exchange could lead to a risk.
    =>Guideword: "1-Not providing" # state/info change intended to be used
  2. Providing the functional exchange could lead to a risk.
    1. Consider contexts in which the functional exchange may never be safe, implying that the exchange should never be made unintentionally:
      => Guideword "2.1-unintended" # state/info change in consideration but not intended to be used
    2. Consider contexts in which the functional exchange has an incorrect parameter (e.g. setting an incorrect emergency frequency on a radio)
      => Guideword "2.2-incorrect" # parameter/function performance
    3. Consider contexts in which an insufficient or excessive value of a parameter may be unsafe (e.g. providing insufficient or excessive braking commands)
      => Guideword "2.3a-insufficient", # parameter
      => Guideword "2.3b-excessive" # parameter
    4. Consider contexts in which the direction of the information on the exchange may be unsafe (e.g. providing turn left instead of turn right commands) 
      => Guideword "2.4-wrong direction" # info
    5. Consider contexts in which the functional exchange has already been provided (e.g. repetitive or oscillatory control actions)
      => Guideword "2.5-already" # state/info already used
  3. Providing a potentially safe functional exchange but too early, too late, or in the wrong order
    => Guideword "3a-too early", # state/info intended to be used
    => Guideword "
    3b-too late",  # state/info intended to be used
    => Guideword
    "3c-wrong order" # state/info sequence
  4. The control action lasts too long or is stopped too soon (for continuous control actions, not discrete ones)
    => Guideword "4a-too long",  # state/info continuous command
    => Guideword
    "4b-too short"  # state/info continuous command

The rationale for deciding a deviation will not occur as a string property value on the interaction with name "Rationale for discounting deviations" shall be recorded 

For each deviation identified

Identify any deviations at operational level that could be caused by, or contributed to by, this deviation

(Note that it is possible for system deviations to be combined logically in order to cause a deviation, e.g.

(system deviation A OR system deviation B) implies operational deviation X;

(system deviation A AND system deviation B) implies operational deviation X.

Model the appropriate causal link and combinatorial logic in the fault tree.

OR combination (OR-gate): If one or more of the system level deviations are sufficient for the occurence of the deviation at operational level.

Exclusive OR combination (XOR-gate): If only one and not more of the system level deviations are sufficient for the occurence of the deviation at operational level. 

AND combination (AND-gate): If all system level deviations that are combined by this AND-gate have to occur for the occurence of the deviation at operational level.


Note

It is possible that, through analysing system failure modes, new routes are identified towards accidents that were not recognised at operational level. In this case, the operational risk assessment needs to be revisited in order to set up the top-level accident-hazardous state-safe state model, set an acceptable deviation probability and assign responsibility. Where an appropriate operational activity does not already exist, a very generic operational activity should be added to capture the need for protection against a certain risk. The rationale for this operational activity should clearly state that the need for it arose from system-level analysis and not directly from an operational need.

Do not attempt to model protections against accidents directly at system level; this will undermine the layering structure of the safety case.

This advice is equally valid for the equivalents for security and business risk.

Tools and non-human resources

Team for Capella

(tbd - possibly a further tool or plugin for modelling fault trees - ticketed SET-183 - Add fault-tree modelling capability to our toolset Created )

CardinalityOnce per system capability
Completion criteria

The functional chain has been completely checked for possible deviations that lead to operational deviations;

The fault tree has been updated with causal links between system deviations and operational deviations

Design review

ARCH.R.3 System capability review

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

RAMS architect

Security architect

Uses outputs (Informed)Independent safety assessor