Tutorial: Designing large-tag-count SCADA systems

In tutorial provides best-practice advice for SCADA systems so their tags (data points) are manageable.

By Control Engineering Staff February 26, 2009

By Steve Carson, MultiTrode

A lot of SCADA systems involving telemetry, especially in the water/wastewater industry, have a minimal amount of data coming from each site. When just a few I/O from each site are sent back over a radio network to a SCADA system, a wastewater collection system with 100 sites might have only 1,000-2,000 tags. (These data points can be either an analog value like “level” or a digital value like “pump running.”) With the addition of a treatment plant or two, a fully integrated system may be double that size. As progressive system integrators have implemented more integrated control systems with PLCs and RTUs, however, tag counts have risen significantly. Proper planning is required to build and successfully manage a system of this magnitude.

Parasyn, a system integrator based in Brisbane, Australia, has had a lot of experience with large SCADA systems. And, somewhat unusual for a system integrator, Parasyn is continuously performing R&D in new areas of SCADA technology. “SCADA systems aren’t scalable out of the box; you have to plan with the final footprint in mind,” says Tony Poole, managing director of Parasyn.

How to plan a SCADA system with a large tag count

Plan your system design with the outputs in mind.

Determine the inputs and how they need to be sampled and processed.

Develop a data management strategy and factor in plenty of testing time to ensure the system performance is acceptable before it goes anywhere near your valuable assets.

Definitely don’t implement a system and then start working on the performance and update speeds, or the results will be much like many poorly designed SCADA systems—slow!

This might seem controversial to anyone who has read a brochure from one of the major SCADA platform providers. Unfortunately, the statement “Brand X runs a one million point SCADA system” is a meaningless statement without a lot more definition.

“The right place to start,” Poole says, “is with the business outputs. What does the organization want out of the SCADA system? These requirements may include:

Access times– for alarm annunciation and alarm acknowledgement;

Data resolution– e.g. for each data point, what kind of deadband or time resolution is needed for later reporting or analysis;

Visualization tools– e.g. the number of data points on the graphical interface verses the update time needed;

Reporting requirements– what kind of reports are needed and how often are they being run.

w to manage the flow of data across all the platforms is the key to application performance and business success.” Time series data and its relationship to the historian can be especially challenging. 

Time stamps. An essential element of building an efficient and scalable SCADA system is data, which is date- and time-stamped in the field. A SCADA system that is real-time demands 100% availability– 365 days of the year – because you can’t afford to miss events. Data that doesn’t get a date/ time stamp from the field requires the SCADA system to acquire, store and process the data instantaneously. This is never achievable in the first place, and as any system grows larger, delays and system latency increases.

A system that first date- and time-stamps in the field, then uses this original or native date/time stamp throughout the system has a big advantage– parts of the system can tolerate significant delays without any deterioration in data quality. A common field protocol for meeting these requirements is DNP3.

Data mining without compromising SCADA performance is an essential element for SCADA managers. Poole says, “SCADA systems aggregate data efficiently, but it is much more difficult to get this data back out without causing performance and system stability problems for the SCADA application itself,” says Poole. “This is why a historian is essential.”

Selecting the right historian

Poole’s systems integration company Parasyn Controls has invested significantly in evaluating what’s important when selecting the right historian for the job. He suggests that, at a minimum, the selection criteria should consider the following:

If time series is required (almost always for utility applications), is it native to the product?

Do the interfaces provide buffered data to support breaks in communications?

What is the server performance above 25,000 tags?

What are the tag naming rules and do they support the business enterprise requirements?

How is clustering supported?

Is redundancy, data replication, or both provided?

How is data retrieval affected by tag count and size of database (a big limiting factor for conventional relational databases)?

Ultimately, the historian acts as the gateway between SCADA and the enterprise’s decision support applications including modeling software, asset management, ERP, and others.

Historians. Historians capture the data and provide it to trend and reporting clients. This allows the HMI portion of the SCADA system to do what it does best, i.e. be a real-time visualization and alarm tool. Unfortunately, even though historians have improved significantly over the past few years, many of them still don’t support time-stamped data from the core. If they do support time series data, often it is via “engineered workarounds.”

The “larger” historians such as PI and eDNA do support time-stamped data out of the box, but come with a price tag to match. Starting with a less expensive historian, however, can be difficult because the system becomes unmanageable as the tag count increases.

Large tag counts are very problematic for relational databases, which simply can’t keep up as the tag count and relative data volumes both increase. The larger historians have a proprietary structure with a relational database “wrapper;” that is, they can be accessed by standard reporting tools as a relational database, but the core has been optimized for the fastest data acquisition.

HMI capability. ucture of the internal databases and the device drivers); and how security is managed as the system—and concurrent use of the system—grows.

Web clients are generally (but not always) refreshed differently to the SCADA server, and even though they are extremely popular, they have inherent problems. The most significant is that a web client isn’t necessarily a real time application, meaning it doesn’t update as the underlying data changes. The other disadvantage sometimes lies with the vendor’s technology for the web clients. Often there seems to be a disconnect between what you can do with “full HMI clients” and what is supported with web clients.

Developers must design the system for the types of HMI clients that will be used. Just because a TCP port is used to transfer the data to the web application doesn’t mean the web application is efficient or secure. Some of the security benefits of using SCADA technology is that the technology is proprietary in nature. The number of clients and loading effects on the SCADA servers is an important area for consideration—particularly for large tag count systems, and especially for busy networks with lots of traffic.

HMI applications that support terminal services offer an excellent interface that overcomes the issues with using differing technology for the same user experience. The additional benefit includes using standard security features and network administration concepts that are familiar to ICT managers. In essence, this allows the SCADA servers to be isolated from corporate systems and client access restricted and managed in a more conventional and familiar manner.

Bandwidth. Bandwidth often appears to be a bottleneck as the size of the system is increased (due to more data per site or more sites being brought online). However, increasing the communications bandwidth can often lead to other bottlenecks and isn’t necessarily the real solution.

David Greally, COO of Parasyn Controls, explains how one client overcame the bandwidth issue. “One large water authority was struggling with slow communications speed while bringing more sites online. Forced upon them by incremental implementation, their solution was first to turn off the collection of all analog values, then all digital status, and only leave alarm reporting. When we first started working with this client, they suggested increasing the data throughput by improved or faster radios. We introduced time-stamped data and, even though they still have their “slow” 1,200 baud radio network, they get all their analog and digital data as well as alarms. This is a massive system by all comparisons.”

That’s the other benefit of time-stamped data, Greally adds: “Bandwidth requirements can be a lot lower because only changed data is reported. There is no substitute for design, including how the data is to be efficiently managed.”

A common reaction from control engineers thinking about increasing the tag count (data points) in their SCADA system goes something like this: “Well, it sounds ok, but it’s going to cost another $5,000 for a larger SCADA license!”A smaller percentage might also factor in that they possibly need to upgrade a server– either replace their current one or add 1 or 2 gigabytes of memory. In fact, building a large tag count SCADA system involves a lot more than these two additions. But with the right understanding and planning, implementing a SCADA system with a large tag count doesn’t have to involve a lotof rework and unplanned costs.

Steve Carson is group marketing manager with MultiTrode , manufacturer of the MultiSmart pump station manager. These units are replacements for pump controllers or PLCs/RTUs for lift stations, adding additional monitoring and control capability to SCADA systems.

– Edited by Renee Robbins , senior editor Control Engineering News Desk Register here and scroll down to select your choice of eNewsletters free .