Exchanging Data Between RFID, Sensors and Bar Code in the IoT Boston 4 May 2017 H. Sprague ACKLEY Honeywell ESC Minneapolis

Overview Exchanging Data Between RFID, Sensors, and Bar Code in the IoT Bar code data systems RFID data systems Sensor data systems Latest developments Encoding bar code data in RFID Encoding sensor data in bar code The future ESC Minneapolis

Bar code data systems Bar code data systems evolved from the concept of identifiers in 1981 Two main systems are in use today Data Identifiers (DIs) are defined by ANSI MH10.8.2 An alpha or special character preceded by 0 to 3 numeric digits For example “+” is healthcare data, 2P is a part number and S is a serial number Application Identifiers (AIs) are defined in the GS1 General Specifications 2 to 4 numeric digits For example 01 is a GTIN, 17 is an expiry date and 422 is Country of Origin ISO/IEC 15418 places these two systems in the international arena ESC Minneapolis

RFID data systems Initially, RFID only encoded a unique set of bits, i.e. not specific data Later, users wanted to encode their own data leading to: MIT Auto-ID labs  EPCglobal ISO/IEC 15962 RFID data is always serialized (i.e., you cannot encode non-serialized data in RFID, or else, how would you know which tag you read?) GS1 uses the EPC Tag Data Standard to encode AI data The rest of the world uses ISO/IEC 15962 to encode DI data ESC Minneapolis

Sensor data systems ISO/IEC 21451-7 for full-function sensors defines an IEEE-based methodology ISO/IEC 24753 for simple sensors generally for use with RFID tags includes: Temperature sensor with high and/or low out-of-range temperature alarm Relative Humidity with high and/or low out-of-range relative humidity alarm Impact sensor with an instance of out-of-range impact alarm Tilt sensor with an instance of out-of-range tilt ESC Minneapolis

Latest developments Encoding bar code data in RFID Encoding temperature sensor data in bar code ESC Minneapolis

Encoding bar code data in RFID How RFID data ended up so different from bar code data How to encode primary serialized bar code data directly into RFID UHF Gen 2 (ISO/IEC 18000-63) has four memory banks (MB) and MB01 encodes primary serialized identity GS1 encodes AI user data according to the EPC Tag Data Standard ISO encodes DI user data according to ISO/IEC 15962 ESC Minneapolis

MB01- Primary serialized identity GS1 uses Electronic Product Code (EPC) 96 bits (12 bytes), very space efficient All numeric Requires buying a “GS1 Company Prefix” ISO uses ISO/IEC 15962 Variable in length, less space efficient Can be alpha-numeric Low or zero cost enterprise identification ESC Minneapolis

MB01EPC from MIT Auto-ID labs MIT scientists envisioned an “internet of things” where everything was unique Part of their plan identified enterprises ESC Minneapolis

EPCglobal from MIT Auto-ID labs GS1 (then UCC) first joined, then bought Auto-ID Labs, then replaced enterprise identification with their own system (i.e., “Company Prefix” as used in EAN/UPC) GS1 established an independent company which they called EPCglobal ESC Minneapolis

EPCglobal Early management actively resisted unifying EPC encoding with bar code Method for encoding a unique item number broke GS1 rules in place for >25 years Encoding methods actually prevented data in bar code symbols from being encoded in an RFID tag Eventually GS1 decided to “fix” the inconsistencies ESC Minneapolis

EPC tag encoding overview EPC is 12 bytes, e.g., in hex: 30 30 25 7B F4 6D 5B 20 00 00 01 90 12 bytes is 96 bits 00110000001100000010010101111011111101000110110110110110010000000000000000000000000000110010000 Bits are counted and assigned meaning. The first 14 bits: EPC Header Filter Partition length: 8 3 3 bits: 00110000 001 100 (7-digits) ESC Minneapolis

EPC tag encoding overview 00110000001100000010010101111011111101000110110110110110010000000000000000000000000000110010000 GS1 Company Prefix bit length: 24 in this example, depends on Partition Value bits: 000010010101111011111101 digits: 0614141 Indicator Digit and Item Reference bit length: 20 in this example bits: 00011011011011011001 digits: 112345 Note: GS1 Company Prefix can be 6 to 12 digits ESC Minneapolis

EPC tag encoding overview 00110000001100000010010101111011111101000110110110110110010000000000000000000000000000110010000 Serial Number bit length:38 (fixed) bits:00000000000000000000000000000110010000 digits:400 EPC URI urn:epc:id:sgtin: 0614141.112345.400 ESC Minneapolis

Bar code to an EPC tag* ESC Minneapolis

Bar code to an EPC tag* *Note: the number of digits in the GS1 Company Prefix is not known *The Partition Value must be determined * Leading digits of the GTIN determine the partition value (e.g. compare with a database of GS1 Company Prefixes) ESC Minneapolis

GS1 has fixed the GCP problem 2007 “60-Day Review” identified concerns about bar code / RFID interoperability 2008 GS1 Missing Identification Replacement (MIR) Work Group 2009 GS1 BarCodes & EPC Interoperability Requirements Work Group 2012 GSMP BC EPC Implementation Work Group Result – a clear need for an offline tool to output the length of the GS1 company prefix (GCP) ESC Minneapolis

Length of Company Prefix tool First meeting of an ad hoc BC EPC WG to develop an offline tool on 23 August 2012 It was decided that GS1 Global Office will provide an updatable consolidated table of ranges of Global Company Prefixes First published 12 April 2016 (about 800kb) Last updated 19 December 2016 Published table available at www.gs1.org/docs/gcp_length/GCPPrefixFormatList.xml ESC Minneapolis

GCP Prefix Format List … ESC Minneapolis

MB01ISO/IEC 15962 First RFID data encoding standard Developed with the idea that “RFID data was different” than bar code data ESC Minneapolis

ISO/IEC 15962 An elaborate system of “Object IDs” was invented so each piece of data was addressable Different encoding methods are flagged by an Application Family Identifier (AFI) ESC Minneapolis

Example encoding FDA UDI data using ISO/IEC 15962 An Application Family Identifier (AFI) defines the encoding method A particularly simple AFI (A1) is useful for encoding Data Identifier data, for example, FDA UDI data according to the HIBCC Issuing Agency [ )>Rs06Gs25SRHH123DEV400RsEoT ESC Minneapolis

15962 AFI A1 encoding overview UDI = 25SRHH123DEV400 Where 25S is the UII Data Identifier (DI) RH is the issuing agency ID H123 is the Labeller Identification Code (LIC) DEV400 is the item number and serial number combination Each character is replaced by 6-bit ASCII The bits are grouped into bytes (15x6=9012) Pad to a full byte if necessary with some or all of the string “100000” ESC Minneapolis

15962 AFI “A1” encoding overview Replace each character with 6-bit ASCII value Group bits into bytes and convert to hex Insert AFI for final encoded data stream A1 CB 54 D2 20 8C 72 CC 41 56 D3 0C 20 ESC Minneapolis

Encoding temperature sensor data in bar code Temperature sensors are used on perishable items in the supply chain When the product arrives at the point-of-use, the temperature safety data is needed, often without network connectivity Many vendors produce color-change temperature sensors A need exists to be able to determine product efficacy at point-of-use ESC Minneapolis

AIM TSC to collaborate with GS1 AIM, the bar code and RFID Industry Association, has just been tasked with developing a data system using GS1 AIs for optical sensors The AI data will tell the scanner (e.g., a smart phone running an app) the sensor type and the temperature expiry parameters The first meeting to discuss the new standard was 24 April 2017 ESC Minneapolis

Temperature sensor example This symbol encodes the previous AI data plus sensor data In use, a scanner decodes the symbol and interprets the color In this case, the red color indicates the product has been exposed to temperatures at and above 18.5°C The smart phone can issue the appropriate warning, e.g., DO NOT USE – TEMPERATURE THRESHOLD EXCEEDED  ESC Minneapolis

AIM TSC – GS1 project underway Sensor standards fit with AIM’s IoT strategy GS1 US proposes creating variable-length AI (NNNN) for all sensors AIM TSC (Technical Symbology Committee) will lead an ad hoc Task Force to define the AI and to assign sensor AI data structures AIM to act as external AI Registrar for users of this AI ESC Minneapolis

Will there ever be seamless multi-application data? “Who the hell wants to watch movies with sound?“ Harry Warner, president of Warner Brothers Studios, 1918 It took nearly 20 years for the bar coded supermarket to become ubiquitous and it will probably be about the same for RFID and sensors Applications changing from internal closed-systems to fully open systems such as IoT are forcing data interchangeability Prediction: Within the five years, data in IoT applications will be data carrier independent ESC Minneapolis

Speaker/Author Details H. Sprague ACKLEY Fellow   Honeywell Safety and Productivity Solutions 16201 25th Ave W, Lynnwood, WA  98087 USA +14255018995 hsprague.ackley@honeywell.com www.honeywellaidc.com ESC Minneapolis

Thank You! Questions? @ESC_Conf ESC Minneapolis

Exchanging Data Between RFID, Sensors and Bar Code in the IoT Boston 4 May 2017 H. Sprague ACKLEY Honeywell ESC Minneapolis