Hi UA,
I have a process vessel (a unit) which must act as a container for a number of type instances (for eg valve, pump, level transmitter, agitator).
The purpose of the container is to have a couple of properties unique to the vessel and also variable aliases to phase (sequence) instances. This is an ISAS88 implementation
for the pharmaceutical industry.
I originally thought that the unit class should be of object type. However there is no requirement for methods. I note that the OPCUA Green book
mentions view as an alternative to objects. I am considering using a structure datatype that has an array of Node IDs.
What what be the normal recommended implementation in this scenario? (ie a container for instances of different subtypes)
Thank you
Geographical Area Container. Object or structure?
Moderator: Support Team
-
ctgarvey
- Sr. Member
- Posts: 14
- Joined: 17 Mar 2013, 13:27
-
Support Team
- Hero Member
- Posts: 3069
- Joined: 18 Mar 2011, 15:09
Re: Geographical Area Container. Object or structure?
Hi,
Object is the right concept for your use case.
A structure data type would be a hack that can not be handled by generic clients.
A View would be an overkill. Views are normally used to browse subsets of the address space for different use cases.
If your container has no type, you can just use a FolderType object. Folders are used to group other objects independent of their component hierarchy. Folders are also used to provide different entry points into the address space. You just reference the typed objects with Organizes references from the Folder object. You can add Properties to the Folder with HasProperty references. You can reference typed objects from different folders.
If your container has a type (you want to indicate that certain properties are always available (mandatory) or may be available (optional)) but you want to use Organizes references, you can derive your type from FolderType.
If you want to indicate in your type that a certain component or a list of a certain component type is expected you can use the following modelling rules on the components of the type:
- Mandatory - e.g. the container has always on pump with the name PumpA
- Optional - e.g. the container may have a level transmitter with the name Level
- OptionalPlaceholder - e.g. the container may have several valves
- MandatoryPlaceholder - e.g. the container can have a list of valves but has at least one
Best Regards,
Unified Automation Support Team
Object is the right concept for your use case.
A structure data type would be a hack that can not be handled by generic clients.
A View would be an overkill. Views are normally used to browse subsets of the address space for different use cases.
If your container has no type, you can just use a FolderType object. Folders are used to group other objects independent of their component hierarchy. Folders are also used to provide different entry points into the address space. You just reference the typed objects with Organizes references from the Folder object. You can add Properties to the Folder with HasProperty references. You can reference typed objects from different folders.
If your container has a type (you want to indicate that certain properties are always available (mandatory) or may be available (optional)) but you want to use Organizes references, you can derive your type from FolderType.
If you want to indicate in your type that a certain component or a list of a certain component type is expected you can use the following modelling rules on the components of the type:
- Mandatory - e.g. the container has always on pump with the name PumpA
- Optional - e.g. the container may have a level transmitter with the name Level
- OptionalPlaceholder - e.g. the container may have several valves
- MandatoryPlaceholder - e.g. the container can have a list of valves but has at least one
Best Regards,
Unified Automation Support Team