AUTOSAR Basic Software (BSW)

Fig. AUTOSAR layered architecture (detailed)

Above figure shows detailed AUTOSAR Layered architecture. The mild black layer is the microcontroller on which the AUTOSAR would work. The layers 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 MCU dependent and will change on change in 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 have APIs 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 with the MCU directly from RTE. It is useful for writing drivers of peripherals/external devices not defined in AUTOSAR or drivers which requires very high timing constraints beyond scheduler timer. CDD layer is Hardware dependent. 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.

The BSW layer is divided further into:

• I/O: Provides standardized access to external devices like sensors, actuators, relays, and ECU on-board peripherals.
• Memory: Provides standardized access to external or internal memory
• Crypto: Provides standardized access to crypto including external or internal crypto accelerators.
• Communication: Provides standardized access to network systems, ECU on-board communication, internal SWC communication.
• Off-Board Communication: Provides standardized access to Vehicle to other communication system, ECU off-board communication, or internal wireless communication.
• System: Provides standardized things ( OS, timers, etc) and ECU specific functions.  

In AUTOSAR context, there are two driver types 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 external Flash, EEPROM, Watchdog, etc. The internal driver lies in MCAL layer whereas the external driver lies in the ECU abstraction layer. Some external devices like memory mapped memories may be accessed by microcontroller directly, drivers for such devices lies in MCAL.

AUTOSAR also implements the concept of Interfaces, Handlers and Managers. 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 provide a generic API 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. It 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 Groups:

• 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 Communcation 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 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 for which this module can be used. Or if a functionality requires strict timing constraints which may be lesser than the general timing of OS then Complex Drivers module is useful as it directly helps connecting the MCU with the application. Or if the application needs to implement a functionality for controlling a valve by using interrupts of MCU then this module can be used. 
But complex drivers functionality is highly MCU and application dependent and may not be easy to port.

3. ECU Abstraction Layer:

1. 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. This module abstracts such low level details from Application and only provides APIs for using the I/Os. This is MCU independent but is ECU hardware dependent.
2. 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 CAN) is used or which pin is used it just "understands" the data which will be transmitted and received irrespective of communication controllers selected is on chip or on board. For achieving this functionality this module is used. It gives APIs which will be called by respective modules and perform data transmit or receive.
3. Crypto Hardware Abstraction: This module abstracts the crypto functionality by hiding the information of the Crypto used (internal , external device or software based). It provides mechanism for accessing the Crypto devices. 
4. 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 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.
5. 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 like internal or external watchdog timers.     

4. Services:

1. 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. This is MCU and ECU hardware independent but dependent on bus type. The communication services with its stack will be explained in detail in upcoming posts.
2. Off board Communication Services: This is a group of modules for vehicle to X (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.
3. 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 to implement this in a uniform way and abstraction from memory locations and properties this module is used. Provides mechanism for non volatile data management saving, loading, checksum, etc. This is MCU and ECU hardware independent and is highly configurable.
4. 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 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 posts 😊. If you have any doubts please comment it below.