ISA-88 (S88) is a batch automation standard that defines how to structure control systems so that process sequencing is separated from equipment control logic. In a traditional PLC program, the sequence of steps and the equipment behavior are often hard-coded together, making product or process changes difficult and costly. ISA-88 solves this by implementing reusable equipment logic in the PLC and defining the order of operations, parameters, and variations through recipes. As a result, product changes usually require only recipe modifications, not PLC code changes, leading to greater flexibility, easier validation, and improved maintainability in batch and regulated industries. In this post, we will see the concept of ISA-88.
What is the ISA-88 standard?
ISA-88 (also called S88) is an international standard that defines how batch automation systems should be structured, especially in industries where the same equipment is used to manufacture different products. The core idea of ISA-88 is to separate “what the process does” from “how the equipment works.” In an ISA-88-based system, the PLC is responsible only for controlling equipment behavior, such as how a valve opens, how a motor starts, or how a temperature loop is regulated, while the sequence of actions required to make a specific product is defined outside the PLC in the form of recipes. This separation makes batch systems easier to modify, reuse, validate, and maintain over time.
In contrast, a normal or traditional PLC sequence logic usually combines everything into one program. The PLC logic itself decides the sequence of steps: open a valve, start a motor, heat to a setpoint, hold for a time, and then move to the next step. Product-specific decisions, timing, interlocks, and equipment control are often mixed together in step-based logic. While this approach works for simple or single-product machines, it becomes difficult to manage in multi-product or regulated environments because any process change requires PLC code modifications, re-testing, and re-validation.
ISA-88 changes this approach by introducing structured elements such as phases, operations, and procedures. The PLC implements reusable “phases” that define how a specific action is performed, for example, heating, mixing, or transferring. The recipe then instructs the system when to run each phase and with what parameters, such as temperature or duration. As a result, changing a product typically involves changing only the recipe, not the PLC logic. This leads to more flexible systems, reduced engineering effort, faster commissioning, and easier compliance with validation and regulatory requirements, which is why ISA-88 is widely adopted in pharmaceutical, food, and specialty chemical industries.
How is ISA-88 logic different from a normal PLC logic sequence?
Let us understand with an example. In a traditional PLC sequence, even though operators can change setpoints such as 80 °C to 70 °C from the HMI, the order of actions is still fixed in the PLC logic. The PLC program typically contains step-based or state-based code that explicitly defines what happens first, second, and third; for example, heat first, then mix. So while a parameter change like temperature can be handled through the HMI, a sequence change, such as moving heating after mixing, requires modifying the PLC step transitions, reordering logic, or adding conditional branches. That is why PLC code changes become necessary: the PLC itself owns the sequence and decides what action comes next.
In an ISA-88-based system, the situation is different. The PLC does not contain the sequence; it only contains phase logic that defines how heating or mixing is performed when commanded. The sequence, whether heating happens before or after mixing, is defined in the recipe, not in the PLC code. If heating is required after mixing, the recipe order is changed, while the PLC phase logic remains the same. A PLC code change is required only if the behavior of heating or mixing itself changes (for example, a new control strategy or new equipment), not when the order or parameters of execution change. This is the fundamental advantage of ISA-88: it turns sequencing into configurable data instead of hard-coded control logic.
Why is ISA-88 important?
ISA-88 is important because it directly addresses the practical problems engineers face in batch and multi-product plants, especially where changes, validation, and long-term maintenance are unavoidable. In many traditional PLC systems, product logic, sequencing, and equipment control are tightly coupled. As a result, even small process changes can require PLC code modifications, extensive testing, and revalidation, which increases risk, downtime, and engineering cost. ISA-88 reduces this problem by enforcing a clear separation between equipment behavior and process execution, allowing systems to evolve without repeatedly touching proven control logic.
Another major reason ISA-88 is important is reusability and scalability. Once equipment logic, such as valves, motors, heating loops, or mixing functions, is implemented as standardized modules or phases, the same logic can be reused across multiple products, units, or even plants. This dramatically reduces engineering effort for new products or plant expansions. For global companies, ISA-88 also provides a common structure and terminology, making it easier for different teams, integrators, and vendors to work on the same system with fewer misunderstandings.
ISA-88 is also critical from a validation and compliance perspective, particularly in regulated industries like pharmaceuticals, food, and specialty chemicals. Because recipes define product-specific behavior and PLC logic remains stable, changes can often be managed as recipe revisions rather than software changes. This simplifies change control, reduces revalidation scope, and improves audit readiness. Overall, ISA-88 is important not because it replaces PLC programming, but because it makes automation systems more flexible, maintainable, and suitable for long-term operation in complex industrial environments.
How are the responsibilities separated in ISA-88?
In ISA-88, separation of responsibilities means that each layer of the automation system has a clearly defined role, preventing overlap between process decisions and equipment control. The PLC is dedicated to controlling the physical equipment and ensuring safe, reliable operation. It contains the logic that defines how devices behave, such as how a pump starts and stops, how a valve responds to commands, how a heater regulates temperature, and how interlocks and alarms are handled. This logic is designed to be robust and long-term, and once validated, it is rarely changed.
Process logic, on the other hand, is handled outside the PLC in the form of recipes. Recipes describe the steps required to manufacture a product, including the sequence of actions and the parameters associated with each step. They do not redefine how equipment works; they simply instruct existing equipment functions when to run and with what values. This allows different products or batch variations to be executed using the same PLC code. By dividing responsibilities in this way, ISA-88 enables safer systems, easier changes, clearer ownership between teams, and simpler validation and troubleshooting.
This division of responsibilities reduces errors, improves maintainability, and simplifies validation. Equipment logic changes are rare and controlled, while recipe changes are more frequent but lower risk. In regulated industries, this separation is especially valuable because it limits the impact of changes and makes audits and troubleshooting much easier.
The core model of ISA-88
In ISA-88, the core models provide a standardized way to describe a batch system by separating it into equipment structure, process execution, and product definition, each with clearly defined levels. The physical model represents how the plant equipment is organized. It is hierarchical and starts with the Enterprise, which may contain multiple Sites. Each site is divided into Areas, and within an area, there may be one or more Process Cells, which represent independent batch-processing capabilities. A process cell contains one or more Units, such as reactors, mixers, or tanks, that perform major processing steps. Each unit is composed of Equipment Modules, which group related equipment functions like heating, agitation, or dosing. At the lowest level are Control Modules, which directly interface with field devices such as valves, motors, drives, and PID loops. This model guides how PLC programs, function blocks, and hardware are structured and reused.
The procedural model defines how manufacturing activities are carried out over time, independent of product details. At the highest level is the Procedure, which represents the complete manufacturing process for a product. This is broken down into Unit Procedures, each describing what happens in a specific unit. Unit procedures are further divided into Operations, which group related processing activities such as charging, reacting, or cleaning. The lowest level is the Phase, which represents a single, executable action such as starting a mixer, heating to a setpoint, or transferring material. Phases are typically implemented in the PLC as reusable logic blocks or state machines and are the direct interface between recipes and equipment control.
The recipe model defines what is being produced and how it should be executed, and it is divided into four types to support reuse and flexibility. The General Recipe describes the manufacturing process in a completely equipment-independent way, focusing only on process intent. The Site Recipe adapts this general recipe to a specific plant by incorporating site-level constraints and practices while still avoiding direct equipment references. The Master Recipe binds the process to actual equipment by mapping operations and phases to units defined in the physical model, along with default parameters and limits. Finally, the Control Recipe is a runtime instance of the master recipe that represents a specific batch, including batch IDs, operator inputs, timestamps, and actual values recorded during execution.
Together, these three core models and their defined levels ensure that equipment behavior, process execution, and product definition are clearly separated yet fully aligned. This structured approach is what enables ISA-88 systems to be modular, scalable, easier to validate, and suitable for complex batch manufacturing environments.
How does ISA-88 look in PLC Programming?
In PLC programming, ISA-88 does not appear as a special language or a fixed block of code; instead, it shows up as a structured way of organizing logic. The PLC program is divided into modular, reusable components that directly reflect the ISA-88 physical and procedural models. At the lowest level, control modules are implemented as function blocks or AOIs for basic devices such as valves, motors, drives, and PID controllers. These blocks handle all device-specific behavior, including start/stop commands, interlocks, alarms, and fault handling, and they remain independent of any product or batch sequence.
The above control modules are equipment modules, which combine multiple control modules to perform a meaningful equipment function, such as a heating system, agitation system, or transfer system. For example, a heating equipment module may coordinate a steam valve, temperature sensor, and PID loop. These equipment modules expose simple commands and status signals to the higher-level logic, making them easy to reuse across different units or projects.
The procedural model is implemented in the PLC primarily through phases, which are typically coded as state machines. Each phase has clearly defined states such as idle, starting, running, holding, completing, completed, aborting, and aborted. When a recipe or batch system requests a phase to start, the PLC transitions the phase through these states while executing the required equipment actions via equipment and control modules. Importantly, the phase does not decide what phase comes next; it only reports its status back to the batch system.
Sequencing and product-specific behavior are not hard-coded in the PLC. Instead, they are handled by the recipe execution layer in SCADA or a batch engine, which calls PLC phases in a defined order and passes parameters such as setpoints and times. From a PLC programmer’s perspective, this means the focus shifts from writing long step-based sequences to building robust, reusable phase logic and equipment modules that can support many different recipes without modification.
Commissioning and validation perspective of ISA-88
From a commissioning and validation perspective, ISA-88 brings significant advantages because it limits how often proven control logic needs to be modified. In an ISA-88–based system, the PLC code primarily contains equipment behavior and phase logic, which are thoroughly tested during Factory Acceptance Testing and then kept stable. Once this logic is validated, most future changes, such as product variations, parameter adjustments, or sequence modifications, are handled through recipes rather than PLC code. This greatly reduces the scope of re-testing and re-validation, which is especially critical in regulated industries.
During commissioning, ISA-88 also enables a structured and repeatable approach. Equipment modules and phases can be tested individually before full batch execution, making it easier to isolate issues and verify functionality. Because each phase has defined states and clear start and end conditions, engineers can systematically verify behavior under normal, hold, and abort conditions. From a validation standpoint, the clear separation between equipment logic and recipe data simplifies documentation, change control, and audit trails. Auditors can easily see that product-specific changes were made at the recipe level without impacting validated PLC code, reducing risk, downtime, and compliance effort.
When should you not use ISA-88?
ISA-88 is not always the right choice, and applying it blindly can add unnecessary complexity. It is generally not suitable for simple or fixed-purpose machines where the process sequence rarely changes, such as a small conveyor system, a basic pumping station, or a standalone skid performing a single, repetitive operation. In these cases, a traditional PLC sequence is often simpler, easier to understand, and faster to implement, while ISA-88 would introduce extra structure without delivering real benefits.
ISA-88 is also less effective for purely continuous processes where material flows continuously, and there is no clear batch start or end, such as large-scale oil refining or continuous power generation. These processes are better served by continuous control standards and architectures. Additionally, for small systems with limited product variation, the overhead of defining recipes, phases, and equipment hierarchies may outweigh the flexibility gained. In such scenarios, using selected ISA-88 concepts, like modular equipment logic, can still be helpful, but a full ISA-88 implementation would be unnecessary and inefficient.
