AUTOSAR – Automotive Open Systems Architecture
What is AUTOSAR?
The Wikipedia definition yields “It is an open and standardized automotive software architecture jointly developed by automobile manufacturers, suppliers and tool developers”
In plain words, AUTOSAR is a common platform across the whole automotive industry which will enhance the scope of applications of vehicle functionalities without disturbing the existing model.
AUTOSAR works on below mentioned principle –
“Cooperate on Standards, Compete on Implementation “.
The sole objective of AUTOSAR is to establish a common standard among the manufacturers, software suppliers and tool developers, retaining the competition so that the end outcome of business is not altered in the process.
The need for AUTOSAR:
One might wonder does automotive industry really needs such a complex infrastructure? .With the increase in demand for intelligence and more safer ,smarter vehicles the competition is only going to increase in coming days. All the intelligence and vehicle functions are not implemented by single authority, i.e.: Consider a Car X, which has Airbags, Electronic injection system, etc. All of these individual features are implemented on different ECUs by different automotive industries. The way each of them are implemented are no longer independent.
The same holds good for software development process even. Until recently the software developed were only targeted to deliver the intended functionalities without taking into account of how it effects the system. To further complicate matters a lot of functionalities are distributed over various ECUs across different vehicle networks (CAN, LIN, MOST, etc.). This became a more critical problem with the increase in non-standard development procedures. These formed underlying reasons for emergence of AUTOSAR.
In a nutshell why AUTOSAR?
a. Demands for more services, security, economy and comfort.
b. Increase in complexity due to increase in number of ECUs and growth of software sharing and functionality.
c. More diverse set of hardware and networks.
Formation of AUTOSAR:
In 2003, leading automobile companies and first-tier suppliers formed a partnership. This is established as industry wide standard for automobile electronic consisting of 10 core partners: BMW Group, Bosch, Continental, DaimlerChrysler, Ford Motor Company, General Motors, PSA Peugeot Citroen, SiemensVDO, Toyota Motor Corporation, and Volkswagen.
Fig. 1: Symbolic Image of AUTOSAR
Objectives of AUTOSAR:
· Consideration of availability and safety requirements
· Redundancy activation
· Scalability to different vehicle and platform variants
· Implementation and standardization of basic functions as an industry wide “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.
Benefits of AUTOSAR:
Ø Reuse of existing software code.
Ø More design flexibility
Ø Reduced costs and development time.
b. Suppliers :
Ø Increased efficiency in functional development
Ø New business models possible.
c. Tool Provider:
Ø Common Interfaces with development processes.
d. New Market Entrant:
Ø Transparence and defined interfaces enable new business models.
What are expected outcomes of AUTOSAR?
· A standard platform for vehicle software
· An OS with basic functions and interface to software
· Functionality is supplied as software components
· These components are hardware independent
· No applications of its own
· The same interface for all basic software
· The software is exchangeable
· The software can be reused
· More than one supplier can compete with their software
AUTOSAR Layered Architecture:
Fig. 2: Block Diagram of AUTOSAR Layered Architecture
The fundamental concept in AUTOSAR is separation of Application and Infrastructure.
The application part consists of AUTOSAR software component and connectors. The software component encapsulates the functionality of each sub system. The encapsulation might vary from atomic level to whole sub system level.
However each component is implementation is not prescribed by AUTOSAR
Description of Software Component by AUTOSAR:
· The operations and data elements that the software component provides and requires.
· The resources needed by component (Memory usage, CPU- time, etc.)
The source code component implementation is independent from:
· Type of the ECU and the type of the ECU on which the component is mapped upon.
· Number of times a software components is instantiated in a system.
· Location of other components with which it interacts.
The Virtual Function Bus (VFB):
To fulfill goal of transferability, AUTOSAR software components are implemented independent of underlying hardware. VFB provides such virtual interconnection between different components without
By using VFB the software components need not know how with which other application software components they communicate . As the interface is defined in such a way that, the software components give their output to VFB, the VFB guides the information to other components which need this data into their respective input ports. This approach makes it possible to validate the interaction of all components and interfaces before software implementation. This is also a fast way to make changes in the system design and check whether the system will still function.
Run Time Environment:
This acts as system level communication center for inter and intra ECU information exchange. RTE is run time representation of VFB.
The AUTOSAR Runtime Environment has the responsibility to provide a uniform environment to AUTOSAR Software Components to make the implementation of the software components independent from communication mechanisms and channels.
The RTE achieves this by mapping the communication relationships between components, that are specified in the different templates, to a specific intra-ECU communication mechanism, such as a function call, or an inter-ECU communication mechanism, such as a COM message which
leads to CAN communication.
The RTE is responsible for the lifecycle management of AUTOSAR Software Components. It has to invoke startup and shutdown functions of the software component. It acts as layer of separation between ASW (applicationsoftware) and BSW (base software). The BSW modules are free to call any API functions or other modules directly. Whereas ASW components can only communicate via ports.
The RTE is furthermore responsible for ensuring the consistency of data during communication, that
is, to ensure that data are not changed while being received or sent.
RTE Generation happens in two phases:
a. Contract Phase :
This phase is ECU-independent. It provides the contract between a given ASW component and the RTE, that is, the API that the ASW component can be coded against. The input for this phase is the description of an ASW component with all its ports and runnable entities.
The result is an ASW component-specific header file that can be included by the corresponding
source code file. In this header file, all RTE API functions that may be used by the ASW componentare declared. It also declares the necessary data types and structures needed by the ASWcomponent.
b. Generation Phase:
In this phase the concrete code generation for a given ECU is performed. Input
for this phase is the ECU configuration description, which includes especially the mapping of runnableentities to OS tasks or the communication matrix. Together with the ASW component header filescreated during the contract phase and all necessary BSW code, the generated code can then becompiled to an executable file for the given ECU.
Basic Software (BSW):
Basic Software is the standardized software layer, which provides services to the AUTOSAR Software Components and is necessary to run the functional part of the software. It does not fulfill any functional job itself and is situated below the AUTOSAR Runtime Environment. The Basic Software contains standardized and ECU specific components.
Access to the hardware is routed through the Microcontroller Abstraction layer (MCAL) to avoid direct access to microcontroller registers from higher-level software. MCAL is a hardware specific layer that ensures a standard interface to the components of the Basic Software. It manages the microcontroller peripherals and provides the components of the Basic Software with microcontroller independent values. MCAL implements notification mechanisms to support the distribution of commands, responses and information to different processes. Among others it can include:
· Digital I/O (DIO)
· Analog/Digital Converter (ADC)
· Pulse Width (De)Modulator (PWM, PWD)
· EEPROM (EEP)
· Flash (FLS)
· Capture Compare Unit (CCU)
· Watchdog Timer (WDT)
· Serial Peripheral Interface (SPI)
· I2C Bus
ECU Abstraction Layer
This layer interfaces driver of Microcontroller abstraction layer. Also contains drivers of external devices. It offers API for access to peripherals and devices regardless of their location and their connection to uC.
The highest layer of BSW which provides services to application software such as:
· Memory Services
· Communication Services
· Diagnostic Services
The implementation is uC and ECU hardware independent.
Complex Device Driver (CDD)
This serves as special functional and timing requirements for handling complex sensors and actuators. The CDD implements complex sensor evaluation and actuator control with direct access to uC specific interrupts and peripherals.
BSW Conformance Classes
The conformance classes are basically used to ease migration form non AUTOSAR to AUTOSAR platform. Since taking all the modules at once will be a huge effort, the classes are divided into three sections as ICC1, ICC2, and ICC3.
Modes of Communication
The client initiates the communication, requesting that the server performs a service, transferring a parameter set if necessary. The server waits for incoming communicationrequests from a client, performs the requested service, and dispatches a response to theclient’s request. The direction of initiation is used to categorize whether an AUTOSARSoftware Component is a client or a server. A single component can be both a client and aserver, depending on the software realization. The client can be blocked (synchronouscommunication) or non-blocked (asynchronous communication), respectively, after theservice request is initiated until the response of the server is received. The image gives an example how client-server communication for a composition of three software components and two connections is modeled in the VFB view.
The sender-receiver pattern gives solution to the asynchronous distribution of information, where a sender distributes information to one or several receivers. The sender is not blocked (asynchronous communication) and neither expects nor gets a response from the receivers (data or control flow), i.e. the sender just provides the information and the receivers decides autonomously when and how to use this information. It is the responsibility of the communication infrastructure to distribute the information.
Filed Under: Articles
Questions related to this article?
👉Ask and discuss on Electro-Tech-Online.com and EDAboard.com forums.
Tell Us What You Think!!
You must be logged in to post a comment.