Control theory knows a lot more algorithms. PID is arguably simple to implement but is not particularly good algorithm.
It kinda seems to me as if everybody red only the first page on control theory and decided they don't need to read further and base their solution on it.
PID will basically have you experience either large overshoots (which you will experience as overcorrecting to changes in demand) or slow adaptation to changes.
There is also possibility that your system changes and your PID parameters will cause the whole controller to misbehave.
I have implemented a controller for espresso machine boiler water temperature. Replacing PID with moving horizon estimator allowed me to cut time from startup until stable temperature by at least half and eliminate any measurable over or undershoots.
Of course the problem with applying PID to server capacity is that compute resources come in discrete chunks that are slow to bring online (‘computers’) rather than being a continually variable resource.
Why do you think PID is an improvement here? IMHO the bang bang approach is preferable because it behaves extremely predictably. Operationally, knowing how the system will react to extreme conditions might be more valuable than being a little more optimal.
Did you mean MPC by any chance? (which MHE is often used in tandem with)
If so, MPC is indeed a superior algorithm, but it also requires a dynamic model (LTI, or state space). Such a model may or may not be easy to identify -- it would require the characterization of the dynamics of data center operations.
PID on the other hand, while less optimal, is "model-free" (technically it has a model, i.e. its tunings can be thought to derive from IMC or direct synthesis, even though in practice hand tuning is common) in that it can respond to a wide variety of circumstances without knowing much a priori about the underlying dynamics. PID tunings are also amenable to optimization (products like Loop Pro are used in industry)
Due to their simplicity, PIDs are capable of operating at much higher frequencies than more complex algorithms like MPC. PIDs operate in the order of miliseconds or faster, while MPC operates in the order of seconds to minutes because it has to solve an optimization problem at every iteration, which is too slow for fast loops. In the hierarchy of control, there's supervisory layers on top (RTOs), then MPCs then PIDs. It's usually not either-or, but all together, working at different layers.
Even in industries where MPC is dominant, PID control is still ubiquitous and used alongside it, especially for local regulatory control loops. I don't have enough insight into data center ops to know if PID control is good enough but in my experience PID can be good enough for many applications -- most control loops in the world are essentially still PID. Not because more advanced algorithms don't exist, but because PID has the advantage of being just good enough for most purposes. (cost is also an issue: PIDs are cheap, while licensing costs for industrial MPC software range from 10s to 100k$)
This model can estimate future temperature of brew water based on current and past temperature measurements in various points in the system as well as on amount of water being pumped through the system.
There are four temperature measurements being made:
- ambient temperature
- water reservoir temperature (the thermometer touches the reservouir), though I am pretty sure this one could be estimated from past operation of the boiler.
- boiler temperature (the thermometer glued to the outside of the boiler at a selected point below water line)
- group head temperature (the thermometer glued to the outside of the group head at selected point). This one could also potentially be estimated from past operation but I tried it and it complicates my model too much.
In particular the model is designed to be able to calculate a single parameter, what is going to be the water temperature if used for brewing coffee, at a point in future, if heating element keeps adding given amount of energy and pump pumps given amount of water.
The way the model is being used depends on what the machine is waiting for. For example, when you want to brew coffee, it delays start of brewing until it can achieve stable temperature.
To achieve this as fast as possible (ie power on from cold to stable temperature) the machine is heating water at maximum power and the model is being executed 50 times a second to estimate what will be maximum temperature attained by brew water if we shut the power now. The idea here is we want to run the heater at max power for as long as possible and shut it off at exact moment so that the heat that spreads will cause the brew water to achieve the exact desired temperature.
Mind that brew water temperature is not measured directly. I can only measure it experimentally with a modified portafilter.
The parameters of the system are being observed and I use other filters to correct the parameters as system changes. For example, the system can detect amount of boiler scale developing rather precisely, mainly due to how it affects impedance between water in the boiler and the temperature sensor.
---
Now, I am pretty sure it is overkill for an espresso machine. I am doing this to teach myself some control theory. But the effects are real and the algorithm works like magic -- the machine starts and achieves optimal temperature in shortest possible time and then keeps it stable with no over or undershoots that could affect the brew.
In todays world the chips that can run this model are being sold for pennies and the only real complication is rather precise, noise free temperature measurement that you need for this plus measurement of amount of water being pumped.
Is it really that hard/complex to calculate MPC that it can't be stuck inside a loop that runs at 1hz or less? Talking on decent generic or dedicated hardware. Some tiny SOC is a different story.
In reality, we know that this is not realistic. Over provisioning results in an immediate financial cost (that can be easily modeled in $$$), but under provisioning results in a far more complex penalty. I think it'd be important to understand these costs (along with the general shape of your traffic) before implementing a control system.
Furthermore, it's very likely that you'll want to implement a deadzone, and almost certainly you'll want to implement a low pass filter, especially if you're sampling processing time significantly faster than ~30 seconds (the estimated startup time). Oh, and the usual things like anti-integral windup, and hard limits so you don't bankrupt yourself.
Good day :)
I'm curious if there exists something intelligent enough to be able to rely on it for a large-scale deployment without human oversight? In general, I would think dead simple and manually controllable is a feature in the context of expenditure.
> Replacing PID with moving horizon estimator allowed me to cut time from startup until stable temperature by at least half and eliminate any measurable over or undershoots.
I'm familiar with PID controllers, but haven't used MHE before. The formulas look really similar at first glance to me. Three terms and three weights? Is a slow PID controller due to poor tuning, or is MHE intrinsically better? What is the reason that MHE would adapt more quickly with less overshoot than PID? MHE appears to be three integrals instead of one, but I don't see immediately why that would be better, is there an intuitive and/or fundamental reason?
I think without a context that's a no. Some systems will want good throughput, some want low latency and require pre-scaling on some cues (time of day, day of week), some want minimal cost but do want to allow bigger bursts for a max of N minutes, etc.
Any intelligent scaling without human oversight has a good chance of either burning your money or not optimising for what you care about.
A model predictive controller will need much less iterations because it would actually try to predict number of servers necessary based on some kind of model of the server farm.
Parameters for that model can even be learned/adjusted over time, automatically.
I chose Silvia mainly because it doesn't have its own electronics, it is all 230V AC wiring, thermostats, switches, etc.
I made myself a precise thermometer with PT 1000 probe inside coffee puck and I learned the temperature can vary as much as 10-15 degrees.
I first used PID but was not satisfied with long settling time, because when water is right temperature at the boiler it still needs to pass through huge hunk of metal that will determine to large extend the end temperature of brew water.
So I built a bit more complex algorithm with the aim of first getting the water a little hotter in the boiler (while grouphead is still cold) and then slowly adjusting setting for the boiler as the grouphead heats up.
But there were still problems, for example pumping cold water into the boiler threw everything into chaos. Then the problem that you get temperature readouts with delays and offsets.
That's when I decided to just build a more complete model of the system that does not only take current but also past states of the system into account.
To answer why PID, basically somebody I follow asked this question on twitter, and I thought yeah why not seems like a reasonable thing to try :)
Actually I do conclude that PID is not quite the right thing for this problem. For me the learnings from making a PID sort of work for this problem were:
1. must use the right error function. like frequency not time. 2. must use shrinkage on the error to handle discrete number of server. 3. have to run controller at a multiple of server delay to avoid perturbations.
Also I discuss the basic assumptions that a PID controller makes that are suboptimal in the video.
PID are simple to implement but tricky to tune.
In your case you could probably have solved most issues by improving tuning.
> PID will basically have you experience either large overshoots (which you will experience as overcorrecting to changes in demand) or slow adaptation to changes.
Such a blanket statement is meaningless without a description of the system you are controlling, those kind of overshoot can be attributed to wrong parameters, to badly sized elements of control or even to bad measuring devices, the PID algorithm has zero to do with those cases.
> I have implemented a controller for espresso machine boiler water temperature. Replacing PID with moving horizon estimator allowed me to cut time from startup until stable temperature by at least half and eliminate any measurable over or undershoots.
Did you try a "bang-bang" controller,I would no be surprised if you'd get the same results with 1% of the complexity.
What do you think is the relation between boiler water temperature and the water that actually reaches coffee?
When the machine starts, the grouphead is cold. If you want to get good brewing temperature you need to, either
a) Wait for 40 minutes until grouphead heats up slowly and everything stabilizes
b) Heat up water for 10 minutes and then pump a lot of water through the grouphead to get it hot from the water and pray everything works well
c) Build a model that will predict correct setting of water in the boiler given predicted temperature of the grouphead so that when you push water through the grouphead it cools just the right amount. Unfortunately, the correct brew temperature is 92C so you only have couple of degrees to work with. But, still, heating the water to higher temperature causes grouphead to heat up faster and you don't need to heat it as much because it will receive hotter water.
Commercial machines do not have this problem because they are started in the morning and only turned off for the night and they have huge tanks of brewing water in them so inflowing water does not affect the temperature so much.
From the abstract of [2]:
We evaluate a specific design for a resource closure operator by simulation and demonstrate that the operator achieves a near-optimal balance between cost and value without using any model of the relationship between resources and behavior. Instead, the resource operator relies upon its control of the resource to perform experiments and react to their results. These experiments allow the operator to be highly adaptive to change and unexpected contingencies.
Not my field so not sure if anything significant has been done using this in the past 10 years, or if it fizzled out.
[1]: https://www.duo.uio.no/handle/10852/8753
[2]: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.304....
Could you give an example ? I don't think PIDs are chosen for their optimality properties.
I'd like to see an example of when you think PID is an ideal choice? I've never found a real usecase. Whenever I've hacked one into anything, I've quickly replaced it with something simpler and better (thermostats being the most obvious example).
