The automotive industry has undergone radical changes in the last decade. New functionalities that have been 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 the 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 require a lot of advanced code, such as:
- Automated driving
- V2X communication (vehicle-to-vehicle and vehicle-to-infrastructure communication)
- Continual over-the-air updates
- High definition multimedia
- AI computing, image recognition
These new features also require changes in the paradigms that were sufficient for the classic approach. To address these challenges, the AUTOSAR Consortium, which includes most of the 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 which provide sophisticated functionalities like advanced driving assistance systems, media streaming, or software updates via internet. The platform contains the specification of interfaces that define services and APIs. Some of the novelties introduced in Adaptive AUTOSAR are:
- Object Oriented approach
- C++ programming language
- Service oriented architecture
- POSIX operating system
- ECU configuration changes during system runtime
- Over the air deployment and updates
C is not enough
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 they are outdated and do not correspond to the modern development patterns. On the other hand, we have the C++17, standard which is still very fresh. The argument to leave behind the C++98 and C++03 was:
- Substantial evolution/improvements of C++ language
- Availability of better compilers
- Availability of better testing and analysis tools
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 C++17 standard are still very new and require more testing and better support for use in safety-critical development. So, the choice was made to rely on C++14 standard as a reasonable middle option.
What about coding guidelines?
The release of the Adaptive AUTOSAR platform increased the adoption of modern C++ in automotive projects. This made one specific problem to be very visible: while the C++ language evolution speeded up in the last years, the automotive coding standards seemed to fall 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 was growing and becoming more nagging. Developers widely accepted the new features of the latest C++ standards, and started using them without appropriate guidance. This situation was especially problematic for teams developing safety-critical systems which are required by ISO26262 to use static analysis with suitable set of coding guidelines.
To solve this problem, the AUTOSAR Consortium released the dedicated guidelines document as a part of 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 (December)
AUTOSAR C++14 Coding guidelines
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:
- 154 rules are adopted from MISRA C++ 2008 without modifications (67%)
- 131 rules are based on existing C++ standards
- 57 rules are based on the research or other literature or resources
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:
- Required rules: mandatory for claiming compliance with the standard
- Advisory rules: recommended but without mandatory status
In addition, the rules are also classified according to enforcement by static analysis tools:
- Automated: can be fully supported by static analysis tools
- Partially automated: can be supported by static analysis tools but may require additional practices such as code review
- Non-automated: cannot be supported with 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:
How do I become compliant?
In 2016, the MISRA consortium released a document titled, “MISRA Compliance:2016 Achieving compliance with MISRA Coding Guidelines.” This document was very well-received in the industry, as it addressed a very 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 guidelines are based on MISRA C++ 2008, it is reasonable to refer back to the MISRA standard to look for the guidance about the process of achieving compliance.
MSRA C++2008 discusses the compliance requirements with fewer details and attention than the “MISRA Compliance:2016” document; however, in section 4.3, we can find some hints on the process adoption:
- Produce a compliance matrix which states how each rule is enforced
- Produce a deviation procedure
- Formalize the working practices within the quality management system
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 (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 deviations 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, “is expected that the procedure will be based around obtaining a sign-off for every deviation or class of deviations.”
This is a very 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:
- A compliance matrix has been completed that shows how compliance has been enforced
- All of the C++ code in the product is compliant with the rules of MISRA C++2008 document or subject to documented deviations
- A list of all instances of the rules not being followed is being maintained and for each instance there is an appropriately signed-off deviation
The “MISRA Compliance:2016” document 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:2016” 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:2016” 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:2016” 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. These differences, however, do not seem to be fundamental, and adopting “MISRA Compliance:2016” as a base for AUTOSAR C++14 is certainly an option.
Where do we go from here?
The automotive industry is dynamically evolving. Among many other changes, we are witnessing the transformation of the car to a device more akin to a mobile phone, perhaps. The concept of purchasing a specific functionality of a car in form of an app is a reality. Long drive for vacation? Why not to buy a cruise control for 2 weeks?
To cope with these challenges, 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 process and enable automotive software development teams to focus on delivering better and more advanced functionalities.
The only practical way to enforce compliance with a coding standard like AUTOSAR C++14 is with a static analysis tool with sophisticated reporting that aligns with the requirements imposed by the standards. To get started with compliance, it is important to start with a phased and organized approach, especially when cleaning existing code bases. 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. Great reporting will allow you to constantly monitor the progress of your codebase, control the deviation process, and make educated decisions about extending the rule set on your path to compliance.