Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
?
EE Times-Asia > Embedded
?
?
Embedded??

Adopting aerospace verification standards (Part 2)

Posted: 23 Sep 2013 ?? ?Print Version ?Bookmark and Share

Keywords:DO-178C? avionics? MISRA? verification? Code coverage?

Part 1 of this series looked into a coding standards survey.

Source code verification checks that test cases have exercised all applicable requirements and highlights the sections of code that have and have not been executed. The identification of non-executed code pinpoints a number of potential shortcomings:
???Errors in the test cases
???Imprecise or inadequate requirements
???Not all requirements have been tested
???Dead code, i.e., code which is impossible to execute

Code coverage has several levels of precision; as a minimum, coverage reports need to show whether a line of source code has been executed at least once by the set of test cases. Statement coverage is the lowest precision sufficient to satisfy the requirements of DO-178C for software components which have a safety level C. Greater precision is required as the safety level increases to A.

DO-178C's requirement for structural coverage analysis. Section 6.4.4.2a of the DO-178C standard links coverage precision to the software level: "Activities include ... analysis of the structural coverage information collected during requirements-based testing to confirm that the degree of structural coverage is appropriate to the software level. Table A-7 formalizes the coverage which must be applied for each level." An edited summary of that is shown the table.

Table: An edited summary of Table A-7 of DO-278C Section 6.4.4.2a.

Statement coverage may be sufficient to identify missing test cases, as illustrated in the following code snippet:

if (reading > 10.0) {
??led_mode = 4;
??}
else {
??led_mode = 5;
??}

With red signifying covered code, it is clear that a new test case is needed to exercise the situation where "reading" is not greater than 10.

Statement coverage adequately identifies dead code such as the following:

if (reading > 10.0) {
??led_mode = 4;
??}
else {
??led_mode = 5;
??}
if (led_mode == 8) {
??update_panel();
??}

No matter how many additional test cases are created, the call to "update_panel" can never be reached. The root of the problem may be a design error in another part of the code, or the code in question may not trace to a requirement. Either way, the problem has been identified and can now be addressed.

Statement coverage simply indicates that a line of source code has been executed at least once. Typically, due to "if-then" branches and loops, there are several routes through a software component and, above safety level C, each route must be exercised and reported as covered. This is known as decision coverage and may be illustrated by the following code snippet:

led_mode = 0;
if (reading > 10.0) {
??led_mode = 4;
??}
update_panel();

The report shows that we have exercised the code with values of "reading" up to 10.0 but not above. Statement coverage would highlight this too, of course; however, it will not show the converse, i.e., values of "reading" above 10.0, but not below. And, we need to be sure that "update_panel" has been called with "led_mode" set to 4 and when left with its initial value of 0.

The highest level of coverage precision required under the directives of DO-178 is modified condition/decision coverage (MC/DC). This is reserved for software components assessed at safety level A and places the component under exhaustive testing to prove that each decision tries every possible outcome, each condition in a decision takes on every possible outcome, and each condition in a decision is shown to independently affect the outcome of the decision. In simple terms, we are concerned with the permutations of a compound condition as illustrated in this code snippet:

if (reading > 10.0 or submode == 3) {
??led_mode = 4;
??}
else
??{ ...

The coverage report needs to confirm that we have exercised the code where "reading" is both above 10.0 and below in combination with "submode" being 3 and some other value, i.e., 4 permutations.

Source code verification is vital in gauging the effectiveness of testing, whether in proving that all requirements have been satisfied or uncovering a problem with the design or requirements. This task cannot be undertaken manually, but instead requires investment in automated tools.

Fortunately, most test tools offer highly automated coverage analysis that is virtually transparent. Additional benefits gained from this include a significant increase in the quality of the code and of the overall test process. These benefits greatly impact the later stages of integration testing and beyond in object code verification.

Object code verification
While a key testing element of many avionics programs, object code verification has been a relatively unused technique outside the avionics industry. However, the increasing sophistication and safety-critical nature of many modern embedded control applications has led non-avionics suppliers to adopt object code verification.

DO-178C's requirement for Object Code Verification. Section 6.4.4.2b (Structural Coverage Analysis) of the DO-178C standard describes the requirement as follows: "Structural coverage analysis may be performed on the Source Code, Object Code or Executable Object Code. Independent of the code form on which the structural coverage analysis is performed, if the software level is A and a compiler, linker or other means generates additional code that is not directly traceable to Source Code statements, then additional verification should be performed to establish the correctness of such generated code sequences."

1???2?Next Page?Last Page



Article Comments - Adopting aerospace verification stan...
Comments:??
*? You can enter [0] more charecters.
*Verify code:
?
?
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

?
?
Back to Top