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.
Many products can be used to as an OPC tunnel. 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.
Classic OPC was based solely on Microsoft’s DCOM for data transportation. Consequently, OPC applications typically reside on Windows. There are ports of DCOM to other operating systems (such as Linux). Consequently, OPC will work on those systems as well.
With OPC UA the OPC Foundation wrote its own services for the data transportation. The OPC Foundation is providing source code to developers who can then port the technology to any operating system.
Classic OPC (based on DCOM) works on any operating system that supports DCOM. Microsoft Vista supports DCOM (even in the 64 bit version), thus OPC will work on Windows Vista 64 bit. In addition, OPC also functions properly between 32 and 64 bit systems.
OPC provides specifications that enable applications to communicate with each other. As vendors release their software, and apply patches and upgrades, they provide different executables (distributable packages). However, to ensure successful OPC communication, users do not need to ensure that all their applications have the same releases. While this may be a good practice in some situations, it is not necessary. OPC compliant applications that support the same release of an OPC specification will be able to communicate with each other regardless of their vendor’s release.
Antivirus software detects viruses and other malware (trojans, worms, etc). Anti virus applications protect your computer from unwanted activities. These applications should not catch OPC servers because the servers are not harming the computer. However, it is possible future automated updates may incorrectly flag your OPC applications.
Therefore, you should add your OPC clients and servers to the exception list so that they will not be accidentally stopped in the future.
Note: these anti-virus applications are only one part of a cyber security measures. To improve your protection, you should also deploy firewalls on each computer, and restrict user account access. For an automated solution, refer to OPC Rescue.
Problem: When trying to configure DCOM components within DCOMCNFG, Windows issues the following DCOM configuration warning:
The CLSID {1F87137D-0E7C-44d5-8C73-4EFFB68962F2}, item C:\WINDOWS\System32\wbem\wmiprvse.exe and title Microsoft WMI Provider Subsystem Secured Host has the named value AppID, but is not recorded under \\HKEY_CLASSES_ROOT\AppId. Do you wish to record it?
Cause: In Windows XP, the most common cause of this problem is the following Windows Update: Security Update for Windows XP (KB956572) Unfortunately, this update is only valid on Windows 2003 (as per Microsoft's documentation). Adding to the complexity, not all Windows XP installations are affected by this update.
Notes:
Suggested action: Uninstall "Security Update for Windows XP (KB956572)". However, if you are already in the process of reinstalling Windows, simply ensure you do not apply this update.
To configure OPC communication to pass through a firewall, you must open a port for DCOM communication and provide application exceptions.
Configuration Procedure for Windows firewall (see below for hardware firewalls):
DCOM will only require enabling the above ports to establish communication. DCOM will find these ports automatically. This method will only work with Win
DCOM can also be configured to pass information across static (or fixed) ports so it can work well with external or hardware firewalls. In this case, only 2 ports will be necessary.
OPCTI's Level 2: OPC Security and Level 4: Advanced OPC Projects cover this configuration extensively. For automated firewall configuration, refer to OPC Expert.
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).
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.
Additional resources:
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.
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.
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.
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.
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.
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.
OPC can transfer tens of thousands of values per second. Some OPC Servers have been clocked at over 100,000 values per second.
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.
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.
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.
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.
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.
The various OPC specifications state how an OPC Server should communicate with an OPC Client. However, the OPC specifications do not state how each product should be configured. To find out how to configure a specific OPC application (such as an OPC Server or a Client application), you must consult the specific product documentation.
There are many reasons an OPC Client application will fail to connect to an OPC Server. The single most common reason is a failure to pass the Windows authentication process. The OPC Training Institute’s website covers many of these reasons in detail. Our whitepapers (available for free) list various error conditions, their causes, and how to solve them using a step-by-step guide.
There is no need to delay purchases of OPC DA to wait for OPC UA products. This is because OPC UA is backwards compatible with OPC DA. As well, Integrators and vendors will be able to retrofit any OPC DA product with an OPC UA wrapper that the OPC Foundation provides.
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. The OPC Training Institute encourages you to find out how a server handles configuration at the time project requirements are set.
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:
Each of failure condition is unique. To diagnose these problems in real-time, deploy any of the following:
In all these cases, OPC Rescue can be a valuable first-line of defense to help you diagnose real-time connectivity problems.
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.
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.
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. Our whitepapers (available for free) list various error conditions, their causes, and how to solve them using a step-by-step guide.
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.
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.
Windows reports error 0x80040002 as: Can't enumerate any more, because the associated data is missing. Programmers know this error as OLE_E_ENUM_NOMORE.
This error typically occurs when trying to establish an initial connection with OPC (DCOM) applications. During this error condition, DCOM was able to find the required (server) application on the target computer. However, this application uses interfaces (i.e. features) not registered on target computer. In other words, this problem occurs on the same computer as the server (not client) application.
For example, this could be caused when trying to browse computers (using OpcEnum), or connecting to OPC servers. This could happen when connecting either locally or to remote applications. In both cases, features are not registered on the computer running the target OPC server (or OpcEnum).
To automatically repair error 0x80040002, which occurs during browsing (i.e. using OpcEnum), download OPC Expert (www.OpcExpert.com), and run it on affected computers. OPC Expert will provide full repair instructions. OPC Expert also enables users to view OPC server data, connect OPC to Excel, trend values, and more.
If this problem occurs when connecting to OPC servers, reinstall said server.
In addition, consider OPCTI's training classes (physical and online) at http://www.opcti.com/Training-Schedule.aspx
If you are unable to find the right answer for your situation, please contact us and we will help you make the connection.
Windows reports error 0x80040153 as: Invalid value for registry. Programmers know this error as REGDB_E_INVALIDVALUE.
This error typically occurs when trying to establish an initial connection with OPC (or DCOM) applications. During this error condition, DCOM was able to find the required (server) application on the target computer, however, a Registry entry for said application is either missing or corrupt. This is not caused by DCOM permission problems.
For example, this could be caused when trying to browse computers (using OpcEnum), or connecting to OPC servers. This could happen when connecting either locally or to remote applications.
To automatically repair error 0x80040153, which occurs during browsing (i.e. using OpcEnum), download OPC Expert (www.OpcExpert.com), and run it on affected computers. OPC Expert will provide full repair instructions. OPC Expert also enables users to view OPC server data, connect OPC to Excel, trend values, and more.
Windows reports error 0x80040154 as: Class not registered. Programmers know this error as REGDB_E_CLASSNOTREG.
This error typically occurs when trying to establish an initial connection with OPC (or DCOM) applications. During this error condition, DCOM was not able to find the required (server) application on the target computer. This is not caused by DCOM permission problems.
To automatically repair error 0x80040154, download OPC Expert (www.OpcExpert.com), and run it on affected computers. OPC Expert will provide full repair instructions. OPC Expert also enables users to view OPC server data, connect OPC to Excel, trend values, and more.
To solve this problem manually reinstall your server application, or if this problem occurs during browsing, reinstall OpcEnum.
Windows reports error 0x80040155 as: Interface not registered. Programmers know this error as REGDB_E_IIDNOTREG.
This error typically occurs when trying to connect to remote applications. During this error condition, DCOM was able to find the required (server) application on the target computer. However, this application uses interfaces (i.e. features) not locally registered.
To automatically repair error 0x80040155, download OPC Expert (www.OpcExpert.com), and run it on affected computers. OPC Expert will provide full repair instructions. OPC Expert also enables users to view OPC server data, connect OPC to Excel, trend values, and more.
To solve this problem manually (not recommended), use RegSvr32.exe (included with Windows) to register specific OPC DLLs. OPC applications will begin working when you register these DLLs properly because DCOM will be able to find the interfaces.
Windows reports error 0x80040202 as: An event was delivered but there were no subscribers. Programmers know this error as EVENT_S_NOSUBSCRIBERS.
This error typically occurs when trying to establish a subscription (advise) call with an OPC server. This error occurs after establishing a connection with an OPC server. During this error condition, OPC client applications are able to establish an OPC server connection. However, callbacks do not reach the client computer. This could be caused by a variety of issues such as firewall, network connections, DCOM permissions, user accounts, etc. Windows Registry problems do not cause this error.
To automatically repair error 0x80040202, download OPC Expert (www.OpcExpert.com), and run it on affected computers. OPC Expert will provide full repair instructions. OPC Expert also enables users to view OPC server data, connect OPC to Excel, trend values, and more.
Windows reports error 0x80070005 as: General access denied error. Programmers know this error as E_ACCESSDENIED.
This error typically occurs when trying to establish an initial connection with OPC (or DCOM) applications. However, it also occurs while trying to subscribe (setting up OPC advise calls). During this error condition, DCOM was able to find the required (server) application on the target computer, but DCOM permissions prevent users from accessing specific client/server components.
OPC Expert (www.OpcExpert.com) is able to diagnose this problem, so we highly recommend you run it for a thorough check of your system. OPC Expert will provide full repair instructions. OPC Expert also enables users to view OPC server data, connect OPC to Excel, trend values, and more.
See also
Windows reports error 0x800706BA as: The RPC server is unavailable.
DCOM errors typically begin with a "0x800" code.
The following resources are available on OPC Training Institute's website:
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.
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. These reasons are listed on the OPC Training Institute’s website in the whitepaper titled "Troubleshooting OPC and DCOM: Quick Start Guide."
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:
In contrast to OPC client applications, OPC servers always do as they are told.
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.
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.
DCOM uses Port 135 to establish communication. Once the OPC Client and Server are able to communicate, they will negotiate new port numbers for communication dynamically. OPC applications typically use 4 ports. Once, the OPC Client and OPC Server applications find the available ports, they use them and release traffic from port 135.
DCOM provides a versatile and secure platform for OPC communication. It is also freely available with Windows. However, there are instances where DCOM does not or cannot provide an acceptable solution, and Integrators prefer to pay money to install an OPC tunneling product from a vendor. The following lists the scenarios in which DCOM OPC tunneling technology is preferred over DCOM:
Whether you decide to use OPC Tunneling or DCOM, the OPC Training Institute hopes that you endeavor to learn DCOM before you make your decision. Most people find DCOM to be surprisingly logical once they understand how it works.
OPC Servers always send OPC Client applications information on the Value, Quality, and Timestamp of an item. But some control systems do not provide a timestamp. In this case, the OPC Server sends the PC timestamp, which is the only timestamp it has available.
When the OPC Server connects to control systems that have information on the timestamp, the OPC Server has a choice. It can either use the timestamp from the control system, or it can use the timestamp from the PC. Some OPC Servers even enable the integrator to make this choice.
The ability to use the timestamp from the control system and even to select the source of the timestamp is a differentiating feature amongst OPC Servers. The OPC Training Institute recommends that System Architects investigate the timestamp requirements. For example, a high-speed data acquisition to record a Sequence of Events (SOE) typically requires the timestamp to come from the control system. However, if the OPC Server is only used in conjunction with an HMI (Human Machine Interface), the control system timestamp may not be required.
There are many reasons an OPC Client application will fail to connect to an OPC Server. The OPC Training Institute’s website covers many of these reasons in detail. Our whitepapers (available for free) list various error conditions, their causes, and how to solve them using a step-by-step guide.
Making changes to DCOM configuration to accommodate OPC communication does not open any security holes or compromise security.
OPC applications can be configured to work across firewalls. Refer to How can I acquire data from an OPC Server through a firewall?