How to Design a SCADA Tag Naming Convention

Back to Blog

List the Fields a Name Must Encode

Start by deciding what information a reader should be able to pull out of a tag name without opening anything else. On most systems that is four to five things: the site or area, the asset or equipment it belongs to, the measurement type, and a sequence number to break ties. A name like WELL03_SEP_PT_01 tells you the well pad, the separator, that it is a pressure transmitter, and that it is the first one, all before you have looked at a single property. If you cannot articulate what each character earns, the field does not belong in the name.

Anchor the measurement-type field to an existing standard rather than inventing abbreviations. ISA-5.1 instrument identification letters (P for pressure, T for temperature, L for level, F for flow, followed by the function letter) give you a vocabulary the whole industry already reads, and reusing it means a P&ID and a tag database speak the same language. Where you need types the standard does not cover, extend it deliberately and record every abbreviation in the standard so RUN never competes with RUNTIME or RNTM for the same meaning. This field is closely related to the underlying concept of a SCADA tag as the addressable unit the whole system indexes on.

Resist the urge to encode volatile facts. A PLC rack slot, a vendor name, or the year commissioned all feel useful and all change, and every change either forces a rename cascade or leaves the name lying. The rule of thumb is that a field belongs in the name only if it is stable for the life of the point. Everything else - engineering units, description, alarm limits, area path - lives in tag properties or a separate hierarchy, not in the identifier.

Order Fields From Most Stable to Most Specific

Order matters because names sort alphabetically, and a good order makes the sort do useful work. Put the most stable, broadest field first (site or area), then the asset, then the measurement type, then the sequence. That ordering groups every point on a given asset together in any alphabetical list, so a browse of the tag database reads like a walk down the P&ID rather than a scramble. The opposite order, leading with the measurement type, scatters an asset's points across the whole namespace and makes templated screens far harder to build.

Decide the delimiter and case once and enforce them everywhere. Underscores or periods both work; mixing them does not. Some historians treat the period as a hierarchy separator, so if yours does, reserve it for that and use underscores within a level. Pick a single case style - all upper is common in SCADA because many legacy systems fold case anyway - and never rely on case alone to distinguish two tags, because a case-insensitive downstream tool will collide them silently.

Set a hard maximum length and test it against every consumer before you commit. The HMI, the historian, the alarm printer, the report engine, and any export to a spreadsheet or ODBC client each have a field width, and the shortest one governs. A convention that produces a beautiful 48-character name is worthless if the historian truncates it to 32 and starts merging distinct points. Where your platform supports a formal hierarchy, lean on a structured tag namespace to carry the path so the leaf name itself can stay short.

A worked example makes the ordering concrete. Reading WELL03_SEP_PT_01 left to right, each field is more specific than the last:

Field	Example	Meaning	Stability
Site/area	WELL03	Which pad	Most stable, sorts first
Asset	SEP	The separator	Stable
Measurement	PT	Pressure transmitter (ISA-5.1)	Fixed by type
Sequence	01	First of its kind on the asset	Most specific, sorts last

Write the Standard and Reserve Room to Grow

A convention that lives only in the lead engineer's head is not a convention. Write it as a short document: the field list, the order, the delimiter, the case, the length budget, the abbreviation dictionary, and at least a dozen worked examples covering the awkward cases (redundant instruments, calculated points, spare channels). The examples are what people actually copy, so make them cover the edge cases you know will come up rather than only the easy ones.

Reserve number ranges instead of packing sequences tight. If separators on a pad get 01 through 09 and you have three today, you have not left room for the fourth; give each equipment class a block (transmitters 01-19, valves 20-39) so additions slot in without renumbering. The same discipline applies to sites: a two-digit site field caps you at 99 sites, which a growing operation will hit, so size the field for the plant you expect to have, not the one you have now.

Plan for the tags the naming scheme does not yet know about. Calculated points, totalizers, and diagnostic bits all need a place in the pattern, and if the standard is silent someone will improvise. Decide up front how a computed value is marked (a CALC segment, a distinct prefix) so it never gets mistaken for a raw field point, a distinction that matters the moment you start building calculated tags on top of the raw namespace.

Verifying the Convention Holds Up

Prove the convention before you scale it by naming one complete asset end to end - say a full separator skid with its transmitters, valves, and calculated flows - and having a second engineer read the names cold. If they can reconstruct the P&ID from the tag list alone, the scheme communicates; if they have to ask what SEP2_X means, the field is ambiguous and needs fixing while the cost of change is still one skid, not the whole plant.

Run a mechanical check for the failure modes that silently break sorting and templating: names that exceed the length budget, mixed delimiters, case-only differences, and sequence numbers with inconsistent zero-padding (1 versus 01 sorts wrong). A quick script or spreadsheet filter over the proposed tag list catches all four before they reach the historian. When you later bulk-load points, the same check belongs in your CSV tag import so a typo does not create a near-duplicate that hides in the namespace forever.

Common Mistakes to Avoid

The most expensive mistake is changing the convention midstream. A plant with two naming schemes is worse than a plant with one bad scheme, because every query, every template, and every trained operator now has to know which era a tag came from. If the original scheme is genuinely broken, migrate all of it deliberately rather than letting new work drift to a new pattern while old work stays on the old one.

The second common mistake is encoding meaning in a way only humans can parse, like free-text descriptions crammed into the identifier. Names are for machines to sort and template on; descriptions are for humans to read. Keep the rich, changeable, human-facing text in the description property where it belongs, and keep the identifier terse, stable, and mechanical. The third is forgetting spares: leave named, reserved placeholders for channels you know you will fill, so the eventual addition follows the pattern instead of breaking it.

Frequently Asked Questions