A hydraulic top-drive system in active service. The equipment earns while it runs, so it cannot be taken offline to suit an engineering schedule, and no test rig exists that behaves like it. Whatever gets written has to be correct against the real machine the first time it touches it. That is a different discipline from most software work. There is no staging environment and no safe window for rolling back, and the feedback loop for a mistake runs through several tonnes of moving hydraulic machinery.
A controller is a loop that keeps correcting a machine, and it only corrects well for the machine it was tuned on.
A control loop does one thing over and over. It measures what the machine is doing, compares that with what the machine should be doing, called the setpoint, and adjusts an output to close the gap. Then it measures again. A thermostat is the simplest example: too cold, open the valve, check again. In hydraulic equipment the same loop runs quickly, driving valves that move fluid under pressure to hold a speed, a position or a force.
The most common controller, PID, decides how hard to push from three views of the error: how large it is now, how long it has persisted, and how fast it is changing. Each view has a weight, called a gain, and choosing the gains is called tuning. Tuning is done against a particular machine in a particular state. Push too gently and the machine wanders away from its setpoint. Push too hard and it overshoots and oscillates, and on hydraulic equipment oscillation means wear, noise and stress on every component in the loop.
The trouble is that the machine does not stay in the state it was tuned in. Load changes what the controller is pushing against. Hydraulic fluid behaves differently as it warms. Seals and valves wear. Each of these changes how strongly the machine responds to the same push, so gains that were right at commissioning become too gentle in some conditions and too aggressive in others. Gain scheduling is the standard engineering answer. The controller keeps a set of tunings, recognises which operating regime it is in, and uses the tuning that fits, with limits on how far and how fast it may change. The idea is simple. The difficulty lies in choosing the regimes, bounding the transitions and showing that the result is safe, and that is where the engineering effort goes.
A controller with fixed gains is tuned at one operating point. Load, temperature and wear then move the machine away from that point, and a live machine never sits still. The controller does not fail loudly when this happens. It simply holds the setpoint less well, in conditions nobody is watching. Two more constraints bind beneath the control law. The loop deadline is part of the specification, and the protocol round trip to the PLC happens inside it. And the controller behaves according to how it actually implements Modbus, which is not always how the standard describes it, and that can only be discovered against this controller.
Control loops on live equipment fail slowly, and at their edges.
A fixed-gain controller almost never fails dramatically. It degrades. As load, temperature and wear move the machine away from its commissioning point, the loop holds its setpoint a little less tightly, overshoots a little more, settles a little later. Nothing alarms, because the controller is still working. It is working worse, in conditions that nobody has instrumented, and by the time anyone notices, the machine has been out of specification for some while.
The other failures live at the edges of the design. A loop that depends on a network round trip can miss its deadline when that round trip stretches, and a late correction is a wrong correction. A device that implements its industrial protocol differently from the standard behaves unexpectedly in exactly the cases the standard covers least. And an adaptive controller with no bounds can adapt itself into instability, which on several tonnes of hydraulic machinery is far worse than the drift it was meant to fix.
The reflex, and the fix.
A fixed-gain PID
Faster to deploy, well understood, and fine in a demonstration.
It cannot hold across the operating range of live equipment, and its degradation is silent, so nobody finds out until the machine is already out of specification.
An adaptive control law
More design and tuning work, carried out against a running machine with conservative bounds and a fallback to the known-good controller.
Stability across the range of conditions the machine actually meets, and not only at the point where it was commissioned.
Adapt to the operating regime, because the plant will not hold still and a silent drift out of specification is the worst failure available.
Protocol and transport as ground truth
The controller is read and written over Modbus TCP through an industrial VPN gateway. Its observed behaviour is treated as ground truth, ahead of what the standard says it should do. The round trip is measured and budgeted as part of the loop, never assumed.
A gain-scheduled law in place of fixed gains
The controller carries a tuning for each operating regime and moves between them, so stability holds across the load, temperature and wear the machine actually meets. The scheme runs inside a safety-instrumented basic process control system, which bounds what the adaptation is allowed to do.
The deadline as part of the specification
The loop closes inside its deadline with the protocol round trip included and headroom reserved. A control loop that meets its deadline on average and misses it occasionally is a control loop that occasionally does the wrong thing.
Correct against the running machine, first time
The only test environment is the equipment in service, which raises the bar on everything upstream: staged rollout, conservative bounds on adaptation, and the ability to fall back to the known-good controller at any point.
What each choice cost, and what it bought.
AChoosing adaptive control over a fixed-gain PID
A fixed-gain PID would have been quicker to deploy and easier to explain, and it would have looked fine on the day it was commissioned. The adaptive law costs more design and more tuning, done against a running machine. What it buys is a controller that holds across the conditions the machine actually meets, and protection from the worst failure available here, a slow and silent drift out of specification.
BBounding the adaptation and keeping a fallback
An adaptive controller allowed to change freely can find its way into instability. Bounding what the adaptation may do, inside a safety-instrumented basic process control system, means accepting a controller that is sometimes less than ideal at the edges of its range. Keeping the known-good controller available at every point means any problem has an exit that does not involve stopping the machine. On live hydraulic equipment those limits are the price of being allowed to adapt at all.
CPutting the round trip inside the deadline
It is common to treat communication delay as somebody else's problem and to design the control law as if measurements arrived instantly. Here the Modbus round trip through the VPN gateway is measured and counted against the loop deadline, with headroom reserved. That leaves less time for computation. In exchange the loop's timing becomes a guarantee, and each correction is applied to the machine as it is now.
DTreating the controller's behaviour as ground truth
The protocol standard describes how a device should behave. This controller behaves the way it actually implements the protocol. Learning that against the real device takes care and time on equipment that cannot be disturbed. It removes a whole class of surprises that would otherwise appear only in service, which is the one place where there is no room for them.
A single headline number hides where a system fails. This work was scored on the dimensions that actually decide whether it holds in production, measured on real, held-out cases rather than the demo path.
A controller tuned beautifully at commissioning that quietly stops holding specification a few months later, in operating conditions nobody instrumented, with no alarm and no obvious cause.
Stable control held across the machine's real operating range, on equipment that stayed in service throughout, over an industrial protocol path with the round trip budgeted inside the loop deadline.
What it owns, and what it hands to a person.
Adaptive control widens the range over which a controller holds. The plant still has to stay inside the envelope the law was designed for, and a mechanical fault is still a mechanical fault. The adaptation is bounded on purpose, because an unbounded adaptive law on live hydraulic equipment is a worse failure than a slightly detuned fixed one.
There is no machine learning in this engagement. The work is a control law, a timing budget, an industrial protocol, and the discipline of being correct against hardware you cannot stop. It sits alongside the real-time closed-loop work in robotics and the fail-closed architecture in defence, and the same discipline runs through all three. The deadline is part of the specification. The hardware is ground truth and the document is a guide. What the system does at its boundaries is designed in advance, never discovered in service.
A controller tuned at one operating point is only right at that point. If the machine's load, temperature or wear changes, expect a fixed-gain loop to drift.
Control loops rarely fail loudly. They hold setpoint a little worse over time, so judge them across the operating range and not only at commissioning.
In a networked control loop, the communication round trip is part of the deadline and has to be budgeted like any other step.
An adaptive controller needs bounds and a fallback, because unlimited adaptation on heavy equipment is more dangerous than mild detuning.
When a device and its protocol standard disagree, the device is right. Learn its behaviour against the real hardware.