The first version of thestandard 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).
ASAMMCD-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.
ASAMMCD-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 thestandard. 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.
Thecalibration 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 ofcalibration 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.
ASAMMCD-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 withMC-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.
ASAMMCD-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.
The primary application area for ASAMMCD-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, manualmeasurement 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.
The file extension of ASAMMCD-2 MC compliant description files is " a2l", which is an abbreviation of "ASAM MCD-2 MC Language".
If no encoding is specified in thea2l-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 (/* … */).
The internal format ofa2l-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 ofa2l-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 inXML. Parameters and aggregated keywords may be mandatory or optional and may have a multiplicity.
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.
Thestandard 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 ina2l-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.
Ana2l-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.
At the beginning of ana2L-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:
Secondary keywords may actually span across several more levels.
Ana2l-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 MODULE per a2l-file.
Version of the ASAMMCD-2 MC meta language ( AML) used in this file.
|ASAP2_VERSION||Version of the ASAM MCD-2 MC standard used in this file.|
|HEADER||Allows to specify a project number and an ECU software version, for which the a2l-file is compatible with.|
|MODULE||Contains the data description for one ECU.|
|PROJECT||Keyword 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.
|A2ML||Defines 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_PTS||Axes 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.|
|BLOB||Definition 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 describes the properties of a tunable parameter. This parameter can be ascalar, string, array or look-up-table with associated axes. The following types of tunable parameters are available:
The address, record layout, computation method, upper and lowercalibration limits and further properties are defined.
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 anMC-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:
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_TAB||Conversion 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_VTAB||Verbal 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.|
|Same as COMPU_VTAB, but allows to specify a value range for each string.|
|FRAME||Allows 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.|
|FUNCTION||Allows 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.|
|GROUP||Allows 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_DATA||List 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.|
To instantiate a MEASUREMENT, CHARACTERISTIC, AXIS, BLOB or structure object.
|MEASUREMENT||MEASUREMENT 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_COMMON||Defines 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_PAR||Specifies 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_LAYOUT||Describes 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.|
Definition of call to an external function (32-bit or 64-bitDLL) 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:
TRANSFORMERs are typically use forIP protection, or if COMPU_METHODS are not useable due to complex conversion algorithms.
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.
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.
|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.|
Type definition of ameasurement 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.
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.
|UNIT||Defines 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_RIGHTS||Lists GROUPs and access rights for named users. Access rights might be read-only or read & write.|
|VARIANT_CODING||Description 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 ana2l-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.
|ADDR_EPK||MOD_PAR||Address of EPROM identifier.|
|ALIGNMENT_BYTE||MOD_COMMON, RECORD_LAYOUT||Alignment of byte data in memory.|
|MOD_COMMON, RECORD_LAYOUT||Alignment of float32 data in memory.|
|MOD_COMMON, RECORD_LAYOUT||Alignment of float64 data in memory.|
|ALIGNMENT_INT64||MOD_COMMON, RECORD_LAYOUT||Alignment of int64 data in memory.|
|ALIGNMENT_LONG||MOD_COMMON, RECORD_LAYOUT||Alignment of long data in memory.|
|ALIGNMENT_WORD||MOD_COMMON, RECORD_LAYOUT||Alignment of word data in memory.|
|ANNOTATION||AXIS_DESCR, AXIS_PTS, CHARACTERISTIC, FUNCTION, GROUP, MEASUREMENT||Container for annotation.|
|ANNOTATION_LABEL||ANNOTATION||Title of annotation.|
|ANNOTATION_ORIGIN||ANNOTATION||Creator of annotation.|
|ANNOTATION_TEXT||ANNOTATION||Explanatory text in an annotation.|
|ARRAY_SIZE||MEASUREMENT||Number of values in the measurement. 1D array is supported, only. Obsolete keyword. Please use MATRIX_DIM instead.|
Specifies the properties of an axis that belongs to a tunablecurve, map or cuboid. The following axis types are available:
|AXIS_PTS_REF||AXIS_DESCR||Reference 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 / _5||RECORD_LAYOUT||Specifies position, datatype, index increment and addressing method of the X, Y, Z, Z4 or Z5 axis points in memory.|
|AXIS_RESCALE_X||RECORD_LAYOUT||Specifies the rescale mapping between stored axis points and used points for curve and maps.|
|BIT_MASK||CHARACTERISTIC, MEASUREMENT||Specifies a bit mask to extract single bits from the object's value.|
|BIT_OPERATION||MEASUREMENT||Specifies an additional bit masking operation which consists of a bit shift and a sign extension.|
|BYTE_ORDER||AXIS_DESCR, AXIS_PTS, CHARACTERISTIC, MEASUREMENT, MOD_COMMON||Endianness or position of the most significant bit.|
|CALIBRATION_ACCESS||AXIS_PTS, CHARACTERISTIC||Type of access to the tunable parameter, e.g. full access, offline or no access.|
|CALIBRATION_HANDLE||CALIBRATION_METHOD||Parameters for CALIBRATION_METHOD.|
|CALIBRATION_HANDLE||Text for CALIBRATION_METHOD.|
|MOD_PAR||Specifies the memory access method used by the MC-system.|
|COEFFS||COMPU_METHOD||Coefficients for the rational function (RAT_FUNC).|
|COEFFS_LINEAR||COMPU_METHOD||Coefficients for the linear function (LINEAR).|
|CHARACTERISTIC||Reference to a MEASUREMENT, which represents the working point on a curve.|
|COMPU_TAB_REF||COMPU_METHOD||Reference to a conversion table.|
|CPU_TYPE||MOD_PAR||String that identifies the CPU.|
|CURVE_AXIS_REF||AXIS_DESCR||Reference to the curve's CHARACTERISTIC that is used to normalize or scale the axis.|
|CUSTOMER||MOD_PAR||String that identifies the customer or company.|
|CUSTOMER_NO||MOD_PAR||String that provides a number associated to the customer.|
|DATA_SIZE||MOD_COMMON||Number of bits in measurement and calibration objects. Typically represents the bit-width of the used micro-controller.|
|DEFAULT_VALUE||COMPU_TAB, COMPU_VTAB, COMPU_VTAB_RANGE||Default output string, which is used for display when the measured ECU value is out of range of the defined table.|
|COMPU_TAB||Default output float value, which is used for display when the measured ECU value is out of range of the defined table.|
|DEF_CHARACTERISTIC||FUNCTION||References to AXIS_PTS or CHARACTERISTIC that belong to the function.|
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.
|DEPOSIT||AXIS_DESCR, AXIS_PTS, MOD_COMMON||Storage mode for axis points: "ABSOLUTE" signifies that absolute values are stored. "DIFFERENCE" signifies that difference-values between axis points are stored.|
|DISCRETE||CHARACTERISTIC, MEASUREMENT||Indicates that the parameter values shall not be interpolated, e.g. in displays or in post-processing.|
|DISPLAY_IDENTIFIER||AXIS_PTS, CHARACTERISTIC, MEASUREMENT||Can be used to specify a display name, which is different (e.g. shorter) than the original object name.|
|DIST_OP_X / _Y / _Z / _4 / _5||RECORD_LAYOUT||Specifies 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.|
|ECU||MOD_PAR||String that describes the control unit.|
|ECU_ADDRESS||MEASUREMENT||Address of the MEASUREMENT in ECU memory.|
|AXIS_PTS, CHARACTERISTIC, MEASUREMENT||Specifies additional address information, for instance to distinguish between different address spaces of an ECU.|
|MOD_PAR||Offset 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.|
|EPK||MOD_PAR||String that describes the EPROM.|
|ERROR_MASK||MEASUREMENT||Bit mask that can be used to mask-out those bits of a MEASUREMENT, which indicate an error.|
|EXTENDED_LIMITS||AXIS_DESCR, AXIS_PTS, CHARACTERISTIC||Specifies 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_PAR||AXIS_DESCR||Specifies 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_DIST||AXIS_DESCR||Specifies 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_LIST||AXIS_DESCR||Explicitly specifies the sample point values of the axis of type FIX_AXIS.|
|FIX_NO_AXIS_PTS_X / _Y / _Z / _4 / _5||RECORD_LAYOUT||Specifies the number of axis points. This number is fixed and not stored in memory.|
|FNC_VALUES||RECORD_LAYOUT||Specifies position, datatype, orientation and addressing method to store table data in the record layout.|
|FORMAT||AXIS_DESCR, AXIS_PTS, CHARACTERISTIC, MEASUREMENT||Specifies the display format of object values in C-printf notation. Overrules the format parameter in referenced COMPU_METHOD.|
|FORMULA||COMPU_METHOD||Specifies 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_INV||FORMULA||Specifies 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||List of MEASUREMENTs that are bundled in this frame.|
|FUNCTION_LIST||AXIS_PTS, CHARACTERISTIC, MEASUREMENT||Lists the FUNCTIONs in which this object is listed. Obsolete keyword. Please use FUNCTION instead.|
|FUNCTION_VERSION||FUNCTION||String that describes the version of this function.|
|GUARD_RAILS||AXIS_PTS, CHARACTERISTIC||Determines that the outermost values of axes, curves and maps are calculated and cannot be adjusted.|
|IDENTIFICATION||RECORD_LAYOUT||Specifies position and data type of an identification number for the stored object.|
|IF_DATA||AXIS_PTS, CHARACTERISTIC, FRAME, FUNCTION, GROUP, MEASUREMENT, |
|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_MEASUREMENT||FUNCTION||References to MEASUREMENTs that are defined as inputs to this FUNCTION.|
|LAYOUT||MEASUREMENT||Specifies how multidimensional measurement arrays are stored in linear memory. "ROW_DIR" signifies row-major order. "COLUMN_DIR" signifies column-major order.|
|LEFT_SHIFT||BIT_OPERATION||Number of bit positions to shift to the left in a BIT_OPERATION.|
|LOC_MEASUREMENT||FUNCTION||References to MEASUREMENTs that are defined as local variables in this FUNCTION.|
|MAP_LIST||CHARACTERISTIC||Lists the maps which comprise a cuboid.|
|MATRIX_DIM||CHARACTERISTIC, MEASUREMENT||Specifies the dimensions of multidimensional arrays.|
|MAX_GRAD||AXIS_DESCR||Specifies the maximum permissible gradient for this axis.|
|MAX_REFRESH||CHARACTERISTIC, MEASUREMENT||Maximum refresh rate for this object in the control unit.|
|MEMORY_LAYOUT||MOD_PAR||Description of the memory layout of an ECU. Obsolete keyword. Please use MEMORY_SEGMENT instead.|
|MEMORY_SEGMENT||MOD_PAR||Description of one memory segment of the ECU. Includes program type, memory type, location, address, size and offsets.|
|MONOTONY||AXIS_DESCR, AXIS_PTS||Specifies which kind of monotony for the sample values is allowed for this axis.|
|NO_AXIS_PTS_X / _Y / _Z / _4 / _5||RECORD_LAYOUT||Specifies position and datatype of the number of axis points within the record layout.|
|NO_OF_INTERFACES||MOD_PAR||Number of interfaces.|
|NO_RESCALE_X||RECORD_LAYOUT||Specifies position and datatype of the number of rescaling values within the record layout.|
|NUMBER||CHARACTERISTIC||Specifies the number of elements (ASCII characters or values) in a 1D array. Obsolete keyword. Please use MATRIX_DIM instead.|
|OFFSET_X / _Y / _Z / _4 / _5||RECORD_LAYOUT||Specifies 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_MEASUREMENT||FUNCTION||References to MEASUREMENTs that are defined as the outputs of this FUNCTION.|
|PHONE_NO||MOD_PAR||Phone number of the responsible calibration engineer.|
|PHYS_UNIT||AXIS_DESCR, AXIS_PTS, CHARACTERISTIC, MEASUREMENT||Specifies the physical unit. Overrules the unit specified in the referenced COMPU_METHOD.|
|PROJECT_NO||HEADER||String that describes a project number.|
AXIS_DESCR, AXIS_PTS, CHARACTERISTIC, USER_RIGHTS
|Specifies read-only access to this tunable parameter or for this user.|
|READ_WRITE||MEASUREMENT||Specifies that write-access is allowed for this MEASUREMENT.|
|REF_CHARACTERISTIC||FUNCTION, GROUP||References to AXIS_PTS or CHARACTERISTIC that are used but not owned by this FUNCTION or which belong to this GROUP.|
|REF_GROUP||USER_RIGHTS||Reference to groups of MEASUREMENTs and CHARACTERISTICs to define the access rights for this group of users.|
|REF_MEASUREMENT||GROUP||Reference to MEASUREMENTs that belong to this group.|
|AXIS_PTS, CHARACTERISTIC, MEASUREMENT||Reference to a memory segment in case the address is not unique, e.g. if overlapping memory segments exist.|
|REF_UNIT||COMPU_METHOD, UNIT||Reference to a physical unit.|
|RESERVED||RECORD_LAYOUT||Specifies a position in this record layout that shall be ignored (i.e. not interpreted).|
|RIGHT_SHIFT||BIT_OPERATION||Number of bit positions to shift to the right in a BIT_OPERATION.|
|RIP_ADDR_W / _X / _Y / _Z / _4 / _5||RECORD_LAYOUT||Specifies 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.|
|ROOT||GROUP||Specifies the root of this GROUP's hierarchy.|
|SHIFT_OP_X / _Y / _Z / _4 / _5||RECORD_LAYOUT||Specifies 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_EXTEND||BIT_OPERATION||Specifies 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_EXPONENTS||UNIT||Specifies the exponents of the seven SI base units to express this derived SI unit.|
|SRC_ADDR_X / _Y / _Z / _4 / _5||RECORD_LAYOUT||Specifies position and datatype of the address of the axis' input value within the record layout.|
|RECORD_LAYOUT||Specifies 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_REF||COMPU_METHOD||Reference 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_SIZE||AXIS_DESCR, AXIS_PTS, CHARACTERISTIC||Specifies an increment value that is added or subtracted when using the up/down keys while calibrating.|
|SUB_FUNCTION||FUNCTION||Reference to other FUNCTIONs, which are sub-functions of this FUNCTION. Can be used to reproduce the hierarchy of functions in the ECU software.|
|SUB_GROUP||GROUP||Reference to other GROUPs, which are sub-groups of this GROUP. Can be used to create a hierarchy of group objects.|
|SUPPLIER||MOD_PAR||String that describes the manufacturer or supplier of the ECU.|
|SYMBOL_LINK||AXIS_PTS, CHARACTERISTIC, MEASUREMENT||Reference 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_CONSTANT||MOD_PAR||Specifies name and value of a constant that can be used in FORMULA or FORMULA_INV.|
|UNIT_CONVERSION||UNIT||Specifies slope and offset of a linear formula to convert the referenced unit (REF_UNIT) to this UNIT.|
|USER||MOD_PAR||String that describes the name of the user.|
|VAR_ADDRESS||VAR_CHARACTERISTIC||List 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_CHARACTERISTIC||VARIANT_CODING||Description 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_CRITERION||VARIANT_CODING||Description 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.|
|VARIANT_CODING||Combination of variants that are not allowed.|
|VAR_MEASUREMENT||VAR_CRITERION||Reference 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_NAMING||VARIANT_CODING||Indexing method to distinguish different variants, e.g. "NUMERIC" or "ALPHA".|
|VAR_CRITERION||Reference 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_SEPERATOR||VARIANT_CODING||Separation symbol between the name of a variant coded parameter and the variant extension.|
|VERSION||HEADER, MOD_PAR||String that describes the software version.|
|VIRTUAL||MEASUREMENT||Specifies that this MEASUREMENT is not measured but calculated from the listed input measurements via a COMPU_METHOD.|
|CHARACTERISTIC||Specifies 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.|
ASAMMCD-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 data types as used in the automotive industry.
|8||two's complement integer|
|SWORD||signed||16||two's complement integer|
|SLONG||signed||32||two's complement integer|
|A_INT64||signed||64||two's complement integer|
|FLOAT32_IEEE||signed||32||IEEE 754 single precision|
|FLOAT64_IEEE||signed||64||IEEE 754 double precision|
Thestandard 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.
Thedata 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.
The main advantage of ASAMMCD-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 correspondinga2L-file, which is all that is needed to enable his customer to carry out calibration & measurement tasks.
Sincea2l-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.
Due to this comprehensive and complete coverage of data related tomeasurement 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, ASAMMCD-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.
Thestandard includes the following deliverables:
ASAM offers a checker tool fora2l- 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.
The downloadable archive contains ana2l-file and a referenced transformer- DLL for demonstration purposes. The archive also includes matching data files, such as an cdfx-file, an mf4-file and a HEX-file. The data in the HEX-file can be read by the transformer DLL.
ZIP-archive including files for thestandard formats a2l, cdfx and mf4.