Data flow is no longer hierarchical
Can industrial edge computing fit into the Purdue model?
Since its introduction in 1992, the Purdue model has remained virtually unchanged. Considering the blazing speed of technological change characteristic of today’s modern business landscape, is it time to re-evaluate the model’s relevancy, especially given the advent of the Industrial Internet of Things (IIoT)?
When the Purdue Model for Control Hierarchy was published by Theodore J. Williams and the Industry-Purdue University Consortium for Computer Integrated Manufacturing, it quickly became the de-facto standard for how manufacturing teams thought about, architected, and implemented industrial control systems. The Purdue model became the barometer of what good manufacturing looks like, the reference point for conversations about systems and data flows and the defining snapshot of where operational and plant floor applications sit relative to the rest of the business. In short, it defined the landscape.
With the advent of IIoT, the Purdue model may be starting to show its age. Today’s technology stack is vastly different than what it was back in the 1990s, and a host of new and exciting methods are being deployed to unlock business capabilities in ways that were previously impractical. Most notably, rapid acceleration of the number of disparate connected devices and mass democratization of computing power introduces new requirements not addressed within the linear hierarchy of the model in its current form. Let’s look at what this really means.
The Purdue model was created to ensure security. This is accomplished by taking a layered view of how machines and processes function and interact with each other, and how data is produced, transferred and consumed at the various levels.
What is the Purdue model?
As shown in Figure 1, the Purdue model is a guideline for industrial automation and control systems, including network and security requirements. It is the most widely used framework across industrial environments globally. Many industrial controls, data collection and SCADA systems are designed around the model, ensuring that new and existing architectures continue to adhere to it. The Purdue model also inspired ISA-95, an international standard from the International Society of Automation that defines interfaces between enterprise and control systems.
The model, in the shape of a pyramid formation represents how information flows from the shop floor upwards into high-level enterprise systems. The model separates enterprise and operational domains into different zones isolated with an industrialized Demilitarized Zone, or DMZ, in between. Built-in security prevents security breaches between Level 0 and Level 5.
The model keeps computing and networks deterministic, i.e., ensuring that networks on the shop floor remain dedicated to the control systems and do not become “flooded” with non-production related data that could result in network capacity issues that could stop the manufacturing process.
The model purports to regulate and protect required responsiveness for each layer through segmentation. Segmentation is the primary methodology to mitigate concerns over unwarranted or unwanted traffic from the IT world from disrupting fragile and untested legacy controls equipment.
The Purdue model also serves as a blueprint for IT systems to acquire shop floor data via the DMZ without compromising production or allowing capture of plant floor mechanical equipment for nefarious purposes. Cybersecurity concerns were also addressed by firewalls placed between industrial and enterprise zones, isolating data within the zones absent explicit data sharing rules.
Figure 2: The Purdue model with an industrial edge computing platform. Courtesy: Litmus
What are the limitations?
The Purdue model fit the world of 1992 nicely. Cloud computing was just a dream. The bulk of compute capability to run the facility and manufacturing processes was found on-premises. Data sharing between manufacturing facilities and central offices was limited to order placement and fulfillment.
These layers and zones contributed to a controlled flow of data, mostly originating from the bottom of the Purdue pyramid upwards or planning data pushed down into the model for consumption at lower levels.
The model dictated that data be organized to be hierarchical and purpose driven. Data required to run processes came into the system top down and was processed and consumed as needed at each level. Data generated from the shop floor was sent back up, sometimes being used at the Level 3 industrial security zone, but more often being passed up through the DMZ into the enterprise security zone where it was used for basic historical reporting purposes.
Today’s data flow is no longer hierarchical. Manufacturers added intelligence at the sensors (Level 1), controllers (Level 2), and “edge,” which can be anywhere along Level 1 to 3 based on where the edge device is placed. All of this to say that points of exposure are occurring much further down the pyramid than the Purdue model ever considered. Due to the expanded power of edge computing devices, large amounts of data can be collected at Level 1, processed and be sent directly to the cloud. There is no inherent need to funnel data up through different layers. Data can be derived from many sources and service many clients, opening up widening pathways for consumption. IIoT, in all its interconnected glory, has demanded that we change the paradigm from that of a pyramid to that of a pomegranate.
Critics say Industry 4.0 has made the Purdue model at best outdated and at worst obsolete. These outdated applications of the model are seen in use cases where sensor data is being collected at Level 0 and is required to be sent to the cloud to enable predictive maintenance capabilities. Sending Level 0 data to Level 5 directly violates the segmentation aspects of the Purdue model.
Stay or go?
Scrapping the Purdue model, however, doesn’t work either. The Purdue model still serves the segmentation requirements for both wireless and wired networks and protects the operational technology (OT) network from unwarranted traffic and exploits.
What is needed is a hybrid solution that integrates into the Purdue model to maintain segmentation for traditional instances of IT and OT data flow, but also provides the flexibility needed as Industrial IoT use cases become more prevalent.
This level of IIoT flexibility can be attained by adding an industrial edge computing platform software layer. With this layer, an Industrial IoT project can adhere to each level in the Purdue model. This platform layer can sit either at Level 2 or Level 3 and provide data collection capability from OT devices at Level 0, 1, 2 and 3, while also facilitating data collection from IT layers at Levels 4 and 5. The benefit is that the traditional hierarchies inherent in the Purdue model can be bypassed where needed (i.e. sensors sending data from Level 0 to Level 5) by piping the data through the platform to ensure control and security.
Consider Figure 2, which demonstrates how an industrial edge computing platform can be inserted into the Purdue model.
The industrial edge computing platform sits inside the Purdue model, facilitating communications between any level as required. It is the data quarterback. It is the orchestration platform that makes it easy for systems to communicate amongst themselves.
Around the outside of the diagram, the traditional and established data flows will continue to persist as per the Purdue model, maintaining adherence to proven guidance of the model.
The Purdue model has benefits still valuable in today’s manufacturing environment. Implementing an industrial edge computing platform into the model preserves the integrity of the system while allowing flexibility that drives the foundation of a flat data collection and analytic environment that accelerates continuous improvement.
Vatsal Shah leads the management and engineering team as co-founder and CEO of Litmus. Vatsal earned his master’s degree in global entrepreneurship from Em-Lyon (France), Zhejiang University (China) and Purdue University (USA) jointly and his bachelor’s degree in electronics engineering from Nirma University in India.
This article appears in the IIoT for Engineers supplement for Control Engineering and Plant Engineering.