AUTOSAR Architecture Requirements on Runtime Environments

The Automotive Open System Architecture (AUTOSAR) organization, founded in 2003, was created to provide guidance for manufacturers to safely develop embedded software for automotive electronic control units (ECU). AUTOSAR is a partnership of automotive industry titans from around the world like Toyota, BMW, Ford, and more, with a focus on standardizing the software architecture throughout the industry to manage the increasingly complex control systems, while improving quality and reliability for this safety-critical software.

AUTOSAR Architecture

An average ECU can contain thousands of functions. Before AUTOSAR architecture, each ECU needed to be completely rewritten when any hardware changes occurred. Once AUTOSAR was assembled, the group figured out a way to make software independent from the hardware, creating a new standard for the entire industry to create modular and sustainable applications. Better yet, the new standards were compliant with international automotive safety standards including ISO 14229, ISO 27145, among others.

Although the Motor Industry Software Reliability Association (MISRA) had developed a C++ coding standard, MISRA C++:2008, its rules are based on C++03 (ISO/IEC 14882:2003), which does not support many of the required critical and safety-related software aspects needed. Therefore, the AUTOSAR group selected C++14 (ISO/IEC 14882:2014) and built their own coding standard around it, called AUTOSAR C++ 14. This standard has been updated and released twice a year since March 2017.

AUTOSAR C++14 Explained

In 2017, the AUTOSAR group published Guidelines for the use of C++14 language in critical and safety-related systems. It’s commonly referred to as AUTOSAR C++14 and now part of its overarching AUTOSAR architecture platform. The release of AUTOSAR C++14 was introduced with the intent to supersede MISRA C++:2008 and to become the de facto coding standard throughout the entire automotive industry. In fact, these guidelines are so robust, they can be applied to any industry that requires embedded programming.

Another reason C++14 stayed chosen, was because safety engineers had become accepting of object-oriented languages and it gave developers the ability to use superior compilers and improved access to enhanced testing, verification, and analysis tools. It also allowed new development methods to be used, like continuous integration/continuous delivery (CI/CD) which can detect errors sooner in the software development lifecycle. MISRA C++:2008 just failed to accommodate any of these emerging innovations.

Using AUTOSAR C++14 for New Automotive Technologies

AUTOSAR C++14 guidelines are being used for new automotive technologies like automated driving, vehicle-to-vehicle, or vehicle-to-infrastructure (V2X) communication, continuous over the air (OTA) updates, high-definition displays, and AI computing. While MISRA C++:2008 is still used in some projects and has helped engineers adopt a coding standard, it remains a standard that is incomplete. This is because, since the release of C++ 03, there have been a staggering number of improvements to the language as C++ evolved which MISRA C++:2008 does not.

If an organization is relying on MISRA C++:2008, migrating to AUTOSAR C++ 14 will be a significant effort for them. But there is also a huge value in doing it, because the delta between MISRA C++:2008 and AUTOSAR C++ 14 addresses the changes added in the C++ language since 2003. Therefore, all the novelties in C++11 and C++14 are included in AUTOSAR C++ 14. So yes, there’s an impact, but there’s also a lot of value to updating to the new standard.

AUTOSAR Architecture & Coding Requirements

AUTOSAR C++ 14 has 342 rules to help give the user a clear understanding and guidance on coding requirements. It classifies each rule based on whether it’s required or a recommendation. “Required rules” are mandatory for AUTOSAR C++14 compliance, while “advisory rules” don’t need to be adhered to, but they are highly recommended. However, a deviation from a rule or guideline can be permitted. Nevertheless, a procedure in obtaining a sign-off for every deviation must be included, because it prevents abusing the deviation concept by developers deviating at will.

When looking at employing a coding standard like AUTOSAR C++ 14, the only practical way to enforce compliance is with a static analysis tool that also has a sophisticated interactive reporting system and enables an efficient daily workflow. In fact, consider a solution that integrates the scanning process into the continuous integration (CI) builds on servers. This kind of automation saves a lot of time and money.

Additionally, if cleaning existing codebases, 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 prevents a vast number of violations or noise to overwhelm the team and it allows for monitoring the progress of your codebase, control the deviation process, and make educated decisions about extending the ruleset.

A Unified AUTOSAR-MISRA Standard

Since 2017, the AUTOSAR group has released AUTOSAR C++ 14 guidelines twice per year, partnering with over 200 automotive companies to maintain support along with the changes that come with new C++ language updates. Doubling down on the future, AUTOSAR announced in 2019 that it will be working together with MISRA to merge the two C++ rulesets and provide a single universal C++ software development guideline. These new MISRA-led guidelines are expected to be built with full support for modern C++ language versions like C++17 and C++20.

With this new merger/collaboration of MISRA & AUTOSAR to build the latest and best set of coding rules and guidelines for C++, I expect that it will be heavily adopted by other industries besides automotive. Industries such as aerospace, medical, industrial, rail, telecom, energy, and many others. Software developers are very much looking forward to the ability to deliver safe and secure projects that have been or are to be developed in C++17 and C++20 programming languages.

Static Analysis Helps Create Safe and Secure C++ Code

One important aspect of ISO 26262 is the recommendation to use a coding compliance standard like AUTOSAR C++14. The best way to achieve compliance is through automation and using a TUV certified tool like Parasoft C/C++test, which is also capable of supporting multiple testing technologies and capabilities like unit testing, structural code coverage, requirement traceability and more. As a fully integrated software testing solution for safety-critical industries, Parasoft C/C++test can also easily be integrated into your C++ IDE or CI/CD pipeline to be configured to detect defects early, and automatically enforce compliance.

Tailored specifically for the automotive industry, the Parasoft C/C++test Automotive Compliance Pack integrates rules for AUTOSAR C++14, MISRA C++2008, and high integrity (HI) C++ to help any automotive developer expand testing functionality and streamline testing for the development team. Developers can also use Parasoft C/C++test to analyze code compliance from within the IDE, while automatically creating reports to notify teams of any status updates.

As one of the most complete solutions for testing safety-critical applications, Parasoft C/C++test offers a simplified solution for static analysis, while offering more support for the coding standards required by the automotive industry. With a platform that automatically ensures compliance for safety-critical systems, you’re able to detect defects early and save time in the development process, prioritize updates to address significant issues first, and automate compliance.

“MISRA”, “MISRA C” and the triangle logo are registered trademarks of The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. All rights reserved.