Introduction: The Three Models

Procedure automation for continuous process operations is based upon three fundamental models that work together:

• Physical Model — reflects the actual configuration of physical assets (equipment you can physically touch)
• Procedure Specification Model — captures all operating procedures and their functional requirements
• Procedure Implementation Model — contains the actual code and logic running on the control system

When procedures are selected for automation, specifications get converted into the implementation model. Agile development is permitted — you can iterate between design and implementation phases.

Physical Model

The Physical Model implements the ISA-95 Role-Based Equipment Model for continuous process operations. It organizes equipment into a hierarchy from individual devices up through enterprise level:

Level	Description	Example
Device	Individual field devices (inputs/outputs to BPCS)	Temperature sensor, control valve
Equipment	Actual hardware components and process equipment	Pump assembly, heat exchanger
Unit	Collection of equipment performing a specific function	Distillation column, reactor
Area	Functional grouping of process units	Crude distillation unit, utilities
Site	A complete manufacturing facility	Refinery, chemical plant
Enterprise	Multiple sites under unified management	Company-wide operations

Procedure Specification Model

Maps the relationship between procedure specifications and the Physical Model hierarchy. Provides a structured framework mirroring the equipment levels: enterprise procedure specifications, unit procedure specifications, equipment procedure specifications, and control specifications at the device level.

Specification model development can be approached three ways:

• Top-down: Starting with high-level operations and decomposing into smaller steps
• Bottom-up: Building from individual device operations upward
• Mixed: Combining both approaches as needed

Operating staff must be actively involved in creating or reviewing specifications — their hands-on experience provides insights that complement engineering documentation.

Procedure Implementation Model

The critical interface linking the Specification Model with the Physical Model. Translates abstract control requirements into implementable control actions that execute on real hardware. Corresponds to the Physical Model hierarchy with implementation modules at each level.

Module Type	Based On	Description
Enterprise implementation module	Enterprise specification	Highest-level coordination across sites
Unit implementation module	Unit specification	Coordinates equipment within a production unit
Equipment implementation module	Equipment specification	Controls specific physical equipment
Control implementation module	Control specification	Device-level control logic

Degrees of Automation

Procedure implementation does not require complete automation. Procedures can include:

• Fully automated — control system executes all steps without operator intervention
• Semi-automated — mix of automated steps and operator actions or confirmations
• Operator-assisted — automation provides guidance while operator executes steps

The operator remains integral — performing visual inspections, manual valve operations, or confirming process variables before proceeding to the next step.

Step and Transition Concepts

Steps represent discrete states or actions within a procedure. Transitions define the conditions that move the procedure from one step to another. Each step can include:

• Command actions — instructions to equipment (open valve, start pump)
• Perform actions — execution of control sequences
• Verify actions — confirmation that actions completed correctly
• Exception handling — response to abnormal conditions