The first ASAMstandard in the measurement and calibration area, ASAM MCD-2 MC (formerly ASAP2), was released in the late 1990th 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 ASAMCDF 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 MSRSWDTD 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 thestandard 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 ASAMCDF 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.
ASAMCDF 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 ASAMCDF 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 uponXML notation. The standard includes a schema definition file (. xsd) and a document type definition file (. dtd) for formal file validation.
ASAMCDF 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.
TheXML-structure of a cdfx-file consists of nine major levels, with the sixth level containing the actual parameters.
<MSRSW> is the root element, which may contains a short name (<SHORT-NAME>) and a category (<CATEGORY>). The category value indicates thestandard and version number, e.g. the value "CDF20" denotes ASAM CDF V2.0.
The next level is the <SW-SYSTEM> element, which contains one or multiple systems for which the cdfx-file holds thecalibration data. The purpose of this element is to allow the calibration data for multiple ECUs, multi-processor ECUs or multicore-CPU ECUs to be put into one cdfx-file. One set of calibration data for one unit is contained in one <SW-SYSTEM> element.
The <SW-SYSTEM> layer aggregates <SW-INSTANCE-SPEC> for formal reasons. This keeps theXML-structure of CDF the same as for other MSRSW-based standards.
The next level is the <SW-INSTANCE-TREE> element, which contains one instance ofcalibration data for the system. Different calibration data sets have to be stored in different files and are distinguished by different short names of the instance tree. The aggregated element <SW-INSTANCE-TREE-ORIGIN> contains the information from which sources the instance tree was created. <CATEGORY> indicates, whether the calibration parameters of the instance tree are variant coded. <SW-CS-COLLECTIONS> can document the calibration history for functions or groups of functions of this instance tree.
The most important element of the instance tree is <SW-INSTANCE>. This element represents one parameter. Each parameter must have a short name for identification. This short name is the reference to description of the parameter in an ASAMMCD-2 MC or ASAM MDX file. If <SW-INSTANCE> is aggregated by another <SW-INSTANCE> that is an array, then this element must also have the <SW-ARRAY-INDEX> element, instead of only a short name to identify the element's position in the array.
Other aggregated elements of <SW-INSTANCE> are:
They are described in the next sub-chapters.
ASAMCDF 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:
Arrays of elements are not supported by ASAMMCD-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 ASAMMCD-2 MC. The category values in ASAM CDF and ASAM MDX are identical.
|CDF Category||MCD-2 MC Parameter||Description|
|VALUE||VALUE||Scalar or enumerated type|
|DEPENDENT_VALUE||DEPENDENT_CHARACTERISTIC (Keyword)||Calculated value, not stored in ECU memory|
|VAL_BLK||VAL_BLK||Array, up to 3 dimensions|
|CURVE_AXIS||CURVE_AXIS||Shared axis rescaled (i.e. normalized) by a curve|
|RES_AXIS||RES_AXIS||Shared axis rescaled (i.e. normalized) by another axis|
|VALUE_ARRAY||n/a||Array of arrays|
|CURVE_ARRAY||n/a||Array of 1D tables|
|MAP_ARRAY||n/a||Array of 2D tables|
|STRUCTURE_ARRAY||n/a||Array of structures|
Each parameter is typically declared and owned by a function (ASAMMCD-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 bycalibration 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 bycalibration 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:
The precision of a physical value in the cdfx-file must be high enough so that the original implementation value can be calculated. When theCDF-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.
The development state of the parameter. Defined states are:|
• changed: value has been changed and state has to be re-determined
• -: default value
• prelimCalibrated: value was determined by other means than tests with the ECU in the loop
• calibrated: value was determined with the ECU in the loop
• checked: value is considered as optimal
• completed: value is considered as ready for production
The standard allows to define more values for describing the state to reflect specific, internal process needs. However, for common understanding it is recommended to use only the defined state values, if different companies are involved in the calibration process.
|<DATE>||Date of change in ISO 8601-format|
|<CSUS>||Name of the user, who defined the state of the parameter|
|<CSPR>||Name of the project|
|<CSWP>||Name of the work package within the project, in which the current value was determined|
|<CSTO>||Identification of the used test object|
|<CSTV>||Identification of the used test object variant|
|<CSPI>||Identification of the used ECU software|
|<CSDI>||Identification of the used dataset|
|<SD>||Special data, name specified via the GID-attribute, meaning is described via the SI attribute|
<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:
Those elements may hold process-specific values. Sincecalibration processes are typically very specific to companies, application domains and technical systems, the standard does not define specific values for <CATEGORY> and <FLAG>.
ASAMCDF 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>.
Thisvariant coding method is compatible with the variant coding methods of ASAM MCD-2 MC and ASAM MDX.
Thedata 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 acalibration tool chain and my impede interoperability. It is advisable to not use them in multi-company collaborative development projects.
Thestandard 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 theMCD 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 ASAMCDF is the calibration of ECU software.
All majorcalibration 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.
Thestandard 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.
Thestandard includes the following deliverables:
The downloadable archive contains a cdfx-file and the correspondinga2l-file for demonstration purposes. The archive also includes further files that are typically used in an ECU measurement and calibration project.
ZIP-archive including files for thestandard formats a2l, cdfx and mf4.