- Contact Us
About Hardware-In-the-Loop Simulation
The Hardware-in-the-Loop process has existed for no more than 15 to 20 years.
Its roots are found in the Aviation industry.
The reason the use of a HIL process is becoming more prevalent in all industries
is driven by two major factors: time to market and complexity.
- The Process
- Modern Design Process
- Why use Hardware-in-the-Loop Simulation?
- Tight Development Schedules
- High-Burden-Rate Plant
Consider a vehicle engine of the 70's as compared to today. Engines had one or two very low level non-complex controllers that managed air fuel mixtures and gas heat emissions. Engines themselves were not very complex and had relatively few sub-systems. Today consumer demand requires an engine to be light but have high power, be environmental but have responsive handling characteristics, reduce gas emissions but be economical. The complexity of the engine and all its sub-systems has grown enormously and includes dozens of highly complex controllers required to manage everything from fuel injection, to responsiveness, engine noise, fuel economy and emissions.
Now consider the complexity of whole systems such as cars, trucks, trains, aircrafts, weapons systems, ships, as well as sub-systems such as jet engines.
Twenty years ago a small engineering team would first build a physical prototype of an engine or sub-system and then write simple code to control the hardware. This first prototype engine would then be used to test all aspects of its required
function. The cost related to building the hardware (and possibly destroying it during testing) was understood and accepted as normal business practice.
In many industries this is no longer possible due to the complexity inherent in the design and manufacture of complex hardware. Entire teams of software engineers who are required to control the hardware have been added to a large
team of hardware engineers who they themselves are working on sections of these complex machines.
In many cases these teams of engineers are working in parallel, designing both the hardware, and the software to control it.
In addition the monetary cost of actually building a physical prototype is becoming increasingly prohibitive and in some cases unrealistic in view of time to market considerations.
Consider the complexity of a Boeing jetliner or of a new automobile. If all parts of a new aircraft or automotive design needed to be physically built, tested, assembled, and tested again as part of the greater unit, (and all this before teams of software engineers could even begin to write controllers), the time to market of new jet liners and cars would stretch into decades, and fall well outside the window of opportunity for the product.
The tight development schedules associated with most new automotive, aerospace and defense programs do not allow embedded system design and testing to wait for a prototype to be available. In fact, most new development schedules assume that HIL simulation will be used in parallel with the development of the plant. For example, by the time a new automobile engine prototype is made available for control system testing, 95% of the engine controller testing will have been completed using HIL simulation.
Embedded systems (controllers) are designed to control, both basic and complex plants (read hardware or hardware sub-systems)such as land vehicles (cars, trucks, trains, carts, ATV's), turbines, satellites, spacecrafts, Unmanned Aerial Vehicles (UAVs), aircrafts, weapon systems, marine vehicles, and jet engines.
Noted above, as the complexity of the hardware being controlled increases, so too does the complexity of the embedded system that is designed to control the hardware. Hardware-in-the-Loop (HIL) simulation is a technique that is used increasingly in the development and test of complex real-time embedded systems.
The purpose of HIL simulation is to provide an effective platform for developing and testing real-time embedded systems, often in close parallel with the development of the hardware. Software development no longer needs to wait for a physical plant in order to write and test code. In addition testing can include simulations of larger versions of the plant (a 1 kW generator and a scaled up 100 kW generator) or simulation of over burdening, which would likely destroy a physical plant.
HIL simulation provides an effective platform by adding the complexity of the plant under control to the development and test platform. The complexity of the plant under control is included in test and development by adding a mathematical representation (model) of all related dynamic systems. These mathematical representations are referred to as the "plant simulation."
For example, an HIL simulation platform for the development of a wind turbine generator may have mathematical representations for each of the following subsystems in the plant simulation:
• Mechanical Variables
o Mechanical torque (made of wind speed, blade pitch, gear box resistance, shaft length, etc.)
• Electrical Variables
o State (voltage, current)
An HIL simulation must also include electrical emulation of sensors and actuators. These electrical emulations act as the interface between the plant simulation and the embedded system under development or test. The value of each electrically emulated sensor is controlled by the plant simulation and is read by the embedded system under test. Likewise, the embedded system under test implements its control algorithms by outputting actuator control signals. Changes in the control signals result in changes to variable values in the plant simulation.
This question is an important part of understanding real-time technology. To restate the question using a control systems term: Why not connect the embedded system under test to the "real plant," that is the dynamic system being controlled, to perform development and testing?
In many cases, the most effective way to develop an embedded system is to connect the embedded system to the real plant, if such a plant exists. Increasingly however, HIL simulation is more efficient and or required.
The metric of development and test efficiency is typically a formula that includes the following factors:
Cost of the approach will be a measure of the cost of all tools and effort. The duration of development and test affects the time-to-market for a planned product. The safety factor and duration are typically equated to a cost measure.
Specific conditions that warrant the use of HIL simulation include the following:
• Tight development schedules
• High-burden-rate plant
The tight development schedules associated with most new automotive, aerospace and defense programs do not allow embedded svstem testing to wait for a prototype to be available. In fact, most new development schedules assume that HIL simulation will be used in parallel with the development of the plant. For example, by the time a new automobile engine prototype is made available for control system testing, 95% of the engine controller testing will have been completed using HIL simulation.
In many cases, the plant is more expensive than a high fidelity, real-time simulator and therefore has a higher-burden rate. Therefore, it is more economical to develop and test while connected to an HIL simulator than the real plant. For jet engine manufacturers, HIL simulation is a fundamental part of engine development. The development of Full Authority Digital Engine
Controllers (FADEC) for aircraft jet engines is an extreme example of a high burden-rate plant. Each jet engine can cost millions of dollars. In contrast, an HIL simulator designed to test a jet engine manufacturer's complete line of engines may demand merely a tenth of the cost of a single engine.
Take for example the development of a wing flap, slat or spoiler motor used in a fly-by-wire flight controlled plane. Fly-by-wire flight controls eliminate the mechanical linkages between the flight controls and the aircraft control surfaces. Sensors communicate the demanded flight response and then apply realistic force feedback to the fly-by-wire controls using motors.
The alternative to HIL simulation is to place prototype flight controls in early aircraft prototypes and test for usability during flight test. This approach fails when measuring the three conditions listed below.
• Cost: A flight test is extremely costly and therefore the goal is to minimize any development occurring as a result of a flight test.
• Duration: Developing flight controls with a flight test will extend the duration of an aircraft development program. Using HIL simulation, the flight controls may be developed well before a real aircraft is available.
• Safety: Using a flight test for the development of critical components such as flight controls has a major safety implication. Should errors be present in the design of the prototype flight controls, the result could be a crash landing.