In OPC “Classic” (COM-based) specifications, such as OPC Data Access or OPC Alarms and Events, there is little or nothing specified about the times the OPC servers should use, and the timestamps that come with the OPC data. Specifically, there is no requirement that the OPC servers must have proper and synchronized time.

This becomes an issue when your application starts combining data from multiple OPC servers, and even more if they run on different computers. Unless you can guarantee their time synchronization by some application-specific means, you must assume that their times might be out of sync. Events that come in sequence from different servers may have their timestamps in decreasing order instead.

The OPC Unified Architecture specification has given more though to time, and (with some simplification), we may say that it requires the times be synchronized on both sides of the communication (between the OPC server and the OPC client), although it does not provide a mechanism to do, and again relies on external means to achieve.

The OPC-UA requirements consequently mean that if the OPC client (such as your application with StreamInsight Extensions for QuickOPC) communicates with multiple OPC servers, all their times should be synchronized. In reality, however, not all systems will be set according to OPC specifications, and adding to that, the synchronization required by OPC-UA is not precise, and there may be several seconds’ difference between the times on various computers. In StreamInsight, however, the time monotony requirement is a strict one – you cannot go back in time even by a fraction of a second.