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
Goal | Manage 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 | |
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. 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:
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:
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
|
Cardinality | Once 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 | |
Step done by (Responsible) | System architect |
Provides input to/assists (Contributes) | RAMS architect Security architect |
Uses outputs (Informed) | Independent safety assessor |