HIL Testing Software Compared 2026 (dSPACE, VeriStand, Typhoon)

HIL testing software runs a real-time plant simulation against real hardware, so an embedded controller can be tested as though installed in the real system. The platforms are expensive, capable, and largely non-substitutable once chosen.

The most valuable question in this category is not which platform to pick. It is whether the tests you plan to run actually need HIL, because the majority of tests that end up on HIL rigs do not.

First: do you need HIL?

HIL is the right tool when all of these are true:

• •You are testing a controller, not a component. Something with firmware that reads sensors and drives actuators.
• •The controller expects a plant you cannot safely, cheaply, or repeatably connect. An engine, a vehicle, a grid, a battery pack under fault conditions.
• •You need deterministic timing because the controller's own loops depend on it.
• •You need fault injection that would destroy real hardware.

If you are sweeping a regulator's load line, characterising a converter's efficiency, or checking a sensor's linearity, that is bench validation. It runs perfectly well on a supply, a DMM, and a load, and putting it on a HIL rig costs real-time licence money for no benefit. See what is HIL testing for the boundary in more detail.

The audit worth doing: list every test currently running on your HIL rig, and for each write the required loop rate and whether a plant model is loaded. Teams routinely find that a third or more of the tests need neither.

The platforms

1. dSPACE

The automotive standard. SCALEXIO hardware, ControlDesk for the operator layer, AutomationDesk for test sequencing, and a mature Simulink toolchain.

Strengths: deep model integration, excellent bus and I/O coverage, and the toolchain that most automotive OEMs and tier ones already require. If your customer specifies dSPACE, the evaluation is over.

Weaknesses: cost, at every layer. Hardware, software, and support are all premium. Vendor lock-in is substantial once a rig is built.

Pick it if: automotive, or the customer requires it.

2. NI VeriStand

Configuration-driven real-time on NI PXI and Linux Real-Time targets. Maps channels, loads models, runs stimulus profiles, provides operator workspaces.

Strengths: strong if you are already in the NI ecosystem, good channel mapping at scale, and integration with the wider NI hardware catalogue. Configuration rather than programming for a large part of the work.

Weaknesses: five-figure seats plus deployment licences per target, and it tends to pull LabVIEW in for custom devices. See NI VeriStand alternatives.

Pick it if: you have NI hardware and NI skills already.

3. Typhoon HIL

Specialist in power electronics and microgrids, with FPGA-based simulation reaching switching-frequency resolution.

Strengths: genuinely the right tool for inverters, converters, motor drives, and grid simulation, where the required simulation step is measured in hundreds of nanoseconds. General-purpose CPU-based HIL cannot reach that.

Weaknesses: narrower domain. Outside power electronics it is not the natural choice.

Pick it if: you test power converters, drives, or grid-connected equipment.

4. Vector CANoe and VT System

Bus-centric. Residual bus simulation, ECU testing, diagnostics over UDS, and network simulation.

Strengths: the best tool if the system under test is primarily a bus node. Restbus simulation and diagnostics are its core competence and it does them better than general HIL platforms.

Weaknesses: not a general plant simulator. Analog and mixed-signal plant modelling is not what it is for.

Pick it if: the network is the system under test.

5. Custom real-time Linux, plus OpenTAP for sequencing

The build-it-yourself option. PREEMPT_RT Linux, your own model execution, commercial or open I/O hardware, and OpenTAP sequencing tests against it.

Strengths: no licence cost, complete control, and appropriate for well-bounded problems with modest loop rates.

Weaknesses: you are building a HIL platform. That is a multi-engineer, multi-quarter project, and the maintenance never ends. Teams that go this way and succeed usually have a specific reason the commercial platforms do not fit.

Pick it if: requirements are modest and specific, and you have the engineering capacity to own it.

Comparison table

What separates them in practice

Loop rate versus domain. This is the real dividing line. A vehicle dynamics model at 1 kHz and a switching converter model at 1 MHz are different engineering problems, and no CPU-based platform reaches the second. If you are testing an inverter, Typhoon's FPGA approach is not a preference, it is a requirement.

Model source. If your plant models are Simulink and already exist, dSPACE and VeriStand both integrate them well and the choice moves to hardware and ecosystem. If the models do not exist yet, budget for building them, because that is frequently larger than the platform cost and it is regularly omitted from project plans.

I/O count and type. A rig with 2,000 channels across analog, digital, and several bus types is a different purchase from one with 40 analog channels. Get the channel list right before any vendor conversation, because it drives the hardware quote more than anything else.

Who operates it. Test engineers pressing run need ControlDesk or a Workspace. Developers running regressions need a CLI and CI integration, and the commercial platforms are weaker there than you would expect.

The cost structure to plan for

A realistic HIL programme, in rough proportions:

Plant model development is the line most often missing from the business case. A validated model of the system you are simulating is a substantial engineering deliverable in its own right, and an inaccurate model produces confident, wrong test results, which is worse than no HIL at all.

The recommendation

1. 1

   Audit first. Split your test list into "needs determinism and a plant model" and "does not". Only the first list justifies HIL.

2. 2

   Move the second list to bench automation. Free or low-cost tools cover it. See best test automation software.

3. 3

   For the remaining list, pick on domain. Power electronics means Typhoon. Automotive networks mean Vector. General automotive or aerospace plant means dSPACE or VeriStand.

4. 4

   Budget the model, not just the platform.

5. 5

   Insist on CI access. Whatever you buy, confirm you can trigger a run from a script without a human in ControlDesk. Vendors do not lead with this and you will want it within a year.

Questions to ask a HIL vendor

Vendor conversations go better with these, and they surface differences that demos do not.

• •What is the guaranteed worst-case loop jitter at my required rate, with my channel count? Not typical, worst case, with the I/O loaded. This is the number the whole platform exists to provide.
• •Can I trigger a test run from a script, headless, with no operator? Essential for regression testing and frequently weak on platforms sold on their operator interface.
• •What happens to my test definitions if I stop paying? Get it in writing.
• •How many deployment licences does my proposed rig need, and what does each cost? Ask for the mapping to specific targets.
• •What is the model development effort for my plant, and who does it? If the answer is professional services, price it as part of the platform.
• •How do I version-control the configuration? A rig configuration that only exists inside a GUI is a single point of failure.
• •What is the parts availability commitment for this hardware generation? HIL rigs live for a decade and a discontinued I/O card is a rebuild.

The headless-run question is the most revealing. A platform that cannot be driven from CI will not support the regression testing that justified buying it.

The test you can run before committing

If you can borrow or hire time on a rig, one exercise settles more than any demo.

Take your actual plant model and your actual controller, and get them running a closed loop on the platform for a week. Not the vendor's demo model, yours.

What you learn:

• •Whether your model compiles to the real-time target at all, which is a genuine risk with models built for offline simulation
• •The real loop rate you achieve with your model's complexity, which is frequently lower than the platform's headline figure
• •How long the integration actually takes with your I/O
• •Whether the toolchain fits how your team works

Teams that skip this discover the answer after the capital purchase, at which point the options are expensive. The week of rig time is the cheapest risk reduction available in a programme of this size.

The loop-rate question, answered properly

Every decision on this page reduces to one number, and most teams cannot state it. Here is how to get it.

The question is not "how fast does the system run". It is "what is the fastest thing my software must close a loop on". Closing a loop means reading a value, computing a response, and writing it back, with a deadline. If nothing has a deadline, you do not have a real-time requirement.

The fourth row is the one that gets misclassified constantly. A microsecond event does not create a real-time software requirement if an instrument with its own timebase is capturing it. Your software arms the scope and reads the result afterwards, which is a SCPI transaction, not a control loop.

If you cannot name the deadline and the consequence of missing it, you are not doing HIL, and the test sequencer comparison is the more useful page.

What a HIL programme costs beyond the software

The software licence is usually the smallest line, which is why software-first comparisons mislead.

The two that get underestimated are the plant model and the integration. A HIL rig without a validated model is an expensive I/O box, and model work is a modelling project with its own schedule, not a line item on a hardware order.

Common mistakes

• •Buying HIL for bench validation. The single most expensive mistake on this page. See the table above, then see NI VeriStand alternatives for how it happens.
• •Not writing down the loop rate and the jitter budget. Both numbers, in writing, before any vendor conversation.
• •Treating the plant model as a deliverable someone else provides. It is the core of the system and it is your domain knowledge.
• •Skipping fault insertion in the scope. Open circuits, shorts to battery, and shorts to ground are why HIL exists. A rig that only tests the happy path is a very costly simulator.
• •Ignoring deployment licences. Same trap as the rest of the industry: development seats are visible, per-target runtime licences are not.
• •Underestimating integration. Budget engineering months, not weeks, for the first rig.
• •Choosing the platform before the I/O count is known. Channel count and signal types drive the hardware, and the hardware drives the software choice more than the reverse.

Related reading

• •What is HIL testing
• •NI VeriStand alternatives
• •ADAS testing with HIL
• •Test sequencer software compared
• •Best test automation software
• •NI software licensing costs, the deployment-licence trap
• •Instrument control with VISA and SCPI, what bench work actually needs
• •LabVIEW FPGA and real-time, the NI real-time route
• •OpenTAP vs TestStand, for the non-real-time half
• •Automated test report generation, the output either way
• •Optimizing test coverage, deciding what the rig must exercise
• •Hardware testing best practices
• •LabVIEW alternatives, if the whole NI stack is in scope
• •SCPI command cheat sheet, for the bench half of a mixed programme
• •NI TestStand alternatives, the sequencer that often sits beside a HIL rig