Data Foundations: Tagging, Naming & Baseline Metrics Playbook

Data Foundations Playbook

Goal: establish a minimal, repeatable data foundation so operator boards, OEE dashboards, and early AI pilots use trustworthy signals. This playbook gives concrete rules for tag selection, naming and ownership, sampling and aggregation, a baseline collection plan, three quick operator-facing metrics you can deliver within a week, a validation checklist, and governance next steps.

What success looks like

• Every critical signal has a single canonical tag with a documented owner.
• Sampling and aggregation rules are documented so dashboards match shop-floor reality.
• Two-week baseline windows per line produce initial thresholds you can validate with operators.
• Three operator-board metrics are live and trusted within one week of the pilot start.

1. Tag selection — what to capture first

Prioritize signals that directly feed decision-making and OEE-style metrics. Start with a small, high-value set:

• Uptime / machine state (run/stop/fault) — event-driven or 1s sampling
• Cycle time (per part/cycle timestamp or per-cycle duration)
• Good part count (counter)
• Reject count (counter with reject reason if available)
• Speed / feed / process variable (analog, e.g., RPM, m/min)
• Equipment state codes / fault codes (text or enumerated ints)

Why these? They let you compute Availability, Performance, and Quality (the OEE building blocks) and catch problems early.

2. Naming convention template & owner assignment pattern

Use a predictable, parseable pattern. Example template:

[PlantCode].[Area].[Line].[Equipment].[SubSystem].[SignalType].[SignalName].[Unit]

Example: PLT1.LINEA.CELL3.PRESS.CNT.GoodParts.count

Naming rules (keep names short but descriptive):

• Use consistent separators (period). Avoid spaces and special characters.
• SignalType values: state, cnt, meas, evt, param. Unit at the end helps downstream conversions.
• Include product/recipe only if the tag is product-specific — prefer metadata instead.

Owner assignment pattern (minimum metadata each tag must store):

• OwnerRole (e.g., ProcessEngineer), OwnerName, ContactEmail
• Stewardship (e.g., AutomationTeam / LineLead)
• TagVersion and ChangeLog link

3. Sampling strategy, aggregation rules & latency expectations

Define rules by signal type rather than ad-hoc for each tag:

• State signals: event-driven preferred; if polling, 1s is ideal to preserve short stops. Aggregate as latest-state with timestamps and compute dwell time per state.
• Cycle events / counters: increment on each part; store raw increments and compute rates (parts/hr) in analytics. Keep counter rollovers and resets explicit.
• Analog measurements (temperature, speed): 1–5s sampling depending on dynamics. Store raw samples when feasible. For dashboards, precompute 1s/10s/1m aggregates: min, max, mean, stddev.
• Fault codes & text: event record with timestamp and duration. Map codes to categories in metadata for easier aggregation.

Aggregation rules examples:

• Availability = (run_time) / (scheduled_time) where run_time is computed from state tag dwell times.
• Performance = ideal_cycle_time * good_parts / run_time.
• QualityRate = good_parts / (good_parts + rejects) using counters over the same window.

Latency expectations:

• Operator boards: near real-time (<5s preferred).
• Shop-floor dashboards: 10s–1min acceptable depending on network constraints.
• Historical storage and ML training: retain raw or high-frequency aggregates (1s or per-cycle) where practical.

4. Baseline collection plan (practical steps)

1. Select a pilot line and define a 2-week stable window per line (include at least several product runs and all shifts).
2. Tag the metadata: shift, product, operator, recipe; capture contextual markers for changeovers.
3. Collect raw data at the agreed sampling rates. Run automated quality checks daily (gaps, duplicates, out-of-range).
4. Compute baseline statistics: mean, median, percentiles (5/95), stddev, and rate metrics per shift and product.
5. Set provisional thresholds (e.g., alarms at 95th percentile or mean ± 3σ) and validate with operators for false positives.
6. Iterate thresholds after one week of human validation.

Note: the two-week guideline is a starting point — if the line has long product changeovers or seasonal effects, capture representative cycles instead of strict calendar windows.

5. Quick wins — three small metrics to ship in a week

These give immediate value on operator boards and validate your tags and aggregation logic:

1. Line OEE (shift view): Show current shift OEE with trend. Data: state tag, cycle-time, good/reject counters.
2. First Pass Yield (per shift): good_parts / total_parts, with reject reason breakdown if available.
3. Cycle Time Trend or Takt Compliance: display last 30 cycles and 1-hour average vs. target takt.

Display each metric with a short explanation, a sparkline, and a red/amber/green status flagged to the operators. Keep the visuals simple.

6. Tag validation checklist (use this during commissioning)

• Tag exists in registry and follows naming convention.
• Owner and stewardship fields populated.
• Unit and data type correct and documented.
• Sampling rate and aggregation rules recorded.
• Timestamps are synchronized (NTP) and timezones correct.
• Data shows expected values during simple manual tests (increment counters, force state changes).
• Automated health checks in place: gap detection, spike detection, duplicate messages.

7. Common pitfalls and how to avoid them

• Inconsistent units across similar tags — standardize units in metadata and convert at ingestion.
• Duplicate tags representing the same physical signal — consolidate and deprecate duplicates with redirects.
• Low sampling hides short stops — increase state sampling to 1s for critical signals.
• Missing product/recipe metadata making baselines noisy — capture contextual markers during collection.
• Leaky counters or resets without documented resets — detect and correct resets in preprocessing.

8. Governance & next practical steps

1. Create a lightweight Tag Governance board (ProcessEngineer, AutomationLead, LineLead, IT/OT steward).
2. Publish a one-page naming & sampling standard and a tag registration form your team uses whenever a new tag is added.
3. Run a 2-week pilot on one line: implement the three quick metrics, validate baselines with operators, and run the validation checklist.
4. Schedule a quarterly tag audit and a lightweight change process that records TagVersion and a change rationale.

Templates & artifacts to create next (recommended)

• Tag registration template (CSV / interactive form) with required metadata fields.
• Sampling & aggregation rules reference sheet by signal type.
• Baseline calculation notebook or SQL queries for mean, percentiles, and thresholds.
• Operator-board widget spec for OEE, FPY, and Cycle-Time Trend.

Short experiment to run in week 1

Pick one line, register the critical tags using the template, implement the three quick metrics on an operator display, and run the tag validation checklist. Use the pilot to refine sampling rates and thresholds with operators. If the pilot shows trusted values and operator adoption, scale to additional lines.

Tip: preserve raw high-frequency samples for at least the pilot period even if you intend to downsample later — raw data makes root cause analysis and ML much easier.