Tag Naming and Engineering Templates for Large-Scale SCADA Projects

What chaotic tag names cost after commissioning

• Duplicate and colliding names: two stations both carry Pump1_Run, reports mix the two, and nobody can tell which site an event came from
• Screens and tags drift apart: a display label is rewritten on the HMI while the underlying tag stays as an electrician's shorthand, so troubleshooting needs two vocabularies
• Alarm text cannot be generated from the tag: each message is typed by hand, so a rename on the process side never reaches the alarm list
• Expansion copies the chaos: the next area is cloned from the first, including the bad names, and cleanup cost grows with every line added
• Handover becomes tribal knowledge: only the original engineer knows that T12 is the discharge temperature of pump A, and that person is no longer on site

These five costs appear after commissioning, not during it. That is why they are easy to postpone and expensive to reverse. A naming rule is cheap in week one; renaming tens of thousands of tags after the HMI is live is not.

Fields a naming rule has to cover: area, equipment, signal, type

A naming rule is not a style preference. It is a contract from which every tag, every alarm text and every screen object can be derived. If a field is missing, later scripts cannot filter by area, cannot generate alarm text, and cannot tell a process value from a command.

The four fields below are the minimum that has to be decided before the first tag is created. Delimiter, length and character set belong in the same rule, because mixed PLC brands and later database exports will punish informal spelling. We have collected close to 80,000 variables from 366 devices on one network in a single project. That figure describes a specific job. It is not a typical project size, and it is not an advertised ceiling for every contract. What it shows is that the rule has to hold when the tag count is large, not only when a pilot line has a few hundred points.

• Area (site, line or building): who owns the asset geographically — plant, workshop, line or pump-station code. Without it, two identical machines in different halls collide
• Equipment (unit, skid or machine): the asset itself — a compressor, a conveyor, a pump set — so all signals of one machine sort together
• Signal (measurement or function): what is being read or written — run feedback, discharge pressure, fault, setpoint
• Type (class): analog in, analog out, digital in, digital out, calculated, alarm, setpoint — so historians, screens and alarm engines can treat the point correctly
• Delimiter, length and character set: one separator (underscore is common practice), a length the shortest PLC and the historian can both accept, and no spaces or locale punctuation that break exports

Engineering templates that have to exist before the first screen

Screens are the visible part of a SCADA project, so they get discussed first. On a large job that order is reversed: I/O allocation, the tag list and the HMI specification have to exist before anyone draws. Without those three, every later screen invents names as it goes, and the live system has no master to be checked against.

We have carried out alarm engineering on a project of nearly 30,000 alarm points, on top of the collection scale above. Those numbers are evidence from specific jobs, not a size we expect of every site. They are also not a product claim about how many tags a platform will take on every job. The tag-count upper limit on a given network segment follows from bandwidth, poll interval and server headroom, and it is written into the templates below rather than discovered during commissioning.

• I/O allocation table: cabinet, slot, channel, signal type, engineering range and destination tag name, frozen before PLC addressing starts
• Tag list (point table): the master — tag name, description, area, equipment, address, data type, scan class, engineering unit, alarm flag. One row per point, one owner for the file
• HMI / screen specification: which screens exist, which tags they bind, navigation and alarm presentation — written before graphic work, not after
• Address and network map: which controller owns which range, how many devices share a segment, and the tag-count upper limit that segment can carry at the agreed poll interval

Bad naming, the problem it causes, and a recommended structure

The table below is a working checklist, not a universal standard. The pattern in the third column is AREA_EQ_SIGNAL_TYPE. Fill the four fields from your plant, then freeze spelling, delimiter and length so every later import uses the same contract.

The recommended structure is a starting template. Character set, length and the exact codes for area and equipment have to be agreed with the site team against the PLC brands and the historian actually in use.

Govern alarm points and process points as two lists

A process point answers what the value is. An alarm point answers whether someone has to act. Mixing them in one tag looks economical at a few hundred points and becomes unmanageable at a few thousand. The alarm list then inherits every naming shortcut in the process list, and later rationalization has nothing clean to work on.

Priority levels, suppression and reset archiving are a separate design. We have set those out in the column on SCADA alarm rationalization; this section does not repeat that tutorial. What belongs here is the split that makes that later work possible: two populations, two owners, one naming contract that can generate alarm text from area, equipment and signal.

• Separate populations: every process tag that needs an alarm gets a paired alarm tag, or an alarm record linked by name — not a dual-purpose point
• Alarm text is generated from the naming fields: area, equipment and signal produce a readable message, so a rename updates both the tag and the text
• Different owners: process tags are owned with the I/O and the historian; alarm tags are owned by operations, with a priority and a closeout rule, and the two lists are reviewed on different cadences
• Do not copy alarm class into every process name: class belongs in the alarm record. Putting HH, H, L, LL into thousands of process tags makes a later re-prioritization into a mass rename

On a project of nearly 30,000 alarm points, the engineering that held together was this split, not a larger graphic. Most plants will never reach that count. The split is still worth doing at a few hundred alarms, because that is when it is still cheap.