AUTOSAR

What is AUTOSAR?

AUTOSAR (AUTomotive Open System ARchitecture) is a worldwide development partnership of automotive manufacturers, suppliers, and other companies in the electronics, semiconductor, and software industries. AUTOSAR standards are designed for software standardization, reuse, and interoperability.

AUTOSAR has implemented a layered architecture similar to OSI model. It has different layers to handle and abstract different operations of code.

The AUTOSAR standard provides two platforms to support current and future generations of automotive electronic control units (ECUs).

The Classic Platform supports traditional internal applications such as powertrain, chassis, body, and interior electronics.
The Adaptive Platform supports service-based applications such as autonomous driving, Car-to-X, over-the-air (OTA) software updates, and using vehicles as part of the Internet of Things (IoT).

AUTOSAR Classic, AUTOSAR Adaptive, and non-AUTOSAR ECUs can interoperate in one vehicle.

AUTOSAR Architecture

Application Layer: This layer has the application code which resides in top. It can have different application blocks called as Software Components(SWCs) for each feature which the ECU needs to support according to application. For example, the functions like power window and temperature measurement will have separate SWC. This is not a norm, but it depends on the Designer.

AUTOSAR Classic SWC generates ARXML descriptions and algorithmic C code for testing and integration into AUTOSAR RTE.

The AUTOSAR application layer consists of three components which are: application software components, ports of software components, and port interfaces.

Runtime Environment (RTE) provides communication between application software and base software (BSW). The SWC communicates with other components and his BSW module exclusively via his RTE. This allows the SWC to be independent of specific ECUs and other SWCs.

RTE Layer provides ECU independent interfaces to the application software components. The application layer consists of many SWC which does not follow layered architecture style but component style. The Software Components communicate with other components (inter and/or intra ECU) via the RTE.

The Classic Platform uses the Virtual Function Bus (VFB) to support hardware-independent development and use of AUTOSAR application software. This bus consists of an abstract representation of the RTE for a specific ECU and separates his AUTOSAR software components of the application layer of the architecture from the architecture infrastructure. AUTOSAR software components and buses communicate using dedicated ports. Configure the application by mapping the ports of the components to the RTE representation of the system ECU.

BSW provides services such as ECU abstraction, microcontroller abstraction, and memory and diagnostics.

Basic Software

Vehicles are equipped with numerous cameras and other sensors both inside and outside them. These sensors are in place to assist the driver in driving, they are used for human vision or machine vision. With a fixed number of sensors already in place, there is a need to utilize them for both machine vision as well as human vision, this gives the need for dedicated algorithms that work with the raw data from the camera making them suitable for the application. Basic software layer is further classified into:

Services Layer,
ECU Abstraction Layer,
Microcontroller Abstraction and Complex Device Drivers (CDD).
Microcontroller Abstraction Layer (MCAL)

The Microcontroller Abstraction Layer is the lowest layer of the Basic Software, this means that MCAL modules can directly access the HW resources. MCAL contains internal drivers which are software modules that are direct access to the µC and internal peripherals.

As the name resembles, the MCAL layer makes the upper layers independent of HW (MCU).

ECU Abstraction Layer

The ECU Abstraction Layer interfaces the drivers of the Microcontroller Abstraction Layer (MCAL). It also contains drivers for external devices within the ECU and provides an abstraction for various peripheral hardware.

It provides interfaces to access all features of an ECU like communication, memory, or I/O, no matter if these features are part of the microcontroller or served by peripheral components.

Complex Device Drivers Layer

The Complex Device Drivers (CDD) Layer spans from the hardware layer to the RTE. CDD fulfills special functions and timing requirements needed to operate complex sensors and actuators.

Provide the possibility to integrate special-purpose functionality. This layer consists of drivers for devices that are not specified within AUTOSAR, with very high timing constrains.

Services Layer

The Services Layer is the topmost layer of the Basic Software (BSW) which also applies its relevance for the application software. It provides an independent Interface of a microcontroller (MCU) and ECU hardware to application software.

The Services Layer offers:

Operating system functionality
Vehicle network communication and management services
Memory services (NVRAM management)
Diagnostic Services (UDS, Error handling, Memory)
ECU state management, mode management
Logical and temporal program flow monitoring (Wdg manager) Task Provide basic services for applications, RTE, and basic software modules.

Advantage of AUTOSAR

AUTOSAR uses a layered architecture which has different layers dedicated to perform different operations and abstraction. The application code is fully portable as AUTOSAR is designed in such a way that the application code is written independent of the hardware so the same application code can run on different hardware platforms. AUTOSAR has a layer dedicated to support hardware functionalities called MCAL (Micro controller abstraction) layer which has drivers for accessing the underlying hardware peripherals of MCU. As AUTOSAR provides standard way of communication, ECUs can communicate with each other irrespective of ECU developer (whether OEM or Tier1) and hence there is no need to maintain custom standard of communication. ECUs utilizing AUTOSAR can communicate with each other irrespective of underlying differences in hardware. Mostly chip manufacturers provides MCAL layer of AUTOSAR, but if they don’t then the developer needs to write his own MCAL layer or outsource to companies providing such services.

Adaptive Platform

Adaptive Platform is distributed computing and service-oriented architecture (SOA). The platform provides high-performance computing, message-based communication mechanisms, and flexible software configurations to support applications such as autonomous driving and infotainment systems. Software based on this platform allows you to:

Meet strict integrity and security requirements
Addresses environmental awareness and motion response planning
Integrate the vehicle into an external system back end or infrastructure
Compatible with external system changes (as software changes are possible during the vehicle’s lifetime)

The RTE layer of the software architecture includes the C++ Standard Library. It supports communication between AUTOSAR software components of the application layer and between AUTOSAR software components and the software provided by the base software layer. The base software layer consists of the system’s underlying software and services. The AUTOSAR software components of the application layer communicate with each other, with services outside the platform, with the underlying software, and with services by responding to event-driven messages. Software components use C++ application programming interfaces (APIs) to interact with software in the base software layer.

The underlying software includes the POSIX operating system and software for system administration tasks, including:

execution management
communication management
time synchronization
identity access management
Logging and tracking

Examples of services include:

Update and configuration management
diagnosis
Signal to service mapping
network management

The ECU hardware on which a single instance of an Adaptive Platform application runs is a machine . A machine can be one or more chips or virtual hardware components. The hardware can be a single chip hosting one or more machines, or multiple chips hosting a single machine.

The Adaptive Platform supports the development and use of hardware-independent AUTOSAR application software. The abstract representation of RTE for a specific ECU (microcontroller, high-performance microcontroller, virtual machine) separates the AUTOSAR software components of the application layer of the architecture from the architectural infrastructure. AUTOSAR software components and underlying software and services communicate using dedicated ports. Configure the application by mapping the ports of the components to the RTE representation of the system ECU.

Comparison between AUTOSAR Classic Platform and Adaptive Platform

purpose or function	Classic Platform	Adaptive Platform
Use Case	embedded system	High-performance computation, communication with external resources, and flexible deployment
programming language	C	C++
operating system	bare board	POSIX
real-time requirements	hard	soft
calculation ability	low	high
communication	signal base	event-based, service-oriented
safety and security	Support available	Support available
dynamic update	It can not be used	Incremental deployment and runtime configuration changes
Level of standardization	High — detailed specifications	Low — API and semantics
agile development	none	can be