Scribd
Upload
73 views5 pages

Architectures For Implementing Hil System

This document discusses architectures for implementing hardware-in-the-loop (HIL) test systems. It describes that HIL systems allow testing embedded control systems using simulation. A HIL system consists of a real-time processor, I/O interfaces, and an operator interface. The document outlines how HIL can test multi-ECU systems and discusses using distributed processing and I/O to handle high channel counts and wiring complexity. It recommends NI products and tools for implementing HIL test systems.

Uploaded by

sinq57
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
73 views5 pages

Architectures For Implementing Hil System

This document discusses architectures for implementing hardware-in-the-loop (HIL) test systems. It describes that HIL systems allow testing embedded control systems using simulation. A HIL system consists of a real-time processor, I/O interfaces, and an operator interface. The document outlines how HIL can test multi-ECU systems and discusses using distributed processing and I/O to handle high channel counts and wiring complexity. It recommends NI products and tools for implementing HIL test systems.

Uploaded by

sinq57
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

Architectures for Implementing a

Hardware-in-the-Loop System

Overview
You can test embedded control systems more efficiently with the powerful method of hardware-in-the-
loop (HIL) simulation. Safety, availability, or cost considerations can make it impractical to perform all the
necessary tests with the complete embedded control system. Using HIL simulation, you can simulate
the parts of the system that pose these challenges. By thoroughly testing the embedded control device
in a virtual environment before proceeding to real-world tests of the complete system, you can maintain
reliability and time-to-market requirements in a cost-effective manner even as the systems you are
testing become more complex.

Contents
Components of an HIL Test System ............................................................................................................. 2
Hardware Fault Insertion ............................................................................................................................... 2
Testing Multi-ECU Systems .......................................................................................................................... 2
Additional Processing Power—Distributed Processing ................................................................................. 3
Simplified Wiring—Distributed I/O ................................................................................................................ 4
Implementing HIL Test Systems .................................................................................................................. 4
Next Steps..................................................................................................................................................... 5

ni.com/hil
Components of an HIL Test System
An HIL test system consists of three primary components: a real-time processor, I/O interfaces, and an
operator interface. The real-time processor is the core of the HIL test system. It provides deterministic
execution of most of the HIL test system components such as hardware I/O communication, data
logging, stimulus generation, and model execution. A real-time system is typically necessary to provide
an accurate simulation of the parts of the system that are not physically present as part of the test.
The I/O interfaces are analog, digital, and bus signals that interact with the unit under test. You can use
them to produce stimulus signals, acquire data for logging and analysis, and provide the sensor/actuator
interactions between the electronic control unit (ECU) being tested and the virtual environment being
simulated by the model. The operator interface communicates with the real-time processor to provide
test commands and visualization. Often, this component also provides configuration management, test
automation, analysis, and reporting tasks.

Figure 1. An HIL test system consists of three primary components: an operator interface, a real-time
processor, and I/O interfaces.

Hardware Fault Insertion


Many HIL test systems use hardware fault insertion to create signal faults between the ECU and the rest
of the system to test, characterize, or validate the behavior of the device under these conditions. To
accomplish this, you can insert fault insertion units (FIUs) between the I/O interfaces and the ECU to
allow the HIL test system to switch the interface signals between normal operation and fault conditions
such as a short-to-ground or open circuit.

Figure 2. You can use hardware fault insertion to test the behavior of the ECU during signal faults.

Testing Multi-ECU Systems


Some embedded control systems, such as an automobile, aircraft, or wind farm, use multiple ECUs that
are often networked together to function cohesively. Although each of these ECUs may initially be tested

ni.com/hil
independently, a system’s integration HIL test system, such as a full vehicle simulator or iron bird
simulator, is often used to provide more complete virtual testing. When testing a multi-ECU control
system (and even some single ECU control systems), two needs often arise: additional processing
power and simplified wiring.

Figure 3. Automobiles, aircraft, and wind farms use multiple ECUs.

Additional Processing Power—Distributed Processing


Even with the latest multicore processing power, some systems require more processing power than
what is available in a single chassis. To address this challenge, you can use distributed processing
techniques to meet the performance requirements of these systems. In very high-channel-count
systems, the need is more than simply additional processing power, additional I/O is also necessary. In
contrast, systems using large, processor-hungry models often use additional chassis only for the extra
processing power, allowing those processors to remain dedicated to a single task for greater efficiency.
Depending on how the simulator tasks are distributed, it may be necessary to provide shared trigger and
timing signals between the chassis as well as deterministic data mirroring to allow them to operate
cohesively.

Figure 4. When using multiple chassis for additional processing power, it is often necessary to provide
timing and data synchronization interfaces between them.

ni.com/hil
Simplified Wiring—Distributed I/O
Implementing and maintaining wiring for high-channel-count systems can pose costly and time-
consuming challenges. These systems can require hundreds to thousands of signals be connected
between the ECU and the HIL test system, often spanning many meters to compensate for space
requirements.

Fortunately, deterministic distributed I/O technologies can help you tame these wiring complexities and
provide modular connectivity to ECUs, which allows for efficient system configuration modifications.
Instead of routing all connections back to a single rack containing one or more real-time processing
chassis instrumented with I/O interfaces, you can use deterministic distributed I/O to provide modular I/O
interfaces located in close proximity to each ECU without sacrificing the high-speed determinism
necessary for accurate simulation of the virtual parts of the system.

This approach greatly reduces HIL test system wiring cost and complexity by making it possible for the
connections between the ECU and the I/O interfaces to be made locally (spanning less than a meter)
while a single bus cable is used to span the additional distance to the real-time processing chassis.
Additionally, with the modular nature of this approach, HIL test systems can easily scale, incrementally,
from a multi-ECU test system in which all but one of the ECUs are simulated to a complete system
integration HIL test system where none of the ECUs are simulated.

Figure 5. Deterministic distributed I/O interfaces greatly reduce HIL test system wiring cost and
complexity because the connections between the ECU and the I/O interfaces can be made locally.

Implementing HIL Test Systems


After you have selected the appropriate architecture for your HIL test system, the first step in creating a
HIL test system is to select the components that best meet your development requirements. NI provides
a wide variety of real-time processing and I/O options for implementing HIL test systems. Because they
are all based on open industry standards, you can be assured that they always deliver the latest advances
in PC technology to your HIL test system and always meet future test system requirements.

ni.com/hil
The NI HIL platform is open and extensible, which means that it can adapt to changing system
requirements. Because of its modular architecture, the NI HIL platform can be easily upgraded with
additional functionality, which helps you future proof your test systems and meet the requirements of
the most demanding embedded software testing applications. In addition to the widest range of I/O on
market, NI offers software tools that help you automate your HIL tests, perform post-processing and
report generation, and map test results to requirements. These tools help you perform a wider range of
tests earlier in the software development process, which reduces overall development cost while
improving product quality.

Next Steps
 Read the case study: TATA Motors Builds HIL Test System for Hybrid Vehicle Simulation Using
NI Tools

 Read the case study: Embraer Performs Full Airplane Simulation Using NI HIL Tools

 Learn more about NI HIL tools

ni.com/hil

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy