petri net translation patterns for the analysis of ebusiness collaboration messaging protocols

1022 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS—PART A: SYSTEMS AND HUMANS, VOL. 39, NO. 5, SEPTEMBER 2009

Petri Net Translation Patterns for the Analysis ofeBusiness Collaboration Messaging Protocols

Andrew L. Feller, Teresa Wu, Dan L. Shunk, and John Fowler

Abstract—Electronic messaging protocols such as RosettaNet(RN) automate the asynchronous exchange of business docu-ments between collaborating trading partners over the Internet.Such protocols commonly employ mechanisms such as retries,time-outs, and fault handling to overcome uncertainty in thetiming and reliability of message transmission, receipt, andprocessing. To determine the reliability and performance of sucha protocol under varying network and message processing con-ditions, we have developed reusable patterns for Petri net mod-eling of these common mechanisms and used them to assemblea timed Petri net simulation that represents the RN standard’sbehavior. The reusable patterns are derived through translationof the abstract representations provided in the RN standard intoan executable model, paving the way for a multimodeling ap-proach for supply chain communications. The resulting stochasticPetri net is simulated to generate performance curves guidingimproved protocol reliability.

Index Terms—Communication system fault tolerance, messagesystems, modeling, multimodeling, Petri nets, protocols, simula-tion, supply chain.

I. INTRODUCTION

P ETRI net models have a good track record for performancevalidation of time-dependent concurrent processes, such as

communication and messaging protocols, as demonstrated in[1]–[3]. One challenge in using this approach, however, is theneed for the analyst to generate complex Petri nets from scratch,which accurately represent a protocol’s behavioral rules andimplied event sequencing. To make this modeling process easierand more reliable, we have developed preset patterns for modelgeneration. Our purpose in presenting this research is to providea reusable set of such patterns that can improve the analysis,design, and implementation of messaging protocols used tointegrate business processes across company boundaries. Thispaper focused on modeling the popular RosettaNet (RN) supplychain collaboration standard; however, the same patterns willbe useful for modeling other communication and messagingprotocols. This research contributes to the practice of modelgeneration and presents analysis results characterizing the ro-bustness of an RN Partner Interface Process (PIP) under varying

Manuscript received June 15, 2007; revised July 11, 2008. First publishedAugust 14, 2009; current version published August 21, 2009. This workwas supported in part by a grant from Intel Corporation. This paper wasrecommended by Associate Editor M. P. Fanti.

A. L. Feller is with the Arizona State University, Tempe, AZ 85282 USA, andalso with American Express Technologies, Phoenix, AZ 85027 USA (e-mail:[email protected]).

T. Wu, D. L. Shunk, and J. Fowler are with the Department of Indus-trial Engineering, Arizona State University, Tempe, AZ 85287 USA (e-mail:[email protected]; [email protected]; [email protected]).

Color versions of one or more of the figures in this paper are available onlineat http://ieeexplore.ieee.org.

Digital Object Identifier 10.1109/TSMCA.2009.2025022

message timing and loss rate conditions. In particular, we used atimed Petri net (TPN) simulation derived from the RN protocolto determine the rates at which a single-action PIP will failwhen individual messages are lost or delayed by the network,or when a trading partner’s acknowledgment response is de-layed. This question is important because of the number of RNtransactions that are processed by firms on a continuous basis.Reviewing RN log files at a prominent semiconductor firmshowed over 400 000 PIPs processed in a month with a failurerate of approximately 3% [4]. It is of considerable importanceto determine whether the protocol’s dynamic behavior could bepart of the problem.

Our research was conducted in the context of developingmethods for translating supply chain models between levelsof abstraction. Supply chain models fall into two paradigms:conceptual models that represent the supply chain in waysthat are readily accessible for practitioners to comprehendand analysis or execution models based on mathematical andcomputer representations used to simulate and analyze systemperformance. Conceptual models are easy to understand andhave face validity but do not allow for detailed model executionand analysis of system-wide behavior. Formal analysis andexecution models allow system behavior and performance to beanalyzed or executed in a simulation environment but requireknowledge of the methodology being used and significantexpertise to build. As supply chains grow in complexity andinterdependence, more expressive and complete methods areneeded for translating and integrating conceptual and analyticalmodeling approaches to enable the analyses of the integratedflows of information and materials that determine a supplychain’s performance.

Our approach uses a multimodeling method developed usingconceptual graphs, which is a knowledge representation methodfrom the field of artificial intelligence (AI) [5]. The approachbuilds on systems theory [6] to generate translation patternsusing conceptual graphs that capture all required behaviorsspecified in the RN protocol. The patterns are then used togenerate an executable TPN.

There are three contributions made by this research. First, wedefine a set of patterns for translating RN PIPs into Petri netswhich accurately represent the messaging behavior and eventsequencing that occurs under the RN implementation frame-work (RNIF). Next, we apply these patterns to generate a com-plete Petri net model representing the asynchronous behavior ofa single-action PIP including all possible state/event paths thatthe protocol can lead to, including successful completion, fail-ure processing, and recovery. Finally, we use the derived Petrinet to analyze the performance of a PIP to determine robust

1083-4427/$26.00 © 2009 IEEE

FELLER et al.: PETRI NET TRANSLATION PATTERNS 1023

thresholds for message timing and loss rates. In particular, weanswer the question “what are the network thresholds belowwhich RN’s performance becomes unacceptably degraded?”

The following sections are organized as follows. InSection II, we provide background on multiparadigm modeling,RN, and the elements of Petri nets and conceptual graphs rele-vant to our approach. We then present our translation patterns inSection III, followed by the generation of a complete Petri netrepresenting a single-action PIP in Section IV. In Section V, wepresent analytical results for the PIP’s performance, followedby conclusions and further research in supply chain multimod-eling in Section VI.

II. BACKGROUND

This section discusses prior works in multiparadigm model-ing and introduces RN PIPs and RNIF along with the elementsof Petri nets and conceptual graphs used in our approach tomodel translation and analysis.

A. Multimodeling

This paper builds on research and practice in multimodelingframeworks. Multimodeling entered mainstream system analy-sis in the mid 1990s with a number of candidate approachesresolving into the Unified Modeling Language (UML) standard,which is an object-oriented system-modeling method that hasgained wide practical acceptance and use [7], [8]. UML’ssuccess is due in large part to the successful balancing ofthe conflicting goals of human comprehension versus rigorousanalysis [9]. UML diagrams represent systems using succinctdiagrams that aid human understanding; however, the syntaxand semantics do not directly enable formal analysis and exe-cution. UML behavior diagrams are used to represent RN PIPs;however, an approach for model translation and simulation toanalyze RN’s capabilities had not been accomplished.

To our knowledge, few works have been done to translatebetween abstraction levels in supply chain models; however,multiparadigm model translation is an emerging field with newmethodologies under development. Zeigler first developed aformal representation for discrete event simulation and dis-cussed abstraction techniques [10]. Fishwick’s early work insimulating complex processes over multiple levels of abstrac-tion in 1986 [11] began a stream of research into multimodeling[12], [13]. Fishwick and Zeigler reported on a multimodelingmethodology used to bridge levels of abstraction in qualitativemodels [14], yet the proposed framework did not solve thetranslation between multiparadigm models. As Fishwick andZiegler [14] stated:

The problem of semiautomating the process of takinga conceptual nonexecutable object-based model of thesystem and converting it into an executable model remainsa very hard problem that has taken form in AI, simulation,and software engineering.

Subsequent work by Fishwick and others has developedmultimodeling methods for real-time simulation [15] and gen-eral multimodeling software frameworks [16]. More recently,Vangheluwe et al. [17] describe the emerging field of multi-

paradigm modeling, asserting it can assist with the following:1) transformation between models described in different for-malisms; 2) clarifying relationships between models at differ-ent levels of abstraction; and 3) describing models in formalspecifications or metamodeling.

A number of multiformalism metamodels have been de-veloped for translating between models described in differentformalisms [18]; however, the focus has been on linking ana-lytical models, such as in the hybrid environments surveyed byBarton and Lee [19], which link discrete event simulation withdifferential and algebraic equations, and not with linking acrosslevels of abstraction.

Mapping between levels of abstraction in simulation frame-works is beginning to be addressed at simulation conferences[17], [20]–[22]; however, model translation in the context ofsupply chains has not been addressed. Current research worksreported in the IEEE TRANSACTIONS ON SYSTEMS, MAN,AND CYBERNETICS—PART A, ACM Transactions on Mod-eling and Computer Simulation, and IEEE TRANSACTIONS

ON CONTROL SYSTEM TECHNOLOGY [18], [23], [24] focuson modeling imbedded control systems and translating betweenanalytical formalisms. Kim et al. [25] use hybrid modelingto represent traffic networks; however, specific techniques fortranslating supply chain models are not considered. Still, someof the conclusions reached for analyzing these systems arerelevant to the supply chain domain. For example, Lee and Hsu[26] translate between UML diagrams and Petri nets for modelexecution and conclude that UML diagrams lack the precisesemantics needed for qualitative and quantitative analyses ofsystem behavior. Lin and Jeng also transform UML diagramsinto Petri nets to verify the logical correctness and dynamicbehavior of a system framework [27], and Du et al. [28]extend message sequence charts using Petri nets to analyze thesoundness of cooperative workflows. Similar to our approach,these researchers all use Petri nets for analysis. In their works,however, they provide no formal mechanism or patterns fortranslation, relying on the modeler’s expertise to perform themapping. Researchers have translated UML diagrams into sev-eral variants of Petri nets, such as object coordination nets [29],[30], colored or high-level Petri nets [31]–[33], generalizedstochastic Petri nets [34], [35], and other approaches includinggeneralized semi-Markov processes [36], queuing networksbased on execution graph/machinery models [37], and first-order temporal logic [38]. These studies, however, did not focuson patterns for model translation or on messaging protocols.

Similar to this paper, prior UML diagram translations havefocused on the behavioral diagrams that come closer to defininga finite state machine for an object’s behavior. The addition ofrigor for execution is required due to problems in the formaltractability of statecharts for specifying and verifying designs[39]. The UML diagrams and derived executable models shareproperties that allow the modeling primitives to be corre-lated, leading to partial mappings of one modeling approachto another. Graph grammars provide a compact method fortranslation between graphical system representations but lackthe semantic richness needed to map from abstract conceptualmodels to an executable representation. This leaves a gap inthe current research—translation patterns between conceptual


Fig. 1. UML diagrams representing single-action PIP 4A1: “Notify of Strate-gic Forecast.”

and executable models needed in the supply chain domain.Our method for model translation uses system theory andconceptual graphs to fill this gap. We build on Fishwick’sframework [13] for classifying models using system theory toorganize our approach and provide a formal basis for modeltranslation.

B. Conceptual Model: RN

RN PIPs are specialized system-to-system eXtended MarkupLanguage (XML)-based dialogs used to execute businessprocesses between trading partners [40]. Each PIP specificationincludes a business document with XML vocabulary and abusiness process with the choreography of the message dialog.Several hundred different PIPs are used to automate standardinformation flows between supply chain participants, such asexchanging forecasts and transmitting orders, and thousandsof partner connections have been implemented in industry.It is not unusual for a trading partner to execute millionsof PIP transactions in a year, yet the conceptual model formost exchanges is quite simple. Every PIP specification usesa UML sequence diagram to document a prespecified two-way transaction pattern for the intercompany business processand a modified UML statechart diagram to further define thePIP functional behavior (see Fig. 1) [41]. In this example, thesuccess path has one trading partner sending a business messagecontaining a forecast notification. Once the message format isverified, the receiving partner sends an acknowledgment.

In addition to these diagrams, PIP specifications containtables and text specifying trading partner roles and performancecontrols, such as retry and time-out parameters.

The general behavior for fault management required of allPIPs is specified in the RNIF. RN uses a two-stage processfor validating and processing business messages, which firstdetermines if it is readable and well formatted. If it is, an ac-

Fig. 2. Two-stage validation and processing of an RN message.

knowledgment signal is returned to the sender. If not readable atall, the receiver waits for a resend. If readable but not correctlyformatted, an exception signal is sent, and the originator ofthe PIP aborts processing. After a correctly formatted messageis acknowledged, the receiver then processes the message’sbusiness content. This second stage can complete normally orfind a business rule violation in the content, leading to a sub-sequent error condition. Depending on whether the PIP wouldhave been completed by this message and acknowledgmentsignal or would have required a subsequent responding businessmessage, the failure to process the business content resultsin either an exception signal message or the initiation of aNotification of Failure (NoF)—PIP 0A1. The invocation of theNoF PIP begins another pattern of PIP execution with a two-stage process for validating and processing the NoF messageand its own sequence of retries and message processing. Thisgeneral pattern for the two-stage process of handling a receivedRN message is shown in Fig. 2. The RNIF specification pro-vides flowcharts and descriptive text defining these messagevalidation and error handling processes, but no methods orguidelines for analysis.

We have chosen RN as our conceptual model for three rea-sons. First, it provides a structured starting point for developingmodel translations for supply chain messaging.

Second is our interest in determining causes for observedfailure rates in RN transactions. Finally, the patterns derivedfrom RN can be used to analyze other protocols, such as theEuropean Internet Electronic Data Interchange (EDI) guide-lines [42].

C. Translating to an Executable Model: Petri Nets

A Petri net is a bipartite directed graph of alternating placeand transition nodes connected by arrows [43]. States arerepresented by places shown as circles on the graph. Events arerepresented by transitions that are shown as bars. The places canhold tokens represented by dots within a circle. Finally, a tran-sition rule specifies how tokens migrate through the network.The basic rule is that all of the places preceding a transitionmust hold a token in order for the transition to fire. Firing thetransition then removes a token from each of the transition’sinput places and puts tokens in each of the transition’s outputplaces. Formally specified, a Petri net structure “S” is as afour-tuple: S = (P, T, I,O), where P = {p1, p2, p3, . . . , pn}is a finite set of places, T = {t1, t2, t3, . . . , tm} is a finite set


of transitions, the set of places and transitions is disjoint, I isthe input function that maps places to transitions, and O is theoutput function that maps transitions to places.

Sometimes the I and O functions are combined into a singleflow function F . The state of a system is represented by tokensusing a marking vector M with an integer valued number oftokens (≥ 0) at each place in P .

A number of Petri net variants have been applied to sup-ply chain and communication protocol modeling. This paperfocused on timed place transition (P/T) nets. A P/T net addsinteger valued arc weights and places capacities to the netdefinition to achieve a more concise representation. TPNs allowthe representation of temporal behavior by adding a durationparameter to the transitions of a Petri net. This allows theexecution of a modular form of discrete event simulation thatcan be used to characterize system behavior using traditionalsimulation techniques. The duration or delay timings can alsobe represented as random variables. The assignment of expo-nentially distributed random variables to the duration periodsin a TPN defines a stochastic Petri net. Petri nets have beenused for modeling and analysis of the quality of Web servicesby Xiong et al. [44] and combined with network simulationtools by Ye and MacGregor to enable formal verification of thecorrectness of a network protocol [45].

We build upon this background to develop Petri net transla-tion patterns that accurately represent the behavior of the RNmessaging protocol and the RNIF. To document the patterns,we use conceptual graphs. Conceptual graphs are a synthesisof Peirce’s existential graphs [5] with dependence graphs andthe semantic networks of AI and can be translated to logicallyequivalent expressions in predicate calculus [5], [46]. A con-ceptual graph is a connected bipartite graph made of conceptnodes and conceptual relation nodes. Every relation node hasone or more arcs, each of which must be connected to someconcept. Concepts are mapped into a set of type labels, andthe type labels are arranged into a hierarchical lattice called atype hierarchy which imposes a partial ordering based on themeaning of the concept types. Conceptual relations are alsomapped into a hierarchy with relations of the same type havingthe same number of arcs.

Conceptual graphs have been used in the development ofexpert systems, semantic database retrieval, inference capabili-ties, and natural language processing. Feller and Rucker usedconceptual graphs to extend structured analysis modeling inthe analysis of shop floor system requirements, developing ametamodel for system analysis that generated a TPN [47], [48].Willumsen [49] developed a method for generating executableprototypes from conceptual models using rule-based languages,but this was a general approach for model execution focusedon information system design and not tailored for supply chainmodeling. Baresi and Pezze [31] used graph grammars todevelop customization rules for translating UML models intoPetri nets; however, the graph grammars lack the richness ofconceptual graphs’ ability to ground the mappings semanticallyand the extensibility to develop new and varying translations. Inour use of conceptual graphs to generate Petri net patterns forRN, we limit our type hierarchy of concepts to two fundamentaltypes: states (Q in system theory notation) and transitions (δ in

Fig. 3. Example of a conceptual graph translation pattern.

system theory notation). The states and transitions are labeledto provide semantic relevance for the translation patterns.

A simple example for translating a portion of the RNIFflowchart for sending a message that also enables retries intoa Petri net is shown in Fig. 3.

III. TRANSLATION PATTERNS

Translation patterns for generating Petri nets for RN PIPswere derived by first analyzing PIP and Petri net representationsusing the system theory framework to characterize the requiredmapping. This clarified underlying patterns of abstraction,specification, and representational capability that the modelingapproaches provide. This was followed by conceptual modelingof the constructs needed to span the gap from the RN model toan executable Petri net.

A. System Theoretic Analysis

The initial step uses the seven elements of system theoryto analyze RN PIP and RNIF specifications, including text,tables, and diagrams. Our analysis of the expressive capabilityof the RN model from a knowledge representation standpointprovides a formal basis for correlating modeling elements fromRN to the states and events of a Petri net.

To demonstrate, consider an example PIP: 4A1—Notify ofStrategic Forecast and system theory’s time set variable T . Inthe RN conceptual model, time is captured by numbering stepsin a UML sequence diagram in a fashion similar to a flowchart.The business operational view for a PIP specification providesthe modified statechart diagram shown in Fig. 1 [41]. Start andend state conditions are given in the PIP specification alongwith a 2-h time limit to acknowledge receipt and a maximumretry count of three. An RN UML sequence diagram for thisinteraction set specified in the functional service view of thePIP specification is also shown in Fig. 1. This diagram showsthe sequencing of the forecast notification and acknowledg-ment, which is a simple two-step handshake. Based on theseviews, the time set for this PIP can be described as an indexvariable representing the time at which the system reaches oneof four possible states. The possible states are the initial orSTART state, a “Request Sent” intermediate state, and eithera successful “Acknowledge Received” END state or a FAILEDstate. The examination of the intermediate request sent state,however, shows that there are elements of the state set Q thatare not represented. This state may last for up to 8 h (up to threeretries with 2-h maximum duration each for acknowledgment);


TABLE IANALYSIS OF RN AND PETRI NET MODELS USING SYSTEM THEORY ELEMENTS

however, the UML diagram does not represent the number ofrequests sent or how long the state might endure—these are im-plicit and result from other information provided in tables in thePIP specification and the rules for retries specified in the RNIF.

Comparing the time set for the target executable model, aTPN formulation for simulating this sequence would require aplace initialized with a token count to explicitly represent theallowed number of retries, a counter place for the number ofattempted retries, a failure transition that requires three retrytokens, and a timed retry transition. This indicates the need foradditional modeling primitives in the executable representationthat the RN diagrams do not contain. As demonstrated usingthis example, the time set T and state set Q are modelingelements that must be augmented when translating an RN PIPinto a Petri net.

In similar fashion, our analysis focused on identifying all dif-ferences in the seven system modeling elements in the RN spec-ifications and the required elements needed in a Petri net model.We cataloged the modeling capabilities of the RN specificationsand the required Petri net, and their respective placement inthe system theory framework. The application of this approachidentified five key differences. These were the following.

1) The time set T . As described, the representation of ex-plicit time sequences is needed for intermediate statesand events. Some information about timing is providedin text, tables, and flowcharts in the PIP specification butis not included in the specification in a structured format.

2) The output set Y . RN PIPs do not have a fully de-fined output function. The sequence diagrams show areturn response, but the RN specifications call for failureprocessing to be specified in individual trading partneragreements, allowing the possibility of an ambiguous endstate. The Petri net will require specific places to holdtokens representing the end state of both trading partners.An additional specification of places is needed for repre-senting all messages that retries and error processing mayrequire.

3) The state set Q. RN does not specify a complete setof internal trading partner states. The diagrams for thePIP show that the internal conditions other than start and

end may be stateless. The Petri net, on the other hand,must include explicit places for the intermediate states ofeach trading partner and must represent the dependencestructures that determine timing and sequencing for eachof these states.

4) The transition function δ. Petri net transitions and execu-tion rules are required to allow net execution, and a com-plete transition function between all states is required.The state changes represented on RN PIP diagrams arenot fully formed since the trading partner roles haveno internally defined states and, therefore, no transitionfunction.

5) The output function λ. Finally, the RN specificationhas no formal output analysis functions such as reach-ability analysis. This is an obvious difference betweenconceptual and executable models: the lack of a formalcapability for output analysis of system behavior. A Petrinet allows analysis for specific properties of the overallsystem. Various output functions are needed, dependingon the desired analysis, for example, analysis for possibledeadlock states, or simulation results to characterize RN’sperformance.

These results are summarized in Table I. Our analysis ex-posed a lack of system theoretic elements in the RN PIP andRNIF specifications needed to analyze a PIP’s behavior.

In particular, RN specifies a limited time set, state set, outputset, and transition function and has no output function for ana-lytical results. RN does specify a more thorough input set anda detailed definition of the allowed content for each message.The gaps we identified pinpoint the model elements that needto be added to an RN conceptual model to make it executable.In particular, a Petri net model for a PIP must add places torepresent all possible messages, including exception signals andnotifications of failure, and requires a sequential state/executionmodel that reflects the implied time set, including retries,acknowledgment time-out, and exception processing, to derivethe complete set of possible states, i.e., the output set.

The next step in developing general patterns for RN PIPs wasrecognizing that partner roles interact solely by the exchange ofinterface messages in specific sequences and time frames and


Fig. 4. All possible interface messages for a single-action PIP success orfailure.

listing these interface messages as states with transitions forsending and receiving them. For the single-action PIP patterns,there are eight possible interface messages:

1) single-action PIP messagesa) initial message: Msg;b) acknowledgment: Ack;c) exception: Excp;

2) NoF messagesa) sender NoF: S-NoF;b) acknowledgment of sender NoF: S-NoF Ack;c) responder NoF: R-NoF;d) acknowledgment of responder NoF: R-NoF Ack;

3) out of band messagesa) manual reset.

These messages are organized for generating the Petri net, asshown in Fig. 4, with the interface messages in the middleand send/receipt transitions on either side representing thetrading partner’s actions. The success path for this type ofPIP is represented by the top two rows of two message placesand two send/receive transition pairs. All other messages andsend/receive transitions are used for failure processing.

Next, a set of patterns for modeling the internal states of thetrading partners connected to the interface messages is specifiedusing conceptual graphs.

B. Conceptual Graph Pattern Mapping

RN is a message passing protocol; thus, we begin by focusingon the business and signal (acknowledgment and exception)messages that can be sent and the process specifications forsending and receiving them.

RNIF provides flowcharts to define the process for mes-sage retries, receipt, acknowledgment, validation, and failureprocessing; however, the flowcharts cannot be directly trans-lated due to ambiguous states and processes in the conceptualmodel. To execute properly, two patterns were formulated torepresent the messaging structure. The first, shown in Fig. 5,handles retries beginning with a start state and the initiating“send message” event. This is followed by two states: a sentmessage and the enablement of retries. Subsequent states andevents capture the retries and the possible resulting states, in-

Fig. 5. (a) Conceptual graph: Send message with retries. (b) Resulting Petrinet pattern for retry mechanism.

cluding a retry failure, an acknowledgment leading to success,or receipt of an exception signal leading to an exception failure.Note that there is a general pattern that can be used to modelretries with a transition that initiates retries (A), and output forretries (B), retry failure (C), and transitions that halt retries dueto success or failure events (D).

The second pattern follows from Fig. 2, represents the re-ceipt, validation, and processing of a business message by themessage recipient, and signals results to the sender. This patternbegins with the message-sent state from the prior graph andallows the recipient to handle unreadable or invalid messages.As specified in the RNIF, this pattern also enables resendingan acknowledgment or exception signal if a subsequent retrymessage is received. These patterns are shown in Fig. 6.

The other significant pattern required for the analysis ofan RN PIP behavior is processing a failure notice: RN PIP0A1—NoF. RN has defined this special PIP for handling failurenotification when a failure arises after the normal processing ofa PIP may be completed by the other trading partner. This re-quires special handling to ensure that the status of the businessprocess being conducted remains synchronized between bothparties. When a NoF is received, the recipient must abort thecurrent process and prevent subsequent processing no matterwhat state he/she is in. This requires an interrupt scheme andthe capability to clear any possible state occurring when theNoF is received. In addition, the NoF receipt must be ac-knowledged to alert the trading partner when (and whether) theprocess state has been synchronized; otherwise, an out of band


Fig. 6. Conceptual graph and resulting Petri net pattern for RNIF compliant message receipt, validation, processing, and signaling of success or failure.

communication is required. The conceptual graph pattern andresulting Petri net structure for processing a failure notice areshown in Fig. 7. This graph starts with the failure notificationstate and includes a general pattern of linkages to the potentialstate and event sets that must be cleared or aborted when a NoFmessage is received. Note that, for clearing an undeterminedstate, the model requires an intermediate state for processingthe NoF and a series of events (labeled δA, δB , δC , etc.) forclearing any potential state that the trading partner might be in.The output of this graph is a failure state for the PIP initiatorand a closed incomplete state for the PIP recipient. This patternmust be combined with the first pattern for sending an action

message, so that retries are generated for the NoF as well. Asspecified in the RNIF, a retry failure for the NoF does notgenerate another NoF but goes to an out of band communication(e.g., a phone call) to reset the process.

The translation patterns shown in Figs. 5–7 augment the RNmodel for analysis. The time set is specified using timed tran-sitions, the state and output sets now contain all intermediatestates and possible outcomes, and the transition function iswell defined based on the constraint of alternating state/eventnodes and the use of Petri net firing rules. Output functionsare also available using Petri net analysis capabilities, such asreachability graphs and simulations.


Fig. 7. Conceptual graph and resulting Petri net structure for processing aNoF—PIP 0A1.

The following conventions have been used to simplify theconceptual graphs. State concepts are labeled with Q andsubscripted with a state label. Event or transition conceptsare labeled with δ and subscripted with an event label, andtimed events have a bold outline. Arrows without a conceptualrelation (circle) imply a functional flow relation linking statesand events. In one instance, an increment action is used. Con-ceptual graphs use a diamond for actors that can perform analgorithm, for example, incrementing a counter for the numberof retries.

The only remaining element needed for model execution isthe input set Ω. Tokens are initially required in the set {QStart,QRetriesLeft (3), QNo Readable Msg, and QNo NoF Rcvd}.Adding the initial marking completes the executable model.

IV. APPLICATION—SINGLE-ACTION PIP

The patterns we developed were combined to compose acomplete Petri net for a single-action PIP. The first step was tolink the patterns to the business and signal interface messagesthat can occur. For a single-action PIP, there is one businessmessage and two potential NoF messages that require retrymechanisms. The business message can be responded to by

TABLE IIREGRESSION TESTING PATHS FOR A SINGLE-ACTION PIP

an acknowledgment or an exception, and the NoF can beacknowledged or not—in which case, an out of band resetmessage is required. These messages are represented by sentmessage states at the interface between the trading partners.Transitions are added to send, receive, and possibly lose eachof these interface messages. A composition process was usedto combine the patterns to generate the complete Petri net.

One key feature of the net is a processing gate with aninitialized token indicating that no NoF has been received. Thisplace is used as an input and an output for all processing stepsother than those used to process a failure notification. Thisfreezes processing regardless of state when the trading partnerreceives a failure notice.

It should be noted that earlier attempts to develop a Petrinet representing RN PIP behavior without these patterns wereconsiderably more difficult and time consuming, yet resultedin a network that was overspecified and had process anomaliesthat were only discovered later during testing. This motivatedour development of reusable patterns representing commonbuilding blocks of protocol behavior.

Regression testing of the pathways that the process can takewas initially used to determine the correctness of the result. Thisregression testing exercised all of the contingencies identifiedin Table II. Through structured token game exercises withthe model, we were able to validate correct processing andaddress unforeseen contingencies when augmenting the modelfor continuous simulation.

The resulting Petri net structure is shown in Fig. 8. Surpris-ingly, the resulting network for a simple single-action PIP has238 562 possible states, making the analysis of the reachabil-ity tree cumbersome. For this reason, the resulting structurewas additionally tested using linear temporal logic (LTL) withBüchi Automota using the TPN analyzer (TINA) from the


Fig. 8. Complete Petri net for a single-action PIP.

LAA–CNRS [50] to assure that the only output (deadlock)states correspond to the synchronized outputs specified by theprotocol (END or FAIL) and that one of these final states isalways achieved.

LTL statements for checking this are shown in (1) and (2)using LTL symbols [ ] (box) for always and 〈〉 (diamond) foreventually

[ ] (QStart ⇒ 〈〉 ((QEnd ∧ QComplete)∨(QFailed ∧ QClosedIncomplete))) . (1)

Equation (1) indicates that the start state always eventuallyleads to either the End/Complete or the Failed/Closed Incom-plete state. To assure that these are the only end states, the LTLchecker is used to test (2). This tests that the End/Completeand Failed/Closed Incomplete states are the only cases thatdeadlock

¬ ((QEnd ∧ QComplete) ∨ (QFailed ∧ QClosedIncomplete))⇒ ¬DEAD. (2)

Results from these tests were true, indicating that the modelallows only synchronized end states. Additional verificationusing reachability and simulation ensured that the model’sbehavior matched the RN specification.

We augmented the Petri net with additional structure toreset initial conditions and enable continuous processing of themodeled protocol with variable random choice of process paths,message loss rates, and variable random delay timings. Thisallowed running the model for a 100 000 iterations in a fewminutes, allowing all paths to be exercised and verifying that thefrequency of intermediate states conforms to what is expectedand allowable.

This also allowed controlled experimentation for perfor-mance analysis. Results from these experiments are reportedin the following section.

V. PERFORMANCE ANALYSIS

The Petri net structure was created and analyzed using theset of publicly available research tools shown in Fig. 9. ThePlatform Independent Petri net Editor [51], [52] was used toconstruct the net and perform visual token game simulations,invariant analysis, and model testing. This editor generates astandard Petri Net Markup Language file that is readily inputinto the TINA tool mentioned earlier for LTL model checkingand formatting. A textual output from TINA was then modifiedmanually to generate an input file for a TPN tool [53] forrunning simulations. To simplify the generation of multipleruns, additional patterns were devised to reset token markings to


Fig. 9. Petri net tools used for model construction and analysis.

the original start state and capture protocol success and failurecounts for output analysis.

The augmented Petri net for TPN simulation requires notransient since each run starts in a known state and can runmany thousands of iterations in less than a minute. The TPNtools allow probabilities to be defined for the transitions fol-lowing free-choice places. This allows network message lossrates to be specified using transitions for lost messages thatwere added to each interface message. The tools also allowfor deterministic or stochastic (exponentially distributed) timedtransitions. Deterministic transitions were used for the time-outof retries and stochastic transitions for message transmissionand acknowledgment processing times. C language functionsfor pseudorandom sampling imbedded in the tool generate thedelay. The TPN tools were operated with a script to enable inputparameters to be modified for each set of runs. One hundredthousand runs were simulated for each setting to generate a ratioof protocol successes versus failures.

Two research questions were considered: 1) What is the im-pact of network conditions on RN’s success rate and 2) what isthe impact of a trading partner’s delay to acknowledge a mes-sage on the success rate? The network condition question fo-cuses on how robust the protocol is to network-caused messagelosses and stochastic message delivery timing. In other words,what are the network performance thresholds below whichthe RN protocol’s performance begins to degrade and becomeunacceptable? The second question considers how sensitive theprotocol is to acknowledgment processing and response time. Inother words, how long is “too long” for a trading partner to senda response. Full factorial experiments were run to answer thesequestions, running the Petri net over a wide range of reasonableparameter values.

A. Sensitivity to Network Conditions

Experiments were run to determine the protocol’s sensitivityto message transmission speed and loss rate. With variable con-ditions on the Internet and trading partners that span the globe,messages take varying amounts of time to get to their destina-tion and may be lost with varying frequency. For our analysis,we varied random message loss rates in 1% increments from0.1% to 10% and varied the average message speed using anexponentially distributed processing time in increments from6 to 24 min. Acknowledgment time was pegged at twice themessage transmission time to allow for reasonable message-acknowledgment turnaround. These experiments showed that

Fig. 10. Protocol sensitivity to network conditions.

the RN protocol for a single-action PIP achieves highly reliablecommunications (> 99%) as long as the message loss rateis below 6% for very fast (i.e., 6 min) message transmissionand below 3.5% for very slow (i.e., 24 min) transmission. Formessage loss rates above 4%–5%, the performance degrades,losing about 0.4% in yield for each percentage increase in indi-vidual message loss. These results are summarized graphicallyin Fig. 10, where transmission times were adjusted to provide avisible spread in the curves. These results are not tractable ana-lytically due to repeated interactions between retried messagesand probabilistic message loss and delay timing.

B. Sensitivity to Acknowledgment Processing Time

Additional experiments were run to determine the protocol’ssensitivity to delays in acknowledgment response time. Usingan exponential random variable for delay, the average delaytime was varied in regular increments from 1.2 min to 15 h. Theprotocol is very robust to acknowledgment delays as long as theacknowledgment time is less than an hour and then degradesquickly, losing nearly 10% for each additional hour of averagedelay. This is not surprising; the protocol is asynchronous andshould be able to handle reasonable delays in response.

Still, it shows that average downtimes longer than an hourin a trading partner’s responding system will begin to createfailed PIPs that need to be handled. These results are showngraphically in Fig. 11.

After completing our simulation analysis, we determinedthat the result for exponentially distributed delay times mightbe determined analytically by combining three cumulative


Fig. 11. Protocol sensitivity to acknowledgment delays—simulated and ana-lytical results.

exponential distributions. If the probability of success for asingle retry is governed by the cumulative exponential distri-bution in

P(success) =1−e−(Time−out/(ProcessingDelay+AckTransmitDelay))

(3)

then assuming independence with three retries, the protocolyields a success/delay curve according to

Y ield=1−((

1−P(success)

)(1−P(success)

)(1−P(success)

)). (4)

Graphing the analytical versus simulated results (Fig. 11)verifies the Petri net simulation; however, the simulation canbe used to determine performance parameters that analyticalsolutions cannot such as cycle time. Cycle time analysis per-formed using our model showed potential business impacts inscenarios where RN is used to transmit time-sensitive data suchas for just-in-time inventory replenishment.

We found that, when degraded network performance andresponse delays cause PIPs to fail between 0.025% and 1.5% ofthe time, the successful PIPs complete in less than 2 h between68% and 82% of the time and less than 4 h over 94% of the time.

The PIPs that do fail under these conditions, however, takemore than 6 h to fail and reset between 55% and 94% of thetime. Even with rapid partner response, network failure ratesthat exceed 3% begin to cause failed PIPs to take over 6 h morethan 13% of the time, indicating that using RN for just-in-timeoperations that must complete the same day may not be robustunless network conditions are adequate.

The prediction of failure rates for the protocol based ontrading partners’ ability to respond might be used to assess thecosts of manually resetting failed transactions in a high volumetransaction environment. We have observed RN transaction logfiles [54] that indicate a preponderance of failed PIPs comefrom relatively few specific trading partners. This analyticalresult supports the establishing of an objective benchmark foracknowledgment response times in the 5-min range to improveprotocol performance.

VI. CONCLUSION AND FUTURE RESEARCH

We conclude with several comments about our work and adiscussion on future work to generalize and automate the use ofour patterns through the use of a composition algorithm.

This research has been validated through testing and analysisaugmented with comparisons to industry logs of RN trans-actions. We find the model consistent with the RN protocolspecification and our observations of the protocol’s behaviorin practice, but we were unable to characterize the log filesstatistically for comparison with our results since networkdelays, loss rates, and acknowledgment delays could not beextracted from the logs and we were limited to viewing the logson site due to proprietary restrictions.

We also recognize a number of needed extensions, such asanalyzing the RN two-action PIP and other protocols suchas the GS1 EDI over the Internet Transport CommunicationGuidelines [42] which allow for configurable retry schedules.For the GS1 guidelines, it would be useful to determine howtuning the retry mechanism can improve robustness underdegraded network conditions and processing delays.

An area of interest considered for future work is the gener-alization and automation of model translation using the mes-saging behavior patterns we developed. We have looked intocomposition rules for using these patterns and have some usefulresults. First, the protocol to model must conform to the samerules as RN, such as timed retries, a two-stage process forvalidation and processing of messages, and a rule that abortsprocessing when a failure message is received. An algorithmfor composing a model using our patterns would then beginby classifying the interface messages that are sent between theparties into categories that commonly occur in communicationprotocols. In RN, we have the following four: 1) message-WithRetry; 2) acknowledgmentSignal; 3) exceptionSignal; and4) failMessageWithRetry.

Each message is represented by a place with transitionsattached to send, receive, and possibly lose the message. Thepatterns attach to the appropriate message send and receivetransitions: retry patterns to send the messages with retry;receipt pattern with validation, processing, and signaling ofresults to the receipt of these messages; and failure processingto the receipt of exception and fail signals. One key to makingan algorithmic process work is attributing the places and tran-sitions in the patterns to indicate the states that must be clearedand events that must be prevented when an exception or failurenotice is received. Then, the necessary “clear state” transitionscan be added and linked to a “Process Failure Notice” stateplace to pull a token from each possible internal state place, andinternal event transitions can be linked to a “No-NoF Received”place to prevent internal events when the process aborts.

We performed this algorithm manually when composing thePetri net for our study; however, when extending the patternsto handle a greater number of interactions such as in RN’s two-action PIP, we found that considerable additional complexitywas introduced due to a proliferating number of potentialstate combinations that occur across the trading partner bound-ary and the addition of a time-out clock maintained by thePIP originator. Time-out is an additional failure mechanism


implemented in the RNIF for two-action PIP that is still beingconsidered in our research.

For example, whether an exception occurs during the initialvalidation of message format or later during processing, themessage requires two different exception states. This is be-cause, for the latter, the acknowledgment of message formatwill deactivate the retry timer. Thus, one type of exception de-activates a timer, but the other does not. Adding the possibilityof a time-out failure for the PIP originator requires the additionof new message places to handle exception signals that may besent after an acknowledgment signal has deactivated the time-out mechanism.

When we consider the challenge of supply chain messagemodeling more generally, we note that the creation and applica-tion of models that accurately represent the behavior of supplynetworks are challenging for at least two reasons.

One is the inherent complexity of the environment beingmodeled. For example, we were surprised in the course of ourwork that a simple single-action message/handshake protocolcould explode into nearly a quarter of a million possible states!A second reason for difficulty in applying models of supplychain performance is that analytical models are often difficult tocomprehend by practitioners in industry, precisely because theyare driven by the high level of complexity in the environment.Our research is directed at building bridges to span this divisionby combining tools and approaches from software engineering,AI, and simulation.

We believe that this research represents an important steptoward developing a rigorous approach for creating multipara-digm modeling frameworks in the supply chain domain. Futurework will be directed at making the analysis of supply chainmessaging and collaboration more accessible while increasingthe use of analytical methods in practice. To this end, we plan todevelop translations for other conceptual models of the supplychain into executable simulation models.

ACKNOWLEDGMENT

A. L. Feller would like to thank W. Zuberek for the assistancewith the TPN tool and the RN staff at Intel for their support.The authors would like to thank the reviewers and editor fortheir comments that have helped to improve this paper.

REFERENCES

[1] K. Garg, “An approach to performance specification of communicationprotocols using timed Petri nets,” IEEE Trans. Softw. Eng., vol. SE-11,no. 10, pp. 1216–1225, Oct. 1985.

[2] B. Berthomieu and M. Diaz, “Modeling and verification of time dependentsystems using time Petri nets,” IEEE Trans. Softw. Eng., vol. 17, no. 3,pp. 259–273, Mar. 1991.

[3] A. Yakovlev, S. Furber, R. Krenz, and A. Bystrov, “Design and analysisof a self-timed duplex communication system,” IEEE Trans. Comput.,vol. 53, no. 7, pp. 798–814, Jul. 2004.

[4] Intel Corporation, Intel RosettaNet Transaction Logs, Chandler, AZ, 2006.[5] J. Sowa, Conceptual Structures: Information Processing in Mind and

Machine. Reading, MA: Addison-Wesley, 1984.[6] L. Padulo and M. A. Arbib, Systems Theory: A Unified State Space Ap-

proach to Continuous and Discrete Systems. Philadelphia, PA: Saunders,1974.

[7] Introduction to OMG’s Unified Modeling Language (UML). [Online].Available: http://www.omg.org/gettingstarted/what_is_uml.htm

[8] OMG, UML Summary, 1997. ver. 1. [Online]. Available:http://www.omg.org/cgi-bin/doc?ad/97-08-11

[9] OMG UML Specification, Mar. 2003. ver. 1.5 formal/03-03-01. [Online].Available: http://www.omg.org/docs/formal/03-03-01.pdf

[10] B. Zeigler, Theory of Modeling and Simulation. New York: Wiley, 1976.[11] P. A. Fishwick, “Hierarchical reasoning, simulating complex processes

over multiple levels of abstraction,” Ph.D. dissertation, Univ.Pennsylvania, Pittsburgh, PA, 1986.

[12] P. A. Fishwick, “The role of process abstraction in simulation,” IEEETrans. Syst., Man, Cybern., vol. 18, no. 1, pp. 18–39, Jan./Feb. 1988.

[13] P. A. Fishwick, “An integrated approach to system modeling using asynthesis of artificial intelligence, software engineering and simulationmethodologies,” ACM Trans. Model. Comput. Simul., vol. 2, no. 4,pp. 307–330, Oct. 1992.

[14] P. A. Fishwick and B. P. Zeigler, “A multimodel methodology for qual-itative model engineering,” ACM Trans. Model. Comput. Simul., vol. 2,no. 1, pp. 52–81, Jan. 1992.

[15] K. Lee and P. A. Fishwick, “OOPM/RT: A multimodeling methodologyfor real-time simulation,” ACM Trans. Model. Comput. Simul., vol. 9,no. 2, pp. 141–170, Apr. 1999.

[16] R. M. Cubert and P. A. Fishwick, “A framework for distributed object-oriented multimodeling and simulation,” in Proc. IEEE Winter Simul.Conf., 1997, pp. 1315–1322.

[17] H. Vangheluwe, J. de Lara, and P. Mosterman, “An introduction to multi-paradigm modeling and simulation,” in Proc. AIS Conf. (AI, Simul. Plan-ning High Autonomy Syst.), 2002, pp. 9–20.

[18] P. J. Mosterman and H. Vangheluwe, “Guest editorial: Special issueon computer automated multi-paradigm modeling,” ACM Trans. Model.Comput. Simul., vol. 12, no. 4, pp. 249–255, Oct. 2002.

[19] P. I. Barton and C. K. Lee, “Modeling, simulation, sensitivity analysis,and optimization of hybrid systems,” ACM Trans. Model. Comput. Simul.,vol. 12, no. 4, pp. 256–289, Oct. 2002.

[20] H. Vangheluwe and J. de Lara, “Metamodels are models too,” in Proc.IEEE Winter Simul. Conf., 2002, pp. 597–605.

[21] H. Vangheluwe and J. de Lara, “Computer automated multi-paradigmmodeling: Meta modeling and graph transformation,” in Proc. IEEE Win-ter Simul. Conf., 2003, pp. 595–603.

[22] M. Traore, “A meta-theoretic approach to modeling and simulation,” inProc. IEEE Winter Simul. Conf., 2003, pp. 604–612.

[23] J.-S. Lee, M. C. Zhou, and P.-L. Hsu, “Multiparadigm modeling forhybrid dynamic systems using a Petri net framework,” IEEE Trans.Syst., Man, Cybern. A, Syst., Humans, vol. 38, no. 2, pp. 493–498,Mar. 2008.

[24] P. J. Mosterman, J. Sztipanovits, and S. Engell, “Special issue on computerautomated multi-paradigm modeling in control systems,” IEEE Trans.Control Syst. Technol., vol. 12, no. 2, pp. 223–234, Mar. 2004.

[25] Y. W. Kim, T. Kato, S. Okuma, and T. Narikiyo, “Traffic network controlbased on hybrid dynamical system modeling and mixed integer nonlinearprogramming with convexity analysis,” IEEE Trans. Syst., Man, Cybern.A, Syst., Humans, vol. 38, no. 2, pp. 346–357, Mar. 2008.

[26] J. Lee and P. Hsu, “Design and implementation of the SNMP agents forremote monitoring and control via UML and Petri nets,” IEEE Trans.Control Syst. Technol., vol. 12, no. 2, pp. 293–302, Mar. 2004.

[27] C.-P. Lin and M. D. Jeng, “An expanded SEMATECH CIM framework forheterogeneous applications integration,” IEEE Trans. Syst., Man, Cybern.A, Syst., Humans, vol. 36, no. 1, pp. 76–90, Jan. 2006.

[28] Y. Y. Du, C. J. Jiang, and M. C. Zhou, “Modeling and analysis of real-timecooperative systems using Petri nets,” IEEE Trans. Syst., Man, Cybern. A,Syst., Humans, vol. 37, no. 5, pp. 643–654, Sep. 2007.

[29] H. Giese and G. Wirtz, “Visual modeling,” J. Vis. Lang. Comput., vol. 12,no. 2, pp. 183–202, Apr. 2001.

[30] H. Giese, J. Graf, and G. Wirtz, “Closing the gap between object-orientedmodeling of structure and behavior,” in Proc. 2nd Int. Conf. UML—Beyond the Standard, Fort Collins, CO, Oct. 28–30, 1999, pp. 534–549.

[31] L. Baresi and M. Pezze, “On formalizing UML with high-level Petri nets,”in Concurrent Object Oriented Programming and Petri Nets: Advances inPetri Nets, vol. 2001, Lecture Notes in Computer Science. New York:Springer-Verlag, 2001, pp. 276–304.

[32] J. Garrido and M. Gea, “A coloured Petri net formalisation for a UML-based notation applied to cooperative system modeling,” in Proc. 9thInt. Workshop Interactive Syst. Des., Specification, Verification, 2002,pp. 16–28.

[33] J. Xu and J. Kuusela, “Modeling execution architecture of software systemusing colored Petri nets,” in Proc. 1st Int. Workshop Softw. Perform.,Santa Fe, NM, 1998, pp. 70–75.

[34] J. Merseguer, J. Campos, S. Bernardi, and S. Donatelli, “A compositionalsemantics for UML state machines aimed at performance evaluation,” inProc. 6th IEEE Int. WODES, 2002, pp. 295–302.

[35] S. Bernardi, S. Donatelli, and J. Merseguer, “From UML se-quence diagrams and statecharts to analyzable Petri net models,”


in Proc. 3rd Int. Workshop Softw. Perform., Rome, Italy, 2002,pp. 35–45.

[36] C. Lindemann, A. Thümmler, A. Klemm, M. Lohmann, and O. Waldhorst,“Performance analysis of time-enhanced UML diagrams based on sto-chastic processes,” in Proc. 3rd Int. Workshop Softw. Perform., Rome,Italy, 2002, pp. 25–34.

[37] V. Cortellessa and R. Mirandola, “Deriving a queuing network basedperformance model from UML diagrams,” in Proc. 2nd Int. WorkshopSoftw. Perform., Ottawa, ON, Canada, 2000, pp. 58–70.

[38] L. Lavazza, G. Quaroni, and M. Venturelli, “Combining UML and formalnotations for modeling real-time systems,” in Proc. 8th Eur. Softw. Eng.Conf. Held Jointly With 9th ACM SIGSOFT Int. Symp. Found. Softw. Eng.,2001, pp. 196–206.

[39] A. Simons, “On the compositional properties of UML statechart dia-grams,” in Proc. 3rd Workshop Rigorous Object Oriented Methods, 2000,pp. 4.1–4.19.

[40] RosettaNet Implementation Framework: Core Specification: RosettaNet,Jul. 13, 2001. [Online]. Available: http://rosettanet.org

[41] RosettaNet PIP Specification, Cluster 4: Inventory Management, Seg-ment A: Collaborative Forecasting, PIP4A1: Notify of Strategic Forecast:RosettaNet2002. [Online]. Available: www.RosettaNet.org

[42] Issue 1 EDIINT AS1 and AS2 Transport Communication Guidelines:GS1, Feb. 2006. [Online]. Available: http://www.gs1.org/docs/gsmp/EDIINT_AS1_AS2_Transport_Comm_Guide_i1.pdf

[43] J. L. Peterson, Petri Net Theory and the Modeling of Systems.Englewood Cliffs, NJ: Prentice-Hall, 1981.

[44] P. C. Xiong, Y. S. Fan, and M. C. Zhou, “QoS-aware web service configu-ration,” IEEE Trans. Syst., Man, Cybern. A, Syst., Humans, vol. 38, no. 4,pp. 888–895, Jul. 2008.

[45] Q. Ye and M. H. MacGregor, “Combining Petri nets and ns-2: A hybridmethod for analysis and simulation,” in Proc. 4th Annu. CNSR Conf.,May 24–25, 2006, pp. 139–148.

[46] J. Sowa, “Relating diagrams to logic,” in Proc. 1st ICCS, ConceptualGraphs Knowl. Represent., Quebec City, QC, Canada, Aug. 4–7, 1993,pp. 1–35.

[47] A. Feller and R. Rucker, “Extending structured analysis modeling withA.I.: An application to MRPII profiles and SFC data communicationsrequirements specifications,” in Optimization of Manufacturing SystemsDesign. Amsterdam, The Netherlands: North Holland, 1990.

[48] A. Feller and R. Rucker, “Meta-modeling systems analysis primitives,” inConceptual Structures: Current Research and Practice. New York: EllisHorwood, 1992, ch. 10, pp. 201–220.

[49] G. Willumsen, “Executable conceptual models in information sys-tems engineering,” Ph.D. dissertation, Norwegian Inst. Technol. Univ.Trondheim, Trondheim, Norway, 1993.

[50] B. Berthomieu, P.-O. Ribet, and F. Vernadat, “The toolTINA—Construction of abstract state spaces for Petri nets and timePetri nets,” Int. J. Prod. Res., vol. 42, no. 14, pp. 2741–2756, Jul. 2004.

[51] J. D. Bloom, “Pipe—A platform independent Petri net editor,” M.S. thesis,Imperial College, London, U.K., 2003.

[52] ver. 2.0 Platform Independent Petri Net Editor (PIPE), The Home Pageof PIPE (Platform Independent Petri Net Editor). [Online]. Available:http://pipe2.sourceforge.net

[53] W. Zuberek, “Timed Petri nets—Definitions, properties and applications,”Microelectron. Reliab., vol. 31, no. 4, pp. 627–644, 1991.

[54] Intel Corporation, Intel RosettaNet BCRN Indicators—Transaction Sum-mary Report, Chandler, AZ, 2006.

Andrew L. Feller received the B.S. and M.S. de-grees in industrial engineering from Arizona StateUniversity (ASU), Tempe, where he is currentlyworking toward the Ph.D. degree.

He is also working with American Express Tech-nologies, Phoenix, AZ, leading modeling and sim-ulation projects focused on improving informationtechnology capacity planning and service processperformance. During the past several years, he hasled consulting practices as a Vice President and theDirector at two Arizona firms, improving operational

efficiency and financial performance for clients such as Honeywell and MDHelicopters. He coauthored two book chapters on advanced system analysismethods and architectures. His research interests include modeling and simula-tion in manufacturing, supply chain, and service management.

Mr. Feller is a member of the Society of Manufacturing Engineers and theInstitute of Industrial Engineers. He is the recipient of the alumni of the yearand academic distinction from the ASU Corporate Leaders program.

Teresa Wu received the Ph.D. degree in industrialengineering from The University of Iowa, Iowa City,in 2001.

She is currently an Associate Professor of indus-trial engineering with the Department of IndustrialEngineering, Arizona State University, Tempe. Herresearch interests include distributed decision sup-port, distributed information systems, supply chainmodeling, and disruption management. She has over25 articles published in journals, such as the Interna-tional Journal of Production Research, Omega, Data

and Knowledge Engineering, and American Society of Mechanical Engineer:Journal of Computing and Information Science in Engineering, and the IEEETRANSACTIONS ON ENGINEERING MANAGEMENT. She serves on the Edito-rial Review Board for the International Journal of Production Research, IEEETRANSACTIONS ON ENGINEERING MANAGEMENT, Computer Standards andInterfaces, and the International Journal of Electronic Business Management.

Dan L. Shunk received the Ph.D. degree in in-dustrial engineering from Purdue University, WestLafayette, IN, in 1976.

He is currently an Avnet Professor of supply net-work integration in industrial engineering with theDepartment of Industrial Engineering, Arizona StateUniversity, Tempe, where he is pursuing researchinto collaborative commerce, global new productdevelopment, model-based enterprises, and globalsupply network integration.

Dr. Shunk won a Fulbright Award in 2002–2003,the 1996 Society of Manufacturing Engineers (SME) International Award forEducation, the 1991 and 1999 I&MSE Faculty of the Year award, the 1989SME Region VII Educator of the Year award, and the 1982 SME OutstandingYoung Engineer award. He was the Chair of AutoFact in 1985.

John Fowler received the Ph.D. degree in industrialengineering from Texas A&M University, CollegeStation, in 1990.

He is currently a Professor of industrial engineer-ing with the Department of Industrial Engineering,Arizona State University, Tempe, and he was theCenter Director for the Factory Operations ResearchCenter that was jointly funded by International SE-MATECH and the Semiconductor Research Cor-poration. His research interests include modeling,analysis, and control of semiconductor manufactur-

ing systems. He is an Area Editor for SIMULATION: Transactions of theSociety for Modeling and Simulation International (SCS).

Dr. Fowler is a member of the Institute of Industrial Engineers (IIE), Institutefor Operations Research and the Management Sciences (INFORMS), and SCS.He is an IIE Fellow, the Vice President of Chapters/Fora for INFORMS, andthe Treasurer of Omega Rho and is on the Winter Simulation ConferenceBoard of Directors. He is an Associate Editor of the IEEE TRANSACTIONS

ON SEMICONDUCTOR MANUFACTURING.

petri net translation patterns for the analysis of ebusiness collaboration messaging protocols

Documents