A SCADA component chart with a troubleshooting logo on it

SCADA Basics: Troubleshooting

If you’ve been following along with your SCADA Basics series, you’ve learned the components of a SCADA system, as well as how to choose your telemetry communication method. We understand, though, that not everyone is looking to get a new system. Many of you already have SCADA systems, and your challenge is keeping them online. This installment is for you.

 

Unfortunately, as with any system, uptime for a SCADA system is rarely 100%. When a problem arises, we usually guide our customers to check the easy stuff first. Oftentimes a problem can be solved quickly easily by your on-site personnel. Sometimes the problem with a SCADA system can be identified just by knowing where to look. The ability to do some basic troubleshooting on your SCADA system is very valuable, so the following is a very basic process for tracking down issues in SCADA systems. Even if you can’t fix the issue yourself, being able to give guidance to outside or remote support personnel can speed up the resolution process substantially.

 

1. Check the HMI

The human-machine interface (HMI) can be anything from the display on the front of a control panel to the computer to which the data is fed. Many times a simple setting change can be the issue of a SCADA system not collecting data or not reading properly. Verify that the settings are set as they should be. Don’t overlook the mundane, but critical, aspects of the HMI: caps lock, number lock, power feeding to the system, etc. Have operators review to confirm that the HMI settings all look the way they usually do.

 

2. Confirm Communication

The backbone and reason SCADA systems work in the first place is the communication process. Locate where the Ethernet (or other communication) ports are and verify that they are talking through the wire (this can often be confirmed by a blinking indicator light on the connector itself). If that light is off, no signal is getting through the wire. If you have the ability, check the signal of your telemetry communication. Is the radio getting interfered with? Is the cellular network down?

Additionally, take the time to open the control panel to verify that a signal is being sent to the proper places. Are there lights on the controller? Is the programming up-to-date? Do all of the wires appear to be connected well (no frayed strands, not too many wires on the same contact, etc.)? Are the components on the panel connected to something in the first place? Another step is to verify the correct connections with the “as-built” drawings that accompany the control panel.

 

3. Field Verification

If everything else appears to be in working order, the next step is to make the trip to the data point. Once there, you’ll want to check a few things. First, if you’re using a terrestrial radio system, visually check your antennas for lightning strikes. If you don’t see any issues, check your RTU unit to ensure that it has power and appears to be running as expected. If you’re using cellular, confirm that the network is online. Don’t see issues there? The next step is to check your instrumentation.

The easiest (though not always the most practical) way to verify correct readings from instrumentation is to manipulate the expected value to a known quantity (usually zero) and check the SCADA readings. For example, if a flowmeter is sending the signal of flow from a pump through a controller and into a SCADA system, the easiest way to verify that the readings are correct is to turn off the pump and confirm that the SCADA system also reads zero flow. If it doesn’t, or if it reads zero when the pump is still running, you’ve probably got a bad flowmeter. This step can be very labor-intensive depending on the process, so it is best to save this one until the other possible issues have been ruled out.

 

The particular application and process of a given SCADA system will determine the effectiveness, order, and workability of these steps. This list is not all-inclusive, by any means. However, it does provide a good starting point for people who may not be as intimately familiar with the SCADA system as the original system integrator. As we said at the beginning, you may not resolve the issue, but any info you collect about the problem before tech gets onsite will help speed up your time to going back online, and that’s the goal, isn’t it?

 

Have SCADA issues that you can’t resolve? Call us and let us get you back online!