Functional hazard analysis objectives

Although system architectural features (e.g., redundancy, monitoring and partitioning) are used to help prove the safety objectives set in the Functional Hazard Analysis (see Table 3.3), it is practically impossible to guarantee the correctness and completeness of requirements definition or design implementation. 

This whole process of safety analysis is regulated by the ARP 4761. Identification of safety objectives is given by a fimctional approach, documented in a functional hazard analysis demonstrating compliance with these objectives is achieved by identifying the combinations of failiues, and this is documented in the System Safety Assessment (SSA). 

The preliminary hazard list and the customer requirements form the basis for the Functional Hazard Assessment (FHA). While considering the required functionality and the respective system enviromnent the FHA shall answer the question How safe does the system need to be The analysis performed during the FHA provides the safety objectives and a first set of system safety requirements which are necessary in order to fulfil the safety goals and to prevent the identified hazards from occurring. The system requirements are amended by the system safety requirements. Doing this in the early project phase assures that the safety requirements are appropriately considered in the system design. 

The JSA, then, is a specialized approach of task analysis that takes an existing job and analyzes its tasks to specifically identify hazards encountered in the work environment. At the very least, the JSA does have a place within the system safety process as a tool to evaluate the hazards or risks of an existing task or function during the operation phase of the project life cycle. Here we see another connection between the principal elements of the industrial safety process and one of the basic objectives of the system safety effort, namely, that the JSA tries to eliminate or control the risk of hazard exposure in a given task during the life of the project. 

Abstract. Autonomous systems operating in the vicinity of humans are critical in that they potentially harm humans. As the complexity of autonomous system software makes the zero-fault objective hardly attainable, we adopt a fault-tolerance approach. We consider a separate safety channel, called a monitor, that is able to partially observe the system and to trigger safety-ensuring actuations. A systematic process for specifying a safety monitor is presented. Hazards are formally modeled, based on a risk analysis of the monitored system. A model-checker is used to synthesize monitor behavior rules that ensure the safety of the monitored system. Potentially excessive limitation of system functionality due to presence of the safety monitor is addressed through the notion of permissiveness. Tools have been developed to assist the process. 

FHA is a system safety analysis tool for identifying hazards through the rigorous evaluation of system and/or subsystem functions, including software functions. Systems are designed to perform a series of functions, which can be broken into sub-functions, sub-sub-functions, and so on. Functional objectives... 

For each hazardous effect, it should be determined how the aircraft/system will satisfy the safety objectives. This could mean that an analysis might need to be performed to identify all failure conditions (e.g. sub-system or LRU failures) which could lead to the hazardous effect. Each of these failure conditions is either allocated a derived safety objective (i.e. safety objectives have been set for the systems/functions, then apportioned to sub-functions/sub-systems, then apportioned to components) or, in the case of COTS equipment, existing data is used and the system architecture is manipulated to obtain the safety objectives discussed above. 

---