AUTOSAR Basic Software (BSW) Tutorial

In this article we will see the AUTOSAR BSW (Basic Software) layer ( the layer below RTE). it is one of the important layers which helps application layer to use, communicate with different peripherals of MCU. 

The BSW configuration which we do in Configurator software like Vector DaVinci Configurator is actually configuration of this layer which is below RTE layer.

 

 

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) stands for 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.

 

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:

ECU abstraction layer helps in achieving ECU hardware independence (hardware independence not only of MCU chip but different external peripherals of ECU board also). Lets look at the blocks in this 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  ECU hardware is  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 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. 

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. 
• 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.

 

Q & A

If I have to add a service in BSW, which will make use of Ethernet Driver using EthTsync, Will I have to add it as Complex driver ?

- No need.