AUTOSAR for next generation cars - Smooth interaction of different software platforms

1. Abstract

New applications like highly automated driving, Car-2-X, software updates over the air, or cars as part of the internet of things raise completely new requirements to a software platform for ECUs. AUTOSAR as the worldwide leading standardization organization for in-vehicle software bears this challenge and paves the way making the car an intelligent and adaptive vehicle.

Based on a set of selected use-cases, identified by the AUTOSAR partners, the presentation explains the challenges and the approach to master requirements for next generation cars. Starting with an overview of today’s in-vehicle software platforms and their limitations regarding future requirements the new AUTOSAR Adaptive Platform is motivated and the presentation outlines key aspects of the software architecture.
The new platform aims to support dynamic deployment of customer applications, to provide an environment for applications that require high-end computing power and to connect deeply embedded and non-AUTOSAR systems in a smooth way while preserving typical features originated in deeply embedded systems like safety, determinism and real-time capabilities. Built around existing standards such as POSIX, the Adaptive Platform will complement automotive specific functionalities enabling the platform to run in an automotive network.

The presentation will provide an answer how AUTOSAR intends to integrate different software platforms smoothly.

Beside the technical approach, a roadmap indicates until when specifications of the new software platform will be available.

2. Introduction

Cars continue to turn into real cyber physical systems – Just connecting to the internet and exchanging data with smartphones is state of the art. Future cars will be connected to almost everything: Smart homes, roadside infrastructure and even vehicles around them – they become a part of the internet of things.

Another trend beside the increasing connectivity is the vision of autonomous driving. Further enhancements of today’s driver assistance systems like Adaptive Cruise Control pave the way towards piloted driving and parking.

Figure 1: Use-cases driving the further development of the AUTOSAR Standard

The realization of these new features also adds new requirements on the software infrastructure, hosting these functionalities. Besides the existing requirements such as functional safety and security the software architecture has to support e.g. hardware with high-end computing power, updates-over-the-air, communication to backend-systems or dynamic deployment of applications. An evaluation by AUTOSAR showed that these new requirement cannot be realized by today’s software architectures where almost all vehicle internal communication is done via a deeply embedded controller to meet OEM requirements like startup times or functional safety and where the communication can be described by AUTOSAR means. In general it can be stated that a software infrastructure is required that is much more flexible as today, highly available and capable to adapt itself to specific application requirements at a given point in time. An extension of AUTOSAR’s software architecture for deeply embedded systems turned out not to be feasible.  Consequently todays architectures will be complemented by a new software architecture that come along with operating systems designed for high-performance computing which needs to be enhanced by e.g. safety, security or real-time features.  Nevertheless the well-known characteristics of deeply embedded system will remain. The combination of these trends results in an evolution of today’s E/E architectures.

3. Key aspects of the new E/E architecture

The following two key aspects characterize tomorrows E/E architectures:

1.) Integration of heterogeneous software platforms

Networking architectures of today’s cars can be clustered into different domains for infotainment and connectivity, chassis, powertrain, etc. While infotainment ECUs are typically using Linux, QNX or other general purpose operating systems, the AUTOSAR Classic Platform is the standard for deeply embedded control units. With the new use cases and the increasing demand also from deeply embedded applications for computing power a third type of ECUs will arise with different characteristics that has to be integrated into existing E/E architectures. 

2.) Service oriented and signal based communication

The traditional automotive communication is still based on the idea of ECUs providing signals to other ECUs as broadcast. This paradigm fits very well for control data of limited size, which has to be communicated cyclically.

Advanced applications like highly automated driving with higher payload demands e.g. to exchange lists of objects detected by a set of sensors and Ethernet as a communication system require more sophisticated protocols. The concept of service oriented communication is based on applications that provide a service on the communication system and other applications subscribe to this service. The data is then sent only to the subscribers. The combination of service oriented communication with the existing signal based paradigm is the second key aspect of future E/E architectures and a demanding challenge from a methodological point of view.  

Figure 2: AUTOSAR widens its scope and supports the integration of heterogeneous platforms on software specification and bus Level

AUTOSAR as the global standardization consortium for automotive software architectures aims to adopt to these trends and to provide a consistent standard for these aspects.

For deeply embedded systems used to realize typical power train and chassis functionalities the AUTOSAR Classic Platform will remain the first choice. Such applications are characterized by high-demands on safety, real-time and determinism while running on low cost hardware. Meanwhile AUTOSAR provides for these applications a well-proven and mature software platform including a widely used methodology, which supports all of today collaboration models.

To support dynamic deployment of customer applications and to provide an environment for applications that require high-end computing power AUTOSAR is currently standardizing a second software platform which is called AUTOSAR Adaptive Platform. Based on existing standards, the idea is to benefit as much as possible from developments in other areas (e.g. consumer electronics), while still considering automotive-specific requirements such as functional safety.

4. The AUTOSAR Adaptive Platform

Figure 2 depicts the overall architecture of this new platform. For Release 1.0.0 one of the main goals for the AUTOSAR Adaptive Platform is to provide application developers a stable programming interface the so called Adaptive AUTOSAR API.

Figure 3: Architecture of the AUTOSAR Adaptive Platform

The interface consists of a standardized interface for accessing operating system functionalities and a communication middleware, which allows data exchange with local and remote applications as well as to the Adaptive AUTOSAR Services. The second goal is to support the basic functionality needed to smoothly integrate the platform into existing E/E architectures based on Ethernet.

To achieve this goal the following components will be specified: The core of the AUTOSAR Adaptive Platform is the Operating system based on a subset of POSIX according to IEEE1003.13 [1] and providing the application developer commonly used functionality such as signals, timers, semaphores, signals and thread handling. If an application restricts itself to the use of this subset it shall be portable to any AUTOSAR Adaptive Platform. From the functional point of view the operating system defines some of the essential differences of the AUTOSAR Adaptive Platform to the AUTOSAR Classic Platform. Applications are not bound any more to a very strict and static scheduling and memory management but are free (within well-defined boundary conditions) to create and destroy tasks and to allocate memory depending on their current need.  

The module Application Execution Manager is responsible for startup and shutdown of the ECU and the Applications and it has to take care that the necessary resources for the applications are available and to degrade the ECU in critical situation according to a well-defined strategy.

A communication middleware shall realize the communication between local applications as well as to applications residing on other ECUs. This includes the interaction with the AUTOSAR Adaptive Services.
For the Release 1.0.0 the support of Ethernet based communication systems is foreseen, based on SOME/IP as bus protocol, which also enables applications on the AUTOSAR Adaptive Platform to establish communication relationships with ECUs running the AUTOSAR Classic Platform.

The goal for the Release 1.0.0 is, to enable the first series projects to start developing ECUs based on the AUTOSAR standard. Nevertheless there are features, which are already under investigation but not in scope of Release 1.0.0. This includes but is not limited to the support for fail-operational systems, enhanced safety and security features and the integration of CAR2X communication protocols.

5. Support for the Integration of heterogeneous platforms

The methodology defined by AUTOSAR is the only standardized solution available today, which allows describing the software architecture together with the network topology in a unified machine readable format. Up to now this concept considered only the ECUs based on the AUTOSAR Classic Platform and the principle of signal based communication. For the future the most important challenge is to support a seamless integration process of different platforms. With the introduction of Ethernet and a service oriented communication paradigm based on SOME/IP in the Release 4.1.1 of the Classic Platform AUTOSAR already made a big step to support this use case. In terms of SOME/IP, a service can be seen as the functional representation of an ECU on the bus independent of the underlying software platform. From this follows that a formal description of a service has to be independent of a specific platform, be it the AUTOSAR Classic Platform, the AUTOSAR Adaptive Platform or a non-AUTOSAR platform. The important thing is that each platform realizes the service in the same way w.r.t. to its on-the-wire format. 

This means that AUTOSAR has to provide answers for the following aspects:

  • Description of the relevant communication relationships on software level
  • Provisioning of standardized communication protocols. 

The main difference between platforms supported by AUTOSAR and other platforms is then the support of a methodology, which enables tool vendors to provide automated configuration of ECUs running a software stack, which complies with the standard.

6. AUTOSAR products and Timeline

Previously, AUTOSAR released all of its specifications as one bundle, however, it became increasingly difficult for users to track relevant changes to the standard, especially with the introduction of the Adaptive Platform. To keep the standard manageable, useable and to enable flexibility AUTOSAR decided to split the standard into so-called AUTOSAR products. An AUTOSAR product is a consistent set of AUTOSAR deliverables, which are released at the same time. AUTOSAR deliverables can, but are not limited to be of the following kinds:

  • textual explanations
  • textual specifications
  • test specification
  • source code
  • other formal or semi-formal textual formats (e.g. Arxml, UML models, XML Schema)

The approach of structuring AUTOSAR’s deliverables into products also opens up the new possibility to deal with future use cases and to establish the new AUTOSAR Adaptive Platform beside AUTOSAR Acceptance Test and the AUTOSAR Classic Platform. Common parts of these products such as bus protocols and common aspects of the methodology will be released as a separate product called AUTOSAR Foundation.

Up to now the AUTOSAR partnership has agreed on the following timeline for their main products. The next minor release for the AUTOSAR Classic Platform is planned for October 2016. This comes along with the first release of the AUTOSAR Foundation. The first version of the AUTOSAR Adaptive Platform will be available end of March 2017.

Figure 4: Timeline for AUTOSAR Releases

7. Conclusion

Over the past 10 years AUTOSAR has demonstrated it is a well-suited platform to coordinate and drive the standardization for a software infrastructure, which meets the requirements of the automotive industry.
Upcoming demands and new functionalities will pose further challenging requirements on future E/E architectures. With the restructuring of its portfolio and the introduction of the new AUTOSAR Adaptive Platform the organization has adopted this challenge and will also in the future provide a common platform for its users.

[1] IEEE1003.13; IEEE Standard for Information Technology - Standardized Application Environment Profile (AEP) - POSIX® Realtime and Embedded Application Support

Authors of this article

Dr.-Ing. Markus Bechter (AUTOSAR project leader team, BMW Group, markus.bechterbmwde);

Dr. Marcel Wille (AUTOSAR project leader team, Volkswagen AG, marcel.willevolkswagende)