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

Automation objects and State Based Control

State based control is a method of defining the required states of some equipment and then driving the equipment to one of these states, typically where a Phase step sets the Equipment States.
It is an excellent way of describing the required behaviour of an Automation Object, or at least what I think of as an automation object. But I cannot relate it to Part 5 as it stands.
In essence designing a state controlled automation object involves in a large part determining all the required states that you need to set that object to. Please note that these States are not comparable to the Part 1 or 5 'Procedural States', they are things like Open, Closed, Ready to Fill, Filling, Reacting etc.
ControlDraw has long supported this method because it provides a very efficient method of representing functional requirements. And consequently over the 10+ years of designing systems with ControlDraw I now have designs for hundreds of these. You can read more here and here.
They range from basic control modules like motors and valves to highly intricate units, such as BioReactors, semi continuous sterilizers etc.
And looking at these, they have never needed to contain Resource Management. Yes they may have properties that relate to Resource Management, but always the actual Resource Manager is outside them. The lower level ones such as PID Controllers, are contained in Equipment Modules or Units, and the Resource Manager does not look at them, it only deals with the higher levels.
This is one reason for my objections to Part 5 as it stands. But please understand that I don't want to spend my time complaining about Part 5, I want to contribute positively.  

As it stands, I cannot. I think it should be completely re-started or abandoned.

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.

S88 Part 5 Resource Managment

Part 5 has it seems started on a path that includes recource management in some way, tho I have yet to undertand what way.

Part 1 has no model for Resource Management so Part 5 has not got a chance of having anything worth saying in that context.

First, Part 1 should refine resources