There is always that moment on a retrofit project when someone opens a spreadsheet with several thousand rows in it. Then they realise nothing else can move forward until that file has been reworked line by line. That file is the signal list. Yet nobody ever mentions it at the project kick-off meeting.
The reason is simple. This step touches no production equipment, and it rarely appears on the schedule the client sees. It still governs everything that follows. Until the signals carry the names defined by the site, no engineer can write reliable code, nobody can configure the SCADA properly, and maintenance teams will lose their bearings on the day of commissioning.
- What is signal tagging in an industrial project?
- Why the step comes back on every project
- What manual recoding actually costs
- Automating the transformation: the principle
- A concrete example: 934 signals
- What automation does not solve
- How to approach this on your next project
- Optimising engineering, not just equipment
What is signal tagging in an industrial project?
Signal tagging means giving every piece of information exchanged between the process and the control system a unique identifier, built according to a naming convention specific to the site.
In practice, a temperature sensor, a conveyor motor, a control valve or a proximity switch all send and receive information. Each of those needs a name. More importantly, that name is not arbitrary: it tells you where the equipment sits, which area it belongs to, what type of signal it carries and what function it serves.
The tag therefore becomes the common language of the project. The engineer writing the logic, the electrician pulling the cable, the maintenance technician who will walk into that plant eight years from now: all of them use the same reference. That is why a sound convention lets anyone read a drawing without calling its author.
Why the step comes back on every project
On a greenfield installation, the question arises once, at the start. On a modernisation project, by contrast, it comes back every single time, whether the site calls it a control system retrofit or a plant revamp. The reason is straightforward: nobody built the existing lists for the system that is arriving.
Those lists come from everywhere. Part of the data is exported from the legacy PLC, abbreviations and all. Another part reproduces the equipment supplier’s documentation, which follows its own convention. A third part has lived for fifteen years in a spreadsheet that several people have edited in turn, with the inconsistencies you would expect.
On top of that, many sites apply a group-wide tagging standard. Some rely on KKS, widely used in cement plants and power generation, or on IEC 81346, which structures the designation of industrial installations. Others follow ISA-5.1 conventions for instrumentation. Many, finally, have built their own in-house grammar: perfectly logical to those who use it daily, completely opaque to everyone else.
The task, therefore, is to move several thousand rows from a mix of conventions into a single one.
What manual recoding actually costs
When teams handle this by hand, they always follow the same sequence:
- first, gather the existing signal lists and identify where each one came from;
- next, analyse the convention in force on site, often by reverse-engineering it from examples;
- then rework every row into the new standard;
- finally, check consistency across the whole file before integration.
On a mid-sized project, that means several days. On a large one, several weeks of engineering time.
Time is not the only issue, however. The nature of the work matters just as much. Anyone applying the same transformation thousands of times will produce inconsistencies: an abbreviation handled one way in the morning and another way after lunch, an area number missed across a whole batch, a duplicate that slips through.
Those inconsistencies do not surface immediately. They appear during commissioning, when a signal fails to land where the engineer expects it. Sometimes later still, in operation, when an operator searches the SCADA for a piece of equipment and cannot find it under the name they know. By then, fixing it costs ten times what it would have cost upstream.
Automating the transformation: the principle
The idea sounds simple, though the execution demands rigour. Since the transformation follows a rule, you can write that rule once and then apply it automatically across the entire file.
That is exactly how the tool we built at IBITEK works. You give it the project’s signal list and the site’s tagging standard. It then applies the transformation rules to every row. Finally, it flags the rows it cannot resolve with certainty and returns a structured file.
What the tool leaves to the engineer matters as much as what it handles. In other words, it does not make decisions on anyone’s behalf: it executes what is deterministic and escalates what is ambiguous. Someone who knows the project then validates the result.
That split is not a detail. It separates useful automation from dangerous automation. A tool claiming to handle 100% of cases without oversight would propagate its errors across the whole file, and those errors would be far harder to catch than an isolated human mistake.
A concrete example: 934 signals
On a customer project, our engineers processed a file of 934 signals with this tool.
The outcome:
- the tool retagged 95% of the signals automatically;
- it escalated 5% for manual review, mostly edge cases or source descriptions that were incomplete to begin with;
- processing dropped from one to two weeks of manual work to a few minutes.
The time saving is the obvious result. It is not, however, the most valuable one. What really changes is consistency: the same rule transformed all 934 rows, in the same way, from the top of the file to the bottom. No fatigue, no mid-afternoon drift.
Moreover, the engineering hours freed up do not vanish. They go back where they create value: process analysis, system architecture, commissioning preparation.
What automation does not solve
It is worth being direct here, because this is where the unpleasant surprises come from.
A vague standard stays vague. If the site never wrote its convention down, or if three versions coexist across different areas, no tool will make that call for you. The first step therefore remains a human one: formalise the convention, get it approved, then freeze it. That is often the longest part of the job, and also the part that pays off for the next twenty years.
Incomplete source data stays incomplete. For example, if the original description identifies neither the area nor the function of the equipment, the information has to come from somewhere else: the drawings, or the plant floor.
Edge cases remain edge cases. The 5% escalated for review are precisely the ones that call for judgement. That is normal, and healthy.
How to approach this on your next project
A few questions worth asking before the design phase starts:
- Does the site’s tagging standard exist in writing, or only in a few people’s heads?
- How many different sources feed the project’s signal list?
- Who signs off, on the client side, that the convention will suit operations and maintenance?
- Finally, how many engineering days does the cost estimate allow for this activity?
That last question is revealing. In many schedules, tagging appears nowhere at all. It disappears into a single “engineering” line that nobody breaks down, and it then generates delay without anyone understanding why.
Optimising engineering, not just equipment
Industrial performance is usually associated with production assets: a kiln that burns less fuel, a conveyor that fails less often, a line that runs faster.
A significant share of project lead time, however, is decided much earlier, in engineering tasks nobody watches. Signal tagging is one of them, alongside legacy documentation rework and the build-up of SCADA databases. In short, thankless tasks, invisible to the end client, yet heavy on the schedule.
Taking them seriously therefore shortens projects, produces reliable technical data and makes life easier for the teams who will run the plant for the next two decades.
At IBITEK, we design, integrate and commission automation and control systems for industrial production sites, on greenfield installations as well as retrofit and revamp projects, across six countries across EMEA. The tools we build for our own engineers all come from the same observation: time saved on repetitive work is time given back to the project.
Planning a modernisation project? Let’s talk about your tagging standard before it turns into a bottleneck.
