Saturday, September 01, 2007

What does it mean?  "Real-time" is a heavily used (possibly over used) term in our modern vernacular.  We see claims like "real-time data" or "information in real-time"; however, there is generally no explanation of what real-time means in the context of the claim.  Iris Connection is no exception:  We too make claims about "real-time steaming data" in the Watchman's vPanelTM.  In this article, we'll attempt to define the meaning of real-time in the context of remote monitoring of water management systems, the realm of the WatchmanTM.

Generally, one thinks of "real-time" as synonymous with "fast" or "current".  More formally, however, definitions of "real-time" reference specific response-time constraints.  For example, according to the book Real-Time System Design and Analysis, by Phillip Laplante, IEEE Press, "A real-time system is a system that must satisfy explicit response-time constraints or risk severe consequences, including failure"

The actual time-constraints depend, of course, on the application.  Therefore, how "fast' or how "current" data has to be in order to be considered "real-time" also depends on the application.  For example, a real-time system that controls the ignition timing in a modern automobile engine may have sensor feedback time-constraints in milliseconds or possibly in microseconds.  If the time constraints aren't met, then the system fails to be real-time!  Alternately, another real-time system that provides "real-time" weather data may have data update time-constrains measured in tens of minutes or possible even in hours.  And yet this system with relatively slow data updates (relative to the ignition timing system) can be considered real-time simply because it meets the application's time constraints for real-time.

As stated above, the purpose of this article is to define the meaning of real-time in the context of remote monitoring of water management systems.  The real-time monitoring of the Watchman includes many different parameters of a water delivery / treatment system.  Examples include pressure, flow rate, water levels in holding tanks, electric utility voltage and current, free chlorine concentration, and diesel Gen Set battery voltage among others.  They may all have different time-constraints in order to be considered "real-time".

Let's first consider the monitoring of a battery used to start a diesel Gen Set, which is used for back-up power in the event of the electric utility power outage at a pump site.  The battery voltage may be continuously monitored as an indicator of its general health and ability to start the Gen Set's diesel motor when needed. 

Consider the example below of a vPanel display.  It displays the "current real-time" value of the battery voltage as well as a strip chart showing the last twenty-four hours of voltage values.  Monitoring a healthy battery's voltage is a little like "watching grass grow".  It doesn't change much, which suggests that data update time-constraints could be fairly long:  Minutes or, perhaps, even hours.

battery_voltage

However, before assuming data update rates of hours are ok for this particular parameter, consider more dynamic events that may affect battery voltage.  For example, we have seen problems with battery charger units that would only be exposed by much tighter update rates. 

Other equipment that is sharing the same utility power source may affect a defective charger.  Specifically, we have seen a defective charger significantly over charge a battery whenever a pump is running that happens to be on a shared circuit with the charger.

If this were the case, the above strip chart would show voltage spikes whenever the pump was running as long as the voltage data updates were dynamic enough to capture that data.  That is, the data update rates would need to be some fraction of the time that the pump may be running.  Typically, update rates on the order of a few minutes should suffice.  However, if the data update rate were on the order of hours, the defective charger would not be immediately detected.  It might be only after burning up many batteries before the problem was diagnosed.  Or worse, a battery failure may occur when the Gen Set is needed, which would, in turn, lead to a complete power failure and ultimately the temporary loss of a critical water supply.

Let's consider next a more dynamic parameter.  Suppose we are monitoring the pressure on the outlet of a pump that is delivering water to a closed system with a very dynamic demand, such as a large number of residential water connections.  The load is dynamic because water demand over a large  

number of residents can vary significantly during the course of the day.  There is no predicting when residents will run their showers or water their lawns.  However, any given resident expects water at constant pressure regardless of what the neighbor is doing.

Suppose further that a Variable Frequency Drive (VFD), which in turn, is being controlled by a Programmable Logic Controller (PLC) or, preferably the WatchmanTM, is driving the pump.  The Watchman (or PLC) will be constantly monitoring the pressure and adjusting the speed of the VFD to accommodate the very dynamic load while trying to maintain a constant pressure.

Consider the example below of a vPanel display for a booster pump that's driven by a Watchman controlled VFD.  It displays the "current real-time" value of the pressure and flow rates as well as a strip charts for each.   The pressure strip chart exhibits a "text-book" example of pressure regulation based on the Proportional Integral Derivative (PID) algorithm.

booster_pressure

In order to examine how well the pressure is being regulated in the above example, we would need data updates on the order of seconds, which the Watchman does for this case.  It should be noted that a standard SCADA system can not update remote monitoring at this rate, and would therefore, not be able to deliver real-time data for this application.

Again, real-time remote monitoring for water delivery and water treatment systems requires that data be updated at rates that are appropriate to the specific parameter being monitored.  We have examined a parameter that requires updates times on the order of a few seconds and one that requires update times on the order of a few minutes.  Most parameters of a water delivery system require response times which are somewhere in between.  In addition to the quality of real-time, data accuracy, resolution, and time determinism are qualities of remote monitoring that should be considered.  These are topics for future newsletters.

Leave a Comment
Your Name:
Your Email Address:
(will not be shown)
Your Comments:
Enter the code exactly as you see it in the image:
Code Image - Please contact webmaster if you have problems seeing this image code Load New Code