Using Static Analysis and Code Verification to Improve Embedded Software
Page 2 of 4
Based on these criteria, the document establishes six Software Quality Objectives (SQO); SQO-1 requires meeting just a few criteria, and SQO-6 requires fulfilling all criteria. Selecting the appropriate SQO for a project depends on:
- The project’s criticality;
- The organization’s internal quality processes, which may include the application of Capability Maturity Model Integration (CMMI) or Software Process Improvement and Capability Determination (SPICE);
- The need to abide by standards such as IEC 61508, ISO 26262, or DO 178B.
Table 1 shows criteria applicable to various SQOs. Some of the criteria have an associated threshold metric. Exceeding the threshold triggers achievement of a specific SQO. For example, to achieve SQO-1, an organization must have a quality plan, a detailed design description, and a set of established code metrics. To achieve SQO-2, the organization must additionally adhere to basic coding standard rules, eliminate all systematic run-time errors, and verify that non-terminating constructs do not exist in the code. To achieve SQO-3, the organization must further prove that there are no unreachable branches (dead code).
Using a Language Subset to Comply With Coding Standards
Table 2. The implementation of a function (right) with its incorrect prototyping and usage (left).
General purpose languages, including C and C++, have been designed to cover a wide range of applications, from desktop software to embedded systems. With extensions such as C99 for the C language and those provided by the GNU or Visual C++ compilers, these languages have evolved to allow more design patterns. The drawback to these advances is the increased cost of verifying complex code. More complex languages are more difficult to verify, either by hand or using an automated tool. To simplify verification, most standards, including IEC 61508 and ISO 26262 (table A.3), restrict the use of the language to a limited subset. To comply with the standard, an organization must use only those features of the language allowed by it. The quality model illustrated in Table 1, for instance, requires adherence to the MISRA-C:2004 coding standard.
In addition to making code easier to verify, coding standards also lead to code that is easier to read, maintain, and port. In general, the adoption of a coding standard does not mean that every rule specified in the standard must be enforced. The automotive OEM quality model previously described establishes two subsets of MISRA-C coding standards. The first subset, which is required for SQO-1 through SQO-4, includes rules such as:
- 8.11: The static storage class specifier shall be used in definitions and declarations of objects and functions that have internal linkage.
- 8.12: When an array is declared with external linkage, its size shall be stated explicitly or defined implicitly by initialization.
- 13.3: Floating-point expressions shall not be tested for equality or inequality.
- 20.2: Dynamic heap memory allocation shall not be used.
The second subset, which is required for SQO-5 and SQO-6, includes rules such as:
- 8.7: Objects shall be defined at block scope if they are only accessed from within a single function.
- 9.2: Braces shall be used to indicate and match the structure in the non-zero initialization of arrays and structures.
- 13.1: Assignment operators shall not be used in expressions that yield a Boolean value.
- 20.3: The validity of values passed to library functions shall be checked.