2 2007 Lee S. J Manuf Syst Simulation Based Planning and Control From Shop Floor to Top Floor
-
Upload
laura-veronika-diah-mousehunter -
Category
Documents
-
view
213 -
download
0
Transcript of 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 -
7/28/2019 2 2007 Lee S. J Manuf Syst Simulation Based Planning and Control From Shop Floor to Top Floor
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.
-
7/28/2019 2 2007 Lee S. J Manuf Syst Simulation Based Planning and Control From Shop Floor to Top Floor
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
-
7/28/2019 2 2007 Lee S. J Manuf Syst Simulation Based Planning and Control From Shop Floor to Top Floor
4/14
88 S. Lee et al. / Journal of Manufacturing Systems 26 (2007) 8598
(a) Shop floor simulation. (b) Top floor simulation.
Fig. 5. Simulation in the planning stage: Approximation via random numbers.
(a) Shop floor simulation. (b) Top floor simulation.
Fig. 6. Simulation in the planning stage: Simulation embedding external simulation.
(a) Shop floor simulation. (b) Top floor 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
-
7/28/2019 2 2007 Lee S. J Manuf Syst Simulation Based Planning and Control From Shop Floor to Top Floor
5/14
S. Lee et al. / Journal of Manufacturing Systems 26 (2007) 8598 89
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
-
7/28/2019 2 2007 Lee S. J Manuf Syst Simulation Based Planning and Control From Shop Floor to Top Floor
6/14
90 S. Lee et al. / Journal of Manufacturing Systems 26 (2007) 8598
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/28/2019 2 2007 Lee S. J Manuf Syst Simulation Based Planning and Control From Shop Floor to Top Floor
7/14
S. Lee et al. / Journal of Manufacturing Systems 26 (2007) 8598 91
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
-
7/28/2019 2 2007 Lee S. J Manuf Syst Simulation Based Planning and Control From Shop Floor to Top Floor
8/14
92 S. Lee et al. / Journal of Manufacturing Systems 26 (2007) 8598
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
-
7/28/2019 2 2007 Lee S. J Manuf Syst Simulation Based Planning and Control From Shop Floor to Top Floor
9/14
S. Lee et al. / Journal of Manufacturing Systems 26 (2007) 8598 93
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
-
7/28/2019 2 2007 Lee S. J Manuf Syst Simulation Based Planning and Control From Shop Floor to Top Floor
10/14
94 S. Lee et al. / Journal of Manufacturing Systems 26 (2007) 8598
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
-
7/28/2019 2 2007 Lee S. J Manuf Syst Simulation Based Planning and Control From Shop Floor to Top Floor
11/14
S. Lee et al. / Journal of Manufacturing Systems 26 (2007) 8598 95
(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.
-
7/28/2019 2 2007 Lee S. J Manuf Syst Simulation Based Planning and Control From Shop Floor to Top Floor
12/14
96 S. Lee et al. / Journal of Manufacturing Systems 26 (2007) 8598
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/ -
7/28/2019 2 2007 Lee S. J Manuf Syst Simulation Based Planning and Control From Shop Floor to Top Floor
13/14
S. Lee et al. / Journal of Manufacturing Systems 26 (2007) 8598 97
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/ -
7/28/2019 2 2007 Lee S. J Manuf Syst Simulation Based Planning and Control From Shop Floor to Top Floor
14/14
98 S. Lee et al. / Journal of Manufacturing Systems 26 (2007) 8598
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]