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.

image017.png

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.

image018.png

Figure 15 – Example of Operational Location using Objects

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

image019.png

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 50.

Table 50 – OperationalLocations definition

Attribute

Value

BrowseName

OperationalLocations

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 51.

Table 51 – 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