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.

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:

1. An unassigned Serial Number, where the number has not been assigned to any specific product, production order, or packaging run.
2. 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.
3. 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.
4. The printed label as it is applied to the physical product, called a commissioned label, and identified as a Serialized Identifier (SID).

Figure 1 – Lifecycle Stages of a Serial Number

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.

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.

Figure 2 – Activities in Serialization

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.

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.

Figure 3 – Serialization Information Model

Note:The model above is different from the Version 1 PSS model, through the addition of a set of optional Serial Number Properties for each Serial Number. This was added to handle the case, such as in Russia, where there is optional additional information associated with each Serial Number which is exchanged information. See Section 6.4.2.

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

Note 1The state is managed is a distributed manner, no single system provides the state of the serial numbers. The events and methods defined in this document provide the means for applications to manage their internal state representation.

Note 2All Serial Numbers in a Serial Number Collection only contain Serial Numbers with the same state.

Note 3All Serial Numbers in a Label Collection only contain Serial Numbers with the same state and ancillary information.

Note 4Generally the events that record a transition can come from any state or substate.

Figure 4 – Serial Number State and Event Model

Each Serial Number state is defined in Table 1.

Table 1 – Serial Number State Definitions

SID State	Description	Examples
Unassigned	The Serial Number has not been assigned to production or a packaging run. The unassigned state is used for communication to systems that assign serial numbers.	A request is sent to an agent or serial number management system that creates serial numbers, along with possible information such as product codes.
Unallocated	As Serial Number has been assigned to production or a packaging run, but it has not yet been allocated for use a specific production run of a product or aggregation.	A local serial number management system maintains a set of unallocated serial numbers.
Allocated	The Serial Number has been assigned to a specific product or aggregation production run.	Serial Numbers are available and maintained in a local printer for printing on a label.
SN Invalid	The Serial Number is no longer viable, and the related serial number is no longer defined. The Serial Number will not be the subject of subsequent events.	A process order using the Serial Numbers was cancelled, the provisioned Serial Number are not associated with a physical product and will not be further used.
Encoded	The Serial Number has been written to a barcode or RFID tag, but not yet commissioned.	An industrial printer prints a label.
Label Sampled	The printed label has been retained and is not associated with a physical product or aggregation.	A printed label is attached to a batch record.
Label Scrapped	A label was encoded with a Serial Number but was made unusable before being applied to a product or aggregation.	A vision system detects that a label was misapplied or ripped on a product or aggregation and the label was removed from the product or aggregation.
Commissioned	The Serial Number has been associated with a physical product or aggregation but has not yet left the responsibility of production. The Serial Number can now be identified as a SID.	A label is attached to a package, and the package is being placed into a case, and the case is being placed on a pallet.
Sampled	The product or aggregation is to be used as a sample for testing or other use, not to be made active.	Product was pulled from the end of the packaging line and stored in a facility for later stability testing.
Inactive	The product or aggregation is no longer active but may not have been destroyed. GS1 defines this disposition as a decommissioned object that may be reintroduced to the supply chain, however any status change after decommissioning is not in scope of the PSS.	Product over its expiration date is send to a facility for destruction or for testing to determine its viability.
Destroyed	The product or aggregation has been fully rendered non-usable.	A production error was detected, and all packaged product was pulled from the line and destroyed.
Released	The Serial Number has been associated with a physical product or aggregation and has left the responsibility of production.	A pallet of products/packages is delivered to the warehouse and the transfer of control is sent to the ERP system.

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

Table 2 – Serial Number Events

Event	Description
provisioning	Unassigned Serial Numbers were made available for use in eventual encoding and commissioning.
sn_returning	Unallocated Serial Numbers may be returned to the Unassigned state
sn_allocating	Unallocated Serial Numbers are to be assigned for use in a packaging run
sn_deallocating	Unused allocated Serial Numbers may be returned to the unallocated state.
sn_invalidating	Provisioned Serial Numbers are no longer available for use
sn_encoding	Serial Numbers and other associated information are written to a barcode or RFID tag but are not yet associated with a product or aggregation. (Derived from the GS1 “encoding” business step.)
label_inspecting	Written barcode or RFID was read to address potential physical or documentation defects.
label_sampling	Written barcode or RFID is pulled from production and retained as a sample for later testing or inspection.
label_scrapping	Written barcode or RFID was made unusable in production and the serial number if no longer associated with a packaging run
commissioning	A Serial Numbers is associated with a specific product or aggregation. (Derived from the GS1 “commissioning” business step.)
inspecting	Product or aggregation is pulled from production and retained as a sample for later testing or inspection.
shipping	Indicates the overall process of staging, outbound, loading and departing the responsibility of production. (Derived from the GS1 “shipping” business step.)
decommissioning	Process of disassociating an instance-level identifier (Serial Number) with an object. For example, either time or an event has caused to the serial number to be disassociated with a product or aggregation. (Derived from the GS1 “decommissioning” business step.)
destroying	Process of terminating a physical object. For an instance-level identifier, the object will not be the subject of subsequent events; subsequent events are likely indicative of error (such as a stray read of a tag inside an incinerator). (Derived from the GS1 “destroying” business step.)
packing	Denotes a specific activity within a business process that includes putting objects into a larger container. For example, adding labeled bottles into a case or adding cases into a pallet. (Derived from the GS1 “packing” business step.)
unpacking	Denotes a specific activity within a business process that includes removing products (individuals, inners, cases, pallets) from a larger container. For example, removing labeled bottles from a case or removing cases from a pallet. (Derived from the GS1 “unpacking” business step.)

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:

Table 3 – OPEN-SCS PSS Function to OPC UA Method Mapping

OPEN-SCS PSS Function	OPC UA Method	Method Use
Serial Number Request Unassigned	SNRequestUnassigned	Pull of information from a pool management server
Serial Number Request Unallocated	SNRequestUnallocated	Pull of information from a pool management server
Serial Number Request Allocated	SNRequestAllocated	Pull of information from a pool management server
Serial Number Return Unallocated	SNReturnUnallocated	Push of information to a pool management server
Serial Number Return Allocated	SNReturnAllocated	Push of information to a pool management server
Serial Number To Unallocated	SNtoUnallocated	Push of information to a pool management server
Serial Number To Allocated	SNtoAllocated	Push of information to a pool management server
Serial Number to Encoded	SNtoEncoded	Push of information to a pool management server
Serial Number Invalidating Event	SNInvalidatingEvent	Push of information to an event management server
Label Encoding Event	LabelsEncodingEvent	Push of Information to an event management server
Label Scrapping Event	LabelsScrappingEvent	Push of information to an event management server
Label Inspecting Event	LabelsInspectingEvent	Push of information to an event management server
Label Sampling Event	LabelsSamplingEvent	Push of information to an event management server
SID Commissioning Event	SIDCommissioningEvent	Push of information to an event management server
SID Destroying Event	SIDDestroyingEvent	Push of information to an event management server
SID Shipping Event	SIDShippingEvent	Push of information to an event management server
SID Inspecting Event	SIDInspectingEvent	Push of information to an event management server
SID Decommissioning Event	SIDDecommissioningEvent	Push of information to an event management server
Aggregation Packing Event	AggregationPackingEvent	Push of information to an aggregation management server
Aggregation Unpacking Event	AggregationUnpackingEvent	Push of information to an aggregation management server

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.

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.

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.

Figure 5 – The Scope of OPC UA within an Enterprise

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

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.

Figure 6 – A Basic Object in an OPC UA Address Space

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.

Figure 7 – The Relationship between Type Definitions and Instances

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.

Figure 8 – Examples of References between 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.

Figure 9 – The OPC UA Information Model Notation

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.

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.

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.