Over the last ten years OPC has become the de facto standard for open communication between SCADA systems and field devices.
The first versions of the OPC standards are based on the DCOM architecture defined by Microsoft. These standards are limited to Microsoft Windows® operating systems because of the use of the DCOM architecture. Only a few implementations based on other operating systems exist, like Technosoftware AG solutions.
With the .NET initiative, Microsoft is now promoting another distributed architecture beside DCOM: the web services environment based on XML and W3C protocols. In a similar move, OPC is also specifying XML based communication.
The OPC Foundation also released a first version of a “unified architecture” specification that will now be totally interoperable with full internet connectivity and unlimited scalability across platforms of the end-users choice.
Most of the upcoming implementations are based on Microsoft Windows and the .NET architecture. At least for servers based on the new specifications this results in large and complex environments required by Microsoft OSs to run web services (.NET framework and IIS web server). But also for clients the .NET framework is still required. Implementing OPC clients or servers for these new specifications is complex and using well proven and tested developer tools can speed up development and ensure compliance with these specifications.
OPC Specifications
The OPC Foundation released several specifications in the last 10 years starting from OPC Data Access up to the new OPC Unified Architecture specification. Below just the specifications are mentioned which are covered by the OPC Developer Studio .NET.
Data Access (DA)
An OPC DA Server allows OPC DA Clients to retrieve information about several objects: the server, the group and the items.
- The OPC server object maintains information about the server and acts as a container for OPC group objects.
- The OPC group object maintains information about itself and provides the mechanism for containing and logically organizing OPC items.
- The OPC items represent connections to data sources within the server.
The OPC DA Specification defines two read/write interfaces:
- Synchronous
The client can perform a synchronous read from cache (simple and reasonably efficient). This may be appropriate for fairly simple clients that are reading relatively small amounts of data. - Asynchronous
The client can ‘subscribe’ to cached data using IAdviseSink or IOPCDataCallback which is more complex but very efficient. Asynchronous access is recommended because it minimizes the use of CPU and NETWORK resources.
In all cases the OPC DA Server gives the client access to current values of the OPC items. The OPC DA Server only holds current information in cache. Old information is overwritten. As a result of this it cannot be guaranteed that an OPC DA Client retrieves all changes in values (also not in asynchronous mode).
For such cases there exist two more OPC specifications, the OPC Alarms&Events and the OPC Historical Data Access Specification.
Alarms&Events (AE)
The OPC AE interface provides a mechanism for OPC AE clients to be notified when a specified event and/or alarm condition occurs. The browser interface also allows OPC AE clients to determine the list of events and conditions supported by an OPC AE Server as well as to get their current status.
Within OPC, an alarm is an abnormal condition and is thus a special case of a condition. A condition is a named state of the OPC Event Server or of one of its contained objects that is of interest to an OPC AE client. For example, the tag Temperature may have the following conditions associated with it: HighAlarm, HighHighAlarm, Normal, LowAlarm, and LowLowAlarm.
On the other hand, an event is a detectable occurrence that is of significance to the OPC Server, the device it represents, and its OPC AE clients. An event may or may not be associated with a condition. For example, the transition into HighAlarm and Normal conditions are events, which are associated with conditions. However, operator actions, system configuration changes, and system errors are examples of events, which are not related to specific conditions. OPC AE clients may subscribe to be notified of the occurrence of specified events.
The OPC AE specification provides methods enabling the OPC AE client to:
- Determine the types of events that are supported by the OPC AE server.
- Enter subscriptions to specified events so that OPC AE clients can receive notifications of their occurrences. Filters may be used to define a subset of desired events.
- Access and manipulate conditions implemented by the OPC AE server.
Historical Data Access (HDA)
Historical engines today produce an added source of information that should be distributed to users and software clients that are interested in this information. Currently most historical systems use their own proprietary interfaces for dissemination of data. There is no capability to augment or use existing historical solutions with other capabilities in a plug-n-play environment. This requires the developer to recreate the same infrastructure for their products, as all other vendors have had to develop independently with no interoperability with any other systems.
In keeping with the desire to integrate data at all levels of business, historical information can be considered to be another type of data.
There are several types of Historian servers. Some key types supported by the HDA specification are:
- Simple Trend data servers.
These servers provided little else then simple raw data storage. (Data would typically be the types of data available from an OPC Data Access server, usually provided in the form of a duple [Time Value & Quality]) - Complex data compression and analysis servers.
These servers provide data compression as well as raw data storage. They are capable of providing summary data or data analysis functions, such as average values, minimums and maximums etc. They can support data updates and history of the updates. They can support storage of annotations along with the actual historical data storage.
XML-DA
The OPC Foundation has defined interfaces to Data Access Servers, Event Servers, Batch Servers, and History Data Access Servers. These servers have information that is valuable to the enterprise, and is currently being provided to enterprise applications via OLE/COM based interfaces.
XML, the eXtensible Markup Language, and XML-based schema languages provide another means to describe and exchange structured information between collaborating applications. XML is a technology that is more readily available across a wide range of platforms. OPC XML-Data Access (OPC XML-DA) is the OPC Foundation’s adoption of the XML set of technologies to facilitate the exchange of plant data across the internet, and upwards into the enterprise domain.
The purpose of this specification is to continue OPC’s goal of enabling and promoting interoperability of applications. The OPC XML-DA based interfaces simplify sharing and exchanging of data amongst the various levels of a plant hierarchy (from low level devices up to enterprise systems) and to a wider range of platforms. The goal for this specification is to provide:
- Support for OPC Data Access 2.0x/3.0 data
- Support for HTTP, and SOAP
- Support for Subscription based services
- Support for a Security approach