|
|
|
|
OPC 10000-7 |
|
|
OPC Unified Architecture Part 7: Profiles
Release 1.05.02 2022-11-01
|
|
|
|
|
OPC 10000-7 |
|
|
OPC Unified Architecture Part 7: Profiles
Release 1.05.02 2022-11-01
|
|
Specification Type: |
Industry Standard Specification |
Comments: |
Report or view errata: http://www.opcfoundation.org/errata |
|
|
|
|
|
|
Document |
OPC 10000-7
|
|
|
|
Title: |
OPC Unified Architecture Part 7: Profiles |
Date: |
2022-11-01 |
|
|
|
|
|
|
Version: |
Release 1.05.02 |
Software: |
MS-Word |
|
|
|
Source: |
OPC 10000-7 - UA Specification Part 7 - Profiles.docx |
|
|
|
|
|
|
Author: |
OPC Foundation |
Status: |
Release |
|
|
|
|
|
CONTENTS
3. Terms, definitions, and abbreviations
4.2. Conformance Units and Conformance Groups
4.6. Conventions for Profile definitions
FIGURES
Figure 1 – Profile – ConformanceUnit – TestCases.................................... 4
TABLES
Table 1 – Profile Categories.................................................................. 5
____________
UNIFIED ARCHITECTURE –
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-2022, OPC Foundation, Inc.
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.05.02 Highlights
The following table includes the major Mantis issues resolved with this revision.
|
Mantis ID |
Scope |
Summary |
Resolution |
|
Errata |
Deprecate Kerberos |
Changed status of Issued Token Facets to “deprecated”. |
|
|
Feature |
New Conformance Units used in Node Tables |
A number of conformance units have been added to cover all nodes defined in UA parts that define base information elements. A few CUs have been replaced by new CUs.
New Facet “Exposes Type System Server Facet” created. |
|
|
Errata |
Create Minimum Client Facet mainly for companion specifications |
Created this Facet as suggested. In addition, the Core 2022 Client Facet has been modified to match the requirements for Minimum UA Client and Standard UA Client. |
|
|
Feature |
Add ECC Security Policy |
ECC-curve25519 is the required policy for low-end UA applications where security was not required. Added proper conformance units to Nano Server and Minimum Client. |
|
|
Errata |
Client support for unencrypted passwords is mandatory |
Split the CU into 2 where one requires encryption of the password and the other does not. The CU that requires encryption is mandatory. |
|
|
Errata |
Clients shall support a deadband filter |
Support / use of the absolute deadband filter is now mandatory in the DataChange Subscriber Client Facet. |
|
|
Feature |
Conformance units missing for well defined roles |
Added CU “Security Role Well Known Group 2” and “Security Role Well Known Group 3” to cover the remaining user roles. |
|
|
Errata |
Remove limit requirements |
All limit requirements have been removed. In case where a functional requirement was implied, this requirement has been transformed into a base functional unit. Added mandatory “documentation” CUs for limits. |
|
|
Feature |
Security Default ApplicationInstance Certificate missing for Clients |
Added as mandatory to Core 2022 Client Facet. |
|
|
Feature |
No time synchronization for existing full-featured profiles |
Added the time sync Facet to Core Client and Core Server Facets. |
|
|
Feature |
Require OperationLimits for all supported features |
The Capability CUs are now mandatory in all facets · Core 2022 (Base Info Server Capabilities 2) · Node Mgmt 2022 (Base Info Node Mgmt Capabilities) · Method 2022 (Method Capabilities) · User Role Base 2022 (Base Info Security Role Capabilities) · Subscription 2022 (Base Info Server Capabilities Subscriptions) · Event Subscr 2022 (Base Info Events Capabilities, Base Info Server Capabilities Subscriptions) · Hist Data 2022 (Base Info History Read Capabilities, Base Info History ReadData Capabilities, Base Info History UpdateData Capabilities) · Hist Events 2022 (Base Info History ReadEvents Capabilities, Base Info History UpdateEvents Capabilities) |
|
|
Feature |
Require ECC Policy |
Either ECC-curve25519 or ECC-nist256 are required for low-end UA applications where security was not required. Added proper conformance units to Nano Server and Minimum Client. |
|
|
Feature |
Add support for server user management |
Created a CU for Server and Client and added as optional to the User Role Management Facets. |
OPC Unified Architecture
Part 7: Profiles Specification
This document specifies value and structure of Profiles in the OPC Unified Architecture.
The actual Profiles are maintained in an online database and accessible via https://profiles.opcfoundation.org/.
OPC UA Profiles are used to segregate features with regard to testing of OPC UA products and the nature of the testing (tool based or lab based). This includes the testing performed by the OPC Foundation provided OPC UA CTT (a self-test tool) and by the OPC Foundation provided independent certification test labs. This could equally as well refer to test tools provided by another organization or a test lab provided by another organization. What is important is the concept of automated tool based testing versus lab based testing. The scope of this standard includes defining functionality that can only be tested in a lab and defining the grouping of functionality that is to be used when testing OPC UA products either in a lab or using automated tools. The definition of actual TestCases is not within the scope of this document, but the general categories of TestCases are within the scope of this document.
Most OPC UA applications will conform to several, but not all of the Profiles.
The following documents, in whole or in part, are normatively referenced in this document and are indispensable for its application. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document applies.
OPC 10000-1, OPC Unified Architecture - Part 1: Overview and Concepts
http://www.opcfoundation.org/UA/Part1/
OPC 10000-2, OPC Unified Architecture - Part 2: Security Model
http://www.opcfoundation.org/UA/Part2/
OPC 10000-3, OPC Unified Architecture - Part 3: Address Space Model
http://www.opcfoundation.org/UA/Part3/
OPC 10000-4, OPC Unified Architecture - Part 4: Services
http://www.opcfoundation.org/UA/Part4/
Compliance Part 8 UA Server, OPC Test Lab Specification: Part 8 – UA Server
http://www.opcfoundation.org/Test/Part8/
Compliance Part 9 UA Client, OPC Test Lab Specification: Part 9 – UA Client
http://www.opcfoundation.org/Test/Part9/
For the purposes of this document, the terms and definitions given in OPC 10000-1, OPC 10000-2, and OPC 10000-3, and OPC 10000-4 as well as the following apply. An overview of the terms defined in this standard and their interaction can be viewed in Figure 1.
3.1.1.
application
a software program that executes or implements some aspect of OPC UA
Note 1 to entry: The application could run on any machine and perform any function. The application could be software or it could be a hardware application, the only requirement is that it implements OPC UA.
3.1.2.
Application Profile
a Profile that defines all features necessary to build a functional OPC UA application
Note 1 to entry: An Application Profile in particular adds definitions of the transport and security requirements. Application Profiles are organized in the “Application Profiles” ProfileCategory.
3.1.3.
ConformanceUnit
a specific set of OPC UA features that can be tested as a single entity
Note 1 to entry: A ConformanceUnit can cover a group of services, portions of services or information models.
3.1.4.
ConformanceGroup
a group of ConformanceUnits that is given a name
Note 1 to entry: This grouping is only to assist in organizing ConformanceUnits. Typical ConformanceGroups include groups for each of the service sets in OPC UA and each of the Information Model standards.
3.1.5.
Facet
a Profile dedicated to a specific feature that a Server or Client may require
Note 1 to entry: Facets are typically combined to form higher-level Profiles. The use of the term Facet in the title of a Profile indicates that the given Profile is not a standalone Profile.
3.1.6.
ProfileCategory
arranges Profiles into application classes, such as Server or Client
Note 1 to entry: These categories help determine what a given Profile is used for. For additional details see 0.
3.1.7.
TestCase
a technical description of a set of steps required to test a particular function or information model
Note 1 to entry: TestCases provide sufficient details to allow a developer to implement them in code. TestCases also provide a detailed summary of the expected result(s) from the execution of the implemented code and any precondition(s) that must be established before the TestCase can be executed.
3.1.8.
TestLab
a facility that is designated to provide testing services
Note 1 to entry: These services include but are not limited to personal that directly perform testing, automated testing and a formal repeatable process. The OPC Foundation has provided detailed standard describing OPC UA TestLabs and the testing they are to provided (see Compliance Part 8 UA Server, Compliance Part 9 UA Client).
CTT Compliance Test Tool
HA Historical Access
The OPC Unified architecture multipart standard describes a number of Services and a variety of information models. These Services and information models can be referred to as features of a Server or Client. Servers and Clients need to be able to describe which features they support and wish to have certified. This document provides a grouping of these features. The individual features are grouped into ConformanceUnits which are further grouped into Profiles. Figure 1 provides an overview of the interactions between Profiles, ConformanceUnits and TestCases. The large arrows indicate the components that are used to construct the parent. For example a Profile is constructed from Profiles and ConformanceUnits. The figure also illustrates a feature of the OPC UA Compliance Test Tool (CTT), in that it will test if a requested Profile passes all ConformanceUnits. It will also test all other ConformanceUnits and report any other Profiles that pass conformance testing. The individual TestCases are defined in separate documents see Compliance Part 8 UA Server and Compliance Part 9 UA Client. The TestCases are related back to the appropriate ConformanceUnits defined in this standard. This relationship is also displayed by the OPC UA Compliance Test Tool.
Figure 1 – Profile – ConformanceUnit – TestCases
Each ConformanceUnit represents a specific set of features (e.g. a group of services, portions of services or information models) that can be tested as a single entity. ConformanceUnits are the building blocks of a Profile. Each ConformanceUnit can also be used as a test category. For each ConformanceUnit, there would be a number of TestCases that test the functionality described by the ConformanceUnit. The description of a ConformanceUnit is intended to provide enough information to illustrate the required functionality, but in many cases to obtain a complete understanding of the ConformanceUnit the reader may be required to also examine the appropriate part of OPC UA. Additional Information regarding testing of a ConformanceUnit are provided in the Compliance Part 8 UA Server or Compliance Part 9 UA Client test standards.
The same features do not appear in more than one ConformanceUnit.
For improved clarity, the large list of ConformanceUnits is arranged into named ConformanceGroups. These groups reflect different OPC UA aspects like the Service Sets, security, transport, and Information Models.
ConformanceGroups have no impact on testing; they are used only for organizational reasons. These groups and the ConformanceUnits that they describe are available at https://profiles.opcfoundation.org/conformanceunit/.
A Profile is a named aggregation of ConformanceUnits and other Profiles. To support a Profile, an application has to support the ConformanceUnits and all aggregated Profiles. The definition of Profiles is an ongoing activity, in that it is expected that new Profiles will be added in the future.
Multiple Profiles may include the same ConformanceUnit.
Testing of a Profile consists of testing the individual ConformanceUnits that comprise the Profile.
Profiles are named based on naming conventions (see 4.5 for details).
Profiles are grouped into categories to help vendors and end users understand the applicability of a Profile.
Table 1 contains the list of currently defined ProfileCategories.
Table 1 – Profile Categories
|
Category |
Description |
|
Application Profiles |
Application level Profiles represent a collection of Facets necessary to build a functional OPC UA Application.They specifically include Transport Profiles and generally also Security Profiles. |
|
Server |
Profiles of this category specify functions of an OPC UA Server. The URI of such Profiles can be exposed in the Server capabilities. |
|
Client |
Profiles of this category specify functions of an OPC UA Client. |
|
Publisher |
Profiles of this category specify functions of an OPC UA Publisher. |
|
Subscriber |
Profiles of this category specify functions of an OPC UA Subscriber. |
|
Transport |
Profiles of this category specify specific protocol mappings. The URI of such Profiles has to be part of an Endpoint Description. |
|
Security |
Profiles of this category specify security related functions. Security policies are part of this category. The URI of Client-Server security policies has to be part of an Endpoint Description returned from the GetEndpoints Service. |
|
Global Directory Service |
Profiles of this category specify functions for global discovery and certificate management. |
An OPC UA application shall implement all mandatory ConformanceUnits in a Profile in order to be compliant with the Profile. Some Profiles contain optional ConformanceUnits. Optional means that an application has the option to not support the ConformanceUnit. However, if supported, the application shall pass all tests associated with the ConformanceUnit. If an OPC UA application desires to be listed as supporting the optional ConformanceUnit then it shall include any required information model items in the configuration provided for certification testing. The test result that is generated by the certification testing lists all optional ConformanceUnits and whether they are supported or not by the tested OPC UA application.
Profiles may also include other Profiles. If a Profile is included it means that it is mandatory and the same conformance rules apply to it.
Profiles have the following naming conventions:
· Profiles intended for specific application types have the application type in their titles. Currently defined application types are Server, Client, Publisher, Subscriber, and GDS.
· The term Facet in the title of a Profile indicates that this Profile concerns a specific feature of OPC UA. Such Profiles are expected to be combined with Application Profiles to define the complete functionality of an OPC UA application.
Versioning of Profile is accomplished with a naming convention. Whenever a profile is revised, the year of the new revision is added to the name. Example:
|
Version 1 |
Core Server Facet |
|
Version 2 |
Core 2017 Server Facet |
|
Version 3 |
Core 2022 Server Facet |
A vendor that is developing an OPC UA application, shall review the list of available Profiles. From this list the vendor shall select the Profiles that include the functionality required by the application. Conformance to a single Profile may not yield a complete application. In most cases multiple Profiles are needed to yield a useful application. All UA applications shall support at least one Application Profile.
For example an HMI Client application may choose to support the Minimum UA Client 2022 Profile, the “Data Access Client Facet”, the “DataChange Subscriber Client Facet” and the “Attribute Write Client Facet”. This list of Profiles would allow the Client to communicate with an OPC UA Server using UA-TCP/UA Security/UA Binary. It would be able to subscribe for data, write to data and would support the DA data model.
Clients should take into account the types of Servers and Server Profiles that they are targeted to support. Some Servers might not support Subscriptions and Clients should be able to fall back to the Read Service.
A special case is a generic Client that is designed to communicate with a large number of Servers and therefore able to perform a broad range of functionality. ”Standard UA Client Profile” has been defined for this kind of Clients.
Many Clients, however, will be specialized and do not need all of the functionality in the ”Standard UA Client Profile” and thus would only support the limited set of functionality they require. A trend Client, for example, would only need functionality to subscribe to or read data.
____________