ASAM MCD-1 POD
History
Commercial-off-the-shelf Measurement & Calibration tools (MC-tools) for automotive ECU development emerged in the mid 90th and quickly replaced in-house developed tools, which were commonly used at that time. The companies ETAS, Vector Informatik and Accurate Technologies quickly gained a substantial market share of today more than 80% in this area. Very early on, standardization work groups came together to define standards for the Measurement & Calibration area. The standards, called ASAP-1, -2 and -3 at that time, specified virtually all interfaces that are external to the ECU. One area was not covered by standards, which is the interface for direct, fast access to the microcontroller's resources via its data- and address bus or the debug Port. Such interfaces are commonly called 'plug-on device' (POD), 'memory emulator module' or 'ETK' (German: Emulatortastkopf). They are highly dependent on hardware and have to meet critical performance requirements. This was probably the primary reason why this area was left out from standardization. Tool vendors created their own PODs, adapted and optimized them for specific hardware (i.e. microcontrollers and debug-interfaces) and delivered them together with the necessary drivers to their customers. Despite the ASAP standards that the marked-leading tools supported early on, this lack of a standardized POD interface made users of commercial MC-tools effectively highly dependent on one tool vendor. They cannot easily switch the PODs from different vendors on one ECU, or connect different tools from multiple vendors to one POD. This led to the status-quo in ECU development that all components of an MC-tool chain typically come from one vendor.
ASAM MCD-1 POD addresses the standardization of the POD driver, called PSS in the Standard: POD Service Software. ASAM started the project in 2014. Experts from ten companies from Europe and the US participated in the project group, supported by two service providers. Japanese OEMs participated during the public review of the Standard. Version 1.0 was released in mid 2017, covering POD configuration, detection, initialization, synchronous Measurement and Calibration. Additional commands and events for the ASAM MCD-1 XCP protocol are specified to support the communication between the POD and connected tools. The Standard reduces the strong dependency from the POD-vendor by making the integration of the PSS into the overall ECU software easier through a standardized API.
Motivation
When changing the POD on an ECU, it is typically required to change the PSS in the ECU software as well. This furthermore requires a new ECU software build and corresponding integration tests. Consequently, swapping PODs and their attached tool chain is not plug-and-play. This practically inhibits the use of multiple Calibration tools within one ECU development project.
With a fully standardized PSS, the POD and attached tools could be exchanged in a plug-and-play manner. The first version of ASAM MCD-1 POD achieves this partially. Major parts of the PSS API are standardized, while there are still vendor-specific parts left over in the PSS. This standardization makes the integration of the PSS from different vendors easier and integration testing is quicker. However, the goal of POD plug-and-play capability is not yet fully achieved.
Application Areas
The primary application area of ASAM MCD-1 POD is in MC-systems. The Standard specifies the ECU driver of a plug-on device (POD) for the purpose to gain access to internal resources of the microcontroller and the ECU. This allows to carry out typical tasks in ECU software development such as Calibration of ECU parameters, logging and Stimulation of ECU-internal variables, and ECU flash programming. The POD and driver might also be used by debugging tools.
The Standard has been created to support the development and easy integration of software drivers for the integration of PODs in ECUs. The Standard also defines a framework for POD configuration via XCP commands and A2L-files. Tool vendors in the area of MC-tools, debuggers, data loggers and rapid control prototyping systems (i.e. bypassing) may decide to implement PODs according to this Standard. ECU software developers and integrators, particularly in the area of basic ECU software, as well as experts in development tools & methods at OEM- and Tier-1-companies, would profit most from using the Standard. The most prominent benefit of having an ASAM-compliant POD in the ECU is the easy software integration and quick exchange of external ECU tools within the same development and testing project.
Technical Content
System Architecture
Plug-on devices (POD) are used in ECU development. A POD is a hardware adapter, which is typically integrated directly on the ECU board and has an interface for direct access to the microcontroller's resources. This interface is typically a debug Port with serial communication. The POD connects the ECU with one or multiple external tools for the purpose to establish communication between the ECU application software (EAP) and the application software of the external tool(s). An external tool is typically a Measurement & Calibration system, a data logger, a rapid control prototyping system for bypassing or a debugger.
The overall system architecture is shown in the figure on the right in an example with two connected tools. The architecture consist of three major components:
- ECU
- POD
- external tool(s)
The ECU interface is specified by other standards, such as BDM, JTAG, Nexus or DAB. This interface requires a driver in the ECU software, called POD Service Software (PSS). The PSS is the primary subject of standardization of ASAM MCD-1 POD. The standardfully defines the API between the EAP and the PSS. Furthermore, some common functions of the PSS are defined, which are shared by all Standard-compliant PODs (ASAM PSS). Other functions remain vendor specific. They use the standardized API, too. However, each POD has their own, vendor-specific implementations of the functions, which must be individually integrated into the ECU software (Vendor PSS). This is necessary to allow for vendor-specific functionality and optimization.
Components of the architecture, which are within the scope of this Standard, are surrounded with a red box in the above figure. They are described in the following table.
Component | Description |
|---|---|
| POD API | Application interface between the EAP and the PSS. |
| ASAM PSS | PSS functions shared by all PODs, e.g. detection of PODs. |
| XCP | XCP protocol, extended with POD-specific commands and events from this standard. |
| A2L | A2L-file, with POD-specific AML interface definition from this standard. |
Components of the architecture, which are out of scope of this Standard, are described in the following table.
None-Standard Component | Description |
|---|---|
| EAP | ECU application software. |
| Vendor PSS | PSS functions, whose functionality is defined and implemented by the POD vendor. Uses the POD API. |
| ECU Interface | Interface between the ECU and POD. Typically a debug port such as BDM, JTAG, Nexus or DAB. |
| POD Adapter | Small embedded board with processor and its own memory. |
| Tools | External tools for ECU development, such as calibration systems, data loggers, rapid control prototyping systems or debuggers. |
The architecture could include multiple PODs from different vendors. Furthermore, other means of communication between the ECU and external tools could be integrated into the overall architecture, for example XCP. This is shown in the figure on the right.
The Standard makes the assumption that only one POD is connected to the ECU at any time. However, the ECU software could have multiple PSSs, which would allow to switch between multiple PODs without the need to create a new ECU software version. The EAP would have to handle this scenario. POD- and PSS-switching is out of scope for this Standard. Furthermore, the communication between the POD and the PSS is proprietary to the tool vendor and the used ECU interface, hence it is out of scope, too.
Supported Technical Use-Cases and Features
The Standard defines three technical use-cases that are required to start and configure the POD. The use-cases are:
- POD Configuration
- POD Detection
- PSS Initialization
The Standard defines two features, which support specific processes that are part of an ECU development process. Those features are:
- Synchronous Measurement
- Calibration
The next chapters describe the technical use-cases and features. They include tables of standardized API functions for the communication between PSS and EAP to support the use-cases and features. If not otherwise stated in the description, then the function is mandatory. Functions are common for all PODs, if their function name starts with the prefix "A_PSS_". Such a function must be integrated only once in the ECU software and can be used by all Standard-compliant PODs from all vendors. If the function name starts with the prefix " <VENDOR>_PSS_", then this is a POD-specific function and can only be provided by the vendor of that POD. Such a function must be integrated for each POD individually in the ECU software and can only be used for this POD exclusively.
POD Configuration
POD configuration is the process to select and activate a specific setup for the system to support a specific work scenario.
External tools need to have concurrent but conflict-free access to the internal resources of the ECU, so that users can carry out their work unaffected by tools that interfere with each other. Furthermore, a POD shall be usable with multiple variants of one ECU. The POD configuration shall ensure this through the definition of 'Configurations'. They are identified via 'Variants' and 'Scenarios'. This overall setup is defined at compile-time, typically by a POD-integrator or tool-administrator in collaboration with tool users. The figure on the right shows an example of two ECU variants with three scenarios and a total of four configurations.
The terms and their corresponding AML keywords for POD configuration are defined in the next table.
Term | AML Keyword | Description |
|---|---|---|
| Variant | VARIANT_ID | A variant describes all resource of an ECU that are available to the POD. Examples for ECU resources are memory, emulation RAM, mailboxes, busses and others. The variant is stored in the EAP through the Variant ID. |
| Scenario | OPERATIONAL_SCENARIO | A scenario is a set of features which can be carried out concurrently and which use resources that do not overlap. Available features are:
|
| Configuration | POD_CONFIGURATION | A configuration is defined for a specific variant and scenario. A configuration is identified by the Configuration ID and contains parameters for the initialization of the resources for the chosen scenario on the given ECU variant. |
| POD | POD_IDENTIFICATION | A specific hardware version of a POD. |
| Vendor | (none) | The vendor/maker of the POD. |
The A2L-file contains the POD configuration. The Standard defines a data structure in AML, called "POD", which allows to define individual configurations for each Variant and scenario. This data structure can also optionally contain an identification for the POD hardware. The actual content of the configuration is vendor-specific. The Standard reserves a binary large object (BLOB), which holds the configuration parameters. The BLOB is either directly stored in the A2L-file or there is a reference to an external file that contains the BLOB.
During the start-up phase, the tool reads the A2L-file with the POD configurations. The user can select a Variant and scenario. The tool connects to the POD and downloads the current POD configuration. If the scenario selected by the user is different than the currently active scenario stored in the POD, then the new configuration for that scenario will be download to the POD and activated.
With a Standard-compliant implementation, the configuration process can be performed between tools and PODs from different vendors. It is also possible to specify and use different XCP transport layers for different scenarios, e.g. performing Measurement and Calibration via TCP/IP and bypassing via UDP.
The completion of this process is a prerequisite to start the POD initialization process.
The configuration process does not involve the EAP. Consequently, there are no API methods defined for this Technical Use-Case.
The following table lists XCP commands for the communication between the external tool and the POD. Those commands are specific to PODs and have their own command space within the XCP protocol. They are all mandatory commands, i.e. they must be implemented when compliance to this Standard is claimed.
Command | Description |
|---|---|
| POD_GET_INFO | Retrieve basic information from the POD, such as POD ID, POD description, System ID or diagnostic information. |
| POD_GET_STATUS | Obtain the POD status, i.e. POD detected by the EAP and initialization status of features. |
| POD_MANAGE_TRANSFER | Prepares the down- or upload of a BLOB representing the POD configuration. |
| POD_UPLOAD | Uploads the configuration BLOB or diagnostics information from the POD. |
| POD_DOWNLOAD | Downloads the configuration BLOB to the POD. |
| POD_SET_ACTIVE_CONFIGURATION | Activates an already downloaded configuration in the POD. |
The communication between the POD and PSS is vendor-specific, as both components always come from the same vendor. This communication has not been standardized in ASAM MCD-1 POD.
POD Detection
POD detection is the process of the ECU to detect a connected POD and to determine access to the ECU resources. This process runs independently from POD configuration.
Prior of running the detection process, the POD is supposed to check if the chosen configuration is available on this ECU, i.e. whether scenario ID and Variant ID match. If there is no match, then detection is stopped and an error message is sent to the tool.
The detection process can be triggered at any time by the EAP. Typical detection schemes are to start the detection only once shortly after ECU startup, which requires to connect the POD prior of starting up the ECU, or to call the detection periodically, allowing the exchange of PODs during runtime of the ECU.
During startup, the POD writes the POD Configuration ID into a mailbox (ECU RAM or processor register). Once the EAP starts the POD detection, it polls the mailbox regularly. Once the mailbox has been written by the POD, then the EAP has detected that a POD is connected and knows its current configuration. The mailbox optionally holds additional data for cold-start on which the EAP shall respond quickly. The next table contains the mailbox data and its meaning.
Mailbox Data | Description |
|---|---|
| FUNC_FIRST_CYCLE_DAQ | Do first cycle measurement. |
| FUNC_PGM | Do ECU programming. |
| FUNC_POD_WAKEUP | The tool has woken up the POD. |
| FUNC_FIRST_CYCLE_STIM | Do first cycle bypassing. |
| FUNC_DBG | Do debugging. |
| START_ON_WP | POD will start from the working page. |
| MASTER_CONNECTED | POD is connected to at least one XCP master. |
The completion of POD detection is a prerequisite to start the POD initialization process. API methods for POD detection:
Function Name | Description |
|---|---|
| A_PSS_Prepare_Detect | Prepares the detect sequence of the POD, called from the EAP during initialization. This function is optional. |
| A_PSS_Detect | Checks whether a POD is connected to the ECU. |
POD Initialization
POD initialization is the process of initializing the PSS and activating the features as selected by the user. The process can be started at any time and can initialize the PSS even without a connected and detected POD. Furthermore, POD initialization can run only once per power cycle, i.e. it is not allowed to change the assignment and initialization of resources during run time of the ECU. There is one exception: Calibration can be deactivated by the EAP at any time after initialization. Reactivation is not allowed in this case.
The features as per the next table can be activated.
Feature | Description |
|---|---|
| CAL | Calibration |
| DBG | Debugging |
| DAQ | Synchronous measurement |
| STIM | Bypassing, stimulation |
| PGM | ECU flash programming |
The information about which features has been selected is extracted from the POD configuration received during POD detection. The EAP first sends an initialization command to the PSS for the identified vendor, which initializes the required resources. The initialization is done with vendor-specific data. After successful initialization, POD and PSS are set to active and can respond to more requests than just detection and initialization. The EAP then sends for each feature an activation request and checks if the POD has actually activated the feature. The EAP also triggers the POD to send a message to the tool about the success of each feature activation. Activated features can now be used by the user.
API methods for POD initialization:
Function Name | Description |
|---|---|
| <VENDOR>_PSS_Init | Starts the initialization of the PSS and the POD, and sets both to active mode. |
| <VENDOR>_PSS_Activate_Features | Starts the activation of one or more features. |
| <VENDOR>_PSS_Deactivate_Features | Triggers the deactivation of a set of features. |
| <VENDOR>_PSS_Check_Feature_Status | Checks if the activation of a specific feature has been completed by the PSS. |
Synchronous Measurement
Synchronous Measurement means event-triggered, periodic sampling of ECU-internal data and transmission to the external tool. This mode is also called DAQ (data acquisition) in other standards such as ASAM MCD-1 XCP.
Measurement configurations, - also called 'DAQ configurations' -, are defined in the A2L-file in accordance with ASAM MCD-2 MC. This A2L-file must exist with each ECU software version that is flashed into the ECU. The A2L-file contains the following definitions for synchronous Measurement:
- Event: The event determines the point of time when the internal data is collected in the ECU and transferred to the external tool. For the feature 'synchronous measurement', an event means that a specific execution point in the EAP software has been reached. When this occurs, then the PSS is called to collect and transfer the measurement data. This execution point is periodically reached, e.g. it could be time-synchronous or angle-synchronous. Each event is defined in the A2L-file with the keyword "EVENT" and identified by an event channel number (keyword: EVENT_CHANNEL_NUMBER).
- ECU-internal data to be measured: This data is defined with the A2L-keyword "MEASUREMENT". Part of the description is the event channel number at which it is collected and transferred to the external tool. The collection of all data to be measured at a specific event is called "DAQ configuration" or "DAQ channel list".
A user has three functions available for synchronous Measurement:
- Configure measurement
- Start acquisition
- Stop acquisition
Before a user can start a Measurement, he has to select a DAQ configuration as defined in the A2L-file. The tool sends the configuration via the POD to the PSS. The PSS initializes the ECU for synchronous Measurement.
Next step is that the user starts the data acquisition. The tool sends a start request via the POD to the PSS. The EAP calls the PSS each time, when the specified event occurs. At that moment, the PSS collects the data from ECU memory, determines the time stamp and sends the data via the POD to the external tool. This process repeats for every event until the user stops the data acquisition.
API methods for synchronous Measurement:
Function Name | Description |
|---|---|
| <VENDOR>_PSS_DAQ_Trigger | Informs the PSS that a certain event has occurred. |
Calibration
Calibration is the process of online tuning of internal ECU parameters. Calibration parameters have an impact on EAP behavior. Their determination is a major process step in the development of ECUs. During Calibration, the user changes parameters while the ECU is running to obtain optimal control performance. Calibration parameters are read-only for the EAP.
The properties of Calibration parameters are defined in the A2L-file in accordance with ASAM MCD-2 MC. The Standard uses the keywords 'CHARACTERISTIC',' AXIS_PTS' or 'BLOB' for describing Calibration parameters. The A2L-file also defines the memory layout of the ECU and the memory pages that hold the Calibration parameters. This is done with the A2L-keyword 'MEMORY_SEGMENT'. A development ECU typically has an active Calibration page and one or multiple working pages. The EAP only uses the Calibration parameters from the active page. The active page can not directly be modified by the tool during runtime to avoid data corruption. The tool has read-write access to the working page(s) only. Once the user has completed his parameter changes on the working pages, then one working page can be switched to become the active page. This effectively allows the process of online Calibration.
From a technical point-of-view, Calibration consists of three processes, which run in parallel:
- Data synchronization: The tool downloads the data from ECU calibration memory via the POD and mirrors this data in its own memory. The tool keeps the data in synchronization throughout the calibration process.
- Calibration data tuning: The user modifies calibration parameters in the working page(s).
- Page switching: The user can initiate a page switch. This shall turn the user-selected working page in ECU memory to the active page. The page switch command is sent from the tool via the POD to the PSS. If only the PSS can switch the active page, then the PSS waits for the next page switch synchronization command from the EAP, which signals to the PSS that the switch can now safely be performed. If only the EAP can switch the active page, then the EAP regularly polls the PSS for a page switch command from the user and carries out the page switch once the PSS signals this to the EAP. In each case, the EAP is the master for page switching and can temporarily or permanently inhibit page switches.
The Standard also defines an 'Emergency Mode', in which the EAP can deactivate page switching and set the default Calibration page. After triggering this mode, the Calibration feature is not available any longer until ECU power-off.
API methods for synchronous Measurement:
Function Name | Description |
|---|---|
| <VENDOR>_PSS_CAL_Sync_Page_State | This function shall be called by the EAP directly before activation of the calibration feature to inform the PSS of the currently active calibration page state in the ECU. |
| <VENDOR>_PSS_CAL_Page_Switch | Informs the PSS that a page switch can now occur. |
| <VENDOR>_PSS_CAL_Get_Page_Switch_Status | Returns the status of the page switch execution to be done by the PSS. |
| <VENDOR>_PSS_CAL_Get_Page_Switch_Request | EAP polls the PSS for a page switch request. |
| <VENDOR>_PSS_CAL_Set_Page_Switch_Status | EAP informs the PSS about the page switch status. |
| <VENDOR>_PSS_CAL_Set_Page_Switch_Mode | Sets the overall calibration mode to temporarily or permanently inhibit page switching. |
Common API Functions
The Standard defines further API functions, which cannot be assigned to a specific Technical Use-Case or feature. They ease the job of the ECU software integrator in such a way that the functions can be called from multiple PSSs.
Function Name | Description |
|---|---|
| A_PSS_Mem_Copy | Called by the PSS in order to copy memory content to a specific location (e.g. to a mailbox). |
| A_PSS_Get_Current_CoreID | Called by the PSS in order to retrieve the current core ID of a multi-core processor. |
Relation to Other Standards
ASAM MCD-1 POD is using ASAM MCD-1 XCP for communication between the POD and connected tools. The Standard is using its own command space in XCP and defines six POD-specific commands and one event.
ASAM MCD-1 POD defines the AML-section for A2L-files in accordance with ASAM MCD-2 MC. This AML-section must be used when the POD is connected to an ASAM-MCD-2 MC-compliant tool.
Industry Adoption
Since its release in 2017, ASAM MCD-1 POD had a slow start. Commercial PODs exist since more than 20 years, so the Standard is a late-comer. Automotive companies got used to the formula: one ECU project = one Calibration tool. They have yet to push their tool vendors to support the Standard and use it for more flexible tool chains.
There is a good chance for the Standard to be used in rather new technology domains of the automotive industry, such as ADAS or alternative propulsion systems, as they require flexible tool chains and do not have legacy tools and long-established development processes. The Standard can also be seen as a good chance for tool companies, who want to enter this market. They can use the Standard as an initial Specification for their PSS, and simultaneously open up their products to be used together with competitor tools, which is lowering the bar for them to enter an already well occupied market.
List of Deliverables
The Standard includes the following deliverables:
- Base standard
- AML-file
- PSS reference implementation in C
- Example A2L-file
- Example project for an AURIX board with an Infineon TriCore processor
Follow us on
