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