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 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

More on Common Resources

Good old Anonymous has made some good comments about Common Resources.
Anonymous people are founts of infinite wisdom, if only you could meet them over a pint!
Read the whole comment - at the end Anon says
By your definition, these EMs would be common resources. I am not sure I agree with that, as their primary function is with the parent unit (Reactor), plus all the problems which would be associated with P&IDs, tagging etc.What about the concept of expanding and shrinking Units? How would this fit in with the concepts of common resources?
Great point, but what are these Units that expand and Contract? The comment explains it well, We do need expanding and contracting Units, for example after a mixing vessel has been filled and closed the inlet valve, what happens on the other side of that valve no longer matters. So long of course as it does not fail but that's another story.
One way of handling this is to have 'Virtual Units'. These are Units that the recipe can see, in it's view of the physical model, but that do not exist in the physical plant. These can expand and contract. (Also you can use them to point to selected equipment so the recipe does nto care wich equipment it is using - more later)
Good PLC and DCS programmers can easily construct them by the way, provided that they are prepared to use indexing and a little logic. It might help to have that rare thing, an object oriented PCS, so for example the equipment could inherit the current batch formula.

Another solution may be to eliminate Units and Equipment Modules completely and just have
Equipment Procedural Entities - EPE's. Then the recipes that are running (for example several batches and several cleans running simultaneously) can acquire the equipment that is required dynamically, using only the EPE's needed at any one point.
You can call the EPE's Units, EM's or Common Resources if you like, I don't care. The EPE's can be very small or quite large, it just depends on equipment the batch occupies.

Now, where all this gets hard is the fact that equipment control has to be fast and safe, and can be complex. Of course the safety aspect can normally be handling by simple logic that is close to the IO. The fast aspect is also easy - but not with a transaction based batch manager running on a busy PC on a busy network- this sort of performance needs controller software.

Common Resources

What are these Common Resources?

If more than one unit can acquire or request the services of a single resource, the resource is
designated as a common resource. Common resources are often present with complex batch
processes. Common resources are often implemented as either equipment modules or control
modules. A common resource may be either exclusive-use or shared-use.

That definition is pretty good for me, but there is still disagreement, and to a degree I think that they are the bits where the original S88 parties could not agree. For example, some give the example of Storage Tanks, but in an alternative perspective (not just mine) Storage Tanks are Units.

Another good example is transfer systems. Surely these are common resources?

Actually some of the best batch implementations I have seen treat them as units. They call them X units, but as far as controlling them they are exactly the same as 'normal' Units, including having Equipment Procedural Elements.
The viewpoint once described to me was that if contains even part of the batch it then it is a unit.

Something like steam supply or other utilities are for sure common resources aren't they?

Can a resource be a Unit and a Common Resource?
So, is there any prospect of the revised part 1 coming up with an improved wording that will stop the divergent interpretations, of things like storage tanks, transfer systems?

Of course, the definition that CR's may be made as equipment modules implies that they can have EPE's, and take part in recipes.
To be continued