System hazard analysis design phase

There are two approaches to ERS design. One is system modeling, which identifies the cause of a pressure rise from a hazard analysis. It uses approximate models—allvapor flow, all-liquid flow, or two-phase flow—to simulate the pressure increase of the reacting system vs. time and to determine vent size. The method is complex since it must identify the stoichiometry, the mechanism, and the kinetics of the decomposition causing the pressure rise. Two pressure models are used for vent sizing ... 

Prototyping FDA (1995) An approach to accelerate the software development process by facilitating the identification of required functionality during analysis and design phases. A limitation of this technique is the identification of system and software problems and hazards. [Adapted.]... 

Hazard Analysis. The second assumption is that developers have access to information on the dysfunctional behaviour of the components usually utilized in design. This base of information can be the result of studies on previous exploitations of similar components in systems already in use. In (David ef a/. 2009), we proposed a way to formalize this database using SysML. If such a database is unavailable, the process will contribute to building one, but the automatic phases will be less efficient. 

In the analysis of system safety, the initial process begins with the development of the preliminary hazard list during the project or system concept phase. Although it is not always compiled in aU cases, an available PHL can become the working foundation for the development of the preliminary hazard analysis during the design phase of the project life cycle. 

The SSHA evaluates hazardous conditions, on the subsystem level, which may affect the safe operation of the entire system. In the performance of the SSHA, it is prudent to examine previous analyses that may have been performed such as the preliminary hazard analysis (PHA) and the failure mode and effect analysis (FMEA). Ideally, the SSHA is conducted during the design phase and/or the production phase, as shown in Chapter 3, Figure 3.4. However, as discussed in the example above, an SSHA can also be done during the operation phase, as required, to assist in the identification of hazardous conditions and the analysis of specific subsystems and/or components. In the event of an actual accident or incident investigation, the completed SSHA can be used to assist in the development of a fault tree analysis by providing data on possible contributing fault factors located at the subsystem or component level. 

The ETBA is one of the fundamental tools of system safety analysis and, when used, can not only document the adequacy of hazard barriers and controls but also identify those energy flow areas within a system that may have been overlooked as potential risk hazards during the concept or design phase of the project. 

The second and more common hardware FMEA examines actual system assemblies, subassemblies, individual components, and other related system hardware. This analysis should also be performed at the earliest possible phase in the product or system life cycle. Just as subsystems can fail with potentially disastrous effects, so can the individual hardware and components that make up those subsystems. As with the functional FMEA, the hardware FMEA evaluates the reliability of the system design. It attempts to identify single-point failures, as well as all other potential failures, within a system that could possibly result in failure of that system. Because the FMEA can accurately identify critical failure items within a system, it can also be useful in the development of the preliminary hazard analysis and the operating and support hazard analysis (Stephenson 1991). It should be noted that FMEA use in the development of the O SHA might be somewhat limited, depending on the system, because the FMEA does not typically consider the ergonomic element. Other possible disadvantages of the FMEA include its purposefiil omission of multiple-failure analysis within a system, as well as its failure to evaluate any operational interface. Also, in order to properly quantify the results, a FMEA requires consideration and evaluation of any known component failure rates and/or other similar data. These data often prove difficult to locate, obtain, and verify (Stephenson 1991). 

This example will develop a hardware FMEA for a proposed system that is well into the design phase of the product life cycle. For informational purposes, it is assumed that a preliminary hazard analysis was previously performed during the early stages of the design phase of this system. The information from the PHA will be used to assist in the development of the hardware FMEA. It should also be noted that the nature of a FMEA requires evaluation of subsystems, subassemblies, and/or components. For this reason, more detailed and specific descriptive information is provided here than that supplied for previous examples discussed in this text. 

You will be able to determine if one or more hazard analysis systems designed to address routine job, process, or phase hazards are in place at the facility. 

Architectural design analysis Once the requirements phase has been completed, the software team passes on to the top-level systems design. As the design is laid out, the criticality analysis tracking system is updated with the new, more detailed information. This is performed primarily through software hazard analysis. Another tool is software FMEA. 

---