Detail

History

The first release of ASAM HIL 1.0.0 was in June 2009. Maintenance releases 1.0.1 and 1.0.2 have been launched in February 2011 and February 2012. The first releases focused on the description of test bench functionality and Port-based communication between the test bench and the test automation system.

Cross tests have been carried out in June 2012 and February 2013 based on ASAM HIL 1.0.2 by the major HIL system vendors dSPACE GmbH, ETAS GmbH, National Instruments Corporation, TraceTronic GmbH and Vector Informatik GmbH. These tests demonstrated that test systems and test automation software using the HIL API are able to communicate without integration efforts. The few minor functional deficits that occurred due to a Standard misinterpretation were identified and fixed with the next release.

ASAM XIL 2.0.0 was released in October 2013 and marks a major milestone in the further development of the Standard. A framework was introduced to the Standard, which is completely new and contains broadly extended functionality such as logging of variables and mapping of units, data types or variable identifiers as well as managing of ports already known from ASAM HIL 1.0.2. The ports themselves were extended slightly with respect to missing functionality in the previous Standard version, such as configuration and initialization. In order to give test developers standardized access to CAN busses, the Network Port was added to the Standard.

ASAM cooperated with the ITEA2-funded project Modelisar during the development of the ASAM XIL API 2.0 project. As a result, part of the ASAM XIL Standard has been re-published as ASAM XIL-MA with the title "Generic Simulator Interface for Simulation Model Access". Within the group of Modelica FMI (functional mock-up interfaces) standards, ASAM XIL-MA takes the position of functional mock-up interfaces for applications.

The release 2.1.0 introduced further improvements that members reported to ASAM as a result of the first implementations of the major release 2.0.0. Simulations can now be paused, Real-Time scripts can be executed for test Stimulation, signal descriptions can be parameterized, timestamping has been improved e.g. for data capturing and signal generation, user-defined events for data capturing has been introduced and concurrent access to variables from different models is now possible. The DiagPort has been redesigned and cleaned up to ease its implementation.

Motivation

HIL technology has been developed over the years by only a few suppliers. Due to several reasons the architecture of these HIL systems was characterized by a direct rigid coupling of test automation software and test hardware. Therefore test cases directly depended on the used test hardware. The end user, was not able to combine the ‘best’ test software with the ‘best’ testing hardware for his purpose.

Know-how could not be transferred from one test bench to the other. This resulted in additional training costs for employees. Switching to the newest testing technology and to a new development process stage was difficult because of tool specific formats and test hardware compatibility issues. Furthermore, the exchange of test cases between different parties, e.g. OEM and supplier, was difficult and costly.

The major goal of the ASAM XIL standardization effort is to allow for more reuse in test cases and to decouple test automation software from test hardware. As a consequence, the reuse of test cases within the same test automation software on different test hardware systems is achieved. This leads to a significant reduction of efforts for test hardware integration into test automation software.

Software investments and test case development efforts are long-term protected. End users may choose a test automation software system and use it for many years without being forced to use the test hardware from the same supplier.

Some areas of the ASAM XIL Standard are not HIL-specific. The MAPort, for example, can also be used to connect test automation tools to PC-based Simulation tools. This allows engineers to develop test cases in very early stages and in different domains in order to reuse them in later stages on Real-Time HIL simulators.

Application Areas

ASAM XIL focuses on the decoupling of test-cases from real and virtual test systems. It broadly covers all use cases in the testing area and is primarily used in conjunction with test automation tools on a client server base. The Standard is used in test automation applications of all automotive E/E domains, e.g. drivetrain, steering, electric lighting, body electronics etc.

Typical application areas of XIL are test automation scenarios in Hardware-in-the-Loop (HIL) Simulation environments. HIL Simulation has become a well-established Verification technology applied in many ECU development projects today. Tests of failure situations or tests of dangerous maneuvers can be shifted to the Real-Time Simulation, at least some parts of the complete test program. The major advantage is the capability to automate these tests. This allows to reproduce all test cycles and to operate these test benches 24h per day.

Some areas of the XIL Standard are not HIL-specific. The Simulation model access Port, for example, can also be used to adapt Simulation tools. This allows engineers to develop test cases in very early stages and in different domains in order to reuse them in later stages at a real HIL simulator using XIL. The Functional Mock-up Interfaces (FMI) initiative has cooperated with the XIL API Project 2.0. As a result of the ITEA2-funded project Modelisar, standardized interfaces for model exchange and co-Simulation of subsystems from different domains have been developed. These “functional mock-up interfaces” will support Simulation system setup at all stages of function software development (MIL, SIL, HIL, etc.).

Thus, a subset of XIL mainly dealing with the Simulation model access Port as “Functional Mock-up Interface for Applications” has been released separately. This means that tests written in those early Simulation environments can be directly reused in HIL environments at a later stage.

Furthermore, XIL is used in rapid control prototyping environments. As an example, Tula Technology Inc. from Silicon Valley, California uses it in early stages of function development. Through a combination of a unique application of digital signal processing and sophisticated powertrain controls, Tula has created the ‘digital engine’, thereby providing a cost-effective and easily integrated fuel-reduction technology. Therefore, Tula uses hardware components from dSPACE and National Instruments at a test bench accessed by test cases using the HIL API.

Technical Content

Overview

ASAM XIL contains two major parts:

The framework, which provides functionality such as logging of variables and mapping of units, data types or variable identifiers as well as managing of port-based communication to the test bench. The framework uses functionality that is available on the test bench.
The test bench, which includes access-ports to the simulation model, ECU data (parameters, variables and diagnostics), electrical error simulation and the ECU network.

The measuring capability of ASAM XIL allows data acquisition from different data sources (Simulation model, ECUs etc.) to be configured. The time traces of variables from these different data sources are assembled on a common time basis. Users can control the data acquisition using sophisticated triggers that respond to important situations such as gear shifts, transient response in the drivetrain, etc. Recorders stream the coherent results either to memory for further processing or to standardized Measurement files (ASAM MDF 4.0 or higher) for data reuse in a later process stage.

It is a challenging task for test developers to achieve effective decoupling between test cases and test benches in order to improve test reuse. The test developer's work is greatly facilitated by one of the ASAM XIL framework features: mapping. This provides the standardized mapping of values (variable identifiers, physical units, data types) between the test case and the test bench. Thus, mapped values can differ during the development process. The user just has to adjust the mapping - the test case (e.g., Measurement definition) remains unaffected. The user can configure proper Port preconditions in a unified way (e.g. which Simulation model to download on the Port and whether Simulation needs to start automatically after download). This information enables the framework to put ports into their proper states before the Measurement begins.

Introduction

This chapter consists of five sections, starting with Synchronized Data Acquisition, which demonstrates one of the major features of ASAM XIL.

The XIL Test System Architecture section explains the general concepts of the Framework’s and Testbench’s API, containing the ports such as the Model Access Port - MAPort).

The following two sections Overview Framework and Overview Test Bench go into some more detail of these specific areas of the XIL API.

XIL Test System Architecture

The ASAM XIL Standard specifies two major APIs, namely the Framework API and the Testbench API. This section will explain the general architecture, which is the basis of the different interfaces. The picture gives an overview of a test system in general. A typical XIL test bench consists of a system under test, which is a coupled system of ECUs, hardware components, and simulated parts of the system, depicted by the dark grey box at the bottom. The interaction between these parts is managed by different tools of different vendors, shown in the light grey boxes. These tools serve different purposes, such as accessing ECUs, or offer capabilities to interface bus systems, like CAN. The simulated parts might be executed by Simulation tools or on the basis of compiled code. These tools have their proprietary means for configuration (orange blocks).

XIL testbench API with direct port access

A first step of standardization has been achieved with ASAM HIL 1.0.2 providing standardized interfaces to the different types of tools by means of specific test bench ports in a test bench API. ECUC Port and ECUM Port offer standardized access to ECUs via an Calibration and a Measurement interface. The MA Port deals with model access, the DIAG Port with a diagnosis interface. The EES Port offers means for electric error Simulation. ASAM XIL 2.0 additionally introduces the Network Port for accessing CAN networks.

Based on these test bench Port interfaces, a test automation tool could utilize a standardized access to variables and signals on these ports without dealing with proprietary details of different vendors and their tools. However, in such a setup the test case has to implement start and shutdown of the test bench ports, which is highly dependent of the test system. In order to access variables and signals the test case has also to deal with Port-specific addresses and data types.

These drawbacks have been resolved with ASAM XIL 2.0. The test bench Port access is still available (see right side of figure) for compatibility reasons and in order to provide some detailed functionality, that is not provided by the framework.

Test system with XIL framework API and XIL testbench API

ASAM XIL 2.0 introduced Port independence to test cases by using an object-oriented access to variables on test bench ports. This kind of Port abstraction is provided by the framework layer between test automation and test bench. According to some test bench specific configuration within the framework, the different ports are started and shutdown in a specified order.

At the present time it is a challenging task for test developers to achieve effective decoupling between test cases and test benches in order to improve test reuse. The test developer’s work is greatly facilitated by one of the framework’s basic features: mapping. This allows to mapped values between test cases and the test bench:

abstract identifiers for variables
physical units
data types

Thus, mapped values can differ during the development process. The user just has to adjust the mapping – the test case remains unaffected. Mapped values such as the data type or physical unit of a vehicle’s velocity may change on the test bench side because different precisions or different Simulation model suppliers are involved in the development process while the same test case implementation is being reused.

Based on a MappingInfoAPI a test case can retrieve all information, which is part of the mapping definition. Based on the variable objects, the framework also provides objects for Port-independent signal recording, signal generation, and event watching and triggering. A more detailed description is given in the following sections.

Overview Framework

General

The Framework class is the central class for managing the set of test bench ports and their configuration, mapping information as well as overall recording and Stimulation. The Framework class provides factories for other framework related objects, e.g. the creation of variables (see right figure).

Initialization

The ASAM XIL framework simplifies initialization of the test bench ports. The complete test system is initialized based on a configuration, which can be loaded from file using the LoadConfiguration() method. It references other mapping and Port configuration files in order to setup the complete framework with all relevant ports. For more details see the section Configuration of the Standard. The Init() method is called in order to initialize all ports according to the previously loaded configuration in a specified order. After successful initialization the test automation system is ready to perform framework variable accesses, or more precisely, all test bench ports are in their target state as specified in the configuration.

Framework Variables

The most fundamental concept of ASAM XIL is to provide framework variable objects which abstract from the test bench ports and memory addresses of variables. The following figure shows the FrameworkVariable class.

Framework variables are created using the Framework.CreateVariable() method using an AbstractIdentifier string. This string has to be defined in the mapping configuration, where it is related to a specific test bench Port. The mapping also contains meta data about unit and data type of the variable, as well as unit and data type of the test bench Port value, which the variable represents. This allows an automatic unit and type conversion at any framework access.

The value of a framework variable is encapsulated by a Quantity object. A quantity has a physical dimension, e.g. length, a unit, e.g. meter, and a value.

Framework variables exist as Scalar variables as well as vector, matrix, Curve, and Map variables. More details on methods and framework mechanisms utilizing framework variables can be found in section Framework Variables of the Standard.

Note: In ASAM XIL , framework variables cannot be used for the DiagPort and EESPort.

To reduce the effort for test case developers and increase the functional safety, ASAM XIL has a special concept for working with quantities of framework variables if they are used in mathematical operations. A computation table is used to describe multiplication and division operations, based on the physical dimensions and units contained in the mapping file. The contained equations are based on the usage of physical dimensions. The used quantities of an equation should fit to one entry inside the computation table by equal physical dimensions of these units. Because the identifiers of units and dimensions can be user defined an easy alignment with the user approach is possible. The delivered computation table template includes the most common equations of automotive business.

Acquisition and Stimulation

Data acquisition is an important part of test systems. With the Acquisition object (see next figure), which can be obtained from the Framework, the data flow from the test bench ports to the framework is configured and controlled. The configuration is based on framework variables, which carry the relation to the test bench Port and information about unit and data type.

Several recorders can be created. In order to reduce the amount of data, which is transferred to the host PC, the Measurement process can be configured via triggers and a downsampling factor. A recorder can store signals from different ports. A RecorderResult can be held in memory or stored to file, e.g. in MDF4 format. Details are given in section Measuring of the Standard.

In a similar way, Stimulation is configured. The next figure shows the Stimulation class.

Several recorders can be created. In order to reduce the amount of data, which is transferred to the host PC, the Measurement process can be configured via triggers and a downsampling factor. A recorder can store signals from different ports. A RecorderResult can be held in memory or stored to file, e.g. in MDF4 format. Details are given in section Measuring of the Standard.

In a similar way, Stimulation is configured. The next figure shows the Stimulation class.

Several Player instances can be configured. The information about the specific Port variable is again taken from the framework variables, which have been assigned in the configuration. A player can also use a previously recorded signal from file for Stimulation. For details refer to section Stimulation of the Standard.

Watcher objects are used to generate trigger events, e.g. for recordings. The trigger conditions are defined based on General Expression Syntax (GES) strings. In order to refer to framework variables, their AbstractIdentifier is used. Watchers can be defined for variables of different test bench ports.

Overview Test Bench

General

The Testbench API covers access to the test bench ports with their hardware and software components.

The API provides vendor independent access to the functionalities of a XIL simulator via Port interface definitions for the different kinds of ports. Each tool vendor can provide an implementation of these interfaces, which is specific for his tool set. Thus, the user of the XIL Testbench API gains standardized access to the tools of different vendors.

The ASAM XIL Testbench API covers the functional areas:

Model access (MA port)
ECU access (ECUC and ECUM port)
Network access (Network Port),
Diagnostics access (Diag Port)
Electrical error simulation (EES port)

Each of these functional areas is represented by one or several ports. In contrast to ASAM HIL 1.0.x, in ASAM XIL 2.0 the Port initialization is supported by means of standardized configuration methods and objects.

Note: Usually, initialization is performed by the framework. However, initialization sequences can also be programmed in test cases.

Ports of the ASAM XIL Test Bench API

The following class diagram shows the different test bench ports.

The Model Access Port (MAPort) provides access to the Simulation model. It is possible to read and to write data and to capture and to generate signals.

The ECU Measurement Port (ECUMPort) communicates with an electronic control unit. The ECUM Port allows to capture and to read Measurement variables.

The ECU Calibration Port (ECUCPort) communicates with an electronic control unit. It provides access to ECU internal Calibration values.

The Network Access Port (NetworkPort) provides access to networks, such as CAN or FlexRay.

Note: Please note that in ASAM XIL 2.0 only CAN networks are supported. Support for FlexRay or other buses will be part of a future version of the Standard.

The Diagnostic Port (DiagPort) communicates with a diagnostic system to read data via diagnostic services from an ECU or Functional Group.

The EES Port (EESPort) controls electrical error Simulation hardware. It allows to set different types of errors.

Synchronized Data Acquisition

Measured signals from different hardware (accessed via different test bench ports) with different hardware timers usually are not synchronous. The XIL framework can synchronize these signals to a common time base and therefore, it provides standardized interfaces to configure and enable the synchronization. The framework supports synchronized data acquisition among signals across different capture systems accessed by test bench ports, which support capturing (MAPort, ECUMPort, NetworkPort).

Hardware timers usually are simple counters which start counting, once the hardware is switched on. During data acquisition, each Measurement value of a capture system is given a time stamp by the corresponding timer. During data acquisition, those timers have different initial values (due to different times, when they have been switched on) and they also may drift apart due to slightly different frequencies.

Effects of offsets and drifting timers (without resynchronization)

To make it more clear, let’s compare the hardware timers with clocks at different places in the world, which provide time stamps for measured values (see figure below): Montreal and Sydney provide Measurement data in their own time base. Of course the time difference to these places will vary according to where in the world you are, but let’s fix Munich as the place, from where this scenario is observed. Thus, Munich is supposed to be the framework time as the common time base to make measured signals from different locations comparable. At acquisition start, Munich is 6 hours ahead of Montreal, which means there is an offset of 6 hours; i. e. 4 am in Montreal is 10 am in Munich. However, the frequencies of timers differ, resulting in a mere 4 hours of difference between both cities at acquisition end in this example.

But it gets even more complex: Not all timers run at a constant frequency. The reason for this: changing environmental factors over time may affect the timer frequency, e. g. a rising temperature results in a higher timer frequency (see the significant curveprogression of the Sydney time). Consequently, the framework compensates all these effects, if resynchronization is switched on (see figure below) using correction factors for offset and drift. Thus, the framework is turning the values of time stamps for Sydney back to Munich time, for Montreal it is advancing them. If signals are measured with equidistant time stamps at a local time, this transformation may lead to non-equidistant time stamps within the common time base, where the data is synchronized to. At acquisition start, all time stamps are reset to 0.

Effects of offsets and drifting timers corrected with resynchronization

The Resynchronisation property specifies the time interval, after that the framework recalculates the correction factors periodically in order to also deal with non-constant timer frequencies. A negative value of Resynchronization means, that the framework’s resynchronization mechanism is switched off.

Note, that the acquisition and the recording result objects have a past, present and future. This means that the framework adds recently synchronized measured values at the present arrow to the result object, whereas measured data, which already has been added remains unchanged, since it is history. Thus, no post processing is done of data, the framework has already added to in the past. Remember: The past is not controllable, but observable – the future is not observable, but controllable. This means that the framework uses (observes) data that has been collected in the past, in order to compute new correction factors, which will be used for timestamp adjustment (control) in the near future of the next resynchronization interval.

Each test bench Port, which supports capturing, provides the method GET_DAQ_CLOCK. This method returns the time of its Port in seconds. This time base is also used for the acquisition signals, as it is also known from XCP. Internally, the framework requests the current hardware time from the capture system using the getDAQClock method of the corresponding test bench Port (e. g. MAPort). Note, that this method call has some latency time between starting the call and receiving the result. This may be one reason for some inaccuracy within the synchronized data acquisition.

The value of AcquisitionStartTime is the number of seconds since the Unix epoch time (i.e., the time unit is Unix time or POSIX time or Unix timestamp). This is the number of seconds that have elapsed since January 1, 1970 (midnight UTC/GMT), not counting leap seconds (in ISO 8601: 1970-01-01T00:00:00Z. Thus, the epoch is Unix time 0 (midnight 1/1/1970).

The Resynchronisation property specifies the time interval, after that the framework recalculates the correction factors periodically in order to also deal with non-constant timer frequencies. A negative value of Resynchronization means, that the framework’s resynchronization mechanism is switched off.

Note, that the acquisition and the recording result objects have a past, present and future. This means that the framework adds recently synchronized measured values at the present arrow to the result object, whereas measured data, which already has been added remains unchanged, since it is history. Thus, no post processing is done of data, the framework has already added to in the past. Remember: The past is not controllable, but observable – the future is not observable, but controllable. This means that the framework uses (observes) data that has been collected in the past, in order to compute new correction factors, which will be used for timestamp adjustment (control) in the near future of the next resynchronization interval.

Each test bench Port, which supports capturing, provides the method GET_DAQ_CLOCK. This method returns the time of its Port in seconds. This time base is also used for the acquisition signals, as it is also known from XCP. Internally, the framework requests the current hardware time from the capture system using the getDAQClock method of the corresponding test bench Port (e. g. MAPort). Note, that this method call has some latency time between starting the call and receiving the result. This may be one reason for some inaccuracy within the synchronized data acquisition.

The value of AcquisitionStartTime is the number of seconds since the Unix epoch time (i.e., the time unit is Unix time or POSIX time or Unix timestamp). This is the number of seconds that have elapsed since January 1, 1970 (midnight UTC/GMT), not counting leap seconds (in ISO 8601: 1970-01-01T00:00:00Z. Thus, the epoch is Unix time 0 (midnight 1/1/1970).

Relation to Other Standards

ASAM XIL uses the ASAM General Expression Syntax for defining watcher conditions.

Measurement data in ASAM XIL includes numerical data, e. g. within CaptureResult or RecordingResult objects. For streaming this data to file, ASAM XIL uses the definition of MF4-files from ASAM MDF.

The Unit class, which is related to the Quantity of the FrameworkVariable in ASAM XIL has been designed according to the ASAM Harmonized Data Objects Standard (HDO).

The generic UML model of XIL API is based on the ASAM IS Modeling Standard.

List of Deliverables

The Standard includes the following deliverables:

Standard package containing:
- Programmers Guide
- Generic UML Model
- Templates and template examples (e.g. schemas)
- Technology References for C# and Python
- MSI setup package containing all .NET assemblies of the standard.
C# examples package containing
- Documentation
- Framework examples (C#)
- NUnit tests
- Framework example
- Dummy MAPort example
- Testbench examples
- Test data
- MS Visual studio project file
C# TestSuite package containing
- Documentation including test cases
- Source code of test cases (C#)
- Sandcastle project for test case documentation
- Test data
- MS Visual studio project file