AUTOSAR Basic Software (BSW) Tutorial

Above figure shows detailed AUTOSAR Layered architecture. Lets summarize it.

• The mild black layer is the microcontroller on which the AUTOSAR would work.
• The blocks in red color lies under MCAL (Microcontroller Abstraction Layer) which has drivers for accessing peripherals. MCAL is the lowest layer of BSW, this layer is highly MCU dependent which means, this blocks in this layer will change on change in the MCU.
• The layers in Green color (except CDD) lies under ECU Abstraction Layer. Abstraction in this case means to hide lower level details of the module and just expose APIs to upper layers for implementing functionality. This layer abstracts the MCAL layer from upper layer and provides APIs for accessing external as well as internal drivers. ECU abstraction layer is useful for making upper layers ECU hardware independent.
• Next layer is the CDD (Complex Device Drivers) which connects SWC from application layer directly with the MCU via RTE. It is useful for writing functions/drivers of peripherals/external devices not defined in AUTOSAR or functions which requires very high timing constraints beyond OS timer minimum tick resolution. But this layer is highly hardware dependent and hence there is very less scope of reuse ability or portability.
• The next layer is the Services Layer (all blocks in blue) which is the top most layer of the BSW. This layer provides basic services for application, RTE, BSW modules. Services like: Operating system functionality, Communication services, Memory Services (for NVRAM), ECU state management, etc.

We will see each block of each layer in detail in my future articles.

Internal and External Drivers in AUTOSAR:

In AUTOSAR context, there are two types of driver based on peripheral used they are: internal and external drivers. Internal drivers are used to access internal peripherals located in microcontroller peripherals like Internal EEPROM, ADC,etc. External drivers are used to access external peripherals located outside the micrcontroller like external Flash, EEPROM, Watchdog, etc. The internal driver lies in MCAL layer whereas the external driver lies in the ECU abstraction layer. There are exceptions for some external devices like memory mapped memories, which can be accessed by microcontroller directly and hence drivers for such devices lies in MCAL.

Concept of Interfaces, Handlers and Manager:

AUTOSAR also implements the concept of Interfaces, Handlers and Managers. Please don’t confuse this with Port Interfaces 😀 ! The interfaces lies in the ECU abstraction layer whereas the managers lies in the Services layer. The interfaces provides a functionality to abstract the lower level modules and exposes a generic API access which can be used by upper layers. Interfaces provides access to specific type of device irrespective of number of devices existing of same type and independent of hardware. The handlers control the concurrent, multiple and asynchronous access of one or multiple clients, handlers also performs buffering,queuing etc.The handler functionality is often implemented in the driver or interface. A manager offers specific services to multiple clients. It is required in all cases where only handler is not sufficient. For example NVRAM manager controls the accesses to internal/external Flash memory.

Lets start learning about all layers in detail.  

1. MCAL (Microcontroller Abstraction Layer): 

This layer consists of following module/blocks:

• Microcontroller Drivers: This module has internal drivers for accessing the internal peripherals of the MCU like Watchdog, General purpose Timers, or have functions for direct access to MCU like CoreTest.
• Memory Drivers: This module has drivers for accessing on chip memories like internal Flash, internal EEPROM, or memory mapped devices like external flash.
• Crypto Drivers: This module has drivers for on chip Crypto devices like SHE, HSM.
• Wireless Communication Drivers: This module has drivers for wireless network systems (in – vehicle or off board communication).
• Communication Drivers: This module has drivers for on board communication like SPI, I2C, etc and also has the drivers for Vehicle communication like CAN, FlexRay.
• I/O Drivers: This module has drivers for accessing and using the I/O pins of MCU including digital and Analog, PWM.

2. Complex Device Drivers Or CDD: 

This module useful in implementing non standard functionality within BSW stack. There can be many cases when we need to implement some functionality which is not supported by AUTOSAR, so CDD is used for such cases.  Or if a functionality requires strict timing constraints which may be lesser than the minimum timing of AUTOSAR OS resolution then Complex Device Drivers module is useful, as it directly helps connecting the MCU with the application. 
But complex drivers functionality is highly MCU and application dependent and the code may not be easy to port.

3. ECU Abstraction Layer:

• I/O Hardware Abstraction: In real life ECUs, the I/O peripherals can be on chip or on board and the ECU hardware layout like MCU pin connections or pin inversions may be complex. In conventional software writing, we would have to consider such low level details also, but in AUTOSAR its not. This module abstracts such low level details from Application and only provides APIs for using the I/Os. This is MCU independent(because it just points to lower level drivers) but is ECU hardware dependent because it uses external drivers for on-board peripherals, which if changed then I/O hardware abstraction for it will also change.
• Communication Hardware Abstraction: This module abstracts the location of communication controllers and the ECU hardware layout. The application don’t know about which communication controller(in case of CAN) is used or which pin is used or even which type of communication bus is used whether it is CAN, FlexRay, or other it just “understands” the data which will be transmitted and received irrespective of communication controllers selected is on chip or on board. This module is used for achieving such level of hardware independence. It gives APIs which will be called by respective modules and perform data transmission or reception.
• Crypto Hardware Abstraction: This module abstracts the crypto functionality by hiding the information of the Crypto used (internal , external device or software based). Again upper layers are unknown of the type of Crypto used or even which Crypto is used like whether it is on-chip or on-board or coded in software. This module provides mechanism for accessing the Crypto devices. 
• Memory Hardware Abstraction: This module also abstracts the location of the memory device used. The memory can be on-chip or on-board and the on-board memory may have different ECU hardware layout(like the memory chip differences) but all this information is abstracted from application as it only knows about data and has no control over the type of memory device to be selected.
• Onboard Device Abstraction: This module provides abstraction from ECU specific on board devices. This module contains drivers for on board devices which cannot be called as sensors or actuators or timers like internal or external watchdog timers.     

Till here did you had a WOW moment? if not, then please read again all the things above 😀 . I had a WOW moment when I first understood this, because it is so intelligently designed and the level of hardware independence ECU abstraction layer offers is amazing.

4. Services:

• Communication Services:  This is a group of modules for vehicle network communication which aims at providing uniform services for network management, providing uniform interface to vehicle network for communication and diagnostic communication, also to hide protocol and message properties from the application. Communication Services interfaces with the communication drivers(in MCAL) with the help of Communication Hardware Abstraction (as discussed above). This is MCU and ECU hardware independent but dependent on bus type. So, some part of these services may change if the bus type (CAN, FlexRay, etc) is changed. For more information on communication services you can check out this page.
• Off board Communication Services: This is a group of modules for vehicle to outer clients communication via an adhoc wireless network. It has three blocks used for implementing different functionalities. This module provides a uniform interface for Wireless Ethernet network by hiding protocol and message properties.
• Memory Services: This service consists of one module, the NVRAM manager. It is responsible for the management of non volatile data (read/write from different memory drivers). Generally, application requires storing data in memory for future use, so this module is used to implement this in a uniform way and provide abstraction from memory locations and lower level properties. Memory Services provides mechanism for non volatile data management saving, loading, checksum, etc. This is MCU and ECU hardware independent and is highly configurable.
• System Services: This is a group of modules which can be used by modules of all layers. Examples are Real Time Operating System, Error messenger. These services can be some MCU dependent or may support special MCU capabilities (like Time Service), partly ECU Hardware and application dependent.

In this way the moderately detailed discussion on BSW ends, I hope I explained it in easy language. Don’t worry If you don’t understand some terms you will understand it soon by reading future articles 🙂 .

 If you have any doubts please comment it below.