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.

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.

1. The asset is software without hardware. In this case, only the SoftwareRevision is provided, and the HardwareRevision is omitted.
2. The asset is hardware without software. In this case, only the HardwareRevision is provided, and the SoftwareRevision is omitted.
3. The asset is a combination of hard- and software. In this case, the following model approaches can be done
4. Represent asset as one Object: The asset provides the HardwareRevision and SoftwareRevision
5. 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.

Figure 4 – Examples of the Usage of Version Information

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.

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.

Figure 5 – Example providing Operational Counters

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.

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.

Figure 6 – Example of the DocumentationLinks AddIn

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.

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

Table 29 – DocumentationLinksType Definition

Attribute	Value
BrowseName	DocumentationLinksType
IsAbstract	False
Description	AddIn to link documentation provided by the manufacturer and / or end-user.
References	NodeClass	BrowseName	DataType	TypeDefinition	Other
Subtype of the 0:BaseObjectType Type defined in OPC 10000-5
0:HasProperty	Variable	0:DefaultInstanceBrowseName	0:QualifiedName	PropertyType
0:HasComponent	Variable	<Link>	0:UriString	BaseDataVariableType	OP
0:HasComponent	Method	AddLink			O
0:HasComponent	Method	RemoveLink			O
Conformance Units
AMB DocumentationLinks Base

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.

Table 30 – DocumentationLinksType Attribute values for child Nodes

BrowsePath	Value Attribute	Description Attribute
0:DefaultInstanceBrowseName	DocumentationLinks
<Link>		Represents links to externally managed documentation, typically URLs.
AddLink		Method to add an end-user specific link that is stored persistently in the server.
RemoveLink		Method to remove an end-user specific link that is managed in the server.

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);

Table 31 – AddLink Method Arguments

Argument	Description
LinkToExternalSource	Link to an external source. The server might or might not check if a correct URI is provided, or if the URI is available/reachable.
BrowseName	The BrowseName of the new created Node. Method fails if a Variable with the same BrowseName already exists.
DisplayName	The DisplayName of the new created Node. If the server supports multiple locales, and the Client wants to provide more than one locale, the Write operation on the Variable shall be used.
Description	The Description of the new created Node. If the server supports multiple locales, and the Client wants to provide more than one locale, the Write operation on the Variable shall be used.
LinkVariable	The NodeId of the newly created Variable.

Method Result Codes (defined in Call Service)

Result Code	Description
Bad_UserAccessDenied	See OPC 10000-4 for a general description.
Bad_InvalidArgument	See OPC 10000-4 for a general description.

Table 32 – AddLink Method AddressSpace definition

Attribute	Value
BrowseName	AddLink
References	NodeClass	BrowseName	DataType	TypeDefinition	ModellingRule
0:HasProperty	Variable	0:InputArguments	0:Argument[]	0:PropertyType	0:Mandatory
0:HasProperty	Variable	0:OutputArguments	0:Argument[]	0:PropertyType	0:Mandatory
Conformance Units
AMB DocumentationLinks Base

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

);

Table 33 – RemoveLink Method Arguments

Argument	Description
VariableToBeDeleted	NodeId of the Variable containing a link, that should be deleted. Variable shall be referenced from the Object with a HasComponent Reference where the Method is called on.

Method Result Codes (defined in Call Service)

Result Code	Description
Bad_UserAccessDenied	See OPC 10000-4 for a general description.
Bad_InvalidArgument	See OPC 10000-4 for a general description.

Table 34 – RemoveLink Method AddressSpace definition

Attribute	Value
BrowseName	RemoveLink
References	NodeClass	BrowseName	DataType	TypeDefinition	ModellingRule
0:HasProperty	Variable	0:InputArguments	0:Argument[]	0:PropertyType	0:Mandatory
Conformance Units
AMB DocumentationLinks Base

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

Figure 7 – Example providing Requirements

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

Figure 8 – Example providing Capabilities