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
- 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.
|Title||Meta Data Exchange Format|
|Download||ASAM MDX V1.23.0|
Software architecture development
ECU data definition
Automated code generation
Automated document generation
- Data model specification
- XML schemata and DTD
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.