Safety systems assessment

The SPEAR framework to be described in subsequent sections is designed to be used either as a stand-alone methodology, to provide an evaluation of the human sources of risk in a plant, or in conjunction with hardware orientated analyses to provide an overall system safety assessment. The overall structure of the framework is set out in Figure 5.4. 

The collated documents required to demonstrate the above are often collectively referred to as a System Safety Assessment (SSA). ... 

For more information on how the System Safety Assessment came about (and a comparison with Safety Case), see Kritzinger, D.E, 2005. Aircraft System Safety Military and Civil Aeronautical Applications. Woodhead Publishing Ltd, Cambridge, CBl 6AH. 

The output of this step is the issue of a Preliminary Aircraft Safety Assessment (PASA) and/or a Preliminary System Safety Assessment (PSSA), which ... 

This top goal is the seed from which the argument can develop and represents the ultimate aim of the System Safety Assessment or Safety Case. In setting the goal, all stakeholders need to be in agreement regarding the scope (see Section 2.1.3). 

With due notice of the GSN challenges referred to in Section 2.5, Fig. 2.4 is intended to provide a starting point for anyone trying to compile a GSN argument for a CS25.1309 compliant System Safety Assessment. This argument is by no means definitive and appropriate in all circumstances, but should provide a stimulus for debate. 

Figure lA Suggested System Safety Assessment strategy for the case study. For a larger print of this illustration. Please see www.aircraftsystemsafety.com. 

For the purposes of the Preliminary System Safety Assessment (PSS A), the FHA considers functional failure modes only (i.e. not their probability of occurrence). Failure conditions identified at this level are not dependent on the way the functions are implemented or the system architecture. 

As illustrated in Fig. 3.2, before proceeding with a detailed System Safety Assessment (SSA), the FHA is often used to determine the need for and scope of any subseqnent analysis. An FHA may contain a high level of detail in some cases (such as for a Flight Guidance and Control System with many functional modes), but many installations may need only a simple review of the system design [AMC25.1309 para 10b(3)]. If further safety analysis is not required, then the FHA could itself be used as a complete safety assessment. 

The first step for a successful FTA is to define the objective of the FTA. The resulting scope of the FTAs will depend on the exact phrasing of the top-level event as well as the scope of the controlling System Safety Assessment (e.g. see Fig. 2.5). Careful... 

In most civil aviation System Safety Assessments, this event originates from a Function Hazard Analysis (FHA, see Chapter 3), but it can also come from any other hazard identification technique (e.g. ZS A or PRA). An FTA is a deductive approach (i.e. top down) that determines how a given state (i.e. the undesired event) can occur. It does not identify all failures in a system in a way that inductive tproaches (such as an FMEA) would. 

Once fully verified the up-to-date and fnlly populated fault trees should then be written up either as an annex of the System Safety Assessment or as a separate report. The annex or report should include an index of the failure conditions considered, including the probability targets which were set. For eaeh fault tree, include the following ... 

The FTA needs to be verified prior to being finalised for publication (or reference) in the System Safety Assessment. The validated FTA might have been completed in the early stages of the design to help substantiate that we have a suitable architecture in the proposed design. However ... 

Note A piece-part FMEA is often only effectively conducted by the design authority of the part being considered. For the purposes of supporting a 2X.1309 System Safety Assessment, the piece-part FMEA is thus seldom applied above System Level 3 and is only conducted(ARP4761 para G.3.2.2) when necessary (eg, when the more conservative results of a functional FMEA will not meet the ETA probability of failure budget). 

Note This checklist is derived from SAE ARP 4761 (p. 162-164) and includes the author s experience. This list in intended to be thought provoking but has all the limitations of generic data. In no circumstances should it be considered complete or necessarily applicable to all systems. Note also, with reference to CS25.1309(c), it is interesting to note that there are currently no CS requirements to actually address errors by maintenance personnel in the System Safety Assessment. 

At this point the author of the PRA must ensure visibility of these recommendations to all relevant stakeholders. Consideration needs to be given to issuing the first draft of the PRA as early as possible, especially if the output influences the requirements management process (see Fig. 1.3). This may take the form of a stand-alone report or may be contained within any interim updates of the System Safety Assessment (i.e. PSSA is the first issue, SSA is the final issue, with as many ISSAs as required to keep track with the evolving design and maturing System Safety Assessment). 

Preliminary System Safety Assessment The PSSA should have already been conducted and should have highlighted some of the architectural/installation requirements (such as physical and electrical segregation) needed to ensure appropriate levels of redundancy in system functionality during potential failure events. 

Recommendations as to how the System Safety Assessment needs to take account of any event independence vulnerabilities (refer Section 8.2). 

Caldwell, R.E., Merdgen, D.B., 1991. Zonal analysis the final step in system safety assessment (of aircraft). In Reliability and Maintainability Symposium, http //ieeexploie.ieee.org/ xpl/articleDetails.jsp tp= arnumber=154447 url=http%3A%2F%2Fieeexplore.ieee. org%2Fxpls%2Fabs all.jsp%3Famumber%3D154447. 

Any S/W or hardware providing partitioning should be assessed by the system safety assessment (SSA) process to ensure that it does not adversely affect safety. 

A-2 Derived high-level requirements are defined and provided to the system processes, including the system safety assessment process. O o o o SAV Requirements Data 11.9 ... 

Requirements are identified, defined and documented. This includes allocated requirements from the Preliminary System Safety Assessment (PSSA) and derived requirements from the hardware safety assessment. 

All of the above can result in system misdiagnosis, which is known as a Cognitive Task Error. At best, this action delays the correct response at worst, it compounds the problem. A more proactive approach is therefore required, and the wise consideration of the human role, performance and frailties in overall system performance, is thus a fertile area to explore in the System Safety Assessment (SSA). 

The aim of this chapter is to explore the issues surrounding crew performance and how this integrates with the content of a typical CS/FAR 25.1309 System Safety Assessment. 

System Safety Assessment process to mitigate crew errors... 

In the absence of a holistic approach to system safety assessment, it is tempting to concentrate safety assessment effort on what we understand or think we understand (such as hardware and software) and to adopt a head in the sand approach to the human factors which are often perceived as too difficult. Humans are often the major causal factor for hazards in safety-related systems (Sandom 2002) and yet human failures often don t receive proportionate attention in safety analyses. On the other hand, human operators also often provide substantial mitigation between... 

---