JULY 13, 2017

A Functional Description of Automation

By Eric C. Cosman

Keywords

Activity Models, Architecture, Cybersecurity, Portfolio Management, Pro-

cess Automation, Standards

Overview
A May 2016 ARC Insight, Defining the Automation Profession, described
that challenge in terms of the competencies and experience required for
success. That Insight also included observations on how these competencies
are evolving in the face of changing technology and how competency de-
scriptions are necessary due to different perceptions and the lack of
common definitions and expectations.

While that discussion addressed the people as-

To effectively define the scope of
pect of the people/process/technology triad,
automation, it is necessary to consider
each of the people, process and challenges and opportunities remain to address the
technology perspectives. The people and technology aspect. Specifically, what is the func-
process perspectives can be addressed tional definition of the term automation? The
using competencies and business traditional focus on instrumentation and direct
processes; but the technology
control is no longer sufficient. This is due to de-
perspective requires a set of models
velopments such as the increased integration with
that describe functional elements, as
business processes and systems and blurring of the
well as a full range of activities.
underlying technology that drives what has come
to be known as IT-OT Convergence.

As a result, standards development organizations and other stakeholders

need guidance and tools that allow them to position specific products, solu-
tions, and tools within the broad scope of automation. Some are already
available in the form of various reference models, but more are required.

Standards development organizations (SDOs) are addressing these ques-

tions as part of their efforts to better define and manage their standards
portfolios. End users can use a similar approach to manage their portfolio
of installed solutions.

VISION, EXPERIENCE, ANSWERS FOR INDUSTRY

 ARC Insights, Page 2

Defining Automation
The challenge begins with the apparently simple question; What is Auto-
mation? Anyone who has ever tried to answer this question for a
layperson knows that it is more difficult than it might seem, and usually
requires using analogies to things like home thermostats and automobile
cruise controls.

Dictionary definitions such as, The technique, method, or system of oper-

ating or controlling a process by highly automatic means, as by electronic
devices, reducing human intervention to a minimum,1 may be of little
practical use when trying to describe automation to manage technology.

In the context of system specification and design, we must consider the

three typical perspectives of people, process and technology. It is possible
to address the people and process perspectives using a combination of
business processes and competencies, respectively. The technology perspec-
tive often presents specific challenges, but managing large or complex
solution portfolios requires that these be addressed.

Most people have heard of the parable of the blind men and the elephant, in
which a group of blind men who have never come across an elephant be-
fore, describe it based on their sense of touch. The moral of the parable is
that we have a tendency to project our partial experiences as the whole
truth, and ignore other people's partial experiences.

This clearly applies to the functional definition of automation. An instru-

mentation expert has one view, an advanced automation and optimization
expert has another, and the experts supporting the underlying technology
yet another.

Current Models

Over the years, several groups and committees have developed reference
models to address part of this challenge. Notable examples are those in the
Purdue Enterprise Reference Architecture (PERA), and derivative works
such as the ISA-95/IEC 62264 standards. Unfortunately, some of these ref-

1 http://www.dictionary.com/browse/automation

2017 ARC 3 Allied Drive Dedham, MA 02026 USA 781-471-1000 ARCweb.com

 ARC Insights, Page 3

erence models only go so far, typically staying at a relatively high concep-

tual level.

The ARC Collaborative Manufacturing Model (CMM) has been used for
several years as a tool to position specific functional elements along one of
three intersecting axes or dimensions, each
representing a specific lifecycle.

In the Suppliers to Customers dimension, mate-

rial, component, and inventory flows are
managed in and out of production. Manufac-
turers collaborate with upstream suppliers
(e.g., oil & gas production, other raw material
sources, etc.) and downstream suppliers or
transportation logistics providers.

Collaborative Manufacturing Model In the Design to Support dimension, products

are designed in collaboration with both cus-
tomers and subcomponent suppliers; the manufacturing process is de-
signed/optimized for the product. The production process that creates the
products also has a lifecycle that begins with engineering plant design and
build phase. After the plant starts, the lifecycle of the plant moves to the
operate and maintain phase.

In the Business to Production dimension, scheduling, prioritization, and or-

der flow of the manufacturing plants are managed with collaboration from
business systems to distributed production plants or outsourced produc-
tion plants.

By positioning functions within this model, it is possible to identify major

gaps or overlaps, and assign accountable for functions to specific organiza-
tions or business processes.

Some organizations have expanded on the concepts in CMM and similar

models to define the landscape for smart manufacturing. The National In-
stitute for Standards and Technology (NIST) has published a report2 that

2 http://dx.doi.org/10.6028/NIST.IR.8107

2017 ARC 3 Allied Drive Dedham, MA 02026 USA 781-471-1000 ARCweb.com

 ARC Insights, Page 4

describes this landscape based on a definition of a smart manufacturing

ecosystem.

The product, production and busi-

ness dimensions in this model are
essentially the same as those used by
CMM. These are superimposed on a
Manufacturing Pyramid, which
depicts the vertical integration of
machines, plants, and enterprise sys-
tems.

The NIST reports goes on to describe

applicable standards for each ecosys-
tem dimension. It also maps
NIST-IR 8107 Smart Manufacturing Ecosystem standards to each of the levels of the
Manufacturing Pyramid. Finally, it
identifies specific opportunities for further standards development.

While conceptual models such as these are helpful in describing the posi-
tioning of and relationships between major functions, effective portfolio
management requires additional models and approaches.

Specific Challenges
If the intent in defining automation is to determine which functional ele-
ments are within the scope of standards or solutions portfolios, we need
more specificity. A less conceptual approach could address several specific
challenges related to solution specification and system design.

Identifying standards Many industry standards address various aspects

of automation. However, not all apply to all situations. Standards selection
is an essential step in defining scope.

Relating functionality It is not sufficient to simply list the functions that

are included in a particular application of automation. It is also important
to identify relationships between functions. For example, time or data de-
pendencies may have to be considered.

2017 ARC 3 Allied Drive Dedham, MA 02026 USA 781-471-1000 ARCweb.com

 ARC Insights, Page 5

Describing data flows The flow of data between functions is perhaps the
most important relationship that must be identified. All data must have a
specific source and destination.

Regardless of whether associated with a system supplier, systems integra-

tor, or end user; system architects and solution designers are familiar with
these and related questions, as well as the challenges faced in trying to ad-
dress them.

Activity Models

Both the ANSI/ISA-88 (IEC 61512) and ANSI/ISA-95 (IEC 62264) standards
contain Activity Models that logically decompose the functional scope
into specific activities, each with a clear definition. While the two standards
may not be entirely consistent in their use of the activity model concept, the
basic concept is the same.

The scope of Process Automation is generally equivalent to layers 0

through 3 of the ANSI/ISA-95 general reference model. Both the Manufac-
turing Operations (Layer 3) and the Process Control (Layers 0 through 2)
portions can be described as a series of
activities.
Production Production
Recipe
Planning and Information
Management
Scheduling Management
For Process Control (levels 0 through 2),
the ANSI/ISA-88 standard includes a se-
Process Cell
Management ries of models based on a general activity
model. Although initially focused primar-
Unit ily on the needs of Batch processing, this
Supervision
model has some application to a broader
scope of control systems. However, it
Process
Control
does not provide sufficient differentiation
Outside the scope
on functional areas such as control strate-
Personnel and
of this standard
NOTE:
Only major information
Environmental
Protection
gy execution, operator actions, etc.
flows are shown.

ISA-88 Activity Model The major activities in the Manufacturing

Operations portion of the architecture are
defined in ANSI/ISA-95 Part 3, in the form of a series of Activity Models.
The standard begins with a single generic model, as well as more specific
adaptations for Production Operations Management, Maintenance Opera-

2017 ARC 3 Allied Drive Dedham, MA 02026 USA 781-471-1000 ARCweb.com

 ARC Insights, Page 6

tions Management, Quality Operations Management, and Inventory

Operations Management.

By combining elements from the Production

Operations Management Process Control
models, it is possible to create a blended
model that represents the major activities of
an integrated automation system that spans
layers 0 through 3 of the ISA-95 reference
model. This single model in turn provides the
context for describing each of the major activi-
ties, as well as the data flows and
relationships between them.

The ISA Standards and Practices community

is currently considering the use of such a
model as the context or framework for identi-
fying current and required automation
standards. This, in turn, would become the
basis for a comprehensive description of the
Blended Automation Activity Model ISA standards portfolio.

Value to End Users

End users can use a similar methodology to define their own respective
portfolios of automation-related systems and solutions. The first benefit
comes from the fact that each of the functional elements must be clearly
identified, named, and defined. This can greatly reduce the ambiguity often
encountered when discussing functional needs across disciplines such as
Manufacturing Operations and Process Control.

By positioning the functional elements (products and solutions) in their re-

spective portfolios, it is much easier to identify functional gaps or overlaps.
Gaps may represent opportunities for new or improved solutions, while
overlaps may be opportunities to optimize the portfolio.

Describing the information flows between functions provides the means for
identifying dependencies that must be considered when replacing a specific
function.

2017 ARC 3 Allied Drive Dedham, MA 02026 USA 781-471-1000 ARCweb.com

 ARC Insights, Page 7

The above approach to portfolio definition is entirely vendor-neutral. If ap-

plied carefully and consistently, it provides a very useful framework (i.e.,
terminology and concepts) for identifying and communicating strategy and
functional requirements.

Recommendations

Based on ARC research and analysis, we recommend the following actions

for owner-operators and other technology users:

Use consistent terminology All documents and communications ma-

terials that deal with the functional aspects of automation should use a
consistent set of terminology when describing activities.

Define functional scope for your situation Adapt the general approach
described here to develop the functional scope of automation that is
most appropriate for the particular situation based on input from all
stakeholders.

Follow industry standards Monitor developments in standards devel-

opment organizations (e.g., ISA) and adopt new or revised concepts as
they become available and proven in use.

Use cases and case studies Identify and describe use cases and case
studies that illustrate the needs of a specific industry or situation. Pro-
vide these to standards groups to use to help validate their more
general models.

For further information or to provide feedback on this Insight, please contact your
account manager or the author at ecosman@arcweb.com. ARC Insights are pub-
lished and copyrighted by ARC Advisory Group. The information is proprietary to
ARC and no part may be reproduced without prior permission from ARC.

2017 ARC 3 Allied Drive Dedham, MA 02026 USA 781-471-1000 ARCweb.com