Pagetree

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.

Datasheet
TitleMeta Data Exchange Format
CategoryAE

Current Version

1.3.0
Release Date25.06.2015
DownloadASAM MDX V1.3.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

xml

 

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.

Main contributors to the standard are Audi AG, Continental Automotive AG, MAN Truck & Bus AG, Robert Bosch GmbH, Visu-IT! GmbH, Volkswagen AG and XI-Works.

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 ElementDescription
<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 ElementDescription
<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 ElementDescription
<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.

 

Top-level  structure of an MDX-file

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

 

Base structure of <SW-SCHEDULING-SPEC>

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

 

Base structure of <SW-DATA-DICTIONARY-SPEC>

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 ElementDescription
<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>
  • REFERENCE: address, which points to another data object in ECU memory
<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 2nd-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_NIT8: 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

 

Base structure of <SW-COMPONENT-SPEC>

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 ElementDescription

<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

 

Base structure of <SW-COLLECTION-SPEC> for application groups

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.

 

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

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

 

Base structure of <SW-CPU-SPEC>

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 ElementDescription

<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.

List of Deliverables

The standard includes the following deliverables:

  • User's Guide
  • XSD and DTD schema files
Skip to end of metadata
Go to start of metadata

Back to Top