On 29th January 2019, MISRA and the AUTOSAR partnership (AUTomotive Open System ARchitecture) announced that their two C++ language subsets are to be integrated together. The resulting guidelines will initially apply to versions up to and including ISO/IEC 14882 C++17, and will evolve on an ongoing basis to reflect the three-year release cycle for new versions of the C++ language.

Guidelines adopted from AUTOSAR will be aligned with MISRA conventions and terminology, while the MISRA C++:2008 guidelines used as the base for the new document will benefit from improvements to their rationale and examples.

That sounds great on paper. But what will this new document offer in practice, and what will it mean for AUTOSAR application developers?

Language subsets

The driving force for the adoption of language subsets (often referred to as “guidelines” or “coding standards”) arguably has less to do with AUTOSAR in particular than with functional safety and cybersecurity in general.

The functional safety standard “ISO 26262 Road vehicles — Functional safety” is considered obligatory across much of the modern automotive development world. The relationship between the system-wide ISO 26262-4:2011 and the software-specific sub-phases found in ISO 26262-6 can be represented in a V-model (Figure 1).

Both the new ISO 26262:2018 standard and the more familiar 2011 release collate hundreds of topics into dozens of tables to describe a process to follow in the creation of a functionally safe product.

For today’s connected car, functional safety is only half the story. SAE J3061 provides guidance on best practices from a cybersecurity perspective, just as ISO 26262 provides guidance on practices to address functional safety. The recommendations in SAE J3061 are designed to complement the ISO 26262 process, and call for broadly similar techniques with a cybersecurity focus.

Both ISO 26262 and SAE J3061 call for the use of language subsets because they help developers avoid troublesome parts of the language and make the resulting code more reliable, less prone to error, easier to test, and/or easier to maintain. Figure 2 shows just one example of how language subset violations can be presented.

 

A meeting of minds

This newly announced language subset results from an agreement between the AUTOSAR partnership and the MISRA organization.

The AUTOSAR partnership is a synergistic group of automotive OEMs and suppliers focusing on the continuous development of a reference architecture for vehicle ECU software.

Complementing the long-established Classic Platform for embedded systems with hard real-time and safety constraints, the Adaptive Platform is AUTOSAR’s solution for high-performance computing ECUs to build safety-related systems for use cases such as highly automated and autonomous driving. Classic Platform applications are developed in C while those for the Adaptive Platform are developed using C++.

MISRA is also a collaboration between manufacturers, component suppliers and engineering consultancies, but is best known for its language subsets. Although MISRA was born out of the automotive sector, these days its guidelines are in common use across many safety and security sectors including medical devices, industrial, aerospace and rail transportation.

During the process of defining the environment for the Adaptive Platform, AUTOSAR needed a language subset to support C++14 and subsequent evolutions of the language. MISRA C++ was considered admirable but it was published in 2008 to support C++03 and so was not sufficiently up-to-date.

Unaware of MISRA’s existing commitment to update MISRA C++:2008, AUTOSAR supplemented MISRA C++:2008 with its own rules to create the AUTOSAR C++14 guidelines, leading to two parallel developments of roughly the same thing. January’s announcement resolves that situation by amalgamating the latest efforts of the AUTOSAR partnership with those of MISRA.

The impact on AUTOSAR application development

The embedded development world in general is long overdue a de facto C++ language subset, and for a commitment to its ongoing maintenance as the language evolves. The joint announcement is to be applauded just for that.

However, any simplification and streamlining of rules and regulations is particularly welcome for AUTOSAR application developers. There are already enough challenges in complying with the demands of the ISO 26262 functional safety standard, the SAE J3061 cybersecurity guidelines and the protocols defined by the AUTOSAR standard itself, without the selection of a language subset being needlessly complicated.

Commonality between the AUTOSAR Adaptive and Classic platforms is helpful – a fact already reflected in the AUTOSAR Foundation Standard, which contains requirements and technical specifications applicable to both. The adoption of MISRA conventions and terminology for the integrated C++ language subset to be used in Adaptive applications will align with the MISRA C guidelines already used for Classic developments. This helps simplify the lives of anyone involved with both platforms and making it very clear which is the “right” coding standard to use.