Answer the expensive questions before you build the hardware.
Modelling and simulation for connected products: circuit, thermal and system models, live digital twins of deployed equipment, and honest assessment of what a model can and cannot tell you.
Two different things share this name
“Digital twin” is used for two distinct activities, and conflating them causes disappointment.
The first is simulation during development: modelling behaviour before hardware exists, so design decisions are made with evidence instead of intuition. The second is a live twin of deployed equipment: a model kept in step with a real machine using its own telemetry, used to compare actual against expected and to test changes safely.
Both are useful. They require different work and they answer different questions.
Simulation during development
- Circuit simulation. Verifying topology, stability and behaviour at corners before committing to a board.
- Thermal modelling. Where heat goes in the real enclosure, which is usually harder than the electrical design and more often wrong.
- Power and energy modelling. Runtime across duty cycles and temperature, before a battery is chosen. See battery and power engineering.
- Signal and interference analysis. Supporting layout and EMC decisions. See EMC and compliance readiness.
- Algorithm development on recorded data. Developing and testing detection or control logic against real captured signals, long before it has to run on a device.
- Hardware-in-the-loop. Exercising firmware against a simulated environment, including the rare and dangerous conditions you cannot safely reproduce physically.
Live twins of deployed equipment
Once equipment is instrumented and reporting, a model fed by that telemetry can maintain an expected state alongside the observed one. The useful output is the difference between them: a machine drawing more power than the model says this cycle should need is telling you something before any threshold is crossed.
This also provides a safe place to try changes. Evaluating a different operating parameter against a model does not risk production, though a model’s answer is a hypothesis to be tested, not a result.
How we help
- Deciding whether a model is warranted. Sometimes building the thing is faster and cheaper than modelling it, and we will say so.
- Model development. Circuit, thermal, power and system-level models at the fidelity the question requires, rather than the maximum achievable.
- Validation against reality. Comparing model output with measurements from actual hardware, and stating where it diverges.
- Data pipeline for live twins. The instrumentation, collection and storage that a twin depends on. See IoT development.
- Deviation detection and interfaces. Turning expected-versus-actual into something an engineer can read and act on.
- Test environments. Hardware-in-the-loop rigs for firmware development and regression testing.
What a model will not do
A model reflects the assumptions built into it. It will confidently produce output beyond the range where those assumptions hold, and it will not announce that it has left them. Unvalidated models are a way of formalising a guess.
So a model’s value depends on validation against measurement, on the fidelity matching the question, and on the limits being stated. A live twin additionally depends on the quality of the telemetry feeding it: a twin built on poorly chosen sensors inherits every one of their weaknesses. See sensor selection and signal conditioning.
We would rather deliver a narrow model that is validated than a broad one that is merely impressive.
What you receive
The models with their assumptions and validity range documented, validation results against measured data where hardware exists, any test rigs or pipelines built, and the interfaces through which the output is used.
Related
AI for industrial machinery, predictive maintenance programmes, idea to working prototype.
What question do you need answered?
Tell us the decision the model is meant to support, and whether hardware already exists to validate it against.
What clients ask before starting
Is a model worth building for our product?
Not always. Sometimes building the thing is faster and cheaper than modelling it, and we will tell you when that is the case. A model earns its cost when the question is expensive to answer physically or unsafe to test directly.
How accurate is a model?
Only as accurate as its validation. A model will confidently produce output beyond the range where its assumptions hold and will not announce that it has done so, which is why we validate against measurement and state the limits.
Do we need a digital twin to do predictive maintenance?
No. Condition monitoring and departure detection work from measured behaviour without a physics model. A twin adds value where you want expected-versus-actual comparison or a safe place to evaluate changes.