Introduction

1 Scope

This specification was created by a joint working group of the OPC Foundation and AIM. It defines an OPC UA Information Model to represent and access AutoID Devices.

OPC Foundation

OPC is the interoperability standard for the secure and reliable exchange of data and information in the industrial automation space and in other industries. It is platform independent and ensures the seamless flow of information among devices from multiple vendors. The OPC Foundation is responsible for the development and maintenance of this standard.

Initially, the OPC standard was restricted to the Windows operating system. As such, the acronym OPC was borne from OLE (object linking and embedding) for Process Control. These specifications, which are now known as OPC Classic, have enjoyed widespread adoption across multiple industries, including manufacturing, building automation, oil and gas, renewable energy and utilities, among others.

With the introduction of service-oriented architectures in manufacturing systems came new challenges in security and data modelling. The OPC Foundation developed the OPC UA specifications to address these needs and at the same time provided a feature-rich technology open-platform architecture that was future-proof, scalable and extensible.

AIM

AIM (including AIM Global) is the leading industry association and worldwide authority on automatic identification & data capture technologies (AIDC/AutoID), which comprise barcode, OCR, 2D code, RFID, NFC, RTLS, sensors and mobile computing. It is serving members around the globe as a trusted resource for more than 40 years. AIM actively supports the development of standards through its own Technical Symbology Committee (TSC), Global Standards Advisory Groups, the US and European RFID Experts Groups (REG / EREG) and the IoT Experts Group. Furthermore, AIM experts take a leading role at working groups at standardisation organisations like ISO, ANSI, CEN, CENELEC, ETSI and DIN. AIM Germany (AIM-D e.V., Lampertheim, Germany: www.AIM-D.de) is the regional chapter for central Europe (Germany, Austria, Switzerland). AIM members include technology providers, systems integrators, consulting firms, research institutes and other associations. AIM's general goal is to facilitate the market dissemination of AIDC technologies on a reliable basis for the benefit of solution providers and users.

2 Normative References

OPC UA for AutoID Information Model specification references

OPC 10000-1, OPC Unified Architecture – Part 1: Overview and Concepts

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

OPC 10000-4, OPC Unified Architecture – Part 4: Services

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

OPC 10000-6, OPC Unified Architecture – Part 6: Mappings

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

OPC 10000-100, OPC Unified Architecture – Part 100: Devices

ISO/IEC 14443 (all parts) Identification cards -- Contactless integrated circuit cards -- Proximity cards

ISO/IEC 15418: 2009 Information technology -- Automatic identification and data capture techniques -- GS1 Application Identifiers and ASC MH10 Data Identifiers and maintenance

ISO/IEC 15434: 2006 Information technology -- Automatic identification and data capture techniques -- Syntax for high-capacity ADC media

ISO/IEC 15693 (all parts) Identification cards -- Contactless integrated circuit cards -- Vicinity cards

ISO 17363: 2013 Supply chain applications of RFID -- Freight containers

ISO 17364: 2013 Supply chain applications of RFID -- Returnable transport items (RTIs) and returnable packaging items (RPIs)

ISO 17365: 2013 Supply chain applications of RFID – Transport units

ISO 17366: 2013 Supply chain applications of RFID – Product packaging

ISO 17367: 2013 Supply chain applications of RFID – Product tagging ISO/IEC 18000-1: 2008 Information technology — Radio frequency identification for item management — Part 1: Reference architecture and definition of parameters to be standardized

ISO/IEC 18000-1: 2008 Information technology — Radio frequency identification for item management — Part 1: Reference architecture and definition of parameters to be standardized

ISO/IEC 18000-2: 2009 Information technology – Radio frequency identification for item management – Part 2: Parameters for air interface communications below 135 kHz

ISO/IEC 18000-3: 2010 Information technology — Radio frequency identification for item management — Part 3: Parameters for air interface communications at 13,56 MHz

ISO/IEC 18000-63: 2013 Information technology — Radio frequency identification for item management — Part 63: Parameters for air interface communications at 860 MHz to 960 MHz Type C

ISO/IEC 19762, Information technology — Automatic identification and data capture (AIDC) techniques — Harmonized vocabulary

GS1 EPCglobal™: GS1 EPC™ Tag Data Standard [EPCTDS]

GS1 EPCglobal™: EPC™ Radio-Frequency Identity Protocols Class-1 Generation-2 UHF RFID Protocol for Communications at 860 MHz - 960 MHz Version 1.2.0 [EPCGen2]

NMEA 0183 v. 4.10: Data transmission protocol and time and specific sentence formats

3 Terms, abbreviations and conventions

3.1 Use of terms

Defined terms of OPC UA specifications, types and their components defined in OPC UA specifications and in this specification are highlighted with italic in this specification.

3.2 OPC UA for AutoID Information Model terms

3.2.1 AutoID Device

Identification device executing a scan, read or write process

3.2.1.1 Untitled

3.2.2 AutoID Identifier

Transponder, tag or code identifying an object

3.3 Abbreviations

3.4 Conventions used in this specification

3.4.1 Conventions for Node descriptions

Node definitions are specified using tables (See Table 1)

Attributes are defined by providing the Attribute name and a value, or a description of the value.

References are defined by providing the ReferenceType name, the BrowseName of the TargetNode and its NodeClass.

If the TargetNode is a component of the Node being defined in the table the Attributes of the composed Node are defined in the same row of the table.

The DataType is only specified for Variables; “[<number>]” indicates a single-dimensional array, for multi-dimensional arrays the expression is repeated for each dimension (e.g. [2][3] for a two-dimensional array). For all arrays the ArrayDimensions is set as identified by <number> values. If no <number> is set, the corresponding dimension is set to 0, indicating a dynamic size. If no number is provided at all the value is scalar and the ArrayDimensions is omitted. If no brackets are provided, it identifies a scalar DataType and the ValueRank is set to the corresponding value (see OPC 10000-3). In addition, ArrayDimensions is set to null or is omitted. If it can be Any or ScalarOrOneDimension, the value is put into “{<value>}”, so either “{Any}” or “{ScalarOrOneDimension}” and the ValueRank is set to the corresponding value (see OPC 10000-3) and the ArrayDimensions is set to null or is omitted. In Table 2 examples are given.

The TypeDefinition is specified for Objects and Variables.

The TypeDefinition column specifies a NodeId of a TypeDefinitionNode, i.e. the specified Node points with a HasTypeDefinition Reference to the corresponding TypeDefinitionNode. The symbolic name of the NodeId is used in the table.

The ModellingRule of the referenced component is provided by specifying the symbolic name of the rule in the ModellingRule column. In the AddressSpace, the Node shall use a HasModellingRule Reference to point to the corresponding ModellingRule Object.

If the NodeId of a DataType is provided, the symbolic name of the Node representing the DataType shall be used.

Nodes of all other NodeClasses cannot be defined in the same table; therefore only the used ReferenceType, their NodeClass and their BrowseName are specified. A reference to another section of this specificationpoints to their definition.

If no components are provided, the DataType, TypeDefinition and ModellingRule columns may be omitted and only a Comment column is introduced to point to the Node definition.

Components of Nodes can be complex, i.e. containing components by themselves. The TypeDefinition, NodeClass, DataType and ModellingRule can be derived from the type definitions, and the symbolic name can be created as defined in 3.4.2.1. Therefore those containing components are not explicitly specified; they are implicitly specified by the type definitions.

3.4.2 NodeIds and BrowseNames

3.4.2.1 NodeIds

The NodeIds of all Nodes described in this specification are only symbolic names. Annex A defines the actual NodeIds.

The symbolic name of each Node defined in this specificationis its BrowseName, or, when it is part of another Node, the BrowseName of the other Node, a “.”, and the BrowseName of itself. In this case “part of” means that the whole has a HasProperty or HasComponent Reference to its part. Since all Nodes not being part of another Node have a unique name in this specification, the symbolic name is unique.

The NamespaceUri for all NodeIds defined in this document is defined in Annex A. The NamespaceIndex for this NamespaceUri is vendor-specific and depends on the position of the NamespaceUri in the server namespace table.

Note: This specification does not only define concrete Nodes, but also requires that some Nodes have to be generated, for example one for each AutoID Device represented by the Server. The NodeIds of those Nodes are server-specific, including the Namespace. But the NamespaceIndex of those Nodes cannot be the NamespaceIndex used for the Nodes defined by this specification, because they are not defined by this specification but generated by the Server.

3.4.2.2 BrowseNames

The text part of the BrowseNames for all Nodes defined in this specification is specified in the tables defining the Nodes. The NamespaceIndex for all BrowseNames defined in this specification is server specific and depends on the position of the namespace URI defined in this specification in the server namespace table.

If the BrowseName is not defined by this specification, a namespace index prefix like ‘0:EngineeringUnits’ is added to the BrowseName. This is typically necessary if a Property of another specification is overwritten or used in the OPC UA types defined in this specification. Table 87 provides a list of namespaces used in this specification.

3.4.3 Common Attributes

3.4.3.1 General

The Attributes of Nodes, their DataTypes and descriptions are defined in OPC 10000-3. Attributes not marked as optional are mandatory and shall be provided by a Server. The following tables define if the Attribute value is defined by this specification or if they vendor specific.

For all Nodes specified in this specification, the Attributes named in Table 3 shall be set as specified in the table.

3.4.3.2 Objects

For all Objects specified in this specification, the Attributes named in Table 4 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

3.4.3.3 Variables

For all Variables specified in this specification, the Attributes named in Table 5 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

3.4.3.4 VariableTypes

For all VariableTypes specified in this specification, the Attributes named in Table 6 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

4 General information to AutoID and OPC UA

4.1 Introduction to AutoID

AutoID (Automatic Identification) technologies use mainly barcodes, OCR, 2D codes, RFID and NFC in order to identify all sorts of objects in all industry sectors and in logistics: articles in the super market, parts and modules in the production line, (returnable) transport items (RTI), vehicles and so forth. The main benefits of AutoID solutions are the acceleration of business processes and the improvement of data quality compared to manual procedures. AutoID systems rely on numbers, which identify the marked objects ("article number"). If it is required to distinguish similar objects uniquely from each other the article numbers must be extended by serial numbers.

While the automation of enterprise processes is rapidly growing the AutoID technologies achieve a crucial meaning. Concepts like the Internet of Things (IoT) or "Industrie 4.0" can only be put into practice successfully, if AutoID systems provide reliable data about all kinds of moving objects in the diversity of business processes, production lines and logistics chains. This data must be transferred securely to the IT systems in the background which control the processes, take actions if discrepancies are detected and post alerts to managers if human actions are required.

Talking about AutoID today means not to stay with the mere automatic identification of objects. It is also important to collect information about further parameters of moved or stationary goods. Therefore, critical goods are not only equipped with RFID tags, but also with sensors which record parameters like temperature, humidity, acceleration (to detect shocks), etc. Such functionality helps to make sure, that goods do not only reach their goal, but also keep appropriate properties so that they can be sold in the super market or mounted at the production line.

After identification and sensing there is a third vital requirement in modern logistics and production environments: real-time locating systems (RTLS). Primarily, people think of GPS systems to provide real-time locating. But GPS has its limits. For instance a truck approaching a distribution centre cannot make sure to hit the right hub when just using GPS. For the last meters towards the hub this truck would need complementary components based on e. g. active RFID or RTLS.

The collaboration of AIM Germany and OPC Foundation aims at the easy systems integration of all these AutoID components and at an easy way to improve and substitute systems according to new requirements and market developments.

4.2 Introduction to OPC Unified Architecture

4.2.1 General

The main use case for OPC classic specifications is the online data exchange between devices and HMI or SCADA systems using Data Access functionality. In this use case the device data is provided by an OPC server and is consumed by an OPC client integrated into the HMI or SCADA system. OPC DA provides functionality to browse through a hierarchical namespaces containing data items and to read, write and to monitor these items for data changes. The OPC classic specifications are based on Microsoft COM/DCOM technology for the communication between software components from different vendors. Therefore OPC classic server and clients are restricted to Windows PC based automation systems.

OPC UA incorporates all features of OPC classic specifications like OPC DA, A&E and HDA but defines platform independent and secure communication mechanisms and generic, extensible and object-oriented modelling capabilities for the information a system wants to expose. OPC UA is directly integrated into devices and is used for configuration, diagnostic and maintenance use cases in addition to online data exchange. OPC UA is an integrated communication interface used from sensor level devices up to enterprise applications.

The OPC 10000-6 defines different transport mechanisms optimized for different use cases. The first version of OPC UA is defining an optimized binary TCP protocol for high performance intranet communication as well as a mapping to accepted internet standards like Web Services. The abstract communication model does not depend on a specific protocol mapping and allows adding new protocols in the future. Features like security and reliability are directly built into the transport mechanisms. Based on the platform independence of the protocols, OPC UA servers and clients can be directly integrated into devices and controllers.

The OPC UA Information Model provides a standard way for Servers to expose Objects to Clients. Objects in OPC UA terms are composed of other Objects, Variables and Methods. OPC UA also allows relationships to other Objects to be expressed.

The set of Objects and related information that an OPC UA Server makes available to Clients is referred to as its AddressSpace. The elements of the OPC UA Object Model are represented in the AddressSpace as a set of Nodes described by Attributes and interconnected by References. OPC UA defines eight classes of Nodes to represent AddressSpace components. The classes are Object, Variable, Method, ObjectType, DataType, ReferenceType and View. Each NodeClass has a defined set of Attributes.

This specification defines Nodes of the OPC UA NodeClasses Object, Method, Variable, ObjectType and DataType.

Objects are used to represent components of a system. An Object is associated to a corresponding ObjectType that provides definitions for that Object.

Methods are used to represent commands or services of a system.

Variables are used to represent values. Two categories of Variables are defined, Properties and DataVariables.

Properties are Server-defined characteristics of Objects, DataVariables and other Nodes. Properties are not allowed to have Properties defined for them. An example for Properties of Objects is the DeviceLocation Property of an AutoIdDeviceType ObjectType.

DataVariables represent the data contents of an Object.

4.2.2 Graphical Notation

OPC UA defines a graphical notation for an OPC UA AddressSpace. It defines graphical symbols for all NodeClasses and how different types of References between Nodes can be visualized. Figure 1 shows the symbols for the six NodeClasses used in this specification. NodeClasses representing types always have a shadow.

Figure 2 shows the symbols for the ReferenceTypes used in this specification. The Reference symbol is normally pointing from the source Node to the target Node. The only exception is the HasSubtype Reference. The most important References like HasComponent, HasProperty, HasTypeDefinition and HasSubtype have special symbols avoiding the name of the Reference. For other ReferenceTypes or derived ReferenceTypes the name of the ReferenceType is used together with the symbol.

Figure 3 shows a typical example for the use of the graphical notation. Object_A and Object_B are instances of the ObjectType_Y indicated by the HasTypeDefinition References. The ObjectType_Y is derived from ObjectType_X indicated by the HasSubtype Reference. The Object_A has the components Variable_1, Variable_2 and Method_1.

To describe the components of an Object on the ObjectType the same NodeClasses and References are used on the Object and on the ObjectType like for ObjectType_Y in the example. The instance Nodes used to describe an ObjectType are instance declaration Nodes.

To provide more detailed information for a Node, a subset or all Attributes and their values can be added to a graphical symbol.

4.3 Use Cases

AutoID Devices like RFID or optical readers and RTLS are used in several applications, from production control to material flow, logistics, asset management, and more. In all of these applications, the AutoID Devices have to scan the environment and read / decode the given object ids.

In addition, the object ids can be altered in case of RFID and RTLS systems.

If a RFID transponder provides additional memory, these data areas might be read and written.

In case of RTLS, the host system may ask the RTLS for the current position of a given object transponder.

The information delivered by AutoID systems can be used by host systems as PC applications, mobile applications, IT systems, programmable logic controllers (PLC), and more.

5 AutoID Information Model Overview

5.1 Modelling concepts

The base interface concept of the AutoID information model shown in Figure 4 supports two different communication procedures. One procedure is to trigger the scan from an OPC UA client and the other procedure is that the AutoID Device sends a scan event whenever the AutoID Device detected a tag or code.

The AutoIdDeviceType provides the method Scan to trigger a scan and to return the scan result with the Method response. In addition the ScanStart provides a way to start the scan but to receive the scan result through an AutoIdScanEventType.

The AutoIdScanEventType defines the information provided with a scan event and it is either triggered through a ScanStart Method call or through the AutoID Device itself.

5.2 Model Overview

The following Figure 5 provides an overview of the concrete types for the different AutoID reader device types and the corresponding scan event types. They define the AutoID Device type specific semantic of the method parameters and event fields. The AutoID Device types are derived from the DeviceType defined in OPC 10000-100.

6 OPC UA ObjectTypes

6.1 AutoIdDeviceType

6.1.1 General

This OPC UA ObjectType represents an AutoID Device. It defines all methods and properties required for any kind of AutoID Device in general, e.g. methods for controlling the scan operation or the mechanism to load a configuration file to the reader. However, the object is an abstract definition in terms of the actual AutoID technology, i.e. there are no properties or methods which rely on specific features or technologies.

Figure 6 shows an overview for the AutoIdDeviceType with its Properties and the base type DeviceType. It is formally defined in Table 7.

There are several options to start the scanning of AutoID Identifiers like transponders or codes. The access to the different options requires that the OPC UA Client and the user are authorized to access the requested information.

Option 1: The reader starts the scanning when the Client calls the Scan Method. The operation stops according to the termination conditions specified in the Settings parameter of the Method. The scanned data will be the result of the method call. The Settings parameter has the DataType ScanSettings. The DataType is defined in 9.3.7. Only the OPC UA Client calling the Method receives the scanned data.

Option 2: The reader will throw Events at each time a transponder or code has been detected. The scan operation starts when the client calls the ScanStart Method. The operation stops according to the termination conditions specified in the Settings parameter of the Method, or if the client calls the ScanStop Method. The scanned data is delivered through the Events. Every OPC UA Client subscribed for Events will receive the scanned data.

Option 3: The reader will throw Events at each time a transponder or code has been detected. The scan operation is controlled by the reader itself, e.g. by a trigger button. In this case, none of the scan Methods has to be called. The scanned data is delivered through the Events. Every OPC UA Client subscribed for Events will receive the scanned data.

Option 4: The reader starts the scanning when the Client writes True to the Variable ScanActive. The scan result is provided through the Variable LastScanData. The configuration is provided through the parameters in the FunctionalGroup ScanSettings. The simple option has several limitations and is only used with OPC Clients limited to Data Access functionality. Additional Scan result information can be provided via Variables like LastScanTimestamp, LastScanAntenna and LastScanRSSI, where the last two Variables are only offered by the RfidReaderDeviceType. OPC UA does not ensure a consistent delivery of a list of Variable Values. An OPC UA Server shall set all Variable SourceTimestamps and the value of the LastScanTimestamp Variable with a consistent value if the Variables Values are updated. An OPC UA Client must ensure that it has a constent set of Values. The Client can use the DataChangeFilter STATUS_VALUE_TIMESTAMP_2 to receive updates for all Variables to verify if all necessary information is available or a Client can subscribe only for one Variable like LastScanData and then read the related Variables including a verification of the SourceTimestamp.

Depending on the AutoID Device capabilities, the Scan, ScanStart and ScanStop Methods are optional. If none of these methods are implemented, option 3 or 4 has to be supported. See also 10.1 for the definition of the different AutoID Device Profiles.

6.1.2 ObjectType definition

The AutoIdDeviceType is formally defined in Table 7.

The AutoIdDeviceType ObjectType is an abstract type and cannot be used directly.

6.1.3 ObjectType Description

6.1.3.1 Object RuntimeParameters

This FunctionalGroup is used to organize runtime configuration parameters and Methods. All standard or vendor specific runtime parameters of AutoID Devices shall be exposed below this FunctionalGroup. FunctionalGroups can be nested. The runtime parameters may be also exposed in other parts of the AutoID Device OPC UA Server Address Space.

The FunctionalGroupType is defined in OPC 10000-100.

Predefined parameters for this FunctionalGroup are defined in Table 8 and described below.

The parameter CodeTypes allows the user to determine the supported and to select the configured code types. It is used to expose the list of supported code types.

The Value of the Variable contains the currently selected types as a number. The assigned code type Strings are defined in 9.1.3.

CodeTypes can contain the predefined values or vendor specific values.

The ScanSettings FunctionalGroup shall be provided if the ScanActive Variable is supported for the control of the scan behaviour. It contains the following parameters (defined in Table 8):

• Parameter Duration specifies the duration of the scan operation in milliseconds. The value 0 is infinite. It is one of the termination conditions for the scan operation. The termination conditions are related to each other. If one of the conditions is fulfilled, the scan operation is stopped.

• Parameter Cycles specifies the duration of the scan operation in ‘number of scan cycles’. The value 0 is infinite. It is one of the termination conditions for the scan operation. The termination conditions are related to each other. If one of the conditions is fulfilled, the scan operation is stopped.

• If parameter DataAvailable is True, the scan operation is completed as soon as scan data is available. If DataAvailable is False, only the other termination conditions are used.

• Parameter CodeType specifies the format of the LastScanData Variable Value as string. The CodeTypeDataType and the predefined format strings are defined in 9.1.3.

6.1.3.2 Object IOData

This FunctionalGroup is used to organize IO data from sensors and actuators connected to the AutoID Device. All vendor or configuration specific IO data of AutoID Devices shall be exposed below this FunctionalGroup. FunctionalGroups can be nested. The IO data may also be exposed in other parts of the AutoID Device OPC UA Server Address Space.

An IO data point is represented by an OPC UA Variable Value. OPC UA Clients can read and write Variable Values depending on the AccessLevel of the Variable. Values can also be monitored for changes.

The FunctionalGroupType is defined in OPC 10000-100.

6.1.3.3 Object Diagnostics

This FunctionalGroup is used to organize diagnostic data from the AutoID Device. All diagnostics data of AutoID Devices shall be exposed below this FunctionalGroup. FunctionalGroups can be nested. The diagnostics data may also be exposed in other parts of the AutoID Device OPC UA Server Address Space.

A diagnostics point is represented by an OPC UA Variable Value. OPC UA Clients can read the Variable Values. Values can also be monitored for changes.

The FunctionalGroupType is defined in OPC 10000-100.

Predefined parameters for this FunctionalGroup are defined in Table 8 and described below.

Presence identifies if there currently is seen an AutoID Identifier (e.g. a code or a transponder) by the device. If supported by a device, it may show the concrete number of AutoID Identifiers.

The Logbook FunctionalGroup shall be provided if Logging values are supported for diagnostic purposes. Its predefined parameters are defined in Table 8 and described in the following list:

• Parameter LogColumns specifies the column headings of the Logbook.

• Parameter LastLogEntry specifies the last entry of the Logbook.

The LastAccess FunctionalGroup shall be provided if values for the last AutoID Identifier access are supported for diagnostic purposes. Its predefined parameters are described in the following list:

• Parameter Client specifies the client application (interface) which was the originator of the AutoID Identifier access.

• Parameter Command specifies executed command, including the Scan command. Dependend on the kind of the client application, the names of the commands may vary. When the client application is an OPC UA Client, the names shall correspond to the command names used within this specification, e.g. “ReadTag” for the execution of the ReadTag command.

• Parameter Identifier specifies the AutoID Identifier which was accessed by the command. The DataType can be one of the DataTypes defined in the ScanData Union defined in 9.4.2. Due to the use case for limited OPC UA Clients, the DataType is normally String or ByteString.

• Parameter Timestamp specifies the point of time the AutoID identifier (e.g. a transponder) was accessed by the command.

The Last Access Variable Values belong together logically. OPC UA does not ensure a consistent delivery of a list of Variable Values. Thus, there are several limitations and the Last Access Variables should only used with OPC Clients limited to Data Access functionality. It is recommended that complex applications use the AutoIdAccessEvents or RfidAccessEvents.

An OPC UA Server shall set all Variable SourceTimestamps with a consistent value if the Variables Values are updated. An OPC UA Client must ensure that it has a constent set of Values. The Client can use the DataChangeFilter STATUS_VALUE_TIMESTAMP_2 to receive updates for all Variables to verify if all necessary information is available or a Client can subscribe only for one Variable like Timestamp and then read the related Variables including a verification of the SourceTimestamp.

6.1.3.4 Method Scan

This method starts the scan process of the AutoID Device synchronous and returns the scan results.

The duration of the scan process is defined by the termination conditions in the Settings parameter. A Client shall not set all parameters to infinite for the Scan Method. The values for infinite are defined in the ScanSettings DataType definition in 9.3.7. An additional setting to consider is the TimeoutHint used for the Call Service.

Signature

	Scan (
		[in]	ScanSettings				Settings
		[out]	ScanResult []				Results
		[out]	AutoIdOperationStatusEnumeration	Status
		);
	

Method Result Codes

6.1.3.5 Method ScanStart

This method starts the scan process of the AutoID Device asynchronous. The scan results are delivered through Events where the EventType is a subtype of the AutoIdScanEventType defined in 7.2. There is a subtype defined for each concrete AutoID Device types.

The scan process is stopped through the Method ScanStop or if one of the termination conditions in the Settings parameter is fulfilled.

In addition, the scanning stops if the Client closes the Session, or if a new configuration file is stored within the AutoID Device. There might be other conditions depending on technology or device manufacturer.

Signature

	ScanStart (
		[in]	ScanSettings				Settings
		[out]	AutoIdOperationStatusEnumeration	Status
		);
	

Method Result Codes

6.1.3.6 Method ScanStop

This method stops an active scan process of the AutoID Device.

Signature

	ScanStop ( );

Method Result Codes

6.1.3.7 Method GetDeviceLocation

This method returns the location of the AutoID Device.

Signature

	GetDeviceLocation (
		[in]	LocationTypeEnumeration	LocationType
		[out]	Location				Location
		);
	

Method Result Codes

6.1.3.8 Variable ScanActive

This OPC UA Variable allows simple applications to trigger the scan process. Simple appications involve OPC UA Clients that are limited to Data Access functionality.

The scan is triggered by writing True to the Variable Value. The behaviour of the scan is defined by the parameters in the ScanSettings FunctionalGroup defined in 9.3.7. The Value of the Variable is changed back to False by the Server if the scan is stopped according to the ScanSettings. The Client can stop the scan by writing False to the Variable Value.

The write permission can be limited to one Client. OPC 10000-3 and OPC 10000-5 define capabilities to enforce this limit with Roles and RolePermissions. Roles can be limited to a single OPC UA Application.

The scan result is provided through the Variable LastScanData. Further restrictions for this simple mechanism are described for the Variable LastScanData.

6.1.3.9 Variable LastScanData

This OPC UA Variable represents the last scanned AutoID Identifier. The DataType can be one of the DataTypes defined in the ScanData Union defined in 9.4.2. Due to the use case for limited OPC UA Clients, the DataType is normally String or ByteString.

The Variable can be provided for simple applications where OPC UA Clients are limited to Data Access functionality. Such OPC UA Clients are typically limited to built-in DataTypes like String or ByteString too. The use of this Variable implies the following restrictions.

Only one AutoID Identifier can be delivered for a scan.

The frequency of scans is limited to the sampling interval set by the OPC UA Client.

The delivery of scan results depends on the MonitoredItem settings or Read behaviour of the OPC UA Client.

It is recommended that complex applications use scan Methods and Events.

6.1.3.10 Variable LastScanTimestamp

This OPC UA Variable of DataType UtcTime belongs to the Variable LastScanData and represents the point of time the last AutoID Identifier was scanned. The value of this Variable shall be equal to the SourceTimestamp of the Variable LastScanData.

The Variable can be provided for simple applications where OPC UA Clients are limited to Data Access functionality. Such OPC UA Clients are typically limited to built-in DataTypes like UtcTime. The use of this Variable implies the following restrictions.

Only one AutoID Identifier can be delivered for a scan.

The frequency of scans is limited to the sampling interval set by the OPC UA Client.

The delivery of scan results depends on the MonitoredItem settings or Read behaviour of the OPC UA Client.

It is recommended that complex applications use scan Methods and Events.

6.1.3.11 Variable DeviceInfo

This OPC UA Property of DataType String represents an AutoID Device additional information, which can be used freely for device management purposes.

6.1.3.12 Variable DeviceLocation

This OPC UA Variable of DataType Location represents the AutoID Device location as Union of different coordinate systems and the related units. The DataType Location is defined in 9.4.1. The VariableType LocationVariableType is defined in 8.1.

The variable can be set during commissioning for fixed-mounted readers or can be updated automatically for mobile readers. The aim is to give the actual position where a specific scan event has been created.

6.1.3.13 Variable DeviceLocationName

This OPC UA Property of DataType String represents a user defined name of the AutoID Device location.

This variable can be used to assign a real name to the AutoID Device, e.g. “Gate 21”. It allows a device-independent event description in higher IT levels.

6.1.3.14 Variable DeviceName

This OPC UA Property of DataType String represents the AutoID Device name, which can be used freely for device management purposes.

6.1.3.15 Variable DeviceStatus

This OPC UA Property of DataType DeviceStatusEnumeration represents the AutoID Device status. The DeviceStatusEnumeration is defined in 9.2.2.

6.1.3.16 Variable AutoIdModelVersion

This OPC UA Property of DataType String represents the AutoID Information Model version. The version string for this specification version is “1.00”.

6.2 OcrReaderDeviceType

6.2.1 General

This OPC UA ObjectType represents an OCR reader device. It defines additional methods and properties required for managing OCR readers or to get additional information on the OCR scan events.

Figure 7 shows an overview for the OcrReaderDeviceType with its Object, Methods, Properties and related ObjectType. It is formally defined in Table 9.

6.2.2 ObjectType definition

The OcrReaderDeviceType is formally defined in Table 9.

The OcrReaderDeviceType ObjectType is a concrete type and can be used directly.

6.2.3 ObjectType Description

6.2.3.1 Object RuntimeParameters

This FunctionalGroup is inherited from the AutoIdDeviceType and described in 6.1. Predefined runtime parameters for for this FunctionalGroup are defined in Table 10 and described below.

Parameter TemplateName is the activate template which defines a specific identification task. The templates have to be defined during configuration.

Parameter MatchCode defines the target value for 2D and OCR decoding.

6.2.3.2 Object Images

For quality and testing purposes, the actual image taken by the OCR reader can be accessed with this object. E.g. the picture might be checked by engineers if the OCR decoding does not deliver the expected results.

The Images Object when available shall contain the list of FileType Objects (see Table 10) with the images taken by the OCR reader.

The MIME type of an image is provided through the MimeType Property of the FileType.

6.2.3.3 Method Scan

This method starts the scan process of the OCR reader device syncronous and returns the scan results. It overwrites the Scan method of the AutoIdDeviceType defined in 6.1.3.4.

Signature

	Scan (
		[in]	ScanSettings				Settings
		[out]	OcrScanResult []				Results
		[out]	AutoIdOperationStatusEnumeration	Status
		);
	

Method Result Codes

6.3 OpticalReaderDeviceType

6.3.1 General

This OPC UA ObjectType represents an optical reader device (1D or 2D codes). It defines additional methods and properties required for managing optical code readers or to get additional information on their scan events.

Figure 8 shows an overview for the OpticalReaderDeviceType with its Methods and related ObjectType. It is formally defined in Table 11.

6.3.2 ObjectType definition

The OpticalReaderDeviceType is formally defined in Table 11.

The OpticalReaderDeviceType ObjectType is a concrete type and can be used directly.

6.3.3 ObjectType Description

6.3.3.1 Object RuntimeParameters

This FunctionalGroup is inherited from the AutoIdDeviceType and described in 6.1. Predefined runtime parameters for the OpticalReaderDeviceType are defined in Table 12.

The parameters TemplateName and MatchCode are described in 6.2.3.1.

6.3.3.2 Object Images

For quality and testing purposes, the actual image taken by the optical reader can be accessed with this object. E.g. the picture might be checked by engineers if the optical decoding does not deliver the expected results.

The Images Object when available shall contain the list of FileType Objects (see Table 12) with the images taken by the optical reader.

The MIME type of an image is provided through the MimeType Property of the FileType.

6.3.3.3 Method Scan

This method starts the scan process of the optical reader device synchronous and returns the scan results. It overwrites the Scan method of the AutoIdDeviceType defined in 6.1.3.4.

Signature

	Scan (
		[in]	ScanSettings				Settings
		[out]	OpticalScanResult []			Results
		[out]	AutoIdOperationStatusEnumeration	Status
		);
	

Method Result Codes

6.4 OpticalVerifierDevice

6.4.1 General

This OPC UA ObjectType represents an optical verifier device (1D or 2D codes). It defines additional methods and properties required for managing optical code verifiers or to get additional information on their scan events.

Figure 9 shows an overview for the OpticalVerifierDeviceType with its Methods and related ObjectType. It is formally defined in Table 13.

6.4.2 ObjectType definition

The OpticalVerifierDeviceType is formally defined in Table 13.

The OpticalVerifierDeviceType ObjectType is a concrete type and can be used directly.

6.4.3 ObjectType Description

6.4.3.1 Method Scan

This method starts the scan process of the optical verifier device synchronous and returns the scan results. It overwrites the Scan method of the OpticalReaderDeviceType defined in 0.

Signature

	Scan (
		[in]	ScanSettings				Settings
		[out]	OpticalVerifierScanResult []		Results
		[out]	AutoIdOperationStatusEnumeration	Status
		);
	

Method Result Codes

6.5 RfidReaderDeviceType

6.5.1 General

This OPC UA ObjectType represents an RFID reader device including NFC reader devices. It defines additional methods and properties required for managing RFID readers or to get additional information on their scan events. The object provides also functions for accessing the user memory, writing to a tag, and more. There is no dependency to the actual RFID technology (e.g. HF, UHF).

Figure 10 shows an overview for the RfidReaderDeviceType with its Methods, Property and related ObjectType. It is formally defined in Table 14.

6.5.2 ObjectType definition

The RfidReaderDeviceType is formally defined in Table 14.

The RfidReaderDeviceType ObjectType is a concrete type and can be used directly.

6.5.3 ObjectType Description

6.5.3.1 Object RuntimeParameters

This FunctionalGroup is inherited from the AutoIdDeviceType and described in 6.1. Predefined runtime parameters for for this FunctionalGroup are defined in Table 15 and described below.

Parameter CodeTypesRWData allows the user to determine the supported code types and to select the configured CodeTypes for the diagnostics value RWData (defined in Error! Reference source not found.). This parameter is used to expose the list of supported CodeTypes. This list can contain the predefined values or vendor specific values. The Value of the Variable contains the currently selected types. The code type Strings are defined in 9.1.3.

Parameter TagTypes allows the user to determine the expected tags in a multi-type environment (e.g. ISO 14443 or ISO 15693). This parameter is used to expose the list of supported tag types. This list can contain the predefined values or vendor specific values. The Value of the Variable contains the currently selected types. The following Strings are defined by this specification.

ISO 14443

ISO 15693

ISO 18000-2

ISO 18000-3 Mode1

ISO 18000-3 Mode2

ISO 18000-3 Mode3

ISO 18000-4

ISO 18000-61

ISO 18000-62

ISO 18000-63

ISO 18000-64

EPC Class1 Gen2 V1

EPC Class1 Gen2 V2

Parameter RfPower is used to adjust radio transmission power, per antenna.

Parameter MinRssi is the lowest acceptable RSSI value (see also Strength field in RFIDSighting).

Parameter EnableAntennas determines the antennas that shall be used by the RfidDevice for its operation. The value is a binary selection of the antennas. Each bit represents one antenna, max. 32 antennas can be addressed.

• Bit0 corresponds to antenna number 1, Bit1 corresponds to antenna number 2, …

• A Bit value of 1 means an activated antenna, a Bit value of 0 a deactivated antenna. E.g.: The value BIN 1101 = DEC 13 enables the antennas 1+3+4

• A total value of 0 of EnableAntennas does not have any effect. The general device configuration can just be limited, not extended by EnableAntennas. E.g. if a four-port reader has three antennas activated according to the general configuration, it is not possible to activate the antenna four via EnableAntennas.

6.5.3.2 Object Diagnostics

The Diagnostics FunctionalGroup and its component, the LastAccess FunctionalGroup, are described in clause 6.1.3.3.

Predefined parameters that are specific for the LastAccess FunctionalGroup in the RfidReaderDeviceType are defined in Table 15 and described in the following list:

• Parameter RWData specifies the user data which was written to / was read from the Rfid Transponder by the command. The DataType can be one of the DataTypes defined in the ScanData Union defined in 9.4.2. Due to the use case for limited OPC UA Clients, the DataType is normally String or ByteString.

• Parameter Antenna specifies the antenna with which the transponder was accessed by the command.

• Parameter CurrentPowerLevel specifies the power level with which the transponder was accessed by the command.

• Parameter PC specifies the Protocol Control Word of the transponder accessed by the command.

• Parameter Polarization specifies the Polarization with which the transponder was accessed by the command.

• Parameter Strength specifies the Rssi value with which the transponder was accessed by the command.

6.5.3.3 Method Scan

This method starts the scan process of the RFID reader device synchronous and returns the scan results. It overwrites the Scan method of the AutoIdDeviceType defined in 6.1.3.4.

Signature

	Scan (
		[in]	ScanSettings				Settings
		[out]	RfidScanResult []			Results
		[out]	AutoIdOperationStatusEnumeration	Status
		);
	

Method Result Codes

6.5.3.4 Method KillTag

This method will process a kill command e.g. like specified in GS1 EPCglobal™, ISO/IEC 18000-63 and ISO/IEC 18000-3. The related standard depends on the RFID technology which is in use. The kill command allows an interrogator to permanently disable a transponder.

See Annex B for technology specific mappings.

Signature

	KillTag (
		[in]	ScanData					Identifier
		[in]	CodeTypeDataType				CodeType
		[in]	ByteString					KillPassword
		[out]	AutoIdOperationStatusEnumeration	Status
		);
	

Method Result Codes

6.5.3.5 Method LockTag

This method is used to protect specific areas of the transponder memory against read and/or write access. If a user wants to access such an area, an access password is required.

See Annex B for technology specific mappings.

Signature

	LockTag (
		[in]	ScanData					Identifier
		[in]	CodeTypeDataType				CodeType
		[in]	ByteString					Password
		[in]	RfidLockRegionEnumeration		Region
		[in]	RfidLockOperationEnumeration		Lock
		[in]	UInt32					Offset
		[in]	UInt32					Length
		[out]	AutoIdOperationStatusEnumeration	Status
		);
	

Method Result Codes

6.5.3.6 Method SetTagPassword

This method changes the password for a specific transponder.

The Method should only be called via a SecureChannel with encryption enabled.

See Annex B for technology specific mappings.

Signature

	SetTagPassword (
		[in]	ScanData					Identifier
		[in]	CodeTypeDataType				CodeType
		[in]	RfidPasswordTypeEnumeration		PasswordType
		[in]	ByteString					AccessPassword
		[in]	ByteString					NewPassword
		[out]	AutoIdOperationStatusEnumeration	Status
		);
	

Method Result Codes

6.5.3.7 Method ReadTag

This method reads a specified area from a tag memory.

One Method invocation reads one AutoID Identifier. The Call Service used to invoke the Method can take a list of Methods. Therefore a list of AutoID Identifiers can be read by passing in a list of Methods to the Call Service.

See Annex B for technology specific mappings.

Signature

	ReadTag (
		[in]	ScanData					Identifier
		[in]	CodeTypeDataType				CodeType
		[in]	UInt16					Region
		[in]	UInt32					Offset
		[in]	UInt32					Length
		[in]	ByteString					Password
		[out]	ByteString					ResultData
		[out]	AutoIdOperationStatusEnumeration	Status
		);
	

Method Result Codes

6.5.3.8 Method WriteTag

This method writes data to a RFID tag.

See Annex B for technology specific mappings.

Signature

	WriteTag (
		[in]	ScanData					Identifier
		[in]	CodeTypeDataType				CodeType
		[in]	UInt16					Region
		[in]	UInt32					Offset
		[in]	ByteString					Data
		[in]	ByteString					Password
		[out]	AutoIdOperationStatusEnumeration	Status
		);
	

Method Result Codes

6.5.3.9 Method WriteTagID

This method initializes an EPC-ID inclusive the PC of an ISO 18000-63 tag.

See Annex B for technology specific mappings.

Signature

	WriteTagID (
		[in]	ScanData					Identifier
		[in]	CodeTypeDataType				CodeType
		[in]	ByteString					NewUId
		[in]	Byte						AFI
		[in]	Boolean					Toggle
		[in]	ByteString					Password
		[out]	AutoIdOperationStatusEnumeration	Status
		);
	
	

Method Result Codes

6.5.3.10 Variable AntennaNames

This OPC UA Property of DataType AntennaNameIdPair array represents the list of ID and name pairs for the antennas of the RFID reader device. The DataType AntennaNameIdPair is defined in 9.3.3. The Property can be set during commissioning.

6.5.3.11 Variable LastScanAntenna

This OPC UA Variable of DataType Int32 belongs to the Variable LastScanData and represents the ID of the antenna with which the last AutoID Identifier was scanned.

The Variable can be provided for simple applications where OPC UA Clients are limited to Data Access functionality. Such OPC UA Clients are typically limited to built-in DataTypes like UtcTime. The use of this Variable implies the following restrictions.

Only one AutoID Identifier can be delivered for a scan.

The frequency of scans is limited to the sampling interval set by the OPC UA Client.

The delivery of scan results depends on the MonitoredItem settings or Read behaviour of the OPC UA Client.

It is recommended that complex applications use scan Methods and Events.

6.5.3.12 Variable LastScanRSSI

This OPC UA Variable of DataType Int32 belongs to the Variable LastScanData and represents the RSSI Value with which the last AutoID Identifier was scanned.

The Variable can be provided for simple applications where OPC UA Clients are limited to Data Access functionality. Such OPC UA Clients are typically limited to built-in DataTypes like UtcTime. The use of this Variable implies the following restrictions.

Only one AutoID Identifier can be delivered for a scan.

The frequency of scans is limited to the sampling interval set by the OPC UA Client.

The delivery of scan results depends on the MonitoredItem settings or Read behaviour of the OPC UA Client.

It is recommended that complex applications use scan Methods and Events.

6.6 RtlsDeviceType

6.6.1 General

This OPC UA ObjectType represents an RTLS device. It defines additional methods and properties required for managing RTLS sensors or systems, and to retrieve information on located objects, either via a direct method call or returned by location events.

Figure 11 shows an overview for the RtlsDeviceType with its Methods, Property and related ObjectType. It is formally defined in Table 16.

6.6.2 ObjectType definition

The RtlsDeviceType is formally defined in Table 16.

The RtlsDeviceType ObjectType is a concrete type and can be used directly.

6.6.3 ObjectType Description

6.6.3.1 Method Scan

This method executes the location acquisition process of the RTLS device or system. It overwrites the Scan method of the AutoIdDeviceType defined in 6.1.3.4.

Signature

	Scan (
		[in]	ScanSettings				Settings
		[out]	RtlsLocationResult []			Results
		[out]	AutoIdOperationStatusEnumeration	Status
		);
	

Method Result Codes

6.6.3.2 Method GetLocation

This method queries the RTLS device or system synchronous and returns the location of an object. Depending on vendor-specific implementation, it may initiate a location or range acquisition and synchronously return a result, or the RTLS device may return the last known location of the object (the age of the last location acquisition will be apparent from the timestamp returned in the result).

Signature

	GetLocation (
		[in]	ScanData			Identifier
		[in]	CodeTypeDataType		CodeType
		[in]	LocationTypeEnum		LocationType
		[out]	RtlsLocationResult	Result
		);
	

Method Result Codes

6.6.3.3 Method GetSupportedLocationTypes

This method returns the RTLSLocationTypes (as defined in RTLSLocationTypeEnum and in section 8.3) the RTLS device or system supports. At least one Type must be returned. The first type that is returned (first position in the resulting array) is the default type that the RTLS device or system will use.

Signature

	GetSupportedLocationTypes (
		[out]	LocationTypeEnumeration[]	SupportedLocationTypes
		);
	

Method Result Codes

7 OPC UA EventTypes

7.1 General

The following Figure 12 provides an overview of the different AutoID reader Scan Event types.

The following Figure 13 provides an overview of the different AutoID reader Diagnostic Event types.

The Events created by AutoID devices can be received by all OPC UA clients that subscribe for the Events from a device.

7.2 AutoIdScanEventType

The AutoIdScanEventType is formally defined in Table 17.

This event is the abstract definition of an AutoID scan event. It will be fired by the AutoID Device after execution of the ScanStart Method or after a scan triggered by the reader device.

The ScanResult contains the results of the scan execution. The ScanResult DataType is defined in 9.3.8.

The DeviceName contains the name of the AutoID Device that executed the scan.

7.3 OcrScanEventType

The OcrScanEventType is formally defined in Table 18.

This event is the definition of a scan event for OCR reader devices. It will be fired by the AutoID Device after execution of the ScanStart Method or after a scan triggered by the reader device.

The ScanResult contains the results of the scan execution. The OcrScanResult DataType is defined in 9.3.9.

7.4 OpticalScanEventType

The OpticalScanEventType is formally defined in Table 19.

This event is the definition of a scan event for optical code readers. It will be fired by the AutoID Device after execution of the ScanStart Method or after a scan triggered by the reader device.

The ScanResult contains the results of the scan execution. The OpticalScanResult DataType is defined in 9.3.10.

7.5 OpticalVerifierScanEventType

The OpticalVerifierScanEventType is formally defined in Table 20.

This event is the definition of a scan event for optical code verifiers. It will be fired by the AutoID Device after execution of the ScanStart Method or after a scan triggered by the verifier device.

The ScanResult contains the results of the scan execution. The OpticalVerifierScanResult DataType is defined in 9.3.11.

7.6 RfidScanEventType

The RfidScanEventType is formally defined in Table 21.

This event is the definition of a scan event for RFID readers. It will be fired by the AutoID Device after execution of the ScanStart Method or after a scan triggered by the reader device.

The ScanResult contains the results of the scan execution. The RfidScanResult DataType is defined in 9.3.12.

7.7 RtlsLocationEventType

The RtlsLocationEventType is formally defined in Table 22.

This event is the definition of a location event for RTLS devices or systems. It will be fired by the AutoID Device or system after execution of the ScanStart Method or after a scan triggered by the RTLS device or system.

The ScanResult contains the results of the scan execution. The RtlsLocationResult DataType is defined in 9.3.15.

7.8 AutoIdDiagnosticsEventType

The AutoIdDiagnosticsEventType is formally defined in Table 23.

This event is the abstract definition of an AutoID diagnostics event. It will be fired by the AutoID Device after the occurrence of specific diagnostics data.

The DeviceName contains the name of the AutoID Device that performed the diagnostic action.

7.9 AutoIdLogEntryEventType

The AutoIdLogEntryEventType is formally defined in Table 24.

This event is the definition of a Log Entry diagnostics event for AutoID devices. It will be fired by the AutoID Device after a new entry to the Logbook was written.

The new entry to the Logbook will be provided in the Event field Message defined by the BaseEventType.

7.10 AutoIdAccessEventType

The AutoIdAccessEventType is formally defined in Table 25.

This event is the definition of an Access diagnostics event for AutoID devices. It will be fired by the AutoID Device after at least one AutoID Identifier was accessed by a command, including the Scan command.

Client contains the name of the client application which was the originator of the command.

Command contains the executed command. Dependend on the kind of the client application, the names of the commands may vary. When the client application is an OPC UA Client, the names shall correspond to the command names used within this specification, e.g. “ReadTag” for the execution of the ReadTag command.

The AccessResult contains additional values of the AutoID Identifier access. The AccessResult DataType is defined in 9.3.17.

7.11 RfidAccessEventType

The RfidAccessEventType is formally defined in Table 26.

This event is the definition of a Rfid Access diagnostics event for Rfid devices. It will be fired by the Rfid Device after at least one Rfid Transponder was accessed by a command, including the Scan command.

The AccessResult contains additional values of the transponder access. The RfidAccessResult DataType is defined in 9.3.18.

7.12 AutoIdPresenceEventType

The AutoIdPresenceEventType is formally defined in Table 27.

This event is the definition of a Presence diagnostics event for AutoID devices. It will be fired by the AutoID Device if the number of AutoID Identifiers (e.g. Codes or transponder), seen by the device, changes.

Presence identifies if there currently is seen an AutoID Identifier by the device. If supported by a device, it may show the concrete number of AutoID Identifiers.

8 OPC UA Variable Types

8.1 LocationVariableType

This VariableType is used for location information. The Properties defined by this type provide the units used for the different information contained in the location information. The LocationVariableType is formally defined in Table 28.

The LengthUnit Property of DataType EUInformation represents the unit with which the AutoID Device returns length measurements, e.g. for coordinates. Examples are meters, millimetres, inches, miles, etc.

The RotationalUnit Property of DataType EUInformation represents the unit with which the AutoID Device returns rotational measurements, e.g. to express the orientation of an object. Examples are degrees, radians, gon, etc.

The GeographicalUnit Property of DataType EUInformation represents the unit with which the AutoID Device returns geographical coordinates. Examples are deg[°] min[‘] sec[“]; deg[°] min.decimal_fraction_min[‘] or deg.decimal_fraction_deg[°].

The SpeedUnit Property of DataType EUInformation represents the unit with which the AutoID Device returns the current speed of a located object. Examples are m/s, km/h or mph.

9 Mapping of DataTypes

9.1 Primitive data types

9.1.1 LocationName

This DataType is a String that represents an arbitrary name given to a location. It can be used to return location denominations in a simple way, independent of complex coordinate structures.

Its representation in the AddressSpace is defined in Table 29.

9.1.2 NmeaCoordinateString

This DataType is a String that represents a GPS coordinate as defined by NMEA 0183 v. 4.10.

Its representation in the AddressSpace is defined in Table 30.

9.1.3 CodeTypeDataType

This DataType is a String that represents a code type used for an AutoID Identifier.

Its representation in the AddressSpace is defined in Table 31.

The values in the CodeTypeDataType are extensible by individual manufacturers, starting with "CUSTOM:”. Predefined values are defined in Table 32

Transponder as well as optical 2D-Codes are data carrier for information usually displayed in bits and bytes. But the contained information could be organized in a certain structure. How to do this in a norm conforming way is described in the standard ISO/IEC 15434 “Syntax for high capacity ADC Media” (ADC stands for Automatic Data Capture).

The two most prominent data structures in use are following the rules of GS1 and the ASC MH1. They are described in the standard ISO/IEC 15418 (Data Identifier and Application Identifier).

It is the purpose of these international standards to define the syntax for high capacity ADC media (such as transponder or 2D-Codes), in order to enable ADC users to utilize a single mapping utility, regardless of which high capacity ADC media is employed.

The interoperability of different data structures is achieved by the definition of a Message Header and a Format Header. While the Message Header defines the start and the end of the data contained, the Format Header indicates which data format is used.

Below two examples are shown for a GS1 and an ASC data format.

Example GS1

<Macro05>01312345123457GS1012345GS17101231

Interpretation by the Reader

]d1[)>RS05GS0134012345123457GS1012345GS17101231RSEOT

Example ASC MH 10

<Macro06>25PLEABCBQ3DGS1T234567GS14D101231

Interpretation by the Reader

]d1[)>RS06GS 25PLEABCBQ3DGS1T234567GS14D20101231RSEOT

For RFID the data structures are controlled by AFIs (lower 8 bits of PC) when ISO format is used according ISO/IEC 15961-2 and -3. Depending on the AFI different data compression methods may be used. Details are described for example in ISO 17363, 17364, 17365, 17366 and 17367.

9.2 Enumeration DataTypes

9.2.1 AutoIdOperationStatusEnumeration

This DataType is an enumeration that specifies the status for the AutoID operations like scan, read, write, lock or kill. Its values are defined in Table 33.

Not all status values are usable for all AutoID reader types. The table contains flags to indicate the expected status values for the different reader types.

Its representation in the AddressSpace is defined in Table 34.

9.2.2 DeviceStatusEnumeration

This DataType is an enumeration that defines operational states of an AutoID Device. Its values are defined in Table 35.

Its representation in the AddressSpace is defined in Table 36.

9.2.3 LocationTypeEnumeration

This DataType is an enumeration that defines the format of the location of an object returned by an RTLS device or system. Its values are defined in Table 37.

Its representation in the AddressSpace is defined in Table 38.

9.2.4 RfidLockOperationEnumeration

This DataType is an enumeration that defines the operational mode of the LockTag Method Its values are defined in Table 39.

Its representation in the AddressSpace is defined in Table 40.

9.2.5 RfidLockRegionEnumeration

This DataType is an enumeration that defines the memory region that a lock operation affects. Its values are defined in Table 41.

Its representation in the AddressSpace is defined in Table 42.

9.2.6 RfidPasswordTypeEnumeration

This DataType is an enumeration that defines the type of a password. Its values are defined in Table 43.

Its representation in the AddressSpace is defined in Table 44.

9.3 OPC UA Structure DataTypes

9.3.1 General

The Stuctured DataTypes in this chapter are formally defined in two different table formats.

One table format has the columns Name, Type and Description for the definition of standard OPC UA structures where all structure elements are mandatory and must be transported between OPC UA Client and Server.

The second table format has the columns Name, Type, Optional and Description for the definition of OPC UA structures with optional structure elements.

9.3.2 Structure DataType Overview

The following Figure 14 provides an overview of the Structure DataTypes defined for the AutoID Device access.

9.3.3 AntennaNameIdPair

This DataType is a structure that defines a pair of RFID antenna ID and antenna name. Its composition is formally defined in Table 45.

Its representation in the AddressSpace is defined in Table 46.

9.3.4 LocalCoordinate

This DataType is a structure that defines the location of an object in a Cartesian local coordinate system arbitrarily chosen during configuration of an RTLS system. Its composition is formally defined in Table 47.

Its representation in the AddressSpace is defined in Table 48.

9.3.5 Position

This DataType is a structure that defines the position and the size of a code or a plain text within an image (so-called code area, used by OCR and optical code readers). Its composition is formally defined in Table 49.

Its representation in the AddressSpace is defined in Table 50.

9.3.6 ScanDataEpc

This DataType is a structure that defines the structure of the scanned data in Epc_1 format. Its composition is formally defined in Table 51.

Its representation in the AddressSpace is defined in Table 52.

9.3.7 ScanSettings

This DataType is a structure that defines the settings for a scan execution. Its composition is formally defined in Table 53.

Its representation in the AddressSpace is defined in Table 54.

9.3.8 ScanResult

This DataType is a structure that defines the results of a scan. Its composition is formally defined in Table 55.