Streamlining Compliance to ASPICE, ISO 26262, and ISO/SAE 21434 with Polyspace Static Code Analysis

Automotive software systems are playing an increasingly important role in the safety, reliability, and efficiency of today’s vehicles. As such, engineering teams are focused on delivering innovative functionality for advanced driver assistance systems (ADAS), battery management systems, stability control, and similar applications. Frequently, they must also ensure functional safety and cybersecurity requirements are met by demonstrating compliance with ISO^® 26262 and ISO/SAE^® 21434 requirements.

As a top-tier global automotive supplier, Ficosa International is developing software for a wide range of automotive applications. As part of the processes put in place to ensure compliance with industry standards, our engineering teams use Polyspace^® static code analysis products to measure and improve code quality throughout the entire development lifecycle—from implementation to unit verification, integration, and qualification testing. Many of the processes we use are based on a set of clearly defined software quality objectives, organized around factors such as the criticality of the component under development and the maturity level of the project. The software quality objectives plainly spell out acceptance criteria and thresholds for Polyspace static analysis metrics and coding guidelines such as MISRA™ and CERT^®/CWE™, as well as run-time errors. These criteria are now automatically evaluated and enforced on each software change as an integral part of our software development process. As a result, we have minimized subjectivity in code quality assessments, while improving overall development efficiency throughout the software development lifecycle.

The Evolution of Polyspace Usage at Ficosa International

In 2010, we began working on a project for a vehicle communication module. As part of the requirements for this project, the customer mandated the use of static analysis to check MISRA C™ compliance. After a thorough evaluation of commercially available static analysis products, we selected Polyspace products based on performance and cost. In the meantime, we were also phasing in Automotive SPICE^® (ASPICE) capability level 2 compliance, and we began using static analysis with Polyspace Bug Finder™ and Polyspace Code Prover™ in support of software unit verification activities.

Soon, our engineering teams began moving into other areas of ADAS and our customers began requiring ASPICE level 3 compliance. In parallel, we started several projects that required the fulfillment of functional safety requirements in accordance with ISO 26262. It wasn’t too long before some of our customers began requiring CERT C conformity and Common Weakness Enumeration (CWE) checks to ensure that secure coding standards were being met, in this case searching compliance with ISO 21434.

Static analysis with Polyspace products helped us support each one of these initiatives. From an organizational perspective, however, we lacked a comprehensive plan that clearly defined the techniques, measurements, and thresholds that we would apply—and when we would apply them—in our development and verification activities to ensure software quality. One disadvantage of not having a formal framework in place was that development teams tended to wait until later project phases to perform the static analysis, rather than performing it systematically from the start of the project. The results of static analyses conducted only late in development, understandably, included many violations, including numerous MISRA C violations. Because the project was in an advanced phase when the problems were identified, it was quite difficult to recover from such many violations by resolving them or justifying them.

To address this challenge, we seized the opportunity during a relative downtime in active projects during the 2020 pandemic to thoroughly analyze how Ficosa International could best meet our own software quality goals and those of our customers across multiple dimensions such as reliability, functional safety, and security. The end product of this analysis was a software quality objectives document, which our teams now use as the foundation for ensuring the quality of the software systems we deliver.

Defining Software Quality Objectives

Within the Ficosa International software quality objectives document, we define all the metrics and rules that come into play when verifying the software we develop, including those based on MISRA C, CERT C, and CWE, as well as software metrics such as cyclomatic complexity and comment density.

Next, we define criteria for applying the metrics and rules based on where the code being verified originated from, the type of component under development, and its maturity.

For example, we define different objectives for third-party code, legacy code, automatically generated code, and code written by hand (Figure 1). For third-party code, we run only mandatory MISRA C rules with the assuption that this type of code is supplied with other complementary quality evidence. For legacy code, generated code, and manual code, we impose increasingly stringent sets of rules. Components that have functional safety or security implications undergo additional checks in accordance with Automotive Safety Integrity Level (ASIL) requirements in ISO 26262 and cybersecurity assurance level (CAL) requirements in ISO/SAE 21434.

Further, we define more rigorous objectives for projects as a component progresses from early development (“A sample”) to intermediate, penultimate, and final delivery (“B, C, and D samples”). Lastly, we have a separate, reduced subset of rules and metrics for integrated code—that is, a set of components that have each passed their individual component software quality objective assessments are now integrated together as part of a larger system. This is very useful when simplifying the static analysis on complex software.

Integrating Static Analysis into Development Workflows

Once we had a document that unambiguously defined software quality objectives, we began integrating them into our development and testing processes using Polyspace static analysis products (Figure 2).

A key step in this process involved introducing a requirement for developers when they issue a pull request in Git™, our version control system. For a pull request to be approved, it must successfully pass certain static analysis checks from Polyspace Bug Finder and Polyspace Code Prover in addition to unit test results. This single change made a significant improvement in our overall workflow, because it established a gating mechanism that ensured developers could only successfully complete a pull request once they had thoroughly verified their code against the appropriate software quality objectives and then resolved or justified any issues that were identified during the static analysis.

During software integration and testing, Polyspace products are used to perform static analysis based on software quality objectives for integrated code. At this stage, checks on MISRA C compliance and code metrics are restricted to system-level rules and integrated software metrics. A focus is placed on integration-level issues such as concurrency access of shared memory, dead code, and critical run-time errors.

As we increase our adoption of continuous integration and continuous delivery (CI/CD) practices with Jenkins, frequent static analysis and continuous feedback enabled by Polyspace products will ensure our developers and integrators keep the source code aligned with target quality objectives. In addition, with the Polyspace Access™ web interface, all our teams can access a central database to review static code analysis results and monitor progress towards the delivery quality objective level.

Another important aspect to consider when developing functional safety products is to ensure that software tools do not introduce—or fail to detect—errors in the mass production software. ISO 26262 explicitly calls for a software tool qualification process to classify tools according to their criticality, and perform the necessary activities to qualify them. For Polyspace products, MathWorks provides a certification kit that supports both Bug Finder and Code Prover in the project scope.

Key Advantages

The use of well-defined software quality objectives with Polyspace products has led to several important advantages for Ficosa International in the development and delivery of automotive software in accordance with ISO 26262 and ISO/SAE 21434 standards.

One advantage is the steady increase in development skills among our developers. The detailed, rapid feedback they receive from Polyspace products helps them understand where and how they can improve the quality of their code, and that, in turn, enables them to become more skilled and more productive developers. In fact, with the processes we have in place, there is no alternative—they must understand and resolve the issues that are detected through static analysis.

Another important benefit we have realized is streamlined external quality assessments for ASPICE and ISO 26262, or other customer-required compliance objectives. Today, everything we do is easier to justify because we have clear software quality objectives in place along with reporting that shows, for example, far fewer MISRA and CERT deviations than in the past, along with evidence that our code has passed objective quality criteria.

Perhaps most importantly, Polyspace products have helped us achieve our quality objectives while increasing—or at least maintaining—efficiency. Often, when a governance team or similar group alters their organization’s development workflow to institute the type of early verification steps that we have implemented, developers view the additional steps they need to complete as extra effort. With Polyspace products, we were able to demonstrate to our teams that the extra step of performing static analysis for each pull request actually increased efficiency. They can deliver high-quality code more efficiently and with more confidence because all the errors found through static analysis are eliminated much earlier in the process instead of in the final stages.