This article is geared towards mitigating the initial brain fog in understanding the AUTOSAR concept, and further discussing the capabilities and shortcoming of the ubiquitous AUTOSAR is.
Embedded software development in automotive industry is very different from typical software development scenarios in domains such as web development, windows-based application programming and so on. One of my former colleague Viktor Shepik as aptly described the automotive SW development situation in one of his blog posts. As Viktor rightfully mentions in the post, a software engineer is shocked when he/she steps into automotive software development, and IMHO it may come to some as an understatement.
Technical terms are domain specific jargons, compilers are tweaked and overhauled, rules of programming are stringent. Moreover experienced engineers aren’t either willing or don’t have the patience or time to share their vast accumulated knowledge with an automotive newbie. Existing information in the books has mostly nothing to do with practical day to day tasks at large.
What is AUTOSAR?
First of all, it is a consortium in order to standardize same or similar functionalities under an open and standardized layered software architecture for automotive *ECUs. The consortium was founded in 2003 by automotive giants like BMW, Daimler, VW, Ford, GM, Toyota, PSA, Continental ve Bosch. Automobile manufacturers, suppliers, software and tool developers work together under one roof.
* ECU: Electronic Control Unit
Why is AUTOSAR needed?
The ever increasing E/E (Electric/Electronic) complexity of automotive systems was a major motivation which led to the development of the standard. A modern car may have more than 100 ECUs and each of them contains thousands of functions which must often be rewritten from scratch when hardware (processor type) is changed.
It was urgent need for automotive giants to cooperate together in order to make application software independent from hardware. In order to accomplish this, basic functions are implemented in AUTOSAR as an industry wide “standard core” solution and to make software modular and reusable.
What are goals?
The motto is simple:
“Cooperate on standards, compete on implementation.”
- With AUTOSAR, it is possible to develop the Software independent from ECU and this Software can be transferred or used in different Systems or ECUs. On the other hand, basic software can be used in different ECUs and areas. It can be adapted to different vehicles, platforms or hardwares
- Compliant with all automotive international standards such as ISO 15767, ISO 14229, ISO 27145 and state-of-art technologies like Steer-by-wire, Autonomous car
Automotive ECUs have following features:
- Strong interaction with the hardware (i.e. Sensors and actuators)
- Connection with bus systems in automobile
- Contain a microcontroller typicaly 16 or 32 Bits
- Real Time System
- Internal/External Flash Memory
AUTOSAR Architecture Layer
AUTOSAR subdivides Embedded-Software into 5 Layers. At first glance, we see an OSI-similar but characteristic layer model which describes hierarchical structure of AUTOSAR software in an top-down approach.For this purpose, AUTOSAR subdivides into basic software, runtime environment and application layer. In each layer, certain software modules are abstracted and these layers communicate via interfaces.The basic software consists of 3 Layers: Microcontroller Abstraction Layer, ECU Abstraction Layer and Services Layer and each layer includes predefined software modules and services which make application software independent from ECU.
MCAL: Microcontroller Abstraction Layer
MCAL is the lowest software layer of basic software. The MCAL, as a microcontroller specific layer, encapsulates HW-specific drivers like AD Converter, PWM, Flexray Controller, MCU, Watchdog to have direct access to *µC and specific functionalities. Its task is to make higher software layers independent from µC.
ECAL: ECU Abstraction Layer
ECAL provides interfaces to have access to all functionalities of an ECU independent from µC. Its task is to make higher software layers independent from ECU.
The Services Layer provides standardized Services which are relevant for Application Software and Basic Software like i.e. Operating system, vehicle network communication, memory services (NvRAM management), diagnostic services (*UDS, error memory), etc. Its task is to make higher software layers independent from ECU and µC.
*UDS: Unified Diagnostic Services
RTE: Runtime Environment
RTE is the heart of AUTOSAR Architecture.
- RTE works like a call center. It is a configurable interface (Middleware) between Application Software and Basic Software
Application software of an ECU or a vehicle can be developed as a system of interconnected software components by AUTOSAR layer model.
With the help of AUTOSAR layer model, an application software of an ECU or a vehicle can be developed independent from Hardware and it can be transferred to other projects from one ECU to another.Furthermore, basic functions like vehicle communication, error detection which are indispensable prerequisites for automobile manufacturers are developed as a part of basic software while manufacturers themselves and suppliers configure these basic softwares to best suit their individual needs with AUTOSAR-Tools which are usually developed by tool providers. (Configuration)