Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

ASAM MDX defines a description format for the software architecture and data definition of the software of an automotive ECU. The standard supports highly distributed development processes for ECU software, where software is generated by different organizations and with different tool chains in a multi-tier development process. The software architecture and data definition is typically defined by a software architect at OEM-level and then disseminated down the supply-chain for functional development, implementation, calibration, integration and testing. All instances of this development process must work with exactly the same architecture and data definition specification, so that the software components will actually fit together. Errors in communication and understanding of the specification can cause integration problems, debugging efforts and long delays, which typically occur at the later, more costly stages of the software development process. This problem worsens, if sources cannot be shared with the integrator due to IP concerns. Repetitive problems with software integration are one of the major causes of ECU projects running out of time and budget.

To solve this problem, automotive companies have defined a description format via the ASAM MDX standard, which describes software components, their interfaces, owned data and scheduling in a standardized XML-format. ASAM MDX contains the following definitions for software components and data:

  • Software components, -features and -services
  • Scheduling
  • Variables, calibration parameters and system constants
  • Base-types and stereotypes
  • Type definitions for structures, enumerations and unions
  • Units, constraints, computation methods, address methods and much more data properties
  • Groupings and mappings of description data to support various development processes
  • Variants of the definition for software components and data

This format allows the user to unequivocally specify all architectural and integration aspects of embedded software components. OEMs have the advantage that they can link supplied software with the overall system without permanently running into integration issues. Suppliers can hide their know-how by delivering just the object code and MDX-files. The object code can still be linked and calibrated, even though the sources of the supplied software are not known by the integrator. Since MDX is technology- and vendor-independent, it allows all involved parties in a software development process to use the tools of their choice, as long as they are able to import and export MDX-compliant description files.

TitleMeta Data Exchange Format

Current Version

Release Date1025.1206.20122015
DownloadASAM MDX V1.23.0
Application Areas
  • Software architecture development

  • ECU data definition

  • Automated code generation

  • Software documentation

  • Automated document generation

Specification Content

  • Data model specification
  • XML schemata and DTD

File Formats



Table of Contents


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. The current version Version 1.2., released in December 2012, allows to specify prototypes and interface mappings between different software systems.


Back to Top