Software-in-the-loop and hardware-in-the-loop simulations (or simply SILS and HILS)

Since I am working in the simulation field, or at least in a team which has simulation related tasks, I thought necessary to say some words about those testing methodologies which, in my opinion, are crucial for a test engineer.

So … if you are a test engineer and things like block-box testing, white-box testing, design under test, software-in-the-loop, hardware-in-the-loop simulation, verification vs validation (what is the difference between them), test automation, sanity testing, smoke testing and few others … are not familiar to you … this is definitely NOT A GOOD THING. I hope my workmates won’t swear me when reading this πŸ™‚

Before starting I think it is worthwhile to answer some basic questions: What is simulation about and why is it necessary? As far as I know from my personal work experience but also from digging for information on google, simulation is good to speed the software development lifecycle and implicitly to reduce project’s overall costs. In embedded systems you can test either software, either hardware. One way would be to deploy the corresponding embedded software and to see it at work in its environment. For example if you developed some anti-lock braking software you can wait for the ECU controller to come out of the production line, then to deploy it and finally to see it at work when the ECU is placed on the car.

For sure this is a very costly procedure, you have to wait for the environment to be ready (ECU controller, ECU network within the car, the car) and only after this you can begin checking if your software really does what was designed for. On the other hand you could be a hardware engineer and you would like to the test the ECU (if it correctly reads the sensors, if correctly activates the actuators, mainly electrical tests). It would be very difficult for you to wait for a car prototype to be ready and to test the ECU directly on car. It would be very helpful, for the software as well as for the hardware tester to have a platform to reproduce the physical environment where your Design Under Test will be implemented.

Another very important reason for using simulation that I almost forgot to mention is SAFETY ( for people working with real-time systems, whose deliverables are running on cars or airplanes, this word should be really written in uppercase) . No one would like to drive a car where the EBS system is not guaranteed to work good-enough. (it may be also any other car component, EBS was just an example, there are plenty of critical components in a car which, for sure, you do not want to test them directly installed in the cockpit )

In the testing terminology this “environment” simulating the reality is called plant simulation. In case of ECU controllers this can represent a system simulating road characteristics, vehicle’s speed, yawing rate or pressure applied on the brake pedal.

Okay … but what actually is the difference between software in the loop and hardware in the loop simulation? In my opinion and as far as from my experience hardware in the loop simulation deals with reproducing the environment where the embedded system will run. This is usually one of the last steps in the testing procedure, probably before integration and system tests.

In this case you are in the possession of the original software and hardware, you’re not working with models, all you want to have is a plant simulation to make sure that you will create real conditions for your software-hardware package.

Unfortunately hardware comes later in the project development phases so you have to make use of a software model to test your algorithm. Here software-in-the-loop simulation comes into play. This is an earlier stage in the testing procedure. In this case you check only for your algorithm, not the entire system.

Like you may see in the picture below both, your software algorithm and the model, are running on the same machine, usually a desktop PC.

When performing hardware-in-the-loop simulation your software runs on a real embedded system. Software-in-the-loop testing offers the advantage of flexibility, expensive hardware equipment is not required, but its main drawback is that simulation time will be completely different than the one expected from a real-time system, as it is the case in hardware-in-the-loop simulation (in general simulation time of a model is several orders of magnitude greater than the one of the hardware).

Hope you had a nice lecture … and now things got clearer …


9 Responses to Software-in-the-loop and hardware-in-the-loop simulations (or simply SILS and HILS)

  1. A very nice Topic. Thanks alot hope you go for the detail next time! we offer hardware resources,hope you will like it “”

  2. T.Prabhakaran says:

    short & sweet.

  3. Taufiq says:

    Nice! Btw, the SILS picture does not show correctly.

  4. Henry says:

    Thanks, that was helpful!

  5. Madson Ferrari says:

    The topic is very good. I think that now both simulations should be explained with more details.

  6. Erwin says:

    I don’t see any SILS image. 😦

    I also still don’t understand it. Many times the test results of the software depend directly on the used hardware. The HILS is a piece of software that simulates this hardware, either because it is too costly/dangerous to use real hardware or because the hardware is not available yet. Correct so far?

    Then what is SILS now? You only mentioned when it is coming into play, but not what it is.

    • Sory for not seeing the SILS image, I thought this has been corrected … I will try to solve it..
      Regarding the difference between the two: SILS and HILS is as follows: as the names imply, HILS is a testing approach in which the original HW is replaced

        by an equipment

      (meaning that is a piece of HW) designed to simulate its behavior, it is also called testbench. For instance, in automotive (it is the field that first comes into my mind πŸ™‚ )you connect the ECU (electronic-contrl-unit) to a box of circuitry that simulates the physical environment where that ECU will be placed in a car (can have various switches for turning on/off lights, can have the bulbs that shouls be in a real car … an so far)

        SILS is a software

      that allows a SW develloper to test its SW module as part of a whole SW system, before it is ready. In other words, for someone writing an application that controls lifting of the windows in a car (sorry, but another example from automotive πŸ™‚ ) the SILS is a black box SW component that simulates all the memory and communication drivers that the corresponding component neeeds to use. As a consequence that developper will write and test his component only using some APIs provided by that SILS, without being aware on which physical bus the corresponding signals will go, in which kind of memory (flash, eeprom …) will be saved its data …
      Hope it clarified a bit more ..

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: