Back to FAQ's
How are communication failures fixed?
There are literally thousands of types of SCADA system configurations using hundreds of different type of communication. It is virtually impossible to give a detailed explanation of how to tackle all communication failures but the following steps can be used as a general guideline:
The first step towards fixing communication failures is to determine where in the SCADA system the problem is located. This is usually made very apparent by “stale”, or un-updated data residing in either the SCADA Host or a data-collecting PLC. Back-tracking through the SCADA system layout should lead you to the failed communication link.
The second step is to determine the nature of the failure. Most, but not all, communication failures reside at either the master or slave end of a communication leg. Using the techniques described in FAQ #13 and simple logic it can be determined at which end the problem resides.
For example, if in a radio communication network where a host is communicating with twenty PLCs, all but one PLC responds to messages from the host, it can be assumed that the problem resides with the slave PLC or its radio. It is unlikely that the host itself or its radio is defective since the other nineteen slaves are communicating. As another example, if in the same system as described in the previous paragraph, all twenty slaves fail to respond, then it is safe to assume that the problem lies with the host and its radio.
The third step is to determine if the communication medium (radio, modem, direct-wired connection, Ethernet) itself is defective. This can be accomplished by swapping-out the communication medium at the suspected site of the problem. Note: Many SCADA systems involve the utilization of extensive communication infrastructures including large ETHERNET LANs and WANs. It will become increasingly difficult to diagnose failures in these types of systems through “swapping-out” of equipment.
