Introduction to OPC

The underlying layer of the OPC Data Access (DA) specification is based on Microsoft's COM/DCOM technology, which enables inter-process communication in a variety of programming languages for the Windows operating system. In modern operating systems, processes are encapsulated to provide increased stability and security. COM provides a communication interface layer that allows local and remote procedure calls between processes. DCOM (Distributed COM) is the natural extension of COM to support communication among objects on networked computers

DCOM can achieve security transparency, making distributed applications secure without any security-specific coding or design in either the client or the component. This is because DCOM lets developers and administrators configure the security settings for each component. Just as Windows operating systems allow administrators to set Access Control Lists (ACLs) for files and directories, DCOM also stores ACLs for components. These ACLs indicate which users or groups of users have access to a component of a certain class.  For additional specifications on DCOM security, refer to the DCOM Technical Overview paper on the Microsoft TechNet website. 

OPC allows client and server applications to communicate with each other. OPC is designed to be an abstraction layer between industrial networks and proprietary PLC drivers. The OPC standard specifies the behavior that the interfaces are expected to provide to their clients; and the clients receive the data from the interfaces using standard function calls and methods. Consequently, as long as a computer analysis or data acquisition program contains an OPC client protocol, and an industrial device driver has an associated OPC interface, the program can communicate with the device. The specification also includes a protocol for working with data control systems and application databases, as well as online data access, alarm and event handling, and historical data access for all of these data sources.

The data access server has three divisions:

• Server − Contains all of the group objects
• Group − Maintains information about itself and contains and organizes the OPC items
• Item − Contains a unique identifier held within the group. The identifier acts as a reference for the individual data source, as well as value, quality, and timestamp information. The value is the data from the source. The quality status gives information about the device. The timestamp is the time that the data was retrieved.

An OPC application accesses all items through the OPC group rather than through the item itself. The group also contains a specific update rate for itself, which tells the server at what rate to make data changes available to the OPC client. A deadband specific for each group tells the server to reject values if they have changed by less than a specified deadband percentage.

The OPC server also provides alarm and event handling to clients. Within a server, an alarm is an abnormal condition of special significance to the client − a condition associated with the state of the server, a group or an item within the server. For example, if a data source value that represents the real-world temperature of a mixer drops below a certain temperature, the OPC server will send an alarm to the application, so that the application will properly handle the low temperature. Events are detectable occurrences that are important to the server and client, such as system errors, system configuration changes, and operator actions.

OPC also incorporates historical data access standards, which are a way to access the data stored by historical engines, including raw data storage servers and complex data storage and analysis servers. This feature of OPC allows interoperability of proprietary database systems.

The OPC Foundation’s stated design, goals, and motivation for industry standardization of control systems have enabled the implementation of high-channel-count systems that are efficient and highly scalable.

Client software developers and users of these applications have greater flexibility in implementing a solution that is tailored to their needs because data is organized into groups and the naming, or tagging, of data points is determined by the client software. Grouping is beneficial in dealing with large sets of data sources because it provides greater organization of the data as well as easy reference to similar sets of data. In an OPC application, a tag gives a unique identifier to an I/O point. Based on the OPC specification, the client or server software is responsible for naming tags. The software can programmatically name tags or specify that the user name tags. This flexibility is a significant factor in the ability of client software to provide solutions that are tailored for high-channel-count applications.

Client software also specifies the rate at which the server supplies new data to the client. Because the server is responsible for data publication, the client software does not need to perform time-consuming data polling, which frees up more time for analysis and data logging. Moreover, the client software instead becomes a reactive object that waits for new data to arrive. Therefore, the client becomes event-driven and handles large sets of data much more efficiently.  

The client also specifies deadbands on the server, which allows the client to determine which data is important and then disregard data that is insignificant. Deadband percentages reject values that do not change more than a certain percentage from the previous value recorded. By establishing moderate deadband values, the client receives only information about channels which the client deems essential. This prevents the client from being flooded with superfluous information. In this way, the client can monitor a much greater number of channels.

Because OPC is now an industry standard, client software can connect to almost every vendor device available. Client software now is compatible with many types of devices, so the software can be designed with large numbers and varieties of devices in mind. These are a few of the many OPC characteristics that give development software a huge advantage when you use OPC connectivity to implement high-channel-count application software.

LabVIEW allows developers to integrate with OPC systems. You can connect both OPC clients and servers to LabVIEW applications to share data. The primary component that allows LabVIEW to perform this action is the Shared Variable Engine (SVE). The SVE is installed as a service on the computer when LabVIEW is installed. Using a proprietary technology called the NI Publish-Subscribe Protocol (NI-PSP), the SVE manages shared variable updates. Once you deploy Shared Variables to the SVE, the SVE works as a separate process running on the computer. For example, regardless if LabVIEW or a VI runs, the SVE items will automatically be available after the computer restarts. Moreover, the SVE will continue to be accessible for updates at any time and continue to run until stopped. For more detailed information about network-published shared variables, refer to the NI Developer Zone article Buffered Network-Published Shared Variables: Components and Architecture.

^{Figure 1: The Shared Variable Engine Can Be Either an OPC Client or a Server}

For OPC, the SVE acts as the middleman between NI-PSP data items and other applications. You can configure I/O servers to be OPC clients. This functionality is included in the LabVIEW Datalogging and Supervisory Control (DSC) Module. You can configure the SVE as an OPC server to publish NI-PSP data items to the network so other OPC clients can interact with them.

The DSC Module provides OPC Client I/O servers for communicating with any server implementing the OPC Foundation OPC server interface.  This allows LabVIEW to communicate with any PLC that is interacting with an OPC Server. An OPC Client I/O server will list all available OPC servers that are installed and running on a local or network computer.  Figure 2 shows the relationship of the components involved in communication between LabVIEW and a PLC.

^{Figure 2: LabVIEW and the SVE Can Communicate with PLCs through OPC}

PLCs publish data to the network. An OPC Server program uses the PLC’s proprietary driver to create OPC tags for each physical I/O on the PLC. National Instruments provides an OPC Server solution with NI OPC Servers. NI OPC Servers contains a list of drivers for many of the industry’s PLCs. For a list of supported PLCs, refer to the NI Developer Zone article Supported Device & Driver Plug-in List for NI-OPC Server. The OPC Client I/O servers provided with the DSC Module can connect to each OPC tag using the OPC DA standard. You can configure the multiple OPC Client I/O servers in the SVE with different update rates, deadband percentages, and reconnect poll rates. The SVE provides a PSP URL for each OPC tag that other Shared Variables can bind to by enabling aliasing. Once you deploy the Shared Variables in the SVE and the Shared Variables receive values, LabVIEW can easily read and write to the Shared Variables using a VI.  

The SVE can act as an OPC server. However, the SVE as an OPC server should not be confused with NI OPC Servers, because the SVE does not contain essential proprietary PLC drivers. The SVE can take a network-published Shared Variable and create OPC tags that an OPC DA client can connect to. This allows LabVIEW VIs to easily communicate with other OPC client software.

^{Figure 3: The SVE as an OPC Server}

A common application for using the SVE as an OPC Server involves employing National Instruments Data Acquisition (DAQ) devices and an NI-DAQmx driver to set up a DAQmx Virtual Channel. This DAQmx Virtual Channel can then be referenced by an NI-PSP URL. Therefore, the SVE can bind a network-published Shared Variable to the values being read by the DAQ device. The SVE then uses OPC DA standards to create OPC tags for the Shared Variable. In this way, an OPC client can read and write to the DAQ device. For a step-by-step process on publishing a DAQ device I/O to an OPC client, refer to the NI Developer Zone article Using the LabVIEW Network-Published Shared Variable and OPC with NI-DAQmx.

• NI Developer Zone: How LabVIEW Uses I/O Servers
• NI Developer Zone: Connect LabVIEW to Any PLC Using LabVIEW