AUTOSAR - Technical Overview - Part 1

This is the first article in "AUTOSAR - Technical Overview" series. The base for this series is the technical overview document published by autosar.org. But in these articles I attempt to make the concepts clear and explain them in a simple terms and easy to understand way.

Prerequisites : ECU AUTOSAR Overview, AUTOSAR advantages

        AUTOSAR is a standard software architecture specifically for automotive ECUs followed by manufacturers and suppliers in automotive industries.

So any company which develops AUTOSAR compliant software must adhere to this architecture as standard. In fact AUTOSAR standardizes these following 3 things:
1) Software Architecture
2) Methodology
3) Interfaces

They are explained as below:

1) Software Architecture: 

AUTOSAR partners has formed a software architecture and decided the guidelines and set the rules. Any AUTOSAR compliant software must adhere to these rules and guidelines and must fit in the architecture. The AUTOSAR software architecture is as shown in below diagram.

AUTOSAR Software Architecture

AUTOSAR Software architecture is broadly classified into 3 categories. They are 

1) Basic Software (BSW) 

2) Application Software (ASW) 

3) Run Time Environment (RTE).

BASIC SOFTWARE (BSW)

        Basic software is the infrastructure which is responsible for supporting ASW and providing service to application software to communicate and utilize the hardware resources. The underlying hardware here is ECU (Electronic Control Unit) which consists of  micro-controller, memory chips, ASICs, power stages,  and any other hardware resources needed to control the automotive system in a desired manner.  Basic software itself doesn't implement any automotive functionality which can be used by the user.
        The AUTOSAR  has made basic software as layered architecture. The layers are
i) MCAL (Microcontroller Abstraction Layer): Which directly access and control the underlying micro-controller and its resources. It abstracts the micro-controller from its upper layers. [That means the details of registers, memory location, if the controller is a BIG ENDIAN or LITTLE ENDIAN etc are hidden from above layer and provides a uniform interface to them to access the below hardware.]

ii) ECUAL (ECU Abstraction Layer): Which interacts with MCAL layer for micro-controller access and directly accesses the hardware resources inside the ECU and not inside micro-controller (like external memory chips, external CAN controllers etc). It abstracts the ECU from its upper layers. If the ECU is changed or upgraded then the layers above ECUAL will not be affected.

iii) Services Layer: Which provides the services to application layers using which the application software components can utilize the hardware resources. Services layer also includes the operating system. The real time operating system of AUTOSAR is called OSEK.


        We visualized BSW as layers (horizontal) before. Basic software can also be viewed as stacks (vertical layers) depending on the functionality. For example The software modules for communication (like CAN Flexray, ethernet etc) in each of the layers like MCAL, ECUAL and services can be visualised as stack of software modules for communication. This is called as comstack. Similarly the AUTOSAR can be visualized as group of following stacks:
i) Service stack: General services (like I2C SPI etc )provided by BSW to upper layer
ii) Comstack: Communication stack for intra-ECU or inter-ECU communication
iii) Memstack: Memory stack. Stack of software modules which provide services to access the memory resources of ECU.
iv) Diagstack: Diagnosis stack. Stack of software modules which implement the vehicle diagnosis and tester communication and OBD standards. [Click here to know more about vehicle diagnostics.]

v) IO stack: Input Output Stack. The software modules which control the input pins output pins of ECU, the ADC and other input output related devices present in the ECU.

Complex Device Drivers: ECUs resources can be generally classified into above 5 stacks. But sometimes ECUs will have some ASICs (Application Specific Integrated Chips) from suppliers present in the ECU. These resources can not be categorized in any of the above mentioned stacks. Since these are not generic and specific to the suppliers and is dedicated for a complex functionality, these are called complex devices. So to access these complex devices, suppliers also write drivers for them called as complex device drivers. Since this software module cannot be included in any of the above mentioned standard stacks, a separate section is given for such complex device drivers in AUTOSAR software architecture. These provide services and means for application software to utilize thee complex devices to realize their automotive functionality. Note that this complex driver can not be sub divided into horizontal layers like MCAL ECUAL and service layer. 

APPLICATION SOFTWARE (ASW)

               Application Software (as its name indicates) is the software which actually has value to the user. It realizes the automotive functionality and the features in the ECU. AUTOSAR has made the application software layer as component based. Application software consists of software components (SWCs) as shown in the diagram above. 
                A software component is a basic unit of ASW which encapsulate an automotive application which runs on AUTOSAR infrastructure. It has well defined interfaces which are standardized in AUTOSAR. 



REAL TIME ENVIRONMENT (RTE)
            Real Time Environment (RTE) is in-between layer of ASW and BSW. RTE provides a communication medium between software components (SWCs) or a SWC and a BSW module.
            A software component may have dependency on an input variable which may be produced and output by another software component in the system. But as per AUTOSAR the application software component is independent of the underlying hardware. Also the SWC which needs the variable doesn't have knowledge of presence or location of the SWC which is producing the variable. So there should be some piece of software which connects connects the two SWCs by taking the variable from producer SWC and gives it as input to receiving SWC. This piece of software is called as API (Application Programming Interface). Collection of all these APIs together forms RTE.

There can be 2 cases. 
Case 1: If the both software components happen to be in same ECU. then RTE implements API to be just taking the data from producer software component (say SWC - 2) and give it to receiving software component (say SWC - 1) as shown in below diagram.

RTE: API for communication of  Intra ECU SWCs

Case 2: If the both software components happen to be in different ECUs. then RTE of receiving ECU implements API to be just taking the data from its comstack (BSW) and give it to receiving software component (say SWC - 1). On the other hand the RTE of ECU where the producer software component (say SWC - 2) is located, takes implements a API to take the variable from SWC - 2 and gives it to its comstack as shown in below diagram.

RTE: API for communication of  Inter ECU SWCs

            When all the Autosar Software Components are available, during integration into ECUs, these APIs are generated and RTE layer is formed.

2) AUTOSAR Methodology

            AUTOSAR requires a common technical approach for some steps of system development. This approach is called the “AUTOSAR Methodology“. The AUTOSAR Methodology is neither a complete process description nor a business model and “roles” and “responsibilities” are not defined in this methodology. Furthermore, it does not prescribe a precise order in which activities should be carried out. The methodology is a mere work-product flow: it defines the dependencies of activities on work-products. Click here to know more about AUTOSAR methodology.

Author - Shyam Bhat

AUTOSAR - Advantages and Disadvantages

Prerequisites: ECU  AUTOSAR Overview

This article explains you the advantages and disadvantages of AUTOSAR

Any company would only switch or make changes in its process only if it gets benefit in time (which will result in  time to market or delivery and market control ), quality (Which will increase goodwill of the company) or money (increases money spent which in turn increases profit). So below the pros and cons of AUTOSAR are given which will finally boil down to impact n above mentioned 3 factors. These points will make you understand why AUTOSAR has become viral now in automotive industry.

Advantages of AUTOSAR:

1) Standardization of specification exchange formats: 

        Each OEM company previously had their own customized formats of providing requirement and specification to its tier1 company. So the tier 1 company has to invest some time in understanding the format and procedure or requirement handling. If a company had requirements from 100 manufacturers then there were 100 different formats in which requirements were given. But after AUTOSAR, the formats and content of specifications are standardized. By doing this the tier companies need to be familier with only standard format and reduces the time and hence improved productivity.

2) Standardization of Basic software: 

        The software present in an ECU can be divided into two major categories. One being the support software or the infrastructure and the second being the application software which implements the actual automotive functionality of value to the user. For example the drivers of hardware modules are the software which doesn’t give any user value by itself. But a software module which controls the headlight operation or injections etc have a application which is useful to the user and implements the feature for which the customer pays. So the infrastructure software which doesn’t have a standalone value is called as a Basic software whereas the software which implements a automotive function or feature is called an application software. The basic software on its own doesn’t implement any automotive feature so as a user perspective is of no value. But without basic software, the application software can’t work.  So in a way the time and money invested in the  design and development  of basic software  is a total waste.

AUTOSAR structure (Basic)

              AUTOSAR standardizes this BASIC software in order to reduce the time and money to be spend on BSW development. AUTOSAR defines the HDL (High level design) and structure of BSW so that only LLD (Low level design) Needs to be taken care by the company to have a standard BSW and concentrate its major focus on development of application software and earn good profit.

3) Layered architecture of Basic Software (BSW):  

            Suppose if the micro-controllers availability and manufacture is stopped or if the new functions implemented are overloading the existing controllers then the need for changing the micro-controllers arises. But if the underlying hardware is changed then entire basic software needed to be changed as entire BSW was previously designed based on hardware. But AUTOSAR has layered architecture of BSW as shown in below diagram. The layer MCAL abstracts the underlying micro-controller specifics from its above layers and ECU-AL abstracts the underlying ECU specifics from its above layers.  So if the micro-controller needs to be changed then there is no need to re-design and develop entire BSW but only the MCAL layer. So the effort and time and money which was needed to be invested in upper layers like ECUAL or service layers is saved.

AUTOSAR Layered Architecture

4) Software sharing between companies:

              Previously since each company had their own software architecture, the software modules from different suppliers could not be combined and put on a single ECU. So the entire software for a ECU needed to be developed completely by a single supplier. But AUTOSAR is a standard architecture and has made each software module as independent as possible. Due to this its possible to take multiple software components developed by multiple AUTOSAR following suppliers, and integrate them together into a single ECU. Due to this the manufacturers or OEMs has the option of selecting the best of software components from multiple suppliers and can integrate them in a single ECU and this improves the quality of the automotive systems a lot. 

5) Software Component Re-Usability:

              Previously, the software components were written and were dependent on underlying hardware and hence each software specific to its ECU. But AUTOSAR has made software components independent. When you learn AUTOSAR in further articles you will realize that software components in AUTOSAR are completely independent of hardware and also need not know from where is it getting its inputs and dependency of other modules on it. So a software component can be re-used in any ECU again and again and hence saves a lot of money. 

6) Standardization of Interfaces:

            When a small innovation need to be implemented at a reasonable effort, it was not possible as the software module implementation had to be implementation of the innovation and the redundant implementation to make the software module to adapt to the OEM specific environment. When I say OEM specific environment I mean that the interfaces which it takes needs to be same as it is in the existing software, the attributes of software implemented newly must be made to adjust to existing infrastructure. But with AUTOSAR, the interfaces are standardized which makes implementation of new small innovations as only implementing the algorithm. The architecture and integration process automatically makes sure that new module is fit in infrastructure. In simple words if a software component is implemented as per AUTOSAR guidelines and rules, then no effort or separate implementation is needed to make the software adapt to AUTOSAR infrastructure hence saving of time and money.

Disadvantages of AUTOSAR:

            AUTOSAR has no disadvantage but two negative point to classical suppliers due to introduction of AUTOSAR are mentioned below. Note that both disadvantages are with business perspective: 

1) Software sharing is a disadvantage to ECU suppliers:

            Before AUTOSAR was developed, The suppliers who manufactured the ECU used to develop entire software for the OEM. But since advent of AUTOSAR, software sharing is possible. It means the OEMs can take the software modules from multiple suppliers and integrate them on the ECU This means that when OEM takes a part of software from other supliers, then its a loss for the supplier who used to provide entire software before. So even though AUTOSAR is a plus point for OEM, it became a negative point to the supplier.

2) Initial investment cost for changing the architecture:

           This is not a disadvantage in reality. When AUTOSAR was developed and the companies adopted AUTOSAR, it doesn't happen overnight.  A lot of money and effort has to be invested in learning the new architecture, migrating the existing software implementation to AUTOSAR compliant software etc. So this is a investment from companies can be considered as a con. But once this phase is over, AUTOSAR compensates the loss and starts giving the profit very soon.

Author - Shyam Bhat

AUTOSAR - Overview

Prerequisites: Electronic Control Unit

AutOSAr is an acronym for Automotive Open System Architecture. As its name suggests it is a software architecture for automotive ECUs. 

Before understanding AUTOSAR, you need to know what is meant by a software architecture.

Software architecture is a blueprint or the software model designed based on its hardware which guides software developer to make the software as modular as possible  and get optimum utilization of available hardware resources too. 

AUTOSAR is the software architecture designed specially for Automotive ECU hardware. If you have read the ECU article given in the pre-requisites, then you already know that automobiles have Electronic control systems in them called ECUs. These ECUs are embedded systems. And an embedded system without software is like a body without mind. Software tells the hardware, what actions to be taken on its input and how the outputs  must be computed and given. All the algorithms for vehicle control are  realized by software in ECUs. But the automotive system controlled by an ECU is huge and complex. So we need a software architecture as a guide for writing the software. This software architecture sets some rules and guidelines following which, will make the process of software development easy and simple. 

But there are so many companies in market who write software for ECUs and manufacture ECUs too ( like Bosch, Delphi, Continental etc). And each company has their own separate software architecture. So the OEMs ( Original Equipment Manufacturers : say Car Manufacturers)  had to take the complete software for an ECU from a single company. For example, Engine ECU controls exhaust system and ignition system both. Now if Bosch has very good software for exhaust control but continental has better software for ignition control, The car manufacturer could not take both software modules from both company and merge them in a single ECU. The reason being both companies follow different software architectures and hence their softwares are not compatible. 

But wouldn't it be wonderful if both the companies followed same software architecture so that the software modules from both  could be integrated together in a single ECU and the car has best of both ignition and Exhaust systems.

So a major stakeholders of Automotive Industry (Manufacturers and Suppliers) joined together and designed a common software architecture which will be used as a standard by all the automotive companies and followed by them in software development process. They called this standard software architecture as AUTOSAR. The textbook definition of AUTOSAR is as given below:

AUTOSAR (AUTomotive Open System ARchitecture) is a partnership of automotive manufacturers and suppliers working together to develop and establish a de-facto open industry standard for automotive E/E architectures.

The slogan of AUTOSAR is "Cooperate on standards, Compete on Implementation". This calls for all the automotive companies to use a standard AUTOSAR architecture and competition can be shown in areas like better LLD (Low level design, Better algorithms to achieve functionalities, implementing new features etc.

This software architecture AUTOSAR also keeps updating its rules and guidelines and hence various versions of AUTOSAR are present. Initially we had AUTOSAR 1.0 then came AUTOSAR v2.0, then V3.0 and V4.0. Currently as of today (end of 2017) The latest AUTOSAR is version 4.3. In each version, minor improvements and features are added to previous versions and released.

AUTOSAR Members:

The nine companies which founded AUTOSAR are Core Members of AUTOSAR community. They are as shown in the below:

AUTOSAR CORE MEMBERS

Then there are Premium Partners who make use of AUTOSAR architecture and also collaborate with core partners and development partners  in order to define AUTOSAR specifications.

Click here to see the list of premium partners of AUTOSAR.

Then there are Development Partners who also make use of AUTOSAR architecture and also collaborate with core partners and premium partners  in order to define AUTOSAR specifications.

Click here to see the list of development partners of AUTOSAR.

There are also Associate Partners who are authorized to make use of AUTOSAR documents which are already released.

Click here to see the list of associate partners of AUTOSAR.

Finally there are Attendees who witness the process of  defining the autosar specifications and help in defining the specifications with core, premium and development partners.

Click here to see the list of attendees of AUTOSAR consortium.

If you want to join AUTOSAR then click here.

This is the first article in our AUTOSAR series where I have given an introduction of AUTOSAR to you. We will delve deep into benefits of AUTOSAR, technicalities of AUTOSAR software architechture and then further deep into the specifications of each module in our coming articles. If you want to see the AUTOSAR specifications and know more about it then you can go to official website of AUTOSAR (Link: https://www.autosar.org/).

Author -  Shyam Bhat

ECU Quiz

ECU Quiz

Quiz

 

1. What is full form of ECU?
   1.   Engine Correction Unit
   2.   Electronic Control Unit
   3.   Embedded Controller Unit
   4.   Engine Control Utility
2. What is the need for ECUs in automobiles?
   1. To meet Emission Legistaltion Norms
   2. Car becomes cheaer with ECU
   3. Human Safety
   4. ECU makes car more beautiful
3. Which of the following are not Emission norms?
   1. EURO5
   2. OBD 2
   3. CARB
   4. BS4
4. Which of the following are limited in emission norms
   1. Carbon Monoxide (CO)
   2. Carbon Dioxide (CO2)
   3. Hydrocarbons (HC)
   4. Ammonia (NH3)
5. Which of the below ECUs prevents theft of automobile
   1.   Engine control unit
   2.   Airbag control unit
   3.   Immobilizer
   4.   Body control manager
6. ECUs are ___________ systems.
   1.   Mechanical systems
   2.   Electro-mechanical systems
   3.   Embedded systems
   4.   Software systems
7. Which of the following statements is wrong?
   1.   ECUs made it possible to have additional safety and luxury features in cars
   2.   ECUs increase the accuracy and precision of our control on autonmotive functions
   3.   Every car in todays world has ECUs in them
   4.   ECUs have sensors and actuators

Electronic Control Unit (ECU)

Pre-arequisites: None

Background:

In automobile industry, there was a time where automobiles like cars consisted of only mechanical systems. From engine to chassis, break, transmission system, fuel system, whatever you name it, it was completely mechanical.. Even the complete car set up and machine was simple and there was no much advanced  features in them. But the mechanical systems had inherent limitations and limited accuracy, which not only caused undetected failures, but also pose life threats to the consumers. So the Electronic chips were introduced in automotive systems. These electronic controllers were necessary mainly due to 4 reasons given below:

1) Vehicle and human safety: If some fault occurs in any sub system of the car, then  the driver doesn't get to know until the fault leads to some bigger problem. The problems like car getting suddenly stopped in between road, or failure in break system etc. Such problems can be very dangerous to the vehicle and even to the life of its occupants. So it is necessary to detect such faults at an early stage and report it to the driver so that it can be diagnosed and fixed soon. The Electronic control units, makes it possible by diagnostics. These electronic controllers monitor the car health status continuously and indicate the driver upon occurrence of an error so that we can prevent that error causing a bigger problem in the future and thus increasing the safety.

2) Emission Legislation Norms: When the cars were completely mechanical, they were one of the significant sources of air pollution. These Petrol(Gasoline) and diesel cars would burn the fuel and emit all the air polluting by-products (like carbon monoxide, Nitrous oxides, sulfur, particulate, soot etc) into the atmosphere without precise processing of its exhaust gases. These emissions were polluting the air. So the government of various countries made laws to limit the amount of chemicals the cars were allowed to emit into the air and this limit kept getting more and more stringent with time. These are called the emission norms and the automobiles which did not comply with these norms are not given licence by the government. (Please click this link to know more about emission norms in detail).

        So in order to adhere to the emission norms, we need to control the amount of the chemicals emitted by  the car without affecting its quality and performance. For achieving this, various methods were invented which needed precise control over the engine functions and monitoring the amount of chemicals etc. Some of the processes for reducing emissions are exhaust gas re circulation, Variable valve timings(briefly explained at the end of this article) etc These all need sensors and actuators and algorithms to be implemented in electronic controllers. So these controllers made it possible for automobile manufacturers to adhere to emission norms.

3) Vehicle Security:  When the automobiles were completely mechanical, it was very easy to hack any car and rob it. Just by finding ignition wires and triggering it would be sufficient to start the car even without having the key. Along with this, tampering with mileage, number of kilometers traveled, etc could be easily tampered with. But since the advent of electronic control units in automotive industry, the security has increased predominantly. Various cryptography algorithms are implemented into car systems and it becomes almost impossible to hack the system or rob it. A separate control unit like immobilizer prevents robbery completely and even if the car is theft, there are systems installed in it which makes it easy to trace the location of the car and get it back. Hence ECUs are necessary for vehicle security

4) Advanced Features: As you know, like all other industries, Automotive industry is also a profit-oriented business. There are so many manufacturers of car and they have to compete in the market to convince customers to buy their cars. So one way to lure the customers in is by providing various advanced features in the car at a low cost. Safety and luxury features like ABS, Adaptive cruise control, infotainment system, GPS connectivity, Cloud connection, etc makes the customers buy their cars instead of others. These advanced additional features makes the life of the driver more easy and comfortable and we need electronic control systems to realize these features. So we have Electronic control units for these like airbag ECU, ABS ECU and so on.

What are ECUs:

ECU stands for Electronic Control Unit. ECUs are the embedded systems present in the automobiles which control a electrical or electronic system with the help of sensors and actuators. These ECUs will have Micro-controllers and memory chips, communication controllers (like CAN or Flexray or SPI etc), and ASICs (Application Specific Integrated Chips) and any other resources needed for controlling its corresponding system. 

These ECUs have sensors and actuators connected to it. They take the necessary input from sensors, process the data and control the system using actuators in order to get the optimum performance out of the system. 
Generally an ECU looks like the image shown below:

Robert Bosch company (Gmbh) produced first ever ECU for Volkswagen car in 1967. and refined it throughout the 70s and 80s. Sports saloons such as the BMW 2002Ti/Tii popularized the concept. Now a days, even a basic low-end car has around 20-25 ECUs present in them and a high end cars will have around 150 ECUs in them. The list of most common ECUs in a car are listed below:

Abbr.	Full name
ABS	Anti-Lock Brake System
ACC	Adaptive Cruise Control
AFS	Active Front Steering
	Advanced Frontlighting System
BCM	Body Control Module
	Brake Control Module
BJB	Battery Junction Box
BMS	Battery Management System
CCM	Climate Control Module
CMC	Cell Module Controller
ECM	Engine Control Module
EPAS	Electronic Power Assisted Steering
ESC, ESP	Electronic Stability Control (Program)
(E)SCL	(Electronic) Steering Column Lock
EMS	Engine Management System
ESS	Energy Storage System
HU	Head Unit
SBC	Sensoric Brake Control
IPC	Instrument Panel Cluster
LSM	Light Switch Module
PAM	Park Assist Module
PDC	Park Distance Control
RSM	Rain Sensor Module
TBM	Trailer Brake Module
TRM	Trailer Module
TCS	Traction Control System

Let me explain you role of ECU with an example of Variable valve timing: 

In a 4-stroke engine of a car. the inlet valve and the outlet valve were opened and closed via camshaft mechanically. This means the inlet and outlet valves were opened and closed at constant regular times, irrespective of amount of fuel intake, or air pressure, or other environmental conditions. So the degree of control we had on engine operations were very limited. This resulted in incomplete combustion of charge (fuel + air mixture) and hence more emission and unwanted wastage of fuel etc. 

Many researches in automotive field showed that we can reduce emissions and save fuel if we could control the time and duration of opening and closing of these inlet and outlet valves depending on different conditions. But it was not possible to achieve with mechanical means. So ECUs made this kind of precise control possible and hence giving the benefit to the car user. Instead of camshaft lobes, solenoid actuators were positioned to control the valves. The various inputs (fuel intake, incoming air volume and pressure, engine speed etc) to understand the condition of engine were taken from various sensors and this data is given to Engine ECU. Engine ECU had the software in which the algorithm for computing the inlet and outlet valve opening and closing times and the duration for getting the optimum results was implemented. Depending on these timings  a pulse signal with corresponding duty cycle was generated at output pin of ECU which was then fed to solenoid. As per this input , the solenoid actuator operated the valves. This mechanism is called as Variable valve timing (VVT) and is as shown in below diagram.

So you can see that unlike mechanical system, ECU was able to control the valves differently at different times depending on different conditions in VVT. 

VVT is one of the many functions of how ECU is able to provide precise control over various systems in order to get the optimum output results and performance from the vehicle systems and sub systems. Some of such examples are Exhaust gas re-circulation, Diagnostics, Antilock Braking systems, Variable fuel injections, Exhaust treatment systems and so on. The list is endless.

Quiz Time: 

Click here to take a quiz to know how much you have understood the topic 

Author: Shyam P Bhat