Closed PierreREN closed 4 years ago
There is a many-to-many relationship between equipment and equipment type. One of these relationships could be to a HierarchyScopeType. However, there are generally a lot more equipment types than HierarchyScopeTypes. (For example: pump, value, heating unit, conveyor section, ...). I think a better way to look at this, is that that there is a specific EquipmentType hierarchy that is the HierarchyScopeType. So I could identify a production line as a WorkCenter with one relationship, and as a 2 liter bottle filling line as another relationship. Anyway, that is how I think about the relationships.
That makes sense. I have been treating HierarchyScopeType as an analogue to organizaiton trees which are more often used in enterprise applications for dividing the topmost unit into hierarchical minor units to distribute control and management responsibilities. As divided, the logical role hierarchy tree will have no intersection between units at the same level and thus the hierarchy has no cycles inside. And that requires a one-to-many relationship between HierarchyScopeType and HierarchyScopeType. As for EquipmentType, yes, many-to-many relationship among them can lead to a situation where the equipment can be assembled freely and easy for future usage, but will also causes cycles among equipments. Eg1: Equip A is composed of B and C, B composed of D and E, C composed of F and G. No cycles formed, everything is fine and clear. Eg 2: Equip A is composed of B and C, B composed of D and E, C composed of E, F and G. E is referred to both from B and C. As for equipment relationship, there is nothing wrong. As for the hierarchy scope, we need to treat E carefully, as it may cause ambiguity. If we add E to the subordinates of B in the hierarchy scope model, then the ambiguity seem to disappear. Eg 3: Equip A is composed of B and C, B composed of D and E, C composed of F and G, E composed of B and H. Then cycle occurs. This type of cycle shall be avoided in case of infinite loops. Eg 4: Equip A is composed of B and C, B composed of D and E, C composed of F and G, E composed of C and H, F composed of E and I. Then cycle occurs. This type of cycle shall be avoided in case of infinite loops. Eg 5: Equip A is composed of B and C, B composed of D and E, C composed of E, F and G, E composed of H and I, F composed of H and I, G composed of J, I composed of J. No cycle occurs. The equipment relationship can be seen as a directed no-loop graph. However, if we take the hieararchy scope model as A->[B->[H, I], C->[F,->[J] G]] or something else that has arcs formed by unconnected equipments from the equipment graph, confusing hierarchical levels occur immediately. Many-to-many relationship among equipment may introduce flexibility as well as logical conflicts at the same time. I think, maybe it will be better if we redefine the equipment composition relationship as a restricted many-to-many relationship where all equipment shall form a directed no-loop graph to avoid infinite loops conflicts, and the hierarchy scope model as a tree selected from the equipment graph obeying its node and edge constraints. Thus every equipment does not have to be in the hierarchy scope model, but every node in the hierarchy scope model shall be able to fit back into the equipment graph without breaking any existing constraint.
Let me send this to the ISA-95 committee. It sounds like something that should be there. Its not something we can check in B2MML. Thanks Dennis
As HierarchyScopeType has a required attribute "equipmentID", I assume this is a one-to-one relationship between EquipmentType and HierarchyScopeType. But neither IEC62264 nor B2MML declare certainly that every equipment will be added to the role-based equipment hierarchy. This uncertainty has caused a lot of confuses for me, and provides to many possibilities during pratical usage.