Error Providers are a plugin interface for VeriStand that translates generic faulting sequences (ASAM error configurations) into a sequence of VeriStand channel and value pairs. The key elements of the Error Provider are a translate VI and a XML file. The translate VI implements the logic of how to translate ASAM error sets into VeriStand channel and value pairs. The XML file describes the translate VI to call for the VeriStand system definition tree.
Inputs to the translate VI are a Signals Base Path string and an Electrical Error JSONs string array. The output is a Channels and Values array. In each call, the base path to the GUID is passed to the translate VI. If a channel belonging to the GUID item is part of the error set, the JSON strings are also passed.
In this tutorial, <TargetTypeGUID>7f9b2ef4-f3fc-4448-975a7018fe511e0d</TargetTypeGUID> refers to the “User Channel Folder.” In a real case, the GUID would refer to a section of a custom device. In <VS\Engine Demo\Engine Demo.nivssdf>, there are four sections matching this GUID: [Targets/Controller/User Channels/] Calculations, Safety Limits, ECU Pins, and EES.
An error configuration, consisting of one error set with an interrupt error on the Pin 1 Fault and one empty error set that clears all errors, is created and downloaded to the EES port. During the download, the Translate User Channel Errors.vi is called eight times. The VI is called four times for the first error set and four times for the second.
The tutorial contains the following VeriStand specific files (modifications to the original Engine Demo Project are listed).
Issue 3812: "Download() and Update() calls shall check that the errors from the error configuration can be applied by the underlying EES system and throw an exception in case an unsupported feature or parametrization is used."
This VI performs the following steps:
ASAM is an automotive development and test systems standardization organization. It is made up of experts, including OEMs, Tier-1s, tool vendors, engineering service providers, and research institutes.
The ASAM XIL API Project’s goals are to:
The following graphic displays common ports covered by the ASAM XIL API.As a first port, the MAport was implemented by most companies supporting XIL. Recently a larger group implemented the Electrical Error Simulation port to provide a standardized access to fault insertion. Frequent cross tests and a unit test suite provided by ASAM ensure seamless interoperability between different tools. ( Link: XIL Cross Test 2017: Freedom to Choose )
The framework concept introduced in ASAM XIL 2.0 decouples test cases from the underlying test system. All identifiers of a test system, such as the IO channels, diagnostic variables, and fault insertion channels, are abstracted using the framework mapping. With this framework, a test designer does not need to care about where the value comes from. They can design the test case based on the functional requirements and not the specific test system implementation.
The following graphic displays how the framework abstracts the test cases.
ASAM defines an error as a
“…defined disturbance of one or more electrical signals, typically pins of the SUT. E.g. an error may disturb a signal by interrupting the line and replacing it with a resistor. More than one error for different signals may be in effect at the same time, but each signal may only be used once in an error set. All errors that start at the same time are put together in an error set. An EES configuration comprises of a sequence of error sets (see Figure 164).”
The EES Port can be used in two logical modes:
To execute an error configuration, it must be downloaded and started by the test case. When an error configuration is executed, the error sets are executed in the defined sequence (see Figure 165). That means the first error set is activated when the trigger for the first error set becomes true. All other triggers are not considered so far. The errors in the error set stay active as far as the trigger of the next error set becomes true.
The sequence of error sets is defined by the error configuration. It does not depend on the sequence the triggers of the error sets are fired. The triggers only determine when the next error set replaces the currently active error set.
The error configuration must be stopped by the test case using the ASAM XIL API. The last error set remains active if the error configuration is not stopped. To get a defined end of signal disturbance, an empty error set can be used as the last error set in the configuration. Empty error sets can also be used to create error-free phases. Use the figure below as an example for the execution of an error configuration.
If an error is defined in the same way in two consecutive error sets, the error will stay in action. If one error set is replaced by a consecutive error set containing the same error for the same signal, the error will not be restarted or modified.
The EES system uses trigger events to switch from one error set to another error set. These triggers are handled by the EES hardware and software. They are not defined by the ASAM XIL API. There are no means to define trigger conditions for EES error sets in the EES port. In an EES error configuration, only the awaited trigger type is defined. The trigger type can be thought of as the trigger input connection of an appropriate hardware. The trigger can also be controlled by the software.
An error is defined by several independent aspects: the error category, the error type, and the option to disturb with or without load.
The error category defines how a signal should be disturbed. A signal is interrupted or connected to other signals or a potential (see Figure 166). The way the interruption or short-circuit is provided is not defined by the error category. It is defined by the error type.
The below figure displays how error categories are defined by EES port.
Typically, the error category affects one signal. Only in case of a pin to pin, interchanged, or multi-pin error are two or more signals affected.
The error “short-circuit potential” is the generalized form of a short-circuit error. For this category of errors, the EES hardware must provide additional potentials beside Ubattery and ground. Multiple potentials identified by unique numbers may be supported. Ubattery and ground are covered by separate categories because of their importance.
The error type defines the disturbance itself. There are several possibilities that differ in the dynamic of the disturbance (static, for a defined duration, controlled by a PWM signal) and the resistance in case of the error (defined resistance or completely open/closed).
The concrete circuit also differs between short-circuit errors and interrupt errors, because in one case the error is caused by closing a connection, in the other by opening the connection. Nevertheless, the idea of an error of the same error type is the same in both cases.
The below figure displays the available error types and the principal circuits used for short-circuits and interrupts.
The option “with load” or “without load” is an additional aspect of a signal. This aspect is orthogonal to error category and error type and can be freely chosen for almost every kind of error. Only interruptions do not provide this option because technically it does not make any sense in this case.
Background: If a signal between the XIL and the SUT is disturbed by the EES hardware, not only the SUT has to deal with the disturbance. A short-circuit for example effects the XIL hardware, too. To protect the XIL hardware the EES can open the connection between XIL and EES. Thus, the disturbance has an effect on the SUT but cannot damage the XIL.
The below figure displays the principal circuit of the with/without load protection in the EES hardware.
Collaborate with other users in our discussion forums
A valid service agreement may be required, and support options vary by country.