| An OPC Server is essentially the middleware that connects a field device to the HMI for the SCADA system. An OPC Server consists of two basic layers. The upper layer, or the OPC layer, is the common OPC interface running various OPC specifications—such as OPC Data Acquisition (DA), OPC Alarms and Events (A&E), OPC Historical Data Access (OPC HDA), and OPC XML—to connect to the application software that has an OPC Client built in. As for the lower layer, device manufacturers or third-party OPC Server package providers need to offer a communication interface (usually known as a fieldbus) in order to connect to a field device. |
| |
 |
| Push for tag installation |
|
|
| An Active OPC Server can generate tags and necessary information for target devices automatically, without requiring system integrators to specify IP addresses, I/O channels, and data formats one by one, or edit and import configuration text files. In this push-based architecture, a single click "pushes" the installation profile from the device itself to the OPC Server so that the user does not need to spend time searching the devices on the network or checking the user's manual for detailed address definitions. It takes users an average of 2.5 minutes to create tags using a traditional OPC Server, and 60% of that time is wasted on looking up details in a user's manual. By using Active OPC Server's push technology, users can generate all of the tags they need in seconds.
|
| |
 |
|
| |
|
| Push for device connection |
|
|
When using Ethernet and TCP/IP networks, the fact that remote field devices need to use fixed IP addresses (so that the OPC Server can connect to a target IP address), creating problems for both IP management and Internet connectivity. For example, mobile devices are generally assigned dynamic IP addresses because they are constantly moving, such as in hospital or factory floor applications. However, dynamic IP addresses make it incredibly difficult for an OPC Server to connect to the devices and locate a device on the Internet. Obtaining fixed addresses for your devices would be ideal but is often too costly.
Active OPC Server reverses this situation, acting as a Web server to provide access to remote devices regardless of their IP addresses. This push-based algorithm allows field devices to be located anywhere on the network, even if the IP address constantly changes, making the OPC to field device connection Internet/WAN and firewall friendly. Traditional OPC Servers, especially those used for data acquisition applications, are not capable of using this approach.
|
| |
 |
|
| |
|
Most Ethernet fieldbus protocols, as well as Modbus/TCP and similar proprietary protocols, designate "master" and "slave" devices in their setups. As the terminology suggests, slaves respond to queries from the master. However, an increase in the numbers of devices and channels can result in CPU overloading, more bandwidth being occupied, and longer response times when polling the entire loop cycle of devices. Using push technology for tag status updates can go a long way in solving this problem. Instead of polling and waiting for timeouts or responses from a traditional OPC Server, Active OPC Server simply waits for remote devices to send updates when an exception (such as change of status, or when a pre-defined threshold, limit, or schedule is reached) occurs. As a result, Active OPC Server reduces response time and CPU usage through push-based, event-driven, and periodic data updates.
Performance tests have revealed that using Active OPC Server and this "Push" architecture results in an I/O response time that is 7 times faster than other OPC Server packages (in a testing environment with 2,560 I/O channels). In a different test of network bandwidth usage, Active OPC Server and the field device caused an apparent 80% reduction in network traffic. The end result is that I/O access is more precise, and the cost of communicating with remote I/O devices is substantially lower, especially when the remote site has limited bandwidth (e.g., satellite, microwave, and cellular communication). At the same time, the CPU usage of the SCADA/HMI system is also reduced by 35% so that less maintenance effort and lower level hardware devices can be used.
|
 |
|
| |
|
