Tag Naming Convention Policy & Example Catalog

Purpose

This policy defines a clear, consistent tag naming convention and required metadata for shop-floor signals used by historians, MES, SCADA, dashboards, and analytics. The goal is trustworthy, joinable, and auditable data so operators and analytics teams can make reliable real‑time and historical decisions.

Scope

Applies to all new and changed instrumentation, PLC tags, historian points, MES data points, and derived signals at the site. Existing tags should be migrated or documented against this policy as part of the Data Foundations stage.

Naming Convention: Structure and Rules

Tag names must be human-readable, machine-parseable, and consistent across systems. The canonical structure is:

<site>_<line>_<asset>_<signalType>_<unitOrQualifier>_<sampleHint>

• site — short site code (lowercase, alphanumeric).
• line — production line or cell identifier.
• asset — equipment identifier (pump01, motorA, oven2).
• signalType — short semantic type (temp, rpm, status, flow, pres, lvl, vib, energy, sp for setpoint).
• unitOrQualifier — engineering unit or qualifier (C, F, rpm, lpm, bar, pct, kWh, mm/s).
• sampleHint (optional) — sampling annotation for human readers (1s, 5s, 1min). Use only when it adds clarity.

Use underscore (_) as separator. Use only lowercase letters, digits, and these allowed separators: underscore. Avoid spaces, special characters, or embedded dots. Keep names < 128 characters where possible.

Example canonical pattern (human form): site_line_asset_signal_unit_sampling

Suggested validation regex example (implement in tooling):

^[a-z0-9]+(?:_[a-z0-9]+)*_[a-z]+_[A-Za-z0-9%/]+(?:_\d+[smh])?$

(Adjust regex to your site codes and allowed signalTypes. The platform should validate tag creation against an approved list of signalTypes and units.)

Required Metadata

Every tag registered in the catalog must include these metadata fields at creation time:

• DisplayName — human-friendly label used on dashboards.
• Description — brief functional description: what is measured and why.
• Owner — responsible person or role (name, team, contact).
• PhysicalLocation — site, building, line, and mounting point.
• DeviceID — PLC/IO device identifier or connection point.
• DataType — float, int, bool, enum, string.
• EngineeringUnits — acceptable units (C, bar, rpm, lpm, %, kWh, mm/s).
• ExpectedRange — min and max typical operating values (for alerting and data quality checks).
• SampleRate — nominal collection frequency (1s, 10s, 1min).
• TimestampSource — device timestamp or collection server.
• RetentionPolicy — retention and aggregation plan (raw/30 days, hourly/2 years, etc.).
• QualityFlags — how bad/missing samples are annotated.
• CreatedBy / CreatedDate and ChangeHistory — audit trail entries.
• Lineage — source mapping if derived from other signals.

Example Catalog (10 example tag names with brief notes)

1. northplant_lineA_pump01_temp_C_1s — pump 1 temperature in °C sampled every second.
2. northplant_lineA_pump01_vib_mms_1s — vibration magnitude (mm/s) for pump 1.
3. northplant_lineB_motor02_rpm_rpm_1s — motor speed in RPM.
4. northplant_lineB_oven02_sp_C — oven setpoint in °C (setpoint signals rarely sampled faster than control loop).
5. southplant_fill01_flow_lpm_1s — flow at filler station in liters per minute.
6. southplant_fill01_level_pct_10s — level percentage at filler, sampled every 10s.
7. plantX_chiller01_press_bar_5s — chiller pressure in bar.
8. plantX_pack01_line_status_bool — packing line RUN/STOP status (boolean or enum).
9. central_energy_main_meter_kwh_1m — facility energy meter cumulative kWh, 1 minute resolution.
10. plantY_blend01_tempC_avg_1m — blended temperature (derived) averaged to 1 minute.

Note: Use a controlled vocabulary for signalType and engineering units. Maintain that vocabulary in the data catalog.

Change Control and Tag Lifecycle

To avoid ad-hoc tagging and fragmentation, follow a simple governance workflow:

1. Request — Engineers or operators submit a Tag Request (include proposed name, metadata, purpose, and owner).
2. Review — Data/Instrumentation steward validates name against the registry, checks metadata completeness, and confirms ownership and retention policy.
3. Approve & Create — Approved tags are created in the historian/MES and catalog with audit metadata (createdBy, date).
4. Modify — Any name change requires new tag creation and deprecation of the old tag with a clear mapping; historical continuity must be documented.
5. Retire — Tags are retired by marking status=deprecated, noting replacement mapping and retirement date; historic data retained per retention policy.

Define roles: Tag Requester (who asks for the tag), Tag Steward (reviews and approves), and Data Owner (long-term owner). Use role-based access for tag creation in systems.

Operational Guidance and Enforcement

• Publish the naming vocabulary and required metadata template in the data catalog.
• Provide an approved list of signalTypes and units to enforce during validation.
• Automate validation where possible (PLC export checks, tag import scripts, CI checks for historian uploads).
• Register change history and maintain searchable lineage to support analytics and operator trust.
• Use the naming convention during MES and dashboard configuration so joins and aggregations are predictable.

Exceptions and Special Cases

Special derived signals, temporary test points, or vendor-supplied device names may be allowed with an exception record in the catalog. Exceptions must include an owner and an expiration or migration plan.

How to Use This Policy During Data Foundations

Apply this policy during the Data Foundations stage: scan current tag inventory, map deviations, prioritize high-value signals for remediation, and publish a migration plan. Treat this policy as the baseline for future analytics and AI work; inconsistent tag names and missing metadata are primary causes of failed analytics and lost operator trust.

Appendix: Implementation Tips

• Create a simple CSV template or form for mass imports that includes all required metadata fields.
• Implement a lightweight approval workflow in your data catalog or ticketing system for tag requests.
• Provide a short cheat sheet for field engineers that shows examples and the preferred vocabulary.
• Consider a small pilot to fix the top 100 tags used by OEE, quality, and maintenance dashboards before wider rollout.