In industrial communication systems, data validity is just as critical as the data itself. A subtle inconsistency in how validity is handled can lead to misleading system states, incorrect operator decisions, or downstream processing errors.

During a recent project involving SCADA protocol conversion within an industrial router, I encountered a practical example of this problem—one that highlights both the complexity of IEC 60870-5-101 and the importance of proper testing tools.

The Problem: Stale Validity State

The router in question implements a protocol conversion feature, where an IEC 60870-5-101 client collects data from a remote server and maps it internally for further processing or exposure via other protocols.

At system startup, the behavior was correct:

• The IEC 101 client performed a General Interrogation (GI)
• The server responded with all configured data points
• Each received point had its IV (Invalid) quality bit cleared, indicating valid data

However, an issue appeared during runtime.

If a point was removed on the IEC 101 server side after the initial interrogation:

• The server no longer included this point in subsequent GI responses
• The router, however, continued to treat the point as valid
• The IV bit was never updated, leaving stale data marked as “good”

In essence, the system had no mechanism to invalidate points that silently disappeared.

Why This Matters

In IEC 101/104 systems, absence of data is not neutral—it is meaningful.

If a point is no longer reported:

• It may indicate configuration changes
• It may signal communication or device issues
• It must not be treated as still valid

Failing to update the validity state can result in:

• Incorrect SCADA visualization
• False assumptions about field device state
• Risky automation decisions based on outdated inputs

Reproducing the Issue with VestaTel SCADA Simulator

To properly investigate and fix the issue, reproducibility was essential. This is where the VestaTel SCADA Multi-Protocol Simulator proved extremely effective.

The test setup was straightforward:

1. Configure the simulator in IEC 101 server mode
2. Allow the router to connect and complete initial General Interrogation
3. Verify that the test point is received and marked valid
4. Disable the selected point in the simulator (via checkbox)
5. Wait for the next periodic General Interrogation

One of the key advantages of the simulator is how quickly such scenarios can be reproduced—without custom scripting or complex lab setups. The ability to dynamically enable or disable individual data points makes it particularly useful for testing edge cases like this one.

Observations and Verification

After the second interrogation cycle:

• The disabled point was not included in the server response
• A Wireshark capture confirmed its absence on the wire
• However, the router still showed the point as valid/online

This clearly demonstrated the flaw:

The client logic only updated validity on received points, but did not handle missing points.

Root Cause and Fix Approach

The issue stemmed from an incomplete state management strategy:

• Validity was updated only on reception
• There was no reconciliation step between consecutive interrogations

A robust approach requires:

• Tracking previously known points
• Comparing them against the latest GI response
• Explicitly marking missing points as invalid (IV = 1)

This ensures the internal data model reflects the true state of the upstream device.

Takeaway

What is not reported can be just as important as what is.

This case highlights how subtle protocol handling issues can lead to significant system inconsistencies—and how having the right testing tools makes all the difference. If you are working with IEC 101/104 or building protocol conversion solutions, tools like the VestaTel SCADA Multi-Protocol Simulator can dramatically reduce debugging time and improve reliability.