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.