Pharmaceutical Fermenter Equipment Modules

I have recently been looking at ControlDraw models for  large scale Pharmaceutical Fermenter Units from 4 different companies. Process wise, all the fermenters are broadly similar, but each client has their own way!
I cannot publish them because because they are confidential, agreements signed!

However I have summarised them using some statistics from the models. 

Some differences are immediately apparent.

Why is the IO Count for Client 3 so low? This is because they do not use limit switches on their valves. This is something I have never understood as it seems to me that any cost savings would be obliterated by the downtime cause by the inablity to quickly diagnose valve failures.

Why do  Clients 1 and 3 have so many parameters? I think that this is in part because they do not distinguish between critical parameters (that can be changed to define the product or CIP ) and other parameters

Actually the differences are greater than they appear, mostly because of different ways of handling routing and cleaning.
What they all have in common is Equipement modules for:

Agitator Control
CIP / SIP
Dissolved Oxygen Control
Exhaust Filter
Gas Feed
Inoculation Transfer
Media Supply
pH Control
Pressure Control
Product Transfer
Sampling
Temperature Control

Some of the models are Unit Centric (the EM's are driven to states by a Unit Level phase) and some are EM Centric where the EM's run phases in parallel with each other. The former approach is my preference as it results in less complexity

S88 Phase Programming for DeltaV

With Emerson’s DeltaV and some other systems an S88 Phase is constructed around their version of the S88 “State transition diagram for example states for procedural elements.”

The Emerson structure uses Sequential Function Charts for each of the major state changes, such as that the Running SFC that goes between  Idle and Complete. In addition a Fail Monitor evaluates conditions that cause the phase to go into the Holding state.

The diagram below shows an overview of this.

Now, there are other and in my opinion better ways of constructing the phases. For example a Phase could just have one SFC, but with Running Holding, Aborting, Stopping And Restarting logic all handled within the same SFC.

Actually it is quite possible to do that even using the Emerson structure, if you don’t slavishly follow the Emerson examples. 

ISA 106 - a Simple Hierarchy diagram

Just an initial proposal!

Suggestion for ISA 106 - The Production Run

This ISA 106 Production Run overview diagram shows a suggested high level state model for a Production Run
A Production Run is a suggested new Term that covers the operation of a Unit or Process Cell from shutdown through Starting, Producing to Stopping and back to ShutdownThe Production Run
Click the diagram to see it full size

ISA106 - What is a continuous process anyway?

You can read about the new ISA106 committee here. It is intended to develop standards, recommended practices, and technical reports on the design and implementation of procedures for automating continuous process operations.
One question this raises is what a continuous process really is! So let's look at a couple of real processes.


The first example is from the biotech world, the second from petrochemicals

Fermentation - there are some very large processes with fermentation at their core. Some use entirely batch whereby the fermentation is done and then the fermentation product is transferred downstream as a single batch. But there are others that run the fermenter continuously for as long as they can (many weeks) whilst periodically taking fermentation product out. Is this batch or continuous? They most certainly have recipes. And either way they spend a lot of time in a single controlled state that is essentially governed by control loops. I know of many such processes and both types use S88 oriented implementations.

The Unipol process. (A nice animation, note the batches appearing in step 6)
Much like the continuous version of the fermentation process this runs with a continuous feed but product is taken from the reactor in batches. Different grades of product can be made by changing the set points (recipe formula!) without shutting down. Is this batch or continuous?   This process too spends much of it's time in a single controlled state that is essentially governed by control loops.

It is not really important. but ff the two, the fermentation processes I have seen are more complex, but in part this is due to CIP complexities. On the other hand the Unipol process has more complex control loops and higher level optimisation systems.

I suspect the petrochemical industry is right up 106's street and the biotech industry is not

So what will distinguish the sort of process (or is it industries?) that 106 is to be aimed at?
This is a key point that must be resolved at the meeting

Finally a note -  there used to be a link to the Official ISA Part 5 Blog 

But this is presently unavailable as controlengineering.com has closed. Supposedly it will return.

ISA106: Procedural Automation for Continuous Process Operations

A new standard is being proposed, called ISA106: Procedural Automation for Continuous Process Operations
The WBF website provides a description of the forthcoming effort.

In the very early days of S88 Part 1, in October 1995 I presented a paper at the EBF in Dublin titled “Extending SP88 into continuous and semi-continuous processes.”

One point I made was that the Recipe operations for a continuous process are distributed in Space rather than time. So the sequence of process operations to make stuff happens continuously in a stream of equipment.

The essence of this is exactly the same as defined in part 1 for batch, so a continuous operation still carries out a process operation - A major processing activity that usually results in a chemical or physical change in the material being processed .

And in a continuous plant the ‘sequence’ is achieved continuously as the material passes through the equipment, whereas a batch plant carries out the sequence of actions batch by batch and may carry out many of the sequence of operations in the same equipment.



Since then I have further developed my understanding this to encompass how to make continuous processes (or discrete ones) exactly the same as batch..

The essence here is that the procedures needed to make a quantity of stuff or things as from the operation viewpoint can be identical for both batch and continuous.

This is predicated on the idea that the procedural operation of plants, whether batch, continuous or discrete can be the same. And that these procedures do not need to work real time – or at least in the time domain needed to control equipment.

Unfortunately (from an s88 purist’s point of view like mine) the procedural aspects of part 1 have been taken by many to prescribe a means of controlling equipment.

Now the concept of combining sequential control with state orientated control is a very powerful one, capable of controlling highly complex processes. But in my view these equipment sequences are not the same as the procedural level that puts together product independent equipment control to make stuff.

And I have never agreed that the procedural level as described in the original Part 1 was intended for equipment control. It was intended to provide the means to map equipment control to the operational procedures needed to make stuff. And no more.

But practise has not been that, and what we now have is a lot of systems which use recipe managers to perform equipment control - and I am convinced that this has been detrimental to many projects.

Now, referring to the Dow/ABB State based Control architecture I know it very well and I have in fact worked with Dow and Yahya to develop ControlDraw to support it even better than it used to.

But I do not believe that it is really S88 based, apart from the division of units into equipment modules (which by the way are not recipe aware) and control modules. The entire procedural level in the examples of this approach is missing, yes there are sequences to start up and shut down the equipment, but they are not in my opinion even phases as they do not perform process actions. For example, a sequence to start a distillation column is not a phase because it does not perform a process action, it just sets the column into the state where it can perform the distil process.

There is much more to say, for example about equipment requirements and routing etc. But I do ask that the ISA106 group consider what I am saying about the procedural level being an operational level rather than a control level.

What are all these Recipe Defer Functions for?

If you are programming a Batch Manager, such as DeltaV batch or RSBatch, you will find yourself having to define the Defer Levels of Recipe parameters.

What is all this about?

Well, you can see some explanation on the DeltaV Books Online web site. And by the way Emerson, thank you for that excellent resource. And the explanation of the paints project shows well how to build a recipe in DeltaV.  

The basic principle is that the value of a recipe formula parameter used in a phase can be set by a higher level, so that you can ultimately create a master recipe formula containing the settings and define a path through the procedural hierarchy that sets the required value in the phase and hence in the equipment control.
Now, there may be many, perhaps hundreds or more, parameters that are used in the entire collection of phases that are run for a batch, but the actual master recipe formula need only have a small portion of them.
A design rule might be to only defer parameters that have to change for different recipes.

Deferring a Recipe to the Recipe Procedure

Deferring a Recipe to the Unit Procedure

The actual process of defining the paths looks rather tedious, because (as I understand)  you have to go through each level of the hierarchy, bottom up, deciding whether a parameter must be deferred, and furthermore if a parameter has to pass though multiple levels, then each level needs to contain the parameter - shown as Pass Thru parameters in the above diagrams. I can't help thinking that there must be a better way.
ControlDraw by the way allows you to link the top level parameters to the bottom level ones and then automatically work out all these Pass Thru parameters. Whether DeltaV would allow you to import these I do not know.