How to Describe Automation by Functionality

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 descriptions are necessary due to different perceptions and the lack of common definitions and expectations.

While that discussion addressed the “people” aspect of the people/process/technology triad, challenges and opportunities remain to address the technology aspect. Specifically, what is the functional definition of the term “automation?” The traditional focus on instrumentation and direct control is no longer sufficient.  This is due to developments such as the increased integration with business processes and systems and blurring of the 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, solutions, 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 questions 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.

Describe Automation

The challenge begins with the apparently simple question; “What is Automation?” 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 operating 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 perspective 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 before, 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 instrumentation 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 reference models only go so far, typically staying at a relatively high conceptual 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, material, component, and inventory flows are managed in and out of production.  Manufacturers collaborate with upstream suppliers (e.g., oil & gas production, other raw material sources, etc.) and downstream suppliers or transportation logistics providers. 

In the Design to Support dimension, products are designed in collaboration with both customers and subcomponent suppliers; the manufacturing process is designed/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 order flow of the manufacturing plants are managed with collaboration from business systems to distributed production plants or outsourced production plants.

By positioning functions within this model, it is possible to identify major gaps or overlaps, and assign accountable for functions to specific organizations or business processes.

Some organizations have expanded on the concepts in CMM and similar models to define the landscape for smart manufacturing. The National Institute for Standards and Technology (NIST) has published a report[2] that describes this landscape based on a definition of a smart manufacturing ecosystem.

The product, production and business 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 systems.

The NIST reports goes on to describe applicable standards for each ecosystem dimension. It also maps 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 positioning 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 elements 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 dependencies may have to be considered.

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 integrator, or end user; system architects and solution designers are familiar with these and related questions, as well as the challenges faced in trying to address 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 Manufacturing Operations (Layer 3) and the Process Control (Layers 0 through 2) portions can be described as a series of activities.

For Process Control (levels 0 through 2), the ANSI/ISA-88 standard includes a series of models based on a general activity model. Although initially focused primarily on the needs of Batch processing, this model has some application to a broader scope of control systems. However, it does not provide sufficient differentiation on functional areas such as control strategy execution, operator actions, etc.

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 Operations 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 activities, 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 identifying current and required automation standards. This, in turn, would become the basis for a comprehensive description of the 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 respective 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.

The above approach to portfolio definition is entirely vendor-neutral. If applied 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 materials 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 development 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. Provide these to standards groups to use to help validate their more general models.

 

If you would like to buy this report or obtain information about how to become a client, please  Contact Us

Keywords: Activity Models, Architecture, Cybersecurity, Portfolio Management, Process Automation, Standards, ARC Advisory Group.