ASAM MCD-1 POD

Commercial-off-the-shelf Measurement & Calibration tools (MC-tools) for automotive ECU development emerged in the mid 90^th 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.

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.

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.

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 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 is the process to select and activate a specific setup for the system to support a specific work scenario.

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.

The completion of POD detection is a prerequisite to start the POD initialization process. API methods for POD detection:

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.

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:

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:

1. 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).
    
2. 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:

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:

1. 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.
2. Calibration data tuning: The user modifies calibration parameters in the working page(s).
3. 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:

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.

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.

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.

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