Every once in a while we get asked: “Can I store and forward my OPC data?” It seems like a reasonable question. I’m connecting an OPC server and client across a network, possibly with OPC UA, or more likely OPC DA—using DCOM or an OPC tunnelling product. In any case, should there be a network problem and the connection gets broken, I don’t want to lose any of my data. Why not store it, and forward it later when the connection is back up? A little understanding of the purpose of OPC, and how it works, though, should make it clear that this impossible. The answer to this question is effectively “No–not real-time data, anyway.”
Let’s look at the OPC DA scenario first, since this is where the question comes up most often. Put simply, you cannot store and forward OPC DA data. The OPC DA protocol is for live, real-time data. OPC DA clients need to know what is happening right now in the system. An OPC DA server does not maintain a history of past values, and an OPC DA client only works with the most recent value of an OPC tag.
Despite this reality, suppose some bright spark decided he wanted to go ahead and add store-and-forward capability to OPC DA. When the connection to the client breaks, somehow the OPC server would need to start storing values―and this raises questions. How would the client identify which items in the server need to replay past values? How would the server know how long to store the data? What should the server do if this limit is exceeded? There is no facility in OPC for the client to specify any of this information, and it could not be robustly specified at the server. Not all clients would have the same requirements.
Then, when the connection gets re-established, the OPC server would start sending those values to the OPC client. Here it runs into more trouble. How would the server know that this was the same client reconnecting? How long has the client been disconnected? Has the client configuration changed since the last connection and therefore the previous store-and-forward configuration is out of date? How quickly should the values get sent? Should the OPC server replicate the time gaps between value changes? Then it would never catch up to the present. Or should it send all the stored values in a sudden burst of changes?
But the biggest problem is that old values are, by definition, wrong – only the most recent value is correct. In a store-and-forward scenario the client would experience a series of changes that could manifest as wrong indications in an HMI, or worse, wrong control signals to a physical system. Would you really want a piece of equipment turning on and off repeatedly as the data history catches up on the client? That could be inefficient, damaging or dangerous. In practice, most OPC clients can only hold one value for any given tag, and only now matters. The client doesn’t need and can’t use a replay of historical data, it needs to know what’s happening this instant.
It is a fact of life that network connections drop occasionally. When this happens, the client should present the data with a Bad or Not Connected quality, or show a Last Known Value warning until the connection is restored. Once the connection is back the client should receive the current data values. Whatever happened in the meantime is unimportant or downright misleading.
The idea of store-and-forward makes perfect sense, though, for data logging, archiving, and historical data. This is where it is possible to maintain a complete record of everything that has taken place on the OPC server. Although OPC DA itself does not offer this capability, a user can add an OPC HDA server, or connect a database to the OPC DA server. The responsibility for store-and-forward is now in the hands of the historian, where it belongs.
Turning now to OPC UA, from a fundamental design perspective the store–and-forward story is actually pretty much the same as it was for OPC DA. Nothing has really changed for an OPC UA client – it still expects to receive the latest data possible. The only slight difference is that the OPC UA architecture integrates historical data access better than OPC Classic does. This makes it easier for OPC UA servers to support historical data, and for OPC UA clients to request historical information. But whether data storage or archiving abilities are built into the server or provided separately, the reality of real-time data communications is that a real-time client cannot handle data that has been stored and forwarded. Nor is that its purpose. There are other tools designed for that.
So, the answer to the question, “Can I store and forward my OPC data?” is two-fold. On the one hand, you can record your OPC data, and then store and forward it as archived data. But you cannot store and forward data in real time.