AUTOSAR – A Leading Standard In the Automotive Industry
Posted by Dušan Bogdanović on 04 August 2020
The AUTOSAR standard (AUTOmotive Open System Architecture) is a product of the collaboration of the world’s largest automotive companies. It is an open standard for the electrical/electronic architecture in the automotive industry, developed in 2003 within the established AUTOSAR development partnership of the automotive OEMs, suppliers and other companies in the software, semiconductor and electronics industries.

Image source: Vector Informatik GmbH (2016): Autosar – fundamentals, AUTOSAR Course Manual, p.3
The aim of this standard is to provide the set of specifications that describe the basic software modules, define the programmatic connections and implement the common methods for the further development based on the standardized format. This standardized format ensures the application of the standard in the vehicles of different manufacturers, but, also, it can be implemented by the various manufacturers of electronic equipment used in those vehicles.
Why is the AUTOSAR important?
With the AUTOSAR, it is possible to develop the independent software and this software can be transferred or used in different systems or ECUs. So, it can be adapted to the different vehicles, platforms or hardwares.
The increasing complexity of modern vehicles was the main motivation behind the development of the AUTOSAR. Furthermore, today’s vehicles have more than a hundred ECUs each. Every one of them has thousands of functions. Without this standard, they often have to be completely rewritten when the hardware is changed. This has made it urgent for automotive manufacturing giants to come together and make software independent from the hardware. To make that possible, they set the AUTOSAR as an industry-wide standard, which was a core solution for the software to become reusable.
AUTOSAR three-tier architecture
The AUTOSAR standard includes a three-tier architecture consisting of:
1. Basic Software (BSW) – standardized software modules that are necessary for the functioning of the higher software layers.
2. Runtime environment (RTE) – middleware which realizes the communication between the software components and basic software.
3. Application Layer – components of the application software that communicate with RTE.
These three layers represent the AUTROSAR Classic platform architecture, which is significant because it enables the communication within and between the Electronic Control Units (ECUs). Also, the platform independent development and using of the application software are enabled without knowledge of the lower layers.

Image source: Lukić, A., Kukolj, D. et al. (2019): Automatsko generisanje testova za automotiv sisteme zasnovane na AUTOSAR modelu, Book of proceedings – ETRAN, Beograd, p. 902
In addition to the Classic platform, a newer AUTOSAR Adaptive platform architecture was developed later and, unlike the AUTOSAR Classic Platform where the individual vehicle ECUs are statically integrated into the system and where the initial configurations cannot be changed later, this new platform provides the key advantage in integrating applications into the system during the runtime.
However, in this blog we will stick the classic platform in explaining the most important segments and elements of the AUTOSAR architecture.
Aplication layer – AUTOSAR software components
Software components (SWCs) are the small applications that have the specific tasks. Their interconnection is possible thanks to the ports, which represent the starting points in the SWCs communication. Also, it’s important to say that one port belongs to the one component.
Virtual Functional Bus (VFB) handles the communication between the SWCs. Of course, at this point in the time, the allocations of the components to the Electronic Control Units (ECUs) are still undefined. Only when the system is configured, the SWCs can be deployed to the appropriate ECUs. So, we can say that the VFB, actually, represents the communication within an ECU as well as between the ECUs and this virtual bus is a set of the RTE interfaces that are not yet deployed to the specific Electronic Control Unit. As the communication takes place through the ports, the communication interfaces must be connected to those ports.

Also, each software component contains one or more runnables, that actually contain the implementation of that software component and make it executable. Runnables consist of the small parts of the code or the instruction sets of the appropriate component and they can be activated in two ways: cyclically (depending on the period and scheduler) and after an event occurs (like receiving data).

Image source: Lukić, A. (2019): Automatsko generisanje testova za automotiv sisteme zasnovane na AUTOSAR modelu, Završni rad, Fakultet tehničkih nauka, Novi Sad, p.8
RTE – runtime environment
As we have already mentioned, in the AUTOSAR architecture, communication between the software components (SWCs) and basic software (BSW) is possible thanks to the RTE interfaces. Software components communicate with other components and/or with modules of the basic software only through the RTE interfaces. This not only ensures the independence of the software component from the other components, but also the independence from the individual ECUs.
Runtime environment (RTE) is an abstraction of the operating system, communication services, hardware interfaces and software components work scheduling.

(1) RTE as runtime environment for runnable, (2) RTE as a communication interface
Image source: Vector Informatik GmbH (2016): Autosar – fundamentals, AUTOSAR Course Manual, p.3
There are two types of communications that RTE realizes:
1. Client/Server Communication which has two modes: synchronous (work in the same context) and asynchronous (work in different contexts). The client initiates the communication, requesting that the server performs a service, transferring a parameter set if necessary. The server waits for incoming communication requests from a client, performs the requested service, and dispatches a response to the client’s request. The direction of initiation is used to categorize whether an AUTOSAR Software Component is a client or a server. A single component can be both a client and a server, depending on the software realization.
2. Sender/Receiver Communication which has two modes: explicit (uses explicit RTE API calls to receive and send parts of data) and implicit (RTE automatically reads certain data sets before the runnable component is called). Sender / Receiver communication can be further divided as follows:
i. direct (Rte_Read, Rte_Write) – RTE uses direct access for the data buffer, 1:N communication and Init values as default. They provide a non-blocking read operation on the actual variable containing the latest valid value. Components communicate data to other components using the Rte_Write call. The call is defined per port and interfaces data item for each component. Components receive communicated data items from other components using the Rte_Read call. Also, the call is defined per port and interfaces data item for each component.
ii. buffered (Rte_IRead, Rte_IWrite, Rte_IWriteRef) – RTE generates copy before the runnable executing and after the execution, the RTE copies the data to the global buffer. Values won’t be changed during the execution.
iii. queued (Rte_Receive, Rte_Send) – RTE reads from the specific receive queue.
Basic software
The Basic Software (BSW) consists of Basic Software Modules (BSWM) as a collection of software files (code and description) that define a certain basic software functionality present on an ECU. The basic software consists of 3 layers:
1. Services Layer – this is the uppermost layer of the basic software. While I/O access is organized by the ECU Abstraction Layer, the Service Layer offers the following services:
i. Operating system services,
ii. Vehicle network communication and management services,
iii. NVRAM management,
iv. Diagnostic services,
v. ECU state management.
2. ECU Abstraction Layer – provides an API for devices, which are independent of their location. The task of this layer is to make the higher layers independent of the ECU hardware layout.
3. Microcontroller Abstraction Layer – this is the lowermost layer of the basic software. This layer contains drivers for the direct access to the microcontrollers, internal peripherals and memory mapped microcontrollers of external devices. The task of the Microcontroller Abstraction Layer is to make higher layers independent of the microcontroller.
4. Complex Device Drivers – control special sensors and actuators by the direct microcontroller access. They represent the special case in the Layered Software Architecture of AUTOSAR.

Image source: Vector Informatik GmbH (2016): Autosar – fundamentals, AUTOSAR Course Manual, p.3
Conclusion
In this blog, I wanted to present you the AUTOSAR architecture, technical aspects and the importance of this architecture for the automotive industry. Today we can say that the all major companies in the automotive industry apply the AUTOSAR standard and the aspects defined therein.
Even the largest Serbian automotive software companies are implementing the AUTOSAR in their work and developing the software solutions, because the AUTOSAR goals include the scalability to different vehicle and platform variants, transferability of the software, the consideration of availability and safety requirements, a collaboration between the various partners, sustainable use of the resources, and maintainability during the whole software product lifecycle.
So, we can conclude that the AUTOSAR has been devised to pave the way for innovative electronic systems that further improve performance, safety, and environmental friendliness and to facilitate the exchange and update of the software and hardware over the service life of the vehicle.

Dušan Bogdanović
Software Engineer