Limitations to the Purdue Model
The Purdue model has been the foundation in the OT world for many years, but it needs to adapt to the current reality of Cloud, IIoT and Data Highways.
In this previous post we introduced our favorite Purdue model. In summary, the model describes an architecture for OT by separating systems in 4 levels + the actual plant:
Level 0: Represents the physical process.
Level 1: Involves sensor/actuators for real-time manipulation.
Level 2: Encompasses control systems like DCS and SCADA.
Level 3: Covers manufacturing operations systems like MES and data historians.
Level 4: Involves business systems, primarily ERP.
Remaining relevant for more than 30 years is an achievement, but in order to still exist in 10-or-so years the model needs to adapt to the current reality of cloud and IIoT.
The internet, the cloud & SaaS : introducing level 5
In the 90’s all IT systems were part of the company’s network and the internet was just a science experiment. Nowadays your IT landscape is spread out across different systems accessible via the web hosted by one of several cloud providers.
Internet connectivity is becoming a must have in the OT world as well: being able to ask for remote support, downloading a software patch, sending data to an external party… All this means we need to make a small enhancement to the model: we will just slap on a new level and call it “Level 5” !
We keep the same logic as before when it comes to best practices between levels. So going from a public cloud service on L5 (like a SaaS solution) to a data historian on L3 requires at least a small visit to L4.
Private cloud
The cloud we all know is the public cloud, accessible by anyone on the internet.
Large companies however want the benefits of cloud solutions without having all their internal systems exposed to the public. Integrating cloud solutions (virtually) in your own network is known as Private Cloud.
It’s still somebody else’s server but set up in a way that it’s only accessible by you and fully integrated into your business network.
As such private clouds are considered L4 systems, which make them much easier to integrate into your OT data flows.
Industrial Internet of Things (IIoT)
IIoT poses an interesting problem: Most IIoT data is processed in the cloud, but the sensor is actually installed in your physical plant. So… should it be a Level 1 or Level 5 device?
Even if the sensor is bolted to a pipe and is sitting next to a normal sensor wired to your SCADA system, the data will still go to a Cloud system. That means that it will never be considered to be an L1 device, but be treated as any other cloud service (meaning L5 if the sensor is connected to a Public cloud or L4 if it is talking to your Private Cloud*).
So if the IIoT data needs to be integrated in your landscape (like your OT data lake or Data Historian)
Here is a typical data flow if you would like to integrate the IIoT data into your landscape (like into your OT Data Lake or Data Historian):
IIoT Sensor (L5) => Pushes data to a Public Cloud Platform (L5)
Enterprise Data Bus on L4 pulls the data from the L5 Cloud Platform
Enterprise Data Bus on L4 pushes it into your L4 or L3 Data Lake / Historian
(*) IIoT on L4? That’s certainly possible but that means you’ll need to ensure the IIoT sensor and all its components are part of L4, including connectivity. Something that brings even more complexity than it removes.
Data Highways
The best practices in security from the entire level concept are great. But the amount of data that needs to move between plant and cloud in real time is pushing this model to its limits. How can we still find a way to simplify this without sacrificing security? Enter data highways.
In the past a sensor would only send its value. Modern sensors have a lot of additional data: fault codes, calibration status, battery levels… So why not use it?
In the classic model all this data would need to be captured by the L2 system, be captured by the L3 level and find its way to the L4 or L5 system. Not only is that a lot of overhead, it’s also very expensive as you often pay per I/O point for most systems on each level.
Wouldn’t it be better to simply send the data to where it must go instead of adding more work and cost? This is called a data highway.
There are however some challenges associated with Data Highways:
Can this be made secure? Are we sure that the highway cannot be misused by hackers, circumventing security controls in L2? Do we now need to patch our sensors as well? Do we need something more than just firewalls (e.g. Data Diodes)?
Are the sensors smart enough? Can we actually learn something from their quality indicators or is it just a bunch of unusable data?
Will every vendor come up with their own standard? Do we need another standard to rule them all?
At this time data highways are mainly being talked about in groups like NAMUR (NAMUR Open Architecture - https://www.namur.net/en/work-areas-and-project-groups/wa-2-automation-systems-for-processes-and-plants/wg-28-automation-architectures.html ) and Open Process Automation™ Forum (https://www.opengroup.org/forum/open-process-automation-forum ). To be fair it’s still a topic that hasn't reached maturity in terms of solutions and use cases.
Our summary for Your next Powerpoint slide:
The Purdue model is a longstanding reference architecture in industrial control systems.
Level 0: Represents the physical process.
Level 1: Involves sensor/actuators for real-time manipulation.
Level 2: Encompasses control systems like DCS and SCADA.
Level 3: Covers manufacturing operations systems like MES and data historians.
Level 4: Involves business systems, primarily ERP.
Emerging technologies like Cloud and IIoT are prompting updates to the model.
Level 4 get’s extended to also include Private Cloud solutions.
Level 5 was introduced for Public Cloud / SaaS.
IIoT sensors are also placed in Level 5 (under the assumption that they connect over a public network to a Cloud platform).
Data highways are a concept to simplify the collection of data but it’s work in progress