Whitepaper · Digital twins · Safety-critical systems tested without the hardware
Take the hardware out of the loop — and test overnight what took a season.
A device you cannot crash, a radio you cannot jam, a flight you cannot afford to repeat: put the hardware in the loop as a model instead. We build twins that boot your unmodified firmware, reproduce your radio bit for bit and run your controller a thousand times before breakfast, gated in CI on every push.
The first two run in our CI on every push; the third was measured on our own desktop AI system.
Your test plan is bounded by how many units you can afford to break
With the hardware in the loop, every test is bounded by how many units you have, how many people can hold them, and how many crashes the budget allows. The rare fault — the one certification asks about — shows up once a quarter and never on the bench.
A model that is nearly right is a liability: it passes tests the hardware fails. A twin earns trust only when it is checked against silicon — frame against frame, packet against packet, run against run — and when that check runs on every commit, not once at the start.
The device under test leaves the loop. The proof stays.
What we bring
Four things, each one measured on the hardware.
Unmodified firmware
Your production image boots in the model — the same bytes you ship. No test build, no stubbed drivers, nothing to argue about later.
Deterministic runs
Byte-identical results across processes, gated in CI, so a fault found at three in the morning reproduces at nine. A single microsecond of input difference is visible as a different run.
Validated against silicon
Vision engine pixel for pixel, radio bit for bit, controller trace for trace. The twin's agreement with the hardware is itself a test that runs on every push.
Scale that finds the rare fault
Thousands of flights, links or boots a night on one machine, with fault injection, fading, collisions and sensor noise that a bench cannot schedule.
Twins we run today
Silicon twins
45 camera-SoC machines boot unmodified firmware on the desktop, with the vision engine emulated and validated pixel for pixel against the chip. Every push to the driver runs against the twin before it touches a board, so bring-up bugs are found in CI, not on the bench.
Radio twins
Wi-Fi up to the current generation is transmitted and received on software radio, 35 configurations bit-exact, and used to validate our own driver on air. On a physical model of the link, a learned controller beat the measured-evidence controller under fading on both counts — less energy and more delivery — with the model kept tick for tick in step with what ships.
Control twins
A flight-controller simulator runs the pilot's real firmware with byte-identical determinism, virtual motor controllers, collision physics and a training environment. The same method reaches robots: on our desktop AI system a humanoid trains on rough terrain at 63,000 simulation steps a second, with video of every run rendered without a screen.
What we model
Camera & vision SoCsFlight controllersWi-Fi & custom radio linksRobots in GPU physics
Twins are delivered as CI jobs with the validation suite that proves them, so the agreement between the model and the hardware is a number your pipeline checks, not a claim in a report.
How an engagement works
Twin feasibility
Fixed price, fifteen working days. You send the firmware image or controller, the hardware — a unit or its documentation — and the test you cannot run today. You get your firmware booting in a first model, or your controller running in the simulator, the validation plan against silicon, and a fixed quote for the full twin.
The project
Build the twin to the fidelity the test needs, validate it against your hardware, and install it in your CI with the agreement check as a gate.
Keep
The twin, its validation suite and the CI jobs are yours; your team extends it as the product changes, and the gate keeps telling the truth.
Send the firmware and the test you cannot run. In fifteen days it will run.
One mail with four lines: the system, the test you cannot run today, what you can share, and where the tests should run. An engineer answers with a plan, not a sales script.
Write to business@openipc.org Ask in the chat
Commercial support, OEM licensing and the other services are on the business page.