Representative End User Clients
Representative Automation Clients
Representative Software Clients
Overview
In industrial automation, as with other technical disciplines, it is generally accepted that the development and adoption of standards are important to advance the technology. In this manner, standards are important for end users and suppliers alike. Technology and product capabilities change as a result of research and development, sometimes in disruptive ways. Some of this disruption can be mitigated by developing standards that codify these changes in forms that promote broad adoption. These standards can be of three types:
- Formal industry standards, developed by a recognized standards development organization (SDO), using verified practices
- De facto (open) standards that have not yet been sanctioned by one or more industry bodies
- Proprietary (closed) standards
Standards of each of these types contain information that can be used to define functional and technical requirements that ultimately contribute to the development of improved industrial automation system capabilities.
Standards that define essential functions translate into more choice for the end user. At the same time, newer standards are emerging in areas ranging from application techniques to security and infrastructure. Suppliers participate in these developments for several reasons, ranging from promoting their solutions to assessing industry needs. Standards committees provide a very useful forum in which end users can develop a consensus on needs and requirements and share these with suppliers.
Essential Automation System Capabilities
The fundamental purpose of automation is to optimize processes to reduce risk and variability and maximize production. Safely and securely operating industrial processes as close to possible to physical and economic limits creates value for the end user. Virtually all current and requested capabilities of the automation system are employed to achieve this goal.
While end users can and do specify a rich set of capabilities in the form of business and system requirements, several capabilities are generally considered to be “table stakes” (requirements) for any modern installation. Most of these have been addressed in existing standards.
Safety
Safe operation is essential for any automated system. Standards such as IEC 61508 and IEC 61511 clearly define the requirements in this area. These requirements, in turn, form the basis for system certification.
Availability
Very high system availability has long been a fundamental tenet in the automation discipline. If the control of complex and potentially hazardous industrial processes is to be trusted to an automated system, that system must be capable of operating essentially uninterrupted over extended periods of time. For such systems, availability targets of over 99.999 percent are common. It is possible to achieve such targets through a combination of system design, reduced variability, and the careful use of proven and standard technologies.
Resilience
As important as it is, availability alone is not sufficient. Automation systems must also be resilient in the face of changing threats and conditions. There may have been a time when it was possible to operate these systems for years in an essentially unchanging environment. This is clearly no longer the case. The system software supporting these systems changes almost constantly, and with the increased need to connect them to external business systems, they have become vulnerable to a rapidly evolving threat environment. As a result, reducing the vulnerability of industrial automation systems to computer- and network-based attacks and intrusions has been a major area of emphasis for over a decade.
Evolution and Migration
Given the rapid pace of change in technology, automation systems must be designed and implemented in a manner that allows them to evolve over time, including inevitable migration and replacement. End users have long expressed this need, but individual suppliers have responded to varying degrees, particularly when it comes to migrating to other suppliers’ products.
Interoperability
No automation solution or more complex system exists in a vacuum. Although previous generations of systems may have been configured to perform defined functions without having to depend on external functions or information, this is simply no longer possible. Modern systems must be able to exchange information with counterparts at other levels of the architecture, as well as with peer level systems using products and technologies from various sources. Examples include the use of business information for production planning and scheduling, and sharing equipment performance data with maintenance systems.
Secure-by-design
Ensuring the security of automation systems and the data that they contain has become an essential capability in the response to rapidly changing risks. There has been a wide range of responses from end users, regulators, governments, and technology suppliers, including the use of effective countermeasures, and the ability to better identify, 
analyze and respond to threats and vulnerabilities. While these responses are laudable and required, they are not sufficient. Virtually all experts in this area agree that long-term success in this area requires that the inherent security of industrial automation systems and associated technology be improved “out of the box.” The full impact of such improvements will appear gradually, because of the long lifetime of installed systems.
Technology and system suppliers understand this, and have responded by making improvements to the security of existing product lines and implementing secure development methods to improve future products. Where necessary, they have developed, adopted or recommended specific products that can serve as compensating countermeasures. They also use the experience and knowledge gained to contribute to industry standards that define the minimum expectations for anyone providing components and systems in this area.
Standards Help
Formal standards, such as those defined and sanctioned by international standards bodies such as ISA, IEC, and IEEE, address most if not all essential capabilities. Specific examples include the ISA and IEC 62443 standards (Secure by 
Design), ISA84, IEC 61511 and ISA88 (Availability and Resilience), and ISA95 or IEC 62264 (Interoperability). Most, if not all, are reviewed regularly and updated as required to reflect changes to accepted practices.
Product and system suppliers have long used relevant standards as a reference when providing what have become basic or essential capabilities. These, in turn, provide more choice for the end user. While end users may not see these as differentiating features during the evaluation and selection process, the above standards can provide a basis for assessing compliance. Suppliers can and do use various certifications (e.g., safety, security) to establish the capabilities of their products.
Beyond the Essentials
Although most if not all major suppliers provide the above capabilities, many other features and functions are also required in automation systems. While suppliers may collect much of this information using a combination of market research and discussions with their customers, standards can also be a useful resource. To the extent that specific standards may look forward in an attempt to define developing and evolving needs, suppliers can use them to identify and assess limitations of their products and services.
In some cases, standards can help users and suppliers alike understand developing - and potentially disruptive - trends in areas such as the Industrial Internet of Things (IIoT), cloud computing, and Big Data. In combination, the effect may be even more dramatic.
Assessing technology trends and developments involves answering several fundamental questions, such as:
- Is the availability of new and improved technology sufficient to affect real change?
- Is it possible for the practice of automation to “absorb” or incorporate new technology as rapidly as it emerges?
- Are potential business drivers for improved automation well defined and generally accepted?
- Do end users truly believe that improved automation capabilities can deliver real business value?
With respect to technology-related drivers (questions 1 and 2), it is challenging to shift from relatively slow, incremental 
improvements to more fundamental changes in functionality and the underlying technology. End users can play a major role in driving these changes. However, the desire for these technical improvements still must be balanced with the inherent ability to absorb these changes.
While some end users have gone to great length to define their business drivers for improvements in automation, more dialog is needed to ensure that these drivers are widely supported within the community. Available venues for achieving this consensus include standards committees and user groups. However, all require that more end users make their needs known in several specific areas.
Operation and Support
Many of the challenges end users face in applying automation solutions arise during the operational phase of the lifecycle. They must reduce the cost and effort related to configuration changes and routine maintenance. It must also be easier to expand and extend existing systems, without disrupting normal operation.
Interoperability
Standards such as ISA95 (IEC 62264) promote a level of interoperability that is beyond what is possible with many 
current products and systems. Interoperability between products and systems from a single supplier is fairly common, but end users typically must deal with a variety of systems from multiple suppliers.
Needs and imperatives in this area are some of the drivers behind the formation of the Open Process Automation Forum, which describes itself as being “… focused on developing a standards-based, open, secure, interoperable process control architecture.” If successful, it is reasonable to assume that this initiative will reduce migration- and interoperability-related challenges to a significant degree. (ARC clients have access to multiple reports on this important initiative, which we support.)
Security
Even if new systems are designed and delivered with security features “built in,” they must still evolve and support new features in response to evolving and changing risks. This includes the ability to integrate or coexist with new countermeasures as they are identified and confirmed as suitable for the industrial environment.
Process Improvement
As with technology, processes must constantly change and improve to meet evolving needs and expectations.
For example, security related standards and practices such as 62443-2-1 (management systems), 62443-2-3 (patch management) and 62443-4-1 (product development) address processes, rather than technical capabilities. To varying degrees, they are aspirational, describing a higher level of performance than current norms. Suppliers and other stakeholders can use these standards to define specific plans to improve their performance in these areas. They then must measure and report of these improvements to their customers and stakeholders.
Using Standards
Suppliers, system integrators, end users and service and support providers all have a role to play in making the most effective use of standards. Industry associations and standards development organizations (SDOs) provide an effective venue for this type of collaboration.
Those involved in selecting, applying, and managing automation solutions often hear about developments related to a variety of standards. For suppliers, it is very important to track and, if possible, participate in the development of 
standards, as this can provide valuable guidance for product development. End users can describe their limits and constraints in areas such as management of change and lifecycle management.
Consultants and other experts often advise end users to educate themselves about applicable standards, and – most importantly – reference them in requests for information or requests for proposals. The idea is that this will accelerate standards adoption by suppliers and ultimately, lead to increased interoperability and perhaps even lower costs.
Whether developed by a formal standards development organization (IEC, ISO, etc.), or by an industry consortium, the standards produced are almost certain to be of higher quality and have broader acceptance if they include input from a broad spectrum of stakeholder groups. Better and more robust solutions will ultimately benefit everyone.
What Is Holding Us Back?
If we accept that all stakeholders could benefit from the development and application of standards, we must also examine the barriers and constraints involved.
Standards Development Processes
Many of the criticisms voiced about standards are directed at the processes used for their development. There is a common view that standards take too long to create relative to the rapid pace of technology development. The processes and associated constraints are often arcane, putting off people who might otherwise participate. Standards intended for broad adoption require the consensus of a broad range of stakeholders, which can easily take years. In some cases (e.g., IEC 62264, IEC 62443), the development has spanned more than a decade, involving multiple standards development organizations.
Interdependencies
Disciplines like automation include a wide range of processes and technologies. The result is a complex web of standards, with many interdependencies and other relationships. For example, functional standards such as ISA84 (safety) and ISA88 (batch) are related to process- and technology-related standards such as those required for security.
Evolving Technology
Technology and functionality develop and evolve much more quickly than the associated standards and practices. This is not surprising, since by definition, standards are included to capture accepted practices after they have been proven in use.
As capabilities improve, the expectations of stakeholders also increase. New technology brings new capabilities, which in turn lead to new and novel applications based on business needs.
Competitive Concerns
Many of the potential contributors to standards are constrained to some degree by a variety of competitive concerns. New and novel technology or methods often provide a competitive advantage, and may be protected by copyright, patent, or trade secret. The level of disclosure required by standardization can be a major barrier to contribution and involvement by suppliers and, to a lesser degree, by end users.
Service providers and consultants are often reluctant to share their practices and methods, since they may see these as the “secret sauce” (competitive differentiator) at the base of their business model. In some areas (e.g., security), addressing particular problems with standards could erode the revenue stream from addressing these problems on a case by case basis.
Multiple Stakeholders
Creating effective and lasting standards requires contribution from a broad range of stakeholders ranging from product and service suppliers to integrators, end users, and even regulators. With so many perspectives represented, it is often very difficult to develop a common vision of the end result. For example, regulators may be focused on compliance, while technical experts may take a longer or broader view.
Conclusion
In the face of all of this complexity and the associated constraints, standards are still a very valuable source of information for those developing and applying automation technology.
Suppliers rely on standards to identify basic accepted practice and minimum accepted requirements. This in turn allows them to focus on identifying features and technology that build on the standards, thus increasing the appeal of their offerings for end users. They may also contribute to standards development to help advance a particular technology or approach.
For all of this to work, standards must reflect the needs and views of a broad range of communities, including suppliers, integrators, and end users. End users in particular can benefit from understanding how standards influence (and are influenced by) product and service suppliers.
Recommendations for End Users
Based on ARC research and analysis, we recommend the following actions for end users:
- Assess standards awareness & involvement – When discussing the application and value of standards with prospective business partners, do not simply accept at face value statements such as: “We are committed to standards.” Pose specific questions to determine the level of familiarity with common standards.
- Ask about development processes – When considering potential suppliers or specific solutions, take the time to ask the supplier about the processes that they use to develop their products. For example, do they follow secure design practices as defined by standards such as the 62443 series? Do they have a clear preference for standard communications protocols to promote interoperability?
- Check for certification – In some cases it is possible to use compliance certification as a “shorthand” means to assess compliance with specific standards. Take the time to determine whether certifications are available for the standards of interest, and ask if they are held by prospective suppliers and partners.
- Be specific with procurement criteria – During the procurement process it is essential to be very clear about the specific selection criteria that will be used. Where appropriate, these criteria can and should include compliance to specific standards.
- Contribute to standards activities – If the appropriate skills and resources are available, organizations could benefit from becoming directly involved in standards development. Participation in a committee provides an opportunity to get an advanced view of and even help influence the direction being taken. This information can then be used to implement new processes and technology long before the standards are generally available.
If you would like to buy this report or obtain information about how to become a client, please Contact Us
Keywords: Automation Systems, Essential Capabilities, Requirements, Standards, ARC Advisory Group.