Behavior of a Deadband Controller
Deadband Controllers result in a process variable that oscillates between the bottom of the deadband and the top of the deadband. The smaller the deadband (and/or the higher the Flow Capacity), the more frequent the oscillations.
To illustrate this, consider the following example. In this model, there is a “noisy” inflow of water to a pond that changes daily (with a mean of 50 m3/day) , and the Deadband Controller is an Outflow Controller (i.e., an outflow is turned on and off). The outflow rate is set to 60 m3 (enough to make up for the average inflow). The goal is to maintain the volume near a target of 3000 m3 with a deadband between 2975 m3 and 3025 m3:
As can be seen, the Controller performs quite well. Note, however, that something looks unusual about this plot. In particular, it appears that the outflow is switched on and off before the volume actually reaches the top or bottom of the deadband. The reason for this is that the timestep A discrete interval of time used in dynamic simulations. for this model is 1 day. Hence, the plot is only showing the time points for every day. But if the process variable is a state variable The output of an element in GoldSim whose value is computed based on the historical value of the element’s inputs (as opposed to only being a function of the current value of the element’s inputs). State variables have well-defined initial conditions. Feedback loops can only be created if they contain at least one state variable. (and in this example it is), GoldSim inserts an unscheduled update whenever the top or bottom of the deadband is reached. We can actually see this by displaying unscheduled updates Timesteps that are inserted automatically by GoldSim during a simulation and are not directly specified by the user prior to running the model..
When we do this, we see that the top and bottom of the deadband is indeed reached:
Because GoldSim inserts unscheduled updates in this case, the actual scheduled timestep that is specified does not affect the behavior of the Controller (there is always a timestep exactly when it reaches the top or bottom of the deadband).
Note, however, that this is not the case if the process variable is not a state variable. In this case, GoldSim can only check to see if the process variable has reached the boundary at the scheduled timestep. Hence, it may not be able to respond (e.g., by turning on or off the flow) until the process variable has moved outside of the deadband.
Note: In most cases, the process variable will indeed be a state variable (e.g., the output of a Pool A stock element that integrates and conserves flows of materials. A Pool is a more powerful version of a Reservoir (it has additional features to more easily accommodate multiple inflows and outflows). or a Reservoir A stock element that integrates and conserves flows of materials.). However, in some cases, the process variable may not be a state variable (e.g., if the process variable was and Expression that was some function of one or more state variables).
Here is the same example in which the process variable is not a state variable (this was forced to be the case by simply making the process variable an Expression that was equal to the Pond volume):
As can be seen, the performance is much worse. The performance in this case can be improved, however, by using a smaller timestep (here it is reduced to 0.1 day):
Hence, whereas the performance of the Deadband Controller when the process variable is a state variable is independent of the scheduled timestep length, the performance of the Deadband Controller when the process variable is not a state variable is strongly dependent on the timestep length.
The performance of the Deadband Controller is also a function of the Flow Capacity. Here is the same example (this time with the process variable defined as a state variable, and unscheduled timesteps displayed), in which the Flow Capacity is doubled (from 60 m3/day to 120 m3/day):
A higher Flow Capacity causes many more oscillations.
Of course, the Flow Capacity can also be specified as being too small. Here is a case where instead of the uncontrolled inflow having a constant mean, it steadily increases:
In this model, the Flow Capacity is 100 m3/day. Initially, it can effectively counteract the inflow (with increased oscillations). But as the inflow increases, eventually it can no longer keep up and the process variable just keeps rising. This could be addressed, of course, by simply making sure that the Flow Capacity was sufficient to counteract the inflow (e.g., increasing it to 170 m3/day). In this case, however, this would result in a large number of oscillations (particularly at early times while the inflow is low). To address this (without creating a large number of oscillations), the Flow Capacity would need to be specified as changing with time (to reflect the increasing inflow rate).
The behavior of the Deadband Controller can be summarized as follows:
- The Deadband Controller is typically used to simulate the actual behavior of a system that controls the process variable by abruptly turning a flow on or off (e.g., a thermostat, a pumping system that is triggered at certain water levels).
- Such a Controller can be most realistically represented by ensuring that the process variable is a state variable. In this case, the behavior of the Controller is independent of the scheduled timestep.
- Deadband Controllers result in a process variable the oscillates between the bottom of the deadband and the top of the deadband. The smaller the deadband (and/or the higher the Flow Capacity), the more frequent the oscillations.
- Unless the Flow Capacity is very high, however, the process variable does not necessarily stay within the deadband since it is possible that the uncontrolled flows could, at least temporarily, exceed the flow being controlled.
An example model which illustrates the basic use of the Deadband Controller (Deadband.gsm), in particular, the cases discussed in this