CHAPTER 3: AUTOSAR
As discussed before, the complexity of the instrument cluster design increases with increase in the data to be displayed. The need for a display that is more flexible to display dynamically is constantly increasing. The introduction of several safety and comfort systems has increased the number of ECUs and their interaction. In addition to the complexity in design, the manufacturers expect more innovative solutions in a short period to cope with the competitors in the market. Thus, the cluster has to be designed in a way easy to modify, upgrade and update irrespective of its hardware implementation. When such a cluster is designed, the existing clusters can be modified and updated to provide innovative solutions. Thus, the time take to design a cluster is considerably reduced.
In addition, a single authority does not implement vehicle systems for a car. For e.g. the clusters may be implemented by a different company. On the other hand, the air bag systems may be implanted by another company. Even if the same automotive company manufactures, different teams in that industry may be responsible for individual systems. Hence, the way in which each system is implemented is inter dependent since finally, ECUs interact to implement various functionalities across the car.
Hence, there is a need to standardize the implementations of the software and hardware modules inside the car. Such a standardized architecture is Automotive Open System Architecture (AUTOSAR).
The motivation for such a standardization are as follows:
To manage the complex E/E complexity
Flexibility to product medication, upgrade and update.
Improve the quality and reliability of E/E systems.
The primary goals of AUTOSAR are as follows:
Fulfillment of future vehicle requirements, software updates, upgrades, and maintainability.
Increased stability and flexibility to integrate and transfer functions.
Cost optimization of scalable systems
Improved containment of products and process complexity and risk.
The technical goals of AUTOSAR include the following.
This enables the ability to modify the automotive elements according to the individual requirements of the ECUs.
This indicates the ability of the automotive element to adapt to different platform variants. This prohibits automotive elements with same functionality.
This optimizes the use of resources.
This improves the product quality and reliability.
The main principle of the AUTOSAR is “cooperate on standard, compete on implementation”.
The main objectives of AUTOSAR include:
Consideration of availability and safety requirements.
Scalability to different vehicle and platform variants.
Implementation and standardization of basic functions as an industrywide “standard core” solution
Transferability of functions from one ECU to another within the network of ECUs
Integration of functional modules from multiple suppliers
Maintainability throughout the whole product life cycle
Increased use of commercial-off-the-shelf (COTS) hardware
Software updates and upgrades over vehicle lifetime
Hence, AUTOSAR makes it possible to control the complexity of the electrical and electronic components, together with an increase in quality and profitability. The future of automotive engineering is in these modular and scalable AUTOSAR software architectures.
The virtual functional bus is the abstraction of the AUTOSAR Software Components interconnections of the entire vehicle. The communication between different software components and between software components and its environment (e.g. hardware driver, OS, services, etc.) can be specified independently of any underlying hardware. The functionality of the VFB is provided by well-defined communication patterns.
The layered architecture of AUTOSAR is as shown in figure 3.1 and 3.2.
Fig.3.1 Layered architecture of AUTOSAR
Fig 3.2 Detailed layered architecture of AUTOSAR.As seen in the above figure, the fundamental goal of AUTOSAR is the separation of the application and hardware. Any system inside the car is implemented based on this architecture. The three main parts of this architecture is:
Run Time Environment (RTE).
3.5.1. BASIC SOFTWARE
The basic software layer can be further divided into different layers as:
Microcontroller abstraction layer
This layer provide the access to the hardware. This is the lowest layer. It contains the low-level drivers with direct access to microcontrollerperipherals below it. It is responsible for proving abstractions to the microcontroller . These devices include:
memory drivers, communication drivers and
Input/output (I/O) drivers.
ECU abstraction layer:
This layer is responsible for providing abstraction to the ECU hardware layout from the layers above it. This is above the microcontroller abstraction layer, which provides access to the hardware components outside the microcontroller on the ECU. Components included here include:
CAN interface etc.
Thus, it contains drivers for external devices. It provides an interface for access to peripherals and external devices.
This is the highest layer of the basic software This layer is above the ECU abstraction layer and serves to provide the basic software functionality to the application.
Components included in this layer include:
The service layer offers the following functionalities:
Operating system functionality
Vehicle network communication and management services
Memory services (NVRAM management)
Diagnostic services (including UDS communication, error memory and fault treatment),
ECU state management
3.5.2 AUTOSAR OS
The AUTOSAR OS accesses the hardware in order to manage the timer for time sliced scheduling.
3.5.3 COMPLEX DEVICE DRIVER
Like the OS, Complex device driver is also allowed to directly access the hardware. The purpose of the complex device drivers is to extend the standardized part of the architecture with new device drivers, which have not yet been standardized.
3.5.4 RUN TIME ENVIRONMENT
This layer separates the basic software from the application layer. The primary task is to make the AUTOSAR componens independent from mapping to a single ECU. This acts as a center for inter and intra ECU communication. This enable easy integration of customer specific software functional modules. Thus, this layer strictly separates basic software and application layer. It totally shields the application layer from the peculiarities of the basic software and allows success in a clearly defined way.Thus, this layer provides communication services to applications.From the viewpoint of the AUTOSAR, the RTE implements the VFB functionality on a specific ECU.
3.5.5 APPLICATION LAYER
This contains the actual system like the Antilock braking system(ABS), Electronic stability system (ESP) , instrument cluster etc.
From the brief description about the architecture of AUTOSAR, the key features of AUTOSAR can be concluded as:
Modularity and Configurability
This implies the
Definition of a modular architecture for automotive electronic control units.
Resource optimized configuration of the SW infrastructure of each ECU depending on the function deployment.
Scalability of the E/E-system across the entire range of vehicle product lines
Standardization of different APIs to separate the AUTOSAR SW layers
Run time environment.
AUTOSAR runtime environment to provide inter- and intra-ECU communication across all nodes of a vehicle network. Thus, it enables the easy integration of customer specific functional SW-modules
Hence, every system implemented must comply with the AUTOSAR standards. This applies to the instrument cluster too. The following chapter discusses how the general block diagram of the instrument cluster discussed in the previous chapter is implemented using the AUTOSAR architecture.