This blog is part of our series on understanding AUTOSAR better. Our Automotive Product Engineering team, who has in-depth AUTOSAR expertise, will help us understand the essential components of the layered architecture of AUTOSAR.
To kick start our journey of learning more about AUTOSAR, in this blog we will first focus on AUTOSAR MCAL.
Understanding the Basics of AUTOSAR MCAL Architecture:
MCAL stands for Microcontroller Abstraction Layer. In the context of embedded software development, the MCAL can be defined as follows:
MCAL is a software module that has direct access to all the on-chip MCU peripheral modules and external devices,which are mapped to memory. And it makes the upper software layers (Basic software layer, or BSW, Application Layer) independent of the MCU.
(Source – Renesas)
MCAL enables a very significant advantage of the layered architecture of the AUTOSAR compliant design – it makes the application and also the middleware (Basic Software layer) independent of the underlying hardware platform.
This renders immense benefit to the product development cost and time, as there is a shift in the ECU design approach from coding to configuration.
Software Architecture of AUTOSAR MCAL (Microcontroller Abstraction Layer):
MCAL has a range of software modules designed to serve a particular purpose. Each Software Module (Driver) accesses the corresponding On-chip peripheral function. For instance, CAN Driver will ensure that CAN messages can be received and transmitted by the MCU.
What are the Different Device Drivers of AUTOSAR MCAL Module?
Microcontroller Drivers:
- GPT Driver: GPT (General Purpose Timer) device driver uses on-chip MCU timer. Initializes GPT and performs timer count.
- WDG Driver: WDG (Watchdog) Driver, this on-chip device driver Initializes WDG and performs WDG mode settings.
- MCU Driver: MCU (Micro Controller Unit) Driver, this device driver helps configure MCU settings, initializes clock and helps configure power mode settings.
Memory Drivers
- FLS Driver: FLS (Flash) Driver initializes FLS and reads/writes to FLS memory.
Communication Drivers
- SPI Handler/Driver: SPI (Serial Peripheral Interface) is a Handler/Driver Device with on-chip clock serial function that Initializes SPI, performs SPI input/output and SPI I/O buffer settings
- LIN Driver: LIN (Local Interconnected network) is a device driver that initializes LIN and performs LIN input/output.
- CAN Driver: CAN (Controller Area Network) is a device driver that initializes CAN and performs CAN input/output.
- FlexRay Driver: FlexRaydevice driver initializes FlexRay and performs FlexRay input/output.
- Ethernet Driver: Ethernet device driver initializes Ethernet Driver and performs Ethernet Driver input/output.
I/O Drivers
- ICU Driver: ICU (Input Capture Unit) is a device driver using on-chip MCU timer and initializes ICU. It also measures PWM waveforms.
- PWM Driver: PWM (Pulse Width Modulation) is a device driver using on-chip MCU timer. It initializes PWM and sends PWM waveforms as output
- ADC Driver: ADC (Analog Digital Converter) is a device driver for on-chip ADC. It Initializes ADC, starts/stops AD conversion, sets AD conversion result buffer and reads AD conversion results.
- DIO Driver:DIO (Digital Input/Output) is an MCU port device driver thatperforms port signal (input/output).
- PORT Driver:PORT Driver is a MCU port device driver that performs MCU pin settings (I/O, shared functions)
Development and Configuration of AUTOSAR MCAL
All the MCAL drivers are designed for a specific microcontroller platform. This is because the device drivers access the on-chip peripherals of the system MCU.
As a result, every microcontroller comes equipped with its very ownMCALsoftware.
This MCAL software (which is part of the package that includes the hardware platform) now needs to be configured for the specific automotive application.
For example, CAN BUS (MCAL) driver needs to be configured for in-vehicle networking application. Similarly, several drivers like LIN BUS, FlexRay, PWM, SPI, and Ethernet have to be configured based on specific requirements of an automotive application.
The configuration of these drivers is carried out by using specialized tools for code generation and configuration.
Let’s understand the process of AUTOSAR MCAL driver development and configuration, in detail:
The following three steps are involved in this process:
- Configuration and Code Generation for AUTOSAR MCAL Drivers
- AUTOSAR MCAL Driver Development
- Testing and Validation of AUTOSAR MCAL Drivers
Let’s explore them!
- Configuration and Code Generation for MCAL Drivers: Configuration of MCAL drivers implies configuration of certain parameters associated with a particular MCAL driver. An example with help you understand better.A CAN MCAL driver needs to be configured with specific baud rates depending on the application. Here, the baud rate is the parameter that must be configured.
In order to carry out this configuration, the developers require the following files and tools:
- Parameter Definition File (PDF): This file consists of the parameters to be configured for the MCAL driver. This file contains the description of the parameters as well as their min and max values.PDF is created in .XML or .arxml format so that it can be accessed by the tools. In case of a CAN BUS Driver, the PDF will have the baud rate range of the driver.
- Configuration Tool: The PDF file is an input for the AUTOSAR configuration tool. As the tool is equipped with a graphical user interface (GUI), loading the PDF into it and subsequent configuration becomes easy.
- Code Generation Tool: The Code Generation Tool runs in the background of the Configuration Tool and is responsible for processing of Parameter Definition File (PDF).It is a Perl/Python script that takes in PDF as the input and gives Post Build and Pre Config source files (*_PBCfg.c / *_PBCfg.h and *_Cfg.h) as outputs. Another output, called the ECU description file is also generated.
Let’s analyze the outputs now!
- Configuration Source Files: These source files consist of structures with elements such as configuration values. These configuration files are generated based on the values specified in the Parameters Definition File. The configuration values need to be fed to the peripheral registers, address pointers, macro definition, etc.
- ECU Description Files: This file is similar to Parameter Definition File in terms of format (xml/arxml). The only difference is that the parameters stored in this file are already configured.In a scenario, where an AUTOSAR MCAL Driver development project is shared within different teams, ECU Desc file acts as an input to the Code Generation Tool.
In such cases, this tool is not a part of Configuration Tool.
- AUTOSAR MCAL Driver DevelopmentDriver Static Code is the core MCAL driver that enables access to the on-chip peripherals of the microcontroller.
The Driver Static Code file has an extension .c [dot c].
For example, the- driver static code for CAN BUS Driver will be CAN.c. Similarly, for a General Input/Output, it will be GPIO.c and so on.
This .c file along with the Configuration Source file (Obtained in Step1), together act as an AUTOSAR MCAL Driver, which is configured for a particular automotive application.
Driver Static Code is developed based on requirements specified in AUTOSAR MCAL Driver Software Specifications along with the Microcontroller Hardware Specification.
The AUTOSAR MCAL Driver Software Specification consists of every software requirement that needs to be met by the MCAL Driver. It consists of API details, parameters to be passed to the API and their return value.
Details like Data Types to be used and Configurable Parameters to be provided, can also be found in this specification.
Considering all these specifications, the Driver Static Code is developed.
- Source Code Testing and Validation of the AUTOSAR MCAL DriverThe validation of the MCAL Drivers is important to keep the bugs at bay. The validation process involves creating a test bench using an Integrated Development Environment (IDE) or a compiler.
The PDF, Configuration Source File and the Driver Static Code are tested in this Test Environment.
One important point to be noted here is that AUTOSAR BSW is required for scheduling of the MCAL Driver verification. In its absence, stub files need to be created that replicates AUTOSAR BSW with similar APIs.
Test Applications Files are written using the compiler or the IDE to test functions of the MCAL Driver Component.
For instance, a separate test application needs to be written for CAN Driver to test if the ECU communication is happening uninterrupted. Similarly, test applications for memory functions, Input/Output, etc. also needs to be written.
Conclusion
Different layers of AUTOSAR architecture are developed independent of each other and MCAL Drivers are no exceptions. This is how the required abstraction and thus the standardization is achieved.
MCAL Drivers also command a lot of importance, as they are the bridge between the upper layers of AUTOSAR architecture and the microcontroller unit.
Related Posts on AUTOSAR Software Development
- AUTOSAR Communication Stack (ComStack): Our AUTOSAR development team explains what are the different software modules of a Communication Stack (ComStack). Also, learn about the software modules of CAN based Communication Stack in AUTOSAR
- AUTOSAR Memory Stack (MemStack): Get introduced to the various software modules of AUTOSAR Memory Stack (MemStack) that provide basic memory management services to the upper layers. Our AUTOSAR development team shares the basics of AUTOSAR 3.0 and 4.0
- AUTOSAR Development partnership: Find out what is AUTOmotive Open System Architecture (AUTOSAR) development partnership and why OEMs, Tier-I suppliers, Semiconductor Vendors and Embedded hardware and software service providers collaborated to form this global partnership
