Extracting MCAL Parameters from ECU Configuration (ARXML)

1. The Language of AUTOSAR Configuration: ARXML

In AUTOSAR, all configuration information—from the system-level signal definitions down to the bit-timing of an MCAL SPI driver—is described using a standardized XML-based format called ARXML. Think of it as the comprehensive database for an entire automotive project.

There isn't just one single ARXML file; rather, it's a collection of files, each with a specific purpose in the development workflow. Understanding these types is key to knowing where to look for certain information.

To summarize the workflow described in the video:

1. The OEM defines the entire vehicle network in a System Configuration Description.
2. This is split into ECU Extracts, one for each ECU, which are given to Tier-1 suppliers.
3. The Tier-1 engineer imports this ECU Extract into a configuration tool (like Vector DaVinci or EB Tresos). The tool then uses the information from the extract to pre-fill many parameters and creates the ECU Configuration Description.

It is this ECU Configuration Description file (often named EcuC.arxml or similar) that contains the specific parameter values for all the BSW modules, including our target, the MCAL drivers.

2. Anatomy of an ECU Configuration ARXML

Now, let's look inside an ECU Configuration file to see how MCAL parameters are actually stored. At its core, it's a structured text file that you can open with any text or XML editor.

The structure follows a standard XML hierarchy. When you're looking for MCAL parameters, you'll typically navigate through these key tags:

• <AUTOSAR>: The root element of any ARXML file.
• <AR-PACKAGES> -> <AR-PACKAGE>: These are used to group and organize the contents, much like folders in a file system.
• <ELEMENTS>: This tag holds the main configuration descriptions.
• <ECUC-MODULE-CONFIGURATION-VALUES>: This is a critical tag. There will be one of these for each BSW module (e.g., Can, Port, Mcu, Dio). This is how you find the configuration for a specific driver.
• <CONTAINERS> -> <ECUC-PARAMETER-VALUE-CONTAINER>: Within a module's configuration, parameters are grouped into logical containers. For example, in a Port module configuration, you would find a container for each physical port pin being configured.
• <PARAMETERS>: This holds the actual parameter settings for a given container.
• <ECUC-NUMERICAL-PARAMETER-VALUE> / <ECUC-TEXTUAL-PARAMETER-VALUE>: These tags hold the final value of a specific parameter, like 101 for a Pin ID or PORT_PIN_OUT for its direction.
• <DEFINITION-REF>: This is a very important tag. It's a reference that links a value back to its formal definition, which is stored in a separate BSW Module Description (BSWMD) file. The BSWMD file defines what a parameter is, its data type, its valid range, and a description of its purpose.

So, the workflow for analyzing a parameter is:

1. Find the module configuration (ECUC-MODULE-CONFIGURATION-VALUES).
2. Navigate to the correct container (ECUC-PARAMETER-VALUE-CONTAINER).
3. Find the parameter value.
4. Use its <DEFINITION-REF> to understand its meaning and constraints.

3. From GUI to ARXML: A Practical Example

You will rarely edit ARXML files by hand. Instead, you'll use a graphical configuration tool. However, understanding how the GUI settings translate to ARXML is crucial for debugging, scripting, and integration.

Let's look at a real-world example from a vendor's integration guide. We'll examine the configuration for the Dio (Digital I/O) driver.

Let's break down how the configuration shown in the guide maps to ARXML:

1. Module: The entire "DIO Configuration" corresponds to an <ECUC-MODULE-CONFIGURATION-VALUES> section where the <DEFINITION-REF> points to the Dio module definition.
2. Container: In the guide, you see a DioPort container is added with a DioPortId of 6. In the ARXML, this would be represented as:

   <CONTAINERS>
     <ECUC-PARAMETER-VALUE-CONTAINER>
       <SHORT-NAME>Dio_PG</SHORT-NAME> <!-- Corresponds to the 'Name' in the GUI -->
       <DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/AUTOSAR/Dio/DioConfig/DioPort</DEFINITION-REF>
       <PARAMETERS>
         <ECUC-NUMERICAL-PARAMETER-VALUE>
           <DEFINITION-REF DEST="ECUC-INTEGER-PARAM-DEF">/AUTOSAR/Dio/DioConfig/DioPort/DioPortId</DEFINITION-REF>
           <VALUE>6</VALUE>
         </ECUC-NUMERICAL-PARAMETER-VALUE>
       </PARAMETERS>
       <!-- ... more containers inside, like for DioChannel ... -->
     </ECUC-PARAMETER-VALUE-CONTAINER>
   </CONTAINERS>
   

3. Parameter: Inside that container, a DioChannel is added named Dio_Led2 with DioChannelId = 6. This becomes another nested container with its own parameters.

This hierarchical structure of Module -> Container -> Parameter is fundamental to all BSW configuration.

<ECUC-PARAMETER-VALUE-CONTAINER>
  <SHORT-NAME>PortPin_LED_RED</SHORT-NAME>
  <DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/AUTOSAR/Port/PortConfigSet/PortPin</DEFINITION-REF>
  <PARAMETERS>
    <ECUC-NUMERICAL-PARAMETER-VALUE>
      <DEFINITION-REF DEST="ECUC-INTEGER-PARAM-DEF">/AUTOSAR/Port/PortConfigSet/PortPin/PortPinId</DEFINITION-REF>
      <VALUE>42</VALUE>
    </ECUC-NUMERICAL-PARAMETER-VALUE>
    <ECUC-TEXTUAL-PARAMETER-VALUE>
      <DEFINITION-REF DEST="ECUC-ENUMERATION-PARAM-DEF">/AUTOSAR/Port/PortConfigSet/PortPin/PortPinDirection</DEFINITION-REF>
      <VALUE>PORT_PIN_OUT</VALUE>
    </ECUC-TEXTUAL-PARAMETER-VALUE>
  </PARAMETERS>
</ECUC-PARAMETER-VALUE-CONTAINER>

4. An Important Detail: Configuration Classes

Not all parameters are handled the same way. AUTOSAR defines Configuration Classes that determine when a parameter's value is bound to the software. This is an advanced topic often discussed in interviews.

The main classes are:

• Pre-compile time: The parameter's value is used during code generation to create #define macros in header files or to enable/disable code blocks with #if/#endif. To change the parameter, you must regenerate the code and recompile the module. Most MCAL performance and safety-critical parameters (like clock settings, pin modes, API enabling/disabling) are pre-compile.
• Link time: The parameter's value is resolved during the linking stage. This is less common for MCAL drivers.
• Post-build time: The parameter's value is stored in a data structure (often a const struct in Flash) that the driver code reads during initialization (_Init() function). This allows you to change the configuration without recompiling the source code, which is useful for creating a single executable that can be used on slightly different hardware variants. For example, CAN message IDs are often post-build configurable.

For MCAL, the vast majority of parameters are pre-compile because they define fundamental hardware properties that the code must be built against.

Interview Corner

Q1: What is the primary role of an ECU Configuration Description (ARXML) file in an AUTOSAR project?
A: The ECU Configuration Description contains the specific parameter values for all the Basic Software (BSW) modules for a single ECU. It's the output of an AUTOSAR configuration tool and is used by code generators to produce the C header files (.h) and source files (.c) that tailor the BSW, including the MCAL drivers, to the specific requirements of the project.

Q2: You need to configure the system clock to 80 MHz and set up the CAN controller's baud rate. In which AUTOSAR file would you expect to find the final parameter values that the code generator will use?
A: You would find these values in the ECU Configuration Description file (EcuC.arxml or similar). Specifically, you would look inside the <ECUC-MODULE-CONFIGURATION-VALUES> for the Mcu driver to find clock configuration parameters, and inside the one for the Can driver to find the baud rate settings.

Q3: Explain the typical workflow involving the System Configuration, ECU Extract, and ECU Configuration files.
A: The workflow usually starts at the OEM, who defines the entire vehicle network in the System Configuration Description. This file describes all ECUs, their communication relationships, messages, and signals. The OEM then generates an ECU Extract for each specific ECU, which is a subset of the system configuration relevant only to that ECU. This extract is given to the Tier-1 supplier. The Tier-1 engineer imports this ECU Extract into their configuration tool. The tool uses it as an input to create the ECU Configuration Description, where the engineer configures all the BSW parameters, including the MCAL drivers, for that specific ECU.

Q4: When analyzing an ARXML file, you find a parameter <VALUE>1</VALUE>. How would you determine what this parameter actually does?
A: The <VALUE> tag by itself is just a number. To understand its meaning, I would look for the associated <DEFINITION-REF> tag within the same parameter block. This reference points to the formal parameter definition in a BSW Module Description (BSWMD) file. The definition provides the parameter's symbolic name (e.g., CanControllerBaudRate), a detailed description, its data type (integer, enum, etc.), and its valid range or possible values.

Q5: What is the difference between a pre-compile and a post-build configuration parameter, and why are most MCAL parameters pre-compile?
A: A pre-compile parameter is resolved before compilation; its value is typically used by a code generator to create #defines in a header file. Changing it requires recompiling. A post-build parameter is read by the code at runtime from a data structure in memory. Changing it only requires modifying that data structure, not recompiling the code. Most MCAL parameters, such as clock tree configuration, peripheral modes, and pin functions, are pre-compile. This is because they define fundamental hardware behaviors that are deeply embedded in the driver's logic and timing. The generated code must be optimized and built specifically for these static hardware settings to ensure correctness, safety, and performance.

Conclusion

Today, we've demystified the ARXML format and learned how to navigate it to find the configuration parameters that drive our MCAL modules. This is the "source of truth" for the entire BSW stack.

Key Takeaways:

• ARXML is the standard format for all AUTOSAR configuration data.
• The ECU Configuration Description file contains the parameter values for all BSW modules on a specific ECU.
• ARXML files have a clear hierarchical structure: Module -> Container -> Parameter.
• A parameter's meaning is defined by its <DEFINITION-REF>, which links to a formal definition.
• MCAL parameters are typically pre-compile time, meaning they are baked into the generated code for maximum performance and safety.

Next Lesson Preview:
We now understand what the MCAL is and how it's configured. In our next lesson, we will take the final step and see how this configuration is used in practice. We will begin to Implement core functionality for the AUTOSAR Port and Dio drivers based on a configuration structure. This is where we'll start connecting configuration data to C code, moving closer to hands-on driver implementation.