The Basics of A2L Files

Micael Coutinho,Wed Nov 09 2022 • autosar calibration a2l

Why are A2L Files Used in ECU Development and Their Contents

If you start digging in the industry, soon you'll stumble upon A2L files, as they play their part in ECU development. But, what are they? They, are specified by the ASAM (Association for Standardization of Automation and Measuring Systems) MCD-2 MC standard, where MCD stands for Measurements, Calibration, Diagnostics systems.

The A2L file role is to provide a description of internal ECU data and how to access it, through calibration tools (for example, from Vector). So, it allows you to access some parts of the memory in your ECU through a communication protocol (CAN, FlexRay, unfortunately not with LIN) by making use of the XCP Autosar module and the information it has on the addresses of variables. So, A2L and XCP are usually bound together, and sort of depend on each other. To learn more about XCP, we recommend you to consult the article XCP Module Overview (coming soon), as the A2L functionalities will make way more sense.

So, let's start with the file structure. For that, we took the examples available on the standard website, which provdes a pretty good example of an A2L file for us to start with. But there is just a tiny problem: the file contains almost 6000 lines, and I don't see how that's simple for a beginner. So, we will take a look at the file by chunks. The bare minimum, the skeleton of the A2L file will look like this, and we'll use {description} as a means to keep the example as concise as possible. So, this is the only part of the syntax which is not correct for an A2L:

  ASAP2_VERSION 1 71
  /begin PROJECT ASAP2_Example ""

    /begin HEADER "ASAP2 Example File"
      VERSION "V1.7.1"
      PROJECT_NO P2016_09_AE_MCD_2MC_BS_V1_7_1_main
    /end HEADER

    /begin MODULE Example ""
      /begin A2ML
        {A2ML description}
      /end A2ML

      /begin MOD_COMMON ""
        {MOD_COMMON description}
      /end MOD_COMMON

      /begin IF_DATA XCP 
        {IF_DATA description}
      /end IF_DATA

      /begin MOD_PAR ""
        {MOD_PAR description}
      /end MOD_PAR

      {description of the remaining blocks}

    /end MODULE
  /end PROJECT

There we go! Better than 6000 lines, for sure. Now, let's refer to this small table to know what these blocks mean:

Block	Description
ASAP2_VERSION	Version of the ASAP2 standard. Necessary due to the introduction of new blocks, which will not be retro-compatible
PROJECT	Root keyword that contains everything
HEADER	Number of the ECU and Software version which the A2L file is compatible with
MODULE	Encapsulates the data description
A2ML	A2ML description. Defines the syntax of the protocol between the MC-System and the ECU
MOD_COMMON	Defines default parameters that are common for other keywords, so they don't have to be repeated, such as byte alignment and order
IF_DATA	Configuration of the communication between the ECU and the MC-System. Contain mainly the Xcp configuration and the underlying protocol (e.g. CAN)
MOD_PAR	Specifies the general parameters of the ECU, most importantly, the memory segments (RAM, ROM), available to your MC-System

What about the remaining blocks? Well, let's just see the essentials with a bit more description.

A measurement is a variable, located in the RAM of your ECU and can be configured to be measured regularly in your MC-System through XCP. It contains the name of the measurement, a small description, its data type, the reference to a COMPU_METHOD, resolution, accuracy, lower and upper limits, the address on the ECU to which corresponds the variable (usually accompanied by a SYMBOL-LINK parameter, the reasons being stated here, in the article How to Create an A2L File, coming soon), the format which will be used to display the variable in the MC-System, and the display identifier, also used to display in the MC-System.

  /begin MEASUREMENT ASAM.M.SCALAR.UBYTE.IDENTICAL
    "Scalar measurement"
    UBYTE CM.IDENTICAL 
    0 
    0 
    0 
    255
    ECU_ADDRESS 0x13A00
    FORMAT "%5.0"    /* Note: Overwrites the format stated in the computation method */
    DISPLAY_IDENTIFIER DI.ASAM.M.SCALAR.UBYTE.IDENTICAL    /* optional display identifier */
  /end MEASUREMENT

A compu-method is a conversion (either through a mathematical formula, or a name, in case it references a COMPU_TAB) used to display the variable referenced by it in a nicer way for the user.

  /begin COMPU_METHOD CM.IDENTICAL
    "conversion that delivers always phys = int"
    IDENTICAL "%3.0" "hours"
  /end COMPU_METHOD

A characteristic is (usually) a constant value that you can manipulate. It has a common ground with measurements when it comes to parameters. The main differences are the type of tunable parameter (scalar value, in this case, but it can be a string, curve, map, and so on) and a record_layout reference.

  /begin CHARACTERISTIC ASAM.C.SCALAR.UBYTE.IDENTICAL
    "Scalar FW U16 and CDF20 as name"
    VALUE 
    0x810000 
    RL.FNC.UBYTE.ROW_DIR
    0 
    CM.IDENTICAL  
    10 200
    DISPLAY_IDENTIFIER DI.ASAM.C.SCALAR.UBYTE
  /end CHARACTERISTIC

A record_layout describes how a tunable parameter (characteristics, axis_pts) are stored in the memory, with information on byte alignment, order and so on.

  /begin RECORD_LAYOUT RL.FNC.UBYTE.ROW_DIR
    FNC_VALUES 1 UBYTE ROW_DIR DIRECT
  /end RECORD_LAYOUT

These are the very essential blocks, just to get you started on your calibration adventures. Lastly, I want you to remember that there is more. Although we got most of the basics down when it comes to A2L files, I encourage you to explore more, either from reading the standard or our article on How to Create an A2L File (coming soon), which works as a good follow-up to this one, by teaching you how these files can be created in the development process.

Author: Micael Coutinho (opens in a new tab)

References:

ASAM MCD-2 MC standard (opens in a new tab)