Why Changes ?

• No update since last two decades
• Advancement in SW Engineering / New Technologies (like MBD, OOT, Formal Methods…)
• CAST Papers (33 as of today)
• Tool Qualification
• How to use COTS and previously developed software
• To address known issues – DO248B

New document structure:

Core document

• DO-178C, Software Considerations in Airborne systems and Equipment certification.
• DO-248C, Supporting Information for DO-178C.

Supplement documents

• DO-330, Software Tool Qualification Considerations.
• DO-331, Model-Based Development and Verification Supplement to DO-178C
• DO-332, Object-Oriented Technology and Related Techniques Supplement to DO-178C
• DO-333, Formal Methods Supplement to DO-178C

Objectives:

Change Categories:

1. Errors and inconsistencies
2. Inconsistent terminology
3. Unclear descriptions
4. Hidden objectives
5. Gaps and new topics

Errors and inconsistencies:

1.1- Error in Table A-7

Now in DO178C

1.2 Table 7-1: Error in cross reference

In DO178C……

1.2b Table A-4: Error in cross reference

In DO178B……

In DO 178C

Is Testing a process or activity?:

1.3- Testing: process or activity?

Since verification is a combination of analyses, reviews and test, the term “testing process” is incorrect.

• The title of Section 6.4 is changed from “Software Testing Process” to “Software Testing”
• The title of Figure 6.1 is changed from “SOFTWARE TESTING PROCESS” to “SOFTWARE TESTING ACTIVITIES”
• In section 6.4, 2nd paragraph, the word “process” is replaced with “activity”. The text now reads: ”Figure 6-1 is a diagram of the software testing activities…”.

1.4- Partitioning integrity

• Partitioning : Partitioning is a technique for providing isolation between functionally independent software components to isolate faults.
• DO-178B Section 6.3.3 deals with verification of the Software Architecture. In particular, item ‘f’ addresses the integrity of the partitioning. The original text was: “The objective is to ensure that partitioning breaches are prevented or isolated”.
• For some time the phrase “or isolated” at the end of this sentence has been known to be inappropriate. Errata #5 from ED-94B/DO-248B thus suggests deleting this phrase from the sentence, resulting in the following wording: “The objective is to ensure that partitioning breaches are prevented.” This change has been made in ED-12C/DO-178C

In DO 178B…

Changes….

In DO178C

Section 5.3.2 Software Coding Process Activities:

in DO 178B

• Additional changes were made in both the Software Coding Process and Integration Process sections to clarify that object code is not an output of the software coding process but rather an intermediate product of the integration process:

Software Coding Process :

Compiler warnings :

in DO 178B

in DO 178C..

1.6- Control Category of Design Description (level C)

2. Inconsistent Terminology

2.1 “Guidance “and “Guidelines”

2.2 “Objectives” and “activities”

In DO 178B …

In DO178C..

2.2.1- New activity in Software planning process

One objective of the software planning process (Section 4.1) is to address the additional considerations such as those described in Section 12. However, in the Planning Process Activities section (4.2), there was no activity related to the satisfaction of this objective.

A new bullet is thus added: section 4.2, Point k

2.2.2- New activity in Design process (data flow & control flow)

The primary objective of the Design process is to develop the architecture and the Low-level requirements. Control and Data flow are part of the architecture, but none of the Design Process activities required developing this subset of the design data.

A new activity is thus added: section 5.2.2.d

2.2.4- Verification process chapter reorganization

2.2.5- Software Configuration Management Process objectives

2.2.6- Traceability to activities in the objective tables

For the sake of completeness and to assist in the correct understanding of the document, the tables in Appendix A now provide (for each objective) the references to all sections where the suggested activities are listed, in addition to the references to the sections where the objective itself is described

3 Unclear descriptions

3.1 Coordinated System/Software Aspects

3.1.1 System requirements allocated to software

3.1.2 Contribution of a software error to system failure / Failure Condition Categorization / software level

New section 2.3.1 Relationship between software errors and Failure conditions

3.2 Figure 6.1 : Software testing

in DO 178C

3.3 Robustness

• A note is added in the section 6.4.2 on requirements-based test selection:

Some additional information is provided in section 4.5 on Software Development Standards

3.4 Derived requirements

• DO178B Glossary Definition :-

-Additional requirements resulting from the software development processes, which may not be directly traceable to higher level requirements.

• DO178B Section 5, Definition :-

-Derived requirements are requirements that are not directly traceable to higher level requirements.

• DO178C Glossary Definition :-

• Eg : 1. Interrupt handling requirements, periodic monitor’s iteration rate.

2. The addition of scaling limits when using fixed point    arithmetic.

• Have to provide reason/rationale for derived requirement existence.

DO178C, section 5.1.2, Point ‘h’

• Have to submit derived requirements for system process

3.4 Traceability

Traceability : DO178B was unclear on

1. Data items
2. Top-down or bottom- up ?
3. What is trace data ?
4. Purpose and activities of traceability.

Section 5.5. is a new addition to address software development process traceability

Section 6.5 (new) provides the purpose of the traceability, as long as verification data are concerned:

3.4 Deactivated code

• Deactivated code should be traceable to requirement.
• Defensive programming structure, Compiler inserted object code, error or exception handling routine, time stamps are often mistakenly considered as deactivated code

Deactivated code classifications

• if Category 1 (not intended to be activated) – prove that the code cannot be inadvertently activated.
• if Category 2 (executed in certain approved configurations) – write test cases to prove that the code complies with the requirement(s).

Section 5.2.4, Designing for deactivated code (New)

3.4 WCET and Stack analysis

WCET (Worst Case Execution Time) and Stack analysis were identified in DO-178B/ED-12B as part of reviews and analysis of the source code verification process (objective “accuracy and consistency” in 6.3.4.f). This could be considered as acceptable 25 years ago, when assembler language was heavily used. But now, it is obvious that time and memory assessment might not be achieved through reviews and analysis of source code.

New additions :-

• In section 6.3.4.f, a sentence is added, requiring that compiler, linker and hardware to be assessed for impact on WCET.
• In the introduction to the section on software reviews and analysis (section 6.3), it is also identified that reviews and analysis alone may not completely satisfy some objectives (e.g. WCET, stack analysis) and that some tests may be also necessary

Section 6.3 updated for WCET and stack analysis

3.7 Additional considerations in verification process

The section providing an overview of the software verification process activities (6.2) adds considerations on:

• Reverification and independence

3.8 Structural coverage analysis

• Clarified that the structural coverage analysis of data and control coupling between code components should be achieved by assessing the results of the requirements-based tests (see section 6.4.4.2c).

• Clarified that all tests added to achieve structural coverage are based on requirements (see section 6.4.4.2d)

3.9 MC/DC definition

• The “Modified Condition/Decision Coverage” (MC/DC) definition is changed.
• Masking MC/DC, Short Circuit, Coupled conditions (same variable used in multiple conditions) as well as DO-178B’s interpretation of MC/DC (often termed Unique-Cause MC/DC), are now allowed.

Eg :

• Unique-cause MC/DC : (A&B)|(C&D)
• Coupled conditions :   (A&B)|(B&D)

Hidden objectives

• DO-178C added the so-called “hidden objectives” to Annex A:
• A means for detecting additional code that is not directly traceable to the Source Code and a means to ensure its verification coverage are defined

Table A-7 (added item #9, objective for additional code verification)

• Assurance is obtained that software plans and standards are developed and reviewed for consistency.

Table A-9 (Updated for SQA objectives)

4 Gaps and New Topics

4.1.1 Parameter data item (PDI)

Parameter data item

New objectives for parameter data item

Table A5 : Verification of software coding and integration process

4.1.3 Extraneous code

4.1.4 Objectives for Level D software

An inconsistency was identified in the objectives applicable to level D software in DO-178B/ED-12B: Though Table A2 was requiring both Design data and Source Code to be developed; none of the verification objectives associated with these data were applicable (except verification of partitioning integrity).

In DO-178C/ED-12C, the objectives of the development processes A2-4 (LLR), 5 (Derived LLR) and 6 (Source code) are no longer applicable to level D. The main benefit is to ease the use of COTS for level D software, as these data do not need to be provided for certification.

DO178C, Table A2

4.1.5 Single Event Upsets

• The definition of Single Event Upsets (SEU) is added to the Glossary as “random bit flips in data that can occur in hardware.”
• Even if the origin of SEU susceptibility is hardware, mitigation for its effects may be made in software or hardware. This could be a decision of a system process, and then that will flow down to the software processes.
• A note is added in the section 4.5:

Supplements

• The fundamental idea is to keep the core document as much as possible independent of any methods or techniques
• A long term objective is to add new supplements in future without modifying the core document DO-178C.
• Each supplement provides first all information about method and techniques which are being addressed. Then from section 2 to 12, and annex A (objectives table) the supplement uses exactly the same sections and subsections as the cored document.
• Addition or modification are written in ‘Normal’ text style and unchanged things are written in ‘italic’ text