1 Scope

This document specifies the overall architecture and uses cases of a Cloud Library for storing and retrieving OPC UA NameSpaces. Detailed interface definitions (APIs) will be released in part 2 and beyond.

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, authorization 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

CESMII

CESMII is the United States’ national institute on Smart Manufacturing, driving cultural and technological transformation and secure industrial technologies as national imperatives. By enabling frictionless movement of information – raw and contextualized data – between real-time Operations and the people and systems that create value in and across Manufacturing organizations, CESMII is ensuring the power of information and innovation is at the fingertips of everyone who touches manufacturing.

Founded in 2016, in partnership with DOE’s Office of Energy Efficiency and Renewable Energy (EERE), CESMII is the third institute funded by EERE’s Advanced Manufacturing Office. The Institute is accelerating Smart Manufacturing (SM) adoption through the integration of advanced sensors, data (ingestion – contextualization – modeling – analytics), platforms and controls to radically impact manufacturing performance, through measurable improvements in areas such as: quality, throughput, costs/profitability, safety, asset reliability and energy productivity. CESMII’s program and administrative home is with the University of California Los Angeles (UCLA).

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

3 Terms, abbreviated terms and conventions

3.1 Overview

It is assumed that basic concepts of OPC UA information modelling (OPC 10000-5) are understood in this document.

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

3.2 OPC UA for Cloud Library terms

3.2.1 Cloud Library

An online database of OPC UA NameSpaces that can be accessed through a REST-style interface (SwaggerV3/OpenAPI), as well as Graph Query Language (GraphQL) and OPC UA Server Sessionless Method calls. In V1, only REST-style interfaces will be used.

3.3 Abbreviated terms

4 General information to Cloud Library and OPC UA

4.1 Introduction to Cloud Library

The UA Cloud Library is an online store of OPC UA NameSpaces. It provides a mandatory REST interface (as well as additional option interfaces) to upload, download and query for NameSpaces.

For a Client application to access information from a machine today, it must browse the AddressSpace of the OPC UA Server when it is online. The final configuration can only happen when the Server is online. For example, an industrial robot typically has an OPC UA Server built in. An AddressSpace can contain a combination of machine-specific and vendor-neutral Namespaces.

See here for a typical, standardized OPC UA information model (that can be part of an AddressSpace of a real OPC UA server).

To identify a stored NameSpace in the Cloud Library, a globally unique identifier such as the NamespaceUri (as defined in OPC 10000-100) can be used.

4.2 Introduction to OPC Unified Architecture

4.2.1 What is OPC UA?

OPC UA is an open and royalty free set of standards designed as a universal communication protocol. While there are numerous communication solutions available, OPC UA has key advantages:

A state of art security model (see OPC 10000-2).

A fault tolerant communication protocol.

An information modelling framework that allows application developers to represent their data in a way that makes sense to them.

OPC UA has a broad scope which delivers for economies of scale for application developers. This means that a larger number of high-quality applications at a reasonable cost are available. When combined with a Cloud Library, OPC UA makes it easier for end users to access data via generic commercial applications.

The OPC UA model is scalable from small devices to ERP systems. OPC UA Servers process information locally and then provide that data in a consistent format to any application requesting data - ERP, MES, PMS, Maintenance Systems, HMI, Smartphone or a standard Browser, for examples. For a more complete overview see OPC 10000-1.

4.2.2 Basics of OPC UA

As an open standard, OPC UA is based on standard internet technologies, like TCP/IP, HTTP, Web Sockets.

As an extensible standard, OPC UA provides a set of Services (see OPC 10000-4) and a basic information model framework. This framework provides an easy manner for creating and exposing vendor defined information in a standard way. More importantly all OPC UA Clients are expected to be able to discover and use vendor-defined information. This means OPC UA users can benefit from the economies of scale that come with generic visualization and historian applications.

OPC UA Clients can be any consumer of data from another device on the network to browser based thin clients and ERP systems. The full scope of OPC UA applications is shown in Figure 1.

OPC UA provides a robust and reliable communication infrastructure having mechanisms for handling lost messages, failover, heartbeat, etc. With its binary encoded data, it offers a high-performing data exchange solution. Security is built into OPC UA as security requirements become more and more important especially since environments are connected to the office network or the internet and attackers are starting to focus on automation systems.

4.2.3 Information modelling in OPC UA

4.2.3.1 Concepts

OPC UA provides a framework that can be used to represent complex information as Objects in an AddressSpace which can be accessed with standard services. These Objects consist of Nodes connected by References. Different classes of Nodes convey different semantics. For example, a Variable Node represents a value that can be read or written. The Variable Node has an associated DataType that can define the actual value, such as a string, float, structure etc. It can also describe the Variable value as a variant. A Method Node represents a function that can be called. Every Node has a number of Attributes including a unique identifier called a NodeId and non-localized name called as BrowseName. An Object representing a ‘Reservation’ is shown in Figure 2.

Object and Variable Nodes represent instances and they always reference a TypeDefinition (ObjectType or VariableType) Node which describes their semantics and structure. Figure 2 illustrates the relationship between an instance and its TypeDefinition.

The type Nodes are templates that define all of the children that can be present in an instance of the type. In the example in Figure 2 the PersonType ObjectType defines two children: First Name and Last Name. All instances of PersonType are expected to have the same children with the same BrowseNames. Within a type the BrowseNames uniquely identify the children. This means Client applications can be designed to search for children based on the BrowseNames from the type instead of NodeIds. This eliminates the need for manual reconfiguration of systems if a Client uses types that multiple Servers implement.

OPC UA also supports the concept of sub-typing. This allows a modeller to take an existing type and extend it. There are rules regarding sub-typing defined in OPC 10000-3, but in general they allow the extension of a given type or the restriction of a DataType.

4.2.3.2 Namespaces

OPC UA allows information from many different sources to be combined into a single coherent AddressSpace. Namespaces are used to make this possible by eliminating naming and id conflicts between information from different sources. Each namespace in OPC UA has a globally unique string called a NamespaceUri which identifies a naming authority, and a locally unique integer called a NamespaceIndex, which is an index into the Server's table of NamespaceUris. The NamespaceIndex is unique only within the context of a Session between an OPC UA Client and an OPC UA Server- the NamespaceIndex can change between Sessions and still identify the same item even though the NamespaceUri's location in the table has changed. The Services defined for OPC UA use the NamespaceIndex to specify the Namespace for qualified values.

There are two types of structured values in OPC UA that are qualified with NamespaceIndexes: NodeIds and QualifiedNames. NodeIds are locally unique (and sometimes globally unique) identifiers for Nodes. The same globally unique NodeId can be used as the identifier in a node in many Servers – the node's instance data may vary but its semantic meaning is the same regardless of the Server it appears in. This means Clients can have built-in knowledge of of what the data means in these Nodes. OPC UA Information Models generally define globally unique NodeIds for the TypeDefinitions defined by the Information Model.

QualifiedNames are non-localized names qualified with a Namespace. They are used for the BrowseNames of Nodes and allow the same names to be used by different information models without conflict. TypeDefinitions are not allowed to have children with duplicate BrowseNames; however, instances do not have that restriction.

4.2.3.3 Companion specifications

Typically, an OPC UA companion specification for an industry specific vertical market describes an Information Model by defining ObjectTypes, VariableTypes, DataTypes and ReferenceTypes that represent the concepts used in the vertical market. The Cloud Library Companion Specification is one that proposes new capabilities to serve libraries of NameSpaces to other OPC UA Servers.

5 Use cases

For each of the use cases, the OPC UA NameSpace needs to be known up front, before a connection to the physical machine (containing an OPC UA server) is possible. Therefore, the NameSpace for the machine needs to be available on the Internet on a global scale.

5.1 Configure the application behind the OPC UA Client which consumes the data from the machine

As a machine operator I want to configure the OPC UA Client and the applications behind, already very early in the development/procurement process of a machine or factory. The Cloud Library enables the machine builder to upload the NameSpace after final commissioning before the machine is shipped and installed in the factory. During this timeframe the application developer can finalize the development/configuration before the machine is online on the shop floor. Example: Online dashboard (“Cloud SCADA”) for condition monitoring, OEE calculation, predictive/preventative maintenance, etc.

As a machine builder I need to maintain a library/repository of all shipped machines and their respective NameSpaces. The Cloud Library enables such a storage and is also a versioning control system. Businesswise this reliefs the machine builder to operate and maintain such a repository for their own organization.

As a machine operator I could determine deltas in machine NameSpaces to identify and make use of new features of a machine. Therefore, I could browse the UpToDate model of this machine model to determine if available new features are useful for my operations.

The Cloud Library enables in this use case uniform processes for the whole shop floor machines. Additionally, I gain the time benefit between factory acceptance and final operation to develop and configure the applications which consume the OPC UA data.

The use of a Cloud Library in the context of auditing business process at the machine operator and machine builder’s organization enables an end to end reliable and well-defined process.

5.2 Specification compliance verification for new machines

As an OPC UA compliance certification authority I could use tools which are automating the NameSpaces certification of new machines by using the public Cloud Library as a unique uniform source for accessing the relevant type libraries.

As an equipment supplier I need to perform partial or complete NameSpaces compliance verification for a new machine tool which is integrating besides its own components, hardware/software from one or more suppliers either by aggregation or extension.

During operation and maintenance of a machine, the structure of the AddressSpace could change to reflect variations of the new replacing parts. As a process control engineer / maintenance technician I want to perform verifications of the OPC UA Server’s loaded AddressSpace against reference NameSpaces for troubleshooting or validation.

As a SCADA software engineer, I need to use automated tools to check compliance of new/replacing servers to client applications and vice-versa, report differences or support necessary re-adaptions.

As an automation integration engineer, I need to have a consistent up to date source of information about devices/manufacturers/suppliers which are conformant to a given companion specification/version.

As an equipment manufacturer/supplier I want to publish information about product releases conformant to a given companion specification/version as a way for creating product/brand awareness.

Structuring NameSpaces and associated metadata such that every nodeset is mastered (or edited) in only one place (single source of truth) and referred through unique uniform identification could enhance the engineering tools for automated IM compliance verification, with the final aim of reducing the overall systems engineering effort.

There could be two categories of compliance checks that are needed for all those use cases.

First check if a given model is compliant to the OPC UA specification in general (i.e., not violate any rules of how IM can be designed). This includes checks if known models (companion model or vendor specific) are used in a correct way.

The other kind of check would target the maintenance / update task. Find out if an updated model is backwards compatible to what is currently used. In other words, answer the question: The model changed, it is still compliant to the specification, but will my application and configuration still work? For example, adding a new subtype of an Object Type in a server still enables the client to continue working with the known super type. Other non-compatible changes would generate an error.

5.3 Retrofit OPC UA to existing machines

Brown field manufacturing systems may have embedded data models that aren’t articulated in a discoverable fashion but are likely derived from patterns or practices that have broad internal, or vertical industry acceptance – though without detailed implementation design. This “tribal knowledge” of how a piece of equipment or process works can be easily misinterpreted by different personas and runs the risk of getting lost entirely as a workforce shifts or turns over. Capturing these NameSpaces in a semantically reliable, structurally useful fashion, and publishing them for broad consumption, can allow manufacturers to map their systems to normative approaches found in a common library. Not only does this mapping accelerate future information projects on existing machines by providing a common interface and dictionary of terms, but it facilitates interoperability between systems, workforce development, and a reference implementation of industry practices that can be used to derive or develop new standards. A published library of NameSpaces that constituents can draw from enables implementers to begin to speak a “common language” that uses OPC UA as its lexicon.

Specific examples for this use case are:

As a Process Engineer designing a new line, I want to search for NameSpaces for Packaging Machines. I am familiar with PackML, so might search for that by name, or use terms from that standard.

As a supply chain participant for a consumer goods company, I’m required to implement an AddressSpace for my inventory management system that they have published to the Cloud Lib. I’d like to search for it by endorser and application (e.g.: warehouse, or logistics)

As a quality assurance engineer, I want to understand which Extruder OEMs have published NameSpaces about their inspection capabilities. I might search by vendor name, machine type, or quality terms I’m familiar with.

As a Production Manager, I’d like to find an efficiency NameSpaces I can retrofit into my paper converting operation.

As a Process Control Engineer, I would like to build my PLC program so that it fulfills a published NameSpace for a heat treatment process. I might search for “heat treatment” but I’ll also be interested to know if any existing Models have been built by or for my PLC hardware vendor of choice.

As a Machine Builder, I would like to understand what NameSpaces my customers might have found in the Cloud Lib to determine if I should implement my machine to support those models. I might search by industry, problem space, or even customer name.

As a System Integrator, I would like to retrofit the control program for an Automotive paint line, so that it meets the requirements of a newly published NameSpaces standard suggested by the Auto Industry.

As an AI Researcher trying to build a predictive energy model for smelting operations, I would like to search the CloudLib to see what NameSpaces the industry is using, so I can determine what data might be available for training my model.

Requirements for this use case include:

Comprehensive set of existing (standardized) OPC UA info models pre-set in UA Cloud Lib, logically grouped by machine type (can be a query API feature)

“Mapping Guide” for doing the actual mapping (can be supplied separately)

5.4 Downloading a NameSpace from the Cloud Library into a “blank” UA Server Instance

Abby works as an OT engineer at a steel welder machine manufacturer. For a new model steel welder that she is currently working on, her team has decided to map the proprietary information model provided by the machine to an OPC UA AddressSpace. Abby has learned that there is a vast online library of existing OPC UA NameSpaces out there, so instead of starting from scratch, she decides to base her information model on one of the existing NameSpaces, especially given the fact that her company has been using OPC UA for a while now and there have also been contributions to the Cloud Library. She goes online and quickly finds the Cloud Library main frontend website. She authenticates with the website and browses its metadata via one of the REST APIs. Within minutes, she finds the specific NameSpace that she wants to use in her “blank” OPC UA server built into the steel welder based on capability keywords that she has provided. There is also a preview of a subset of the NameSpace available directly on the Cloud Library frontend website where she can be confident that the NameSpace has the right information included for her. Building a machine OPC UA AddressSpace used to take weeks, now she can make it available for testing within minutes.

She acquires the license for the NameSpace she wants to use. She downloads the NameSpace in nodeset.json format and imports it into her OPC UA server via the standard OPC Foundation reference tools (e.g. “modelcompiler” tool).

After a few minutes, the OPC UA sever built into the steel welder is up and running and she can start browsing the newly created AddressSpace using a standard OPC UA Client application running on her laptop. She then starts wiring up data nodes to machine sensors and starts implementing the defined OPC UA Methods to control the machine.

5.5 Engineering support from existing NameSpaces

The use case of Jeff, a design engineer at a plant and machinery company, is similar to the before mentioned scenario of Abby, the OT engineer at a steel welder machine manufacturer. The difference is that Jeff needs to compose a new production line for his customer and many components of this production line are provided by suppliers who – like Jeffs company – deliver their machines and devices with NameSpaces. As these suppliers publish their OPC UA NameSpaces to the Cloud Library, it is a tremendous work simplification for Jeff, that he can – similar to Abby – find and download all relevant NameSpaces and merge them into the OPC UA server’s AddressSpace of the whole production line. Jeff will certainly also upload the resulting NameSpace to the Cloud Library, so that his customer can prepare the corresponding OPC UA Client and system landscape integration way before the new production line is physically installed at his customers premises.

6 User Roles/Personas interacting with the Cloud Library

Contributor

Create/Read/Update/Delete – CRUD on NameSpaces they own

User

Simple search based on metadata, e.g., contributor (name, email address, company name), or nodeset name

Query-based search (complex search queries) will require GraphQL (see below)

Download NameSpaces (as a single nodeset file)

7 Support for existing Companion Specs

The OPC UA companion specs (including all their versions) will simply be NameSpaces hosted in the Cloud Library. These NameSpaces are used as a reference but mostly will be extended b vendor-specific additions. Since OPC UA companion specs are public domain, these NameSpaces will be excluded from monetization.

8 Support for Additional Metadata

During upload, the provision of additional metadata through the creating of a manifest file (or similar) must be supported, since there may be a need for, e.g. nameplate, attribution, mapping to standardized UA models) or references to existing, related NameSpaces stored in the UA Cloud Library. This can be done through definition new references.

Additionally, manual tag definition (strings) can be supported. For example, GitHub uses this feature.

9 Incentivize the Upload of a NameSpace

Information modelling represents a valuable commodity for industrial applications, and while the Cloud Library creates an opportunity for re-use, it should not preclude monetization of the NameSpaces it makes available. The Cloud Library may be used in conjunction with an external marketplace that brokers access to downloads, as well as a mechanism for identifying, storing, presenting and requiring agreement to, appropriate licenses.

Common metadata fields should be considered for tagging and linking NameSpaces to facilitate search and discovery. Marketplace implementations may consider augmenting this base set of data to include popularity ratings, reviews, and curation information.

10 Authentication, Authorization, Download Tracking

The Cloud Library shall have built-in authentication and authorization using HTTP authorization headers. For unattended downloads of nodesets, authorization validation needs to be additionally supported. Supplied email addresses must be corporate-controlled, and addresses entered must be confirmed before access is granted.

The Cloud Library shall optionally have authorization on a per-nodeset basis, i.e., the nodeset owner can specify who to give access to. Access control can be individuals, organizations, or user types).

The Cloud Library shall optionally have download tracking built-in, which logs the user’s actions.

11 Access Control

11.1 Sovereignty

To create a workable marketplace, NameSpace owners’ IP rights must be protected when they make their NameSpaces available via the Cloud Library. NameSpace sovereignty is a fundamental aspect of the Cloud Library as such, NameSpace Owners will remain in control of their NameSpaces. Examples of such control factors include who has access to each NameSpace and on what terms (ex. financial terms, geographic restrictions, duration, and so on).

11.2 Licensing Terms & Conditions

The primary method of protecting owners’ IP rights will be via Cloud Library licensing terms and conditions (owner supplied). The Cloud Library will enforce individual agreements being accepted before download starts.

12 Monetization

The Cloud Library can optionally implement the mechanisms required to facilitate the commercial transactions needed to gain access to specific NameSpaces, and to track and log the specifics of the agreed to terms of usage. These services may be provided by trusted 3rd Parties specialized in payment processing, data access management, etc.

13 Production Readiness

13.1 Input Validation

All Cloud Library REST calls shall be validated, and appropriate HTTP error codes returned, according to the OpenAPI specification. Additionally, the uploaded NameSpaces (especially the ones not standardized and released through the OPC Foundation that have already gone through validation) shall be semantically validated using a new nodeset validator (that can be optionally built), where possible. For non-standardized NameSpaces, a subset of the OPC Foundation’s CTT test tool may be used for additional validation.

13.2 Ratings

The Cloud Library shall have a rating system built in (for example “stars”) giving users a quick overview about high quality NameSpaces, similar to what GitHub uses for repositories today.

13.3 Content Owner Insights

Content owners (i.e., the data model uploader persona) shall have access to basic metadata which helps to understand how popular their NameSpace is. This can be a great source of customer data that can flow into product management decisions regarding the assets being described by the uploaded NameSpace from a particular source.

13.4 Logging

The Cloud Library shall have operations logging built-in, without capturing personal identifiable information or credentials.

13.5 Query Performance Insights (Operations)

Operators of the Cloud Library shall have access to performance data specifying how many NameSpaces were returned for a particular query and the time it took to execute it. This will give the operator an indication of how the database scales and if adjustments to its resources must be made.

Agreement of Use

COPYRIGHT RESTRICTIONS

This document is provided "as is" by the OPC Foundation and CESMII.

Right of use for this specification is restricted to this specification and does not grant rights of use for referred documents.

Right of use for this specification will be granted without cost.

This document may be distributed through computer systems, printed or copied as long as the content remains unchanged and the document is not modified.

OPC Foundation and CESMII do not guarantee usability for any purpose and shall not be made liable for any case using the content of this document.

The user of the document agrees to indemnify OPC Foundation and CESMII and their officers, directors and agents harmless from all demands, claims, actions, losses, damages (including damages from personal injuries), costs and expenses (including attorneys' fees) which are in any way related to activities associated with its use of content from this specification.

The document shall not be used in conjunction with company advertising, shall not be sold or licensed to any party.

The intellectual property and copyright is solely owned by the OPC Foundation and CESMII.

PATENTS

The attention of adopters is directed to the possibility that compliance with or adoption of OPC or CESMII specifications may require use of an invention covered by patent rights. OPC Foundation or CESMII shall not be responsible for identifying patents for which a license may be required by any OPC or CESMII specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. OPC or CESMII 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 NOR CESMII 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 NOR CESMII 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 combination of CESMII and OPC Foundation shall at all times be the sole entities 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 as specified within this document. 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 CESMII or 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 Germany.

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.

Revision 1.0.x Highlights

The following table includes the issues resolved with revisions of 1.0.