Tag Catalog & Naming Convention Starter

Tag Catalog & Naming Convention Starter

Purpose: Create a single, authoritative tag catalog so sensors, PLC signals, historian points, and calculated KPIs are consistently named, owned, and governed—so analytics, MES, and dashboards are reliable and discoverable.

Why this matters

When tags are inconsistent, dashboards break, models fail silently, and onboarding new engineers takes longer. A clear catalog reduces duplicate signals, protects institutional knowledge, speeds integrations, and restores operator and analyst trust.

Quick principles

• Be predictable: Names should follow a small set of reusable patterns so humans and machines can parse them.
• Be precise: Include units, timestamp semantics, and data type metadata rather than encoding those details in informal notes.
• Be owned: Every tag must have an owner, a steward and a lifecycle state.
• Prefer discoverability: Document synonyms, mappings, and derived calculations so consumers can find canonical signals.
• Keep it practical: Balance purity with operational reality—start with a lightweight catalog and evolve it as you onboard sites.

Recommended Tag Structure (fields every catalog entry should include)

• TagID / CanonicalName (primary key) — the canonical, machine-friendly name used across analytics and MES.
• DisplayName — human-friendly label for dashboards and operators.
• Description — short plain-English explanation of what the tag measures and how it is produced.
• SourceSystem — PLC, historian, MES, cloud connector, or derived/calculated.
• PhysicalLocation — plant, line, cell, machine, or area identifier.
• Unit — explicit unit of measure (e.g., °C, rpm, liters/min, boolean).
• DataType — integer, float, boolean, string, timestamp.
• TimestampSemantics — eventTime, sampleTime, aggregateWindow, etc.
• Owner — role or person responsible for the signal (engineering owner).
• Steward — data steward or analyst who validates use in reporting and models.
• LifecycleState — proposed, active, deprecated, replaced, archived.
• Version — version number and change log link.
• Mapping — mapping to vendor tag names, PLC addresses, or historian point IDs.
• SecurityClassification — public, internal, restricted, or regulatory.
• SampleRate / Granularity — seconds, minutes, event-driven.
• DerivedFrom — if calculated, list source tags and formula.
• QualityFlags — null handling, bad-data indicators, thresholds for alarms.
• LastValidated — date of last validation and validator.

Naming convention pattern

Use a structured, tokenized name that consumers can parse. A recommended pattern:

Plant.Line.Machine.Location.TagType.MeasurementModifier

Examples (literal string examples):

• PLANT1.LINEA.MACHAIR01.INLET.PRESSURE
• PLANT2.PACK.LINE3.CHECKER.TEMP
• PLANT1.LINEB.PUMP05.OUTLET.FLOW
• PLANT1.LINEA.MACHAIR01.INLET.PRESSURE.AVG30s

Guidelines for tokens:

• Keep tokens short but meaningful; use consistent abbreviations and publish the abbreviation list in the catalog.
• Use upper-case and a single separator (dot, period) to ease parsing by scripts.
• Reserve suffixes for modifiers like AVG, MAX, MIN, DERIVED, or window lengths (e.g., AVG5m).
• Do not embed units in the canonical name—units belong in the Unit field.

Units, timestamps and data types

Record explicit units and make conversions visible. If a tag's unit can vary across sources, create a canonical tag with a single unit and maintain mapped raw-source tags with conversion metadata. For timestamp semantics, choose consistent terms (eventTime vs sampleTime) and document them in each entry.

Versioning and lifecycle policy

Simple policy to start:

• Versioning: Increment major.minor (1.0, 1.1). Major changes (unit change, semantic change) require a new tag name and deprecation of the old tag. Minor changes (description edits, metadata) increment minor version.
• Deprecation: Mark tags as deprecated with a replacement tag and an expiration date. Do not delete historical data; mark the catalog entry as archived only after a retention period is met.
• Change log: Keep a short change note and approver for each version.

Ownership model & governance roles

Assign distinct responsibilities:

• Owner (Engineering): accountable for tag correctness and physical mapping.
• Steward (Data/Analytics): accountable for catalog metadata, analytics readiness, and documentation.
• Approver (Ops Lead): approves new or changed canonical tags that impact production dashboards or MES.

Validation checklist for new or changed tags

Require this checklist before a tag becomes canonical:

1. Name follows the canonical pattern and abbreviation list.
2. Description clearly explains what the tag measures and any units or ranges.
3. Unit and DataType fields populated and consistent with source.
4. TimestampSemantics defined and appropriate for consumers.
5. Owner and Steward assigned and contactable.
6. Mapping to raw source (PLC/historian point) documented.
7. Derived formulas include source tags and math, and are peer-reviewed.
8. QualityFlags and expected ranges defined; out-of-range behavior specified.
9. SecurityClassification and access rules set.
10. Tested in a staging environment; sample data validated for correctness and unit consistency.
11. Version and change-log entry recorded; approver signed off.

Sample tag entries (examples of filled catalog rows)

• CanonicalName: PLANT1.LINEA.PUMP05.OUTLET.FLOW — DisplayName: Pump 05 Outlet Flow — Unit: L/min — DataType: float — SourceSystem: HISTORIAN_A — Owner: Mechanical Eng — Steward: Process Analytics — LifecycleState: active
• CanonicalName: PLANT2.PACK.CHECKER.TEMP — DisplayName: Case Checker Temperature — Unit: °C — DataType: float — DerivedFrom: RAW_SENSOR_123 * 0.1 — LifecycleState: active
• CanonicalName: PLANT1.LINEB.MACHAIR01.INLET.PRESSURE.AVG30s — DisplayName: Machine Air Inlet Pressure (30s avg) — Unit: bar — DataType: float — LifecycleState: active

Common pitfalls to avoid

• Embedding units in the canonical name (harder to change later).
• Allowing local one-off names that become de facto standards without cataloging.
• Mixing raw and canonical tags without explicit mapping and conversion formulas.
• Not assigning ownership — undocumented tags proliferate and become orphaned.

Practical rollout steps (first 90 days)

1. Agree on the naming pattern and abbreviation list with engineering, ops, and analytics representatives.
2. Seed the catalog with 50–100 highest-value tags (OEE components, critical sensors, top KPIs).
3. Publish the validation checklist and require it before a tag gains canonical status.
4. Set up a lightweight change approval process (email or ticket) and record approvals in the catalog.
5. Train site leads and analysts on how to propose, validate, and consume canonical tags.

Next steps and extensions

After the initial rollout, consider:

• Automated discovery scripts that suggest candidate tags for cataloging.
• Dashboards that show tag coverage, orphan signals, and deprecated tags in use.
• Integration of the catalog with MES and historian mapping tools so canonical tags can be used directly by downstream systems.

Where to store the catalog

Begin with a shared, versioned document or spreadsheet integrated into your document management system. As the catalog matures, migrate to a searchable service or a managed metadata store that supports APIs for discovery and mapping.

If you want, this playbook can be converted into an interactive tag submission and validation form so teams can propose tags, run the checklist, and store approvals directly in your catalog (see capability notes below).