Large tag count SCADA systems need proper planning

A lot of SCADA systems involving telemetry, especially in the water/wastewater industry, have a minimal amount of data coming from each site. A wastewater collection system with 100 sites, for example, might have only 1,000 to 2,000 tags. (These data points can be either an analog value like "level" or a digital value like "pump running.

By Steve Carson, MultiTrode April 1, 2009

A lot of SCADA systems involving telemetry, especially in the water/wastewater industry, have a minimal amount of data coming from each site. A wastewater collection system with 100 sites, for example, might have only 1,000 to 2,000 tags. (These data points can be either an analog value like “level” or a digital value like “pump running.”) As progressive system integrators have implemented more integrated control systems, 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. And the right place to start, he says, is with the business outputs.

SCADA system requirements should include detailed specifications for the following:

  • Access times—for alarm annunciation and alarm acknowledgement;

  • Data resolution—e.g., for each data point, the kind of deadband or time resolution needed for later reporting or analysis;

  • Visualization tools—e.g., the number of data points on the graphical interface vs. the update time needed;

  • Reporting requirements—the kind of reports needed and how often they are to be run.

“Once we have this established, we can start to design the system and test each element to ensure that it functions correctly under real-life conditions,” says Poole. “The elements are communications, the drivers, the SCADA (or HMI), and the historian. The methodology of how 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 operates in 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,” he says. “This is why a historian is essential.”


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 more well-known 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

Important considerations for a well-designed HMI include: number of data points on each screen; response time required for the screen to load; response time for the screen to update; how the HMI acquires data when screens require updating (i.e., caching concepts and how this is affected by the structure 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 it 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 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. 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 with faster radios. We introduced time-stamped data and, even though they still have their 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 lot of rework and unplanned costs.

Author Information
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.

System design planning

Use the following tips when creating 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!