ASAM MDX
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:
The Standard distinguishes between eleven data types of variables, which is identified via the <CATEGORY> element:
|
| <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:
|
| <SW-SYSTEMCONST> | Defines parametric data similar to Calibration parameters, but with differences in two aspects:
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:
|
| <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:
|
| <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:
|
| <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:
|
| <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:
|
| <SW-SERVICES> | Describes executable objects of a software system. The Standard defines the following two types of executable objects:
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:
|
| <SW-CLASSES> | Defines types for variables or Calibration parameters. The Standard defines the following types of types:
|
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-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:
|
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.
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.
|
| <SW-MEM-TYPE> | Defines the storage technology of the memory segment.
|
| <SW-MEM-ATTR> | Defines the location of the memory segment relative to the CPU.
|
| <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.
List of Deliverables
The Standard includes the following deliverables:
- User's Guide
- XSD and DTD schema files
Follow us on
MEET US AT THE
ASAM International Conference 2024
ASAM is hosting the 6th ASAM International Conference. Join us to discuss the latest developments in automated driving and the software-defined vehicle.
on: Dec 04 - 05, 2024
in: Munich, Germany
Read more
