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.]
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.
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.
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
Excellent!!! Very useful content. Explained in a simple language.
ReplyDelete