Technology

Write the test once. Run it on every target.

One test project runs against a simulated vehicle, against an electronic control unit (ECU) on an Electron eins desktop unit, and on a test bench already in use. The test files do not change between them.

This page is written for engineers. If you are looking for what we sell and what it costs, start with the products. See the products

One project

Three places the same tests can run.

What changes between them is how much of the system is real. What does not change is the test project.

  • Software-in-the-loop

    A simulated vehicle

    The control software is real and runs on an ordinary Windows PC. Everything around it — the microcontroller, the sensors, the loads, the bus traffic — is a model. No hardware is involved at all.

  • Hardware-in-the-loop

    Electron eins, on a desk

    A real ECU, running the binary that will ship, connected to a desktop test unit over CAN — the vehicle bus — and over input/output lines. One unit per engineer rather than one rack per team.

  • Existing rig

    A bench already in the lab

    A rig already in use becomes one more place the tests can run, through an adapter developed for that rig. Adding a bench is an adapter, not a rewrite of the tests.

A test that needs real hardware is marked as such. A simulation run skips it rather than reporting a pass it did not earn.

Verified today

  • CAN bus interfaces
  • Tests written in Python
  • Windows desktop application
  • Adapters for existing rigs on request
One test projectPYTHON · VERSION CONTROLLEDSimulated vehicleSOFTWARE IN THE LOOPORDINARY PCElectron einsHARDWARE IN THE LOOPREAL ECU ON A DESKA bench in useHARDWARE IN THE LOOPALREADY IN THE LABADAPTER, BUILT PER BENCHThe test files are identical on all three.
Concept illustrationOne test project, three run targets. The adapter is developed per rig and is the only part that differs between benches.

Methods

Software-in-the-loop and hardware-in-the-loop, plainly.

Both run the same tests. They differ in what they are able to prove, and in when you can start.

Software-in-the-loop (SIL)

The code is real. Everything else is modelled.

The production build of the control software runs on a PC against a model of the vehicle around it. Nothing is rewritten for simulation — that is the point, because a model of your software proves nothing about your software.

Real

  • The production build, unchanged
  • Every branch and every fault path in the control logic
  • Calibration values, still parameters
  • The test cases themselves

Modelled

  • The microcontroller and its peripherals
  • Sensors, loads and the plant
  • Traffic from the other control units on the bus
  • Time, which need not run at the wall clock

Models are approximations. Software-in-the-loop moves most testing earlier. It does not replace the bench.

Hardware-in-the-loop (HIL)

The control unit is real. The vehicle around it is simulated.

A real ECU sits on a bench with its electrical interfaces connected to a system that generates the signals it would see in a vehicle, in real time, and reads back what it does in response.

Real

  • The ECU, and the binary flashed onto it
  • Its electrical interfaces and the signal levels on them
  • Bus traffic, on the wire
  • Timing, on actual silicon

Simulated

  • The plant: the mechanics, the loads, the environment
  • The other units the ECU expects to be talking to
  • Faults, injected deliberately into real circuits
  • Operating conditions that would be unsafe in a vehicle

This is where electrical behaviour, real-time response and fault reactions are proved — and where you confirm that the binary that ships is the binary that passed.

When each one is available

Software-in-the-loop is available from the first build that compiles, which is long before there is a board to run it on. It does not stop being useful when the hardware arrives: it stays the cheap place to run a large number of cases.

Hardware-in-the-loop is available once there is a unit to put on a bench. Up to that point the window belongs to simulation, and testing that waits for the window to open is testing that starts late.

The two also differ in capacity, and the difference is structural rather than a matter of degree. A bench runs one engineer’s test at a time, so a team shares it by queueing. A simulated target runs on each engineer’s own PC, so the whole team runs at once. The useful arrangement is both: simulation for volume, the bench for what only hardware can prove.

Reporting

100% passed is not the same as 100% tested.

A report saying every test passed answers one question: did the tests that were written pass? A release needs the answer to a different one: was the function tested?

Those two questions come apart, and the space between them has a shape. Three kinds of gap account for most of it, and none of them shows up in a pass count — a suite with all three can report 100%.

  1. Boundary

    A function changes behaviour at a threshold. If no case sits just either side of that threshold, the threshold was never tested. Only the comfortable middle was.

  2. Negative

    Tests are usually written to check that a function acts when it should. The case where it must not act matters just as much, and is written far less often.

  3. Equivalence

    One input is chosen to stand for a whole class of inputs. That is a sound technique — and it is also where a class quietly ends up represented by a case that was not representative of it.

COVEREDBOUNDARYEQUIVALENCENEGATIVEnever runINPUT PARAMETER AINPUT PARAMETER BEvery test in this picture passed.
Concept illustrationThe three kinds of gap a pass count cannot show, drawn over two input parameters. A drawing of the argument — not a test result.

So a run has to be reported twice over: what passed, and what the run covered. Software Studio shows a coverage view alongside the run result for that reason.

One note on AI

A function that learns makes coverage the only proof available.

Where a vehicle function is specified, a test compares its output against the specification. Where a function is learned, there is often no single correct output to compare against, so the pass count means even less than it did before and covering the input space means even more. That is the section above, applied to a harder case, and it is the whole of our interest in the subject.

Readiness: Planned

AI assistance for drafting plant models and test scripts inside Software Studio is planned, not released. We do not sell it today and the products above do not depend on it.

What this page does not cover.

How the software is built internally, and what its modules are called. If you are evaluating it, that is not the question anyway: half an hour on a demo with your own ECU and your own bus traffic settles more than an architecture diagram would.

Next step

See it run against your own ECU.

A demo on your part, your signals and your test cases, online or at our lab in India. Bring something that already gives you trouble.

Book a product demoContact our engineering team

We reply within 1 business day.