Tag Naming & Manufacturing Data Catalog Playbook

Welcome — why a canonical tag catalog matters

Manufacturing data is only useful when everyone understands what each tag means, who owns it, how it should be used, and where it came from. A single authoritative tag catalog reduces duplicate signals, prevents unit mismatches, speeds onboarding, protects dashboards from breakage, and preserves institutional knowledge as a living asset.

How to use this playbook

This playbook gives concrete naming patterns, required tag attributes, governance roles, onboarding and audit steps, and ready-to-adapt examples. Use it as a site-level standard or copy into an enterprise domain and tailor tokens, abbreviations, and retention rules to local systems.

Naming convention guidelines (practical rules)

• Choose a single separator and stick with it. Recommended: dot (.) for hierarchical tokens (plant.area.line.asset.signal).
• Use only lowercase letters, numbers, dot, and dash where needed. Avoid spaces and special characters.
• Keep names human-meaningful and machine-parseable. Prefer tokens over long free-text phrases.
• Limit length where system constraints exist; keep the most important tokens at the leftmost positions.
• Standardize abbreviations in a shared glossary (pump = pmp, temperature = temp, pressure = pres, vibration = vib, etc.).
• Reserve suffixes for semantics: .raw, .avg, .sum, .calc, .status, .cmd
• Do not encode ownership or transient state in the tag name; use metadata for owner, status, and lifecycle.
• Use versioning in metadata rather than changing names whenever possible; deprecate and supersede tags rather than renaming in place.

Recommended canonical pattern (token order)

Pattern: plant.area.line.asset_type.asset_id.signal_type.measurement.suffix

Example:

• plant01.lineA.pmp.pump01.vib.rms.raw
• plant01.lineA.oven.oven03.temp.sensor.C.raw
• plant01.lineA.pmp.pump01.flow.calc.lpm.avg
• plant01.assemblyA.conv01.status.running

Standard attributes (metadata every catalog entry should include)

• canonical_name: the agreed tag name
• display_name: human-readable title
• description: one-sentence purpose and physical meaning
• owner: person or role (email/role) responsible for correctness
• source_system: PLC/historian/edge device name and tag id
• data_type: analog/digital/string
• unit: standardized unit from site glossary (psi, C, mm/s)
• sampling_frequency: e.g., 1s, 10s, event-driven
• timestamp_convention: device-time, server-ingest-time, event-time
• aggregation_method: avg/min/max/count/none
• criticality: P0/P1/P2 or Business/Critical/Informational
• retention_policy: raw retention and aggregated retention
• status: active, deprecated, superseded
• last_modified and version
• security_classification: public/internal/restricted
• related_kpis: links to MES/KPI catalog entries

Criticality & retention policy (practical defaults)

Define small set of criticality levels and map them to retention and backup rules so storage and compliance are predictable.

• P0 (Operational-critical): raw data retained 1 year, aggregated rollups 7 years
• P1 (Important): raw 90 days, rollups 3 years
• P2 (Reference/Diagnostic): raw 30 days, rollups 1 year

Document exceptions and legal/regulatory retention separately.

Version control and lifecycle

• Keep a version and change log in metadata rather than changing canonical_name whenever possible.
• When a signal must be replaced, create a new canonical name and mark the old tag deprecated with a superseded_by field pointing to the new tag.
• Maintain backward mapping tables so dashboards and MES integrations can be remapped without immediate breakage.

Governance roles (recommended RACI)

• Data Owner (R): Plant engineer or process owner—accountable for correctness and criticality.
• Data Steward (A): Site data steward—maintains catalog entries, units, and metadata.
• Tag Author (C): Engineer who proposes new tags and naming.
• Historian Admin (C): Implements and tests tags in the historian.
• MES/Analytics Integrator (I): Consumer who validates mapping and use in dashboards/MES.
• Security Officer (I): Reviews access rules for sensitive tags.

Sample tag templates & examples

Use these as starting templates and adapt token names to your glossary.

• Sensor (raw): plant01.area.station.asset.sensorType.measurement.raw
  • Example: plant01.lineA.pmp.pump01.vib.rms.raw
• Calculated KPI: plant01.area.line.asset.kpiName.calc.period
  • Example: plant01.lineA.oee.oee.calc.shift
• Status/command: plant01.area.asset.status.running
  • Example: plant01.lineA.pmp.pump01.status.running

Onboarding checklist for new tags

1. Submit a Tag Request with proposed canonical_name and token mapping.
2. Data Steward reviews abbreviations, units, and naming conflicts.
3. Assign Data Owner and security classification.
4. Implement in source system and confirm source_system mapping in metadata.
5. Test data flow to historian/MES and verify timestamps and units.
6. Set retention_policy and criticality.
7. Publish entry in the catalog and notify integrators/consumers.
8. Record version and change log entry.

Short audit script and queries (quick wins)

The following are generic pseudo-queries you can adapt to your catalog DB or historian query language.

-- Find tags with missing owner
SELECT canonical_name FROM tags WHERE owner IS NULL OR owner = '';

-- Find duplicate source mappings (same source_system + source_tag but different canonical_name)
SELECT source_system, source_tag, COUNT(*) FROM tags GROUP BY source_system, source_tag HAVING COUNT(*) > 1;

-- Find tags with inconsistent units for similar signals (group by signal token)
SELECT signal_signature, ARRAY_AGG(DISTINCT unit) as units FROM tags GROUP BY signal_signature HAVING ARRAY_LENGTH(units) > 1;

-- Find tags not referenced by dashboards or MES (requires joins to integration mapping tables)
SELECT t.canonical_name FROM tags t LEFT JOIN integrations i ON t.id = i.tag_id WHERE i.tag_id IS NULL;
  

Run these scripts regularly and surface results to the Data Steward queue for triage.

Practical governance tips

• Keep an abbreviations glossary as part of the catalog and make it editable by the Data Steward team.
• Automate basic audits and create a weekly digest of new, deprecated, and orphaned tags.
• Use metadata-driven dashboards to show tag health: missing owners, inconsistent units, low data quality rates.
• Publish a simple intake form (onboarding checklist) so every new tag follows the same workflow.

Next steps & templates to copy

Copy this playbook into your plant domain and:

1. Adapt the canonical token order and abbreviations to local equipment terminology.
2. Create the onboarding form and catalog schema with the metadata fields listed above.
3. Implement the example audit queries for your historian and schedule automated runs.

End of playbook. Use the governance notes and templates as living artifacts—update them when new systems or naming patterns appear.