DO 178 Project

DO-178 Projects DO-178 Software Development & Certification DO-178 Software Considerations in Airborne Systems & Equipment Certification For nearly a decade, CERTON has provided services and solutions to customers across the Aerospace Industry from General Aviation to Space Flight focused on certification of Airborne Software compliant with RTCA/DO-178 Software Considerations in Airborne Systems & Equipment guidelines. CERTON can work closely with you to ensure successful TSO and/or Type Certification during any phase of the software project lifecycle under DO-178B. DO-178 Design Assurance Level (DAL) For systems and equipment using software to fulfill a safety related aircraft function, the FAA Advisory Circular 20-115B cites RTCA/DO-178 as a means of compliance to the Federal Aviation Regulations (FARs) Part 21, 23, 25, 27, 29 and 33. The FAA defines RTCA/DO-178B as a means, but not the only means, of compliance to the FARs. It is an extremely rare exception that an alternative means of compliance is used for software in avionics applications In order to certify safety-critical airborne software using the RTCA/DO-178 guidelines, the system safety assessment process will identify the applicable DAL according to the five failure conditions categories necessary for safe operation identified in the table below. DAL

Condition

Level A

Catastrophic

Software that would cause or contribute to a failure of the system function resulting in conditions that would prevent continued safe flight and landing. Level B

Hazardous/Severe-Major

Software that would cause or contribute to a failure of the system function resulting in reducing the capability of the aircraft or the ability to the crew to cope with adverse operating conditions so that there would be a large reduction in safety margins of functional capabilities. Level C

Major

Software that would cause or contribute to a failure of the system function resulting in reducing the capability of the aircraft or crew with adverse operating conditions that would create a significant reduction in safety margins or functional capabilities, a significant increase in crew workload, possibly including injuries. Level D

Minor

Software that would cause or contribute to a failure of the system function which would involve crew action that are well within their capabilities that causes slight reductions in safety margins or functional capabilities and slight increase in crew workload. Level E

No Effect (DO-178B Objectives Do Not Apply)

Software that would cause or contribute to a failure of the system function which has no affect the operational capability of the aircraft or increase workload. CERTON has the expertise to develop and certify airborne software for any DAL using the RTCA/DO-178 guidelines for compliance and Certification Authority approval.

The CERTON DO-178 Compliant Model The DO-178 Software Development Lifecycle is made up of six main phases, Project Planning, Validation & Verification, Requirements, Design & Architecture, Implementation & Integration, and Delivery. Each phase in the software development lifecycle consist of guidelines and activities to achieve compliance with the certification objectives that need to be filled in order for phase completion. In CERTON’s model of the DO-178 Software Development Lifecycle, the Validation & Verification Phase encompasses activities during all of the development phases once the plans have been approved by a Certification Authority (FAA, EASA, ANAC, Transport Canada, etc.). This is the key to successfully managing the risk on a DO-178 project and the V&V team members should contribute to the development of these plans that will affect the entire program as it evolves.

Software Development projects that fall victim to schedule and budget overruns can almost always be attributed to not having a trained and experienced V&V team in place early and actively involved during all phases of the software lifecycle. DO-178 projects are requirements based, and CERTON has the expertise and experience to contribute valuable input related to System Requirements, High Level Requirements, and Low Level Requirements Design and Architecture that will support streamlined implementation and integration, V&V, and Delivery. Errors in the Requirements, Design and Architecture have to be identified and resolved as they are created by the Development team early in the project. Otherwise, the inevitable consequence of detection by V&V after implementation and integration is complete rework from the top all the way down. These avoidable errors become very costly to a program with milestone deadlines, such as First Flight (SOF), Type Inspection Authorization (TIA), and Certification. Project Planning Phase At the start of the DO-178 Software Development Lifecycle, the objective of the DO-178 Planning Phase must be addressed for compliance. [DO-178B Table A-1] This Software Planning Process involves creating plans and standards to govern the development, verification, configuration management, quality assurance, and delivery of software in compliance with DO-178 guidelines. In this phase, the Software Development Plan (SDP), Plan for Software Aspects of Certification (PSAC), Software Quality Assurance Plan (SQAP), Software Configuration Management Plan (SCMP),

Software Verification Plan (SVP), and Software Requirements, Design & Coding Standards (SRDCS) documents are written and reviewed in preparation for the first Stage of Involvement (SOI) Audit with the Certification Authority. These documents are explained in further detail below. CERTON has the experience and expertise to help you develop the plans that will be approved by the Certification Authority and govern your successful DO-178 project. Plan for Software Aspects of Certification (PSAC)

The purpose of the PSAC is to provide the primary means used by the Certification Authority for determining whether an applicant is proposing a software lifecycle that is commensurate with the rigor required for the DAL of software being developed (DO-178B Section 11.1). The PSAC should include the following, at a minimum: 

System Overview



Software Overview



Certification Considerations



Software Lifecycle



Software Lifecycle Data



Schedule



Additional Considerations

Software Development Plan (SDP)

The purpose of the SDP is to identify the objectives, standards, and software lifecycle(s) to be used in the software development processes, ref. DO-178B Section 11.2. It can be included in the PSAC and should contain the following, at a minimum: 

Standards



Software Lifecycle



Software Development Environment

Software Verification Plan (SVP)

The SVP is a description of the verification procedures to satisfy the software verification process objectives, ref. DO-178B Section 11.3. The procedures vary by software DAL as defined in the Tables of DO-178B Annex A. The SVP should contain the following, at a minimum: 

Organization



Independence



Verification Methods



Verification Environment



Transition Criteria

Software Configuration Management Plan (SCMP)

The Software Configuration Management Plan establishes the methods to be used to achieve the objectives of the software configuration management (SCM) process throughout the software lifecycle, ref. DO-178B Section 11.4. The SCMP should contain the following, at a minimum: 

Problem Reporting



Environment



Activities



Configuration Identification



Baselines and Traceability



Change Control



Change Review



Configuration Status Accounting



Archive, Retrieval, and Release



Software Load Control



Software Lifecycle Environment Controls



Software Lifecycle Data Controls



Transition Criteria



SCM Data



Supplier Control

Software Quality Assurance Plan (SQAP)

The purpose of the SQAP is to establish the methods to be used to achieve the objectives of the software quality assurance (SQA) process, ref. DO-178B Section 11.5. The SQAP should contain the following, at a minimum: 

Environment



Authority



Activities



Transition Criteria



Timing



SQA Records



Supplier Control

CERTON provides expert Quality Assurance assessment for compliance with DO-178B. Click here to view our Corporate Quality Assurance page. Software Requirements, Design & Coding Standards (SRDCS) The purpose the Software Requirements, Design, and Coding Standards is to establish a set of methods, rules, and tools that will be used in the development of the software item to promote consistency among processes, outputs, and artifacts. These standards will provide the constraints necessary to enforce clarity and consistency between developers and streamline the activities associated with requirements, design, and code development, validation, and verification throughout the software lifecycle to prevent errors that could cause safety issues, schedule impact, and budget overruns.

DO-178 Verification & Validation Phase The most important phase in the development of DO-178 Software is the Validation & Verification Phase. The V&V phase provides assurance for satisfying the RTCA/DO-178B objectives identified in Tables A-2 through A-9 have been satisfied according to the objectives in Table A-1. The majority of effort involved in a DO-178 project is associated with this phase of the software development lifecycle, beginning with the Requirements Phase and ending with the Delivery Phase. Developing testable requirements is crucial to streamlining the DO-178 Verification & Validation processes.

Validation Process The Validation process in this phase provides assurance that the correct software requirements and code have been developed according to the intended functions described in the System Requirements. The High Level Requirements are aligned with and validated against the System Requirements, the Design (Low Level) Requirements are aligned with and validated against the High Level Requirements, and the Code Implementation is aligned with and validated against the Design (Low Level) Requirements. Verification Process

The Verification process in this phase provides assurance that the executable object code performs the intended functions described by the validated High Level and Low Level Requirements while executing in the target operational environment. Test Cases are developed and reviewed for complete coverage (normal range and robustness) of the High Level Requirements (DAL A, B,C and D) and Low Level Requirements (DAL A, B, and C). Test Procedures are developed and reviewed to correctly and completely implement the Test Cases in a test environment according to the approved Software Verification Plan (SVP). The Software Verification Cases & Procedures document (SVCP) details how to reproduce the test setups and execution, along with a trace matrix for complete requirements based test coverage. The Verification process checks that expected results from the written requirements are equal to the actual results produced from the Black Box or Actual Flight Code. CERTON has developed CertSAFE™ and CertBENCH™ for Test Case development and fully automated Test Procedure execution against Black Box LRU, Circuit Cards, or SDK boards with the target processor.

Structural Coverage Analysis Structural Coverage Analysis at the source code level is broken down into three categories: 

Statement Coverage – during execution of requirements based testing, every statement in the program should be invoked at least one time.



Decision Coverage – during execution of requirements based testing, every point of entrance and exit in the program should be invoked at least once, and every decision in the program should take on all possible outcomes at least once.



Modified Condition/Decision Coverage (MC/DC) – during requirements based testing, every point of entry and exit in the program should be invoked at least once, every decision should take all possible outcomes at least once, every condition in a decision should take all possible outcomes at least once, and each condition in a decision should be shown to independently affect the outcome of that decision.

Code structures identified during Structural Coverage Analysis that are not exercised during requirements based testing may be the result of one or more of the following, ref. DO-178B Section 6.4.4.3: 

Shortcomings in the requirements based test cases and/or procedures



Missing or inadequate in software requirements



Dead Code



Deactivated Code

The Structural Coverage Analysis activity should also confirm the data coupling and control coupling between the code components. Note: Requirements based test coverage for data and control coupling should be identified as part of the separate data and control coupling analysis activities. Also, reference DO-248B, Section 3.43: Sections 6.4.4.2 and 6.4.4.3 of DO-178B/ED-12B define the purpose of structural coverage analysis and the possible resolution for code structure that was not exercised during requirements-based testing. The purpose of structural coverage analysis with the associated structural coverage analysis resolution is to complement requirements-based testing as follows: 1. Provide evidence that the code structure was verified to the degree required for the applicable software level; 2. Provide a means to support demonstration of absence of unintended functions; 3. Establish the thoroughness of requirements-based testing. Source to Object Code Trace Analysis (Level A Only) The compiler converts the Source Code into assembly object code before it is compatible with the target computer. For DAL A software, it is required to provide assurance that all assembly object code generated by the compiler is traceable to the source code. Any assembly object code that is not traceable directly to the source code requires additional verification to be performed in order to provide safety assurance and the absence of unintended behavior. DO-178 Requirements Phase The Requirements Phase uses the outputs of the System Lifecycle Process to develop the High Level Requirements. These High Level Requirements include functional, performance, interface, and safety-related requirements, ref. DO-178B Section 5.1. The inputs to the Requirements Phase are as follows: 

System Requirements Data (SRD) allocated to software



Hardware Interfaces and System Architecture



Software Development Plan



Software Requirements, Design, and Coding Standards (SRDCS)

The outputs to the Requirements Phase are as follows: 

Software High Level Requirements Document (SHLRD)



Software High Level Signal Dictionary (SHLSD)

Software High Level Requirements Document (SHLRD)

The Software High Level Requirements Document partitions and lists the high level requirements of the software item using functional decomposition to differentiate the functionality of the subcomponents. This includes operational, behavioral, and functional requirements. Derived high level requirements should be provided to the system safety assessment process. The V&V phase activities should commence as soon as a baseline of the SHLRD can be established in CM, including reviews for clarity, consistency, and most important testability. Software High Level Signal Dictionary (SHLSD)

The High level signal dictionary is used to capture a consolidated and universal list of all Input and Output signals to the software from a board level perspective in order to generate requirements that are testable from “end to end”. Ideally, this signal dictionary would be directly traceable to system level signals and schematics with a standardized naming convention for all signals. DO-178 Software Design & Architecture Phase The DO-178 Software Design & Architecture Phase uses the outputs of the Requirements Phase to develop the low level requirements. These low level requirements include details on the design and architecture that can be used to implement Source Code, ref. DO-178B Section 5.2. The inputs to the DO-178 Software Design & Architecture Phase are as follows: 

Software High Level Requirements Document (SHLRD)



Software High Level Signal Dictionary (SHLSD)



Software Development Plan



Software Requirements, Design, and Coding Standards (SRDCS)

The outputs to the DO-178 Software Design & Architecture Phase are as follows: 

Software Low Level Requirements Document (SLLRD)



Software Low Level Signal Dictionary (SLLSD)

Software Low Level Requirements Document (SLLRD)

The software low level requirements document identifies how the requirements are partitioned and lists the low level requirements of the software item. Low level requirements may contain implementation specific details of how the software will implement the functionality and behavior described in the high level requirements. Derived low level requirements should be provided to the system safety assessment process. The V&V phase activities should commence as soon as a baseline of the SHLRD can be established in CM, including reviews for clarity, consistency, and most important testability.

Software Low Level Data Dictionary (SLLDD)

The low level data dictionary contains a list of the input and output signals used in the SLLRD. This document also describes the attributes of the signals. This includes: the signal names, signal data types, operational ranges (min/max), memory map addresses, units, etc. Ideally, this data dictionary would be directly traceable to the Software High Level Signal Dictionary (SHLSD) with a standardized naming convention for all data. Implementation & Integration Phase The DO-178 Implementation & Integration Phase uses the outputs of the Design & Architecture Phase to develop the Source Code, ref. DO-178B Section 5.2. This Source Code will be compiled and loaded onto the target computer for verification. The inputs to the DO-178 Implementation & Integration Phase are as follows: 

Software Low Level Requirements Document (SLLRD)



Software Low Level Data Dictionary (SLLDD)



Software Development Plan



Software Requirements, Design, and Coding Standards (SRDCS)

The outputs to the DO-178 Implementation & Integration Phase are as follows: 

Source Code



Executable Object Code

Source Code

This is the Source Code implementation developed from the software architecture and low level requirements using the approved programming language specified in the SDP. This will be traceable to the low level requirements and reviewed in order to validate the correct Source Code has been developed. Executable Object Code

This is the assembly object code generated by the compiler from the Source Code that will be loaded onto the target computer as part of the integration process and verified using the the requirements based test cases and procedures, including HW/SW integration testing. For DAL A software, this will need to be shown to be directly traceable to the Source Code from which it was generated by the compiler. Delivery Phase The project delivery data should be maintained in the approved CM system, which is essential for satisfying the objectives of DO-178. In some cases, the final delivery data may be extracted from CM and burned to an electronic media format for final delivery to the customer. At this point the project is complete and ready for certification audit (SOI-4), assuming all other phases have been completed. Software Configuration Index (SCI)

The primary purpose of the Software Configuration Index is to identify the configuration of the Software product with specific information needed to produce the software item, including versions of source code files, build instructions, software load instructions, tools, etc. Software Environment Configuration Index (SECI)

The SECI lists the configurations of the environments used to develop and verify the software item. (For example: OS, compiler, linker, loader, libraries, emulator, etc…) This document should also be used to list the tools and versions used in the development and verification of the software item. This may include design tools, verification tools, requirements management tools, and test environments. Software Accomplishment Summary (SAS)

The primary purpose of this Software Accomplishment Summary is to show compliance to the plans and processes set forth in the PSAC. The SAS demonstrates to the Certification Authority that the objectives set forth in the planning documents have been achieved. Any deviation from the plans that has not been approved by the Certification Authority needs to be clearly described in the SAS.