Want to see Parasoft in action? Sign up for our Monthly Demos! See Demos & Events >>
X
Want to see Parasoft in action? Sign up for our Monthly Demos! See Demos & Events >>
Reading Time: 5 minutesTeams wishing to streamline their ISO 26262 compliance efforts by applying AUTOSAR C++ coding guidelines will be more successful if they are well-informed when they select the static analysis tools for use in their project. Read on for some tips of the trade.
The C language, which dominated the automotive space for years, is no longer sufficient to address the growing complexity of automotive software architectures, and with the requirement of object-oriented design, C++ is a natural choice for many automotive teams. But C++ is a complicated language and requires a lot of effort to assure predictability, safety, and security.
The automotive functional safety standard ISO 26262 provides some guidance on the software development and V&V processes, but it does not go in depth at the level of language constructs. To get such guidance, organizations turn to coding standards like MISRA C/C++ or AUTOSAR C++. In this blog, I’ll share how to comply with ISO 26262 by using a static analysis tool that’s configured with AUTOSAR C++ 14 compliance checkers.
Compliance with a functional safety standard like ISO 26262 requires significant effort and needs to be an integrated part of the project from the very beginning. Even in the case of the software components, compliance requires specific activities during requirements gathering, planning, and implementation, and it is definitely not something that can be “added later.”
ISO 26262 specifies a collection of methods that are required to achieve compliance with the standard. To claim compliance, users must provide evidence that all applicable requirements and methods have been implemented. Not all methods apply to everyone. Applicability of the method depends on the Automotive Safety Integrity Level (ASIL), which is a risk classification defined in the standard (ASIL A represents the lowest degree and ASIL D represents the highest degree of automotive hazard). The method can be highly recommended, recommended, or neutral.
The challenge that teams are typically facing when trying to comply with the standard is how to implement the methods that are recommended for their processes. The decision on how to comply with the specific method or requirement is frequently based on the team experience. In some simple situations, manual procedures and reviews can be an answer, but in most cases, teams are trying to find tools that can automate required methods.
A tool that is used to comply with ISO26262 has to be approved for the intended use through the formal process called tool qualification. The objective of the qualification of software tools is to provide evidence of software tool suitability, for use when developing a safety-related item or element. This can be a time and resource consuming task. (If you’re using Parasoft C/C++test, it is supported with an automated qualification kit that streamlines the qualification process and includes a TÜV SÜD certification that in many situations is sufficient for tool qualification.
Following a coding standard like AUTOSAR C++ is a widely accepted method for satisfying some of the requirements stemming from ISO 26262. AUTOSAR C++ 14 provides the traceability tables that map ISO 26262 principles and recommendations to the appropriate coding guidelines. The mapping covers mainly section 8 of Part 6 of ISO 26262, and highly simplifies the process of achieving compliance with corresponding methods and requirements from the standard.
But the AUTOSAR C++ 14 coding guidelines alone are not sufficient to achieve compliance with ISO 26262 for the software component. Some methods in the standard can’t be covered with the application of AUTOSAR guidelines, such as methods 1g, which recommends “Use of style guides,” or method 1h, which recommends “Use of naming conventions.” AUTOSAR C++ 14 does not include any style guides or naming conventions. Both of these methods, however, can be easily implemented with Parasoft C/C++test, which includes more than 3000 static analysis checkers, including code style checkers, and provides a module for creating a custom static analysis rules. Methods in the standard that can’t be implement with static analysis in general require other testing techniques such as fault injection testing.
So of course this brings us to finding the right tool to make compliance easiest. Introducing the coding standard compliance process into the team development workflow is not an easy task. As such, it is very important to select a tool that will help in achieving compliance without imposing too much overhead and without the requirement for additional manual procedures. The following points are important decision-making factors when selecting the solution for static analysis.
AUTOSAR C++ 14 defines a substantial number of the guidelines. The most up-to-date version of the AUTOSAR coding standard contains at this moment approximately 400 guidelines, with 350 of these guidelines possible to be enforced with static analysis. Supporting this number of guidelines is a challenge for static analysis tool vendors, and not all static analysis tools available on the market cover the standard sufficiently enough for compliance. (Shameless plug: Parasoft C/C++test is the leading solution in this case, covering the highest number of the AUTOSAR C++ guidelines, and continuing to implement more every day.)
Guidelines defined in the AUTOSAR C++ coding standard have different levels of complexity. Some are simple guidelines that can be enforced with relatively simple static analysis technology, but there are also guidelines that require sophisticated data and control flow analysis to simulate the paths in the analyzed source code and decide if a given guideline is violated or not.
The static analysis tool you choose has to evaluate the paths in the code to correctly determine if the index that is used for accessing the data in the container is within the correct range or not. Many commercial tools and most open-source tools on the market apply very rudimentary flow analysis to this class of problems, and in effect they either miss an issue in the code or report an enormous number of false positives, which consume a huge amount of time to review, and kill productivity. When benchmarking a static analysis tool, I would highly recommend that you put special attention on comparing results for more complex guidelines, which require flow analysis technology.
Although AUTOSAR C++ does not explicitly require tool qualification to approve the static analysis solution for use, ISO 26262 does. So when planning to use AUTOSAR C++ for streamlining the compliance with ISO 26262, it is recommended to pick a static analysis solution that supports end-users with appropriate certificates and a qualification kit.
Following a coding standard like AUTOSAR C++ 14 can help organizations achieve compliance with ISO 26262, as there are multiple methods and requirements defined in the ISO 26262 standard that can be satisfied by conforming with the AUTOSAR coding guidelines. AUTOSAR C++ 14 provides dedicated traceability tables that demonstrate the mapping between ISO 26262 requirements and the coding guidelines, and teams wishing to streamline their ISO 26262 compliance efforts by applying AUTOSAR C++ coding guidelines will be more successful if they are well-informed when they select the static analysis tools for use in their project.
“MISRA”, “MISRA C” and the triangle logo are registered trademarks of The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. All rights reserved.
Product Manager for Parasoft's embedded testing solutions, Miroslaw's specialties include C/C++, RTOSes, static code analysis, unit testing, managing software quality for safety critical applications, and software compliance to safety standards.