ASAM MDX

GET STANDARD

Standards
ASAM MDX

Current Version

More Information

Previous versions

History

Various description formats for specifying software components already existed before the inception of ASAM MDX, e.g. company-specific formats from Bosch and Continental or a first standardization effort from the MSR working group. They were either proprietary, or had technical flaws or were not well documented. Volkswagen and Bosch took the initiative in 2004 by initiating the development of ASAM MDX to develop a public Standard that overcomes the shortcomings of earlier description formats. The goal was to create a well-documented, public Standard for the description of SW-components of an ECU, their interfaces and all owned data elements. The baseline for the development of ASAM MDX was the ASAM internal Standard MSRSW DTD 3.0 and Bosch's PaVaSt Specification. The first version of ASAM MDX was released in 2006. The subsequent version 1.1. got extended with Specification means for tasks and scheduling. Version 1.2., released in December 2012, allows to specify prototypes and interface mappings between different software systems.

Motivation

Several trends in embedded, automotive software development motivated OEMs and suppliers to create and use ASAM MDX. The most important trends are:

Software development becomes an increasingly distributed process between OEM, system suppliers and engineering service providers.
OEMs increasingly focus on the design of software architectures and data definitions
Software architectures and data definitions are typically stored in OEM-proprietary database systems
Function and software development jobs are more and more outsourced to system suppliers and engineering service providers
Software has to be tested and validated as partial subsystems, without having access to the complete source code base for the project
Software integration and software builds are carried out without compiled sources

All these trends require, that software components and their data can be formally and unequivocally described in a Specification, and then distributed to all involved parties. Furthermore, the description must be machine-readable, yet understandable for software engineers and architects. This is a pre-requisite to keep such highly distributed software development processes manageable, seamless and relatively free from communication errors. ASAM MDX fulfills those pre-requisites and thus enables more collaboration in embedded software development than ever seen before in the automotive industry.

Application Areas

ASAM MDX is an exchange format of universal use in the software development process for automotive ECUs.

Software architects from an OEM are typically the origin and the creators of ASAM MDX-files. In a typical top-down workflow, software architects create an overall software architecture of software components that run on an ECU. Furthermore, they specify data that is owned, used or private to the software components. Many further properties of the software system may be specified, e.g. Calibration parameters, computation methods, units, tasks, scheduling information and so on. This is done in software architecture tools and databases. Such tools typically have an MDX-exporter. Once a software system for an ECU is defined, the information needs to be disseminated to subsequent development processes via generated MDX-files. This is the primary Use-Case for ASAM MDX.

Recipients of MDX-files can be essentially every other person and tool involved in the software development process. Software developers use the file to know the exact function signature, interface description and available data for the functions that they are supposed to implement. The MDX-file can be an input to a model-based design tool to generate model-stubs or to a code-generator to create code-stubs. MDX-files might be used for roundtrip-engineering, so that changes from software engineers are transferred back to all other involved parties, including the responsible architects.

Build managers use MDX-files to integrate code from various sources. This is particularly useful when the source code is not available. MDX-files contains all information that is needed to integrate compiled object code.

In a similar way, MDX-files along with incomplete sources allow test engineers to compile a partial software subsystem for test- and Validation.

Function developers and technical writers use ASAM MDX in conjunction with ASAM FSX to create the technical documentation for the software system. The formal description of the software system is available via the MDX-file, which is then enriched with functional descriptions and the overall documentation structure via the FSX-file. Both file formats together allow generators to automatically generate the technical documentation of the software system.

Most of the data descriptions in MDX-files are equivalent to the data descriptions in A2L-files of the ASAM MCD-2 MC Standard. This means that MDX-files can also be used by application engineers and imported into Calibration tools. However, unlike A2L-files, MDX-files do not contain address information (Address and ECU_ADDRESS) and interface data descriptions (IF_DATA and A2ML). Consequently, MDX-files cannot be a complete substitute for A2L-files.

Technical Content

File Format

The file extension of ASAM MDX compliant description files is "XML".

The file must 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 MDX-file such as in <LONG-NAME> or <DESC>.

The internal format of MDX-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 MDX is tightly coupled with ASAM MCD-2 MC and ASAM CDF. The ASAM CDF User's Guide describes with many examples, how entries of Calibration values defined in ASAM MCD-2 MC or ASAM MDX files are supposed to be expressed in ASAM CDF files.

Common Elements

Elements in ASAM MDX typically aggregate a group of Standard elements. They provide Standard information about the element such as the name or a description. Those elements are described in this chapter and are not repeated in subsequent chapters.

Common Element	Description
<SHORT-NAME>	Unique, meaningful name of the element.
<LONG-NAME>	Brief, headline-style description of the element.
<DESC>	Longer and more detailed description of the element.
<CATEGORY>	Subdivides the meaning of the element in categories.
<ADMIN-DATA>	Administrative data defining the revision history of an element, language and company-specific information.
<SW-SYSCOND>	Defines a condition that evaluates to "true" or "false". In case of "false", the aggregating element shall be omitted.

The <SHORT-NAME> has a crucial function in ASAM MDX. Every identifiable element (i.e. it can be referenced) must have a unique short name. It shall provide an idea about the meaning of the element. The short name is the value of references (unidirectional associations) from other elements to this element. Aggregations of short-named elements will result in a concatenation of short names separated by "/". The Standard demands that all references in an MDX-file must be resolvable.

Structure

The XML-structure of an MDX-file consists of four top levels, which divide the elements of a ECU software architecture up into major groups.

<MSRSW> is the root element, which aggregates the following top-level elements.

MSRSW Element	Description
<CATEGORY>	Has the fixed value "MDX".
<SW-SYSTEMS>	Aggregates exactly one <SW-SYSTEM>, which is used to describe the software inside of an ECU.
<SW-INTERFACE-MAPPINGS>	Map interface variables or software services from one <SW-SYSTEM> to another <SW-SYSTEM>.
<MATCHING-DCIS>	URL to a Document Control Instance file that defines validation rules against which the MDX-file should be checked.

The top-level element <SW-SYSTEMS> can contain exactly one <SW-SYSTEM>. This element describes the software components of the software system, their grouping, scheduling and data, and the CPU that executes the software.

System Element	Description
<SW-SCHEDULING-SPEC>	Description of tasks, assigned processes and execution order of processes within tasks.
<SW-DATA-DICTIONARY-SPEC>	Description of data objects and services of the software system and other elements that further describe these objects.
<SW-COMPONENT-SPEC>	Description of functional objects and associated data, services and other describing elements.
<SW-COLLECTION-SPEC>	Allows to create logical groups of tasks, features and their data.
<SW-CPU-SPEC>	Description of memory segmentation of the software system.

Details for each element are described in the next sub-chapters.

The top-level element <SW-INTERFACE-MAPPINGS> allows to define a mapping between interface variables and software services of two different <SW-SYSTEM>s. This mapping can be used to create adapter components that allow the integration of software components of one system into the other system. The data structure contains references to source variables or services, references to target variables or services to which the sources shall be mapped to, and a reference to a task that shall carry out the mapping. The Standard allows to define mappings between individual array elements. Optionally, conditions can be defined for mappings.

Scheduling

The system element <SW-SCHEDULING-SPEC> defines the scheduling architecture of a software system by defining tasks, their assigned processes and the execution order of processes within tasks.

<SW-SCHEDULING-SPEC> aggregates <SW-TASK-SPEC>. An attribute in <SW-TASK-SPEC> determines, whether the execution order of processes within the task is recommended or mandatory. <SW-TASK-SPEC> aggregates <SW-TASKS>, which aggregates one or multiple <SW-TASK>. The element <SW-TASK-DEADLINE> underneath determines the maximal allowed response time of the task.

One task is a collection of ordered <SW-PROCESS-LISTS> containing one or multiple <SW-PROCESS-LIST>. Such lists of processes shall ensure a specific execution order grouping. Processes in a process list that are further back in position shall be executed after processes in a process list that are further in a front position within <SW-PROCESS-LISTS>. One <SW-PROCESS-LIST> contains the <SW-SERVICE-REFS> element that contain one or multiple ordered <SW-SERVICE-REF> elements, which are references to services. In ASAM MDX, <SW-SERVICE> is the smallest, schedulable unit that cannot be further subdivided for scheduling purposes. In C programming, a service is implemented as a function.

This structure allows to create an elaborate scheduling architecture with tasks and processes, where the execution order of processes within tasks can be grouped and ordered. Furthermore, <SW-SYSCOND> elements for <SW-TASK>, <SW-PROCESS-LIST> and <SW-SERVICE-REF> allow to conditionally enable or disable the existence of such elements in the scheduling architecture. This allows that variants in the software architecture are also reflected in the scheduling architecture.

Data Dictionary

The system element <SW-DATA-DICTIONARY-SPEC> defines data objects and services of the software system and other elements that further describe these objects. A software system has one global data dictionary, which describes globally available data and services. Each software component of the software system has an optional local data dictionary, which describes internal data. Local data dictionaries have their own name space, i.e. the short names of their elements only have to be unique within that local data dictionary.

The primary purpose of a data dictionary is to define data once, which is then shared among multiple objects in the software system. Typically, elements of the global data dictionary are referenced by software components via <SW-COMPONENT-SPEC> for defining owned elements, imported interface elements and exported interface elements (see subchapter "Software Component").

The data dictionary holds the definitions of the elements as per the following table.

Data Dictionary Element	Description
<UNIT-SPEC>	Defines physical units that can be referenced by <SW-VARIABLE>, <SW-CALPRM> and <COMPU-METHOD>. Units shall be stated according to the seven standardized base units (amount of substance, electric current, length, mass, luminous intensity, temperature, time) from the International System of Units (SI). <UNIT-SPEC> supports SI based units described by exponents of the seven base units as well as derived units described by a referenced unit and a linear conversion method.
<SW-VARIABLES>	Defines variable data which is calculated, transmitted or received by the software system during runtime of the ECU. The Standard distinguishes between three implementation types of variables, which is identified via the <SW-IMPL-POLICY> element: STANDARD: global variable, used for exchange of data between services on one ECU, data consistency is not guaranteed MESSAGE: global variable, used for exchange of data between services on one ECU or between multiple ECUs, data consistency is checked and guaranteed in specific circumstances MEASUREMENT-POINT: variable that is accessible for a MC-system, services can only write to measurement-point variables and have no read-access The Standard distinguishes between eleven data types of variables, which is identified via the <CATEGORY> element: VALUE: scalar or enumerated type BOOLEAN: boolean, stored as byte or word ASCII: string BIT: single bit, either as part of a HOST-type variable or as a direct addressable bit HOST: scalar that contains packed bit data UNION: union type STRUCTURE: structured type VALUE_ARRAY: array of arrays STRUCTURE_ARRAY: array of structures TYPED_VALUE: type defined via a referenced <SW-CLASS>
<SW-CALPRMS>	Defines parametric data with read-only access by the software system and with read-write access by an MC-system. Calibration parameters are typically determined during the Calibration process. The Standard distinguishes between nineteen data types of variables, which is identified via the <CATEGORY> element: VALUE: scalar or enumerated type BOOLEAN: boolean, stored as byte or word ASCII: string VAL_BLK: array CURVE: 1D table MAP: 2D table CUBE_3: 3D table CUBE_4: 4D table CUBE_5: 5D table COM_AXIS: Shared axis RES_AXIS: Shared and rescaled (i.e. normalized) axis by another axis UNION: union type STRUCTURE: structured type VALUE_ARRAY: array of arrays CURVE_ARRAY: array of 1D tables MAP_ARRAY: array of 2D tables STRUCTURE_ARRAY: array of structures TYPED_VALUE: type defined via a referenced <SW-CLASS> DEPENDENT_VALUE: calculated value, not stored in ECU memory
<SW-SYSTEMCONST>	Defines parametric data similar to Calibration parameters, but with differences in two aspects: their definition includes a value the values can be used before runtime, i.e. for conditional compilation, as a preprocessor value or for code generation Typical use-cases for system constants are to set an array size, set the number of cylinders of an engine, set the value of a scientific constant such as π, set a time base value or set a physical conversion factor. The Standard distinguishes three types of system constants, which is identified via the <CATEGORY> element: FIXED: fixed value STABLE: value may be changed for different projects, value range defined via <DATA-CONSTR-REF> ADJUSTABLE: value must be decided for each project, value range defined via <DATA-CONSTR-REF>
<SW-CLASS-INSTANCES>	Defines an instantiation of variables or calibration parameters whose type is defined by <SW-CLASS>. The standard distinguishes between two types of instantiation: STRUCTURE: instantiates a structure of variables or a structure of calibration parameters CLASS_INSTANCE: instantiates a variable as a structured type or calibration parameter as a structured type
<COMPU-METHODS>	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 <SW-VARIABLE> or <SW-CALPRM>. 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, or may displays discrete data such as error codes as text strings. Supported conversion methods are: IDENTICAL: no conversion LINEAR: 2-coefficient function with slope and offset RAT_FUNC: 6-coefficient rational function with 2^nd-degree numerator and denominator polynomials TAB_INTP: table with interpolation TAB_NOINTP: table without interpolation TEXTTABLE: verbal table (i.e. enumeration) of value/string pairs BITFIELD_TEXTTABLE: verbal table of bit-mask/string pairs For all methods, <COMPU_METHODS> allow to define both conversion directions: physical format to internal format and vice versa. Other properties describe the display format (in C-printf notation) and reference to a unit.
<SW-ADDR-METHODS>	Describes how a variable or calibration parameter is addressed by the software. The short name of <SW-ADDR-METHODS>typically indicates a specific use that is recognized by tools such as compilers or code generators. Other aggregated elements provide further descriptions, such as a reference to a memory segment <SW-CPU-MEM-SEG-REF>, a pattern of the memory allocation keyword <MEMORY-ALLOCATION-KEYWORD-POLICY>, initialization <SECTION-INITIALIZATION-POLICY> or the type of memory section <SECTION-TYPE>.
<SW-RECORD-LAYOUTS>	Describes how structures of calibration parameters, including axes, are stored in memory. It describes order, position, type of values, type of axis and other properties of calibration objects in memory.
<SW-CODE-SYNTAXES>	Defines the representation of objects in the program source code via the short name. The short name of <SW-CODE-SYNTAXES> is recognized and used by tools such as compilers or code generators.
<BASE-TYPES>	Defines how variables, Calibration parameters and other data-typed objects are stored in memory. The Standard defines the following base types: A_VOID: pseudo type for non-existing elements A_BIT: one bit A_UNIT8: unsigned integer 8-bit A_UINT16: unsigned integer 16-bit A_UINT32: unsigned integer 32-bit A_INT8: signed integer 8-bit, two's complement A_INT16: signed integer 16-bit, two's complement A_INT32: signed integer 32-bit, two's complement A_INT64: signed integer 64-bit, two's complement A_FLOAT32: IEEE 754 single precision A_FLOAT64: IEEE 754 double precision A_ASCIISTRING: string, ISO-8859-1 encoded A_UTF8STRING: string, UTF-8 encoded A_UNICODE2STRING: string, UCS-2 encoded A_BYTEFIELD: Field of bytes Fixed- and variable-length bit-widths can be defined. Other storage properties are defined such as bit-width, encoding, memory-alignment and endianess.
<DATA-CONSTRS>	Defines upper and lower value limits for variables and calibration parameters. Limits can be expressed as an internal format or in a physical format. The limits are either open (value is inside the allowed value range), closed (value is outside the allowed value range) or infinite (no limit). Multiple limits can be expressed within one <DATA-CONSTR>.
<SW-AXIS-TYPES>	Defines the formula to calculate axis points for an axis of category "FIX_AXIS". As opposed to other axis types, the axis points of fixed-axes are not stored in memory but are rather calculated during run time of the software system. The Standard allows two types of fixed-axis calculation: via formula: axis points are calculated via a defined formula, e.g. X[i] = offset + i * (2*shift) via array: axis points are stored in the MDX-file and in the software system Optionally includes a reference to <DATA-CONSTRS>* to define an upper and lower limit for axis values.
<SW-SERVICES>	Describes executable objects of a software system. The Standard defines the following two types of executable objects: PROCESS: C-function without arguments and return values, typically called by the scheduler of an operating system STANDARD: C-function with arguments and/or return values, typically called by processes (i.e. functions of the type "PROCESS") The properties of arguments and the return value are described in detail, so that the function interface is fully defined. Furthermore, external variables and Calibration parameters accessed by this service are described. Pointers are supported. A service may call other services, which can be expressed within <SW-SERVICES> as well. Three execution and implementation properties of the service are defined. The <SW-SERVICE-REENTRANCE> element allows to define the service as a reentrant function. <SW-IMPLEMENTS-CALLBACK> allows to define the service as a callback function. <SW-IMPL-POLICY> allows to define the implementation of the function in source code: STANDARD: implementation as regular function INLINE: implementation as an inline function, i.e. for which the compiler is requested to perform an inline expansion MACRO: implementation as a macro, i.e. as a pre-compiler textual search-and-replace token
<SW-CLASSES>	Defines types for variables or Calibration parameters. The Standard defines the following types of types: TYPEDEF_SIMPLE: redefined base type or defined complex type TYPEDEF_STRUCT: structured type definition TYPEDEF_UNION: union type definition TYPEDEF_ENUM: enumerated type definition SIMPLE_MODEL: variable prototype or calibration parameter prototype STRUCTURE_MODEL: structure of variables or structure of calibration parameters CLASS: combines variables, calibration parameters, class instances and services to one class

Software Component

The system element <SW-COMPONENT-SPEC> defines functional objects and associated data, services and other describing elements. A <SW-COMPONENT-SPEC> contains one <SW-COMPONENTS> element. This aggregates one or multiple <SW-FEATURE> elements. A feature is an aggregation of elements that implement one functionality in a software system. Those elements are further subdivided in interfaces and owned elements as described in the next table.

Feature Element	Description
<SW-FEATURE-VARIANT>	Marks the feature as a variant.
<SW-DATA-DICTIONARY-SPEC>	Defines a local data dictionary of data objects, services and other descriptive elements that are only defined and used by this feature. Other features have no access to them.
<SW-FEATURE-OWNED-ELEMENT-SETS>	Lists of references to elements in the global data dictionary that are owned by this feature. One element in the global data dictionary can only be owned by exactly one feature. A feature can own the following elements: SW-CALPRM SW-VARIABLE SW-AXIS-TYPE SW-SERVICE SW-SYSTEMCONST SW-CLASS-INSTANCE SW-CLASS COMPU-METHOD DATA-CONSTR For a description of those elements, please refer to the preceding chapter "Data Dictionary".
<SW-FEATURE-INTERFACES>	Lists of references to elements in the global data dictionary that are either imported (i.e. used) by this feature or exported by this feature (i.e. used by other features). Exported elements must be owned by the feature, i.e. they must be listed in <SW-FEATURE-OWNED-ELEMENT-SETS> as well. Imported elements must have been exported by another feature. The complete <SW-FEATURE-INTERFACES> list constitutes the interface of this feature towards other features of the software system. A feature can import and export the following elements: SW-CALPRM SW-VARIABLE SW-AXIS-TYPE SW-SERVICE SW-SYSTEMCONST SW-CLASS-INSTANCE SW-CLASS COMPU-METHOD DATA-CONSTR For a description of those elements, please refer to the preceding chapter "Data Dictionary".

Collection

The system element <SW-COLLECTION-SPEC> allows to create logical groups of tasks, features and their data. Typical use-cases for collections are to group objects together, which control one hardware component, which shall be jointly calibrated, which are developed by one external party or which belong to one specific criticality level. Tools can use this grouping for displaying or processing data that logically belong together.

The element <SW-COLLECTION-SPEC> aggregates <SW-COLLECTIONS>, which contains one or multiple <SW-COLLECTION>s of the <CATEGORY> "APPLICATION_GROUP". One <SW-COLLECTION> may references other collections, so that a collection hierarchy can be set up. The actual content of a collection is defined by <SW-COLLECTIONS-CONT>. It aggregates an arbitrary number of element references:

<SW-FEATURE-REFS>
<SW-VARIABLE-REFS >
<SW-CALPRM-REFS >
<SW-CLASS-REFS >
<SW-CLASS-INSTANCE-REFS >
<SW-SYSTEMCONST-REFS >
<SW-TASK-REFS >

The collection consist of those referenced elements.

The Standard also describes a way how collections can be used to resolve read/write conflicts for specific scheduling scenarios. It allows to specify that a process can read a variable before it has been written by another process of the same task.

Base structure of <SW-COLLECTION-SPEC> for read/write conflict resolutions

The element <SW-COLLECTION-SPEC> aggregates <SW-COLLECTIONS>, which contains one or multiple <SW-COLLECTION>s of the <CATEGORY> "DY-ALLOW-READ-BEFORE-WRITE" or " DY-FORCE-READ-BEFORE-WRITE ". The aggregated element <SW-COLLECTIONS-CONT> determines the read/write conflict scenario:

<SW-FEATURE-REFS>: Feature that the reading process belongs to
<SW-SERVICE-REFS >: Reading process
<SW-VARIABLE-REFS >: Variables of the process that cause the read/write conflict
<SW-TASK-REFS >: Task that owns the reading and writing processes and the affected variables

Read-access before write-access is allowed in the scenarios described in those collections.

CPU

The system element <SW-CPU-SPEC> allows to define the memory segmentation of the ECU's address space, including CPU-internal and external memory.

The element <SW-CPU-SPEC> aggregates <SW-CPU-MEM-SEGS>, which contains one or multiple <SW-CPU-MEM-SEG>s. One <SW-CPU-MEM-SEG> contains the description of one memory segment as defined in the following table.

CPU Element	Description
<SW-MEM-PROGRAM-TYPE>	Defines the content of the memory segment. CODE: Program code DATA: Calibration parameters which can be used for online calibration OFFLINE_DATA: Calibration parameters which can only be used for offline calibration RESERVED: Reserved segment VARIABLES: Variables SERAM Data for serial memory emulation CALIBRATION_VARIABLES: Calibration parameters in ECU memory, which are not uploaded with a hex-file EXCLUDE_FROM_FLASH: Calibration parameters in ECU memory, which are not uploaded with a binary file
<SW-MEM-TYPE>	Defines the storage technology of the memory segment. RAM EEPROM EPROM ROM REGISTER CPU FLASH
<SW-MEM-ATTR>	Defines the location of the memory segment relative to the CPU. INTERN EXTERN
<SW-MEM-BASE-ADDR>	Defines the base address of the memory segment.
<SW-MEM-SIZE>	Defines the size of the memory segment.
<SW-MEM-OFFSETS>	Defines the offset values in case of mirrored memory segments.

Relation to Other Standards

The Standard belongs to a group of tightly coupled standards that specify interfaces of Measurement, Calibration and diagnostic systems (MCD). ASAM MDX and ASAM MCD-2 are harmonized standards, which means that both standards use the same semantics for the same elements. Their data can be converted into each other format via 1-to-1 mappings. However, since both standards serve different use-cases, they contain some data descriptions, which are missing in the other Standard.

ASAM MDX and ASAM MCD-2 MC are furthermore associated with ASAM CDF and ASAM MDF, which are file formats that store the values of Calibration parameters and Measurement variables defined by them.

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.

Industry Adoption

Implementations of ASAM MDX are mostly encountered in data management and documentation generators. OEMs and system suppliers still use in-house developed tools for this purpose. They are mostly implemented based upon Database systems and use ASAM MDX for data import and export. Other tools like generators for system specifications and functional documentation use ASAM MDX importers. They merge information from other sources, e.g. from ASAM FSX files, to generate the technical documentation. ASAM MDX is used in automotive companies like Volkswagen AG, Audi AG, Daimler AG, MAN Truck & Bus AG and Robert Bosch GmbH.

ASAM MDX has strongly influenced the development of the AUTOSAR Software Component Template (SWC-T). Many elements of both standards are semantically identical. They serve essentially similar use-cases, with the AUTOSAR SWC-T having some more means to express the component architecture of an ECU software system. Consequently, ASAM MDX is typically used for non-AUTOSAR projects and the SWC-T is used for AUTOSAR projects.