Sensor Tagging & Naming Convention Template

Purpose

This template defines a clear, automation-friendly convention for naming sensor tags and the associated metadata fields you should capture. Consistent tag names and metadata make sensor data discoverable, analyzable, and reliable across historians, MES, analytics, and dashboards — and prevent broken dashboards, failed analytics experiments, and confusing integrations.

Core principles

• Be predictable: Use a single, well-documented structure so tools and people can infer meaning without custom lookups.
• Be machine-friendly: Use lowercase, alphanumerics, and a single separator; avoid spaces and punctuation that confuse parsers.
• Capture essential metadata: Name alone is not enough — capture units, sampling rate, owner, calibration, acceptable ranges, and provenance.
• Support governance: Record ownership, lifecycle status, and a change-history policy so tags remain trustworthy over time.

Recommended tag name structure

A compact hierarchical format is easiest to read and parse. Use a single separator (hyphen) and lowercase letters:

Format: site-line-machine-sensor-location-signal

• site — facility code or plant name (e.g., plantA)
• line — production line, cell, or area (e.g., line1)
• machine — equipment id (e.g., mill01)
• sensor — physical sensor identifier or position (e.g., head1)
• location — optional finer position such as bearing, spindle (e.g., spindle)
• signal — measured quantity and axis if applicable (e.g., temp, vibration-axial, speed)

Example: plantA-line1-mill01-head1-spindle-temp

Keep names concise but meaningful. Max length: document a practical limit (e.g., 64 characters) for your systems and enforce it with validation rules.

Allowed characters and case

• Lowercase letters a–z, digits 0–9, and hyphen (-) as the only separator.
• No spaces, underscores, slashes, dots, or special characters.
• Start with a letter, not a digit, when possible.

Essential metadata fields (minimum)

Store these fields with each tag in your tag registry or asset management system so systems and teams can use the tag reliably.

• tag_name — canonical name following the convention above
• display_name — human-friendly label for UIs
• unit — standardized units (SI preferred, e.g., C, m/s2, rpm)
• data_type — float, integer, boolean, string, enum
• sampling_rate_hz — nominal sample frequency in Hz (or seconds interval)
• sensor_id — hardware identifier, serial number, or asset tag
• calibration_date — last calibration or verification date
• owner — team or person responsible for the sensor (contact)
• acceptable_min / acceptable_max — operational range for basic filtering and alerts
• source_system — PLC, RTU, OPC-UA server, historian name
• aggregation — recommended aggregation for analytics (raw, avg_1s, avg_1m, max_1min)
• status — active, maintenance, deprecated
• tags — keywords (e.g., quality-critical, safety, predictive-maintenance)

Sampling rate guidance

Choose sampling rates based on the signal bandwidth and the use case:

• High-frequency diagnostics (vibration): 1 kHz+ for raw waveforms; consider streaming to a dedicated vibration system and storing derived metrics in the historian.
• Condition metrics: 1–100 Hz depending on dynamics (e.g., spindle-speed RPM might be 1–10 Hz sampled, while fast-changing currents need more).
• Slow-changing values (temperature, level): 0.016–1 Hz (one sample per minute to one per hour), depending on thermal time-constant.
• Rule of thumb: Sample at least 2x the highest frequency of interest (Nyquist), then consider storage cost and downstream needs; store high-rate raw data selectively or in compressed repositories.

Acceptable ranges, quality, and flags

Record acceptable_min and acceptable_max to enable basic sanity checks and automated alerts. Use a quality flag field with consistent semantics (e.g., 0=good, 1=stale, 2=bad, 3=calibration) so analytics can ignore or treat data appropriately.

Examples

Tag name examples for common signals:

• plantA-line1-mill01-head1-spindle-temp — spindle temperature (C)
• plantA-line1-mill01-head1-spindle-speed — spindle speed (rpm)
• plantA-line1-mill01-bearing1-vibration-axial — vibration axial (m/s2) high rate
• plantA-line1-press02-hydraulic-pressure — pressure (bar)

Example metadata payload (for registry storage):

{
  "tag_name": "plantA-line1-mill01-head1-spindle-temp",
  "display_name": "Mill01 Head1 Spindle Temp",
  "unit": "C",
  "data_type": "float",
  "sampling_rate_hz": 1,
  "sensor_id": "SN-12345",
  "calibration_date": "2025-03-12",
  "owner": "maintenance.team@example.com",
  "acceptable_min": -10,
  "acceptable_max": 120,
  "source_system": "opcua://plantA/historian1",
  "aggregation": "avg_1m",
  "status": "active",
  "tags": ["quality-critical", "process"]
}

Automation-friendly rules

1. Enforce the naming regex in ingestion pipelines (e.g., ^[a-z][a-z0-9-]{1,63}$ with separators validated for expected positions).
2. Automatic validation on ingest: verify unit matches data_type and values are within acceptable_min/max or set quality flag.
3. Provide tag templates for new devices so onboarding scripts can generate tags and metadata automatically.
4. Keep a machine-readable registry (JSON/CSV/SQL) with stable keys (tag_name) and API access for tools and analytics.

Governance & lifecycle

Define a lightweight governance process:

• Tag creation request workflow (who may create tags, required metadata, validation checks).
• Ownership assignment and contact details for every tag.
• Change control and deprecation policy (mark tags deprecated before removal, keep aliases for mapping historical data).
• Periodic audit and cleanup schedule (e.g., quarterly review of unused or duplicate tags).

Quick checklist for new tag onboarding

• Does the name follow the site-line-machine-sensor-location-signal pattern?
• Are unit and sampling_rate_hz set and consistent with the signal?
• Is an owner assigned and contactable?
• Are acceptable_min and acceptable_max defined?
• Is the tag registered in the central registry and mapped to the source system?
• Has the tag been given a status and a retention/aggregation policy?

Next steps and integrations

Make this template actionable by:

• Implementing registry validation rules in your ingestion pipeline and historian connectors.
• Providing a simple tag request form (or Interactive tag registry) that enforces metadata fields on submission.
• Mapping tags to asset and CMMS records to join sensor data with maintenance history.
• Adding scripts to auto-generate derived tags and aggregation points for analytics and MES consumption.

Appendix: Naming examples quick reference

• Vibration raw waveform (high-rate store): plantA-line1-mill01-bearing1-vibration-axial
• Temperature for historian (1 Hz): plantA-line1-mill01-head1-spindle-temp
• Motor current (analytics): plantA-line1-mill01-motor1-current