RFID Simulation of the US Pharmaceutical Supply Chain

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 1

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 2

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, RFIDEPC 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 3

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 4

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 5

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 6

Safe & Secure
Supply Chain

Is the Is the Chain
Product Authentication Pedigree of Custody
Genuine? Intact?

Is the EPC
associated with the Product Where is the
item valid? Track product and where
Identity is it headed?

Does the item have Where was the
Physical
expected covert or Trace product? (Locations
overt features? Features 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 7

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 8

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-ID Labs 9

3.1 Softwa Arch
are hitectur
re

The system is desig
gned to run on a single machine in a massivel threaded environmen Each
n ly nt.

ndependent o all other facilities an interacts by receivin messages on
facility is totally in of nd ng s

“Ports”. Facilities a known b their “Fa
. are by acilityID” an the Sche
nd eduler maint
tains a regis of
stry

“endpoi
ints” that ca be either references to facility objects on th same machine or We
an o he eb

Service endpoints o a differen machine.
on nt .

Figure 2 Simulator Layers wit Scheduler and Regis Services
r th r stry s

The ph
hysical supp chain i organized into Tier such as Manufact
ply is rs, s turing Tier, Tier 1
,

Wholesaler, Tier 2 Wholesale and so o with the Retailer Tier being the final Tier (Figure
er, on r

© Auto-ID Labs 10

2). The physical g
e goods flow downstrea from th manufact
w am he turer to the retailer. Purchase
e P

orders a propagat upstream until a fac
are ted m cility is able to satisfy t
e them.

Figure 3 The Supp Chain O
3. ply Organized in Tiers and Facilities
nto d

There are two spec Facilitie in our mo that are not in the physical su
cial es odel e upply chain, namely
,

the Sou
urce and Sin These a named from the perspective of the prod
nk. are p duction of physical

goods b
because the Source act as the un
ts niversal prod
ducer of go
oods. The Sink is the universal
u

purchas of good and also simulates purchaser demand by issuin Purchas Order
ser ds o s rs’ ds ng se

Request into the system.
ts

Both the source an the sink c be used to control the flow of goods throu the syst
e nd can t ugh tem. For

example the flow of goods t
e, through the system ca be contr
e an rolled by th Sink issu
he uing PO

Request to the Re
ts etail Tier. F example if the Sin issues re
For e, nk equests for 1 million it
tems per

day the once the purchase orders hav reached the manufa
en e ve acturers and enough time has
d t

elapsed to reach st
teady state the average flow of physical goo through any tier will be 1
e p ods h w

million items per day. This can be easily seen since on the uni
r s n nly iversal Sou
urce can

manufac
cture goods and there is no loss of goods in the sys
s e stem, and t capacity of the
the y

warehou is finite.
uses

© Auto-ID Labs 11

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 12

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-ID Labs 13

day and only subm them ups
d mit stream ever 24 hours. Similarly we can var the way in which
ry ry i

warehou fulfill i
uses incoming pu
urchase ord
ders.

Figure 7 The Fac
7.4 cility State M
Machine Sh
howing Inco
oming and O
Outgoing Ev
vents

4.2 The S
Schedu
uler
The Sch
heduler keep track of all the facil
ps lities. It also provides a number of control par
o f rameters

that dete
ermine the r at whic manufact
rate ch tured goods are injected into the su
s upply chain and the
n

rate at w
which purch
hase orders are injected by the ret
tailers in re
esponse to g
goods being sold. It
g

also pro
ovides “Tim
mers” that s
send trigger events to the facilitie that contr when go
r t es rol oods are

shipped downstream and when POs are se upstream
d m n ent m.

© Auto-ID Labs 14

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-ID Labs 15

fun
nction(s). T way in which me
The n essages are buffered c be con
e can ntrolled so that for

exa
ample, we c wait unt N messag have arr
can til ges rived before passing th to the function.
e hem fu

Figure 5 The Port Abstraction Showing t Buffer and the Dele
n the a egate Functi
ion

A port with no me
essages in i buffer co
its onsumes ar
round 175 b
bytes of me
emory, so that on a

laptop it is possible to create a
t e around 7 million ports.

Since th
hese “intern ports” co
nal orrespond c
closely to so
ockets it is q
quite easy t arrange for a port
to fo

to pass on its mes
ssages to a external Web Servi for proc
an ice cessing. Th
hus, to simu
ulate the

message to the R
es Registry we can easily push mess
sages repres
senting ship
pment or re
eceipt of

goods to or from a Facility to a Registry W Service on a remo machine
o Web ote e.

The CC arranges for every Port to run in its own thread of e
CR s n n Thus, once POR or
execution. T

POF m
messages are injected into the s
simulator th facilities respond to these messages
he s m

indepen
ndently (as a
autonomous state mach
s hines).

4.
.2.2 The Registry

The sim
mulator is ca
apable of sim
mulating the message traffic both b
e t between fac
cilities and also to a

third pa registry. There are two kinds o message traffic to the registry, n
arty of t namely “I’v
ve

© Auto-ID Labs 16

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 17

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 18

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 19

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</bizTransa
ction>
<bizTransaction
type="urn:epcglobal:fmcg:btt:bol">urn:epcglobal:fmcg:bti:bol:0614141073468.A</bizTran
saction>
</bizTransactionList>
<epcList>
<epc>urn:epc:id:sgtin:0614141.107340.1</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>
<bizTransaction
ction>

© Auto-ID Labs 20

<bizTransaction
type="urn:epcglobal:fmcg:btt:bol">urn:epcglobal:fmcg:bti:bol:0614141073468.B</bizTran
saction>
<epcList>
</epcList>
<readPoint>
</readPoint>
<bizLocation>
</bizLocation>
</TransactionEvent>
<TransactionEvent>
<bizTransaction
ction>
<bizTransaction
type="urn:epcglobal:fmcg:btt:bol">urn:epcglobal:fmcg:bti:bol:0614141073468.C</bizTran
saction>
<epcList>
</epcList>
<readPoint>
</readPoint>
<bizLocation>
</bizLocation>
</TransactionEvent>
<TransactionEvent>

© Auto-ID Labs 21

<bizTransaction
ction>
<bizTransaction
type="urn:epcglobal:fmcg:btt:bol">urn:epcglobal:fmcg:bti:bol:0614141073468.D</bizTran
saction>
<epcList>
</epcList>
<readPoint>
</readPoint>
<bizLocation>
</bizLocation>
</TransactionEvent>
<TransactionEvent>
<bizTransaction
ction>
<bizTransaction
type="urn:epcglobal:fmcg:btt:bol">urn:epcglobal:fmcg:bti:bol:0614141073468.E</bizTran
saction>
<epcList>
</epcList>
<readPoint>
</readPoint>
<bizLocation>
</bizLocation>
</TransactionEvent>

© Auto-ID Labs 22

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

© Auto-ID Labs 24

RFID Simulation of the US Pharmaceutical Supply Chain

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (8)

Similar to RFID Simulation of the US Pharmaceutical Supply Chain

Similar to RFID Simulation of the US Pharmaceutical Supply Chain (20)

Recently uploaded

Recently uploaded (20)

RFID Simulation of the US Pharmaceutical Supply Chain