Copyright DB Netz AG, licensed under CC-BY SA 3.0 DE (see full text in CC-BY-SA-3.0-DE)
ARCH.068 Assess deviation probability (external constraints)
SM-2810
-
Populate Confluence page for activity definition: ARCH.068 Assess the deviation probabiilty
IN PEER REVIEW
Goal | Define a probability value for deviations of functional exchanges added on system level |
---|---|
Requirements met by this process step | EN 50126-1 6.4.3.1, 6.4.3.2 |
Inputs | AMOD-004 Fault tree (per operational deviation) |
Outputs | AMOD-004 Fault tree (per operational deviation) (updated) |
Methodology | Following prerequisite activities have been completed in ARCH.067:
In this activity all system level deviations of functional exchanges that are coming from actors or systems external to the system of interest shall be assessed in terms of their safety integrity. This means to set the probability of the deviation in accordance to that safety integrity. Example: Deviations on incoming functional exchanges, where the provider of the functional exchange might be a human being such that the probability of a deviation type "incorrect" might be 1E-04/h. In case the information conveyed by this functional exchange is used in SIL4 functions additional safety measures are needed to compensate for the low integrity input. The fault tree shall be updated to reflect the assessment of the aforementioned system level deviations. In the fault tree it shall be checked, if the related operational deviations are still not exceeded when taking into account the assessed system level deviations. If the result is that the operational deviation probability is not exceeded then this process can be followed by ARCH.070. If the result is that the operational deviation probability is exceeded then this process shall be followed by ARCH.069. Note Functional exchanges that are related to railway processes that require high safety integrity (e.g. SIL4) and these functional exchanges are outgoing of the system of interest (i.e. consumed by actors or other systems) non functional requirements will be defined on these functional exchanges to define the limits of accountability of the system of interest. |
Tools and non-human resources | Team for Capella (tbd - possibly a further tool or plugin for modelling fault trees - ticketed |
Cardinality | Once, with allowed revisions after changes in the operational level risk model or the system function definitions |
Completion criteria | The deviations of all functional exchanges provided by actors or other systems have been assessed and are reflected in the fault tree. |
Design review | ARCH.R.3 System capability review |
Step done by (Responsible) | RAMS architect Security architect |
Provides input to/assists (Contributes) | None identified |
Uses outputs (Informed) | None identified |