ASAM CDF

The first ASAM standard in the measurement and calibration area, ASAM MCD-2 MC (formerly ASAP2), was released in the late 1990^th and became a great success. This standard describes measurement and calibration data. ASAM MCD-2 was quickly adopted by tools in the MC area. However, the actual calibration parameter values continued to be stored in proprietary formats such as CSV or DCM.

To fill this gap, the ASAM community developed the ASAM CDF standard in the early 2000s. Version 1.0 was released by the end of 2002. Unlike ASAM MCD-2 MC, CDF used XML, which was not yet very widely accepted in the automotive industry. Furthermore, XML lacked some important features. As a consequence, the standard was not well received and had almost no tool support in the following years.

For version 2.0, the working group completely abandoned version 1.0 and used the MSRSW DTD 3.0 as the starting point for the new version. The group incorporated data descriptions from ASAM MCD-2 MC and took over the quality meta data description from the proprietary format PaCo. The standard also included a new User's Guide with many examples how to create CDF XML code based upon data descriptions from ASAM MCD-2 MC and ASAM MDX. Version 2.0 was released in 2006 and turned out to be a very stable and successful release until today.

Version 2.1 incorporated changes to make the standard compatible with ASAM MCD-2 MC 1.7. For example, the changes include support for structured data types, BLOBs, look-up tables with three to five dimensions (CUBOID, CUBE_4, CUBE_5) and model links. The latter allows to re-import changed calibration values into models of simulation and graphical programming tools.

The main motivation for ASAM CDF was to close the gap in the MC-standards portfolio of ASAM with a standard that stored calibration parameter values and associated meta data. Together with ASAM MCD-2 MC and ASAM MDF, those three standards completely cover the data handling of MC tools. The standard should furthermore replace company-proprietary storage formats and the corresponding importers, exporters and converters. ASAM ensures that those three standards are always aligned with each other and that data exchange of compliant tools is seamless and does not involve conversions or data loss.

ASAM CDF is purpose-made for calibration of ECU software.  The sole use is in this area. Calibration tools store parameter values in CDF format. Calibration data management tools are able to import them into their internal database. Calibration data is being exchanged between different companies, using ASAM CDF. Other application scenarios include the automated generation of reports and documentation that include parameter values and their meta data. Model-based design tools may import CDF-files to calibrate controller models.

The file extension of ASAM CDF compliant description files is either "cdfx" or "xml".

The file should be encoded in the UTF-8 character set. UTF-8 allows the use of non-Latin characters like Chinese or Japanese, which is useful in descriptive texts inside the cdfx-file such as descriptions <LONG-NAME> and remarks <REMARK>.

The internal format of cdfx-files is based upon XML notation. The standard includes a schema definition file (.xsd) and a document type definition file (.dtd) for formal file validation.

ASAM CDF is tightly coupled with ASAM MCD-2 MC and ASAM MDX. The ASAM CDF User's Guide describes with many examples, how entries of parameter values defined in ASAM MCD-2 MC or ASAM MDX files are supposed to be expressed in ASAM CDF files.

Other aggregated elements of <SW-INSTANCE> are:

• <CATEGORY>: type of parameter
• <SW-FEATURE-REF>: reference to a function or feature
• <SW-VALUE_COUNT> and <SW-AXIS-CONTS>: value representation
• <SW-CS-HISTORY>: quality meta data
• <SW-CS-FLAGS>: process meta data
• <SW-INSTANCE-PROPS-VARIANT>: variant coding

They are described in the next sub-chapters.

ASAM CDF and ASAM MDX support arrays of elements of the types VALUE_ARRAY, CURVE_ARRAY, MAP_ARRAY and STRUCTURE_ARRAY. Each element of the array is identified and accessible via the <SW-ARRAY-INDEX> element . The arrays must meet the following conditions:

• each element of the array must have the same structure of types
• tables in CURVE_ARRAY and MAP_ARRAY must use the same axis types or reference the same axes

Arrays of elements are not supported by ASAM MCD-2 MC.

The type of the parameter is described in <SW-INSTANCE> and identified by the <CATEGORY> element. The following table lists the available types. The table also shows the corresponding category values for the CHARACTERISTIC and AXIS_DESCR keywords in ASAM MCD-2 MC. The category values in ASAM CDF and ASAM MDX are identical.

Each parameter is typically declared and owned by a function (ASAM MCD-2 MC) or feature (ASAM MDX) of the ECU application software. The standards ASAM MCD-2 MC and ASAM MDX define the names of the functions or features, respectively. The same names can be stored in cdfx-files for each <SW-INSTANCE> under the aggregated element <SW-FEATURE-REF>. This definition provides a link between parameter descriptions, their values and their owner-functions or owner-features.

The actual values of each parameter are stored in the element <SW-AXIS-CONT> for axes and <SW-VALUE-CONT> for all other parameter types. Those elements aggregate the mandatory element <SW-VALUES-PHYS>. The element name indicates that a cdfx-file shall store physical values instead of implementation values. Physical values have a unit and are easily understood by calibration engineers. CDF-processing tools must convert between physical values and implementation values as stored in ECU memory. The conversion is described via the COMPU_METHOD keyword in a2l-files (see ASAM MCD-2 MC) or the COMPU-METHOD element in MDX-files (see ASAM MDX).

Optionally, the <VG> element can be used as the next aggregation to arbitrarily group values. This grouping can be used by calibration systems for arranging the data on a display.

The final level of aggregation holds the <V> element for each individual parameter value, indicating that it is a numerical value, or <VT>, indicating that it is a textual value (i.e. a string). Numerical values can be represented in the following formats:

• decimal, e.g. 123456.789
• exponential, e.g. 12346e-5
• hexadecimal, e.g. 0xFF3E
• binary, e.g. 0b1010011

The precision of a physical value in the cdfx-file must be high enough so that the original implementation value can be calculated. When the CDF-processing tool is not able to reach the necessary precision, then the "PW" attribute in <SW-INSTANCE> shall be set to the value "NOT-PRECISE".

Special floating-point values such as NaN, −∞ and +∞ are not supported. Corresponding value entries are to be left empty in cdfx-files.

Each parameter may include a set of optional meta data that allows to infer the quality of its value. This is done via the aggregated elements <SW-CS-HISTORY> and <SW-CS-ENTRY>. The following table lists the quality meta data that can be stored for each parameter.

<STATE>, <DATE> and <CSUS> are mandatory elements for each entry.

The <SW-CS-ENTRY> entries are sorted. The most current entry is at the top of the <SW-CS-HISTORY> list.

Calibration tools use this data to show the state, origin and test environment that was used for the determination of the value for each parameter. The meta data is also often used to create reports and statistics. For example, the progress of a project can be presented in a pie chart, in which each segment represents a state and the number of parameters in this state. Engineers and managers can quickly assess the overall progress and maturity of the calibration project.

For each parameter the <SW-INSTANCE> may include a set of optional elements for process-related meta data. This data is aggregated via the element <SW-CS-FLAG>.  The element may include <CSUS>, <DATE> and <REMARK>, as described in the previous chapter. Two further elements are available:

• <CATEGORY>: type of process meta data
• <FLAG>: value of meta data, depending on the category

Those elements may hold process-specific values. Since calibration processes are typically very specific to companies, application domains and technical systems, the standard does not define specific values for <CATEGORY> and <FLAG>.

ASAM CDF allows to express selectable variants of parameter values. If <SW-INSTANCE-TREE> has the <CATEGORY> value "VCD", then this denotes that all parameters <SW-INSTANCE> within this instance tree may have more than one value. Every <SW-INSTANCE> must aggregate the <SW-INSTANCE-PROPS-VARIANT> element. The <SW-INSTANCE-PROPS-VARIANT> element aggregates the elements for the definition of values and additionally includes one or several elements of <SW-VCD-CRITERION-VALUE>, which is used to distinguish different variants of the parameter value instance via criterion parameters. If a parameter value shall have no variants, then the <SW-VCD-CRITERION-VALUE> element is just omitted underneath <SW-INSTANCE-PROPS-VARIANTS>.

This variant coding method is compatible with the variant coding methods of ASAM MCD-2 MC and ASAM MDX.

The data model of ASAM CDF is appropriate for most of the calibration processes in the automotive industry. However, a need could exist for storing data in a cdfx-file, for which no specific place is defined in the CDF data model. The standard allows to store such data in special data groups <SDG>, which is a standard extension mechanism in XML. Such special data groups can be aggregated by any other element of ASAM CDF. <SDG> allows to extend the data model with new data in a structurally standard-compliant way, but whose meaning is not defined by the standard. A <SDG> has a name given by its GID-attribute. <SDG> aggregates an arbitrary number of special data <SD>. <SD> elements have a name via the GID-attribute, too, and their semantic meaning may be further described by the SI-attribute.

Tools are allowed to ignore <SDG>. The tools can import the <SDG> data structure without erroring out. However, the tools most likely will not be able to understand the meaning of the data inside the <SDG> and cannot further process this proprietary data, unless the tool has been specifically developed to identify the GID- and SI-attributes. Consequently, care should be taken by using <SDG>. Information in <SDG> may not be understood by all tools of a calibration tool chain and my impede interoperability. It is advisable to not use them in multi-company collaborative development projects.

The standard belongs to a group of tightly coupled standards that specify interfaces of measurement, calibration and diagnostic systems (MCD). ASAM CDF is associated to ASAM MCD-2 MC and ASAM MDF.  ASAM MCD-2 MC is a file format that stores the description of calibration parameters and measurement data.  MDF is a file format that stores the values of measured variables and associated meta data. ASAM CDF supports all data elements of ASAM MCD-2 MC except CUBOID. Furthermore, ASAM CDF is compatible to ASAM MDX.

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 primary application area of ASAM CDF is the calibration of ECU software.

All major calibration tools have importers and exporters for the format. Proprietary formats still exist in this area such as DCM and CSV. Furthermore, the majority of tools for calibration data management have importers and exporters for ASAM CDF.

The standard is widely accepted for this class of tools. It is desirable that model-based development tools and documentation generators know how to import and export calibration data; however, support for ASAM CDF is still not very common for this class of tools.

The standard includes the following deliverables:

• Reference Guide
• User's Guide
• XSD and DTD schema files
• Example files
   

The downloadable archive contains a cdfx-file and the corresponding a2l-file for demonstration purposes. The archive also includes further files that are typically used in an ECU measurement and calibration project.