OPC Client Troubleshooting : Implementing Heartbeat Tags

Heartbeat Pitfalls

The IDX OPC client is commonly used when implementing heartbeat/watchdog/health-status tags. These tags are typically binary or counter tags that change state continously to indicate that a controller, typically a PLC, is still operating. Usually the PLC writes a changing variable to a tag in an OPC server which is monitored by one or more OPC clients.

However, difficulty is often encountered with symptoms of tags not updating correctly or at all after the initial connection. In almost all cases, this problem is centered on the misconfiguration of OPC client update rates with relation to the server and controller update interval and the use of binary heartbeat tags.

Binary heartbeat tags are more sensitive to sampling frequency because the tag only has two states. We recommend the use of a revolving integer counter as a heartbeat rather than a bit based tag, simply because the counter’s value is practically guaranteed to change, regardless of sample frequency. Binary tags can be used, but careful attention must be paid to the OPC sampling (read) frequencies. Consider the scenario below:

images\heartbeat1.jpg

 

If the binary heartbeat is generated by a PLC for instance and written to the OPC server every 4 seconds, the following would represent a plot of the resulting heartbeat vs time:

images\heartbeat.jpg

 

If the heartbeat is then sampled by the connected OPC client every 10 seconds, the following sampled heartbeat would result:

images\heatbeat10s.jpg

 

This is because the sample interval of 10s is simply not of sufficient resolution to detect the changes occurring between the 10s pulses, resulting in a overly slow, or sometimes even static OPC client heartbeat.

This problem can be addressed by adhering to the Nyquist Sampling Criterion, which states that in order to sample data reliably, the sample rate must be at least twice that of the frequency of the sampled signal. In the above scenario, if the OPC client samples every 2 seconds, the result is shown by:

images\heartbeat2s.jpg

 

which is the exact reconstruction of the original heartbeat signal. This problem could be avoided completely by using a heartbeat counter. In the above scenario, if using a counter rather than a bit would mean than the counter would simply increment every 4 seconds. This means, if the OPC client reads the heartbeat every 10 seconds, a change will still be detected between samples, even if they are not incremental.

Other considerations

·      The behaviour of the OPC server from which the heartbeat signal is being read must also be considered. In some situations, the OPC server, especially those closely coupled to PLC devices, only update the heartbeat according to the fastest OPC client request in an attempt to minimize PLC CPU overhead. This means that connecting another OPC client, such as the FactorySoft OPC client that is supplied by the IDX install, directly to the OPC server causes the IDX client to suddenly start operating correctly. This occurs because these clients typically have an update rate of 500-1000ms, meaning the source OPC is forced to update the heartbeat at that rate.

Resolutions

·      Ensure the heartbeat tags are being read from the OPC server at a rate at least twice that of the rate it is being generated at the server.

·      Assign binary heartbeat tags to a faster IDX OPC Client read group. Other tags may be updated slower than the heartbeat sample rate. This can be checked and amended in the OPC client DM properties page.

·      Use a counter heartbeat rather than a binary heartbeat in order eliminate sampling issues.