Does your problem start with a physical process rather than a user?
Modelling, simulation, and instrumentation for problems where the physics has to be right before the software matters.
The problem
Software people are often handed a physical process — heat, flow, radiation, mechanics, optics — and asked to build a system around it without anyone having modelled the process itself. The result is code that fits the data it was tuned on and fails outside it, with nobody able to say why. The problem was never the software; it was that the physics was guessed.
How we approach it
We start from the governing equations and the measurements, and build a model that is as simple as the problem allows and no simpler. Where the model can be solved analytically we do that; where it cannot we simulate, and we validate the simulation against measurement before anyone trusts it. Instrumentation is designed with the model in mind, so we measure what actually constrains the answer. Only then does the software get built, on top of a process that is understood.
Worked example
Why the sensor readings drifted every afternoon
A greenhouse automation system was adjusting ventilation from temperature sensors that drifted by two degrees every afternoon, and the control software had accumulated three layers of corrections that made it worse. We modelled the radiative heating of the sensor housings themselves and found the drift was the housings, not the air: direct sunlight through the glass warmed them in a predictable pattern. A shielded mounting and a simple correction term derived from the model replaced all three software patches. The control loop became stable, and the software got shorter.
What you get
- A physical model of the process, with its assumptions and validity range stated
- Simulation validated against measurement, with the discrepancies explained
- Instrumentation and data pipelines that measure what constrains the answer
- Software built on the model, documented so the physics stays visible in the code