Pagetree

ASAM MCD-2 MC (aka ASAP2) defines the description format of the internal ECU variables used in measurement and calibration. Measurement & calibration systems (MC-systems) require this description for both the parameterization of scalar constants, curves and maps of the ECU software and for recording the system's response via measurement variables during real-time testing. The description contains information about data types, dimensions, record layouts and memory locations of ECU variables. The standard also describes how the variable values are converted into human-readable quantities and displayed in an MC-system.

The support for automotive-specific processes and working methods is one of the major strengths of ASAM MCD-2 MC. The standard defines extensive support for lookup tables (up to 5 dimensions) with static or calculated axis points and static, measured, or calculated calibration parameters.  Calibration and measurement variables can be hierarchically grouped via various means to support function-oriented calibration.

The standard allows to fully specify how data is displayed in an MC-system, independent from ECU-internal data formats. The data description is achieved via computation methods, format definitions and the definition of units. This approach has the advantage that calibration engineers can work with data formats that are understandable and meaningful to them. The standard furthermore allows the description of the memory segments in the ECU, including the description of their location inside the address space, the type of memory, and the access method.

The standard also describes the device interface between the MC-system and the ECU for read and write access. As a result, the ASAM MCD-2 MC description contains all information in one place for access, modification, interpretation, and display of ECU-internal variables.

The data description is written in a structured ASCII format (*. a2l), which can be easily parsed and imported. The BOM mechanism (byte order mark) permits the use of the UTF-8 character set. Include statements collect descriptions from different sources. The standard is technology and vendor independent. Due to its completeness, versatility, and maturity, the standard is widely used and supported by virtually all major MC-systems on the market today.

Datasheet
TitleData Model for ECU Measurement and Calibration
CategoryAE

Current Version

1.7.0
Release Date26.02.2015
DownloadASAM MCD-2 MC V1.7.0
Application Areas
  • Calibration of ECU parameters

  • Measurement of ECU variables

  • ECU programming

Specification Content

  • Programmers guide

  • Data model

  • Interface description

File Formats

a2l, aml

 

History

The first version of the standard was developed before the foundation of ASAM e.V. in 1994.  The initial name of the standard was "ASAP-2", which was later changed to ASAM MCD-2 MC. The standard belongs to a group of coordinated standards, which are part of a 3-layer  base architecture for MCD-systems (Measurement, Calibration, Diagnostics).

ASAM MCD-2 MC includes the description of internal ECU data (characteristics and measurements) and the ECU interface (how to access characteristics and measurements) in one file. This inclusion was a deliberate decision to keep all information to describe and access ECU data in one location. Furthermore, ASAM MCD-2 MC describes a very compact ASCII format. When XML became popular in the industry in the early 2000s, the standardization group deliberately did not migrate ASAM MCD-2 MC to an XML-compatible format. Using XML would have otherwise increased the file size by approximately five times, which would have caused severe performance issues with tools that process such files. Furthermore, many tools in the Automotive industry relied already on the non-XML format and would have had to be re-written from scratch - an effort that was deemed to be unjustified.

ASAM MCD-2 MC v1.6 introduced UTF encoding for the A2L-file to support non-European languages (such as Japanese or Chinese), 4- and 5- dimensional data objects to extend curves, maps and cuboids, 64-bit integer data types, layouts for measurement objects and more keywords.

With version 1.7, ASAM introduced the definition of structured data types to the standard. Calibration tools can now show measurement variables and calibration parameters as part of a data structure. Furthermore, the standard introduced the definition of BLOB (binary large object) as a new object type to handle unstructured data blocks. A new transformer concept allows to convert complex, internal data structures into physical values by calling an external DLL. Those new additions to the standard support calibration and measurement of AUTOSAR-compliant ECUs.

Main contributors to the standard are Continental Automotive GmbH, dSPACE GmbH, ETAS GmbH, M&K GmbH, Robert Bosch GmbH, Softing AG and Vector Informatik GmbH.

Motivation

The calibration of parameters is an essential part of ECU software development. Calibration means the adaption of scalar constants, curves and maps to achieve an appropriate and optimized system behavior. Once a new set of parameters has been determined, the next development step is to run tests in order to evaluate the effectiveness of the calibration. For this purpose, internal variables are read from memory and transferred to a system that displays the data in a human-readable format.

In the early days of ECU development, the values of calibration parameters were directly modified in the source code. Variables had to be made available for data logging in the source code as well. Every change to parameters or the list of measureable variables required modifications in the source code, re-compilation and flashing of the ECU.

As the control software grew in complexity, the development of the software was split up into several groups of engineers (function developers, software developers, calibration engineers, vehicle test engineers, etc.).  The side-effect of specializing the tasks however, was that this process became too cumbersome and slow. Additionally, the process of measurement & calibration needed to be separated from the process of software development, because a calibration engineer would need to change a parameter value or would want to record the values from a measurement variable, he had to ask the software developer to compile a new software version for him. This is the fundamental motivation for the group of ASAM MCD standards.  The MCD standard provided the way to abstract the calibration from the physical memory locations.

ASAM MCD-2 MC provides an ECU description that is optimized for the calibration engineer. Relevant information such as detailed descriptions of calibration and measurement variables is included. Information that is not needed for calibration (such as code details) is excluded. Furthermore, the standard contains a description of the device interface to the ECU for read and write access. Such a description of calibration and measurement variables can easily extend to several thousand entries per ECU.

Today, software development is highly distributed. Different OEMs and or Tier 1’s work with MC-systems from different tool vendors. Without standardization, the creation and maintenance of such description files could easily become a major time and cost factor of the overall development process.  Without standardization, the OEM or Tier 1 would be required to maintain several data description files in parallel or else continuously converting the files between different formats to ensure that everyone in the development process used the right format. The variety of tools and description formats would quickly become a hindrance for development progress and a frequent source of errors in the MCD tool chain.

ASAM MCD-2 MC was created to overcome those problems of wasting time and money to deal with various description formats that more or less contain the same data. The standard defines the syntax and semantics of the data descriptions. The standard was developed to consider the needs of all involved groups in the calibration process. For example, the description is typically produced by function developers, software engineers, tools & instrumentation experts, and is used by calibration engineers from various disciplines such as mechanical engineering, electrical engineering or controls engineering. Each finds data elements and properties within the description format that they need for their work. Furthermore, they can work with the ECU data in a familiar representation without having to understand ECU-internal data formats such as scaled integers, bit-fields or ID-codes.

Application Areas

The primary application area for ASAM MCD-2 MC is the area of measurement & calibration. Virtually all market-leading MC-systems for the Automotive industry know this format and are able to import, process and export a2l-files. The standard is also used in adjacent industries such as in train- and shipbuilding. Another closely related field is the area of rapid control prototyping systems.

Besides, manual measurement and calibration from the toolsets, test automation systems use ASAM MCD-2 MC for automated calibration and data logging. The standard is also used by in-vehicle data loggers and diagnostic tools. Most of the production code generators for embedded software automatically generate a2l-files.

Technical Content

File

The file extension of ASAM MCD-2 MC compliant description files is "a2l", which is an abbreviation of "ASAM MCD-2 MC Language".

If no encoding is specified in the a2l-file, then ISO-8859-1 (Latin-1) is assumed. Otherwise, a2l-files use the Unicode Transformation Format at least on the level of UTF-8. Higher levels (UTF-16 and UTF-32) can be used. UTF allows the use of non-Latin characters like Chinese or Japanese, which is useful  in descriptive texts inside the a2l-file such as descriptions (LongIdentifier), annotations (ANNOTATION) and comments (/* … */).

File Format

The internal format of a2l-files is based upon a non-XML notation. This format is not XML because the first version of ASAM MCD-2 MC was created several years before XML became an official standard. The schema described in ASAM MCD-2 MC is simple, efficient and easy to parse. There was never a real need to transform ASAM MCD-2 MC to an XML-compliant schema and the standard continues today to remain a non-XML format.

The content of a2l-files consists of keywords, parameters, delimiters and comments. Together, these items form a data model, which describe data semantics and data values. The keywords are the main elements of the ASAM MCD-2 MC data model. Keywords can contain parameters and other keywords. The parameters of a keyword contain the values of the data model.

Other keywords underneath a keyword create a hierarchical structure of keywords similar to an aggregation in XML. Parameters and aggregated keywords may be mandatory or optional and may have a multiplicity.

 

Structure of an a2l-file

Some keywords are delimited with "/begin" and "/end". The delimiters are applied to those keywords that contain optional keywords or list of parameters with variable length. These delimiters prevent ambiguous interpretation.

The standard clearly defines the list of parameters and aggregated keywords via prototype definitions. The prototype also specifies whether parameters and aggregated keywords are mandatory or optional, their multiplicity and use of delimiters.

Comments in a2l-files follow the same syntactical rules as for the C++ language. Single line comments start with a double forward-slash (i.e. //). Multi-line comments are delimited with a forward-slash and asterisk (i.e. /*) at the beginning and with an asterisk and forward-slash (i.e. */) at the end and cannot be nested.

An a2l-file can have include statements (/include <filename>), which allows to include a2l-file fragments into one a2l-master-file. These include statements are common practice in distributed development processes, where software originates from different suppliers and different tool chains. Each a2l file provide partial data descriptions via a2l-file fragments, that have to be merged via include statements into a single file. Furthermore, it is common practice to place the interface description (i.e. the A2ML section) into its own file with the extension ".aml".

Some keywords are delimited with "/begin" and "/end". The delimiters are applied to those keywords that contain optional keywords or list of parameters with variable length. This shall prevent ambiguous interpretation.

The standard clearly defines the list of parameters and aggregated keywords via prototype definitions. The prototype also specifies whether parameters and aggregated keywords are mandatory or optional, their multiplicity and use of delimiters.

Comments in a2l-files follow the same syntactical rules as for the C++ language. Single line comments start with a double forward-slash (i.e. //). Multi-line comments are delimited with a forward-slash and asterisk (i.e. /*) at the beginning and with an asterisk and forward-slash (i.e. */) at the end and shall not be nested.

An a2l-file can have include statements (/include <filename>), which allows to include a2l-file fragments into one a2l-master-file. This is common practice in distributed development processes, where software originates from different suppliers and different tool chains. They all provide partial data descriptions via a2l-file fragments, that have to be merged via include statements into a single file. Furthermore, it is common practice to place the interface description (i.e. the A2ML section) into its own file with the extension ".aml".

Structure

At the beginning of an a2L-file, the version number (keyword: ASAP2_VERSION) of the standard and optionally the version number of the AML language (A2ML_VERSION) is stated. The a2l-file consists of four structural levels:

  • Project
  • Module
  • primary keywords
  • and secondary keywords.

Secondary keywords may actually span across several more levels.

An a2l-file contains one project (PROJECT), which describes all calibration and measurement data that belong to one calibration project. A header provides some general information about the project such as project number, version and a description (HEADER). A project consists of one or more modules (MODULE). Each module represents one ECU. The standard allows to contain several ECU descriptions via the MODULE keyword, but current MC-systems typically only support one MODULEper a2l-file.

Top-Level KeywordDescription

A2ML_VERSION

Version of the ASAM MCD-2 MC meta language (AML) used in this file.

ASAP2_VERSIONVersion of the ASAM MCD-2 MC standard used in this file.
HEADERAllows to specify a project number and an ECU software version, for which the a2l-file is compatible with.
MODULEContains the data description for one ECU.
PROJECTKeyword on root level of the a2l-file. Contains everything.
The third level, which is below the keyword MODULE, holds the primary keywords, which contain the actual description of ECU data. The following list contains the keywords of this level.

Primary KeywordDescription
A2MLDefines the formal description of parameters that describe the communication between the MC- system and the ECU. The A2ML block only describes the syntax of communication parameters. Their meaning (i.e. semantics) depends on the used communication protocol and drivers, which is not part of ASAM MCD-2 MC. The parameters typically contain the configuration of the protocol stack and are needed to create messages for measurement & calibration objects such as MEASUREMENT and CHARACTERISTIC. The actual parameter values are given in the IF_DATA blocks. The values in the IF_DATA blocks must match the syntax description of the A2ML block. The description is expressed in the ASAM MCD-2 MC meta language (AML).
AXIS_PTSAxes contain the sample point values for curves and maps. The keyword describes the properties of an axis, such as its address in memory, references to the input variable (MEASUREMENT), record layout and computation method, the maximum number of sample points and further properties.
BLOBDefinition of a binary large object for calibration (not measureable). Is just an array of bytes, with no further structural or semantic interpretation. Has no COMPU_METHOD or RECORD_LAYOUT.
CHARACTERISTIC

CHARACTERISTIC describes the properties of a tunable parameter. This parameter can be a scalar, string, array or look-up-table with associated axes. The following types of tunable parameters are available:

  • VALUE: scalar
  • ASCII: string
  • VAL_BLK: array (no axes)
  • CURVE: 1D-table
  • MAP: 2D-table
  • CUBOID: 3D-table
  • CUBE_4: 4D-table
  • CUBE_5: 5D-table

The address, record layout, computation method, upper and lower calibration limits and further properties are defined.

COMPU_METHOD

Describes the methods and properties for converting values from an ECU-internal format, which is optimized for implementation, to a physical format, which is easily understood by human beings. Computation methods are typically referenced by CHARACTERISTICs and MEASUREMENTs. The majority of automotive ECU software still uses scaled integers for this data. COMPU_METHODs convert this data from their fixed-point representation into a floating-point representation for display in an MC-system. This representation typically has an SI unit for signals, or may displays discrete data such as error codes as text strings. Supported conversion methods are:

  • IDENTICAL: no conversion
  • LINEAR: linear, 2-coefficient function with slope and offset
  • RAT_FUNC: 6-coefficient rational function with 2nd-degree numerator and denominator polynomials
  • TAB_INTP: table with interpolation
  • TAB_NOINTP: table without interpolation
  • TAB_VERB: verbal table (i.e. enumeration)
  • FORM: formula which consists of a specific set of operators and functions

Please note that the conversion direction is from the internal format to the physical format, except for RAT_FUNC, which describes the conversion from the physical format to the internal format.
Other properties describe the display format (in C-printf notation) and the unit. If needed, the COMPU_METHOD specifies the formula coefficients, references to tables, formulas and units.

COMPU_TABConversion tables are used by COMPU_METHODs, if the conversion cannot be expressed by a formula. They are described by input-output value pairs, i.e. same as a 1D lookup table. Conversion tables with or without interpolation are supported.
COMPU_VTABVerbal conversion tables are used to convert internal ECU values into human-readable strings. A number or bit-pattern is assigned to a string. Verbal conversion tables are described by pairs of input-values and output-strings. This method is equivalent to enumerated types in the C programming language.
COMPU_VTAB_RANGESame as COMPU_VTAB, but allows to specify a value range for each string.
FRAMEAllows to group MEASUREMENTs to selection lists, which can be chosen in an MC-system for selective recording and display of ECU-internal variables. FRAMEs are typically used to bundle variables, which shall be measured and viewed together. The FRAME keyword can also be used to describe the packaging of ECU-internal variables in a CAN frame.
FUNCTIONAllows to group MEASUREMENTs, CHARACTERISTICs and AXIS_PTSs into selection lists, which can be chosen in an MC-system for selective tuning of parameters and recording of variables. FUNCTIONs are typically used to bundle variables and parameters, which belong to one software function. This supports function-oriented measurement and calibration. Owned and external parameters and variables can be expressed. Function hierarchies that include sub-functions can be expressed.
GROUPAllows to group MEASUREMENTs, CHARACTERISTICs and AXIS_PTSs into selection lists, which can be chosen in an MC-system for selective tuning of parameters and recording of variables. GROUPs are typically used to bundle variables and parameters that have a common meaning or are used for a specific view. GROUPs can be used in conjunction with USER_RIGHTS to control user access. This supports function-oriented measurement and calibration. Group hierarchies can be expressed that include a root and sub-groups.
IF_DATAList of parametric values that are used to configure the device driver for communication between the MC-system and ECU. As a primary keyword on MODULE level, the IF_DATA section contains the parametric values for the configuration of the protocol stack. IF_DATA sections may also be used as secondary keywords (see table below) to parameterize the communication of objects such as MEASUREMENT and CHARACTERISTIC. The list of values needs to match with the syntax definitions in the A2ML section of the a2l-file.
INSTANCE

To instantiate a MEASUREMENT, CHARACTERISTIC, AXIS, BLOB or structure object.

MEASUREMENTMEASUREMENT describes the properties of a recordable, ECU-internal variable. This variable can be a scalar or an array. Bit masks and bit operations can be applied to the measurement. The address, byte order, computation method, upper and lower limits and further properties are described. Standard allows also to write to measurement objects, e.g. to stimulate the ECU during runtime. MEASUREMENT may also describe a virtual variable, which is calculated from ECU-internal variables, other virtual variables and constants.
MOD_COMMONDefines default parameters that are common for other keywords of the module, so they do not have to be repeated for each of them. They include the definition of byte alignment, byte order, size and storage of data in the ECU memory. The parameters of MOD_COMMON are optional parameters of other keywords. If they are not defined in a keyword, then the corresponding parameter value of MOD_COMMON is used. Otherwise, when a parameter is defined in a keyword, then it overrules the parameter value defined in MOD_COMMON.
MOD_PARSpecifies general parameters of a module (i.e. ECU). This includes data such as the name of the CPU, customer, version and other ECU-specific data. Furthermore, this keyword contains the description of the organization of the ECU's memory via the keyword MEMORY_SEGMENT as well as a list of system constants which can be used in conversion methods.
RECORD_LAYOUTDescribes how structures of tunable parameters (CHARACTERISTIC) and axes (AXIS_PTS) are stored in memory. It describes byte alignments, order and position of calibration objects in memory, their rescaling, memory offset and further properties.
TRANSFORMER

Definition of call to an external function (32-bit or 64-bit DLL) for converting calibration object values between their implementation format and physical format. Bi-directional conversion is possible. Includes list of input and output objects. Input and output objects cannot contain measurement objects. Defines timeout. Defines trigger conditions:

  • ON_CHANGE
  • ON_USER_REQUEST

TRANSFORMERs are typically use for IP protection, or if COMPU_METHODS are not useable due to complex conversion algorithms.

TYPEDEF_AXIS

Type definition of a axis object. Can be used for defining multiple axis objects of the same type. Can be used to define axis objects, which are part of a structure.

TYPEDEF_BLOB

Type definition of a BLOB. Can be used for defining multiple BLOBs of the same type. Can be used to define BLOBs, which are part of a structure.

TYPEDEF_CHARACTERISTIC

Type definition of a calibration object. Can be used for defining multiple calibration objects of the same type. Can be used to define calibration objects, which are part of a structure.

TYPEDEF_MEASUREMENT

Type definition of a measurement object. Can be used for defining multiple measurement objects of the same type. Can be used to define measurement objects, which are part of a structure.

TYPEDEF_STRUCTURE

Definition of structured data types similar to the "typedef" command in C. Contains objects of type TYPEDEF_, including other structures. Cannot mix TYPEDEF_MEASUREMENT objects with any other object types.

UNITDefines units that can be referenced by MEASUREMENT, CHARACTERISTIC, AXIS_PTS and COMPU_METHOD. Units shall be stated according to the International System of Units (SI). UNIT supports SI based units described by exponents of the seven base units as well as derived units described by a reference unit and a linear conversion method.
USER_RIGHTSLists GROUPs and access rights for named users. Access rights might be read-only or read & write. 
VARIANT_CODINGDescription of tunable parameters, which have more than one value stored in ECU memory at different addresses. The description of variant-coded parameters and non-variant coded parameters does not differ in the CHARACTERISTIC keyword. If a parameter shall be variant coded, then VARIANT_CODING has a reference to this parameter and specifies additional properties that describe how to select the active variant (i.e. read the selected value from memory). The active variant might be selected by another tunable parameter (VAR_SELECTION_CHARACTERISTIC) or an ECU-internal variable (VAR_MEASUREMENT).

The fourth and lower levels of an a2l-file consist of secondary keywords. They are aggregated by primary keywords. The secondary keywords are a way to further structure the data and to provide further details. The following list contains the keywords of this level.

Secondary KeywordAggregated byDescription
ADDR_EPKMOD_PARAddress of EPROM identifier. 
ALIGNMENT_BYTEMOD_COMMON, RECORD_LAYOUTAlignment of byte data in memory.
ALIGNMENT_FLOAT32_
IEEE
MOD_COMMON, RECORD_LAYOUTAlignment of float32 data in memory.
ALIGNMENT_FLOAT64_
IEEE
MOD_COMMON, RECORD_LAYOUTAlignment of float64 data in memory. 
ALIGNMENT_INT64MOD_COMMON, RECORD_LAYOUTAlignment of int64 data in memory.
ALIGNMENT_LONGMOD_COMMON, RECORD_LAYOUTAlignment of long data in memory.
ALIGNMENT_WORDMOD_COMMON, RECORD_LAYOUTAlignment of word data in memory.
ANNOTATIONAXIS_DESCR, AXIS_PTS, CHARACTERISTIC, FUNCTION, GROUP, MEASUREMENTContainer for annotation.
ANNOTATION_LABELANNOTATIONTitle of annotation.
ANNOTATION_ORIGINANNOTATIONCreator of annotation.
ANNOTATION_TEXTANNOTATIONExplanatory text in an annotation.
ARRAY_SIZEMEASUREMENTNumber of values in the measurement. 1D array is supported, only. Obsolete keyword. Please use MATRIX_DIM instead.
AXIS_DESCRCHARACTERISTIC

Specifies the properties of an axis that belongs to a tunable curve, map or cuboid. The following axis types are available:

  • STD_AXIS:  Axis specific to one table.
  • FIX_AXIS:  Axis specific to one table with calculated axis points. Axis points are not stored in ECU memory.
  • COM_AXIS:  Axis shared by various tables.
  • CURVE_AXIS:  Axis shared by various tables and rescaled, i.e. normalized, by a curve (CURVE_AXIS_REF).
  • RES_AXIS:  Axis shared by various tables and rescaled, i.e. normalized, by another axis (AXIS_PTS_REF).
AXIS_PTS_REFAXIS_DESCRReference to AXIS_PTS in case the axis values are stored in a different memory location than the values of the CHARACTERISTIC the axis description belongs to.
AXIS_PTS_X / _Y / _Z / _4 / _5RECORD_LAYOUTSpecifies position, datatype, index increment and addressing method of the X, Y, Z, Z4 or Z5 axis  points in memory.
AXIS_RESCALE_XRECORD_LAYOUTSpecifies the rescale mapping between stored axis points and used points for curve and maps.
BIT_MASKCHARACTERISTIC, MEASUREMENTSpecifies a bit mask to extract single bits from the object's value.
BIT_OPERATIONMEASUREMENTSpecifies an additional bit masking operation which consists of a bit shift and a sign extension.
BYTE_ORDERAXIS_DESCR, AXIS_PTS, CHARACTERISTIC, MEASUREMENT, MOD_COMMONEndianness or position of the most significant bit.
CALIBRATION_ACCESSAXIS_PTS, CHARACTERISTICType of access to the tunable parameter, e.g. full access, offline or no access.
CALIBRATION_HANDLECALIBRATION_METHODParameters for CALIBRATION_METHOD.
CALIBRATION_
HANDLE_TEXT
CALIBRATION_HANDLEText for CALIBRATION_METHOD.
CALIBRATION_
METHOD
MOD_PARSpecifies the memory access method used by the MC-system.
COEFFSCOMPU_METHODCoefficients for the rational function (RAT_FUNC).
COEFFS_LINEARCOMPU_METHODCoefficients for the linear function (LINEAR).
COMPARISON_
QUANTITY
CHARACTERISTICReference to a MEASUREMENT, which represents the working point on a curve.
COMPU_TAB_REFCOMPU_METHODReference to a conversion table.
CPU_TYPEMOD_PARString that identifies the CPU.
CURVE_AXIS_REFAXIS_DESCRReference to the curve's CHARACTERISTIC that is used to normalize or scale the axis.
CUSTOMERMOD_PARString that identifies the customer or company.
CUSTOMER_NOMOD_PARString that provides a number associated to the customer.
DATA_SIZEMOD_COMMONNumber of bits in measurement and calibration objects. Typically represents the bit-width of the used micro-controller.
DEFAULT_VALUECOMPU_TAB, COMPU_VTAB, COMPU_VTAB_RANGEDefault output string, which is used for display when the measured ECU value is out of range of the defined table.
DEFAULT_VALUE_
NUMERIC
COMPU_TABDefault output float value, which is used for display when the measured ECU value is out of range of the defined table.
DEF_CHARACTERISTICFUNCTIONReferences to AXIS_PTS or CHARACTERISTIC that belong to the function.
DEPENDENT_
CHARACTERISTIC
CHARACTERISTIC

The value of the CHARACTERISTIC, which references this DEPENDENT_CHARACTERISTIC, is calculated instead of read from ECU memory. DEPENDENT_CHARACTERISTIC specifies a formula and references to other parameters (in memory or virtual) for the purpose to calculate the value. The value changes automatically, once one of the referenced parameters has changed its value.

DEPOSITAXIS_DESCR, AXIS_PTS, MOD_COMMONStorage mode for axis points: "ABSOLUTE" signifies that absolute values are stored. "DIFFERENCE" signifies that difference-values between axis points are stored.
DISCRETECHARACTERISTIC, MEASUREMENTIndicates that the parameter values shall not be interpolated, e.g. in displays or in post-processing.
DISPLAY_IDENTIFIERAXIS_PTS, CHARACTERISTIC, MEASUREMENTCan be used to specify a display name, which is different (e.g. shorter) than the original object name.
DIST_OP_X / _Y / _Z / _4 / _5RECORD_LAYOUTSpecifies position and datatype of the distance (i.e. slope) value within the record layout. The distance value is used to calculate the axis points for the described FIX_AXIS.
ECUMOD_PARString that describes the control unit. 
ECU_ADDRESSMEASUREMENTAddress of the MEASUREMENT in ECU memory.
ECU_ADDRESS_
EXTENSION
AXIS_PTS, CHARACTERISTIC, MEASUREMENTSpecifies additional address information, for instance to distinguish between different address spaces of an ECU.
ECU_CALIBRATION_
OFFSET
MOD_PAROffset that has to be added to calculate the absolute address of a CHARACTERISTIC. Used to resolve near-pointers in record layouts or to select   the data set among several variant data sets.
EPKMOD_PARString that describes the EPROM.
ERROR_MASKMEASUREMENTBit mask that can be used to mask-out those bits of a MEASUREMENT, which indicate an error.
EXTENDED_LIMITSAXIS_DESCR, AXIS_PTS, CHARACTERISTICSpecifies an extended upper and lower value beyond the normal upper and lower limit values. Can be used to distinguish between out-of-range warnings and out-of-range error messages, or to allow specific power-users to set calibration values beyond a safe margin.
FIX_AXIS_PARAXIS_DESCRSpecifies the value of the first sample point, the power-of-two exponent of the increment value and total number of sample points for computing the sample point values of an equidistant axis of type FIX_AXIS.
FIX_AXIS_PAR_DISTAXIS_DESCRSpecifies the value of the first sample point, the increment value and the total number of sample points for computing the sample point values of an equidistant axis of type FIX_AXIS.
FIX_AXIS_PAR_LISTAXIS_DESCRExplicitly specifies the sample point values of the axis of type FIX_AXIS.
FIX_NO_AXIS_PTS_X / _Y / _Z / _4 / _5RECORD_LAYOUTSpecifies the number of axis points. This number is fixed and not stored in memory.
FNC_VALUESRECORD_LAYOUTSpecifies position, datatype, orientation and addressing method to store table data in the record layout.
FORMATAXIS_DESCR, AXIS_PTS, CHARACTERISTIC, MEASUREMENTSpecifies the display format of object values in C-printf notation. Overrules the format parameter in referenced COMPU_METHOD.
FORMULACOMPU_METHODSpecifies a conversion formula to calculate the physical value from the ECU-internal value. Expression of the formula complies with ANSI C notation. Shall be used only, if linear or rational functions are not sufficient.
FORMULA_INVFORMULASpecifies a conversion formula to calculate the ECU-internal value from the physical value. Is the inversion of the referenced FORMULA. Expression of the formula complies to ANSI C notation.
FRAME_
MEASUREMENT
FRAMEList of MEASUREMENTs that are bundled in this frame. 
FUNCTION_LISTAXIS_PTS, CHARACTERISTIC, MEASUREMENTLists the FUNCTIONs in which this object is listed. Obsolete keyword. Please use FUNCTION instead.
FUNCTION_VERSIONFUNCTIONString that describes the version of this function.
GUARD_RAILSAXIS_PTS, CHARACTERISTICDetermines that the outermost values of axes, curves and maps are calculated and cannot be adjusted.
IDENTIFICATIONRECORD_LAYOUTSpecifies position and data type of an identification number for the stored object.  
IF_DATAAXIS_PTS, CHARACTERISTIC, FRAME, FUNCTION, GROUP, MEASUREMENT,
MEMORY_LAYOUT,   MEMORY_SEGMENT
IF_DATA sections are used to configure the device driver for communication between the MC-system and the ECU. As a secondary keyword, it includes the list of parametric values that are needed to create the message for this object that the device driver has to transfer. The list of values needs to match with the definitions in the A2ML section of the a2l-file. IF_DATA sections may also be used as primary keywords (see table above) to configure the protocol stack.
IN_MEASUREMENTFUNCTIONReferences to MEASUREMENTs that are defined as inputs to this FUNCTION.
LAYOUTMEASUREMENTSpecifies how multidimensional measurement arrays are stored in linear memory. "ROW_DIR" signifies row-major order. "COLUMN_DIR" signifies column-major order.
LEFT_SHIFTBIT_OPERATIONNumber of bit positions to shift to the left in a BIT_OPERATION.
LOC_MEASUREMENTFUNCTIONReferences to MEASUREMENTs that are defined as local variables in this FUNCTION.
MAP_LISTCHARACTERISTICLists the maps which comprise a cuboid.
MATRIX_DIMCHARACTERISTIC, MEASUREMENTSpecifies the dimensions of multidimensional arrays.
MAX_GRADAXIS_DESCRSpecifies the maximum permissible gradient for this axis.
MAX_REFRESHCHARACTERISTIC, MEASUREMENTMaximum refresh rate for this object in the control unit.
MEMORY_LAYOUTMOD_PARDescription of the memory layout of an ECU. Obsolete keyword. Please use MEMORY_SEGMENT instead.
MEMORY_SEGMENTMOD_PARDescription of one memory segment of the ECU. Includes program type, memory type, location, address, size and offsets.
MONOTONYAXIS_DESCR, AXIS_PTSSpecifies which kind of monotony for the sample values is allowed for this axis.
NO_AXIS_PTS_X / _Y / _Z / _4 / _5RECORD_LAYOUTSpecifies position and datatype of the number of axis points within the record layout.
NO_OF_INTERFACESMOD_PARNumber of interfaces.
NO_RESCALE_XRECORD_LAYOUTSpecifies position and datatype of the number of rescaling values within the record layout.
NUMBERCHARACTERISTICSpecifies the number of elements (ASCII characters or values) in a 1D array. Obsolete keyword. Please use MATRIX_DIM instead.
OFFSET_X / _Y / _Z / _4 / _5RECORD_LAYOUTSpecifies position and datatype of the offset value within the record layout. The offset value is used to calculate the axis points for the described FIX_AXIS.
OUT_MEASUREMENTFUNCTIONReferences to MEASUREMENTs that are defined as the outputs of this FUNCTION.
PHONE_NOMOD_PARPhone number of the responsible calibration engineer.
PHYS_UNITAXIS_DESCR, AXIS_PTS, CHARACTERISTIC, MEASUREMENTSpecifies the physical unit. Overrules the unit specified in the referenced COMPU_METHOD.
PROJECT_NOHEADERString that describes a project number.
READ_ONLY

AXIS_DESCR, AXIS_PTS, CHARACTERISTIC, USER_RIGHTS

Specifies read-only access to this tunable parameter or for this user.
READ_WRITEMEASUREMENTSpecifies that write-access is allowed for this MEASUREMENT.
REF_CHARACTERISTICFUNCTION, GROUPReferences to AXIS_PTS or CHARACTERISTIC that are used but not owned by this FUNCTION or which belong to this GROUP.
REF_GROUPUSER_RIGHTSReference to groups of MEASUREMENTs and CHARACTERISTICs to define the access rights for this group of users.
REF_MEASUREMENTGROUPReference to MEASUREMENTs that belong to this group.
REF_MEMORY_
SEGMENT
AXIS_PTS, CHARACTERISTIC, MEASUREMENTReference to a memory segment in case the address is not unique, e.g. if overlapping  memory segments exist.
REF_UNITCOMPU_METHOD, UNITReference to a physical unit.
RESERVEDRECORD_LAYOUTSpecifies a position in this record layout that shall be ignored (i.e. not interpreted).
RIGHT_SHIFTBIT_OPERATIONNumber of bit positions to shift to the right in a BIT_OPERATION.
RIP_ADDR_W / _X / _Y / _Z / _4 / _5RECORD_LAYOUTSpecifies position and datatype to store the result of interpolation for the X, Y, Z, Z4 or Z5 axis and the look-up table's output W.
ROOTGROUPSpecifies the root of this GROUP's hierarchy.
SHIFT_OP_X / _Y / _Z / _4 / _5RECORD_LAYOUTSpecifies position and datatype of the power-of-two exponent of the distance (i.e. slope) value within the record layout. The distance value is used to calculate the axis points for the described FIX_AXIS.
SIGN_EXTENDBIT_OPERATIONSpecifies that a right shift operation shall extend the leftmost bit to the left so that the new, shifted number has still the same sign in the two's complement system.
SI_EXPONENTSUNITSpecifies the exponents of the seven SI base units to express this derived SI unit.
SRC_ADDR_X / _Y / _Z / _4 / _5RECORD_LAYOUTSpecifies position and datatype of the address of the axis' input value within the record layout.
STATIC_RECORD_
LAYOUT
RECORD_LAYOUTSpecifies that a tunable axis with a dynamic number of axis points does not compact or expand in memory when removing or inserting axis points.
STATUS_STRING_REFCOMPU_METHODReference to a verbal conversion table (COMPU_VTAB or COMPU_VTAB_RANGE). Used to split up the value range of the measurement to a numerical part and a verbal part. The latter contains status information about the numerical part such as providing an error or describing the quality of the measurement.
STEP_SIZEAXIS_DESCR, AXIS_PTS, CHARACTERISTICSpecifies an increment value that is added or subtracted when using the up/down keys while calibrating.
SUB_FUNCTIONFUNCTIONReference to other FUNCTIONs, which are sub-functions of this FUNCTION. Can be used to reproduce the hierarchy of functions in the ECU software.
SUB_GROUPGROUPReference to other GROUPs, which are sub-groups of this GROUP. Can be used to create a hierarchy of group objects.
SUPPLIERMOD_PARString that describes the manufacturer or supplier of the ECU.
SYMBOL_LINKAXIS_PTS, CHARACTERISTIC, MEASUREMENTReference to the symbolic name of the object within a linker map file. Can be used for an automatic update of memory addresses in an a2L-file.
SYSTEM_CONSTANTMOD_PARSpecifies name and value of a constant that can be used in FORMULA or FORMULA_INV.
UNIT_CONVERSIONUNITSpecifies slope and offset of a linear formula to convert the referenced unit (REF_UNIT) to this UNIT.
USERMOD_PARString that describes the name of the user.
VAR_ADDRESSVAR_CHARACTERISTICList of ECU addresses for each value of a variant coded tunable parameter (VAR_CHARACTERISTIC). The number of addresses in this list must match the number of variants from the referenced variant criteria (VAR_CRITERION).
VAR_CHARACTERISTICVARIANT_CODINGDescription of a tunable parameter with more than one value in ECU memory. The description consists of a reference to the tunable parameter (CHARACTERISTIC), references to variant criteria (VAR_CRITERION) defining the possible variants and a reference to the list of ECU addresses for the values for each variant (VAR_ADDRESS).
VAR_CRITERIONVARIANT_CODINGDescription of a variant criterion. The description consists of a list of named variants and a selector variable (reference to a MEASUREMENT or CHARACTERISTIC) defining the currently active variant by its value.
VAR_FORBIDDEN_
COMB
VARIANT_CODINGCombination of variants that are not allowed.
VAR_MEASUREMENTVAR_CRITERIONReference to an ECU-internal variable, which selects the active variant by its value. The corresponding MEASUREMENT must refer to a COMPU_TAB, whose strings must correspond with the variant names defined in VAR_CRITERION.
VAR_NAMINGVARIANT_CODINGIndexing method to distinguish different variants, e.g. "NUMERIC" or "ALPHA".
VAR_SELECTION_
CHARACTERISTIC
VAR_CRITERIONReference to a tunable parameter, which selects the active variant by its value. The corresponding CHARACTERISTIC must refer to a COMPU_TAB, whose strings must correspond with the variant names defined in VAR_CRITERION.
VAR_SEPERATORVARIANT_CODINGSeparation symbol between the name of a variant coded parameter and the variant extension.
VERSIONHEADER, MOD_PARString that describes the software version.
VIRTUALMEASUREMENTSpecifies that this MEASUREMENT is not measured but calculated from the listed input measurements via a COMPU_METHOD.
VIRTUAL_
CHARACTERISTIC
CHARACTERISTICSpecifies a formula to calculate the initialization value of this virtual characteristic based upon referenced CHARACTERISTICs. The value of the virtual characteristic is not stored in ECU memory. It is typically used to calculate DEPENDENT_CHARACTERISTICs.

Datatypes

ASAM MCD-2 MC supports datatypes that are typically used in ECU software. The standard does not explicitly state the signedness, bit-width and format of those data types. The following table provides a typical interpretation of the datatypes as used in the automotive industry.

DatatypeSignednessBit WidthFormat
UBYTE

unsigned

 8one's complement

SBYTE

signed

 8two's complement

UWORD

unsigned

 16one's complement
SWORDsigned16two's complement
ULONGunsigned32one's complement
SLONGsigned32two's complement
A_UINT64unsigned64one's complement
A_INT64signed64two's complement
FLOAT32_IEEEsigned32IEEE 754 single precision
FLOAT64_IEEEsigned64IEEE 754 double precision

Relation to other Standards

The standard belongs to a group of tightly coupled standards that specify interfaces of meas-urement, calibration and diagnostic systems (MCD). The ASAM MCD-1 standards specify cali-bration protocols between the ECU and an external MC-system. ASAM MCD-2 standards specify data models and description file formats for describing internal ECU data and network data. The ASAM MCD-3 standards specify APIs for remote controlling of MCD-systems, e.g. for automated calibration. The diagnostic part of ASAM MCD-3 has also been published as ISO 22900-3. ASAM MCD-2-MC is furthermore associated to ASAM CDF, which is a file format that stores the values of calibration parameters and associated meta data, and ASAM MDF, which is a file format that stores the values of measured variables and associated meta data. When all standards are jointly applied, then the MCD tool-chain achieves a high degree of interoperability, vendor- and technology-independence and allows easy exchange of data between customers and suppliers.

The data model of ASAM MCD-2 MC has been the foundation for other, later standards of the automotive industry. For example, ASAM MDX took the majority of ASAM MCD-2 MC data elements over into its own data model. The same applies to AUTOSAR's software component template, which is almost identical to ASAM MDX with respect to MCD data descriptions.

Benefits & Advantages

The main advantage of ASAM MCD-2 MC is that the standard allows to separate the process of measurement & calibration from the process of software development. Calibration engineers can work independent from software engineers as soon as they get a flashable software version and a matching a2l-file.

The advantages are even more significant when the development process is spread over several companies. Software sources do not have to be shared any longer to allow other parties to tune parameters or change the list of measurable. A software supplier may just provide a flashable executable and the corresponding a2L-file, which is all that is needed to enable his customer to carry out calibration & measurement tasks.

Since a2l-files are standardized and vendor-independent, they do not have to be converted even though every partner in a development project may use different tools and different interfaces. The standard allows to connect software development tools, calibration tools and ECU calibration interfaces with a neutral description format. All tools that support the description format are able to exchange and process the included information, hence there are no vendor-specific or technology-specific dependencies between tools of an ASAM-compliant calibration tool-chain.

Industry Adoption

Due to this comprehensive and complete coverage of data related to measurement and calibration, the standard has been globally accepted in the automotive industry and displaced most of the proprietary formats that were formerly used in the automotive industry.

Today, ASAM MCD-2 MC is widely used in the automotive industry as the data format to describe measurement variables and calibration parameters. Virtually all market-leading MC-systems know this format and are able to import and export a2l-files. The standard is used furthermore in other tools in the MCD area, such as data loggers, diagnostic tools, rapid control prototyping systems and automated calibration and testing systems. Most of the production code generators for embedded software automatically generate a2l-files along with C-code sources. Special tools are available for most of the Linker map file formats that can update an a2l-file with address and record-layout information.

List of Deliverables

The standard includes the following deliverables:

  • Standard document

ASAM offers a checker tool for a2l- and aml-files, which is available as a seperate deliverable. The checker verifies that files are syntactically correct, name spaces have unique names, references are resolved and that mandatory parameters are specified and correctly typed, dependencies between parameters and some further plausibility and consistency checks.

Downloads

The data description in this a2l-file matches the downloadable cdfx-file (see ASAM CDF) and mf4-file (see ASAM MDF). You can study with those three files how they work together.

ASAP2_Demo_V161.a2l

Example of an a2l-file, including AML-section for XCP.

 

Skip to end of metadata
Go to start of metadata

Back to Top