Adaptive Intelligent Recovery PID Loop
I am trying to write a PID loop for an Adaptive Intelligent Recovery type system. I only know the basics of how the system works and I was hoping that someone could explain it to me. I appreciate everyone's help greatly.
Bump. I've heard it called Smart Recovery also.
Originally Posted by tanksboard
You are probably not receiving much by way of replies from folks because ....
(1) You say you want to write a program (in what language, and for what platform, BTW?) for a PID loop. Adaptive Intelligent Recovery, or Smart Recovery, or --- insert term here --- isn't a PID loop. Essentially WHATEVER Recovery (call it what you want) is a section of logic which would include a database of historical run data, some calculation functions, etc which would tell a PID loop when to shift from using a set back set point, and instead to use an occupied set point.
(2) You say you really don't know much about a Smart Recovery type system. Well, welcome to the club. I do this sort of thing for a living, but I am not aware of any OFFICIAL definition for anything called an Adaptive Intelligent Recovery system, or a Smart Recovery system, etc. EXACTLY what each sort of scheme does, how it does it, what its called, and so forth is more a matter of each manufacturer's opinion ... and a matter of what each manufacturer's Marketing and Sales team thinks will look good in the advertisements and on sales brochures.
(3) All these various methods and schemes have only a general idea in common. That is, you can set up a schedule or series of schedules, designating times for when the system should use an "Occupied" (we're home and awake and want to be comfortable) set point, and times when the system should use an "Unoccupied" (we're not home, or we're asleep and under the blankets so we don't care if it gets 5 degrees cooler) set point.
The same as you could do manually by changing the thermostat whenever you leave the house, then again when getting home, then once again when you go to bed, and finally one more time when you wake up.
The difference being that if you wait until you get up in the morning to change the thermostat from a night time setting, for heating, of 62'F to 68'F you might well find yourself taking your shower in a cold bathroom. As, depending on your system, the amount of setback you do, the outdoor air temp, the size of your home, and how well it's insulated and sealed ... it might take a couple hours or more for the interior temps to go from 62'F to 68'F.
So the idea is, if you set 6 a.m. as your normal wake up time, and you want the space temp to be 68"F when you are taking your shower, dressing, eating breakfast, and such ... the "Intelligent" system should be able to figure out when to start using that 68'F set point so that when you wake up, at 6 a.m. the system will have achieved that 68'F space temp. In short, it will have figured out what time to start, which will be some time BEFORE 6 a.m.
In my work world (commercial BAS), we call this Optimum (or Optimized) Start/Stop.
Typically, for residential systems using some sort of Smart Stat scheme, the system stat collects some historical data. It might only be what temperature is indicated on the stat at "Wake up" time. The first day. Then it guesses at some earlier start up time, say start at 5:30 am instead of 6:00 a.m. The next day it tries this and compares how close its some to the goal temperature. If its off, it readjusts start time again. And checks the next day. So on and so forth until it has got it right. It may take several days to get it right.
Then it operates off that data.
Until it no longer works, then it keeps collecting data, and readjusts start time.
If you live in an area where day to day high and low temps might vary a LOT ... this can be a problem.
I live in such an area, BTW.
As a way to improve things, some such Smart stats can incorporate and use an Outdoors Air Temperature sensor (OAT). Usually an additional cost, both for the sensor, and the added installation cost. And might also include additional memory storage areas for keeping more (longer time period) historical data. Might include internally held data tables with seasonal average weather data for different areas of the country, which along with a clock and calender, and the user entering some info about where he/she lives, can be used as a factor in calculating final start time. Some, these days, will even include an internet connection and the ability to gather data from the latest weather forecast.
End result, generally speaking the stat figures out as best it can some offset from the set "wake up" time, to use for determining what time it should really start heating up to the occupied set point so as to achieve it at or close to that time.
In addition, such a scheme might also do the reverse. Calculate when to actually start the set back set point, so as to be at that temperature at or shortly after the setback time.
Insert any one of almost an infinite number of additional refinements, schemes and whatever here.
Frankly, most such I see, customer/user has disabled the "Smart" part, and simply use ordinary, by clock schedule, setbacks and setups. Adjusting start/stop times manually ... then leaving them at that. Or making a seasonal adjustment 2 or 3 times a year.
The reason? Most of the Smart Recovery schemes do not work all that well. In some cases they're difficult to understand and set, or to over ride when user wants THIS TEMP NOW. Or user gets upset when power outage causes thing to reset and start GUESSING and learning all over again. Or it can not be configured properly for the actual hardware system installed. Or for whatever reason.
In the commercial world, the Optimum Start/Stop scheme we use works pretty decent. User has to play around with a few adjustable variables to TUNE it for their building. But even so. many just turn off that feature. Just don't wish to deal with it. And instead change it to work as regular, scheduled time start/stop (switch from occupied to unoccupied). Then either adjust times manually from time to time so that Occupied is achieved at or before occupants arrive for the day. Or set em at fixed times and just let occupants get adjusted to the idea that it might be a bit warm or a bit cool during the first hour or so of their work day. DEAL WITH IT.
In most cases building owners, managers, and in house facility operations and repair personnel we deal with ... aren't gonna try to keep everybody happy and cater to fussy people. Usually set some standard heating and cooling set point, and advise occupants to dress in layered fashion. So they can remove and item, or put one on if a little too warm or too cool. On the principle that trying to maintain too close of a lower and upper limit on the space temps is neither energy efficient nor good for the long term MTBF (mean time between failure) of the equipment. And, in fact, no matter what set points you use ... some percentage of the occupants are gonna *****.
I've been in building where two offices, side by side, had occupants who in winter where one wanted 66 to 68 degrees and the other wanted 78 - 80 degrees. BOTH just as angry and adamant as the other that it be THEIR way.
As Osiyo correctly stated its not done with a PID loop, attached is a copy of a single drum in a program from an Andover system that was installed in the 1970's, still running today, and the Optimum start as it is called in this program works fairly good. I am not going to try and break down each line of code, but will say that the key component is a variable called RATE, which is a calculated number to change the start time of the system, once the building (variable A.AVE) is at the setpoint RATE is recalculated. This program does not take into account the outdoor temperature, I have seen newer modules in other systems that do, but unless the outdoor temperatures changes greatly from one day to the next this program works great.
Not saying that this Andover program is the best, just an example now it can be done, things have changed a bit from the 1970's and better built-in functions are available in many modern control programs.
When you talk, you are only repeating what you already know. But if you listen, you may learn something new. - Dalai Lama
Wow reading this thread about Adaptive Intelligent Recovery and figured I might learn something new, only to see an AC256 Drum program used as an example! Had to read it a couple of times just to make sure I wasn't hallucinating.
Just when I thought I had cleared all that old drum knowledge out of my brain, Kevins example brought it all back.
To his Kevins point that program worked ok, and certainly better then the historical lookup version engineers always specified back in the day. Not sure I actually saw one work.
I appreciate all of your guys feedback on this. It has opened many ideas as to how to approach this. As always, I still appreciate any input that anyone is willing to offer! Thanks again guys.