Importance of Industry Standards with Regards to a Comprehensive Automation Strategy

 

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 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.

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.

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 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.

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, 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.

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 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)

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 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
• 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.

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)

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)

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 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).

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.

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.

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.

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.

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 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