Manufacturing Data Catalog Playbook

Welcome — why a canonical tag catalog matters

Shopfloor analytics and MES integration only deliver value when the underlying signals are consistent, discoverable, and trusted. This playbook helps teams create a canonical tag catalog (a single source of truth for each signal) with clear naming, required metadata, ownership rules, and an onboarding process that prevents duplicates, ambiguous signals, and brittle dashboards.

What you’ll get from this playbook

• A recommended set of required tag metadata fields and a template for tag records
• Simple, practical naming conventions with examples you can adapt
• An ownership matrix template so every tag has a steward and clear access rules
• An onboarding checklist to add new sources (PLCs, historians, IoT devices, manual entries)
• Governance rules for versioning, deprecation, audits, and change control
• KPI ideas so you can measure catalog health and onboarding velocity

Scope & roles

This playbook covers signal-level governance for process and machine data that feed analytics, MES, and dashboards. Typical roles:

• Data Owner / Process SME: accountable for the meaning and business use of the tag.
• Tag Steward / Integrator: accountable for tag metadata, instrumentation mapping, and onboarding.
• Platform Owner: ensures the catalog is available, searchable, and integrated with historians/MES.
• Governance Board: approving naming patterns, access classifications, and exceptions.

Recommended tag metadata fields (minimum)

Each canonical tag record should include the following fields. Treat this as a starting point and adapt to your environment.

• TagID: immutable internal identifier (GUID or short canonical code)
• CanonicalName: standardized name following your naming convention
• ShortLabel: human-friendly short name
• Description: plain-English explanation of what the signal means
• SourceSystem: PLC, historian, sensor model, vendor
• SourceAddress: device address, point path, or connector mapping
• DataType: numeric, boolean, string, timestamp, enum
• Unit: e.g., °C, kg, rpm (or blank if not applicable)
• SamplingFrequency: raw sampling or expected publish rate
• AggregationRule: how to summarize for analytics (avg/sec, last, max)
• ProcessArea / Location: plant, line, cell, area
• EquipmentID: referenced asset registry ID
• OwnerRole and OwnerName
• AccessClassification: public, internal-analytics, restricted
• Status: Proposed, Active, Deprecated, Deleted
• CreatedDate and LastValidatedDate
• Tags: freeform keywords for discovery (e.g., temp, pressure)
• Notes / Validation History

Naming convention — a practical template

A good naming convention balances machine-parsability with human readability. Use a consistent, delimited structure and document every element. Example template:

<Plant>.<Area>.<Line>.<Equipment>.<SignalCategory>.<SignalName>[-<Suffix>]

Concrete example:

PLT1.AREA3.LINE2.MIXER2.TEMP.CURRENT

Meaning: Plant 1 → Area 3 → Line 2 → Mixer 2 → temperature signal → instantaneous value

Naming rules (keep these short and enforceable)

• Use upper-case letters and periods as delimiters.
• No spaces or special characters other than hyphen for suffixes.
• Use short, consistent abbreviations for common items (e.g., TEMP, PRES, FLW).
• Include a suffix for derived signals (e.g., _AVG, _MAX, or use aggregations in metadata).
• Reserve names for standardized control points (e.g., START, STOP, SETPOINT).

Good vs. bad examples

• Good: PLT1.LINE1.PUMP3.FLOW.CURRENT — clear structure, equipment, signal
• Bad: Flow_P3 — ambiguous: which plant, which pump, units?
• Bad: PUMP3_FLOW_LPS — inconsistent delimiter and embedded unit
• Good: PLT2.AREA5.FURNACE1.TEMP.SETPOINT — clearly a setpoint not a measurement

Ownership matrix template

Each tag should map to a small ownership record. Example columns for your registry:

• TagID / CanonicalName
• OwnerRole (Process SME)
• OwnerName (person or team)
• TagSteward (integrator/engineer)
• AccessLevel
• ValidationCadence (e.g., quarterly)

Onboarding checklist (use this when adding a new source)

1. Map source points to proposed canonical names and metadata.
2. Check for existing canonical tags (de-duplicate).
3. Populate required metadata fields and assign OwnerRole/OwnerName.
4. Confirm sampling/aggregation rules and units.
5. Classify access and any PII/security considerations.
6. Run a short validation: compare live values to expected ranges for 24–72 hours.
7. Record validation results and sign off by Owner and Steward.
8. Publish the canonical tag entry and update any downstream mappings (dashboards, MES, historian tags).

Governance, lifecycle & change control

Protect catalog integrity with a lightweight governance process:

• Adopt a change request template for adding/changing/deprecating tags.
• Require at least one Process SME and one Integrator to approve changes.
• Tag lifecycle: Proposed → Active → Deprecated → Removed. Deprecated tags remain discoverable with redirect to canonical replacements.
• Run periodic catalog audits (quarterly) to catch drift, duplicates, stale owners.
• Keep a validation history for each tag (who verified, when, what tests).

KPIs & measures of catalog health

• Percent of analytics-critical signals covered by canonical tags (target 95%)
• Number of duplicate or ambiguous tags found per quarter (trend down)
• Average time to onboard a new device/signal (days)
• Percent of tags with an assigned OwnerName (target 100%)
• Number of dashboard incidents caused by ambiguous signals (target 0)

Practical rollout plan

1. Start with a pilot scope: one plant or one product line. Standardize 100–300 high-value tags first.
2. Run a short naming workshop with Process SMEs, Controls, IT, and Analysts to agree on the base template and abbreviations.
3. Populate the initial catalog entries and onboard into a searchable registry (spreadsheet → lightweight DB → formal tool over time).
4. Integrate the canonical names with historian/MES mappings so dashboards read canonical tags, not source addresses.
5. Institutionalize the onboarding checklist and governance approvals.
6. Measure KPIs and expand scope iteratively.

Sample canonical tag record (example)

Common pitfalls and how to avoid them

• Allowing local ad-hoc names: require that any dashboard or analytics query references the canonical name or a documented mapping.
• Missing ownership: make OwnerName mandatory for activation.
• Overly long or inconsistent naming rules: keep the template small and enforce abbreviations centrally.
• Not planning for deprecation: always create a replacement and timeline when removing a tag.

Next steps & templates

Use the onboarding checklist for every new source. Start by standardizing the top 100 signals that feed core dashboards and MES transactions. Track onboarding and validation results in a shared spreadsheet or registry. Over time move the registry into a searchable catalog tool and enforce lookups via integrations with MES and historians.

Appendix — quick checklist (copyable)

1. Agree naming template & abbreviations (workshop)
2. Populate seed canonical tag list (top 100 signals)
3. Map sources and remove duplicates
4. Assign owners and run 24–72 hour validation
5. Publish canonical tags and update downstream mappings
6. Schedule quarterly audit & measure KPIs

Ready to make this operational? Consider converting the onboarding checklist into an interactive form that captures each new tag’s metadata and stores it in the catalog. That enables historical tracking of validations, automated duplicate checks, and dashboards showing onboarding progress.