What are PERA Architecture "Levels", and how many should there be ?
The number of Levels in an enterprise architecture is not determined by the PERA model, but rather by analysis of requirements of the Enterprise. Typically, this involves 5 to 7 Levels, but it may be more or less for a specific industrial facility.
The Enterprise Control and Information Architecture is first defined in a "logical Architecture" of Software Applications and associated data flows. This is accomplished during the Conceptual Engineering Phase (of a project), or the Master Planning Phase (of a program or new enterprise).
This Logical Architecture diagram indicates the boundary of "Plant Wide Systms" that determine interfaces between Plant and Corporate IT systems. This is the interface described in ISA 95 (for Process Industries) including the B2PML language.
It also indicates the interface between Process Operations, and Plant Manufacturing Management Systems. This Process Operations interface is where the "Plant Firewall" is usually located and it is the boundary where the CIA (Confidentiality, Integrity, Availability) priorities of IT systems change to the SAIC (Safety, Availability, Integrity, Confidenciality) priorities of Plant Automation and Control Systems (ACS). This is also where the IT "Zero Trust" cybersecurity environment changes to a "Managed Trust" ACS environment.
This diagram shows the Interfaces with Engineering, Laboratory and other Plant Systems.
Later, typically during the Preliminary Engineering Phase, a more detailed Physical Architecture Diagram is developed that defines both the "4R Criticality levels", and the separation by "Physical Units". These "units" may be process units (like Compression or Distillation units) or functional units like Quality Control laboratories or Engineering Offices.
The combination of Levels and Units provide "segregation" that can then be used to implement "defense in depth". This has been the practice in PERA for over 30 years, however, it is not the only way to segregate and protect different parts of the Enterprise. New radio-frequency technologies like 5G cellular networks and Low Earth Orbit satellite networks provide a "physically flat" architecture that has been used for "campus" or even "regional" networks. These have the advantage of quick deployment and ease of modification, however segregation is only possible through sofware configuration. This is, by its very nature, both complex to manage and vulnerable to both human errors and deliberate attacks.
Reliable and secure Plant control and inforamtion systems require a "Sitewide Network Architecture" (see "Process Industry Example in Figure 1). In the classical PERA architecture each process unit is separated into "levels", which are distinguished from each other by four principle criteria;
| Level 0 | Transmitters sense Temperature, Pressure, Flow, and other process parameters at the highest practical sample rates. |
| Level 1 | Twice per secon, process parameters are used by a Level 1 controller to adjust the position of a flow control valve. |
| Level 2 | "1 to 5 second" samples are displayed on an Plant Operator HMI (Human-Machine Interface). |
| Level 3 | "1 minute" averages of the flow rate are used by a plant area optimizer or an alarm/trip system. |
| Level 4 | "1 hour" integrals are used for process unit performance calculations. |
| Level 5 | "1 month" integrals are used for planning feedwater heater preventive maintenance inspections. |
By contrast however, applications at level 5, can safely be shut down for hours or even days, with relatively minor consequences. Indeed, this is fortunate, since the communications, programming changes, and many users of these computers may make them more vulnerable to failure.
A key consideration for plant control and computing devices and the networks which connect them, is the ease with which these devices can be repaired after a hardware failure. For example, many continuous processes cannot easily be shut down to repair control devices such as PLC's (Programmable Logic Controllers) or DCS's (Distributed Control Systems). These devices and the networks connecting them must be maintainable "hot", (e.g., changing boards with the power still applied), to avoid shutting down associated equipment. These requirements apply to control software as well as hardware. Reloading, reconfiguration, and software patching may be necessary with the systems "online".
In addition to quickly repairing hardware and software failures, we must consider whether plant systems can survive or quckly recover after a cyberxecurity attack. Programs in ROM (that cannot be changed), and backup copies of programs and operating data that may be quickly restored are similar to hardware or software repairs.
Together, the ability to recover from hardware and software failures, human operating errors and cyber-attacks are defined as "Resilience". Resilience is rated in terms of MTTR (Mean Time To Repair).
Design of data-flows between programs and data bases is evaluated, often in the form of "block data-flow diagrams". An example is shown in Figure 2.
Application programs must be positioned at the appropriate level in the information architecture to satisfy the Response, Resolution, Reliability, and Resilience requirements of the application.
The positioning of applications is very dependent upon the requirements of that particular plant and site. It is quite possible that a given application might exist at level 3 in one plant, and at level 4 or 5 in another. Also, most applications span several levels. Possible "multi-level" examples include quality management, production reporting, material tracking, and maintenance.
Clearly, several different applications operating at different levels may require access to the same piece of production information (eg. input flow rate). It is not practical to have each system independently request this piece of data from the level 1 device to which the sensor is connected.
In most cases, access of data is primarily from an application which is one level higher in the architecture. However, this is not always the case. For example, a level 5 engineering system may require one minute averages (Level 2) for the purpose of process unit studies. Similarly, Level 5 cost information may be provided to Level 2 or 3 optimization algorithms. None-the-less, inquiries spanning more than one level are the exception, and in general the network should be designed to optimize communications between adjacent Levels.
As data moves up through the architecture, it tends to become increasingly summarized. It also concentrates from many devices and data highways at the lowest levels, to a single production database at level 4. This Level 4 system also provides the "gateway" through which the "office systems" view the plant data, and through which plant systems view "office" information. Interestingly, as data moves up from Level 4, it tends to "fan out" again, into various commercial and technical systems. The Level 4 Database is therefore a "nexus" for all data moving from, or to, the operations level.
Once the data flow requirements are established, it is necessary to implement this within a physical communications network, connected to physical computers.
A principal difference in the appearance of the Sitewide Network and the Network Dataflows results from the ability of modern networks to allow any device on the highway to communicate directly with any other device. For example, it is possible for a Level 4 "Sitewide Database" to get data from a Level 3 Supervisory computer. However a Level 3 system may exchange data directly with another Level 3 supervisory system.
Communications in the network may range from 4-20 milliamp analog signals to high speed co-axial or optical highways. Each of these kinds of connections has a role, and indeed also has its own messages in terms of impact on the Response, Resolution, Reliability, and Resilience of that part of the network.
Discretionary programming makes possible integration of communications protocols from different vendor's proprietary networks. Typically, a single Level 3 Processor may integrate information from several lower level devices or networks.
These operating systems, such as Windows, Unix, and others, provide an environment which can support the full 7-Level OSI/ISO communications model.
Sitewide Networks may be implemented using:
For obvious commercial and technical reasons, control system vendors are very reluctant to allow users and other vendors to connect devices directly to their proprietary data highway(s).
For this and other reasons, A "PROPRIETARY" NETWORK SHOULD NEVER BE USED AS THE PLANT WIDE INDUSTRIAL NETWORK. This network forms the foundation for a Plant Wide System and must be "open" to allow connection of a wide range of systems from various vendors.
Also, since a proprietary network may not be based on agreed, published standards, it will almost certainly "evolve" over time. As a result, even if an owner standardizes on a single vendor, he may probably still encounter long-term compatibility problems in expanding his system.
Working with an industry-standard network also maximizes the likelihood of being able to purchase device interfaces for any "3rd Party" equipment which may be acquired in the future.
One exception may be "Broadband Trunks" where "logically" separate channels may share "physical" transport media. However, the Broadband network must then operate at the Response, Reliability and Resilience level of the most critical industrial application that it carries.
Similarly, an Industrial LAN cannot afford to be "clogged" by large volumes of data processing information, such as would routinely be transferred on the Office LAN. Otherwise, critical control or alarm data might arrive too late.
The Office LAN typically has much lower response, reliability, and resilience requirements than the Industrial LAN. Industrial networks are often specified in such a way that "worst case" transmission delays of much less than a second can be guaranteed, whereas office LANs may sacrifice guaranteed response time for more efficient use of the available communications bandwidth. In the Industrial Network, failure of a single program or hardware interface to the highway must never "bring down" the whole network. However, elaborate precautions such as redundant data highways, are rarely justified in the office environment.
In many cases, a secure "gateway" is necessary between the two networks. This "gateway function" may be performed by the same processor as used to implement the Level 4 Site-Wide production Database, or it may be a separate processor.
This gateway performs several functions.
Since the "environments" for operation of an Office Network and an Industrial Network are so fundamentally different, protection is required between the networks. Commercial and Technical programmers on the Office LAN should not have to worry about possible consequences of their programming activities on the Industrial Network, or worse still on plant equipment!
Some data transfer between these levels is, however, essential. If optimization of the plant is to be accomplished, some cost information must be available to plant level systems. Similarly, production throughputs, losses and quality data, must be made available to "front office" systems. what is needed then is a "filter" which will allow certain kinds of pre-specified access.
Furthermore, it may be necessary to implement a "release" mechanism which will assure that production data is validated by supervision personnel before it is released to management information systems, and that cost information is verified before it is released for use by optimization algorithms at levels 3 and 4.