Validation & Verification Phase
The most important phase in the development of DO-178B 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-178B project is associated with this phase of the software development lifecycle, beginning with the Requirements Phase and ending with the Delivery Phase.

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 CERTTEST and CERTBENCH Tool sets 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:
- Provide evidence that the code structure was verified to the degree required for the applicable software level;
- Provide a means to support demonstration of absence of unintended functions;
- 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.

Welcome,


