Enterprise Integration & System Migration

5
Enterprise
Integration &
System Migration
Traditionally, the automation system has been an isolated island—
not connected to anything. However, new methods of operation
require remote access for visualization and supervision of the
controls through a live link. This requires network access to the
automation system from other parts of the enterprise. Up-to-date
data from the automation system is required for activities and deci-
sion support at the execution and business levels. Therefore, the
automation needs connectivity to the upper levels. The control-level
network, therefore, has to be connected to the operations informa-
tion network and business logistics network (see Figure 5-1).
Since it is paramount to protect the integrity of the automation

system, a firewall should be used between the automation system
and any other networks. For administrative reasons, it is better to
use two firewalls back-to-back. This way the responsibility for the
automation-side firewall can rest with the automation systems
engineers, while the responsibility for the IT-side firewall rests
with the IT network administrators. This leaves a clear demarca-
tion line for the responsibilities. Different forms of firewalls and
security methodologies are discussed in Chapter 10.
Since packet-filtering firewall is used between the automation

system and the rest of the enterprise, it is necessary to use Web
technologies to bring the data across the networks. Moreover,
automation networking protocols and software interfaces such as
OPC are not supported by common IT applications and business
software. Therefore, standard IT technologies for the Web are
ideal for integration with higher levels of the enterprise. Execution
163
164 Software for Automation
systems cross the information boundary between automation and

business systems. One of the functions of the software at the
border between the automation level and the execution level is to
take OPC and OLE_DB data and present it in a Web-based format.
Today the network technology used at all three levels is the same:
IP on Ethernet. The systems and applications are technically on
the same network, albeit usually on separate IP subnets. The
result is homogenous network architecture.
Figure 5-1. Traditional Networking and Enterprise Levels
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 and other security equipment
are necessary to protect the control network from problems origi-
nating from the execution and business levels.
Since the network infrastructure technology at the different levels

is now the same, and the applications are modular rather than
monolithic, it is very hard to draw a distinct line between automa-
tion software and execution software. For example, the SQL server
database now often found as an integral part of the automation
systems’ operator visualization software has traditionally been
seen as the core of MES software. In the past, the automation
system such as a DCS did not have the database capacity for long-
term trends; it left that to the separate historian applications part
of the execution system which had a totally independent data-
base. Today, an SQL server often serves as the interface between
automation and execution.
Chapter 5 – Enterprise Integration & System Migration 165
The automation application is now populating the shared histo-

rian server “data warehouse” with data, with the execution soft-
ware clients consuming it. The applications in business systems
are transaction-based, using the SQL database as the interface
rather than interfacing direct application-to-application. The
automation and execution applications are merging into a single
“control domain” below the enterprise domain. A similar blurring
of the traditional boundaries between operation execution and
business logistics is also occurring. Throughout the three levels,
TCP/IP on Ethernet is the network platform of choice.
Simply connecting a business system to the automation system

would overload the business system and network with data. Soft-
ware at the execution level extracts and distills automation
system data to the information required for decision support at
the business level. This typically means reports of integrated
totals, summary charts, as well as easy to grasp Key Performance
Indicators (KPI) numbers.
Existing automation systems found in plants, buildings, and on

production lines are not based on open technologies and do not
have connectivity required to integrate with the execution and
business levels to reap subsequent benefits. Therefore, to achieve a
totally integrated system, a plan for change needs to be put in
place. The long-term objective is usually to replace the entire DCS
or PLC to benefit from lower-level fieldbus networking, but short-
term this is often not feasible. Therefore, the first step is to make
the legacy system coexist with the newer systems. Such integration
usually entails replacing workstations and software of the existing
automation system with modern applications, based on OPC.
Having the automation system connected, particularly perma-

nently, to the enterprise LAN and outside world has security
issues addressed in Chapter 10.
Web Visualization
Operator visualization is performed at the automation level by
operators at workstations on the control-level network in some
sort of control room, typically not from other places. However,
occasionally it may also be advantageous for other persons to
remotely monitor subsets of information from the process, produc-
tion line, or building from anywhere in the enterprise using a
simple Web browser. A Web browser is a “thin-client,” meaning no
pre-installed software or configuration is required (see Figure 5-2).
Web technologies work well behind a firewall and, therefore, there

is no need to open any ports on the client-side network firewall.
Since firewalls need not be opened, the network where the
browser client sits remains very secure. However, the firewall on
the network where the Web server sits needs to have port 80 open.
This leaves the server network somewhat vulnerable, unless you
implement other security measures. You should think twice about
linking the control system to the rest of the enterprise if the
system is very critical because the information network and busi-
ness networks connect to the public Internet.
Figure 5-2. Thin-Clients at the Execution and Business Levels Show the
Same Data as Thick-Clients at the Automation Level
Use of Web technologies does not necessarily mean use of the

public Internet, with its associated security risks. Many simply
use Web technologies within the Intranet and even just within the
automation system. It is simply a practical way of presenting
information on or off the World Wide Web.
WARNING—The public Internet is a dangerous place.

Connecting the automation system to the public Internet has
many security implications. It is recommended that access to the
automation be restricted to the corporate Intranet. For more
information, see Chapter 10.
Web Server
Web visualization for automation exists with different degrees of
sophistication. Plain Web visualization simply takes a static snap-
shot on demand of the regular graphics displays with values,
presenting them as an image in the Web client browsers. This thin-
client scheme does not provide dynamic display updates to contin-
uously show what is happening, and it does not enable any action.
Advanced Web visualization allows operators to load, login, view,

and interact with animated graphic displays remotely from virtu-
ally any computer on a network. Apart from live viewing and
changing parameters, it is also possible to view trends and
manage alarms. This thin-client scheme is based on ActiveX tech-
nology. Therefore, advanced Web visualization requires Web
servers and Web browsers that support ActiveX. The viewer is an
ActiveX plug-in hosted by the Web browser. No software has to
be pre-installed in the client. The viewer plug-in automatically
installs itself in the client software over the network from the
server when the user visits the graphic page. Similarly, all neces-
sary ActiveX controls and components used in the graphics are
automatically deployed from the server. The Web server supports
multiple remote users using nothing more than regular Web
browsers (see Figure 5-3).
Figure 5-3. Web Browser with Viewer ActiveX
The server application for Web visualization generally runs on the

same machine as the Web server application. This machine is typi-
cally dedicated for the Web, with all other applications such as
OPC servers running on other machines. One part of the Web
visualization is responsible for serving up the graphics, including
deployment of ActiveX components. Graphic files are down-
loaded by the browser in their native format but packaged within
a firewall-friendly HTML wrapper. The advantage of this plug-in
scheme is it is displayed exactly as designed (i.e., WYSIWYG or
What You See Is What You Get). The other part is Web tunnelling
of OPC values from all kinds of OPC servers, such as hardware
and other applications, from a multitude of vendors.
Graphics that shall also be used for Web visualization shall use
VBScript or Java script instead of VBA script.
Web Configuration
The first step to set up a server for Web-based visualization is to
install a Web server such as the Microsoft Internet Information
Server (IIS). The next step is to Web-enable the graphic files. The
same files that display in the operator visualization’s native
displays are used to generate the files for Web visualization. The
graphics design tools contain Web publishing wizards for putting
the file in an HTML wrapper and for establishing references for
loading ActiveX components. as well as links to other graphic
pages. The graphics tools have wizards and templates to simplify
creation of a page where users can log into the system. The system
integrator does not need Web design or HTML knowledge to
publish Web-enabled pages. Lastly, the graphic files are uploaded
on the Web server.
It may be a good idea to create a user group in the Windows security

specifically for Web access.
Browser Plug-In Authenticity

ActiveX objects must be installed on the client computer to appear
in graphic displays on remote Web browsers. The Web browser
automatically loads the CAB files, as necessary, delivered from the
server without manual intervention. The type and number of
components required depends on display contents. On a low
bandwidth network, such as dial-up to the Internet, this process
can be slow at the very first connection.
An ActiveX component is a powerful piece of software with full

access to resources in a computer. A malicious component could
wreak havoc with a computer. Loading an ActiveX from the Web
onto a computer can be a security risk. Therefore, it is important
to know the source of the component and assure it has not been
tampered with to perform a malicious activity. In order to trust a
component you want to know who made it. You also want to
make sure it has not been altered.
A component can be digitally signed by the publisher to assure its

authenticity. The digital signature is based on a digital publisher
certificate, hashing, encryption, and public and private keys. The
digital certificate is issued to the software publisher by a reputable
certifying authority. The software publisher generates a signature

for the component and includes it in the component. Windows
warns the user before a component is installed from the Web. By
extracting the information, a component with a digital signature
will be identified with description, publisher, and certifying
authority (see Figure 5-4). Unsigned components do not have any
information and are therefore shown as unknown.
Figure 5-4. Digital Certificate for ActiveX Component
The independent certifying authority ensures that the publisher of

the component does not claim a false identity. Based on the certifi-
cate, it is possible to accept or reject installation of the component.
Pages with complex graphics may require many components to be
loaded the first time, prompting the user to accept each one.
With a great deal of time and effort, cryptographic keys can theo-
retically be cracked and thus publisher certificates and component
signatures may theoretically be falsified. Therefore, publishers
must renew their digital certificates from time to time. From the
digital signature, it is possible to determine if the signature was
made using an expired certificate or if the certificate has expired
since signing.
WARNING—Make sure to verify authenticity before down-

loading and installing any components from the Web. Install
only digitally signed components from reputable publishers.
Make sure software is signed with a certificate that was not
expired at the time of signing.
Data Feed
OPC, OLE_DB, and other COM client-server schemes are two-tier
solutions (i.e., a client-tier and a server-tier). This is a very
powerful and high performance solution that works well on a
private LAN such as the automation system’s control network.
However, when working between networks, such as the corporate
Intranet or public Internet, considerations must be made with
regard to security as well as the prospect of a very large number
of users. The two-tier scheme gives a direct connection to data,
exposing it to the outside. Because servers are open for access by
clients, the servers are not well protected against malicious or
unexpected behavior. See Chapter 10 for more information on
security.
However, a distributed three-tier environment, or n-tier, solution

uses an intermediary such as a Web server that only gives indirect
access to the data source, thus protecting the data. A browser
front-end interacts with a middle-tier Web server, which in turn
communicates with a back-end database server for storage (see
Figure 5-5). That is, a Web browser is the user interface (presenta-
tion layer) running on the client workstation. The application
logic (business layer) and storage (data layer) are hosted together
on the same or separate servers where the underlying data is
protected. Remote applications do not have direct access to data.
The Web server retrieves the data from the actual data source and
returns it to the remote application. The n-tier architecture
provides easier scalability for a large number of users and
provides better security.
Figure 5-5. “N-tier” Architecture Protects Data
The interface for database data is called Remote Data Service

(RDS) and may be used for historical trend data as well as alarm
and event log. For live OPC data, Web tunnelling is used, as
explained in Chapter 3. Firewall friendly Web tunnelling of OPC

based on HTML or XML is less efficient and not fast enough for
process operators. Therefore, Web visualization is not used at the
automation level, only for levels 3 and 4.
For the future, OPC-UA (Unified Architecture) is set to offer the

best of both worlds. Provided operating system vendors can agree
on an interoperable platform of Web services, OPC-UA will
provide connectivity across platforms and will also make it easy
to select higher performance binary messaging for greater
throughput when supported in both ends.
Enterprise Integration
At the lower-end, a modern automation system integrates with
sensor and actuator hardware networked using fieldbus tech-
nology. At the upper-end, the automation system integrates with
execution software applications that, in turn, integrate with busi-
ness software applications. An MES proactively manages manu-
facturing processes, and an ERP system proactively manages busi-
ness processes. This is where automation software meets regular
IT. While the automation system handles visualization and
control, the MES does track & trace, performance analysis, main-
tenance, and document management. The ERP, in turn, handles
finance, order management, and logistics.
The need for enterprise integration is driven very much by e-busi-

ness. In an e-business scenario the initial delivery time promise
requires knowledge of machinery and processing equipment
availability as well as raw material inventory. This information for
decision support must come from diagnostics and measurements
ultimately originating from the shop floor. Orders from customers
must find their way into the production planning, individual
product items down to detail production scheduling, and, lastly,
as the required machine and equipment settings. Once in produc-
tion, fulfillment progress updates, quality reports, and so forth,
pushed to the customer are derived from information percolated
up from field measurements. Throughout this process, the
production, quality, and maintenance departments need their
specific information. For example, there are lots of bi-directional
transactions between the layers and a fully automated solution
requires integration between the systems at all levels.
The connectivity characteristics are very different at the different

levels of the plant hierarchy. At the lower-end, network protocols
such as FOUNDATION™ Fieldbus have very tight interoperability

including strong data typing and definition of semantics for the
data. At the automation level, OPC and OLE_DB provide rela-
tively tight connectivity but do not cover semantics and provide
great flexibility for data types, thus requiring some configuration
and possibly scripting for interpreting the data. Between applica-
tions at the MES and ERP levels, the integration is loose, generally
requiring special data mapping applications or even drivers in
order to patch data from sources to consumers together. Loose
coupling means more work for the system integrator, and thus
higher costs for the end-user. For many proprietary systems at
automation, execution, and business levels, integration is not
possible at all, since database formats and application interfaces
are hidden.
Traditional systems for automation, execution, and business are

usually monolithic having proprietary interfaces between insepa-
rable applications that cannot be freely chosen. The trend at the
execution and business levels is now towards open interfaces and
applications based on Web technologies. All applications at the
execution level are very much about consolidating information
from various sources, compiling the data into reports and summa-
rizing them into key performance indexes. Therefore, it is impor-
tant that all underlying data sources have open interfaces based
on specifications, such as OPC and OLE_DB, to provide easy
access to the data. Some also support ActiveX and VBA, making it
possible to include information in other displays. Similarly, MES
applications must have open interfaces to exchange data among
themselves and to make it available to higher-level business appli-
cations.
Traditionally, the automation system and execution system have

separate databases. It is still common that the plant information
management system (PIMS) is a stand-alone application that
interfaces to the automation system through a driver or OPC.
However, it is increasingly common that a powerful SQL based
plant information database performing trend and alarm & event
logging is part of the automation system. At the execution level,
the primary function is increasingly to provide a “portal” to
publish consolidated information and summaries (see Figure 5-6).
Figure 5-6. Web Portal
At the execution and business levels, the interfaces between appli-

cations are not well defined and interchanges are occasional,
across firewalls and domains, and even between different operating
systems. At these levels, exchange is based on message transactions
between loosely coupled applications. Therefore, Web services
and the Microsoft .NET framework are more suitable than DCOM.
Applications at this level store and process huge amounts of data
for very many users. The .NET framework is scalable to multipro-
cessing platforms and therefore better handles large loads.
Level 3 - Execution
The execution level is the level immediately above the automation
system. The MES level may be tying together many underlying
automation systems for different areas, from different suppliers,
using different generations of technologies. An amalgam of
process control and factory automation, such as a pulp mill and a
paper machine, will be tied together at the MES level. Clearly
such integration is easier and less costly if the underlying automa-
tion systems are based on open technologies. Software applica-
tions at this level have a product focus and are concerned with
operations management. Servers and workstations at this level are
tied together using the operations information network that
connects to the underlying automation system through firewalls.
Large volumes of live data from the PAS must be passed to the
MES level for reporting. To secure the automation system, a fire-
wall is required at the network interface to the MES level. The use
of a firewall means Web technologies with poorer throughput
must be used. As a result, the MES function is often split into two
sublevels: the lower part is an MIS (Manufacturing Intelligence

System) that aggregates data the upper part presents, and use for
higher level control.
OPC-XML-DA is suitable to bring data from the servers at the

automation level through the firewalls to the clients at the execu-
tion level. A “wrapper” application can act as a gateway to make
DCOM-based servers accessible using OPC-XML-DA. A single
Web server and wrapper application can act as the gateway for
several DCOM-based servers.
MES activities include tracking and reporting on costs, produc-

tion, inventory, manpower, raw materials, spare parts and energy
usage. MES also manage statistical quality analysis and control,
personnel management. MES applications are also responsible for
establishing detailed production schedule, including maintenance
and transportation, based on overall schedule from level 4. Basic
MES functions include:
• Detailed scheduling
• Resource management
• Production tracking
• Product definition management
• Product dispatching
• Production execution
• Production analysis
MES is not one but a group of software categories which includes

applications such as:
• Laboratory Information Management System (LIMS)

• Plant Information Management System (PIMS)
• Computerized Maintenance Management System (CMMS)
• Enterprise Asset Management (EAM)
• Warehouse Management System (WMS)
• Scheduling/Dispatch (APS)
• Statistical Process Control (SPC)
• Statistical Quality Control (SQC)
Key software elements for data-mining and presentation solutions

at the MES level include SQL database, reporting, Web portal, and
transaction mapping.
SQL Database
If a plant information management database is not already
present in the automation system, one needs to be added at the
MES level. An industrial database adds modules for alarm genera-
tion, alarm capture, trending, and so on, to a basic SQL database
server. Using alarm and trending modules based on OPC
collecting live data from multiple sources throughout the plant,
factory, or building becomes a simple point-and-click operation.
Use of OPC, in turn, means data can be captured for fieldbus and
Ethernet type networks and from DDE servers. If the database
provides ODBC and OLE_DB interfaces, reporting and analysis
tools can connect and extract the data much easier. These indus-
trial aspects are described in Chapter 4.
Reporting
Reporting software collects unmanageable volumes of incompre-
hensible data from diverse sources such as OPC servers as well as
logged data from databases, and turns it into knowledge. Data is
automatically aggregated, processed and formatted in a report
and then displayed, saved on disk, printed as hard copy, fax or
PDF files, published to Web servers, or emailed to selected recipi-
ents or the entire organization. Manufacturing intelligence reports
published to a Web server can be accessed from the corporate
Intranet or the public Internet using a regular Web browser
restricted using password security on a need-to-know basis.
Reporting tools let users navigate archived reports and manage
report generation aspects, such as trigger scheduling.
Report formats can be freely designed, and data picked using

OPC tag browser plug-in tools for the familiar Microsoft Excel
(see Figure 5-7). Wizards are used to schedule reports based on
time/date, value/alarm/event, or on demand. Pre-formatted
templates include regulatory reports such as for FDA and EPA, as
well as percent Down Time (DT) and Operational Equipment
Effectiveness (OEE), and for SQC or lot genealogy. Also note that
OEE is sometimes known as Overall Equipment Effectiveness.
Reports and KPIs can be tailored to suit the different decision-
makers, such as VP of operations, plant manager, process engi-
neer, facilities engineer, quality manager, maintenance managers,
shift operators, etc. Once configured, the design tool remains

invisible while the reporting operates unattended and handles
archiving or deletion or old reports.
Figure 5-7. Excel Plug-in for Report Design (Courtesy: ICONICS)
Reports can be made based on data mined from databases such as

from Oracle SQL or SAP as well as from historians such as Aspen-
Tech’s InfoPlus.21 or OSI’s PI. Web services technology can be
used to data mine a Web service enabled database over the
Internet or Intranets. For example, NASDAQ and SAP informa-
tion can easily be integrated into reports. Define your own KPI
and plant metrics and use mathematical functions such as SPC,
totalization, running average, etc., to compute them.
Reports generated at the MES level often are disseminated beyond

the immediate plant, factory, or building, shared throughout the
enterprise. In multinational companies, reports are generated in
local languages for each subsidiary are possible if the reporting
tool supports language switching.
Portal
Reports are useless unless they are easy to locate. A portal server
makes it easier to publish, share, subscribe to, and find reports
and other information, since it is kept in one place. A portal is a
“digital dashboard” made up of different “Web parts,” with each
having a specific function such as access to reports, relevant links,
and company news. For example, a portal is a Web part container
(see Figure 5-8). The portal is viewed through a Web browser that
users can customize to view live or historical information.
Figure 5-8. Web Portal with “Web Parts” (Courtesy: ICONICS)
A portal based on Microsoft SharePoint server makes it easier to

ensure that users get relevant and timely information. It is
expected that in the near future many third parties will make
industry specific Web parts available for MES functions that use
Web services to access data.
One benefit of Web-based MES and business applications is that a

mobile workforce can access it while on the move, from hotel
rooms, or from “hotspots” at airports or elsewhere. Non-Web-
based applications, like most level 2 automation software, need
IPsec VPN infrastructure.
Transaction Mapping
MES is not one application but many different applications. Infor-
mation for MES has to be aggregated from many different sources.
MES reports have to be disseminated to many different destina-
tions. Therefore, there will inevitably be many instances where
data has to be bridged from one source to another. The data
bridging required may be from an OPC server to database, Web
service, or other OPC server. Bridging may be from a database to
OPC or to another database. Data mapping is therefore a core
component of an MES solution. Transactions are mapped visually
from source to destination (see Figure 5-9). Transactions can be
triggered based on different criteria.
Figure 5-9. Transaction Mapping (Courtesy: ICONICS)
MES is a crossroads for bi-directional information flow. Data is

percolated from the plant floor up to business applications, and
commands are propagated from business applications down to
the plant floor. The importance of open interfaces at the MES level
can therefore not be overstated.
Level 4 - Business
The business level, or enterprise domain, is the level immediately
above the execution system. The business level may be
exchanging information with many underlying MES applications
for different functions. Clearly such integration is easier and less

costly if the underlying systems are based on open technologies.
Software applications at this level have a customer focus and are
concerned with collaboration within the enterprise and the
upstream and downstream supply chain. Servers and worksta-
tions at this level are tied together using the business logistics
network that connects to the underlying execution system.
Formerly called S95 by the SP95 group, the ANSI/ISA-95 series on
enterprise-control system integration (ISO/IEC-62264) deals with
the functionality of execution and business applications and the
interface between them.
Software at the business level is concerned with all aspects of the

enterprise, not just production. Basic business functions include,
for example: sales and distribution, materials management,
production planning, quality management, plant maintenance,
human resource, financial accounting, and asset management.
Among these, production planning is the activity that really ties in
with the underlying MES applications. Level 4 activities related to
manufacturing include:
• Raw material and spare parts usage, inventory, and

purchasing
• Energy usage, inventory, and purchasing
• Goods in process and production inventory
• Quality control
• Preventive and predictive maintenance planning
• Manpower use
• Production schedule
Business level software is not one application but a group of

applications including:
• Enterprise Resource Planning (ERP)

• Supply Chain Management (SCM)
• Customer Relationship Management (CRM)
• Material Requirements Planning (MRP)
• Manufacturing Resource Planning (MRP II)
• Logistics Systems
The Web portal concept is also gaining popularity for business

level software. Already ERP solutions exist where the user inter-
face is a Web browser. It is expected that, in the near future, third
parties will make Web parts available for business functions that
use Web services to access data.
Automation System Coexistence & Migration

Many new automation systems are installed during automation
revamp or expansion of an existing plant or building. An automa-
tion system revamp is usually phased. The first step of system
modernization is typically to replace only the operator consoles
and their software, while I/O nests and controller hardware
remains the same. At times, it is not feasible to replace the entire
system with sensors and actuators in one go. In the case of expan-
sions of facilities and factories, for example, technology has
usually moved on quite a bit since the original system was
installed, and expansion will most likely use a much higher
version of the system. The expansion may even use a totally
different system altogether, often from a different supplier. In case
of both migration and expansion, it is necessary for modern and
legacy automation to coexist.
Legacy Coexistence
One aspect of system integration is to connect the new system
with the old existing systems to permit the operators to handle
any control loop in the entire plant, factory, or building from the
same workstation. The various automation systems should inte-
grate at the automation level, not just at the MES level or plant
information database, in order to ensure operators can drive the
plant from a single dashboard.
Some independent third-party companies now specialize in

providing OPC servers for interfaces and gateways to legacy DCS
and PLC. This makes it possible to integrate existing automation
systems in plants and factories with modern control systems.
Console Migration (OPC and HMI)

As existing legacy automation systems become old, there may be
a need to replace operator consoles and software. These systems
often use special hardware no longer supported and, therefore,
impossible or expensive to repair. One of the main reasons for
migrating to OPC-based workstations is the high cost and
unavailability of spares and consumables for old consoles.

Secondly, there may be a corporate demand for more information
to percolate up from the plant floor. The proprietary nature of
legacy systems prevents use of sophisticated automation applica-
tions and integration with the enterprise. Upgrading operator
consoles, while preserving the rest of the hardware and the
control strategy configuration, extends the life of existing system
with minimum expenditure. It is even common to keep the orig-
inal console during the transition period for a smooth migration.
A number of companies specialize in the development of OPC

servers for legacy systems, as well as OPC client solutions that
allow old consoles to be replaced while I/O hardware and
controls remain the same. In a phased migration where worksta-
tions and software have already been replaced, the second step is
to replace sensors, actuators, and controller hardware. The special-
ized DCS migration solutions provide more than just the OPC
server. These solutions may include utilities for converting the
DCS database and graphics, including trends, alarms, faceplates,
and tuning. The new modern OPC-based solution can have the
same look and feel as the original consoles, including dedicated
keyboard and trackball.
Upgrading the console is not the complete solution, only the first
step. First, it is necessary to migrate to modern technology to
make improvements possible, and then add value on top of this
new technology (i.e., immediately after a migration little or new
capability has been added, but a platform for a suite of improve-
ments has been created). Once the system has been migrated to
OPC it becomes much easier to make future software additions.
Many enhancements can be done without upsetting running
production.
Also, keep in mind that one day the new system will inevitably be
the old system that has to be replaced at a future upgrade. Plan
for that future upgrade now by using a system based on open
technologies in order to ensure easy integration with the next
generation system. A system based on proprietary technologies
will have no connectivity with future systems and forces you into
a situation for which the same vendor can offer a migration solu-
tion without competing offers.
Exercises
1. What is a “thin client”?
2. Is it possible to tell if an ActiveX plug-in component about

to be installed from the Internet is malicious or legitimate?
3. At which level of the enterprise hierarchy is the PIMS

located?
4. Is it possible for a DCS based on Unix to coexist with a

system based on Windows through OPC?
References and Bibliography

1. Berge, Jonas. Fieldbuses for Process Control: Engineering, Oper-
ation and Maintenance. ISA – The Instrumentation, Systems,
and Automation Society, 2002.
2 ANSI/ISA–95.00.01–2000, Enterprise-Control System Integra-

tion Part 1: Models and Terminology. ISA – The Instrumenta-
tion, Systems, and Automation Society, 2000.
3 Microsoft Windows DNA for Manufacturing, White Paper.

Microsoft, February 1999.

Enterprise Integration & System Migration

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

Enterprise Integration & System Migration

Uploaded by

Copyright:

Available Formats

5

Since it is paramount to protect the integrity of the automation

Since packet-filtering firewall is used between the automation

systems cross the information boundary between automation and

Figure 5-1. Traditional Networking and Enterprise Levels

Because inserting firewalls between the automation network and

Since the network infrastructure technology at the different levels

The automation application is now populating the shared histo-

Simply connecting a business system to the automation system

Existing automation systems found in plants, buildings, and on

Having the automation system connected, particularly perma-

Web technologies work well behind a firewall and, therefore, there

Use of Web technologies does not necessarily mean use of the

WARNING—The public Internet is a dangerous place.

Advanced Web visualization allows operators to load, login, view,

Figure 5-3. Web Browser with Viewer ActiveX

The server application for Web visualization generally runs on the

It may be a good idea to create a user group in the Windows security

Browser Plug-In Authenticity

An ActiveX component is a powerful piece of software with full

A component can be digitally signed by the publisher to assure its

certifying authority. The software publisher generates a signature

Figure 5-4. Digital Certificate for ActiveX Component

The independent certifying authority ensures that the publisher of

WARNING—Make sure to verify authenticity before down-

However, a distributed three-tier environment, or n-tier, solution

Figure 5-5. “N-tier” Architecture Protects Data

The interface for database data is called Remote Data Service

explained in Chapter 3. Firewall friendly Web tunnelling of OPC

For the future, OPC-UA (Unified Architecture) is set to offer the

The need for enterprise integration is driven very much by e-busi-

The connectivity characteristics are very different at the different

such as FOUNDATION™ Fieldbus have very tight interoperability

Traditional systems for automation, execution, and business are

Traditionally, the automation system and execution system have

Figure 5-6. Web Portal

At the execution and business levels, the interfaces between appli-

sublevels: the lower part is an MIS (Manufacturing Intelligence

OPC-XML-DA is suitable to bring data from the servers at the

MES activities include tracking and reporting on costs, produc-

MES is not one but a group of software categories which includes

• Laboratory Information Management System (LIMS)

Key software elements for data-mining and presentation solutions

Report formats can be freely designed, and data picked using

shift operators, etc. Once configured, the design tool remains

Figure 5-7. Excel Plug-in for Report Design (Courtesy: ICONICS)

Reports can be made based on data mined from databases such as

Reports generated at the MES level often are disseminated beyond

Figure 5-8. Web Portal with “Web Parts” (Courtesy: ICONICS)

A portal based on Microsoft SharePoint server makes it easier to

One benefit of Web-based MES and business applications is that a

Figure 5-9. Transaction Mapping (Courtesy: ICONICS)

MES is a crossroads for bi-directional information flow. Data is

for different functions. Clearly such integration is easier and less

Software at the business level is concerned with all aspects of the

• Raw material and spare parts usage, inventory, and

Business level software is not one application but a group of

• Enterprise Resource Planning (ERP)

The Web portal concept is also gaining popularity for business

Automation System Coexistence & Migration

Some independent third-party companies now specialize in

Console Migration (OPC and HMI)

unavailability of spares and consumables for old consoles.