Object-oriented software implementation for manufacturing systems.

1. Introduction

Traditional simulation approaches do not provide for explicit representation of data, information, knowledge, and decisions (control) in a simulation model. A modeling formalism has been proposed [1,2] to overcome this shortcoming of conventional modeling approaches. There

is a natural link between the developed formalism and the object-oriented programming (OOP) approach. The work presented in this paper is an effort to show how to integrate a science base for simulation, object-oriented modeling, and artificial intelligence techniques under a unified framework. The first two sections give a brief overview of the proposed discrete event simulation formalism and object-oriented programming concepts. The reader should refer to [1] and [3], respectively, for detailed information on the material introduced in these two sections. The next section gives an overview of the software implementation of these concepts in the Smalltalk language, explaining how the constructs of the formalism are used to define software object classes that are directly utilized to develop a simulation model. Because the main emphasis of the study is on modeling manufacturing systems, object classes are designed within the context of manufacturing. Furthermore, a made-to-order type of system is assumed to test the software's ability to represent real-time dynamic interactions between system elements.

2. Object-oriented programming

In object-oriented programming, a software system is composed of interacting 'objects'. Objects are the combination of the attributes of both data and procedures of traditional computer programming. In OOP, data is active in the form of an object and performs operations on itself. Each object represents some abstract or physical entity in the problem being solved and is a complete description of the entity, including the data structures to define its structure and state, and procedures to define its behavior. An object is an instance of a 'class'. The class object provides all the information necessary to construct and use objects of a particular kind. In other words, objects that have things in common are abstracted into a class. Each object instance is a member of a class and a class may have multiple instances. In addition to the data and the way in which it is stored, a class also provides storage for the methods that are simply procedures (similar to functions/subroutines in procedural programming) that are shared by all instances of the class and are invoked by sending messages (similar to function/subroutine calls in procedural programming). For example, in the object-oriented world view, adding two numbers such as 2 + 3 is viewed as sending a '+' message from an instance of number class (2) to another instance of number class (3).

Each OOP language must exhibit four characteristics: encapsulation, message passing, inheritance, and dynamic binding. Encapsulation means that data is encapsulated inside an inviolable shell along with the methods required to use it. The only legal way to access the data is through the use of these methods. Message passing is a natural result of encapsulation. Messages are the carriers of all the interactions between objects. Inheritance enables the creation of classes in a hierarchical tree structure, allowing new objects to be specializations of other objects. A new object class can be defined by 'subclassing' an existing class; a subclass in the tree obtains its essential features from its parent class via inheritance but it can also acquire its own characteristics. A new class needs to be specified only by how it differs from an existing class rather than being completely redefined. Dynamic binding is the process of associating the data and the procedure during run time. It means that references are symbolic and a method can be compiled without compiling all of its callers. The same symbolic names can be used regardless of the type of the object, and a single message can invoke several methods. In the OOP environment this is known as polymorphic behavior and it allows code that is written to be independent of the object that will receive the message.

In addition to modularity and natural decomposition advantages, OOP allows simulations to become extensible owing to the ease of adding new classes and entities, [4-6]. Because the objects contain their own functionality, intelligence can be built directly into this functionality by using the techniques of artificial intelligence, [7,8]. Furthermore, this 'intelligence' can be updated through simulated experience that imitates the learning process. Because some objects in simulations are physical and real, the user can often directly translate the model into a graphical and animated simulation without any conceptual changes [9]. The OOP approach also provides a natural basis for concurrent, distributed simulation.

3. Discrete event simulation formalism

Within the context of simulation, formalism refers to structured, symbolic representation of model entities and their interactions. It is based on the notion that a system is a collection of interacting component systems that can be expressed through a hierarchy of system specifications. In the formalism [1], five distinct levels are defined to represent different capabilities and functionalities of system entities. The Source System, SS, represents the facts-based real physical system components and is used to express the physical interactions between the entities. The next level, Data System, DS, is a natural extension of SS and provides the plain data elements by establishing the link between observed facts and available meanings. The Information System, IS, is the next level that utilizes the data created by DS to generate information on a timely basis. At this level, the information created is processed, programmed, and decisions are made and coordinated. The next level, Knowledge based System, KS, provides for the symbolic expression of the knowledge derived from information level entities and supplies real-time knowledge bases for the next level entities. The top level of the hierarchy is the Intelligent System, IN. These are the entities that process the knowledge generated at KS and make non-programmed decisions based on the present state of their own domain and what they perceive about the rest of the system. Although each entity can be independently defined, because each level is hierarchically embedded in the following level; all data, information, and control components are readily accessible by upper-level entities. A set-theory-based symbolic construct is provided for each level to express the structural and behavioral characteristics of generic entities along with the simulation dynamics [2].

4. Software implementation of the formalism

We now discuss issues related to implementation of the formalism. We chose the Smalltalk OOP language because of the application software development power, extensive object library, and the user interface environment that it provided [10,11].

To take full advantage of the inheritance property of OOP, the whole environment is designed around three abstract tree structures SystemStructure, ProductDataBase, and OrderDataBase (bold italic type is used for trees; regular bold type for the levels of the formalism), which are transparent to the user during the simulation. The first tree, SystemStructure, represents the hierarchical configuration of the physical entities of the manufacturing system. These physical entities include machine tools and handling devices, and correspond to the Source System constructs defined in the formalism. The real physical entities form the leaves of this tree. At the next level up, parent-child relationships on the tree define the physical/logical workcenter or manufacturing cell configurations. The following level identifies the way in which workcenters are grouped together to form a department or a shop. The top level in the tree structure, the root, defines the collection of departments or functional units that exist in the manufacturing system, and represents the total system. This configuration allows the modeler to define and conceptualize a system in a simple hierarchical form and sets the foundation for an easy graphical model definition interface. Because the physical and control objects are defined as separate modules, each physical object in the system is in fact a stand-alone object unless linked with an appropriate control (logic) object.

As soon as each physical entity is defined, the software automatically creates the material channel that provides for the material flow between the physical entity and the rest of the physical system. This material channel object corresponds to the material channel constructs defined as part of the Source System of the formalism. These objects provide hard linkage between equipment along with internal material storage and are created with a default material-equipment interaction mechanism.

In addition to the material channel object, the software automatically creates a default control entity for the physical entity and sets up the links between the two. The control entity is where the logic functions are implemented. Each control entity along with its corresponding physical entity, depending on which level it is residing in, implements either the Information System, IS, or the Intelligent System, IN, constructs of the formalism. The system automatically creates a communication channel object for the control object and links them together. This object provides the soft linkage between the control object and the rest of the system and is where the exchange of information and/or knowledge takes place. All of the logical activities take place in control objects and these objects are the driving entities of the simulation model. The other building blocks in the model, such as physical objects, material channel objects, and communication channel objects, support and/or implement the actions of the control entities. The control object classes defined follow the same basic hierarchy given for the physical system configuration and each class has different types of capabilities and functions.

In summary, each node of the SystemStructure tree is built around the physical entity corresponding to that node in the real system, and includes the material channel object and the control object with an attached communication channel. Fig. 1 shows the visual representation of the SystemStructure tree, which is implemented as an instance of the class named SimulationModel. A method defined for the instances of this class is used to construct the tree, and this class is one of the two classes that interact with the graphical model definition interface.

The second set of information that is essential for the proper representation of a manufacturing system is the product information. A class named BOMs that represents the bill of material is implemented for this purpose. The only instance variable, a variable attached to the instances of a class, is the root of an abstract tree called Products that denotes the collection of product structures for the items manufactured in the system. Each child of the root itself is a node that expresses the whole product tree structure for an individual product type. This tree construct is referred to as ProductDataBase and is illustrated in Fig. 2.

The SystemStructure and ProductDataBase trees maintain relatively static information about the configuration of the system under study and the products manufactured in it. To keep track of the dynamic information involved in the simulation, another tree structure is employed. This third tree is a highly dynamic one and frequently manipulated during the simulation. It represents the dynamic database of the whole system where transactions generate new information, delete unnecessary information, or update present information. This data structure, named OrderDataBase, holds all the information relevant to the orders involved in the operation of the manufacturing system, and these orders constitute the major portion of the communication between system entities.

The root of OrderDataBase is implemented as an instance variable of the system control object. This allows the system level control object to easily access most of the dynamic information about the customer and manufacturing orders. The children nodes represent unique customers and in turn each child node of a customer node contains the individual orders of a particular customer. The next level represents the product combinations for each individual customer order. Each product order at this level is also a node and is associated with a small local database that contains information specific to the individual order and product type.

An important aspect of OrderDataBase is that at the beginning of the simulation this is basically an empty tree consisting of nothing but a root linked to the system control object. As the orders arrive to the manufacturing system, the branches and subbranches representing customers, their individual orders, and specific product combinations requested within each order are dynamically created as the simulation progresses. The subsequent levels are also dynamically created from the information stored in ProductDataBase by appropriate level control entities. As soon as a product order is created and added to OrderDataBase, the system control entity, using its knowledge-based decision-making mechanism, decides between releasing or not releasing the order. If the order is released, the shop level control object receiving the order goes through a translation process and creates the required suborders for the product and adds them to the appropriate nodes of OrderDataBase. Thus, the system level control object acts as a gate to control the flow of product orders to shop control entities. Similarly, by deciding on releasing or not releasing the next level of orders, shop level control entities act as suborder flow gates that control the arrival of orders to workcenter control entities. The workcenter control entity receiving the order goes through another translation process to create batch-orders that are released to the lowest level of control, machine control entities, and adds them to the appropriate nodes in OrderDataBase. The batch-orders are analogous to the typical work-orders in a manufacturing system and they contain information on parts, quantities, and due dates. Finally, each machine control entity communicates with its physical machine entity and sends the necessary signals (messages) to perform the manufacturing operation. This is where the real connection from the logical system to the physical system takes place.

As a result of the process described above, as the simulation clock advances, OrderDataBase grows. As the operations are performed, the state of individual product, component, and part orders are updated by the control entities. When the final operation of a product order is completed, the branch originating from that node is pruned and related statistics are updated. This process prevents infinite growth of OrderDataBase. Thus, at any instant before the completion of the final operation of a product order, OrderDataBase can be accessed to inquire about the history and the status of each component and part orders associated with this particular order. Fig. 3 graphically represents the structure of OrderDataBase tree. In Fig. 3, the database associated with each order object contains local information about the order object.

In this implementation scheme, the simulation process can best be visualized in terms of asynchronous waves of messages between the control objects of the SystemStructure hierarchical tree. The downward message wave is triggered by the arrival of a customer. The system level control object translates this event into a set of specific product orders and, using its knowledge base and planning mechanism, decides on what to do with the product orders. A similar process, but with a different context, takes place at shop, workcenter, and machine control objects, and finally the message wave reaches the bottom of the hierarchy, to the physical machine objects. As operations on parts and components are performed at physical machine objects, an upward message wave takes place. This set of messages originates from the physical object and may go sequentially up to workcenter, shop, or system controller level through the hierarchy, depending on the operation performed and the present status of the parts. Fig. 4 summarizes the flow of orders and hierarchical structure of the communication taking place during the simulation.

5. Simulation object classes

This section gives a brief description of some of the classes defined in the Smalltalk implementation of our formalism. These classes implement the formalism and its information/knowledge processing scheme. The simulation control class, Simulate, is defined as a subclass of the class Simulation, where the time advance and event scheduling mechanism is implemented. Similarly, most of the physical and logical entities involved in the manufacturing system simulation are defined as subclasses of the class SimulationObject, where generic objects with tasks to do during the simulation are implemented. Instances of classes Simulation and SimulationObject interact with each other and use the scheduling/object-coordination mechanism provided in Smalltalk by utilizing a set of system library classes. The tree structure below summarizes the hierarchy of the classes defined. The indentations represent class subclass relationships. The class names that end with Phys, Cntrl, and Com are for physical, control, and communication object classes, respectively. Also, the class name CmptOrder is used for component orders, BtchOrder is used for batch-order, and Cstmr is used for Customer. The instances of these classes are the basic building blocks of a simulation model and are automatically created and configured during the model-building process. The subclasses in the tree inherit their basic behavior from their superclasses. The individual tailoring of subclasses is achieved by using the polymorphism property of Smalltalk that allows the same message names to be used by subclasses to implement different behaviors if necessary.

Object Simulation Simulate

SimulationObject SystemPhys ShopPhys WorkCenterPhys MachinePhys SystemCntrl ShopCntrl WorkCenterCntrl MachineCntrl SystemCommunication ShopCom WCCom MachCom MaterialPort ProductOrder CmptOrder BtchOrder Raw Material Cstmr

BOMs SimulationModel IDGenerator QueueStatistics UtilizationStatistics

The next section gives further information on a few selected classes along with their instance variables and message protocols. The instance variables are the variables that define the properties of the instances of each class. The Initialization message protocol is the collection of messages that are used to set the initial values of instance and class variables. The messages in the Accessing message protocol are defined to retrieve and/or change values of the instance and class variables. The messages in the Task Language message protocol are used to implement the behavior of the instances of the class. The messages with a colon require a parameter to pass information to the object receiving the message.

class SystemPhys: instance variables - controller, node, matChannel message protocol Initialization: initialize, controllerEnterSimulation Accessing: controller, getNode, setNode:, materialChannel, checkForMaterial: Task Language: commitMaterial:quantity:, distribute:quanti ties:to:

The instance variables are used to define a link to a controller object, a reference to the node in the System-Structure tree that holds this physical object, and a link to an instance of MaterialPort class. The initialize method is used to create the controller (SystemCntrl) and MaterialPort instance that are associated with the system level physical object. The method named controllerEnterSimulation is used to define the general mechanism by which various levels of controller objects enter the simulation and is inherited by the subclasses of this class. The Accessing protocol holds various types of method to define or change the objects linked with the physical system object. The methods of the Task Language protocol are self-explanatory and are used to perform material control at the system level. The methods here are inherited and used by the subclasses of this class for material transfer between physical machine objects. ShopPhys and WorkCenterPhys objects inherit their basic behavior from this class with some additional methods and features defined specific to their own behavior.

class MachinePhys: instance variables - load, utilization, procsTimeDist, timeToBreak, mttrDist, state message protocol Initialization: initialize Accessing: load, resetLoad, status, utilization Task Language: breakdown, doOperation:, getBatchTime:, load Material:quantity:, loadMaterials:quantities:, operationDone:, performOperationOn:, unloadMaterial:, tasks

The instances of the MachinePhys class are the actual implementors of the manufacturing operations on raw material, parts, and components. The instance variables hold information about the present material object being worked on, present state, and utilization statistics. In addition, the mean time to repair distribution, process time distribution, and time to breakdown information are kept in instance variables. The Accessing protocol defines methods for retrieving the information contained in some of the instance variables. The Task Language protocol implements the physical operations on material. The machine control object issues an activity order, by sending the physical machine object the message 'performOperationOn:'. This message triggers the following ordered set of activities. First, the physical machine object starts with an idle state and loads the material by interacting with its material port. Next, it determines the time required to process the batch by interacting with ProductsDataBase. After updating the time to break it issues a 'doOperation:' command to itself where physical machine state changes, statistical updates, and time delays take place. When a breakdown is encountered, the physical machine object immediately reports the event to its controller, changes its state to broken, and waits until it is repaired. After being repaired, it sets its 'timeToBreak' instance variable to a new value, and completes the remaining part of the operation. The next two steps of the ordered set of activities are unloading the processed material and signaling the transfer of it to its next destination, and reporting to the controller object about the completion of the request.

class SystemCntrl: instance variables - controls, status, database, plan, customers, channel, productConsidered message protocol Initialization: initialize Accessing: controls, customers, database, getDestinationFor:, getPlannedOrders, getReleasedOrders Task Language: askCustomerForOrder:, customerArrival:, getAction:, productDone: readyForAssembly:, release AssemblyOrder:, releaseOrder:, translate:for: Reset KnowledgeBase Interrogator: moreOf:, oneOf:, request: Knowledge Acquisition: customer, product, quantity, shopCapacityStatus, shopLoadStatus, slack, slackMinusLeadTime Planning and Decision: planning:, reviewPlan Action Implementation: putltInPlan, release

All the interaction with the entities that are external to the system takes place at an instance of this class. The communication channel object that is associated with an instance of this class provides inflow and outflow of information to and from the system. The instance variables of the class keep information about the associated physical system object, present status of the entity, its local database and plan, a link to its communication channel, an order currently considered for decision, and a pointer to the root of OrderDataBase.

The only method in the Initialization protocol creates an instance of the SystemCommunication class, establishes the link between two objects, and sets the initial values for instance variables. The methods defined in the Accessing protocol are self-explanatory. Because most of the methods defined in the task language are inherited by the subclasses of this class, they are generic. In addition to creating branches for new customers in OrderDataBase, task language methods initialize the statistics regarding the arrival of customers, add a new node for the customer in OrderDataBase, and start the order translation process, i.e., the breaking of the customer order into specific orders that are represented with new subnodes. The knowledge-based planning mechanism is activated by using the 'getAction:' method to make decisions about this new set of product orders. This implementation style is based on the simulation dynamics of the formalism in terms of making decisions by using present internal and perceived external states in real time.

We used the Smalltalk-based Humble [12] inference engine to implement the knowledge-based decision-making mechanism. In the usual object-oriented style, entities about which the system will make inferences are grouped into categories called entity types and are characterized by parameters. In addition to parameters, an entity can hold other entities with their own sets of parameters and subentities. Every parameter in a knowledge base can contain data which is uncertain, expressed by an attached certainty value between -1.0 and 1.0. A 1.0 indicates absolute certainty that the value is the correct one, and a -1.0 indicates that the value is not the correct one. A 0.0 indicates a complete lack of knowledge. The system supports the ability to have several different potential values for each parameter in the fact base simultaneously. Each of these potential values is referred to as a hypothesis.

The interaction between the intelligent simulation object and the knowledge base takes place as follows: when a controller object needs to make a non-programmed decision, it triggers the method called 'getAction:' from its task language protocol. The system, shop, and work-center control entities overwrite this method, thereby allowing the use of their own knowledge base at each level. The method 'getAction:' initializes the requested knowledge base entities; in other words, it resets the knowledge base's facts by initializing the values of the parameters. This is necessary because each knowledge base retains its most recent facts, and during simulation each time a knowledge base is consulted by a control object, knowledge (facts) is dynamically acquired from the executing simulation model and must not contain values from a previous consultation. Thus, each consulting object needs to dynamically acquire its own domain-specific knowledge during the interaction. The control object next sets itself as the interrogator of the knowledge base. This allows the simulation object to query the knowledge base; conclusions drawn are sent back to the simulation object.

After the link is established, the control object triggers the interrogation process by sending a 'findOut:' message (provided in Humble) to the knowledge base with parameter 'action' being the argument. The knowledge base tries to determine a value (a proposed action) for the parameter by using its backward chaining mechanism. During this process, as the values of parameters in the knowledge base such as shop or equipment status are required in one of the activated rules, the knowledge base automatically asks back to the interrogating control object to acquire this piece of information for it. The control object in turn uses the appropriate method defined in its knowledge acquisition protocol to retrieve real-time data, processes that data, creates the knowledge, and returns it to the knowledge base. During data retrieval, the control object may interact with the subordinate level entities to extract the necessary data. This process is repeated for every piece of on-line knowledge acquired and may require heavy interaction between the knowledge base and the interrogating control entity. Because of the uncertainty property, there may be more than one value qualified for the parameter 'action'. Among all qualified values, the one associated with the highest certainty value is returned by the knowledge base as the action that needs to be taken by the control object.

When the concluded action is passed back, the control object implements the returned action by the appropriate method defined in its action implementation protocol. This corresponds to 'update internal status' and 'update external status' functions of the formalism and reflects the effects of the action taken. This whole process described above is repeated each time a knowledge base is interrogated by one of the control objects. Currently, only two types of action regarding the orders are implemented. These actions are referred to as 'release' and 'putItInPlan' and are self-explanatory. If an order is put in the plan where orders are scheduled according to a set of rules, it will be re-evaluated at a later time. If the decision is to release the product order, the system controller changes the status of the order, creates a ProductOrder object, defines its content, requests its physical counterpart to distribute the committed material to appropriate physical machine objects, and enters a new ProductOrder object into the simulation. Then the system controller object goes through its plan and re-evaluates product orders against the changed system state and time.

The other methods defined for the Task Language protocol of the SystemCntrl class are used to process the progress reports received from shop level control entities. The methods defined in other message protocols are designed to execute the knowledge-based decision-making mechanism and to implement the resulting actions. Classes ShopCntrl and WorkCenterCntrl reimplement some of the methods defined in their superclass within the context of their own domain. Some of these methods are designed to operate recursively to explore the components/parts of a product structure tree. The mechanics of the planning process in these classes are very similar to the system level control entity, the major differences being the type of knowledge acquired and the different knowledge base used by the inference mechanism. The simulation real-time knowledge used at this level is basically about the load and capacity status of the entities controlled by the object and what is known about the rest of the system. The communication channel object instances associated with each control entity continuously monitor the release of relevant orders from upper-level control objects by using Smalltalk's non-busy wait mechanism. The other methods of the class SystemCntrl are mostly self-explanatory, such as 'askCustomerForOrder:' for interacting with an instance of class customer to inquire about a customer order, 'releaseOrder:' for creating and releasing an instance of the appropriate class defined for orders, 'shopCapacityStatus' for asking the appropriate shop control instance about the present shop capacity status, 'planning:' to trigger the planning process, and 'putItInPlan' for inserting the order instance object in an ordered list called plan.

The following is a brief description of the MachineCntrl class that implements the bottom layer of the control hierarchy. Each instance of this class is linked to an instance of a MachinePhys class.

class MachineCntrl: instance variables - none message protocol Initialization: initialize Accessing: status Task Language: orderArrival:, reportBreakdown, tasks, translate:

The instances of this class provide the link from upper-level intelligent control entities to data-driven information entities of the formalism. The functions of a machine control object are to receive batch orders from its superior workcenter control object and check for material availability by indirectly interacting with the material port that is linked to the physical machine object. These objects also issue requests to their physical counterparts to trigger a set of ordered actions that are implemented in the machine physical objects for performing and monitoring the requested operations.

The instances of class Cstmr hold information on the products desired, their due dates and quantities. The initialize instance method sets up the values for customer and order properties from the theoretical/empirical probability distributions provided by the modeler. The RawMaterial class provides the material objects flowing through the physical system. As soon as instances of these subclasses are entered into the simulation, they coordinate with the material port object of the system physical object.

The following general procedure in Smalltalk is used to invoke the simulation process:

* Set up the random number seeds of the several distributions defined for class Cstmr.

* Create an instance of class Simulate and send the message 'startUp'. This instance is the object where the simulation processing takes place.

* Create a new instance of class BOMs. The method 'defineProducts' of this class creates the user-defined product structure trees for the products manufactured in the system.

* Create an instance of class SimulationModel and invoke the method 'defineModel' to generate the desired SystemStructure tree to express the configuration of the physical entities of the system.

* Declare the file names and paths for printing the standard reports on utilization, queue, and order statistics.

* Specify a termination time or condition. The simulation immediately starts monitoring the clock or the conditions against the specified values. As long as the simulation clock is less than the termination time or the termination conditions are not met, the objects created interact and the simulation proceeds.

6. Experimentation and conclusion

We define an example make-to-order manufacturing system that consists of two shops, three workcenters, five machines, and two product trees. We modeled and simulated this system by using the developed environment and the modeling methodology dictated by the formalism. Three different classes of rule-based knowledge system corresponding to system, shop, and workcenter level planning are designed. The rules are defined assuming a moving fixed-length time frame (a different length for each class) that dynamically evaluates the status, capacity, and load of a controller's domain. The systemPlanning knowledge base uses the order size, product type, and unique customer identification to derive the importance of the order. Next, it assesses the order timing priority by using the order importance, lead time, and slack time information. Then it obtains the shop capacity and load status and evaluates through a set of rules to find the best action at that particular time. The conversion of analytical data regarding the load and capacity status takes place as follows: the load of a particular shop at that instant of time is retrieved and divided by the fixed time window length. Depending on which of the several defined regions this ratio falls, one of the possible symbolic values such as 'veryheavy' or, 'heavy', is returned to the knowledge base. A symbolic value for the shop capacity status is determined by using the simple ratio of number of operational machines in the shop at that instant to the total number of machines. The other knowledge bases shopPlanning and workCenterPlanning deal with component and batch orders, respectively, and their main design principles are similar to the those in the systemPlanning knowledge base.

We define the following four experimental levels for the example manufacturing system.

1. System without non-programmed control. In this scheme, the orders at all control levels are translated to suborders and immediately released to the next level. The orders mostly accumulate at the machine control level where they are processed according to FIFO or shortest processing time.

2. Only system level non-programmed control is employed. The release of product orders to the shop level is controlled by the system controller using the systemPlanning knowledge base. Each time a new customer order arrives or a product is completed, the knowledge base evaluates all the orders not yet released (including the new arrivals) starting with the earliest due date order. The lower level controls are not changed and they still use FIFO or shortest processing time.

3. System and shop level control both use their knowledge bases simultaneously to employ non-programmed control. Similarly to system controller, shop controller activates its knowledge base each time a product order is released or a component is completed. The component orders are evaluated starting with the one with the earliest due date.

4. System, shop, and workcenter control all employ their knowledge bases simultaneously. Similarly to system and shop controllers, the workcenter consults its knowledge base each time a component order is released or a batch-order is completed. The batch-orders are also evaluated according to their due dates. Additionally, the knowledge base of workcenter control prioritizes the assembly and processing operations for each machine controller.

The main idea behind the defined knowledge bases and the experimental levels is to perform a tighter timing and non-programmed control around different types of orders as they move downward in the hierarchy. Five replications are made for each level. Common random number seeds are used to induce a positive covariance, thereby reducing the variance during pairwise comparison of the differences between system performance. We utilize a performance measure called manufacturing velocity, which represents the time between the release of a product order by the system level controller and completion of the order. A set of additional measures such as order lateness and customer response time, along with utilizations and queue statistics, are obtained and investigated for each run for multidimensional analysis of the performance. The random number seeds are changed between replications but kept the same across the levels. The pairwise statistical analysis of the simulation output yielded the following.

It is concluded that the manufacturing system under study performs best when knowledge-based control is employed at all levels of the control hierarchy. It is also clear that non-programmed system level control provides better results than the system with no knowledge-based control. In contrast, the benefits of adding a knowledge-based control at the shop level cannot be clearly observed from the main statistics of interest and usual statistics of simulation. However, one should keep in mind that the shop control knowledge bases defined in this example are relatively simple and system performance depends heavily on the policies employed in the knowledge bases of various levels. A more elaborate non-programmed control scheme for shop level control may yield a different conclusion. We plan to conduct other possible experiments, such as employing only shop or workcenter level knowledge bases or other combinations to see the synergistic and/or standalone effects of the knowledge bases.

The simulation environment developed, despite being a prototype, has proved to be useful in expressing simulation models in detail and different aspects that are not possible with conventional modeling approaches. The object-oriented approach, from conceptualization to modeling, has established itself as being very useful in expressing system entities and their behaviors. In this new environment, conceptualization of a manufacturing system first in terms of hierarchical physical components, then a set of modular control structures attached to those physical components according to the constructs of the formalism, reduced the required modeling effort significantly.

References

[1] Karacal, S.C. and Mize, J.H. (1997) A formal structure for discrete event simulation. I.: formalism for modeling multiple level systems. IIE Transactions, 28 (9), 753-760.

[2] Karacal, S.C. (1991) The development of an integrative structure for discrete event simulation, object oriented modeling, and embedded decision processes. Ph.D. Dissertation, School of Industrial Engineering and Management, Oklahoma State University, Stillwater, OK.

[3] Cox, B. (1986) Object Oriented Programming: An Evolutionary Approach. Addison-Wesley, Reading, MA.

[4] Luna, J.J. (1992) Hierarchical, modular concepts applied to an object-oriented simulation model development environment, in Proceedings of the 1992 Winter Simulation Conference, Arlington, VA, pp. 694-699.

[5] Thomas, C. (1993) Hierarchical object nets - a methodology for graphical modeling of discrete event systems, in Proceedings of the 1993 Winter Simulation Conference, pp. 650-556.

[6] Zeigler, B.P. (1987) Hierarchical, modular discrete-event modeling in an object-oriented environment. Simulation, 49 (5), 219-230.

[7] Burns, J.R. and Morgeson, J.D. (1988) An object-oriented worldview for intelligent, discrete next-event simulation. Management Science. 34, 1425-1440.

[8] Doman, A. (1988) Object-Prolog: dynamic object-oriented representation of knowledge, in Artificial Intelligence and Simulation: The Diversity of Applications, in The Society for Computer Simulation, San Diego. CA.

[9] Thomasma, T. and Ulgen, O.M. (1987) Modeling of a manufacturing cell using a graphical simulation system based on Smalltalk-80, in Proceedings of the 1987 Winter Simulation Conference, Atlanta, GA, pp. 683-691.

[10] Goldberg, A. and Robson, D. (1989) SMALLTALK-80: The Language and Its Implementation, Addison-Wesley, Reading, MA.

[11] Object Works/SmallTalk User's Guide, (1992) Parcplace Systems, Sunnyvale, CA.

[12] Xerox Special Information Systems (1987) Humble Reference Manual, Xerox Corporation.

Biographies

S. Cem Karacal is an Assistant Professor of Industrial Engineering at Southern Illinois University at Edwardsville. He received his B.S. degree in IE from Middle East Technical University, Ankara, Turkey, in 1982, and M.S. and Ph.D. degrees in Industrial Engineering from Oklahoma State University in 1986 and 1990, respectively. He has four years of experience in academia, industry and consulting. His primary areas of interest are object-oriented modeling, AI applications in simulation, and semiconductor manufacturing scheduling. He is a member of IIE, Alpha Pi Mu and Tau Beta Pi.

Joe H. Mize, Regents Professor of Industrial Engineering at Oklahoma State University, has over 30 years, experience in academia and industry. He is the author or co-author of six engineering text books, and has edited over 90 engineering texts. He has also authored or co-authored over 60 technical articles. He is Past President of the Institute of Industrial Engineers, and is a Fellow of lie and the Institute of Production Engineers. He is a member of the National Academy of Engineering and in 1990 received the Frank and Lillian Gilbreth Industrial Engineering Award from IIE.