The following blog is adapted from the book Industrial Cybersecurity Case Studies and Best Practices, authored by Steve Mustard. More excerpts will be following in the coming weeks. See Excerpt #1 here. See Excerpt #3 here.

NEW: See Steve Mustard's October 2022 appearance on NasdaqTV here.

Why the Purdue Hierarchy is Still Relevant

The Purdue hierarchy, sometimes called the Purdue model, has been a mainstay of automation and control systems for 30 years, and is utilized in the ISA/IEC62443 series of standards when considering cybersecurity of these systems.

In recent years the applicability of the hierarchy has been called into question. In fact, the Purdue hierarchy remains as essential to automation and control systems design as the OSI seven-layer model is to network design.

Purdue Hierarchy

The Purdue hierarchy was developed by a team led by Theodore (“Ted”) Williams (formerly of Monsanto Chemical Co.) at Purdue University’s consortium for computer integrated manufacturing and published in 1992.[1] The Purdue reference model is part of a larger concept: the Purdue Enterprise Reference Architecture (PERA). This concept “provides a way to break down enterprises into understandable components, to allow staff at all levels to see the ‘20,000-ft view’ as well as to describe the details that they see around them every day.”[2] PERA expert and evangelist Gary Rathwell was a member of the original development team. He maintains that PERA was ahead of its time and never achieved the level of adoption that it deserved. Rathwell has successfully implemented many major automation projects by following the PERA methodology, but few outside his projects appreciate what can be achieved.

Most automation professionals know only of the Purdue hierarchy, either from the ISA-95 standard, incorporated into the IEC 62264 standard, Enterprise-Control System Integration,[3] or the ISA-99 standard, incorporated in ISA-62443-1-1, Security for Industrial Automation and Control Systems,[4] and even then, there is limited understanding of the principles behind it.

Figure 1 shows the original Purdue hierarchy, in this case for a continuous process such as petrochemicals. Another version (with different descriptions) covered a manufacturing complex. The ISA-62443-1-1 version of the Purdue hierarchy is shown in Figure 2.

Figure 1. The original Purdue Hierarchy[5]

Figure 2. Purdue Hierarchy as Defined in ISA-62443-1-1[6]

IIoT and the Purdue Reference Model

Some consider the Purdue hierarchy obsolete. Key drivers behind this opinion are the growing adoption of the IIoT and the move to locate central processing servers to the cloud.

Figure 3 shows an example of a cloud-oriented industrial architecture. This alternative to the Purdue hierarchy is intended to demonstrate why it is no longer applicable.

Figure 3. Example of a Cloud-oriented Industrial Architecture

This diagram, and the associated argument, demonstrate a common misunderstanding of the Purdue hierarchy.

The Purdue hierarchy is a logical, or functional, hierarchy rather than a physical one. In the PERA,[7] Williams identifies the key reasons behind a functional hierarchy:

• Levels reduce the size and complexity of the problem.
• Levels limit the scope of responsibility and authority.
• Levels differentiate between the length of the planning horizon and the required speed of response.
• Moving down the hierarchy, the planning horizon decreases while required speed of response increases.

The example in Figure 3 is a mixture of functional (e.g., machine operations) and physical (e.g., plant floor Ethernet switches) elements. This figure makes the implicit assumption that placing applications (e.g., inventory tracking) in the cloud affects the hierarchy. Again, this decision concerns the physical, not functional, elements and has no bearing on the hierarchy.

Planning Horizon and Speed of Response

Figure 4 shows the Purdue hierarchy from ISA-62443-1-1 overlaid with a simplified example, and associated time-bases for speed of response. This example considers condition-based monitoring, which requires data at a relatively low rate and assumes the condition does not change rapidly. The goal is to predict failures, rather than detect issues in near real time. Figure 4 shows that both solutions can achieve the condition-based monitoring application requirement. The diagram also highlights that the application of the Purdue hierarchy does not require that communications from sensor to condition-based monitoring go through all levels of the hierarchy. It is perfectly acceptable, from the Purdue hierarchy perspective, to communicate directly from level 0 to level 3. Securing this communication link will of course be a key activity in the control systems design. The ISA/IEC62443 concepts of zones and conduits will be used to guide this design.

Figure 4. Conventional and IIoT-based Approach to Condition-based Monitoring

Hierarchy and Resilient Design

IIoT “allows for a higher degree of automation by using cloud computing to refine and optimize the process controls.”[8] Figure 5 shows how this would be realized. The traditional, closed-loop control arrangement involves several steps. First, it compares a set point (desired value) to a measured value. Then it uses the difference (the actuating variable) to provide an input to a controller. The controller produces an output (the manipulated variable) that drives the plant toward minimizing the difference.

Figure 5. Control in the Purdue Hierarchy

In traditional implementations, the set point is set locally via the operator console or the supervisor control console. The advent of improved communications and devices allows a “higher degree of automation.” This enables some business logic to determine the optimal set points needed to achieve a particular objective. However, the use of IIoT cannot change where the closed-loop control is executed, at least not in a resilient solution. The Purdue levels help explain the order of priority for operation:

• Level 0 – The plant must be able to either operate safely without Level 1 or be shut down in the event of a loss of level 1 (local control).
• Level 1 and below – The plant must be able to operate without Level 2 (supervisory control).
• Level 2 and below – The plant must be able to operate without Level 3 (historian).
• Level 3 and below – The plant must be able to operate without Level 4 (business logic).

Misunderstandings about the Purdue hierarchy have enabled the creation of architectures that are not resilient against common failure modes. These modes include loss of wide area network connectivity and failure of supervisory console.

Consider a typical control system environment. It includes a plant control/monitoring function communicating directly with a SCADA function for operator display. This setup also enables onward communication to a historian function for use in reporting within the business. There is a requirement is to log some data for regulatory purposes.

A failure to log the required data may result in regulatory action, including fines. Consider the following failure scenarios:

• Loss of communications between the site and SCADA data acquisition (Level 1 to 2)
• Failure of the SCADA data acquisition (Level 2)
• Loss of communications between SCADA data acquisition and the SCADA historian (Level 2 to 3)
• Failure of the SCADA historian (Level 3)

Using the Purdue hierarchy allows designers to properly consider the design to accommodate these failure modes. For instance, ensuring there is a Level 1 function to log the required data that can operate without Level 2 or above (e.g., the SCADA system, or the communications network to the SCADA system). This would ensure that data is captured and can be recovered later when Levels 2 and above are restored.

Summary

The Purdue hierarchy has been a mainstay of automation and control systems for 30 years and today it remains as essential to automation and control systems design as the OSI seven-layer model is to network design.

The Purdue hierarchy represents a logical or functional view of an automation environment rather than a physical one. Designers should use the Purdue hierarchy to guide them in the implementation of user requirements to ensure that resilient and secure solutions are created.

[1] Theodore J. Williams, The Purdue Enterprise Reference Architecture: A Technical Guide for CIM Planning and Implementation (Research Triangle Park, NC: Instrument Society of America, 1992).

[2] PERA Enterprise Integration (website), Gary Rathwell, accessed June 21, 2021, http://www.pera.net/.

[3] IEC 62264-1:2013, Enterprise-Control System Integration (Geneva 20 – Switzerland: IEC [International Electrotechnical Commission]).

[4] ISA-62443-1-1-2007, Security for Industrial Automation and Control Systems – Part 1-1: Terminology, Concepts, and Models (Research Triangle Park, NC: ISA [International Society of Automation]).

[5] Williams, The Purdue Enterprise Reference Architecture, 146.

[6] ISA-62443-1-1-2007, Security for Industrial Automation and Control Systems, 60.

[7] Williams, The Purdue Enterprise Reference Architecture, 144.

[8] “Industry 4.0,” University of West Florida (website), accessed June 21, 2021, https://uwf.edu/centers/haas-center/industrial-innovation/industry-40/.