Acceptance of industrial real-time data integration is not just about connecting a protocol. It covers the complete path from PLC, SCADA, MES, or IoT sources through acquisition, transport, buffering, cleaning, and semantic mapping to the business application. For critical points, verify identifiers and units, timestamps, quality states, end-to-end timeliness, replay after disconnection, permission audits, and recovery records. Agree on frequency, delay, capacity, and recovery targets in writing based on site conditions and business consequences.
This guide focuses on real-time or near-real-time data paths on the industrial side. If the project is still inventorying general sources such as Excel, databases, APIs, and device platforms, start with how to connect data for enterprise dashboards. Industrial projects should also include permissions, audits, and endpoint boundaries in dashboard security acceptance.
A typical path is: field instrument or device → PLC / RTU → edge gateway or SCADA → message broker, industrial data platform, or integration service → storage and metric service → API / WebSocket → dashboard, business system, or digital twin interface. MES and IoT platforms may sit in the middle, or act as business sources or consumers. The actual topology depends on existing systems and network segmentation.
ISA's official introduction to ISA-95 provides a general layered view of enterprise and control-system integration. It can help clarify the responsibilities of PLCs, SCADA, MES, ERP, and analytical applications, but its layers should not be copied mechanically in place of investigating the site architecture.
| Path segment | What to confirm | Acceptance evidence to retain |
|---|---|---|
| Field and control layer | Device models, point addresses, ranges, units, read/write attributes, quality codes, and sampling capabilities | Point list, device or driver documentation, and comparison of field values with read values |
| Gateway and acquisition layer | Protocol, polling or subscription strategy, timestamp source, offline queue, reconnection, and replay | Configuration exports, runtime logs, and disconnection and recovery test records |
| Platform and storage layer | Message persistence, deduplication, ordering, data models, quality rules, retention, and archiving | Sample messages, table schema or topic inventory, and exception-handling records |
| Application and display layer | Metric definitions, API refresh, caching, alert states, permissions, and degraded-page behavior | API logs, comparison of page and source values, and negative permission tests |
They often sit at different points in the path and are not interchangeable peers. A project might read device registers over Modbus, publish from the gateway to a platform over MQTT, and push from the platform to a browser over WebSocket. Alternatively, an OPC UA client might subscribe to variables exposed by SCADA or a device server.
| Technology | Best-suited problem | Acceptance focus |
|---|---|---|
| OPC UA | Industrial interoperability, information models, reads and writes, subscriptions, events, and controlled access | Node namespaces, data types, read/write permissions, sampling and publishing parameters, source timestamps, quality states, certificates, and sessions |
| Modbus | Access to coils, discrete inputs, and registers by function code and address, commonly on the device or gateway side | Device point list, station ID, address offsets, byte order, data types, scaling, polling intervals, exception codes, and connection recovery |
| MQTT | Publish and subscribe to telemetry or events through a broker, decoupling multiple producers and consumers | Topics, payload schema, QoS, sessions and retained messages, persistence, backlog, permissions, duplicates, and consumer acknowledgments |
| WebSocket | A persistent bidirectional connection between browser and server, suitable for pushing messages to a page | Authentication, heartbeats, disconnection detection, retry backoff, gap recovery, message versions, backpressure, and fallback behavior |
OPC Foundation's OPC UA overview describes information modeling, access, subscriptions, events, and security. Sampling intervals describe how frequently a server samples a source; they are not the same as end-to-end delay on a page. Check the SamplingInterval definition in the OPC UA specification against the actual product implementation.
Modbus Organization's specification catalog provides materials on the application protocol and TCP message implementation. Modbus does not automatically define a device's addresses, data types, scaling, or units, so a vendor point list and on-site checks remain prerequisites.
OASIS MQTT 5.0 specification defines publish-subscribe and QoS behavior. QoS 0 may lose messages; QoS 1 may deliver duplicates; QoS 2 constrains delivery within the protocol session. None replaces consumer idempotency or recovery design across the full data path.IETF RFC 6455 defines the WebSocket protocol, while application-level reconnection, history recovery, deduplication, and message semantics remain system responsibilities.
Collection frequency answers “How often is a value generated or read at the source?” End-to-end delay answers “How soon is a change visible in the target application?” Between them lie gateway polling, subscription and publication, network queues, platform processing, database writes, API caches, and page rendering. A page-refresh animation alone does not prove fresh source data.
Production, automation, IT, security, and application owners should agree on targets for each use case. A trend dashboard, shift operations, fault alarms, and closed-loop control have different consequences and cannot share one universal “real-time” number.
A recovered network does not mean all data has returned. First agree whether records during an outage will be dropped, buffered at the edge, or fetched from the platform; what happens when storage fills; and whether replay keeps original order or prioritizes the newest values. Distinguish live data from history replay. Each record should ideally include a traceable point ID, source timestamp, sequence or unique key, and quality state. The consumer can then deduplicate according to business rules.
A record may contain device-event time, gateway-collection time, platform-receipt time, and database-write time. Choose which drives trends and alerts, and use the others for diagnostics. Standardize time zone, daylight-saving handling, precision, and format. Depending on the site, clocks may be synchronized through NTP, PTP, or an existing time service. Record clock sources, drift monitoring, and handling of lost synchronization.
At a minimum, the application should distinguish valid, invalid, offline, out-of-range, manually substituted, and unknown-source data. Missing values should not simply become zero. The Chinese national-standard catalog's GB/T 36344-2018, Information Technology—Data Quality Evaluation Indicators can inform quality dimensions; project-specific fields, rules, thresholds, and ownership still require agreement.
| Quality issue | What to define | Verifiable evidence |
|---|---|---|
| Missing records | Which points should arrive periodically, and how gaps are identified for event-driven points | Reconciliation of expected and actual records, plus a gap list |
| Outliers | Physical limits, business limits, rates of change, and exceptional cases | Out-of-range samples, rule versions, and handling logs |
| Duplicates and out-of-order data | Unique keys, sequence rules, late-arrival windows, and overwrite policy | Stored and displayed results after injecting duplicates and out-of-order messages |
| Inconsistent time | Timestamp sources, time zones, synchronization method, and allowable deviation | Cross-layer timestamps for one event and clock-status records |
| Semantic errors | Units, scaling, decimal places, enumerations, and device hierarchy | Point dictionary and comparison of field instruments with application values |
Dashboards, management views, and digital twin displays should default to read-only monitoring. A protocol's ability to write does not mean the application should have write privileges. Writable objects such as coils and holding registers, or OPC UA writes and method calls, require approval from device, process, and safety owners.
If the business truly requires reverse control, assess and accept it separately: command allowlists, identity and least privilege, network zones and channels, action confirmation, prerequisite checks, timeouts and cancellation, complete audits, behavior on communication failure, priority of local versus remote operation, and relationships with PLC, DCS, SIS, and other control or safety logic. A display system must not replace field safety interlocks or safety instrumented functions.
NIST SP 800-82 Rev. 3 discusses performance, reliability, and security constraints in operational technology environments. The official overview of the ISA/IEC 62443 series emphasizes lifecycle roles and security requirements for industrial automation and control systems. Use these frameworks to review network zones, assets, identity, remote access, logs, patches, and incident response, while selecting actual controls according to site risks and applicable requirements.
An acceptance table should state each metric's definition, test prerequisites, target, sampling method, evidence location, and owner. The following dimensions provide a structure, not universal thresholds.
| Acceptance dimension | Project definition and prerequisites | Test action | Decision rule and boundary | Evidence to retain |
|---|---|---|---|---|
| Point semantics | Point inventory, criticality, units, data types, and status codes have been approved | Sample critical points and compare each with source data, field values, and business meaning | A passing point count does not prove correct semantics; use the signed baseline and permitted deviations | Point list, comparison records, discrepancy register, and approvals |
| Timestamps and timeliness | Define event, acquisition, receipt, and storage times; record clocks and test load | Trigger a traceable event and compare times across layers under normal and high load | Set targets according to the business action, site network, and clock error | Original timestamps, monitoring charts, test scripts, and result snapshots |
| Quality and completeness | Define normal, offline, missing, out-of-range, and substituted values and valid operating windows | Inject or reproduce abnormal values; reconcile valid records, duplicates, out-of-order records, and late arrivals by period | Explain shutdowns, maintenance, and event-driven points separately; do not hide missing values as zero | Quality-code samples, reconciliation results, handling logs, and exception notes |
| Disconnection and replay | Agree on buffering scope, full-buffer strategy, reconnection order, deduplication, and backlog handling | Interrupt and restore the path in a safe window; compare live flow with history replay | Judge permitted loss, replay deadlines, and gap handling against the project's signed baseline | Outage record, path logs, before-and-after reconciliation, and gap list |
| Capacity and stability | Fix point count, message size, frequency, consumers, runtime, and resource environment | Apply sustained and burst loads, observing backlogs, errors, degraded operation, and recovery | Do not copy another project's thresholds; use agreed capacity and stable-operation goals | Load configuration, resource charts, error logs, and inspection records |
| Permissions and audits | Read and write rights, certificates, accounts, network zones, and control boundaries have been approved | Use test accounts to confirm unauthorized reads, expired credentials, and non-allowlisted writes are rejected | Tests must not affect production safety; the display system does not replace field interlocks | Test accounts, request records, rejection logs, and approvals |
| Backups and recovery | Define configurations, data, certificates, dependencies, recovery order, and owners | Restore the service from the agreed backup and verify configuration, data availability, and gaps | Set recovery targets and permitted manual steps according to project risk and operating conditions | Exercise records, validation results, dependency list, and improvements |
| Suitable | Not suitable, or requires separate assessment |
|---|---|
| Monitoring and analysis of equipment status, energy use, output, quality, and alarms | Closed-loop control or safety interlocks requiring deterministic hard real-time response |
| SCADA, MES, or IoT platforms supplying data to dashboards or business systems | Ownership of devices, rights to use data, or network-access authorization remains unclear |
| Acceptance of a data foundation for smart factories, campuses, energy projects, and digital twins | No point list or protocol materials, and unwillingness to validate at the site |
| Read-only monitoring, historical trends, and exception tracing on internal or privately deployed networks | Treating a display page as a replacement control system for PLC, DCS, or SIS |
| Projects that need clear handover, operations, reconnection, and data-quality ownership | One-off visual prototypes that do not promise a connection to real data |
If the goal is a unified view of factory operations, production, equipment, and energy, use the smart-factory dashboard solution to define business-level metrics. For interface and frontend implementation, review the scope of data-visualization dashboard development. For water quality, filtration, and pump or valve states, the water-treatment data and control-boundary page (Chinese) can help verify points, quality states, and read-only principles. For data-center cooling loops, use the liquid-cooling loop, equipment, and alarm page (Chinese) to organize temperature, pressure, flow, and equipment objects.Water and Energy Storage Integrated Monitoring Platform (Chinese) and the pages above illustrate object layers, monitoring metrics, and delivery approaches. They should not be read as undisclosed claims of completed client work.
You can begin with the API, sample-data, and integration preparation checklist (Chinese) for general API materials, then add this section's industrial protocols, points, and site boundaries. If interfaces are incomplete, a small number of real points may support a technical trial, but long-term simulated data cannot replace final integration acceptance.
They often occupy different positions in the path; there is no need to choose just one. OPC UA suits industrial interoperability with semantics, subscriptions, and security. Modbus often reads or writes device registers through function codes. MQTT publishes and subscribes to telemetry through a broker. WebSocket maintains a bidirectional browser-server connection. Combine them according to device support, data meaning, network zones, reliability, and security needs.
No. Timeliness targets follow business actions and risks, and source sampling, transport, processing, API push, and page refresh are distinct. Trend analysis, executive dashboards, fault alarms, and closed-loop control have different requirements. Agree on acceptance values in writing for the specific project.
No. Delivery semantics for one MQTT segment are not an end-to-end guarantee. QoS 2 constrains message delivery within the protocol session, but source collection, broker persistence, consumer processing, database writes, and replay need separate designs. End-to-end acceptance also checks unique keys, idempotency, acknowledgments, retries, backlogs, and fault recovery.
No. WebSocket provides bidirectional connection and message transport, not complete business-level recovery. The application must implement and test retry backoff, session restoration, gap detection, offline buffering, historical catch-up, deduplication, and ordering.
Some protocols and devices technically allow writes, but a display system should not receive control authority by default. Assess read-only monitoring and reverse control separately. If control is required, the owner's process, safety, and automation leads must specify isolation, authorization, interlocks, confirmation, audits, and failure handling. A dashboard cannot replace the PLC, DCS, or SIS field safety logic.
Distinguish device-event, gateway-collection, platform-receipt, and storage times. Then agree on time zones, precision, clock synchronization, missing values, and drift handling. Compare timestamps across layers using traceable events, and check out-of-order and late arrivals and cross-system time differences.
No. Internal networks and private deployment define a boundary, but project risks still require network segmentation, identity, least privilege, credentials and certificates, transport protection, audit logs, patches, backups and recovery, and controlled operations access. The project owner and security specialists should decide whether classified cybersecurity protection or industry-specific rules apply.
Discovery and validation can begin, but the full integration scope should not be promised immediately. First obtain device and system inventories, a point list, protocol materials, network conditions, sample messages, test accounts, and owners. Validate reading, timestamps, quality codes, exceptions, and permissions with a few real points before setting a plan and acceptance baseline.