With the vigorous expansion of the global biopharmaceutical sector, a growing portfolio of biologic products has advanced into commercial manufacturing. As a vital segment within the biopharmaceutical value chain, fluid processing technology exerts profound impacts on drug quality, production throughput and time‑to‑market.
This paper presents flexible production practices implemented on an ISA‑88 architecture with WinCC. It elaborates the core principles of ISA‑88 physical and procedural models to achieve decoupling between process logic and equipment control. Leveraging redundant system design, recipe governance and standardized Phase/Operation frameworks, batch control is deployed via S7‑1500 PLC and WinCC to underpin data integrity and regulatory compliance. The paper further explores the convergence of IT and OT systems, and highlights the architecture’s strengths in flexibility, operational reliability and regulatory compliance for multi‑product, low‑volume manufacturing.
Driven by the global manufacturing paradigm shift, process industries including pharmaceuticals, food and beverage, fine chemicals and biotechnology are facing unprecedented challenges and opportunities. Market requirements have rapidly evolved from mass production of single products toward customised manufacturing characterised by high product variety and small batch sizes. This paradigm shift imposes new requirements on automation systems: how can different product specifications be manufactured rapidly on a common physical asset base merely through recipe reconfiguration? How can consistent batch quality and full traceability be maintained while satisfying stringent regulatory audits such as GMP and FDA 21 CFR Part 11?
The ISA‑88 standard (commonly referred to as S88) provides a globally recognised framework to address these challenges. First published in 1995, ISA‑88 establishes consistent terminology and reference models for batch control. More importantly, it introduces a transformative design philosophy: the separation of process recipes from equipment control. This principle breaks the conventional PLC programming paradigm where process sequences and equipment control logic are tightly interwoven. It decouples two independent dimensions: the equipment assets deployed for production, and the procedural methodology of manufacturing.
Drawing on contemporary technical documentation, industrial field cases and the authors’ hands‑on engineering experience, this paper comprehensively addresses the implementation essentials of ISA‑88 projects built upon classic WinCC, covering system architecture, redundancy configuration, recipe governance, modularised development, data integration and future technical outlook.
1 Theoretical Foundation of the ISA‑88 Model and Evolution of the WinCC Platform
1.1 Core Philosophy of ISA‑88: Decoupling of Process and Procedure
To contextualise WinCC‑based batch systems, it is essential to fully comprehend the two foundational S88 constructs: the physical model and the procedural model.
The physical model defines hierarchical production assets:
1. Enterprise: The uppermost tier, responsible for corporate strategic decision‑making.
2. Site: A geographically bounded manufacturing facility.
3. Process Cell: The core production entity with independent manufacturing capacity, capable of executing one or multiple batches. Within a pharmaceutical plant, a reaction train and its auxiliary utilities typically correspond to one Process Cell.
4. Unit: Primary process equipment hosted within the Process Cell, such as reactors or mixing vessels, which may only be allocated to a single batch at any given time.
5. Equipment Module: A coordinated assembly of equipment executing a dedicated local function, for instance a gravimetric dosing module or closed‑loop temperature control module.
6. Control Module: The lowest tier of automation components, encompassing discrete valves, pumps and field sensors.
The procedural model defines the formal description of manufacturing workflows:
1. Phase: The elementary low‑level control task, exemplified by “open valve” or “start agitator”.
2. Operation: A relatively self‑contained process step assembled from multiple Phases. A feeding Operation, for example, may comprise sequential actions including opening the inlet valve, activating the feed pump and monitoring flow accumulation.
3. Procedure: A complete manufacturing workflow composed of sequential Operations. A product formulation Procedure may include material charging, heating, hold and agitation Operations.
4. Recipe: A formal definition of the Procedures, setpoint parameters and equipment allocation rules required to manufacture a defined product.
The transformative merit of ISA‑88 lies in the capability to instantiate new product recipes through recombination and parameterisation, without modification to underlying equipment control logic. Within WinCC Batch, low‑level Phase logic is typically implemented using SCL in the PLC, whereas process engineers graphically assemble recipes from these predefined Phases via WinCC’s native recipe editor.
In field engineering, particularly for 24/7 continuous pharmaceutical production lines, system reliability constitutes a non‑negotiable baseline requirement. A single point of failure can trigger full line shutdown and substantial commercial losses. Consequently, redundant architecture design becomes a core consideration for large‑scale Batch projects. This paper describes the design and configuration of a representative redundant ISA‑88 implementation built on classic WinCC.
The architecture adopts a master‑standby hot standby scheme. The master server bears all active production workloads, while the standby server synchronises runtime data in real time and assumes production responsibilities immediately upon master server failure.
1. PC1 (Master Server): Hosts the WinCC Server runtime
2. PC2 (Standby Server): Deployed with WinCC Redundant Server as a hot standby node, ready for seamless takeover
3. Client Nodes: WinCC Client installations for operator supervision and recipe authoring by process engineers
4. Controller Tier: Redundant S7‑1500 PLCs communicating with the server layer over industrial Ethernet
2 Engineering Implementation of Recipe Management — A Case Study of a Pharmaceutical System
2.1 S88‑Compliant Procedural Recipes: Process and Equipment Decoupling
Within traditional PLC development, process logic is often hard‑coded as fixed sequential control within ladder logic. Only limited process parameters are exposed for entry on the HMI, while process sequences remain static, resulting in poor production reconfigurability. As an illustration, a material transfer routine may directly control Pump 1, Valve 2 and heating hardware, with timing logic embedded statically. The inherent limitation is clear: any adjustment to the transfer temperature profile or insertion of pre‑transfer process activities requires PLC code modification. This approach suffers from low engineering efficiency and introduces risks of unintended software defects.
Under the ISA‑88 framework, recipes are procedural by design. For illustrative purposes, process engineers may define production sequences graphically within the WinCC recipe editor as follows:
Step 1: Execute “Quantitative Water Addition” on Unit1, Parameter: Water dosage = 50 kg
Step 2: Execute “Temperature Control” on Unit1, Parameter: Target temperature = 65 ℃
Step 3: Execute “Temperature Control” and “Agitation” on Unit1, Parameter: Hold time = 60 min, Agitation speed = 60 RPM
These Operations abstract low‑level equipment details such as pump actuation and valve switching; such hardware behaviours are encapsulated within Equipment Modules and invoked inside individual Phases. New product recipes can therefore be authored and amended independently.
During validation activities, verification scope only needs to extend down to the Phase level.
2.2 Instantiation and Dynamic Allocation of Unit Recipes
ISA‑88 stipulates that a Unit can only be assigned to one batch at any moment to eliminate resource contention. In project deployments with three physical Units, each is treated as an independent asset, and a Unit occupancy registry is maintained for resource scheduling.
Encapsulation of Phase Logic: On the PLC layer (e.g. S7‑1500), core Phase routines including feeding, agitation, heating and cleaning are encapsulated as standard function blocks (FBs) with normalised input and output interfaces. A gravimetric dosing Phase, for example, accepts input parameters for target weight, allowable tolerance and feed rate, and outputs status flags for execution completion and fault reporting.
Parameterised Invocation Mechanism: When WinCC Batch initiates a master recipe for product manufacturing, the system evaluates the occupancy status of the three Units and executes the manufacturing sequence defined in the recipe accordingly.
3 Engineering Implementation of Phase and Operation Design — Core Delivery of S88
Within the ISA‑88 architecture, Phases and Operations function as the execution and logical building blocks of the batch control system. They form the bridging layer between high‑level recipes and field equipment. The quality of their design directly governs system flexibility, reliability and maintainability. This section explores Phase and Operation design methodologies based on the Siemens stack: S7‑1500 / TIA Portal paired with WinCC.
3.1 Definition and Encapsulation Principles of Phases
3.1.1 Definition of a Phase
Within the S88 procedural model, a Phase represents the minimum low‑level control task, encapsulating a discrete set of equipment control actions. Each Phase maps to an indivisible elemental process action[3], typical examples including PH_OpenValve (Open Valve), PH_StartPump (Start Pump), PH_HeatToTemp (Heat to Target Temperature) and PH_Dosing (Metered Dosing).
Key characteristics of a Phase:
1. Atomicity: Executes one complete elemental function with standardised external interfaces
2. Parameterisability: Receives setpoint values such as target temperature or dosing quantity via input parameters
3. Status reporting: Communicates execution states to upper layers, including running, completed, faulted and held
4. Equipment binding: Associated with a specific Equipment Module or Control Module
3.1.2 Standard Interface Specification for Phases
To enable seamless integration with WinCC Batch, Phase interfaces must comply with ISA‑88 specifications. A standard Phase function block implements the following interface elements[3].
Input signals include an Enable boolean flag set by the Batch runtime, a variant or user‑defined data type container for process parameters such as setpoints, tolerances and duration, an Abort boolean for emergency termination and a Hold boolean for pause commands. Output signals comprise Done indicating successful completion, Busy denoting active execution, Error signalling a runtime fault, an ErrorCode word for diagnostic tagging and a Status word encoding detailed machine states including idle, running, held and completed. An in‑out parameter DeviceRef of variant type references the instantiated Equipment Module associated with the Phase.
3.1.3 Internal State Machine Design of Phases
Every Phase must implement a full state machine to respond to commands originating from the Batch system. State transitions follow the standard sequence outlined below.
IDLE denotes the quiescent state, awaiting an enable command from the Batch system. RUNNING indicates active execution of control logic. HOLDING is entered upon receipt of a pause instruction while the pause sequence is executed. HELD signifies successful suspension, pending a resume command. RESTARTING represents the transition back to operation from the held state. COMPLETE marks normal successful termination. RESET triggers state reset to return the Phase to IDLE.
This state machine architecture ensures the Phase can reliably respond to Batch commands including Hold, Resume and Abort.
3.2 Combinatorial Logic Design of Operations
3.2.1 Definition and Functional Role of an Operation
An Operation is a logical construct assembled from sequentially executed Phases to deliver a self‑contained process function. A feeding Operation, for instance, may incorporate the following Phase sequence:
- PH_OpenInletValve — Open inlet valve
- PH_StartFeedPump — Start feed pump
- PH_MonitorFlow — Monitor cumulative flow
- PH_StopPump — Stop pump
- PH_CloseValve — Close valve
Key characteristics of Operations:
1. Mid‑tier logical entity: positioned between low‑level Phases and top‑level Recipes
2. Reusability: a single Operation may be invoked across multiple independent recipes
3. Sequential orchestration: governs Phase execution order and transition conditions
4. Exception handling: defines recovery strategies triggered by failure of any constituent Phase
3.2.2 Operation Implementation Approaches
At the WinCC Batch layer, Operations can be directly assembled from Phases by process engineers within the recipe editor. In this implementation mode, Operation definition is fully configured on the supervisory layer, with the PLC only responsible for hosting the underlying Phases.
3.2.3 Interaction Protocol between Operation and Phase
Operations invoke Phases in accordance with a standardised interaction protocol. Using the Siemens Batch system as reference, the communication workflow proceeds as follows.
First, command issuance: the Operation asserts the Phase Enable bit by writing TRUE through PLC variable interfaces. Second, status monitoring: the Operation continuously polls the Phase’s Busy, Done and Error status bits. Third, parameter transfer: recipe parameters are written into the Phase input parameter region. Fourth, command synchronisation: upon reception of a Hold command, the Operation sets the Phase Hold bit to TRUE; upon Resume, the Hold bit is cleared; upon Abort, the Operation asserts the Phase Abort bit to TRUE.
This bit‑and‑word based interaction mechanism is simple and robust, independent of complex data structures, and preserves real‑time communication performance.
Recipes are constructed in a modular, lego‑style fashion through flexible composition of Phases and Operations, meeting manufacturing requirements for diverse products and achieving the flexible integration of process logic and physical equipment. Process engineers can reorganise and configure process sequences autonomously without intervention from software developers.
4.1 Electronic Batch Records and Audit Trails
Regulatory mandates such as FDA 21 CFR Part 11 require pharmaceutical and food manufacturers to retain immutable electronic batch documentation. Leveraging WinCC’s archiving subsystem, an Electronic Batch Record (EBR) is generated for every executed batch.
The EBR captures a full batch timeline, including start timestamp, end timestamp and duration of every process step; trend traces of actual process parameters alongside their setpoint baselines; operator intervention logs recording user identity, timestamp and modified parameters; alarm and event histories capturing process anomalies and corresponding operator responses; and electronic signatures for operator validation at critical process steps.
All datasets are persisted within SQL Server databases via WinCC’s archiving engine. Records are tamper‑resistant, retrievable on demand and printable, fully satisfying regulatory audit requirements.
Via exposed data interfaces, third‑party tools such as Excel and Power BI can access data under read‑only permissions to support engineering analytics and generation of custom process reports.
5 Outlook on Technical Evolution
5.1 WinCC Unified and Web‑Based Architecture
As Siemens continues to promote WinCC Unified, web‑enabled visualisation is emerging as the mainstream paradigm. Built on HTML5 technology, Unified enables operators to access production graphics from PCs, tablets or mobile devices, delivering true mobile operation and maintenance capabilities. SiQence, the native batch solution for Unified, provides a modern responsive user interface supporting multi‑touch interaction, aligning with the operational habits of new‑generation plant personnel.
Future migration from C/S to B/S architecture will unlock expanded opportunities for secure mobile data access.
5.2 Standardisation as the Future
Field experience from case projects demonstrates that engineering methodologies built on ISA‑88 standards and Siemens template frameworks are transitioning from hand‑coded development toward configuration‑centric integration. Organisations can codify proprietary process knowledge into standardised Equipment Modules and process templates to enable knowledge reuse and institutional inheritance. Regardless of platform evolution — from classic WinCC C/S architecture to Unified B/S architecture, or from on‑premises deployment to cloud‑edge orchestration — modularisation and separation of concerns will remain enduring foundational principles of industrial automation[4].
A WinCC‑based ISA‑88 architecture project represents far more than software configuration; it embodies a transformation in production management philosophy. It translates complex manufacturing workflows into structured data models, satisfying market demand for product diversification while sustaining standardisation and regulatory compliance for commercial production.
For automation engineers and enterprise decision‑makers embarking on Batch projects, deep comprehension of ISA‑88 physical and procedural models, deliberate redundant architecture planning and adoption of standardised development frameworks carry greater strategic weight than low‑level software manipulation. Only upon a solid foundation of standardisation can enterprises establish truly flexible, reliable and scalable intelligent manufacturing systems and capture competitive advantages amid digital transformation.
