ISA88 Part 5 draft: Resource Manager implementation question, answer
In posted comment and question to a prior blog posting, "Revised ISA88 Part 5 definitions," Rick Slaugenhaupt raises some good points about Resource manager implementation. Here's more information to discuss and try to clarify.
In posted comment and question to a prior blog posting, "Revised ISA88 Part 5 definitions," Rick Slaugenhaupt raises some good points about Resource manager implementation. I want to start a dialog about this to make sure we understand each other.
I would agree that there is a certain amount of central supervision to manage coordination among the modules that make up a unit/machine/cell (for example this supervisory function would at the start of any production using a recipe make sure all entities in a cell are in a receptive condition such that the commands of the recipe will be able to be implemented all the way down to the physical equipment).
Placing the responsibility for all the modules in an implementation in this single supervisory function really becomes unwieldy in a large system and I feel is better met by allowing it to be shared through the use of a function such as mentioned in Part 5 as the Resource Manager. The top level supervisory function needs only to interact with the upper tier of modules and those modules in turn understand how to bring its direct subordinates into a receptive condition and so on down to the lowest levels.
I think each module needs to be aware of that modules relationship between all other modules that it must coexist with. In the event that a specific module is going to be directed by an entity other than the “normal” (say the recipe is normal and this other entity is a maintenance person) there needs to be a method that allow all the entities to work together to manage the ownership of a module so these multiple entities don’t cause unintended actions by the module.
Please do not confuse this with a “Shared Resource” as mentioned in ISA88 Part 1. While this Resource management function could be viewed as a method to “arbitrate” shared resources its primary function is to support multiple entity interaction with a module. This also should not be confused with the “Manual/Automatic” modes referred to in ISA88 Part 1, which in Part 5 is currently referred to as the “Mode of Action” and the above mentioned management of entities that issue commands to the module is referred to as the “Mode of Control” in Part 5.
Please note that the names are subject to change based on the feedback of the committee as Part 5 progresses. This resource manager also provides a method to help in managing modules that host multiple operation schemes of which only one can be active in a module at any given time (a new item in Part 1 that is often implemented in practice but has no formal methods to manage it).
All this being said, if someone does not want to implement a system with these features they can indeed create other methods of managing module interaction, as has been done in the past. The Part 5 committee is in the process of describing some traditional approaches currently used in the creation of an automated system and contrasting them to what is being proposed in Part 5. I’ll publish this when it is a little farther along.
David A. Chappell, Complete Manufacturing Automation associates - LLC
Not seeing the comments box? Click here to comment on this, and scroll to the bottom of the page.