Collecting data from multiple remote sites or aggregating, as it is generally referred to, is a big part of geographically distributed control operations. Having a macro picture of your operations over all of your locations is key.
And efficient, reliable performance is always a concern. This blog post will discuss performance as it relates to aggregating data from multiple remote sites using a tunneler solution and why it's important for tunneler solutions to support multiple tunnel connections in the same instance.
Similar to situations where having the ability to control data update rates that OPC clients are requesting can help maximize performance with OPC tunneling, the ability to aggregate data can also greatly improve performance and lower paid data usage (in telemetry situations).
Imagine if you have ten OPC client applications that need the same data from your control OPC servers. Do you want those clients to make one connection to each OPC server, or would you prefer they connect to a central aggregation point? Tunnelers that offer built-in aggregation functionality will save you significant bandwidth by minimizing the overhead required to collect the same data.
Currently in the process of choosing a tunneling solution? Learn more about aggregation and performance considerations and other variables in our free whitepaper "25 Considerations when choosing a tunneling solution".
There are a few scenarios where this is beneficial. It's pretty common for there to be many OPC Server computers in a network architecture with a single OPC Client needing to access them. With a tunneling solution, a tunneler component exists on each of the OPC Server computers and tunnel their source data back to a single tunneler component on the OPC Client computer in that scenario (assuming the tunneler solution supports aggregation and a many-to-one scenario).
Alternately, it's also possible to have one OPC Server computer that you need to share with multiple remote OPC Client computers. In that scenario, you would need to have a tunneler component on the OPC Server computer and a tunneler component on each of the remote OPC Client computers.
How efficient the tunneling solution is in either scenario then ultimately depends on the method of transfer used by the tunneling solution: generally either the actual OPC calls themselves or raw data packets. One of those options is inherently more efficient and will perform faster.
With tunneling solutions that simply tunnel OPC calls, it is still required to make multiple OPC connections, which limits the savings on bandwidth that we mentioned earlier. It's not much more efficient than a straight DCOM connection, at that point.
However, with tunneling solutions that tunnel raw data packets and not OPC calls, the bandwidth savings and performance improvement is substantial. Raw data packets ultimately take up far less bandwidth than packets containing entire OPC calls. So the data transfer is faster and more reliable (and cheaper if you're on a telemetry system over radio or cellular).
Performance and the ability to effectively and efficiently share data across your distributed operations is important in most industries for running an enterprise as a whole. When considering tunneling solutions for transferring that data between your various systems, make sure to consider your overall architecture and ask the tunneling solution vendor if they support aggregation and what method is actually being used for the data transfer on the wire.
Aggregation and performance are just a few of the many considerations when choosing a tunneler - learn about the other variables you should be considering in the free whitepaper “25 Considerations when choosing a tunneling solution”.
