5 Part 5: V-Modell Reference Work Products
5.3 Products
5.3.7 Requirements and Analyses
5.3.7.10 Safety and Security Analysis
Process module: Safety and Security (Supplier)
Responsible: Safety Manager (when using process module Safety and Security (Supplier))
Activity: Performing and Evaluating Safety and Security Analysis
Participating: QA Manager
Purpose
The safety and security analysis (frequently also called risk analysis) is intended to determine the causes of hazards and to estimate the probability of ocurrence of this hazard with respect to functional safety.
The risks (probability of occurrence times damage level per hazard) will be determined, and risk minimization measures will be selected. The selection must be justified.
The safety and security analysis shall be executed for every system element regarded as critical for safety and security.
Is generated by
Project Manual, Overall System Specification (see product dependency 4.27)
Software Implementation, Integration and Evaluation Concept, Software Architecture (see product dependency 4.18)
Hardware Architecture, Hardware Implementation, Integration and Evaluation Concept (see product dependency 4.7)
Software Implementation, Integration and Evaluation Concept, Software Architecture (see product dependency 4.19)
Software Implementation, Integration and Evaluation Concept, Software Architecture (see product dependency 4.17)
Hardware Architecture, Hardware Implementation, Integration and Evaluation Concept (see product dependency 4.8)
Hardware Architecture, Hardware Implementation, Integration and Evaluation Concept (see product dependency 4.6)
System Implementation, Integration and Evaluation Concept, Enabling System Architecture (see product dependency 4.16)
Enabling System Implementation, Integration, and Evaluation Concept, Enabling System Architecture (see product dependency 4.24)
Enabling System Implementation, Integration, and Evaluation Concept, Enabling System Architecture (see product dependency 4.5)
Enabling System Implementation, Integration, and Evaluation Concept, Enabling System Architecture (see product dependency 4.21)
System Implementation, Integration and Evaluation Concept, System Architecture (see product dependency 4.15)
System Implementation, Integration and Evaluation Concept, System Architecture (see product dependency 4.23)
System Implementation, Integration and Evaluation Concept, System Architecture (see product dependency 4.4)
System Implementation, Integration and Evaluation Concept, System Architecture (see product dependency 4.20)
Overall System Specification (see product dependency 4.25)
Overall System Specification (see product dependency 4.26)
Depends on
Project Manual, Data Protection Concept, Information Security Concept (see product dependency 5.46)
5.3.7.10.1 Hazard Identification and Damage Classification
The subject »Hazard Identification and Damage Classification describes hazards which may lead to the occurence of damage when the respective system is used. For every hazard, the potential damage level per damage category will be indicated. For every identified hazard, the respective damage class per damage category will be indicated.
Depending on the system type, the occurrence of damage may lead to different damage categories, e.g., loss of life, injuries, illness, loss or damage of equipment or property and/or environmental damage. It may also lead to purely economic losses, e.g., by production shortfalls or nonavailability of an urgently needed system.
Possibly, an intangible damage may occur, e.g., in case of an infringement of legal regulations/parameters, a reduced image which may impair sales or if a recall action is initiated. Every occurrence of damage, which may be caused by a hazard, has consequences of a different level. In order to facilitate the processing, the occurrence of damage will be subdivided into appropriate damage classes.
5.3.7.10.2 Post analysis and determination of relevance
For every hazard recognized during the hazard identification, the following results will be collected:
- cause of hazard,
- probability of occurence of hazard,
- risk determination (probability of occurrence of damage times damage level),
- assessment if the determined risk lies within the risk level accepted by the acquirer. If the risk is above the acceptance value, risk-reduction measures shall be selected in the next step. In case of the hazard "component failure", the probability of occurrence can be indicated based on the component's lifetime or operating hours.
5.3.7.10.3 Safety and Security Measures
Risk-reduction measures will be determined for all risks regarded as inacceptable in the system safety and security analysis. The proposals for risk-reduction measures are described in the Project Manual under the subject »Safety and Security - Organization and Directives.
Risk-reduction measures are required if a hazard occurs which is outside the prespecified tolerance range or above the prespecified threshold value, thus becoming inacceptable. Therefore, suitable measures must be determined, and it must be checked whether the present risk is reduced to an acceptable level if these measures are taken.
»Safety and Security Measures may include constructional procedures (regarding system development and realization), analytical measures (test measures), additional functional or non-functional system requirements and additional safety and security systems or organizational requirements.
Risk-reduction measures are intended to reduce the damage level (damage class) and/or the probability of occurrence of a hazard.
The effects of the measures - e.g. degree of reduction, effort required for implementation, effects on initialization, operation, deactivation of the system or on the operating personnel - will be assessed with respect to their technical and economical suitability.
The decision for the selection of the optimum measure will be justified.
If it is impossible to find a suitable measure, the safety and security specifications in the Project Manual shall be followed. In cooperation with the acquirer, a solution shall be searched and introduced by a problem report/change request. The approach shall be documented.