4.9 Government off-the-shelf (GOTS) software.
Operating systems, libraries, applications, and other software obtained from a government entity and not custom built for the applicant’s project.
4.10 Level of criticality.
The risk posed by a computing system safety item, which is a combination of the severity of the hazards associated with the computing system safety item and the computing system safety item’s degree of control.
4.11 Memory.
Parts of an electronic digital computer that retain instructions and data for some interval of time. Memory is the electronic holding place for instructions and data that the microprocessor of a computer can access.
4.12 Risk.
Measure that takes into consideration, for hardware, the probability of occurrence and the consequence of a hazard to a population or installation. For computing systems, risk takes into consideration the computing system’s contributions to hazard causation or mitigation and the consequence of a hazard to a population or installation.
4.13 Risk mitigation.
Process of reducing either the likelihood or the severity of a risk for hardware. For software, risk mitigation is the process of reducing the severity, reducing the degree of control, or validating and verifying correct control.
4.14 Safety-critical computer system function.
Any computer system function whose proper recognition, control, performance, or tolerance, is essential to ensuring public safety and the safety of property.
4.15 Safety requirement.
A computing system requirement or software requirement defined for a computing system safety item that specifies an attribute or function that presents, mitigates, or is otherwise involved in a hazard to the public.
4.16 Software.
Computer programs, databases, and, possibly, associated documentation and data pertaining to the operation of a computer system. Operating system software that controls the basic functions of the computer system and application software that enables the computer to perform tasks are included, as are configuration files, databases, firmware, and supporting data structures.
4.17 Validation.
An evaluation to determine that each safety measure derived from a system safety process is correct, complete, consistent, unambiguous, verifiable, and technically feasible. Validation ensures that the right safety measure is implemented, and that the safety measure is well understood. 14 CFR 401.7.
4.18 Verification.
An evaluation to determine that safety measures derived from a system safety process are effective and have been properly implemented. Verification provides objective evidence that a safety measure reduces risk to acceptable levels. 14 CFR 401.7.
8 5 MEANS OF COMPLIANCE.
The guidance in chapters 6 through 9 of this AC details methods that an operator may use to demonstrate compliance with each of the requirements in § 450.141.
5.1 RCC 319-19 Tailoring.
An applicant may choose to demonstrate compliance with § 450.141 by tailoring Range Commanders Council, Range Safety Group, Flight Termination System Commonality Standard, RCC 319-19. The FAA will work with applicants to tailor RCC 319-19 to comply with § 450.141. A tailored RCC 319-19 used as a means of compliance for § 450.141 should be submitted to the FAA for acceptance prior to being included in a license application.1
1 RCC 319-19 is a flight termination system design standard. Applicants should carefully consider the requirements throughout RCC 319-19 prior to tailoring the requirements for systems other than flight termination systems.
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.