01/11/2017
To create an object in the server, is it mandatory that object type definition having the variable types and other details are present?
Or is it ok to create object instance based on BaseObjectType?
In some cases a client processing the address space , may encounter objects which does not have the exact object type definitions. Some clients may depend on the type definitions to create the corresponding the types in the client system. If the type definition for an object is not present can the client safely say that this is an invalid configuration?
05/30/2017
If a Type Node is referenced by an instance in the Server address space then the Type Node shall be in the Server address space.
However, Object instances that use BaseObjectType as their TypeDefinition are permitted and clients cannot assume that every component of an Object instance is specified by the TypeDefinition even when the TypeDefinition is a subtype of BaseObjectType.
i.e.
Lets say: ObjectTypeY -> { ChildA, ChildB }
then ObjectZ -> {ChildA, ChildB, ChildC } is a valid instance of ObjectTypeY.
01/11/2017
In that case does ObjectZ has a linkage to ObjectTypeY? How can the client find that ObjectZ is of type ObjectTypeY?
If an object instance need not have a type definition then what is the use of the type definitions?
Looks like client has to depend on the object instance instead of types. Am I correct?
Consider the case when ObjectA has definition --> { Child1, Child2} . But the type definition of ObjectA is BaseObjectType. Is this a valid scenario?
05/30/2017
If ObjectZ is a instance of ObjectTypeY then it will have a HasTypeDefinition reference to ObjectTypeY.
If ObjectZ has a HasTypeDefinition to BaseObjectType then it is not an instance of ObjectTypeY.
It is valid for ObjectZ to have a HasTypeDefinition to BaseObjectType, however, it is not recommended when there is a known structure that could be represented with an ObjectType if one was defined.
01/11/2017
In the above example you have given,
Lets say: ObjectTypeY -> { ChildA, ChildB }
then ObjectZ -> {ChildA, ChildB, ChildC } is a valid instance of ObjectTypeY
ObjectZ is a valid type of ObjectTypeY even if it has an additional child which is not in ObjectTypeY .
Even if it is not recommended for objects to derive from BaseObjectType , it is allowed and the object can have child elements.
This makes it difficult for a client which depends on an object type to design the structure of an object in the client system.
Why OPC UA gives this flexibility to create object which is different from its object type?
Now object type only gives an idea on the final object instance and there is no rule as such which says object instance must have the same format as its type considering mandatory and optional parameters.
05/30/2017
UA allows the flexibility because there are lot of places where it is needed.
For example, a Folder Object containing a set of Temperature sensors where the number and name of the Sensors are not known when the type model was being developed.
The flexibility should pose no problem for Clients because Clients programmed against ObjectTypeY should not care that addition instances are present. The Client can ignore extra nodes that it does not understand.
1 Guest(s)