9 6 IDENTIFICATION OF COMPUTING SYSTEM SAFETY ITEMS.
6.1 Identifying each Computing System Safety Item.
6.1.1 Section 450.141(a)(1) requires the applicant to identify any software or data that implements a capability that, by intended operation, unintended operation, or non-operation, can present a hazard to the public. In order to meet the requirement of § 450.141(a), an operator should define computing system safety items in a way that encompasses all of the software functions that work together in a given component. It is possible to isolate or partition a computing system safety item from non-safety functionality on a single hardware component such that the non-safety functions would not be part of the computing system safety item. RCC 319-19, Appendix A, discusses partitioning in greater detail.2 An applicant’s list of computing system safety items should at least include software that performs common safety-related functions, such as:
1. Software used to control or monitor safety-related systems.
2. Software that transmits safety data, including time-critical data and data about hazardous conditions.
3. Software used for fault detection in safety-related computer hardware or software.
4. Software that responds to the detection of a safety-related fault.
5. Software used in a flight safety system.
6. Processor-interrupt software associated with safety-related computer system functions.
7. Software that schedules the execution of safety related functions.
8. Software that computes safety-related data.
9. Software that accesses or manages safety-related data.
10. Software that displays safety data.
11. Software used for wind weighting.
6.1.2 Computing system safety items and their effects on public safety should be evident from the applicant’s functional hazard analysis, performed in accordance with § 450.107(b), as described in AC 450.107-1. If a system or subsystem hazard analysis identifies any software or data as potential hazard sources or hazard controls, then the applicant should perform a software hazard analysis, or extend the functional hazard analysis, to assess the hazard and the degree of control of any computing system safety item over the hazard, in accordance with § 450.141(a). Software hazard analyses identify potential software faults and their effects on the computing system and the system as a whole, as well as mitigation measures that can be used to reduce the risk.
2 If an operator isolates or partitions non-safety functionality from computing system safety items on a single hardware component, then the isolation or partition would become a safety requirement that must be verified by testing appropriate for the highest criticality function performed by the hardware component, in accordance with § 450.141(b).
10 Typical software hazard analyses include Software Failure Modes Effects Analysis (SFMEA) and Software Fault Tree Analysis (SFTA). Appendix B of this AC and the Joint Services Software Safety Committee (JSSSC) Software System Safety Handbook provides examples of SFMEA and SFTA. The analytical method and level of detail in the analysis should correspond to the complexity of the software and computing system, intricacy of the operations, and scope of the program. An applicant’s software hazard analyses should consider a range of potential error conditions, as described in Table 1 of this AC. Appendix B of this AC provides an example of a classification scheme for software and computing system errors that an applicant can use to develop its hazard analysis.
Table 1.1 – Examples of Calculation or Computation Errors Error Condition Examples Incorrect algorithms The software may perform calculations incorrectly because of mistaken requirements or inaccurate coding of requirements.
Calculation overflow or underflow The algorithm may result in a divide by zero condition.
Table 2.2 – Examples of Data Error Conditions Error Condition Examples Improper data The software may receive out of range or incorrect input data;
no data because of transducer drop out; wrong data type or size, or untimely data; produce incorrect or no output data, or both.
Input data stuck at some value A sensor or actuator could always read zero, one, or some other value.
Large data rates The software may be unable to handle large amounts of data or many user inputs simultaneously.
11 Table 3.3 – Examples of Logic Errors Error Condition Examples Improper or unexpected commands The software may receive bad data but continues to run a process, thereby doing the right thing under the wrong circumstances.
Failure to issue a command The software may not invoke a routine.
Command out of sequence A module may be executed in the wrong sequence, or a system operator may interrupt a process leading to an out of sequence command.
Race condition/incorrect timing Software processes may have timing dependencies, within or between processes, which cause unintended data alterations at random times. System operators can interrupt processes causing a problem in timing sequences, or processes may run at the wrong times.
Table 4.4 – Examples of Interface Errors Error Condition Examples Incorrect, unclear, or missing messaging A message may be incorrect, unclear, or missing, leading to the system operator making a wrong decision.
Poor interface design and layout An unclear graphical user interface can lead to an operator making a poor decision.
Inability to start or exit processing safely A system operator may be unable to start or stop a test of a flight safety system once the automated routines have started.
Multiple events occurring simultaneously A system operator may provide input in addition to expected automated inputs during software processing.
12 Table 5.5 – Examples of Software Development Environment Errors Error Condition Examples Improper use of tools Turning on the compiler option to optimize or debug the code in production software may lead to a software fault.
Changes in the operating system or commercial software module Upgrades to an operating system may lead to a software fault.
Table 6.6 – Examples of Hardware-Related Errors Error Condition Examples Unexpected shutdown of the computing system Loss of power to the CPU or a power transient may damage circuits.
Memory overwriting Improper memory management may cause overwriting of memory space and unexpected results.
6.2 Assessment of Computing System Criticality.
6.2.1 Section 450.141(a)(2) requires an applicant to identify the level of criticality of each computing system safety item, commensurate with its degree of control over hazards to the public and the severity of those hazards. A level of criticality is specified by the combination of the severity of hazards associated with a computing system safety item and the computing system safety item’s degree of control over those hazards.
6.2.2 To satisfy § 450.141(a)(2), an applicant should first define the severities of hazard consequences of interest for its system, then assign degrees of control to computing system safety items using a framework that will enable the FAA to validate the appropriate severity and control categorization. An applicant could assess degrees of control using any of the following methods:
1. Assumption of high criticality: An applicant could simplify the assessment of the criticality of each computing system safety item by assuming that all computing systems have the highest criticality level.
2. RCC 319-19, Section A.3.1.1, defines software categories for flight safety systems.
3. MIL-STD-882E, Section 4.4, or GEIA-STD-0010A, Section A.6 defines software control categories and a software criticality index.
4. NASA-GB-8719.13, Section 3.1.2 defines software control categories and a software risk index.
5. Fault tolerance: an applicant could also use the fault tolerance method described in this section to assess system level criticality.
6.2.3 Consequence Definitions.
To assess the criticality of computing system safety items, an applicant should first define the hazard consequences of interest for its system. Applicants should define hazard consequences such that computing system safety items fit in one or more consequence categories. An applicant should consider the FAA’s definitions of the words “mishap,” “anomaly,” “casualty,” “public,” and “safety critical” in § 401.7 when composing its consequence definitions.
6.2.3.1 Option 1: Public Safety Consequence Categories.
Guidance document MIL-STD-882E and GEIA-STD-0010A define hazard consequence categories (see references [1] and [13] of paragraph 3.3 of this AC). Since the severity categories in these standards do not explicitly identify public safety consequences, an applicant for a Part 450 license must tailor the MIL-STD-882E or GEIA-STD-0010A severity tables for public safety to make them consistent with § 450.141(a)(2). This may result in something similar to Table 2, Public Safety Severity Categories, with revisions in bold underline.
14 Table 7 – Public Safety Severity Categories Description Severity Category Hazard Consequence Catastrophic 1 Could result in one or more of the following: death or permanent total disability of a member of the public, or irreversible significant environmental impact.
Critical 2 Could result in one or more of the following: permanent partial disability, injuries, or illness that may result in hospitalization of a member of the public, or reversible significant environmental impact.
Marginal 3 Could result in one or more of the following: injury or occupational illness resulting in one or more lost work day(s) to a member of the public, or reversible moderate environmental impact.
Negligible 4 Could result in one or more of the following: injury or occupational illness not resulting in a lost workday, or minimal environmental impact.
6.2.3.2 Option 2: Functional Hazard Assessment Hazard Consequence Classifications.
Computing system hazard consequences could also be determined in the course of a functional hazard assessment. In a Functional Hazard Assessment, such as that required by § 450.107(b) or § 450.109, the applicant must assess the effects on the public for all reasonably foreseeable hazardous events, and computing system safety assessments can use the consequence classifications from the functional hazard assessment to classify computing system hazard severity. The reasonably foreseeable faults for a computing system are those that an analyst can discover through methodical assessment of the system and could depend on such factors as the programming language, hardware configuration, and any other computing systems that interact with the operator’s computing system. The advisory circulars associated with § 450.107(b) and § 450.109 provide guidance on functional hazard assessment consequence classifications.
6.2.4 Method of Assigning Levels of Criticality.
The following are methods that an applicant could use to assess the degree of control of a computing system safety item has over a hazard to assign system level criticality.
6.2.4.1 Option 1: Assumption of High Criticality.
An applicant could determine analytically the highest criticality computing system safety item involved in its operations, and then define a development process that develops and tests all computing system safety items in a manner sufficient to mitigate the risks presented by its highest criticality computing system safety item. By subjecting all software to the process controls needed at its highest criticality level, an applicant could eliminate the need to characterize the criticality and degree of control of each computing system safety item, and FAA would accept that approach satisfying the requirement to identify the level of criticality of each computing system safety item under § 450.141(a)(2). Applicants could find this approach overly conservative.
6.2.4.2 Option 2: RCC 319-19 Software Categories.
An applicant could identify each of its computing system safety items as safety-critical, support-critical, or non-critical, according to the definitions in RCC 319-19, Section A.3.1.1. This method for identification of level of criticality and degree of control is appropriate for systems where an FTS is the only part of the system that contains computing system safety items because RCC 319-19 is an FTS standard.
6.2.4.3 Option 3: MIL-STD-882E/GEIA-STD-0010A Software Control Categories.
An applicant could identify each of its computing system safety items in the appropriate software control category from MIL-STD-882E, Section 4.4, or GEIA-STD-0010A, Section A.6 (see references [1] and [13] of paragraph 3.3 of this AC). These categories are described in detail in Table 3, MIL-STD-882E and GEIA-STD-0010A Software Control Categories.
16 Table 8 – MIL-STD-882E and GEIA-STD-0010A Software Control Categories Level Name Description 1 Autonomous (AT) Software functionality that exercises autonomous control authority over potentially safety-significant hardware systems, subsystems, or components without the possibility of predetermined safe detection and intervention by a control entity to preclude the occurrence of a mishap or hazard.
(This definition includes complex system/software functionality with multiple subsystems, interacting parallel processors, multiple interfaces, and safety-critical functions that are time critical.)
2 Semi- Autonomous (SAT) Software functionality that exercises control authority over potentially safety-significant hardware systems, subsystems, or components, allowing time for predetermined safe detection and intervention by independent safety mechanisms to mitigate or control the mishap or hazard.
(This definition includes the control of moderately complex system/software functionality, no parallel processing, or few interfaces, but other safety systems/mechanisms can partially mitigate risks. System and software fault detection and annunciation notify the control entity of the need for required safety actions.)
Computing system safety item that displays safety-significant information requiring immediate operator entity to execute a predetermined action for mitigation or control over a mishap or hazard. Software exception, failure, fault, or delay will allow, or fail to prevent, mishap occurrence.
(This definition assumes that the safety-critical display information may be time-critical, but the time available does not exceed the time required for adequate control entity response and hazard control.)
3 Redundant Fault Tolerant (RFT) Software functionality that issues commands over safety-significant hardware systems, subsystems, or components requiring a control entity to complete the command function. The system detection and functional reaction includes redundant, independent fault tolerant mechanisms for each defined hazardous condition.
(This definition assumes that there is adequate fault detection, annunciation, tolerance, and system recovery to prevent the hazard occurrence if software fails, malfunctions, or degrades. There are redundant sources of safety-significant information, and mitigating functionality can respond within any time-critical period.)
Software that generates information of a safety-critical nature used to make critical decisions. The system includes several redundant, independent fault tolerant mechanisms for each hazardous condition, detection, and display.
17 Level Name Description 4 Influential Software generates information of a safety-related nature used to make decisions by the operator, but does not require operator action to avoid a mishap.
5 No Safety Impact (NSI) Software functionality that does not possess command or control authority over safety-significant hardware systems, subsystems, or components that does not provide safety-significant information.
Software does not provide safety-significant or time sensitive data or information that requires control entity interaction. Software does not transport or resolve communication of safety-significant or time sensitive data.
6.2.4.4 Option 4: NASA-GB-8719.13 Software Control Categories.
An applicant could categorize each of its computing system safety items using the software control categories from NASA-GB-8719.13, Section 3.1.2.1 (see reference 10 of paragraph 3.3 of this AC). These categories are described in detail in Table 4, NASA-GB-8719.13 Software Control Categories.
18 Table 9 – NASA-GB-8719.13 Software Control Categories Software Control Categories Descriptions IA
Partial or total autonomous control of safety-critical functions by software.
Complex system with multiple subsystems, interacting parallel processors, or multiple interfaces.
Some or all safety-critical functions are time critical.
IIA & IIB*
Control of hazard but other safety systems can partially mitigate.
Detects hazards, notifies human operator of need for safety actions.
Moderately complex with few subsystems and/or a few interfaces, no parallel processing.
Some hazard control actions may be time critical but do not exceed time needed for adequate human operator or automated system response.
IIIA & III B* * A = software control of hazard. B = Software generates safety data for human operator
Several mitigating systems prevent hazard if software malfunctions.
Redundant sources of safety-critical information.
Somewhat complex system, limited number of interfaces.
Mitigating systems can respond within any time critical period.
IV
No control over hazardous hardware.
No safety-critical data generated for a human operator.
Simple system with only 2-3 subsystems, limited number of interfaces.
Not time-critical.
6.2.4.5 Option 5: Fault Tolerance.
An applicant could perform a detailed analysis to specify the system’s tolerance to faults in computing system safety items. The system’s tolerance to software faults should be the basis for degree of control assessments at the following levels, with additional levels as appropriate:
1. Zero fault tolerant – a single fault in the computing system safety item could result in an adverse consequence.
2. Single fault tolerant – a fault in the computing system safety item requires a second, independent fault in order to result in an adverse consequence.
3. Dual fault tolerant – a fault in the computing system safety item requires two or more independent faults in order to result in an adverse consequence.
4. Critical informational – a fault in the computing system safety item results in erroneous information that the operator could not readily perceive as erroneous, which can cause an operator to take actions that result in an adverse consequence.
5. Informational – a fault in the computing system safety item results in evidently erroneous information that, if not detected, could cause an operator to take actions that result in an adverse consequence.
6. Non-safety – a fault in the computing system safety item has no potential to result in an adverse consequence.
6.2.4.5.1 A fault tolerance analysis should first identify the conditions under which each level of fault tolerance is acceptable for the proposed operation. For example, fault tolerance acceptability criteria might include “hazards that are catastrophic must be dual fault tolerant to computing system faults,” or “hazards that are critical must be single fault tolerant.” The FAA would evaluate any such conditions as part of the license evaluation. The analysis should identify each computing system safety item and document its fault tolerance, then describe the measures in place to limit risk, linked to tests and analyses that demonstrate their adequacy.
6.2.4.5.2 These categories are not arranged in a hierarchical order; instead, each category represents a degree of control that a computing system safety item could exert on the system through nominal or faulty operation. For example, a computing system safety item that can cause an adverse outcome with a single fault, and for which no other system could credibly prevent an adverse outcome as a result of that fault, is zero fault tolerant.
A computing system safety item that can cause an adverse outcome with a single fault, but that requires a hardware component to fail or a human to make a mistake in order for the software fault to cause an adverse outcome, may be one fault tolerant if the software fault is independent of the second fault. A computing system safety item that could misinform a
20 system operator in a way that the operator could independently and credibly detect and correct would be informational. A computing system safety item that could misinform a system operator in a way that the operator could not independently detect or correct would be critical informational.
7 SAFETY REQUIREMENTS.
7.1 Identification of Safety Requirements.
7.1.1 In accordance with § 450.141(b)(1), applicants are required to develop safety requirements for each computing system safety item identified under § 450.141(a).
Safety requirements specify the implementation of public safety-related functions, capabilities, or attributes in a computing system safety item. Safety requirements are not necessarily obvious, which makes their methodical and explicit identification an important step in understanding a system. In general, an increase in either the severity of hazards, or the computing system’s degree of control over those hazards, will increase the level of rigor applied to that computing system to protect the public. The requirements in § 450.141 are based on this relationship between a computing system’s potential consequences, its degree of control in the causal chain for those consequences, and the rigor applied to development and testing. Software requirements and safety requirements are frequently inherited or derived from system requirements. In addition to the examples listed in Appendix A of this AC, common safety requirements for computing system safety items might include:
Shall use metric units.
Shall compute vacuum instantaneous impact point.
Shall contain a boundary polygon that ensures that the consequence of any reasonably foreseeable failure mode, in any significant period of flight, is no greater than 1 × 10-3 conditional expected casualties.
Shall compare vacuum instantaneous impact point to boundary polygon.
Shall not use flight safety system memory or CPU.
Shall accept and execute “abort” command from ground control at any time.
7.1.2 Deficient requirements are the largest single factor in software and computing system project failure, and deficient requirements have led to a number of software-related aerospace failures and accidents, some of which are described in Appendices C and D.
Faults in requirements can originate from the adoption of requirements that are incomplete, unnecessary, contradictory, unclear, unverifiable, untraceable, incorrect, in conflict with system performance requirements, otherwise poorly written, or undocumented. It is important that operators properly identify and document safety requirements, and per industry standards, ensure that safety requirements are internally consistent and valid at the system level for the resulting computing system to work safely. Applicants should implement a process for managing safety requirements