2 2007 lee s. j manuf syst simulation based planning and control from shop floor to top floor

7/28/2019 2 2007 Lee S. J Manuf Syst Simulation Based Planning and Control From Shop Floor to Top Floor

1/14

Journal of Manufacturing Systems 26 (2007) 8598

Contents lists available at ScienceDirect

Journal of Manufacturing Systems

journal homepage: www.elsevier.com/locate/jmansys

Technical paper

Simulation-based planning and control: From shop floor to top floor

Seungyub Lee a, Young-Jun Son b,, Richard A. Wysk a

a Industrial and Manufacturing Engineering Department, Pennsylvania State University, University Park, PA, USAb Systems and Industrial Engineering Department, University of Arizona, Tucson, AZ, USA

a r t i c l e i n f o

Article history:

Received 5 October 2006Accepted 3 July 2007

a b s t r a c t

This paper illustrates how simulation-based shop-floor planning and control can be extended to

enterprise-level activities (top floor). First, the general planning and control concept are discussed,followed by an overview of simulation-based shop-floor planning and control. Analogies between theshop floor and top floor are discussed in terms of the components required to construct simulation-

based planning and control systems. Analogies are developed for resource models, coordination models,physical entities, and simulation models. Differences between the shop floor and top floor are also

discussed in order to identify newchallenges faced for top-floor planningand control. A major differencebetween the top floor and the shop floor is the way a simulation model is constructed for use in

planning, depending on whether time synchronization among member simulations becomes an issueor not. Another difference is in the distributed communication/computing platform. This work uses a

distributed computing platform using Web services technology to integrate heterogeneous simulationsand systems in a distributed top-floor control environment. The research results reveal that simulation-

basedplanning andcontrol is extensibleto thetop-floor environments evolving newresearchchallenges.

2008 The Society of Manufacturing Engineers. Published by Elsevier Ltd. All rights reserved.

1. Simulation-based planning and control

A shop floor control system (SFCS) plays a major role inautomating manufacturing facilities to fill production ordersreceived from the factory-level (top floor) control system [7].During the planning stage, decision alternatives (plans or policies

that will generate plans) are evaluated using a certain typeof model (for example, analytic models, simulation models)of the actual system against the forecasted future information[39,8]. Once the best alternative is chosen, it is executed todrive the actual system as planned (control stage). Usually,switching between the planning and control stages occurs eitherperiodically or as the result of a system change (event-based).When using periodic decision making, the frequency of the

planning stage is fixed. When using event-based methods, theplanning stage is invoked when it is necessary (for example, whenthe reality deviates from what was predicted beyond a thresholdvalue). To check the deviation of the reality from what waspredicated, either system input parameters (for example, demand,

resource availability, processing times) or performance metrics(for example, throughout, cycle time) are typically used. Fig. 1depicts an example of when a performance metric is used [5],where the projected performance path is obtained from the plan

Corresponding author. Tel.: +1 520 626 9530; fax: +1 520 621 6555.

E-mail address: [email protected](Y.-J. Son).

at the planning stage. Further, the actual performance path madeby decision making in real time is tracked. The two performancepaths are almost identical if no major departure events occur inthe system. However, the dynamic and unpredictable nature ofmanufacturing systemsdue to the concurrent flow of various parts,sharing of different types of resources, disturbances (for example,resource breakdown, processing time variations), and exogenousdisturbances (for example, unexpected rush orders) may causediscrepancies between the predicted and actual performancepaths, as shown in Fig. 1. Hence, the planning stage can be invokedwhenever a discrepancy is larger than a predetermined threshold.

Several researchers have proposed simulation-based real-timeplanning and control approaches, where online simulation involv-ing the current status of the system is used to evaluate candidate

alternatives (dispatching rules) at the planning stage [8,37,15,9,10,30,29]. Recent advances in high-performance computing and com-munications make the online simulation approach more viable.Theoptimal or near-optimalpolicies(in terms of dispatching rules)allow real-time (almost immediate) response to dynamic systemchanges. As online simulation is an evaluation tool as opposed toan optimization tool, many researchers combined it with OR orAI techniques. One of the early attempts at this was by Wu andWysk [37], who combined learning techniques in which the man-ufacturing control system learned from its own historical perfor-mance with simulation. Cho and Wysk [6] have suggested usingneural networks to identify candidate rules for simulation-basedplanning and control. Jones, Rabelo and Yih [14] presented a sim-ilar method combining neural networks, genetic algorithms, and

0278-6125/$ see front matter 2008 The Society of Manufacturing Engineers. Published by Elsevier Ltd. All rights reserved.doi:10.1016/j.jmsy.2007.07.001
http://www.elsevier.com/locate/jmansyshttp://www.elsevier.com/locate/jmansysmailto:[email protected]://dx.doi.org/10.1016/j.jmsy.2007.07.001http://dx.doi.org/10.1016/j.jmsy.2007.07.001mailto:[email protected]://www.elsevier.com/locate/jmansyshttp://www.elsevier.com/locate/jmansys


2/14

86 S. Lee et al. / Journal of Manufacturing Systems 26 (2007) 8598

Fig. 1. Comparison of predicted and actual performance paths [5].

Fig. 2. Overview of simulation-based real-time planning and control [29].

simulation. OKeefe and Rao [22] proposed methodologies for de-termining part input sequences using a look-ahead simulation anda fuzzy rule base. Today,manycommercial simulation packages areavailable with built-in meta-heuristics (for example, genetic algo-rithm, tabu search, neural network, simulated annealing) for such

purposes.Smith et al. [28] and Son et al. [29] proposed a unique

feature for simulation-based real-time planning and control. Thekey is that the same simulation model (executing in the fastmode) used at the planning stage after some modification is usedas a real-time task generator (real-time simulation) during thecontrol stage (see Fig. 2). At each decision point in the real-time simulation, a subroutine in real-time simulation activates afast-mode simulation by sending a message to see what controlpolicy best impacts the current system (switching to the planningstage). Once the look-ahead manager receives a request, it opensfast-mode Arena and runs the number of alternative modelssequentially. Several simulations are run, and the performanceof each alternative is recorded in the specific file. When this

procedure is done in the fast-mode simulation, this control policyis then fed to the real-time simulation for execution of the

best control strategy on the system (switching to the controlstage). The real-time simulation drives the manufacturing systemby sending and receiving messages using TCP/IP socket-basedcommunication links to a supervisory-level executor [a Finite StateAutomata (FSA)]. The supervisory executor receives instructions

(messages) from the real-time simulation and, based on the systemstatus, sends messages to the equipment-level controllers. Aftera task message is sent from the supervisory executor, both thesupervisory executor and the real-time simulation wait for acompletion_ok message from the equipment-level controllerthat received the message. Once the supervisory executor receivesthe completion_ok message, it sends a similar message to thereal-time simulation, and the simulation knows that the currenttask was completed. The task generator and execution modulescommunicate through the task initiation queue (TIQ) and the taskcompletion queue (TCQ). The real-time simulation uses the TIQto instruct the supervisory executor to perform specific tasks andreceives completion messages through the TCQ. These queuesfacilitate the explicit separation of the decision maker from the

execution module. The separation of the decision maker andthe execution module makes the system truly plug and play.


3/14

S. Lee et al. / Journal of Manufacturing Systems 26 (2007) 8598 87

Fig. 3. Illustrative example of required tasks to facilitate part flow in a shop floor.

Fig. 4. Illustrative example of required tasks in top-floor control.

In fact, as long as the task generator understands the physical

constraints imposed on the task sequences, any task generator canbe plugged into the execution module. Example task generatorsinclude simulation, a human operator, and an expert system [28].

Among these candidates, the following advantages have madesimulation popular as the task generator: (1) easy bookkeeping, (2)

easy specification of physical systemconstraints, (3) built-in abilityto interface with external modules such as databases and external

decision procedures, (4) real-time monitoring and animation, and(5) offline production prediction or cost estimation [29,32].

2. System components: From shop floor to top floor

An overview of simulation-based shop floor control was givenin Section 1. The goal of this section is to extend the concept

to the extended enterprise (top floor). More specifically, the in-tent is to simplify the effort to build a simulation-based top-

floor control system by extending the existing shop floor controlsystem and improving the efficiency of its operation by provid-

ing a time-synchronization mechanism and a distributed comput-ing/communication platform. To this end, the shop floor and thetop floor are compared in terms of system components needed for

the simulation-based planning and control system, including (1)simulation model, (2) resource model,(3) execution (coordination)

model involving FSA, and (4) TCP/IP-based communication server(router). Son et al. [29] discussed the system components needed

for simulation-based shop-floor planning and control in detail. Theefforts to extend from the shop floor to the top floor have beenmade by the lean manufacturing discipline as well, starting with

value streams for the shop floor and then extending them to thesupply chain [24].

2.1. Physical entities and tasks

This section compares the shop floor and top floor in terms

of their physical entities and corresponding tasks. Fig. 3 shows atypical exemplary shop floor composed of buffers, machines, and a

robot. It also illustrates tasks needed to move a part from the load

station to M1, process it, move it to M2, process it, and move itto the unload station. Similarly, Fig. 4 shows a typical exemplary

top floor (extended enterprise) composed of suppliers, assembly

plant, transportation systems, and customers. It also illustratesthe tasks needed to produce component parts, move them to the

assembly plant, assemble them, and move the finished products to

customers. These two example systems will be used to illustratethe system components throughout the paper.

2.2. Simulation model

As mentioned in Section 1 (see Fig. 2), Smith et al. [28] and

Son et al. [29] demonstrated that the same simulation modelcould be used as a task generator (control stage) as well as the

fast-mode plan evaluator (planning stage) in shop-floor planning

and control. The same concept can be extended to the top-floorcase. Figs. 5 and 6 depict simulation models with two degrees of

fidelity used in the planning stage for the shop floor and top floor.

Tasks in Fig. 5 are simulated via the aggregated random variableswhereas tasks in Fig. 6 are simulated via external component

simulators. Fig. 6(a) shows that machine tasks and robot tasks

for this system configuration are independent, and therefore theirsimulation clocks do not have to be synchronized. However, in

Fig. 6(b), during the operation of the suppliers simulation andthe assembly plant simulation, information exchanges [such as


4/14


(a) Shop floor simulation. (b) Top floor simulation.

Fig. 5. Simulation in the planning stage: Approximation via random numbers.


Fig. 6. Simulation in the planning stage: Simulation embedding external simulation.


Fig. 7. Simulation in the control stage.

sending out procurement order(s)] may take place. Therefore, thesimulation clocks must be synchronized to obtain a more accuratesimulation result. Section 3 discusses the time-synchronizationissues in detail. Fig. 7 depicts simulation used in the control stagefor the shop floor and top floor, where interactions between themodules are somewhat similar to those in Fig. 6.

2.3. Formal resource model

This section explores a production resource model that providesa common frame of reference among the simulation, the executionsystem, the process planner, and so on. Wysk, Peters and Smith[38] and Steele, Son and Wysk [33] developed a resource model

containing a set of definitions and symbolic descriptions thatare required to describe all of the individual resources in amanufacturing facility as well as the necessary interactionsbetween these resources. The rest of this section is a discussion ofan analogous resource (information) model for the top floor.

Formalmodelsof resources, activities, andinformationfor com-ponents in the top-floor control systems are described in thissection, and they can be used as a modeling paradigm or ref-erence framework for specifying component simulation modelsat different levels of abstraction to coordinate activities in thetop floor (federation). Before simulation developers map real sys-tems into simulated systems, it is preferred to construct the gen-eral framework or formal ontological model to define resources,behaviors, data management, communication, rules, granulari-

ties for the manageability of the target systems, and integra-tion of different software systems interacting with each other.

A conceptual model is usefulto describe a context-free informationmodel for the complete description of systems that have differentlevels of abstraction. Therefore, an architecture for the target sys-

tem canbe modeled using several descriptive modeling techniques[Computer-Aided Software Engineering(CASE) tools](see Table1).

The importance of these formal models increases as thetarget domain grows due to the cost and time associated with

constructing and maintaining software systems. Because there arechallenges for model creation such as communication betweenincompatible software applications, knowledge exchanging and

sharing, integration of heterogeneous subsystems, ontologicalconsistency, and so on, a reference system can be established

among these different systems by mapping different granularities

and interfaces of them and creating software mechanisms thatmanipulate instances of these elements.

The formal information model for a large system (for example,

top floor) should have the following capabilities: (1) representingmulti-level hierarchy for systems resources and their interactionsfor with different granularities, (2) creating different viewpoints

of a model, (3) identifying the integration scheme across allsystem functions or interaction/transaction scheme among key

functions (for example, delivery of parts), (4) coordinatinginstances of distributed objects, (5) providing structured and

standard interfaces and a mapping framework for compatible dataabstraction for different subsystems, (6) handling large amountsof shared information from internal or external systems, (7)

providing semi-automatic derivation of subsequent specifications

[21,19,17]. In the most straightforward approach, the large systemis broken up into general subcomponents, which correspond to


5/14


Table 1

Classification of various CASE models [1,21,26]

Type of basic theory Modeling techniques Characteristics

Object-oriented (O-O) Unified Modeling Language (UML), Integrated Computer-Aided

Manufacturing (ICAM) DEFinition (IDEF) ontologies, Object

Modeling Technique (OMT)

Representation of unambiguous information for the

entire domain functions using classes and their

attributes and interaction. Straightforward approach.

Easy scalability.

Pi-calculus Web Service Choreography Interface (WSCI), Bus iness Process

Modeling Language (BPML), XML business process language(XLANG)

Powerful methods for modeling concurrent processes

that interact with one another dynamically.Channel-based process interaction.

Petri-nets Bus iness Process Modeling Notation (BPMN), Yet Another Workflow

Language (YAWL), Web Service Flow Language (WSFL), Event Driven

Process, UML 2.0 Activity diagram using token semantics

Graphical tools suitable for concurrent, asynchronous,

nondeterministic, and/or stochastic systems.

Activities and State Machines UML State Diagram, Finite State Automata (FSA), Event Driven

Process Chain (EPC), UML 2.0 Activity/state machine diagrams,

Supply Chain Operations Reference (SCOR)

Natural visualization (states and transitions) of a

business process using flow chart based representation

and the behavior of entities. Enumeration of possible

ontological conditions. Conception of the set of

event-triggered transitions and reconciled states.

Domain specific functions Computer-Integrated Manufacturing Open System Architecture(CIM-OSA), Purdue Reference Architecture (PERA), SCOR, the Global

Supply Chain Forum (GSCF)

Different views for the functional descriptions of thedomain, intra-activities, and interactions.

Hybrid SCOR, Systems engineering workbench for CIM-OSA (SEW-OSA),UML 2.0, other combined techniques

Business process reengineering, benchmarking, processMeasurement into a cross-functional framework.

target granularities of autonomous distributed units in the supply

chain system and, in turn, can be specified with increasing detail.

This top-down modeling approach can be a powerful technique to

especially develop distributed simulation models of the top-floor

systemsby breaking a large system into a number of smaller, more

manageable subsystems.

Among several information models shown in Table 1, a

extended resource model based on structural top-down object-

oriented classes and behavioral modeling diagrams (state machine

based or sequence diagram) is used to formalize and encapsulate

physical components in the target system (static information) and

their logical interactions (for intra-supply chain systems) and

transactions (for inter-supply chain systems) across different

participants in the supply chain systems in this paper. This

approach is useful because it can provide a multi-level graphical

formalism as well as include the dynamics of parallel-object

structures. Because the typical resource and control models used

on the shop floor for the physical entities in the system, such as

resources, part, and order, cannot represent object transactions

(for example, scheduling) explicitly, it might be required to gather

information regarding definitions, standard descriptions of the

multi-level business processes that represent logical workflows

and facilitate integration across the supply chain system in order

to manipulate those interactions that occur dynamically. The

Supply Chain Council (SCC) has established a standard way to

examine and analyze supply chains with the SCOR model [34]. Its

four levels of top-down process hierarchy can be well matched

with resource hierarchy for the classes in the object-oriented (O-

O) model and with planning hierarchy for the planning stage

in MRP-type planner systems. Additionally, the SCOR model

explicitly specifies key transactional processes such as deliver,

source, and return, which have high levels of inter-company

connectivity, in order to coordinate processes across the top floor.

In this case, each external member of the supply chain can share

only its transactional information using those processes as data

exchange objects.

Lambert, Garcia-Dastugue, and Croxton [17] identified integra-

tion aspects of purchasing, operations, and logistics in the five

standard processes of the SCOR model forinteractions and transac-

tions, while excluding functions such as marketing, finance, and so

on. Hence, the implementation of the system mapped into feder-ates can be performed in a more straightforward way, even though

it does not integrate all of the functions all the way to the top-

floor system. Barnett and Miller [3] have also discussed O-O re-

source and process models and how they can be developed and

employed to construct simulation models. Additionally, the SCOR

model identifies standard performance metrics of the processes so

that federates can evaluate performance of business processes us-

ing look-ahead analysis. Promising operating policies can then be

chosen among alternatives throughout the federation and will be

used to drive the actual system. Hence, the implicit information in

the SCOR model would be mapped and customized into structured

anddetailed business modeling diagrams (that is,customized hier-

archical UML diagrams and/or FSA) corresponding to physical and

logical characteristics of federates in the top-floor system in order

to extend the same framework used in the shop floor into a higher

level of system hierarchy.

Another benefit of a formal information model is that it can be

used for enhancing the generalized model components for the sys-

tem entities so that they can be reused. It describes not only how

the entire model maps to components and processes in a top-floor

system, but it also described the fundamental information for the

mapping mechanism. To map components (real systems to soft-

ware systems) that have different semantics and interfaces, com-

monalities and gateway interfaces or shared information objects

among the component systems are also identified and mapped

to the formal information model. For example, simulation mod-

eling logic such as modeling fidelity, order release, granularity of

simulation time windows, and attributes and message manipula-

tion can be also be specified. As shown in Fig. 8 (the behavior of

the actual top-floor system), activities of a federation of simula-

tion models and transactions of the SCM planner are similar (may

have different data scheme), and they can be identified using a

behavior formalism and matching rules among different systems

using a formal ontology. Both system developers and users can

develop, test, use, and maintain the various systems with less ef-

fort and time using the conceptual information model as a ref-

erence system. A formal model representing abstraction of the

target domain can first be generated using predefined SCOR

processes and domain knowledge for the particular federate. A

formal information mapping model is then combined with the

formal information model using common data, rules, and specifi-

cations. Based on the formal information mapping model, a map-ping and translation mechanism such as object-to-relation based


6/14


Fig. 8. Relationship among different systems and development steps.

(using an intermediate database) and/orrule based (using algorith-

mic mapping ontology) can then be generated and used for simu-

lation model generation (manual or automatic) along with modu-

lar template information and specifications of variables, attributes,

and messages. This architecture facilitates the sharing of resource

data across the members (internal or external) in a top floor andthe development of software to implement engineering functions

[31,32].

2.3.1. A structural resource model

The proposed system architecture can also be defined as a

formal resource reference model in terms of a set of standard

object-oriented classes to integrate the different functions and

domains in top-floor systems. This model is quite similar to the

shop floor model in terms of entities and hierarchy of entities.

However, it differs from the model used in the shop floor in that

it has to integrate heterogeneous and intangible organizations or

membersand their organizational business data. As shown in Fig.8,

the planning system, for example, the MRP/ERP system, represents

all data and processes of an organization in the supply chain

system, including structural entities and data. Hence, it is a goodstarting point to classify fundamental information for organization

information, product, order type, physical resources, and so on,

which can be used to construct and implement the simulationmodels from the planner system.

Object classes for structured data entities can be formally

grouped into an organizational entity model, data model, and

information process model based on the key data elements

in the planning system and the SCOR reference model. They

can be decomposed into subclasses to represent hierarchical

relationships. Diagrams for the four major classes defined above

and their subclasses are depicted in Figs. 9 and 10. Among many

classes, the physical resource elements (classes) that consist of

the target domain and some of their attributes can be also

illustrated using the UML class diagram for snapshots of the entireextended resource model. An organizational entity model can be

considered as a cross-referenced information model, especially fordata sharing. It can have encapsulated SCOR business processesthat are decomposed into the SCOR business transaction classand SCOR business interaction class, a resource model for thetarget domain and organizational information such as customers.A data model consists of product and order models that determineentity interactions typically occurring by information and material

movements. An information process model is a class regardingimplementation parameters and input/output for the modeledsystem.

The resource model also contains a set of definitions andsymbolic descriptions that are required to describe all of theindividual resources in a system as well as the necessaryinteractions (represented using either a sequence diagram, FSA, orcombined diagrams) between these resources. Fig. 11 summarizespartial definition of classes that construct a federation using settheoretic notation in an O-O classification. Each node (object)can be associated with an individual factory, transporter, orwarehouse. A connectivity graph (CG) for this model can beestablished a bit differently from that forthe shop level.It is a graphshowing the connections among the facilities (objects) in the SCS

in different levels.

2.3.2. A behavioral model based on the SCOR model

As discussed, the dynamic (behavioral) model can be classifiedinto two types of models according to the degree of connectivityand information sharing among members (internal or externalsupply chain system). Dynamic information refers to detailed andinteracted workflow in the supply chain system. The arcs amongprocesses are associated with entity interactions (transactionsof orders, material movement, and so on). Each state (node)performs the following actions: (1) receive orders for Source,Make,Deliver, and Return according to the Plan,(2) fill andperform orders(real execution for Source, Make,Deliver, andReturn), and (3) deliver the products and notify replenishment

orders to upstream entity. From the extended resource models, thefirst stepin the SCOR-based behavioralmodelis to createa physical


7/14


Fig. 9. An extended resource model class for the top floor.

Fig. 10. A resource model class in the organizational entity model (subclass of the class in Fig. 9).

layout of the supply chain system. The next step involves choosingthe relevant SCOR level 2 process elements among predefinedcategories and depicting them as shown in Fig. 12. At this point,a company knows about the information inputs required and whatoutputs are expected. Activity/state-based diagrams employ fourlevels of top-down process hierarchy in the SCOR model. Blocksat the lowest level can be mapped conveniently into elements inthe UML state/activity diagrams, FSA, or simulation process blockssuch as Arena. Rder and Tibken [25] have categorized differenttypes of enterprises within the top-floor system into three types

to provide the basis for the detailed modeling and classificationusing the process categories as defined in the SCOR model. For an

illustrative example used in the paper, component suppliers canbe categorized into Source-Make-Deliver or Make-Delivertypeenterprises. Similarly, component assemblers can also be classifiedas Source-Make-Deliver type enterprises and transporters asSource-Deliver type enterprises. Fig. 12 depicts the processesfor the component supplier and shows that it is a Source-Make-Deliver type enterprise. This enterprise is connected to theassembler enterprise or buyer through a Deliver type process inthe supplier and a Source process in the component assemblerenterprise in the next echelon. They are transactional processes

carried outbetween separate members or objectsin either externalor internal supply chain systems. These processes are important in


8/14


Fig. 11. Partial view of set theoretic notations for the above O-O classification.

Fig. 12. Partial view of decomposed plan and execution processes in the SCOR model and corresponding FSA mapped for the component supplier.

that they are bridges for data sharing among different enterprises

and time synchronization for the federations.Lower levelActivities

(level 3) decomposed from the level 2 processes can be directly

mapped into an FSA (activities are mapped into messages in

the arcs). For example, a supplier sends the request for product

deliveries to a material supplier (an upstream enterprise, which

is not shown in the figure) for the process 2.1. This process canbe directly mapped into the message (schedule_delivery_sm). In

addition, the aggregate planning and Master Production Schedule

(MPS) from the MRP/ERP type planner can be mapped to level

2 and level 3 plans, respectively. The centralized planner in the

level 1 plan for a entire top-floor system can exist for the internal

supply chain because it is assumed that data in the different

sites can be also shared through the centralized database system.

In this centralized planning system, all subsequent activities aretriggered by the completion of events of previous activities in


9/14


a predefined sequence that is defined in the SCOR model orperiodical time frames. Layouts for detailed processes or activitieswithin the predefined processes can be represented as customizedstate machine based diagrams such as an FSA. Therefore, dynamicinteractions and connectivity features among atomic activities canalso be identified by classic hierarchical process decomposition.The models created by an FSA can be also reused to coordinateand synchronize federates as a coordinator when implementingsimulation federates as shown in Section 3.2.

Along with the behavioral model, dynamic system informa-tion in the information process model (logical input/output infor-mation among process elements) provides the message schemefor simulation and coordination models, that is, physical mes-sages between simulation models and the coordination adapter.Furthermore, transitions and conditions defined among states inthe process map enable simulation modelers to specify rules toconstruct target simulation models. Therefore, a formal informa-tion model using set theoretic symbology, system objects (object-oriented approach), and formalbusiness processes (SCOR model) isproposed to map federate object interactions, resolve granularityissues for a federation, and verify consistency of formal businessbehavior among distributed objects and adequacy of mapping un-

der the different operating policies. The framework developed cansignificantly increase efficiency of model development and man-agement in terms of overhead dealing with component systemswith different granularities by standardizing data interfaces.

3. Coordination and time synchronization for the top-floor

system

As discussed in the formal information model, a global plan(level 1 plan in the SCOR model) is periodically generated orregenerated based on the scheduling information collected fromthe members of thetop-floor system. Local plans (level 3) or short-term schedules for the activity areas such as shops, workstations,and so on, that are a closely bound set of activities and determined

by levels of system hierarchy shown in Fig. 12, are made basedon the global plan. The time interval for such periodic planningactivitiescorresponds to the size of the timebucket in the MRP/ERPsystem for the top-floor system. This coordination scheme iscalled centralized time-phased planning, which can be appliedto the internal supply chain system or each individual enterpriseaccording to the granularity level to be modeled. On the contrary,acoordination scheme follows a bottom-up approach for a Kanban-type (pull system). For these two different planning systems, thecoordination scheme for the federates can also be changed. InSections 3.1 and 3.2, centralized time-phased planning (push-based supply chains) and pull-based supply chains are discussed.

3.1. Time bucket-based resource reconciliation mechanism (push or

hybrid systems)

In this section, a synchronization and coordination methodcalled resource reconciliation is proposed to provide maximumparallelism among simulation federates. This method is a variantof the traditional synchronization approach, where each federateexecutes on a single processor as a local activity-area model.Each federate moves forward simultaneously in time but neverrolls back in time (unlike the traditional optimistic methods). Allfederates execute in parallel, advancing time independently fora time bucket. The end of each time bucket is the only pointin time where federates interact; within buckets all federatesrun at full speed. All federates wait at the completion of atime bucket until all other federates have reached this point

in time before they proceed. When all time buckets have beencompleted, each federate may send and receive messages, and all

resource levels and values are reconciled. Once this exchange is

completed, federates again move independently forward at fullspeed until they arrive at the next check point. They move forwardin this fashionfrom time bucket to time bucket until a terminaltime is reached. Resource reconciliation provides for maximum

parallelism but introduces the problem of what levels and statesare accurate, and how does one account for exogenous events thatmight cause unforeseen federate interactions.

The proposed coordination mechanism shown in Fig. 13 focuseson enabling each system entity modeled by federates to constantlycorrect its performance with respect to actual parameters or

performance metrics, and trigger a global coordinator thatconsists of the MRP/ERP and a transaction coordinator system ifnecessitated by any discrepancies observed by the entity through

simulation models.Because the performance of the system and execution speed

of a federation also depend on the level of interactions or

frequency of synchronization among the distributed models,appropriate selection of a simulation time window (T) orthe size of a time bucket is very critical even though typical

manufacturing enterprise or top-floor systems tend to set aconsistent planning horizon. Larger time windows imply a larger

degree of decoupling among federates and can decrease thefrequency of synchronization among them [4]. However, a largertime window also implies deterioration of manufacturing cycletime because it can increase lead time for the manufacturingsystems. There is a trade-off between communication overheads

to and from federates and manufacturing cycle time reduction.Hence, the time window may be selected or adjusted accordingto the nature of the systems, while considering fundamental

constraints in the systems. Many researchers proposed sometechniques for relaxing fixed parameters used in the MRP systemssuch as large time buckets by combining Just-in-Time (JIT)

or Theory of Constraints (TOC) with the MRP-type planning.Additionally, some heuristics such as the Shifting Bottleneck (SB)method are also proposed to calculate the lower bound for the

scheduling time window in the N-job/M-machines/MaximumLateness job shop scheduling problem [20,4,35].

In thispaper, the initial time bucket for periodic activities in the

actual and simulated systems is provided by the MRP/ERP system(for example, weeklyor monthly) forits coordinationcycle.If thereis consensusof a natural checkpoint forall participants or federates(the desired granularity depends on the problem domains) in the

target domain, that is,the supplychain system,enterprise, or shop,it can be used as a sort of standard (obtained from experience andhistorical data). Otherwise, a synchronization interval has to be

determined based on the empirical observation of all of the eventsinthe federates insucha way thatthe assigned lot willbe producedsuccessfully within the determined interval.

To use a small time bucket is a more or less conservative

way. It has both a large frequency of synchronization request andhigh fidelity of transactions. Hence, it can improve manufacturing

cycle time but cause large overheads for the MRP/ERP and adaptersystemsdue to frequent requests from the federates and, therefore,deteriorate speed of simulation execution. On the other hand,

when a large time bucket is used (more optimistic), there arefew synchronization requests but a low fidelity of transactions.Fig. 14 represents a double-phase mechanism for synchronizationand coordination for the resource reconciliation mechanism.

Even though two terminologies such as Synchronization andCoordination are treated as having analogous meaning inthe literatures, their usages are discriminated in this paper.

Synchronization means periodical matching of all local virtualclocks to a global virtual clock. Synchronization is accomplished

by the adapter while providing timing control for distributedsimulation models and maintaining the size of a time bucket. This


10/14


Fig. 13. Overview of resource reconciliation coordination mechanism.

Fig. 14. Synchronization and coordination mechanism.

synchronization method is very similar to a conservative timebucket method and barrier synchronization method [16,11,12].On the other hand, Coordination implies corrective actionfor discrepancies observed in the system entities to guaranteeconsistent views of the system. Coordination is performed bythe MRP/ERP system if it is necessary. This coordination issort of an optimistic approach for recovering production errorsrather than causality errors because these causality errors are

already prevented by conservative synchronization. Therefore,frequency of re-planning in the MRP/ERP system for coordinating

activities and tuning errors in the federates are controlled andmaintained by this mechanism. Although it is not consideringfidelity of atomic time (transit time), it can increase efficiency oftheentire federation in terms of fidelity in order to achieve a globalgoal, such as providing on-time production scenarios.

As shown in Fig. 14, all federates are initiated together andideally completed together at the end of time bucketT [specifiedand controlled by Global Virtual Time (GVT)] because a single-

phase order release scheme is used in this research. However, thefederates might be completed at different times due to difference


11/14


(a) Finite state automata for assembly.

(b) Finite state automata for component supplier.

(c) Finite state automata for transporter.

Fig. 15. FSA for supply chain system [36].

of each simulations Local Virtual Time (LVT) as affected by

computer performance [2]. Upon completion of its process for atime window (time bucket T), each simulation model reports

its preconditions determined by statistics such as the number

of parts produced, flow time, cost estimation, and so on, to the

adapter and waits for a decision for the next manufacturing cycle.

Once the adapter collects all of the reports, including statistics

and preconditions from all federates, it decides whether the entirefederation has to be reconciled by the MRP/ERP system using re-

planning such as regeneration or net changing. Alternatively,

it will be reinitiated using the updated time window T and the

next released orders.

3.2. Formal coordination scheme among supply chain members

In Section 3.1, the coordination scheme for push-based supply

chains was discussed. In this section, the coordination scheme

for pull-based supply chains is discussed. In this research, the

coordination model (referred to as MPSG) used in the shop floor

(see Fig. 2) is extended to the top floor. A message-based part-

state graph (MPSG) [27] is a modified FSA similar to a Mealy

machine [13]. It is a formal model of the execution portionof shop floor control that operates in a distributed control

environment. Individual controllers in a distributed environment

communicate using a well-defined protocol (messages) to affect

system operation.

The coordination between the supply chain members under

pull-based control is performed via MPSG. The MPSG graphs [36]

shown in Fig. 15 represent behaviors within each individual supply

chain member. In Fig. 15, circles with numbers indicate states or

nodes. The arrows indicate action that on completion will allow

the system to proceed to the next state. The actions need to be

performed in the sequence shown. The I, O, and T in Fig. 15

denote the incoming messages, outgoing messages, and tasks

carried out, respectively. Ob denotesthe observation carried out.

In addition, messages ending with as denote messages fromthe assembly plant to a component supplier. Similarly, messages

ending with at denote messages from assembly to transporter;

messages ending with st denote messages from componentsupplier to transporter.

Initially, the component suppliers, final assembly plant, and

transporter are at zero state (node). In this state, the final

assembly plant observes or checks the quantity of the component

available, for every given time period. If the number is above the

prescribed threshold (detect_above_threshold), it remains in thesame state. If the number of components falls below the threshold

(detect_below_threshold) (event for initiating a purchase order), it

moves to the next state. Once it has reached state 1 (node 1), itwill not check the quantity of components again until the entire

transaction is completed and it returns to zero state. The final

assembly initiates the transaction between it and the supplier by

sending the message open_transaction_as (Fig. 15(a) and (b)). It

then waits for a response (open_transaction_ok_sa) (Fig. 15(a) and

(b)). Upon receiving this message, it generates a purchase order

specifying component details and supplier details.

The above purchase order generation is represented by the

task (generate_order) (Fig. 15(a)). After successful generation ofthe purchase order, the final Assembly plant sends the message

order_as$12345$ (Fig. 15(a) and (b)). The number enclosed by the$ signs denotes the purchase order ID. The Supplier, on receiving

the message, seizes the purchase order based on the number pro-

vided. The Supplier then generates a transport order, represented

by the task (generate_transport_order) (Fig. 15(b) and (c)), for

sending the quantity of components requested. It then sends the

transport order, represented by the message (transport_order_st)(Fig. 15(b) and (c)), to the Transporter. The rest of the interac-

tions can be interpreted in a similar manner. It is noted that

this formal model can be also used for the push-type system or

other hybrid planning systems by changing the roles of the mes-

sages, even though FSA shown in Fig. 15 represents a coordination

scheme for pull-based systems. For example, the observation de-

tect_above_threshold can be changed toget_released_orders and themodel will wait forthe pushed release ordersfrom the centralized

time-phased planning system.


12/14


Fig. 16. Architecture for distributed simulation [23,18].

4. Web services technology for distributed simulations in

SBTFC

In this work, Web services technology is used for the integra-

tion of simulation federates operating in distributed environs (see

Fig. 16). The components of the system are: (1) individual simula-

tion federates, (2) corresponding client proxies, and (3) the trans-

action coordinator [23,18]. The simulation federates communicate

with each other using XML-based messages via services pro-

vided by the transaction coordinator. A client proxy provides the

interface that can be used by a simulation federate to commu-nicate with the transaction coordinator. The transaction coordi-

nator is responsible for performing time and data management

required for distributed simulation. In this work, the transaction

coordinator has been implemented using Web services technol-

ogy (state-of-the-art distributed computing technology) to over-

come the barrier of the standard way of communication between

heterogeneous distributed systems via W3C (www.w3c.org) stan-

dard protocols including XML, WSDL, and SOAP. Transaction coor-

dinators were developed using Web services technology instead of

using the standard HLA/RTI (High Level Architecture/Run Time In-

frastructure, IEEE Standard 1516-2000) for two reasons [23]. First,

even though commercial HLA/RTI software systems are reliable,

theyare notflexible to customize synchronizationmethods (which

require nontraditional features from the server). Second, the pro-posed transaction coordinator offers a simplified set of services

that makes it much easier for use as compared with the HLA/RTI.

Federates utilize the Web services developed in this work (ini-

tialize, advanceTime, cons_advanceTime, sendMessage, getMessage,

terminate, and cleanup) to achieve the desired simulation out-

come [18]. Fig. 17 shows a sample WSDL file for the advanceTime

method. A brief description of each service is given below.

initialize(fedName)

A federation execution consists of multiple federates communi-

cating with each other. Any federate that wants to become a

part of a federation execution can do so by calling this method.

Here, fedName is the identifier of the federate joining the feder-

ation execution.

advanceTime(reqFedName, timeVal)

Fig. 17. WSDL snippet for advanceTime(reqFedName, timeVal) [18].

Because the transaction coordinator is the central authority formanaging the synchronization between various federates, if afederate wants to move to a specific time, it must request fromthe transaction coordinator for the required time advance. Inthis method, the transaction coordinator follows the algorithmestimating the next synchronization point and grants the timeadvance accordingly. Here, reqFedName is the identifier of thefederate. The timeVal is the time to which the requestingfederate wants to jump.

cons_advanceTime(reqFedName, timeVal)This method is used when a federate wants to follow theconservative algorithm for time advancement. The WSDLdescription for this method is same as that for the advanceTimemethod.

sendMessage(fedName, msg)This method is used to send a message when a federate wantsto send a message to allfederates participatingin the federationexecution. The contents of the message sent by a federateare not interpreted by the transaction coordinator. Doing sowould imply that the transaction coordinator is limited to aparticular type of simulation. Hence, it is up to the participatingfederates to interpret a message and take appropriate action.Here, fedName is the identifier of the federate sending the

message. Msg is the actual message body to be delivered toother federates.

getMessage(requestingFedName) returns messageEach federate uses this method to retrieve messages queued forit. If there are no messages in thequeue maintained for this fed-erate, the requesting federate is informed accordingly. If thereis more than one message for the requesting federate, all of themessages in the queue are delivered. Here, requestingFedNameis the identifier of the federate interested in receiving the mes-sages queued for it.

terminate(requestingFedName)When a federate no longer wants to be part of the federationexecution, it can request so by calling this method. All of theresources allocated for the requesting federate are deallocated.

Here, requestingFedName is the identifier of the federate thatwants to withdraw from the federation execution. cleanup()

This method is used to destroy the federation execution andto perform cleanup activity. This method also sets up andinitializes data structures required for the next execution of thetransaction coordinator.

5. Conclusions

This paper has illustrated how simulation-based shop-floorplanning and control can be extended to enterprise-level activities(top floor). More specifically, the shop floor and the top floorhave been compared in terms of system components needed for

the simulation-based planning and control system, including: (1)physical entities and tasks, (2) simulation model, (3) resource
http://www.w3c.org/http://www.w3c.org/http://www.w3c.org/


13/14


model, (4) execution (coordination) model based on a Finite State

Automata (FSA), and (5) TCP/IP-based communication server. The

research in this comparison revealed that most of the above-

mentioned components for the shop floor were extensible to the

top floor. However, the research also creates new challenges for

top-floor planning and control.

First, during the operation of the integrated enterprise simula-

tion (involving multiple members simulations), several informa-tion exchanges take place. Their simulation clocks needed to be

synchronized to obtain a more accurate simulation result. To re-

solve this problem, a time bucket-based resource reconciliation

mechanism has been proposed, where all simulations execute in

parallel at full speed for a time bucket, and they reconcile only at

the end of the time bucket. Also discussed is how to determine an

efficient time bucket considering the frequency of re-planning in

the MRP/ERP system. Second, members simulations usually op-

erate under heterogeneous environs (for example, different simu-

lation languages, different operating systems, different networks),

which typically are geographically dispersed. To resolve this prob-

lem, use of Web service technology for the communication server

has been proposed, where the barrier of the standard way of com-

munication between heterogeneous distributed systems is over-come viaW3C standard protocols including XML, WSDL, and SOAP.

Third, a top-floor resource model (both the structural as well as

behavioral aspects) examining the Supply Chain Operations Refer-

ence (SCOR) model from the Supply Chain Council has been devel-

oped.

It is believed that the proposed component models, synchro-

nization mechanism, and communication server needed for the

top-floor simulation-based control system will not only simplify

the effort required to build such a system but also improve the ef-

ficiency of its operation. The future focus area of the research is to

apply the proposed approach to real manufacturing enterprises.

References

[1] Aguiar M, Murgatroyd I, Edwards J. Object-oriented resource models: Theirrole in specifying components of integrated manufacturing systems. ComputIntegrated Mfg Systems 1996;9(1):3348.

[2] AltuntasB, WyskRA. A framework for adaptivesynchronization of distributedsimulation. In: Proc. of 2004 winter simulation conf. 2004. p. 3717.

[3] Barnett MW, Miller CJ. Analysis of the virtual enterprise using distributedsupply chain modeling and simulation: An application of e-SCOR. In: Proc. of2000 winter simulation conf. 2000. p. 3525.

[4] Brandimarte P, Rigodanza M, Roero L. Conceptual modeling of an object-oriented scheduling architecture based on the shifting bottleneck procedure.IIE Trans 2000;32(10):9219.

[5] Cho H, Son Y, Jones A. Design and conceptual development of shop floorcontrollers through the manipulationof process plans. IntJ Comput IntegratedMfg 2006;19(4):35976.

[6] Cho H, Wysk RA. A robust adaptive scheduler for an intelligent workstationcontroller. Int J Production Res 1993;31(4):77190.

[7] Cho H, Wysk RA. Intelligent workstation controller for computer-integratedmanufacturing: Problems and models. J Manufacturing Systems 1995;14(4):25263.

[8] Davis WJ, Jones AT. A real-time production scheduler for a stochasticmanufacturing environment. Int J Comput Integrated Mfg 1988;4(4):53144.

[9] Drake GR, Smith JS, Peters BA. Simulation as a planning and scheduling toolfor flexible manufacturing systems. In: Proc. of 1995 winter simulation conf.1995. p. 80512.

[10] Drake GR, Smith J. Simulation systems for real time planning scheduling andcontrol. In: Proc. of 1996 winter simulation conf. 1996.

[11] Fujii S, KaiharaT, Morita H. A distributed virtualfactoryin agile manufacturingenvironment. Int J Production Res 2000;38(17):411328.

[12] Fujimoto RM. Parallel and distributed simulation systems. New York: JohnWiley and Sons; 2000.

[13] Hopcroft JE, Ullman JD. Introduction to automata theory, languages, andcomputation. Reading, MA: Addison-Wesley Publishing Co; 1979.

[14] Jones AT, Rabelo L, Yih Y. A hybrid approach for real-time sequencing andscheduling. Int J Comput Integrated Mfg 1995;8(2):14554.

[15] Kim MH, Kim YD. Simulation-based real-time scheduling mechanism in aflexible manufacturing system. J Manufacturing Systems 1994;13(2):8593.

[16] Kuhl F, Weatherly R, Dahmann J. Creating computer simulations: Anintroduction to the high level architecture. Upper Saddle River, NJ: Prentice-Hall; 1999.

[17] Lambert DM, Garcia-Dastugue SJ, Croxton KL. An evaluation of process-oriented supply chain management frameworks. J Business Logistics 2005;26(1):2551.

[18] Lee S, Zhao A, X. K, Shendarkar Y, Vasudevan, Son. Fully dynamic epoch (FDE)time synchronization method for distributed supply chain simulation. Int JComput Appl Technol 2008;31(34):24962.

[19] Lee S. Wysk RA. Resource reconciliation mechanism for a manufacturing

federation coordinated using an MRP/ERP system. In: Proc. of 2004 wintersimulation conf. 2004. p. 108593.

[20] Miltenburg J. Comparing JIT, MRP, and TOC and embedding TOC into MRP. IntJ Production Res 1997;35(4):114769.

[21] McLean C, Jones A, Lee T, Riddick F. An architecture for a generic data-drivenmachine shop simulator. In: Proc. of 2004 winter simulation conf. 2002.p. 110816.

[22] OKeefe RM, Rao R. Part input into a flexible flow system: An evaluation oflook-ahead simulation and a fuzzy rule base. Int J Flexible Mfg Systems 1992;4(2):11327.

[23] RathoreA, Balaraman B, ZhaoX, Venkateswaran J, SonY, WyskR. Developmentand benchmarking of an epoch time synchronization method for distributedsimulation. J Manufacturing Systems 2005;24(2):6978.

[24] Rother M, Shook J. Learning to see: Value stream mapping to add value andeliminate muda. Brookline, MA: Lean Enterprise Institute; 2003.

[25] Rder A, Tibken B. A methodology for modeling inter-company supply chainsandfor evaluatinga method of integrated productand processdocumentation.European J Oper Res 2006;169(3):101029.

[26] Shin K, Leem C. A reference system for internet based inter-enterprise

electronic commerce. J Systems Software 2002;60(3):195209.[27] Smith J, Joshi S. A formal model for shop floor control in automated

manufacturing. In: Proc. of 2nd industrial engg. research conf. 1993.[28] Smith JS, Wysk RA, Sturrok DT, Ramaswamy SE, Smith GD, Joshi SB. Discrete

event simulation for shop floor control. In: Proc. of 1994 winter simulationconf. 1994. p. 9629.

[29] Son Y, Joshi S, Wysk R, Smith J. Simulation based shop floor control.J Manufacturing Systems 2002;21(5):38094.

[30] Son Y, Rodriguez-Rivera H, Wysk RA. A multi-pass simulation-based, real-time scheduling and shop floor control system. Trans Society Comput SimulInternat 1999;16(4):15972.

[31] SonY, WyskRA. Automatic simulation modelgenerationfor simulation-based,real-time shop floor control. Comput Industry 2001;45(3):291308.

[32] Son Y, Wysk RA, Jones AT. Simulation based shop floor control: Formal model,model generation, and control interface. IIE Trans 2003;35(1):2948.

[33] Steele J, Son Y, Wysk RA. Resource modeling for the integration of themanufacturing enterprise. J Manufacturing Systems 2001;19(6):40727.

[34] Supply Chain Council. Supply-chain operations reference model: An overviewof SCOR version 8.0. Available online at www.supply-chain.org ; 2004

[accessed Sept. 2004].[35] ThoneyKA, Hodgson TJ, King RE, TanerMR,Wilson AD. Satisfyingdue-dates in

large multi factory supply chains. IIE Trans 2002;34(9):80311.[36] Venkateswaran J, Son Y. Design and development of a prototype distributed

simulation for evaluation of supply chains. Int J Industrial Engg 2004;11(2):15160.

[37] Wu D, Wysk RA. Multi-pass expert control system - a control/schedulingstructurefor flexiblemanufacturingcells.J Manufacturing Systems 1988;7(2):10720.

[38] Wysk RA,PetersBA, Smith JS.A formalprocessplanning schemafor shop floorcontrol. Engg Design Automation J 1994;1(1):319.

[39] Yamamoto M, Nof SY. Scheduling/rescheduling in the manufacturing operat-ing system environment. Int J Production Res 1985;23(4):70522.

Seungyub Lee is a doctoral candidate in the Department of Industrial andManufacturing Engineering at Pennsylvania State University. He received his B.S.Degree in industrial engineering fromYonsei University in Korea and his MS degree

in industrial and manufacturing engineering at Penn State. His research interestsare distributed simulation, simulation-based control, formal modeling of systemsof systems,and computer-integrated manufacturing. He can be reached by email [email protected].

Dr. Young-Jun Son is an associate professor in the Department of Systems andIndustrial Engineering at the University of Arizona. Dr. Son received his B.S. degreein industrial engineering with honors from POSTECH in Korea in 1996 and his M.S.and Ph.D. degrees in industrial and manufacturing engineering from PennsylvaniaState University in 1998 and 2000, respectively. He is an associate editor of theInternational Journal of Modeling and Simulation and the International Journal ofSimulation and Process Modeling, a senior member of SME, and a professionalmember of ASME, IEEE, IIE, and INFORMS. He is a recipient of the SME 2004M. Eugene Merchant Outstanding Young Manufacturing Engineer Award, the IIE2005 Outstanding Young Industrial Engineer Award, and the IERC 2005 Best PaperAward of the Modeling and Simulation Track. Dr. Son has authored or coauthoredmore than 60 publications in refereed journals and conferences, primarily ondeveloping the new field of distributed federation of multi-paradigm simulations

andexpanding thefield of computer-integrated control to encompass the extendedmanufacturing enterprise. He can be reached by email at [email protected].
http://www.supply-chain.org/http://www.supply-chain.org/mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]://www.supply-chain.org/


14/14


Dr. Richard A. Wysk is well known for his work in computer-integratedmanufacturing, computer-automated manufacturing, computer-aided processplanning, and concurrent engineering. He holds the Leonhard Chair in Engineeringat Pennsylvania State University. Prior to his current position, he was directorof the Institute for Manufacturing Systems and holder of the Royce WisenbakerChair in Innovation at Texas A&M University. Dr. Wysk also served on thefaculty of Virginia Tech and worked in industry as a research analyst for theCaterpillar Tractor Company and as production control manager for General

Electric. He is a decorated Vietnam veteran. Dr. Wysk is the author of severaltextbooks. Honors recognizing his research include the Institute of IndustrialEngineers David F. Baker Distinguished Research Award and the Society ofManufacturing Engineers Outstanding Young Manufacturing Engineer Award.Dr. Wysk holds bachelors and masters degrees in industrial engineering andoperations research from the University of Massachusetts and a Ph.D. inindustrial engineering from Purdue University. He can be reached by emailat [email protected] .
mailto:[email protected]:[email protected]:[email protected]

2 2007 lee s. j manuf syst simulation based planning and control from shop floor to top floor

Documents