1 Scope

This document defines the OPC UA OPEN-SCS companion specification. OPEN-SCS is a set of interface specifications for exchanging product serialization information across an enterprise and their contract partners from the packaging process to the distribution warehouse. The interface specifications are called the OPEN-SCS Packaging Serialization Specification (PSS).

The PSS defines an abstract information model and transaction model, which can be implemented in multiple specific technologies, such as OPC UA, XML and Web services. This standard is the OPC UA technology implementation of the Open Serialization Communication Standard (OPEN-SCS) Packaging Serialization Specification (PSS).

2 Normative References

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

OPEN-SCS Packaging Serialization Specification (PSS) 1.0

https://www.open-scs.org/

OPC 10000-1, OPC UA Specification: Part 1 – Overview and Concepts

3 Terms, definitions and conventions

3.1 Overview

It is assumed that basic concepts of OPC UA information modelling are understood in this specification. This specification will use these concepts to describe the OPEN-SCS object models. The concepts and terms used to describe the OPC UA Information models are defined in other parts and listed in the following sections. Note that OPC UA terms and terms defined in this standard are italicized in the specification.

For the purposes of this document, the terms and definitions given in OPC 10000-1 and OPC 10000-3 as well as the following apply.

3.2 OPC UA for OpenSCS Terms

3.2.1 Aggregation

A collection of serialized child objects (such as bottles or cases) in a serialized parent object (such as a case, container, or pallet)

3.2.2 Commissioned Label

A printed label that is associated with a specific product or package.

3.2.3 Information Provider

An application or system which responds to a request for a service or information from an Information Requester or provides information to an Information Receiver. In this OPC UA implementation the Information Provider is an OPC UA Server.

3.2.4 Information Receiver

An application or system which receives information from an Information Provider and may provide an acknowledgement. In this OPC UA implementation the Information Provider is an OPC UA Server.

3.2.5 Information Requestor

An application or system which requests a service or information and receives responses from an Information Provider. In this OPC UA implementation the Information Requestor is an OPC UA client.

3.2.6 Printed Label

A serial number on a human and machine-readable label that is not yet associated with a specific package or aggregation.

3.2.7 Serial Number

A string of characters with a defined syntax used for purposes of establishing uniqueness between otherwise identical objects. Serial numbers may be numeric, alphanumeric and contain symbols.

3.2.8 Serialized Identifier

A unique identifier (serial number) comprising of a string of characters within a defined format that is associated with a physical object such that no two physical objects are associated with the same string of characters. Abbreviated as SID, this could be an EPC according to the GS1 standard.

3.3 Abbreviations and symbols

3.4 OPC UA Notation

This standard uses the ModellingRules OptionalPlaceholder and MandatoryPlaceholder to define instance declarations, and defines a rule that the BrowseName of instance declarations having an OptionalPlaceholder or MandatoryPlaceholder ModellingRule be enclosed in angle brackets (<>). Originally, this rule is defined in OPC 10000-3 as a recommendation. This naming rule is also used in the description of a table. The BrowseName of a Node that has OptionalPlaceholder or MandatoryPlaceholder ModellingRule are described with angle brackets, which denotes that the name is not fixed. For example, BrowseName of Property is described as <PropertyName> in graphical notation and tables results in a Property that can have any name.

4 Concept

4.1 OPEN-SCS Overview

For OPC UA users that may not be familiar with OPEN-SCS the following section provides a brief overview of key elements of serialization. See the OPEN-SCS Packaging Serialization Specification (PSS) 1.0 documentation for a full description of a serialization management system.

4.1.1 Serial Number Lifecycle

This document defines the serialization management OPC UA interfaces to support global regulation reporting requirements and the packaging serialization management process from the enterprise serialization manager to the packaging lines for serialized products.

Healthcare supply chain systems are being deployed to meet the product serialization and track-and-trace country regulations and laws to address the widespread healthcare counterfeiting issues. The regulations and laws require healthcare manufacturers to apply unique serialized identifiers to individual instances of physical objects for supply chain serialization and track-and-trace purposes.

Unique serialized identifiers may be generated within a company, may be obtained from regulatory authorities, or may be obtained by contract manufacturers from product owning company, depending on the regulations or laws that apply to the product and the intended market.

The key concepts of OPEN-SCS PSS are Serial Numbers, Serial Number Collections, Label Collections and Serialized Identifiers.

A Serial Number is a string of characters with a defined syntax used for purposes of establishing uniqueness between otherwise identical objects.

A Serial Number Collection is a collection of Serial Numbers which have not yet been printed onto a label. Serial Number Collections are defined to provide for efficient exchange of collections of Serial Numbers.

A Label Collection is a collection of Serial Numbers with the same state and associated information needed for the label such as lot numbers, expiration dates and manufactured dates. Label Collections are defined to provide for efficient exchange of collections of Serial Numbers with the associated other information needed for the label.

A Serialized Identifier is a unique identifier (serial number) comprising of a string of characters within a defined format that is associated with a physical object such that no two physical objects are associated with the same string of characters. Abbreviated as SID. An example of an SID is an Electronic Product Code (EPC) that is a unique identifier attached to a class of product or aggregation such a pallet, with the addition of a unique serial number for each product or aggregation.

The general lifecycle of a Serial Number is from unassigned, to associated with a production run, to representation on printed label, to a commissioned label, as shown in Figure 1. When the serial number is printed it is combined with other information required on the label, for example: product code, lot number, expiration date, etc. Figure 1 illustrates the stages of Serial Numbers:

An unassigned Serial Number, where the number has not been assigned to any specific product, production order, or packaging run.

A provisioned Serial Number containing the serial number in a digital form that has been associated to a specific product, package type, production order, or packaging run.

The Serial Number as it is printed on a label and combined with other label information, but not yet applied to the physical product, called a printed label.

The printed label as it is applied to the physical product, called a commissioned label, and identified as a Serialized Identifier (SID).

In some cases, the activity of serialization includes the packing of serialized child objects (packages) into serialized and parent objects (containers) in a process identified as aggregation. Serialization aggregation events usually start with the Lowest Saleable Unit (LSU) (e.g. bottle or blister pack) and potentially include multiple levels in the packaging hierarchy (such as a pallet made up of cases, cases made up of packages, and packages made up of blister packs, with serialization information defined at each level of the hierarchy.) Aggregation Serial Numbers follow the same lifecycle as product Serial Numbers.

4.1.2 Serialization Activities

The activities of serialization are illustrated in Figure 2. Each of the activities may be performed for each level of a packaging aggregation hierarchy, such as separate serial number management, provisioning, printing, and commissioning for pallet labels, and similar activities for cases and cartons. The scope of the OPC UA OPEN-SCS implementation are information exchanges between the activities. Not all communication exchanges are shown in Figure 2.

Global Serial Number Management – This is the activity of creating, allocating, registering, and general management of Serial Numbers. This activity may be local (within a company) or remote in a regulatory agency or a third party. Generally, this activity is global in scope, even within a company, in order to ensure that uniqueness of Serial Numbers. Global serial number management may deal with any Serial Number state, but generally deal with unassigned, invalid, scrapped, destroyed, commissioned, sampled, or inactive states.

Local Serial Number Management – This is the activity of managing available Serial Numbers, assigning Serial Numbers to production of specific products, packages, or aggregations. Generally, this is local in scope (within a company, a site within the company, or area within the site) in order to meet performance requirements in obtaining Serial Numbers for provisioning. If locally managed Serial Numbers which have not been commissioned and will not be used, they are generally returned to global serial number management for possible reuse.

Serial Number Provisioning – This is the activity of associating a Serial Numbers with a specific production run. This activity is generally performed locally (within a company, a site within the company, or area within the site), but may be done by a third party that is pre-printing labels. This activity may be done some time before the label is printed, because of limitations in the printing system, or just-in-time if available on the printing system. If Serial Numbers cannot be used (such as more are provisioned than are needed for the production run), then the unused numbers are either returned to local or global serial management for possible reuse or reported as invalid for tracking purposes.

Label Printing – This is the activity of printing the Serial Numbers and related information on a label. This is usually in the form of a 1D barcode, QR (2D), DataMatrix or RFID tag. If the printed labels are scrapped before they are commissioned, then the Serial Numbers associated with the labels are usually returned to local or global serial number management indicating that labels with the serial numbers were printed, but the labels were scrapped.

Label Commissioning – This is the activity of associating a label with a product or package. Typically this involves attachment of the label to the product or package. If the association is later removed and the label scrapped, such as the label being removed from the product/package because of rework of the product, then the Serial Numbers on the scrapped label are reported to local or global serial number management for tracking. Once the Serial Number is associated with a product, package, or aggregation it is known as a SID.

Product Delivery – This is the activity of shipping the product/package out of the custody of production to other parts of the business or the supply chain. If the product is destroyed or otherwise made non-usable, then the destroyed Serial Numbers are usually returned to global serial number management for tracking. Often the transfer of custody is to local warehouses or shipping departments.

Each of the activities may be performed for each level of a packaging aggregation hierarchy, such as separate serial number management, provisioning, printing, and commissioning for pallet labels, and similar activities for cases and cartons.

4.1.3 Serial Number Information Model

The information objects identified in Figure 3 are used to describe the information used in the serialization services.

SID Class - An SID Class represents information specified by global industry standards, governmental standards or regulation used in representation of a Serial Number in an SID. Each standard or regulation defines one or more SID Classes including the specification of the syntax of the SID and the allowed character set, the internal structure and the intended area of use.

SID Class Property - Additional information associated with the SID Class is represented in name/value pairs and defined SID Class Properties.

Collection – An abstract class that is a representation of a list of Serial Numbers is defined as a Collection.

Serial Number Collection - A representation of a list of numbers from which Serial Numbers may be obtained is defined as a Serial Number Collection.

Serial Number - A string of characters with a defined syntax used for purposes of identification to be used for serialization purposes is defined as a Serial Number.

Label Collection - A set of Serial Numbers which have been, or will be encoded onto a label, with all the same state and associated to a specific production or packaging run is defined as a Label Collection.

Label Property – Additional information associated with a label for a SID Class Property is defined as a Label Property.

Serial Number Pool - A representation of a managed collection of Serial Numbers which may be associated with multiple SID Classes, and which have selection criteria defined to allow selection of sets of numbers for specific purposes is defined as a Serial Number Pool.

Pool Selection Criteria - A set of key/value pairs which represent selection criteria that may be used to determine what set of Serial Numbers are returned from a serial number request service is defined as a Pool Selection Criteria.

4.1.4 Serial Number State and Event Model

The state and event model for a Serial Number shall follow the model displayed in Figure 4.

Each Serial Number state is defined in Table 1.

Each Serial Number event is defined in Table 2. The events occur as a result of a business or process step.

4.1.5 Serialization Functions

The OPEN-SCS PSS defines a technology independent set of functions that are to be provided to support serialization, and information on Serial Number Pools and SID Classes.

The following table defines the functions identified in the OPEN-SCS PSS, the method defined by this specification, and definition of the method’s use:

4.2 OPC UA Summary

4.2.1 Introduction

For OPEN-SCS users that may not be familiar with OPC UA the following section provides a brief overview of key features that OPC UA provides.

4.2.2 What is OPC UA?

OPC UA is an open and royalty free set of standards designed as a universal communications framework. While there are numerous communication solutions available, OPC UA has several 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 powerful semantic models such as OPEN-SCS, OPC UA makes it easier for end users to access data via generic commercial application.

The OPC UA model is scalable from small devices to ERP systems. OPC UA devices 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.

4.2.3 Basics of OPC UA

As an Open Standard, OPC UA is based on standard Internet technologies – TCP/IP, HTTP, Ethernet, and XML.

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. This specification is an example of an OPC UA Information Model designed to meet the needs of developers and users.

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 are shown in Figure 5.

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.4 Information Modelling in OPC UA

4.2.4.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 web 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 6.

Object and Variable Nodes are called Instance Nodes and they always reference a Type Definition (ObjectType or VariableType) Node which describes their semantics and structure. Figure 7 illustrates the relationship between an Instance and its Type Definition.

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 7 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 child. 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 devices implement.

OPC UA also supports the concept of sub typing. This allows a modeler 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. For example, the modeler may decide that the existing ObjectType in some cases needs an additional variable. The modeler can create a Subtype of the object and add the variable. A client that is expecting the parent type can treat the new Type as if it was of the parent Type. With regard to DataTypes, if a variable is defined to have a numeric value, a sub type could restrict the Value to a float.

References allow Nodes to be connected together in ways that describe their relationships. All References have a ReferenceType that specifies the semantics of the relationship. References can be hierarchical or non-hierarchical. Hierarchical references are used to create the structure of Objects and Variables. Non-hierarchical are used to create arbitrary associations. Applications can define their own ReferenceType by creating Subtypes of the existing ReferenceType. Subtypes inherit the semantics of the parent but may add additional restrictions. Figure 8 depicts several references connecting different Objects.

The figures above use a notation that was developed for the OPC UA specification. The notation is summarized in Figure 9. UML representations can also be used; however, the OPC UA notation is less ambiguous because there is a direct mapping from the elements in the figures to Nodes in the AddressSpace of an OPC UA server.

A complete description of the different types of Nodes and References can be found in OPC 10000-3 and the base OPC UA AddressSpace is described in OPC 10000-5.

OPC UA specification defines a very wide range of functionality in its basic information model. It is not expected that all Clients or Servers support all functionality in the OPC UA specifications. OPC UA includes the concept of profiles, which segment the functionality into testable certifiable units. This allows the development of companion specification (such as OPC UA for ISA-95) that can describe the subset of functionality that is expected to be implemented. The profiles do not restrict functionality, but generate requirements for a minimum set of functionality (see OPC 10000-7).

The OPC Foundation also defines a set of information models that provide a basic set of functionality. The Data Access specification (see OPC 10000-8) provides a basic information model for typical data. The Alarm and Condition specification (see OPC 10000-9) defines a standard information model for Alarms and Conditions. The Programs specification (see OPC 10000-10) defines a standard information model for extending the functionality available via method calls and state machines. The Historical Access specification (see OPC 10000-11) defines the information model associated with Historical Data and Historical Events. The aggregates specification (see OPC 10000-13) defines a series of standard aggregate functions that allow a Client to request summary data. Examples of aggregates include averages, minimums, time in state, Standard deviation, etc.

4.2.4.2 Namespaces

OPC UA allows information from many different sources to be combined into a single coherent address space. Namespaces are used to make this possible by eliminating naming and id conflicts between information from different sources. Namespaces in OPC UA have a globally unique string called a NamespaceUri and a locally unique integer called a NamespaceIndex. The NamespaceIndex is only unique within the context of a Session between an OPC UA Client and an OPC UA Server. All of the web services defined for OPC UA use the NamespaceIndex to specify the Namespace for qualified values.

There are two types of values in OPC UA that are qualified with Namespaces: NodeIds and QualifiedNames. NodeIds are globally unique identifiers for Nodes. This means the same Node with the same NodeId can appear in many Servers. This, in turn, means Clients can have built in knowledge of some 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. The BrowseName is used to identify the children within a TypeDefinitions. Instances of a TypeDefinition are expected to have children with the same BrowseNames. TypeDefinitions are not allowed to have children with duplicate BrowseNames; however, Instances do not have that restriction.

4.2.4.3 Companion Specifications

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.

5 Modelling Approach of OPEN-SCS

The modelling approach for generating an UA model from the OPEN-SCS PSS specification follows the following general concepts.

An OPC UA server may support the activities of Local Serial Number Management, Serial Number Provisioning, Label Printing, Label Commissioning, serial number, SID, label, and aggregation event management. The server contains one or more Serial Number Pools and zero or more SID Class objects.

The functions listed in the OPEN-SCS PSS are implemented as methods on Serial Number Pool Manager objects, Serial Number Event Manager objects and Aggregation Event Manager objects within an OPC UA server.

6 OPEN-SCS Data Representation Model

6.1 General

The OPC UA OPEN-SCS Information Model is a representation of the OPEN-SCS data model in OPC Methods, ObjectTypes, VariableTypes, DataTypes and ReferenceTypes.

This model generates standard types. All OPEN-SCS types will be defined in their own namespace and will begin with “OPENSCS”

The following conventions apply to ObjectType, VariableType and DataType naming:

All ObjectTypes include “ObjectType” as part of the name

All DataTypes that are structures include “DataType” as part of the name, this is to be able to differentiate them from any VariableTypes that will just end in Type.

All enumerations will end in “Enum”, to clearly identify that it is an enumeration.

All base DataTypes (int32, float, …) used in the OPC UA server will be those defined in OPC UA, see OPC 10000-6 for more detail on the representation of the datatypes.

6.2 Instance AddressSpace

Figure 10 provides an example of the instance object model for OPEN-SCS.

The OPC UA Server shall have an OPENSCSObjects folder under the OPC defined Objects folder on a UA server. This folder shall contain instances of OPENSCSPoolObjectType, OPENSCSEventManagerType, and/or OPENSCSSIDClassType.

6.3 ObjectTypes

6.3.1 OPENSCSPoolManagerObjectType

The OPEN-SCS model for pool management when adapted to OPC UA results in a number of methods attached to a pool manager object, as illustrated in Figure 11.

A pool manager may manage one or more pools of serial numbers. Depending on the profile supported the pool manager may:

Return serial numbers of the appropriate state based on a request method from a specified pool in the server (SNRequestUnassigned, SNRequestUnallocated and SNRequestAllocated).

Accept returned serial numbers of the appropriate state based on a return method to a specified pool in the server (SNReturnUnallocated and SNReturnAllocated).

Accept unsolicited serial number of a specified state to be added to the server’s pool (SNtoUnallocated, SNtoAllocated and SNtoEncoded).

The pool manager may use pool selection criteria to determine which pool is to be used on a method call. The pool selection criteria available from the pool manager are available in the PoolSelectionCriteria key/value pairs. The selection criteria are read only and are defined by the configuration of the pool manager server.

The formats for the returned serial number are defined by the SNFormat parameter and must match a serial number format defined in the pool manager server.

6.3.1.1 OPENSCSPoolManagerObjectType Definition

Table 4 is the AddressSpace definition of an OPENSCSPoolManagerObjectType.

PoolSelectionCriteria - Defines a read-only set of key value pairs which define the selection criteria used to determine the pool from which serial numbers are requested or returned. For example: “GTIN”, “SCSCGP”, and “PoolID”.

SNFormat – Defines a read-only set of possible serial number formats that may be used on pushes, requests or returns of serial numbers. For example: “SERIALONLY”, “LITERAL”, and “EPCURI”. As a minimum the value “SERIALONLY” shall be supported.

MaxSNRequestable - Defines a read-only maximum number of serial numbers which can be requested in a single method call. If the request methods are not supported, this number shall be zero.

MaxSNReturnable - Defines a read-only maximum number of serial numbers which can be returned in a single method call. If the return methods are not supported, this number shall be zero.

MaxSBPushable - Defines a read-only maximum number of serial numbers which can be pushed to the server in a single method call. If the push methods (SNtoUnallocated, SNtoAllocated, SNtoEncoded) methods are not supported, this number shall be zero.

6.3.1.2 SNRequestUnassigned Method

SNRequestUnassigned –This Method requests unassigned serial numbers from an OPC UA Server that is performing serial number management for a specific Serial Number Collection.

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

Signature

	SNRequestUnassigned (
		[in]	String				SNCollectionID
	[in]	UInt32				Count
	[in]	String				SNFormat
	[in]	OPENSCSKeyValueDataType[]	PoolSelectionCriteria
	[in]	String			   	RequestToken
	[out]	OPENSCSReturnEnum	   	ReturnStatus
	[out]	OPENSCSSNCollectionDataType 	SNCollection
	[out]	String			   	ReturnedRequestToken
	);

Method Result Codes are defined as part of the Call service (see OPC 10000-4 and Table 95).

6.3.1.3 SNRequestUnallocated Method

SNRequestUnassigned –This method requests unallocated serial numbers from an OPC UA Server that is performing serial number management for a specific Serial Number Pool.

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

Signature

	SNRequestUnallocated (
		[in]	String				SNCollectionID
	[in]	UInt32				Count
	[in]	String				SNFormat
	[in]	OPENSCSKeyValueDataType[]	PoolSelectionCriteria
	[in]	String			   	RequestToken
	[out]	OPENSCSReturnEnum	   	ReturnStatus
	[out]	OPENSCSSNCollectionDataType 	SNCollection
	[out]	String			   	ReturnedRequestToken
	);

Method Result Codes are defined as part of the Call service (see OPC 10000-4 and Table 95).

6.3.1.4 SNRequestAllocated Method

SNRequestAllocated –This method requests allocated serial numbers from an OPC UA Server that is performing serial number management for a specific Serial Number Pool.

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

Signature

	SNRequestAllocated (
		[in]	String				SNCollectionID
	[in]	UInt32				Count
	[in]	String				SNFormat
	[in]	OPENSCSKeyValueDataType[]	PoolSelectionCriteria
	[in]	String			   	RequestToken
	[out]	OPENSCSReturnEnum	   	ReturnStatus
	[out]	OPENSCSSNCollectionDataType SNCollection
	[out]	String			   	ReturnedRequestToken
	);

Method Result Codes are defined as part of the Call service (see OPC 10000-4 and Table 95).

6.3.1.5 SNReturnUnallocated Method

SNReturnUnallocated – This method sends unallocated serial numbers back to an OPC UA Server that is performing serial number management of unassigned serial numbers for a specific Serial Number Pool.

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

Signature

	SNReturnUnallocated (
		[in]	OPENSCSSNCollectionDataType	SNCollection
	[in]	OPENSCSKeyValueDataType[]	PoolSelectionCriteria
	[in]	String				SNFormat
	[out]	OPENSCSReturnEnum		ReturnStatus
	);

Method Result Codes are defined as part of the Call service (see OPC 10000-4 and Table 95).

6.3.1.6 SNReturnAllocated Method

SNReturnAllocated – This method sends allocated serial numbers back to an OPC UA Server that is performing serial number management of unallocated serial numbers for a specific Serial Number Pool.

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

Signature

	SNReturnAllocated (
		[in]	OPENSCSSNCollectionDataType	SNCollection
	[in]	OPENSCSKeyValueDataType[]	PoolSelectionCriteria
	[in]	String				SNFormat
	[out]	OPENSCSReturnEnum		ReturnStatus
	);

Method Result Codes are defined as part of the Call service (see OPC 10000-4 and Table 95).

6.3.1.7 SNtoUnallocated Method

SNtoUnallocated – This method sends unsolicited serial numbers to be placed into the unallocated state to an OPC UA Server that is performing serial number management for a specific Serial Number Pool.

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

Signature

	SNtoUnallocated (
	[in]	OPENSCSSNCollectionDataType 	SNCollection
	[in]	OPENSCSKeyValueDataType[]	PoolSelectionCriteria
	[in]	String				SNFormat
	[out]	OPENSCSReturnEnum	  	ReturnStatus
	);

Method Result Codes are defined as part of the Call service (see OPC 10000-4 and Table 95).

6.3.1.8 SNtoAllocated Method

SNtoAllocated – This method sends unsolicited serial numbers to be placed into the reserved state to an OPC UA Server that is performing serial number management for a specific Serial Number Pool.

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

Signature

	SNtoAllocated (
	[in]	OPENSCSSNCollectionDataType 	SNCollection
	[in]	OPENSCSKeyValueDataType[]	PoolSelectionCriteria
	[in]	String				SNFormat
	[out]	OPENSCSReturnEnum	  	ReturnStatus
	);

Method Result Codes are defined as part of the Call service (see OPC 10000-4 and Table 95).

6.3.1.9 SNtoEncoded Method

SNtoEncoded – This method sends unsolicited serial numbers to be placed into the encoded state to an OPC UA Server that is performing serial number management for a specific Serial Number Pool. It may include label properties associated with the encoding run.

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

Method Signature

	SNtoEncoded (
		[in]	OPENSCSSNCollectionType	SNCollection
	[in]	OPENSCSKeyValueDataType[]	PoolSelectionCriteria
	[in]	String				SNFormat
	[out]	OPENSCSReturnEnum		ReturnStatus
	);

Method Result Codes are defined as part of the Call service (see OPC 10000-4 and Table 95).

6.3.2 OPENSCSEventManagerObjectType

The OPEN-SCS model for event management when adapted to OPC UA results in several methods attached to an event manager object.

The event manager receives unsolicited events through the event methods. All but one of the event methods have the same method signature. The specific methods supported by an event manager are defined in profiles.

Table 21 is the AddressSpace definition of an OPENSCSEventManagerObjectType.

MaxEvents - Defines the read-only maximum number of SN, Label, or SID events which can be received in a single method call.

MaxEPCISObjectEventSIDs – Defines the read-only maximum number of SIDs (SGTINs) in EPCIS object events that may be written in a single EPCISStream file transfer.

MaxEPCISAggregationEvents – Defines the read-only maximum number of EPCIS aggregation events that may be written in a single EPCISStream file transfer

6.3.2.1 EPCISStream Object

The EPCIS file transfer services are provided through a TemporaryFileTransferType, defined in OPC 10000-5. The transferred information is in the form of an EPCIS structured XML file, as described in Annex C. The EPCISStream object is used to push EPCIS Object Events (with various Business Steps in business process such as “urn:epcglobal:cbv:bizstep:commissioning”, “urn:epcglobal:cbv:bizstep:inspecting”, “urn:epcglobal:cbv:bizstep:packing”, “urn:epcglobal:cbv:bizstep:shipping”) and EPCIS Object Aggregation Events (with Business Steps as ‘urn:epcglobal:cbv:bizstep:packing’) to an OPC UA EventManager server.

The OPC UA TemporaryFileTransferType method GenerateFileForWrite is used to start the write file transaction. A successful call of this Method creates a temporary FileType Object and returns the NodeId of this Object and the file handle to access the Object. (From OPC 10000-5). The returned FileType object is not browsable in the AddressSpace and can only be accessed with the NodeId and FileHandle returned by the method in the same Session. The returned FileType Object is used to transfer the file stream between OPC UA Client and Server.

The EPCIS structured file is then transferred in blocks to the Event Manager server using the Write method. Once the transfer is complete the CloseAndCommit method is used to close the transfer, and the EventManager processes the transferred information.

The general use of the EPCISStream to transfer an EPCIS file is illustrated in Figure 13.

The GenerateFileForRead method of the EPCISStream object is not specified and shall always return an error from the EventManager.

The generateOptions is used for the GenerateFileForWrite to transfer arguments to the EventManager server that match the arguments used in the EventManager server’s event methods.

An EventManager Server shall specify OPENSCSEventStreamArgumentDataType as the concrete DataType of for the Argument Structure for the generateOptions argument in the instance of the GenerateFileForWrite method.

6.3.2.2 SNInvalidatingEvent Method

SNInvalidatingEvent – This method is used to send unsolicited notification of Serial Number Invalidating events to an OPC Server that is performing serial number event management.

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

Signature

	SNInvalidatingEvent (
		[in]	OPENSCSSNCollectionDataType 	SNCollection 
	[in]	String				SNFormat
		[in]	OPENSCSKeyValueDataType[]	OPENSCSEventContext
	[out]	OPENSCSReturnEnum	    	ReturnStatus
	);

Method Result Codes are defined as part of the Call service (see OPC 10000-4 and Table 95).

6.3.2.3 LabelsEncodingEvent Method

LabelsEncodingEvent – This method is used to send unsolicited notification of Labels Encoding events to an OPC Server that is performing label event management.

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

Signature

	LabelsEncodingEvent (
		[in]	OPENSCSLabelCollectionDataType	LabelCollection 
	[in]	String					SNFormat
		[in]	OPENSCSKeyValueDataType[]		OPENSCSEventContext
	[out]	OPENSCSReturnEnum	    		ReturnStatus
	);

Method Result Codes are defined as part of the Call service (see OPC 10000-4 and Table 95).

6.3.2.4 LabelsScrappingEvent Method

LabelsScrappingEvent – This method is used to send unsolicited notification of Labels Destroying events to an OPC Server that is performing label event management.

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

Signature

	LabelsScrappingEvent (
		[in]	OPENSCSLabelCollectionDataType	LabelCollection 
	[in]	String					SNFormat
		[in]	OPENSCSKeyValueDataType[]		OPENSCSEventContext
	[out]	OPENSCSReturnEnum	    		ReturnStatus
	);

Method Result Codes are defined as part of the Call service (see OPC 10000-4 and Table 95).

6.3.2.5 LabelsInspectingEvent Method

LabelsInspectingEvent – This method is used to send unsolicited notification of Label Inspecting events to an OPC Server that is performing label event management.

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

Signature

	LabelsInspectingEvent (
		[in]	OPENSCSLabelCollectionDataType	LabelCollection 
	[in]	String					SNFormat
		[in]	OPENSCSKeyValueDataType[]		OPENSCSEventContext
	[out]	OPENSCSReturnEnum	    		ReturnStatus
	);

Method Result Codes are defined as part of the Call service (see OPC 10000-4 and Table 95).

6.3.2.6 LabelsSamplingEvent Method

LabelsSamplingEvent – This method is used to send unsolicited notification of Label Sampling events to an OPC Server that is performing label event management.

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

Signature

	LabelsSamplingEvent (
		[in]	OPENSCSLabelCollectionDataType	LabelCollection 
	[in]	String					SNFormat
		[in]	OPENSCSKeyValueDataType[]		OPENSCSEventContext
	[out]	OPENSCSReturnEnum	    		ReturnStatus
	);

Method Result Codes are defined as part of the Call service (see OPC 10000-4 and Table 95).

6.3.2.7 SIDCommissioningEvent Method

SIDCommissioningEvent – This method is used to send unsolicited notification of SID Commissioning events to an OPC Server that is performing SID event management.

The signature of this Method is specified below.

Table 32 and Table 33 specify the Arguments and AddressSpace representation, respectively.

Signature

	SIDCommissioningEvent (
		[in]	OPENSCSLabelCollectionDataType	LabelCollection 
	[in]	String					SNFormat
		[in]	OPENSCSKeyValueDataType[]		OPENSCSEventContext
	[out]	OPENSCSReturnEnum	    		ReturnStatus
	);

Method Result Codes are defined as part of the Call service (see OPC 10000-4 and Table 95).

6.3.2.8 SIDDestroyingEvent Method

SIDDestroyingEvent – This method is used to send unsolicited notification of SID Destroying events to an OPC Server that is performing SID event management.

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

Signature

	SIDDestroyingEvent (
		[in]	OPENSCSLabelCollectionDataType	LabelCollection 
	[in]	String					SNFormat
		[in]	OPENSCSKeyValueDataType[]		OPENSCSEventContext
	[out]	OPENSCSReturnEnum	    		ReturnStatus
	);

Method Result Codes are defined as part of the Call service (see OPC 10000-4 and Table 95).

6.3.2.9 SIDShippingEvent Method

SIDShippingEvent – This method is used to send unsolicited notification of SID Shipping events to an OPC Server that is performing SID event management.

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

Signature

	SIDShippingEvent (
		[in]	OPENSCSLabelCollectionDataType	LabelCollection 
	[in]	String					SNFormat
		[in]	OPENSCSKeyValueDataType[]		OPENSCSEventContext
	[out]	OPENSCSReturnEnum	    		ReturnStatus
	);

Method Result Codes are defined as part of the Call service (see OPC 10000-4 and Table 95).

6.3.2.10 SIDInspectingEvent Method

SIDInspectingEvent – This method is used to send unsolicited notification of SID Inspecting events to an OPC Server that is performing SID event management.

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

Signature

	SIDInspectingEvent (
		[in]	OPENSCSLabelCollectionDataType	LabelCollection 
	[in]	String					SNFormat
		[in]	OPENSCSKeyValueDataType[]		OPENSCSEventContext
	[out]	OPENSCSReturnEnum	    		ReturnStatus
	);

Method Result Codes are defined as part of the Call service (see OPC 10000-4 and Table 95).

6.3.2.11 SIDDecommissioningEvent Method

SIDDecommissioningEvent – This method is used to send unsolicited notification of SID Decommissioning events to an OPC Server that is performing SID event management.

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

Signature

	SIDDecommissioningEvent (
		[in]	OPENSCSLabelCollectionDataType	LabelCollection 
	[in]	String					SNFormat
		[in]	OPENSCSKeyValueDataType[]		OPENSCSEventContext
	[out]	OPENSCSReturnEnum	    		ReturnStatus
	);

Method Result Codes are defined as part of the Call service (see OPC 10000-4 and Table 95).

6.3.3 OPENSCSAggregationManagerObjectType

The OPEN-SCS model for aggregation management when adapted to OPC UA results in two methods attached to an aggregation manager object.

The aggregation manager receives unsolicited events through the aggregation methods. The aggregation methods have the same method signature. The specific methods supported by an aggregation manager are defined in profiles.

Table 42 is the AddressSpace definition of an OPENSCSAggregationManagerObjectType.

MaxAggregationEvents - Defines a read-only maximum number of AggregationElements for packing and unpacking events which can be received in a single method call.

6.3.3.1 AggregationPackingEvent Method

AggregationPackingEvent – This method is used to send unsolicited notification of Aggregation Packing events to an OPC Server that is performing aggregation management.

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

Signature

	AggregationPackingEvent (
	  [in] OPENSCSAggregationDataType[] 	AggregationElement
	  [in] String					ParentSNFormat
	  [in] String					PackedElementSNFormat
	  [in] OPENSCSKeyValueDataType[]		AggregationContext
 	  [out] OPENSCSReturnEnum	    		ReturnStatus
	);

Method Result Codes are defined as part of the Call service (see OPC 10000-4 and Table 95).

6.3.3.2 AggregationUnpackingEvent Method

AggregationUnpackingEvent – This method is used to send unsolicited notification of Aggregation Unpacking events to an OPC Server that is performing aggregation management.

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

Signature

	AggregationUnpackingEvent (
	  [in] OPENSCSAggregationDataType[] 	AggregationElement
	  [in] String					ParentSNFormat
	  [in] String					PackedElementSNFormat
	  [in] OPENSCSKeyValueDataType[]		AggregationContext
 	  [out] OPENSCSReturnEnum	    		ReturnStatus
	);

Method Result Codes are defined as part of the Call service (see OPC 10000-4 and Table 95).

6.3.4 OPENSCSSIDClassObjectType

SID Class objects are used to obtain information about the SID Classes that may be supported by a server. This information is read-only and is defined by the server, as illustrated in Figure 15.

Table 47 defines the structure of an OPENSCSSIDClassObjectType.

SIDClassID - An identification of the SID Class of the Serial Number Collection. For example: GS1:SSCC

SIDClassOwner - An identification of the owning, or controlling organization, which defines the information in the SID Class. For example: GS1The Global Language of Business, www.gs1.org

SIDClassDescription - Additional information and description about the SID Class.

SyntaxSpecification - Defines the rules for the syntax of a SID. The format is not defined in this specification and must be negotiated between Information Providers and Information Requesters during design or change management of a system.

AllowedCharacterSet - A string containing the allowed characters that may be used in representing the Serial Number in a SID.

IntendedUse - A string containing a natural language description of the use of the SID. Defines the intended use of the SID Class, such as logistics tracking or pallet aggregations.

SIDClassProperty - An array of property elements, each of which may have associated label property definitions.

6.4 DataTypes

6.4.1 OPENSCSAggregationDataType

The OPENSCSAggregationDataType is a type of structure that identifies a parent element and a collection of packed elements. This is used in the aggregation packing and unpacking methods.

The structure is defined in Table 48

Table 49 is the AddressSpace definition of an OPENSCSCollectionDataType.

6.4.2 OPENSCSCollectionDataType

The OPENSCSCollectionDataType is an abstract subtype of OPC UA Structure that defines a collection of Serial Numbers and associated Collection information. No instances of this type can exist.

There is always at least one Serial Number in the collection.

The structure is defined in Table 50.

Table 51 is the AddressSpace definition of an OPENSCSCollectionDataType.

6.4.3 OPENSCSEventStreamArgumentDataType

The OPENSCSEventStreamArgumentDataType is a subtype of OPC UA Structure that defines the generateOptions argument for an EPCISStream GenerateFileForWrite method. It defines the serial number format information for object events and for aggregation events, and event context information. The structure is defined in Table 54.

Table 55 is the AddressSpace definition of an OPENSCSEventStreamArgumentDataType.

6.4.4 OPENSCSKeyValueDataType

The OPENSCSKeyValueDataType is a subtype of OPC UA Structure that defines two linked data items: the key, which is a unique identifier for some item of data, and the value, which is the data that is identified. The structure is defined in Table 54.

Table 55 is the AddressSpace definition of an OPENSCSKeyValueDataType.

6.4.5 OPENSCSLabelDataType

The OPENSCSLabelDataType describes a subtype of Structure type that defines a single serial number and label, which may be associated with an SID, and collection of properties in the form of OPENSCSKeyValueDataType. The structure is defined in Table 56.

Table 57 is the address space definition of an OPENSCSLabelDataType.

6.4.6 OPENSCSLabelCollectionDataType

The OPENSCSLabelCollectionDataType describes a type that defines a collection of Labels with Serial Numbers and associated Collection information. The structure is defined in Table 58.

Table 59 is the AddressSpace definition of an OPENSCSLabelCollectionDataType.

6.4.7 OPENSCSLabelPropertyDataType

The structure is defined in Table 60.

Table 61 is the AddressSpace definition of an OPENSCSLabelPropertyDataType.

6.4.8 OPENSCSReturnEnum

The OPENSCSReturnEnum describes the possible return status from an OPENSCS Method call.

The OPENSCSReturnEnum is defined in Table 62.

6.4.9 OPENSCSSerialNumberStateEnum

The OPENSCSSerialNumberStateEnum listed in Table 63 describes the possible serial number states.

6.4.10 OPENSCSSIDClassPropertyDataType

The structure is defined in Table 64.

Table 65 is the AddressSpace definition of an OPENSCSSIDClassPropertyDataType.

6.4.11 OPENSCSSNCollectionDataType

The OPENSCSSNCollectionDataType describes a subtype of OPENSCSCollectionDataType type that defines a collection of Serial Numbers and associated Collection information.

Table 66 is the AddressSpace definition of an OPENSCSSNCollectionDataType.

6.5 Product Master Data

Product master data, as defined in the OPEN-SCS PSS specification should be exchanged using material models defined in the OPC Unified Architecture for ISA 95 Common Object Model Companion Specification. See https://opcfoundation.org/markets-collaboration/isa-95/ or https://opcfoundation.org/developer-tools/specifications-OPC UA-collaborations/isa-95-common-object-model/

7 Profiles and Namespaces

The section describes the various Facets that are provided as part of the OPEN-SCS OPC UA InformationModel. These Facets include OPEN-SCS InformationModel ConformanceUnits, but they also include ConformanceUnits or Facets from the OPC 10000-7 specification. They are summarized in Table 67.

7.1 Profile Overview

Table 68 lists the general functionality of client and server profiles that support the OPEN-SCS OPC UA interface.

The profiles are defined to allow the maximum flexibility in allocation of functions to devices and components (hardware and software). These are graphically represented in Figure 16.

For example: a system may be made up of a:

global serial number manager (GSNM), which manages unallocated serial numbers, and records all events on serial numbers, labels, and SID to comply with regulatory requirements,

and implements the Unassigned Serial Number Manager Server Profile

and implements the Serial Number Event Manager Server Profile

and implements the Label Event Manager Server Profile

and implements the SID Event Manager Server Profile

and implements the Aggregation Event Manager Server Profile

a local serial number manager (LSNM) that manages unallocated and reserved serial numbers but does not handle events,

and implements the Unallocated Serial Number Manager Server Profile

and implements the Allocated Serial Number Manager Server Profile

and implements the Unassigned Serial Number Manager Client Profile

a print and label system (PLS) that encodes serial numbers and applies the encoded numbers to products,

and implements the Print and Commission Manager Server Profile

and implements the Print and Commission Manager Client Profile

a cartonizer and palletizer that aggregates products into cartons and pallets and prints and applies carton and pallet labels.

and implements the Print and Commission Manager Server Profile

and implements the Print and Commission Manager Client Profile

and implements the Aggregation Event Manager Client Profile

a global event manager that receives EPCIS event files from multiple systems recording local events.

And implements the EPCIS Event Manager Server Profile

7.2 Namespace Metadata

Table 69 defines the namespace metadata for this specification. 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.

7.3 Conformance Units

7.3.1 Overview

This section defines the ConformanceUnits that are specific to the OPC UA OPENSCS Information model. These ConformanceUnits are separated into ConformanceUnits that are Server specific and those that are Client specific.

7.3.2 Server Conformance Units

Table 70 defines the Server based ConformanceUnits.

7.3.3 Client Conformance Units

Table 71 defines the Client based ConformanceUnits.

7.4 Profiles and Facets

Profiles are named groupings of Conformance Units. Facets are Profiles that will be combined with other Facets or Profiles to define the complete functionality of an OPC UA Server or Client. The following tables specify the Profiles and Facets available for components (physical or virtual) that implement the OPEN-SCS PSS specification.

Some Conformance Units. Facets and Profiles may not be implemented by all conformant products. Such optional functionality is indicated in the Mandatory/Optional columns in the tables in this clause. If a product chooses to implement functionality indicated as optional, it must be implemented to conform to the chosen optional Conformance Unit, Facet or Profile.

7.4.1 OPENSCS Facets

The following sub-clauses define OPENSCS Facets that, when implemented, are used to add additional functionality to the basic OPENSCS functionality.

7.4.1.1 OPENSCS Security Server Facet

The OPENSCS Security Server Facet defined in Table 72 includes ConformanceUnits for Servers that are not included in other OPC UA defined Facets and Profiles. This Facet is required to meet the security requirements of OPENSCS.

7.4.1.1.1 OPENSCS Server Mandatory Authentication

OPENSCS security requirements mandate that the session shall always be authenticated. The use of endpoints enabling the security policy SECURITY_POLICY_NONE is not allowed.

7.4.1.2 OPENSCS Security Client Facet

The OPENSCS Security Client Facet defined in Table 73 includes Conformance Units for Clients that are not included in other OPC UA defined Facets and Profiles. This Facet is required to meet the security requirements of OPENSCS.

7.4.1.2.1 OPENSCS Client Mandatory Authentication

OPENSCS security requirements mandate that the session shall always be authenticated. The use of the security policy SECURITY_POLICY_NONE is not allowed.

7.4.2 OPENSCS Server Profiles

7.4.2.1 OPENSCS Base Server Profile

Table 74 defines a Profile for the minimum functionality necessary for a component that conforms to the functionality of an OPENSCS server using the OPC UA Client/Server Interface.

7.4.2.2 Aggregation Event Manager Server Profile

Table 75 defines the profile facets and conformance units for an Aggregation Event Manager Server.

7.4.2.3 Allocated Serial Number Manager Server Profile

Table 76 defines the profile facets and conformance units for an Allocated Serial Number Manager Server.

7.4.2.4 Unallocated Serial Number Manager Server Profile

Table 77 defines the profile facets and conformance units for an Unallocated Serial Number Manager Server.

7.4.2.5 Unassigned Serial Number Manager Server Profile

Table 78 defines the profile facets and conformance units for an Unassigned Serial Number Manager Server.

7.4.2.6 Print and Commission Manager Server Profile

Table 79 defines the profile facets and conformance units for a Print and Commission Manager Server.

7.4.2.7 Serial Number Event Manager Server Profile

Table 80 defines the profile facets and conformance units for a Serial Number Event Manager Server.

7.4.2.8 Label Event Manager Server Profile

Table 81 defines the profile facets and conformance units for a Label Event Manager Server.

7.4.2.9 SID Event Manager Server Profile

Table 82 defines the profile facets and conformance units for a SID Event Manager Server.

7.4.2.10 SID Class Manager Server Profile

Table 83 defines the profile facets and conformance units for a SID Class Manager Server.

7.4.2.11 EPCIS Event Manager Server Profile

Table 83 defines the profile facets and conformance units for an EPCIS Class Manager Server.

7.4.3 OPENSCS Client Profiles

7.4.3.1 OPENSCS Base Client Profile

The OPENSCS Client Profile defined in Table 85 includes Facets and Profiles that define the minimum functionality necessary for a component that conforms to the functionality of an OPENSCS client using the OPC UA Client/Server Interface.

7.4.3.2 Aggregation Event Manager Client Profile

Table 86 defines the profile facets and conformance units for an Aggregation Event Manager Client.

7.4.3.3 Allocated Serial Number Manager Client Profile

Table 87 defines the profile facets and conformance units for an Allocated Serial Number Manager Client.

7.4.3.4 Unallocated Serial Number Manager Client Profile

Table 88 defines the profile facets and conformance units for an Unallocated Serial Number Manager Client.

7.4.3.5 Unassigned Serial Number Manager Client Profile

Table 91 defines the profile facets and conformance units for an Unassigned Serial Number Manager Client.

7.4.3.6 Print and Commission Manager Client Profile

Table 90 defines the profile facets and conformance units for a Print and Commission Manager Client.

7.4.3.7 Serial Number Event Manager Client Profile

Table 91 defines the profile facets and conformance units for a Serial Number Event Manager Client.

7.4.3.8 Label Event Manager Client Profile

Table 92 defines the profile facets and conformance units for a LabelEvent Manager Client.

7.4.3.9 SID Event Manager Client Profile

Table 93 defines the profile facets and conformance units for a SID Event Manager Client.

7.4.3.10 EPCIS Event Manager Client Profile

Table 94 defines the profile facets and conformance units for an EPCIS Event Manager Client.

Annex A (normative): OPENSCS Namespace and mappings

A.1 Namespace and identifiers for OPENSCS-SER Information Model

This appendix defines the numeric identifiers for all of the numeric NodeIds defined in this document. The identifiers are specified in a CSV file with the following syntax:

<SymbolName>, <Identifier>, <NodeClass>

Where the SymbolName is either the BrowseName of a Type Node or the BrowsePath for an Instance Node that appears in the specification and the Identifier is the numeric value for the NodeId.

The BrowsePath for an Instance Node is constructed by appending the BrowseName of the instance Node to the BrowseName for the containing instance or type. An underscore character is used to separate each BrowseName in the path. Let’s take for example, the <OPENSCSSIDClassPropertyDataType> ObjectType Node which has the <PropertyValue> Property. The Name for the <PropertyValue> InstanceDeclaration within the <type> declaration is: OPENSCSSIDClassPropertyDataType_PropertyValue.

The NamespaceUri for all NodeIds defined here is http://opcfoundation.org/OPENSCS-SER/

Note that NamespaceURIs are NOT live URLs.

The CSV released with this version of the specification can be found here:

http://www.opcfoundation.org/UA/schemas/OPENSCS/1.0/NodeIds.csv

http://www.opcfoundation.org/UA/schemas/OPENSCS/NodeIds.csv

A computer processible version of the complete Information Model defined in this document is also provided. It follows the XML Information Model schema syntax defined in OPC 10000-6.

The Information Model Schema released with this version of the document can be found here:

http://www.opcfoundation.org/UA/schemas/OPENSCS/1.0/Opc.Ua.OPENSCS.NodeSet2.xml

http://www.opcfoundation.org/UA/schemas/OPENSCS/Opc.Ua.OPENSCS.NodeSet2.xml

Annex B OPC UA Method result Codes

B.1 Method Result Codes

The OPC UA Method Result codes, from OPC 10000-4, are copied in Table 95.

Annex C (Normative) EPCIS File Transfer Format

C.1 Reference documents

EPCIS documents shall conform with GS1's EPCIS and Core Business Vocabulary (CBV) standards (i.e., ISO/IEC 19987 and 19988, respectively).

Additional guidance is provided by GS1's global, cross-sector EPCIS and CBV Implementation Guideline, as well as by the pharmaceutical supply chain-specific, GS1 US implementation guideline, “Applying GS1 Standards for DSCSA and Traceability”.

C.2 Additional Syntax Rules

In addition, the following rules apply to transferred files:

The transferred file shall use UTF-8 encoding.

GS1 based identifiers shall be expressed as EPC Pure Identity URI encodings, as specified in GS1's EPC Tag Data Standard (TDS), specifically:

SGTIN EPC URI for trade items

Example:

urn:epc:id:sgtin: 0614141.112345.000000000400

SSCC EPC URI for logistic units

SGLN EPC URI for read points and business locations

Non-GS1 identifiers (e.g. country or region-specific codes, or communication within Level 2 and Level 3 that use company specific identification) shall follow CBV provisions for:

“General Considerations for HTTP URLs as User Vocabulary elements”,

“HTTP URLs for Instance-level identification of objects” and

“HTTP URLs for Location identifiers”

which are normatively defined in the GS1 Core Business Vocabulary Standard, Chapter 8 User Vocabularies.

Example (non-GS1 instance-level object identifier:

https://MyCountryDomain.eu/ProductCode/obj/8675ABC556

Example (non-GS1 location identifier):

https://local.com/HEX/loc/3114257BF5A13B8790000000

All serialized identifiers (i.e., SGTIN and SSCC), including but not limited to those appearing in shipping and packing events, shall first have been captured in a commissioning event (i.e., an EPCIS Object Event with action "ADD", business_step "urn:epcglobal:cbv:bizstep:commissioning" and disposition "urn:epcglobal:cbv:bizstep:active".

Aggregation shall be used to capture the relationship between each serialized parent and its immediate children (i.e., an EPCIS Aggregation Event with action "ADD" and business_step "urn:epcglobal:cbv:bizstep:packing"); each additional (nested) level of packaging hierarchy (i.e., grandparents and great-grandparents of the lowest registered level) must be expressed in an additional, dedicated EPCIS Aggregation Event.

Each shipped unit shall always be identified as a logistic unit and captured by means of its SSCC upon dispatch (i.e. an EPCIS Object Event with action "OBSERVE", business step "shipping" and disposition "in_transit").

Each individual hierarchical level packed within this logistic unit shall have been captured in an earlier EPCIS Aggregation Event.

Each commissioning event shall include as many SGTINs as practical; common sense shall be leveraged in conjunction with dialogue between communicating partners to establish an agreed approach to managing file sizes.

The maximum number of SGTINs must be agreed between communicating partners during design or change management of a system and should be represented in the properties MaxEPCISObjectEventSIDs and MaxEPCISAggregationEvents of the OPENSCSEventManagerObjectType.

While timestamping of individual EPCs (i.e., in individual EPCIS events) is to be avoided to avoid unnecessary bloating of payload, the opposite extreme of including an entire batch run in one event might cause file size exceptions.

Strictly enforce GS1 EPCIS chronology sequence standard to be upheld for any single EPC, for example:

For any single EPC, the Commission time must be before the Aggregation time which must be before the Shipping time.

The Aggregation timer of bottles into a case must be before the Aggregation of the case into a pallet.

Any single EPC cannot share the same timestamp in 2 separate events.

When possible do not include custom EPCIS event extensions as they increase file size. Where extensions cannot be avoided, these shall be implemented in compliance with the EPCIS standard's extensibility mechanism, including but not limited to declaration of the applicable vendor/user namespace.

Bibliography

Agreement of Use

© 2020 OPC Foundation

COPYRIGHT RESTRICTIONS

This document is provided "as is" by the OPC Foundation and OPEN-SCS.

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 OPEN-SCS 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 OPEN-SCS 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 OPEN-SCS.

OPC Foundation members, OPEN-SCS Member and any 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 is the OPC Foundation. 16101 N. 82nd Street, Suite 3B, Scottsdale, AZ, 85260-1830

COMPLIANCE

The OPC Foundation and OPEN-SCS shall at all times be the only 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. 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 and OPEN-SCS. 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.