Adaptive AUTOSAR in a nutshell

Quick facts:

• Adaptive AUTOSAR is standardization of the AUTOSAR runtime for Adaptive Applications (ARA)
• The standard contains two types of interfaces; services and APIs
• The AUTOSAR Adaptive standard is released two times a year — end of March and end of October
• First release of the standard was in March 2017 (17–03)
• Standardization is done by AUTOSAR Consortium which has members from almost every automotive company

What does it contain?

The standard contains interfaces required for developing future automotive ECUs (Electronic Control Units) running on state-of-the-art multicore microprocessors. These interfaces allow OEMs, as in the car manufacturers, to implement autonomous driving, over-the-air software updates, IoT (Internet of Things) features, media streaming and other services to their future cars. Compared to AUTOSAR Classic, the Adaptive platform allows dynamic linking of services and clients during ECU runtime which makes it much more flexible for the application developers. Platform also utilizes C++14 to allow feature rich and fast development of ARA applications.

Adaptive AUTOSAR architecture

The architecture picture shows different parts of AUTOSAR Adaptive platform. Each of these areas may contain one or more different software modules which are each specified in separate specification documents. You can find the specification documents of each different software module from the AUTOSAR web page.

Apart from API specification documents there are other documents related to these parts presented in the picture and each of them can be identified with the first 2–3 letters of the filename:

• SWS — Software Specification document. This is the actual software module API and non-functional specification where you can find all bits and pieces to start developing applications on top of the module.
• RS — Requirements document. This document contains all functional requirements of the specific module. These documents are mostly used by companies providing implementation of the Adaptive Platform.
• EXP — Explantory document. This is more human readable document describing the use of specific software module most likely with good examples. These documents are a very good starting point for newcomers.
• TPS — Template Specification document. Describes the “Manifest” used in general or in some part of the Adaptive Platform. These documents are useful for understanding how things are modeled in the platform.
• TR — Technical Report document. These documents contains technical information and are mostly referenced from other documents.

How is it specified?

As mentioned in the beginning, the specification work is done by AUTOSAR Consortium which totals to over 250 people from 70 different companies. These numbers contain also people working on Classic AUTOSAR and other AUTOSAR specification work.

AUTOSAR partners

The Adaptive specification work is split to multiple Feature Teams (FTs) which all concentrate on a specific area in the standard. The FTs are also responsible for providing an reference implementation of the standardized interfaces. This means each feature team consists not only of architects and technical writers, but also programmers are involved.

I am part of one of these FTs and I have colleagues working in other teams as well. The way of working differs from FT to other but I think quite common is to have face-to-face meetings once a month or so. These meetings are usually hosted by one of the team members. People attending to specification work are somewhat required to travel often, mostly in Europe. Apart from the face to face meetings all feature teams work in “Scrum” mode which means there is also 1–3 telcos every week with the team. Also joint sessions between the teams are organized once or twice a year.

Specification work is done mostly with open-source tools by utilizing documentation frameworks such as LaTeX. The actual work is not that hard — the hardest part is to understand what are you specifying, where it should be specified and how it affects other specifications in the standard.

Who is implementing it?

Besides Elektrobit, there are few companies that are publicly developing products that implement the Adaptive AUTOSAR. You can find these companies with simply typing “Adaptive AUTOSAR” in your favorite search engine. At Elektrobit, the Adaptive Platform product is called Corbos and you can find more information about that here.

There is basically nothing that would prevent new players joining the automotive industry by creating their own product based on the standard. Only obstacle is that it will take tremendous amount of time to deliver all specified components especially with the safety requirements (ISO26262) that most automotive OEMs require.

Who is using it?

Mostly OEMs. They acquire a product or license to a product from AUTOSAR vendor and on top of that they develop their own applications for their cars. As the products should follow the standard, it should be possible for the OEM to switch between vendors and products and still have their applications working.

While the standard is mostly targeted for cars, I would not see any problem using it in any other microcontroller based project where the requirements for high-availability and fail-operational system are present.

More reading

• https://www.autosar.org/standards/adaptive-platform/
• https://www.elektrobit.com/products/ecu/eb-corbos/adaptivecore/
• http://www.ai-online.com/Adv/Previous/show_issue.php?id=6881

About me

I am Heikki Hellgren, Software Expert and technology enthusiast working at Elektrobit Automotive. My interests are in software construction, tools, automatic testing and all the new and cool stuff like AI and autonomous driving. You can follow me on Medium and Twitter. Also you can check out my website for more information.