OPC Communication Interview Questions and Answers

Read the OPC Communication Interview Questions for your interview preparation.

OPC Communication Interview Questions

OPC

What is OPC?

OPC is the world’s most popular standards-based data-connectivity method. It is used to answer one of the automation industry’s biggest challenges: how to communicate between devices, controllers, and/or applications without getting caught up in the usual custom driver-based connectivity problems.

OPC is the interoperability standard for secure and reliable information exchange in industrial automation and the enterprise. The original OPC specification was developed in the mid-1990s by a group of automation industry vendors to standardize data exchange between software applications and industrial automation hardware devices.

The OPC specifications define an interface between clients and servers, and servers-to-servers, so system components like PLCs, HMIs and any OPC-aware device can share data without having to develop custom software device interface applications.

Why Is OPC Important?

The OPC standard brings plug-and-play connectivity to industrial automation. Before OPC, application vendors had to develop custom software for every third-party device and application that needed to be integrated into the automation system.

With OPC, you get open connectivity across products, independent of your hardware or software platform. OPC defines the standard way for sharing real-time data, historical data, and alarms & events, reducing your integration and total life cycle costs for system implementations.

What Are The OPC Technologies?

The two primary technologies that comprise the OPC standards are OPC Classic and OPC UA (Unified Architecture).

OPC Classic is the original architecture, first released in 1996, based on Microsoft Windows technology, using COM/DCOM (Distributed Component Object Model) which was the Microsoft standard for software application communication.

OPC UA integrates all the functionality of the existing OPC Classic specifications into a single service-oriented architecture, while adding new features to OPC, such as platform independence, complex information modeling, security, and reliability.

What Is OPC UA?

As the next-generation of OPC technology, OPC UA (Unified Architecture) is a major leap forward for secure, reliable and platform independent interoperability. OPC UA is designed for the transport of data and information from first-tier factory and process control devices through to the enterprise information system.

The OPC UA specification, first released in 2008, integrates all the functionality from the existing OPC Classic specifications into a single service-oriented architecture. It adds essential new features, such as platform independence, diagnostics, discovery, rendering of complex information models, security, and reliability. Additionally, OPC UA was released as an IEC Standard, IEC 62541 in October 2011.

OPC UA provides a single set of services for the OPC data models, such as Data Access, Alarms & Conditions, and Historical Access and can be implemented on non-Microsoft systems, including embedded devices.

OPC UA provides services for simple / complex information models of vendors and consortia to be “plugged in” to the address space of OPC UA. This information modeling feature allows generic software applications to browse, read, write and subscribe to a whole new world of information.

What Is OPC Classic?

The OPC Classic specifications are based on Microsoft Windows technology, using COM/DCOM (Distributed Component Object Model) for communication among software components in a distributed client-server network. The OPC Classic specifications provide separate specifications for exchanging process data, alarms and historical data.

The original OPC Classic specification is OPC DA (Data Access), which defines an interface between client and server applications to exchange process and manufacturing data. Other important OPC Classic specifications include OPC Alarms & Events (OPC AE) and OPC Historical Data Access (OPC HDA).

OPC Classic continues to be an integral part of the OPC technology portfolio. In 2010, OPC Classic was enhanced with the OPC .NET 4.0 specifications to adapt to the new technical innovations of the Microsoft platforms providing better connectivity, reliability, security and interoperability.

What Is The OPC Foundation?

The OPC Foundation is the world’s leading community for interoperability solutions developing and maintaining OPC specifications that deliver secure reliable interoperability.

The mission of the OPC Foundation is to:

• Provide an international infrastructure to facilitate users, vendors and consortia to cooperate together to develop standards for multivendor, multiplatform, secure and reliable interoperability in industrial automation
• Develop, maintain and bring to market the specifications for the OPC standards
• Certify member products

The OPC Foundation is dedicated to providing the best specifications, technology, and product certification.

Supplier members are provided a complete infrastructure to rapidly develop quality OPC certified products.

End-user members gain access to myriad of technical information and innovation to be able to successfully use the OPC technology and OPC products from the OPC Foundation community to easily be able to assemble complex complete automation system/solutions.

Also Read: Overview of OPC

Why OPC Succeeds where Custom Drivers Fail

The key to OPC’s success in creating truly vendor-independent communications is that OPC abstracts the Data Source (e.g., PLC) and Data Sink (e.g., HMI) implementation details from each side so data can be exchanged between them without requiring them to know anything about each other’s native communications protocol and internal data organization.

This is in sharp contrast to the custom driver approach of writing applications that, by definition, are required to natively communicate with both the Data Source and the Data Sink.

How OPC Communication works (Conceptual)

OPC can be represented as an “abstraction” layer that sits between the Data Source and the Data Sink, allowing them to exchange data without knowing anything about each other.

How OPC Works (Functional View)

The OPC “device abstraction” is realized by using two, specialized OPC components called an OPC Client and OPC Server. Each of which is described in a following section.

What’s important to note is that just because the Data Source and Data Sink can communicate with each other via OPC does not mean their respective native protocols are no longer necessary or have been replaced by OPC.

Instead, these native protocols and/or interfaces are still present, but only communicate with one of the two OPC components.

In turn, the OPC components exchange information amongst each other and the loop is closed. Data can travel from the Application to the Device without having one talk directly to the other.

Benefits of using OPC Connectivity

At first glance, trading a single Custom Driver for two OPC components (OPC Client and OPC Server) may not look like much of an improvement but as experience has shown, it is.

Following are some key benefits of using OPC:

1. An OPC enabled Application can freely communicate with any OPC-enabled Data Source visible to it on the network without the need for any driver software, specific to the Data Source.
2. OPC-enabled applications can communicate with as many OPC-enabled Data Sources as they need. There is no inherent OPC limitation on the number of connections made.
3. Today OPC is so common that there’s an OPC connector available for almost every modern and legacy device on the market. It’s easy to get started using OPC.
4. OPC-enabled Data Sources may be swapped out, exchanged, or upgraded without the need to update the drivers used by each application (Data Sink) communicating with the Data Source via OPC. Only the OPC Server for that Data Source needs to be kept current.
5. Users are free to choose the best-suited devices, controllers, and applications for their projects without worrying about which vendor each came from and whether they will communicate with each other… inter-communication is now assumed!

What Types of Data does OPC Support?

The most common types of Automation data transferred between devices, controllers, and applications break down into three broad categories:

• Real-time data
• Historical data
• Alarm & Event data

Each of the above also supports a wide range of value types. Some common examples of these data types are integer, floating point, string, date, and various array types to name a few.

OPC addresses the challenges of working with these different data categories by independently specifying how each one is to be transmitted via the OPC Client and OPC Server architecture.

The three OPC specifications corresponding to the three data categories are:

1. OPC Data Access Specification (OPC DA) – used to transport real-time data

2. OPC Historical Data Access Specification (OPC HDA) – used to transport historical data

3. OPC Alarms & Events Specification (OPC A&E) – used to transport alarming information

Do All OPC Connectors Support all OPC Specifications?

No. OPC connectors are not required to support all of the OPC specifications.

Historically, most common were OPC servers that supported real-time data followed by OPC HDA implementations. It is prudent to inquire what OPC specifications an OPC connector supports before choosing it for use in a project.

Does it Matter what OPC Specification an OPC Client or OPC Server Supports?

Yes, this is crucial. While all three OPC Specifications (OPC DA, OPC HDA,

OPC A&E) use the same underlying OPC Client/Server architecture to transfer the different data category types, both the OPC Client and OPC Server must support the same OPC specification to properly coordinate passing data between each other, and to work correctly with the Data Sink and Data Source respectively.

OPC Servers

What is an OPC Server?

An OPC Server is a software application, a “standardized” driver, specifically written to comply with one or more OPC specifications. The word “server” in

“OPC Server” does not refer to the type of computer being used but instead reflects its relationship with its OPC counterpart, the OPC Client.

What Do OPC Servers Do?

OPC Servers are connectors that may be thought of as translators between the OPC world and a Data Source’s native communication protocol or interface.

Since OPC is bi-directional, this means OPC Servers can both read-from and write-to a Data Source.

The OPC Client/OPC Server relationship is a Master/ Slave one which means one OPC Server will only transfer data to/from a Data Source if an OPC Client commands it to.

What Types of Data Sources (Devices) can OPC Servers Communicate With?

OPC Servers can communicate with virtually any Data Source whose output can be read or written to via electronic means.

A brief list of possible Data Sources includes: devices, PLCs, DCSs, RTUs, electronic scales, databases, historians, web-pages, and automatically updating CSV files.

To communicate with any of these devices requires only the use of an OPC Server that employs the appropriate native protocol or interface.

Once such an OPC Server is configured, any OPC enabled application (with permission) can begin communicating with the Data Source without concern for how the Data Source communicates natively.

Where can I Find an OPC Server for Device X?

While many vendors provide OPC Servers with their devices, controllers, and applications, there are many who do not.

MatrikonOPC is the world’s largest provider of high-quality, OPC connectors for hundreds of devices. A good place to start is on the MatrikonOPC Server website, or by calling MatrikonOPC directly.

How do OPC Servers Work?

While users do not need to know anything about the inner workings of OPC Servers to be able to use them, a conceptual understanding of what goes on under the hood helps shed light on why the quality and performance of different vendors’ OPC Servers vary greatly.

A conceptual view of the inner workings of an OPC Servers looks as follows:

• OPC Communications Module: This part of the OPC Server is responsible for properly communicating with a given OPC Client. Well written OPC Servers must be fully compliant with the OPC

Specification(s) they implement to ensure they properly communicate with OPC Clients. 

• Native Communications Module: The OPC Server should employ the most efficient method of communicating with the Data Source. In some cases this means connecting to the Data Source directly via its native protocol, while in other cases, this means communicating with the Data Source via its custom driver via an Application Programming

Interface (API). Typically, the more experience the OPC Server vendor has with the device, the better the OPC Server will utilize the device’s communications options. 

• Translation/Mapping Module: This is where all the “magic” in an OPC Server happens. This module is tasked with properly interpreting the arriving OPC requests from the OPC Client and in turning them into proper native requests that get sent to the Data Source and vice versa.

 If this is done efficiently, the OPC vendor can keep Data Source loading to a minimum while maximizing data throughput.

Can an OPC Server from one Vendor Communicate with OPC Clients from Other Vendors?

Yes, assuming both the OPC Client and OPC Server are compliant with the same OPC specifications, they should be capable of communicating with each other regardless of which vendor each OPC component came from.

Can OPC Servers Share Information with other OPC Servers?

OPC Servers do not communicate directly with each other; they are only designed to communicate with OPC Clients.

There are however, OPC utilities like the MatrikonOPC Data Manager, designed to specifically make this OPC Server-to-OPC Server communication trivial.

OPC Clients

What is an OPC Client?

An OPC client is software written to communicate with OPC connectors. It uses messaging defined by a specific OPC Foundation specification.

What does an OPC Client do?

Conceptually: OPC Clients represent a data-sink. They initiate and control communications with OPC Servers based on what the application they are embedded in requests of them.

OPC Clients translate a given application’s communication requests into an OPC equivalent request and send it to the appropriate OPC Server for processing.

In turn, when OPC data returns from the OPC Server, the OPC Client translates it back into the application’s native format so the application can properly work with the data.

Technically: OPC Clients are software modules used by an application to enable it to communicate with any compliant OPC Server visible to it on the network. Typically, OPC Clients are embedded in applications such as HMIs, trending packages, historians, and report writers to make them inherently OPC-enabled.

It is common to refer to the application with an OPC Client embedded in it as the “OPC Client” even though only the OPC implementation is the true OPC Client.

Can OPC Clients Simultaneously Communicate with Multiple Devices (OPC Servers)?

There are two parts to this answer:

1. First, Semantics: It’s important to remember that OPC Clients are by design only capable of communicating with OPC Servers, not the end devices or other data sources. This is necessary because OPC Clients must remain protocol independent, otherwise they would fall into the original device-driver trap of the past.

2. Yes, OPC Clients can communicate with multiple OPC Servers at the same time. Effectively, this means an OPC Client can read and write data to and from multiple data sources via their respective OPC Servers.

How does an OPC Client Work?

As with the OPC Server, the OPC Client can be conceptually broken down into three modules that include: the Application Communications Module,

Translation/Mapping Module, and OPC Communications Module. Each of whose functions are described below.

OPC Communication Module: While not as involved as the OPC Server (the OPC Server portion is more complicated ) it is still crucial for the OPC Client to behave correctly as it connects with an OPC Server, exchanges data with it, and disconnects without destabilizing the OPC Server.

Application Communications Module: The OPC Client is typically written to work within a specific application, so it relies on a few calls to the Application’s Programming Interface (API) to allow data to be passed from the application down to the OPC Server/Data-Source via the OPC Client.

It is also possible for a generic OPC Client to communicate with an application via a protocol rather an API if the application supports such a protocol.

(An example of this is the MatrikonOPC Client for ODBC which uses SQL statements over ODBC to communicate with a Relation Database application.)

Translation/Mapping Module: A key function of the OPC Client is to bi-directionally translate information as the application it represents requests data to be read-from or written-to the end device or Data-Source.

How many OPC Servers can an OPC Client connect to?

The short answer is—as many as it needs to. Within the OPC framework, there is no theoretical limit placed on how many OPC Servers an OPC Client can connect to.

Can OPC Clients communicate directly with other OPC Clients?

No. OPC Client-to-OPC Client communications are not defined in OPC. Only the OPC Client /OPC Server architecture is supported.

However, if an application is expected to provide OPC Data to other clients, it needs to have an OPC Server of its own. This OPC Server will then allow OPC Clients from other applications to use this application as an OPC Data Source.

Where is the OPC Client Installed?

OPC Clients are typically built into the applications that use them, such as

HMIs or historians for example. If for some reason the application at hand does not have a built in OPC Client, one may be available from the Application vendor or a third-party OPC vendor like MatrikonOPC.

An OPC Client external to the application would typically communicate with the application via one of its native protocols. In this case, the OPC Client would not even have to reside on the same computer as the application.

Can I run an OPC Server as a Windows service and what would be the benefits?

An OPC Server can execute as a Windows service. The benefit of this operation is the OPC Server will start with the Operating System. It will even take the identity of the Operating System which is desirable in some cases.

Some OPC Servers cannot execute as a Windows Service. This will either require a user to be logged on to the PC, or some other application to initiate the operation of the OPC Server.

Can I use my HMI software to tunnel OPC data between PCs?

Some people use an HMI or even their Historian to provide OPC Tunneling services.

However, in most cases, an OPC tunnel provides a far easier way to transfer data since the OPC tunnels are typically preconfigured for the specific task of transferring data rather than visualizing or storing it.

How can I acquire data from an OPC Server through a router?

OPC works seamlessly through most routers. However, any router that provides NAT (Network Address Translation) services will stop DCOM from working. This is because the OPC Server PC must be able to address the OPC Client PC directly.

In practice, most routers that are internal to a site/company do not use NAT.

However, Routers that provide communication to the Internet typically use NAT and will stop OPC communication. If your OPC applications are separated by a router that uses NAT, you will have to either use Tunneling technology or use OPC UA (which uses web-services to establish communication instead of DCOM).

How can I diagnose the cause of an OPC interface to stop collecting data?

In general, there are three ways to diagnose a failure in communication.

First, look at the log files of both OPC applications. Often they will indicate if the application failed to receive a request, or failed to receive a reply. The log files will also indicate whether or not the application sent a request for a reply.

This will help you to isolate the cause of the problem and determine whether the source of the miscommunication was on the OPC Client or Server end.

Note that the amount of information in a log file is controlled by that application’s vendor. OPC specifications do not specify the type of information to log. Nevertheless, logging any information that would help a person find the cause of problem is good practice.

Second, look at the Windows event log to find out if there were any errors logged by Windows. This will also help you to isolate the cause of the problem.

Third, use a third-party application to log the OPC communication between the OPC Client and OPC Server. These applications (often called “sniffers” or “loggers”) simply capture the communication between the OPC Client and server and record all the calls in a log file. The integrator can then read through the file and determine the cause of the problem.

How can I use OPC across different computer domains?

OPC applications can communicate with each other even when they are on different Windows Domains. The trick to getting communication working is Windows Authentication on both the OPC Client and OPC Server PCs.

First, the OPC Server PC must recognize the User Account of the OPC Client PC. Therefore the User Account of the OPC Client must exist in the Active Directory (located on the Domain Controller) of the OPC Server PC. Alternatively, the OPC Server PC must have a local User Account setup for the OPC Client application.

Second, the OPC Client PC must recognize the User Account of the OPC Server PC. Therefore the User Account of the OPC Server must exist in the Active Directory (located on the Domain Controller) of the OPC Client PC. Alternatively, the OPC Client PC must have a local User Account setup for the OPC Server application.

All this can be made easier if the IS (Information Systems) or IT (Information Technology) staff setup a Trust between the two Windows Domains. This will ensure that all User Accounts will be automatically synchronized between the two Domains.

How do I know when my OPC Server has lost its connection with its data source (such as a PLC, DCS, Analyzer, etc)?

OPC Servers that lose communication with their data source (such as a PLC, DCS, Analyzer, etc), should indicate that the process values now have “Bad Quality”. In addition, they should also indicate the reason for this “Bad Quality”.

For example, an OPC Server can indicate the Quality value is “Bad” because it lost communication with the data source, or the item in question is “out of range” or there was a “Sensor Failure”, etc.

These quality values can clearly indicate that the loss of communication was due to a failure between the OPC Server and its data source, rather than a communication problem between the OPC Client and OPC Server. Vendors can choose to implement this type of diagnosis in their OPC Server or not. Therefore, some OPC Servers provide no diagnosis at all.

The ability to diagnose problems and pass the results in a Quality parameter is an important feature that will help you to differentiate between various vendors. OPC specifications provide a list of possible error values.

How do Workgroups and Domains affect OPC connectivity via DCOM?

Computers on a Workgroup do not use an external PC (Domain Controller with the Active Directory) to help with the process of Authentication. Instead, they rely on their own information for Authentication.

Suppose an OPC Client application, which resides on a Workgroup, communicates with an OPC Server on a Domain. In this case, the OPC Client application’s User Account must either exist on the Domain Controller (of the OPC Server PC), or on the OPC Server PC itself. Furthermore, the User Account of the OPC Server must exist on the OPC Client application’s PC.

Suppose that an OPC Client application that resides on a Domain communicates with an OPC Server on a Workgroup. In this case, the OPC Client application’s User Account must exist on the OPC Server PC itself. Furthermore, the User Account of the OPC Server must either exist on the Domain Controller (of the OPC Client PC), or the OPC Client application’s PC.

How does OPC read and write data from and to a PLC?

An OPC Server provides data to an OPC Client application (such as an HMI, Historian, etc) using OPC. However, an OPC Server always uses a non-OPC method to exchange data with a PLC.

For example, suppose an OPC Server communicates with a PLC using the Modbus protocol. In this case, the OPC Server will ask the PLC for specific memory addresses that contain the data that the OPC Server requires. This is done using the Modbus protocol. The PLC provides all the responses to the OPC Server using Modbus as well.

This way, the OPC Server can read data from, and write data to the PLC using Modbus. The OPC Server then converts the data it retrieves from the PLC (using Modbus), to OPC “format,” and sends the data to an OPC Client application.

In every case, the OPC Server must know something very specific about the PLC to which it connects. At minimum, it needs to know the protocol/API spoken by the PLC.

However, in most cases, the integrator needs to configure the OPC Server for the specific information the PLC contains, which will change from project to project. In every case, once the integrator configures the OPC Server properly, any OPC Client application can retrieve data from the OPC Server without having to know anything about the PLC or its configuration.

How does the performance of OPC compare with communication over a serial line?

OPC can transfer tens of thousands of values per second. Some OPC Servers have been clocked at over 100,000 values per second.

On the other hand, serial communication typically provides data transfer rates of around 300 values per second, or a little more.

Thus, OPC does not add a new communication bottleneck. Typically bottlenecks are a result of non-OPC related factors such as external network limitations.

How does the performance of OPC DA using COM compare with OPC UA using Web Services?

Initial tests with the binary data transportation for OPC UA show that Classic OPC (based on DCOM) is faster for small messages, while OPC UA is faster for large messages.

Nevertheless, context is most important. Both Classic OPC and OPC UA can transfer tens of thousands of values per second, whereas most control systems are unable to keep up with a fraction of this data transfer rate.

Consequently, OPC UA is not expected to add another bottleneck to the communication system; just as classic OPC (which was OPC before Unified Architecture) does not add a communication bottleneck today.

How fast can an OPC Server transfer values?

OPC can transfer tens of thousands of values per second. Some OPC Servers have been clocked at over 100,000 values per second.

How many different OPC Clients can connect to an OPC Server?

The OPC specifications do not limit the number of OPC Clients that can connect to an OPC Server.

However, vendors might set their own limits for various commercial, performance, security, and other reasons.

How many different OPC Servers can be connected to a single OPC Client application?

OPC specifications do not limit the number of OPC Servers to which a Client can connect.

However, vendors might set their own limits for various commercial, performance, security, and other reasons.

How many OPC Servers can I install on a single PC?

The OPC specifications do not limit the number of OPC Servers that can be installed on a single PC.

However, vendors might set their own limits for various commercial, performance, security, and other reasons.

How popular is the OPC Historical Data Access (OPC HDA) specification? Has it heavily penetrated industry?

The most popular OPC Specification today is OPC Data Access (DA). OPC HDA is a distant second, while OPC Alarms & Events (A&E) is a very distant third.

Nevertheless, as more users demand standardized access to their historical process data, OPC HDA continues to gain ground. Already all the major historian vendors support OPC HDA.

How well does OPC perform from a computer resource perspective?

There are many factors that affect computer resource usage. Nevertheless, consider the following.

Applications that use DCOM abound in the world of IS (Information Systems). This is the reason the OPC Foundation selected DCOM as the platform of choice for OPC.

Also DCOM is already loaded in Windows by default. Therefore, the amount extra resources used by OPC applications are minimal.

Is there an easy way to configure OPC for multi-tag data structures on PLCs?

The beauty of OPC is that once the OPC Server has information, any OPC Client can easily retrieve it without having to worry about the specific PLC format.

However, configuring an OPC Server to communicate with a PLC takes some work. A common issue is what to do about data sources (PLCs or DCSs) that have a specific structure for the data.

With OPC Data Access (DA), the most common mechanism to describe the data is to simply use a common naming convention. Thus, “FIC101.PV” provides the Process Variable, “FIC101.SP” provides the Setpoint, etc.

Some OPC Servers are aware of structures in the device to which they are supposed to connect. In this case, the OPC Server can configure itself automatically for the scenario above.

Other OPC Servers do not have a predetermined structure and require Integrators to set these up repeatedly for each project.

The ability for an OPC Server to automatically configure itself to a PLC, or do so with minimal integrator interaction is a key differentiator between OPC Servers.

My OPC client application periodically loses connectivity to the OPC server. When I check again, the connection works. How can I diagnose intermittent OPC communication problems?

OPC and DCOM provide a highly reliable data communication base, which is suitable for critical 24X7 operations.

Connections should never stop (drop) without explanation. Nevertheless, factors beyond DCOM’s control may stop connections and include any of the following:

• Network connection may terminate due to cable disconnections or network appliance (switch, router, gateway, etc) failures
• OPC servers may terminate due to two main reasons:
  • Expected: A user may shutdown an OPC server
  • Unexpected: OPC servers may terminate unexpectedly due to a variety of reasons (bugs, lack of resources availability, manual termination, etc)
• The computer hardware may fail etc.

Each of failure condition is unique. To diagnose these problems in real-time, deploy any of the following:

• Manually monitor the system for connectivity problems (not recommended)
• Use a process historian to continuously capture real-time data and network conditions at the time of failure
• Use event monitoring software capture and diagnose real-time problems

What actions and errors must an OPC application log?

OPC Specifications do not require applications to log any data specifically. Nevertheless, logging any information that would help a person find the cause of a problem is good practice.

Most OPC applications provide some logging facilities. The OPC Training Institute recommends that Integrators base a part of their OPC product selection on the application’s error logging facilities, which help Integrators reduce their time to diagnose problems and improve project success.

What are the security holes when working with OPC?

Microsoft’s DCOM provides a highly secure and robust platform for applications to setup their communication. Classic OPC (before OPC UA) uses DCOM as its transportation platform. Therefore, an OPC application is, in essence, a DCOM application.

OPC only requires the standard configuration that any other DCOM application requires. When properly configured, OPC applications do not open any new security vulnerabilities for DCOM.

Having noted the above, many people disable security to get their DCOM (and OPC applications) working for the first time. This is a valid practice; however, Integrators MUST remember to restore the security back when they are done.

Failure to do this will cause a security hole. In this case, it would be the Integrators themselves that are the cause of the security hole and not OPC technology in and of itself.

What are the standard DCOM error messages?

Microsoft Windows defines the standard DCOM error messages. DCOM errors typically begin with a “0x800” code. Classic OPC (previous to OPC UA) uses DCOM as its transportation mechanism.

Thus, OPC states what information must transfer, and DCOM handles the transfer itself. DCOM also handles security aspects such as authentication and encryption.

There are a multitude of reasons for an OPC Client application to fail to connect to an OPC Server due to DCOM problems. The OPC Training Institute’s website covers many of these reasons in detail.

What are the standard OPC error messages?

OPC specifications provide a list of possible error values and messages. Vendors can choose whether or not they want to implement these.

The ability to diagnose problems and pass the results in a Quality parameter is an important feature that will help you to differentiate between various vendors.

What DCOM settings are required for connecting OPC Servers between two different domains?

OPC applications can communicate with each other even when they are on different Windows Domains. The trick to getting communication working is Windows Authentication on both the OPC Client and Server PCs.

First, the OPC Server PC must recognize the User Account of the OPC Client PC. Therefore the User Account of the OPC Client must exist in the Active Directory (located on the Domain Controller) of the OPC Server PC. Alternatively, the OPC Server PC must have a local User Account setup for the OPC Client application.

Second, the OPC Client PC must recognize the User Account of the OPC Server PC. Therefore the User Account of the OPC Server must exist in the Active Directory (located on the Domain Controller) of the OPC Client PC. Alternatively, the OPC Client PC must have a local User Account setup for the OPC Server application.

All this can be made easier if the IS (Information Systems) or IT (Information Technology) staff setup a Trust between the two Windows Domains. This will ensure that all User Accounts will be automatically synchronized between the two Domains.

What is OPC self certification?

The OPC Foundation provides a test harness for OPC Client and OPC Server applications. Vendors use this harness to ensure that their OPC applications can pass all the tests. If the OPC application passes all the tests, the Vendor can state that their application is OPC Compliant. They are also able to post the results of their tests on the OPC Foundation’s website.

You should ask all OPC vendors who state their applications are OPC compliant about the last time that they attended an OPC Interoperability session and the results of the test.

What is OpcEnum and why do I need it?

When an OPC Client application connects to a remote computer and attempts to browse for OPC Servers, it is actually connecting to a copy of OpcEnum on the remote PC. OpcEnum retrieves the list of OPC Servers on the computer on which it resides.

The inability to connect to OpcEnum is typically a result of authentication failure. There are other causes for a failure to connect to OpcEnum.

What is the difference between a client and server?

The basic distinction between a client and server is “control.” Clients control servers. Clients tell servers what to do, while servers do as they are told.

The following factors will help you determine whether or not an application should be programmed as an OPC client or server:

• Push or pull data: OPC clients can pull data from OPC servers. They can also push data to OPC servers. In both cases they tell the server what to do.
• Synchronous or asynchronous communication: OPC clients can initiate synchronous and asynchronous calls to OPC servers. Again, the client is telling the server what to do.
• Initiating communication: OPC clients typically initiate communication with OPC servers. However, in the case of callbacks, OPC servers actually initiate replies to OPC clients with data changes. In effect, the server behaves like a client. This callback is technically in reply to a client’s initial request, and so the client still controls the server.

In contrast to OPC client applications, OPC servers always do as they are told.

What is the OPC Interoperability session?

The OPC Interoperability session is an event the OPC Foundation hosts three times every year. During the event, OPC vendors gather to ensure their OPC Clients and OPC Servers can communicate with each other.

Thus, Vendor X tries to connect their OPC Client application to vendor Y’s OPC Server and also the OPC Server by Vendor Z. The success and/or failure results are posted on the OPC Foundation’s web site.

You should ask all OPC vendors who state their applications are OPC compliant about the last time they attended an OPC Interoperability session and the results of the test.

What is the relationship between DCOM and OPC?

Classic OPC relies on DCOM for data transportation. That is, OPC specifies the format of data that transfers between applications that use OPC.

For example, each OPC Data Access application must transfer a timestamp, quality level and data value. It is not enough to simply pass along the data value itself.

So while OPC states what information must transfer between applications, DCOM handles the transfer itself. DCOM also handles security aspects such as authentication and encryption.

What ports does DCOM use?