Opc Faq
Opc Faq
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.
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 Microsofts 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.
Classic OPC was based solely on Microsofts 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.
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 vendors release.
Do I need to add my OPC applications (OPC clients and OPC servers) to the list of exceptions in my
anti virus software (Avg, Panda antivirus, Avast, Kaspersky, McAfee, Microsoft Defender, Microsoft
Windows Security Essentials, Norton, Symantec, etc)?
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.
Clicking the "Yes" or "No" buttons does not solve the problem
To configure OPC communication to pass through a firewall, you must open a port for
DCOM communication and provide application exceptions. Specifically, you must
configure your firewall as below.
OPC Client PC configuration: First, you must provide exceptions for DCOM's end-point
mapping (EPMAP) functions on TCP port 135. You must also provide exceptions for
OPC Client applications.
OPC Server PC configuration: First, you must provide exceptions for DCOM's end-point
mapper (EPMAP) on TCP port 135. Then you must provide exceptions for both the OPC
Server as well as OpcEnum.
DCOM will take over from there, and will only require enabling 4 ports to establish
communication. Luckily, DCOM will find these ports automatically.
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 Rescue.
Additional resources:
o
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?
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 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.
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.
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.
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.
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.
I am trying to connect to an OPC Server using a particular product (name withheld), but I am
having difficulty. What is the DCOM configuration for both the Client and Server?
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 Institutes 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.
In light of the OPC UA (Unified Architecture) specification, should I avoid OPC Servers based on the
DA (Data Access) specification?
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 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.
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. The OPC Training Institute encourages you to find
out how a server handles configuration at the time project requirements are set.
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:
o
o
o
Etc.
Each of failure condition is unique. To diagnose these problems in real-time, deploy any
of the following:
o
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
applications error logging facilities, which help Integrators reduce their time to diagnose
problems and improve project success.
Microsofts 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 Institutes 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.
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.
Windows reports error 0x80040155 as: Interface not registered. Programmers know this
error as REGDB_E_IIDNOTREG.
DCOM errors typically begin with a "0x800" code.
This error typically occurs when applications are trying to use interfaces (or "features"
for which there is no record in the Windows registry.
To solve this problem, 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.
The following resources are available on OPC Training Institute's website:
o
If you are unable to find the right answer for your situation, please contact us and we will
help you make the connection.
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 Foundations 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 Institutes 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:
o
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.
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 Ys OPC Server and also the OPC Server by Vendor Z. The
success and/or failure results are posted on the OPC Foundations 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:
o
Integrators dont know how to configure DCOM. (This is the most common
reason people use OPC Tunneling.)
Integrators dont know how to configure the firewall. (This is the second most
common reason people use OPC Tunneling.)
There is a requirement to use only a single port for OPC communication. (DCOM
typically uses 4 ports.)
Communication has strict bandwidth restrictions that can only be overcome with
OPC Tunneling. (This is sometimes the case when bandwidth is restricted such as in
off-shore communication, or wireless telemetry communication.)
You should consider the following if you decide to use OPC Tunneling:
o
Does the Tunneling product provide Encryption services, or does it send data "in
the clear?" If Encryption is available, does it provide an acceptable level of
encryption? DCOM provides encryption services that enable it to keep
communication secret on a network.
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
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 Institutes website in the whitepaper titled "Troubleshooting OPC and DCOM:
Quick Start Guide."
Additional resources:
o
o
o
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 Institutes website in the whitepaper titled "Troubleshooting OPC and DCOM:
Quick Start Guide."
Additional resources:
o
o
There are many reasons an OPC Client application will fail to connect to an OPC Server.
The OPC Training Institutes 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.
Additional resources:
o
o
o
DCOM errors typically begin with a "0x800" code. Specifically, the 0x80040202 error
appears in the OPC Client application when it fails to receive a callback from the OPC
Server. The OPC Training Institutes website has a whitepaper that provides details on
this error its various potential causes, and how to solve them using a step-by-step guide.
Additional resources:
o
DCOM errors typically begin with a "0x800" code. Specifically, DCOM Error
0x80070005 appears in OPC client applications when they try to connect to a server to
which they are refused access. This error could be caused under several conditions. Read
the full article to troubleshoot and repair this DCOM error. The OPC Training Institutes
website has a whitepaper that provides details on this error its various potential causes,
and how to solve them using a step-by-step guide.
Other resources:
o
o
o
o
o
If you are unable to find the right answer for your situation, please contact us and we will
help you make the connection.
Will making changes to DCOM to accommodate OPC open any security holes?
OPC applications can be configured to work across firewalls. Refer to How can I acquire
data from an OPC Server through a firewall?