Currently, hardware-in-the-loop (HIL) testing is the de-facto standard for electronic control unit (ECU) verification and validation at the majority of commercial vehicle OEMs and Tier 1 suppliers. HIL testing is used to shorten development and testing time for both engine and machine control systems. To use this process, many of these companies have to develop and maintain expertise in the area of model-based development (MBD).
The current process for HIL testing in the industry is a complex integration of hardware and software that allows for accurate, repeatable testing. The hardware used for testing is generally based on a high-end computing platform, connected to the system under test (SUT) via I/O channels and other necessary interfaces, such as signal conditioning, actuator loads, and failure insertion hardware. The software paradigm used for testing is generally based on complex real-time deterministic models or synchronized I/O systems, depending on the complexity of the plant that is controlled by the SUT. Finally, interface tools to control and monitor both the models and SUT are required to use these systems. These tools can vary from simple user interfaces to completely automated test systems.
To implement these HIL systems, many companies develop deterministic plant models or use internally developed off-line simulations, ported to run in real time. They can also select a commercially available model from a simulation supplier, already prepared for real-time capability and HIL simulation. Regardless of the source of the plant models, expertise is needed to map these models to the HIL hardware interfaces. The process for this mapping involves development and maintenance of tools and systems, which requires in-house expertise and resources dedicated to modeling for HIL system implementation.
Additionally, the process for using these HILs involves an additional mapping of these same interfaces to the user interfaces and testing functions. Streamlining the mapping of HIL interfaces and using this information for automation of the user tools could greatly accelerate the test implementation process.
The procedure for implementing the real-time application is a mapping process of the test equipment to the application for testing, which can be done at several levels. The real-time executable program allows for the greatest test functionality if it is generated via MBD.
However, once a given HIL hardware architecture is designed for the test system, the mapping of the I/O interfaces and plant model connections is strictly application-dependent. This process can either be done directly within the model or abstracted out with a proper model architecture. This architecture then allows the user to map the application to the core HIL interface functions.
Organizing and presenting the information from the real-time system to a user is essential to provide an interface for configuration and subsequent interaction with the HIL application.
An example real-time interface tool, dSPACE ControlDesk, provides a graphic visualization interface to the real-time application. Using an open standards-based API, layouts can be automatically generated from the information stored in the database.
A configuration process is required to map the HIL I/O to the ECU application. One option is to handle this at the model level and add all the scaling and sensor initialization information in the model itself. This approach gives users the flexibility of specifying their I/O in a multitude of ways. The only downside is that the model needs to be recompiled for the settings to take effect. Additionally, the users need to employ modeling tools even if they are only doing an open-loop HIL simulation.
Another option for I/O configuration that is more effective especially for open-loop HIL simulation is to parameterize the I/O on the real-time system during runtime.
One standard method for mapping of ECU I/O signals to engineering units is via a lookup table (LUT), as this provides the greatest flexibility for a signal specification. A standardized graphical dialogue to allow a user to enter sensor or actuator parameter data, whether through equations or graphical point-to-point editing, is a key tool to allow for definitions of LUTs for standard parts that a company uses for its ECU applications.
Not all the I/O in an ECU is set up for electrical fault tolerance and not all the basic types of electrical faults are applicable to each I/O line. Therefore, it is necessary to specify the permissible faults for each applicable signal.
This is also dependent on the core hardware architecture of the HIL itself. Some signals (generally ECU sensor inputs) can be faulted simply by feeding values at the limits or outside of the valid ranges for input signals. Other signals (generally ECU outputs) may require true hardware faulting (short circuits and open circuits) to make a fault occur on the SUT.
This user-defined signal faulting information can be used to auto-generate failure patterns for the HIL application.
A template for the test automation may be generated with the application information. This can significantly help the end users by giving them a jump start with automated testing on the HIL.
This information can be manifested as data objects in an automation environment such as dSPACE AutomationDesk. But these objects need to be coupled with custom test blocks that can execute tests or test steps using these data objects.
Future integration of plant models into the I/O model can be facilitated by auto-generating a framework around the I/O subsystem with potential connection points to plant models. These plant model subsystems can be integrated or mapped to the HIL I/O model in much the same way as the I/O is mapped to the ECU application. This would obviate the user from having to work within the MBD tool.
Once a simulation is running, it is important to interact with the HIL to control and monitor tests from the host PC.
The interface tool provides a synchronized time base for all platform devices. It can provide a seamless process for capturing ECU information simultaneously. The tool provides for a single time base for gathering multirate signals, from different sources (plant model, external USB, diagnostic CAN, and ECU interface devices), which saves testing and analysis time. The user can now correlate system events with physically measured data to determine and document overall system performance. This takes into account system transport delays and internal data flow dependencies. Measuring the true system latencies will help ensure that the end product will meet and/or exceed the system specifications.
To achieve the greatest benefit from an HIL system, automation is needed to do “lights out” testing and provide for an easy way to perform repeatable regression testing. AutomationDesk is a tool for HIL test development, execution, and management.
AutomationDesk provides the user with a way to graphically develop tests with structured work flows, error handling, and the prevention of syntax errors. A graphical test framework is included to ensure each developed test contains the necessary test steps for proper operation.
Direct connection to user requirements tools and configuration management systems is possible via the open COM interface architecture of AutomationDesk. The Doors Connect&Sync interface is used to manage and correlate the traceability of requirements. The requirements translate into tests for the SUT. These requirements can be exported out of the Doors environment to build up the test framework, which consists of test sequence structures, test cases, parameter sets, and test descriptions. The test system will now have a way to trace which test goes to which customer requirement. Once tests are executed, the test results are passed from the automation software to the Doors environment.
This article is based on SAE International technical paper 2011-01-2261 by Amanjot Dhaliwal, Jace Allen, and Jeff Warra of dSPACE Inc. The paper will be presented Sept. 13 at the Commercial Vehicle Engineering Congress during the “Hardware-in-the-loop (HIL) simulation—Testing functions, system integration, and communication of electronic control units (ECUs)” session.