Safety Risk Analysis
- Safety Risk Analysis
- the safety engineering
task during which
safety risks are analyzed and documented
As illustrated in the preceding figure, Safety Risk Analysis is part of the following inheritance hierarchy:
- Type: Concrete
- Superclass: Safety Task
- Subclasses:
The typical responsibilities of Safety Risk Analysis are to:
- Support the generation of
security requirements
by determining acceptable levels of safety risks.
- Support the architecting of safeguards.
Safety Risk Analysis typically may begin when the following preconditions hold:
- The safety team
is adequately staffed and trained in safety risk analysis.
Safety Risk Analysis is typically complete when the following postconditions hold:
Safety Risk Analysis typically involves the safety team performing the following steps in an iterative,
incremental, parallel, and time-boxed manner:
- Learn top-level safety goals from the safety program plan.
- Identify the valuable assets that have the potential to be vulnerable to accidental harm.
- Determine what accidental harm could come to these assets.
- Determine what the negative impact of this harm would be.
- Determine the types of accidents that might occur that could cause such harm to these assets.
- Determine and categorize the hazards that these types of accidents represent.
- Determine the vulnerabilities that these assets might (or do) have to these hazards.
- Determine the safety risks that these hazards and vulnerabilities represent.
- Prioritize and categorize these safety risks.
- Determine acceptable levels of these risks.
- Develop the safety risk analysis report.
- Update the safety compliance repository.
- Supply the requirements team with the safety risk analysis report so that proper safety requirements may be generated.
Safety Risk Analysis is typically performed using the following techniques:
Safety Risk Analysis typically results in the production of the following work products:
- The scope of safety risk analysis is typically an entire application, which can be a system containing data,
hardware, software, personnel, and procedural components.
- Safety risk analysis should be performed during the entire life cycle from inception through retirement
(i.e., as long as safety hazards are relevant).
- Safety risk analysis should be an ongoing task that produces and delivers different versions of the safety risk
analysis document during the course of development.
- There are many types of hazards that may impact a system including (but not limited to) hardware failure,
operator or user error, and software defects (faults). Thus, hazard analysis for software-intensive systems
should not be restricted only to sofware defects.
- Not every defect (faults) can cause a failure that leads to an accident (causes harm to an asset).
Thus, safety risk analysis is only interested in those defects that are hazardous.
- While there is a significant overlap between safety and reliability, as system can be safe without being reliable
(common failures may not cause accidents resulting in harm) and a system can be reliable without being safe (rare
failures may cause serious accidents). Thus, although safety risk analysis can use some of the same techniques as
reliability analysis, the use of these techniques should be limited to hazardous situations.
