Make Your Product Automotive Ready with AutoSAR MCAL

A Note to Readers:

This blog belongs to  those who want to get their product for Automotive readiness, like  one of the characteristic functional safety (or) ASLI-D ( or) automotive standards. One of the automotive firmware products is AutoSAR.

AutoSAR is used for providing intrinsic advantages to the associates to handle more complex electrical and electronic systems in a vehicle like simple integration, switch the functions within complex engine control (ECU) network & to control over the lifecycle of the whole product.

We will move to a detailed description of the MCAL solution we developed at Adept Chips, which is now readily available for customers. AutoSAR is an advanced stage of Embedded Systems, so our readers are expected to have knowledge of Embedded Systems, C programming, layered Architecture, and communication protocols like CAN, I2C, SPI, ADC, GPT and LIN etc.

For the benefit of our readers, we will start with a simplified explanation of the AutoSAR Layered Architecture to show where exactly MCAL fits in.

Image 1 – AutoSAR Layered Architecture

Application Layer: This layer has the application code and it  at the top of the architecture. It can have different application blocks called  Software Components (SWCs) for each feature that the electronic control unit (ECU), needs to support according to its target application. For example,  power window and temperature measurement functions will have separate SWCs. This is not a norm and  depends on the Designer.

AutoSAR Runtime Environment  (RTE): This is one of the most significant layers in AutoSAR. It provides communication between different software components (SWCs) and between the electronic control units (ECUs). The Application layer uses RTE while communicating with other layers below using ports. For more information on RTE, read this article.

Services Layer: This layer provides different services for applications. Services such as  System Services, Memory Services, Crypto Services, Off board communication services, Communications services.

ECU Abstraction Layer: This layer provides ECUs with  related abstractions. It includes different abstracted layers like I/O hardware abstraction layer, On-board device abstraction, Memory hardware abstraction, Crypto hardware abstraction, etc. that enable  applications hardware to become independent.

Image 2: Applications of AutoSAR

 

The architecture of AutoSAR MCAL and Different Device Drivers of AutoSAR MCAL Module. Their benefits.

The Abstraction layer with direct access to the On-chip MCU peripheral modules is MCAL (Microcontroller Abstraction Layer). MCAL is a software module with direct access to every MCU peripheral module on-chip and all external devices mapped to memory. Here, the upper software layers such as the Basic software layer, BSW, Application Layer are independent of the MCU.

We will then move to a detailed description of the MCAL solution we developed at Adept Chips, which is now readily available for customers. AutoSAR is an advanced stage of Embedded Systems, so our readers are expected to have knowledge of Embedded Systems, C programming, layered Architecture, and communication protocols like CAN, I2C, SPI, ADC, GPT and LIN etc.

Image 3 – MCAL Driver

MCAL Driver:

MCAL includes a variety of software modules designed to cater to a particular purpose. Each software module has its corresponding on-chip peripheral function. For example, the CAN Driver guarantees that the MCU can receive and transmit CAN messages. The Microcontroller Abstraction Layer (MCAL) of AutoSAR architecture must be developed independently according to the hardware. This is a laborious and tedious process. With the AutoSAR and MCAL package, SoC providers can improve their efficiency, accelerate their speed and lower their effort while developing MCAL to build a robust business model.

What is AutoSAR MCAL?

In the context of embedded software, MCAL is a software module with direct access to every MCU peripheral module on the chip and external devices mapped to the memory. It offers an advantage of the layered architecture of the AutoSAR compliant design.

Development and Configuration of AutoSAR MCAL

Now comes the Microcontroller Abstraction Layer. It has drivers used by the above layers to communicate with Microcontroller hardware peripherals.

Now that we know where MCAL sits, let’s move to the development and configuration process. Essentially, there are three steps involved in this process, and they are

• Configuration and code generation for AutoSAR MCAL Drivers
• AutoSAR MCAL Driver Development
• Testing and Validation of AutoSAR MCAL Drivers

 

Detailed about our AutoSAR MCAL Driver Development ?

Our AutoSAR software developers have in-depth expertise and project experience in AutoSAR MCAL driver development. We understand how microcontroller drivers such as GPT driver and MCU driver, communication drivers like CAN, LIN, FlexRay and MOST and I/O drivers like ICU, PWM, ADC, Flash, and EEPROM are developed. Our AutoSAR software development team has collaborated with customers to develop static files of the microcontroller driver and the AutoSAR MCAL driver configuration. Driver Static Code is the core MCAL driver that enables access to the on-chip peripherals of the microcontroller.

 

Image 4 – MCAL Driver development WorkFlow

 

MCAL Driver development WorkFlow:

• The Driver Static Code is developed according to AutoSAR Specifications and the MCU user manual.
• Driver Static Code + Configuration Source File = MCAL Drivers.
• This .c file and the Configuration Source file (Obtained in Step1) act as an AutoSAR MCAL Driver configured for a specific automotive application.
• Driver Static Code is developed based on the AutoSAR MCAL Driver Software Specifications and the Microcontroller Hardware Specification.

Testing and Validation of AutoSAR MCAL Drivers

The validation of the MCAL Drivers is essential while trying to avoid bugs. This process creates a test bench using an Integrated Development Environment (IDE like Eclipse) or a compiler. The Configuration Source File and the Driver Static Code are tested in this Test Environment. Test Applications Files are written with the compiler or the IDE to test functions of the MCAL Driver Component.

• MCAL driver source files
• IDE or Compiler for creating test applications
• A simple Scheduler and Stubs (to replicate BSW) for making calls to and from test applications.

Image 5 – Testing and Validation

 

Generating Code from GUI Tool

These configuration files are generated per the values specified in the Parameters Definition File. Following are the steps to create a configuration file for all the peripheral modules using a GUI Tool:

• Parameter Definition File (PDF): This file includes configurable parameters for the MCAL driver. It contains a description of the parameters and their minimum and maximum values. A PDF is created in .xml or .arxml format to enable access by the tools. In the case of a CAN BUS Driver, the PDF will have the baud rate range of the driver.
• Configuration Tool: The PDF is considered an input for the AutoSAR configuration tool. This tool comes with a graphical user interface (GUI), which loads the PDF and makes the configuration easy.
• Code Generation Tool: The Code Generation Tool runs in the background of the Configuration Tool. Its responsibility lies in processing the Parameter Definition File (PDF). It is a Perl/Python script that takes PDF as the input and gives Post Build and Pre Config source files (*_PBCfg.c / *_PBCfg.h and *_Cfg.h) as outputs. It also generates another output, known as the ECU description file.

Image 6 – Configuration and Code Generation for AutoSAR MCAL Drivers

 

Image 7- Graphical Interface For Configuration

 

Supported Platforms : Windows, Linux

Verifying Designs and Code

Products support hand code and generated code. These codes enable you to ensure zero run-time errors and enforce coding rules. In addition, they check for security vulnerabilities by using standards such as the coverity tool.

Supporting Standards

Use Embedded Coder to generate code that complies with popular software and safety standards such as AutoSAR, MISRA C, and other industry standards for automotive and aerospace embedded systems.

Hardware Support

Quickly generate code and compile it for your hardware no matter what your application does, ranging from signal processing, computer vision, image processing, or control systems.

Generate code and prototype it on embedded platforms such as Aurix TC399,  Zynq UltraScale+MPSOC or Xilinx. On automotive platforms, integrate the generated code into your application and run it on a custom board, or include accessing onboard sensors such as the video camera, microphone, radar, temperature and accelerometer. Finally, deploy your embedded system to powerful microprocessors.

Challenges of building a high performance hardware/software platform

There are many challenges to building a high-performance hardware/software platform. Firstly the system needs sufficient sensors like a camera, Radar and Lidar. Secondly, the system needs high-speed communication to make decisions at a speed proportional to the target speed of the vehicle. Finally, the system also needs multiple parallel hardware to handle many objects that the vehicle encounters in its path.

All the systems need to work together and smoothly to guide the vehicle in any situation at a stipulated time, making it a highly challenging system.

What Adept Chips did to solve this

We have built a high-performance platform that has paved the way for a fully autonomous system. A high-performance platform with sufficiently high-speed communication and sensors can help achieve an autonomous driving system that processes all the plausible scenarios of the vehicle so that it either meets or exceeds human driving intelligence.

We have designed and developed an AutoSAR MCAL component for migration to the new hardware platform. It supports customized configuration and code generation using the GUI tool.

Conclusion

Once the MCAL drivers are available, every user application/feature for the SOCs must be independently developed in the AutoSAR environment.

Those interested can obtain a complete work package with technology expertise and process know-how from us for elevating any SOCs to automotive-ready ECUs or MCUs. Including assistance in gaining certifications for Automotive functional safety standards