DO-178B

C++test can be used as a qualified tool for DO-178B standard compliance

To get C++test Qualification Kit for DO-178B/ED-12B click here.

DO-178B, Software Considerations in Airborne Systems and Equipment Certification is a guidance for software development published by RTCA, Incorporated. The standard was developed by RTCA and EUROCAE. The FAA accepts use of DO-178B as a means of certifying software in avionics. The standard specifies what tool can be qualified as verification tool in DO-178B process.

Parasoft C++test can be used as qualified tool for DO-178B. Why? Lets see:
According to the DO-178B standard, tools can be divided into two categories. Below you can find direct quotation from the section 12, 'Tool Qualification' of the standard.

“Software tools can be classified as one of two types:

Software development tools: Tools whose output is part of airborne software and thus
can introduce errors. For example, a tool which generates Source Code directly from
low-level requirements would have to be qualified if the generated Source Code is not
verified as specified in section 6.

Software verification tools: Tools that cannot introduce errors, but may fail to detect
them. For example, a static analyzer, that automates a software verification process
activity, should be qualified if the function that it performs is not verified by another
activity. Type checkers, analysis tools and test tools are other examples.”

Based on the above it is clear that C++test belongs to 'Software verification tools' category since its output cannot introduce any errors into the software to be certified. If so, the standard provides following guidelines to consider the tool qualified.
Direct quotation from the standard says:

“12.2.2 Qualification Criteria for Software Verification Tools
The qualification criteria for software verification tools should be achieved by demonstration
that the tool complies with its Tool Operational Requirements under normal operational
conditions.”

and further:

“12.2.3.2 Tool Operational Requirements
Tool Operational Requirements describe the tool's operational functionality. This data should include:

1. A description of the tool's functions and technical features. For software development
   tools, it includes the software development process activities performed by the tool.
2. User information, such as installation guides and user manuals.
3. A description of the tool's operational environment.
4. For software development tools, the expected responses of the tool under abnormal
   operating conditions.”

Point d) of section 12.2.3.2 is not relevant to C++test because it concerns software development tools; not verification tools. So, there are only a), b) and c) to consider. When we look into the manual delivered with C++test itself, it is not hard to recognize that all of the above points are met. For example, a description of the operational environment can be found in the 'Supported environments' section. The Installation guide can be found in the 'Installation' section. A description of the tool functions and technical features can be found in the following chapters:

• Coding Standards Static Analysis
• BugDetective (Data Flow) Static Analysis
• Code Review
• Test Generation and Execution
• Cross-Platform and Embedded Testing

However, if certification authorities would require additional documentation to regard C++test as a software verification tool, (as described in the section 12.2.4 of the standard) Parasoft is always of help to assist and promptly provide required documentation.

Therefore, we can definitely consider C++test as a qualified software verification tool, or as one which is “qualificable” since – according to the standard – qualification is always considered with relation to particular project.

Detailed relevance to C++test functional aspects

1. C++test provides 5 types of code coverage, including decision and modified condition/decision coverage. C++test does not directly provide statement coverage. This can be achieved though by ensuring that only one statement is used per line. To control that compliance one can use C++test static analysis feature – to be precise an JSF-42-3 rule, which is a part of JSF coding standard (JOINT STRIKE FIGHTER, AIR VEHICLE, C++ CODING STANDARDS Chapter 4.9 Style, AV Rule 42). See details in C++test manual.
2. C++test supports two types of static analysis – code structure and data/control flow analysis. As a part of it C++test supports following recognized standards: JSF, MISRA C, MISRA C 2004, MISRA C++ 2008. In addition to that C++test supports less recognized, yet very useful rule sets, like: Qt Best Practices, Effective STL, Ellemtel, Effective C++, Sutter-Alexandrescu, and many many other useful rules, not necessary falling into named standards (security, memory management and others). See details in C++test rules reference documentation.
3. Both static and dynamic analysis are supported for C and C++. There is no support for ADA.
4. This point can be achieved by annotating test cases in C++test with requirement reference tags. In such case test case results, sent to Parasoft Report Center, can be automatically related to previously imported requirements (from DOORS or other RM systems). One can monitor how many requirements do have test cases and what was the outcome of such test case. Below is presented an exemplary graph (herein requirements are under “enhancements” label). Yellow color denotes requirements not implemented yet, orange – implemented but without tests, green – implemented with tests which passed and red – implemented with tests that failed.