The AUTOSAR C++ 14 guidelines are an update for MISRA C++ 2008, providing coding guidelines for modern C++ as defined by ISO/IEC 14882:2014.
The automotive industry has undergone radical changes in the last decade. New functionalities introduced to modern cars have fundamentally changed them into computing centers. This is reflected in the development of the platforms that are used for building automotive software, specifically AUTOSAR.
The classic approach, which assumed static configuration at compilation time, no dynamic memory allocation, and predominance of the C language, is no longer sufficient. New features like these require a lot of advanced code:
These new features also require changes in the paradigms that were sufficient for the classic approach. To address these challenges and improve automotive development, the AUTOSAR Consortium, which includes most of the leading car manufacturers in the world, released the new edition of the AUTOSAR standard in March 2017, called Adaptive AUTOSAR.
The release of the new standard does not invalidate the Classic Platform, it will still stay as a primary choice for control units with no connectivity needs, limited hardware requirements, and hard real-time functionality.
Adaptive AUTOSAR defines a platform for developing automotive control units that provide sophisticated functions like advanced driving assistance systems, media streaming, or software updates via the internet. The platform contains the specification of interfaces that define services and APIs. Some of the novelties introduced in Adaptive AUTOSAR include:
Adaptive AUTOSAR was an answer to the growing complexity of requirements for modern cars and new challenges that the connected world paradigm imposed on the automotive systems. The C language, which was the primary choice in the past for automotive developers, became a blocker, or at least the slowdown.
The complexity of the systems forced a switch from the C language to C++, which offers better support for structuring the large and distributed systems, and provides better mechanisms for data encapsulation.
Adaptive AUTOSAR relies on the C++14 language standard. The choice of the language standard version was a selection between “not too old” and “not too new.” On the one hand, we have C++98 and C++03, which are still widely used in the automotive industry, but outdated and don’t correspond to the modern development patterns. On the other hand, when the C++17 standard was published, it was fresh and there were arguments to leave behind the C++98 and C++03 including:
One of the main reasons not to go for C++17 was that the new features introduced in the standard may bring security risks to the systems—detecting and understanding security vulnerabilities require some time. In addition, C++ compilers that comply with the C++17 standard were still new and required more testing and better support for use in safety-critical development. So, the choice was made to rely on the C++14 standard as a reasonable middle option.
As the C++ language continues to evolve, today we have C++20 (ISO/IEC 14882:2020) replacing C++17.
In support of C++17, AUTOSAR and MISRA have joined forces in the development of safe and secure coding guidelines for the use of C++17 with plans to continue into C++20. For many organizations, this is very significant because modern C++ features offer new innovations that are important in developing systems. Using AI, for instance, relies on modern architectures, modern platforms, and modern libraries developed in the latest editions of C++.
The release of the Adaptive AUTOSAR platform increased the adoption of modern C++ in automotive projects. This made one specific problem much more visible: while the C++ language evolution has sped up in the last few years, automotive coding standards seem to have fallen behind.
At the time when C++11 and C++14 were released, the most popular automotive coding standard for C++, MISRA C++2008, was already seriously outdated and was addressing only C++03 version of the language.
With every year, the problem grew and became more nagging. Developers widely accepted the new features of the latest C++ standards and started using them without appropriate guidance or best practices. This situation was especially problematic for teams developing safety-critical systems, which are required by ISO 26262 to use static analysis with a suitable subset of coding guidelines.
To solve this problem, the AUTOSAR Consortium released the dedicated guidelines documentation as a part of the Adaptive AUTOSAR platform, which is titled, “Guidelines for the use of the C++14 language in critical and safety-related systems.” Relying on unmodified MISRA C++ 2008 would simply be an offense. The situation is depicted by the timeline below.
1998 – C++98 standard is released
2003 – C++03 standard is released
2008 – MISRA C++2008 (covers C++03)
2011 – C++11 standard is released
2014 – C++14 standard is released
2017 – AUTOSAR C++14 (March)
2017 – C++17 standard is released
2020 – C++20 standard is released
2022 – MISRA & AUTOSAR C++17 (TBA)
2022 – MISRA & AUTOSAR C++20 (TBD)
The AUTOSAR C++ 14 guidelines document is meant to be an update for MISRA C++ 2008 and provides coding guidelines for modern C++ as defined by ISO/IEC 14882:2014. The main application of this coding standard is the automotive industry, but it can be used in other industries where embedded programming is required.
The standard specifies 342 rules:
The standard is well documented and provides traceability to the other existing C++ standards, such as HIC++ 4.0, JSF, SEI CERT C++, C++ Core Guidelines, and of course to MISRA C++ 2008.
AUTOSAR C++14 follows the rules classification approach from MISRA C++ 2008. The rules are classified according to obligation level:
In addition, the rules are also classified whether they are enforced automatically by static analysis tools:
And finally, rules are classified according to allocation target: implementation, verification, toolchain and infrastructure. Rules in the AUTOSAR C++14 standard are tagged with the information about classification, for example:
In 2016, the MISRA consortium released a document titled, “MISRA Compliance:2016 Achieving compliance with MISRA Coding Guidelines.” This document has been updated and replaced by the “MISRA Compliance:2020” document.
The compliance documents have been very well-received in the industry, as they addressed an important need of defining the process of achieving compliance, specifying what exactly it means to be compliant.
AUTOSAR C++14 does not provide any similar guidance on the process of achieving compliance, at least not directly. But given that AUTOSAR C++ guidelines are based on MISRA C++ 2008, it is reasonable to refer back to the MISRA standard to look for guidance about the process of achieving compliance.
Fulfilling these requirements means some additional paperwork. The first thing that should happen is a definition of the compliance matrix, which is effectively a declaration of how we are going to enforce every guideline. See the example below.
The desired situation is to have a static analysis tool that covers as many guidelines as possible. The rules that cannot be enforced with static analysis will most likely require manual reviews, which are expensive.
In addition to the compliance matrix, a deviation handling procedure needs to be established. The deviation procedure formalizes the steps that need to be taken when development needs to deviate from a specific guideline. As MISRA prescribes it, it is expected that
“…the procedure will be based around obtaining a sign-off for every deviation or class of deviations.”
This is an important piece of the puzzle. It prevents abusing the deviation concept by developers deviating at will. Effectively, we will need some kind of formal tickets stored in our system that document every deviation in the source code. The same pertains to the compliance matrix and any additional configurations and process descriptions created to enforce compliance. MISRA C++2008 is very clear here and requires “formalization within quality system.”
Finally, if all of the procedures described in MISRA C++ 2008 point 4.3 are in place, we can claim compliance by demonstrating the following:
The “MISRA Compliance:2020” document is now mandated to be used with all future releases of MISRA Guidelines when making a claim of MISRA compliance. “MISRA Compliance:2020” updates the directions given in MISRA C++2008 for establishing the compliance process. Some teams may prefer to use it as a base for the AUTOSAR C++14 compliance process, as it is newer and more detailed.
Just as with MISRA C++ 2008, “MISRA Compliance:2020” requires a formal process for handling deviations and you must document stating enforcement methods for every applicable guideline. This document is called the Guidelines Enforcement Plan (GEP).
“MISRA Compliance:2020” extends the requirements for the compliance process and introduces some new concepts, like the Guidelines Recategorization Plan (GRP), which documents in a formal way any changes that are introduced to rule categories, and the Guidelines Compliance Summary (GCS), which is basically a final artifact from the compliance process that presents the level of compliance that was achieved for every guideline.
“MISRA Compliance:2020” also uses rule categorizations that were introduced in the MISRA C 2012, and are different from those in the MISRA C++ 2008 and AUTOSAR C++14 standards.
The only practical way to enforce compliance with a coding standard like AUTOSAR C++14 is with a static analysis tool, like Parasoft C/C++test, a code quality tool supporting multiple testing technologies. Parasoft C/C++test supports AUTOSAR C++ better than any other code quality tool.
AUTOSAR C++14 rules are a part of Parasoft’s Automotive Compliance Pack, which extends the functionality of Parasoft C/C++test for automotive developers specifically. In addition to the industry-specific static analysis rules such as AUTOSAR C++14, HIC++, and MISRA, Parasoft’s Automotive Compliance Pack brings a sophisticated interactive reporting system that is customized to the requirements imposed by AUTOSAR, HIC++, and MISRA, and enables an efficient daily workflow for the team.
Parasoft C/C++test enables developers to check the compliance of their code without leaving their IDEs, and integrates the scanning process into the CI builds on servers. With Parasoft’s automotive-specific reporting system, team members can continuously monitor their compliance process with ease.
When cleaning existing codebases, teams benefit from the ability to create compliance policies that define what assures the consistency of the testing practice. In such cases, it is a recommended practice to start with the subset of the rules from the standard, and progressively increase the number of active rules as cleaning of the code progresses. This reporting layer allows you to constantly monitor the progress of your codebase, control the deviation process, and make educated decisions about extending the ruleset.
The automotive industry is dynamically evolving. Among many other changes, we are witnessing the transformation of the car to an experience that’s more like using a smartphone. The concept of purchasing a specific functionality of a car in the form of an app is a reality. Long drive for vacation? Why not buy cruise control for 2 weeks?
To cope with these challenges and potentially reduce development time, the automotive industry needs constant innovation in the area of hardware and software platforms that are used in modern cars. These innovations need to be supported with appropriate standards, on various levels, which assure functional safety, quality, and security. AUTOSAR C++14 certainly contributes to this process.
But standards themselves are just a piece of paper (if we print them) and their implementation is simply not possible without tools that bring automation to the practices and processes and enable automotive software development teams to focus on delivering better and more advanced functionalities. Parasoft C/C++test is the most complete solution for safety-critical C/C++ development, with more support for automotive coding standards (AUTOSAR C++, CERT C/C++, MISRA) than any other tool vendor, and a dynamic, flexible, and useful reporting system that enables your whole team to succeed with compliance.
“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.