ACME Lightweight desktop tool · real-time control development

HIL-grade feedback, from day one of firmware development.

SIL is early, but not real. HIL is real, but late. Our Virtual Prototyping platform (VP-M) offers both — your actual production MCU, running your actual firmware, closed-loop in real time, before the prototype hardware exists. So your software team develops and builds confidence from the very beginning, instead of waiting on prototypes.

Early like SIL

Before hardware exists

Start developing and iterating control firmware before the prototype ECU, power stage, or physical plant is built — with no laboratory or instruments required.

Real like HIL

On real silicon

The exact production MCU, interfaced through real analog & digital I/O, in a hard real-time closed loop — not a host-PC model.

Lightweight by design

Lives on your desk

A desktop tool, not an instrument rack. Engineers validate on the real target MCU in real time without leaving the office — then swap the MCU or reshape the plant model as the design changes.

VP-M real-time monitoring software Green board = your target, tailored per project
This is VP-M — our desktop Virtual Prototype. The green top board is tailored to your target — change the MCU and we reconfigure the interface and the plant model. Everything beneath it is the same unit, every project.

Where it’s used

Built for power electronics

First time here? Here’s the short version of where VP-M fits. Wherever a controller switches serious power, the same firmware runs — and the same microsecond timing bugs bite. If any of this is your world, it’s built for you.

Electric drives & generators

Motor-control firmware where code becomes torque — traction and industrial inverters, gensets, and everything that spins.

Power supplies, every direction

DC/DC, AC/DC and DC/AC conversion, switching right at the edge of what timing allows.

High-power charging

The control behind HPC and fast-charge power stages — hundreds of kilowatts of DC.

Green energy

Solar and wind inverters that have to stay locked to the line, cycle after cycle.

Grid & energy storage

Battery storage, microgrids and grid-forming inverters that keep the grid steady.

Batteries & BMS

Cell monitoring, balancing and protection — where a late reaction isn’t a bug, it’s a safety event.

Working across Automotive Aerospace & Defense Energy Industry Education

Why it matters

The unseen business impact

The technology is a means to three outcomes an engineering director actually owns: time, cost, and schedule risk.

Time to market

Ship the software earlier

Control-software development stops waiting on hardware. The team builds and validates on the production MCU from the start — so firmware isn’t the item on the critical path.

Program cost

Fewer prototype spins

Bugs die on a desktop tool during development — not on scarce, expensive prototype ECUs or fully-booked HIL benches late in the program, where every fix costs more.

Schedule risk

Protect the launch date

Target-level and integration bugs surface in development, so late validation confirms a working system instead of firefighting one weeks before start of production.

20–30% higher engineering productivity across the firmware program
up to1 year earlier start of production — the whole software effort shifts left by a hardware cycle

Measured across our customer programs.

Shift left

Test where a fix still costs a code change

The whole field is being pushed the same direction: catch defects on the left of the V-model, in development, where fixing one is a code change — not a hardware respin, a booked-out bench, or a field recall. The later a defect is found, the more it costs to fix, and the curve is steep. For control firmware, though, the left side is exactly where you couldn’t test the parts that matter — so those bugs slid right, to the most expensive place to fix them.

SPEC · DESIGN IMPLEMENTATION INTEGRATION · TEST early / cheap late / costly Found today integration · HIL · field With VP-M in development SHIFT LEFT
Where the defects are caught. Today, control-firmware bugs cluster on the right of the V — found in integration, on the HIL bench, or in the field. VP-M moves that whole distribution left, into development, where the fix is cheapest.

And where a bug is caught decides what it costs to fix:

↑ COST TO FIX A DEFECT Design Implement Integrate Validate / HIL Field SHIFT LEFT Caught late — HIL / field 10–100× to fix Caught in development with VP-M · ~1× to fix
The cost-of-defect curve (after Barry Boehm’s cost-of-change work): a defect gets dramatically more expensive the later it’s found. Moving the catch-point left is the cheapest lever in the whole program. Multipliers are the long-standing industry rule of thumb; the shape is the point.

VP-M is how the control-firmware loop shifts left. The target-dependent testing that used to wait for a HIL bench or a prototype — real MCU, real I/O, real-time closed loop — moves into development. You’re not adopting another tool; you’re moving your most expensive class of bugs to the cheapest phase to fix them.

The problem

A structural constraint, hiding in plain sight

The bottleneck isn’t any one team’s fault — it’s an assumption baked into the workflow years ago, when firmware was simple enough that waiting for hardware was reasonable. It isn’t anymore.

Complexity has grown

Modern power-electronics software carries full AUTOSAR stacks, multi-core MCUs, and safety-relevant layers. Firmware is orders of magnitude more complex than a decade ago.

Workflows haven’t kept pace

The assumption that testing requires physical hardware access was reasonable for simple firmware. For today’s codebases it’s a structural liability.

The cost is invisible

No line item, no single owner. It hides in schedule padding, late defect discovery, and senior engineers waiting for bench access.

Two mature tools bracket the workflow. The step between them — where the target-dependent software actually comes together — has no tool at all.

Exists today · early

MATLAB / Simulink

Plant model · control algorithm — the MIL stage. Great for the algorithm, blind to the target.

No tool covers this today

The missing step

Integration · AUTOSAR · BSW · firmware · drivers · interfaces — the target-dependent software that never runs before hardware.

Our solution fills it
Exists today · late

Traditional HIL / bench

Functional validation — once the prototype ECU and plant finally exist.

So what is the bottleneck actually costing you?

Put real numbers on it — your team, your timeline, your lab time — in about two minutes.

Open the Hidden Cost Calculator →

The part no PC can run

Only a third of your code is the function

Here’s the trap in “just simulate it on a PC.” The application software everyone pictures is the minority of the binary. Most of what ships is platform — and platform only behaves like the real chip.

YOUR ECU CODE BASE — 100% ≈30–40% function software ≈60–70% OS · HAL · MCAL · drivers · registers · HW IP runs only on the real MCU — we run it for real
A modern ECU binary is mostly platform, not function. The other 60–70% — operating system, calibration, hardware abstraction (HAL/MCAL), drivers, libraries, register-level code and the silicon’s own hardware IP — only behaves correctly on the real microcontroller. A PC-based SIL can’t run it; even a target-level virtual ECU only models it on a simulated core. VP-M executes all of it, on the actual MCU — so the majority of your code is under test before hardware exists. (Split is a working industry rule of thumb; exact ratio varies by ECU type.)

Why power electronics is unforgiving

In power electronics, switching and timing are the product

A traction inverter switches a high-voltage half-bridge tens to hundreds of thousands of times a second. Correctness lives in microseconds — dead-time, the instant a PWM register updates, when the ADC samples, how long an interrupt takes. Put one edge in the wrong place and the output isn’t a little worse: the bridge shoots through, protection trips, or a control cycle silently disappears. These are real-time, on-silicon events — a non-real-time PC model cannot produce them.

Half-bridge PWM · 100 kHz · full 1 ms window 100 switching cycles — spot the fault
HS LS ? 0 10 µs / cycle 1 ms
Zoom · cycles 60–66
HS LS high-side held ON — one extra cycle

Did you catch it? A PWM register update landed a few microseconds late, behind an unlucky interrupt — so the high-side FET held on for a full extra cycle and a control step vanished. A silly mistake? Sure. Does it happen on real programs? Constantly. Would SIL catch it? No — it never runs the real interrupts on the real core in real time. We do.

Where VP-M sits

The empty corner: early and high-fidelity

Plot every option against the two things that actually matter — how early you can use it, and how faithful to the target it is. The valuable corner has been empty. The usual “middle” options don’t reach it; they just sit between, strong at neither.

EARLY + HIGH-FIDELITY the missing corner FIDELITY ↑ on-target silicon · live I/O · real-time loop EARLIER · NO PROTOTYPE → SIL early · low fidelity HIL high fidelity · late PIL a compromise VP-M
The two axes that decide the tool. SIL owns the bottom-right (usable immediately, low fidelity); HIL owns the top-left (high fidelity, but only once hardware exists). PIL — the classic in-between — is weak on both. VP-M reaches the corner that was empty: HIL-grade fidelity, available as early as SIL.

Side by side

The traditional path vs. VP-M

A line-by-line scorecard of the three approaches. Where VP-M and HIL both show a check, the capability is identical — the difference is everything around it.

 
Traditional
SIL
Traditional
HIL
Our approach
VP-M
Usable in the lifecycle ✓Development — early ✕Validation — late ✓Development — early
Prototype hardware needed ✓None ✕Full ECU + plant ✓Only the MCU (swappable)
Control runs on ✕Host PC ✓Real target silicon ✓Real target silicon
Real target timing & peripherals ✕No ✓Yes — native to the chip ✓Yes — native to the chip
Real electrical I/O ✕All virtual ✓Yes — real signals ✓Yes — real signals
Real-time closed loop ✕No ✓Yes — hard real-time ✓Yes — hard real-time
Reconfigures when design changes ✓Edit the model ✕Re-wire / re-fixture ✓Swap MCU · edit plant model
Cost & footprint ✓A laptop ✕Heavy, expensive bench ✓Desktop tool — no extra instruments

Why it isn’t a compromise

Best of both — not a watered-down middle

VP-M doesn’t split the difference between SIL and HIL — it takes the real strength of each. For the reader who wants the architecture argument in full:

›Why it concedes nothing on realism or earliness

The usual “middle” tools split the difference and end up genuinely good as neither SIL nor HIL. VP-M doesn’t split the difference — it takes the real strength of each.

PIL and real-time model-in-the-loop sit between SIL and HIL because they give up something on both sides: PIL is offline and step-locked, so it never sees closed-loop dynamics; real-time MIL still runs a model, not real silicon. Each is a concession.

It concedes nothing on the two axes that decide the tool. It has HIL’s realism — because the real production MCU really executes your firmware and really drives its I/O — and SIL’s earliness — because the only real part you need is that MCU; everything it talks to is emulated in the FPGA. That’s architecture, not a trade-off.

The reason it works: the real/virtual boundary is drawn at the MCU’s pins. Classic HIL draws it at the connector of a finished unit — so the whole ECU must exist. VP-M pulls the line all the way in to the silicon, and emulates everything around it inside one lightweight desktop tool. Only the brain is real; its entire world is simulated, and reshapeable.

Honest scope What VP-M is not — yet

It’s signal-level today, not yet power-level: no real power stage, gate drivers, high currents, thermal, or EMC. Power-stage capability is on the near-term roadmap. Full-ECU and vehicle-network integration still belong on a HIL bench later. Its job is to make that phase shorter, by killing the control-logic bugs during development so validation validates instead of debugs.

Turnkey, not a toolkit

Zero internal maintenance

Being right about the technology isn’t enough if adopting it is a project of its own. Every hour your team spends sourcing, wiring, modeling and babysitting a test setup is an hour not spent on your product. The alternatives sell you a kit of parts. We hand you a working environment, configured for your project — and we keep it running.

The toolkit approachwhat others ship
  • ☐Source and assemble the hardware, real-time host, and licenses
  • ☐Learn the platform and its modeling language
  • ☐Build and validate your own plant model
  • ☐Wire and interface it to your ECU yourself
  • ☐Cross-compile and glue it into your toolchain
  • ☐Maintain it forever — updates, breakage, version drift
The VP-M wayturnkey · cost-effective
  • ✓Arrives configured for your exact production MCU
  • ✓Plant model built — and kept current — with you
  • ✓Real I/O already interfaced to the target
  • ✓Plug in, flash, iterate — working out of the box
  • ✓Nothing to assemble, compile, or integrate
  • ✓Zero toolchain for your team to maintain — we own it

Dedicated to individuals, not projects.

Compact and affordable enough to sit beside every engineer integrating firmware — right at the desk, in a normal office, no lab required. Bugs get caught where the code is written, and never leave the desk.

In the box

A full monitoring suite, included

VP-M isn’t just the bench. It ships with PC software to drive it, watch it, and automate it — no extra licences, nothing to assemble.

Live dashboards

See the system’s state at a glance — clear, readable dashboards instead of log-diving.

Oscilloscope-grade recording

Capture every signal at full rate and zoom into any moment after the run.

Data acquisition

Stream and log exactly the channels you need, run after run, ready for post-analysis.

Live parameter tuning

Change parameters on the fly and watch the plant respond — no rebuild, no reflash.

API for automation

Script test sequences and regression runs through a clean API — hands-off, overnight.

MCP for AI workflows

A built-in MCP server — wire the bench into AI agents and automated test workflows.

In daily work

Not a pitch — a desk you work at.

A normal development loop, minus the wait for hardware and lab time: flash, run closed-loop, watch, tune, automate.

  • 1Flash firmware to the real production MCU — at your desk.
  • 2Run closed-loop against the emulated plant, in real time.
  • 3Watch live dashboards and scope-grade recording.
  • 4Tune parameters on the fly — no rebuild, no reflash.
  • 5Automate regression runs through the API and MCP.
  • 6The bug dies before lunch, on the desk.
DC bus
798 V
Phase current
142 A
Live capture · phase A
Switching
100 kHz
Loop
OK

Illustration — real product screenshots go here.

In one line

VP-M runs your real control firmware on the real production MCU, in a real-time closed loop, before any prototype exists — HIL-grade fidelity on your desk, so control software gets developed with confidence from the very beginning.

The business result: firmware comes off the critical path, prototype spins go down, engineering productivity goes up 20–30% — and start of production arrives sooner.

Book a 20-minute call → No prep, no obligation — grab a slot at calendly.com/david-kiss-acmegroup.
Prefer to explore first? Size the impact yourself.
Funded by the National Research, Development and Innovation Fund (NKFI Alap)