1 Scope

This document defines basic concepts for asset management used in an OPC UA Information Model. It considers different aspects of asset management. Applications do not have to use all or nothing of this specification, but can chose which concepts they want to support. In some cases, this specification just defines how to use concepts of the base OPC UA specifications, in other cases it does define additional OPC UA Nodes (types or standardized instances).

The intention of this specification is to define commonalities on asset management, that can be used as base from other companion specifications which might further refine those concepts for their domain specific needs. However, it is also possible to use this specification directly, without additional companion specifications.

OPC Foundation

OPC is the interoperability standard for the secure and reliable exchange of data and information in the industrial automation space and in other industries. It is platform independent and ensures the seamless flow of information among devices from multiple vendors. The OPC Foundation is responsible for the development and maintenance of this standard.

OPC UA is a platform independent service-oriented architecture that integrates all the functionality of the individual OPC Classic specifications into one extensible framework. This multi-layered approach accomplishes the original design specification goals of:

Platform independence: from an embedded microcontroller to cloud-based infrastructure

Secure: encryption, authentication, authorisation and auditing

Extensible: ability to add new features including transports without affecting existing applications

Comprehensive information modelling capabilities: for defining any model from simple to complex

2 Normative references

The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments and errata) applies.

OPC 10000-1, OPC Unified Architecture - Part 1: Overview and Concepts

OPC 10000-1

OPC 10000-2, OPC Unified Architecture - Part 2: Security Model

OPC 10000-2

OPC 10000-3, OPC Unified Architecture - Part 3: Address Space Model

OPC 10000-3

OPC 10000-4, OPC Unified Architecture - Part 4: Services

OPC 10000-4

OPC 10000-5, OPC Unified Architecture - Part 5: Information Model

OPC 10000-5

OPC 10000-6, OPC Unified Architecture - Part 6: Mappings

OPC 10000-6

OPC 10000-7, OPC Unified Architecture - Part 7: Profiles

OPC 10000-7

OPC 10000-9, OPC Unified Architecture - Part 9: Alarms and Conditions

OPC 10000-9

OPC 10000-11, OPC Unified Architecture - Part 11: Historical Access

OPC 10000-11

OPC 10000-16, OPC Unified Architecture - Part 16: State Machines

OPC 10000-16

OPC 10000-17, OPC Unified Architecture - Part 17: Alias Names

OPC 10000-17

OPC 10000-19, OPC Unified Architecture - Part 19: Dictionary Reference

OPC 10000-19

OPC 10000-23, OPC Unified Architecture - Part 23: Common ReferenceTypes

http://www.opcfoundation.org/UA/Part23/

OPC 10000-100, OPC Unified Architecture - Part 100: Devices

OPC 10000-100

3 Terms, abbreviated terms and conventions

3.1 Overview

It is assumed that basic concepts of OPC UA information modelling and asset management are understood in this document. This document will use these concepts to describe the Asset Management Basics Information Model. For the purposes of this document, the terms and definitions given in OPC 10000-1, OPC 10000-2, OPC 10000-3, OPC 10000-4, OPC 10000-5, OPC 10000-6, OPC 10000-7, OPC 10000-9, OPC 10000-11, OPC 10000-16, OPC 10000-17, OPC 10000-19, OPC 10000-23 and OPC 10000-100 apply.

Note that OPC UA terms and terms defined in this document are italicized in the document.

3.2 Abbreviated terms

3.3 Conventions used in this document

3.3.1 Conventions for Node descriptions

3.3.1.1 Node definitions

Node definitions are specified using tables (see Table 2).

Attributes are defined by providing the Attribute name and a value, or a description of the value.

References are defined by providing the ReferenceType name, the BrowseName of the TargetNode and its NodeClass.

• If the TargetNode is a component of the Node being defined in the table the Attributes of the composed Node are defined in the same row of the table.

• The DataType is only specified for Variables; “[<number>]” indicates a single-dimensional array, for multi-dimensional arrays the expression is repeated for each dimension (e.g. [2][3] for a two-dimensional array). For all arrays the ArrayDimensions is set as identified by <number> values. If no <number> is set, the corresponding dimension is set to 0, indicating an unknown size. If no number is provided at all the ArrayDimensions can be omitted. If no brackets are provided, it identifies a scalar DataType and the ValueRank is set to the corresponding value (see OPC 10000-3). In addition, ArrayDimensions is set to null or is omitted. If it can be Any or ScalarOrOneDimension, the value is put into “{<value>}”, so either “{Any}” or “{ScalarOrOneDimension}” and the ValueRank is set to the corresponding value (see OPC 10000-3) and the ArrayDimensions is set to null or is omitted. Examples are given in Table 1.

• The TypeDefinition is specified for Objects and Variables.

• The TypeDefinition column specifies a symbolic name for a NodeId, i.e. the specified Node points with a HasTypeDefinition Reference to the corresponding Node.

• The ModellingRule of the referenced component is provided by specifying the symbolic name of the rule in the ModellingRule column. In the AddressSpace, the Node shall use a HasModellingRule Reference to point to the corresponding ModellingRule Object.

If the NodeId of a DataType is provided, the symbolic name of the Node representing the DataType shall be used.

Note that if a symbolic name of a different namespace is used, it is prefixed by the NamespaceIndex (see 3.3.2.2).

Nodes of all other NodeClasses cannot be defined in the same table; therefore, only the used ReferenceType, their NodeClass and their BrowseName are specified. A reference to another part of this document points to their definition.

Table 2 illustrates the table. If no components are provided, the DataType, TypeDefinition and Other columns may be omitted and only a Comment column is introduced to point to the Node definition.

Components of Nodes can be complex that is containing components by themselves. The TypeDefinition, NodeClass and DataType can be derived from the type definitions, and the symbolic name can be created as defined in 3.3.3.1. Therefore, those containing components are not explicitly specified; they are implicitly specified by the type definitions.

The Other column defines additional characteristics of the Node. Examples of characteristics that can appear in this column are show in Table 3.

If multiple characteristics are defined they are separated by commas. The name or the short name may be used.

3.3.1.2 Additional References

To provide information about additional References, the format as shown in Table 4 is used.

References can be to any other Node.

3.3.1.3 Additional sub-components

To provide information about sub-components, the format as shown in Table 5 is used.

3.3.1.4 Additional Attribute values

The type definition table provides columns to specify the values for required Node Attributes for InstanceDeclarations. To provide information about additional Attributes, the format as shown in Table 6 is used.

There can be multiple columns to define more than one Attribute.

3.3.2 NodeIds and BrowseNames

3.3.2.1 NodeIds

The NodeIds of all Nodes described in this standard are only symbolic names. Annex A defines the actual NodeIds.

The symbolic name of each Node defined in this document is its BrowseName, or, when it is part of another Node, the BrowseName of the other Node, a “.”, and the BrowseName of itself. In this case “part of” means that the whole has a HasProperty or HasComponent Reference to its part. Since all Nodes not being part of another Node have a unique name in this document, the symbolic name is unique.

The NamespaceUri for all NodeIds defined in this document is defined in Annex A. The NamespaceIndex for this NamespaceUri is vendor-specific and depends on the position of the NamespaceUri in the server namespace table.

Note that this document not only defines concrete Nodes, but also requires that some Nodes shall be generated, for example one for each Session running on the Server. The NodeIds of those Nodes are Server-specific, including the namespace. But the NamespaceIndex of those Nodes cannot be the NamespaceIndex used for the Nodes defined in this document, because they are not defined by this document but generated by the Server.

3.3.2.2 BrowseNames

The text part of the BrowseNames for all Nodes defined in this document is specified in the tables defining the Nodes. The NamespaceUri for all BrowseNames defined in this document is defined in 16.2.

For InstanceDeclarations of NodeClass Object and Variable that are placeholders (OptionalPlaceholder and MandatoryPlaceholder ModellingRule), the BrowseName and the DisplayName are enclosed in angle brackets (<>) as recommended in OPC 10000-3. If the BrowseName is not defined by this document, a namespace index prefix is added to the BrowseName (e.g., prefix '0' leading to ‘0:EngineeringUnits’ or prefix '2' leading to ‘2:DeviceRevision’). This is typically necessary if a Property of another specification is overwritten or used in the OPC UA types defined in this document. Table 60 provides a list of namespaces and their indexes as used in this document.

3.3.3 Common Attributes

3.3.3.1 General

The Attributes of Nodes, their DataTypes and descriptions are defined in OPC 10000-3. Attributes not marked as optional are mandatory and shall be provided by a Server. The following tables define if the Attribute value is defined by this document or if it is server-specific.

For all Nodes specified in this document, the Attributes named in Table 7 shall be set as specified in the table.

3.3.3.2 Objects

For all Objects specified in this document, the Attributes named in Table 8 shall be set as specified in the Table 8. The definitions for the Attributes can be found in OPC 10000-3.

3.3.3.3 Variables

For all Variables specified in this document, the Attributes named in Table 9 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

3.3.3.4 VariableTypes

For all VariableTypes specified in this document, the Attributes named in Table 10 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

3.3.3.5 Methods

For all Methods specified in this document, the Attributes named in Table 11 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

4 Introduction to Asset Management

Asset management is a huge topic with many different facets. In this specification, the topic is intentionally rather left open, and for example, this specification does not define what is considered to be an asset. The intention of this specification is to define basic information modelling constructs that can be used and refined by companion specifications to domain-specific needs.

The specification does define specific use cases like the identification and discovery of assets, the access of the health status of assets, and the classification of assets. Section 5 describes those use cases addressed by this specification in more detail.

5 Use cases

5.1 Overview

The following sections describe use cases addressed in this version of the specification.

5.2 Identification of Asset (UC001)

5.3 Discovery of Assets (UC002)

5.4 Technical Specification: Skills / Capabilities (UC003-1)

5.5 Technical Specification: Requirements (UC003-2)

5.6 Technical Specification: Version information (UC003-3)

5.7 Health Status (UC004)

5.8 Health Status: Health Categories (UC004-1)

5.9 Health Status: Specific Health Conditions (UC004-2)

5.10 Health Status: Tracking of Health Information (UC004-3)

5.11 Maintenance: Log of maintenance activities (UC005-2)

5.12 Location/Contextualisation: Hierarchical Location (UC007-3)

5.13 Location/Contextualisation: Time/Local Time Location (UC007-4)

5.14 Location/Contextualisation: Digital Location (UC007-6)

5.15 Location/Contextualisation: Operational Location (UC007-7)

5.16 Structure of Assets: Identifying the Structure of Assets (UC008-1)

5.17 Asset Classification (UC009)

6 Asset Management Basics Information Model overview

6.1 General

This specification defines base functionality for asset management to fulfil the use cases described in section 5. It is intended to be a base specification, that can be extended by domain-specific companion specifications and vendor-specific information models. Therefore, this specification does not define, what an asset is. It can be, for example, a piece of hardware like actuators, sensors, PLCs, network equipment, or software, like a PLC program or firmware. It can contain an OPC UA Server providing the information model, like on a field device or PLC, or it can be some passive component like a calibration target, gear, or pipe. In general, it can be anything that is worth to be manged by an asset management system.

This specification defines general concepts how to manage the assets, so that a Client can manage those assets, independent of the type of asset. The information model is built in a modular way, defining concepts for the different use cases, that can be used independent of each other. The ConformanceUnits defined in section 15.1 reflect those individual functionalities. As not all concepts are independent of each other, for example the identification of an asset is needed in most cases, the Profiles defined in section 15.2 combine the ConformanceUnits to functionality that is required to be provided together.

6.2 Where to apply the Asset Management Basics Information Model?

This specification defines an Information Model to represent one or several assets. It does not define, where the Information Model should be deployed. In some cases, the asset itself might provide a Server, and this Server might provide asset management related information about the asset as defined in this specification. Other assets might not have any electronics and no capability to even run a Server, and any Server providing information about the asset is running outside the asset.

Independent of that, even if the asset provides a Server, not all asset management related information has to be provided by that Server, and some information might be provided by some higher-level system potentially aggregating the information of many assets. For example, the information when the next maintenance activity is planned might not be known by the asset but only by some higher-level asset management systems.

7 Identification of Asset

For the identification of an asset, this specification mainly uses Properties defined in OPC 10000-100. In order to support already released companion specifications and products as well as the different options provided by OPC 10000-100, this specification does not define or require a specific ObjectType or Interface, but ConformanceUnits and Profiles referencing mandatory and optional Properties as defined in OPC 10000-100.

The Properties defined in OPC 10000-100 for identification can either be implemented directly on the Object representing the asset, or in a grouping Object called 2:Identification, also defined in OPC 10000-100.

This leads to the following options, as shown in Figure 1:

Usage of 2:ComponentType or 2:DeviceType. An Object representing an asset can have the TypeDefinition 2:ComponentType, 2:DeviceType, or a subtype of one of those ObjectTypes and thus containing the identification Properties defined in OPC 10000-100.

Usage of 2:IVendorNameplateType and 2:ITagNameplateType. An Object representing an asset can either directly implement those interfaces, or has a TypeDefinition directly or indirectly implementing the interfaces.

Usage of 2:Identification Object. An Object representing an asset provides the 2:Identification Object, and the 2:Identification Object provides the Properties, either by implementing the 2:IVendorNameplateType and 2:ITagNameplateType or by just providing the Properties.

The 2:Identification Object shall have the BrowseName 2:Identification and shall be referenced with a hierarchical Reference from the Object representing an asset. The ObjectType of the 2:Identification Object shall be 2:FunctionalGroupType or a subtype of 2:FunctionalGroupType.

The preferred and recommended approach is to use the 2:Identification Object. However, Clients shall be aware of the other approaches and consider those for the identification of an asset as well.

OPC 10000-100 defines most of the Properties as mandatory on the 2:DeviceType, with default values when the value cannot be provided. The 2:ComponentType and the Interfaces define the Properties as optional, i.e., they should be omitted when the information cannot be provided. The preferred and recommended approach is to omit Properties if the information is not available. However, Clients shall be aware that there are default values and shall consider those.

In order to allow a globally unique identification of an asset, the 2:ProductInstanceUri shall be provided (see ConformanceUnit AMB Asset Identification in 15.1). It shall be either a Property of the Object representing the asset or referenced with a hierarchical Reference from the 2:Identification Object. The Property value shall not be an empty String.

All other Properties of 2:IVendorNameplateType should be provided if the information is available. Other companion specifications will define additional, domain-specific identification information and vendors may add information as well. This additional information should preferably be put on the 2:Identification Object. A specialisation of 2:IVendorNameplateType can also be used to identify this additional information is identification information.

If the 2:AssetId of the 2:ITagNameplateType is provided it shall be writable to allow a configurable identification of the asset (see ConformanceUnit AMB Configurable Asset Identification in 15.1). Other Properties of 2:ITagNameplateType and additional configurable Properties may be provided as well.

Older versions of OPC 10000-100 did not define the 2:IVendorNameplateType and 2:ITagNameplateType and thus Clients shall not expect that the 2:IVendorNameplateType and 2:ITagNameplateType are explicitly implemented on the TypeDefinition.

8 Discovery of Assets

8.1 Overview

For the discovery of assets, this specification uses the concept of AliasNames, as defined in OPC 10000-17. AliasNames define an additional name for any Node of a Server and can be used to categorize AliasNames and provide filter functionality on the AliasNames. The same AliasName can be represented by several Nodes, for example, if managed in different Servers. Using AliasNames simplifies managing information from various Servers, where some Servers potentially are not aware of AliasNames. AliasNames defines a concept how to integrate AliasNames into a Global Discovery Server (GDS). AliasNames already define the usage of NodeVersion and ModelChangeEvents to get notification on changes, which is used in this specification as well.

Unlike other usages of AliasNames, in this specification the purpose is not to define additional names for a Node / asset, but use the provided information of the assets.

That is, this specification defines two standardized categories for AliasNames, one using the mandatory 2:ProductInstanceUri as AliasName, and another one using the writable 2:AssetId, which can be set by the user.

In Figure 2, an example of the usage of AliasNames is given, to discover assets in a Server. This specification defines the standardized Nodes Assets, AssetsByProductInstanceUri and AssetsByAssetId (see 8.2). In order to discover the assets, a Client would either browse AssetsByProductInstanceUri or AssetsByAssetId to receive the AliasNames representing the assets, and from there with another browse access the Nodes representing the assets. Or it would call the Method 0:FindAlias on one of the Objects, allowing potentially to filter for the 2:ProductInstanceUri or the 2:AssetId. To get notified if assets have been added or removed, the Client subscribes to the 0:NodeVersion Property or subscribes to ModelChangeEvents.

As shown in the example in Figure 2, the Server manages three assets, X:Asset0, X:Asset1 and X:Asset2, somehow arranged in the vendor-specific hierarchy of the Servers AddressSpace. For all three assets, an AliasName Object for the 2:ProductInstanceUri exists. As X:Asset0 does not support the 2:AssetId, AliasName Objects for the 2:AssetId only exist for X:Asset1 and X:Asset2. Each AliasName is based on the identification information of the asset.

Note that a Server might not provide both entry points, depending on the supported ConformanceUnits.

Note that an AliasName could point to several Nodes representing the same asset (not shown in the example). The returned structure of 0:FindAlias allows to return several Nodes for one AliasName (see OPC 10000-17).

Note that the concept also allows for Off-Server References, for the 0:AliasFor References as well as for the 0:FindAlias Method (not shown in the example).

8.2 Instances

8.2.1 Assets

The Assets Object is formally defined in Table 12.

8.2.2 AssetsByProductInstanceUri

The AssetsByProductInstanceUri Object is formally defined in Table 12. All AliasNames organized by this category shall be assets having a 2:ProductInstanceUri (see section 7). The string part of the AliasName shall be identical to the value of the 2:ProductInstanceUri, the namespace of the AliasName shall be the one defined by this specification in section 16.

8.2.3 AssetsByAssetId

The AssetsByAssetId Object is formally defined in Table 12. All AliasNames organized by this category shall be assets having a 2:AssetId (see section 7). The string part of the AliasName shall be identical to the value of the 2:AssetId, if the value of 2:AssetId is not an empty or null String. The namespace of the AliasName shall be the one defined by this specification in section 16.

As the default value of the 2:AssetId is an empty String, in a system where the 2:AssetId is not configured, many assets will have the identical 2:AssetId (empty String). In this case, each individual asset should have its own AliasName Object and all of those assets should not use the same AliasName Object. Same assets shall be, in this case, identified by the 2:ProductInstanceUri. In this case, the string part of the AliasName shall be “NoAssetIdAssigned” and the namespace of the AliasName shall be the one defined by this specification in section 16.

Note: Ideally, 2:AssetIds should be unique and two assets with different 2:ProductInstanceUris should have different 2:AssetIds. Also, if an asset is represented by more than one asset Node, meaning several asset Nodes have the same 2:ProductInstanceUri, the same 2:AssetId should be used. As the 2:AssetId is set by the user, this might not be the case. Assigning AliasNames in the context of this Object is done by 2:AssetId. The 2:ProductInstanceUri should only be considered when the 2:AssetId is empty (default value). Therefore, browsing and filtering is also done based on the 2:AssetId, not the 2:ProductInstanceUri.

9 Health Status

9.1 Overview

In order to provide the health status of assets, this specification mainly uses the concepts defined in OPC 10000-100.

9.2 Overall health status of an asset

The Variable 2:DeviceHealth defined in OPC 10000-100 is used to provide the overall health status of an asset. It uses an enumeration having the values NORMAL, FAILURE, CHECK_FUNCTION, OFF_SPEC and MAINTENANCE_REQUIRED (see OPC 10000-100 for details).

Note that this Variable should be used for all assets, independent of what type of asset it is, for example also for software components. For some types of assets, not all values of the enumeration can reasonably be applied.

OPC 10000-100 defines the interface 2:IDeviceHealthType containing optionally the Variable 2:DeviceHealth. In older versions of OPC 10000-100 the Variable was only defined on the 2:DeviceType.

In order to support older versions of OPC 10000-100, Objects representing an asset and providing health status information shall provide the 2:DeviceHealth Variable. This should be achieved by implementing the 2:IDeviceHealthType interface providing optionally the 2:DeviceHealth Variable. This can be done either directly on the instance (X:Asset1) or via the TypeDefinition (X:Asset2), as shown in Figure 3. However, it is also allowed to just provide the 2:DeviceHealth Variable as done by X:Asset3 by using the 2:DeviceType. Note that in the current version of OPC 10000-100 2:DeviceType does implement 2:IDeviceHealthType.

The SourceTimestamp of the 2:DeviceHealth Variable provides the time when the asset entered that health status. In order to provide an accurate time, Servers should preserve the time, also when restarting the Server. As this might not always be possible, a Client shall be aware that the SourceTimestamp is not always the time when the asset switched the health status.

9.3 Asset specific information on health status

To provide asset specific information on failure or maintenance conditions the alarming mechanism of OPC UA is used. The 2:IDeviceHealthType already defines the optional 2:DeviceHealthAlarms folder, where such alarm Objects can be provided. However, it is not required to provide the folder and the alarm Objects in the AddressSpace. Servers should use the AlarmTypes defined in OPC 10000-100 (2:DeviceHealthDiagnosticsAlarmType and subtypes) to expose the asset specific information. The event fields shall be used as defined in OPC 10000-5 and OPC 10000-9. The 0:SourceNode and 0:SourceName shall identify the asset. The 0:Severity should be used as defined in Table 15. Applications may refine those categories to a more detailed categorisation.

9.4 Root cause of asset specific information on health status

9.4.1 Overview

An asset might have several reasons why it’s not operating as expected, which often are dependent on each other. For example, the asset MyMachine might indicate the faults that a pump is not working and the oil pressure is too low. The second fault is caused by the first fault. To manage assets, it is desirable to identify the root causes of failures. In order to provide the root cause of why an asset is not operating as expected, the interface IRootCauseIndicationType is defined (see 9.4.2). Servers providing this information shall use AlarmTypes implementing this interface for alarms indicating asset specific information on failures.

9.4.2 IRootCauseIndicationType

The IRootCauseIndicationType is an interface and should be applied to AlarmTypes. It is formally defined in Table 16.

Note: The IRootCauseIndicationType cannot only be applied to AlarmTypes, but in general to subtypes of 0:ConditionType.

The mandatory Property PotentialRootCauses contains an array of potential root causes of the alarm. This is intended to be a hint to the client and might be a local view on the potential root causes of the alarm. The list might not contain all potential root causes, that is, other potential root causes might exist as well. If the alarm itself is considered to be the root cause, the array shall be empty. If no potential root causes have been identified, there shall be at least one entry in the array indicating that the root cause is unknown.

The child Nodes of the IRootCauseIndicationType have additional Attribute values defined in Table 17.

9.4.3 RootCauseDataType

This structure contains information about the root cause of an alarm. The structure is defined in Table 18.

Its representation in the AddressSpace is defined in Table 19.

9.5 Standardized categories of asset specific information on health status

9.5.1 Overview

Although the alarming mechanism of OPC UA is used to indicate asset specific information on the health status, there are common indications of alarms across assets. To standardize the common indications, and leave options for extensibility by companion specifications and vendors, this specification uses the mechanism of the ConditionClassId defined for conditions in OPC 10000-9. In the following, specific subtypes of BaseConditionClassType are defined that should be used as ConditionClassId for specific alarms. Other companion specifications and vendors might add additional subtypes of BaseConditionClassType and might inherit from the types defined in this specification.

9.5.2 ConnectionFailureConditionClassType

The ConnectionFailureConditionClassType is used to classify conditions related to connection failures. It is formally defined in Table 20.

9.5.3 OverTemperatureConditionClassType

The OverTemperatureConditionClassType is used to classify conditions related to over temperature. It is formally defined in Table 21.

9.5.4 CalibrationDueConditionClassType

The CalibrationDueConditionClassType is used to classify conditions related to calibration being due. It is formally defined in Table 22.

9.5.5 SelfTestFailureConditionClassType

The SelfTestFailureConditionClassType is used to classify conditions related to self-test failures. It is formally defined in Table 23.

9.5.6 FlashUpdateInProgressConditionClassType

The FlashUpdateInProgressConditionClassType is used to classify conditions related to flash updates being in progress. It is formally defined in Table 24.

9.5.7 FlashUpdateFailedConditionClassType

The FlashUpdateFailedConditionClassType is used to classify conditions related to flash update failures. It is formally defined in Table 25.

9.5.8 BadConfigurationConditionClassType

The ConfigurationIsBadConditionClassType is used to classify conditions related to configurations being bad. It is formally defined in Table 26.

9.5.9 OutOfResourcesConditionClassType

The OutOfResourcesConditionClassType is used to classify conditions related to running out of resources. It is formally defined in Table 27.

9.5.10 OutOfMemoryConditionClassType

The OutOfMemoryConditionClassType is used to classify conditions related to running out of memory. It is formally defined in Table 28.

9.6 Tracking of health information

When the Server wants to provide the overall health status of an asset over time, the history of the 2:DeviceHealth Variable shall be used. For each 2:DeviceHealth Variable, where the history is currently tracked, the Historizing Attribute is set to True and the AccessLevel is set to HistoryRead. In order to provide the information, when history tracking started, a HistoryDataConfiguration is referenced with a HasHistoricalConfiguration Reference (see OPC 10000-11 for details).

When the Server wants to provide information for tracking the alarms with detailed health information of an asset over time, the history of the events based on the alarms shall be used. . This specification does not define which Objects are used as EventNotifier. As defined in the base specification, the Server Object shall be an EventNotifier when events are supported, which can be used to subscribe to all events of the Server. It is, therefore, server-specific where the history of events can be accessed and what details of the events are stored. The general concepts are defined in OPC 10000-11. The server should provide for each asset the history of events for the same amount of time as the history of the 2:DeviceHealth.

10 Technical Specification

10.1 Overview

The use cases for technical specifications consider different information on the assets. Some, like standard error messages, are already defined in other sections of this document and not considered further. This section is divided into subsections addressing the different information aspects.

10.2 Version Information

The version information of an asset can consist of different information like the hardware version, potentially a software version when the asset is or contains software, and a revision counter. Those Properties are already defined in OPC 10000-100, at the same level where the identification is defined. Therefore, this specification uses those Properties as defined in OPC 10000-100. They can be deployed in the same way as the identification information as defined in section 7.

Those Properties include:

HardwareRevision providing the revision level of the hardware

SoftwareRevision providing the revision level of the software

RevisionCounter providing an incremental counter when the configuration of the asset has changed

For the usage of those Properties, different cases need to be distinguished.

The asset is software without hardware. In this case, only the SoftwareRevision is provided, and the HardwareRevision is omitted.

The asset is hardware without software. In this case, only the HardwareRevision is provided, and the SoftwareRevision is omitted.

The asset is a combination of hard- and software. In this case, the following model approaches can be done

Represent asset as one Object: The asset provides the HardwareRevision and SoftwareRevision

Represent software as sub-assets of hardware Object. This modelling approach makes specifically sense, if the software of the asset is not considered as one monolithic piece of software, but consists for example of firmware, drivers, applications, etc. In this case, the hardware is the main asset and the software components sub-assets. The main asset might contain a SoftwareRevision which contains the overall revision of all software assets.

In Figure 4, examples for the different cases are shown. In the example, always the Identification Object is used for grouping. The HardwareAsset only provides the HardwareRevision, the SoftwareAsset only the SoftwareRevision. The HardwareAndSoftwareAsset combines both and provides HardwareRevision and SoftwareRevision. The HardwareAndSoftwareAssetWithSubAssets does provide a HardwareRevision and an overall SoftwareRevision, and two sub-assets representing software assets, each containing a SoftwareRevision.

In order to provide patch information about the software components, OPC 10000-100 defines the SoftwareVersionType. This is used for updating software via the OPC UA interface, using the SoftwareUpdate AddIn. In case the Server supports the AddIn for the asset, the SoftwareVersionType shall be used as defined in OPC 10000-100 to provide the patch information. In case, the Server does not support the AddIn for the asset, the Property 2:PatchIdentifiers should be provided on the same level as SoftwareRevision with the same semantic as defined on the SoftwareVersionType.

10.3 Operation Counters

When an asset is operating, several numbers might be of interest when managing the asset, like the hours of operation, hours in standby, etc. Those are often the base to calculate KPIs (key performance indicators) like the OEE (overall equipment efficiency). As this specification is just a base specification for asset management, and the counters are domain specific, this specification does not define any of those counters. It just defines a standardized way to find those counters. Other companion specifications or vendors might define those counters.

In order to provide access to the counters, the concept of a FunctionalGroup as defined in OPC 10000-100 is used. This specification just defines to use the standardized name “2:OperationCounters”. Servers might provide the counters using different access paths, but they should provide the 2:OperationCounters FunctionalGroup as well. This FunctionalGroup might be organized into other FunctionalGroups, so Clients shall expect that they need to browse several hops to get to all counters. In Figure 5, an example is given.

10.4 Supported OPC UA Functionality

If an asset supports Server functionality directly, it means that it does support the standardized Server Object defined in OPC 10000-5. This Object can contain information about the supported OPC UA functionality in the ServerCapabilites Object, like the supported OPC UA Profiles in the ServerProfileArray. The corresponding ConformanceUnit is already defined in OPC 10000-7. Therefore, this specification does not further address this topic.

10.5 Link to Digital Records

10.5.1 Overview

To provide links to digital records, the ObjectType DocumentationLinksType is introduced, which is deployed as AddIn on Objects representing assets. The AddIn serves as entry point to Variables linking to digital records managed outside the Server. The Variable contains a URI, which is typically a URL. Vendors might add additional Properties defining meta data of the linked document, e.g. type of file or size. In addition, it optionally provides the capabilities to add and remove editable links to user-defined documents like operator’s handbooks.

In Figure 6, an example of using the DocumentationLinks AddIn is given.

Instead of providing the optional Methods to add and remove links, a server not capable of the dynamics in its AddressSpace might also just provide some writable Variables that the user can edit and thus manage its links.

10.5.2 DocumentationLinksType

The DocumentationLinksType is an AddIn and should be applied to Objects or ObjectTypes representing Assets. It is formally defined in Table 29.

The Property 0:DefaultInstanceBrowseName defines the default BrowseName of instances of this ObjectType.

The <Link> Variable represents links provided by instances of this type.

The components of the DocumentationLinksType have additional Attributes defined in Table 30.

10.5.3 AddLink Method

This Method provides the capability to persistently add a link to an externally managed resource by adding a Variable according to the input arguments with a HasComponent Reference to the Object the Method is called on. The server shall manage the added link persistently, i.e., if the Method was executed successful, the Variable representing the link shall be persistent and available after restart of the Server. It might disappear after resetting or reconfiguring the Server or after calling the RemoveLink Method. The Value Attribute of the created Node should be writable, so the end-user can change the URI. In addition, the BrowseName, DisplayName, and Description might be writable. Servers might restrict the execution of this Method as well as writing the Attributes to specific users / roles.

The signature of this Method is specified below. Table 31 and Table 32 specify the Arguments and AddressSpace representation, respectively.

Signature

	AddLink (
	  [in]  0:UriString       LinkToExternalSource,
	  [in]  0:QualifiedName   BrowseName,
	  [in]  0:LocalizedText   DisplayName,
	  [in]  0:LocalizedText   Description,
	  [out] 0:NodeId          LinkVariable);

Method Result Codes (defined in Call Service)

10.5.4 RemoveLink Method

This Method provides the capability to remove a Variable representing a link. The Method shall only succeed when the Variable to be deleted is referenced from the Object the Method is called on. Servers might restrict the execution of this Method to specific users / roles. Servers will typically reject the deletion of Nodes not added with the AddLink Method.

The signature of this Method is specified below. Table 33 and Table 34 specify the Arguments and AddressSpace representation, respectively.

Signature

	RemoveLink (
	  [in]  0:NodeId       VariableToBeDeleted
	);

Method Result Codes (defined in Call Service)

10.6 Requirements

When operating an asset, certain requirements need to be fulfilled. This may include, that certain things need to be provided to the asset like pressure or electricity with a specific voltage and current. This may also include specific environmental conditions like a minimum and maximum temperature, air pressure and humidity and the weight and dimensions of the asset the environment need to support.

This specification does not define specific types of requirements. Other specifications, like IEC Common Data Dictionary or ECLASS do define those. This specification defines a standardized place to expose the requirements. It is recommended to use dictionary references, as defined in OPC 10000-19, to reference external dictionaries like IEC Common Data Dictionary or ECLASS to define the semantic of the specific requirements.

In order to provide access to the requirements, the concept of a Folder as defined in OPC 10000-5 is used. This specification just defines the use of the standardized BrowseName “Requirements” (defined in the Namespace of this specification). Servers might provide the requirements using different access paths, but they should provide the Requirements Folder as well. This Folder might be organized into other Folders, so Clients shall expect that they need to browse several hops to get to all requirements. In Figure 7, an example is given, also pointing with dictionary references to an external dictionary (ECLASS).

10.7 Capabilities

Assets provide skills / capabilities. It is desirable to describe, what capabilities the asset supports to select the right asset for the right purpose. Depending on the asset, the capabilities can be very different. A temperature sensor has the capability to measure the temperature, whereas an injection moulding machine can produce parts, and the parts depend on the configuration of the machine.

This specification does not define specific types of capabilities. Other specifications, like IEC Common Data Dictionary or ECLASS define common capabilities. Application-specific capabilities, like producing application-specific parts, are related to describing those parts in recipes, jobs or programs. It is expected, that other specifications, dealing with those, may define concepts for those application-specific capabilities.

This specification defines a standardized place where to expose the capabilities. For common capabilities, it is recommended to use dictionary references, as defined in OPC 10000-19, to reference external dictionaries like IEC Common Data Dictionary or ECLASS.

In order to provide access to the capabilities, the concept of a Folder as defined in OPC 10000-5 is used. This specification just defines the use of the standardized BrowseName “Capabilities” (defined in the Namespace of this specification). Servers might provide the capabilities using different access paths, but they should provide the Capabilities Folder as well. This Folder might be organized into other Folders, so Clients shall expect that they need to browse several hops to get to all capabilities. In Figure 8, an example is given, also pointing with dictionary references to an external dictionary (ECLASS).

11 Asset Classification

For the classification of assets, this specification uses dictionary references, as defined in OPC 10000-19. Dictionary references allow to reference external dictionaries like IEC Common Data Dictionary or ECLASS. This can be used to classify the assets according to those external dictionaries. In Figure 9, an example is given. There are two different classification schemas: “SomeClassification” and “OtherClassification”, the first one using IRDIs and the second URIs. In the example, two of the assets, Asset1 and Asset2, use both classification schemas, one classifying as flow transmitter, and the other as field device. The third asset, Asset3, only uses the second classification schema and classifies as machine. The concept of dictionary references allows to expose many classification schemes, all managed under the standardized Dictionaries Object of the Server Object.

This specification does not further define what external dictionaries should be used for classification. Companion specifications may suggest or mandate specific external dictionaries for specific types of assets.

12 Log of Maintenance Activities

12.1 Overview

To provide information about the maintenance of an asset, the alarming mechanism of OPC UA is used. This allows providing information on upcoming or not executed maintenance activities by making the conditions representing the upcoming maintenance activity active. Even if the maintenance activity has not been executed (planned or in execution), the information can already be provided to the Client. In this case, the 0:Retain Property of the condition shall be set to true, allowing Clients to access the information.

Using the alarming mechanism of OPC UA also allows providing information about past maintenance activities by providing access to the history of Events for those maintenance activities.

The conditions representing maintenance activities might be represented as Objects in the AddressSpace, however, this is not required. If they are provided, it is recommended to use the 2:DeviceHealthAlarms folder defined in 2:IDeviceHealthType as container for those Objects.

This specification does not define a specific 0:ConditionType for maintenance activities. Companion specifications or vendors might define their own 0:ConditionTypes for specific types of maintenance activities. It is recommended to create those as subtypes of 2:MaintenanceRequiredAlarmType defined in OPC 10000-100.

To allow clients to easily identify or filter for maintenance activities, the 0:ConditionClassId is used as defined for conditions in OPC 10000-9. Maintenance activities shall use the 0:MaintenanceConditionClassType or a subtype as 0:ConditionClassId. In 12.4, specific 0:ConditionClassIds are defined. Companion specifications or vendors might create subtypes of 0:MaintenanceConditionClassType or its subtypes for a more detailed classification.

The maintenance activities should provide specific information. This specification defines an interface (see 12.2) that should be implemented by all ConditionTypes used as maintenance activities.

For a recurring maintenance activity it is recommended to use one condition and change the state of the condition to the next planned occurrence of the maintenance activity once the maintenance activity has taken place.

When the execution of a maintenance activity fails (e.g., the correct part to exchange is not available) the message field of the event should be used to indicate the failure. The event may be extended with additional event fields for more specific information. However, this specification does not define more specific event fields for this case.

12.2 IMaintenanceEventType

The IMaintenanceEventType is an interface and should be applied to 0:ConditionTypes. It is formally defined in Table 35.

The MaintenanceState provides the information if the maintenance activity is still planned, currently in execution, or has already been executed.

The PlannedDate provides the date for which the maintenance activity has been scheduled. In case of replanning, it is allowed to change the PlannedDate. However, it is not the intention that the PlannedDate is modified because the maintenance activity starts to get executed. If the PlannedDate depends for example on the operation hours of the asset, it might get adapted depending on the passed operation hours.

The EstimatedDowntime provides the estimated time the execution of the maintenance activity will take. In case of replanning, it is allowed to change the EstimatedDowntime. If during the execution of the maintenance activity the EstimatedDowntime can be adjusted (e.g., the asset needs to be repaired because an inspection found some issues) this should be done. Clients can access the history of Events to receive the information on the original estimates when the maintenance activity started.

The MaintenanceSupplier provides information on the supplier that is planned to execute, currently executing or has executed the maintenance activity. The content may change during the different MaintenanceStates. By accessing the history of Events a Client can distinguish between the planned and actual supplier that executed the maintenance activity. The value contains always a human-readable name of the supplier and optionally references a Node representing the supplier in the AddressSpace.

The QualificationOfPersonnel provides information on the qualification of the personnel that is planned to execute, currently executing or has executed the maintenance activity. The content may change during the different MaintenanceStates. By accessing the history of Events a Client can distinguish between the planned and actual qualification of the personnel that executed the maintenance activity. The value contains always a human-readable name of the qualification of the personnel and optionally references a Node representing the qualification of the personnel in the AddressSpace.

The PartsOfAssetReplaced provides information on the parts of the assets that are planned to be replaced during the maintenance activity, currently in replacement or have been replaced, depending on the different MaintenanceStates. The content may change during the different MaintenanceStates. By accessing the history of Events a Client can distinguish between the planned and actual parts of the assets replaced during the maintenance activity. The value contains always an array of a human-readable name of the qualification of the parts of the asset to be replaced and optionally references a Node representing each part of the asset in the AddressSpace.

The PartsOfAssetServiced provides information on the parts of the assets that are planned to be serviced during the maintenance activity, currently serviced or have been serviced, depending on the different MaintenanceStates. The content may change during the different MaintenanceStates. By accessing the history of Events a Client can distinguish between the planned and actual parts of the assets serviced during the maintenance activity. The value contains always an array of a human-readable name of the qualification of the parts of the asset to be serviced and optionally references a Node representing the part of the asset in the AddressSpace.

The MaintenanceMethod provides information about the planned or used maintenance method. The content may change during the different MaintenanceStates. By accessing the history of Events a Client can distinguish between the planned and actual used maintenance method during the maintenance activity.

The ConfigurationChanged provides information if the configuration of the asset is planned to be changed or has changed during the maintenance activity. FALSE indicates no change, and TRUE indicates a change. The content may change during the different MaintenanceStates. By accessing the history of Events a Client can distinguish between the planned and actual configuration changes during the maintenance activity.

The description of the maintenance activity should be put into the Message field defined for the BaseEventType in OPC 10000-5.

The maintenance activity starts, when the MaintenanceState changes to Execution, and finished, when it changes to Finished. Clients can use this information to identify the overall duration the maintenance took place.

Servers might change the Severity or other Event Fields as well as the state of the conditions when a maintenance activity becomes nearer to its due date in order notify Clients with an Event notification.

The child Nodes of the IMaintenanceEventType have additional Attribute values defined in Table 36.

12.3 MaintenanceEventStateMachineType

The MaintenanceEventStateMachineType provides information, whether a maintenance activity is planned, currently in execution, or has been executed. A state machine diagram is shown in Figure 10. This specification does not define any effects or actions of the MaintenanceEventStateMachineType, the execution of the StateMachine is server-specific. The Transitions go from Planned to Executing to Finished. In case or repeating maintenance activities, the StateMachine might go back from Finished to Planned for another cycle. The ObjectType and is formally defined in Table 37.

The components of the MaintenanceEventStateMachineType have additional References which are defined in Table 38.

The components of the MaintenanceEventStateMachineType have additional Attributes defined in Table 39.

12.4 Standardized categories of Maintenance Activities

12.4.1 Overview

Maintenance activities can be classified into different categories. This specification uses the mechanism of the ConditionClassId defined for conditions in OPC 10000-9, for such a classification of maintenance activities. In the following, specific subtypes of MaintenanceConditionClassType are defined, that should be used as ConditionClassId for specific maintenance activities. Other companion specifications and vendors might add additional subtypes of MaintenanceConditionClassType and might inherit from the types defined in this specification.

12.4.2 InspectionConditionClassType

The InspectionConditionClassType is used to classify conditions related to inspection maintenance activities. It is formally defined in Table 40.

12.4.3 ExternalCheckConditionClassType

The ExternalCheckConditionClassType is used to classify conditions related to external check maintenance activities. It is formally defined in Table 41.

12.4.4 ServicingConditionClassType

The ServicingConditionClassType is used to classify conditions related to servicing maintenance activities. It is formally defined in Table 42.

12.4.5 RepairConditionClassType

The RepairConditionClassType is used to classify conditions related to repair maintenance activities. It is formally defined in Table 43.

12.4.6 ImprovementConditionClassType

The ImprovementConditionClassType is used to classify conditions related to improvement maintenance activities. It is formally defined in Table 44.

12.5 NameNodeIdDataType

This structure contains the name and optionally a NodeId. It is used to provide a human-readable name of something plus optionally the NodeId in case the something is represented in the AddressSpace. The structure is defined in Table 18.

Its representation in the AddressSpace is defined in Table 46.

12.6 MaintenanceMethodEnum

This enumeration provides information on the maintenance method. The enumeration is defined in Table 47.

Its representation in the AddressSpace is defined in Table 48.

13 Localisation / Contextualisation

13.1 General

13.1.1 Overview

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

13.1.2 Contains ReferenceType

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.

13.2 Local Time

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.

13.3 Hierarchical Location

13.3.1 Overview

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.

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.

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

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.

13.3.2 HierarchicalLocation Property

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.

13.3.3 Hierarchical Location Objects

13.3.3.1 General

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.

13.3.3.2 HierarchicalLocations Object

The HierarchicalLocations Object is formally defined in Table 50.

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.

13.3.3.3 HierarchicalContains ReferenceType

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.

13.4 Operational Location

13.4.1 Overview

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.

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.

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

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.

13.4.2 OperationalLocation Property

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.

13.4.3 Operational Location Objects

13.4.3.1 General

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.

13.4.3.2 OperationalLocations Object

The OperationalLocations Object is formally defined in Table 52.

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.

13.4.3.3 OperationalContains ReferenceType

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.

13.5 Digital Location

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.

14 Structure of Assets

14.1 Sub-Assets

An asset may consist of several sub-assets, and those may have sub-assets as well. In order to expose such a hierarchy, the concept of References is used. Sub-assets shall be referenced from the asset with a hierarchical Reference, preferable 0:HasComponent or a subtype of it. Assets may reference their sub-assets directly, or have additional grouping Objects in between, potentially several layers of grouping Objects. In Figure 17, some examples are given. X:Asset1 contains two sub-assets, directly referenced, and the sub-asset X:Subasset1.2 contains additional two sub-assets. For X:Asset2, the sub-assets are not directly referenced, but some grouping Objects are in between.

In order to identify all sub-assets of an asset, a Client needs to follow all hierarchical References in forward direction from the asset recursively.

14.2 Relations to other Assets

Assets may be related to other assets to expose different information like being physically connected or one asset utilizes another asset. In that case, References are used to expose such functionality. Typically, those References are non-hierarchical References. OPC 10000-23 defines several of those ReferenceTypes, Companion Specification may define additional ReferenceTypes. In Figure 18, some examples are given. X:Asset1 and X:Asset2 are related with the symmetric 0:PhysicallyConnectTo Reference. X:Subasset1.1 utilizes X:Subsubasset1.2.1 using the 0:Utilizes Reference.

In order to identify all relations to other assets, a Client needs to follow all References from the asset considering forward and backward direction. Clients may filter for specific ReferenceTypes.

15 Profiles and Conformance Units

15.1 Conformance Units

Table 54 defines the corresponding ConformanceUnits for the OPC UA Information Model for Asset Management Basics.

15.2 Profiles

15.2.1 Profile list

Table 55 lists all Profiles defined in this document and defines their URIs.

15.2.2 Server Facets

15.2.2.1 Overview

The following sections specify the Facets available for Servers that implement the Asset Management Basics companion specification. Each section defines and describes a Facet or Profile.

15.2.2.2 AMB Base Asset Management Server Facet

Table 56 defines a Profile that describes the base characteristics for all OPC UA Servers that make use of this companion specification.

15.2.3 Client Facets

15.2.3.1 Overview

The following tables specify the Facets available for Clients that implement the Asset Management Basics companion specification.

15.2.3.2 AMB Base Asset Management Client Facet

Table 57 defines a Facet that describes the base characteristics for all OPC UA Clients that make use of this companion specification.

16 Namespaces

16.1 Namespace Metadata

Table 58 defines the namespace metadata for this document. The Object is used to provide version information for the namespace and an indication about static Nodes. Static Nodes are identical for all Attributes in all Servers, including the Value Attribute. See OPC 10000-5 for more details.

The information is provided as Object of type NamespaceMetadataType. This Object is a component of the Namespaces Object that is part of the Server Object. The NamespaceMetadataType ObjectType and its Properties are defined in OPC 10000-5.

The version information is also provided as part of the ModelTableEntry in the UANodeSet XML file. The UANodeSet XML schema is defined in OPC 10000-6.

Note: The IsNamespaceSubset Property is set to False as the UANodeSet XML file contains the complete Namespace. Servers only exposing a subset of the Namespace need to change the value to True.

16.2 Handling of OPC UA Namespaces

Namespaces are used by OPC UA to create unique identifiers across different naming authorities. The Attributes NodeId and BrowseName are identifiers. A Node in the UA AddressSpace is unambiguously identified using a NodeId. Unlike NodeIds, the BrowseName cannot be used to unambiguously identify a Node. Different Nodes may have the same BrowseName. They are used to build a browse path between two Nodes or to define a standard Property.

Servers may often choose to use the same namespace for the NodeId and the BrowseName. However, if they want to provide a standard Property, its BrowseName shall have the namespace of the standards body although the namespace of the NodeId reflects something else, for example the EngineeringUnits Property. All NodeIds of Nodes not defined in this document shall not use the standard namespaces.

Table 59 provides a list of mandatory and optional namespaces used in an Asset Management Basics OPC UA Server.

Table 60 provides a list of namespaces and their index used for BrowseNames in this document. The default namespace of this document is not listed since all BrowseNames without prefix use this default namespace.

Annex A Asset Management Basics Namespace and mappings (Normative)

A.1 NodeSet and supplementary files for Asset Management Basics (AMB) Information Model

The AMB Information Model is identified by the following URI:

http://opcfoundation.org/UA/AMB/

Documentation for the NamespaceUri can be found here.

The NodeSet associated with this version of specification can be found here:

https://reference.opcfoundation.org/nodesets/?u=http://opcfoundation.org/UA/AMB/&v=1.01.1&i=1

The NodeSet associated with the latest version of the specification can be found here:

https://reference.opcfoundation.org/nodesets/?u=http://opcfoundation.org/UA/AMB/&i=1

Supplementary files for the AMB Information Model can be found here:

https://reference.opcfoundation.org/nodesets/?u=http://opcfoundation.org/UA/AMB/&v=1.01.1&i=2

The files associated with the latest version of the specification can be found here:

https://reference.opcfoundation.org/nodesets/?u=http://opcfoundation.org/UA/AMB/&i=2

_____________

Agreement of Use

COPYRIGHT RESTRICTIONS

Any unauthorized use of this specification may violate copyright laws, trademark laws, and communications regulations and statutes. This document contains information which is protected by copyright. All Rights Reserved. No part of this work covered by copyright herein may be reproduced or used in any form or by any means--graphic, electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval systems--without permission of the copyright owner.

OPC Foundation members and non-members are prohibited from copying and redistributing this specification. All copies must be obtained on an individual basis, directly from the OPC Foundation Web site
http://www.opcfoundation.org.

PATENTS

The attention of adopters is directed to the possibility that compliance with or adoption of OPC specifications may require use of an invention covered by patent rights. OPC shall not be responsible for identifying patents for which a license may be required by any OPC specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. OPC specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents.

WARRANTY AND LIABILITY DISCLAIMERS

WHILE THIS PUBLICATION IS BELIEVED TO BE ACCURATE, IT IS PROVIDED "AS IS" AND MAY CONTAIN ERRORS OR MISPRINTS. THE OPC FOUDATION MAKES NO WARRANTY OF ANY KIND, EXPRESSED OR IMPLIED, WITH REGARD TO THIS PUBLICATION, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF TITLE OR OWNERSHIP, IMPLIED WARRANTY OF MERCHANTABILITY OR WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE OR USE. IN NO EVENT SHALL THE OPC FOUNDATION BE LIABLE FOR ERRORS CONTAINED HEREIN OR FOR DIRECT, INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, RELIANCE OR COVER DAMAGES, INCLUDING LOSS OF PROFITS, REVENUE, DATA OR USE, INCURRED BY ANY USER OR ANY THIRD PARTY IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS MATERIAL, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

The entire risk as to the quality and performance of software developed using this specification is borne by you.

RESTRICTED RIGHTS LEGEND

This Specification is provided with Restricted Rights. Use, duplication or disclosure by the U.S. government is subject to restrictions as set forth in (a) this Agreement pursuant to DFARs 227.7202-3(a); (b) subparagraph (c)(1)(i) of the Rights in Technical Data and Computer Software clause at DFARs 252.227-7013; or (c) the Commercial Computer Software Restricted Rights clause at FAR 52.227-19 subdivision (c)(1) and (2), as applicable. Contractor / manufacturer are the OPC Foundation, 16101 N. 82nd Street, Suite 3B, Scottsdale, AZ, 85260-1830.

COMPLIANCE

The OPC Foundation shall at all times be the sole entity that may authorize developers, suppliers and sellers of hardware and software to use certification marks, trademarks or other special designations to indicate compliance with these materials. Products developed using this specification may claim compliance or conformance with this specification if and only if the software satisfactorily meets the certification requirements set by the OPC Foundation. Products that do not meet these requirements may claim only that the product was based on this specification and must not claim compliance or conformance with this specification.

Trademarks

Most computer and software brand names have trademarks or registered trademarks. The individual trademarks have not been listed here.

GENERAL PROVISIONS

Should any provision of this Agreement be held to be void, invalid, unenforceable or illegal by a court, the validity and enforceability of the other provisions shall not be affected thereby.

This Agreement shall be governed by and construed under the laws of the State of Minnesota, excluding its choice or law rules.

This Agreement embodies the entire understanding between the parties with respect to, and supersedes any prior understanding or agreement (oral or written) relating to, this specification.

ISSUE REPORTING

The OPC Foundation strives to maintain the highest quality standards for its published specifications; hence they undergo constant review and refinement. Readers are encouraged to report any issues and view any existing errata here: http://www.opcfoundation.org/errata

Revision 1.01.01 Highlights

The following table includes new features and the Mantis issues resolved with this revision.