What Is a SCADA Tag?
The Named Data Point

Back to Blog

What a Tag Carries

A tag is more than a number. Beyond its live value, a tag typically holds a name (a unique identifier like WELL_04_CSG_PSI), a data type (analog float, discrete boolean, integer, string), engineering units and scaling, a source address that tells the system where to read the value, and configuration such as alarm limits, deadband, quality/status, and timestamp. Some tags are read from the field; others are writable, like a remote setpoint or a start command; some are calculated inside the SCADA itself.

This metadata is what lets one field value power many features at once. The same casing-pressure tag drives the number on the operator display, the red high-pressure alarm, the pressure trend, and the value stored in the historian - all from a single point of truth.

Tag Naming and Mapping to the Field

Because a large operation can have tens or hundreds of thousands of tags, a consistent naming convention is essential. Good tag names encode location and meaning in a predictable structure - site, equipment, measurement, and often instrument type - so an engineer can read a name like PAD12_SEP1_LVL and know exactly what it is. Many operators base their scheme on ISA-style identifiers. Sloppy, ad-hoc names are one of the most expensive mistakes in a SCADA build because they make every later task harder.

Each tag that reads from the field is mapped to a specific address in a controller: a Modbus register, a DNP3 point index, an OPC UA node, an EtherNet/IP or S7 address. The SCADA driver polls that address and updates the tag. In practice, commissioning a site is largely the work of building this tag-to-address map correctly. Merobix models field values as tags and reads them from controllers over Modbus, DNP3, OPC UA, and other supported protocols, so every point at a remote site becomes a named, alarmable, historized tag in the cloud.

Building a Naming Convention That Survives Growth

Write the convention down before the first tag is created, and treat it as a standard, not a suggestion. Decide the segment order - site, equipment, measurement, qualifier - and keep segment widths consistent so names sort cleanly: a fixed-width site code means PAD02 lines up with PAD12 in every list and filter. Pick one delimiter and ban the rest. Avoid spaces and special characters entirely, because some driver, export, or scripting layer downstream will eventually mishandle them, and the failure will surface far from the tag that caused it.

Plan for the awkward realities: equipment that gets renamed in the field, temporary instruments, spare I/O, and calculated values that have no physical address. Give each a defined pattern instead of letting them accumulate ad hoc. Renaming a live tag later breaks trend history, alarm records, and display bindings all at once, so the cheapest time to get a name right is before the tag exists - the walk-through in adding a tag to SCADA shows why naming is the first step of the workflow rather than an afterthought.

The Metadata That Pays Off Later

A tag with a value but empty metadata is a debt that comes due at the worst time - during an alarm flood or a middle-of-the-night callout. A few fields do most of the work:

Attribute	Why it matters
Scaling	Turns raw counts into engineering units; a wrong span silently corrupts every trend and alarm built on the tag
Units	Distinguishes kPa from psi on displays and reports without relying on tribal knowledge
Description	The plain-language line a new operator or integrator reads first
Alarm limits and deadband	Set deliberately per tag, not copied from a template, or the alarm system trains people to ignore it
Write permission	Marks the few tags that command equipment so they can be secured and audited separately

Quality and timestamp deserve particular respect. A tag carrying a last-known value with a bad-quality flag is telling you the number on the screen is stale; displays and logic that ignore quality will happily act on a value from a dead controller and nobody will notice until the discrepancy has consequences.

Keeping the Tag Database Honest

Tag databases only grow. Sites get added, projects bolt on points, and nobody deletes anything, so schedule an audit: export the database, sort by last change and quality, and look for tags that have been flatlined or bad-quality for months, duplicates pointing at the same register, and alarm limits still sitting at commissioning defaults. Each finding is either a dead point to retire or a broken one to fix, and both are cheaper to handle in a scheduled review than during an incident.

Put tag changes under light change control - who added the tag, why, and against which drawing or register map. Bulk edits through export and import are far safer than hand-editing hundreds of entries, and the export doubles as documentation. The tag database, not the screens, is the real record of what the system knows about the field; the historian can only faithfully store what the tags faithfully describe.

Frequently Asked Questions