ISA-88 (ISA-88 or S88) is an international standard that provides a structured framework for designing and controlling batch manufacturing processes and overall recipes (process + equipment + materials). It defines how to represent processes as hierarchical, modular recipes and how to organize the underlying equipment model, while enforcing a clear separation between process logic and equipment control. 

By promoting parameterization, reusability and equipment independence, ISA-88 enables manufacturers to standardize operations, simplify recipe transfer across sites and ensure consistent execution of batches, regardless of the specific production environment. 

The goal of this wiki is to provide a best practice about how to model recipes in DELMIA Recipe Management application to be compliant with ISA-88.

ISA-88 is not a GXP compliance requirement, it is a standard, a way of working that companies can follow, or not, therefore it doesn't require :

• Regulatory compliance features (audit trails, e-signatures, ... functionalities)
• Change control or versioning
• Quality or material management

Here are the question you need to ask yourself if a customer is asking if we are ISA S88 compliant:

• Do we support the 4 recipe types (General, Site, Master and Control) as defined in ISA-88?
• Can we model the full procedural hierarchy (Procedure, Unit Procedure, Operation & Phase)?
• Are recipes defined in the platform independent from specific equipment instances?
• Can recipes reference equipment capabilities and physical assets?
• Can phases and operations be reused across multiple recipes?
• Are process parameters fully externalized and configurable ?
• Is there a strict separation between process logic and equipment control logic?
• Can the same master recipe be deployed across multiple sites with minimal rework?

The goal of this wiki page is to list ISA 88 requirements and help you understand how to be compliant to these requirements with Recipe Management Engineer application if a customer si requiring compliance.

In black will be about what ISA 88 is requiring and in blue how we can answer thanks to the platform to these requirements.

The wiki is structured as followed:

1. The recipe structure
2. The enterprise recipe flow model
3. The physical model
4. Decoupling process and equipment

The enterprise recipe flow model

ISA-88 requires that recipes are not just instructions, but formal objects with defined levels from general definitions, down to execution-ready definitions and finally to a specific batch instance. 

Definition of the different recipe levels

ISA-88 defines 4 types of recipes that is essential for tech transfer between sites, regulatory submissions and batch traceability:

Remark: In the following wiki, we are not going to focus on Control Recipes as Control recipes are instances of Master Recipes at Scheduling and Execution Levels so doesn't require modeling/definition capabilities. 

How to go from a General Recipe to a Master Recipe

A key capability defined by ISA-88 is the ability to structure recipes hierarchically, where each level is derived from the one above. For example, a site recipe is derived from a general recipe and a master recipe is derived from a site recipe.

From General Recipe to Site Recipe

• Branch the full General Recipe process structure from Header Workplan to the last level of General Operations down to Work Instructions, rename the Ttile as (Site_Recipe_ProductXXX). 
  • While branching the process, select also all Continuous Manufactured Materials, Continuous In-Process Materials, Phases and Continous By-Product without the Continuous provided materials (as they will be replaced by local materials)
  • While branching the process, select also the scoped "Capable Resource Structure" node without the Continuous provided materials (as they will be replaced by Site Representative resources).
• Replace the General provided materials with the Site Specific Materials (create any to be qualified if necessary) that are referenced in classification and can be dragged & dropped from IP Classify & Reuse
• Replace the General Resources with Representative site equipment that are referenced in Classification.

From Site Recipe to Master Recipe

• Branch the full Site Recipe process structure from Header Workplan to General Operations down to Work Instructions, rename the Ttile as (Master_Recipe_ProductXXX). 
• Replace Site Representative equipment with real serialized equipment that are referenced in Classification and/or modeled in an Asset Structure. 

Remarks:

• Branching Processes + Resources + Materials can be done in RME through the auxiliar view, users can drag & drop the given objects in the auxiliar view, multi select them and execute the branching actions. This would keep the Implement and capable resource links between the different objects. 
• For additional clarity, the customer can add an additional custom attribute per Recipe Type with a combo list (General, Site & Master) that can be filtered through a 6WTag.
• Starting 27xFD02, it will be possible to define "Originate links" between Header Workplans, that could be a more flexible solutions to manage links between General, Site and Master types of recipes but without further possibilities to do change impact assessment that could be envisioned through branching.
• Relations between branched recipes can be visualised through the "Revision" command in the Lifecycle Tab from the toolbar in Recipe Management:

The recipe structure

Process & Procedural Structure

Definition

The general and site recipe procedures are structured using the levels described in the process model which allows the process to be described in non-equipment specific terms.

The master and control recipe procedures are structured using the levels described in the procedural control model, the elements of which have a relationship to serialized equipment.

Process Model

ISA-88 requires that a batch process is broken down into 4 well-defined levels through the Process Model for General and Site Recipes which correspond to the functionality of the analogous levels :

• Process: Produce Antibody Drug Conjugate
  • Process Stage: Conjugation
    • Process Operation: Reaction
      • Process Action: Add linker

This gives a clear, structured decomposition of the recipe. A "Mixing Process" may include a process stage like "Add Ingredients" with Process Operations like "Dose Solvent" and process actions like "Open Valve".

In general, there is a 1:1 correspondence between the process stages, operations and actions in a general recipe and in a site recipe except that the site recipe stages, operations and actions can be made site-specific.

DELMIA Data Model allows to model the Process Model with the following objects:

• Process: Header Workplan
  • Process Stage: Workplan (APRISO: Process / BIOVIA_ENOVIA: Phase)
    • Process Operation: Header Operation (APRISO: Operation)
      • Process Action: General Operation (APRISO: Step)

Procedural model

The ISA 88 introduces another model, the procedural model that goes a bit deeper as the phases are representing process parameters that are going to be executed with the target vale setpoint of machines, collected target value, ranges, criticality, units and dimensions. This model is mainly use to model Master Recipes and is made up of ordered sets of recipe unit procedures, operations and phases, using the Procedural Control Model.

• Procedure: Produce ADC
  • Unit Procedure: Conjugation 
    • Operation: Reaction
      • Phase: Add Linker
        • Parameters: Quantity 
      • Phase: Start Agitation
        • Parameters: SET 200 rpm
      • Phase: Heat to Setpoint
        • Parameters: SET 20°C / GET pH 7.2 (7.1/7.3)

DELMIA Data Model allows to model the Procedural Model with the following objects:

• Procedure: Header Workplan
  • Unit Procedure: Workplan (APRISO: Process / BIOVIA_ENOVIA: Phase)
    • Operation: Header Operation (APRISO: Operation)
      • Phase: General Operation (APRISO: Step)
        • Parameters: DCP / RPP rows (APRISO: Activity)

Remarks:

• ISA-88 is using the name of "Phase" for the last level of the procedural model level, in the 3DEPXPERIENCE platform, Phase is used by BIOVIA Formulation Design and XSR Specification Management to represent the second and last level of their process structure level (first one being the Procedure reflecting the manufacturing of a given product and second one being the phase, example: "Mixing" can be a "Phase"). Phase is also used as a Formula Item object in RME that can be scoped to Header Worplans or Workplans, it represents a grouping of Continuous Provided Material.

Enable Process Reusability

ISA-88 promotes building processes from reusable elements, standard phases (heating, mixing) and standard operations instead of redefining everything each time. 

All process objects are referenced in the 3DSPACE and therefore be found and reassigned where needed through search for example. 

Admins can also define Libraries, through IP classification editor for process reusability, defined through Procedure/Unit Procedure/phases/operations, here is a best practice proposal:

Users can then navigate and reuse process objects along the recipe definition process through drag-and-drop Procedural Objects.  

Sequence and define transitions between steps

ISA-88 requires defining how process operations are sequenced and connected. Each step follows a clear order, with transitions and conditions (if/then logic) determining when to move to the next step, ensuring a consistent and controlled process flow. 

The Process Flow Diagram / Pert Chart available in Recipe Management allows to define product flow links between process objects of the same types (Wokplans/Header Operations & General Operations) under the same parent with specific types of flows / conditions (Alternate / Scrap / Good / Failed). 

It enables the implementation of conditional logic, which is required when process steps depend on real-time conditions rather than a fixed sequence. For example, in a fed-batch process, buffer (a raw material) must be added each time the pH exceeds a defined threshold. Since the timing and frequency of these additions cannot be predetermined, the process must continuously evaluate the pH and trigger the addition only when the condition is met.
It also supports parallel operations, allowing different product flows and quantity splits.

Remarks:

• User has to select the "Sequencing mode" of the parent operations from which he wants to create links between as "Based on Product Flow" (this mode sequences child operations dynamically, based on explicit product flow connections defined between operations with conditional logic, parralel flows, quantity splits or time constraints) vs "Based on Tree order" (this mode sequences child operations statically, following their hierarchical order in the process tree. It enforces a strict linear execution with no conditional branching or parallelism). Available as a column in the spreadsheet view of RME on the Operations tab

• Users can also detail additional information on the "Linkk Attributes" such as Delay mode, delay, dependency type or quantity overlap

Formula

In ISA-88, materials are defined as part of the recipe’s formula, specifying the inputs and outputs required to execute a batch. This includes the identification and quantities of raw materials, intermediates and final products, as well as their relationship to specific process steps. The focus is on how materials are used and transformed during execution, ensuring consistency and scalability, rather than on full material lifecycle or inventory management.

What the ISA 88 says about Process inputs

Identification and quantity of a raw material required to make a specific quantity of finished product.

How to model it in the 3DEXPERIENCE platform:

• Non discrete raw materials are defined through Continuous Provided Materials, these can model bulk inputs supplied to a process in nondiscrete quantities (gas products, granules or liquids). Defined by consumption metrics ( Mass or Volume _ 100kg of sugar).

  

• Consumables can also be defined as Provided Parts and are defined as premade discrete components or parts sourced externally. Added to processes as fixed-unit inputs (filters or single use bags) and managed in inventory or procurement systems.

   

What the ISA 88 says about Process outputs

Identification and quantity of an intermediate / finished material expected to result from one execution of the recipe. May detail environmental impact and specification of the intended outputs in terms of quantity, labelling and yield.

How to model it in the 3DEXPERIENCE platform:

• Finished Products are defined through Continuous Manufactured Materials and refer to bulk or nondiscrete materials produced in a continuous / batch flow through a workplan or header workplan, such as medicines, chemicals, plastics, liquids or food products that can be put in inventory. Unlike discrete parts, these materials are not counted in individual units but are instead measured by quantities like mass, volume, length or area.

• Intermediates can be defined into 2 different ways, Continuous Manufactured Materials if the intermediate is going to inventory or through continuous In-Process Items that wouldn't be stored but require quality checks with attached performance specifications.

Quality attributes are defined through Performance Characteristics for raw materials, WIP and finished products (conductivity, cell density,...) with acceptance criteria and release limits and can be accessible directly from the information panel of the material in Recipe Management application.

Relationships between the process and the material through Implement links

In ISA-88, materials are not simply defined in a list but are explicitly linked to specific process steps within the recipe. This means that each material is introduced, consumed or produced at a defined point in the process flow, ensuring a clear connection between the formula and the procedural execution. This linkage enables precise control of when and how materials are handled during batch execution, improving consistency and traceability of the process.

Different materials can be scoped / implemented based on their nature with different roles that are owned by the implement link that define permissible actions or states for items/processes:

Items	Operations Link Types	Possible roles defined on implement links
Continuous Provided Materials	Can be implemented to Header Operations or General Operations
Provided Parts	Can be implemented to Header Operations or General Operations
Continuous In-Process Materials	Can be implemented to Header Operations or General Operations
Continuous Manufactured Materials	Can be scoped to Header Workplans and Workplans Can be implemented to Header Operations or General Operations
Phase	Can be scoped to Header Workplan or Workplans	NA

Remarks:

• The roles that are on the implement link can be customized by the admin in the Control Center.

• If there is a need to have an OOTB integration to APRISO, even if the materials could be found at Header Operations level, the best practice would be to implement them to General Operations. If there is a project with only Ortems, the best practice would be to have them implemented at the Header Operations level. If there is a project for both APRISO & ORTEMS, the users would have to implement them at General Operation level and then the service team would manage the retrieval at Header Operation level for Ortems. Need to be defined for the best practice for OOTB integration with PSL.

• The links are then displayed as is in the grid view with the (role):

Management of quantities per recipe types

In ISA-88, quantity management evolves across the different recipe types. Early stages (General, Site) define theoretical quantities, while the Master Recipe refines them with process constraints. During execution, the Recipe definition distinguishes between defined quantities on the Formula Items that are the necessary quantities for one material and to produce one batch and consumed quantities that can be a sub-quantity of the defined quantity.

Here is a recommendation about how to manage quantities in RME based on the recipe type:

Remark: 

• Managing Formula / MBOM's in Percentage will be delivered on a 27x release with auto calculation of Continuous Quantities. 
• Customers might have their MBOM definition in SAP, which would make it complicated to link them to the process OOTB

The physical model

In parallel to the process, ISA-88 defines a hierarchy of equipment from site level down to units and control modules.

The requirement is that the process steps can be mapped to this equipment structure but are not hardcoded to specific assets too early.

Recipe Level	Type of resource Structure used for process modeling	Resource Structure example	Classification Structure of equipment	Asset Structure
General Recipe	Capable Resource Structure			Not applicable
Site Recipe	Capable Resource Structure			Not applicable
Master Recipe	Asset Structure	Not applicable	Not applicable

Remarks: 

• Capable Resource Structure [For General & Site Recipe]: A Capable Resource Structure is a hierarchical framework that defines and organizes the physical or logical resources required to execute one given recipe with generic equipment. The definition of Capable Resource Structure from a Classification Structure is relevant for the definiton of General and Site recipes, where Generic Resources are referenced in Libraries. It can be modeled by drag & dropping objects from IP Classify & Reuse to the Capable Resource structure. 

A "Capable Resources Structure" can be created from the authoring tab in RME:

• Asset Structure [For Master Recipe]: An Asset Structure represents the physical or logical hierarchy of a company with one or multiple factories, organizing key elements such as workcenters (logical or physical units where operations are performed), serialized assets with individual machines or pieces of equipment (a mixer with a serial number) and pools (groups of similar assets or resources managed collectively for efficiency). This structure serves as a foundational framework for linking manufacturing resources to production processes, particularly for scheduling and execution. This hierarchy mirrors the logic of the factory layout, with Serialized Assets and is independent of specific Recipes / production processes but can be dynamically linked to them. The best practice would be for Master Recipe to:

  • Link the Header Workplan with an "Asset Structure" link to the "Factory" or "line" level

  • The Workplan with a "Pre-assigned" link to the Workcenter

  • The "Industrial Machine" as Primary Capable Resource

  • The "Sensors" as Secondary Capable Resource

  Asset Structures can be created from Factory Resource Management application, by deriving an existing General Resource or creating it from scratch and then reusing them in Recipe Management application.

Decoupling process and equipment

It's an important concept of ISA 88 to decouple process logic vs equipment logic, the process defines what to do and the equipment defines how it is done, it is even more important for General recipes as they should strictly NOT be tied to specific equipment, the recipe says “heat to 37°C” and then the equipment decides how to do it. 

Then, the Master Recipe can in addition consider equipment constraints and slightly modify the recipe based on this constraint. The ISA 88 also mention that the Parameters definition should be decoupled of the equipment execution logic, the recipe gives the parameters and the equipment manage the automatism logic.

This enables:

• Portability (same recipe, different plant)
• Flexibility (scale-up, tech transfer)
• Easier validation

Therefore, users have to execute the following tasks based on type of recipes: 

Recipe Level	Tasks	Illustration
[Process Model] General Recipe	Create Procedural Structure Create DCP/RPP and DCP/RPP rows without any link to equipment.
[Process Model] Site Recipe	Create Capable Resource Structure (Creating an Area) Search Site Representative Resources in libraries Create Capable Resource Links to Header Operations  Create Capable Resource Links to Header Operations Modify RPP / DCP row values based tech transfer rules Link RP to a RPP row
[Procedural Model] Master Recipe	Search and elect Serialized Representative Resources Replace Site Representative Capable Resource by Serialized Capable Resource Update the link about the RP of the updated resource and the RPP row

Remarks:

• RPP and DCP rows allow to manage the Setting of Instructions for a resource or to a resource or the collection of data during the process that can be manual collection of resource based data collection. 
• DCP rows would be defined for data that are collected and referenced as is in the Electronic Batch Record.
• RPP rows GET would be defined for data that are collected but not influencing critically quality therefore don't need to be put in the EBR. 
• The visualisation of RPP / DCP rows is optimized through the Swimlane view.