the plant historian as a cloud...

By Harry Forbes

ARC STRATEGIES

NOVEMBER 2012

The Plant Historian as a Cloud Application

Executive Overview .................................................................... 3

Cloud Computing ........................................................................ 4

The Business Value of Cloud Computing ......................................... 8

Data Historians as a Cloud Application .......................................... 11

Historian Supplier Cloud Strategies .............................................. 14

Recommendations ..................................................................... 23

VISION, EXPERIENCE, ANSWERS FOR INDUSTRY

ARC Strategies • November 2012

2 • Copyright © ARC Advisory Group • ARCweb.com

Cloud-Computing Characteristic Explanation

On-demand self-service

A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service provider.

Broad network access

Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, tablets, laptops, and workstations).

Resource pooling The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of loca-tion independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify loca-tion at a higher level of abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, and network bandwidth.

Rapid elasticity Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time.

Measured service Cloud systems automatically control and optimize resource use by leveraging a metering capability1 at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service.

Essential Characteristics of Cloud Computing (Source: NIST)

Cloud Computing Deployment Models


Copyright © ARC Advisory Group • ARCweb.com • 3

Cloud computing is a new but rapidly growing computing model. It is

potentially disruptive to both software business models and enterprise IT

practices. Within manufacturing, ARC believes that the plant historian

software suite is likely to be an early adopter of the cloud model, but both

end users and suppliers see reasons for a gradual rather than rapid adoption.

Executive Overview

Cloud computing is a new computing model characterized by the intensive

use of remote networked computing resources. Cloud architectures are es-

pecially useful for scaling up computing tasks that can be parallelized.

Though relatively new in the commercial/industrial space, cloud technolo-

gy already has huge industry backing because it has been developed in

support of the internet applications of major software and internet firms

such as Google, Amazon, Apple, and Microsoft. Today, cloud data centers

alone comprise an $80-$90 billion annual market.

Cloud represents a disruption to established mod-

els of software development, software deployment,

support, and pricing. It also greatly lowers barriers

to entry in the software market.

Cloud computing also threatens to disrupt enter-

prise IT operations. Cloud offers enterprises more

rapid deployment, greater scalability (up and

down), reduced capital investment, and easier

support for mobile devices. Widespread cloud

adoption will cause enterprise IT organizations to act more as intermediar-

ies rather than internal project and IT asset managers. The business value

proposition for adopting cloud technology in an enterprise application de-

pends upon how strategic and differentiating the application is. Cloud

computing generally improves service for strategic applications and lowers

costs for non-differentiating applications.

In manufacturing, the plant data historian application has evolved signifi-

cantly. Beginning in the late 1970s early digital automation systems

delivered improved plant control and performance, but did not enable

plantwide digital data history or analytics. These first became available in

the late 1980s with the explosion of computer networking technology. Plant

historian software became a critical application and the first one that usual-

ly ran “above” automation networks on IT standardized platforms and

networks. Historian data became a foundation for many other critical ap-

plications and analytics. Such historians can now span many production

units and multiple plants.

Though the plant historian was the first operational technology (OT) appli-

cation to move from an automation system to an IT network, the historian



presents several barriers for implementation in the cloud. Software suppli-

ers are eager to exploit potential cloud benefits such as better support for

mobility, inexpensive and large capacity resources, and easier data sharing.

However, today’s historian suppliers also deliver a large variety of other

software solutions that leverage historian data. For many customers (and

suppliers) these “other” applications are of equal or greater value than the

historian itself. Historian software has to evolve in a way that does not dis-

rupt the value being delivered by these applications. Many manufacturing

software suppliers are now taking the first steps in that journey.

Cloud Computing

Cloud computing is a new computing model that features the intensive use

of remote computing resources (processing, storage, networking, and soft-

ware). The salient feature of cloud computing is that these resources are

delivered to end users as a service over a network, typically the Internet.

Within cloud computing, the available computing resources are virtualized.

Virtualization separates an IT resource from specific physical hardware.

Virtualization can be applied to any IT resource; including servers, storage,

desktops, and networks. For example, server virtualization enables multi-

ple “virtual servers” to run on one physical server. This permits greater

server flexibility and greater server resource utilization. Virtualization pro-

vides large gains in available capacity, resource utilization, and energy

efficiency since it greatly reduces the number of physical resources required

per unit of virtual capacity.

Delivery as a service is another important aspect of the cloud model. Re-

gardless of the deployment model, cloud computing models are defined by

sets of services implemented via application programming interfaces

(APIs). Since the computing resources are remote and virtualized, cloud

APIs must present these resources at a higher level of abstraction.

Cloud APIs enable problems to be solved in a parallel fashion by dividing

the computing tasks and allocating these tasks to a large number of proces-

sors, usually referred to as a cluster. This contributes to cloud computing’s

scalability, or “elasticity.” While many cloud APIs are currently available,

several initiatives are now underway to develop standardized APIs for spe-

cific cloud computing platforms and develop open source implementations



of these. However, since with cloud computing the API essentially defines

a product (service), standardization of cloud APIs is problematic, although

some cloud APIs may become widespread and popular. This situation is

similar to the state of APIs for internet servers where the wide variety of

available APIs range from commercial to open source and from very broad

to very narrow scope.

It’s important to understand the distinction between cloud computing and

outsourcing or remote hosting models. Cloud requires some level of soft-

ware re-design, while the other technologies can simply re-implement

existing practices at a different (and more advantageous) location.

The US National Institute for Standards and Technology (NIST) has devel-

oped an excellent definition that classifies cloud computing by three

properties; its characteristics, service models, and deployment models (see

following tables and on inside cover).

Software as a Service (SaaS)

The capability provided to the consumer is to use the provider’s ap-plications running on a cloud infrastructure2. The applications are accessible from various client devices through either a thin client interface, such as a web browser (e.g., web-based email), or a pro-gram interface. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

Platform as a Service (PaaS)

The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools support-ed by the provider.3 The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting envi-ronment.

Infrastructure as a Service (IaaS)

The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applica-tions; and possibly limited control of select networking components (e.g., host firewalls).

Cloud Computing Service Models (Source: NIST)



Private cloud The cloud infrastructure is provisioned for exclusive use by a single or-ganization comprising multiple consumers (e.g., business units). It may be owned, managed, and operated by the organization, a third party, or some combination of them, and it may exist on or off premises.

Community cloud

The cloud infrastructure is provisioned for exclusive use by a specific community of consumers from organizations that have shared concerns (e.g., mission, security requirements, policy, and compliance considera-tions). It may be owned, managed, and operated by one or more of the organizations in the community, a third party, or some combination of them, and it may exist on or off premises.

Public cloud The cloud infrastructure is provisioned for open use by the general public. It may be owned, managed, and operated by a business, aca-demic, or government organization, or some combination of them. It exists on the premises of the cloud provider.

Hybrid cloud The cloud infrastructure is a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique enti-ties, but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load balancing between clouds).

Cloud Computing Deployment Models (Source: NIST)

Cloud Maturity from Internet Applications

Much of what makes up cloud is already mature technology that is being

delivered today in high volume. Much of cloud technology has already

“crossed the chasm”. This is because cloud technology was initially devel-

oped to provide the extreme scalability that was required for successful

Internet applications. Google search is the canonical cloud application. But

Google, despite its success in internet search, was not simply a search com-

pany. Rather, the more accurate model for Google, even from its early

days, was that of a platform company that ran many different applications

on its own distributed (cloud) platform. These applications included

Google Earth, Blogger, Gmail, Picasa, YouTube, Reader, and others, with

Google Search being the most popular.

The need for extreme scalability of internet applications is not unique to

Google, but is also required by other major software and internet firms.

Amazon needs scalability for its massive on-line sales operation; Apple for

iTunes and for supporting hundreds of millions of consumer devices. Mi-

crosoft ran Hotmail, Bing, and now Skype. And the explosive growth of

Facebook, NetFlix, and other firms forced these companies onto cloud plat-

forms. Why? Because scaling up an application by a factor of 10,000

represents a serious technical challenge. Commercial software generally

cannot scale to this degree. These internet applications need to scale by



Barriers to entry for cloud software- providers are very low,

since they can leverage established cloud platforms.

adding servers (and adding them by the hundreds or thousands), and so

require a virtualized, highly elastic, managed execution environment – a

cloud platform.

As cloud software platforms evolved, the explosive growth of web-oriented

companies created what is now a huge market for new data centers. These

data centers, often owned and financed by internet companies, require bil-

lions of dollars of capital investment. Current estimates of worldwide data

center investment are in the range of $80-90 billion per year (See:

http://www.arcweb.com/strategy-reports/2012-03-22/abb-initiative-

targets-the-data-center-1.aspx). Software companies, forced to invest bil-

lions in the “brick and mortar” of data centers, used their cloud software

platforms to generate additional revenue from their excess data center ca-

pacity. The close partnership between Amazon and NetFlix illustrates this

phenomenon. These platforms offer a huge business opportunity to the

market “survivors” as the market for cloud platforms consolidates.

Cloud Disrupts Software Development and Business Models

The cloud also threatens to disrupt traditional seat-based business models

for software pricing. While cloud does not mandate any change to these

models, it generally represents a shift away from IT pricing models domi-

nated by fixed costs, toward those containing a higher portion of variable

costs. Pay-for-use pricing models will fit cloud applications much more

easily than seat-based pricing.

The cloud’s technical disruption to software development and deployment

will be even more pronounced. For decades, software development has

meant coding critical applications from scratch and linking application code

with packaged libraries to create a deliverable for installation on a support-

ed operating system. Cloud development changes the deployment

environment for both platform as a service (PaaS) and software as a service

(SaaS) models and gives developers any number of new choices for devel-

opment tools and deployment platforms.

Cloud also opens a whole new field for software develop-

ers who create APIs linked to cloud services rather than

following traditional software distribution models. Barri-

ers to entry in this market are very low, since the cloud

service developers exploit the elastic properties of cloud



technology in their own products. In theory, using third-party cloud ser-

vices should enable ISVs to focus on their core application logic. But

software developers also face a host of new challenges. These include find-

ing and testing cloud service options, implementing and testing new

applications, and support throughout their product lifecycle. Most likely,

PaaS providers will facilitate the choice of cloud services but this may not

effectively limit developer choices. Cloud represents a whole new ball

game for developers.

The Business Value of Cloud Computing

The technology disruption that cloud computing represents centers on IT

rather than OT. Cloud represents a new model for IT, challenging an organ-

ization’s established IT practices in every area; new platforms, new

services, new deployment, licensing, and support models. Cloud forces an

IT organization to examine each application within its portfolio and re-

evaluate the way the application is currently deployed and supported.

Furthermore, IT organizations have cultivated and developed many of the

skill sets that the cloud computing model threatens to disrupt. For exam-

ple, the practice of procuring, commissioning, and managing various

servers within an enterprise has been a critical IT skill for decades. Cloud

offers an alternative to this practice, whereas IT outsourcing simply re-

locates existing services to lower cost regions.

From a business standpoint the cloud model offers several potential ad-

vantages over the traditional IT service model:

Rapid deployment – Within many large enterprises it can take several

months to specify, procure, install, and commission a dedicated server.

With this in mind, organizations may move the procurement steps earlier in

a project, when less accurate preliminary sizing information is available.

Regardless, the cloud model offers resources that can be deployed more

quickly.

Elasticity – The concept of elasticity expands on scalability in that it implies

a service that can both grow and shrink to match demand. This attribute is

most valuable for customer-facing and internet applications, which may

exhibit huge demand variances. The “poster child” for cloud elasticity is



probably the internet-based NetFlix

streaming service, which streams

video on demand to many millions of

US households, representing a sig-

nificant fraction of total US internet

traffic during prime time viewing

hours.

Reduced capital investment – The

Cloud model shifts costs from CapEx

to OpEx. It reduces the high initial

outlay required for servers, software,

support staffing, administration, and maintenance. In its place, cost behav-

ior approaches pay-per-use. The challenge here is that fixed costs such as

staffing and administration must be allocated across a portfolio of applica-

tions and these costs will not respond linearly to each adoption of a cloud

model.

Yet another cost advantage is that large corporations and IT shops can pur-

chase cloud services in volume. This enables an IT organization to contract

in advance with its internal customers for rapidly deployable resources.

This option changes the relationship between IT and the rest of the organi-

zation. Instead of managing IT capital projects, an IT organization can

aggregate the internal demand for new computing resources, and offer “in-

stantly available” spare capacity to its internal customers on a contingency

basis. In effect, instead of purchasing IT resources, the IT organization acts

as an intermediary between its own organization and third-party cloud

service providers.

Mobility – The cloud model can form part of the answer to the huge explo-

sion of smartphones and tablet devices that now confront IT organizations.

Since cloud services are by nature external to an enterprise, the gap that

develops between internal and external capabilities becomes less relevant

for cloud-based applications. While there are other solutions for mobility

problems, cloud-enabled location-independent support for user mobility is

one potential advantage of cloud services.

Cloud and the Business IT Portfolio

Businesses operate and maintain a portfolio of IT applications to support

their operations and management. Businesses that manage this portfolio

Cloud Resources Can Match Demands



Cloud computing drivers vary greatly between strategic

differentiating applications and non-strategic applications.

The particular IT applications that are strategic differentiators

vary across vertical industries and enterprises.

effectively not only control their IT costs, but also better

support their company’s mission. ARC research indicates

that leading businesses often classify the applications in

their portfolio based on the degree to which they provide

them with a competitive differentiation or advantage. In

different businesses and industries, these differentiating applications can

vary greatly.

For example, one major global retailer classifies supply chain management

(SCM), inventory management, and point-of-sale as the most critically dif-

ferentiating applications, even though only the point-of-sale application is

directly visible to customers. While large discrete manufacturers such as

major automotives are also very concerned about their supply chains, most

classify their product lifecycle management (PLM) applications as among

the most critical differentiators, especially as they increasingly harmonize

their designs and products globally. Global consultancies or service firms

often consider CRM and HR applications most critical for managing and

deploying their staff and services. Process manufacturers, operating capi-

tal-intensive plants, look to asset lifecycle management (ALM) asset

performance management (APM), and enterprise asset management (EAM)

as the most critically differentiating applications, because these are the ap-

plications that have the potential to improve capital asset utilization and

product costs.

Strategies for allocating IT investment to particular applications drive in-

vestment towards the differentiating applications. Cost reduction is the

major strategy for applications where strategic differentiation is not a fac-

tor. The emergence of cloud architectures adds a new di-

mension to application investment decisions. However,

the drivers for cloud adoption will be much different for

strategic vs. non-strategic applications. For strategic ap-

plications, the benefits of greater scalability, faster time to

market, and greater mobility must weigh heavily. For non-strategic appli-

cations, a higher value point must be reached either through lower costs or

via best-in-class solutions at a lower cost point than is possible with con-

ventional computing architectures.



Early DCS implementations improved process control, not historical data management.

Data Historians as a Cloud Application

Continuous process manufacturers have captured, stored, and managed

historical plant measurement data for decades, but the technology, data

volume, uses, and importance of historical process data continues to grow.

Since production in process plants is usually measured as a continuous

flow rate of product (barrels/day, gallons/minute, liters/min, megawatts,

etc.) the on-line process measurements are the best monitor of actual pro-

duction. In its simplest form, the historical data record for process plants

consists of time series data for each historized measurement.

Stages of Historian Technology

The earliest capture of plant historical data was done with paper chart re-

corders. In fact, paper charts were the only plant data repository until

automation systems became digital in the 1970s. Plants maintained a store

of charts representing critical production measurements, with each circular

chart representing a single day’s history. Filing was relatively easy, but

retrieval, comparison, correlation, and analytics involved so much manual

transcription and inaccuracy that these were largely impractical.

The early digital DCSs did not greatly improve this situation, and in fact

often made it worse. The mission of these systems was to improve and

even optimize process control (and hence production), rather than manage

data. While process data could now be captured and

retrieved with relative ease, from the mid-1970s through

mid-1980s, historical data within a DCS was primarily

limited to supporting the HMI. Besides their proprie-

tary designs, these systems also had very limited data storage capacity (of-

ten less than the legacy paper charts!). In that pre-computer-networking

era, historical process data was essentially captive within the DCS.

That was not the only difficulty. Process plants often utilize different au-

tomation systems in different plants and tend to modernize these

automation systems on a unit-by-unit basis. This made it difficult, if not

impossible, to merge historical data across units with DCS-resident histori-

ans, especially if the DCSs came from different suppliers or were even

different generations of the same supplier’s system.



Plant-wide Historians Enable Data Visualization and Analytics

Enter the Plant Data Historian

Computer networking developed immensely during the decade 1985-1995.

As a result, standalone DCSs could not keep pace with the compute power

and storage capacity of networked systems. Process engineers discovered

powerful software tools to analyze data, but were often frustrated by lim-

ited ability to access their plants’ historical data for analysis.

During this period, data historians emerged as critical applications in the

process industries. Independent software vendors pioneered these prod-

ucts, followed quickly by process automation suppliers. The primary

differentiator of these products was architectural. They were client/server

applications that often ran outside the process control systems on the

plant’s standards-based LANs. These plant historians could support high-

capacity data interfaces to many different DCS, PLC, LIM, and other pro-

cess data sources.

Plant historians quickly added APIs that served desktop clients. These cli-

ents could be PCs within the enterprise or third-party software

applications. Engineers found these new software tools immensely valua-

ble. Plantwide historians could capture and manage large amounts of

measurement data from all the units in a process plant. They enabled pro-

cess engineers to visualize and analyze this data as a time series because all

the data carried some form of time tag. Taking advantage of the digital data

capture capabilities of the DCSs, the process historian became the founda-

tional tool for many activities.

For the first time, engineers had the abil-

ity to see a unified view of their plant

history to support improvements. They

could quickly define an ad hoc set of

plant measurements and display it as a

time-series. Plant-wide historical data

also provided the foundation for a se-

cond phase of more advanced analytical

applications.

Easy access to plant-wide historical data provided immediate payback in

the form of equipment performance metrics. Modern historians with data

retrieval APIs enabled these metrics to become on-line calculations that

could monitor and detect problems; alerting the plant staff to significant

deviations or changes. Many other types of analytics could now be per-



formed as well. Control loop analytics could search through historical data

and advise on improvements to controller parameter settings, but were also

capable of looking for relationships between the disturbances or oscillations

of plant variables. This was only possible because the historian aggregated

a much larger number of measurements. These extended across unit

boundaries and beyond the view of process automation systems.

“Process identification” was one application used to design multivariable

control systems to support on-line optimization. Identification applications

create plant models using historical data. Depending upon the analytics,

the application will develop a model either by deliberately disturbing the

process or by relying on natural disturbances. The model is used to design

multivariable controllers and optimizations which are then deployed on-

line. The economic benefits of real-time

advanced control and optimization have

been huge, as is demonstrated by their

widespread use. An abundance of his-

torical data to use in the design of such

systems was a necessary condition for

their development.

Abundant historical data could also sup-

port production planning and scheduling

activities by comparing built-in assump-

tions against actual operating

performance. Data-driven analysis iden-

tified root causes of deviations between

predicted or ideal plant behavior and

actual performance. These analyses provided critical insights into how to

improve plant performance, but relied on extensive historical data services

as a foundation.

In summary, the domain of modern IT-enabled plant-wide data historians

now extends from the plant automation system to the desktop and from a

single process unit to many entire plants, arguably making them the most

critical component of the “OT” software portfolio for manufacturers.

Process Identification and Modeling Depend on Quality Historical Data (Source: Honeywell)



“Plant” Historians Have Extended Their Reach to the Whole Enterprise (Source: OSIsoft)

Historian Supplier Cloud Strategies

Historian Is Only a Part of a Software Portfolio

Since the plant historian was really the first OT application to migrate “off

platform” from the process automation system to the plant and enterprise

network, it seems logical that historian might also be the first application to

move to a cloud computing platform. Why couldn’t historian suppliers

simply adopt a SaaS model and quickly migrate their customers to a cloud?

This question is much more complex than it may sound. Two factors great-

ly complicate the challenge.

Product portfolio integration - Historian software suppliers provide a large

number of other software products. These are not merely “add-ons” to the

historian, but are critical to both the supplier and the end user. Applica-

tions such as supply chain planning, real-time optimization, process design,

and process identification are common. In some cases, these applications

may be the companies’ flagship products even though they may rely on the

historian data interface. As a result, the software supplier could not mi-

grate the historian to a cloud platform without also integrating its entire

product portfolio with the cloud-based historian, a far more complex mi-

gration process.

Customer data storage preference – Data stored by the historian is both

highly critical and proprietary to a process manufacturing organization.



Manufacturing organizations and plants with very limited IT

resources are better candidates for a cloud-based historian.

Many process industry firms are huge enterprises; super-major oil compa-

nies, national oil companies, global chemical/petrochemical manufacturers,

or large utilities. These companies are unlikely to be early adopters of an

architecture that would move their proprietary data to a service outside

their responsibility and control.

It’s not likely that software suppliers would try to force such a decision on

their customers. Rather, they could offer any new cloud-based product on

a private cloud that could be located with the enterprise.

This would enable their installed base to retain responsi-

bility for protecting their own proprietary data, but would

result in some trade-offs in terms of the elasticity and re-

mote management benefits of cloud architecture.

On the other hand, manufacturing operations that have very limited IT re-

sources are much better candidates for a cloud-based historian. Suppliers

that find this market difficult to serve may be able to gain some traction

here if cloud architecture enables them to provide a lower TCO for this

segment.

Publicly Announced Plans for Cloud Historians

A number of leading historian and automation suppliers have made public

announcements concerning their cloud strategy. Some cloud-based prod-

ucts have been released and some product roadmaps have been sketched

out. Other suppliers have not talked about specifics and some have been

entirely silent, at least in public.

The evolution toward cloud in the historian application is already common

enough that ARC sees the beginning of a trend, especially since market

leader OSIsoft has done probably the most talking. But OSIsoft is by no

means alone in looking to cloud as a way to add value to their historian of-

fering. Here is the current status based on the public information from

some major suppliers. ARC believes the suppliers who have kept quiet will

not be so for much longer.

OSIsoft Privately held OSIsoft pioneered the off-platform historian in the early

1980s. OSIsoft has always positioned its historian at the core of all the

products in its PI system software. Besides its long focus on the historian

application, OSIsoft has also been a close follower and partner of Microsoft



Cloud architectures and deployments could enable easier sharing of “bulk” historical data with outside partners.

This is often a pain point in several manufacturing vertical industries.

since the mid-1980s. PI moved from its original VMS platform directly to

Windows servers, eschewing the UNIX platform period that most other

historian suppliers embraced temporarily.

OSIsoft has made public more detail on its cloud plans than most competi-

tors. It shared its view of cloud computing and long range plans in some

detail with customers and analysts at the OSIsoft Users Conference 2012.

The company mapped out five ongoing initiatives with respect to cloud. In

chronological order of development these are:

Mobility support – Breaking from its tradition, OSIsoft plans to add sup-

port for both iOS and Android client devices. Given Microsoft’s tiny share

of the smartphone and tablet market, this was the only way to enable PI on

most mobile devices. While in ARC’s view this is more a multi-platform

evolution than a cloud initiative, it reflects the reality that unlike its domi-

nance of the enterprise desktop, Windows is a rare exception in the mobile

device world.

PI Coresight SaaS – Coresight is the primary data visualization tool within

the PI system. Creating a SaaS version of this product will enable it to per-

form on different platforms as well as remove the administrative burden

from customer IT departments. In most companies, desktop data visualiza-

tion is the most widely deployed historian application, so reducing IT

support associated with managing it will be important to customers who

often support hundreds or even thousands of seats.

PI Data Exchange Service – This product is used for large-scale historical

data sharing via bulk data transfers. There are several common scenarios

where this could be useful for PI customers. One example is joint venture

ownership of large oil and gas assets, where some owners are also competi-

tors. While all owners may have the right to historical data, only one firm

is responsible for operations and it may be unwilling to offer network ac-

cess to companies who are its major competitors.

A second scenario is data sharing between an own-

er-operator and EPCs or service suppliers. Other

scenarios are contract manufacturing (common in

chemicals and pharmaceuticals), unit or plant op-

erating contracts between owners and large

equipment OEMs, and data sharing to support per-

formance benchmarking. While sharing historical data could provide bene-



fits in all these scenarios, the benefits may not be realized if they require

allowing others access to on-premise IT assets. A cloud version of such a

sharing service would not have this liability, facilitating data sharing and

collaboration.

PI System Monitoring SaaS – This application monitors the performance

of an operating PI system. OSIsoft prides itself on being more a software

supplier than a service provider, leaving the data-driven applications to its

customers and partners. But properly tuning and monitoring a PI installa-

tion is necessary for maximum value. IT staffs at larger customers have

developed expertise in this, but a SaaS implementation would enable all

sizes of customers to benefit from best practices in system self-monitoring

and tuning.

“PI in the Sky” – This is OSIsoft’s tongue-in-cheek term for a cloud-based

re-architecting of the entire PI historian, a long-term initiative for the com-

pany. At present, OSIsoft is only developing customer use cases and

defining the potential properties that such an architecture might exhibit.

Notice that among these initiatives, the customer needs that appear to be

driving the program are the need for data and applications on mobile (non-

Windows) devices, as well as the ability to share data securely with external

partners. Since only a defined subset of historical data needs to be shared,

the ability to move that data subset to the cloud allows manufacturers to

exclude partners from access to their proprietary systems and data. Public

or shared cloud historian architectures would not have this attribute, and

do not have the same priority in OSIsoft’s view.

OSIsoft’s distinction in the industrial software space is that its portfolio has

always centered on its PI historian. Other industrial software companies

lead with different types of products (e.g. HMI, visualization, simulation,

multivariable control, analytics, etc.). For these companies, while im-

portant, their historians usually play a support role, rather than a central

role.

Invensys Operations Management Invensys Operations Management (IOM) takes another approach. Unlike

OSIsoft, Invensys is not purely a software company. It also offers complete

solutions for process automation and safety. However, similar to OSIsoft,

Invensys has had a long and close partnership with Microsoft. Given that

much of its software runs very close to the manufacturing process, IOM



For its customers, Invensys believes the initial benefits of

cloud will be realized by those operating widely geographically

distributed assets or plants.

makes a clear distinction between automation/control software and infor-

mation-oriented applications, and sees the latter as the real candidates for

employing cloud computing.

Invensys sees a combination of greater flexibility and lower TCO as the

drivers for cloud adoption. The company sees cloud allowing customers to

get started quickly and then scale up as demand changes. It also sees cloud

reducing IT management and server administration costs. The company

wants cloud to provide customers with a high-availability architecture and

enable collaboration by increasing accessibility to knowledge and visibility

across the enterprise. Again, the customer pain points targeted relate to is-

sues with IT costs and application lifecycle management (e.g., version

control, patch management, and application monitoring) as well as ad-

dressing the slow adoption rate of new IT products by process industry

plants that may not own the necessary and up-to-date infrastructure.

IOM has discussed its Cloud strategy with key customers. They believe that

the initial benefits to their customer base will be realized by customers op-

erating geographically distributed assets or plants. These occur in many of

their served industries including food & beverage, utili-

ties, and Oil & Gas, as well as small-to-medium sized

enterprises (SMEs) like facilities management, solar panel

installers, and municipalities. One classic scenario is a

food plant that is small and remote, and must operate

with only a skeleton IT staff. Oftentimes the manufactur-

ing engineer also serves as the IT staff, so local resources can be very lim-

ited. Cloud-based applications allow such plants to effectively use

advanced applications, without the need for a local IT group or local sup-

port personnel.

To date, Invensys has three specific product initiatives involving cloud:

SmartGlance SaaS – SmartGlance is Invensys Operations Management’s

visualization and reporting application for mobile devices that connects to

data sources (usually including the Wonderware Historian). The company

released a cloud-SaaS version in 2011 to simplify data connectivity and ad-

ministration. Targeting cost-effectiveness, it enables data delivery

anywhere, anytime (via a mobile device), because the connection point for

data has moved to the cloud. Invensys reports that it has 50 SmartGlance

SaaS customers under subscription.



Wonderware Tiered Historian – A cloud-based future version of this

product would offer users a combination of in-plant and cloud services.

Invensys sees the benefits as greater enterprise access to data at a lower

TCO point. The company also sees applications where customers will find

value in the separation of historical data from in-plant control networks.

Skelta – Skelta is the Business Process Management (BPM) workflow prod-

uct from Invensys. Many corporate software roll-outs (of any software

product, not necessarily Skelta) are challenged to develop and implement

standardized corporate-wide deployments. The challenge is to develop a

good pilot program, and to make the pilot development process both wide-

ly collaborative and visible so that all corporate stakeholders have input

and buy-in to the pilot deliverables. Invensys believes that cloud will speed

up Skelta deployment, and will also offer a single point of administration

and workflow management after the roll-out. This is in addition to the

“normal” cloud benefit of better support for client mobility and remote ac-

cess.

Not-So-Public Plans of Other Suppliers

Other automation and software suppliers have not yet made specific public

announcements about their intentions for cloud computing, but some ARC

insights on how the cloud could fit and enhance their respective portfolios

follow.

ABB Automation and energy equipment supplier ABB has been publically quiet

about the cloud but in ARC’s view seems to have cloud capability in a

number of areas. Since 2010, ABB has executed a string of acquisitions that

include some substantial software firms (Ventyx, Mincom, IKS, and Obvi-

ent). These firms have been formed into a unit within ABB that includes

ABB’s [electric power] Network Management business, a large existing

ABB software organization. Thus, in public at least, ABB has been more

focused on absorbing and extending the reach of newly acquired software

products than on strategizing about software architectures. The company

usually provides an updated product roadmap at its annual “Automation

and Power World” customer event.

Looking beneath the surface, both Mincom and Ventyx already had sub-

stantial business providing hosted solutions for their customers, and ABB is

attempting to leverage this capability as more of its customers look to struc-



ture their applications as managed services. ABB states that its historian

can use resources “at any point in the network,” but thus far this only been

implemented at the automation and enterprise network, not in a cloud.

Another hint may come from the ABB ServicePort. While not technically a

private cloud, ServicePort is a “service delivery device” that can provide a

number of automated support services that are sold on a subscription mod-

el. ABB has only delivered ServicePort in configurations that drop into a

plant site, since this is acceptable to the installed base of customers and be-

cause the types of services (control tuning, event notification, system

monitoring, etc.) are intimately connected to the automation systems. From

a technical standpoint, ARC sees no reason why the “back end” of this

product could not move to a cloud platform. Customer acceptance proba-

bly remains the reason for the current architecture.

AspenTech AspenTech is does not engage in the business of process control but has a

huge portfolio of OT and IT applications for the process industries, includ-

ing its InfoPlus 21 historian. AspenTech has publically discussed its cloud

strategy only in the broadest terms, saying “The ability of the technology

tool to run in a cloud and a range of other IT advancements is likely to im-

pact and change the way software engineering for process industries is

going to be in the future….We believe the focus of future development and

course will be in making data and models available to our customers

through the web and cloud.”

Aspen has already updated its business model and licensing technology to

a pay-for-use model and away from seat licensing. Aspen’s primary busi-

nesses are in process design and simulation, on-line advanced control and

optimization, and production planning and scheduling. Historian and data

visualization capabilities are necessary to support these areas, as well as

being an application in their own right.

Many of the business pain points for historian data (for example shared

plant ownership) impact both the design and operating phases of any plant,

and thus ARC expects Aspen to pursue cloud-based capabilities. However

given its broad product portfolio, large installed base, and the fact that ap-

plications like APC operate in close touch with process automation, ARC

believes Aspen will place a premium on keeping its deployment models

very flexible so as to provide a wide range of options to existing customers.



Honeywell filed a US patent application for “Cloud Computing as

a Basis for a Process Historian.”.

Honeywell Process Solutions The portfolio of Honeywell Process Solutions (HPS) is much more oriented

to process automation. While so far silent about the cloud, like many au-

tomation suppliers, HPS has aggressively employed server and PC

virtualization within its new Experion PKS Orion to reduce the required

number of servers and PCs and to streamline administration and security

measures.

While Honeywell is publically quiet about any over-

arching cloud strategy, ARC notes that in 2010 Hon-

eywell filed a US patent application entitled “Cloud

Computing as a Basis for a Process Historian.” Given

that, it appears that the company is considering the concept of a cloud-

based historian, but has not publically disclosed any impact on Honey-

well’s existing PHD historian. PHD is a tiered historian product, so site-

wide or enterprise PHD implementations could, in theory, be located in a

cloud. Internally, Honeywell Process Solutions collaborates on many de-

velopment activities within the larger Honeywell ACS organization that

includes both Honeywell’s process and building automation businesses.

Rockwell Automation Another automation supplier example is Rockwell Automation, which has

developed cloud-based projects leveraging its relationship with Microsoft.

In Rockwell’s case the customer was a large drilling equipment manufac-

turer who needed visibility and analytics over many remote sites where its

Rockwell-automated equipment was being operated.

Analysis

A transition to cloud involves two major tasks; a re-architecting of software

and a choice of a deployment model. These two activities are largely inde-

pendent, meaning that private clouds within a plant’s Level 2-Level 3

systems are not revolutionary developments and ARC expects to see these

soon. Cloud deployment options will enable software and solution provid-

ers to more closely match their deliverables to customer preferences. Public

or hybrid cloud or hosted solution architectures are more a natural fit for

applications that operate over several production sites (production plan-

ning and scheduling is one). Here an “external” cloud is an advantage.

Cloud encompasses three major deployment models (public, private, and

hybrid). Application and server platforms that are clearly OT rather than



IT and run inside the plant increasingly resemble private clouds. ABB’s

ServicePort and the extensive use of blade servers and virtualization in new

DCS platforms like Honeywell Experion PKS Orion are just two examples.

ARC expects this trend to continue because cloud technologies enable sup-

pliers to leverage commoditized hardware, software, and networks to

deliver high-availability services.

Many “on-line” manufacturing applications seem at first glance to be un-

likely candidates for cloud computing. This is especially true for

applications like APC, which tend to be tightly coupled to the automation

system and must respond quickly to changes in the process and/or auto-

mation system states. Indeed, ARC believes that some applications will

become more tightly coupled with automation while others will more natu-

rally migrate to the cloud. On the other hand, production applications that

impact multiple plant sites, such as production planning and scheduling,

might benefit from the easier universal access enabled by cloud deploy-

ment. This is particularly true for manufacturers with numerous and

widely distributed plants (e.g., the food and cement industries) that need to

coordinate their operations across multiple facilities.

Historian applications have traditionally taken advantage of improvements

in compute capacity, network speed, and storage capacity. Because of this,

it makes good sense that historian applications will be among the first OT

applications to utilize cloud software architecture, though ARC expects

many manufacturers will initially adopt “private cloud” deployment mod-

els that represent less technological disruption and less perceived risk.

Indeed while historical data is a valuable resource and needs to be kept

confidential, key analytical results are far more strategic to manufacturers.

There are numerous parallels between developments in conventional com-

puting and the emergence of the cloud. The decades-long IT trend has been

toward greater reliance on remote networked computation and storage re-

sources. This trend has persisted from the client/server model of thirty

years ago through the development of the Internet and today manifests it-

self as the growth of cloud computing solutions.



Recommendations

ARC recommends the following for plant owner-operators:

• The term “cloud computing” encompasses so many different options

that plant owner-operators should disregard the term itself, and focus

on what business value can be delivered by any “cloud-enabled” archi-

tectural changes in their applications, especially historians.

• Greater plant data visualization on (non-Windows) mobile devices is

likely to be an early cloud benefit.

• Another cloud historian benefit will be easier sharing of historical data

subsets with partners, enabling collaboration without the need for

granting access to the enterprise network.

• For specific applications, manufacturers should consider the pros and

cons of cloud computing based on whether or not the application is a

“strategic differentiator” for the firm.

• For strategic applications, firms should focus on how cloud could ena-

ble them to deliver greater value. For non-strategic applications, cost

reduction is the primary driver for change.

• Using cloud resources can rationalize IT equipment purchases by great-

ly simplifying system sizing considerations. The cost model for cloud IT

resources features less fixed cost and a more linear variable cost charac-

teristic. Cloud resources will also be available in huge (practically

unlimited) amounts at predictable prices, which are likely to decline

over time. Plant historian applications will be among the first to benefit

from these properties.



Analyst: Harry Forbes

Editor: Paul Miller Distribution: MAS and EAS Clients

Acronym Reference: For a complete list of industry acronyms, refer to our web page at www.arcweb.com/Research/IndustryTerms/

ALM Asset Lifecycle Management APC Advanced Process Control API Application Program Interface APM Asset Performance Management BPM Business Process Management CRM Customer Relationship

Management DCS Distributed Control System EAM Enterprise Asset Management HMI Human Machine Interface HPS Honeywell Process Solutions HR Human Resources IaaS Infrastructure as a Service IOM Invensys Operations Management

ISV Independent Software Vendor IT Information Technology LAN Local Area Network LIM Laboratory Information

Management NIST National Institute for Standards

and Technology OT Operational Technology PaaS Platform as a Service PLC Programmable Logic Controller PLM Product Lifecycle Management SaaS Software as a Service SCM Supply Chain Management TCO Total Cost of Ownership

Founded in 1986, ARC Advisory Group is the leading research and advisory firm for industry. Our coverage of technology from business systems to prod-uct and asset lifecycle management, supply chain management, operations management, and automation systems makes us the go-to firm for business and IT executives around the world. For the complex business issues facing organizations today, our analysts have the industry knowledge and first-hand experience to help our clients find the best answers.

ARC Strategies is published monthly by ARC. All information in this report is proprietary to and copyrighted by ARC. No part of it may be reproduced with-out prior permission from ARC.

You can take advantage of ARC's extensive ongoing research plus experience of our staff members through our Advisory Services. ARC’s Advisory Services are specifically designed for executives responsible for developing strategies and directions for their organizations. For membership information, please call, fax, or write to:

ARC Advisory Group, Three Allied Drive, Dedham, MA 02026 USA Tel: 781-471-1000, Fax: 781-471-1100 Visit our web pages at www.arcweb.com

the plant historian as a cloud...

Documents