The AUTOSAR C++14 coding guidelines – “Guidelines for the use of the C++14 language in critical and safety-related systems” – were developed circa 2017-2018, by a specialist sub-group of AUTOSAR members. They were developed with the specific intention to develop a new safer C++ coding standard that would allow them to make greater use of the evolving C++ language; specifically, the new C++11 and C++14 coding features.
At that time, the existing MISRA C++ 2008 coding standard for C++ explicitly required the use of the C++ 2003 language version and did not allow for the modern C++ constructs to be used. This meant that developers in the fast-moving automotive sector of the time – with new requirements around autonomous and semi-autonomous driving systems – were left with the choice of either reverting to older and more restrictive versions of the C++ language, or with coding guideline rules that didn’t really fit much of the new software being developed. And for safety critical automotive software systems coding guidelines or standards are considered a key piece of the related ISO 26262 functional safety system. Thus, AUTOSAR C++ 14 was born.
The latest incarnation of the MISRA C++ standard, which is currently under development, will also address the use of more modern versions of C++ within a safer and more maintainable context, with support for C++ 17. However, as this is not yet released, it is anticipated that the AUTOSAR C++14 will remain widely used within the safety related C++ software markets for some time to come.
AUTOSAR C++14 Revisions
The AUTOSAR C++14 group released revisions of the standard each six months (in March and October) from 2017 to 2019, with the official release being the 18-10 (October 2018) release. Subsequent releases, such as 19-03 (March 2019) only provided document updates without further changes to the rules themselves.
The AUTOSAR C++14 (18-10) guidelines document is available from AUTOSAR
AUTOSAR C++14 Rule Classification
Each of the AUTOSAR C++14 rules is given both a classification of ‘obligation level’, which is defined as either ‘required’ or ‘advisory’, and a classification according to enforcement by static analysis, which is either ‘automated’, ‘partially automated’ or ‘non-automated’. These classifications are given for each rule within the Guidelines document.
According to the AUTOSAR C++14 guidelines, ‘required’ rules are necessary to be covered in order for one to claim compliance to the standard. Whereas, ‘advisory’ rules should normally be followed where practically possible, but do not, officially, impact the claims of compliance.
Enforcement by Static Analysis
Like all coding standards, one of the most convenient and efficient ways to enforce the standard is through the use of static analysis, either as the single enforcement system, or as an augmentation to manual code reviews. The AUTOSAR C++14 standard, which accounts for nearly 400 rules, in particular is suited to some form of automated checking, and static analysis tools are very good at applying large sets of rules constantly and consistently across many software modules and countless lines of code. The classification of whether a rule is ‘automated’, ‘partially automated’ or ‘non-automated’ refers to whether it can (in theory) be wholly checked, partially checked or not checked by static analysis tools.
Enforcing AUTOSAR C++14 With SciTools Understand
The Code Check static analysis engine built into the SciTools Understand developer toolset is well-suited to enforcement of the AUTOSAR C++14 Guidelines and following the latest product update, coverage now is 95% of all statically enforceable rules (Automated + Partially Automated), giving SciTools Understand one of the highest coverage levels of any static analysis tool on the market.
Full coverage details for the SciTools Understand enforcement of the AUTOSAR C++14 standard