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.
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.
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.
- 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.