AUTOSAR – What Every Function Developer Should Know…

Author: Nabile Khoury | Date: June 29, 2020

  • AUTOSAR was introduced 15 years ago as a standardized architecture to develop complex automotive applications
  • Today, new projects and teams continue to embrace the standard
  • What key concepts should be understood by a function developer using AUTOSAR?

In recent decades, the demands for designing smarter and safer vehicles has caused a significant increase in the size and complexity of the automotive systems software. In a modern high-end passenger car, more than 100 million software lines of code (SLoC) are embedded and distributed across as many as 80 ECUs communicating in a network infrastructure. In terms of SLoC, automobile code size is second only to Google's internet services (2billions SLoC). This makes the modern passenger car one of the most complex systems being developed today. To effectively address this complexity while improving the efficiency and quality of automotive software, OEMs (Original Equipment Manufacturer) and suppliers formed a consortium back in 2003 to create AUTOSAR (AUTOmotive Open Software Architecture) as an integrated standard for vehicle software development. The first AUTOSAR version was released in 2006. It’s now called AUTOSAR Classic and in 2017 another AUTOSAR standard (Adaptive) was created to address connected vehicles and autonomous driving applications.

In this article, we’ll explain how AUTOSAR Classic helps to deal with software complexity and introduce the main AUTOSAR concepts and terminologies the function developer should know.

Introduction to AUTOSAR Classic

Automotive systems are often developed in a collaborative effort between OEMs and suppliers. Suppliers develop subsystems specified by the OEM or develop their own subsystem that they sell as an “off-the-shelf” product. Before AUTOSAR, the collaboration relied on specification languages defined within the OEM-Supplier partnership. A new partnership began with an agreement on a new specification language, and integrating a proprietary supplier component required adaptation efforts. With the growing demand of new vehicle functions and the expansion into several domains, the old collaboration approach became impractical.  Distributed functionalities in the vehicle architecture also added complexity.  AUTOSAR was created to make this complexity manageable, by providing a system-based design environment for the development teams creating the software architecture.

Modular architecture and virtual communication bus

To manage the complexity, AUTOSAR introduced a modular architecture with layers to separate hardware-independent application software from hardware-oriented software.

AUTOSAR also provides a way to decouple the applications from the hardware infrastructure. AUTOSAR introduced the concept of Virtual Functional Bus (VFB) which makes it possible for the SWCs to interact independently from where they are executed in the system (inside one ECU or on different ECUs).  As SWCs are allocated to the various ECUs, the virtual connections are mapped to local connections (intra-ECU) or onto network communication technologies such as CAN or FlexRay (inter-ECUs). The connection mapping is implemented by the RTE and becomes the concrete interface between individual SWCs and also between SWCs and the BSW (the RTE implements the VFB on a specific ECU).

With the VFB, OEMs and suppliers can develop multi-domains and competitive software without detailed knowledge on the lower-level technologies or dependencies. It gives the flexibility to scale the overall system afterwards (e.g. number of ECUs, ECU-to-Application mapping, network technology, etc.). It enables the reusability and transferability of software components and makes it easier to add new functions to the system. Moreover, the VFB validates all plausible communication between SWCs, which will detect any software architecture errors and improve the software architecture quality.

AUTOSAR Application Software Layer

An AUTOSAR application consists of several software components interacting together.

Hierarchical architecture

The Application software layer offers a hierarchical structure to create the software components:

AUTOSAR Interfaces

Software components communicate via “Ports”. A Port is a gateway that is used to request or send information. The semantics of the information depends on the kind of data or service being exchanged. A port must first be associated with an Interface which will define the exchanged information (e.g. request/send some specific data). One Interface can be referenced in multiple places, ensuring consistent data definitions for the provided port(s) and the related required port(s). The AUTOSAR Interfaces are:

In the RTE, the respective communication interfaces are implemented with specific constructs called RTE API. E.g. Rte_Read_xxxx(), Rte_Write_ xxxx (), Rte_Call_ xxxx (), Rte_Invalidate_xxxx(), etc.

We’ve seen the communication mechanisms between SWCs. Now let’s look at how a SWC is implemented.

Internal Behavior of an Atomic software component

AUTOSAR Internal Behavior (IB) defines the architecture elements that implement the SWC. It describes the implementation from a code perspective. In the system design timeline, the IB can be specified only when the SWC needs to be implemented, while the structure of the SWC (e.g. the ports) need to be specified upfront. The IB also specifies if the SWC supports multiple instantiations, meaning the SWC is implemented once and instantiated several times in the ECU(s).  This is comparable to the principle of a reusable function (e.g. Seat heating SWC instantiated on each seat). The main IB elements are:

AUTOSAR Methodology and Templates

In addition to the architecture description, AUTOSAR provides a methodology that describes the process steps from the abstract system definition right down to the final EUC executable with a list of design steps and work products. It also provides templates (meta-model) to define design semantics and constraints called the “AUTOSAR Schema,” from which architecture description files can be created and exchanged (as AUTOSAR XML files). This encompassing approach allows all stakeholders of the system development to understand and speak the same language, which dramatically improves the collaborative development environment.Moreover, with the architecture being described in a machine-readable format, it can be processed by design tools to generate the necessary system components (e.g. RTE API calls in the SWC implementation, RTE implementation, BSW implementation including the Operating System, etc.)

Conclusion

AUTOSAR makes it possible to develop application software on an abstraction level, focusing on the interactions between the software components. It offers a modular architecture with a hierarchical structure and standardized interfaces connecting architecture layers and components. More than just a design tool for a single ECU, AUTOSAR addresses challenges bringing together an entire system of interconnected ECUs. It offers a wide range of communication and implementation techniques to develop complex automotive software applications. The standardized exchange formats, encourages collaborative development and enables the creation of software as off-the-self products which can be integrated into any AUTOSAR environment. The machine-readable description of the software architecture enables interoperability between design and testing tools. One example is Model-based development tools like Simulink and TargetLink that have the ability to read AUTOSAR files, making it possible to generate and test AUTOSAR compliant code. Last but not least, for safety critical software development, AUTOSAR mechanisms help to fulfil the architecture design methods recommended in safety standard like ISO 26262.

On-demand Webinar: Efficient Unit Test for AUTOSAR Software

To access this recorded webinar, please fill out the form below (please use your professional email address). 

* required
 

The Author:

Nabile Khoury studied Electronics and Computer Science at the University “Conservatoire National des Arts et Métiers” in Paris. From 2010 to 2016, he worked in automotive companies, mainly in the powertrain department of the French car maker PSA Peugeot Citroën, as software engineer specialized in Model-Based Development involving AUTOSAR and ISO 26262 compliant processes. He then joined BTC Embedded Systems AG where he currently works as a Senior Pilot Engineer in Paris/France.

 Connect with me on LinkedIn