Static Analysis in Automotive SPICE

The Automotive SPICE (software process improvement and capability determination) is a software development process standard that outlines the maturity model for software development, management and business processes. SPICE defines how to assess the capabilities of a software organization’s level of maturity. An organization seeking compliance to SPICE needs to follow the guidelines outlined in the PAM (process assessment model) – the document discussed here is Automotive SPICE® Process Reference Model Process Assessment Model Version 3.0.

An automotive software organization when deciding to adopt a SPICE-compliant process and determine the level of maturity of the process, they need to use the published guidelines in order to achieve and verify compliance during a process assessment. SPICE focuses more on software development management and business practice and is complementary to a functional safety standards such as ISO 26262 (we’ve done several posts on ISO 2626, for example, this one.) There’s a solid business case for using static analysis in ISO 26260 so this post considers is such a case exists for Automotive SPICE.

Where and Why Does Static Analysis Fit in SPICE?

SPICE categorizes aspects of the model on process groups. Of interest here is the Software Engineering process group (SWE) which is further broken down into the typical phases of the development life cycle. The SWEs of interest is for software unit verifications which includes guidelines for code inspection and static analysis.

Source: Automotive SPICE PAM – Table 5 — Primary Life Cycle Processes – SWE process group

In particular these subsections of SWE.4 call out static analysis and MISRA C/C++ coding standards.

SWE.4.BP2: Develop criteria for unit verification. Develop criteria for unit verification that are suitable to provide evidence for compliance of the software units with the software detailed design and with the non-functional requirements according to the verification strategy. For unit testing, criteria shall be defined in a unit test specification.

NOTE 2: Possible criteria for unit verification include unit test cases, unit test data, static verification, coverage goals and coding standards such as the MISRA rules.

SWE.4.BP3: Perform static verification of software units. Verify software units for correctness using the defined criteria for verification. Record the results of the static verification.

NOTE 4: Static verification may include static analysis, code reviews, checks against coding standards and guidelines, and other techniques

In appendix D subsection D.6 “Evaluate”, “Verification Criteria” and “Ensuring compliance” gives MISRA as an example of coding standards and guidelines.

“…Criteria for unit verification ensure compliance of the source code with the software detailed design and the non-functional requirements. Possible criteria for unit verification include unit test cases, unit test data, coverage goals and coding standards and coding guidelines, e.g. MISRA. “

Clearly, the assessment model is recommending both the use of relevant coding standards and static analysis. Since MISRA C/C++ compliance are best measured with static analysis tools, it’s a fairly strong recommendation at that. So what are the benefits of static analysis in Automotive SPICE? There’s more to advanced static analysis than “static verification” or coding standard compliance (although still important processes and capabilities.)

Benefits of Static Analysis Tools

Advanced static analysis tools such as GrammaTech CodeSonar provide tangible productivity improvements to software teams seeking static verification while also satisfying stringent software safety certification criteria (.e.g. ISO 26262). Using a qualified tool as part of the software development process from early stages of development can have significant benefits: 

• Enforcing coding standards for safety, security, and style. Automating code analysis during code development ensures quality in the development stream every day.
• Reducing manual effort in proving software robustness and behavior. Static analysis tools augment software testing by providing more assurance of software quality.
• Reducing number of defects throughout development. Code that works the first time is much cheaper to test and integrate than buggy code. Bugs removed from the code before testing (or even source configuration management) reduces costs and risk.
• Finding serious defects that elude testing. Software testing in safety critical software is exhaustive and, depending on the level of concern (ASIL), require complete statement and or decision coverage. Despite this testing rigor, static analysis tools have found defects that were missed.
• Analyzing Legacy and Third Party Code. Use of third party code such as commercial off-the-shelf software (COTS) and open-source software is a fact of life in embedded software development. CodeSonar can analyze third-party source and binaries to discover defects and security vulnerabilities in software that could be impossible to test otherwise (without including it and running it, an expensive option).
• Accelerating certification evidence. Documenting the results of software unit acceptance is critical to proving compliance to certification standards. Static analysis tools have rich reporting features to help support certification requirements.

Tool Qualification

Although SPICE doesn’t discuss tool qualification, it’s not in the scope of the PAM. However, when tools are used in safety critical software, confidence is required in an automated tools’ results in order for them to be acceptable as certification evidence. To address this, tools vendors can seek certifications for the products they sell as well. Recognizing this need, GrammaTech CodeSonar is independently certified for ISO 26262, IEC 61508, and EN 50128. This means that developers can use CodeSonar with confidence that the results produced are acceptable to approval bodies during certification. It’s just too risky to use unqualified tools, which will only result in further testing, documentation, and certification costs.

Summary

Automotive SPICE PAM makes a strong case for using static analysis to support software unit verification by supporting static verification and coding standard compliance. Static analysis also plays an important role in the development safety critical software complying with functional safety standards such as ISO 26262 (a complementary standard to Automotive SPICE.) Advanced static analysis tools such as CodeSonar can certainly support the required static verification of code but also adds value in areas such as third-party code evaluation and accelerating certification evidence.

Interested in learning more? Read our guide on “Advanced Driver Assistance Systems (ADAS), Safety, and Static Analysis”

{{cta(‘b8d7f680-6ed2-417c-a478-422e2f0773ea’)}}