The familiar four-layer Purdue Enterprise Reference Architecture (PERA) was developed almost 30 years ago, and was formalized as an international standard by the ISA-95 committee in 2000. At present, the standard is jointly published as a second edition, IEC 62264-1:2013, with almost a decade since its last update.
The IEC 62264-1, “Enterprise-control system integration - Part 1: Models and terminology,” standard describes a functional model of the manufacturing operations management domain (Level 3) and its activities, and the interface content and associated transactions in Level 3 and between Level 3 and Level 4.
The purpose of IEC 62264-1 is to support integration between manufacturing operations, control domain (Levels 3, 2, 1) and the enterprise domain (Level 4) by increasing the uniformity and consistency of interface terminology to reduce the risk, cost and errors associated with implementing these interfaces. But what does this mean in the real world of my facility?
To put the layers in context, the PERA model is summarized below. The three layers in italics are commonly found in manufacturing literature and many technical publications, particularly those related to cybersecurity, but they aren't recognized as part of “official” PERA model's 0 through 4 layers:
- Level 5+: Cloud and related systems outside the enterprise domain.
- Level 5: Enterprise network/domain – business
- Level 4: Business planning and logistics – plant production scheduling, operational management, etc.
- Level 3.5: Demilitarized zone/process information network – often added when the model is used with cybersecurity.
- Level 3: Manufacturing operations and control – dispatching, production, production scheduling reliability, assurance and data historians.
- Level 2: Control systems – supervising, monitoring and controlling processes.
- Level 1: Field Devices for sensing and modifying the process.
- Level 0: Physical process.
Part of the reason for the misinterpretation of the PERA model could be that PERA is a functional model that's mistakenly interpreted as an architecture model because of how closely it aligns with how systems are implemented.
The challenge faced by practitioners is illustrated by ISA-112 SCADA's System Model Architecture diagram, which divides a supervisory control and data acquisition (SCADA) system into 11 hardware-oriented layers, then proceeds to align it with the PERA functional model.
Flows versus functions
This is one example of the strength of the PERA model as it reinforces the need to understand the function or what is being done at each layer of the enterprise. The model is, however, being challenged by new technologies including the cloud, Industrial IoT (IIoT) models and virtual sensors that reside outside Level 4 and may not even have a relationship with the organization and control levels. The resulting data may transit through with or without alteration, or bypass Layer 4 altogether before being used in a Level 2 function.
The IIoT introduces the challenge of how to represent an IIoT device existing anywhere as being a Level 1 field device, yet also at the same time being part of a Level 5+ computational (artificial intelligence) model output.
I understand there are several folks in the ISA Standards community who are discussing this challenge and developing some interesting concepts to reconcile the evolution of control system/business system information flows.
Fortunately, despite the orders of magnitude changes in computing capabilities, the evolution from proprietary to open control systems, and the increasing amount of data from anywhere at anytime, the PERA model continues to reflect the core functional concepts developed three decades ago.
