What is Autosar Technology?
Before Autosar and challenges
Before the development of AUTOSAR (AUTomotive Open System ARchitecture) in 2003, the automotive industry lacked a standardized approach to software architecture, hardware platforms, and development standards.
AUTOSAR was created to address these challenges by providing a standardized software development infrastructure. It’s a global partnership between automotive industry participants, including OEMs, suppliers, semiconductor manufacturers, and software suppliers.
Birth of Autosar/Timelines of Autosar
// which companies united for autosar, with what motive it was invented and mention its timeline
//organisation that are established because of autosar
With respect to this background, the leading automobile companies and their first- tier suppliers formed a consortium in 2003, This partnership was established as an industry wide standard for the automobile electronics: AUTOSAR( Automotive Open System Architecture), which is headed by the following 10 “core partners”: BMW Group, Bosch, Continental, Daimler Chrysler, Ford Motor Company, General Motors, PSA Peugeot Citroen, Siemens, VDO, Toyota Motor Corporation and Volkswagen.
Autosar Consortium has different members, mebers in the form of companies that contribute to it. The roles are varied in terms of their contribution and exploitation. These members are divided in 4 categories:
- Premium Members
- Associate Members
- Development Members
- Attendees
- Subscribers
// give small brief about autosar members
Timeline of Autosar:
- The first phase of Autosar started in 2003 and ended in 2006, during this phase 52 premium members, companies of the suppliers and software and semiconductor industries joined the development of this standard and made major contributions in the consortium.
Main Objective of Autosar
- Autosar was set up as a partenership to define an industry wide
- Themost important consequence of the stringent component-based approach of AUTOSAR, concerning the development process ,is as paration of application devel opment from the lower levels of the integration development (basics of software[BSW]). The separator between these two parts is the AUTOSAR run time environment (RTE), which concretely realizes the concept of a virtual functional bus( VFB) as an abstract ing communication principle. The idea of this concept is that an application does not need to know the concrete paths from data and signals below RTE when two applications communicate together.
- The main concept or object of the AUTOSAR architecture is to separate the application software from the basic software and make it independent of the hardware (standardized infrastructure).
- Autosar software architecture provides the scalability of ECU software for serveral car lines and variants.
- Meaning a customer can spend one time developmenr cost to develope and application like a parking assist system and reuse this application on different hardwares for all his car variants.
What is Autosar
- Autosar was set up as a partenrship to define an industry wide standard for software programing of automotive electronics. Or in more technical way one can say a industry/global level standard for embedded system programing of electronics involved in building automotive systems.
- To overcome the challenges, Autosar defined a new development methodology for automotive software and software architecture. The Development methodology is focussed on a model-driven development style.
- The software architecture is defined without considertaion of the hardware on which the software components will run on later. This means that 2 software components might run on the same ECU or on different ECU’s. The communication between the components is then either an intra-ECU communication or an inter-ECU communication. To abstract from this
- The lightweight Classic AUTOSAR enables companies to perform thorough security testing on systems like electronic stability control (ESC), steering, electric parking brakes, park distance control, infotainment, anti-theft systems, remote keyless entry, and more. By using it, manufacturers can find security vulnerabilities accessible via external channels, such as Bluetooth or other public-facing interfaces.
Analogy of Autosar
Autosar Software Stack has 3 layers:
- BSW Layer
- RTE Layer
- Application Layer
Let’s dwell into BSW Layer. BSW layer stands for Base Software. Which further is divided into 3 layers:
- MCAL Layer
- ECU Abstraction Layer
- Complex Drivers
- Service Layer
Now we will understand these layers, with respect to software’s that are involved in an ECU of a Car. So let’s just dwell into simple building blocks of a ECU.
ECU is made up of Microcontroller and with that microcontroller some external sensor/modules are connected to make it a complete functional product of the vehicle.
- Now to use Microcontroller from software side, Microcontroller driver is needed which is termed as MCU Real Time Drivers.
- And to use sensor/module from software side, their driver is needed which is termed as external driver.
This external driver is developed using MCU RTD and Sensor Specific requirements.
These Sensor and Modules are communicating with microcontroller using MCU drivers like UART, I2C, SPI and etc. and then according to sensor/module their driver is further developed above MCU driver.
- Further in an ECU, different software frameworks like: Operating System, Diagnostic, Logging, Memory analyzes is also used for fulfilling requirements that has to be provided by ECU.
Now let’s relate the software requirements of ECU with Different layers of BSW layer.
- MCU Real Time Driver is MCAL layer in Automotive World. So MCAL layer has standardized the API’s that should be used to use MCU. For each peripheral of MCU, there are MCAL standard API’s. Any Microcontroller that has to be used in Automotive world, should have its MCU RTD designed according to MCAL standard.
- To use the sensors and modules software stack which is used is ECU Abstraction Layer. As to use a sensor with MCU, the peripheral through which sensor is connected that RTD stack would be needed to communicate with sensor. This RTD stack comes via MCAL layer and then sensor specific driver would be made using that MCAL layer module and specific driver that is developed lies in ECU Abstraction Layer. Also in an MCU peripheral there are number of features/ways to use. So to standardized those features and ways of accessing peripheral a software layer is made that also lies in ECU Abstraction Layer.
- After this comes other framework stacks of: OS, diagnostics and etc. Which comes in Service Layer.
Layers in Autosar
- Application Layer:
- Different templates/SWC’s
- Ports:
- runnable entities:
- In this need to understand the different types of SWC’s and then understand the concept of Ports and Runnable entieties in it
- RTE Layer:
- VFB concept:
- Ports
- Interfaces
- Phases in RTE: Contact phasr and generation phas
- In this first to understand the concept of Virtual Functional Bus(VFB) and then the concept of ports on how ports are used for mapping of ASW components to BSW modules.
- BSW Layer
- Service Layer: Service layer is directly allowed to interact with Hardware
- Non Volatile Random Access Memory manager
- Diagnostic Event Manager(DEM)
- COM Stack
- Autosar OS:
- ECU -AL :
- I/O hardware Abstraction
- Communication Abstraction
- Memory abstraction and
- onBoard device abstraction
- Complex Device Driver:
- MCAL
- MCU Drivers
- memory drivers
- communication drivers
- I/O Drivers
- Service Layer: Service layer is directly allowed to interact with Hardware
In Depth Explanation of Layers
ASW Layer
- ASW layer contain the software components(SWCs), which realize the application functionality of the ECU.
- The top layer is the application layer that consists of software components that provide various functionalities and services in the vehicle. The two most significant types are the application software component type and the sensor actuator type.
- All the SWC are portable and reusable except the hardware-dependent SWC like Sensor/Actuator SWC.
- Everything that uses the AUTOSAR platform is located in the application layer; this is the part of the system where the components actually do something useful in the vehicle.
- What are the different Software Components(SWCs) in ASW layer
- What are Software Components?
- The main purpose of the Software Components in AUTOSAR ASW layer is to make it reusability and to design a software module independent of Embedded Hardwares.
- Types of SWC’s in ASW layer:
- Application SWC
- Analog Handler SWC
- Digital Handler SWC
- Parameter SWC
- Composition SWC
- Service SWC
- Service Proxy SWC
- ECU Abstraction SWC
- Nvblock SWC
- CDD SWC
- What are these functionalities and services in the vehicle?
- What are Software Components?
- that it is also possible to deliver an ASW component only in the form of object code, forexample, in order to protect intellectual property. All necessary informatio n is ECU-independent and already available in the contract phase. With the ASW component-specific header file it is possible to compile the source code of a given ASW component. The resulting object code together with the header file can then be delivered as a bundle to the customer.
- ASW layer is also not allowed to use any BSW module directly.
- ASW components have dynamic behaviour and is implemented by “runnable entities”.
- What are runnable entities?
- Runnable entity is a part of SWC where the application behaviour logic is written. Runnable is analogous to functions in C.
- These are the smallest pieces of code (basically C-functions) which implement the SWC functionality.
- There are generally 3 types of runnables:
- Init Runnable:
- Periodic Runnable
- Server Runnable
- What are runnable entities?
- While configuring runnable developers must mention the trigger point type as well as access points, it tells under which condition the runnable needs to be triggered or called.
- What are trigger points/RTE-Events?
- The RTE-Event offers a mechanism to specify when to execute a runnable. For each runnable, an RTE Event defines whether the runnable needs to be called periodically or event-based (e.g. events related to communications like when a mode switches, when an operation is invoked, when a trigger signal is received, etc.).
- What are Ports?
- Each SWC is connected with the help of Ports, these ports give communication between 2 SWCs as well as with BSW.
- Ports are like indiviual end points in SWC’s. Through which data goes or comes inside the particular application.
- There are 2 types of Ports:
- Required Ports(R-Port): This type of port is used when data is to be received or required.
- Provider Ports(P-Port):This type of port is used when data is to be transmitted or SWC is a provider of some service to other entities.
- Ports are connected with each other via Port Interface. The kind of information these ports are handle decides the port interface. Their are 2 types of Port Interface:
- Sender Receive Interface: In this data is transferred from one software component to another software components. Data flow from SWC to SWC is done via sender reciver interface. In which Provider Port is sender and Required Port is receiver.
- Client Server Interface: In this data is tranferred from one SWC to BSW layer. Data flow from SWC to BSW layer is done via Client/erver Interface. In which Provider port is Server and Required port is Client.
- What are Port Connectors?
- Port Connectors are used to specify, the location of Ports: Their are 2 types of connectors:
- Assembly Connector: Assembly connectors are used to connect two ports in a single software component.
- Delegate Connector:Delegation connectors are used when some port of SWC needs to be exposed to the outer world of the Composition (ECU).
- Port Connectors are used to specify, the location of Ports: Their are 2 types of connectors:
- What are Access Ports?
- To access the information conveyed via the ports, The access points specify how the runnable expects to access a data (buffered or not) or an operation (synchronous or asynchronous).
- What are trigger points/RTE-Events?
- In the part aboce RTE, ASW components communicate with each other via Ports. Their is no other way of communication allowed.(e.g via shared global variable).
- ASW is mostly hardware independent(CDD modules which are used directly in ASW are hardware dependetnt only), communication between ASW and hardware( which is BSW layer) is done through RTE layer.
- This layer consists of many software components (SWC) which execute the set of tasks to fulfill the functionality of the vehicle. Each SWC contains many runnable. These software components (SWC) are connected with the help of ports. These ports give communication between two SWCs as well as with BSW.
- What are the different Software Components(SWCs) in ASW layer
Author: Kunal Gupta
