Control software verified before the prototype: model-based design and HIL
If the mechanical hardware arrives in six months, the software doesn't have to wait for it. But you do have to know how far the model can be trusted.
The problem: the critical path is always mechanical
On a gimbal or positioning system programme, the schedule is usually set by procurement and machining of mechanical parts, not by software. In the classic flow the software team waits for hardware, integration starts when hardware arrives, and the heaviest debugging period of the project lands exactly where the schedule has the least slack.
The claim of model-based design (MBD) here is modest but effective: take verification of the control algorithm off the physical hardware’s critical path.
The plant model: what is actually worth modelling?
Modelling everything is wasteful; modelling the wrong thing is dangerous. For a motor-load axis, the items that make a real difference are:
- Electrical dynamics — phase resistance, inductance and back-EMF constant in the d-q frame for a PMSM. Correct current-loop tuning depends on these.
- Friction — the viscous term is easy; what governs behaviour is the Coulomb and Stribeck region. Low-speed tracking performance and limit-cycle behaviour come from here.
- Backlash and drivetrain compliance — with a gearbox or belt, a two-mass model behaves qualitatively differently from a one-mass model, and this is where the resonance appears.
- Load inertia and unbalance torque — for a payload that tilts, gravity torque is a position-dependent disturbance.
- Sensor reality — encoder quantisation, latency and noise. Leave these out and the controller will be jitterier on day one in the field than predicted.
Model parameters are not guessed, they are measured: locked-rotor test, coast-down test, frequency response measurement. Skip that step and everything downstream is a good-looking but wrong simulation.
One parameter deserves a warning of its own. Friction is the term most people identify once and then treat as constant, and it is the term least entitled to that treatment. Bearing preload settles over the first hours of running, lubricant viscosity changes across the operating temperature range, and the Stribeck curve measured on a new unit in a warm laboratory is not the curve that unit has at the cold end of its range after a year in service. A low-speed tracking result verified against a single friction identification is verified against one point in the machine’s life.
The MIL → SIL → PIL → HIL chain
Verification happens in four layers of increasing realism, not one:
| Layer | What it verifies | Typical bug caught |
|---|---|---|
| MIL (Model-in-the-loop) | Algorithm logic, gain selection | Stability margin, overshoot, saturation behaviour |
| SIL (Software-in-the-loop) | Equivalence of generated C to the model | Fixed-point overflow, logic divergence |
| PIL (Processor-in-the-loop) | Numerical behaviour on the target processor | Rounding, cycle-time overrun |
| HIL (Hardware-in-the-loop) | Real driver board with its peripherals | Timing, interrupt contention, fault response |
The key point is that HIL does not replace the others. HIL is expensive and slow; hunting algorithm bugs there wastes time. Its real value is in fault scenarios: phase loss, a severed encoder cable, supply collapse, over-temperature. On real hardware these are either dangerous or unrepeatable; on HIL they can be run automatically every morning.
The bug HIL is actually there to catch
Ask an engineer what HIL is for and the answer is usually “the physics”. In practice the failures it earns its cost on are timing failures, and the most instructive one is where the current is sampled.
A motor driver measures phase current with an ADC while the same phase is being chopped by the PWM bridge at high frequency. The current in that phase is not a value; it is a triangle. Sample it in the middle of the switching period and you get something close to the average. Sample it a few microseconds off — because an interrupt arrived late, because a compiler ordered two instructions differently, because the ADC conversion is not where the datasheet’s timing diagram implies — and you measure the ripple instead. The current loop is then closing on a number that is systematically wrong, and it will still look stable. It shows up as unexplained torque ripple, a current loop that has to be detuned to stay quiet, or a fault threshold that trips at the wrong load.
None of that exists in MIL or SIL, because in those layers the measurement is exact and instantaneous. It only exists on a board with a real converter and a real interrupt controller, driving something that reacts. That is the layer HIL is for, and it is why a HIL bench with a slow or averaged I/O path is a bench that will pass this bug straight through.
Auto code generation: where it pays and where it doesn’t
Generating C from the model reduces the hand-written layer and makes model-to-code traceability concrete — which saves real time when assembling a qualification file. But generated code does not substitute for architectural decisions: interrupt structure, timing, the driver layer and fault handling are still designed by hand. A good practical split is: generate the control core, write the surrounding software.
The honest limits of the method
- A model does not replace reality; a model is a measured summary of reality. Without parameter identification, MBD is dressed-up guesswork.
- A model built on the same assumption as the controller will agree with the controller. This is the failure mode nobody notices, because every test passes. If the engineer who decided the load could be treated as one rigid mass also wrote the plant model as one rigid mass, the simulation will confirm a controller that meets a resonance it was never shown. The defence is not more simulation; it is a measured frequency response from the real axis, compared against the model’s, early enough to still change something.
- A plant model that cannot go unstable cannot verify a fault response. If the model saturates gracefully everywhere, the shutdown logic is never actually exercised.
- Thermal behaviour, long-term creep and assembly tolerances are rarely represented faithfully. Those stay in hardware testing.
- The HIL bench is itself a product that needs maintenance. A team that lets the model go stale will happily turn irrelevant tests green.
What changes in practice
Our observation is that this flow measurably shortens integration and — perhaps more importantly — improves the odds of not destroying the first prototype. By the time the driver board meets a real motor, current limits, fault states and shutdown logic have already been exercised hundreds of times.
Technical discussion and quotation
Tell us the platform and the constraint. Our engineering team answers with a configuration that fits it, usually within two working days.
