Feb 19, 2015

Part One: The Trouble with Scheduling Remote SCADA

Posted by Sam Elsner

For folks out there in SCADA engineering, whether fresh data is arriving on your control screens or not is particularly important. In certain environments (like high-speed manufacturing systems), the decision process around what data to read when and at what frequency sometimes can be as simple as determining the fastest rate of change of your most frequently changing data point—and then designing your control system to request all of your data at least twice as fast as this rate. Yes, it is extremely nice to have dedicated, fast data pipes for all of your important process data. But for SCADA engineers in environments where devices potentially exist hundreds of miles away from a central SCADA operations center, running dedicated cabling to these locations is cost prohibitive if not logistically impossible. This means that to connect to equipment, an organization is often using leased and shared Ethernet or telephone lines or utilizing wireless data transfer technologies like radio, cellular, and microwave. These transfer mediums don’t usually offer anywhere near the performance that you’d need for a one-size-fits-all style of data collection frequency.

In order to overcome this, SCADA engineers iStock_000035356284Smallare forced to work in complicated software packages to design rigid, complex, and layered data acquisition schedules that attempt to read the right data sets at the right time at the right frequencywhile making sure that they are fully utilizing the expensive telemetry systems that connect to their devices. Those users in the Oil & Gas and Water & Wastewater industries will know this pain in particular.

With so many factors to take into account, creating data acquisition schedules is one of the most complicated efforts that any SCADA engineer can undertake—and that’s just the first step. Once a best-fit schedule is finally developed, the difficulty is compounded by a lack of easy-to-use tools in the data acquisition systems that actually bring the schedules to life. The need for scheduled data acquisition in environments with remote devices is an unfortunate reality given cost and currently-available technology, but if we hold it as truth that for the time being this requirement can’t change, there is still an opportunity to change the difficulty around creating these schedules in the software. 

You Spoke, We Listened

Over the last year, and at the request of our users, Kepware conducted significant market research to identify both the useful features and the pain points in today’s schedule-ready data acquisition systems. For the sake of brevity, and because it’s vernacular, I’ll call these systems “polling engines” for the rest of this post.

Customers we spoke with who use existing polling engines discussed a myriad of features that they would consider important and useful; for example:

  1. When creating a schedule, allow users to think in terms of logical relationships between data, not what device owns what data. In other words, devices shouldn’t own schedules. Instead, schedules should own data points, and those data points should be able to be pulled from any combination of devices, no matter the protocol or physical medium connecting the device to the polling engine.
  2. Allow users to create a schedule with relatively few clicks of the mouse. And better yet, allow users to configure as much of a schedule as possible externally and import the configuration elements into the polling engine. For example, if you are creating a schedule to read 300 contiguous registers, you can use Excel to create a CSV faster than any user could click through any polling engine’s GUI (no matter how streamlined that GUI may be).
  3. Allow users to quickly and easily change schedules in real-time to request data faster or slower than what the schedule's primary parameters define.
  4. Include a mechanism that allows a SCADA client application to manage parts of the polling engine’s behavior in real-time.
  5. Don’t build something that forces users to manage a driver read request queue. Give enough intelligence to the polling engine so that users don’t need to eliminate requests that have stacked up. Or, reprioritize requests to get more important data back before less important data.
  6. Don’t force a finite number of schedules on users.
  7. Don’t force a finite number of data points per schedule.

And the list goes on. Well, you spoke, we listened, and we have created a tool that we think will meet many of the requirements and requests that you graciously shared with us.

Stay Tuned

Check back in with us for my next blog post on scheduled data acquisition. In it, I’ll detail the features that Kepware determined were absolutely necessary to include in a solution that would ease our customers' workflow. I’ll also discuss how the KEPServerEX communications platform has been enhanced to support the delivery of this new solution. You can learn more about scheduling needs and how the new Scheduler Plug-In for KEPServerEX addresses them in Kepware's Scheduler whitepaper.

Download Kepware's Scheduler Whitepaper