Hardware/software safety analysis

Failure Modes and Effects Analysis (FMEA) and its variants have been widely used in safety analyses for more than thirty years. With the increase of application domain of software intensive systems there was a natural tendency to extend the use of (originally developed for hardware systems) safety analysis methods to software based systems. 

One important point is doing the Software Safety Analysis as part of the overall System Safety Assessment, and not as an independent task. During the FHA critical system functions and system hazards are identified and subsequently broken down to the hardware and software level. Based on the software architecture, potential software faults which might contribute to the system hazards are detected during the Software Safety Analysis. The results of the Software Safety Analysis must be considered at the system level as well. Thus, the Software Safety Analysis is an integrated element of the System Safety Assessment. 

Gather the requirements for the systems including functional (e.g. operational checks) requirements, nonfunctional (e.g., coding standards) requirements, users, company-wide regulatory compliance (e.g., Part 11 technical control), safety, process, and other applicable requirements Characterize information, assess its value to the organization, and incorporate information quality as part of the project plan Conduct a system (hardware, software, and process) risk analysis. New requirements may be found as the result of the risk analysis. Any new requirements must be documented in the requirements specification deliverable... 

Specific Software/Hardware Safety Analysis targeting the specific application in the context of its intended system and operating environment, such as techniques identified in Leveson (1995), the DoD s Software System Safety Handbook (2010), Pumphrey (1999) and Defence Standard 00-58. 

Software hazard analysis is extremely important and will be of growing importance in the future. The software hazard analysis effort should parallel the system safety program for system hardware, be a life cycle effort, and use a combination of methods and approaches. 

Software System Hazard Analysis This type of analysis is conducted similar to a hardware system hazard analysis (SHA), analyzing software functional processing steps to determine whether they may have any particular hazardous effect on the system. The analysis utilizes a hazard-risk index to illustrate the severity of each potential failure. The main advantage to this method is in its ability to positively identify safety-critical hardware and software functions as well as consider the effect of the human element in system software operations. The results of the software SHA, which identifies single-point failures or errors within a system, can often be used to assist in the development of a software fault tree analysis or, to some degree, a system FMEA. However, as with the other various SWHA techniques briefly described above, this method is also time-consuming and costly to perform. 

The process for the specification of human subsystem safety requirements is no different to software or hardware although it is ai uably considerably harder due to the difficulties associated with the immense scope and variety of issues affecting the reliable performance of human tasks. This paper has examined issues relating to the consideration of human subsystem safety and has outlined the scope and activities necessary for a comprehensive human factors safety analysis. A pragmatic method was introduced that advocates the application of focused Human Factors techniques to the assurance of safety for human subsystems. 

Fault Tree Analysis (FTA) is a well known and widely used safety tool, implementing a deductive, top down approach. It starts with a top level hazard, which has to be known in advance and "works the way down" through all causal factors of this hazard, combined with Boolean Logic (mainly AND and OR gates). It can consider hardware, software and human errors and identifies both single and multiple points of failure. Both a quantitative and qualitative analysis is possible. 

The determination and documentation of the method to be used for hazard identification and safety analysis in determination of the system integrity requirements and their subsequent apportionment to the system components, hardware software and data. 

The first software standard to adopt an evidential approach was the Civil Aviation Authority s SWOl. This is the first part of a 3 part standard (HWOl, covering hardware, and SYSOl covering systems will follow). Some assumptions regarding the content of SYSOl are made by SWOl, namely that software safety requirements have been derived from a full risk and safety analysis of the system . 

System description The next step is system description. Some thought should be given to grasping how the system works and how the hardware, software, people, and environment all interact. If the system is not described accurately, then the safety analysis and control program will be flawed. 

It is important to understand that this is not a model of all possible system failures or all possible causes, but rather, a model of particular system failure modes and their constituent faults that lead to the top event. Not all system or component failures are listed, only the ones leading to the top event. Like the other safety analysis techniques discussed previously, only credible faults are assessed. The faults can be events associated with component hardware failures, software glitches, human errors, and environmental conditions—in short, any of the elements that make up the complete system. 

IDPSA—frequently also called Dynamic PSA— can be regarded as a complementary analysis to the classical Deterministic (DSA) and ProbabiUs-tic (PSA) Safety Analyses (Adolfsson et al. 2011, Adolfsson et al. 2012). It makes extensive use of a deterministic dynamics code and applies advanced methods for an improved modeling and probabiUs-tic assessment of complex systems with significant process/hardware/software/firmware/human interaction (Aldemir 2013). An IDPSA is particularly suitable in the frame of a fire PSA, since it can more realistically model and assess the interaction of the fire dynamics with the performance of technical systems and human actions. 

The way how the methods are applied based more on the context of the process how parts 4 (system) and 5 (electronic hardware) of ISO 26262 considers the application of the methods. The descriptions in the previous figures (Figs. 4.35 and 4.36) show the information flow for a system and the electronic hardware as well as for a system and the software. In this context we can see how ISO 26262 invokes the safety analysis and where the results will be applied. This illustration is not showing a complete information flow a complete illustration can only be shown in regards to a specific product development and its realizations. Depending on the maturity level, for example in a B- or C-sample cycle of the development, very different iterations of the information flow have to be considered mainly because of modifications and changes of the product. 

FMEA is applicable to any system or equipment, at any desired level of design detail— subsystem, assembly, unit, or component. FMEA is generally performed at the assembly or unit level, because failure rates are more readily available for the individual embedded components. The FMEA can provide a quantitative reliability prediction for the assembly or unit that can be used in a quantitative safety analysis (e.g., FT). FMEA tends to be more hardware and process oriented but can be used for software analysis when evaluating the failure of software functions. 

FHA is a powerful, efficient, and comprehensive system safety analysis technique for the discovery of hazards. It is especially powerful for the safety assessment of software. Since software does not have discrete failure modes as hardware does, the best way to identify software-related hazards is by evaluating the effect of potential software functions failing. Software is built upon performing functions therefore, FHA is a very natural and vital tool. After a functional hazard is identified, further analysis of that hazard may be required to determine if the causal factors of the functional failure are possible. Since the FHA focuses on functions, it might overlook other types of hazards, such as those dealing with hazardous energy sources, sneak circuit paths, and hazardous material (HAZMAT). For this reason, the FHA should not be the sole HA performed, but should be done in support of other types of HA, such as PHA and SSHA. 

The SRCA is essentially a traceability analysis to ensure that there are no holes or gaps (i.e., no hazard has been left unmitigated) in the safety requirements and that all identified hazards have adequate and proven design mitigation coverage. The SRCA applies to hardware, software, firmware design requirements. 

Taylor J.R. MASER, an integrated system for Hardware, Software and Operator Safety Analysis, ITSA1991, Available firom the author. 

DQ checks that the design documentation matches the requirements stated in the EDS. Layout drawings, operating and maintenance procedures, parts lists and system descriptions are included in the DQ. Both hardware and software configuration are reviewed together with the supplier s product documentation. DQ offers the opportunity to monitor the progress of project validation as well as any operational and safety issues, such as the use of radioactive instruments or access to analysis equipment for maintenance. 

Software need not be treated any differently than the other parts of the system. Most safety-related software problems stem from requirements flaws. The system requirements and system hazard analysis should be used to determine the behavioral safety constraints that must be enforced on software behavior and that the software must enforce on the controlled system. Once that is accomplished, those requirements and constraints are passed to the software developers (through the black-box requirements specifications), and they use them to generate and validate their designs just as the hardware developers do. 

Implementations of I C functions important to safety in nuclear power plants are increasingly realized with computer based systems, i.e. by its software. Often so called equipment families are used to develop these I C functions. Besides a hardware platform, these equipment families provide predeveloped software in the form of basic components from which I C functions can be composed by configuration and parameterization but also larger components which have been developed by conventional software engineering, as e.g. operating systems, I/O drivers, self-supervision software, etc. are included. Outside the equipment families, it may be desirable to introduce also other types of predeveloped software, e g. for simulation and for analysis purposes. 

Before the proliferation of digital technologies [i.e., software (SAV) and complex electronic hardware (CEHW)], the behaviours and properties of a system (or item) were easy to establish (or characterise) by direct inspection, analysis or test. Random failure rates were relatively straightforward to deduce, and these failure rates could be used to feed (e.g., see Table 3.3) traditional system safety methodologies. 

---