SCADA & OT → BI Integration Checklist

Why this checklist matters

Operational telemetry often looks useful until timing, metadata, or safety gaps turn insights into misleading conclusions or unsafe actions. Use this checklist to reduce common sources of data loss, misalignment, and unsafe integrations when bringing SCADA/OT signals into BI and decision workflows.

How to use

1. Work through each section with OT engineers, IT/security, data engineers, and an operations representative.
2. Record responsible owner(s), acceptance criteria, test plans, and completion date for each item.
3. Consider converting this checklist to an interactive form to capture evidence, timestamps, and attachments for audits.

Network & security constraints

• Confirm network segmentation strategy: confirm which OT subnets are allowed to share data, where DMZs or protocol gateways exist, and approved ingress/egress paths.
• Document protocols and ports: list PLC/RTU protocols (e.g., OPC UA, Modbus) and version/transport (TCP, OPC UA over TLS) with required port rules.
• Enforce least privilege: verify that any BI/analytics connection uses dedicated, auditable service accounts or certificates; avoid shared operational credentials.
• Validate encryption and certificate management: confirm TLS, certificate rotation, and trust chain policies for remote connections.
• Rate-limit and monitor: plan traffic controls and IDS/IPS rules to detect abnormal reads or floods from analytics clients.

Acceptance criteria: network diagram updated, firewall rules documented, and a test read performed with security logging enabled.

Timestamp synchronization & timezone handling

• Confirm time sources: ensure PLCs/edge devices use reliable NTP/PTP sources and document their sync intervals.
• Standardize time representation: store all telemetry with UTC timestamps and include the device-local timezone where relevant.
• Define acceptable clock drift: set and document a maximum allowable skew (for example, X seconds) and a remediation process when drift exceeds it.
• Handle out-of-order and late arrivals: specify business rules for late events (e.g., accept, backfill, or flag) and how to backfill in analytics.

Acceptance criteria: sample time-aligned dataset shows expected event order across a 24-hour test period.

Sensor naming, metadata & asset model

• Adopt a consistent tag naming convention: document a canonical pattern that encodes plant, area, unit, asset, and signal type (examples provided in your org's template).
• Define required metadata fields: e.g., asset ID, process role, units, engineering range, quality flag, acquisition method, maintenance tags, and owner/team.
• Map to asset hierarchy: ensure tags map to a single asset/asset tree (site → line → machine → sensor) to support rollups and KPIs.
• Record units and conversions: store native units and a canonical analytics unit with conversion factors when needed.

Acceptance criteria: metadata repository exists and a sample of 100 tags is complete and validated by operations.

Sampling vs event-driven ingestion

• Choose ingestion pattern per signal: document whether each tag will be polled (sampled) or pushed on event change and why.
• Set sampling frequency with purpose: justify frequency by use case (e.g., control loop tuning vs long-term trend) and estimate data volume.
• Define change thresholds for events: for event ingestion, specify delta thresholds and debounce rules to avoid floods from noisy signals.
• Plan aggregation strategy: decide where to aggregate (edge or cloud) and which rollups are needed (min/max/avg/count) for BI.

Acceptance criteria: sampling frequency table created and data volume estimate validated against a pilot stream.

Data compression, storage & retention

• Define raw vs curated storage: where raw telemetry lands vs where time-series is cleaned and enriched for BI.
• Set retention policies by data type and regulatory needs: e.g., raw high-frequency data for 90 days, aggregated hourly for 2 years.
• Choose compression/format for analytics: recommend columnar/time-series-friendly formats (e.g., Parquet, Influx/TSDB) and partitioning strategy.
• Plan purge/archive processes and ensure they meet compliance and business analysis needs.

Acceptance criteria: retention policy documented and sample query performance validated on a typical dataset.

Edge vs cloud processing decisions

• Decide processing location by use case: keep latency-sensitive transformations or safety checks at the edge; send batch enrichment to cloud.
• Define what is pre-processed at edge (e.g., filtering, compression, anonymization) and what must be raw in the cloud.
• Plan for intermittent connectivity: implement buffering, backpressure handling, and deterministic reconciliation for missing windows.

Acceptance criteria: decision matrix exists and a simulated outage shows correct buffering and replay behavior.

Safety & fail-safe design

• Enforce read-only analytics connections to controllers unless a validated, documented write path is required and authorized.
• Separate command/control from analytics: never allow BI systems to issue control commands except through formally reviewed, authenticated paths.
• Implement safety guards: rate limits, approval workflows, and manual overrides for any write-capable integration.
• Design for failure: ensure BI failures do not cascade back to OT (circuit breakers, timeouts, and watchdogs).

Acceptance criteria: security review completed and a fail-open/closed test performed without affecting control loops.

Charting, visualization & operational usability

• Design visuals for operators: prefer familiar terminology, asset context, annotation of events, and time-range quick-views (last 15m, 1h, 24h).
• Include data quality indicators: show signal quality flags, stale data warnings, and recent reconnection timestamps on dashboards.
• Support diagnostic views: provide raw-signal timeline, downsampled trend, and aggregated KPIs for the same asset on one view.
• Confirm role-based access: operators, engineers, managers should see appropriate summaries and underlying detail as needed.

Acceptance criteria: prototype dashboard validated by an operator and a data analyst for clarity and usefulness.

Testing, validation & runbook

• Run a pilot ingestion for a representative subset of tags and validate timestamps, units, and event ordering against ground truth.
• Create data quality checks: completeness, freshness, range checks, and cardinality alerts with actionable owners.
• Document a runbook: include escalation paths, known limitations, scheduled maintenance, and who to call when data anomalies occur.

Acceptance criteria: pilot signed off and automated quality checks reporting zero critical issues for a defined test window.

Handover & continuous improvement

• Assign owners for tags, pipelines, dashboards, and data quality rules; include contact info and SLAs for incident response.
• Schedule regular reviews: cadence for reviewing retention, sampling frequencies, and dashboard relevance (e.g., quarterly).
• Plan for feedback: add an operations feedback loop to evolve tag metadata, visualizations, and alert thresholds.

Suggested artifacts to attach

• Network diagram showing OT/IT zones and DMZs.
• Tag list CSV with required metadata columns.
• Sampling frequency and data volume estimate spreadsheet.
• Pilot test results and data quality reports.

Quick checklist summary (for task tracking)

• Owner assigned and contact recorded
• Network & security controls documented
• Time sync validated and UTC canonicalization in place
• Metadata complete and asset model mapped
• Ingestion pattern chosen and volumes estimated
• Retention & storage strategy defined
• Edge/cloud responsibilities decided and tested
• Safety/write controls enforced
• Dashboards prototyped and validated by users
• Pilot validated and runbook published

Next steps (implementation ideas)

Convert this checklist into an interactive form to capture sign-offs, attach artifacts, and store evidence (use CapabilityIDs 1 & 2). Package the checklist and its artifacts as a reusable toolkit for other plants (CapabilityID 3).