Connecting a Data Platform to an Existing SCADA: Reuse an API or Read the PLC?
Compare supervisory interfaces and direct equipment access by data coverage, timing, licensing, load and ownership. Verify gaps before adding another PLC connection.
On this page7 sections
Evaluate reuse first, but verify what is actually exposed
When a factory already has SCADA, first assess whether its authorized API or historian satisfies the new dashboard or management task. Reusing suitable fields, timing, quality indicators and support arrangements can avoid duplicate acquisition. If essential information is absent, evaluate alternatives with the automation owner and vendor. A separately developed application does not automatically need another PLC connection.
This comparison concerns monitoring and analysis. Equipment commands, interlocks and process changes require a separate decision about control ownership, permissions and safety.
Map what each layer retains
Draw the actual route: equipment or PLC, acquisition service, SCADA, historian or API, then the new platform. Omit layers that do not exist. For each layer, record its owner, field coverage, refresh and storage behavior, transformations and access conditions. A historical trend may contain aggregates while a current state exists only in the acquisition service.
- Do current values include source time and quality? How is a stopped update distinguished from an unchanged value?
- Are historical records raw samples, averages or maxima? Is the required period available?
- Are alarms separate events or calculated conditions? Are activation, return-to-normal and acknowledgment preserved?
- Is third-party API use licensed and documented, and is a test environment available?
Compare both paths against the same operating task
| Question | SCADA or historian interface | Additional device-side reading |
|---|---|---|
| Coverage | Reuse existing fields; verify omitted points, aggregation and state meanings. | May fill gaps, subject to accurate point lists, protocol support and authorization. |
| Timing and history | Check caching, aggregation, timestamps and historical query access. | Define acquisition, storage and reconnection behavior separately. |
| Operational impact | Assess API load, quotas and vendor support conditions. | Assess additional connections and reads with the site and vendor. |
| Maintenance | Track upstream schema and interface-version changes. | Maintain mappings after program, address or equipment changes. |
| Evidence owner | Interface provider confirms coverage, access and availability. | Control-system owner confirms the read path and testing conditions. |
Test data meaning as well as connectivity
Select representative analog values, discrete states, counters and alarm events actually needed by the use case. Compare site observations, the existing system and the new platform over an agreed period. Record units, scaling, timing, quality and exceptional behavior. Any multi-client load or query-limit test needs explicit authorization and a scope based on the existing system, not a universal polling interval.
The OPC Foundation overview describes permission-based access, subscriptions and events. The exact product and configuration determine which capabilities are implemented and exposed. Shared protocol support does not establish shared business semantics.
A small gap may justify a controlled mixed route
Hypothetical example: the existing SCADA exposes production states and counts, but excludes an auxiliary machine. Assess separate acquisition for that machine and use stable equipment IDs in the platform. Give each field a single responsible source so that the same production count is not accumulated from both paths.
Document source priority, switching conditions and maintenance ownership. An outage should not silently switch to a source with different timing or calculations while continuing to show “normal.” Make the active source and data quality visible. This example is a planning method, not a customer-project claim.
Preserve the chosen route as maintainable records
- Field-to-source mapping with version, effective date, units and timestamp rules.
- Account purposes, permissions and responsibility for licenses or certificates; do not distribute plaintext secrets.
- Approved load conditions, timeout and recovery evidence, and any unverified cases.
- Notification, regression and recovery procedures for interface or equipment changes.
Clearly marked samples can support page development before an API is ready, but a demonstration is not proof of live integration. Follow the OT security and reliability principles appropriate to the site. Hongshan can use the confirmed mapping to scope dashboard and interface development. For an earlier-stage inventory, see legacy equipment assessment.
Sources and applicability
This is not a vendor ranking. System versions, licenses, operating tasks and observed test results determine the route. NIST Rev.3 is referenced for principles, not as a compatibility or zero-downtime guarantee.
Sources checked on 15 October 2026. The implementation checklists are editorial recommendations, not a site inspection or a delivery commitment.