What is ISA-88?
ISA-88, formally known as ANSI/ISA-88.01-1995 and also referenced as S88 or IEC 61512, is an international standard that defines models and terminology for batch control in manufacturing processes. The standard originated from the work of the International Society of Automation (ISA) SP88 committee in the early 1990s, driven by the need for a consistent set of concepts that could be applied across plants, vendors, and automation platforms. Rather than prescribing specific control algorithms or batch control software configurations, ISA-88 provides a structured framework for describing how batch processes work, how equipment is organized, and how recipes translate product requirements into executable procedures.
The standard was developed primarily for batch process industries such as pharmaceuticals, specialty chemicals, food and beverage, and biotechnology. However, the underlying concepts have proven useful in any manufacturing environment where finite quantities of material are produced through defined sequences of processing activities on shared or reusable equipment. ISA-88’s main contribution is the conceptual separation of recipe, equipment, and process, which provides a common language for control engineers, IT teams, operations personnel, and management. This separation allows organizations to describe what they make, where they make it, and how they make it as distinct but connected concerns.
Connect981 works with manufacturers that often rely on ISA-88 concepts to structure their batch documentation, traceability, and shopfloor workflows, even when control systems differ across sites or supplier facilities. The models and terminology defined by the standard offer a foundation for consistent communication regardless of the specific batch automation platforms in use.
Batch Manufacturing and Batch Control Context
Batch production involves creating finite quantities of material by subjecting inputs to an ordered sequence of operations over a defined period, typically using equipment that can be reconfigured or reused for different products. This stands in contrast to continuous processing, where material flows through a plant without discrete start and stop points, as in large petroleum refineries or paper mills. It also differs from one-off discrete manufacturing, such as custom fabrication of a unique part, where each item may follow a distinct path.
Many regulated and high-mix environments rely on batch logic. Pharmaceutical manufacturing, for example, produces defined lots of tablets or injectable solutions where every batch must meet strict quality specifications. Chemical processors run different formulations through shared reactors and separators. Food manufacturers produce finite runs of different product recipes on the same filling and packaging lines. In each case, batch operations coordinate what happens, when it happens, and on which equipment, covering activities such as charging materials, heating, holding, reacting, cooling, and discharging.
In life sciences and aerospace-related special processes, the batch concept extends to operations like composite curing, surface treatment baths, and heat treatment cycles. These batches must be tightly controlled and fully traceable to support regulatory compliance and product quality. ISA-88 provides a consistent way to model this complexity so that procedures, equipment capabilities, and recorded batch data remain aligned and auditable across different sites, systems, and even supplier networks.
Purpose and Scope of the ISA-88 Standard
The primary goal of ISA-88 is to define a common set of models and terminology for batch control that can be applied consistently across plants, control systems, and suppliers. Before the standard existed, batch automation was often implemented using custom, plant-specific software that made it difficult to transfer processes between sites, communicate requirements to automation vendors, or integrate systems from different manufacturers.
ISA-88 addresses these challenges by improving efficient communication between process engineering, automation, IT, and operations teams. The standard enables modular, reusable design of batch procedures, meaning that a well-defined phase or operation can be deployed across multiple products without being rewritten for each application. It also supports regulatory compliance by providing structured data structures for batch production records, making it easier to demonstrate traceability and process consistency during audits.
The ISA-88 standard is organized into multiple parts. Part 1 establishes the core models and terminology. Part 2 covers data structures and guidelines for languages used to represent batch logic. Part 3 extends the recipe framework to general and site recipe models that support multi-site standardization. Part 4 defines a data model for batch production records, capturing materials, activities, and process conditions. Part 5 addresses modular concepts for automated control systems, applying ISA-88 principles to reusable automation components. These parts are discussed in more detail later in this article.
The boundaries of the standard’s scope are deliberate. ISA-88 focuses on batch control models and data structures, not on mechanical design, detailed safety interlock systems, or business planning logic. It is also technology-agnostic: the concepts apply whether batch control is implemented on PLCs, DCS platforms, SCADA systems, MES layers, or custom batch engines. Higher-level coordination may use modern platforms like Connect981 or legacy tools, and the ISA-88 framework remains applicable in either case.
Core ISA-88 Models and Terminology
ISA-88 defines a set of abstract models that describe batch processes from multiple perspectives. These include the process model, the physical model, and the procedural control model, along with standardized terminology such as process cell, unit, phase, and recipe. Each model provides a different view of the same manufacturing reality. The process model focuses on the scientific and chemical requirements of what must happen to the material. The physical model describes the equipment hierarchy that exists in the plant. The procedural control model captures how operations are executed over time, connecting process requirements to physical resources.
These models give multidisciplinary teams a shared framework for discussing batch operations without getting lost in vendor-specific control code or hardware details. The following subsections introduce each model and its key components.
ISA-88 Process Model
The process model describes the manufacturing process in terms of what needs to happen to the material, independent of specific physical equipment. It uses a hierarchy of process, process stages, process operations, and process actions. At the top level, a process represents the complete set of steps required to transform raw materials into a final product. For example, in pharmaceutical manufacturing, this might encompass everything from raw active ingredients and excipients through to compressed tablets ready for packaging.
Process stages break the overall process into major segments that are meaningful to process engineers and quality teams. These might include stages such as solution preparation, reaction, purification, and finishing. Each stage represents a significant portion of the overall transformation without yet specifying which tanks, reactors, or dryers will be used.
Process operations and process actions allow further refinement. Operations capture logical steps within a stage, while actions represent elementary tasks such as charging solvent, heating to a setpoint, agitating, or holding for a defined reaction time. Throughout this hierarchy, the process model remains equipment-agnostic. This allows organizations to define a common process description that can later be mapped onto different physical installations, whether at a headquarters plant, a contract manufacturer, or a supplier facility. In aerospace-related special processes, the process model might capture stages like surface preparation, coating application, cure, and post-cure inspection, without assigning specific ovens or spray booths.
ISA-88 Physical Model
The physical model represents the real equipment hierarchy that exists in a manufacturing facility. ISA-88 defines levels including enterprise, site, area, process cell, unit, equipment module, and control module, though batch control typically focuses on the levels from process cell downward.
A process cell is a collection of control equipment arranged to produce one or more products. For example, a pharmaceutical process cell might include a set of reactors, filters, and dryers that can be combined in various configurations to run several different recipes. The process cell is the scope within which batch control coordinates activities.
Units are major pieces of physical equipment capable of carrying out unit procedures. A reactor vessel, blending tank, granulator, or autoclave would each be considered a unit. In the standard model, each unit operates on one batch at a time, making it a natural boundary for procedural execution and traceability.
Equipment modules represent functional groupings within or across units. A dosing skid, heating loop, or clean-in-place module would be examples. Control modules sit at the lowest level and include individual devices like valves, motors, sensors, and measurement instruments. These are the components that receive basic control commands and provide feedback to higher-level logic.
The physical model allows batch designers to reason about what each part of the plant can do, independent of any specific recipe. This makes it easier to reuse units or modules across many products and to understand capacity constraints when scheduling batch production. While ISA-88 was created for control systems, the same physical structure proves useful in higher-level digital tools for mapping work instructions, traceability, and maintenance records onto specific units and modules.
ISA-88 Procedural Control Model
The procedural control model describes how a batch is executed over time, using a hierarchy of procedure, unit procedure, operation, and phase. A procedure represents the complete set of steps needed to run a batch, mapped to a process cell. A unit procedure is a logical segment tied to a specific unit, such as a charging and reacting sequence that takes place entirely within a single reactor.
Operations divide unit procedures into smaller logical steps. Phases are the smallest procedural elements, directly interacting with equipment modules and control modules. A phase might represent actions such as starting an agitator, heating and holding at a setpoint, or transferring material to a buffer tank. Phases are where sequential control and regulatory control commands are typically applied to the physical equipment.
The procedural control model is where the separation between recipe logic and equipment capability becomes operational. The same unit might support phases used by multiple different recipes. A reactor that can heat, cool, agitate, and transfer can execute phases for dozens of products without requiring new control logic for each one.
ISA-88 also defines standard execution states and transitions for phases and units. These include quiescent states like idle and held, transient states representing transitions, and final states indicating completion. The standard provides guidelines for unit states without prescribing PLC programming patterns or specific vendor implementations. This allows multidisciplinary teams to discuss sequence behavior and exception handling using common terminology.
Consider a simple unit procedure: charge materials, heat to reaction temperature, hold for reaction time, cool to discharge temperature, transfer to the next unit. This sequence illustrates how the procedural control model organizes activities without specifying the exact valve sequences or controller settings that would vary by installation.
Separation of Recipe, Equipment, and Process in ISA-88
One of ISA-88’s defining principles is the clear separation of three concerns: what must happen to the material (process), what physical resources exist (equipment), and how a specific product is made at a given site (recipe). This separation allows each concern to be managed, documented, and changed somewhat independently.
ISA-88 defines several recipe types that sit on top of the process and physical models. A general recipe describes a product at a high level, independent of any specific site. A site recipe adapts that general recipe to the capabilities and constraints of a particular manufacturing location. A master recipe adds equipment-specific details for a particular process cell or set of units. A control recipe is the actual executable instance created for a single batch, containing specific parameter values, material quantities, and equipment assignments.
The process model expresses product and chemistry requirements. The physical model describes available units and modules. Recipes bind these two worlds together for a specific product on specific equipment. Recipe management becomes a structured activity rather than ad-hoc customization of control code.
This separation creates practical benefits for organizations. Moving a recipe between sites with different equipment layouts becomes a matter of adapting the recipe at the appropriate level rather than rewriting control logic from scratch. Introducing new equipment modules does not require rethinking the entire product definition if the module can support the required phases. Change control and validation in regulated industries become more tractable when process intent, equipment capability, and recipe parameters are documented in aligned but distinct structures.
Consider scaling a biotech fermentation process from a pilot plant to commercial production. The process model describes the fermentation requirements: media preparation, inoculation, growth phase, harvest. The pilot plant has one set of units with specific volume and control capabilities. The commercial plant has larger fermenters with different instrumentation. By maintaining the separation, the organization can adapt recipes to the new physical model without changing the underlying process definition.
In aerospace and MRO operations, many special processes and repair routes follow similar patterns. Process requirements remain stable, specifying what must happen to achieve required material properties or surface conditions. Equipment assignments and control recipes may vary between in-house facilities, approved suppliers, or partner locations. The ISA-88 framework provides a conceptual structure for managing this variation while maintaining traceability and compliance.
What ISA-88 Standardizes (and What It Does Not)
ISA-88 standardizes how to describe batch processes, equipment, procedures, and data. It does not standardize how to program or configure specific batch control systems. This distinction is fundamental to understanding the standard’s role and limitations.
What ISA-88 Standardizes
What ISA-88 Does Not Standardize
Common terminology for batch control objects
Specific PLC, DCS, or MES configurations
Conceptual models (process, physical, procedural)
Control algorithms or tuning parameters
Types and structure of recipes
User interface layouts or alarm designs
High-level data structures and relationships
Enterprise planning logic (scheduling, capacity)
Concepts for batch production records
Vendor-specific file formats
Modular automation concepts
Manual processes implementation details
Functional model guidelines
Data acquisition system specifics
The standard provides guidelines rather than rigid specifications. It establishes that a control recipe should contain a header, formula, equipment requirements, and procedure, but it does not dictate the database schema or file format used to store that information. It defines what regulatory control and basic control mean in a batch context, but it does not provide guidelines on specific tuning approaches or controller selection.
This deliberate boundary allows ISA-88 to remain stable and vendor-neutral while giving suppliers and manufacturers freedom to innovate implementations. Organizations often map ISA-88 structures onto their own databases, MES systems, or digital operations platforms to maintain consistency from control logic through documentation and traceability without enforcing a single control technology. Connect981, for example, helps organizations structure shopfloor workflows and documentation in ways that align with ISA-88 concepts even when underlying batch control software varies across sites.
The standard is just a standard: a conceptual framework rather than a turnkey solution. Its value lies in widespread adoption of common terminology and models that enable smooth integration across disciplines, vendors, and organizational boundaries.
Relationship Between ISA-88 and ISA-95
ISA-95 is a companion standard focused on integrating enterprise systems and control systems. While ISA-88 addresses the structure of batch control at the equipment and process cell level, ISA-95 defines models for how information flows between higher-level business systems (ERP, planning, MES) and lower-level control environments.
In terms of the Purdue reference model, ISA-88 primarily addresses Levels 1 and 2, where batch operations and control logic reside, with some extension into Level 3 for batch supervision. ISA-95 covers Levels 3 and 4, defining production operations management, scheduling, performance analysis, and inventory management. Together, the standards provide guidelines for a cohesive architecture from enterprise planning through shopfloor execution.
ISA-88 objects such as units, control recipes, and batch production records can be mapped into ISA-95’s production order, production schedule, and production performance models. Joint guidance from ISA working groups, including discussions at the World Batch Forum and related industry events, has clarified how these mappings work in practice.
Consider a practical example: an ERP system creates a production order for a batch of specialty chemicals. This order, structured according to ISA-95 concepts, is translated into one or more control recipes and batch runs modeled according to ISA-88. As each batch executes, batch data is collected according to ISA-88’s production record concepts. Batch results then feed back as production responses and records into higher-level systems, completing the information loop.
Connect981 typically operates in the space between ERP/PLM and on-the-floor control, where ISA-95 production models and ISA-88 batch structures both matter. The platform helps organizations orchestrate work, share data with suppliers, and maintain audit-ready histories in ways that respect both standards’ concepts. Seamless integration between these levels is increasingly important as manufacturers pursue digital transformation and require better visibility across operations, quality, and supply chain functions.
Structure of the ISA-88 Standard Parts
ISA-88 is a multi-part standard developed over several decades, with parts published and maintained both by ISA and as IEC 61512 standards for international adoption. Understanding the structure helps organizations determine which parts are most relevant to their operations.
Part 1: Models and Terminology was published in the mid-1990s and remains the foundation of the standard. It defines the core process model, physical model, and procedural control model along with the vocabulary that has become widely adopted across batch industries. Any organization working with ISA 88 batch control should be familiar with Part 1 concepts.
Part 2: Data Structures and Guidelines for Languages extends Part 1 by describing data models for batch procedures and records. It provides guidance on how to represent batch logic and procedural elements in a structured way that supports implementation across different platforms. While more technical than Part 1, Part 2 is valuable for teams designing batch control software architectures or MES integrations.
Part 3: General and Site Recipe Models and Representation expands the recipe framework above the master and control recipe levels. It addresses how organizations can define recipes at corporate or general levels and then adapt them for specific sites, supporting multi-site standardization and technology transfer. This part is particularly relevant for large organizations with multiple manufacturing locations or extensive contract manufacturing networks.
Part 4: Batch Production Records defines a data model for capturing and storing batch histories, including activities, materials, and process conditions. This part directly supports regulatory compliance requirements in industries like pharmaceuticals, where complete batch records are mandatory for product release. The technical report guidance in Part 4 helps organizations design systems that capture the right information in auditable formats.
Part 5: Modular Concepts for Automated Control Systems applies ISA-88 concepts to modular, reusable automation components. This part extends the standard builds beyond traditional batch process industries to address modular equipment and plug-and-play automation scenarios that are increasingly common in flexible manufacturing.
The IEC 61512 series represents the international adoption of ISA-88, with only minor technical differences between the ISA and IEC versions. Global manufacturers often reference the IEC designation in their documentation, particularly when working with European suppliers or regulatory bodies.
Organizations rarely implement all of ISA-88 at once. Most selectively apply models and recipe concepts that align with their products, regulatory requirements, and legacy batch systems. The modular nature of the standard supports this approach, allowing organizations to adopt terminology and models progressively as their batch operations mature.
For organizations managing complex batch operations across aerospace, pharmaceutical, or chemical industries, understanding ISA-88 provides a common language that bridges engineering, operations, and compliance. Connect981 helps teams put these concepts into practice through digital work instructions, traceability, and workflow management that align with how batch operations are structured and documented. To explore how your batch documentation and shopfloor workflows can benefit from this structured approach, request a demo to see the platform in action.
Frequently asked questions
The primary purpose of ISA‑88 (S88) is to provide a consistent, modular model for batch control so that product recipes are clearly separated from equipment control and system implementation. It defines a common architecture, terminology, and set of models that different teams and vendors can use to design, integrate, and maintain batch processes in a predictable way.
What ISA‑88 is trying to achieve
At its core, ISA‑88 aims to:
In practice, this connects to data mapping and system interoperability when teams need to turn the answer into repeatable execution habits.
- Separate recipes from equipment: Make product and process logic (recipes, procedures) distinct from physical assets (units, modules, phases) so that changing a product does not always require changing control code.
- Standardize batch models and language: Provide a shared way to describe processes, equipment, and control activities so engineering, operations, quality, and vendors can communicate without ambiguity.
- Support modular, reusable design: Encourage unit, equipment module, and phase-based control that can be reused across products and sites, reducing custom code and integration complexity.
- Improve lifecycle manageability: Make it easier to maintain, validate, and evolve batch systems over long equipment lifecycles by reducing tight coupling between control logic and product definitions.
- Enable better traceability of execution: Provide a consistent structure for capturing which recipe, which equipment, and which actions were executed, in what order, to support investigations and regulatory expectations.
What this means in regulated, brownfield environments
In regulated and long‑lifecycle operations, ISA‑88 is primarily useful as a design and integration reference, not as a standalone solution. Its practical role is to:
- Guide how batch control is structured in DCS/PLC/SCADA and batch execution systems, so changes to recipes and equipment can be managed with clearer impact analysis and change control.
- Provide a backbone for integration to MES, historian, and QMS, because the standard models (procedures, unit procedures, operations, phases, units, equipment modules) give stable integration points.
- Support validation and traceability by making the relationship between recipes, equipment behavior, and execution data more explicit and easier to document and test.
Using ISA‑88 does not guarantee compliance, audit success, or validation outcomes. Benefits depend heavily on:
- How consistently the ISA‑88 models are applied across legacy and newer systems.
- The quality of integration between control systems, MES, historians, and quality systems.
- How recipe management, change control, and configuration management are implemented on top of the standard.
Limits and tradeoffs
- Not a replacement strategy: Adopting ISA‑88 does not require ripping out existing DCS/PLC or MES. In fact, full replacement to “go pure S88” is rarely practical in highly regulated plants because of validation burden, downtime risk, and integration debt.
- Interpretation varies by vendor: Different control and batch platforms implement ISA‑88 concepts differently. The standard reduces ambiguity, but it does not eliminate vendor‑specific behavior or configuration.
- Requires discipline to realize value: Without governance around naming, modular design, and recipe/equipment separation, plants can claim “S88‑compliance” yet still end up with tightly coupled, hard‑to‑maintain systems.
In practice, many organizations use ISA‑88 as a reference model to incrementally improve existing batch systems: cleaning up equipment models, standardizing phases, and restructuring recipes, rather than attempting a disruptive, full‑scale replacement.
S88 (ISA‑88) works as a standard way to model and execute batch processes so that processes, recipes, and equipment can be specified, automated, and changed in a controlled and reusable way. It provides a common language between operations, engineering, quality, and automation rather than a specific software product.
Core idea: separate product logic from equipment control
The most important way S88 works is by splitting the problem into layers:
In practice, this connects to data mapping and system interoperability when teams need to turn the answer into repeatable execution habits.
- Product & process intent: what needs to happen to make the batch (procedures, operations, phases, parameters, limits).
- Equipment & control: what units, valves, motors, and instruments exist and what they are capable of doing.
This separation lets you change equipment (for example, run the same recipe on another train) without rewriting the process logic from scratch, and it improves traceability of changes. In practice, this only works if the control system, MES/batch system, and procedures are implemented and maintained to follow the S88 models.
S88 equipment model: how the plant is structured
S88 defines a hierarchical way to describe equipment involved in batch processing:
- Enterprise / Site / Area: administrative and physical context (e.g., company, plant, production area). Often mapped to ERP/MES site and area definitions.
- Process Cell: a collection of units and supporting equipment that can make one or more types of product.
- Unit: a major processing element that performs process steps on material (e.g., reactor, blender, granulator).
- Equipment Module: groups of equipment inside a unit that can perform specific functions (e.g., dosing module, CIP module).
- Control Module: the lowest level, such as a valve, motor, or PID loop.
Automation and MES/batch systems use this structure to configure recipes, allocate equipment, and capture data in a consistent way. In brownfield environments, mapping existing mixed-vendor and legacy equipment into this model often exposes naming conflicts, inconsistencies, and missing metadata that need to be resolved.
S88 procedural model: how the batch recipe is structured
S88 also standardizes how the procedural steps of a batch are represented:
- Procedure: full sequence for a batch or product run.
- Unit Procedure: part of the procedure that runs on a specific unit (e.g., charge and react in Reactor 1).
- Operation: a logical step within a unit procedure (e.g., heat, agitate, hold).
- Phase: the smallest executable step, typically implemented in the control system (e.g., open valve, start agitator, ramp temperature).
In a compliant batch control system, operators start and monitor procedures and unit procedures, while the control system executes phases. This allows clear mapping between SOPs, recipes, and automation logic, which supports review, validation, impact assessment, and root cause analysis.
Recipe types and reuse
S88 defines several recipe categories that work together:
- General recipe: equipment-independent description of how to make a product type.
- Site recipe: adapts the general recipe to a specific site (constraints, materials, utilities).
- Master recipe: site- and equipment-specific definition used as the approved template for execution.
- Control recipe: instance created when a specific batch is scheduled and executed.
This structure supports change control and versioning. QA and engineering can approve a master recipe, while individual control recipes capture actual parameters, deviations, holds, and operator interventions. To realize this in a regulated environment, you need recipe lifecycle governance (draft, review, approval, release) integrated with QMS and document control, and validated tools for version management.
How S88 works in real systems
In practice, S88 works through:
- Model-driven configuration: batch engines (often part of DCS or MES) are configured using S88 equipment and procedural models rather than custom ad hoc code.
- Standard naming and structures: consistent naming for units, phases, and parameters simplifies alarm management, historian use, and data integration.
- Modular automation: phases and equipment modules are designed as reusable blocks that can be combined into different operations or recipes.
- Integration with higher-level systems: MES, ERP, LIMS, and QMS reference S88 entities (batches, units, recipes) for genealogy, electronic batch records, and quality review.
How cleanly this works depends heavily on existing automation architecture, vendor capabilities, historical design decisions, and how rigorously the standard is followed across projects and integrators.
Benefits, with constraints
When implemented with discipline, S88 can provide:
- Consistency across lines and plants: shared models and naming reduce custom one-off logic.
- Faster change with better impact assessment: changes can be localized to specific recipes, units, or phases and traced for validation and quality review.
- Clearer batch records: data can be organized by batch, unit, phase, and parameter, supporting investigations and audits.
- Reuse of engineering effort: proven modules and phases can be used across multiple products and product variants.
However, S88 is a conceptual standard, not a turnkey solution. Achieving these benefits depends on:
- The capabilities and configuration of your DCS/PLC/MES/batch software.
- Consistency across integrators and automation teams.
- Governed recipe and configuration management tied to change control.
- Alignment with validation strategy, including documented requirements, test plans, and traceability.
Brownfield and long-lifecycle realities
In regulated, long-lifecycle plants, S88 adoption is rarely a clean “greenfield” exercise. Typical realities include:
- Mixed control platforms across units and areas, with varying support for S88 constructs.
- Legacy hard-coded batch logic embedded in PLCs that is expensive and risky to refactor.
- Limited downtime windows, which often prevent big-bang migrations to a model-driven S88 batch engine.
- High validation and qualification burden, which makes wholesale replacement of batch logic difficult to justify.
Because of these constraints, full replacement of existing batch systems with a new “pure S88” stack is often not viable. Incremental approaches are more realistic, such as:
- Standardizing naming and hierarchies to align with S88 without rewriting all logic.
- Creating S88-style phases and equipment modules for new products or expansions, while leaving validated legacy logic in place.
- Using S88 models in MES and electronic batch records for data organization and traceability, even if lower-level control is only partly aligned.
Typical failure modes and tradeoffs
S88 can fail to deliver value if:
- It is treated as an IT or automation standard only, without involving operations, QA, and validation in the design.
- Recipes and equipment models are implemented inconsistently across lines or integrators.
- Version control and change management for recipes and phases are informal or fragmented across tools.
- There is an expectation that adopting S88 alone will guarantee compliance or audit outcomes. It does not.
The tradeoff is usually between:
- Stricter adherence to S88 (more design effort, more initial cost, cleaner models, easier long-term maintenance), and
- Local, tactical implementations (faster in the short term, but harder to maintain, extend, and validate consistently).
Most regulated plants land somewhere in the middle, applying S88 where it offers clear, justifiable benefit and incrementally refactoring legacy assets as they undergo major change or revalidation.
S88, formally known as ISA‑88 or IEC 61512, is an international standard for structuring and describing batch manufacturing systems and recipes. It provides a common reference model for how equipment, control logic, and procedures in batch processes are organized and related, so engineering, operations, and IT/OT systems can speak the same language.
What S88 actually defines
S88 does not prescribe how to run your plant or which technology to buy. It provides models and terminology that your systems and procedures can map to:
- Physical model: A hierarchy for how equipment is organized, typically:
- Enterprise > Site > Area
- Process cell
- Unit
- Equipment module
- Control module
This helps separate physical assets (reactors, mixers, valves, scales) into clearly defined levels for design and control.
- Procedural model: A hierarchy for how operations are structured, typically:
- Procedure
- Unit procedure
- Operation
- Phase
This allows human and automated steps to be consistently modeled, reviewed, and automated.
- Recipe model: Standard elements of a batch recipe, including:
- Header (identification, version, authorship)
- Formula (materials, quantities, process parameters)
- Equipment requirements
- Procedure (the process steps using the procedural model)
It distinguishes between general, site, master, and control recipes, which is important for traceability and change control.
- Separation of recipe from equipment: S88 explicitly separates “what to do” (recipe logic) from “what you do it on” (equipment model). This is a key concept for reuse, modularity, and validation.
Why S88 matters in regulated, mixed-system environments
In regulated batch industries, S88 is widely used as a reference for designing and integrating:
- Distributed control systems (DCS) and PLC/SCADA systems controlling units and phases
- Batch execution systems and MES that manage recipes and batch records
- Interfaces to ERP for materials management and order execution
Using S88 as a common model can help with:
- Traceability: Clear mapping between recipes, batch records, and the specific units/equipment modules used.
- Impact analysis and change control: When the model is explicit, you can see which procedures and units are affected by a change.
- Modularity and reuse: Standardized phases and operations can be reused across recipes and units, which simplifies validation and long-term maintenance.
- Integration: Vendors that interpret S88 similarly can integrate more predictably, although this is not guaranteed.
Limits and common misconceptions
Several points are important in practice:
- Not a compliance guarantee: Adopting S88 terminology or models does not by itself satisfy any regulatory requirements. Compliance still depends on your specific implementation, procedures, validation, and documentation.
- Variable vendor interpretation: Different DCS, batch engines, and MES vendors interpret and implement S88 differently. Two “S88-compliant” systems may still not interoperate without custom mapping and careful testing.
- Does not remove the need for validation: In GxP or aerospace-grade environments, every recipe, phase, and system integration still requires appropriate validation, regardless of whether it follows S88.
- Not a full architecture: S88 focuses on batch modeling, not full enterprise architecture, cybersecurity, or data governance. It usually coexists with other standards (for example S95/ISA‑95 for enterprise integration).
Coexistence with legacy and mixed-vendor systems
Most plants do not implement S88 from scratch. Instead, they need to align existing systems with S88 concepts:
- Legacy recipe logic in DCS/PLC: Older control strategies may not follow a clear unit/operation/phase structure. Aligning them with S88 often involves incremental refactoring rather than wholesale replacement, due to downtime and requalification impact.
- Migrating without full replacement: Replacing an entire batch control or MES stack to “go S88” is rarely practical in regulated, long-lifecycle plants. The qualification burden, integration risk, and production downtime often outweigh any benefit from a big-bang change.
- Incremental mapping: A realistic approach is to:
- Map existing equipment and procedures to the S88 physical and procedural models.
- Introduce S88 terminology into specifications, URS/FRS, and design documents.
- Apply S88 modeling to new units, recipes, or revamps, while leaving stable legacy areas largely untouched.
- Integration layers: MES or integration middleware often implements the S88 recipe hierarchy on top of non-uniform underlying control systems, which requires clear interface definitions and robust testing.
Key tradeoffs when applying S88
Adopting S88 more rigorously involves tradeoffs:
- Structure vs. flexibility: Strong S88 discipline improves consistency and traceability but can feel rigid to operations teams that are used to ad hoc recipe changes or unit substitutions.
- Short-term cost vs. long-term maintainability: Refactoring existing logic into S88-style units and phases adds engineering and validation effort in the near term but can reduce ambiguity and rework over the lifecycle of the asset.
- Standard purity vs. practical mapping: In brownfield plants, strict conformance to every detail of S88 is often less useful than a pragmatic mapping that captures the spirit of the standard while fitting existing equipment and recipes.
How S88 typically shows up in your documentation
If you are working in a plant that uses S88 concepts, you will usually see them referenced in:
- User requirement specifications (URS) and functional requirement specifications (FRS) for batch control and MES.
- Control narratives and functional design specifications describing units, equipment modules, and phases.
- Recipe specifications and master batch records, structured around procedures, unit procedures, operations, and phases.
- Change control and impact assessments, where S88 models help identify what is affected by a change.
In summary, S88 is a widely adopted framework for describing batch processes, equipment, and recipes in a consistent, modular way. It can significantly improve clarity and integration across control, MES, and ERP layers, but its effectiveness depends on how carefully it is interpreted, implemented, and maintained within your specific plant and regulatory context.
In ISA‑88 terminology, a procedure is the structured, ordered set of actions that defines how a batch is executed. It is part of the ISA‑88 batch control model, not a single document or a generic “standard operating procedure.”
Where “procedure” sits in the ISA‑88 model
ISA‑88 defines a hierarchy for batch control activities:
- Recipe > overall definition of how to make a product (ingredients, timing, equipment requirements, etc.).
- Procedure > top-level sequence of steps for executing that recipe.
- Unit procedure > subset of the procedure run on a specific unit (for example, Reactor 101 charge and react).
- Operation > logical step within a unit procedure (for example, heat to setpoint, agitate, hold).
- Phase > lowest-level actions implemented in the control system (for example, open valve, start agitator, ramp temperature).
In practice, the ISA‑88 procedure is the layer that organizes unit procedures, operations, and phases into a coherent batch sequence that automation and operators can execute and track.
What an ISA‑88 procedure actually does
An ISA‑88 procedure:
- Defines the execution order of unit procedures and operations for a batch.
- Captures branching and conditions (for example, if temperature not reached in X minutes, raise alarm and hold at step Y).
- Links recipe logic to equipment capabilities through the equipment model.
- Provides a structure for traceability so you can reconstruct what happened in a batch at the level of procedure, unit procedure, operation, and phase.
The procedure is typically implemented in a batch control system (DCS, PLC/SCADA with batch add‑ons, or a batch engine) and may be referenced by higher-level MES workflows. It is not by itself a regulatory filing, but it contributes to how your manufacturing process is executed, monitored, and recorded.
Common misconceptions and constraints
- Not the same as an SOP: An SOP may describe similar steps in narrative form, but the ISA‑88 procedure is a control model used by automation. In regulated plants you usually have to keep both aligned under change control.
- Not a compliance guarantee: Using ISA‑88 structure does not imply compliance. You still need validation, documented requirements, and controlled changes.
- Highly implementation‑dependent: How “procedure” is represented, edited, and executed depends on your batch engine, control platform, and how strictly your integrator followed ISA‑88.
How ISA‑88 procedures coexist with existing systems
In most brownfield plants, ISA‑88 concepts are layered onto legacy control and MES/ERP systems instead of replacing them:
- Control system level: The phases and operations are embedded in the DCS/PLC code, often with an ISA‑88-like structure but not always fully compliant.
- Batch engine: The procedure and unit procedures often live in a batch management module that orchestrates equipment phases and records batch events.
- MES/EBR/QMS: Higher-level electronic batch records and workflow systems reference the procedure steps, but also add checks, approvals, and documentation steps that are not directly part of ISA‑88.
Full replacement of legacy batch logic with a new ISA‑88 implementation can be risky in regulated, long‑lifecycle environments because it triggers significant re‑qualification, extensive downtime, and complex integration work. Many plants instead incrementally refactor existing recipes into ISA‑88 structures during control system upgrades or capacity expansions.
Implications for regulated and validated environments
When you use ISA‑88 procedures in regulated industries (for example, pharma, biotech, some specialty chemicals):
- Traceability: The procedure hierarchy helps you tie batch events, alarms, and setpoint changes to specific steps, which improves investigation and reporting.
- Change control: Any change to procedure logic (sequence, limits, branching) typically requires impact assessment, documented testing, and sometimes re‑validation.
- Recipe versions: Multiple versions of a procedure may coexist for different markets or process revisions. Managing which version was used for which batch is essential.
- Integration quality: The value of ISA‑88 structure is only realized if MES, historians, and reporting tools correctly capture the procedure hierarchy and identifiers.
In summary, the ISA‑88 procedure is the formalized, hierarchical description of how a batch is executed within the ISA‑88 framework, linking recipe logic to real equipment and providing structure for automation, traceability, and controlled change. Its effectiveness depends heavily on your specific control platform, integration approach, and validation practices.
An ISA‑88 standard course is a training program that teaches the ISA‑88 (S88) standard for batch control. ISA‑88 defines models, terminology, and design patterns for structuring batch processes, equipment, and recipes so they can be automated, maintained, and scaled more consistently across systems and sites.
What an ISA‑88 course typically covers
Most ISA‑88 courses focus on the conceptual parts of the standard, not on a specific vendor product. Common topics include:
- The ISA‑88 physical model (enterprise, site, area, process cell, unit, equipment module, control module).
- The procedural model (process, process stage, operation, phase).
- Recipe types (general, site, master, control recipes) and recipe structure.
- Separation of process logic from equipment control to enable reuse and flexibility.
- How S88 concepts map into common DCS, PLC, and batch/MES platforms.
- Basic implications for validation, change management, and documentation in regulated environments.
Advanced or applied courses may add:
- Case studies of retrofitting legacy batch systems to align better with S88.
- Design patterns for modular phases and equipment modules.
- Strategies for integrating S88 batch control with MES/ERP and electronic batch records.
- Impacts on test strategies, qualification, and long‑term maintainability.
What an ISA‑88 course does not guarantee
ISA‑88 training is useful, but it is not a guarantee of project success or compliance outcomes. In regulated, long‑lifecycle environments:
- Understanding ISA‑88 does not remove the need for full system validation and change control.
- A course does not certify a system, a person, or a vendor product as “ISA‑88 compliant.”
- Real results depend on how well the concepts are applied within your specific automation stack, MES/ERP integrations, and plant procedures.
- Legacy systems, historical design choices, and downtime constraints often limit how “purely” ISA‑88 can be implemented.
How ISA‑88 training fits into brownfield reality
In most established plants you cannot simply replace existing batch systems to get a textbook ISA‑88 design. Instead, ISA‑88 courses tend to be most valuable when used to:
- Give a shared vocabulary to engineering, operations, quality, and IT when discussing batch system changes.
- Inform incremental refactoring of recipes and equipment control, rather than full rip‑and‑replace projects.
- Clarify where to draw boundaries between process logic and equipment logic for better testability and traceability.
- Support more structured user requirements, functional specifications, and design reviews with vendors and integrators.
Full replacement of an existing batch/DCS platform solely to “be ISA‑88” is rarely justified in regulated environments because of qualification burden, downtime risk, integration complexity, and the long lifecycles of existing equipment. Training is more often used to steer the next round of upgrades and projects toward better alignment with the standard.
Choosing an ISA‑88 course
When evaluating ISA‑88 courses for regulated manufacturing:
- Check whether the course is vendor‑neutral or tied to a specific control system.
- Confirm that examples are relevant to batch or hybrid processes similar to your own (pharma, specialty chemicals, food & beverage, etc.).
- Ask how the course addresses validation, documentation, and change control impacts.
- Look for exercises on mapping ISA‑88 concepts into brownfield environments, not just greenfield designs.
In most organizations, ISA‑88 training is most effective when attended by a cross‑functional group (automation, process engineering, QA/validation, and IT/OT integration) so that design and lifecycle implications are understood consistently.
In pharma, a BMR is a Batch Manufacturing Record. It is the complete, controlled record that shows how a specific batch of product was actually manufactured, tested, and handled, compared to the approved process.
What a BMR includes
Depending on the product and site procedures, a BMR typically contains:
- Reference to the master manufacturing record / master batch record (MMR/MBR)
- Material details: lot numbers, quantities, expiry/retest dates, and status
- Executed process steps: equipment used, setpoints, actual values, and operators
- In-process controls and test results, including any deviations and investigations
- Environmental or line clearance checks, where applicable
- Labeling and packaging details and line reconciliation results
- Signatures / e-signatures and timestamps for all critical actions and reviews
- Final quality review and batch disposition (e.g., released, rejected, quarantined)
Why the BMR matters in regulated manufacturing
The BMR is a core GMP record because it:
- Provides documented evidence that the batch followed the approved and validated process
- Enables traceability of materials, equipment, personnel, and process parameters
- Supports investigations, complaints handling, and product quality reviews
- Is a primary focus area in regulatory inspections and customer audits
A complete, legible, and accurate BMR does not guarantee a positive audit outcome, but poor BMR practices almost always create findings or concerns.
Paper vs electronic BMRs in brownfield environments
In many pharma plants, BMRs exist as a mix of paper and electronic records:
- Paper BMRs are still common where older equipment, limited integration, or validation cost makes full electronic execution difficult. They are simple to deploy but prone to data entry errors, missing signatures, and legibility issues.
- Electronic BMRs (eBMR) are typically implemented via MES or eDHR/EBR systems. They can enforce sequence, checks, and calculations, but require validated integrations, robust change control, and careful management of hybrid workflows.
In brownfield environments with legacy MES/ERP/PLM/QMS stacks, full replacement of existing batch documentation processes is rare. Incremental approaches are more common, for example:
- Digitizing specific high-risk or high-volume steps while keeping the rest on paper
- Capturing critical data electronically at the equipment level and attaching printouts to a paper BMR
- Running hybrid BMRs where some sections are executed in MES and others via controlled paper forms, with clear linking and reconciliation rules
Attempts to fully replace legacy BMR processes and systems often stall due to validation burden, downtime risk for critical lines, integration complexity with older equipment, and the need to maintain historical traceability across long product lifecycles.
Key constraints and good practices
The exact structure and management of BMRs vary by site, but some common constraints and practices are:
- Change control: Any change to BMR format, content, or execution flow should go through formal change control with impact assessment and, where needed, re-validation.
- Document control: Only the current approved version of the batch record template (the master) should be used to generate BMRs. Obsolete versions must be clearly segregated.
- Traceability: BMRs must be linkable to equipment logs, calibration records, analytical results, deviations, CAPAs, and supply chain data. In fragmented system landscapes this often depends on robust identifiers and disciplined data entry.
- Data integrity: ALCOA+ principles apply. Corrections, overrides, and rework should be clearly documented and attributable.
- Retention: BMRs typically must be retained for many years; storing and retrieving both paper and electronic records reliably over long horizons is a nontrivial design and cost consideration.
Because of these factors, any change to how BMRs are created, captured, or stored should be planned with cross-functional input from manufacturing, quality, IT, and validation, with explicit acknowledgment of brownfield constraints and long equipment lifecycles.
ISA‑88, often referred to as S88.01, is an international standard for batch process control. It defines a set of models and terminology for how batch manufacturing systems are structured and how recipes and procedures are represented, especially in industries like pharmaceuticals, specialty chemicals, food, and biotech.
What S88.01 actually defines
The S88.01 part of the standard (the original core document) provides:
In practice, this connects to data mapping and system interoperability when teams need to turn the answer into repeatable execution habits.
- A physical model for batch plants, including levels such as enterprise, site, area, process cell, unit, equipment module, and control module.
- A procedural model for how batch processes are executed, including procedures, unit procedures, operations, and phases.
- Separation of recipes and equipment, so that process know‑how (recipes) is defined independently of specific hardware implementation where possible.
- Standardized terminology to describe batch control across engineering, operations, IT, and automation vendors.
The intent is to give a consistent conceptual framework so different teams and systems can design, implement, and discuss batch processes with less ambiguity.
What S88.01 does not guarantee
In regulated, mixed‑vendor environments it is important to understand what S88.01 does not provide by itself:
- It does not guarantee vendor interoperability. Two systems can claim to be “S88‑compliant” yet still require significant custom integration.
- It does not prescribe detailed control strategies, alarm handling, or safety instrumented functions.
- It does not ensure regulatory compliance, data integrity, or audit outcomes. Those depend on how you implement, validate, and operate the system.
- It does not replace the need for site‑specific procedures, recipe governance, or change control.
How S88.01 is used in practice
In most brownfield plants, S88.01 is used as a design and communication framework rather than a strict implementation checklist:
- Automation design: Structuring PLC/DCS logic and batch management systems into units, equipment modules, and phases that map to the S88 models.
- Batch management / MES integration: Aligning batch records, electronic batch logs, and recipe management in MES or batch servers with S88 concepts to improve traceability and clarity.
- Recipe standardization: Defining master recipes, site recipes, and control recipes in a way that separates product definition from specific equipment capabilities.
- Cross‑functional communication: Providing a shared vocabulary for process engineering, manufacturing, quality, and IT when discussing changes, deviations, and system upgrades.
How far a site can go with S88.01 depends heavily on existing automation, legacy batch systems, vendor toolsets, and the cost and risk of re‑architecting validated processes.
Implications for regulated and long‑lifecycle environments
For regulated industries, S88.01 can help structure:
- Recipe and equipment traceability: Clear mapping between product recipes, equipment capabilities, and batch records.
- Change control: A modular model that makes it easier to describe and assess the impact of changes at the unit, module, or phase level.
- Validation scope: More consistent definitions of what constitutes a recipe change vs. an equipment or control change.
However, fully re‑architecting a legacy plant to align with S88.01 often fails or stalls because of qualification burden, integration complexity with existing MES/ERP/QMS stacks, downtime constraints, and the need to revalidate critical equipment. Most sites adopt S88.01 incrementally during control system upgrades, new line introductions, or major recipe projects.
Key takeaway
S88.01 is a foundational batch control standard that provides models and language for structuring batch processes, equipment, and recipes. It is a design and communication tool, not a guarantee of interoperability or compliance. Real benefit comes from disciplined, validated implementation in the context of your existing automation, MES, and quality systems.
There is no single global standard that regulates all batch processes in the legal or compliance sense. Instead, there are widely adopted technical standards for how batch processes are modeled and controlled, plus separate regulatory frameworks that apply by industry and jurisdiction.
Core technical standard: ISA‑88 / IEC 61512
For most industrial batch processes, especially in pharmaceuticals, specialty chemicals, and food & beverage, the foundational technical standard is:
- ISA‑88 (S88), also published as IEC 61512: “Batch Control”
ISA‑88 defines:
- A standard batch control model and terminology (procedures, operations, phases)
- Separation of process design from equipment design
- Recipe types (general, site, master, control recipes)
- Equipment models (enterprise/site/area/unit, etc.)
ISA‑88 is not a regulatory statute or binding regulation. It is a consensus engineering standard. It helps align control systems, MES, and recipe structures, and it can make validation, change control, and integration more systematic. But by itself it does not guarantee compliance or a favorable audit outcome.
Related standards often used with batch processes
Depending on your environment, other standards commonly coexist with ISA‑88:
- ISA‑95: For modeling and integrating information flows between enterprise systems (ERP, PLM, QMS) and control/MES layers. Batch recipes and genealogy often sit at this interface.
- GAMP 5 (guidance, not a standard): For approaching computerized system validation in GxP environments, including batch control and MES.
- IEC 61508 / IEC 61511: For functional safety in process industries, sometimes relevant when batch steps involve safety instrumented functions.
None of these are regulations in themselves; they are frameworks that can support your compliance posture if implemented and validated appropriately.
Regulatory frameworks that apply to batch processes
What actually regulates your batch process is typically industry- and region-specific. Examples include:
- Pharmaceuticals / biopharma: FDA 21 CFR Parts 210/211 (drug GMP), 21 CFR Part 11 (electronic records and signatures), and EU/EMA GMP requirements. These govern how you manufacture, document, validate, and control batch production, not just which technical standard you use.
- Medical devices: FDA 21 CFR Part 820 and ISO 13485, which may apply when device manufacturing uses batch processes.
- Food & beverage: FDA/USDA rules in the US, EU food regulations, and HACCP-based requirements, which influence batch traceability, hygiene, and recall readiness.
- Chemicals and other process industries: Environmental, safety, and product stewardship regulations (for example, OSHA PSM in the US, REACH in the EU) that affect how batch operations are designed and documented.
In all of these, regulators do not usually mandate “you must use ISA‑88” but they expect clear procedures, traceability, validated control systems, and robust change control. An ISA‑88-aligned batch model often makes it easier to demonstrate these elements.
Brownfield and coexistence considerations
In real plants, batch processes usually sit within a brownfield stack: legacy DCS/PLC control, historical batch servers, and MES/ERP/QMS systems from multiple vendors. Introducing or tightening ISA‑88 alignment typically means:
- Mapping existing unit operations and equipment to the ISA‑88 models without disrupting validated recipes.
- Refactoring recipes and control logic incrementally to avoid large outages and revalidation scope.
- Coexisting with non‑ISA‑88 legacy units where full retrofit is not economically or operationally viable.
Attempting a full rip‑and‑replace of batch control, MES, or ERP purely “to comply with ISA‑88” is rarely justified in regulated, long‑lifecycle environments. The qualification burden, downtime risk, integration complexity, and impact on existing traceability and change histories often outweigh the benefits unless there is a broader modernization or capacity driver.
Key takeaway
ISA‑88 (IEC 61512) is the primary technical standard for structuring and controlling batch processes, but it does not itself regulate them. Your actual regulatory obligations come from industry‑specific GMP, safety, environmental, and quality regulations. An ISA‑88‑aligned architecture can support, but not guarantee, compliance, and must be implemented with careful validation, change control, and integration planning in existing plants.
ISA-88 (also referred to as S88) is an international standard for batch control developed by the International Society of Automation. When people say the “ISA-88 format,” they usually mean one of two things:
- The ISA-88 conceptual models for how batch processes, equipment, and recipes are structured.
- An ISA-88-inspired data structure used by a specific vendor (for example, how a batch server or MES stores recipes and procedures).
ISA-88 itself is not a single file format or data interchange standard like XML or JSON. It is primarily a set of models and terminology that define how to represent and break down batch manufacturing.
In practice, this connects to data mapping and system interoperability when teams need to turn the answer into repeatable execution habits.
What ISA-88 actually defines
ISA-88 provides a consistent way to model batch operations, covering:
- Physical model: Enterprise, site, area, process cell, unit, equipment module, control module.
- Procedural model: Procedures, unit procedures, operations, phases.
- Recipe models: General, site, master, and control recipes, with defined sections (header, equipment requirements, formula, procedure, etc.).
Vendors implement these concepts in their own databases, configuration tools, and sometimes proprietary or semi-standardized file structures. Those implementations are often described informally as being in “ISA-88 format,” but the exact schema is vendor-specific.
How “ISA-88 format” shows up in real systems
In brownfield environments, you are likely to see ISA-88 concepts used in several ways:
- Batch control systems / DCS: Recipe editors and batch engines that organize logic into procedures, unit procedures, operations, and phases mapped to units and equipment modules.
- MES or eBR systems: Data models that distinguish master recipes from control recipes and link them to equipment and material genealogy.
- Export/import structures: XML, JSON, or proprietary files that contain recipes, phase logic references, and equipment requirements in an ISA-88-like hierarchy.
The structure may follow ISA-88 closely, but the serialization format (file type, schema, APIs) is implementation-dependent. There is no universal, regulator-recognized “ISA-88 file format.”
Implications for regulated, long-lifecycle plants
For operations, engineering, and quality teams, the practical questions are less about a specific ISA-88 file format and more about how ISA-88 modeling affects:
- Traceability: Mapping batch records back to units, equipment modules, and phases in a consistent way.
- Change control: Managing revisions of master and control recipes, including procedures and formulas, under formal change management and validation.
- System coexistence: Keeping an ISA-88-based batch system aligned with legacy MES, ERP, and QMS structures that were not designed around S88.
- Validation burden: Any change to recipe models or control logic can trigger revalidation, especially in GMP or aerospace-grade contexts.
Attempting to replace all non-ISA-88 systems with a single “pure S88” platform is rarely practical in regulated environments. The qualification burden, downtime required for cutovers, and integration with legacy historians, MES, and ERP typically make big-bang replacement high risk. Incremental adoption of ISA-88 concepts around existing assets is more common.
Key tradeoffs when using ISA-88-based structures
When you standardize on ISA-88 models in a brownfield environment, expect tradeoffs:
- Pros:
- Clear, shared vocabulary for engineering, operations, and IT.
- More reusable and modular batch logic (phases, operations, unit procedures).
- Better alignment between equipment capabilities and recipe requirements.
- Cons / constraints:
- Legacy systems may not map cleanly to ISA-88 models, leading to compromise mappings.
- Integration and data exchange rely on vendor-specific schemas or custom interfaces.
- Retrofitting S88 structure onto older control code can be invasive and slow, especially under strict change control.
Practical guidance
If someone in your organization asks for data “in ISA-88 format,” clarify the intent:
- Do they need ISA-88-compliant recipe structures (e.g., procedure, operations, phases) from a batch system?
- Do they expect a specific vendor’s export format that follows ISA-88 concepts?
- Are they referring to modeling and naming conventions for equipment and recipes rather than a file format?
From there, you can determine what is feasible given your control systems, MES, and validation constraints, and whether you need a one-time migration, a connector, or just harmonized modeling across systems.
ISA-88, commonly called S88, is a standard for batch process control. In practice, it provides a consistent way to model batch operations, equipment, recipes, and procedural execution so that batch processes are easier to design, automate, maintain, and transfer across lines or sites.
At a high level, ISA-88 defines batch control through a few core ideas:
-
A physical model that describes the manufacturing assets involved in batch production, typically from enterprise and site down to area, process cell, unit, equipment module, and control module.
-
A procedural model that describes how a batch runs, usually as process, process stage, operation, and phase.
-
A recipe model that separates product-specific instructions from equipment-specific control logic.
-
States and modes that define how equipment and batch procedures behave during execution, hold, restart, stop, and exception conditions.
The most important practical point is that ISA-88 separates what needs to be made from how the equipment performs it. Product intent is captured in recipes, while reusable equipment capabilities are implemented in control strategies and modular automation. That separation is why S88 is often used to improve consistency, recipe portability, and lifecycle maintainability.
How ISA-88 defines batch process control
Under ISA-88, batch process control is not just a sequence of machine commands. It is a structured combination of:
-
Recipe management, including formulas, parameters, inputs, outputs, and required process steps
-
Equipment management, including which units and modules can perform which actions
-
Procedural execution, including ordered phases, branching, holds, and restarts where the process design allows them
-
Batch records and data capture, which are essential for traceability, review, and investigation in regulated operations
In that framework, a batch is executed by applying a recipe to suitable equipment using a defined procedural structure. For example, a recipe may specify material quantities, setpoints, timing, and process parameters, while the unit phases handle actions such as charge, mix, heat, hold, or transfer. The standard helps make those phases reusable across products where the equipment capability is genuinely common.
ISA-88 also distinguishes different recipe types, such as general, site, master, and control recipes. That matters because recipe detail and approval context often differ across development, site deployment, and runtime execution. In regulated environments, those distinctions can support traceability and controlled change, but only if the implementation is disciplined and integrated into the site’s validation and governance practices.
What ISA-88 does and does not do
ISA-88 does not mandate one vendor architecture, one control platform, or one software product. It is a model and terminology standard. A plant can align well with S88 using different combinations of DCS, PLC, SCADA, batch engines, MES, historian, and ERP systems.
It also does not guarantee interoperability, easier validation, or successful recipe transfer by itself. Those outcomes depend on how consistently the models are applied, how cleanly interfaces are designed, and how much variation exists in equipment, instrumentation, and site procedures.
Common failure modes include:
-
using S88 terms loosely without enforcing a real equipment and recipe model
-
embedding product-specific logic deep in PLC or DCS code, which defeats recipe portability
-
assuming two lines are interchangeable when instrumentation, sequencing, or material handling details differ
-
treating batch records as an afterthought instead of designing for review, exception handling, and genealogy from the start
How it fits in brownfield plants
In brownfield environments, ISA-88 is often most useful as a structuring approach rather than a full replacement program. Many plants already have a mix of legacy automation, vendor batch packages, MES workflows, ERP integrations, local historian setups, and manual or semi-digital records. In those conditions, trying to replace everything to become “fully S88 compliant” often fails for predictable reasons: qualification burden, validation cost, downtime risk, integration complexity, and the reality of long-lived production assets.
A more practical approach is usually incremental:
-
standardize recipe and equipment models for new products or new cells first
-
wrap legacy control with clearer procedural and data interfaces where replacement is not justified
-
align MES, historian, and batch record structures to the S88 model over time
-
apply change control carefully so recipe, automation, and record changes remain traceable
That coexistence model is slower, but it is often more realistic in regulated manufacturing where downtime windows are constrained and validation effort is material.
Why operations and quality teams care
When implemented well, ISA-88 can help organizations reduce ambiguity in batch execution, improve repeatability, and make recipe changes more controlled. It can also make cross-functional communication clearer between process engineering, automation, MES, quality, and IT.
But the tradeoff is governance overhead. Modular recipe design, reusable phases, exception handling, and record integration require sustained discipline. If master data is inconsistent, equipment capabilities are poorly defined, or recipe ownership is fragmented across departments, the standard will not fix those problems on its own.
So the short answer is: ISA-88 is the standard that defines a structured model for batch process control by separating recipes, equipment, and procedures into reusable, governable elements. Its practical value is real, but it depends heavily on implementation quality, data discipline, and how well it is adapted to existing plant systems.