MCAL development using Elektrobit's EBTresos MCG

 

Introduction

        In my previous blog I have talked about what the open architecture AUTOSAR is and how it helps OEMs in rapidly developing and deploying their solutions. I have also covered the role of MCAL as the layer closest to the HW and which interacts with the HW directly. We have also understood that any module in the BSW consists of a static code and a generated configuration. The configuration is generated using a MCG(Module Configuration Generator) tool. In this blog we look at how we can use 2 of the most commonly used MCG tools viz. Elektrobit's EBTresos and Vector Informatik's DaVinci Configurator Pro to develop the MCAL.

Development of the MCAL as a EBTresos plugin

Identifying the configuration parameters

        The process of developing a MCAL for any tool begins with identifying the different containers and the configuration parameters which are under the specific containers. The process of identifying the configuration parameters involves in defining the standard configurations as defined by AUTOSAR SWS(Software Specification) and the Vendor specific configuration. The process of identifying the vendors specific configuration involves understanding the peripheral for which the MCAL is being developed and then providing a configuration for it if required. These two configurations combined is known as the module configuration. The AUTOSAR configuration for the module is available from the www.autosar.org website and can be downloaded as an arxml(AUTOSAR XML) file. 

I have provided an example parameter for a Can MCAL. 

     The name of the parameter is CanRxProcessing and it Enables / disables API Can_MainFunction_Read() for handling PDU reception events in polling mode. Although not mentioned above this parameter is part of a container called CanController. Further details about the parameter are also mentioned in the XML file such as the lower multiplicity and upper multiplicity which indicate the minimum and maximum number of parameters which the particular container can have. The XML also mentions the different values the parameter can have viz. INTERRUPT, MIXED and POLLING as the parameter is of a enumeration type. 

Generation of the XDM file

        Once the parameters have been identified and a XML file generated with all these parameters it is necessary to generate the XDM file from the XML file. EBTresos provides a utility using which it is possible to convert the XML file to a XDM file. The XDM file contains essentially the same data as present in the XML file but in a different format. This XDM file is then used by the EBTresos tool to generate the GUI in the MCG using which the user can configure a value for the parameter and then generate a configuration from it.

Create a plugin folder

        The EBTresos tool requires that the MCAL be developed as a plugin which can be read by the MCG tool and then the module is presented to the user who will configure the module in the MCG. 

An example plugin folder is shown below.

  

Explanation for each of these artifacts in the plug-in are provided below 

Files

anchors.xml and plugin.xml file contains metadata which is read by the MCG tool.

Folders

autosar  - contains the XML file which contains the parameter definitions for the MCAL

config - contains the XDM file which contains the parameter definitions for the MCAL

doc - contains the documentation for the MCAL

generate_PB - contains the template used for generating the Post-Build configuration for the MCAL

generate_PC - contains the template used for generating the Pre-Compile configuration for the MCAL  

generate_swcd - contains the template used for generating the SWCD(component description) for the MCAL

include - contains the source headers for the MCAL

META-INF - contains meta-data information about the MCAL

src - contains the source code for the MCAL 

Configuration Template Creation

        As per the AUTOSAR principle the configuration has to be generated for the MCAL. Since the methodology for AUTOSAR is a template based generator, it is necessary to create a template which will be used by the MCG to generate the configuration which acts an an input to the static code of the MCAL and which enables it to configure itself and provide the expected functionality. Elektrobit's has developed it's own language using which this template based code files can be created by the MCAL developer.

Code development

        The code for the MCAL can be developed as per the SWS document. The SWS document provides a list of APIs which are required for the MCAL and also the functionality for each of these APIs is clearly documented in the SWS document. As per this info the static code for the MCAL can be developed.

Conclusion

        In conclusion this blog provides a short explanation about the steps involved in developing a MCAL plug-in for EBTresos. We have not covered in any detail if the required MCAL has to be ASIL compliant. That is a blog topic in it's own. 

        Sophon Technologies has the expertise to develop MCALs for any SoC, micro-controllers used in the automotive industry.  

        Sophon Technologies has already successfully developed drivers for Mcu, Port, Dio, Spi, Can, Can-FD, Lin, Ethernet, Pwm, Gpt, Adc modules as per the AUTOSAR specification.

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

Comments

Post a Comment

Popular posts from this blog

What's AUTOSAR and MCAL?

Image
  What is AUTOSAR and MCAL?   Introduction        AUTOSAR ( AUT omotive O pen S ystem AR chitecture) 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).     ...
Read more

Application of the ISO26262 Functional Safety standard for MCAL development

  Introduction      In my previous blogs we have talked about AUTOSAR and MCAL and briefly about how to develop a plug-in for Elektrobit's EBTresos. In this blog we will talk about how to apply the ISO26262 FuSa(Functional Safety) standard when developing a MCAL.         The ISO26262 standard, which is based on IEC61508, is a risk-based safety standard where the risk of hazardous operational situations is qualitatively assessed and safety measures are defined to avoid or control systematic failures and to detect or control random hardware failures, or mitigate their effects.      Goals of ISO 26262: Provides an automotive safety lifecycle (management, development, production, operation, service, decommissioning) and supports tailoring the necessary activities during these lifecycle phases. Covers functional safety aspects of the entire development process (including such activities as requirements specification, design, ...
Read more