WIXLIB

Table 1 Identification of Computing System Safety ItemsIdentification of Computing System Safety ItemsAC 450.141-1AReferenceDO-178C andOther ReferencesObjectiveActivityActivity OutputsApplicability (Between622.3Figure 2-1Identification ofEach software program with any safety impact is identified System Design andComputing System Safety and is assigned the appropriate criticality level.Software ConfigurationItemsIndex (SCI)This AC 450.141-1A objective falls outside of the scope of DO-178C. 450.141 focuses onComputing System Safety Items, whereas DO-178C addresses all software.SomeIdentify each ComputingSystem Safety ItemAnalyze the system requirements, Functional HazardSystem Design and SCIAnalysis, and architecture to identify all software safetyitems (programs or data). Analysis may include techniquessuch as Software Failure Modes Effects Analysis (SFMEA)and Software Fault Tree Analysis (SFTA).This AC 450.141-1A objective falls outside of the scope of DO-178C, but the FHA and SafetyAssessment processes are indicated as a prerequisite.SomeAssessment ofComputing SystemCriticalitySpecify the level of criticality of each software safety itempreviously identified using one of the following methods:1) Assumption of High Criticality2) RCC 319-19 Section A3.1.13) MIL-STD-882E Section 4.44) NASA-GB-8719.13 Section 3.1.25) AC 450.141 Fault Tolerance AnalysisSection 2.3.2 and 2.3.3 of DO-178C address defining the software level (DAL) based onSomeFailure Condition Categorization, which comes from the system safety assessment process.AC 450.141-1A and DO-178C)GenuenExperienceSAE ARP4754ASAE ARP47616.12.32.3.1SAE ARP47616.22.32.3.22.3.3SAE ARP4761RCC 319-19MIL-STD-882ESoftware RequirementsDocument (SRD),SoftwarePlans/ProcessesHighest criticality level of any of these approaches identified in AC450.141-1A correspondsroughly to DO-178C DAL B. See Error! Reference source not found. for a detailed comparisonof criticality levels between DO-178C and the methods defined in AC 450.141-1A.NASA-GB-8719.136

Levels of CriticalityThe levels of criticality produced by the AC 450.141-1A and civil aviation safety assessment processes are similar. They ultimately depend on the level of hazard to people, property, and the environmentcreated by a software failure. The results of the AC 450.141-1A safety assessment can then be mapped to the Development Assurance Levels of DO-178C to determine the required rigor of the softwarelifecycle processes to be used as the certification basis for AC 450.141-1A. Note that the highest DO-178C criticality level that an AC 450.141-1A safety assessment can map to is DAL B.Table 2 Levels of CriticalityDO-178CSoftware Level DefinitionFailure Condition CategoryRCC 319-19MIL-STD-882ENASA-GB-8719.13AC 450.141-1ASoftware CategoriesSoftware Safety CriticalityIndexSoftware Safety EffortFault ToleranceLevel A: Software whose anomalousbehavior, as shown by systemsafety assessment process, wouldcause or contribute to a failure ofsystem function resulting in acatastrophic failure condition for theaircraft.Catastrophic - Failure Conditions,which would result in multiplefatalities, usually with the loss ofthe airplane.No equivalent Software CategoryNo equivalent Software SafetyCriticality IndexNo equivalent Software Safety EffortNo equivalent Fault ToleranceLevel B: Software whose anomalousbehavior, as shown by systemsafety assessment process, wouldcause or contribute to a failure ofsystem function resulting in ahazardous failure condition for theaircraft.Hazardous - Failure Conditions,which would reduce the capabilityof the airplane or the ability of theflight crew to cope with adverseoperating conditions to the extentthat there would be:- A large reduction in safetymargins or functional capabilities;- Physical distress or excessiveworkload such that the flight crewcannot be relied upon to performtheir tasks accurately orcompletely, or- Serious or fatal injury to arelatively small number of theoccupants other than the flightcrew.Safety-critical - Software in a partitioned systemshall be assigned to a safety-critical partition whenit exercises control over safety systems. Softwarein a safety-critical partition is necessary to providepublic safety functions. This includes, but is notlimited to, the following.a. Software that evaluates predefined safety criteriausing input tracking data, or lack of tracking data,and recommends or initiates FTS actions;b. Software used to communicate with externalsystems or other partitions when thecommunication: may initiate a hazardous state;verify proper operation of software executing in ahazardous state; or direct software executing in ahazardous state to transition to a non-hazardousstate.SwCI 1 - Program shall performanalysis of requirements,architecture, design, and code,and conduct in-depth safetyspecific testing.“Full” Software Safety Effort - Systems and subsystemsthat have severe hazards which can escalate to majorfailures in a very short period of time require the greatestlevel of software safety effort. Some examples of thesetypes of systems include life support, fire detection andcontrol, propulsion/pressure systems, power generationand conditioning systems, and pyrotechnics or ordnancesystems. These systems may require a formal, rigorousprogram of quality and safety assurance to ensurecomplete coverage and analysis of all requirements,design, code, and tests. Safety analyses, softwaredevelopment analyses, safety design features, andSoftware Assurance (SA) oversight are highlyrecommended. In addition, IV&V activities may berequired.Zero fault tolerant – a single fault in thecomputing system safety item could resultin an adverse consequence.SwCI 2 - Program shall performanalysis of requirements,architecture, and design; andconduct in-depth safetyspecifictesting.Single fault tolerant – a fault in thecomputing system safety item requires asecond, independent fault in order to resultin an adverse consequence.Critical informational – a fault in thecomputing system safety item results inerroneous information that the operatorcould not readily perceive as erroneous,which can cause an operator to take actionsthat result in an adverse consequence.7

DO-178CRCC 319-19MILS-STD-882ENASA-GB-8719.13AC 450.141-1ASoftware Safety CriticalityIndexSoftware Safety EffortFault ToleranceSoftware Level DefinitionFailure ConditionCategorySoftware CategoriesLevel C: Software whose anomalousbehavior, as shown by system safetyassessment process, would cause orcontribute to a failure of systemfunction resulting in a major failurecondition for the aircraft.Major - Failure Conditions,which would reduce thecapability of the airplane orthe ability of the crew tocope with adverse operatingconditions to the extent thatthere would be, for example,a significant reduction in thesafety margins or functionalcapabilities, a significantincrease crew workload or inconditions impairing crewefficiency or discomfort tothe flight crew, or physicaldistress to passengers orcabin crew, possiblyincluding injuries.Support-critical - Software in a partitioned system shall beassigned to a support-critical partition when it supportsexecution of safety-critical software. Software in a supportcritical partition does not directly provide public safetyfunctions. This includes, but is not limited to, the following.a. Software that performs power-on self-test (POST)operations.b. Software that prepares and configures processors for use.c. Software that initializes input ports, output ports, orcommunication channels.d. Software that performs memory tests after POSToperations.e. Software that loads kernel software or applicationsoftware.f. Software that verifies successful load of kernel software orapplication software.g. Software that provides communication services forexternal systems and vehicle.h. Software that can result in inadvertent activation of theFTS, and does not present hazard to personnel nor affect theability to issue termination when required. For software ofthis type, the program must fully accept, in writing, the addedmission assurance risk. It is highly recommended thatsoftware of this type be allocated to a safety-criticalpartition.SwCI 3 - Program shall performanalysis of requirements andarchitecture; and conduct indepth safety-specific testing.Level D: Software whose anomalousbehavior, as shown by system safetyassessment process, would cause orcontribute to a failure of systemfunction resulting in a minor failurecondition for the aircraft.Minor - Failure Conditions,which would notsignificantly reduce airplanesafety, and which involvecrew actions that are wellwithin their capabilities.Minor Failure Conditionsmay include, for example, aslight reduction in safetymargins or functionalcapabilities, a slightincrease in crew workload,such as routine flight planchanges, or some physicaldiscomfort to passengers orcabin crew.No equivalent Software CategorySwCI 4 - Program shall conductsafety-specific testing.“Moderate” Software Safety Effort - Systems andsubsystems which fall into this category typically have either1) a limited hazard potential or 2) the response time forinitiating hazard controls to prevent failures is long enough toallow for human operators to respond to the hazardoussituation. These systems require a rigorous program forsafety assurance of software identified as safety-critical.Non-safety-critical software must be regularly monitored toensure that it cannot compromise safety controls orfunctions. Some analyses are required to assure there are no“undiscovered” safety-critical areas that may need softwaresafety features. Some level of Software Assurance oversightis still needed to assure late design changes do not affect thesafety criticality.A project of this level may require IV&V. However, it is morelikely to require a software Independent Assessment (IA).Software independent assessment (IA) is defined as a reviewof and analysis of the program/project’s system softwaredevelopment lifecycle and products. The IA differs in scopefrom a full IV&V program in that IV&V is applied over thelifecycle of the system whereas an IA is usually a one timereview of the existing products and plans. In many ways, IA isan outside audit of the project’s development process andproducts (documentation, code, test results, and others).Dual fault tolerant – a fault in thecomputing system safety itemrequires two or more independentfaults in order to result in an adverseconsequence.“Minimum” Software Safety Effort - For systems in thiscategory, either the inherent hazard potential of a system isvery low or control of the hazard is accomplished by nonsoftware means. Failures of these types of systems areprimarily reliability concerns. Software development in thesetypes of systems must be monitored on a regular basis toensure that safety is not inadvertently compromised or thatfeatures and functions are added which make the softwaresafety-critical. A formal program of software safety is notusually necessary. Of course, good development practicesand SA are always necessary.No equivalent Fault ToleranceInformational – a fault in thecomputing system safety item resultsin evidently erroneous informationthat, if not detected, could cause anoperator to take actions that result inan adverse consequence.8

DO-178CSoftware Level DefinitionLevel E: Software whose anomalousbehavior, as shown by system safetyassessment process, would cause orcontribute to a failure of system functionwith no effect on aircraft operationalcapability or pilot workload.RCC 319-19NASA-GB-8719.13AC 450.141-1AFailure Condition CategorySoftware CategoriesSoftware Safety EffortFault ToleranceNo Safety Effect - FailureConditions that would have noeffect on safety, for example,Failure Conditions that would notaffect the operational capability ofthe airplane or increase crewworkload.Non-critical - Software in a partitioned system shall be assigned to anon-critical partition when it does not meet the criteria for safetycritical or support-critical software. This includes, but is not limited to,software used to monitor system performance (e.g., processortemperature, processor throughput, cycle time, memory usage, taskingexecutive statistics). Note that no safety requirements are imposedupon non-critical software in a partitioned system.“Minimum” Software Safety Effort (see Level D row above) – Level Emay be applied to systems in this category if the proper monitoringmechanisms are in place.Non-safety – a fault in the computingsystem safety item has no potential toresult in an adverse consequence.Safety RequirementsAC 450.141-1A calls for specifying the computing system safety item requirements. These safety requirements spell out the necessary function, capability, and attributes for each of the previously identifiedsafety items. Specified requirements must be correct. They must be implemented and that implementation must be verified and validated. The previously determined level of criticality dictates the rigor ofthese processes.DO-178C defines these processes for commercial aviation. Development, implementation, and verification of safety requirements are laid out in detail. Checklists are provided for each activity and levels ofrigor are defined. The level of independence required for verification at each level is also covered. The evidence produced through these processes can establish a certification basis for the computing systemsafety items based on Table 1 - Identification of Computing System Safety Items in accordance with AC 450.141-1A.Table 3 Safety RequirementsSafety RequirementsAC 450.141-1AReferenceDO-178C andOtherReferences77.1ObjectiveActivity OutputsApplicability (BetweenAC 450.141-1A and DO-178C)Safety RequirementsTable A-2 #1ActivityThe safety requirements for each computer safety critical item are developed andtested.SRD, Software Design Document (SDD),Source Code Files, Executable Files,Software Verification Results (SVR),Trace DataGenuenExperienceExtensiveIdentification of Safety Those software requirements that impact safety are identified.RequirementsSRDSoftware requirements are decomposed from System requirements in DO- Extensive178C. Similarly, the safety requirements are identified and decomposedfrom the System requirements per AC 450.141-1A. Any safety requirementsthat are not identified by the System requirements must be consideredderived, and as such, must undergo the same level of scrutiny within thesystem safety assessment process.Table A-2 #15.1.1.aSoftwareRequirements areDevelopedHigh-level software requirements are developed from System-level requirements.SRD, Trace DataOnly safety requirements need to be identified for AC 450.141-1A.ExtensiveTable A-2 #25.1.1.bDerived SoftwareRequirements aredefinedSoftware requirements that don't come directly from system requirements aredefined, identified, and provided to the system safety assessment process.SRDOnly applies to derived safety requirements.ExtensiveTable A-2 #25.1.1.a5.1.1.b9

Safety RequirementsAC 450.141-1AReference7.2DO-178C andOtherReferencesObjectiveActivityActivity OutputsApplicability (BetweenAC 450.141-1A and DO-178C)GenuenExperienceTable A-36.3.1Ensuring SafetyAll safety requirements are reviewed against standards for completeness andRequirements arecorrectness.Complete and CorrectSRDAC 450.141-1A requires independence for validation of requirements for all Extensivelevels of criticality, whereas DO-178C only requires independence for DALA and B. Requirement standards are not called out in AC 450.141-1A.Traceability to system requirements is not required and compatibility withthe target computer is not identified.Table A-36.3.1Verification of theOutputs of theSoftwareRequirements ProcessSVRItems 2), 4), and 5) are not required by AC 450.141-1A.All software requirements are reviewed against system requirements to ensure:1) Software requirements comply with system requirements2) Software requirements compatible with target computer3) Software requirements verifiable4) Software requirements conform to standards5) Software requirements traceable to the system requirements6) Algorithms are accurateExtensiveIndependence is required in all reviews/inspections of the safetyrequirements.Although a requirement standard is not required by AC 450.141-1A,referencing a standard may produce a compelling rationale for theacceptance of a development process7.3Table A-2 #3Table A-2 #4Table A-2 #5Table A-2 #6Table A-2 #7Table A-4Table on andVerification of SafetyRequirementsSafety and non-safety software requirements are implemented in software. AllSDD, Source Code Files, Executablesafety requirements are verified and validated by a team from a differentFiles, SVR, Trace Datadepartment or organization than the development team. Verification and validationmethods are proportional to the level of criticality of each computing system safetyitem.Per AC 450.141-1A, Implementation and Verification/Validation levels ofrigor are based on the level of criticality of the computing system safetyitem. Independence is required for testing of “safety critical” items.ExtensiveAC 450.141-1A defines traceability from requirements toverification/validation evidence. DO-178C defines tracing between allrequirement levels (system- high-level - low-level), to code, and to testcases, and results.Per AC 450.141-1A, “There need not be a separate implementation processfor safety requirements; the applicant’s normal process for implementingsoftware requirements is 0

Safety RequirementsAC 450.141-1A DO-178C and utputsApplicability (BetweenAC 450.141-1A and DO-178C)GenuenExperienceTable A-2 #35.2.1.aSoftware Architecture A software architecture is created as a framework for implementing theis CreatedSoftware Requirements.SDDTable A-2 #45.2.1.cSoftware Design isDevelopedSoftware Designs are created that implement the software requirementswithin the defined software architecture.SDD, Trace Data This is not specifically identified within AC 450.141-1A but should be defined for criticality levelsthat correspond to DAL C and above.ExtensiveTable A-2 #55.2.1.bDerived SoftwareDesign Componentsare definedSoftware design components

Implementing AC 450.141-1A Using DO-178C DO-178C can provide a roadmap to creating a certification basis for AC 450.141-1A. DO-178C details necessary software lifecycle processes based on a software safety assessment. With increased hazard comes increased rigor. Performing the activities specified in DO-178C can be used to fulfill the dictates .