Copyright 2009 Systems Integration Specialists Company, Inc.

All rights reserved

Creating an Enterprise Class Scalable Model Driven
Infrastructure


The use case for using IBM, OSIsoft, and SISCO
technologies











Version: 1.1 Date: May 28, 2009





Systems Integration Specialist Company, Inc.
6605 19 Mile Road
Sterling Heights, Michigan 48314

Creating an Enterprise Class Scalable Model Driven Infrastructure Page 2




Copyright 2009 Systems Integration Specialists Company, Inc. All rights reserved
Introduction

In order to understand Enterprise Model Driven Integration, it is important to first understand the
business use case for the integration. In order to discuss integration from a general perspective, this paper
will utilize the ISA 95 standard. This paper leaves it to the reader to correlate the ISA 95
information/business drivers for their purposes.


Figure 1: ISA 95 Functional Levels of Integration
1


Figure 1 depicts the four levels of integration/information exchange as defined by ISA 95. The figure
shows distinct integration/information exchange boundaries (e.g. between levels 3-4 and levels 2-3),
reality has shown that the boundaries are not as well defined and that functions are not necessarily as well
segmented as are shown.

An implementation view could show something similar to Figure 2.

ERP
MES
Process Coordination
B
u
s
i
n
e
s
s

P
r
o
c
e
s
s

C
h
o
r
e
o
g
r
a
p
h
y
Process
Information
Exchange
User Interaction





1
Courtesy of Keith Unger, Stone Technologies.
Creating an Enterprise Class Scalable Model Driven Infrastructure Page 3




Copyright 2009 Systems Integration Specialists Company, Inc. All rights reserved
Figure 2: Possible Implementation Architecture

Each implementation layer, shown in Figure 2, could have its own set of tooling and user interfaces.
Additionally, a single layer might make use of different equipment from one or more vendors. The
choice for particular equipment is driven by business requirements. The selected vendors would typically
provide tooling and user interfaces for their equipment to maximize the user experience with the
equipment. In so doing, expertise and advocacy for particular tooling is developed within the business
organization which has the end effect of creating silos of expertise.

Consider the programming of two (2) different PLCs. Both PLCs monitor the production level of
particular business work centers. One PLC has been programmed to provide the information in register
4001. The other exposes production level in register I:177/17. The users that programs each PLC has the
documentation that details which register represents the production level of the cell. However, it would
be difficult for a non-PLC expert to know which register, or the different notations/tooling, to acquire the
production levels of each cell. Similar examples of data naming issues can typically be found between
different product offerings, even potentially from the same vendor.

Low Level Automation
Controllers and I/O
Distributed
Control Systems
Register
Address
Space
Historians
Tag Name
Address
Space

Figure 3: Normal Implementation Architecture to create contextual Tags


Use of Tags

In order to provide some context for the automation information, this information is typically placed/used
by higher level systems that provide the capability to alias automation information into human
recognizable names (e.g. Tags). Figure 3 depicts typical integration/process integration where the low
level automation information is exposed through either Distributed Control Systems (DCSs) or through
historians. There are multiple DCS and historian vendors that could be utilized within each integration
level in a corporate enterprise environment. Each vendor, as with the automation integration level, has
special constraints on Tag naming. Therefore, the general user/application is still required to understand
the special constraints of the system that needs to be accessed for a particular application/display.

Creating an Enterprise Class Scalable Model Driven Infrastructure Page 4




Copyright 2009 Systems Integration Specialists Company, Inc. All rights reserved
However, the single vendor selection strategy is not sufficient. Additionally, a corporate policy for Tag
naming needs to be developed and enforced. However, history has shown that even where there are
strong corporate policies, Tag name consistency does not occur in an enterprise due to several different
reasons:

Configuration errors: In order to comply with corporate naming policies, people must configure the
Tag names that correlate to particular automation information. This is typically a manual process and
is prone to errors (e.g. ProductionLevel and ProductionLvel).

Detection of such errors requires a large amount of naming/data validation.

Constraints on the Tag namespace: Most Tag namespaces do not allow for duplication of Tag names.
Therefore, if the higher level integration levels need to expose more than one ProductionLevel Tag,
the names are inherently forced to be unique.

This issue can be solved by adding an extension to the Tag name in order to provide uniqueness.
Most typical corporate policies dictate that the name of the system, work center, etc. be pre-pended to
the tag name.

As an example, the ProductionLevel for SeparatorTrain1 and SeparatorTrain2 needs to be provided.
The corporate mandated naming convention might specify the Tag names to be
SeparatorTrain1_ProductionLevel and SeparatorTrain2_ProductionLevel.

Most corporate naming conventions must take into account the business hierarchy. This policy could
extend the length of the Tag name to include:

<oil field name>_<platform name>_<production unit name>_<measurement name>

Names of entities change: One thing that has been proven is that over time names of
platforms/production units may be changed. The end effect, of such changes, is that as
platforms/production units names are changed, maintenance of the Tag names, and the applications
that utilize them, may become an issue.

Hierarchical Tag naming creates issues for other business views: The process business view is the
typical standard used to name Tags. However, there are other business related views (e.g.
AssetUtilization, Condition Based Maintenance, others) that would be better facilitated by the use
of another naming hierarchy/view of the information. In general, this is an issue with technologies
that only support hierarchical data organization.

Mergers and acquisitions: Experience has shown that most corporate Tag naming policies do not
provide naming conventions that include naming associated with the corporation or underlying
business units. The lack of this information in the name can create integration issues when
corporations merge.

Use of Models

In 1999, the Electric Power Research institute had an initiative to develop a standardized model and a set
of model access services. The intent of the initiative was to address the previously mentioned issues in
Creating an Enterprise Class Scalable Model Driven Infrastructure Page 5




Copyright 2009 Systems Integration Specialists Company, Inc. All rights reserved
addition to many others. SISCO has been involved in developing integration products and solutions
utilizing semantic models and Model Driven strategies.

Semantic Models

A semantic model is typically considered as:

a basic set of ontology elements classes, relations, functions, instances, intended to serve as
the conceptual defining vocabulary that will permit specification of the meanings of any
domain term or concept. It serves a function analogous to the controlled defining vocabularies
used in some traditional dictionaries to define words.
2


As an example, ISA 95 and ISA 88, define a semantic model that can be utilized in discrete and batch
oriented process
3
that go well beyond defining a hierarchy of measurement/process data access.

Identified by
ISA-88
Must Contain 1 or More
May Contain 1 or more
Area
Site
Enterprise
May Contain 1 or more
Must Contain
1 or More
May Contain
May Contain
Batch
Operations
Process
Cell
Unit
May
Contain
May
Contain
Equipment
Module
Control
Module
Specified by
ISA-88
Must Contain
1 or More
Must Contain
1 or More
Discrete
Operations
Inventory
Operations
Continuous
Operations
Work Cell
Production
Unit
Storage
Zone
Unit
Must Contain
1 or More
Storage
Unit
Area
Site
Enterprise
Specified by
ISA-95
Manufacturing
Line

Figure 4: Simplified representation of ISA 95 and ISA 88 Physical Model
4


Each block, shown is Figure 4, represents object definitions (e.g. expressible as UML classes) that
contain specific attribute definitions and types for the specified attribute. Although, Figure 4 appears to
be able to be expressed as a hierarchy, the diagram represents only one potential view of the process
oriented business functions.

A more accurate representation of the interactions/views required is shown in Figure 5.





2
Mitre Corporation
3
There are other well recognized semantic models such as MIMOSA, CIM, ISO 15926, IEC 61850, etc..
4
Courtesy of Keith Unger, Stone Technologies.
Creating an Enterprise Class Scalable Model Driven Infrastructure Page 6




Copyright 2009 Systems Integration Specialists Company, Inc. All rights reserved
Receiving Batch / Continuous and Discrete Work Centers Shipping
J. Keith Unger
Equipment Specific
Definitions Commands Responses
Equipment
Specific Data
Definition
Management
P
r
o
d
u
c
t
i
o
n
M
a
i
n
t
e
n
a
n
c
e
Q
u
a
l
i
t
y
I
n
v
e
n
t
o
r
y
Execution
Management
P
r
o
d
u
c
t
i
o
n
M
a
i
n
t
e
n
a
n
c
e
Q
u
a
l
i
t
y
I
n
v
e
n
t
o
r
y
Data
Collection
P
r
o
d
u
c
t
i
o
n
M
a
i
n
t
e
n
a
n
c
e
Q
u
a
l
i
t
y
I
n
v
e
n
t
o
r
y
Dispatching
P
r
o
d
u
c
t
i
o
n
M
a
i
n
t
e
n
a
n
c
e
Q
u
a
l
i
t
y
I
n
v
e
n
t
o
r
y
Resource
Management
P
r
o
d
u
c
t
i
o
n
M
a
i
n
t
e
n
a
n
c
e
Q
u
a
l
i
t
y
I
n
v
e
n
t
o
r
y
Detailed
Scheduling
P
r
o
d
u
c
t
i
o
n
M
a
i
n
t
e
n
a
n
c
e
Q
u
a
l
i
t
y
I
n
v
e
n
t
o
r
y
Analysis
P
r
o
d
u
c
t
i
o
n
M
a
i
n
t
e
n
a
n
c
e
Q
u
a
l
i
t
y
I
n
v
e
n
t
o
r
y
Tracking
P
r
o
d
u
c
t
i
o
n
M
a
i
n
t
e
n
a
n
c
e
Q
u
a
l
i
t
y
I
n
v
e
n
t
o
r
y
Operations
Capability
ISA
95
Operations
Definitions
Operations
Request
Operations
Response
ISA
95
ISA
95
ISA
95
How
Product Lifecycle Resource Planning
What
Schedule / Plan
When Delivery
Fulfillment
Enterprise Planning and Logistics Information

Figure 5: ISA 95 Manufacturing Activities
5


The figure 5 shows not only the manufacturing interactions, but the views of information/context that
need to be supported. In order to create the multiple views (e.g. Quality, Inventory, Production, and
Maintenance), mesh oriented model repositories/namespaces need to be utilized instead of hierarchical
namespaces.

In order to address the Tag oriented integration issues, enforcement of the class/attribute definitions is
required. Additionally, the possible relationships between instances needs to be appropriately specified
(e.g. UML associations). It is through the specification of the relationships that multiple business views
of the information can be created.

Implementations of Data Warehouses/Model Repositories that expose such instance relationships would
be considered Model Aware.
Model Driven
Although there are several technologies that can be utilized to create Model Aware repositories, there is a
difference between repositories that are Model Aware and enterprise integration strategies that are Model
Driven. Model Driven integration strategies need to encompass the functionality of being Model Aware
and the additional functionality of:

Support for a work flow that allows for the maintenance of the model within the model repository(s).

The work flow should be able to be integrated into choreographed business processes.

This is required so that model updates can be validated and model changes do not occur at an in-
opportune time. Although, this workflow can be achieved manually, it is recognized that electronic




5
Courtesy of Keith Unger, Stone Technologies.

Creating an Enterprise Class Scalable Model Driven Infrastructure Page 7




Copyright 2009 Systems Integration Specialists Company, Inc. All rights reserved
coordination, which integrates with other business process, offers higher business value.

This includes the dynamic modification of the model due to process changes and business
transactions (e.g. new Work Orders, Batch commands, etc..).


Since 1999, SISCO has developed products that implement those strategies. Over time, SISCO has
evolved its integration strategy to be applicable to other industries besides the electrical utility industry.
The resulting product family name is the SISCO Utility Integration Bus (UIB).

The initial UIB product provided a Model Driven integration infrastructure that utilized a model
repository to create Model Aware/Driven adapters that exchanged information over middleware. SISCO
offers a select set of adapters for the infrastructure:

OPC Client Adapters: Allows applications, which are OPC clients, to access information, in the
context of the model, without requiring the creation of a Data Warehouse or knowledge of the
authoritative source of the information.

OPC Server Adapters: Allows applications, which are OPC Servers, to have their information mapped
into the model and be exposed to the infrastructure as an authoritative source.

Adapter for OSIsoft PI: Allows the enterprise model to be imported/maintained within the PI Module
DataBase or PI AF
6
. This adapter allows for PI client applications (e.g. ProcessBook, RtWebParts,
and DataLink) to be used in a Model Driven fashion.


One of the desires, for the infrastructure, was to have the capability of electronic business choreography.
This ability is now provided within the IBM Integration and Information Framework (IIF) solution.
Additionally, IIF natively allows for electronic business transactions (e.g. EDI, S95, etc...) to be translated
and responded to in terms of the model.

Through the appropriate selection of the appropriate products, and architecture, users can create flexible
integration deployments.


Architecture

Due to the flexibility of the various product offerings, users will need to select the appropriate set of
products based upon corporate commitments to specific technologies, client application environment, and
desired business functions.

From a functional perspective, the suite of available products needs to be functionally classified. For this
purpose, it is desirable to use the following diagram:




6
OSIsoft has a stated strategy of transitioning away from the MDB to AF. SISCO is following that
strategy and is not currently updating the capabilities of the MDB version of the PI Adapter.
Creating an Enterprise Class Scalable Model Driven Infrastructure Page 8




Copyright 2009 Systems Integration Specialists Company, Inc. All rights reserved


Figure 6: Simplified Enterprise Integration Functions

Creating an Enterprise Class Scalable Model Driven Infrastructure Page 9




Copyright 2009 Systems Integration Specialists Company, Inc. All rights reserved
There are several different functional layers depicted in Figure 6:

Data Layer: Actually obtains information from the real-time process automation equipment/sensors.

Information Layer: Applies the semantics of the model to change data into contextual information.
One of this layers capabilities is to access automation/process information via SOA.

Business Process Layer: Allows configuration and implementation of workflow coordination on an
Enterprise level. It also provides a transactional capability (e.g. create a new purchase order, execute
a general batch, etc) from other SOA system.

It is typical for each layer to have one or more visualization components that are used to expose the
information from the layer. Therefore, the strategy does not mandate a single visualization components
use and must be flexible to accommodate multiple tools. However, it is desirable to be able to combine a
subset of the visualization tools, at least one from the Information and Business layer, into a single
method of access to the tools. This would typically be accomplished through exposing the visual
information through a single web portal technology (e.g. Websphere, SAP, or Microsoft) at the
discretion/selection of the customer.

Figure 7: Components of the combined SISCO, IBM, and OSIsoft infrastructure

Figure 7 shows the components/products that are used to create a model-driven infrastructure through
combining the IBMs Information Integration Framework (IIF) solution with SISCO and OSIsoft
products.
Creating an Enterprise Class Scalable Model Driven Infrastructure Page 10




Copyright 2009 Systems Integration Specialists Company, Inc. All rights reserved
Model
Driven
Infrastructure

Figure 8: Functional use of infrastructure components


IIF is an IBM software solution that is being leveraged for solutions in the domains of: Chemical and
Petroleum; Energy and Utilities; and other business application domains. The solution is based upon
IBM products which, in the past, have provided:

Complex Business Process Orchestration and Mediation: This functionality is provided by the IBMs
Webshpere Business Process Server. This product allows the definition of complex business process
interactions and workflow through the use of graphical configuration and Business Process Execution
Language (BPEL) technology.

Mediation and transformation of SOA messages: This functionality is provided within the Websphere
Application Server (WAS) product.

Middleware message transport and security: Provided through the Websphere Enterprise Service
Bus.

IIF adds model awareness to the components through a set of standards based Model related services.
These services allow:

Real-time information to be consumed by the applications so that the business workflow can adapt
based upon the current state of the actual processes within the enterprise.

As an example, consider the reception of an SOA transaction that is used to dispatch a production
batch to a specific production unit. However, that production unit is offline or has not completed its
current batch. The real-time information of the status of the production unit (e.g. that it is not
available) allows, through BPEL, to re-dispatch the batch to an alternate production unit(s) that are
available and are capable of producing the batch.

Creating an Enterprise Class Scalable Model Driven Infrastructure Page 11




Copyright 2009 Systems Integration Specialists Company, Inc. All rights reserved
The applications to query the virtualized model so that relationships/capabilities of equipment,
production units, measurements, etc. can be determined.

The previous batch example implies that the re-dispatching is based upon the knowledge of which
other production units are capable of producing a specific type of batch. The ability to query the
model for this information allows BPEL to dynamically determine which units meet the criteria as
opposed to being programmed (e.g. a priori) with the information.

This allows the designers of the production cells/units to change the model, and thereby allow
adaption in the workflow coordination, without requiring changes to the BPEL. It is the ability to
change the model and impact the coordination that is at the root of enabling the entire orchestration to
be Model Driven.

Historical information to be consumed by the applications in order to determine/adapt business
processes based upon past performance.

Applications to be coordinated and production and business process related metrics/events to be
produced or consumed as part of the overall coordination process.

As part of facilitating the application functionality, IIF also includes SISCO Utility Integration Bus (UIB)
components.

The SISCO UIB PI Adapter is used to populate and manage (e.g. update) OSIsofts AF repository with a
subset of the overall virtual enterprise model. The PI Adapter also allows the historical and real-time
information within the OSIsoft Server(s) to be exposed in the context of the enterprise model to the ESB.
The product also allows the IIF business oriented applications to store the business process generated
metrics/events to be stored within the OSIsoft environment.

Figure 7 shows the most typical OSIsoft products that would be utilized in the architecture. These
products provide the capability of:

Generation of process/production related Key Performance Indicators as well as a mechanism to
generate events that can be consumed as part of the business choreography within the IIF solution and
other components in the architecture.

Publication of process information to the infrastructure (e.g. through the SISCO PI Adapter) in real-
time.

Provides a repository for historical production process and business process information.

Provides a repository for a subset of the enterprise model so that OSIsoft tooling can be used to
visualize/report the information within the context of the enterprise model.

Creating an Enterprise Class Scalable Model Driven Infrastructure Page 12




Copyright 2009 Systems Integration Specialists Company, Inc. All rights reserved

Summary

Through the deployment of world-class products from IBM, OSIsoft, and SISCO; a robust Model Driven
infrastructure can be created that addresses the functional requirements of Enterprise integration.


Figure 9: Infrastructure components vs. enterprise integration layers

The solution also allows business process, production and Manufacturing Execution System (MES), and
process level coordination to occur.


Figure 10: Infrastructure components vs. scope of applicability and ISA levels

Creating an Enterprise Class Scalable Model Driven Infrastructure Page 13




Copyright 2009 Systems Integration Specialists Company, Inc. All rights reserved
For more details, please contact Systems Integration Specialists Company.


Acknowledgements
SISCO gratefully acknowledges the contributions of Troy Carbaugh, Lorenzo Childress, Herbert Falk,
and Ron Montgomery for their input and assistance in the creation of this paper.