Tag names are overrated. Signal behavior tells you more than the PLC documentation sometimes.

In my experience as an industrial scientist, one thing that has always amazed me is how often tag names are essentially useless. We’ve all seen a few different forms of tags like DB10.DBW24, MW1240, R40001, and AI_12. And unless you have the necessary documentation to assist you in interpreting those tags, you won’t have any idea what they are; unfortunately, documentation is often out of date, incomplete, missing entirely, or locked in the head of the engineer who left the company five years ago!

When I am trying to learn more about an unknown piece of equipment, I have found that by pay attention to the way a signal acts, rather than what the signal is called (the name), can often provide you with useful information. For example, if a boolean is TRUE 95% of the time but will fall to FALSE for several minutes at a time, it could be an indication of some type of machine’s status. If a float instantly drops to zero while equipment is stopped, the float may represent speed, throughput, or rate of production. If an integer increases monotonically but will reset to zero from time to time, it may represent a counter for production. If a boolean has large spikes just prior to any period(s) of downtime, that boolean signal may represent some sort of fault, jam, or interlock.

When implementing correlations and patterns of behaviours as opposed to a signal names the identification of these signals becomes surprisingly easy at times. This does not replace process knowledge, PLC programs or adequate paper records; however it can sometimes feel like the only course of action when dealing with older installations where documentation is not available or is unreliable.

I currently have a project to utilize correlations and behaviours of signals to automatically determine the role of each tag prior to performing any manual mapping. The intention of this experimentation is not to eliminate engineering positions, rather it is to be able to significantly reduce the amount of time spent reviewing thousands of undocumented signals looking for only a few that matter.

I am interested in feedback from those doing this type of work in the field. When you are placed in an environment where you end up having to work on a legacy system with sub-par documentation how do you identify the valuable signals? Do you tend to utilize PLC programming, OEM documentation, process engineers, historical trend data analysis, trial and error, or another method that has proven effective?