Starter Manufacturing Data Catalog & Tag Naming Patterns

Why a canonical manufacturing data catalog matters

Confident analytics, trustworthy dashboards, and dependable MES integration all begin with clear, consistent signals. A small, well-governed tag catalog prevents duplicate tags, ambiguous signals, and broken models — so teams can make faster, safer, and better decisions on the shop floor.

Key starter fields (recommended CSV / catalog headers)

• tag_id (string, unique): The canonical machine-readable identifier used in telemetry, MES mapping, and APIs.
• human_label (string): A short, readable name for operators and dashboards.
• description (string): One-line purpose and behavior of the signal.
• asset_id (string): Which asset, line, or area the tag belongs to.
• location (string): Plant/area/coordinate to help physical discovery.
• signal_type (enum): e.g., sensor, setpoint, status, alarm, counter, computed.
• data_type (enum): e.g., float, int, bool, string, datetime.
• units (string): Use standard units (SI where possible).
• sampling_rate (string): e.g., 1s, 500ms, event, on-change.
• aggregation (enum): How to reduce for dashboards (avg, max, min, last, sum).
• source_path (string): PLC address, OPC-UA node, MQTT topic, historian tag.
• owner (team/person): Who is responsible for the tag's correctness and lifecycle.
• steward_contact (email/phone): Operational contact for questions/changes.
• retention_policy (string): e.g., 90d, 7y, tiered; required for compliance/cost planning.
• access_level (enum): public, restricted, confidential.
• version (string): For tag-model changes (v1, v2...).
• created_date and modified_date (datetime)
• deprecated (yes/no) and replacement_tag (optional)
• data_quality_notes (string): Recent known issues or checks.

Naming rules and patterns

Pick a small, consistent template and enforce it. The goal is predictability and discoverability. Use delimiters consistently (dots or colons), prefer asset-context first, then signal semantics, and include a version token for breaking changes.

Recommended canonical pattern (human- and machine-friendly):

<plant>.<area>.<asset_id>.<signal_type>.<signal_name>.v<version>

Example:

• PL01.LINEA.MILL01.sensor.temp.cabinet.v1
• PL01.LINEB.COATER.counter.parts_processed.v1
• PL01.LINEA.PUMP02.status.running.v1

Short rules:

• Use uppercase or lowercase consistently across the catalog (choose one).
• Use short standard abbreviations for common concepts (e.g., temp, pres, rpm, cnt) and document the abbreviation list in the catalog governance doc.
• Avoid spaces and special characters; use dot (.) as the delimiter for readability and compatibility.
• Include a version token (vN) when changing signal semantics or math — do not silently repurpose tag IDs.
• Prefer explicit signal types (sensor, setpoint, status) rather than inferring from name alone.

Concrete examples and when to use them

• Real sensor reading: plant.area.asset.sensor.temp.process.v1 — time-series float with units °C.
• Binary status: plant.area.asset.status.emergency_stop.v1 — boolean (true/false).
• Counter/accumulator: plant.area.asset.counter.parts_processed.v1 — integer, aggregation=sum.
• Computed KPI (derived): plant.area.asset.computed.oee.v1 — computed externally, mark source and calculation in description.

Owner and stewardship rules

• Every tag must have an owner (team or person) responsible for correctness, changes, and retirement.
• Owners must approve new tags in a lightweight registration workflow and confirm retention/access settings.
• Stewards ensure mappings to PLC/MES/historian are accurate and that the source_path is maintained.
• Define a review cadence (quarterly or semi-annually) for high-value tags and after any process change.

Suggested data-quality checks

Automate recurring checks and record results in the catalog (last_checked, pass/fail, notes):

• Null/missing rate: flag tags with >X% gaps over the last 7 days.
• Out-of-range values: compare against configured min/max and alert on breaches.
• Timestamp continuity: detect irregular sampling or clock skew.
• Duplicate signals: monitor correlated tag streams to detect duplicated telemetry.
• Sampling-rate drift: track deviations from declared sampling_rate.

Governance & lifecycle

1. Registration: New tags go through a catalog entry form (fields above) and owner sign-off before production mapping.
2. Test: Ensure a tag is test-published to a sandbox historian or test topic and validated by the owner and integrator.
3. Deploy: Only then map to production streams and downstream consumers (dashboards, models, MES).
4. Change control: Any semantic change creates a new versioned tag_id (v2) with deprecation notice on old tag.
5. Retirement: Mark deprecated tags explicitly, set retention and archive policies, and publish replacements.

MES & analytics integration tips

• Map catalog tag_id values to MES signal identifiers in a single mapping table to avoid duplicated lookups.
• Document transformation logic in the catalog for derived signals (formula, aggregation window).
• Provide consumers a stable view (e.g., canonical tag + version) to avoid breaking dashboards when tags change.

Starter checklist

• Create the catalog CSV with the recommended headers and a short abbreviation glossary.
• Choose and publish the canonical naming delimiter and case rule.
• Run a discovery pass to find duplicate or similar tags and shortlist candidates for consolidation.
• Assign owners and set an initial review cadence.
• Automate at least three quality checks (missing rate, out-of-range, duplicate detection) and surface results to owners weekly.

Next practical steps

Start small: pick a single production line, build the canonical catalog for that line, enforce the registration workflow, and iterate. Use the first 30–60 days to refine abbreviations, thresholds, and owner responsibilities before scaling plant- or enterprise-wide.

References & artifacts to produce

• Canonical tag CSV template (use the starter headers above).
• Abbreviation glossary and signal_type definitions.
• Owner/steward contact list and review cadence policy.
• Automated DQ report templates and alert rules.

When implemented with consistent governance and simple automation, this starter catalog prevents the common failure modes that break dashboards and models: inconsistent names, missing owners, silent repurposing, and untested changes. It’s a small investment that pays back quickly in trust and speed.