(AUTomotive Open System ARchitecture) is a worldwide development partnership of car manufacturers, suppliers and other companies from the electronics, semiconductor and software industry.
Some of the main drivers of AUTOSAR include
- Management of the E/E architecture associated with growth in functional requirements
- Flexibility in product modification and upgrade
- Scalability of solutions within and across product lines
- Improved quality and reliability of the software
A model of the AUTOSAR architecture is illustrated below
An AUTOSAR architecture consists of the following layers- the microcontroller abstraction layer, ECU abstraction layer, services layer, complex drivers together form the Basic software. The application layer is the specific application that it is built for- for example, air bag application The AUTOSAR Runtime environment is the Interface that maps the application with the Basic software.
Microcontroller Abstraction Layer
The microcontroller software layer is the lowest software layer of the BASIC Software. This layer makes the higher software independent of the micro controllers.
As a software engineer it becomes very difficult for us to understand the nuances that are associated the microcontroller. For example, it becomes very complex to understand the drives, GPIO, I/O, A/D functions. All we need to to do is call the interrupts when it is necessary. This is done by the micro controller abstraction layer by developing a set of libraries or functions. We can call those libraries when needed and they will execute the task.
The micro controller is actually developed by different semiconductor industries. the way we access as GPIO may be different for different manufacturers but the GPIO accessories do the same job. So if the micro controller manufacturer provides us a library to access the GPIO in a standard format which we can access rather than we try to understand the Microcontroller then we save a lot of time and effort. (focus is just on configuring)
Further, the semiconductor Industry is the best person to implement this abstraction because they know the micro controller much better as they are the ones developing the microcontroller.
ECU ABSTRACTION LAYER
THE ECU abstraction layer interfaces the drivers of the Microcontroller Abstraction Layer. It makes the higher software layers independent of the ECU hardware layout. It offers access to the I/O signals.
The same microcontroller can be used for building many ECUs. We can have an ECU to control four cylinders, or we can have and ECU to control 6 cylinders or 12 cylinders all running the same micro controller. If we have to develop the BSW for the specific ECU (say for instance- an ECU managing 12 cylinders) we could have to provide different implementations of the final services that these ECUs are intended to deliver. For instance, if you have to drive the current for actuator 0, 1 , 2, 3, 4… at the upper level we want to have available functions with current arguments, then it is upto the BSW to control the proper micro controller threshold layer in order to implement the comment.
ECU abstraction layer is intended to deliver the upper layer with ECU specific services. Again, multiple makers can implement the same service in multiple ways i.e., the software components can be implemented in a single ECU or they can be distributed among many ECUSs. From the application point of view we dont care how they are implemented; we are just expecting the services to be implemented.
The Services layer is the highest layer of the BASIC SOFTWARE.
Service layer takes care of implementing the operating system, diagnostic services and other higher-level services that are usually independent of the hardware. It manages the buffer, the memory , scheduling the tasks of the application based on some policy, booting etc. It provides the basic services for application and basic software modules.
Complex Device driver
It is part of the BSW. This is the place to incorporate anything that has to be standardised. It allows the code to be reused by using a wrapper so that the legacy code can be reused. it is very difficult to reuse the code in the ECU abstraction layer. It is very difficult to change anything in the abstraction layer as it a monolithic piece of code.
Application layer consists of the software modules that will be developed to build a particular application. This is the piece of software that the OEM is ready to pay . Sometimes the OEM build some of the applications to protect their IP. For instance, Ferrari might develop some algorithms to effectively power their engines which they may not wish to share.
It is the glue between the application and the BSW. The application layer communicates with the BSW through the RTE. It makes the AUTOSAR software components independent from the mapping to a specific ECU.
ANCIT is working towards helping automotive software engineers build software application on AUTOSAR. This is a series of BLOGS that is working towards helping the automotive Engineers achieve the same.
The next blog will be on AUTOSAR software components and software architecture.