Courses: Introduction to GoldSim:

Unit 13 - Modeling Discrete Events

Lesson 9 - Exercise: Using Status Elements for Feedback Control

One of the most powerful applications for the Status element is to model a common type of active feedback control: managing to a target.  In this Lesson, we will work on an Exercise that illustrates this.  However, in order to do so, we need to refresh our memory about a problem we discussed back in Unit 8, Lesson 7. In that Lesson, we pointed out that in many engineered (and social and organizational) systems, there is active feedback control designed directly into the system to make it behave in a specified manner.  A thermostat is the classic example of this (the heating and/or cooling rate is adjusted based on the current temperature).

The goal of a feedback control system like a thermostat is to control the value of a state variable in the system by actively adjusting additions and withdrawals to that variable. In the case of a thermostat, the state variable is the amount of heat in the house (quantified via the temperature) and the additions and withdrawals are controlled by turning on/off the heat or air conditioning.

In the problem we discussed in Unit 8, Lesson 7, we considered an analogous (but simpler) system: water flows into a pond (and we have no control over that inflow). We wish to actively control the volume of water in the pond (maintaining it at a target value) by turning a pump (that removes water from the pond) on and off. Hence, the state variable is the amount of water in the pond. Let’s briefly revisit that model now.

The model can be found in the “Examples” subfolder of the “Basic GoldSim Course” folder you should have downloaded and unzipped to your Desktop, and open a model file named Example3_Feedback_Control.gsm.  The model looks like this:

There is an Initial Volume (1 m3), a constant Inflow to the pond (100 m3), and a Target volume (300 m3).  The Withdrawal from the pond is the following Expression:

That is, when the pond volume is greater than or equal to the target volume, the pump is turned on.  When it is below the target volume, it is turned off. Note that the Pumping_Rate is larger than the Inflow (it is defined as 200 m3/day), so when the pump is turned on, the volume in the pond is reduced. The feedback loop between the Pond and the Withdrawal is apparent.

At first glance, it seemed that this logic would work, but when we ran the model and looked at the results, it became apparent that the logic was faulty. Run the model again now and double-click on the Result element.  The result looks like this:

As you can see, the pond fills up, and the volume does remain very close to 300 m3.  However, if we look at the pumping rate, we see that we have created a system that actually oscillates rapidly.  As soon as the volume reaches the target, the pump turns on, the volume is reduced and the pump turns off, and so on. The timestep for this model is 1 hour, and hence the pump oscillates on and off every hour. In fact, if we reduced the timestep to 1 minute, as long as the pumping rate is high enough (and it is), it would oscillate every minute! If the Initial Volume starts above the target rather than below, you would also see this same oscillatory behavior once it reached the target. Clearly, the system would never be designed to operate like this in the real world.  If a thermostat worked this way, the furnace would be turning on and off every few seconds!

So how is such a system actually controlled (and how can we simulate that in a realistic way)? In the real world, feedback systems like thermostats use what is referred to as a dead band or a target range within which the system is controlled. That is, instead of saying “turn the heat on when the temperature drops below 70 degrees and turn it off when it goes above 70 degrees” (which would result in continuous oscillatory behavior), we define a range and say  “turn the heat on when the temperature drops below 69 degrees and turn it off when it goes above 71 degrees”.  This, of course, also results in oscillations, but they are controlled oscillations (with the size of the dead band controlling the period of oscillations).

In GoldSim, the Status element is what we can use to simulate this in a very realistic and accurate manner.

To illustrate this, let’s do an Exercise.  This Exercise will start with the model we are discussing (that resulted in the oscillations).  Again, the model (Example3_Feedback_Control.gsm) can be found in the “Examples” subfolder of the “Basic GoldSim Course” folder you should have downloaded and unzipped to your Desktop.

We are going to make the following changes to this model:

  • Delete the Inflow Data element and replace it with a Stochastic element of the same name. Define the Stochastic as an Exponential distribution with a mean of 100 m3/day.  Resample the distribution every hour.
  • Instead of maintaining a target of 300 m3, maintain the volume between a 10 m3 band around that value (i.e., ranging from 295 m3 to 305 m3).

Now see if you can determine how to use a Status element to manage the volume within the specified band.

Stop now and try to build and run the model.

Once you are done with your model, save it to the “MyModels” subfolder of the “Basic GoldSim Course” folder on your desktop (call it Exercise22.gsm). If, and only if, you get stuck, open and look at the worked out Exercise (Exercise22_ Feedback_Control.gsm in the “Exercises” subfolder) to help you finish the model.

Your model should look similar to this:

Defining the Stochastic as an Exponential is straightforward.  The resampling trigger for the Stochastic should look like this:

The element Band is a Data element set equal to 10 m3. 

The two key changes to the model are modification of the Withdrawal Expression and the addition of a Status element.  Let’s look at the Expression first:

Note that instead of referencing the Pond volume, the Expression references the Status element (Pump_On).

The Status element (named Pump_On) tracks whether the pump is on or off. It starts off (since the Initial Volume of the Pond is 1 m3).  The Triggering dialog for setting the Status to True (i.e., turning the pump on) looks like this:

So the pump turns on when the Pond is greater than or equal to 305 m3. Recall that the “At Stock Test” trigger causes the event to be triggered at exactly the point where the condition becomes True (it inserts a new timestep to do so if necessary).

The Triggering dialog for setting the Status to False (i.e., turning the pump off) looks like this:

So the pump turns off when the Pond is less than or equal to 295 m3.

If you run the model, it will look similar to this (due to differences in random number seeds, if you built your model directly yourself it will look slightly different):

Note that rather than oscillating continuously, the pump is turned on and off in a controlled (and relatively infrequent) manner.

Note: Just because the pump was turned on at 305 m3 does not mean that the volume cannot exceed that value (since water is still flowing in and could temporarily exceed the pumping rate).  If you truly needed to ensure that the volume never exceeded 305 m3, you would need to turn the pump before it reached that volume.

Note: If you were actually trying to control the volume of water in a pond like this, the triggers to turn the pump on and off would not be the volume (as this is typically not something that can easily be monitored).  Rather, it would be the water level.  In your model, you would convert the volume to a water level (probably using a Lookup Table), and then trigger the Status element based on the water level.