Monday, January 31, 2022
OPC technology provides an interoperable, reliable, and secure communication platform. To achieve this, OPC relies on a well-configured DCOM infrastructure. This includes setting Windows security and firewalls, access control lists, server identities, etc. Consequently, OPC may not always work as expected and the initial troubleshooting can be difficult because each problem masks itself with a variety of symptoms. This whitepaper discusses the 5 most common problems, their causes, and how to resolve them.
This whitepaper also makes use of a diagnostic tool called OPC Expert. OPC Expert is free to download, does not require installation, and does not make registry changes. So it is safe to download and run on your computer. The OPC Expert website includes many helpful videos on how to get started and diagnose problems.
A well structured approach can quickly solve the following 5 common problems:
The first challenge is browsing for available OPC servers on remote computers. Browsing is the process whereby OPC client applications view a list of OPC servers on a remote computer. When applications browse, they connect to a copy of OpcEnum, which resides on the remote computer, and retrieves the list of available OPC servers. This list includes OPC server information such as an OPC server's description (verbose English description), ProgID (programmer's reference to an OPC server), and GUID (the numerical identification) of each OPC server. Applications do not yet connect to an OPC server; rather, OpcEnum simply provides connectivity information for each OPC server. Consequently, the OPC server list retrieval is independent of whether or not each OPC server is operational.
When using OPC Expert, find the remote computer , and open it. If you are able to see a list of OPC servers, OpcEnum is likely working well. If OPC Expert is unable to browse the remote computer, you will see an error in the event log at the bottom of OPC Expert. When you double-click the error message, OPC Expert will show a verbose description of the problem and what you can do to repair it.
A failure to browse for OPC servers is a direct result of the inability to properly establish communication with the copy of OpcEnum on the remote computer. Below are several causes preventing applications from browsing (accessing OpcEnum).
Firewalls block communication. Common errors are 0x800706BA and 11001. OPC Expert diagnoses these errors and provides detailed diagnosis. Administrators must configure firewalls for OPC communication (by allowing port 135 and application ports), or they must deactivate said firewalls altogether. Administrators can allow access to dynamic ports using application exceptions. For external firewalls, administrators can configure DCOM to use static ports.
User accounts must match on both computers. The single most common error is 0x80070005. It is possible your user account is not authenticated on the remote computer. Authentication is the process of verifying you are the user you claim to be. Windows compares the user name with the stored password. If Windows does not recognize your user account, it will reject your entry immediately without attempting an OPC server connection. This can happen under at least a couple of circumstances.
In most cases, OPC Expert will be able to automatically diagnose the problem and provide recommendations to help you establish communication.
The OPC Foundation is responsible for the creation and maintenance of OpcEnum. Anyone can obtain OpcEnum for free directly from the OPC Foundation. OpcEnum is typically installed when you install an OPC client or OPC server; but, this is not always the case. It is possible a computer does not have a local copy of OpcEnum installed. The most common errors are 0x80040153 and 0x80040154. In such cases, OPC Expert will enable you to repair this problem automatically by installing OpcEnum.
OpcEnum is only able to browse for OPC servers on the machine on which it is running. Therefore, OpcEnum cannot browse a remote computer, even if a copy of OpcEnum is present on your own computer.
OPC Expert will automatically inform you if OpcEnum is not installed on your computer. It will also repair the problem.
Even if OpcEnum is installed on the remote computer, it must be able to execute, otherwise, communication will fail. If the "Startup Type" for OpcEnum is set to "Disabled" then Windows will be unable to start OpcEnum. Thus, you will have to enable OpcEnum.
To check the Startup Type for OpcEnum follow the steps below:
Try to browse the remote computer again. If it still doesn’t work, move to the next step.
By default, OpcEnum requires Anonymous Logon access (on the OPC server computer). If you do not provide this access, no one will be able to connect to OpcEnum and browse the computer. It is possible this access was overlooked during the setup. You can also configure OpcEnum so it does not require Anonymous Logon access. To do so, use OPC Expert to reinstall and configure OpcEnum correctly by checking the "Enable essential OPC features" checkbox.
When you are unable to connect to an OPC server, the most common errors are 0x80070005, 0x80070422, and 0x80080005. OPC Expert automatically diagnoses most issues.
The act of connecting to a remote OPC server is actually independent of the ability to browse for OPC servers on the remote computer. For example, it is possible to connect to a remote OPC server even though the remote copy of OpcEnum is not even installed. In any case, if you know the identity of the remote OPC server (either through a remote browse or by simply "knowing" the correct GUID), but are still unable to establish the OPC connection, there can be several factors responsible for failures.
If the OPC server is set to run as a Windows Service, it is possible it was disabled. To check if this is the case, follow the same steps I covered in section "1.4 OpcEnum is disabled".
If your OPC client application used OpcEnum to browse the computer on which the OPC server resides, you can skip this section. This is because access to OpcEnum explicitly implies you were properly authenticated.
However, if your OPC client application does not use OpcEnum, then Windows Authentication might be the cause of the communication problem at this point. Refer to section "1.1 Firewall blocks access" to solve this problem.
After authenticating an incoming user account, the Operating System then checks whether or not the user account is allowed to Launch and/or Access the OPC server. This is done with the use of an Access Control List (ACL). The ACL for each application includes information on user accounts permitted or denied from taking specific actions. Thus, it is possible Windows will deny access either because the ACL does not include the necessary permissions for a user account, or because that user account is explicitly denied from receiving launch/access rights. If either of these is the case, you must change the ACL for the OPC server. To learn more about how the ACL affects OPC servers and how to set it properly, refer to my whitepaper titled "OPC and DCOM: 5 things you need to know." Specifically, look for section "3.3 COM Security".
Access to OPC servers is governed by the ACL. However, you must also match the OPC server identity with the business situation at hand. To learn more about the OPC server identity, refer to my whitepaper titled "OPC and DCOM: 5 things you need to know." Specifically, look for section "4. Configure Server Specific DCOM settings". When you understand the OPC server identity settings, refer to the bullets below to diagnose the connection problem you are having.
In general, I do not recommend any of the settings above due to the problems they cause. Instead, I recommend using "The system account (services only)" setting, unless your OPC vendor specifies otherwise.
Once you are able to connect to an OPC server, you know the remote computer recognizes your user account and you have the proper permission to access the OPC server. Also, you have established synchronous communication with the OPC server and can poll the OPC server for data.
If all OPC server items indicate they have a bad quality, it could be due to a couple of factors as listed below. Ensure you investigate them in order.
By following the steps above you will ensure the OPC server is receiving data properly. If your OPC server does not receive data properly from its data source (i.e. PLC, DCS, etc), no amount of Windows security configuration will help you get values as there is simply no data to retrieve.
OPC client applications often fail to receive updates due to security configuration issues. The most common errors are 0x80040202, 0x80070005, 0x800706BA, etc. OPC Expert can automatically diagnose these errors and provide detailed diagnosis and a set of actions. However, before concluding data updates are the cause of the failure, refer to section "3. All items show bad quality" to ensure the OPC server is actually receiving data properly. Once you confirm the OPC server is indeed receiving data, you should begin to suspect unsolicited data updates from the OPC server are failing.
OPC supports a report-by-exception mechanism whereby OPC servers send data updates to OPC clients whenever data changes. OPC terminology refers to this mechanism as "subscription." OPC servers are able to achieve subscription updates through the use of asynchronous callbacks. When OPC servers detect a change in the data, they immediately "call" clients back with the data update. This is an asynchronous mechanism because the OPC client does not know when the OPC server will send the data. However, if you don’t set the security settings properly, these data updates will fail. OPC Expert shows a yellow exclamation mark on the OPC server icon, meaning communication is problematic.
To find out if data updates from the OPC server are failing, try to make a synchronous read from the OPC server. If a proper data value suddenly appears, you can be sure asynchronous callbacks are failing, which can be due to any of the causes below.
If the OPC client computer is behind a (hardware or software) firewall, callbacks may fail to arrive at their destination. While the OPC client will be able to make outgoing OPC calls, callbacks from the OPC server may be blocked by the firewall. To learn more about the Windows Firewall and how to disable it, refer to my whitepaper titled "OPC and DCOM: 5 things you need to know", as it applies to your version of Windows. Specifically, look for section "1. Remove Windows Security".
Once a callback reaches the OPC client computer, the Operating System will attempt to authenticate the arriving user name and password combination with its existing list. Windows will reject this combination for various reasons as below.
It is imperative both the user name and password are recognized on both the OPC client and Server computers. In the case of callbacks, it is possible the user names and passwords on one computer do not match the other computer. You must ensure all combinations match on both computers.
The default setting in Windows XP when using Workgroups is to force local users to authenticate as Guest. This is also known as Simple File Sharing. Windows 7 (and later) does not have this as a default setting. This default setting will not enable you to get the necessary authentication level working. Thus, you will have to turn this option off. To learn more about modifying network access, refer to my whitepaper titled "OPC and DCOM: 5 things you need to know." Specifically, look for section "2.2 Local Users Authenticate as Themselves".
Callbacks take the identity of the OPC server. This identity is governed by the OPC server identity setting. To learn more about the OPC server identity, refer to my whitepaper titled "OPC and DCOM: 5 things you need to know." Specifically, look for section "4. Configure Server Specific DCOM settings". When you understand the OPC server identity settings, refer to the bullets below to diagnose the connection problem you are having.
In general, I recommend using "The system account (services only)" setting, unless your OPC vendor specifies otherwise.
Once Windows authenticates the user account that initiated the callback, it will check the access rights of the user account in the OPC client’s Access Control List (ACL). However, you will recall an OPC client application does not have its own ACL; consequently, it refers back to the System-Wide DCOM settings. In this case, simply follow the guidelines I indicated in my whitepaper titled "OPC and DCOM: 5 things you need to know." Specifically, look for section "3. Configure System-Wide DCOM settings".
You may sometimes notice the CPU of the OPC server computer is much busier than you expect. I did not write specific percent usage values because they are rather situational. Only you can decide whether the CPU load is high or not. Nevertheless, if you believe a load is too high, it may be worth invesitgating.
If the OPC client application seems to be receiving data updates properly, have a closer look at how the OPC client is receiving data updates:
OPC is powerful industrial communication standard. However, OPC relies on having DCOM work properly. Luckily, DCOM problems can usually be overcome with relatively simple configuration changes as documented in this whitepaper. To get a deeper understanding of OPC, DCOM, and the diagnosis of all common problems OPCTI highly recommends you take time to get formal OPC training. This will enable you to structure your OPC knowledge to help you reduce your short and long-term project costs. OPC Expert can help you troubleshoot and diagnose OPC communication problems. It is free, does not require installation, and does not change Windows registry. So it is safe to download and execute on all computers. OPCTI also encourages you to provide us with feedback. Let us know about new problems and solutions you found. We will pass these on to the rest of the OPC community, to help everyone get connected.
About the author: Randy Kondor is a Computer Engineer, and is the President of the OPC Training Institute, the world’s largest OPC Training company. Since 1996, Randy has been vastly involved in OPC technology and a strong supporter of the OPC Foundation. He continues to dedicate himself to spreading the OPC Foundation's message about system interoperability and inter-vendor cooperation. Find Randy on LinkedIn.com and OPCTI.com.
Copyright © 2022 OPC Training Institute (OPCTI). All rights reserved. The information contained in this document is proprietary to OPCTI. No part of this document may be reproduced, stored in a retrieval system, translated, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without prior written permission from OPCTI.
OPCTI is the global leader in OPC training for automation professionals, and is the largest OPC training company in the world. OPCTI offers hands-on training workshops in-person and online.
OPCTI is vendor-neutral, meaning that we will teach you how to establish and implement a robust and secure communication infrastructure, no matter what OPC products you use - the training that you receive from OPCTI can be immediately implemented at your workplace. Our progressive training will enable you to increase your efficiency, security, and productivity.
The Certified OPC Professional (COP) designation is only offered by OPCTI. The designation is awarded to those who have successfully completed our training, and who demonstrate proficiency with OPC technology, design architecture, and installations. The COP designation is endorsed by many OPC Foundation member companies.
OPCTI is an active member and a strong supporter of the OPC Foundation. Randy Kondor, President and Chief Instructor at OPCTI currently serves as the Vice President of Education at the OPC Foundation.
Visit our Training Schedule to see where OPCTI is currently offering training workshops, or contact us to find out more about private trainings for you and your team at your site.