- Email: [email protected]
Component based simulation modeling from neutral component libraries
Computers & Industrial Engineering 45 (2003) 141–165 www.elsevier.com/locate/dsw
Component based simulation modeling from neutral component librariesq Young Jun Sona,*, Albert T. Jonesb, Richard A. Wyskc a
Systems and Industrial Engineering Department, The University of Arizona, Tucson, AZ 85721-0020, USA b Manufacturing Systems Integration Division, NIST, Gaithersburg MD 20899 USA c Industrial and Manufacturing Engineering Department, The Pennsylvania State University, University Park PA 16802 USA Accepted 20 February 2003
Abstract Researchers at the National Institute of Standards and Technology have proposed the development of libraries of formal, neutral models of simulation components. The availability of such libraries would simplify the generation of simulation models, enable reuse of existing models construction of complicated models from simpler ones, and speed Internet-based simulation services. The result would be a dramatic increase in the use of simulation for decision-making and control in manufacturing. In this paper, we describe a collection of formal, neutral models for a discrete-event simulation of the flow of jobs through a job shop, where the simulation executes jobs based on a pre-provided schedule. We then derive a database structure from these formal models and discuss the population of that database with the data entries for a sample job shop. We then examine the translators we developed to go from the neutral representation of the simulation components to the representation required by Arena. Finally, we compare this routing aspect of translator to the routing aspects of a translator we built for ProModel. q 2003 Elsevier Science Ltd. All rights reserved. Keywords: Components based modeling; Simulation; Automatic Generation; Neutral components
1. Introduction Simulation has been a useful tool to design and analyze manufacturing systems for decades. A number of commercial products, with a range of capabilities and price tags, are on the market. Each of these packages has its own user interface for building models, animation capabilities for viewing the evolution of models over time, and tools for analyzing the output from those models. The degree of difficulty in q Processed by Area editor Tom Cavalier. * Corresponding author. E-mail address: [email protected] (Y.J. Son).
0360-8352/03/$ - see front matter q 2003 Elsevier Science Ltd. All rights reserved. doi:10.1016/S0360-8352(03)00023-8
142
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
building models, the fidelity of the visualization, and the sophistication of the analysis tools vary dramatically. Moreover, even for the experienced user, building, running, and analyzing a simulation model can be a very time-consuming and error-prone process. Consequently, the market penetration of simulation has been far less than it could be. To address the model-building issue, researchers at the National Institute of Standards and Technology (NIST) have proposed libraries of formal, neutral models of simulation components such as queues, machines and transporters. Each of these component models would have views tailored to specific modeling scenarios. These scenarios would be defined by different modeling templates-such as an equipment simulation, a material flow simulation, a supply chain simulation, and so forth. The availability of such libraries would enable component-based modeling, model reuse, composable simulations, and Internet-based services, all of which could increase market penetration dramatically (see Fig. 1). The major motivation for our research has been the development of an Internet-based simulationservice system that could be used by small and medium manufacturers. We have built a prototype of such a service (see http://sangham.sie.arizona.edu/ASG/) based on the work presented in this paper. Preliminary experiments were conducted to investigate the performance of this prototype for users requesting multiple services in parallel. In those experiments, the system was able to handle up to ten service requests without significant time delay. The principal effort in building this prototype was the construction of the libraries shown in Fig. 1. Each component in the library becomes basic building block (modules) to compose models of
Fig. 1. New concept using library components.
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
143
manufacturing systems of interest. The composition is done using a model builder (see Fig. 1), which will generate a simulation model for a specific commercial package. The model builder needs to be configured to generate a specific simulation model so that the simulation language works as intended. In this research, we designed and implemented two such model builders: one for Arena (Kelton, Sadowski, & Sadowski, 1998) and one for ProModel (Harrell, Ghosh, & Bowden, 2000). In this paper, we describe the results of a collaborative effort among NIST, Penn State University, and University of Arizona to build the necessary component models and a template for a simple, discreteevent simulation. That simulation models the flow of jobs through a small job shop based on a preprovided schedule. We describe the information requirements for the simulation components and provide simulation-language neutral, formal models based on those requirements. We then derive a database structure from these formal models and discuss the population of that database with the data entries for the sample job shop. Finally, we examine the translators we developed to go from the neutral representation of the components to the representation required by two commercial simulation packages. We begin with a short literature review.
2. Literature review Five approaches have been proposed for model building: natural language interfaces, graphical interfaces, interactive dialogue interfaces, resource and process descriptions, and the use of the production-resource and execution models. All simulation packages use some combination of these approaches. The earliest use of a natural language interface was the Natural Language Programming for Queueing Simulations (NLPQ) (Heidorn, 1974). After the required information had been collected, the NLPQ generated the simulation code in GPSS. Ford and Schroer (1987) developed the Electronic Manufacturing Simulation System (EMSS) also using a natural language interface. The input file, which contained electronics assembly words, expressions, and expectations, was parsed and translated into a representation that allowed the EMSS to generate the simulation code in SIMAN automatically. Yuan, Dogan, and Viegelahn (1993) used a batch file containing a list of operation equations and the remaining system specifications to generate the simulation code. The generator was written in FORTRAN and generated model and experimental files in the SIMAN simulation language. Doshi, Madala, and Sinclair (1985) and Murray and Sheppard (1988) proposed a graphical interface for describing the structure or layout of components within a system. Additional data, such as parameters for random distributions, initialization data, and queue disciplines, are required to complete the simulation model. Therefore, this approach is often combined with a natural language processor or a dialogue monitor. Lee (1996) presented a methodology for building models automatically based on the process flow model and the resource models. The process flow model represents the sequence parts follow through the resources, and any alternatives; the resource models contain descriptions of the resources in the sequence. Aytug and Dogan (1998) and Christenson and Dogan (1995) used a similar methodology for building models of KANBAN-controlled manufacturing systems. In Christenson and Dogan (1995), the system assumes that the generalized flow shop consists of work centers and different parts, and all parts must follow the same process routing. In Aytug and Dogan (1998), the generator has been enhanced so that it can handle convergent and divergent flows and different parts can have different routes.
144
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
Son (2000) and Son, Wysk, and Jones (2003) defined a formal production resource model, including machine information, shop configuration information, schedule information, part routing information, and order information. He used that model together with finite-state-automata-based execution module to generate the simulation model automatically. That approach can handle both push and pull strategies. Before presenting our approach, we give a brief description of the manufacturing system that we will use throughout the remainder of the paper. 3. Example manufacturing system An example shop floor is shown in Fig. 2. It contains a system input-buffer, a system output-buffer, and three processing stations—penn1, penn2, and penn3. Station penn1 has its own input buffer (penn1_in) and its own output buffer (penn1_out). Station penn2 has an input buffer only (penn2_in), and penn3 has neither input nor output buffers. The capacity of system buffers is 100; the capacity of each processing station is 1. This shop can make three different products: a mouse, a notebook, and a pen. The mouse requires processing at penn1 and penn2. The notebook requires processing at penn2 only; and, the pen requires processing at penn3 only. 4. Information requirements To build the model for this system, we have defined seven information objects: header, experiment, shop floor, product/process, production, station/schedule, and output. 4.1. Header information The header information object provides the introductory information about the simulation file. Each simulation file has exactly one header information object. The header information object is composed of a simulation file name, an analyst name, a layout file name, a save date, a save time, and a description. † Simulation file name—the unique name for the simulation file.
Fig. 2. Example system to be used for illustration.
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
† † † † †
145
Analyst name—the name of person that created the simulation file. Saved date—the date of the creation of the simulation file. Saved time—the time of the creation of the simulation file. Description—a word or group of words that describe the simulation file. Layout file name—the name for the layout file that is used for simulation background.
4.2. Experimental information Each simulation file is associated with one experimental information object. The experimental information object describes the environmental setting to run the simulation file and obtain the requested performance measures. That environment includes a time unit, a distance unit, a beginning time, a replication time, the number of replications, a terminating condition, and a collection of output information objects. Each output object is composed of a performance measure name. † † † † † † †
Time unit—the unit of time in the simulation file (can be day, hour, minute, or second). Distance unit—the unit of distance in the simulation file, usually a meter or a foot. Beginning time—the real value defining the beginning time of the first replication. Replication time—optional field to specify length (in time) of each replication. Number of replications—the integer defining the number repeated runs of the model. Terminating condition—optional field to specify an event-based terminating condition. Output information—an optional field to specify the performance name of interest.
4.3. Shop floor information Each simulation file contains one shop floor information object that describes the physical entities on the shop floor. This object is composed of a set of station information objects. Each station information object is composed of a station name, a capacity, a description, and a station type. The station-type information object is associated with a processing-station information object or a buffer-station information object. The former is composed of an optional input-buffer name and an optional outputbuffer name. The latter describes the buffer type. In the actual shop floor, there are two classes of stations: a processing station and a buffer station. If the station information object does not include the processing station information, it is interpreted as a buffer station. † † † †
Station name—the unique name for the station. Capacity—the integer value defining capacity characteristics of the station. Station type—unique identifier for station; e.g. processing, buffer. Processing station information Input-buffer name—optional string containing name for the dedicated input buffer in the processing station. Output-buffer name—optional string containing name for the dedicated output buffer in the processing station. † Buffer station information Buffer type—the string field specifying four possible types of buffers: system_ input_buffer, system_output_buffer, station_input_buffer, and station_output_buffer.
146
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
4.4. Product/process information The product/process information object provides the run time data for a simulation. It is composed of a product name and a process-plan information object. The latter is composed of a process-plan name and an ordered list of operation information objects. Each operation object is composed of an operation number, an operation name, a description, a station name, a processing time, a next station name, and a routing time. † Product name—the unique name for the product. † Process plan information Process plan name—the unique name for the process plan. Operation information Operation number—the unique identifier for the operation. Operation name—the word or a group of words defining the current operation. Station name—the name of a station where the operation occurs. Processing time—the real value defining the duration taken for the current operation. If the station is associated with a processing station, this value is associated with actual machining time. Next station name—the name of a station that the job will visit next. Routing time—the real value defining the time to move from the current station to the next station. Material transporters are not included in this model; therefore, it is assumed that jobs can move to the next station whenever there is available capacity. Description—a word or a group of words that describe the operation. 4.5. Production information A production information object provides the data for what is produced in the simulation and associated due dates. The production information is composed of a product name and a set of job information objects. The attributes for each job information object include a job name, a quantity, an arrival time, and a due time. † Product name—the name of the product that the job is associated with. Using this field, we can derive the associated process plan, which is provided by the product process information object in Section 4.4. † Job information Job name—the unique name of a job, an atomic object associated with one product. Quantity—the number of products to be produced. Arrival time—the time when the current job arrives in the simulation file. Due time—the time by when the current job is wanted to be finished by the customer. 4.6. Station/schedule information A station/schedule information object provides sequences of specific job operations for each processing station. In this research, this sequence is created and maintained external to the simulation. Riddick (1998) termed this sequence a dispatch list; we will call it a work-to-schedule.
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
147
The work-to-schedule object is composed of a name and an ordered list of scheduled operation information objects. Each scheduled operation object is composed of a job name and operation number. † Station name—the name of the station that the work to schedule is associated with. † Work to schedule information Work to schedule name—the unique name for the work to schedule. Scheduled operation information Job name—the name of the job that the work to schedule is associated with. Operation number—the number of the operation that the job is associated with. 4.7. Output information The simulation output is stored in a returned result information object. Each such object is composed of a performance measure name, and an associated graph name. † Performance measure name—the unique name of the performance measure. The contents of this file will be specific to the commercial simulation packages unless a generic way of specifying the name is created. This file needs to be associated with the performance measure name for the output information object. † Graph name—the name of the graph associated with a particular performance measure. This attribute is optional since not all performance measures will be represented as a graph. In general, each performance measure can have many different types of graphs. In this research, however, we only allowed one type for each performance measure.
5. Information models Based on the preceding information requirements, an EXPRESS and an EXPRESS-G (graphical EXPRESS) information model was created (Schenck & Wilson, 1994). EXPRESS is an ISO standard as a formal language to describe language-neutral information model (ISO, 1994). EXPRESS-G is a graphical version of the text-based EXPRESS. Fig. 3 shows the highest level of the EXPRESS-G model, and Fig. 4 shows one of seven lower level EXPRESS-G models. From these models, we generated an EXPRESS model; part of this model is presented in Section 5.1 and the rest of it is presented in Appendix A. A relational database (MS Access) was then instantiated based on the EXPRESS model. Finally, actual data for the example in Fig. 2 is presented. 5.1. Schema Types, entities, and functions have been defined formally as follows: SCHEMA discrete_event_simulation; TYPE station_type_information ¼ SELECT (processing_station_information, buffer_station_information);
148
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
Fig. 3. Discrete_event_simulation_for_schedule_evaluation_schema.
Fig. 4. Schema for Shop_floor_information in Fig. 3.
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
END_TYPE; ENTITY all_simulation_files; simulation_data: SET [0:?] OF simulation_information; END_ENTITY; ENTITY buffer_station_information; buffer_type: buffer_type_items; END_ENTITY; ENTITY header_information; simulation_file_name: name; analyst_name: OPTIONAL name; layout_file_name: OPTIONAL name; saved_date: OPTIONAL date; description: OPTIONAL text; saved_time: OPTIONAL time; UNIQUE UR1: simulation_file_name; END_ENTITY; ENTITY operation_information; operation_number: STRING; operation_name: name; station_name: name; processing_time: REAL; next_station_name: name; routing_time: REAL; description: OPTIONAL text; UNIQUE UR1: operation_number; END_ENTITY; ENTITY processing_station_information; station_input_buffer_name: OPTIONAL name; station_output_buffer_name: OPTIONAL name; END_ENTITY; ENTITY shop_floor_information; station_data: SET [0:?] OF station_information; END_ENTITY; ENTITY simulation_information; product_process_data: SET [0:?] OF product_process_information; production_data: SET [0:?] OF production_information; station_schedule_data: SET [0:?] OF station_schedule_information; returned_result_data: OPTIONAL SET [0:?] OF returned_result_information; header_data: header_information; experiment_data: experiment_information; shop_floor_data: shop_floor_information;
149
150
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
END_ENTITY; ENTITY station_information; station_name: name; capacity: INTEGER; station_type_data: station_type_information; description: OPTIONAL text; UNIQUE UR1: station_name; END_ENTITY; END_SCHEMA;
5.2. Database instantiation From the schemas shown in Section 5.1 and in Appendix A, we generated a collection of database tables in MS Access 97 (see Fig. 5). The tables in the figure belong to two classes. The first class contains a table for each entity in the EXPRESS schema. The second class contains tables that specify relationships among these entities. 5.3. Database for example system Several database tables associated with the example system in Fig. 2 have been populated by hand and are shown in Fig. 6. In the following sections, we describe how we generated the corresponding Arena.doe file and ProModel.mod file.
Fig. 5. The relationship among the tables in MS Access 97.
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
151
6. Model builder development The role of the model builder is to create a discrete-event simulation model for a predetermined simulation language from the neutral description of the system and the actual data in the database. The model builder is designed so that the system is data-driven, meaning the same model can be run many times by simply changing this sequence module (no change is needed if same set of products are used). We have designed and implemented model builders for two commercial simulation packages, Arena and ProModel. Due to limited space, this section focuses only on Arena, and Section 7 compares it with ProModel. 6.1. Shop floor The first step in creating the simulation model is the construction of the shop floor. The model builder creates this shop floor from the ‘stations’ table in the database (see Fig. 6a). Each station in that table is associated with the ‘server’ module of ‘common’ template in Arena (see Fig. 7). Part of the generated Arena model for the example system in Fig. 2 is shown in Fig. 7. Fig. 7 contains nine subsections, and Table 1 explains what they are. Note that Fig. 7 does not contain the subsection associated with schedule implementation due to limited space. Section 6.4 will describe it in detail. A blank ‘server’ module is shown in Fig. 8. The data for Station and Capacity in this module come directly from the stations table in the database. The remaining data in the module are defaults. Due to default characteristics of Arena, the stations table in the database cannot be converted directly to a set of server modules in Arena. First, the ‘server’ module in Arena has its dedicated queue. However, in the stations table, buffers are defined explicitly and independently from processing stations. Second, when two ‘server’ modules are connected, entities move ahead to the next server first and then check the availability of the server (see Fig. 9a). However, in reality, we should not allow entities to move to the next server until the server is available. To resolve these two problems, two modifications have been made in using ‘server’ modules. First, the dedicated queue in the server module has been de-activated by specifying an internal queue option. This allows us to model dedicated physical buffers explicitly with server modules (see Fig. 7). Second, a dummy resource is associated with each server module. When entities transfer from a one server module to another, they must seize (acquire) the dummy resource associated with the next server module (see Fig. 9b). Once entities are transferred to the next server, they release (free) the dummy resource. By doing this, we eliminate balking situations. 6.2. Job flow through the shop To control the flow of jobs through the shop during a particular run, Arena requires explicit values for the routings and processing times. Variables for these values and exact values are contained in a ‘sequence’ module in Arena (see Fig. 7a). The sequence module contains the part routing data, the process plan, for each specific run of the simulation. This data is a collection of three-dimensional arrays (product_id, step_id, n) where n ¼ 1; …3 (see Fig. 10). The meanings of the three values of n are processing time at this location, travel time, and next physical location. The actual data values are derived from the stations table and the operations table in the database. Arena provides two reserved
152
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
Fig. 6. Database information for the example system.
attributes, ‘NS’ and ‘IS’. ‘NS’ is used to represent product id and ‘IS’ is to represent the job step id on the basis of the information in the sequence module. For each Entity– Station pair, the ‘server’ module specifies three variables, Process Time, Leave Station, and Route Time (See Fig. 8). These variables are read in from the process plan (‘sequence’ module) in Fig. 7a and Fig. 10. When an entity enters a specific server, it carries automatically its own ‘NS’ and ‘IS’ values. Arena then read necessary values from the ‘sequence’ module using these ‘NS’ and ‘IS’ values. For each server module, Leave Station specifies the next physical station that the Entity will visit on its path through the shop. And, Route Time specifies the travel time to that server. These values are also read in from the ‘sequence’ module. From Fig. 6b, we see that the mouse’s route is input station, penn1, penn2, and output station. However, from the stations table (see Fig. 6a), we see that the actual
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
153
Fig. 7. Part of generated Arena model for the example system in Fig. 2.
physical path is input station, penn1_in, penn1, penn1_out, penn2_in, penn2, and output station. As noted above, this physical path, including all buffers, must be represented in Arena. This is accomplished using the ‘sequence’ module. 6.3. Job arrival information Arena, by default, does not provide capability to create entities based on the list of specific times. Therefore, it needs to be programmed explicitly so that an entity keeps reading the ‘jobs’ table and creates a job whenever specified. In this research, each ‘arrival’ module has been associated with each Table 1 Description of nine sub-sections in Fig. 7 Sub-section number
Description
a b c d e f g h i
Experimental Information Default blocks (starting point) System input buffer ‘penn1’ station (with input and output dedicated buffers) ‘penn2’ station (with input dedicated buffer) ‘penn3’ station (without dedicated buffers) System output buffer Default blocks (ending point) Entity arrival blocks
154
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
Fig. 8. A blank ‘Server’ module.
job (see Fig. 7i). By doing this, we could save programming load. However, when there are many jobs, many ‘arrival’ modules will be generated. There is nothing wrong with this, but the model looks crowded. Job arrival data is contained in the Arrival module, which contains variables called Station, Assign (e.g. Sequence), Batch Size, First Creation, Max Batches, Time Between, Leave Station, and Route Time. An entity arrives at Station. Assign is used to specify attributes for the arriving entity. Batch Size
Fig. 9. Modifications made in Arena for entity movement.
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
155
Fig. 10. A sequence module used to specify part routing information.
is the quantity of entities that arrive at each arrival time. First Creation is the time of the first arrival, Max Batches is the number of occurrences for every simulation run, and Time Between is the time between arrivals. Leave Station is used to specify the next station for which the entity initially heads for Route Time. Each arrival module (see Fig. 7i) is associated with one job in the ‘jobs’ table in the database (see Fig. 6b). First Creation and Batch Size are read from the ‘jobs’ table. Leave Station is set to penn_in_storage since all the jobs are assumed to arrive at the system input storage. Max Batches is also set to 1. The model builder is designed so that values are read from the ‘jobs’ table in the database (see Fig. 6b) for sequence (product_id and operation_id) and due_time. Time Between is left blank since each entity in a row is created only once for each simulation run. Time Between logic can be implemented using First Creation and Max Batches. For example, a job, whose First Creation is zero, Max Batches is 2, and Time Between is 10, is identical with two jobs, where Max Batches of each job is 1 and First Creation of each job is zero and 10, respectively. In this paper, the latter logic is used. 6.4. Schedule implementation The following describes our approach to implementing the work-to-schedules: † Each processing station is linked to a work-to-schedule. Operations can be added to or removed from the work-to-schedule dynamically during the simulation run. In Arena, an ‘expressions’ module, an array data structure, is used to represent a work-to-schedule. † There are m þ n logical (detached) queues, where m is the number of processing stations and n is the number of system input buffers. Parts wait in these queues until requested. † One entity is created for each processing station. This entity searches the m þ n queues for the next operation to be processed at the station. If the entity finds this operation in a detached queue, it requests that operation. This is associated with the top branch from the ‘Choose’ module in Fig. 11. If the entity cannot find this operation, it delays then searches again (the bottom branch in Fig. 11). The frequency of the search is a user-defined parameter. If the parameter is too large, the animation may
156
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
Fig. 11. Part of generated Arena simulation constructs for schedule implementation.
be slowed; if it is too small, the performance estimates may be inaccurate. Therefore, the frequency parameter should be as large as possible without exceeding the shortest processing time. Note Fig. 11 is associated with one processing station searching one detached queue. Our example contains 4 £ 4 ¼ 16 such subsections—4 processing stations and 4 detached queues. Fig. 12 helps to explain the schedule implementation methodology that has been described so far in this section. In Fig. 12, one system input buffer and two processing stations are associated with logical queues. Fig. 12 also depicts that one product sits on the logical queue associated with processing station
Fig. 12. Generated Arena simulation constructs associated with processing equipment.
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
157
1. This physically implies that processing station 1 has finished processing the job, and the job is still sitting on processing station 1 until it is requested by other processing station or system output buffer. In the dispatch list (work to schedule), the last element is always an arbitrary large number (e.g. 1000). It specifies that the next operation will be performed in the system output buffer, meaning that products leave the system. Given a set of work to schedules, the simulation implements these activity lists using the method that has been explained so far. Here, the work to schedules need to be accurate enough so that they can be directly executed in the simulation-based controller without any modification. In other words, each work to schedule for every station is maintained without any modification. If this assumption is not satisfied, the simulation is not able to implement the schedule. This assumption may be difficult to satisfy due to the different levels of detail between the scheduler and the simulation. To reduce this discrepancy, future research has to be conducted. 6.5. Simulation result information Performance names of interest have been provided in Fig. 6c. Davg(Station_Busy) represents the utilization of resource. The model builder understands this predefined name for performance measures. After simulation model is run, the results will be stored in the returned_results table (see Fig. 5). 6.6. Implementation The model builder has been implemented in Visual Basic 5.0. The model builder interacts with MS Access databases though the Microsoft Access 8.0 Object library and the DAO 3.5 (Data Access Objects) Object library. DAO is an application program interface (API) available with Microsoft’s Visual Basic that lets a programmer request access to a Microsoft Access database. The model builder can recognize templates and objects in Arena through the Arena Object Library. Visual Basic 5.0 provides an environment in which we can link necessary external libraries, Microsoft Access 8.0 Object library, DAO 3.5 (Data Access Objects) Object library, and Arena Object Library.
7. Comparison with another simulation package Each simulation package has its own characteristics. Therefore, a specific model builder needs to be designed and developed for each simulation package. As for a comparison with Arena, this section first describes the way ProModel specifies job flow through the shop. This section then briefly describes some characteristics of different prominent simulation packages. 7.1. Shop floor and job flow through the shop in ProModel The model builder creates this shop floor from the ‘stations’ table in the database (see Fig. 6a). Each station in that table is associated with the ‘location’ template in Promodel (see Fig. 13a). The data for first two columns in this template come directly from the stations table. The remaining columns in the template are defaults.
158
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
Fig. 13. ProModel templates model for the example system in Fig. 2.
To control the flow of jobs through the shop during a particular run, Promodel requires explicit values for the routings and processing times. Variables for these values are contained in the process template and the routing template; exact values are contained in the initialization file (see Fig. 13a and b). The initialization file contains the data for each specific run of the simulation. The model builder is designed so that the system is data-driven, the same model can be run many times by simply changing this file. The initialization file contains process plan data, which is a collection of three-dimensional arrays (product_id, operation_id, n) where n ¼ 1; …; 5: The meanings of the five values of n are: current
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
159
location, processing time at this location, next processing station, travel time, next physical location. The actual data values are derived from the stations table and the operations table in the database. For each Entity– Location pair, the process template specifies a three-dimensional variable called Operation. The first entry is the product_id, the second is the operation_id, and the third is the processing time. These entries are read in from the process plan part of the initialization file, Fig. 13b. For example, the processing time for the product-id ¼ 1, the mouse at penn1, which performs operation-id ¼ 2, is 300; the processing time at penn2, which performs operation-id ¼ 3, is 200. Note that whenever the Location is a buffer, the processing time is 0. The routing template contains variables called Output, Destination, Rule, and MoveLogic. Output has the same value as Entity, unless there is an assembly operation. Rule specifies the order in which jobs are removed from each queue; in this example it is defaulted to first-in-first-out. For each location in the process template, Destination specifies the next physical location that the Entity will visit on its path through the shop and MoveLogic specifies the travel time to that location. These values are read in from the Initialization file as attributes 5 and 4, respectively. From Fig. 6b, we see that the mouse’s route is input station, penn1, penn2, and output station. However, from the stations table, we see that the actual physical path is input station, penn1_in, penn1, penn1_out, penn2_in, penn2, and output station. As noted above, this physical path, including all buffers, must be represented in ProModel. This is accomplished using the routing template (see Fig. 13a) and the process plan data contained in the initialization file (see Fig. 13b). 7.2. Trade-off among simulation packages Each simulation language has its own advantages and disadvantages compared with other simulation languages. Comparing Arena and ProModel as an example, Arena is relatively more general-purpose simulation language whereas ProModel is more manufacturing-oriented simulation language. As a result, Arena has more flexibility than ProModel. On the other hand, modeling a specific manufacturing logic (e.g. pulling logic) in ProModel is easier than in Arena. As presented throughout this paper, both Arena and ProModel can support dynamic job flow, where a specific route is read from somewhere else (‘sequence’ in Arena and ‘Initialization’ in ProModel). This feature is not supported in Quest, where all possible routes from a station must be predefined before running a model. However, Quest is well known for its realistic graphics and animation modules. Due to different characteristics of simulation packages, a specific model builder needs to be designed and developed for each simulation package to achieve the same result.
8. Verification and validation 8.1. Verification Verification is the process of ensuring that a model behaves as intended (Kelton, Sadowski, & Sadowski., 1998). To complete the verification process, we first generated both Arena and ProModel simulation models for several manufacturing systems (including the example system in Section 3). We then allowed only a single entity to enter the system and followed that entity until it left the system to ensure that the model logic and data were correct. Then we ran 3 parts through the system using deterministic values for arrival and service times. We then calculated the predicted behavior by hand and
160
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
verified that generated models matched that behavior exactly. We did all comparisons using the trace tool and system-animation tool provided with the software. 8.2. Validation Validation is the process of ensuring that a model reproduces the behavior of the real system. Validation can be quite complicated—especially if the real system does not exit, which is the case for our example. Our approach was to show that output results from the two generated simulation models were equivalent for two different experiments. In the first experiment, we used the same deterministic values for all processing and routing times. We showed that both simulations terminated at the same time, produced exactly the same set of events, and reported exactly the same output values for makespan and average time in system. In the second experiment, the same simulation models were run with stochastic processing and routing times. All processing and routing times are assumed to be uniformly distributed with means of a; where a is the deterministic value used for the first experiment. The minimum and maximum values for uniform distributions are assumed to be 0:9a and 1:1a; respectively. In this experiment, we attempted to show that the models would not produce statistically different values for two selected performance measures, make-span and average time in system. We first estimated the average make-span for each model, ma and mp ; by simulating each model until 30 of each part type was produced. We then ran an initial experiment of 10 trials—on each trial the same seed number was used for each model. The results are shown in Table 2. To determine if 10 trials was sufficient we computed half-width of the resulting 95% confidence interval. In each case, the width of the interval was less than or equal to 10% of the average make-span. To determine statistical significance, we set a ¼ 0:05 and performed the following hypothesis test: H0 : ma 2 mp ¼ 0 H1 : ma 2 mp – 0 where the subscripts a and p denote Arena model and ProModel model. We then computed a paired-t confidence interval (Miller, Freund, & Johnson, 1990), which is highlighted in Table 2. With 95% confidence, we conclude that there is no significant difference between the make-span of the two simulation models (Arena and ProModel) given that the confidence interval includes zero. Average time in system has been tested in an exactly same manner. Using the same logic, we conclude, with 95% confidence (see Table 2), that there is no significant difference between the makespan of the two simulation models. While the make-span and average time in system are two prominent performance measures for analyzing manufacturing systems, other performance measures can also be tested in a similar manner. 8.3. Limitations The methodologies and simulation generators proposed in this paper were limited to discrete part manufacturing systems that operate with a single unit load. Changing to multiple loads would be quite easy. The other major assumptions were that these systems operate in a push environment and that each process has dedicated input/output buffers. Changing to a pull or a hybrid push/pull environment would
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
161
Table 2 Comparison of two simulation model results based on the paired differences Replication and Performance measure statistics Make-span
Average time in system
Arena
ProModel
Difference
Arena
ProModel
Difference
1 2 3 4 5 6 7 8 9 10
29,996.5 29,717.5 30,278.3 29,883.2 30,301.9 30,480.5 30,527.1 30,176.1 29,664.5 30,471.5
30,247.0 29,724.8 30,019.7 30,255.3 30,516.9 29,831.2 30,837.8 29,788.2 30,243.4 30,401.1
2250.5 27.3 258.7 2372.1 2215.0 648.9 2310.7 387.9 2579.2 70.1
14,585.0 14,506.0 14,824.0 14,508.0 14,798.0 14,939.0 14,995.0 14,603.0 14,414.0 14,926.0
14,692.3 14,349.8 14,558.3 14,596.8 14,832.3 14,449.7 15,074.0 14,323.6 14,781.6 14,958.7
2 107.3 156.2 265.7 2 88.8 2 34.3 489.3 2 79.0 279.4 2 367.6 2 32.7
Average Std. Dev. 95% CI
30,149.6 318.4 29; 921:9 # ma # 30; 377:4 455.5
30,186.5 236.9 352.3 381.4 29; 934:5 # mp 2309:8 # ma 2 mp # 30; 438:5 # 235:9 504.0
14,709.8 210.3 14; 559:4 # ma # 14; 860:2 300.9
14,661.7 48.1 252.6 247.7 14; 481:1 # mp 2129:1 # ma 2 mp # 14; 842:4 # 225:3 361.3
1.5%
1.7%
2.0%
2.5%
95% CI width Width/avg. (%)
require major modifications to our approach. Adding dedicated material handling equipment, such as a robot to tend to each process, would be easy. Adding material handling material and storage systems that were not dedicated to a specific process would require minor modifications to our approach. All of these will be part of our future research. 9. Conclusion In this paper, we used a simple manufacturing example to demonstrate the use of neutral component libraries to generate simulation models in specific simulation languages. We included the information requirements for these components, as well as a partial EXPRESS information model. An MS Access database based on the EXPRESS model and sample data have been instantiated. Two model builders have been designed to generate Arena and Promodel models from such a database. Given the example manufacturing system along with artificial product, process, order data, and a pre-provided schedule, complete Arena and Promodel models were generated, run, and results reported. Finally, characteristics of different simulation packages were compared. Future research will first consider time distributions to add stochastic behaviors to the system. In addition, material-handling equipment will be included in the future research to make simulations more realistic. Finally, future research will extend component libraries and provide an Internet-based simulation modeling service.
162
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
10. Product disclaimer Certain commercial software products are identified in this paper. These products were used only for demonstrations purposes. This use does not imply approval or endorsement by NIST, nor does it imply that these products are necessarily the best available for the purpose.
Acknowledgements This work was supported by the intelligent manufacturing systems (IMS) MISSION project (www. ims.org), and the State of Arizona Information Technology and Commerce Institute project.
Appendix A. EXPRESS information model
TYPE distance_unit_type ¼ ENUMERATION OF (feet, meter); END_TYPE; TYPE month_type ¼ ENUMERATION OF (April, August, December, February, January, July, June, March, May, November, October, September); END_TYPE; TYPE name ¼ STRING; END_TYPE; TYPE quantity_type_information ¼ SELECT (integer_quantity, real_quantity); END_TYPE; TYPE text ¼ STRING; END_TYPE;
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
TYPE time_unit_type ¼ ENUMERATION OF (day, hour, minute, second); END_TYPE; TYPE buffer_type_items ¼ ENUMERATION OF (station_input_buffer, station_output_buffer, system_input_buffer, system_output_buffer); END_TYPE; ENTITY station_schedule_information; work_to_schedule_data: work_to_schedule_information; station_name: name; END_ENTITY; ENTITY work_to_schedule_information; work_to_schedule_name: name; scheduled_operation_data: LIST [1:?] OF scheduled_operation_information; END_ENTITY; ENTITY scheduled_operation_information; operation_number: STRING; job_name: name; END_ENTITY; ENTITY date; year: INTEGER; month: month_type; day: INTEGER; END_ENTITY; ENTITY integer_quantity; quantity: INTEGER; END_ENTITY; ENTITY real_quantity; quantity: REAL; END_ENTITY; ENTITY time; hour: INTEGER; minute: INTEGER; second: INTEGER; END_ENTITY; ENTITY process_plan_information; process_plan_name: name; operation_data: LIST [1:?] OF operation_information; END_ENTITY;
163
164
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
ENTITY experiment_information; time_unit: time_unit_type; distance_unit: distance_unit_type; beginning_time: REAL; replication_time: REAL; number_of_replication: INTEGER; terminating_condition: OPTIONAL text; requested_result_data: OPTIONAL SET [0:?] OF requested_result_information; END_ENTITY; ENTITY requested_result_information; performance_measure_name: OPTIONAL SET [0:?] OF name; END_ENTITY; ENTITY returned_result_information; performance_measure_name: name; quantity_type_data: OPTIONAL quantity_type_information; graph_name: OPTIONAL name; END_ENTITY; ENTITY job_information; arrival_time: REAL; job_name: name; due_time: REAL; UNIQUE UR1: job_name; END_ENTITY; ENTITY product_process_information; process_plan_data: process_plan_information; product_name: name; END_ENTITY; ENTITY production_information; product_name: name; job_data: job_information; END_ENTITY;
References Aytug, H., & Dogan, C. (1998). A framework and a simulation generator for Kanban-controlled manufacturing systems. Computers and Industrial Engineering, 34(2), 337– 350. Christenson, K., & Dogan, C. (1995). A simulation generator for dual-card Kanban-controlled flow shops. International Journal of Production Research, 33(9), 2615– 2631. Doshi, K. A., Madala, S., & Sinclair, J. B (1985). GIST: A tool for specifying extended queueing network models. Technical Report TR8511, Rice University, Department of Electrical and Computer Engineering, Houston, Texas. Ford, D., & Schroer, B. (1987). An expert manufacturing simulation system. Simulation, 48(5), 193–200. Harrell, C., Ghosh, B., & Bowden, R. (2000). Simulation using Promodel. Boston, Massachusetts: McGraw Hill.
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
165
Heidorn, G. E. (1974). English as a very high level language for simulation programming. SIGPLAN Notices, 9, 91 – 100. ISO (1994). Industrial automation systems and integration—Product data representation and exchange—Part 11: Description methods: The EXPRESS language reference manual. Technical Report ISO 10303-11:1994(E). Kelton, D. W., Sadowski, R. P., & Sadowski, D. A. (1998). Simulation with arena. Boston, Massachusetts: McGraw Hill. Lee, S (1996). Automatic Generation of Simulation Model for Shop Floor Control System. Master’s thesis, POSTECH. Miller, I. R., Freund, J. E., & Johnson, R. (1990). Probability and statistics for engineers. Englewood Cliffs, NJ: Prentice Hall. Murray, K., & Sheppard, S. (1988). Knowledge-based simulation model specification. Simulation, 50(3), 112– 119. Riddick, F (1998). Using simulation as a proxy for a real shop floor and data collection system. NIST Report NISTIR 6173. Schenck, D., & Wilson, P. (1994). Information modeling the EXPRESS way. New York: Oxford University Press. Son, Y (2000). Simulation based shop floor control: Automatic model generation and control interface. PhD dissertation, Penn State University. Son, Y., Wysk, R., & Jones, A. (2003). Simulation based shop floor control: formal model, model generation and control interface. IIE Transactions, 35(1), 29 –48. Yuan, Y., Dogan, C., & Viegelahn, G. (1993). A flexible simulation model generator. Computers and Industrial Engineering, 24(2), 165– 175.
Component based simulation modeling from neutral component librariesq Young Jun Sona,*, Albert T. Jonesb, Richard A. Wyskc a
Systems and Industrial Engineering Department, The University of Arizona, Tucson, AZ 85721-0020, USA b Manufacturing Systems Integration Division, NIST, Gaithersburg MD 20899 USA c Industrial and Manufacturing Engineering Department, The Pennsylvania State University, University Park PA 16802 USA Accepted 20 February 2003
Abstract Researchers at the National Institute of Standards and Technology have proposed the development of libraries of formal, neutral models of simulation components. The availability of such libraries would simplify the generation of simulation models, enable reuse of existing models construction of complicated models from simpler ones, and speed Internet-based simulation services. The result would be a dramatic increase in the use of simulation for decision-making and control in manufacturing. In this paper, we describe a collection of formal, neutral models for a discrete-event simulation of the flow of jobs through a job shop, where the simulation executes jobs based on a pre-provided schedule. We then derive a database structure from these formal models and discuss the population of that database with the data entries for a sample job shop. We then examine the translators we developed to go from the neutral representation of the simulation components to the representation required by Arena. Finally, we compare this routing aspect of translator to the routing aspects of a translator we built for ProModel. q 2003 Elsevier Science Ltd. All rights reserved. Keywords: Components based modeling; Simulation; Automatic Generation; Neutral components
1. Introduction Simulation has been a useful tool to design and analyze manufacturing systems for decades. A number of commercial products, with a range of capabilities and price tags, are on the market. Each of these packages has its own user interface for building models, animation capabilities for viewing the evolution of models over time, and tools for analyzing the output from those models. The degree of difficulty in q Processed by Area editor Tom Cavalier. * Corresponding author. E-mail address: [email protected] (Y.J. Son).
0360-8352/03/$ - see front matter q 2003 Elsevier Science Ltd. All rights reserved. doi:10.1016/S0360-8352(03)00023-8
142
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
building models, the fidelity of the visualization, and the sophistication of the analysis tools vary dramatically. Moreover, even for the experienced user, building, running, and analyzing a simulation model can be a very time-consuming and error-prone process. Consequently, the market penetration of simulation has been far less than it could be. To address the model-building issue, researchers at the National Institute of Standards and Technology (NIST) have proposed libraries of formal, neutral models of simulation components such as queues, machines and transporters. Each of these component models would have views tailored to specific modeling scenarios. These scenarios would be defined by different modeling templates-such as an equipment simulation, a material flow simulation, a supply chain simulation, and so forth. The availability of such libraries would enable component-based modeling, model reuse, composable simulations, and Internet-based services, all of which could increase market penetration dramatically (see Fig. 1). The major motivation for our research has been the development of an Internet-based simulationservice system that could be used by small and medium manufacturers. We have built a prototype of such a service (see http://sangham.sie.arizona.edu/ASG/) based on the work presented in this paper. Preliminary experiments were conducted to investigate the performance of this prototype for users requesting multiple services in parallel. In those experiments, the system was able to handle up to ten service requests without significant time delay. The principal effort in building this prototype was the construction of the libraries shown in Fig. 1. Each component in the library becomes basic building block (modules) to compose models of
Fig. 1. New concept using library components.
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
143
manufacturing systems of interest. The composition is done using a model builder (see Fig. 1), which will generate a simulation model for a specific commercial package. The model builder needs to be configured to generate a specific simulation model so that the simulation language works as intended. In this research, we designed and implemented two such model builders: one for Arena (Kelton, Sadowski, & Sadowski, 1998) and one for ProModel (Harrell, Ghosh, & Bowden, 2000). In this paper, we describe the results of a collaborative effort among NIST, Penn State University, and University of Arizona to build the necessary component models and a template for a simple, discreteevent simulation. That simulation models the flow of jobs through a small job shop based on a preprovided schedule. We describe the information requirements for the simulation components and provide simulation-language neutral, formal models based on those requirements. We then derive a database structure from these formal models and discuss the population of that database with the data entries for the sample job shop. Finally, we examine the translators we developed to go from the neutral representation of the components to the representation required by two commercial simulation packages. We begin with a short literature review.
2. Literature review Five approaches have been proposed for model building: natural language interfaces, graphical interfaces, interactive dialogue interfaces, resource and process descriptions, and the use of the production-resource and execution models. All simulation packages use some combination of these approaches. The earliest use of a natural language interface was the Natural Language Programming for Queueing Simulations (NLPQ) (Heidorn, 1974). After the required information had been collected, the NLPQ generated the simulation code in GPSS. Ford and Schroer (1987) developed the Electronic Manufacturing Simulation System (EMSS) also using a natural language interface. The input file, which contained electronics assembly words, expressions, and expectations, was parsed and translated into a representation that allowed the EMSS to generate the simulation code in SIMAN automatically. Yuan, Dogan, and Viegelahn (1993) used a batch file containing a list of operation equations and the remaining system specifications to generate the simulation code. The generator was written in FORTRAN and generated model and experimental files in the SIMAN simulation language. Doshi, Madala, and Sinclair (1985) and Murray and Sheppard (1988) proposed a graphical interface for describing the structure or layout of components within a system. Additional data, such as parameters for random distributions, initialization data, and queue disciplines, are required to complete the simulation model. Therefore, this approach is often combined with a natural language processor or a dialogue monitor. Lee (1996) presented a methodology for building models automatically based on the process flow model and the resource models. The process flow model represents the sequence parts follow through the resources, and any alternatives; the resource models contain descriptions of the resources in the sequence. Aytug and Dogan (1998) and Christenson and Dogan (1995) used a similar methodology for building models of KANBAN-controlled manufacturing systems. In Christenson and Dogan (1995), the system assumes that the generalized flow shop consists of work centers and different parts, and all parts must follow the same process routing. In Aytug and Dogan (1998), the generator has been enhanced so that it can handle convergent and divergent flows and different parts can have different routes.
144
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
Son (2000) and Son, Wysk, and Jones (2003) defined a formal production resource model, including machine information, shop configuration information, schedule information, part routing information, and order information. He used that model together with finite-state-automata-based execution module to generate the simulation model automatically. That approach can handle both push and pull strategies. Before presenting our approach, we give a brief description of the manufacturing system that we will use throughout the remainder of the paper. 3. Example manufacturing system An example shop floor is shown in Fig. 2. It contains a system input-buffer, a system output-buffer, and three processing stations—penn1, penn2, and penn3. Station penn1 has its own input buffer (penn1_in) and its own output buffer (penn1_out). Station penn2 has an input buffer only (penn2_in), and penn3 has neither input nor output buffers. The capacity of system buffers is 100; the capacity of each processing station is 1. This shop can make three different products: a mouse, a notebook, and a pen. The mouse requires processing at penn1 and penn2. The notebook requires processing at penn2 only; and, the pen requires processing at penn3 only. 4. Information requirements To build the model for this system, we have defined seven information objects: header, experiment, shop floor, product/process, production, station/schedule, and output. 4.1. Header information The header information object provides the introductory information about the simulation file. Each simulation file has exactly one header information object. The header information object is composed of a simulation file name, an analyst name, a layout file name, a save date, a save time, and a description. † Simulation file name—the unique name for the simulation file.
Fig. 2. Example system to be used for illustration.
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
† † † † †
145
Analyst name—the name of person that created the simulation file. Saved date—the date of the creation of the simulation file. Saved time—the time of the creation of the simulation file. Description—a word or group of words that describe the simulation file. Layout file name—the name for the layout file that is used for simulation background.
4.2. Experimental information Each simulation file is associated with one experimental information object. The experimental information object describes the environmental setting to run the simulation file and obtain the requested performance measures. That environment includes a time unit, a distance unit, a beginning time, a replication time, the number of replications, a terminating condition, and a collection of output information objects. Each output object is composed of a performance measure name. † † † † † † †
Time unit—the unit of time in the simulation file (can be day, hour, minute, or second). Distance unit—the unit of distance in the simulation file, usually a meter or a foot. Beginning time—the real value defining the beginning time of the first replication. Replication time—optional field to specify length (in time) of each replication. Number of replications—the integer defining the number repeated runs of the model. Terminating condition—optional field to specify an event-based terminating condition. Output information—an optional field to specify the performance name of interest.
4.3. Shop floor information Each simulation file contains one shop floor information object that describes the physical entities on the shop floor. This object is composed of a set of station information objects. Each station information object is composed of a station name, a capacity, a description, and a station type. The station-type information object is associated with a processing-station information object or a buffer-station information object. The former is composed of an optional input-buffer name and an optional outputbuffer name. The latter describes the buffer type. In the actual shop floor, there are two classes of stations: a processing station and a buffer station. If the station information object does not include the processing station information, it is interpreted as a buffer station. † † † †
Station name—the unique name for the station. Capacity—the integer value defining capacity characteristics of the station. Station type—unique identifier for station; e.g. processing, buffer. Processing station information Input-buffer name—optional string containing name for the dedicated input buffer in the processing station. Output-buffer name—optional string containing name for the dedicated output buffer in the processing station. † Buffer station information Buffer type—the string field specifying four possible types of buffers: system_ input_buffer, system_output_buffer, station_input_buffer, and station_output_buffer.
146
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
4.4. Product/process information The product/process information object provides the run time data for a simulation. It is composed of a product name and a process-plan information object. The latter is composed of a process-plan name and an ordered list of operation information objects. Each operation object is composed of an operation number, an operation name, a description, a station name, a processing time, a next station name, and a routing time. † Product name—the unique name for the product. † Process plan information Process plan name—the unique name for the process plan. Operation information Operation number—the unique identifier for the operation. Operation name—the word or a group of words defining the current operation. Station name—the name of a station where the operation occurs. Processing time—the real value defining the duration taken for the current operation. If the station is associated with a processing station, this value is associated with actual machining time. Next station name—the name of a station that the job will visit next. Routing time—the real value defining the time to move from the current station to the next station. Material transporters are not included in this model; therefore, it is assumed that jobs can move to the next station whenever there is available capacity. Description—a word or a group of words that describe the operation. 4.5. Production information A production information object provides the data for what is produced in the simulation and associated due dates. The production information is composed of a product name and a set of job information objects. The attributes for each job information object include a job name, a quantity, an arrival time, and a due time. † Product name—the name of the product that the job is associated with. Using this field, we can derive the associated process plan, which is provided by the product process information object in Section 4.4. † Job information Job name—the unique name of a job, an atomic object associated with one product. Quantity—the number of products to be produced. Arrival time—the time when the current job arrives in the simulation file. Due time—the time by when the current job is wanted to be finished by the customer. 4.6. Station/schedule information A station/schedule information object provides sequences of specific job operations for each processing station. In this research, this sequence is created and maintained external to the simulation. Riddick (1998) termed this sequence a dispatch list; we will call it a work-to-schedule.
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
147
The work-to-schedule object is composed of a name and an ordered list of scheduled operation information objects. Each scheduled operation object is composed of a job name and operation number. † Station name—the name of the station that the work to schedule is associated with. † Work to schedule information Work to schedule name—the unique name for the work to schedule. Scheduled operation information Job name—the name of the job that the work to schedule is associated with. Operation number—the number of the operation that the job is associated with. 4.7. Output information The simulation output is stored in a returned result information object. Each such object is composed of a performance measure name, and an associated graph name. † Performance measure name—the unique name of the performance measure. The contents of this file will be specific to the commercial simulation packages unless a generic way of specifying the name is created. This file needs to be associated with the performance measure name for the output information object. † Graph name—the name of the graph associated with a particular performance measure. This attribute is optional since not all performance measures will be represented as a graph. In general, each performance measure can have many different types of graphs. In this research, however, we only allowed one type for each performance measure.
5. Information models Based on the preceding information requirements, an EXPRESS and an EXPRESS-G (graphical EXPRESS) information model was created (Schenck & Wilson, 1994). EXPRESS is an ISO standard as a formal language to describe language-neutral information model (ISO, 1994). EXPRESS-G is a graphical version of the text-based EXPRESS. Fig. 3 shows the highest level of the EXPRESS-G model, and Fig. 4 shows one of seven lower level EXPRESS-G models. From these models, we generated an EXPRESS model; part of this model is presented in Section 5.1 and the rest of it is presented in Appendix A. A relational database (MS Access) was then instantiated based on the EXPRESS model. Finally, actual data for the example in Fig. 2 is presented. 5.1. Schema Types, entities, and functions have been defined formally as follows: SCHEMA discrete_event_simulation; TYPE station_type_information ¼ SELECT (processing_station_information, buffer_station_information);
148
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
Fig. 3. Discrete_event_simulation_for_schedule_evaluation_schema.
Fig. 4. Schema for Shop_floor_information in Fig. 3.
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
END_TYPE; ENTITY all_simulation_files; simulation_data: SET [0:?] OF simulation_information; END_ENTITY; ENTITY buffer_station_information; buffer_type: buffer_type_items; END_ENTITY; ENTITY header_information; simulation_file_name: name; analyst_name: OPTIONAL name; layout_file_name: OPTIONAL name; saved_date: OPTIONAL date; description: OPTIONAL text; saved_time: OPTIONAL time; UNIQUE UR1: simulation_file_name; END_ENTITY; ENTITY operation_information; operation_number: STRING; operation_name: name; station_name: name; processing_time: REAL; next_station_name: name; routing_time: REAL; description: OPTIONAL text; UNIQUE UR1: operation_number; END_ENTITY; ENTITY processing_station_information; station_input_buffer_name: OPTIONAL name; station_output_buffer_name: OPTIONAL name; END_ENTITY; ENTITY shop_floor_information; station_data: SET [0:?] OF station_information; END_ENTITY; ENTITY simulation_information; product_process_data: SET [0:?] OF product_process_information; production_data: SET [0:?] OF production_information; station_schedule_data: SET [0:?] OF station_schedule_information; returned_result_data: OPTIONAL SET [0:?] OF returned_result_information; header_data: header_information; experiment_data: experiment_information; shop_floor_data: shop_floor_information;
149
150
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
END_ENTITY; ENTITY station_information; station_name: name; capacity: INTEGER; station_type_data: station_type_information; description: OPTIONAL text; UNIQUE UR1: station_name; END_ENTITY; END_SCHEMA;
5.2. Database instantiation From the schemas shown in Section 5.1 and in Appendix A, we generated a collection of database tables in MS Access 97 (see Fig. 5). The tables in the figure belong to two classes. The first class contains a table for each entity in the EXPRESS schema. The second class contains tables that specify relationships among these entities. 5.3. Database for example system Several database tables associated with the example system in Fig. 2 have been populated by hand and are shown in Fig. 6. In the following sections, we describe how we generated the corresponding Arena.doe file and ProModel.mod file.
Fig. 5. The relationship among the tables in MS Access 97.
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
151
6. Model builder development The role of the model builder is to create a discrete-event simulation model for a predetermined simulation language from the neutral description of the system and the actual data in the database. The model builder is designed so that the system is data-driven, meaning the same model can be run many times by simply changing this sequence module (no change is needed if same set of products are used). We have designed and implemented model builders for two commercial simulation packages, Arena and ProModel. Due to limited space, this section focuses only on Arena, and Section 7 compares it with ProModel. 6.1. Shop floor The first step in creating the simulation model is the construction of the shop floor. The model builder creates this shop floor from the ‘stations’ table in the database (see Fig. 6a). Each station in that table is associated with the ‘server’ module of ‘common’ template in Arena (see Fig. 7). Part of the generated Arena model for the example system in Fig. 2 is shown in Fig. 7. Fig. 7 contains nine subsections, and Table 1 explains what they are. Note that Fig. 7 does not contain the subsection associated with schedule implementation due to limited space. Section 6.4 will describe it in detail. A blank ‘server’ module is shown in Fig. 8. The data for Station and Capacity in this module come directly from the stations table in the database. The remaining data in the module are defaults. Due to default characteristics of Arena, the stations table in the database cannot be converted directly to a set of server modules in Arena. First, the ‘server’ module in Arena has its dedicated queue. However, in the stations table, buffers are defined explicitly and independently from processing stations. Second, when two ‘server’ modules are connected, entities move ahead to the next server first and then check the availability of the server (see Fig. 9a). However, in reality, we should not allow entities to move to the next server until the server is available. To resolve these two problems, two modifications have been made in using ‘server’ modules. First, the dedicated queue in the server module has been de-activated by specifying an internal queue option. This allows us to model dedicated physical buffers explicitly with server modules (see Fig. 7). Second, a dummy resource is associated with each server module. When entities transfer from a one server module to another, they must seize (acquire) the dummy resource associated with the next server module (see Fig. 9b). Once entities are transferred to the next server, they release (free) the dummy resource. By doing this, we eliminate balking situations. 6.2. Job flow through the shop To control the flow of jobs through the shop during a particular run, Arena requires explicit values for the routings and processing times. Variables for these values and exact values are contained in a ‘sequence’ module in Arena (see Fig. 7a). The sequence module contains the part routing data, the process plan, for each specific run of the simulation. This data is a collection of three-dimensional arrays (product_id, step_id, n) where n ¼ 1; …3 (see Fig. 10). The meanings of the three values of n are processing time at this location, travel time, and next physical location. The actual data values are derived from the stations table and the operations table in the database. Arena provides two reserved
152
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
Fig. 6. Database information for the example system.
attributes, ‘NS’ and ‘IS’. ‘NS’ is used to represent product id and ‘IS’ is to represent the job step id on the basis of the information in the sequence module. For each Entity– Station pair, the ‘server’ module specifies three variables, Process Time, Leave Station, and Route Time (See Fig. 8). These variables are read in from the process plan (‘sequence’ module) in Fig. 7a and Fig. 10. When an entity enters a specific server, it carries automatically its own ‘NS’ and ‘IS’ values. Arena then read necessary values from the ‘sequence’ module using these ‘NS’ and ‘IS’ values. For each server module, Leave Station specifies the next physical station that the Entity will visit on its path through the shop. And, Route Time specifies the travel time to that server. These values are also read in from the ‘sequence’ module. From Fig. 6b, we see that the mouse’s route is input station, penn1, penn2, and output station. However, from the stations table (see Fig. 6a), we see that the actual
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
153
Fig. 7. Part of generated Arena model for the example system in Fig. 2.
physical path is input station, penn1_in, penn1, penn1_out, penn2_in, penn2, and output station. As noted above, this physical path, including all buffers, must be represented in Arena. This is accomplished using the ‘sequence’ module. 6.3. Job arrival information Arena, by default, does not provide capability to create entities based on the list of specific times. Therefore, it needs to be programmed explicitly so that an entity keeps reading the ‘jobs’ table and creates a job whenever specified. In this research, each ‘arrival’ module has been associated with each Table 1 Description of nine sub-sections in Fig. 7 Sub-section number
Description
a b c d e f g h i
Experimental Information Default blocks (starting point) System input buffer ‘penn1’ station (with input and output dedicated buffers) ‘penn2’ station (with input dedicated buffer) ‘penn3’ station (without dedicated buffers) System output buffer Default blocks (ending point) Entity arrival blocks
154
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
Fig. 8. A blank ‘Server’ module.
job (see Fig. 7i). By doing this, we could save programming load. However, when there are many jobs, many ‘arrival’ modules will be generated. There is nothing wrong with this, but the model looks crowded. Job arrival data is contained in the Arrival module, which contains variables called Station, Assign (e.g. Sequence), Batch Size, First Creation, Max Batches, Time Between, Leave Station, and Route Time. An entity arrives at Station. Assign is used to specify attributes for the arriving entity. Batch Size
Fig. 9. Modifications made in Arena for entity movement.
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
155
Fig. 10. A sequence module used to specify part routing information.
is the quantity of entities that arrive at each arrival time. First Creation is the time of the first arrival, Max Batches is the number of occurrences for every simulation run, and Time Between is the time between arrivals. Leave Station is used to specify the next station for which the entity initially heads for Route Time. Each arrival module (see Fig. 7i) is associated with one job in the ‘jobs’ table in the database (see Fig. 6b). First Creation and Batch Size are read from the ‘jobs’ table. Leave Station is set to penn_in_storage since all the jobs are assumed to arrive at the system input storage. Max Batches is also set to 1. The model builder is designed so that values are read from the ‘jobs’ table in the database (see Fig. 6b) for sequence (product_id and operation_id) and due_time. Time Between is left blank since each entity in a row is created only once for each simulation run. Time Between logic can be implemented using First Creation and Max Batches. For example, a job, whose First Creation is zero, Max Batches is 2, and Time Between is 10, is identical with two jobs, where Max Batches of each job is 1 and First Creation of each job is zero and 10, respectively. In this paper, the latter logic is used. 6.4. Schedule implementation The following describes our approach to implementing the work-to-schedules: † Each processing station is linked to a work-to-schedule. Operations can be added to or removed from the work-to-schedule dynamically during the simulation run. In Arena, an ‘expressions’ module, an array data structure, is used to represent a work-to-schedule. † There are m þ n logical (detached) queues, where m is the number of processing stations and n is the number of system input buffers. Parts wait in these queues until requested. † One entity is created for each processing station. This entity searches the m þ n queues for the next operation to be processed at the station. If the entity finds this operation in a detached queue, it requests that operation. This is associated with the top branch from the ‘Choose’ module in Fig. 11. If the entity cannot find this operation, it delays then searches again (the bottom branch in Fig. 11). The frequency of the search is a user-defined parameter. If the parameter is too large, the animation may
156
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
Fig. 11. Part of generated Arena simulation constructs for schedule implementation.
be slowed; if it is too small, the performance estimates may be inaccurate. Therefore, the frequency parameter should be as large as possible without exceeding the shortest processing time. Note Fig. 11 is associated with one processing station searching one detached queue. Our example contains 4 £ 4 ¼ 16 such subsections—4 processing stations and 4 detached queues. Fig. 12 helps to explain the schedule implementation methodology that has been described so far in this section. In Fig. 12, one system input buffer and two processing stations are associated with logical queues. Fig. 12 also depicts that one product sits on the logical queue associated with processing station
Fig. 12. Generated Arena simulation constructs associated with processing equipment.
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
157
1. This physically implies that processing station 1 has finished processing the job, and the job is still sitting on processing station 1 until it is requested by other processing station or system output buffer. In the dispatch list (work to schedule), the last element is always an arbitrary large number (e.g. 1000). It specifies that the next operation will be performed in the system output buffer, meaning that products leave the system. Given a set of work to schedules, the simulation implements these activity lists using the method that has been explained so far. Here, the work to schedules need to be accurate enough so that they can be directly executed in the simulation-based controller without any modification. In other words, each work to schedule for every station is maintained without any modification. If this assumption is not satisfied, the simulation is not able to implement the schedule. This assumption may be difficult to satisfy due to the different levels of detail between the scheduler and the simulation. To reduce this discrepancy, future research has to be conducted. 6.5. Simulation result information Performance names of interest have been provided in Fig. 6c. Davg(Station_Busy) represents the utilization of resource. The model builder understands this predefined name for performance measures. After simulation model is run, the results will be stored in the returned_results table (see Fig. 5). 6.6. Implementation The model builder has been implemented in Visual Basic 5.0. The model builder interacts with MS Access databases though the Microsoft Access 8.0 Object library and the DAO 3.5 (Data Access Objects) Object library. DAO is an application program interface (API) available with Microsoft’s Visual Basic that lets a programmer request access to a Microsoft Access database. The model builder can recognize templates and objects in Arena through the Arena Object Library. Visual Basic 5.0 provides an environment in which we can link necessary external libraries, Microsoft Access 8.0 Object library, DAO 3.5 (Data Access Objects) Object library, and Arena Object Library.
7. Comparison with another simulation package Each simulation package has its own characteristics. Therefore, a specific model builder needs to be designed and developed for each simulation package. As for a comparison with Arena, this section first describes the way ProModel specifies job flow through the shop. This section then briefly describes some characteristics of different prominent simulation packages. 7.1. Shop floor and job flow through the shop in ProModel The model builder creates this shop floor from the ‘stations’ table in the database (see Fig. 6a). Each station in that table is associated with the ‘location’ template in Promodel (see Fig. 13a). The data for first two columns in this template come directly from the stations table. The remaining columns in the template are defaults.
158
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
Fig. 13. ProModel templates model for the example system in Fig. 2.
To control the flow of jobs through the shop during a particular run, Promodel requires explicit values for the routings and processing times. Variables for these values are contained in the process template and the routing template; exact values are contained in the initialization file (see Fig. 13a and b). The initialization file contains the data for each specific run of the simulation. The model builder is designed so that the system is data-driven, the same model can be run many times by simply changing this file. The initialization file contains process plan data, which is a collection of three-dimensional arrays (product_id, operation_id, n) where n ¼ 1; …; 5: The meanings of the five values of n are: current
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
159
location, processing time at this location, next processing station, travel time, next physical location. The actual data values are derived from the stations table and the operations table in the database. For each Entity– Location pair, the process template specifies a three-dimensional variable called Operation. The first entry is the product_id, the second is the operation_id, and the third is the processing time. These entries are read in from the process plan part of the initialization file, Fig. 13b. For example, the processing time for the product-id ¼ 1, the mouse at penn1, which performs operation-id ¼ 2, is 300; the processing time at penn2, which performs operation-id ¼ 3, is 200. Note that whenever the Location is a buffer, the processing time is 0. The routing template contains variables called Output, Destination, Rule, and MoveLogic. Output has the same value as Entity, unless there is an assembly operation. Rule specifies the order in which jobs are removed from each queue; in this example it is defaulted to first-in-first-out. For each location in the process template, Destination specifies the next physical location that the Entity will visit on its path through the shop and MoveLogic specifies the travel time to that location. These values are read in from the Initialization file as attributes 5 and 4, respectively. From Fig. 6b, we see that the mouse’s route is input station, penn1, penn2, and output station. However, from the stations table, we see that the actual physical path is input station, penn1_in, penn1, penn1_out, penn2_in, penn2, and output station. As noted above, this physical path, including all buffers, must be represented in ProModel. This is accomplished using the routing template (see Fig. 13a) and the process plan data contained in the initialization file (see Fig. 13b). 7.2. Trade-off among simulation packages Each simulation language has its own advantages and disadvantages compared with other simulation languages. Comparing Arena and ProModel as an example, Arena is relatively more general-purpose simulation language whereas ProModel is more manufacturing-oriented simulation language. As a result, Arena has more flexibility than ProModel. On the other hand, modeling a specific manufacturing logic (e.g. pulling logic) in ProModel is easier than in Arena. As presented throughout this paper, both Arena and ProModel can support dynamic job flow, where a specific route is read from somewhere else (‘sequence’ in Arena and ‘Initialization’ in ProModel). This feature is not supported in Quest, where all possible routes from a station must be predefined before running a model. However, Quest is well known for its realistic graphics and animation modules. Due to different characteristics of simulation packages, a specific model builder needs to be designed and developed for each simulation package to achieve the same result.
8. Verification and validation 8.1. Verification Verification is the process of ensuring that a model behaves as intended (Kelton, Sadowski, & Sadowski., 1998). To complete the verification process, we first generated both Arena and ProModel simulation models for several manufacturing systems (including the example system in Section 3). We then allowed only a single entity to enter the system and followed that entity until it left the system to ensure that the model logic and data were correct. Then we ran 3 parts through the system using deterministic values for arrival and service times. We then calculated the predicted behavior by hand and
160
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
verified that generated models matched that behavior exactly. We did all comparisons using the trace tool and system-animation tool provided with the software. 8.2. Validation Validation is the process of ensuring that a model reproduces the behavior of the real system. Validation can be quite complicated—especially if the real system does not exit, which is the case for our example. Our approach was to show that output results from the two generated simulation models were equivalent for two different experiments. In the first experiment, we used the same deterministic values for all processing and routing times. We showed that both simulations terminated at the same time, produced exactly the same set of events, and reported exactly the same output values for makespan and average time in system. In the second experiment, the same simulation models were run with stochastic processing and routing times. All processing and routing times are assumed to be uniformly distributed with means of a; where a is the deterministic value used for the first experiment. The minimum and maximum values for uniform distributions are assumed to be 0:9a and 1:1a; respectively. In this experiment, we attempted to show that the models would not produce statistically different values for two selected performance measures, make-span and average time in system. We first estimated the average make-span for each model, ma and mp ; by simulating each model until 30 of each part type was produced. We then ran an initial experiment of 10 trials—on each trial the same seed number was used for each model. The results are shown in Table 2. To determine if 10 trials was sufficient we computed half-width of the resulting 95% confidence interval. In each case, the width of the interval was less than or equal to 10% of the average make-span. To determine statistical significance, we set a ¼ 0:05 and performed the following hypothesis test: H0 : ma 2 mp ¼ 0 H1 : ma 2 mp – 0 where the subscripts a and p denote Arena model and ProModel model. We then computed a paired-t confidence interval (Miller, Freund, & Johnson, 1990), which is highlighted in Table 2. With 95% confidence, we conclude that there is no significant difference between the make-span of the two simulation models (Arena and ProModel) given that the confidence interval includes zero. Average time in system has been tested in an exactly same manner. Using the same logic, we conclude, with 95% confidence (see Table 2), that there is no significant difference between the makespan of the two simulation models. While the make-span and average time in system are two prominent performance measures for analyzing manufacturing systems, other performance measures can also be tested in a similar manner. 8.3. Limitations The methodologies and simulation generators proposed in this paper were limited to discrete part manufacturing systems that operate with a single unit load. Changing to multiple loads would be quite easy. The other major assumptions were that these systems operate in a push environment and that each process has dedicated input/output buffers. Changing to a pull or a hybrid push/pull environment would
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
161
Table 2 Comparison of two simulation model results based on the paired differences Replication and Performance measure statistics Make-span
Average time in system
Arena
ProModel
Difference
Arena
ProModel
Difference
1 2 3 4 5 6 7 8 9 10
29,996.5 29,717.5 30,278.3 29,883.2 30,301.9 30,480.5 30,527.1 30,176.1 29,664.5 30,471.5
30,247.0 29,724.8 30,019.7 30,255.3 30,516.9 29,831.2 30,837.8 29,788.2 30,243.4 30,401.1
2250.5 27.3 258.7 2372.1 2215.0 648.9 2310.7 387.9 2579.2 70.1
14,585.0 14,506.0 14,824.0 14,508.0 14,798.0 14,939.0 14,995.0 14,603.0 14,414.0 14,926.0
14,692.3 14,349.8 14,558.3 14,596.8 14,832.3 14,449.7 15,074.0 14,323.6 14,781.6 14,958.7
2 107.3 156.2 265.7 2 88.8 2 34.3 489.3 2 79.0 279.4 2 367.6 2 32.7
Average Std. Dev. 95% CI
30,149.6 318.4 29; 921:9 # ma # 30; 377:4 455.5
30,186.5 236.9 352.3 381.4 29; 934:5 # mp 2309:8 # ma 2 mp # 30; 438:5 # 235:9 504.0
14,709.8 210.3 14; 559:4 # ma # 14; 860:2 300.9
14,661.7 48.1 252.6 247.7 14; 481:1 # mp 2129:1 # ma 2 mp # 14; 842:4 # 225:3 361.3
1.5%
1.7%
2.0%
2.5%
95% CI width Width/avg. (%)
require major modifications to our approach. Adding dedicated material handling equipment, such as a robot to tend to each process, would be easy. Adding material handling material and storage systems that were not dedicated to a specific process would require minor modifications to our approach. All of these will be part of our future research. 9. Conclusion In this paper, we used a simple manufacturing example to demonstrate the use of neutral component libraries to generate simulation models in specific simulation languages. We included the information requirements for these components, as well as a partial EXPRESS information model. An MS Access database based on the EXPRESS model and sample data have been instantiated. Two model builders have been designed to generate Arena and Promodel models from such a database. Given the example manufacturing system along with artificial product, process, order data, and a pre-provided schedule, complete Arena and Promodel models were generated, run, and results reported. Finally, characteristics of different simulation packages were compared. Future research will first consider time distributions to add stochastic behaviors to the system. In addition, material-handling equipment will be included in the future research to make simulations more realistic. Finally, future research will extend component libraries and provide an Internet-based simulation modeling service.
162
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
10. Product disclaimer Certain commercial software products are identified in this paper. These products were used only for demonstrations purposes. This use does not imply approval or endorsement by NIST, nor does it imply that these products are necessarily the best available for the purpose.
Acknowledgements This work was supported by the intelligent manufacturing systems (IMS) MISSION project (www. ims.org), and the State of Arizona Information Technology and Commerce Institute project.
Appendix A. EXPRESS information model
TYPE distance_unit_type ¼ ENUMERATION OF (feet, meter); END_TYPE; TYPE month_type ¼ ENUMERATION OF (April, August, December, February, January, July, June, March, May, November, October, September); END_TYPE; TYPE name ¼ STRING; END_TYPE; TYPE quantity_type_information ¼ SELECT (integer_quantity, real_quantity); END_TYPE; TYPE text ¼ STRING; END_TYPE;
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
TYPE time_unit_type ¼ ENUMERATION OF (day, hour, minute, second); END_TYPE; TYPE buffer_type_items ¼ ENUMERATION OF (station_input_buffer, station_output_buffer, system_input_buffer, system_output_buffer); END_TYPE; ENTITY station_schedule_information; work_to_schedule_data: work_to_schedule_information; station_name: name; END_ENTITY; ENTITY work_to_schedule_information; work_to_schedule_name: name; scheduled_operation_data: LIST [1:?] OF scheduled_operation_information; END_ENTITY; ENTITY scheduled_operation_information; operation_number: STRING; job_name: name; END_ENTITY; ENTITY date; year: INTEGER; month: month_type; day: INTEGER; END_ENTITY; ENTITY integer_quantity; quantity: INTEGER; END_ENTITY; ENTITY real_quantity; quantity: REAL; END_ENTITY; ENTITY time; hour: INTEGER; minute: INTEGER; second: INTEGER; END_ENTITY; ENTITY process_plan_information; process_plan_name: name; operation_data: LIST [1:?] OF operation_information; END_ENTITY;
163
164
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
ENTITY experiment_information; time_unit: time_unit_type; distance_unit: distance_unit_type; beginning_time: REAL; replication_time: REAL; number_of_replication: INTEGER; terminating_condition: OPTIONAL text; requested_result_data: OPTIONAL SET [0:?] OF requested_result_information; END_ENTITY; ENTITY requested_result_information; performance_measure_name: OPTIONAL SET [0:?] OF name; END_ENTITY; ENTITY returned_result_information; performance_measure_name: name; quantity_type_data: OPTIONAL quantity_type_information; graph_name: OPTIONAL name; END_ENTITY; ENTITY job_information; arrival_time: REAL; job_name: name; due_time: REAL; UNIQUE UR1: job_name; END_ENTITY; ENTITY product_process_information; process_plan_data: process_plan_information; product_name: name; END_ENTITY; ENTITY production_information; product_name: name; job_data: job_information; END_ENTITY;
References Aytug, H., & Dogan, C. (1998). A framework and a simulation generator for Kanban-controlled manufacturing systems. Computers and Industrial Engineering, 34(2), 337– 350. Christenson, K., & Dogan, C. (1995). A simulation generator for dual-card Kanban-controlled flow shops. International Journal of Production Research, 33(9), 2615– 2631. Doshi, K. A., Madala, S., & Sinclair, J. B (1985). GIST: A tool for specifying extended queueing network models. Technical Report TR8511, Rice University, Department of Electrical and Computer Engineering, Houston, Texas. Ford, D., & Schroer, B. (1987). An expert manufacturing simulation system. Simulation, 48(5), 193–200. Harrell, C., Ghosh, B., & Bowden, R. (2000). Simulation using Promodel. Boston, Massachusetts: McGraw Hill.
Y.J. Son et al. / Computers & Industrial Engineering 45 (2003) 141–165
165
Heidorn, G. E. (1974). English as a very high level language for simulation programming. SIGPLAN Notices, 9, 91 – 100. ISO (1994). Industrial automation systems and integration—Product data representation and exchange—Part 11: Description methods: The EXPRESS language reference manual. Technical Report ISO 10303-11:1994(E). Kelton, D. W., Sadowski, R. P., & Sadowski, D. A. (1998). Simulation with arena. Boston, Massachusetts: McGraw Hill. Lee, S (1996). Automatic Generation of Simulation Model for Shop Floor Control System. Master’s thesis, POSTECH. Miller, I. R., Freund, J. E., & Johnson, R. (1990). Probability and statistics for engineers. Englewood Cliffs, NJ: Prentice Hall. Murray, K., & Sheppard, S. (1988). Knowledge-based simulation model specification. Simulation, 50(3), 112– 119. Riddick, F (1998). Using simulation as a proxy for a real shop floor and data collection system. NIST Report NISTIR 6173. Schenck, D., & Wilson, P. (1994). Information modeling the EXPRESS way. New York: Oxford University Press. Son, Y (2000). Simulation based shop floor control: Automatic model generation and control interface. PhD dissertation, Penn State University. Son, Y., Wysk, R., & Jones, A. (2003). Simulation based shop floor control: formal model, model generation and control interface. IIE Transactions, 35(1), 29 –48. Yuan, Y., Dogan, C., & Viegelahn, G. (1993). A flexible simulation model generator. Computers and Industrial Engineering, 24(2), 165– 175.