Tag Naming & Metadata Template for Manufacturing Data Catalog

Purpose and scope

This template defines a canonical tag naming convention and the required metadata to make every sensor, PLC signal, historian point, and calculated KPI discoverable, unambiguous, and usable across MES, analytics, dashboards, and automation. Use it as the minimal standard for site-level and enterprise catalogs so teams reduce duplicate signals, speed onboarding, and preserve institutional knowledge as a living catalog.

How to use this template

1. Adopt the canonical name pattern and required metadata fields for all new tags.
2. Backfill high-value existing tags (dashboards, KPIs, MES integrations) to meet the standard.
3. Enforce ownership and review cadence to keep the catalog current.
4. Publish the catalog where engineers, operators, analytics, and integrators can query it.

Canonical tag name format

Use a predictable, hierarchical pattern that communicates context at a glance. Recommended canonical format:

plant.line.asset.sensor.signal

Guidelines:

• Use a single delimiter (a period '.') between components.
• Lowercase only; use underscores only inside component tokens when required (prefer no spaces).
• Avoid special characters (%, #, @). Use alphanumeric and underscore (_) only.
• Keep names stable: avoid embedding transient values such as shift, operator, or date in canonical names.

Examples:

• plant1.lineA.cutter01.vibration_rms — RMS vibration for cutter 01
• plant2.line3.mixer02.temp — Temperature sensor on mixer 02
• plant1.lineA.pack01.output_rate — Calculated output rate for packer 01

Required metadata fields (minimum)

Every catalog entry must include these fields. Use these exact labels to support automated ingestion and mapping.

• CanonicalName — The canonical tag name following the pattern above.
• DisplayName — Human-friendly short label for dashboards and lists (e.g., "Cutter 01 Vibration RMS").
• Description — One- or two-sentence description: what the tag measures and why it matters.
• Owner — Role and individual (or contact group) responsible for correctness: e.g., "Instrumentation Engineer / ops-automation@company.com".
• SourceSystem — Origin system (PLC, historian, OPC-UA, MES, calculated): e.g., "PLC:A-BACnet:PLC3" or "Historian:PI".
• SourceAddress — Native address (PLC tag name, register, historian tag) for mapping and troubleshooting.
• DataType — Numeric, Boolean, String, Timestamp, Enum.
• Units — SI-preferred units where applicable (e.g., "°C", "m/s^2", "kg"). If unitless, state "unitless".
• TimestampSemantics — EventTime or IngestTime (clarify how timestamp is assigned and which should be used by consumers).
• UpdateFrequency — Expected sampling or update cadence (e.g., "250ms", "1s", "1m", "on-change").
• AcceptableRange — Expected operational min and max (e.g., "0-300 °C") used for data-quality checks.
• QualityChecks — Brief list of checks (e.g., "stale > 5m, out-of-range %, spike-detection method").
• LastValidationDate — Date when tag and metadata were last validated and by whom.
• LifecycleState — Proposed | Active | Deprecated | Decommissioned.
• ChangeRequestID — Link or identifier for the documented change request that created or altered the tag.

Recommended optional metadata

• AggregationMethod — If calculated: sum, avg, last, custom formula reference.
• SampleCardinality — If multi-channel or vector signal, list channels (e.g., "x,y,z").
• SecurityClassification — Public, Internal, Restricted.
• Tags — Freeform keywords for search (e.g., "OEE", "quality", "energy").

Signal lineage and source mapping

Record the lineage to make mappings and troubleshooting reliable. Fields to capture:

• SourceSystem and SourceAddress (see above).
• DerivedFrom — If a KPI or calculated signal, list canonical names of source signals and the transformation (formula or script reference).
• HistorianTag — If mirrored to historian, include historian tag name and retention policy.
• MESMapping — If used by MES, include MES variable name and expected use-case.

Data quality checks and validation rules

Document concrete checks so consumers and automation can rely on the signal:

• Staleness threshold (e.g., report stale if no update within 5 × UpdateFrequency).
• Out-of-range counts over sliding windows and required alerts.
• Spike and step-detection methods and thresholds.
• Null/NaN handling rules.
• Expected cardinality and tolerance for duplicated timestamps.

Timestamp and units governance

Standardize timestamps and units to avoid subtle mismatch bugs:

• Use UTC for stored timestamps and clearly mark when local time is used for display.
• Prefer SI units. If legacy units exist, include unit conversion formula in metadata.
• Document whether timestamp is event-generated (sensor) or assigned at ingestion.

Ownership, access and change control

• Each tag must have an Owner (role and contact). Owner approves changes and verifies metadata.
• Define an access policy: who can read vs. who can request changes vs. who can decommission.
• All metadata changes must reference a tracked ChangeRequestID and include justification and test plan.
• Schedule periodic reviews (recommended quarterly for critical signals; annually for others).

Lifecycle and decommissioning protocol

1. Proposed — Tag is requested; metadata draft created and assigned to an owner.
2. Active — Tag is in production, used by systems; must have completed validation checks.
3. Deprecated — Tag is scheduled for removal; consumers must migrate. Deprecated tags must remain discoverable and read-only for a defined period (e.g., 90 days).
4. Decommissioned — Tag removed from production streams and marked in the catalog with decommission date and reason. Maintain an archive entry for auditability.

Mapping template (recommended fields for CSV import/export)

Suggested header order for bulk updates or catalog exchange (CSV):

CanonicalName,DisplayName,Description,Owner,SourceSystem,SourceAddress,DataType,Units,TimestampSemantics,UpdateFrequency,AcceptableRange,QualityChecks,LastValidationDate,LifecycleState,ChangeRequestID,DerivedFrom,HistorianTag,MESMapping,SecurityClassification,Tags

Short examples and common pitfalls

• Good: plant1.lineA.mixer02.temp — Description: "Mixer 02 temperature (bearing housing), used for predictive maintenance"; Units: "°C"; TimestampSemantics: "EventTime".
• Pitfall — Duplicate semantic names across lines: Do not use temp alone; include asset context so two different mixers don’t share identical canonical names.
• Pitfall — Embedding operator or date in canonical name (e.g., packer01_202506): makes names ephemeral and breaks dashboards.
• Pitfall — Using different units without metadata: store units and conversion rules so analytics always know how to compare values.

Governance checklist (fast)

• Is the canonical name unique across the catalog?
• Is there a clear Owner with contact information?
• Are Units and TimestampSemantics defined?
• Are AcceptableRange and QualityChecks documented?
• Is SourceSystem and SourceAddress traceable to the physical device or PLC register?
• Is there a ChangeRequestID and audit trail for the tag?

Onboarding and enforcement suggestions

• Require a catalog entry before an analytics or MES integration goes live.
• Provide a simple submission form (template fields) and a light review workflow to populate the catalog.
• Maintain a short, public list of high-priority tags that must meet stricter review and validation.

Short maintenance SOP

When a sensor is replaced, follow this sequence: update SourceAddress → validate sampling and units → run automated quality checks for 24 hours → sign off LastValidationDate → record ChangeRequestID.

Appendix: Example CSV row

plant1.lineA.cutter01.vibration_rms,"Cutter 01 Vibration RMS","RMS vibration on cutter 01 measured on bearing housing","Instrumentation Engineer / instr-eng@co.com",Historian:PI,PI_TAG_CTR01_VIB,Numeric,m/s^2,EventTime,250ms,"0-50","stale>2s; spike>5g",2025-06-01,Active,CR-2025-014,"",PI_CTR01_VIB,MesVar:CTR01_VIB,Internal,"vibration;predictive_maint"

Closing notes

This template is intentionally practical and minimal. Start by applying it to the tags that back dashboards, KPIs, safety or production-critical systems. Expand metadata gradually only when it adds measurable value to discoverability, trust, or integrations.