Liquid Transfer Automation - Part 4

In this post we look at the procedural side of transfers. Starting with Recipes
In S88 a General Recipe "expresses equipment and site independent processing requirements" As such it really has nothing to say about transfers, not least because it is possible that different plants may be able provide the equipment in different ways. For example one Unit in one plant may be able to do what 2 units are needed for in another

Much the same can apply to a Site Recipe

It is when we come to the Master Recipe that transfers become important because this level of recipe must address the actual equipment in the plant in its Procedures

So here's a transfer in a Master Recipe procedure, with Send (Transfer Out) And Receive (Transfer In) phases running simultaneously

PFC showing Transfer from one unit to the next

And it is the Control Recipe that must actually perform the transfer, by invoking transfer phases in the units between which the transfer is happening
You will note that the diagram shows a Synch line connecting the Source (transfer out) and destination (transfer in) phases. This represents the data flow between sender and receiver.
Please note that these communications should be directly between the two units and should work entirely in the equipment phases,
The next post will cover this in more detail.

Liquid Transfer Automation - Part 3

In this post we can see how transfers can be made the same regardless of the source and destination, and how we can assign the equipment to ISA S88 modules
Looking first at a relatively simple case where any of three tanks can transfer to any of three destinations via a single line.

I have seen implementations where this kind of transfer was programmed into the Source and Destination units only, however that approach gets more complex the more routes there are and requires extensive work defining and programming the logic.
This can however be reduced so each Unit only has a single transfer to define and only a single program module.
In this case the source tank is just called Tank src with it's discharge valve call XVSrv, likewise the destination is named dst. This can then apply to any of the 6 possible transfers

Now we can have a single and simple transfer out sequence (an S88 phase in the source unit) which opens the discharge valve XVsrc and a corresponding transfer in which opens the fill valve XVSrc. These phases do not need to worry about controlling the other valves in the route. In fact they don't care what the route is.

Of course there is more to it than that, as we still need to make sure that the other discharge valves and feed valves are closed.

How can we handle that?

Well, let's look at what the Line can do if we give it some intelligence

We could make it respond to a request for a route, in this can one of the 6 possible routes.

Then we can make sure that the valves that must be closed are closed and those that are to be opened (by the source and destination,) are Enabled, meaning that the relevant tank has control and can open or close the valve. Here is a table showing what the 'Line' logic does

Note - it may even be possible for the Line module to find the route by some logic that works it out itself, but a simple table works in cases like this. 

Here we are in S88 terms

And we also need to establish some communications  between the source and destination unit.

This can also be done by the 'Line' common resource. There will be more to come

Liquid Transfer Automation - Part 2

Overview

For any control we need measurements, effectors and some control algorithm - lets call it control logic. Letss look how there apply to a liquids transfer.

Typical Measurements are:

Source level or weight,

Destination level or weight,

Flow path confirmation – from limit switches on valves, flowplate switches etc

Pump status, flow meter readings etc

Typical Effectors are:

Discharge valve at source, inlet valve at destination

Flow path valve actuators

Pumps, control valves etc

Control Logic

To control a transfer, there are devices at each end, such as a discharge valve and a fill valve, pumps, pressurisation systems etc that should be controlled simultaneously.

The control logic needs to sets the devices in the route, monitor them, and determine the start and end of the transfer.

Here is a very simple State Transition diagram for a transfer.

We may also need consider such things as

Need to prime pumps before transfer
Need to drain, or blow line empty after transfer
In the case where the transfer is for dosing a specific quantity there may be need to allow for the 'in flight' material that will flow after the transfer is told to stop.
And we should always consider Exception handling 

Exception handling 

There are many things that can go wrong during a transfer, such as instrumentation, pumps or valves failing, control systems failure such as IO card failure, and even communications errors between the source and destination controllers. The control logic should be designed to handle this. Typically this would involve some logic that detects the failure and then sets the equipment to some fail state, this may well be the same as the Ready State.

Source and  destination coordination:

Now, it is very likely and good practise to have a separate program module to control the source tank and another to control the destination tank. (I will cover this more in future post.) 

It is also possible that the source is controlled by a different control (PLC or DCS) to the destination. Either way it means that we need to have an interface between the source and destination modules.
And I don’t think it right to have PC’s over a network having any real time involvement in this at all, I consider that this should be the domain of purpose designed real time controllers. PLC’s or DCS controllers for example. So this interface should flow on the control network controller to controller and not depend on communications with for example a batch manager.

Liquid Transfer Automation - part 1

This is about moving liquids from one tank to another, a frequent activity in plants but one that has little guidance from the s88 standard.

Specifically it is about transferring via pipes rather than for example by intermediate containers such as bottles, barrels etc.  In other words, the situation when we want to transfer some liquid from a source tank to a destination tank. This could be when we want to move an entire batch, or it could be when one tank gets a quantity dosed from a supply tank

The issue is what control is needed during the transfer, and where and how to apply that control,.

This will cover the physical equipment, the procedures to carry out a transfer and the control logic involved. It will also suggest an S88 module structure for the task and touch on the resources handling of transfer systems

It is the intention is to define a single method that covers the various type of transfers in the same way.

This is in my opinion one of the areas where batch projects, S88 based or otherwise, have had the greatest problems, most especially in the time taken to define, and then program the solutions.

But first let’s look at the general requirements in terms of process flows and the mechanics, the pipes, valves and other equipment used to establish the flow route.

Single Source and Destination

Multiple Source and Destination via Single  line

Now, putting pipework in for each route is expensive and impractical so an alternative is to share the lines, so here for example any of three source tanks can feed any of three destinations via one pipe.

This type (often found in brewing and dairy for example) can be made automatic.

This type involves manually setting the route using Flow plates - this ensures that liquids cannot contaminate each other, typical of pharmaceutical plants

Of course in this case (and assuming the batches must not mix) only one transfer is possible at one time.
More to come, please check back.

Added 7 June 2012 - there is a very interesting discussion following this post in LinkedIn