The undiscovered country: the future of industrial automation — Part 2

The Industrial Internet of Things (IIoT) has significant architectural differences compared with the wider Internet of Things (IoT) concept. Additionally, the question of how the conventional Purdue model for automation systems, and today’s installed base, fits with new IIoT architectures needs to be examined.

As described in Part 1 of this article, one of the main differences between IoT and IIoT architectures concerns the nature of the edge computing environment. In the IIoT the edge computing environment provides the opportunity to address key requirements in the areas of performance and robustness needed in industrial process control. Another significant characteristic of the edge computing environment in the IIoT that sets it apart from the IoT is a high degree of heterogeneity in the devices used and the protocols with which they communicate.

The IIoT edge computing environment consists of a wide range of devices, including sensors, actuators, controllers and HMIs. These devices are located in close proximity to the production process and may communicate directly with cloud-based services or via an edge gateway that acts as a data concentrator or filter and protocol converter. Edge devices may act collectively in a federation of devices to provide an autonomous coordinated set of capabilities at the edge. For example, a federation of sensors, actuators, controllers and HMIs may provide real-time control and management for a process unit or area. Such a federation would utilise peer-to-peer communication among devices using a variety of protocols. While there is a trend toward open IP-based protocols in the IIoT, such as OPC UA, there will continue to be a role for existing protocols such as HART, Profibus, Modbus and so on, particularly for existing installed devices. Edge gateways are used to interface heterogeneous devices and protocols with cloud-based services.

IIoT vs DCS

Some of the key differences between an IIoT architecture and a conventional DCS architecture can be illustrated by comparing the architectures at their highest levels. The structure of a DCS and associated applications typically conform to the well understood Purdue Enterprise Reference Architecture developed in the 1990s. The Purdue model structures an industrial enterprise into a series of layers ranging from the physical process (Level 0), basic control (Level 1), area control (Level 2), site manufacturing operations and control (Level 3), and business planning and logistics (Level 4). Enterprise-wide business systems such as ERP systems are often considered as Level 5 of the Purdue model.

This abstract model typically has a corresponding realisation in the topology of the system in which boundaries between levels are often expressed as network boundaries across which security can be enforced.

Figure 1: Purdue Enterprise Reference Architecture model (left) and IoT Reference Model (right). For a larger image, click here.

Figure 1 illustrates the basic organisation of the Purdue model, including a Level 3.5 DMZ that helps segregate the system in terms of access control and cybersecurity. The IIoT architecture illustrated previously in Part 1 is, at the highest level, separated into two major subdivisions — the edge and the cloud. This structure can be further broken down into a seven-level model, also shown in Figure 1.

An initial reconciliation of the Purdue model with the IoT model considers the partitioning of the functionality represented by the four main layers in the Purdue model within the two main layers in the IoT model. Level 1 of the Purdue model, basic control, moves to the edge in the IoT model, while Level 4, business planning and logistics, moves to the cloud. There is also a strong argument for moving much of Level 2, area control, to the edge to keep it close to the process being controlled for performance, security and reliability reasons. The functionality represented by Level 3, site manufacturing operations, will get pulled up into the cloud and pushed down to the edge depending on the balance of key system quality attributes. History, advanced process control, S88 batch and alarm management are all examples of functions that can be deployed either in the cloud or on-premise in embedded devices, or both.

Figure 2: Approximate correspondence between levels in the Purdue model and the basic structure of the IoT. For a larger image, click here.

An approximate allocation of Purdue model levels to the basic IoT partitioning is illustrated in Figure 2. In general, moving functionality to either the cloud or the edge represents a trade-off among a number of system qualities. For example, moving functionality to the edge can improve performance and reliability at the expense of having to provision and manage functionality distributed across a large number of devices. On the other hand, moving functionality to the cloud makes it easier to install, scale up, upgrade and retire at the expense of the functionality being remote from the devices and controllers on which the functionality may depend.

In general, the move to an IIoT-based architecture will result in a system unconstrained by the hierarchical structure of a DCS.

IIoT benefits

The IIoT can deliver better support for key requirements in the areas of safety, security, reliability and efficiency.

Safety

The overriding concern in any industrial enterprise is safety. There are well-understood and well-developed sets of practices and standards concerning the basic safety of an industrial process. For example, the Safety Integrity Level model provides a quantitative measure of the risk reduction provided by safety instrumented systems that are responsible for the basic safety of a process and formalised in IEC 61511. There will continue to be a key role for safety instrumented systems in any IIoT-based automation system.

Security

A concern closely related to safety is that of security. Unless an automation system is secure from unauthorised access and activity, its safety cannot be guaranteed. Aside from preventing compromises to the safety of the plant, security also serves to protect the intellectual property inherent in an industrial process itself and the procedures for planning, scheduling, executing, maintaining and optimising production on the process. Increasing levels of computer-based automation have increased the risks associated with cybersecurity attacks and has led to the development of cybersecurity standards and practices such as ISA/EC-62443 (formerly ISA-99).

Many existing DCS components have no inherent security built in. For example, they may lack any explicit access control mechanism and may transmit data on the network in plain text, as well as other well-known vulnerabilities. The legacy components do not disappear in an IIoT-based system, but are confined to the edge computing environment to which access is strictly controlled.

IIoT helps address these issues by pushing automation system functionality either down into the hardened edge computing environment or up into the cloud. The cloud computing environment has rich access control and communications security mechanisms built in and the centralised nature of the infrastructure makes it much easier to maintain in order to address vulnerabilities that are discovered.

Reliability

Reliability refers to the ability of a system to remain operational over time. The probability that a highly reliable system will fail to perform its intended function is very small and is a key characteristic of industrial automation systems. An IIoT-based approach can contribute to the reliability of an industrial enterprise both in terms of the reliability of the automation system itself as well as the reliability of the production process more generally.

The reliability of the automation system can be enhanced by pushing functions both out to the edge and into the cloud. As with safety, pushing functions, especially control functions, out to the edge allows those functions to act more autonomously with fewer dependencies on other components, reducing the potential causes of failure. Moving functions into the cloud allows them to be more easily managed, maintained and upgraded, reducing the impact of these operations on the system.

Efficiency

With a production process that is running safely, securely and reliably, attention can turn to making production as efficient as possible in order to maximise the profitability of the enterprise. This amounts to optimising operations in a range of areas such as maximising throughput or yield, minimising energy and raw material usage, minimising engineering, maintenance and labour costs, and so on.

Optimisation is essentially a decision-making process directed toward achieving a specified goal subject to constraints that limit the actions that can be taken to achieve that goal. The decision-making process may occur second-to-second, as in the case of online optimisation of process control variables, or day-to-day, as in the case of production and maintenance planning.

The ability to collect more data from uncorrelated sources provides opportunities for applying data analytics, modelling and machine learning techniques to gain better insight into the current and future state of the enterprise. This information can then be delivered to those in decision-making roles in ways that allow the decision-makers to act on that information.

Analytics, modelling, simulation and machine learning techniques also provide additional opportunities for closing the loop and enacting decisions automatically. In these cases, the decision-making process can be pushed out to the edge environment to enhance the capabilities of the autonomous elements of the system. Moving model-based control into the real-time control platform means that on-premise elements of the system are able to continue to optimise the process rather than just regulate it without depending on non-local resources.

Standards

A significant difference between today’s DCS and an IIoT system has to do with heterogeneity; while a DCS tends to be a combination of a vendor’s proprietary technology, the IIoT must accommodate fine-grained use of technologies and functions from multiple vendors, and do so over a long-time horizon. To do this, new standards beyond those allowing for communications interoperability (HART, Foundation Fieldbus, Profibus, OPC, etc) will need to emerge to allow for functional alignment from multiple sources. OPC UA (OPC Unified Architecture) is one such standard. Although it won’t be the only standard employed in IIoT, it has the potential to be the lingua franca of interoperable and well-bred IIoT solutions.

Getting there from here

The IIoT represents a step change in the evolution of automation systems. The benefits that flow from new, highly scalable deployment patterns, smarter devices, more comprehensive data collection and analytics, and broader reach through mobile applications are large. However, achieving these benefits requires an orderly transition from the automation system of today to the automation system of the future. This transition will be a stepwise initiative that will need to consider the following key aspects:

• Preservation of core IP: Control strategies, supervisory applications and HMI graphics need to be preserved as the automation system evolves. Re-engineering these is expensive and adds little value. It is far better to preserve this investment either by providing ongoing support for these items in their current form or by providing high-fidelity translation to new forms.
• Preserving in-place equipment and solutions: In addition to the engineering content of an automation system, there is a lot of associated equipment. Ripping this equipment out and replacing it with new equipment is usually not feasible or cost-effective, so it is imperative that evolution to the IIoT accommodates existing equipment. A key strategy here is to provide support for existing communications protocols that allows existing equipment to be integrated into an IIoT architecture in a secure way.
• Maintaining SIL levels: Any move to new deployment patterns and new devices needs to maintain existing SIL levels. Of course, the same applies to maintaining the security of a system. In both cases, the evolution of the system should be seen as an opportunity to not only maintain levels of safety and security, but to enhance them beyond their current levels.
• On-process updates to control hardware and software solutions: A stepwise evolution to new forms of automation systems will occur over a period of time. As changes to a system are introduced, they need to be done in a way that does not interrupt or compromise plant production. The updating of hardware and software, as well as the introduction of new system components, needs to be done ‘on process’.
• Performance/capacity of existing systems and demand placed on them from cloud-based applications: The IIoT encourages the collection of more data from more sources, so the impact of this additional demand for data on the existing components of an automation system needs to be managed. There is little point in enabling new forms of application if the needs of those applications compromise the core mission of the automation system.

Conclusion

In many ways, the IIoT represents an ‘undiscovered country’ — full of promise, but waiting to be explored and mapped out. This article has attempted to map out this undiscovered country and provide pointers to how the promise of future automation systems will be realised. The resulting vision is a new form of automation system architecture that balances the computational and life cycle benefits of cloud computing with the requisite on-premise, appliance-hosted capabilities necessary to provide safe, secure and long-lasting automation for complex manufacturing systems and processes.

*Paul McLaughlin is Chief Engineer at Honeywell Process Solutions. He has worked in the automation industry for 35 years and been with Honeywell for the past 30. Paul is currently responsible for the development of the HPS Industrial Internet of Things strategy and has degrees in mathematics and computer science from the University of Delaware and the University of Pennsylvania.

^Rohan McAdam is Chief Architect for Honeywell Process Solutions. He has worked in the field of industrial process control since 1988. Prior to joining Honeywell in 1993, he worked in the alumina industry in Western Australia. He has a mathematics degree from Charles Sturt University, a master’s degree in cognitive science from the University of New South Wales and a PhD in computer science from Charles Sturt University.

Image credit: ©stock.adobe.com/kinwun