05/30/2017
What is unclear about the description in the specification?
05/30/2017
HasAddIn allows information modellers to create re-usable components that may belong to many different ObjectTypes.
The main difference from a simple component with a TypeDefinition is the default BrowseName for the AddIn is specified because it has semantic meaning.
In the example in the specification the AddIn has a BrowseName ‘Lock’ that is explicitly specified with the DefaultInstanceBrowseName in the TypeDefinition.
The HasAddIn reference tells clients that the semantics assigned to the BrowseName by the TypeDefinition apply rather than the semantics associated with a new component of MyDeviceType that happens to be named ‘Lock’.
06/02/2020
Ok, I think I got it. Is this to support from the client an easy way to look up Addins of the same type within the model, using this default browse name and filtering, compare to component where you would need explicitly to know the component definition to find a particular object type?
05/30/2017
It is more than just that.
The LockingServicesType ObjectType provides structure and semantics for a Lock Object but it not define what it locks.
The ‘Lock’ AddIn is a LockingServicesType Object which is a lock for its owner.
If the ‘Lock’ BrowseName was not used the target of the Lock would not be defined in the model. Many would assume it locks the parent but one of the objectives of UA is to eliminate the need to guess or assume semantics.
The additional semantics provided by an AddIn is subtle but can be important.
1 Guest(s)