Monitoring Distributed Control Systems with PRTG

 Originally published on September 29, 2022 by Shaun Behrens
Last updated on January 23, 2024 • 7 minute read

In recent times, I’ve written a lot about how Paessler PRTG monitoring software is well-suited to monitoring OT (Operational Technology) components in industrial environments. We’ve covered using PRTG to monitor everything from OPC UA servers to SCADA systems. And in this article, I’ll take a look at another common element of OT: the DCS, or Distributed Control System. I’ll go into how PRTG can be used to monitor a DCS. But first, let’s get a definition of DCS.

What is DCS?

Here’s the definition from Wikipedia:

“A distributed control system (DCS) is a computerised control system for a process or plant usually with many control loops, in which autonomous controllers are distributed throughout the system, but there is no central operator supervisory control.”

While the role of a DCS is similar to PLCs, a DCS is commonly found as a solution for continuous manufacturing, and it also offers embedded visualization capabilities similar to those of a SCADA systems.

Monitoring a DCS with Paessler PRTG

To understand how PRTG can be used for monitoring a DCS, it first helps to understand the typical architecture – and for that, we come back to our trusted industrial automation pyramid:

Industrial-Pyramid_Dark

Typical DCS setups include operator stations, servers (for example to collect and store processor-level and operational data), and controllers. These operate in the operational level of the pyramid, and specifically in the control and process control levels.

PRTG can be used in these same levels.

PRTG as monitoring middleware

The OPC UA and API connectivity lets PRTG operate as a kind of middleware, since it can monitor the various components of a DCS, as well as provide the DCS itself with information.

DistributedControlSystems_Infographic

The underlying components of the environment that the DCS runs in includes the firewalls, switches, backup structure, PLCs, and more. PRTG gets information from these components using OPC UA, SNMP, REST APIs, and other methods of data collection. This data then forms the basis of monitoring with PRTG – it watches for values that exceed defined thresholds and other signs of issues. The data can also be displayed in dashboards showing the health and status of the various components.

When PRTG detects issues, it can also send notifications to the DCS. It can do this in several ways. If the DCS servers run OPC UA – and these days, many of them do – then PRTG can send the notification of an issue to the DCS by sending an OPC UA tag. Here’s more detailed information about sending notifications to OPC UA servers from PRTG.

Alternatively, the DCS can access the data in PRTG using the PRTG API, or PRTG can generate an email message for the DCS.

PRTG as an offline option

Here’s a point that I feel needs to be mentioned here, especially considering that companies might select a DCS due to its more robust security: the fact that PRTG can be used “offline” – in other words, it doesn’t need to be connected to the outside world – makes it an attractive choice for monitoring isolated infrastructure.

PRTG in a wastewater treatment facility

Earlier I mentioned the usefulness of monitoring the underlying aspects of a DCS, and we have many great examples of how this is possible with PRTG. For this article, I’ll select a specific example that demonstrates how PRTG is used to monitor control systems.

se3_1SE3 (Sistemas Eléctricos y Electrónicos Especializados) is a Mexican consulting company that provides industrial maintenance and automation services. They use PRTG to provide remote monitoring for wastewater treatment plants. For one of their projects in Yucatán, they were able to monitor crucial data such as tank levels, energy consumption, and the states of water pumps and other actuators.

How they got this data is interesting: data from the control system is collected by INSYS gateways, which then convert the industrial protocols to other common protocols. In this case, MQTT was used as the transmission protocol, and PRTG could use its MQTT functionality to bring in the data.

Take a look at the case study – it makes for interesting reading.