This section provides some general infrastructure used for various types of location / contextualization information.

Contains is an abstract ReferenceType as base to point to various types of locations. It is a subtype of 0:HierarchicalReferences.

The semantic of this ReferenceType is to link an Object representing some type of location to Objects (like assets) located in that location.

The SourceNode of References of this type shall be an Object representing a location. This Object should be part of a hierarchy referenced by the 0:Locations Object, directly or indirectly.

The TargetNode of this ReferenceType shall be an Object contained in the location of the SourceNode.

References of this ReferenceType shall always be exposed bidirectional, i.e. navigating from the location and to the location shall be supported.

The Contains is formally defined in Table 51.

Table 49 – Contains definition

Attributes	Value
BrowseName	Contains
InverseName	LocatedIn
Symmetric	False
IsAbstract	True
Description	Links an Object representing some type of location to Objects (like assets) located in that location
References	NodeClass	BrowseName	Comment
Subtype of 0:HierarchicalReferences defined in OPC 10000-5
Conformance Units
AMB Hierarchical Location Objects
AMB Operational Location Objects

OPC UA provides an mechanism to expose the local time of a Server, by the optional Property 0:LocalTime on the 0:Server Object (defined on the 0:ServerType in OPC 10000-5). This Property is also used as optional Event field.

Assets managed by a Server may be in a different time zone than the Server. Therefore, the same Property as on the Server Object should be used to expose the local time of the asset, i.e. a Property with BrowseName 0:LocalTime having the DataType 0:TimeZoneDataType or a subtype.

Servers may set the 0:LocalTime Property to be writable to allow Clients to set the local time of an asset. Servers may provide the 0:LocalTime with a Null Value in case the local time is unknown to the Server and not set by any Client.

In order to provide hierarchical location information, this specification defines two mechanisms, that can be used individual or in combination.

• The hierarchical location Property provides a simple string providing the hierarchical location of an asset. The structure inside the string may expose several levels. How this is exposed, what delimiters are used, etc. is vendor-specific. Examples of such strings are “FactoryA/BuildingC/Floor1” or “Area1-ProcessCell17-Unit4”
• The hierarchical location Objects provide a browsable structure of the hierarchy and simplifies access like getting all assets of one hierarchical location.

In Figure 11, an example is given exposing the hierarchical location by Properties.

Figure 11 – Example of Hierarchical Location using Properties

In Figure 12, an example is given exposing the hierarchical location by Objects. The standardized 0:Locations Object (see 13.3.3.2) is used as entry point.

Figure 12 – Example of Hierarchical Location using Objects

In Figure 13, an example is given combining both approaches.

Figure 13 – Example of Hierarchical Location using Properties and Objects

As shown in the figure, X:Asset0 is referenced by the X:Unit1 of X:Cell4 of X:Area1. The Property HierarchicalLocation provides the same information. As the format of the string is not further defined, it is vendor-specific how to keep both information sources in sync, especially when the Property is writable. Servers may reject Values not represented by Objects or may extend the Locations hierarchy.

Each asset exposing the hierarchical location as Property has a Property with the BrowseName “HierarchicalLocation” (defined in the Namespace of this specification) and the DataType String or a subtype. The structure of the String (e.g. delimiters for different hierarchies) is not further defined in this specification.

Servers may set the HierarchicalLocation Property to be writable to allow Clients to set the hierarchical location of an asset. Servers may provide the HierarchicalLocation with a Null Value or empty string in case the HierarchicalLocation is unknown to the Server and not set by any Client.

In order to expose the hierarchical location as Objects, there is a standardized entry point HierarchicalLocations (see 13.3.3.2). Each Object referenced from the HierarchicalLocations Object with an Organizes Reference or a subtype represents the highest level of a location hierarchy. The ObjectType for those Objects is not further defined, it can be of any ObjectType. Companion specifications might further refine the ObjectType. These Objects may reference other Objects with hierarchical References, exposing deeper level of the hierarchy. The ReferenceType is not further restricted, it is recommended to use the HasComponent ReferenceType. The hierarchy spanned should not contain loops, however, Clients shall not rely on this.

The HierarchicalContains ReferenceType (see 13.3.3.3) is used to relate the contained assets in the corresponding hierarchical location and is excluded from spanning the location hierarchy.

Since the Objects under the HierarchicalLocations Object span a location hierarchy, each asset is only referenced from the deepest level in the hierarchy it belongs to. Implicitly, those assets are also contained from the higher levels in the hierarchy.

The HierarchicalLocations Object is formally defined in Table 50.

Table 50 – HierarchicalLocations definition

Attribute	Value
BrowseName	HierarchicalLocations
Description	Entry point for objects representing the root of a location hierarchy
References	NodeClass	BrowseName	DataType	TypeDefinition
OrganizedBy by the 0:Locations Object defined in OPC 10000-5
0:HasTypeDefinition	ObjectType	0:FolderType
Conformance Units
AMB Hierarchical Location Objects

Objects referenced with an Organizes Reference or a subtype are considered to be the root of a location hierarchy. The HierarchicalLocations Object is the entry point to those root Objects.

HierarchicalContains is a concrete ReferenceType and can be used directly. It is a subtype of Contains.

The semantic of this ReferenceType is to link an Object representing part in a hierarchical location to Objects (like assets) located in that hierarchical location.

The SourceNode of References of this type shall be an Object representing a location. This Object should be part of a hierarchy referenced by the HierarchicalLocations Object, directly or indirectly.

The TargetNode of this ReferenceType shall be an Object contained in the location of the SourceNode.

References of this ReferenceType shall always be exposed bidirectional, i.e. navigating from the location and to the location shall be supported.

The HierarchicalContains is formally defined in Table 51.

Table 51 – HierarchicalContains definition

Attributes	Value
BrowseName	HierarchicalContains
InverseName	HierarchicalLocatedIn
Symmetric	False
IsAbstract	False
Description	Links an Object representing part in a hierarchical location to Objects (like assets) located in that hierarchical location
References	NodeClass	BrowseName	Comment
Subtype of Contains
Conformance Units
AMB Hierarchical Location Objects

In order to provide operational location information, this specification defines two mechanisms, that can be used individual or in combination. Those are the same as for hierarchical locations.

• The operational location Property provides a simple string providing the operational location of an asset. The structure inside the string may expose several levels. How this is exposed, what delimiters are used, etc. is vendor-specific. Examples of such strings are “Warehouse1/Sheet3” or “StainlessSteelTote3”
• The operational location Objects provide a browsable structure of the operational location and simplifies access like getting all assets of one operational location.

In Figure 14, an example is given exposing the operational location by Properties.

Figure 14 – Example of Operational Location using Properties

In Figure 15, an example is given exposing the operational location by Objects. The standardized OperationalLocations Object (see 13.4.3.2) is used as entry point.

Figure 15 – Example of Operational Location using Objects

In Figure 16, an example is given combining both approaches.

Figure 16 – Example of Operational Location using Properties and Objects

As shown in the figure, X:Asset1 is referenced by the X:Shelf1 of X:Warehouse1. The Property OperationalLocation provides the same information. As the format of the string is not further defined, it is vendor-specific how to keep both information sources in sync, especially when the Property is writable. Servers may reject Values not represented by Objects or may extend the hierarchy or operational locations.

Each asset exposing the operational location as Property has a Property with the BrowseName “OperationalLocation” (defined in the Namespace of this specification) and the DataType String or a subtype. The structure of the String (e.g. delimiters for different levels of operational locations) is not further defined in this specification.

Servers may set the OperationalLocation Property to be writable to allow Clients to set the operational location of an asset. Servers may provide the OperationalLocation with a Null Value or empty string in case the OperationalLocation is unknown to the Server and not set by any Client.

In order to expose the hierarchical of operational locations as Objects, there is a standardized entry point OperationalLocations (see 13.4.3.2). Each Object referenced from the OperationalLocations Object with an Organizes Reference or a subtype represents the highest level of a hierarchy of operational locations. The ObjectType for those Objects is not further defined, it can be of any ObjectType. Companion specifications might further refine the ObjectType. These Objects may reference other Objects with hierarchical References, exposing deeper level of the hierarchy. The ReferenceType is not further restricted, it is recommended to use the HasComponent ReferenceType. The hierarchy spanned should not contain loops, however, Clients shall not rely on this.

The OperationalContains ReferenceType (see 13.4.3.3) is used to relate the contained assets in the corresponding location and is excluded from spanning the location hierarchy.

Since the Objects under the OperationalLocations Object span a hierarchy of operational locations, each asset is only referenced from the deepest level in the hierarchy it belongs to. Implicitly, those assets are also contained from the higher levels in the hierarchy.

The OperationalLocations Object is formally defined in Table 52.

Table 52 – OperationalLocations definition

Attribute	Value
BrowseName	OperationalLocations
Description	Entry point for objects representing the root of a hierarchy of operational locations
References	NodeClass	BrowseName	DataType	TypeDefinition
OrganizedBy by the 0:Locations Object defined in OPC 10000-5
0:HasTypeDefinition	ObjectType	0:FolderType
Conformance Units
AMB Operational Location Objects

Objects referenced with an Organizes Reference or a subtype are considered to be the root of a hierarchy of operational locations. The OperationalLocations Object is the entry point to those root Objects.

OperationalContains is a concrete ReferenceType and can be used directly. It is a subtype of Contains.

The semantic of this ReferenceType is to link an Object representing an operational location to Objects (like assets) located in that operational location.

The SourceNode of References of this type shall be an Object representing a location. This Object should be part of a hierarchy referenced by the OperationalLocations Object, directly or indirectly.

The TargetNode of this ReferenceType shall be an Object contained in the location of the SourceNode.

References of this ReferenceType shall always be exposed bidirectional, i.e. navigating from the location and to the location shall be supported.

The OperationalContains is formally defined in Table 53.

Table 53 – OperationalContains definition

Attributes	Value
BrowseName	OperationalContains
InverseName	OperationalLocatedIn
Symmetric	False
IsAbstract	False
Description	Links an Object representing an operational location to Objects (like assets) located in that operational location
References	NodeClass	BrowseName	Comment
Subtype of Contains
Conformance Units
AMB Operational Location Objects

For digital assets like files, it may be desirable to provide the digital location of such assets in form of a reference like a URI.

Each digital asset exposing the digital location has a Property with the BrowseName “DigitalLocation” (defined in the Namespace of this specification) and the DataType String or a subtype. The structure of the String is not further defined in this specification. Servers should use the 0:UriString or a subtype if they expose a URI in order to provide this additional information to the Client.

Servers may set the DigitalLocation Property to be writable to allow Clients to set the digital location of an asset. Servers may provide the DigitalLocation with a Null Value or an empty string in case the digital location is unknown to the Server and not set by any Client.