RFID Simulation of the US Pharmaceutical Supply Chain

© Auto-ID Labs 1

Modeling Registry Network Traffic in the Pharmaceutical Supply Chain

A State Machine Approach to Supply Chain Simulation John R. Williams, Abel Sanchez1, Paul Hofmann, Tao Lin, Ph.D., Michael Lipton, Krish Mantripragada2

1 MIT Auto-ID Laboratory 2 SAP Research Labs, Palo Alto

© Auto-ID Labs 2

Summary In the future, when the Internet of Things becomes reality, serialized data (typically RFID

and/or barcode, based on EPCglobal, DOD/UID and other standards) can potentially be stored

in millions of data repositories world wide. In fact, large data volumes of serialized

information may be coming soon, as the global healthcare industry moves towards deploying

anti-counterfeiting standards as soon as 2009. Those data will be sent to enterprise

applications through the EPC Network Infrastructure. The data volume, message volume,

communication and applications with EPC Network Infrastructure will raise challenges to the

scalability, security, extensibility and communication of current IT Infrastructure. Several

architectures for EPC Network Infrastructure have been proposed. So far, most pilots have

focused on the physical aspects of tag readings within a small network of companies. The lack

of data quantifying the expected behavior of network message traffic within the future EPC

Network Infrastructure is one of the obstacles inhibiting industry moving to the next level.

This paper presents a simulator aimed at quantifying the message flows within various EPC

Network architectures in order to provide guidance for architecting a scalable and secure

network.

© Auto-ID Labs 3

1. Introduction and Motivation RFID/EPC technology enables the tracking of physical objects through their lifecycle without

direct human involvement. Through the wide range of initiatives, such as the one with retail

giants (Wal-Mart and Target), with Food and Drug Administration (FDA), numerous state

Boards of Pharmacy, aerospace (Airbus and Boeing), and Department of Defense (DoD) [1],

RFID/EPC/UID has demonstrated its great value for business operation automation. Taking

an airplane part as an example, it has the potential to be in any place of the world. Therefore,

the data for tracking this part can be recorded from any location. Considering the diversity of

organizations potentially dealing with this part: manufacturer, airline, maintenance and repair,

there could be thousands of data repositories that might record the information related to this

part.

The data stored in the data repositories and also on RFID tags with the new IT infrastructure

together form the EPC Network Infrastructure for the Internet of Things. Considering data

operations with an airplane part, the number of data repositories, the data volume, the number

of messages through the network, the business operations and business applications involved

are potentially far beyond the capacity of today’s IT infrastructure.

With the joint effort by academia and industry, RFID\EPC technology has made great

progress in the past few years. Up to now, most pilots have focused on the physical aspects of

© Auto-ID Labs 4

tag readings within a small network of companies. No quantified data has been collected for

the potential EPC Network Infrastructure. Several architectures for the EPC Network

Infrastructure have been proposed. However, due to the lack of the mechanism for evaluating

these architectures with quantified data, no common criteria can be researched.

This paper presents a supply chain simulator in order to obtain the quantified data of the

message flow in the future EPC Network Infrastructure. The design and development of such

a simulator is a complicated task as a number of dimensions needs to be considered, such as

scalability, extensibility, security, privacy, communication frequency, and in-time response.

The rest of this paper is organized as follows. Section 2 analyzes the requirements of the

simulator through a Pharmaceutical use case. Section 3 presents the software architecture for

this simulator environment. Section 4 discusses a few implementation issues and gives some

initial results. Section 5 concludes this paper.

2. Requirements

2.1 The Pharmaceutical Supply Chain Counterfeit and compromised drugs are increasingly making their way into the public

healthcare system and are considered a threat to the public health by the Food and Drug

Administration (FDA) [2]. Counterfeit pharmaceuticals are a $32 billion dollar industry

representing 10 percent of the global market, according to the FDA. The recent increase in

© Auto-ID Labs 5

patients in the U.S. receiving fake or diluted drugs is focusing more attention on the need for

drug authenticity. In 2003, 18 million tablets of the cholesterol-lowering drug Lipitor, the

world’s best-selling prescription drug in 2004, were recalled by Pfizer in the United States

after fake pills were found in pharmacies [3]. In 2004, the FDA reported 58 counterfeit drug

cases, a 10-fold increase since 2000 [4].

Supply chains consist of several kinds of enterprises, such as manufacturers, transportation

companies, wholesalers, and retailers. The pharmaceutical supply chain is one of the most

complex supply chains and can have as many as a dozen or more enterprises between the

manufacturer and the customer. Recently, the growth of counterfeiting has led to a number of

states in the United States of America considering laws that require the pedigree of every

saleable unit of drugs be tracked. To date, over 30 states have proposed or passed pedigree

legislation. In the case of California a digital document tracking each saleable unit with a

unique identifier must be initiated by the manufacturer, transmitted downstream step by step

to the dispensing pharmacy, and appended to by each enterprise along the way, with digitally

signed details of every shipping and receiving event. There are several proposals being

considered for how this digital document should be produced. The FDA Counterfeit Drug

Task Force has recommended “a combination of rapidly improving ‘track and trace’

technologies and product authentication technologies” to protect the pharmaceutical drug

supply (Combating Counterfeit Drugs, Feb 18, 2004).

Four feature characteristics are paramount to widespread adoption and impact:

• Automated – the high volume and high variance of pharmaceutical packages makes it

impractical for supply chain participants to economically authenticate packaging manually.

Therefore, there is a need for authentication that is automated – needing little to no human

© Auto-ID Labs 6

involvement or interpretation to authenticate the packaging. Automated Strong Authentication

requires electronic acquisition of information from product packages in mass and without

special handling.

• Secure – In order to have high confidence that the product is authentic, the expected features of

the package, either physical, electronic or the combination of both, must be difficult or

economically impractical to duplicate and simulate.

• Private - Concerns for consumer privacy must be respected.

Response in-time – As companies cannot ship or use product until pedigrees are received and authenticated, timely response for all pedigree-related transactions is required

2.2 Options for e-Pedigree In varying degrees, all of the state and federal legislative initiatives require a document to be

passed along the supply chain along with the physical product. Many of these states, such as

California, require an electronic document tied to unique serial numbers. The e-Pedigree

standard recently ratified by EPCGlobal Inc. provides a ratified XML schema for such a

document (see Figure 7.1).

© Auto-ID Labs 7

Safe & Secure Supply Chain

Authentication

Product Identity

Physical Features

Pedigree

Track

Trace

Is the Product Genuine?

Is the Chain of Custody Intact?

Is the EPC associated with the item valid?

Does the item have expected covert or overt features?

Where is the product and where is it headed?

Where was the product? (Locations and Custodians)

Figure 1 Base Reference Model for Secure Supply Chain (EPCGlobal Inc. E-Pedigree)

Thus, when the manufacturer makes a shipment of say N items a pedigree document will

accompany the shipment listing the manufacturer, the date of shipment, the type of product,

and the EPC codes of all the items. A hash of this document is then computed and signed with

the manufacturer’s private key (using the public key infrastructure). Upon, receiving the

goods the wholesaler will add to the e-Pedigree details of the receipt and will again hash and

sign the document. The wholesaler will then add further to the document upon shipment.

This, process is repeated at every receipt and shipment event until the goods reach the

dispensing pharmacy. At each level, the signed inbound e_Pedigree documents must be

embedded into the outbound document, creating a complex nested document.

One disadvantage of this system is that downstream customers may gain knowledge of

upstream enterprises business practices. For example, if the manufacturer produces only one

© Auto-ID Labs 8

e-Pedigree document for say 500 items then everyone downstream can see that the

manufacturer shipped this quantity of goods. To obviate this issue, manufacturers may choose

to produce a separate e-Pedigree document for every item (or case) shipped.

There is concern in the industry that the size and number of e-Pedigree documents will be

large resulting in a problem as the system scales.

2.1.1. The Registry concept

Several alternatives to the document passing scheme have been proposed. One alternative is

that e-Pedigree “fragments” remain with the “owner” and that the “fragments” be assembled

“on the fly” only if required by some authority. Thus, instead of passing on the actual e-

Pedigree document, a link to this “fragment” would be either passed along the supply chain or

possibly passed to some third party registry. Within this concept there are numerous

variations, with more or less information stored in the registry, implying more or less effort

to assemble the pedigree when required.

© Auto-ID Labs 9

3. Supply Chain Network Simulator In order to explore the implications of various approaches to granularity, security, and

alternative pedigree models, a simulator is being developed. The simulator is composed of

N supply chain tiers, such as Manufacturer, Wholesaler or Retailer, where each tier may have

an arbitrary number of facilities. Each facility is modeled as a state machine running in its

own thread of execution.

Just like the links in a metal chain the members of a supply chain may only have business

relationships with their immediate neighbors. They may or may not know about more distant

members of the chain and even if they are aware of their existence they may not have a

business relationship with them.

The supply chain functions by executing business events between trading partners. One party

initiates an event by sending a message to the other party, such as a Purchase Order (P.O.

message).

The state of a facility is determined by the number of Purchase Orders it has pending and how

much stock it has accumulated in its Warehouse. The simulation is driven by Purchase Orders

that are submitted “upstream” by the retail tier. Goods are manufactured in response to

purchase orders and are shipped “downstream”. Initial results show the simulator is capable of

modeling 100,000 facilities and 100 million items of product being injected into the system

per day. The load on the registry can vary by a factor of over 1000 in peak to average load

with around 200 messages per second being the peak load for a 1 million per day flow.

© Auto

3.1

The sys

facility

“Ports”.

“endpoi

Service

Figure 2

The ph

Wholes

-ID Labs

Softwa

tem is desig

is totally in

. Facilities a

ints” that ca

endpoints o

2 Simulator

hysical supp

aler, Tier 2

are Arch

gned to run

ndependent o

are known b

an be either

on a differen

r Layers wit

ply chain i

2 Wholesale

hitectur

on a single

of all other

by their “Fa

references

nt machine.

th Scheduler

is organize

er, and so o

re

machine in

facilities an

acilityID” an

to facility o

.

r and Regis

d into Tier

on with the

n a massivel

nd interacts

nd the Sche

objects on th

stry Services

rs, such as

Retailer Ti

ly threaded

by receivin

eduler maint

he same ma

s

s Manufact

er being th

environmen

ng messages

tains a regis

chine or We

turing Tier,

e final Tier

10

nt. Each

s on

stry of

eb

, Tier 1

r (Figure

© Auto

2). The

orders a

Figure 3

There a

the Sou

goods b

purchas

Request

Both the

example

Request

day the

elapsed

million

manufac

warehou

-ID Labs

e physical g

are propagat

3. The Supp

re two spec

urce and Sin

because the

ser of good

ts into the s

e source an

e, the flow

ts to the Re

en once the

to reach st

items per

cture goods

uses is finit

goods flow

ted upstream

ply Chain O

cial Facilitie

nk. These a

Source act

ds and also

ystem.

nd the sink c

of goods t

etail Tier. F

e purchase

teady state

r day. This

s and there

e.

w downstrea

m until a fac

Organized in

es in our mo

are named

ts as the un

o simulates

can be used

through the

For example

orders hav

the average

s can be

e is no los

am from th

cility is able

nto Tiers and

odel that are

from the p

niversal prod

s purchaser

to control t

e system ca

e, if the Sin

ve reached

e flow of p

easily seen

s of goods

he manufact

e to satisfy t

d Facilities

e not in the

perspective

ducer of go

rs’ demand

the flow of

an be contr

nk issues re

the manufa

physical goo

n since on

in the sys

turer to the

them.

physical su

of the prod

oods. The S

ds by issuin

goods throu

rolled by th

equests for

acturers and

ods through

nly the uni

stem, and t

e retailer. P

upply chain,

duction of

ink is the u

ng Purchas

ugh the syst

he Sink issu

1 million it

d enough t

h any tier w

iversal Sou

the capacity

11

Purchase

, namely

physical

universal

se Order

tem. For

uing PO

tems per

time has

will be 1

urce can

y of the

© Auto-ID Labs 12

3.2 Purchase Order Request When a purchase order request message is posted to a facility the facility checks its

warehouse for the items required. If the warehouse can fulfill the order then the items are sent

to “shipping” were they are stored until shipped. If the warehouse cannot fulfill the order then

the order is sent to the PO Consolidation Store and a copy is sent to the PO Pending

Fulfillment Store. The items sent to the PO Consolidation Store are aggregated by SKU ID

and held there until a trigger from the Scheduler initiates sending the new consolidated POs

upstream. The facility therefore generates new PORs and these may be issued in “bursts” at

various times of the day. These bursts do not generate event traffic to the Registry but to add

variability to the supply chain.

The facility is able to aggregate purchase orders and hold them for some period of time. In a

real supply chain a distributer may apply various strategies to manage their inventory,

including pre-ordering items based on past history. The simulator is able to accommodate

such strategies.

3.3 Purchase Order Fulfilment When physical goods representing a filled inbound purchase order arrive at a facility they are

immediately moved to the Warehouse. When new stock arrives in the warehouse the store of

outbound POs Pending Fulfillment are scanned to see if any can now be filled. If an outbound

PO Request can now be filled the items are removed from the warehouse and sent to Shipping

where they await a shipping event trigger from the Scheduler.

© Auto-ID Labs 13

4. Implementation

4.1 Modelling Facilities as State Machines Each facility is represented as a state machine running in its own thread of execution. The

state of the facility is modified by two kinds of events, namely Purchase Order Request

Messages (POR) that represent purchase orders and Purchase Order Filled Messages (POF)

that accompany goods being received. These messages are received on two external message

ports, one for each kind of message. The state of the facility is represented by the following:

1. The number and type of goods stored in the Warehouse as a result of goods received,

2. The Unfulfilled POR Store that keeps track of purchase order requests that have been

sent upstream but have not yet been filled. ie goods are not yet available in the

Warehouse to fill these orders.

There are also two temporary stores, namely the Shipping Store, where goods are

accumulated before being shipped downstream and the Consolidated PO Store where

incoming POs that cannot be filled locally by the Warehouse are aggregated and then sent

upstream as new POR messages. These temporary stores are “emptied” and the messages

fired upon receipt of trigger messages from the global “Scheduler”. The Scheduler allows us

to inject delays into the facility that represent the time taken by the facility to say ship goods

from the Warehouse.

These two stores, one for digital documents (POs) and the other for physical goods

(Warehouse) allow us to add rules and strategies into how purchase orders are aggregated and

the timing of their submittal. For example, we might consolidate all purchase orders for one

© Auto

day and

warehou

Figure 7

4

The Sch

that dete

rate at w

also pro

shipped

-ID Labs

d only subm

uses fulfill i

7.4 The Fac

.2 The S

heduler keep

ermine the r

which purch

ovides “Tim

d downstream

mit them ups

incoming pu

cility State M

Schedu

ps track of

rate at whic

hase orders

mers” that s

m and when

stream ever

urchase ord

Machine Sh

uler

all the facil

ch manufact

are injecte

send trigger

n POs are se

ry 24 hours

ders.

howing Inco

lities. It also

tured goods

d by the ret

r events to t

ent upstream

. Similarly

oming and O

o provides a

s are injecte

tailers in re

the facilitie

m.

we can var

Outgoing Ev

a number of

d into the su

esponse to g

es that contr

ry the way i

vents

f control par

upply chain

goods being

rol when go

14

in which

rameters

n and the

g sold. It

oods are

© Auto-ID Labs 15

The messages for POR and POF are inherited from the base POMessage class shown below.

Each message contains a PO and the address of the sender of the message. The Scheduler is

responsible for translating FacilityIDs to actual endpoints to which the message is delivered.

These endpoints are called “Ports” and are the building blocks of our simulator.

public class PO { public FacilityID nextDestination; public int skuID; public int numItems;

}

public class POMessage { public PO body; public FacilityID senderFacilityID; }

4.2.1 The Port Abstraction

One novel aspect of the simulator is that it is built upon the Microsoft Coordination and

Concurrency Runtime [4]. The runtime provides support for multi-threaded

programming. It provides an abstraction called a Port that deals with messages of a

single type. A port allows messages to be “Posted” to it and there is a buffer that stores

the messages. A multi-cast delegate can be attached to the Port and when messages

arrive on the Port they are passed to the delegate for processing. There is the concept of

“Activating” a port which triggers the passing of the messages to the delegate

© Auto

fun

exa

Figure 5

A port

laptop it

Since th

to pass

message

goods to

The CC

POF m

indepen

4.

The sim

third pa

-ID Labs

nction(s). T

ample, we c

5 The Port

with no me

t is possible

hese “intern

on its mes

es to the R

o or from a

CR arranges

messages ar

ndently (as a

.2.2 The

mulator is ca

arty registry

The way in

can wait unt

Abstraction

essages in i

e to create a

nal ports” co

ssages to a

Registry we

Facility to

s for every

e injected

autonomous

Registry

apable of sim

. There are

n which me

til N messag

n Showing t

its buffer co

around 7 mi

orrespond c

an external

can easily

a Registry W

Port to run

into the s

s state mach

mulating the

two kinds o

essages are

ges have arr

the Buffer a

onsumes ar

llion ports.

closely to so

Web Servi

push mess

Web Servic

n in its own

simulator th

hines).

e message t

of message t

e buffered c

rived before

and the Dele

round 175 b

ockets it is q

ice for proc

sages repres

e on a remo

n thread of e

he facilities

traffic both b

traffic to th

can be con

e passing th

egate Functi

bytes of me

quite easy t

cessing. Th

senting ship

ote machine

execution. T

s respond

between fac

e registry, n

ntrolled so

hem to the fu

ion

emory, so t

to arrange fo

hus, to simu

pment or re

e.

Thus, once

to these m

cilities and

namely “I’v

16

that for

function.

hat on a

for a port

ulate the

eceipt of

POR or

messages

also to a

ve

© Auto-ID Labs 17

touched EPC X” messages, and query messages of the kind “Who has seen EPC X?” The

first kind of message traffic results from shipments received (incoming POFs) and from

shipments shipped (outgoing POFs). This traffic places into the registry notification events for

each EPC code involved. A typical message might contain the following: EventType, EPC,

Shipper, DateTime, Receiver, PedigreeHash, PedigreeURI

According to the EPCIS 1.0 specification this traffic is likely to aggregate together all EPCs

read at one time (we note that there is as yet no specification for these messages). It is likely

that these messages will conform either to the EPCIS 1.0 specification or something quite

similar. (Appendix I shows an EPCIS 1.0 conformant Ship Order Event)

The Registry will probably respond to such messages with a simple acknowledgement, and

therefore the incoming messages can be buffered by the Registry to smooth any peaks in the

message traffic.

The second kind of message traffic results from queries, such as Pedigree queries, which

require a more elaborate response and which are likely to be time sensitive. Thus, these

queries should be answered in a “timely” manner by the Registry. The query response time

will depend on the volume of data to be searched (EPC data must be stored for several years)

and therefore partitioning of the Registry data may be critical. MIT and SAP are presently

working on strategies for partitioning in-memory databases spread over many machines

(based on the Google model).

4.2.3 Security and Authorization

© Auto-ID Labs 18

One element affecting the latency of the Registry responses is how authentication and

authorization will be achieved. If there is a single Registry and all supply chain participants

have security credentials pre-established then there are a number of standard methods for

dealing with both authentication and authorization. Authentication (who is making the query)

can be established by using X.509 certificates and the PKI [999] infrastructure. Authorization

requires the Registry to answer the question, “Does this person have permission to retrieve

data related to this EPC?” This is a more complex question because to answer it the Registry

must have knowledge of the kind of item to which the EPC is attached. For example, the EPC

might be attached to a packet of cornflakes or to a cruise missile. In the latter case, even

details about what companies are involved in the supply chain might be secret, let alone

details about the present location of the missile. Thus, the Registry must have “business rules”

that depend on the type of item (its SKU) and on the roles associated with that item.

If there are multiple Registries with multiple security boundaries (i.e. Registries operated by

different enterprises) then the problem becomes more complex, since standards for

communicating queries between Registries need to be established. This problem is presently

being researched by EPCGlobal Inc and the Architectural Review Committee and by the

Auto-ID Laboratories.

5 Simulator Performance MIT and SAP are currently working on applying the simulator to analyze potential network

traffic of the pharmaceutical supply chain. Inputs for this model consist of item throughput

© Auto-ID Labs 19

statistics and queries to the Registry. Based on this model we expect to be able to develop

envelopes for the capabilities necessary for the various kinds of registry.

The present simulator, running on a Dell Latitude 620, is able to represent around one million

facilities, which consume around 1 GByte of memory. The CCR is very efficient in that only

those facilities that are “actively” processing messages consume resources. The performance

of the simulator is ultimately limited by the message traffic. Initial runs have simulated a

volume of 1million items per day with the simulator running in real time.

© Auto-ID Labs 20

APPENDIX I <?xml version="1.0" encoding="UTF-8" standalone="yes" ?>

<epcis:EPCISDocument xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:epcis="urn:epcglobal:epcis:xsd:1" xmlns:epcglobal="urn:epcglobal:xsd:1" xsi:schemaLocation="urn:epcglobal:epcis:xsd:1 EPCglobal-epcis-1_0.xsd" xmlns:hls="http://schema.hls.com/extension" creationDate="2006-06-25T07:15:00Z" schemaVersion="1.0">

<EPCISBody> <EventList> <TransactionEvent> <eventTime>2006-06-25T07:16:00Z</eventTime> <bizTransactionList> <bizTransaction

type="urn:epcglobal:fmcg:btt:po">urn:epcglobal:fmcg:bti:po:0614141073468.1</bizTransaction>

<bizTransaction type="urn:epcglobal:fmcg:btt:bol">urn:epcglobal:fmcg:bti:bol:0614141073468.A</bizTransaction>

</bizTransactionList> <epcList> <epc>urn:epc:id:sgtin:0614141.107340.1</epc> <epc>urn:epc:id:sgtin:0614141.107340.2</epc>

</epcList> <action>ADD</action> <bizStep>urn:epcglobal:fmcg:bizstep:shipping</bizStep> <disposition>urn:epcglobal:fmcg:disp:sellable_available</disposition> <readPoint> <id>urn:epcglobal:fmcg:loc:0614141073468.RP-3</id>

</readPoint> <bizLocation> <id>urn:epcglobal:fmcg:loc:0614141073468.3</id>

</bizLocation> </TransactionEvent>

<TransactionEvent> <eventTime>2006-06-25T07:17:00Z</eventTime> <bizTransactionList> <bizTransaction


© Auto-ID Labs 21

<bizTransaction type="urn:epcglobal:fmcg:btt:bol">urn:epcglobal:fmcg:bti:bol:0614141073468.B</bizTransaction>







<bizTransaction type="urn:epcglobal:fmcg:btt:bol">urn:epcglobal:fmcg:bti:bol:0614141073468.C</bizTransaction>





<TransactionEvent> <eventTime>2006-06-25T07:19:00Z</eventTime> <bizTransactionList>

© Auto-ID Labs 22

<bizTransaction type="urn:epcglobal:fmcg:btt:po">urn:epcglobal:fmcg:bti:po:0614141073468.4</bizTransaction>

<bizTransaction type="urn:epcglobal:fmcg:btt:bol">urn:epcglobal:fmcg:bti:bol:0614141073468.D</bizTransaction>







<bizTransaction type="urn:epcglobal:fmcg:btt:bol">urn:epcglobal:fmcg:bti:bol:0614141073468.E</bizTransaction>





© Auto-ID Labs 24

REFERENCES

[1] Available at http://www.acq.osd.mil/dpap/UID/

[2] Combating Counterfeit Drugs: A Report of the Food and Drug Administration Annual

Update, May 18, 2005, page 1. Available at

http://www.fda.gov/bbs/topics/NEWS/2005/NEW01179.html

[3] Cracks in the Pharmaceutical Supply Chain, January 15, 2006, page 1. Available at

http://www.cio.com/article/16565/Cracks_in_the_Pharmaceutical_Supply_Chain/1

[4] Ibid [2], page 2

[5] Giorgio Chrysanthakopoulos and Satnam Sing, “An Asynchronous Messaging Library for

C#” Microsoft Research Paper, http://research.microsoft.com/~tharris/scool/papers/sing.pdf

RFID Simulation of the US Pharmaceutical Supply Chain

Technology

Transcript of RFID Simulation of the US Pharmaceutical Supply Chain