When people think about HMI or SCADA development, they usually picture the visible elements first: process graphics, alarm banners, navigation menus, trend screens, and operator displays within well-designed SCADA and HMI systems.
But the success of an HMI project is often decided long before the first graphic is ever drawn.
I have been working through this reality firsthand on a recent project using iFIX, building out tag group displays (TGDs), dynamos, IO lists, engineering units, and alarm references with multiple engineers involved.
What became clear quickly is that inconsistency in tag structure creates a ripple effect that touches everything: rework, miscommunication, commissioning delays, and long-term maintainability problems.
This blog is about what I have learned, and why tag planning is one of the highest-leverage activities in any SCADA project, regardless of the platform you are working on.
For clients, this translates into fewer commissioning surprises, more consistent operator screens, and a system that is easier to support after the project team leaves.
At a glance, a tag looks like a simple connection point: a pump running signal, a valve command, a temperature reading. But in a real-world project, each tag carries meaning well beyond its raw value.
A well-planned tag should help answer questions like:
When those answers are documented and agreed upon early, development moves with confidence. When they are assumed individually by each engineer, the result is a system that technically works but creates friction at every stage of the project.
One of the most common issues in SCADA development is inconsistent naming. The same signal type may be named differently depending on who created it, what drawing it came from, or what legacy system is being referenced.
This issue becomes especially clear when you look at naming conventions.
A simple pump running feedback might appear in the same project as:
Each one was probably created by someone who made a reasonable choice at the time. But collectively, they create friction. Developers spend time verifying what signals mean instead of building. Reusable objects become harder to build or maintain. Alarm messages become inconsistent. And when someone has to troubleshoot the system a year later, or when new equipment is added, that inconsistency compounds.
This problem becomes especially noticeable when multiple engineers work in parallel. Without a shared naming convention established before development starts, everyone makes locally reasonable decisions that add up to a globally inconsistent system.
Pro Tip: Define your tag naming conventions in a shared document before any development begins. Even a one-page standard covering prefix structure, signal type suffixes, and naming rules can prevent many hours of significant rework later.
Across many major SCADA and HMI platforms, one of the most powerful tools for efficient development is the reusable graphic object, an important part of modern industrial automation and controls system design. The names vary by platform, but the concept is universal: build a well-designed object once and use it across dozens or hundreds of similar pieces of equipment.
In iFIX, these are called dynamos and tag group displays (TGDs). In Ignition, they are UDTs (User Defined Types) paired with Perspective templates. In Rockwell FactoryTalk View, they are Add-On Graphics (AOGs) or faceplates. In AVEVA and Wonderware, they are ArchestrA objects and Galaxy templates. On the PLC side, Rockwell Studio 5000 uses Add-On Instructions (AOIs) and its own UDT structures, which have to align with whatever the SCADA layer expects.
Reusable Object Terminology Across Platforms
iFIX: Dynamos, Tag Group Displays (TGDs)
Ignition: UDTs (User Defined Types), Perspective Templates
FactoryTalk View: Add-On Graphics (AOGs), Faceplates
AVEVA / Wonderware: ArchestrA Objects, Galaxy Templates
Rockwell PLCs: Add-On Instructions (AOIs), UDTs in Studio 5000
Regardless of the platform, the underlying requirement is the same: reusable objects only work reliably when the tag structure feeding them is consistent and predictable.
In iFIX, tag group displays use substitution variables to swap tag references into a common graphic at runtime. If one motor uses RunFB and another uses Running and a third uses a packed status word with undocumented bits, the reusable object either becomes riddled with exceptions or gets abandoned in favor of one-off custom graphics that cost more to build and far more to maintain over time. Figure 1 shows an example TGD for a chilled water pump, where each Symbol in the left column maps to a specific SCADA tag through the Substitution column.
The same TGD can then be reused for similar equipment by updating the substitution values to point to the correct tag set.
[Figure 1: Example iFIX Tag Group Display (TGD) showing Symbol-to-Substitution mapping for MFG_CW_P_1. The TGD acts as the reusable interface between the SCADA graphic and the tag database.]
The same challenge can appear in Ignition when UDT definitions drift between equipment instances, or in FactoryTalk View when AOG tag parameters are not consistently mapped. The technology is different, but the dependency on a clean, predictable tag structure underneath is not.
Pro Tip: Before building any reusable graphic object, define the full tag interface it will expect. What commands does it receive? What feedback, alarm, and status tags does it need? Lock that in early and enforce it consistently across both the PLC and SCADA teams.
One of the most underappreciated aspects of tag planning is the coordination it requires between two teams who are often working in parallel and sometimes in different tool environments entirely: the PLC programmer and the SCADA developer, often working together as part of a broader controls integration effort.
The IO list is where that coordination starts. It is the single shared document that defines what signals exist, where they live in the PLC, what type of I/O they are, and what they represent in the process. If the IO list is treated as a living document that both teams work from, it becomes a powerful alignment tool. If it is treated as a one-time deliverable that gets filed away after I/O checkout, it becomes a source of drift. In that sense, the IO list is not only a design document; it is a communication tool between disciplines.
Here is where things typically go wrong: the PLC team names a signal one way because it makes sense inside the logic structure. The SCADA team names the corresponding HMI tag a slightly different way because it makes sense for display purposes. Neither is wrong individually. But without a documented agreement between the two, those variances accumulate. By the time commissioning starts, the team is spending real hours tracing which PLC address maps to which SCADA tag, and which version of the alarm message is actually the current one.
Figure 2 shows an example IO list excerpt with both PLC-side and SCADA-side columns tracked side by side. Notice the Notes column, which documents agreed naming variances between the PLC tag name and the SCADA tag name. Small differences like a PLC suffix of _Run_Fdbk versus a SCADA name of _Running are perfectly acceptable, as long as they are explicitly documented and both teams know about them.
[Figure 2: IO List excerpt with PLC and SCADA columns aligned side by side. Agreed naming variances are captured in the Notes column to prevent confusion during commissioning.]
When both teams work from the same IO list and document their variances in it, several things get easier:
The variances between PLC and SCADA naming are not always avoidable. PLC structures have their own logic, and SCADA tag naming has its own conventions. The goal is not to make them identical. The goal is to make the differences intentional, documented, and visible to everyone on the team.
Pro Tip: Add a SCADA Tag Name column and a Notes column directly to your IO list. Use it to capture any agreed naming differences between the PLC tag and the SCADA tag. This five-minute step during planning prevents hours of confusion during commissioning.
Tag planning is not only about naming. Engineering units, scaling, decimal precision, alarm limits, and tag descriptions are all part of the user experience, and they all need to be planned intentionally.
A temperature value without units is incomplete. A flow rate with too many decimal places distracts the operator. A pressure reading with the wrong scaling can cause real confusion during commissioning, especially if the issue does not surface until a process is actually running.
An alarm message that does not clearly identify the equipment adds response time during abnormal situations.
These details look minor during development. They become very visible the first time an operator asks what a number means and the answer is not immediately obvious from the screen.
If you are migrating from a legacy SCADA platform to a modern system, the temptation is strong to recreate existing screens as closely as possible and simply reconnect the tags. In many cases, that feels like the path of least resistance.
But legacy systems often carry years of accumulated decisions: tag names that no longer reflect the current process, alarm behavior that was never correct to begin with, outdated descriptions, and graphics built around workflows that have since changed. A migration is an opportunity to ask important questions that often get skipped when the focus is on speed:
Skipping these questions does not make the project faster. It carries the old problems forward into the new system, where they often surface during commissioning, startup, or future troubleshooting.
The best time to resolve tag structure questions is before development begins. Once graphics, alarms, trends, and reports are built, a simple naming change can cascade across dozens of screens, scripts, popup windows, alarm messages, and test documents.
Tag planning does not need to be perfect from day one, but it does need to be intentional. A solid starting point includes:
Projects evolve. Scope changes. Field conditions do not always match the design. But a shared tag standard gives the whole team a structure to work from and reduces the number of independent assumptions being made in parallel.
A well-designed HMI should help operators understand the process quickly, recognize abnormal conditions at a glance, and respond confidently. That does not happen through graphics alone.
Behind every effective HMI is a tag structure that supports it. When tag names, descriptions, engineering units, alarms, and statuses are planned intentionally and consistently from the start, the entire SCADA system becomes easier to build, easier to commission, and easier to maintain for years after go-live.
Tag planning is not the most visible part of a project. It rarely shows up in a schedule as its own line item, and it rarely gets recognized in a project retrospective. But when it is done well, everything else flows more smoothly. And when it is skipped, everything else carries the cost.
Before you build the HMI, build the foundation. A well-structured tag system is what makes everything else work.
At Hallam-ICS, successful HMI and SCADA development goes beyond screen design. It requires careful coordination between controls engineers, SCADA developers, project managers, and the people who will operate and maintain the system long after commissioning.
Whether you are starting a new SCADA build or migrating from a legacy platform, tag planning should be treated as an engineering activity, not an afterthought.
Contact us to learn how we approach SCADA projects from the ground up.
About the author
Horacio Resendiz is an Automation Engineer with a passion for optimizing systems and solving complex technical challenges. With experience spanning controls design, PLC/HMI programming, and industrial automation, Horacio brings a hands-on, detail-oriented approach to every project. Outside of work, he enjoys lifting weights at the gym, listening to electronic music, and tackling DIY handyman projects on the weekends.
Read My Hallam Story
About Hallam-ICS
Hallam-ICS is an engineering and automation company that designs MEP systems for facilities and plants, engineers control and automation solutions, and ensures safety and regulatory compliance through arc flash studies, commissioning, and validation. Our offices are located in Massachusetts, Connecticut, New York, Vermont and North Carolina, Texas and Florida and our projects take us world-wide.