Setup: Application Execution

3
Setup
OPC, SQL, OLE_DB, ActiveX, and other Microsoft software tech-

nologies have been made very easy to use, almost invisible to the
user. Most of the setup is done automatically when applications
are installed. The rest is simply pointing, clicking, and filling in
some blanks. Windows and DCOM security setup is explained
very systematically in Windows manuals and many books, as well
as in most OPC server manuals. Therefore, it is not repeated in
this book. The purpose of this chapter is to give an idea of how to
deal with bigger issues like firewalls and domains.
Windows 95, 98, and ME (Millennium Edition) have a number of

issues related to limited reliability, capability, flexibility, and
security. The Windows NT family of NT4, 2000, and XP are far
better choices.
Therefore, it is a good idea to eliminate non-NT-family computers,

particularly in automation systems.
Keep in mind that you need administrator rights to install OPC

servers and to make changes to DCOM configuration and secu-
rity, for example. However, for most applications users do not
need administrator-level rights to run clients and servers – even
remote servers.
Application Execution
Networking and security must be set up correctly to ensure
remote server applications can be launched when authorized
operators are at the workstations. Clients must be able to launch
servers, and logging applications must be able to start automatically.
67
68 Software for Automation
NT Service
Some applications or components can optionally run as an NT
service. Services are applications that run in the background; they
do not have a user interface, since services are used by other
applications, not by users. Unlike most applications, services are
not launched by the user from the start button. Rather, they are
started and stopped by Windows. If an application runs as an NT
service, a new user can log in without restarting the application.
This is ideal for server applications such as the Windows IIS Web
server, OPC A&E servers such as alarm generators, as well as
alarm and historical trend loggers. These applications should be
running continuously regardless of which operator is using the
system. Other applications suitable to run as an NT service
include OPC tunnelling and security. Not all applications can run
as an NT service. Configuration of an application to run as an NT
service, or not, is done from within the application itself. Verify
with the vendor which applications are configured to run as an
NT service.
If an application runs as an NT service, it can optionally start up

automatically without need for a user to log in. In Windows, this
setting is made in Component Services under Administrative
Tools in the Control Panel. This is ideal for servers because they
are often located remotely, where they are not easily accessed by
shift personnel. Also, automatic start-up is critical in case of
reboot after a power failure. By default, NT services run under the
security context of the “System” account, but there may be situa-
tions where this has to be changed. For example, an OPC client
such as an alarm logger may need to launch the alarm generator
OPC server on a different computer across the network. The client
can then be configured to log on in an account that permits it to
start the server. It is also possible to configure how the NT serv-
ices recover in case of failure. Details of how this is done in
explained in Windows documentation.
It may be a good idea to create an account specifically for the purpose of

launching and accessing networked components such as OPC servers,
including A&E alarm generators.
OPC DA servers typically do not run as an NT service. Access is

configured using the DCOMCNFG utility. Automatic launch can
be achieved by client or manager software.
Chapter 3 – Setup 69
Windows Auto Login

Usually, you would want the user to enter his or her login name
and password before the computer starts. In remote locations, the
computer may be required to run unattended. In this case, it is
possible to configure Windows to login automatically, eliminating
the need for user intervention.
Windows Auto-start
When OPC clients are started, they automatically launch the asso-
ciated OPC servers. Thus, if a shortcut to the client is included in
the Windows Startup folder, it will subsequently also launch the
servers. For server computers in which no client is executed,
“server manager” utilities can be included in the Windows
start-up folder to launch the servers. Therefore, it is possible to
automatically start applications although they don’t run as an NT
service. Another advantage of server manager utilities is they can
keep a server running even if no client is connected. This is ideal
for systems where starting the server and establishing the initial
connection takes a long time.
System Networking
Because inserting firewalls between the automation network and
the information network creates the need for additional hardware
and software to support Web technologies, it is tempting to not
use a firewall. However, the firewall is necessary to protect the
control network from problems permissible in the execution and
business environment, but not in automation. Having the histo-
rian on the control network means substantial traffic sharing
bandwidth with the automation function. Therefore use fast
Ethernet and logically separate information from control on
automation level LAN using virtual LAN (VLAN).
Support for several different networking protocols is built into

Windows. However, these days most automation systems use only
TCP/IP based communication because that is the technology used
in controller hardware in the execution and business environment
Intranet, as well as the public Internet. In an automation system,
workstations and servers are networked over a Local Area
Network (LAN). Of course, a small system may have only a single
computer performing the function of both I/O data server as well
as operator console. A large system may have several workstations
each for operation, maintenance, and engineering, as well as
several servers for I/O data, alarms, historical trending, etc.
These days, there is often a need for data to percolate up into the
MES and ERP levels. For this purpose, a router is used to tie the
automation system network to the plant LAN. By connecting to
the Internet, it is possible to gain access to the automation system
from anywhere to obtain information, or to perform remote opera-
tion or maintenance. Remote access is ideal for in-house as well as
external experts to solve problems in the automation system
outside regular working hours (Figure 3-1).
Figure 3-1. Network Architecture
For greater security, the router should have a built in firewall to

protect the automation system network. Additional security meas-
ures should also be considered. Enterprise integration is covered
in Chapter 5 and network security in Chapter 10. Windows
DCOM does not handle firewalls, domains, routers, and the
Internet very well. Therefore, DCOM-based communication such
as OPC is only used within the automation system. Beyond the
automation system, across the Intranet and Internet, it is better to
use Web technologies. However, Web technologies are too slow to
be used in the automation system.
The Internet is the easiest way to have remote access to the

automation system. However, in some places this may still not be
possible. The traditional way of getting access to the automation
system from a remote location is using a modem for dial-up over
the telephone network.
Local Area Network (LAN) Configuration

Because Windows has built-in support for TCP/IP on the local
network, as well as routing to the Intranet/Internet, network
setup is easy. The automation department should ask the corpo-
rate IT department to assign a block of IP addresses to be used
within the automation system. Network configuration is a matter
of simply entering the IP address for the computer, and, if appli-
cable, the router and domain name servers. Network configura-
tion is explained in Windows manuals and many books, as well as
in most software manuals.
The PING command can be used from the command prompt to

verify the network is configured correctly (Figure 3-2).
Figure 3-2. Ping to Verify Networking (Screenshot: Microsoft Windows)
Remote Access Configuration

Remote Access Server (RAS) is a function built into the Windows
NT family of operating systems. The RAS is installed on one of
the computers on the network. It connects to the telephone
network through a modem (Figure 3-3). Another Windows
computer can dial in to the RAS from anywhere; it is assigned an
IP address, becomes part of the network, and is able to access
resources on the network. This solution is ideal when a permanent
Internet connection is not available for the automation system.
Figure 3-3. Dial-in Using Remote Access Server (RAS)
RAS has a security advantage since the connection, unlike the

Internet, is not publicly accessible and not free, preventing access
by many potential attackers. Remote access can be used to
monitor the manufacturing or building, for example, as well as to
perform engineering work.
Remote Access Server (RAS)

RAS is built into Windows; therefore, the setup is quite simple, as
it is an integral part of the Windows networking, security, and
telephony. Configuring the computer to accept incoming connec-
tions includes selecting which protocols are available. Typically,
only IP, dial-in client IP address range, or DHCP, permitted user
accounts, and optionally safety through RAS callback to client on
a predetermined telephone number has to be configured.
Remote Access Client

In the client-end, no installation or setup is required other than
the modem card and the dial-up account.
Terminal Server
Another scheme to create a multi-user environment is to use
terminal services built into servers. A terminal server is a server-
centric scheme in which an application runs in multiple inde-
pendent sessions on a server for each of many clients. Most appli-
cations can be run in multiple sessions without add-ons. No appli-

cation execution or data storage is done in the client. Thus, “thin-
clients” such as dumb terminals can be used as operator inter-
faces. No software installation or configuration, other than a
generic terminal emulation application or Web browser, is
required. The screen image is transmitted from the server and
displayed on the thin client. Conversely, keyboard input and
mouse clicks are also transmitted from the client to the server.
Using special software, Mac, Linux and Unix computers can be
used as clients having the look and feel of Windows applications
with OPC, OLE_DB, VBA, and ActiveX, for example, actually
running on the server. No graphics conversion is required, since
all displays run in their native format.
Automation software installation and maintenance on every client

computer is manageable within the automation system. However,
managing automation software on computers at other levels of
the enterprise would be more difficult, as these computers are the
responsibility of the IT department and out-of-bounds to automa-
tion engineers. Terminal services thus facilitate support for remote
as well as casual users. Service packs and new versions only need
to be installed on the server.
Although terminal services make it possible to use simpler and

probably cheaper thin-clients, it does require an equivalently more
powerful server, or server clusters, at higher cost. The centralized
architecture has availability issues requiring server clusters. The
shared server and network bandwidth limits system responsive-
ness. Therefore, terminal server architecture is not suitable for
operator stations in the local control room, but best applied to
remote as well as casual users. Some advantages of the terminal
server scheme includes centralized deployment and upgrade – for
example, an application such as operator visualization is installed
and serviced on a single server rather than possibly dozens or
even hundreds of computers throughout the plant.
Terminal services do not use HTTP on port 80 but another protocol

on another port that must be accessible on both the server-side
network and the client-side network. Therefore terminal services
do not work well with firewalls. Since there should always be a
firewall between the control network at the automation system
level, and the information network at the execution level network,
the use of terminal server is limited within the automation system
domain. However, this can technically include remote access using
Remote Access Server (RAS) or Virtual Private Network (VPN), in

which case the remote computers are in fact nodes on the local
network unobstructed by firewalls.
DCOM Setup
DCOM is supported in Windows, except for the earliest versions.
However, verify on which specific operating systems the clients
and servers can run. In general, an OPC server needs to run on an
NT family operating system such as Windows NT4 (workstation
or server), Windows 2000, Windows XP, or later. A client can be
any of those, Windows 98, or Windows ME. Even Windows 95
with DCOM extension is possible. If the client and server are not
on the same computer, then DCOM security must be configured
to enable the necessary networking functions.
Windows XP Service Pack 2 introduced some DCOM security

enhancements that requires additional configuration for OPC to
work across the network.
Network Access Control

The network security scheme for the automation system must be
chosen, and security accounts for access control must be configured.
Domain vs. Workgroup

For Windows, there are two forms of network access: domain and
workgroup. Domain access is based on workstations accessing a
central server in a client-server scheme. Workgroup access is
based on workstations communicating with each other peer-to-
peer. Domain access uses the central server to control access to all
resources on the network for all users in one single place. For
example, accounts are created once for the entire system. For
workgroup access, the security is local and must theoretically be
configured for each user in every computer (i e., eight users and
four computers mean 32 entries, worst case). For any automation
system having more than a handful of computers, domain access
is recommended, since it is easier to manage for larger systems.
However, in reality, every computer rarely needs access to every
other. Normally, clients just access the servers and not other
clients. Therefore it is only necessary to create client accounts on
the servers, and server accounts on the clients. Moreover, in most
automation systems all operators share a single account.
Additionally, for workgroup network access in Windows XP it is

necessary to set sharing and security settings for local accounts as
“Classic - local users authenticate as themselves” (Figure 3-4).
Figure 3-4. Workgroup Network Access Requires More Configuration
It may be a good idea to consult the IT department in the plant to find

the best solution for the site.
Typically, all computers in an automation system should belong to

the same domain and be on the same IP subnet. Computers at the
execution and business levels generally belong to one or more
different domains. Computers in one domain do not have access to
another domain unless special domain trust relationships are estab-
lished. Client and server computers should be in the same
networking domain or workgroup. If they are not, special measures
will be required, somewhat increasing the complexity of the system.
Indeed, it is a good idea to leave the automation system protected by not

permitting other domains to access its resources. Preferably, the automa-
tion system shall be on different IP subnet than execution and business
systems, separated by router and firewall.
Users & Passwords

In the Windows operating system, user accounts have to be
created (Figure 3-5). For workgroup access, the accounts have to
be created in every computer. For domain access, accounts only
need to be created once in the domain controller computer.
It is a good idea to create user groups based on different roles, such as

operators, technicians, and engineers, so all persons in a particular role
can be assigned rights to an application as a group.
Figure 3-5. User Accounts and Groups (Screenshot: Microsoft Windows)
Password and lockout policies, assignment of rights, and other

security options can be set. The details of how this is done is
explained in the Windows documentation.
It may be a good idea to define groups because it makes it easy to add and
remove users, ensuring correct rights, as members join and leave the team.
DCOM Configuration
If client and server applications are located in different computers,
then DCOM must be enabled and configured in all client and
server computers to permit remote access, launch, and configura-
tion. OPC across a network is a classic example of remote access,
activation, and adjustment of remote components. For small
systems where client and server applications are in the same
computer, the default settings will work, and no configuration is
necessary unless there are special security requirements. Most
OPC server manuals explain this configuration systematically. The
steps are the same for all OPC clients and for all OPC servers, and
apply to other DCOM applications as well. The client-side and
server-side configuration is slightly different. Similarly, there are
slight differences between the workgroup and the domain access,
as well as some differences between versions of Windows. Details
of how this is done from DCOMCNFG are typically explained in
the OPC server documentation. Note that the DCOMCNFG utility
configures all COM on the computer, not just OPC, so it will be a
very long list of components (Figure 3-6).
Figure 3-6. DCOM Configuration Console
The DCOMCNFG console permits configuration of these aspects

of distributed components:
• Properties
• Security
• Protocols
Settings have to be done for client and server applications as well

as for the common OPC component called OPCEnum that permits
remote clients to browse for servers. Rather than changing the
settings for each individual application, it is better to change the
“Default” settings for the computer as a whole and custom tailor
only some aspects of a few components. Changing the DCOM
settings requires the computer to be restarted.
Before configuration starts it is a good idea to determine and document

which user or group will use each computer and which applications that
will connect to remote servers.
The proper way to configure DCOM is to assign access and launch

permissions based on user groups and user accounts. However,
during integration and test, it may be a good idea to set this to
“Everyone.” This effectively disables the security, eliminating this
as a potential problem. Once the system is established working,
remove “Everyone” and configure proper access restriction.
Use “Everyone” when doing initial system integration and tests.

Properties
It is possible to configure how strictly the server authenticates the
client, and if the server can impersonate the client’s identity when
performing certain tasks. It is possible to set these DCOM proper-
ties as a “Default” for the computer as a whole, as well as a
specific property for individual applications. The properties for
individual applications override the default properties. Some
combinations of the authentication and impersonation settings
will not work for OPC. The below configuration for the default
properties works for most installations, but some installations
may have special requirements:
• Enable Distributed COM = checked

• Default Authentication Level = Connect
• Default Impersonation Level = Identity
It is a good idea to use only the overall default properties as much as

possible, since this is easier to manage than individual settings for
several components.
Security
It is possible to make the “Default” DCOM security settings for
the computer as a whole as well as specific security settings for
individual applications. The security setting determines which
user or group of users can access, launch, and configure applica-
tions. For example, DCOM security is used to restrict application
use only to authorized persons. Three aspects of the application
are controlled:
• Access
• Launch (normally not required in clients)
• Configuration (normally not required in clients)
Launch and configuration security normally does not have to be

set in the client because the client starts and configures the server,
but never the other way around. However, access must be set in
the client in order to permit the server to call back with subscribed
data. For example, not only must servers be configured to permit
client access, it also is important that clients are configured to
permit server access to enable “callback” interface used by many
components, such as OPC.
Protocols
It is possible to make the “Default” configuration for protocols
DCOM will try to use, and in which order for components in
general as well as specific protocol choice for individual applica-
tions. Fewer protocols reduce the time DCOM spends retrying,
thus notifying operators faster of any failure. The settings for indi-
vidual applications override the default settings. It is a good idea
to use only the single default protocol setting as much as possible,
since this is easier to manage than several individual settings for
each component.
In most installations, all network protocols are based on TCP/IP, so it may

be a good idea to consider removing any unused protocols from the list.
Applications
Authentication level, security, and protocols can be adjusted for
each individual component in cases where the default computer-
wide settings are not suitable (Figure 3-7). Additionally, it is also
possible to set the location where the component will be
executed—that is, on which computer. Further, it is also possible
to run the component using a different user account. It is easier to
manage a single default configuration rather than individual
configuration for each component. Even documentation of
component specific settings gets very messy.
Because it is more difficult to manage a system where the computers

have applications with individual DCOM settings, it may be a good idea
to avoid component specific settings.
Figure 3-7. Custom Security Setting of Configuration Permissions for OPC

Server (Screenshot: Microsoft Windows)
However, OPC servers typically use custom configuration permis-

sions, such as a specific security setting. On the other hand, this is
generally set automatically when the OPC server is installed, in
which case it requires no special documentation or attention. The
common OPCENUM component that permits remote clients to
browse for servers also uses custom configuration permissions,
generally set automatically during OPC server installation.
If a server runs in unattended operation, such as in the case of a

remotely located computer, there will not be any user to log on to
the computer. In this case, the OPC server could either be set to run
as an NT service, if it has this capability, with the identity set to the
“System” account. If the OPC server cannot run as an NT service,
select “This User” identity and be sure to configure Windows to
automatically logon to a user account created specifically for this
purpose with rights configured accordingly.
Summary
The server needs to be configured to enable calls (Table 3-1). The
“Default” properties are configured once and for all for the entire
computer. The application properties can be set for each applica-
tion. The security limits were introduced from Windows XP
Service Pack 2.
Table 3-1. Typical Server-Side Configuration

Scope Tab Item Configuration Remark
Default Default Enable Distribute Yes (checked)
(for My Properties COM
Computer as Default Connect Connect
a whole) Authentication means client
Level is authenticated
when it first
connects.
Default Identify Identify means
Impersonation the server will
Level identify the client
Default Default Access At least Add “Everyone”
Security Permissions “System” and or “Domain
“Interactive” Users” to
override security
Limit Access ANONYMOUS
Permissions LOGIN local and
remote access
allowed
Default Launch At least Interactive means
Permissions “Interactive” logged-on user.
Add “System” if
running service
Limit Launch Local and remote Allow local and
and Activation launch and remote launch
activation and activation
allowed for the for “Everyone”
OPCgroup to override
account security
Default - Usually setup
Configuration automatically
Permissions
Default DCOM protocols Connection-
Protocols oriented TCP/IP
Application General - -
(for individual Location Run applications
component) on this computer
Security Access Default
Permission “System” and
account for
OPCgroup
Launch Default
Permission Account for
OPC group
Configuration Custom Usually
Permission customized
automatically
Identify This user “Launching
Account for User” and
OPCuser “Interactive”
are not
recommended
The client needs to be configured to enable callbacks (Table 3-2).

The “Default” properties are configured once and for all for the
entire computer. The application properties need to be set for every
application.
Table 3-2. Typical Client-Side Configuration

Scope Tab Item Configuration Remark
Default Default Enable Distribute Yes (checked)
(for My Properties COM
Computer as Default Connect
a whole) Authentication
Level
Default Identify
Impersonation
Level
Default Default Access Add “Everyone”
Security Permissions or “Domain Users”
to override security
Limit Access ANONYMOUS
Permissions LOGIN local and
remote access
allowed
Default Launch -
Permissions
Limit Launch and Local and remote Allow local and
Activation launch and remote launch
activation and activation
allowed for the for “Everyone”
OPC group to override
account security
Default -
Configuration
Permissions
Default DCOM protocols Connection-
Protocols oriented TCP/IP
If clients and servers don’t work together, refer to Chapter 6 for

troubleshooting.
DCOM Beyond the LAN

In most plants, the automation system network and the enterprise
Intranet both use TCP/IP on a fast and reliable Ethernet network.
This makes system integration relatively easy, and greatly simpli-
fies administration. However, to protect the control system from
malicious attacks and inadvertent blunders, it is a good idea to
logically separate the control network from the IT network using a
router and firewall.
Indeed, it is also a good idea to use two sets of router and firewall, one on
the control network-side, and one on the IT network-side. This way,
control system engineers can administer one router/firewall, and IT
engineers the other, eliminating conflicts. Each side can configure their
firewall as per their requirement.
DCOM requires a reliable network. The Internet, other WANs,

and even some slow LANs are not reliable. In these cases it must
be possible to tune time-outs or, worst case, change to another
transport protocol. Avoid using DCOM over WANs, and try as far
as possible to run automation protocols such as FOUNDATION™
Fieldbus or Modbus for the long distances from the devices in the
field in SCADA applications.
DCOM does not work well through firewall or router and across
the Intranet, Internet, domain, or workgroup. DCOM over
Internet is difficult because Network Address Translation (NAT) is
not permitted, since DCOM uses the true IP address. DCOM uses
a large number of ports with port numbers assigned dynamically.
Although the port range can actually be restricted, there will still
be too many “holes” in the firewall if a corresponding range was
opened. In short, DCOM is not “firewall friendly.” Therefore,
when an OPC client and server are located on different networks,
special solutions are required. Moreover, DCOM time-out and
retry is fixed in Windows and cannot be set. It works well for fast
LAN connections, but for low bandwidth connections such as
some wireless, modem, and satellite links, it does not perform
satisfactorily. Since DCOM and OPC are usually used within the
automation system, and not beyond, this is only very rarely a
problem. Most plants will never need to worry about this.
Probably the best way is to use DCOM within the automation

system and to integrate with the execution and business environ-
ment through Web technologies, avoiding DCOM limitations.
However, there are instances when DCOM needs to connect
across networks and domains. Software providing several
different solutions to these DCOM problems is available in the
market, primarily for OPC-DA. Since there is no OPC specifica-
tion, the different solutions are incompatible. Thus, there is no
simple way to connect an OPC client direct to an OPC server in
this special scenario. Instead, intermediate software is required to
put OPC messages in a “wrapper” using a special protocol and to
send it across to the other network, where another application
unwraps the original OPC message (Figure 3-8).
Figure 3-8. DCOM Is “Wrapped” in Another Protocol Across the Internet
The tunneller client and server applications can be installed in

every computer, or a single computer on the local area network
can be used as a logical gateway through which computers on the
other network can be reached. Regular DCOM is used between
the gateway computer and the other computers. For example,
when a single server or client is used, this computer routes the
tunnelled DCOM to the other computers on the local network. It
is not necessary to have a dedicated computer for tunnelling. The
tunneller application can run on one of the computers on the
network. For example, a tunnelling application can execute in the
same computer as OPC clients and servers.
Tunnelling applications may be using DCOM, proprietary layer

over TCP/IP, or a Web technology to transport data. Tunnelling
applications are software that executes in computers on the
network. Although the logical function they perform is that of a
gateway, the computer is connected on the network just like any
other (Figure 3-9).
Figure 3-9. The Tunneller Application Is a Computer on the Same Network

The tunnelling client functionality may even be built directly into

the OPC client.
Configurable DCOM Tunnelling

DCOM tunnelling is the simplest form of tunnelling. The protocol
used is still DCOM, but the tunnelling application permits fine-
tuning of time-out and retry to adopt it to the network environ-
ment (Figure 3-10).
Figure 3-10. Application for DCOM Tuning (Screenshot: ICONICS

GenBroker)
A DCOM tunnelling application can be installed in every server and

each client, or one tunneller server application can act as a gateway
supporting several servers on the local network. Similarly, a
tunneller client application can act as a gateway for several clients.
IP Port Tunnelling
Different applications are available that wraps DCOM into a
proprietary frame communicated through a single IP port (Figure
3-11). Using this scheme, only that single IP port in the firewall
need be opened to permit DCOM to be tunnelled through it.
Opening a single IP port in the firewall between the automation
system and the corporate Intranet is relatively secure since it is
within the company, and not the public Internet. However,
opening a wide range of ports would be too risky.
Figure 3-11. Application for IP Tunnelling (Screenshot: ICONICS

GenBroker)
Some tunnelling applications are able to provide compression and

encryption in order to optimize the throughput in low bandwidth
applications, and to ensure security and integrity of the data.
Web Tunnelling
When tunnelling DCOM across the public Internet it is necessary
to use Web technologies such as SOAP, HTTP, XML, and HTML to
ensure the communication is not blocked by firewalls. HTTP uses
port 80, which firewalls permit to pass (Figure 3-12). Because of
the way HTTP operates, opening port 80 in the firewall is the
more secure option, albeit not completely protected. Since the
transport used is HTTP, the server-side network needs to have a
Web server installed to provide this transport. This Web server
can be in the same or a different computer.
Figure 3-12. Application for Web Tunnelling (Screenshot: ICONICS

GenBroker)
It is important that the Web tunnelling solution really communi-

cates HTTP through port 80, and does not try to use some other
protocol through this port universally assigned for HTTP. The
reason is that application proxy firewalls check to assure the
protocol coming through is indeed HTTP and not another protocol.
This good firewall feature provides an additional level of security.
Windows has a scheme called COM Internet Services (CIS) designed
to transport DCOM over the Web through port 80. However, it is
not using HTTP and will therefore in many cases be blocked.
Windows XP Software Firewall

Windows XP service pack 2 introduced new software firewall
functionality that requires additional configuration for OPC
clients and servers if the firewalls shall be left on. For OPC
connections confined to clients and servers within one single
computer this software firewall does not pose a problem and
hence no configuration is required for the firewall.
Ideally the entire automation network shall be protected behind a

network firewall at the connection to the corporate LAN so that a
software firewall in each computer is not required. If the
Windows firewall is disabled the problem goes away and no
further configuration is required. This is the best solution for an
automation system.
If the Windows firewall is still desired it must be configured to

permit all the required server and client applications and proto-
cols to communicate across the network. Firewall exceptions shall
also include OPCEnum and the Microsoft Management Console
(MMC). Additionally, TCP port 135 must be opened for the
DCOM protocol (Figure 3-13). It is expected that in the future,
OPC client and server applications will automatically setup the
Windows firewall when they are installed.
Figure 3-13. Windows Software Firewall Exceptions
Programs and ports that shall not be blocked are easily configured.
It may be a good idea to document all firewall exceptions.
Windows also prompts if an application is being blocked, permit-
ting user to unlock the communication. If communication does not
work and the software firewall is the suspected culprit, temporarily
turn off the Windows firewall to see if it is the source of trouble.
License
Most vendors freely distribute CD with all their software and
many applications can be downloaded from the Web. Getting and
installing software is not an issue. However, software comes with
a license agreement and, to run most automation software, you
need to activate some form of license to unlock the software.
Licensing can be based on either hard key (a.k.a. “Dongle”) or soft
key. The program files are available for free—what you pay for is
the activation license. These days many large applications are
modular, permitting you to customize it to fit your needs by
selecting the necessary application components you want to
license. The cost of the license depends on the components
chosen, how many points or devices it supports and the number
of users in the system. Every vendor has a slightly different
licensing policy. Most applications show the terms and conditions
of the license agreement at the time of installation, but it is
common to skip to the next step without actually reading it. Make
sure at least one person in the company reads and understands
the agreement. There can be important points with regards to the
use of the software, including issues with patents etc.
Different schemes exist for counting “points.” Some applications

may count all the points configured in the database whereas other
applications count only the number of variables polled at any one
time. In the past, one sensor or actuator meant one piece of infor-
mation and a control loop perhaps ten values. In those days, the
point count was never very high. Today, networked intelligent
nodes can have a hundred pieces of data per sensor or actuator,
and several hundreds per loop. However, even though there are
hundreds of devices with hundreds of parameters each, only
some of those such as alarming and trending may be continuously
active. Other parameters may be scanned only when the operators
choose certain pages. For example, a process flow mimic screen
may display a hundred values, one from each device. While a
detail page may show a hundred different values from one device.
For example, if there are a hundred devices with a hundred
parameters each on the plant floor; you may only need a hundred
point license, not 10,000. However, in many cases going for an
“unlimited” license is the best option. Depending on how points
are counted and how much each cost, the price difference between
the schemes can vary greatly.
Most software can run in a demo mode, permitting you to test-

drive before making up your mind. The evaluation mode can
work in several different ways. For example, the demo may be
limited in the number of points that can be used, it may limit the
time for each session, or it may run for only a limited time.
Operator visualization is typically the main software in the

factory, having the most number of nodes and points. Licensing is
typically available with several flexible schemes to tailor capa-
bility to actual needs while reducing cost. Although every vendor
has a slightly different scheme, the basic options are:
• Development
• Run-time
• Client
• Viewer
• Thin-client
For example, a plant may only need one or a few “development”

licenses (i.e., users that can do system configuration). The other
computers can be “run-time” only. Some software allows you to
do development, at no cost at all, eliminating the need for special
development license. Others packages charge extra for develop-
ment capability. Development licenses are ideal for computers
with alarm and historical data servers, as these computers are
rarely used by people and can therefore double as engineering
stations. Other workstations can have “run-time” license (i.e., just
plant operation, no system configuration).
There may also be a client license that only permits remote

servers; for example, all I/O, alarm, and historical loggers run on
server computers elsewhere on the network. While run-time and
client-only permits the operator to both read and write values,
there is often an even simpler “viewer” license for which all
values can be seen. However, the user is not able to change any
values or actuate. Viewer nodes may be ideal for people that just
need to keep an eye on what is going on, but who are not trained
to operate the process. Although there is typically no restriction to
the number of computers on which you can install the software,
there is usually a limit to the number of simultaneous users for
the client-only and view-only nodes.
Visualization for operators and others can be achieved through

thin-client schemes such as browser for Web server or terminal
emulator for terminal server. Web browser clients require a Web
server such as the Windows IIS to be installed on a computer on
the network in the automation system together with the Web visu-
alization server (see further in Chapter 5). Similarly a terminal
server needs to be installed on the network in order to use
terminal emulation software for operator visualization.
Obviously, there is no limit to the number of thin-clients, or where

they are located, but the number of simultaneous users is limited
by the size of the server license. It should be noted that because of
the inefficiencies of Web technologies, displaying data in Web
browsers is significantly slower. Therefore the Web browser solu-
tion is not really suitable for the operators at the automation level,
but are well suited for remote operation or monitoring from the
execution or business levels. At the automation level it is better to
use regular OPC and other DCOM clients. Similarly, the terminal
server scheme puts significant loads on the server also resulting in
slower performance.
Apart from license for the client and server applications, it is also
necessary to have license for operating systems and other infra-
structure such as the SQL database. MSDE is a small-scale
database that can be used for free with a limited number of users.
MSDE is thus an attractive option for a small-scale system.
Similarly the IIS Web server is free with a limited number of users,
but requires a license to be purchased that supports many users.
Key
Licensing for automation software is typically controlled using
keys. The key can be a hardware key, which is simple device
plugged into the parallel port or USB port of the computer. Manu-
facturers have different schemes such as single user license and
multi-user license for different numbers of users that can be active
at any one time. Depending on the number of stations and the
number of users that need to access a particular software in the
automation system, it may make more sense to use either one or a
few single-user license, or go for a multi-user license.
Multi-user licensing is typically installed on a central computer on

the same network as the different client stations. The multi-user
scheme permits a system to have unlimited numbers of
networked workstations in the control room as well as on the
plant floor, and where a license limits the number of users that are
logged in regardless of which computer they are using. In a
centralized multi-user license scheme, the node controlling the
license becomes critical. If the multi-user scheme is selected, make
sure the software supports redundancy for licensing, and use a
second computer as the backup license control node (Figure 3-14).
Operator visualization software usually includes a utility that
allows you to check the licensing for your system.
Figure 3-14. Redundant Multi-User License (Screenshot: SMAR SYSTEM302)
Soft and hard keys prompt you to think about licensing. It is

impossible to run the software beyond the trial period without
purchasing the proper license, ensuring the software is not
pirated. However, software technologies such as ActiveX make it
possible to include licensed components from scores of vendors
into a container. Typically, ActiveX components do not have indi-
vidual key protection; indeed it would be hard to manage.
However, there are terms and conditions for using ActiveX
components that you should read. It is easy to copy ActiveX
components from one computer to the other because they are not
protected. For example, ActiveX components installed with the
evaluation version of software from one vendor’s library may be
used full run-time in software from another vendor, as well.
Violating such a license agreement, even by accident, is easy, if
you are not careful.
A system may have many applications from different software

vendors. This means many licenses and many keys. It is not
uncommon that parallel port hard keys don’t work well when
stacked—for example, installing many applications using a hard
key on the same computer may have issues. Check with the
supplier for any issues. If possible, install the hard keys on
different computers.
Software that runs on fault tolerant servers may require a special

key to ensure the voting redundancy works and the key itself
does not become a single point of failure (see Chapter 10).
Soft Key
The software key scheme is based on a unique identifier for the
hardware. The unique identifier is based on, for example, the hard
disk and other aspects. After installing the software, the license
utility runs. The license utility provides a code unique to the
computer. The code is then registered with the software vendor
via email or online over the Internet. The vendor provides a key
locked to the unique hardware code. The license key is then
entered in the license utility. The application will only run with
the key for the designated computer. Transferring the license from
one computer to another requires a removable disk such as a
floppy or thumb drive (i.e., the original computer must still be
fully functional to move the license). If the computer has some
kind of failure, this may not be possible.
Hard Key
The hardware key is based on a very small device, typically no
larger than a connector, plugged into the computer parallel or
USB port (Figure 3-15). The software only executes if the license
manager can detect the presence of the hard key. Transferring the
license from one computer to another is as easy as moving the
hard key.
Figure 3-15. Hard Keys for USB and Parallel Port (Courtesy: SafeNet, Inc)
Lost or Damaged Key

Hard keys, like all hardware, have a life span and may eventually
fail. Soft keys are installed on and tied to hard disks that may also
eventually fail. Most software can operate in an evaluation mode
for a limited number of days or weeks in the absence of a valid
license key. This may tie the plant over until a replacement key
has been arranged. Check with the software vendor about what
kind of backup plan is provided for the critical applications
required in your plant.
For this reason it may be a good idea to think of hot-standby redun-

dancy—for example, have a second computer with a backup license to be
used in case the primary fails.
The software license can be lost due to hard disk crash, moved or
copied license file, deleted license file, formatted hard disk, change
of file system, partitioned hard disk, some defragmentation utili-
ties, change of computer name, uninstallation of the licensing
utility, or reinstallation of operating system etc. In this case, it is
necessary to run the license utility again to obtain the new hard-
ware code and submit this to the vendor to generate a new key.
Soft Key vs. Hard Key

Most applications can be purchased with an option for either
hardware key or software key. The advantage of software key
includes the fact that you can get it very quickly. You can, for
example, download software from the manufacturer’s Web site,
register the hardware code online, and get a license key almost
instantly. A hard key takes days or weeks to manufacture and
ship. Software keys are easily upgraded to enable more function-
ality, more points, more users, etc. The software key is invisible
and therefore not stolen. It cannot easily get lost.
Hardware keys may cause conflicts with other devices on the

same port such as printers, scanners, external drives, and other
hard keys. Hard key usually has an additional cost, plus shipping
and handling. To provide continuous operation in case of a
computer failure, it may be a good idea to have redundant
computers with independent license, if a software key is used to
permit operation from the other computer while waiting for new
license key for a replaced or repaired computer.
If you know that the system will soon have to be changed, or expanded, it
may be a good idea to use a software key.
Advantages of hard keys include the fact that hard disk failure, or
any tampering with files, does not affect the key. The hard key can
easily be moved to another computer, even after the original
computer has suffered a complete failure. Hard key may be the
best choice for small systems not having hot-standby redundancy.
Hard key is quickly transferred to a replacement computer in case
of failure, thus minimizing downtime.
Exercises
1. Do applications stop executing when a new user logs in?
2. Which DOS command can be used to check IP networking?
3. Which is the preferred setting in the identity level tab for

DCOM security of an application?
4. Which well-known port number is used by HTTP?
5. Can DCOM time-out and retry times be adjusted?
References and Bibliography

1. Berge, Jonas. Fieldbuses for Process Control: Engineering, Oper-
ation and Maintenance. ISA – The Instrumentation, Systems,
and Automation Society, 2002.
2. Server Operating System, DCOM Technical Overview,

White Paper. Microsoft Corporation, 1996.

Setup: Application Execution

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Setup: Application Execution

Uploaded by

Copyright:

Available Formats

3

OPC, SQL, OLE_DB, ActiveX, and other Microsoft software tech-

Windows 95, 98, and ME (Millennium Edition) have a number of

Therefore, it is a good idea to eliminate non-NT-family computers,

Keep in mind that you need administrator rights to install OPC

If an application runs as an NT service, it can optionally start up

It may be a good idea to create an account specifically for the purpose of

OPC DA servers typically do not run as an NT service. Access is

Windows Auto Login

Support for several different networking protocols is built into

Figure 3-1. Network Architecture

For greater security, the router should have a built in firewall to

The Internet is the easiest way to have remote access to the

Local Area Network (LAN) Configuration

The PING command can be used from the command prompt to

Figure 3-2. Ping to Verify Networking (Screenshot: Microsoft Windows)

Remote Access Configuration

Figure 3-3. Dial-in Using Remote Access Server (RAS)

RAS has a security advantage since the connection, unlike the

Remote Access Server (RAS)

Remote Access Client

cations can be run in multiple sessions without add-ons. No appli-

Automation software installation and maintenance on every client

Although terminal services make it possible to use simpler and

Terminal services do not use HTTP on port 80 but another protocol

Remote Access Server (RAS) or Virtual Private Network (VPN), in

Windows XP Service Pack 2 introduced some DCOM security

Network Access Control

Domain vs. Workgroup

Additionally, for workgroup network access in Windows XP it is

Figure 3-4. Workgroup Network Access Requires More Configuration

It may be a good idea to consult the IT department in the plant to find

Typically, all computers in an automation system should belong to

Indeed, it is a good idea to leave the automation system protected by not

Users & Passwords

It is a good idea to create user groups based on different roles, such as

Figure 3-5. User Accounts and Groups (Screenshot: Microsoft Windows)

Password and lockout policies, assignment of rights, and other

Figure 3-6. DCOM Configuration Console

The DCOMCNFG console permits configuration of these aspects

Settings have to be done for client and server applications as well

Before configuration starts it is a good idea to determine and document

The proper way to configure DCOM is to assign access and launch

Use “Everyone” when doing initial system integration and tests.

• Enable Distributed COM = checked

It is a good idea to use only the overall default properties as much as

Launch and configuration security normally does not have to be

In most installations, all network protocols are based on TCP/IP, so it may

Because it is more difficult to manage a system where the computers

Figure 3-7. Custom Security Setting of Configuration Permissions for OPC

However, OPC servers typically use custom configuration permis-

If a server runs in unattended operation, such as in the case of a

Table 3-1. Typical Server-Side Configuration

The client needs to be configured to enable callbacks (Table 3-2).

Table 3-2. Typical Client-Side Configuration

If clients and servers don’t work together, refer to Chapter 6 for

DCOM Beyond the LAN

DCOM requires a reliable network. The Internet, other WANs,

Probably the best way is to use DCOM within the automation

Figure 3-8. DCOM Is “Wrapped” in Another Protocol Across the Internet

The tunneller client and server applications can be installed in

Tunnelling applications may be using DCOM, proprietary layer

Figure 3-9. The Tunneller Application Is a Computer on the Same Network