Introduction to AUTOSAR

What is AUTOSAR, AUTOSAR Basics, AUTOSAR Layered Architecture, Different Layers in Autosar Architecture, Autosar Architecture Advantage and Disadvantage, Application of Autosar

What is AUTOSAR? | AUTOSAR Basics | Introduction to AUTOSAR

How AUTOSAR Layered Architecture is different from Legacy Software (Non-Autosar)

i) Using the AUTOSAR standard, the application software components (ASWC) are completely independent of the hardware.

• Without AUTOSAR standard Application component redeveloped by considering underlying hardware interface protocol, drivers, and microcontroller.
• After Using the AUTOSAR standard, the application does not required to know from where the dependencies and inputs came.
• Application software component (ASWC) can be re-used in any other project independent of underlying hardware for multiple times. It will saves a lot of time and money to develop.
• It was jointly developed by automobile manufacturers, electronics and software suppliers and tool vendors as middleware and system-level standards.

ii) It was developed to standardize software components and Interfaces:

• Any project has the composition of several complex software components, it can be easily implemented using AUTOSAR standard.
• Using the AUTOSAR standard needs to create new software components then, the focus will be only on implementing the inside logic and algorithm, without having to adapt the entire OEM environment.
• Standardized interfaces will provide ease and simple connection to newly created software components with our existing project.

Since, all of the benefits of using AUTOSAR, OEM’s have more time to innovate on their features and applications by considering market competitions.

AUTOSAR Layered Architecture:

The AUTOSAR architecture is a three-layered architecture model.

1. Application Layer (ASWC)
2. Runtime environment (RTE)
3. Basic Software Module (BSW)

1. Application Layer (ASWC):
   • It includes various application-specific software components (ASWC) that are designed to execute a specific set of tasks according to the end-user application.
   • One complete OEM feature (Seating, Lighting, Air-Bag Etc.) in vehicles is possible to deliver by combining multiple application software components (ASWCs) in a single ECU.

2. Runtime environment (RTE): 
   • It acts as a medium between the AUTOSAR application layer and all lower layers including the Basic Software Layer (BSW), Microcontroller Abstraction Layer (MCAL), and ECU Abstraction Layer (ECUAL).
   • RTE will handle intra-ECU communication in between application layer software components (ASWCs) in a single ECU and inter-ECU communication between the BSW Modules through the application layer of two ECU.

3. Basic Software Module (BSW): 
   • It can be defined as a standardized embedded software module that handles various functionality, services required to run the functional part of the upper application software layer (ASWC).
   • This layer consists of a generic Service Module, ECU specific module according to the end application, and a Controller Driver Layer for hardware drivers.

This layer is further divided into three sub-layers:

• Microcontroller Abstraction Layer (MCAL):
  1. It is the lowest software layer of the Basic Software (BSW). It includes internal drivers, which are software modules with direct access to the microcontroller and its internal peripherals.
  2. It will make the higher software layers (application and BSW) abstract independent of lower-lying hardware (microcontroller).
  3. MCAL implementation is completely microcontroller-dependent. Its interface with the upper layer is standardized and microcontroller independent

• Service Layer:
  1. The Services Layer is the highest layer of the Basic Software which also applies for its relevance for the application software: while access to I/O signals is covered by the ECU Abstraction Layer, the Services Layer offers: Ø
  2. Operating system functionality Ø Vehicle network communication and management services Ø Memory services (NVRAM management) Ø
  3. Diagnostic Services (including UDS communication, error memory and fault treatment) Ø ECU state management, mode management Ø
  4. Logical and temporal program flow monitoring (Wdg manager) Task Provide basic services for applications, RTE and basic software modules. Properties Implementation: mostly µC and ECU hardware independent Upper Interface: µC and ECU hardware independent

The Services Layer is the highest layer of the Basic Software which also applies for its relevance for the application software: while access to I/O signals is covered by the ECU Abstraction Layer, the Services Layer offers: Ø Operating system functionality Ø Vehicle network communication and management services Ø Memory services (NVRAM management) Ø Diagnostic Services (including UDS communication, error memory and fault treatment) Ø ECU state management, mode management Ø Logical and temporal program flow monitoring (Wdg manager) Task Provide basic services for applications, RTE and basic software modules. Properties Implementation: mostly µC and ECU hardware independent Upper Interface: µC and ECU hardware independent

It includes all service manager modules like Diagnostic, Communication, and Memory services.

ECU Abstraction Layer (ECUAL):

The ECU Abstraction Layer interfaces the drivers of the Microcontroller Abstraction Layer. It also contains drivers for external devices. It offers an API for access to peripherals and devices regardless of their location (µC internal/external) and their connection to the µC (port pins, type of interface) Task Make higher software layers independent of ECU hardware layout Properties Implementation: µC independent, ECU hardware dependent Upper Interface: µC and ECU hardware independent.

It includes sensor and actuators driver developed which are not part of the MCAL layer.

The Complex Drivers Layer spans from the hardware to the RTE. Task Provide the possibility to integrate special purpose functionality, e.g. drivers for devices: Ø which are not specified within AUTOSAR, Ø with very high timing constrains or Ø for migration purposes etc. Properties Implementation: might be application, µC and ECU hardware dependent Upper Interface: might be application, µC and ECU hardware dependent

Autosar Architect Pros

The advantages of AUTOSAR architecture:

1. Different supplier can work on one product using standard interface/architecture.
2. Reusability is more for software component
3. The layered software architecture
4. Interfaces consistency
5. Modules and interfaces interoperability
6. Cost and software development time will be reduced
7. Efficient functional development

Autosar Architect Cons:

The disadvantages of AUTOSAR include the following.

1. More Complexity
2. Initial cost investment
3. More Learning Curve

Applications

• Sensors like LIDAR and RADAR
• Electrification
• Automotive Apps
• ADAS Functions with a Camera
• Infotainment
• Predictive Maintenance

• Software sharing can be possible between different companies
• Reusability of software component
• The basic software architecture is layered.
• Consistency of interfaces
• Interoperability
• Software code can be reused.
• Design flexibility is more
• Cost and development time will be reduced
• Efficiency can be increased within functional development
• Transparency & distinct interfaces will allow new business models.

The disadvantages of AUTOSAR include the following.

• Complexity
• Initial Investment
• Learning Curve

1) Standardization of specification exchange formats: 

        Each OEM company previously had its 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 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.

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.