上QQ阅读APP看书，第一时间看更新

The data model and retrieving data in OPC Classic

The aims of the OPC Classic standard are as follows:

To structure the data on the server side in order to simplify the data gathering on the client side
To define the communication services and the standard mechanisms to exchange data

Basically, the OPC Classic standard works as follows:

The server manages all available data.
The server sends queries for the data coming from the devices on demand and updates an internal cache on a regular basis. The server initializes and manages a cache for each group of variables requested by an OPC client. The scan rate related to an OPC client group cannot be less than the scan rate used by the OPC server to gather the data from its devices to update its internal cache. It is a good idea to set the OPC client to carry out cache reads and set them to refresh at double the rate that the OPC server scans the devices.
Each piece of exchanged data has its value signed by its timestamp and marked with a quality.
Exchanging the data includes reading it, writing it, and automatically updating it when values change. The reading, or polling, is carried out by the OPC client, which sends queries for the data of a group on a regular basis. The writing stage can either be synchronous or asynchronous. The automatic updates, or the unsolicited data collection, use a request update rate that is provided by the OPC client. The OPC server for each update checks whether the absolute value of the cached value minus the current value is greater than the dead band specified by the client multiplied by the range that is configured for that variable. This can be written as follows:

IF absolute value of (last cached value -current value) > (PercentDeadband/100) * Range 
THEN cache is updated, and the client is notified through a callback mechanism

The information available from the OPC server is organized into groups of related items for efficiency. Servers can contain multiple groups of items. There are two different types of groups:

Public groups: Available for any client to access them
Local groups: Only accessible to the client that created them

Let's take a look at an example. In an OPC server that is connected to a MODBUS-capable PLC, we might configure a water-level group on the SCADA with the following five members:

setpoint (SP)
control output (CO)
process variable (PV)
Low-water alarm (LoAlarm)
High-water alarm (HiAlarm)

The SCADA could register the water-level group with all of these members. It could then read the current values for all five items, either at timed intervals or by exception, which is when their values change. The HMI could also have write access to the SP variable.

A significant advantage of OPC is that you do not have to deal with the control device's internal architecture directly. The software can deal with named items and groups of items instead of dealing with raw register numbers and data types. This also makes it easier to add or change control systems, when migrating from a proprietary protocol to an Ethernet-based protocol, for example, without altering the client applications. The following points provide some suggestions related to how to implement a data flow based on OPC Classic:

If possible, run the OPC Data Access (DA) client on the same Windows box as the OPC DA server to avoid the configuration and performance issues that are related to DCOM.
The OPC DA client can ask the OPC DA server for readings from either the device or the cache. Requests for readings directly from the device instead of the OPC cache should be limited to specific use cases where you need to have the current values related to very few signals. If you need to read a large number of tags on a regular basis, it is better to use cache readings.
To avoid overloading the communication channel and the OPC server, group the tags according to the dynamic of their related signals, setting a different polling time to each group. For instance, you could classify the signals according to their behavior in high, medium, and low dynamic signals and assign a different polling time to each of them. You might assign 5 seconds for the high dynamic signals, 30 seconds for the medium dynamic signals, and 60 seconds for the low dynamic signals. The OPC server will then create three different internal caches and refresh them accordingly. Putting all the tags together and configuring just one group for all of them would force you to assign it the lower polling time of five seconds. The OPC server would have to refresh all tags every five seconds, even if many tags would not change meaningfully in that time interval.
Configuring the OPC group to have unsolicited data readings would force the OPC server to invoke a callback if any of the tags configured in a group changes. The callback mechanism is not very efficient, especially when used with DCOM, where the OPC DA client does not run in the same Windows box as the OPC DA server. For this reason, it should be limited to situations in which you are interested in only a few signals with a low dynamic that don't change their values very frequently.