Yes—Cogent DataHub can bridge live data between two different SCADA systems when both systems provide compatible interfaces and the deployed configuration supports the required connections. That connects selected data, not the complete SCADA applications: you still need to define tag mappings, write permissions, data-quality handling, and recovery behavior before using the bridge in production.
TL;DR
A live connection is not proof that two SCADA systems interpret data identically. A destination can display a changing value while using the wrong engineering units, showing an old timestamp, or failing to distinguish a healthy source from a disconnected one.
For a 2026 integration project, define the data contract before configuring the connection. Software Toolbox provides industrial connectivity and DataOps software; your architecture should identify the specific interface and deployment requirements before selecting the configuration.
The practical distinction is between sharing operational information and transferring control authority. A read-only production overview and a writable cross-system command path need different acceptance criteria, even when they use the same tags.
Yes, provided the connection interfaces and configuration support the intended data exchange. Different SCADA brands are not, by themselves, the deciding factor. The deciding factors are the interfaces each application exposes, the access each interface permits, and how the destination consumes the data.
Use this table to select the integration pattern before defining individual connections. These are architecture choices, not separate product editions.
One-way data sharing
Bidirectional data exchange
Selected-tag exchange
The bridge belongs between defined endpoints. It does not make separate alarm databases, historical archives, security models, graphics, or application logic equivalent. Treat each of those requirements as a separate integration question.
For example, sharing a process value does not establish that an alarm acknowledgment in one SCADA application will acknowledge the corresponding alarm in the other. That behavior needs an explicit supported interface and its own test.
Choose one-way sharing when one SCADA system needs visibility into values owned by another. Examples include a plant overview, a migration dashboard, or a supervisory display that must not issue commands to the source system.
Start with a bounded namespace. For each shared value, record the source identifier, destination identifier, data type, engineering units, quality interpretation, and expected timestamp meaning. A tag name alone is not a data contract.
Keep the destination read-only unless a documented requirement demands otherwise. This reduces the scope of command-related testing, but it does not eliminate the need to test stale values, bad quality, or communication loss.
The limitation is straightforward: visibility is not control. If an operator must change a source setpoint from the destination SCADA system, the architecture has moved beyond one-way monitoring and needs a separate write-path design.
Use bidirectional exchange only where the operating requirement includes a return path. Define which application owns each writable value and what the receiving system must confirm before the operator treats a command as complete.
Specify 1 authoritative writer per shared command as a design rule. If multiple applications need permission to request a change, define arbitration rather than allowing competing writes to determine the result.
Data exchange in 2 directions does not require every tag to be writable in both directions. Separate process feedback, command requests, acknowledgments, and permissives so that each has a clear purpose.
The benefit is controlled interaction between systems. The cost is additional engineering: write authorization, feedback handling, rejected-command behavior, and recovery all need testing. Do not use a mirrored value as proof that field equipment executed a command.
Use the following sequence for a 2026 commissioning plan. Each step should produce a reviewable configuration decision or a test result, rather than an assumption about how the applications behave.
A useful handover package includes the mapping register, network-flow description, access model, and test evidence. Another engineer should be able to explain what crosses the boundary without reconstructing it from a running system.
Define ownership and security before testing connection recovery.
A successful connection answers only whether endpoints can communicate. The following factors determine whether the exchange meets your operating requirements:
For a 2026 acceptance review, attach evidence to each requirement. Avoid describing a system as “real-time” unless the project defines the relevant timing requirement and demonstrates that the complete path meets it.
Review the bridge as a new path between trust zones, not merely as another application connection. Document where each endpoint resides, which side initiates each connection, and which identities receive access.
OPC UA supports application authentication and message-security mechanisms, but those capabilities do not establish that a particular deployment uses the intended policies. Review the actual endpoint configuration, certificate trust, and user authorization.
A DMZ is an architecture boundary, not a substitute for an access policy. Define which data crosses it and whether any permitted flow can carry commands toward the control environment.
Use separate access decisions for reading and writing. A reporting consumer should not receive command authority simply because the connection mechanism supports it. Include account changes, certificate renewal, logging, and configuration backup in the operating responsibilities.
Do not approve the bridge solely because values are visible on the destination screen. Approval should cover the permitted flow, the identities involved, the failure behavior, and the ability to diagnose unauthorized or unsuccessful activity.
Test the complete path from a known source change to the destination behavior. Observing traffic at an intermediate point does not prove that the receiving SCADA application accepted or interpreted the update correctly.
Build the test around the intended operating use:
For your 2026 test record, separate observed results from required limits. Do not substitute a generic product claim for measurements taken on the deployed network and application path.
Retain the configuration used for the test. Otherwise, a later mapping, security, or application change can invalidate the evidence without an obvious change to the operator display.
Live data exchange does not establish deterministic control. A changing display demonstrates information movement; it does not prove a bounded end-to-end response suitable for a control requirement.
Keep timing-critical control responsibilities within an architecture designed and validated for them. Evaluate supervisory commands separately from closed-loop control, and do not move a control dependency across the bridge merely because communication is available.
A data bridge can support integration without replacing both SCADA applications, provided the existing applications expose suitable interfaces. The engineering task is to define and maintain the shared data contract while preserving each application's responsibilities.
That approach also preserves differences. Operators can still encounter different alarm handling, display conventions, security roles, and historical records. During a migration, document which system remains authoritative for each operational function.
Software Toolbox is suited to industrial teams evaluating SCADA connectivity and DataOps software. Its stated offering includes Cogent DataHub alongside industrial connectivity and DataOps products.
Use the architecture specification to frame the evaluation: identify both SCADA endpoints, required read and write paths, network zones, and acceptance tests. Product selection should follow those requirements rather than substitute for them.
The boundary matters. Selecting an integration product does not resolve command ownership, operating procedures, or cybersecurity approval. Those remain project decisions that need named owners and documented evidence.
Can Cogent DataHub bridge two SCADA systems from different vendors?
Yes, when both SCADA systems expose compatible interfaces and the deployed Cogent DataHub configuration supports the required connections. Confirm endpoint access, tag mapping, and destination behavior before production use.
Can both SCADA systems write through the bridge?
Bidirectional writes require supported writable interfaces and explicit configuration; a working read path does not establish write access. Define command ownership, authorization, acknowledgments, and failure handling before enabling writes.
Does bridging SCADA values also synchronize alarms and historical records?
Sharing live values does not establish synchronization of alarm databases or historical archives. Treat alarm events, acknowledgments, and historical records as separate interface requirements.
Will the destination know when the source connection fails?
The destination's response depends on the configured quality and communication-status handling. Test source disconnection and confirm that stale values cannot be mistaken for healthy live data.
Does a live SCADA bridge guarantee a specific response time?
A live SCADA bridge does not establish a guaranteed end-to-end response time. Define the required timing behavior and measure the complete deployed path, including source and destination processing.
What should I test before enabling cross-system commands?
Test accepted commands, rejected commands, lost connections, restarts, and destination feedback before enabling cross-system commands. Confirm that each command has an authoritative owner and that ambiguous outcomes are visible to operators.
Do I need to replace a SCADA platform to share its data?
A suitable exposed interface can allow data sharing without replacing the SCADA platform. Separate the shared data requirement from application-specific functions such as graphics, alarms, and security roles.
The most revealing bridge test is not a value changing successfully. It is the destination losing contact with the source while an operator is watching.
For a 2026 deployment, make that failure demonstration part of acceptance. The operator should be able to distinguish a stopped process from a stopped data connection. That distinction is a stronger foundation for the Software Toolbox evaluation than a demonstration that only shows the normal data path.