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 ---------------
Goal | Gain confidence that all the deviations having a potential impact on safety, business risk and security are identified. |
---|---|
Requirements met by this process step | CSM-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 |
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 modelsSafety 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:
Business risks TBD Security risks TBD 2 - Relate risk conditions to interactions of the operational capability bare business processSafety 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:
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:
The activity should be done jointly between the RAMS architect and Security Architect and the system architect. Safety risk When a deviation is identified as contributing to the occurence of a hazard or an accident :
Each deviation must have a type defined. Only the following interaction deviation types shall be considered at this operational level:
In each relevant safety risk state model:
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:
ARCH.020 wrt. Safety risks |
Tools and non-human resources | Team for Capella |
Cardinality | Once 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 | |
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 |