OPC UA Specification - Amendment

OPC 10001-7

 

OPC Unified Architecture

Amendment 7: Interfaces and AddIns

 

 

Release 1.04

2019-03-27

 

 

 

 

 

 

 


 

Specification Type:

Industry Standard Specification

Comments:

Report or view errata: http://www.opcfoundation.org/errata

 

 

 

 

Document
Number

OPC 10001-7

 

 

Title:

OPC Unified Architecture

Amendment 7: Interfaces and AddIns

Date:

2019-03-27

 

 

 

 

Version:

Release 1.04

Software:

MS-Word

 

 

Source:

OPC 10001-7 - UA Specification 1.04 Amendment 7 - Interfaces and AddIns.docx

 

 

 

 

Author:

OPC Foundation

Status:

Release

 

 

 

 


 

 

OPC Foundation

____________

 

UNIFIED ARCHITECTURE –

FOREWORD

This specification is the specification for developers of OPC UA applications. The specification is a result of an analysis and design process to develop a standard interface to facilitate the development of applications by multiple vendors that shall inter-operate seamlessly together.

Copyright © 2006-2019, OPC Foundation, Inc.

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 https://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: HTUhttp://www.opcfoundation.org/errataUTH

 


Revision 1.04 Amendment 7 Highlights

The following table includes the Mantis issues resolved by this Amendment.

Mantis ID

Summary

Resolution

4049

New ObjectType to structure different aspects of a device.

Interfaces provide (limited) support for multiple inheritance. AddIns provide support for adding so-called facets.

 

 


OPC Unified Architecture Specification

 

AMENDMENT 7: Interfaces and AddIns

 

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

Add the following references

[GH95] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns – Elements of Reusable Object-Oriented Software, Addison-Wesley 1995

[FF04] Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates: Head First Design Patterns, O’Reilly, 2004

 

Add the following Terms

3.1.1     

AddIn

a widely applicable feature or feature-set represented by an ObjectType that will be applied using aggregation

3.1.2     

Interface

an abstract ObjectType used to specify a feature or feature-set that shall be implemented by the Object or ObjectType where it is applied to

 

Add the following Property to Table 12 (ObjectType NodeClass) under section “Standard Properties”) in clause 5.5.2

    DefaultInstanceBrowseName

O

QualifiedName

Allows the definition of BrowseName on an ObjectType that all instances should use by default.

This Property has no ModellingRule. It shall only be on the type Node.

 

Add “4.9 Interfaces and AddIns”

4.9       Interfaces and AddIns for Objects

4.9.1    Overview

OPC UA defines a type model supporting one object-oriented type hierarchy for ObjectTypes. Although the specification does not restrict those hierarchies to be single inheritance (i.e. a type can only have one super-type) it only specifies the semantic (inheritance rules) for single inheritance.

In general, good object-oriented design is accomplished by not over-using inheritance but instead by using composition to aggregate an object providing several functionalities [GH95, FF04].

Interfaces and AddIns complement the type model and can be used when subtyping is not suitable for the required extension. They:

·      allow enhancing multiple types at arbitrary positions in the type hierarchy.

·      also allow enhancing just instances.

4.9.2    Interface Model

Interfaces are ObjectTypes that represent a generic feature (functionality), assumed to be usable by different ObjectTypes or Objects. The Interface model specifies the rules and mechanisms to achieve this.

The “InterfaceTypesObject (see 2601065156.398.2.11) has been defined so that all Interfaces of the Server are either directly or indirectly accessible browsing HierarchicalReferences starting from this Node.

Rules for the defintion of Interfaces:

·      Interface ObjectTypes shall be abstract subtypes of the BaseInterfaceType ObjectType.

·      InstanceDeclarations on an Interface shall only have ModellingRules Optional or Mandatory.

·      Interfaces can be subtyped as specified in clause 6.3.

·      Interfaces shall not be the source of HasInterface References.

·      Recommended convention: The first letter of an Interface should be ‘I’. See examples below.

Rules for applying Interfaces:

·      When an ObjectType references an Interface with a HasInterface Reference or a subtype, the following rules apply:

o   Each mandatory InstanceDeclaration of the fully-inherited InstanceDeclaration­Hierarchy of the Interface shall have for each BrowsePath a similar Node (see 6.2.4) with the ModellingRule Mandatory using the same BrowsePath in the fully-inherited InstanceDeclarationHierarchy of the ObjectType. The rules for instantiating InstanceDeclarations defined in 6.2.6 shall be applied.

o   Each optional InstanceDeclaration of the fully-inherited InstanceDeclaration­Hierarchy of the Interface should have for each BrowsePath a similar Node (see 6.2.4) with the ModellingRule Mandatory or Optional using the same BrowsePath in the fully-inherited InstanceDeclarationHierarchy of the ObjectType. The rules for instantiating InstanceDeclarations defined in 6.2.6 shall be applied. If no similar Node with the same BrowsePath exists, the ObjectType and its sub-types shall not use the same BrowsePath for a different Node (e.g. with a different NodeClass).

If the rules cannot be fulfilled (e.g. name collisions) the ObjectType cannot apply the Interface, i.e. it shall not reference the Interface with a HasInterface Reference of a subtype.

The rules apply for each referenced Interface. As a consequence, an ObjectType cannot reference two Interfaces using the same BrowsePath for Nodes that are not similar Nodes or have TypeDefinitionNodes that are not compatible (compatible means they have either the same TypeDefinitionNode or one TypeDefinitionNode is the subtype of the other TypeDefinitionNode).

·      Subtypes should not have a HasInterface Reference to an Interface if it was already applied to a super-type.

·      When an Object references an Interface with a HasInterface Reference or a subtype, the following rules apply:

o   The Interface shall not be applied on the Object when the Interface cannot be applied on the TypeDefinitionNode of the Object.

o   The same rules on the Object apply as if the Interface would have been applied on the TypeDefinitionNode of the Object (e.g. all Mandatory InstanceDeclarations need to be applied).

o   The Nodes defined based on the Interface shall be handled as if they where defined by the TypeDefinitionNode. For example, the TranslateBrowsePathsToNodeIds Service shall return them first.

o   If several Interfaces should be applied to the Object, they should be treated as if they where all applied to the ObjectType of the Object at the same time. If this is not possible, the Interfaces cannot be applied to the Object together.

o   Instances should not have a HasInterface Reference to an Interface if it was already applied to the TypeDefinitionNode.

 

Figure 7A illustrates example Interfaces:

·      ISerializeServiceType, an Interface to convert the Object and its components into a stream of bytes.

·      ITransactionServiceType, an Interface to perform a sequence of changes to the Object as a single operation.

·      ILocationType, an Interface to specify the installation location of the Object.

Figure 7A – Examples of Interfaces

The following examples illustrate the application of these Interfaces. In Figure 7B the example Interface ILocationType is applied to the XYZ-DeviceType ObjectType. It also illustrates the overriding of Property “Address” by changing the ModellingRule from Optional to Mandatory. Figure 7C in addition shows how to use the ISerializeService Interface on the instance only. Figure 7D shows an Interface hierarchy where InstanceDeclarations of the referenced Interface and its parent type(s) are applied (the fully-inherited InstanceDeclarationHierarchy).

 

Figure 7B – Example: Interface application to an ObjectType

Figure 7C – Example: One Interface applied to an ObjectType another one to the instance

 

Figure 7D – Example: Interface Hierarchy

 

Clients can detect the implementation of Interfaces by filtering for the HasInterface Reference into the Browse Service request.

On instances, the Browse Service will return elements derived from an Interface together with elements of the Node’s base type. Clients can also use the TranslateBrowsePathToNodeId Service with BrowseNames of Interface members to get the NodeId of these members directly.

In the example in Figure 7C “Address” with the starting node MD002 can be used to request the NodeId of this Property.

On Object instances, some Nodes of an Interface may not be available if defined with ModellingRule Optional.

 


 

4.9.3    AddIn model

AddIns associate a feature or feature-set, represented by an ObjectType to the Node (an Object or ObjectType) they are applied to. The Interface model is different than the AddIn model in that it is based on composition. An AddIn is applied to a Node by adding a Reference to the AddIn instance.

There are no restrictions for AddIn ObjectTypes and there is no special supertype for AddIns. To identify instances as an AddIn, the HasAddIn Reference or a subtype shall be used.

The AddIn ObjectType may include the definition of a default BrowseName using the DefaultInstanceBrowseName Property. Instances of such an AddIn should use this default BrowseName. If an AddIn is instantiated multiple times in the same parent, only one instance can have the default BrowseName.

The definition of an AddIn and its use with a default BrowseName is illustrated in Figure 7E.

 

 

Figure 7E – Example of AddIn with default BrowseName

As already described, an AddIn can be applied on types and instances. The use on an instance is shown in Figure 7F.

Figure 7F – Example of AddIn applied to an instance

Clients can detect the implementation of AddIns by passing the HasAddIn Reference as filter to the Browse Service request. If an AddIn has a default BrowseName, Clients can use the TranslateBrowsePathToNodeId Service with the default BrowseName to get the NodeId of an AddIn.

In the example in Figure 7E the relative path “MyFeature/MyPropertyM” with the starting node MD002 can be used to request the NodeId of this Property and the relative path “MyFeature/MyMethodO” can be used for the respective Method.

 


 

Add sections 7.19 and 7.20

7.19     HasInterface ReferenceType

The HasInterface ReferenceType is a concrete ReferenceType and can be used directly. It is a subtype of the NonHierarchical ReferenceType.

The semantic of this ReferenceType is to show the availability of the Interface on the SourceNode. The Interface concept is described in 4.9.2.

The SourceNode of this ReferenceType shall be an Object or ObjectType. Interfaces shall not be a SourceNode. The TargetNode shall be of a subtype of the BaseInterfaceType.

One SourceNode can refer to different Interfaces.

 

7.20     HasAddIn ReferenceType

The HasAddIn ReferenceType is a concrete ReferenceType and can be used directly. It is a subtype of the HasComponent ReferenceType.

The semantic of this ReferenceType is to bind an AddIn to another Node that is the source of this Reference. The AddIn concept is described in 4.9.3.

The SourceNode of this ReferenceType shall be an Object or ObjectType. The TargetNode shall be an Object.

 


 

 

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

Add the following to Table 8 in Clause 6.2 (BaseObjectType):

An additional subtype entry for BaseInterfaceType is required:

HasSubtype

ObjectType

BaseInterfaceType

Defined in 6.9

 

Add the following as Clause 6.9:

6.9       BaseInterfaceType

The BaseInterfaceType ObjectType is the super-type for Interfaces. All subtypes of BaseInterfaceType shall be abstract.

There are no References specified for this ObjectType. It is formally defined in Table 60A.

Table 60A – BaseInterfaceType Definition

Attribute

Value

BrowseName

BaseInterfaceType

IsAbstract

True

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the BaseObjectType defined in 6.2.

 

 

Add the following to Table 82 – Types Definition:

An additional Reference to the InterfaceTypes Object is required:

Organizes

Object

InterfaceTypes

Defined in 8.2.11

 

Add the following as Clause 8.2.11:

8.2.11 InterfaceTypes

This standard Object Node is the browse entry point for ObjectType Nodes that represent Interfaces. Figure 7A illustrates the structure beneath this Node showing some of the standard ObjectTypes defined in clause 6. Only Organizes References are used to relate Objects and Interfaces to the “InterfaceTypes” standard Object. The “InterfacesTypesObject shall not reference any other NodeClasses.

 

Figure 7A[RSA1]  – InterfaceTypes Organization

The intention of the “InterfaceTypesObject is that all Interfaces of the Server are either directly or indirectly accessible browsing HierarchicalReferences starting from this Node. However, this is not required and Servers might not provide some of their Interfaces because they may be well-known in the industry.

The “InterfaceTypesObject is formally defined in Table 87A.

Table 87A – InterfaceTypes Definition

Attribute

Value

BrowseName

InterfaceTypes

References

NodeClass

BrowseName

Comment

HasTypeDefinition

ObjectType

FolderType

Defined in 6.6

Organizes

ObjectType

BaseInterfaceType

Defined in 6.9

 

 

Add the following to Table 100 in Clause 11.3 (NonHierarchicalReferences):

An additional subtype entry for HasInterface is required:

HasSubtype

ReferenceType

HasInterface

Defined in 11.20

 

Add the following to Table 104 in Clause 11.7 (HasComponent):

An additional subtype entry for HasAddIn is required:

HasSubtype

ReferenceType

HasAddIn

Defined in 11.21

 

 

Add the following as Clause 11.20:

11.20   HasInterface

This standard ReferenceType is defined in OPC 10000-3. Its representation in the AddressSpace is specified in Table 114C.

Table 114C – HasInterface ReferenceType

Attributes

Value

BrowseName

HasInterface

InverseName

InterfaceOf

Symmetric

False

IsAbstract

False

References

NodeClass

BrowseName

Comment

 

 

 

 

 

 

Add the following as Clause 11.21:

11.21   HasAddIn

This standard ReferenceType is defined in OPC 10000-3. Its representation in the AddressSpace is specified in Table 114D.

Table 114D – HasAddIn ReferenceType

Attributes

Value

BrowseName

HasAddIn

InverseName

AddInOf

Symmetric

False

IsAbstract

False

References

NodeClass

BrowseName

Comment

 

 

 

 

 

 

 


 

 

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

NOTE There are no ConformanceUnits for Clients. Interfaces and AddIns are concepts mainly used by modelling tools.

 

Add the following ConformanceUnits to section 5.4, Table 14 “Address Space Model”:

Category

Title

Description

Server

Address Space Interfaces

Support Interfaces and associated rules.

Server

Address Space AddIn Reference

Support the HasAddIn Reference to bind an AddIn to an Object or ObjectType.

Server

Address Space AddIn DefaultInstanceBrowsename

Support the DefaultInstanceBrowseName Property for ObjectTypes.

 

Add the following ConformanceUnits to the section 6.6.3 Core 2017 Server Facet:

Group

Conformance Unit / Profile Title

Optional

Address Space Model

Address Space Interfaces

True

Address Space Model

Address Space AddIn Reference

True

Address Space Model

Address Space AddIn DefaultInstanceBrowseName

True

 

 

_________


 [RSA1]Missing figure field.