Functional hazard analysis scope

The Level 4 SSA is at the aircraft level and is the responsibihty of the aircraft integrator. For a modification (e.g. STC), it is scoped to consider the performance of the new system as well as the interaction between all affected aircraft systems. Safety requirements are functionally decomposed in a hierarchical structure from product (i.e. aircraft) level to subsystem (e.g. altitude display system) to components (e.g. Altitude Display Unit). At Level 4 the safety requirements are those requirements generated from the aireraft Functional Hazard Analysis (FHA) based on required aircraft functions... 

Step 1 define the scope of the Functional Hazard Analysis... 

The first step in the acceptance process is the identification of the environment within which the pre-developed software will have to work. This environment is determined by the system-level safety function as described in the system requirements specification. Also the interface and performance requirements, as well as the safety category should be contained in the system requirements specification. This means, that during the establishment of the plant safety design base a risk and hazards analysis has been performed which rendered the categories of safety functions to be implemented by pre-developed software. This risk and hazard analysis - in spite of being out of the scope of I C engineering - has been taken as the first of four acceptance criteria that should be applied to pre-developed software independently of its safety category. 

Introductory Information The analyst should provide basic information in this section of the report which describes the purpose and scope of the FMEA along with any limitations imposed on the analysis as a result (i.e., items not specifically within the scope of the analysis). The scope will also identify the type of FMEA (i.t., functional or hardware). Also included in the introduction section is an explanation of the methodology used to perform the analysis such as, but not limited to drawing reviews, examination of previous analyses (if applicable), evaluation of lessons learned, use of Preliminary Hazard List and/or Preliminary Hazard Analysis, and so on. Finally, any preestablished ground rules that may have been agreed upon should be provided here. Such ground rules typically limit or further narrow the scope of the FMEA, or just a portion of it, and should therefore be explained in the introductory pages of the report. 

All safety activities refer to an item . An item in terms of ISO 26262 is defined as a system or array of systems to implement a function at the vehicle level, to which ISO 26262 is applied . The Item Definition marks the scope of the Safety Considerations on an overview level and is the starting point of all furflier safety activities. It is, in particular, a necessary preparation for the Hazard Analysis and Risk Assessment (HARA), because in order to identify malfunctions that may lead to scenarios that bear the risk of an accident (called hazards), the interfaces of the investigated system to its environment must be known, as well as the specified behavior at these interfaces. Deviations from this specified behavior constitute the item s failures, a subset of these constituting the hazardous failures. As explained above, CMSs are well-suited to be regarded as an item according to the definition in ISO 26262. So the Item Definition usually depicts the entire CMS with camera(s), processing unit(s) and display(s). 

Risk Assessment. Identification of potential risks (step one) was based on an analysis of the taxonomic and ecological characteristics of the parental organisms, the functional changes in the microorganisms brought about by the genetic alteration, the mechanism of pesticidal action, and the nature and scope of the proposed field trials. Evaluation of these four areas was the basis for identification of potential hazards and mechanisms for exposure, which in turn were used to formulate the risk issues. ... 

Part II of this Basic Guide to System Safety presents and briefly discusses some of the more common system safety analytical tools used in the performance of the system safety function. Through example analyses of hypothetical mechanical and/or electrical systems, the reader should become familiar with each type of system safety analysis method or technique discussed. However, it must be understood that it is not within the limited scope of this volume to provide a detailed explanation of each of these methods and/or techniques. The intention is to merely introduce the reader to the various tools associated with the system safety process. The value of each concept in the analysis of hazard risk will vary according to the individual requirements of a given organization or company. 

The overall life cycle discussions in the standard mainly covered in this main Clause 7, having 17 major sub-clauses. Now coming back to main life cycle phases in Fig. VI/4.0.2-1, it is seen that the first part of the safety life cycle is basically the analysis part comprising concept, scope for the system/EUC, hazard/risk analysis, creation of overall safety requirements, and identification of specific safety functions to prevent the identified hazards safety requirements allocation. The middle part is realization activities (Clause 7.10) as detailed in Figs. Vl/4.1.4-1 and Vl/4.1.4-2, are dealt with in Parts 2 and 3 discussions. The next part of the life cycle is related to installation and commissioning (Clause 7.13). Then comes the validation (Clause 7.14), operation and maintenance (Clause 7.15), modification, retrofit (Clause 7.16), and finally, decommissioning (Clause 7.17). 

Our model has three main parts. The first part consists of the EC 61508 steps needed for developing the environment description and then the phases 1-4 (concept, overall scope definitions, hazard and risk analysis and overall safety requirements). These initial steps result in the initial requirements of the system that is to be developed. This is the key input to the second part of the model, which is the Scrum process. The requirements are documented as product backlog items. A product backlog is a list of all functional and safety related system requirements, prioritized by the customer. We have observed that the safety requirements are quite stable (e.g. the response time has to be less than the Process safety time for a fire alarm system), while the functional requirements may change considerably over time. Development with a high probability of changes to requirements will favour an agile approach. 

The extent to which structured methods/tools/techniques are applied is a function of the system s complexity and the system failure consequence, and will be more rigorous with increasing system complexity and severity of consequence (ACJ 25.1309 para 7.e). An analysis may range from a simple report that interprets test results or compares two similar systems to a detailed analysis that may (or may not) include estimated numerical probabilities. The depth and scope of an analysis depends on the types of functions performed by the system, the severities of failure conditions, and whether or not the system is complex. In considering the likely failure sequences, Lloyd and Tye (1995, p. 75) remind us to take account of the fact that, following a series of failures, the pilot himself will be under increased stress and may be more likely to make mistakes. Regardless of its type, an analysis should show that the system and its installation could tolerate hazards and failures to the extent that the applicable safety targets are accomplished in an auditable fashion. 

---