Importance of Industry Standards with Regards to

a Comprehensive Automation Strategy

BY ERIC COSMAN

Table of Contents
• Executive Overview
• Introduction
• The Standards Landscape
• Significant Standards
• Standards and Strategy
• Recommendations

Executive Overview
This report describes several influential standards and provides practical guidance to end users
and other stakeholders on their importance when developing and executing an automation
strategy.

Standards provide specifications, practices, and guidelines that can help define the
characteristics of a product, process, or service. Following standards help simplify selection
and deployment of products and promote interoperability among multiple devices used in
manufacturing systems. The need for automation-related standards has increased be-cause of
the rapid development and adoption of new technology in are-as such as programming,
communications, and instrumentation.

People tend to use the term “standard” very broadly to refer to any of several types of
documents or specifications, often without specifying the context. This often, in turn, leads to
confusion. It is possible to characterize individual standards from any of several different
perspectives, depending on the situation and the ultimate objective. Each standard typically
focuses on prescribing or influencing response and decisions in one or more general areas:

• Defining functionality
• Achieving interoperability or integration
• Supporting operations processes and procedures
• Supporting technology choices

Both end users and suppliers struggle with how to respond to the large number of standards
developed by industry. Identifying and selecting appropriate standards alone are not sufficient
to achieve real business value. Standards must be selected and applied at various stages of the

1
automation systems lifecycle and as an integral component of a well-defined technology
strategy.

Introduction
Standards and Automation

There is a long history of applying standards in the practice of automation. These standards are
developed and issued by groups or associations of professionals in various fields of experience.
They provide specifications, practices, and guidelines that can help define the characteristics
of a product, process, or service. Following standards help make it simpler to select and deploy
products and promote seamless and secure interoperability among multiple devices and
components used in manufacturing systems. The rapid development and adoption of new
technology in areas such as programming, communications and instrumentation has increased
the need for standards.

Complexity
While standards are essential to successfully automate industrial processes, the number and
complexity of these standards often present challenges for both end users and suppliers. End
users struggle to identify and understand which standards are most applicable for their
situations; suppliers must choose which standards to support with their products and services.

It is difficult, if not impossible, to identify all of the standards that may be relevant to the
application of automation to an industrial process. However, ARC has identified several
standards that are particularly significant by virtue of their maturity, breadth of adoption, or the
im-portance of their subject matter.

Developing a standard is often a long and complicated process and it is common to have several
developing standards competing to address specific areas of technology. Both end users and
suppliers have to make informed choices with respect to how they will support or contribute to
standards development.

There are several standards that are particularly significant for the development and execution
of an automation technology strategy.

Objectives
Several general objectives relate to the identification and development of standards. The first
of these is consistency of practice across a broad array of industries, situations, and technology
platforms. This is the essence of defining accepted industry practice.

2
The use of standard technology, methods, and solutions also contributes to increased solution
scalability. Finally, perhaps the most important promise of standards is to increase the level of
interoperability across solutions and technologies, leading to increased sharing and use of
common information.

Benefits

Standards provide many benefits, including conventions in approaches, methods, work

processes, technology, and terminology. The largest benefits to users are certainty in terms of
operation and commercial benefits, because standardization ultimately reduces supplier’s costs
(even if the initial investment in adhering to the standards may require additional up-front
development resources). Users also realize productivity improvements from standards.
The productivity benefits extend from functional scoping through startup and beyond. With
standards, “one-of-a-kinds” can be eliminated, technology widely reused, and documentation
and training costs minimized.

Suppliers benefit from having a clearer view of current and functional requirements for their
solutions, as well as the opportunity for broader application and interoperability.

Standards-based choices should always take precedence over proprietary ones. The choices
made today should broaden, not limit, future options. Standards promote choices.

The Standards Landscape

The first step in identifying and selecting relevant standards is to be-come familiar with the
general context or landscape. This includes understanding the scope of potential application,
the sources of standards that form the basis for commonly accepted practices, and at least a
general familiarity with the processes and constraints associated with standards development.

The latter subject can be very complex, but a detailed knowledge in this area is generally only
required if an individual or organization decides to actively participate in developing one or
more industry standards.

Characterizing Standards
Most people use the term “standard” very broadly to refer to any of several types of documents
or specifications, often without specifying the context. This lack of specificity or consistency
of usage, in turn, of-ten leads to confusion. The reality is that it is possible to characterize
individual standards from any of several different perspectives, de-pending on the situation and
the ultimate objective.

3
Origins

The first and perhaps most important perspective involves describing standards in terms of
their origin.

Standards development organizations (SDO) such as the International Society of Automation

(ISA), the International Standards Organization (ISO), and the International Electrotechnical
Commission (IEC) develop and administer broad portfolios of standards. Many of these
organizations have complex interrelationships and will often adopt the standards developed by
other organizations either wholesale or with some modifications.

Associations and quasi-standards bodies are industry sponsored and include a wide range of
groups that are industry- or region-specific as well as international. Some of these groups are
not “standards organizations” in the strictest sense, but many end users follow their guidelines
and many suppliers embed these organizations’ standards and recommendations into their
solution offerings. For example, NAMUR , an international association of process automation
industry end users, publishes recommendation documents to help end users share practices and
guide suppliers and industry foundations on future technology and product development.

Some standards organizations develop standards specifically for a single industry. However,
these standards may also be adopted by companies in other industries if deemed suitable. Many
standards are specific to certain regions or countries. One example is the Japanese Industrial
Standards (JIS), which specifies the standards used for industrial activities in Japan. The
standardization process is coordinated by Japanese Industrial Standards Committee (JISC) and
standards are published through the Japanese Standards Association (JSA).

Industry foundations are typically sponsored by both supplier and end user clients and
administer industry-standard technologies. They may or may not fall under the auspices of ISA,
IEC, or other such standards bodies. The FieldComm Group is one example. Formed with the
combined assets of the now defunct Fieldbus Foundation and HART Communication
Foundation, the FieldComm Group is the single organization responsible for administering the
HART, WirelessHART, and FOUNDATION fieldbus protocols. Other industry foundations
include OPC Foundation, ODVA (Open DeviceNet Vendors Association), FDT Group, FDI
Cooperation, PROFIBUS International, and many others.

Certifying bodies are organizations that test products and applications for conformance to
certain standards. The world of process safety provides some good examples in the form of
exida and TÜV, which certify products for use in safety applications. Industry foundations also
do conformance testing, interoperability testing, and will register or certify products that
conform to the specifications of their supported technologies. The FieldComm Group, for
example, handles all testing and registration of FOUNDATION fieldbus devices and host
systems, as well as HART and WirelessHART devices. PROFIBUS International does the

4
same for PROFIBUS products. OPC Foundation also offers testing and registration for OPC-
compliant products.

For some technologies, a third party or separate organization may per-form testing, registration,
and certification. For example, the Wireless Compliance Institute (WCI) handles ISA-100.11a
compliance. WCI has its own governing board that is separate from the activities in the ISA-
100 standards committee. ISASecure offers certification for host systems and devices from a
cybersecurity standpoint, specifically the ISA/IEC 62443 standards.

As a general rule, ARC advises its end user customers to purchase products that are certified,
tested, and registered wherever possible. Certification, testing, and registration guarantees a
certain level of functionality and interoperability.

Development and Acceptance

Standards may also be characterized by type, in terms of how they have been developed and
come to be broadly accepted.

De facto standards may or may not be administered by a standards body and technically are
not “official” standards for the process automation business (as opposed to standards that fall
under the auspices of organizations such as IEC or ISA). De facto standards have been adopted
by many industries, organizations or other constituencies. The big difference between official
standards and de facto standards is that suppliers in the industry are not required to support de
facto standards, although most eventually do.

De facto standards include IT-related technologies such as Ethernet (which became an IEEE
standard after initial acceptance); Microsoft Windows; and other technologies supported by
Microsoft, such as .Net. For some de facto standards, the choices on the market may be more
limited as not all suppliers may necessarily support them as rigorously as they do official
standards.

Prescriptive and Non-prescriptive

Prescriptive standards define specific aspects of a technology or specific steps and
requirements that must be taken to adhere to the standard. One example of a prescriptive
standard is ISA-100.11a, which defines the characteristics of wireless sensor networks to be
used in process automation. WirelessHART is similar in that it falls under the IEC 62591
standard. The ISA-84 and IEC 61511 safety standards define a standard safety lifecycle that
must be followed.

5
Non-prescriptive standards come in several varieties. Rather than providing mandates, they
typically provide recommended guidelines, models, templates, or generic work processes that
can be followed, but do not necessarily have to be adopted to the letter.

Scope of Application
Standards are also often grouped according to their scope of application, expressed in terms of
functionality, discipline, or geographic region.

Intent
Perhaps the most useful and practical way to characterize standards is by intent. Each standard
typically focuses on prescribing or influencing response and decisions in one or more general
areas:

• Definition of functionality
• Achieving interoperability or integration
• Operations processes and procedures
• Technology choices

Implications
When identifying, considering and selecting standards it is very important to understand the
scope and limitations of the various alternatives, as well as the basic intent or desired outcome
of their adoption.

The origins and types of standards are generally less important, although they should not be
disregarded entirely.

Significant Standards

The application of and alignment to established standards are important for both end users and
suppliers. However, it is difficult if not impossible to be familiar with all of the standards that
exist, even within a specific discipline such as automation. For this reason, it is important to
identify significant standards that are the most relevant, either be-cause of their concepts and
requirements, or the range and scope of their applicability.

Collaborative Process Automation System (CPAS)

ARC Advisory Group provides a detailed description of a modern automation systems in its
Collaborative Process Automation System (CPAS) report. It addresses guiding principles,

6
architecture, key enabling technologies and standards, and business-enhancing applications.
The CPAS report also contains detailed descriptions of a broad range of standards relevant to
process automation. This ARC Strategy Report discusses a subset of those standards.

Standards Categories
Relevant standards may be grouped into broad categories, based on their stated purpose or
intent. As described in the previous section, these purposes include:

• Definition of functionality
• Achieving interoperability or integration
• Operations processes and procedures
• Technology choices

The following paragraphs describe several standards in each of these categories and explain
why they may be significant when developing an automation strategy.

Functional Standards

Standards in this category provide requirements and guidance for solutions in a specific
functional area. The significant standards in this cate-gory include:

ISA-18.2 (Alarm Management)

The ISA-18.2 standard prescribes a lifecycle-based approach to managing alarms. It guides end
users through the process of establishing a lifecycle program in which alarms are set up,
rationalized in a consistent way, and reviewed for effectiveness.

ISA-18.2 outlines practices for developing alarm strategies for both new plants and existing
facilities. It covers all aspects of alarm strategy development, from alarm philosophy to
rationalization, detailed design, implementation, operation, maintenance, management of
change, monitoring and assessment, and auditing. The standard also builds on earlier work by
the Abnormal Situation Management Consortium (ASM), the Engineering Equipment and
Materials Users Association (EEMUA), and NAMUR.

This standard is significant for automation suppliers. While it does not specify how to design
alarm systems, it does help them make modifications to their alarm management solutions that
will allow end users to put together their alarm management program or strategy.

7
For end users, effective alarm management is an important aspect of operating automation
systems. ARC expects the ISA-18.2 standard to have a significant impact on end user
approaches to alarm management and alarm philosophy and strategy development. It should
result in improved supplier alarm management offerings, increased adoption of a continuous
improvement approach to alarm management, and, ultimately, will result in fewer incidents
and lowered unplanned downtime for the process industries.

IEC 61508 (Functional Safety)

Functional safety is fundamental for the typically complex technology used for safety-related
systems. It provides the assurance that the safety-related systems and equipment will function
as intended to help reduce risk to the desired level. The IEC 61508 standard describes
requirements for functional safety that apply across all industry sectors.

This standard has seven parts, addressing topics from general safety requirements to specific
system and software requirements and guidelines to applications. It can be used both as a
standalone standard and by international standards organizations as a basis for the developing
industry-specific standards, such as for the machinery, process, or nuclear sectors.

This standard is significant for end users because it describes the generic requirements for
functional safety, and provides the basis for certifying safety systems.

When evaluating safety systems, users should select one certified by an independent third party
such as Factory Mutual (FM), exida or TÜV. Note that the certificate from the independent
body should be reviewed in parallel with the User Safety Manual. This is a vendor-supplied
document that defines the restrictions on use of components in a safety instrumented system
(SIS). The manual for a good safety system should be concise, with a minimal number of
restrictions.

IEC 61511/ISA-84 (Safety Instrumented Systems for the Process Industries)

This standard defines the functional safety requirements established by IEC 61508 in the
context and terminology of the process industry sector. Specifically, it addresses applying
safety instrumented systems (SIS) to take a process to a safe state when predetermined
conditions are violated. Its objective is to define requirements for these systems.

The standard has three parts. Part 1 of IEC 61511 is primarily normative, while Parts 2 and 3
are informative.

Part 1 describes the framework, definitions, system, hardware, and software requirements. It is
structured to adhere to a safety lifecycle model. The hazard and risk analysis utilizes the
concept of protection layers and specifies the safety integrity level (SIL) concept developed by
the IEC 61508 standard. It also lists key issues that need to be addressed when developing a
8
safety requirement specification. Issues like separation, common cause, response to fault
detection, hardware reliability, and proven-in-use are also addressed. Software safety
requirement specifications address such items as architecture, relationship to hardware, safety
instrumented functions, safety integrity levels, software validation planning, support tools,
testing, integration, and modification.

Part 2 contains guidelines on the application. It provides “how to” guidance on specifying,
designing, installing, operating, and maintaining safety instrumented functions and related
safety instrumented systems. It borrows heavily from the ISA technical report ISA-
TR84.00.02, which provides guidance on methods to calculate the performance of safety
instrumented systems.

Part 3 provides guidance for determining the required safety integrity levels through the use of
process hazard and risk analysis. It provides information on the underlying concepts of risk and
the relationship of risk to safety integrity and the determination of tolerable risks.

The significance of this standard for end users is that it provides best safety practices for all
users to follow when implementing a modern safety instrumented system (SIS). The US
Occupational Safety & Health Administration (OSHA) has endorsed IEC 61511/ISA 84 as a
“national consensus standard,” stating that it is considered “a recognized and generally
accepted good engineering practice” for SIS.

Although both the 61508 and 61511 standards address the subject of safety systems, there are
important differences in their focus and approach, as shown in the following table.

ISA-88 (Batch Control)

9
Controlling batch processes is an important functional element of mod-ern automation systems.
The predominant standard in this area is ISA88.

This standard provides a consistent set of standards and terminology for batch control and
defines the physical model, procedures, and recipes. It addresses the lack of a universal model
for batch control, difficulty in communicating user requirements, integration among batch
automation suppliers, and difficulty in batch control configuration.

There are several parts to this standard, each addressing a specific aspect of the subject. They
are summarized in the following table.

A fifth part of the series is being developed on implementing models and terminology for
modular equipment control.

XML schema have also been developed based on the ISA-88 and ISA-95 standards. ISA-88:
BatchML (Batch Markup Language) consists of schemas based on ISA-88 Recipes, Control
Recipes, Recipe building blocks, Equipment elements, Batch lists and Enumeration sets.
B2MML (Business to Manufacturing Markup Language) consists of some schemas based on
ISA-95/IEC 62664 Part 2.

The ISA-88 standard is significant because it helps create more flexible manufacturing
processes. It defines a process model, which includes a process that consists of an ordered set
of process stages; which consists of an ordered set of process operations; which consists of an
10
ordered set of process actions. ISA-88 can be applied in fully automated, semi-automated, and
even in completely manual production processes.

ISA-101 (Human-Machine Interfaces)

This standard addresses the philosophy, design, implementation, operation, and maintenance
of human machine interfaces (HMIs) for process automation systems, including multiple work
processes through-out the HMI lifecycle. It is also intended to help users understand the basic
concepts as a way to better and more readily accept the style of HMI that the standard
recommends. The intent is for the standard to apply to all manufacturing industries. Specific
areas covered by ISA-101 include:

• Menu hierarchies
• Screen navigation conventions
• Graphics and color conventions
• Dynamic elements
• Alarming conventions
• Security methods and electronic signature attributes
• Interfaces with background programming and historical databases
• Popup conventions
• Help screens and methods used to work with alarms
• Program object interfaces, and
• Configuration interfaces to databases, servers, and networks

The target audiences for this standard include end users, designers, developers, and
implementers of HMI systems.

End users should review this standard for guidance on how to design, build, operate and
maintain HMIs to achieve a safer, more effective, and more efficient process control system
under all operating conditions. Its use also improves the user’s abilities to detect, diagnose, and
properly respond to abnormal situations.

ISA-106 (Procedural Automation)

The ISA106 committee was established to develop standards, recommended practices, and
technical reports on designing and implementing procedures for automating process operations
to help prevent the recurrence of similar, preventable events. Their goal is to help industry
address current and future needs and reduce overall business risk.

Committee work products will apply to continuous processing applications, addressing topics
including:

• Models and terminology

• Modularization of procedural steps to foster re-use and lower TCO
• Exception handling for abnormal situations
• Physical, procedural, and application models
• Process unit orientation with operational perspective
11
 • Recommended practices
• Implementation of startup, shutdown, abnormal situations, hold states, and transition
logic
• Recommended target platform (i.e. control system vs. safety system) for different types
of procedures
• Lifecycle management practices
• Training and certification practices

The first work product of the ISA106 committee was a technical report, titled “ISA-
TR106.00.01-2013 Procedure Automation for Continuous Process Operations – Models and
Terminology.” The committee is currently working to produce a second technical report
addressing the lifecycle of automated procedures and is working on the standard.

The significance of this activity comes from the growing pressure to improve the design,
implementation, and operation of production procedures. It is increasingly important to
optimize asset utilization, maintain margins, better ensure the safety of physical and human
assets, and reduce the high cost of engineering and maintenance.

Many processes are automated for “normal” operations, but not for startup, shutdown, grade
changes, product changeovers, or abnormal situations. Operators often lack adequate
information about the state of the process during these events. In the North American process
industries, unscheduled shutdowns or slow-downs account for from 2 to 5 percent of process
plant production. Forty-two percent of this relates to people and 14 percent to issues associated
with following procedures.

ISA-108 (Intelligent Device Management)

The objective of the ISA108 committee is to define the use cases, mod-els, and terminology
for intelligent device management (IDM) approaches in process automation. These use cases
span the entire spectrum of the plant lifecycle, from engineering and design to installation,
commissioning, operations, maintenance, and more. The models and terminology will also
include explanations of IDM lifecycles, maintenance processes, diagnostic utilization,
configuration management, and information on maintenance process choices.

The models and terminology form the basis for defining work processes that will provide a
basic template for end users that want to implement IDM processes in their plants and can be
customized to fit the end user’s own requirements. These work processes will also span across
the plant lifecycle, and will be broken up into three primary categories: Configuration and
Revision Management, Diagnostics Management, and Field Procedure Management.

In many ways, maintenance routines in process plants have not changed significantly for many
decades. Routine, preventive maintenance is still the order of the day. Maintenance technicians
still travel out to the field to inspect devices for potential issues. Intelligent field devices offer
the potential to change the way maintenance is done in process plants in some fundamental
ways. In place of often inefficient preventive maintenance rounds and routines, real-time digital
diagnostics from instruments and valves can be used to schedule maintenance based on actual
conditions. This enables today’s time-strapped maintenance staffs to focus on the devices and
assets that actually require attention and become more actively involved in optimizing plant
performance.

12
Interoperability Standards

While functional standards describe common methods, tools and processes, it is also important
to recognize that modern automation systems include elements from a variety of sources and
that interoperability and information sharing between these elements are essential for success.
Several standards of this class are significant for automation system design.

ISA-95/IEC 62664 (Enterprise-Control Systems Integration)

The ISA-95/IEC 62264 standard has received considerable attention in the process industries
for standardizing both integration and information models. The ISA95 committee maintains
the standards and supports their evolution.

The initial parts of the standard define terminology, functional models for operations
management, and information exchange objects. Several manufacturing businesses have used
these to define integrations and clarify communications with systems and software suppliers.
Grouping operational systems into specific levels has become ubiquitous in industry.

Many operations management and enterprise software suppliers have used parts of the standard
as the basis for integrated solutions. Some have adopted ISA-95/IEC 62264 models as the basis
for defining information storage structures. For example, the equipment model is quite useful
for defining equipment information hierarchies.

End users may not need a detailed understanding of the full set of ISA-95/IEC 62664 standards
but, as a minimum, they should be familiar with the basic concepts, since they often provide
the context for supplier products descriptions and proposals.

OPC Specifications (Data Exchange)

13
The OPC Foundation, an international nonprofit organization, has developed a series of
specifications and certifications to enable multivendor interoperability for moving data and
information from the embedded world to the enterprise.

While the original idea behind OPC was to provide standardized communication between
hardware devices and applications, the specifications are also used to develop interfaces
between applications.

The original specifications are referred to as “OPC Classic.” The Data Access specification
(OPC DA) describes how applications exchange data on a Microsoft platform. It provided a
solution to a significant problem and industrial automation and numerous automation systems
and product vendors rapidly supported it. It can be integrated into production management and
ERP systems running on Unix/Linux systems using Java, as well as on controllers and
intelligent devices with real-time operating systems.

The more recent OPC Unified Architecture (OPC UA) is a multiplatform, multivendor series
of specifications for secure reliable interoperability for moving data and information from the
embedded world all the way to the enterprise. These specifications provide a platform to enable
existing OPC Classic products to be seamlessly plugged in allowing complete interoperability
of all OPC based solutions.

The OPC UA specifications provide a rich information model using object-oriented techniques
that not only make it possible to offer a measured value and its engineering unit, but also to
expose the specific type of sensor. The specifications define a simple set of base types that can
be extended by information models, either application-specific, vendor-specific, or
standardized models. Using standard information models lifts interoperability to the next level.
This not only allows interoperable data exchange, but also uses interoperable models. In the
long term, this can drastically reduce engineering costs when integrating systems using
products of different vendors.

Market analysts estimate that more than 4,500 different companies have employed OPC-based
technology in more than 35,000 different products in the marketplace, resulting in literally
millions of installations. Thus, almost every system targeting industrial automation implements
OPC in some manner.

Business to Manufacturing Markup Language

The Business To Manufacturing Markup Language (B2MML) is an XML implementation of
the models defined in ISA-95 provided by the World Batch Forum. B2MML consists of a set
of XML schemas written using the XML Schema language (XSD) that implement the data
models. B2MML is a complete implementation of ISA-95 as documented in the completeness,
compliance, and conformance statement that is part of the B2MML download. Any company
may use B2MML royalty-free as long as it credits the source.

Operational Standards
In addition to addressing required functionality and the conventions and methods used to
integrate various components, it is also important to address the operation of automation
systems. One specific example in this category is ensuring the security of automation systems.

ISA-62443 (Industrial Automation and Control Systems Security)

14
The ISA99 committee (Industrial Automation and Control Systems Security) was chartered to
address industrial automation and control systems for which compromised security could
involve any or all of the following:

• endangerment of public or employee safety

• environmental protection
• loss of public confidence
• violation of regulatory requirements
• loss of proprietary or confidential information
• economic loss
• impact on entity, local, state, or national security

The committee has been collaborating with IEC Technical Committee 65 working group 10
(TC65 WG10) to develop the ISA/IEC 62443 series of standards. These standards are designed
to enhance and extend general-purpose IT security standards such as those in the ISO 27000
series.

The standards in the 62443 series are built around a set of fundamental concepts:

Security Lifecycle – This lifecycle is focused on the security level of a portion of the system
over time. A change to a physical asset may trigger a set of security-related activities, or the
discovery of new security vulnerabilities may trigger changes to the physical asset or the
addition of additional mitigating measures.

Security Program Maturity – A mature security program integrates all aspects of

cybersecurity, incorporating desktop and business computing systems with industrial
automation and control systems. The development of a program shall recognize that there are
steps and milestones in achieving this maturity.

Zone and Conduits – Segmenting or dividing a system under consideration for the purpose of
assigning security levels and associated measures is an essential step in the development of the
program.

Security Levels – Assets that make up the system under consideration shall be assigned desired
security levels using the mechanism defined in ISA-62443-3-2.

Foundational Requirements – The full scope of detailed technical and program requirements
shall be derived from a small set of foundational requirements.

Safety and Security – In an IACS context the subjects of Security and Safety are closely
linked. A failure to secure an IACS can in turn result in a potentially unsafe System under
Control.

Each of these concepts is introduced in the initial standard in the series (62443-1-1) and
addressed in more detail in one or more standards in the series.

ARC expects the significance of ISA/IEC 62443 to increase as more standards in the series are
completed and the security-related expectations and requirements of industrial control systems
continue to evolve and increase. Suppliers will increasingly be called upon to deliver their
solutions with security capabilities as defined in the standards. End users will be expected to

15
operate and maintain their control systems in a secure manner. To meet these requirements
both parties will be required to have some level of familiarity with the standards.

Technology Standards
The fourth category of standards address the technologies that form the basis of information
and communications systems. Several standards in this group are particularly relevant for
automation systems.

Digital Process Fieldbuses

Traditionally, field devices connected to the process automation system with analog 4-20mA
cables. Special I/O cards then translated the signal from analog to digital. While analog
connection is still an option, digital fieldbuses are increasing in popularity. A fieldbus is a
digital data bus for communications between industrial control and instrumentation de-vices
such as transducers, actuators, and controllers. Important fieldbuses in process automation are
PROFIBUS (IEC 61158/61784), FOUNDATION fieldbus, and HART.

IEC Fieldbus Standard – The true fieldbus networks conform to the IEC 61158
standard. Competition in process fieldbus is limited to FOUNDA-TION fieldbus H1 and
Profibus PA. Fieldbus goes beyond the field net-work requirements, however, and
incorporates a high-speed bus at the control layer, such as FOUNDATION fieldbus HSE,
PROFIBUS DP, or Profinet. The IEC fieldbuses will continue to provide the basis for
interoperability and IEC 61158-2 defines the physical layer of the seven-layer stack.

FOUNDATION Fieldbus – Replacing 4-20 mA technology with a digital network was a big
factor in the development of FOUNDATION technology. This technology includes not only
control function blocks, but also has mechanisms for time management, global data access, an
open and standards-based control network backbone in the form of HSE, and many other
aspects that make it a true automation infrastructure. FOUNDATION technology is open and
based on international standards, allowing any automation supplier to incorporate the
technology into its framework for automation while still allowing room for competitive
advantage.

One of the advantages of this openness and standards-based structure is that the technology can
evolve in step with the overall world of technology, providing a sustainable framework that is
being continuously updated. The initial phase of FOUNDATION technology was to develop
a standards-based baseline technology that is operating system independent and “fit for
purpose” for the stringent requirements of process automation, including intrinsic safety,
determinism, and redundancy.

PROFIBUS (Process Field Bus) is a standard for fieldbus communication in automation

technology. It is openly published as part of IEC 61158. Two variations of PROFIBUS are in
use today.

PROFIBUS DP (Decentralized Peripherals) is used to operate sensors and actuators via a

centralized controller in production automation applications.

PROFIBUS PA (Process Automation) is used to monitor measuring equipment via a process

control system in process automation applications. It is designed for use in explosive or
hazardous areas (Ex-zone 0 and 1).

16
In excess of 30 million PROFIBUS nodes were installed by the end of 2009; five million in the
process industries.

Highway Addressable Remote Transducer (HART) – This is an early implementation of

fieldbus. HART devices can communicate over legacy 4-20 mA analog instrumentation wiring,
sharing the pair of wires used by the older system. HART is a good transition protocol for users
who were comfortable using the legacy 4–20 mA signals, but wanted to implement a "smart"
protocol. However, ARC research indicates that few users today are taking advantage of the
full capabilities of their HART devices for asset management purposes.

IEC 61131-3 (Configuration Standard)

The IEC 61131 international standard defines programming languages for programmable
controllers. While IEC 61331 programs cannot usually be directly transferred between different
suppliers’ systems, the standard greatly supports transferring training and know-how between
the systems.

IEC 61131-3 provide a single set of programming languages for the industry. These are
Sequential Function Charts, Instruction List, Ladder Diagram, Function Block Diagram, and
Structured Text.

The standard also controls how a control system is configured. While it provides common
structure and details, the code is not transferable between different suppliers. IEC61131-3 is
designed for a common model distributed processing system with shared common services.
The next generation of IEC 1131 will support IEC 61499, which will support true distributed
control. Users should consider the future ability of suppliers to accommodate IEC 61499.

IEC 61850 (Electrical Equipment)

This standard, based on Ethernet technology, is a communication standard for electrical
substation automation systems. It simplifies integrating electrical components from different
manufacturers and reduces costs for operating and maintaining these systems. IEC 61850 does
not replace the process automation fieldbuses, but can eliminate the many different serial
interfaces in the area of the electrical systems.

17
IEC 61850 is more than just a protocol, it provides a way to model the information associated
with substation automation separately from the means by which it is communicated. The
standard provides a way to model not only the primary equipment, but also secondary devices
and their respective functionality. The standard describes conformance testing, and suppliers
looking to serve the substation automation market are getting their products certified.

IEC 61346 (Object-Based Systems)

The IEC 61346 standard encompasses the world of object-based systems. It uses the important
concepts of object, aspect, and structure. Structuring is a way to organize the objects of a system
to facilitate all activities that need to be performed during the entire lifecycle of that system.
Structuring enables reusable objects to be defined that can be used as building blocks that can
be fine-tuned based on feedback from solution experience to increase quality.

IEC 61346 defines an object as an entity in the process of design, engineering, realization,
operation, maintenance, and demolition. An aspect is a specific way of selecting information
on or describing a system or an object of a system. A reference designation unambiguously
identifies an object of interest within the considered system. Diagrammatically, nodes in tree-
like structures represent these objects. The branches represent the subdivision of these objects
into other objects (sub-objects). Each object that occurs within another object is assigned a
single-level reference designation unique with respect to the object in which it occurs. The
object represented by the top node is not assigned a single-level reference designation.

IEC 61346 establishes three general-purpose, fundamental structures that can be applied to any
technical system:

• Function-Oriented – Structure where objects are organized according to functional

aspect. It answers the question, “what does the object do?” and is identified by the equal
sign.
• Location-Oriented – Structure where objects are organized according to its location
aspect. It answers the question, “where is the object located?” and it is identified by the
plus sign.
• Product-Oriented – Structure where objects are organized according to the product
aspect. It answers the question, “how is the object constructed?” and is identified by the
minus sign.

Common Infrastructure Standards

Due to growing adoption of commercial off-the-shelf (COTS) technology, several general
information technology standards have also become important in process automation. Common
examples include:

IEEE 802.3 (Ethernet), a collection of IEEE standards define the physical layer and data link
layer's media access control (MAC) of wired Ether-net. It has become the prevalent means to
connect automation systems components.

SNMP (Simple Network Management Protocol), commonly supported by network-connected

components of an automation system, is used by asset and network management and
monitoring systems.

18
SNTP (Simple Network Time Protocol) is used by many modern control systems to
synchronize the clocks across multiple network elements.

XML (Extensible Markup Language), a markup language that defines a set of rules for
encoding documents in a format is both human-readable and machine-readable. Although the
design of XML focuses on documents, it is widely used to represent arbitrary data structures.

SQL is a special-purpose programming language designed for managing data held in a

relational database management system (RDBMS). These databases are now very commonly
used for a variety of functions in a process automation system.

Standards and Strategy

Just identifying and selecting standards is not sufficient to achieve real business value.
Standards must be selected and applied at various stages of the automation systems lifecycle
as an integral component of a well-defined technology strategy.

Such a strategy may consist of one or more of several components, de-pending on the nature
of the business situation and the desired results.

Standards Reference Model

Identifying and selecting applicable and significant standards related to process automation
would be much easier in the context of a general-purpose, industry-vetted reference
model. This would describe each standard and position it in terms of business processes and
other aspects of the automation environment. Unfortunately, any model that incorporates each
of the dimensions used to characterize standards would almost certainly be too complex for
practical application.

Several attempts have been made to describe such a model, typically in response to a specific
opportunity. One example is the ARC Collaborative Manufacturing Model (CMM). CMM
provides a framework that can be used to drive strategic planning and technology
assessment. Solutions, standards and technologies can be mapped to this model in order to
identify gaps, overlaps, and other opportunities.

19
The International Society for Automation (ISA) is also investigating options for such a model
that could be used to position the various standards in its portfolio.

Systems Architecture
Even without a general reference model, stakeholders should ideally define a systems
architecture that includes principles, models, and standards that can be used to help make
informed decisions about adopting, acquiring, or developing specific solutions, as well as the
integration required to connect them together.

Technology and Solution Selection

While it is certainly possible to adopt an architecture from a specific supplier for this purpose,
this will inevitably narrow the range of choices possible. The preferred approach is to focus on
functionality and integration, rather than specific solutions or products.

Technologies and solutions should be selected, deployed, and eventually replaced based on a
specific business and/or operational need.

Management Processes
Specific management processes are required to provide rationale and consistency to the
decision making processes. Lifecycle management is perhaps the most important of these. In
addition to addressing the se-lection of new solutions, this process must also address the
requirements for supporting current solutions as well as criteria used to make decisions about
their eventual retirement or replacement.

Advancing Standards
In certain situations, an end user may decide to actively engage in the development of specific
standards to fulfill a specific need or advance a particular agenda.

It is essential to have the necessary processes in place to manage standards engagement on an

ongoing basis. Although the details may vary, most of these processes follow the familiar “plan,
do, check, act” cycle. It is also important to define metrics for this process to be able to
demonstrate the value of standards engagement.

If multiple opportunities are identified, it is necessary to characterize them according to

relevance to business strategy and the desired outcome. Although various classification
schemes are possible, a typical one might include the following designations, each of which
represents and increasing degree of involvement.

User Options
With respect to specific standards or areas of technology development at an industry level, the
end user should choose from a small number of possible responses, based on an assessment of
the situation and the business need.

20
Decisions about when and how to engage are also influenced by the current state of the
standard(s) in question as well as strategic importance and availability of resources. For
standards currently under development, there may be some sense of urgency to have any
significant influence on the outcome. If a standard has already been published, it may be
necessary to wait until there is an opportunity to con-tribute to a revision cycle.

Resources and Commitment

It is also important to determine the best approach to engagement, including the selection of
and support for those who will serve in an active role.

Such activities must be properly managed and monitored, rather than simply leaving it solely
to individual initiative and interest. While these are important in making personnel
assignments, several other factors should be considered.

Assessing Results
All activities related to the development, support and application of standards should be tracked
and recorded in the same manner as any internal project-related activities. This allows ongoing
assessment of the effort against benefits returned to determine an approximate return on
investment (ROI). Although this may be less quantitative than what is possible for typical

21
projects, it remains an important metric. Assessing standards-related or similar external
activities must become part of the regular performance management process.

Recommendations
In addition to the recommendations provided in the above sections, ARC has several
recommendations for those organizations that are considering active involvement in standards
activities.

With the large number of possible opportunities for involvement in developing industry
standards, it is essential for end users to have clear criteria for selecting those that have the
greatest potential benefit and chance of success.

Based on ARC research and analysis, we recommend the following actions as a means to
establish such criteria:

• Consider the use of the ARC Collaborative Process Automation System (CPAS) report
as a more detailed reference on the subject of automation related standards.

• Prepare a description of the desired systems and technical architecture for automation
systems in order to provide a consistent context for making technology and solution related
decisions.

• Include the use of or consistency with established industry standards as a criterion in

the process for solution assessment and selection.

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

22