What is Hardware in the Loop (HIL) and Software in the Loop (SIL) Testing?

By Gabriel Staples
Written: 6 June 2018
Last Updated: 7 June 2018

Quadcopter navigation algorithm SIL test (live video).

In mechatronics and control theory, testing is an important part of controller validation. You need to run experiments to prove that your software/analog/digital controller, actuator, algorithm, etc, does what it’s supposed to do. Experiments, however, can be expensive, time-consuming, difficult,
dangerous, or even impossible to test under all conditions. Therefore, you can do Hardware in the Loop (HIL) testing and Software in the Loop (SIL) testing/simulation to aid the testing, verification and validation of your controller without having to resort to pure, fully-physical testing with actual products under actual conditions.



HIL vs SIL:

Hardware in the Loop (HIL) is a testing technique where you can test a component of your complete system, or your complete hardware system itself, on hardware in a non-final configuration. This might be sitting on the bench, or in a laboratory, where your software is connected to the hardware but running off-board, for example, when it will be embedded on-board for the final system. As one HIL example: you might test a steering control algorithm from a laptop to see how well it actuates a physical, real-life hardware steering actuator sitting on a test bench. In the final product, maybe your controller will run on a microcontroller or other embedded system, such as an embedded Linux computer, but for HIL you might just run it from your laptop, but have a real piece of hardware in the control and/or feedback (if any) loop. In this example, your PC controls the actuator. This is hardware-in-the-loop. HIL might also be as simple as writing a control algorithm in C or C++ that you run on your laptop initially, but then you port it to a microcontroller to see how fast it runs on the microcontroller as compared to on your PC. This way you can tune parameters and loop rates and things, now knowing the physical capabilities of your intended hardware. HIL can also involve measuring system response, such as velocities, accelerations, physical deflections, et cetera--really any physical phenomena.

Software in the Loop (SIL) is essentially the same thing as HIL except that instead of having a real piece of hardware in your control and/or feedback loop, as discussed above, you have a piece of software simulating your hardware you want in the loop. In a SIL form of the above HIL example, you might have a piece of software which simulates the steering actuator, and you simply send control inputs to that instead of to the real thing. You might simulate the actual interfaces, actual outputs, response, or any combination of these. This could be a simple simulation, such as simply adding a delay to your control signal and then outputting an estimated deflection value. Your simulation might also model the actuator fully as a plant.

A super simple SIL test might be one where you just add in control signal delays to "simulate" the actual communication or response delays which occur when passing the signal from one physical device to another, or to simulate other delays due to motor response time, inertia of physical systems, etc. The simulation logic for a pass-through hardware communication module could be as simple as, "when I get a command, wait 200 ms before passing it on to the actuator." Boom! You just "simulated" a control signal delay! There's your SIL!

In all cases above, the delineator between "what is HIL" versus "what is SIL" can be somewhat fuzzy. Sometimes you are using both at once. The definitions seem to be somewhat vague to me, and perhaps aren't super-well-defined in the industry.

In an attempt to define them succinctly, here are my definitions:

Definition Attempt #1:

1. Hardware in the Loop (HIL) is testing any software/firmware/algorithm/control system in such a way that a piece of actual hardware is in your communication stream in a system which is either open-ended (feed-forward only), or with feedback.
2. Software in the Loop (SIL) is testing any software/firmware/algorithm/control system in such a way that a piece of software simulating a piece of hardware, or simulating a physical component, or a physical system, including possibly its response or other characteristics, is in your communication stream in a system which is either open-ended (feed-forward only), or with feedback.

Definition Attempt #2 (let's make is shorter):

1. HIL is any testing where you have an actual piece of product hardware in your test.
2. SIL is any testing where you have a simulated piece of actual product hardware (in other words: software in place of hardware) in your test.

ADVERTISEMENT:
How is SIL different from just using a simulator then? 
Answer: a simulator simulates response. It provides the output that results from your input. Your controller must provide the input to the simulator. Once it does that, you've got SIL. A simulator by itself is not a complete system. It requires a controller to give it inputs. In this way, it seems logical to me that Software in the Loop testing might also be called Software in the Loop simulation.

This website confirms that notion, when they say: "The term ‘software-in-the-loop testing’, or SIL testing, is used to describe a test methodology where executable code such as algorithms (or even an entire controller strategy), usually written for a particular mechatronic system, is tested within a modelling environment that can help prove or test the software...SIL testing and simulation can thus be a useful technique for software proving at earlier stages of the design." (http://www.add2.co.uk/applications/sil/).

Real-life SIL Example:
One common example of this is where you write a control algorithm intended for a real device, but then simulate its physics-based response to your inputs. After one iteration, your controller looks at the new, simulated physical state of the vehicle, compares it to the desired physical state, and gives it another command. The simulator (SIL unit) then simulates its response over one time step to that control input, and outputs a new physical state. Your controller now compares this new physical state to the desired physical state and sends another command, and the simulation/SIL test continues in this manner.

Quadcopter navigation algorithm SIL test (live video).

This image to the right shows an overhead view of a quadcopter navigation algorithm SIL test/simulation I wrote. Watch the video and you'll see exactly what I just described above, but in real-time. When I say real-time in this case, I mean the simulation is running as fast as the computer can process it (using MATLAB--which is SLOW, especially when plotting [note: I'd try using Python next time instead]), although it is not showing the vehicle moving at actual speed. The real-time ratio (simulation speed/vehicle speed), is in the top-right of the window, and is somewhere around 0.20. The funky-shaped blue path are difficult (impossible)-to-follow waypoints I arbitrarily created, and the red path is the vehicle's path history. The red arrow is the vehicle's velocity vector, and the green arrow is the vehicle's acceleration vector due to thrust. The black dot along the path is the point the control algorithm is trying to aim the vehicle's velocity vector, by manipulating its thrust vector. The navigation algorithm uses real physics--the physic equations of motion, to do this calculation, based on real quadcopter physics for a static, hovering vehicle. Vehicle thrust vector rate of change is not modeled, so you'll see the thrust vector instantaneously jump in impossible ways after the target point passes some waypoints. Watch the video here.

Real-life HIL Example:

Quadcopter navigation algorithm HIL test (live video).

After proving to myself that my physics-based navigation algorithm probably really would work in real life, by running the SIL test/simulation on my path-following algorithm above, I then moved to a HIL test. Here, I left my control algorithm on the laptop, but I routed its signals out of the laptop and then wirelessly to a commercial-off-the-shelf quadcopter flying in real life in an indoor flight lab. This is a true HIL test because my control algorithm was still running on my laptop, offboard the vehicle, whereas in a final product it would run on some embedded system (ex: a microcontroller or embedded Linux Computer) on the vehicle. Like I said above, it can get a little fuzzy sometimes when trying to figure out where HIL stops and simply "experimental testing", "prototype testing," or "product testing" begins, and there are many ways to try and delineate and talk about these, but in this case it is clearly a HIL test like I said since the control algorithm is literally running live on a regular laptop sitting on a table in the flight lab. In either case, the HIL test was also a complete success (after adding in a time constant, tau, to limit the commanded delta velocity_vector each control loop rather than trying to command it all at once) and I am thrilled to announce that physics works! :) It was absolutely exhilarating for me to see the fruits of my labors like this in such a real way. What a cool project!

Here just below and to the right you can see a photograph of the quadcopter flying autonomously in the room under the control of my navigation/path-following algorithm. You can watch the video here. That is the 2nd of two videos. The 1st video is here.

Quadcopter navigation algorithm HIL test (live video).

A note about modularity:
Generally, it seems to me your controller and the simulator (SIL test output algorithm) should be maintained as separate, distinct software modules so that you can easily use one without the other. Once a software simulator is created, you can "plug" your controller into the software simulator directly and run a bench-top SIL test. Once a HIL test is created, you can "plug" your controller into the hardware directly and run a HIL bench-top test. Once your product is created, you can integrate your controller into the product itself and run a physical, experimental test. The way in which you integrate your controller into each of these tests is your call as an engineer. You do it how you see best. The level at which you simulate things, and the fidelity of your simulation or HIL setup is your call as an engineer. The way and at what level you integrate signals from one module to another for testing purposes is all part of your engineering design. You have a lot of creative freedom.

Confusing? Yeah...

Fun? Yes! Hard? Super! Worth it? Absolutely!

Feedback from control systems experts or those who know better is welcome. Leave comments below.

Note: this article is not endorsed by nor affiliated with my employer in any way.

What spurred me to think about and write this response? Answer: this question I stumbled upon on Quora today, which was seriously lacking in answers: https://www.quora.com/What-is-Software-in-Loop-SIL.

Thinking about becoming an engineer!? Do it! :) Go make something great!

Additional Reading:

• Wikipedia - Control Theory
• Wikipedia - Plant (control theory)
• Wikipedia - Equations of Motion
• add2.co.uk - Software-in-the-loop testing applications
• Wikipedia - Hardware-in-the-loop simulation
• Wikipedia (in Italian) - Software-in-the-loop (English translation here--someone please go write an English version for this page already!)
• Google search for "what is software in the loop"
• Typhoon HIL Blog - Power Electronics Control Design & Testing in the 21st century

END

Keywords: simulation, hardware in the loop testing, hardware-in-the-loop simulation, hil, software in the loop testing, software-in-the-loop simulation, sil, quadcopter, quadrotor, drone, autonomous air vehicle, MAV (Micro Air Vehicle), SUAS (Small Unmanned Aerial System, or Small Unmanned Aircraft System), Vicon motion capture system, mechatronics, robotics, indoor flight lab, 60 vicon motion capture cameras, MAVLab (Micro Air Vehicles Laboratory), Wright Patterson Air Force Base, AFRL (Air Force Research Laboratory), autonomous vehicle, autonomous robotics, unmanned systems, Arduino, Turnigy 9XR, FrSky Taranis, PPM (Pulse Position Modulation), MATLAB, path planning, path following algorithm, navigation algorithm, waypoint tracking algorithm, lead point navigation approach, vector field navigation approach, physics-based flight controller.

Draft Time: [3 hrs.]
Quadcopter SIL/HIL time above: 2+ yrs working at probably <50% time on it.