What's AUTOSAR and MCAL?

 

What is AUTOSAR and MCAL?

 

Introduction

      AUTOSAR(AUTomotive Open System ARchitecture) which is a global development partnership, was started in 2003. It is a open architecture which enables OEMs to reduce the development time for ECUs by the use of configuration over code development.The objectives are scalability to different vehicle and platform variants, transferability of software, consideration of availability and safety requirements, cooperation between different partners, sustainable use of natural resources and maintainability during the product lifecycle.The philosophy of AUTOSAR is to collaborate on the development of the standard and compete on the implementation.

        AUTOSAR follows a layered approach to software development with the complete software split into multiple layers such as Application layer(SW-Cs), Runtime environment (RTE) and the Basic software (BSW).  

     MCAL(Micro-Controller Abstraction Layer) is a layer present as part of the AUTOSAR BSW(Basic Software) for automotive ECU software architecture  with the intention of separating the hardware dependent part of the ECU software.

How are MCAL drivers different from other drivers?

        The AUTOSAR architecture uses a layered approach to developing software and as per this standard, the layer closest to the hardware has been termed as the MCAL layer. In addition to the MCAL, the services layer, the ECU Abstraction layer and the MCAL layer together constitute the BSW (Basic Software).

 

          So I know what you might be thinking. How exactly is the MCAL different from other drivers?

        The answer to that lies in the AUTOSAR specification for the MCAL layer. AUTOSAR is an open-source architecture with the specification and all relevant documents available at www.autosar.org and can be freely downloaded.

 

          

        AUTOSAR offers official documentation that enables developers to create any part of the Basic Software (BSW), including the MCAL, in line with its standards. Twice a year, AUTOSAR releases its Software Specification (SWS) documents — at the time of writing this blog, the latest was R24-11. These MCAL SWS documents give developers precise details such as the names of APIs, required parameters, and the intended functionality of each driver, ensuring consistent and interoperable software development across the ecosystem.

 What are the benefits of this standardization?

        Standardizing APIs ensures that MCAL drivers, once developed, can be reused not only across multiple customer projects for the same OEM but also with different BSW stacks from various vendors. This eliminates the need to redevelop or heavily modify drivers for each new project, significantly shortening development cycles. For software integrators, it reduces the complexity and time needed to integrate different components. Overall, this faster development and smoother integration accelerate time-to-market and deliver substantial cost savings for OEMs.

        Is it as simple as this? Well not to be a pessimist but there are technical challenges in developing a MCAL driver.

 Challenges in MCAL driver development

   In AUTOSAR, the concept of drivers with APIs is similar to traditional development—application developers call these APIs and pass parameters to perform certain functions.

        The difference lies in the MCAL configuration process. Before the code even                runs,  many aspects of the driver’s behavior—such as hardware pin mappings, clock settings, interrupt priorities, and peripheral initialization—are defined in configuration files generated by AUTOSAR tools (using ECU Configuration Descriptions). These configurations are compiled into the code, meaning the driver’s runtime parameters are partly fixed in advance.

This approach reduces manual coding, ensures consistency across projects, and allows OEMs and suppliers to reuse the same driver binaries across different ECUs simply by changing the configuration.

        So the two sides to MCAL development are the configuration of the MCAL(dynamic) and the development of the MCAL driver code(static). The configuration of the MCAL is done using a MCG (Module Configuration Generator). This is a tool which is used to configure the MCAL and which then generates a configuration which acts as an input to the MCAL static code to enable the driver to then configure the hardware according to the specified configuration generated during the configuration process. 

        So what is so hard about this? Well a couple of questions to ponder about before I provide the answer. The first one. Is the configuration same across multiple hardware platforms? Is the configuration specified in the SWS? 

        The answer to both the questions is again Yes and No. This is the answer most of the AUTOSAR experts will give when asked such questions about the MCAL driver layer. Yes since most of the configurations will be the same across multiple hardware platforms. No since some of the configurations can be hardware specific.

        As an example let us consider PLL configuration of the controller. AUTOSAR provides a SWS document specifying the functionality of the Mcu driver but stops short of specifying how the PLL should be configured or how many of them should be configured. The crux of the matter lies in how many PLLs is the Mcu driver supposed to configure? What elements of the PLL is the driver supposed to configure? Since the SWS has to be a generic document the configuration elements and the number of PLLs to be configured is left to the discretion of the developer and the system designer. After all the system designer is the best person to determine if a certain PLL should be configured or not.

        Coming to the second question as to whether AUTOSAR specifies the configuration elements for the second question, yes it does but again stops short of specifying any hardware specific parameters and again it is the job of the module designer to determine if certain parameters should be included in the configuration.

        Further each driver on a particular hardware platform, with the keyword being hardware platform, has its own idiosyncrasies and as such the AUTOSAR SWS is a merely a guideline which provides the information to the developer about how a certain driver works and how the API development has to be done.

        Deviation from the SWS is allowed only for hardware specific features and implementing or not implementing a feature used by the BSW (layers above the MCAL) is strictly forbidden. It has to be implemented since the SW may not behave as expected once deployed along with the application.

Complex device drivers

        Does AUTOSAR provide the specification for all drivers? What if there is a driver which is not a part of the AUTOSAR MCAL specification? 

        Well, AUTOSAR has also provided support for this as well. The complex device drivers (CDD as per AUTOSAR terminology) are also a part of the AUTOSAR architecture and a guideline is available for developing and integrating a driver, which does not need to conform to the AUTOSAR standard, into the BSW. As such the developer is free to design and develop their own driver with the APIs, parameters and functionality for the APIs according to their choice

Sophon’s expertise

        Sophon Technologies has successfully developed and delivered MCALs for multiple hardware platforms for various chip vendors such as NXP’s MPC57XX family of controllers, ST's STM32 family of controllers and many more.

        Sophon Technologies has successfully developed drivers for Mcu, Port, Dio, Spi, Can, Can-FD, Lin, Ethernet, Pwm, Gpt, Adc modules as per the AUTOSAR specification using various configuration tools such as Elektrobit's EBTresos, Vector Informatik's DaVinci Configurator Pro.

        Further Sophon Technologies also provides support during integration and qualification testing of the MCAL drivers into the BSW.

         If you have any requirements do get in touch with us through our website www.sophontech.in.