Integrationobjects
Integrationobjects
Integrationobjects
To not securely transmit process data, even within a business, exposes process controls
networks to potential cyber attacks, potentially disrupting production and even compromising
safety. This paper expands on the issues and challenges of employing DCOM when deploying
OPC technology and presents an alternative solution that addresses the industrial end-user
requirements.
Most of these industrial users have standardized on OPC as their backbone for all industrial
connectivity solutions, enabling true interoperability between multi-vendor systems and devices.
Deployment of OPC-based applications is easy when both clients and servers are installed on the
same machine. It becomes somewhat slightly more challenging when both systems are installed
within the same process controls network but on two separate machines. Such configurations
were possible and presented little security risk. Historically, however, major challenges arose
when attempting to connect a process controls network to an enterprise or business network(s).
These challenges are primarily due to the fact that OPC specifications are natively based on
COM/DCOM, which is difficult to implement and presents security vulnerabilities.
Users’ concerns for DCOM around difficulty of configuration, robustness, integrity of the data, and
performance of the data transfer are repeated themes from the industrial community. This is best
understood from the following details. OPC Clients and Servers are deployed with relative ease
when they are installed on the same machine. Users face major challenges configuring DCOM,
however, when they are installed remotely on two separate machines. Most hotline support issues
related to DCOM are configuration challenges, which can sometimes consume days to weeks in
troubleshooting. Configuration challenges heightened substantially when servers and clients are
on two different domains, or have a firewall in between. Another concern often raised by industrial
end-users is the way DCOM enables security and the associated impact on the integrity of the
process control data.
This document…
DCOM Robustness
DCOM can take an unreasonably long time to fail an activation request as it tries each available
network protocol (TCP, UDP, IPX, NP, etc.) in turn, until they all fail. Timeouts of 3 minutes are
not uncommon. (The DCOM designers claim they chose robustness over performance, but that
contention is unsupportable.) Few IT practioners will want to wait 3 minutes for a LAN connection
to respond -- 3 seconds is more like it! (Ref: http://www.windojitsu.com/code/atlxdcom.h.html)
Set-Up Complexity
Set-up configuration can be manageable only when both OPC clients and servers are installed on
the same machine. The challenges start when both systems are installed remotely, configured as
NT services, or running over a WAN. To perform such configuration, the user has to be an expert
on Windows Security. The set-up can be as complex, as it could take weeks for some users with
a lot of assistance to get the connectivity between the OPC Clients and Servers working.
New OPC-based software technology is now available to avoid DCOM challenges when seeking
to pass process data from one system to another, while ensuring fast, reliable, and secure OPC
remote communications. These tools are typically easy-to-deploy and maintainable solutions that
allow:
• Ease and fast set-up, with few point clicks only
• Tracking of client/server communications
• Communications through firewalls through single ports to minimize security holes, and
Network Address Translators (NAT)
• Connecting OPC components from different domains, across VPN and through the
internet and intranet
• User authentication at the server and tag levels for increased security
• Automatic reconnection when the connection is lost for robustness
• Configurable communication time outs
• Data encryption for security reasons
• Data compression for better performance of data transfer across the network
This technology uses a message queue that is a queue (repetition) of all messages that are to be
sent through a specific transport connection. The message queue is necessary only for
messages’ being sent and only if the connection is currently unavailable for sending. Constraints
can be applied to the maximum size of messages being sent, to the total size of all messages
kept in the queue and to the total number of messages kept in the queue.
The OPC Server and Client in Figure 1 are isolated by a firewall. To communicate with each
other, they need to select the same channel protocol and formatter. Formatters are the objects
that are used to encode and serialize data into messages before they are transmitted over a
channel. At the other end of the channel, when the messages are received, formatters decode
and de-serialize the messages. Channel protocols include TCP and HTTP. Formatters include
SOAP and binary. For best performance, we recommend using the TCP channel with a binary
formatter.
(C)
(S)
TCP/binary channels
To access a server, the client just needs to specify the server IP address and the port on which
the server will listen. It can get such information from a configuration file (XML file for example).
And as said above, bidirectional communication on a unique port is possible. Here the .Net
Remoting architecture provides a way for applications in different machines/domains to
communicate with each other and offers a powerful, yet easy, way to communicate with objects in
different app domains. So, .Net Remoting communications can traverse different domains and
overcome domain controllers’ security policies. Security barriers can be set using SSPI
(authentication, etc.) or other custom developed modules.
Figure 2 illustrates a second configuration example, showing the communication of process data
between two domains, each behind a dedicated firewall.
DotNet-OPC
Gateway (C)
Windows OS
TCP/IP
Domain 1 (L4)
Firewal
The gateway (C) just needs OPC Client
to know:
- the gateway (S) IP ONB Here, you need to open port x
address to allow communication with
Gateway (C)
- and the port number on gateway (S).
which this latter is listening
for connections and clients Windows OS
requests. TCP/IP
Domain 2 (L3)
Windows OS
TCP/IP
Domain 3 (L2)
Conclusion
The integration between business (enterprise) systems and production systems can increase
visibility of the manufacturing supply chain and create a more agile business environment. Such
integration requires the transmission of process data values across firewalls, where security
considerations are essential. While the OPC standard is useful in this application, OPC and
DCOM together can pose challenges to implement and maintain. This paper has presented a new
technology that increases the security of data and the overall usability of the solution. It facilitates
integration between and with production systems - from the single plant system level through
complex networks; while preventing cyber attacks and unauthorized users from gaining access to
critical process control data and the systems that control production.