Modeling and Specifications of Dynamic Agents in Fractal ... - CiteSeerX

Modeling and Specifications of Dynamic Agents in Fractal Manufacturing Systems Kwangyeol Ryua, Youngjun Sonb, and Mooyoung Junga a

Department of Industrial Engineering, Pohang University of Science & Technology, Pohang, Korea b

Systems and Industrial Engineering Department, The University of Arizona, Tucson, AZ, USA ABSTRACT In order to respond to a rapidly changing manufacturing environment and market, manufacturing

systems must be flexible, adaptable, and reusable. The fractal manufacturing system (FrMS) is one of the new manufacturing paradigms that address the need for these characteristics. The FrMS is comprised of a number of “basic components”, each of which consists of five functional modules: 1) an observer, 2) an analyzer, 3) an organizer, 4) a resolver, and 5) a reporter. Each of these modules, using agent technology, autonomously cooperates and negotiates with others while processing its own jobs. The resulting architecture has a high degree of self-similarity, one of the main characteristics of a fractal. Despite the many conceptual advantages of the FrMS, it has not been successfully elaborated and implemented to date because of the difficulties involved in doing so. In this paper, the static functions and dynamic activities of each agent are modeled using the unified modeling language (UML). Then, relationships among agents, working mechanisms of each agent, and several fractal-specific characteristics (self-similarity, self-organization, and goal-orientation) are modeled using the UML. Then, a method for dealing with several types of information such as products, orders, and resources in the FrMS is presented. Finally, a preliminary prototype for the FrMS using AgletsTM is presented. Keywords: Fractal manufacturing system (FrMS), Agent technology, UML, Modeling, Dynamic agent 1. Introduction Facing intensified competition in a growing global market, manufacturing enterprises have been reengineering their production systems to achieve computer integrated manufacturing (CIM). Major goals of CIM include, but are not necessarily limited to, lowering manufacturing costs, rapidly responding to changing customer demands, shortening lead times, and increasing the quality of products [1,2,3]. However, the development of a CIM system is an incredibly complex activity, and the evolution to CIM has been slower than expected [4,5]. This can be directly attributed to high software development and maintenance costs. Therefore, in order to achieve a competitive advantage in the turbulent global market, the manufacturing enterprise must change manufacturing processes from all angles including ordering, product design, process planning, production, sales, etc. As a control model for implementing CIM systems, hierarchical decomposition of shop floor activities has been commonly used in the shop floor control system (SFCS), the central part of a CIM system [2]. Generally, a central database provides a global view of the overall system, and controllers generate schedules and execute them. Hierarchical control is easy to understand and is less redundant than other

1

distributed control architectures such as heterarchical control. However, it has a crucial weak point, which is that a small change in one level may significantly and adversely affect the other levels in the hierarchy. Therefore, it is normally said that hierarchical control of CIM systems is much more suitable for production in a steady environment than in a dynamically changing environment because it is so difficult to apply control hierarchy changes immediately to the equipment. Furthermore, it is difficult to meet dynamically changing customer requirements because the hierarchical control architecture is not flexible enough to handle the reconfiguration of the shop. Therefore, the manufacturing system of tomorrow should be flexible, highly reconfigurable, and easily adaptable to the dynamic environment. Furthermore, it should be an intelligent, autonomous, and distributed system composed of independent functional modules. To cope with these requirements, new manufacturing paradigms such as a bionic manufacturing system (BMS) [6,7], a holonic manufacturing system (HMS) [8,9], and a fractal manufacturing system (FrMS) [10,11,12,13] have been proposed. Tharumarajah et al. [14] provides a comprehensive comparison among a BMS, a HMS, and an FrMS in terms of design and operational features. An FrMS is a new manufacturing concept derived from the fractal factory introduced by Warnecke [13]. It is based on the concept of autonomously cooperating multi-agents referred to as fractals. The basic component of the FrMS, referred to as a basic fractal unit (BFU) , consists of five functional modules including an observer, an analyzer, a resolver, an organizer, and a reporter [10,11]. The fractal architectural model represents a hierarchical structure built from the elements of a BFU, and the design of a basic unit incorporates a set of pertinent attributes that can fully represent any level in the hierarchy [12]. In other words, the term ‘fractal’ can represent an entire manufacturing shop at the highest level or a physical machine at the bottom level. Each BFU provides services according to an individual-level goal and acts independently while attempting to achieve the shop-level goal. An FrMS has many advantages for a distributed and dynamic manufacturing environment. Automatic reconfiguration of a system through a dynamic restructuring process (DRP) is the most distinctive characteristic of the FrMS. In this paper, the scope of the reconfiguration does not include reconfigurable hardware [15] and layout design. Rather, it focuses on the structure of software components that can be reorganized with software manipulations. The reconfiguration or restructuring in this paper considers both dynamic clustering of the agents and construction/destruction/cloning of agents, which affect the number of agents in the system. The function of a fractal is not specifically designated at the time of its first installation in the FrMS. The reconfiguration addressed in this paper also includes situations where the agents’ enrollments are changed, meaning that the agents are assigned a new goal and new jobs, but their composition does not change. This paper focuses on formal modeling of agents and fractal-specific characteristics that will provide a foundation for the development of the FrMS. Because associated difficulties have, to date, prevented a fractal-based system from being embodied, it is necessary to first explicitly define a concept, mechanisms, and characteristics. The objective of this paper, therefore, is to clearly define and model fractalspecific characteristics in order to enable a manufacturing system to have such characteristics. In order to

2

develop the agents, inter- and intra-fractal activities are first clarified. Then, dynamic activities for each agent and relationships between agents are modeled. In order to more fully develop the FrMS, several fractalspecific characteristics are also modeled. To support embodiment of modeled characteristics, a method for dealing with information about products, orders, and resources in the FrMS is investigated. Through this research, mechanisms of agents and characteristics of the FrMS can be described with simple diagrams that make the system easier to understand. The work contained in this paper extends the FrMS from previous papers by emphasizing and detailing its characteristics. The activities of agents are specified using activity models so that the agents can use the activity models to forecast their next activities at run-time. The rest of this paper is organized as follows: Section 2 describes functions and dynamic activities of agents using functional and activity models of Unified Modeling Language (UML). In Section 3, inter- and intra-fractal activities are specified. Several fractal-specific characteristics are described using UML models in Section 4. Section 5 describes a method for dealing with information about products and resources in the FrMS. Section 6 concludes the paper. 2. Agent-based Fractal Manufacturing System (FrMS) 2.1 Background of an FrMS Fig. 1 depicts the overview of the Fractal Manufacturing System (FrMS). Every controller at every level in the system has a self-similar functional structure composed of an observer, an analyzer, a resolver, an organizer, and a reporter. In addition, each of these modules, regardless of it hierarchical level, consists of a set of agents. After the initial setup of a system, the configuration of the system may need to be reorganized in response to unexpected events such as machine breakdown. The system will also need to be reconfigured when the set of parts to be produced in the system changes due to a change in customer needs. In these cases, fractals in the FrMS autonomously and dynamically change their structure, via the actions of agents for the appropriate working mechanisms of the fractals. Fig. 1 shows two facility layouts and the corresponding compositions of fractals before and after the restructuring process. When a machine (M) and a robot (R3) are added to the system, fractals reorganize themselves with the mechanism of dynamic restructuring process (DRP) in a way that the system continues to work with greatest efficiency. [Insert Figure 1 about here] A fractal consists of five functional modules including an observer, an analyzer, a resolver, an organizer, and a reporter. Functional modules and their relationships in a fractal are illustrated in Fig. 2. The functions of each module can be defined depending upon the application domain. However, when the target domain is determined, the main functions of each module will be consistent throughout the system. For example, the function of a resolver may be different depending upon whether it is defined for controlling a manufacturing system or for managing supply chains. However, the main function of a resolver in a manufacturing system is similar to other resolvers in that system regardless of their level in the hierarchy. Fig.

3

2 shows a bottom-level fractal whose functions are similar to those of a conventional equipment controller in a SFCS. The fractal directly connected to equipment (e.g., machine, robot, etc.) gets sensory signals from equipment and sends messages or commands to them. [Insert Figure 2 about here] The function of an observer is to monitor the state of the unit, to receive messages and information from outer fractals, and to transmit composite information to correspondent fractals. The function of an analyzer is to analyze alternative job profiles with status information, to rate dispatching rules, and to simulate analyzed job profiles in real-time. The analyzer finally reports results to the resolver so that the resolver can use them to make decisions. A resolver plays the most important role in a fractal, generating job profiles, goalformation processes, and decision-making processes. During goal-formation processes, the resolver may employ a variety of numerical optimization or heuristic techniques to optimize the fractal’s goal. If necessary, the resolver executes negotiations, cooperation, and coordination among fractals. The function of an organizer is to manage the fractal status and fractal addresses, particularly for dynamic restructuring processes. The organizer may use numerical optimization techniques to find an optimal configuration while reconfiguring fractals. The fractal status is used to select the best job profile among several alternatives, and the fractal address is used to find the physical address of the fractal (e.g., machine_name, port_number, etc.) on the network. The function of a reporter is to report results from all processes in a fractal to others. In the case of a bottom-level controller, the fractal is similar to a traditional equipment controller. Therefore, most of its messages are commands for controlling the hardware. 2.2 Agents in an FrMS Agent technology has been widely used for various applications including information filtering and gathering [16], knowledge management [17], supply chain management [18], manufacturing architecture, system and design [19,20,21]. While the features and characteristics of an agent vary depending on the application, some common features found across different applications are as follows: • Autonomy: capability of moving and acting for itself in order to achieve goals, • Mobility: capability of migrating its location to other places, (an agent with mobility is called a mobile agent, otherwise known as a software agent) • Intelligence: capability of learning and solving problems, • Cooperativeness: capability of helping others if requested, • Adaptability: capability of being effectively used at various domains, • Reliability: capability of dealing with unknown situations (disturbances) and continuing actions if committed, etc.

4

The mobility of agents is a useful feature in a distributed and dynamic system. A mobile agent is not bound to the system where it begins execution. It can travel freely among the controllers in a network and transport itself from one system in a network to another. The following are some advantages of the use of mobile agents in a system [22]; 1) it reduces the network load, 2) it overcomes network latency, 3) it encapsulates protocols, 4) it executes asynchronously and autonomously, 5) it adapts dynamically, 6) it is naturally heterogeneous, and 7) it is robust and fault-tolerant. The types and functions of agents that implement functional modules of an FrMS have been briefly described, and their initial development has been published in the earlier literature [11]. This paper enhances and refines the previously defined types and functions of agents so that they can perform functions of fractals successfully in the system. The names, types, and functions of agents in the FrMS are described as follows. The terms “-M” and “-S” written after the abbreviated name of each agent represent mobile agents and software agents respectively. 2.2.1 Agents for an Observer • Network Monitoring Agent (NMA-S): it monitors messages from other fractals through TCP/IP. It receives messages from the upper/same/lower-level fractals, such as requests for negotiations, negotiation replies, job orders, status information, etc. The NMA delivers those messages to the resolver or the analyzer. • Equipment Monitoring Agent (EMA-S): it monitors messages directly coming from equipment through a serial communication protocol such as RS232/422. Information on the status of equipment including signals indicating the start and completion of jobs are detected by the EMA. However, the fractal need not directly control equipment if it is not included in a bottom level. 2.2.2 Agents for an Analyzer • Schedule Evaluation Agent (SEA-S): A SEA evaluates job profiles generated by the resolver. It helps the resolver to select the best job profile with respect to the current situation of the fractal. • Dispatching-rule Rating Agent (DRA-S): It chooses the best dispatching rule for achieving its goals among several rules, such as shortest processing time (SPT), earliest due date (EDD), and so on. • Real-time Simulation Agent (RSA-S): It performs real-time simulations in the on-line state with the results of the analyzed job profiles and the best dispatching rule. The RSA reports the results of simulations to the resolver. 2.2.3 Agents for a Resolver • Schedule Generation Agent (SGA-M): It generates operational commands or alternative job profiles for achieving the fractal’s goals. After evaluation and analysis of alternatives in the analyzer, the SGA selects the best job profile. It must have mobility in order to use SEA, DRA, and RSA in the analyzer.

5

• Goal Formation Agent (GFA-S): It modifies incomplete goals delivered from the upper-level fractal, and tries to make the goals complete by considering the current situation of the fractal. GFA divides the goal of the fractal into several sub-goals, and sends them to the sub-fractals. • Task Governing Agent (TGA-S): A TGA generates tasks from the best job profile and its goals. It also performs tasks after arriving at the target fractal. When it finishes performing tasks, it sends acknowledgement to its sender. • Negotiation Agent (NEA-M): It moves to other fractals to deliver negotiation messages or to gather negotiation replies created by participating agents. It filters out unreasonable replies by a pre-evaluation process and brings the rest back to the resolver. • Knowledge Database Agent (KDA-M): KDA invokes knowledge data from the knowledge database to make decisions. It accumulates new knowledge or updates the existing knowledge. • Decision-Making Agent (DMA-S): It performs several operations during the decision-making processes. A DMA creates NEAs to negotiate with other fractals and KDAs to use the knowledge database. After making decisions, the DMA generates several TGAs. Further, the DMA provides a context to agents for negotiation. 2.2.4 Agents for an Organizer • Fractal Status Manager (FSM-S): The FSM collects and manages the information on the status of fractals that is used for analyzing job profiles in the analyzer. It also makes negotiation replies to the status requests from other fractals. • Fractal Address Manager (FAM-S): The FAM manages information about the addresses of fractals in lower levels and at the same level. A fractal address is the fractal’s physical address on the network, such as an IP address. The reporter uses a fractal’s address to confirm the destination of tasks and messages. • Restructuring Agent (REA-M): It performs several operations related to dynamic restructuring processes, such as BFU generation, BFU deletion, and the evaluation of the fractal’s performance. The performance of a fractal is its utilization, e.g., total number of processed jobs or the portion of processing time within total time, etc. If the REA decides that a fractal needs to be restructured, it gathers information about fractal and network addresses, and fractal status. It moves to the DMA and lets it generate a series of jobs for a restructuring process. The cloning mechanism is used to create a new BFU. After creation, the REA tells the FAM to update the addresses of other fractals. 2.2.5 Agents for a Reporter • Network Command Agent (NCA-M): All tasks or messages are delivered to other fractals by the NCA. NCA gets the network address of the destination from the FAM and notifies the TGAs and NEAs of it before starting to migrate to other places to comply with the traveling list. • Equipment Command Agent (ECA-S): When ECA gets tasks for controlling equipment from a TGA, it specifies or divides the tasks into several commands that can be accepted and performed by the

6

equipment. Then it sends the machine commands to the equipment. Like the EMA, the ECA is not needed for a fractal at the bottom level. In addition to the five functional agents, several other agents are needed for components to function like fractals. 2.2.6 Miscellaneous Agents • System Agent (STA-S): It manages device hardware and basic operating systems of physical controllers. It maintains the specifications of controllers so that REA can find the proper specification for a new controller which has to be set up as a fractal among available candidates during dynamic restructuring processes. It can also help to copy agents by doing preparation work such as making directories or installing device drivers by giving notice to an installer about software for equipment. • Network Agent (NTA-S): It manages the network addresses of the unassigned controllers in the system. If the system needs more controllers during the restructuring process, the REA confirms the information about the unassigned controllers from the NTA before cloning agents. When a fractal changes the information about the unassigned controllers, it must notify other fractals so that they can update their information. 2.3 Agent modeling with UML To make system architecture manageable and understandable, the artifacts of a system-intensive process can be expressed, specified, visualized, constructed, and documented. In recent years, a unified modeling language (UML) has emerged from earlier methods for analysis and design of object-oriented systems. In 1997, UML became recognized and accepted as a potential notation standard by Object Management Group (OMG) for modeling multiple perspectives of various systems [23]. UML is a simple, expressive, extensible, and visual modeling language [24]. UML is based on the object-oriented paradigm, and enables the extraction of architecturally significant elements of a model with respect to different viewpoints, independent of the system’s scale. It is mainly used to develop control software because many UML tools support the automatic generation of programming code from UML models. In this paper, modeling of the FrMS with UML is based on the implementation of an agent-based system. 2.3.1 Why UML? UML provides several advantageous features for modeling a system [25]. First, it enables modeling of systems using OO (Object-Oriented) concepts because its semantics come from Booch, OMT (Object Modeling Technique), and OOSE (Object-Oriented Software Engineering). In particular, the use of a “package” supporting OO concepts allows users to refine models iteratively. Second, it unifies several modeling perspectives, enabling modeling of different kinds of systems (business versus software) and

7

different development phases (requirements analysis, design, and implementation). Various kinds of models from different perspectives can be easily managed with one file. Third, many UML tools automatically generate skeleton source code from a model. For example, Rational RoseTM supports code generation in C/C++, Visual Basic, Java/J2EE, Ada 83/95. It also supports XML_DTD (eXtensible Markup Language_Data Type Definition) and CORBA (Common Object Request Broker Architecture). Fourth, UML supports the use of a formal constraint language called OCL (Object Constraint Language) to specify constraints and other expressions attached to the models. OCL is a formal language that remains easy to read and write for adding unambiguous constraints to a model. The last advantage of UML is that it supports MDA (Model Driven Architecture) which is accepted as a standard by OMG. MDA addresses the complete life cycle of designing, deploying, integrating, and managing applications as well as data using open standards. It also provides an open, vendor-neutral approach to the challenge of interoperability. 2.3.2 UML models for an FrMS and agents Fig. 3 shows the class diagram of fractal agents. A class diagram describes the types of objects that are used within an object-oriented system, and defines the types of relationships between them. Attributes and operations of each class are used to define the types of objects and the constraints between them. Four types of relationships available in the class model of UML are association, aggregation, generalization, and dependency (instantiates). The class diagram for fractal agents in Fig. 3 uses only associations (uni- and bidirectional) and dependency. An association relationship, the most general relationship, provides a pathway for the communication between classes or interfaces. A dependency is a relationship between two classes in which a change to one class will affect the other class. Stereotypes are usually used in UML models for representing the sub-classification of model elements. In addition to the predefined stereotypes, users can define customized stereotypes. Some classes in Fig. 3 have a stereotype called an entity, which is represented as an icon (circle with under-bar). Also, some other stereotypes are used such as uses, creates, and supports and so on for the clarification of the associations between the classes. Additionally, multiplicity values are usually used to indicate how many objects or classes may participate in a given relationship. For example, the uni-directional association between the DMA (Decision-making Agent) and the TGA (Task Governing Agent) has the stereotype of creates and two multiplicity values: 1 and 1..*. It means that one DMA class can create more than one TGA class (the asterisk value represents any positive integer value). To simplify the class diagram, the attributes and operations of the classes are omitted in Fig. 3. Also, several other agents necessary for the FrMS are omitted to focus on the relationships between fractal agents. One of these classes (DMA) will be explained in great detail later in this paper. [Insert Figure 3 about here] Each agent in a fractal has been modeled with a class diagram and an activity diagram. An activity diagram is used for defining specific activities and state transitions for classes. Fig. 4 illustrates the class

8

diagram of the DMA, one of the agents in the resolver. Compared with the simplified version in Fig. 3, there are a few additional classes in Fig. 4, including the status information class, goals class, fractal performance evaluator class, and decision-making rule class. [Insert Figure 4 about here] The activities and transitions of the states of the DMA are modeled via the activity diagram in Fig. 5. A rectangle with rounded ends is used to define an activity or a behavior of an object; a rounded rectangle is used to represent a state of an object in the activity diagram; and a diamond is used when a decision is needed. Transitions between actions or states are represented as an arrow. Transitions may have events, a stereotype, arguments, conditions, and actions with such UML syntax as “event(args)[condition] : Action”. Transitions can be split by the decision and the applicable conditions. For example, in the case of the DMA (see Fig. 5), the next activity after executing the “Get input” activity can be one of six actions depending on the input received. Note that, as shown in Table 1, some conditions are represented by symbolic values (c0, c1, …, c8) to simplify the diagram. indicates that one of a, b, or c is a prerequisite flow for the condition, and [a] means that the condition cannot be applicable after a. Other logic (activities, states, decisions, and transitions) in Fig. 5 can be inferred from the English in the Fig.. [Insert Figure 5 about here] [Insert Table 1 about here] 3. Activities of Agents in the FrMS In the FrMS, agents handle all processes and jobs without human intervention. Some activities are processed within the fractal, while other activities require cooperation with other agents that exist in another fractal. Activities of agents are classified into two categories: intra-fractal activity (the activities that are processed in one fractal) and inter-fractal activity (the activities that are processed by the cooperation of several fractals). Fig. 6 summarizes the classification of activities of agents in the FrMS. Most fractal-specific characteristics are related to inter-fractal activities such as negotiation, goal-orientation, and the dynamic restructuring process. [Insert Figure 6 about here] 3.1 Intra-fractal activity In order to control an FrMS, agents are involved in processing jobs with their specific roles. The

9

activities of agents that are performed within a fractal are similar to those of other manufacturing systems including input/output control, scheduling, task generation, simulation, performance of tasks, and equipment control. Inputs from other fractals and equipment are controlled by the NMA (Network Monitoring Agent) and EMA (Equipment Monitoring Agent), respectively. Many agents must cooperate for scheduling activities. The agents dealing with scheduling processes include 1) SEA (Schedule Evaluation Agent), DRA (Dispatching-rule Rating Agent), and RSA (Real-time Simulation Agent) in an analyzer, 2) TGA (Task Governing Agent) and DMA (Decision-making Agent) in a resolver, and 3) FSM (Fractal Status Manager) in an organizer. The DMA first creates the alternative job profiles, and the SEA evaluates them. After the DRA selects the best dispatching rule with respect to the status and goals of the fractal, the RSA scores the evaluated job profiles using real-time simulation. The DMA gets the results of the simulation from the RSA to generate TGAs. If a negotiation with other fractals is needed during the scheduling process, the DMA creates NEAs to gather the necessary information. After completing the schedule, each TGA generates tasks. Regarding the management of information, the FSM (Fractal Status Manager) manages fractal status information, the FAM (Fractal Address Manager) manages fractal addresses, and the STA (System Agent) keeps the specifications of controllers. The task executor in each TGA (Task Governing Agent) accomplishes tasks assigned to a particular fractal. The DMA (Decision Making Agent) interacts with a knowledge database and uses queried knowledge to make decisions by creating KDAs (Knowledge Database Agents). A fractal has an EMA (Equipment Monitoring Agent) and an ECA (Equipment Command Agent) to control the equipment in the system. The EMA monitors sensory signals from equipment and the ECA sends commands made by the TGA to the equipment. 3.2 Inter-fractal activity A negotiation between fractals is the most important process in an FrMS because it is essential in order for the agents to make decisions and to process jobs autonomously and coherently. NEA (Negotiation Agent) is in charge of negotiation, which is created by DMA. To impose a negotiation ability on agents, the contract net protocol (CNP) proposed by Smith [26] is still widely used. However, the CNP is expensive in terms of network bandwidth when the negotiation process implies a heavy communication load. For this reason, the negotiation process in this paper follows the MANPro introduced by Shin et al. [27]. The MANPro applies the mobility and the cloning mechanism of an agent. The greatest advantage of the MANPro is the reduction of the network loads without disturbing the application process. As illustrated in Fig. 7, the communication loads between controllers can burden the system when the CNP-based negotiation is used. This is because the connections between controllers must be maintained at all times. On the other hand, the MANPro-based negotiation generates network loads only when an agent moves from the issuer to the participants. Therefore, it can eliminate the extra network operations in which agents have to monitor communication messages. While all communications between controllers are executed globally in the CNPbased negotiation, they can be performed locally without using network resources in the MANPro-based

10

negotiation. Performing negotiations locally can reduce the number of network messages (e.g. acknowledgments). The MANPro-based negotiation, therefore, is more beneficial for negotiations among agents. [Insert Figure 7 about here] Agents in the FrMS always pursue their own goals. If necessary, they issue a bid and negotiate with others to make a complete goal. The goal-formation process is the process of generating goals by coordinating processes among participating fractals and modifying them as necessary [13]. The GFA (Goal Formation Agent) is the agent that exists for this purpose. The GFA receives an incomplete goal from a NMA (Network Monitoring Agent) and makes sub-goals or modifies the current goal of the fractal. During the goal-formation process, the GFA cooperate with the DMA (Decision-making Agent) and FSM (Fractal Status Manager). The dynamic restructuring process (DRP) is the most important activity of agents in the FrMS. It is performed through complex tasks including negotiations, goal-formations, and task generation. The DRP is initiated by one of the agents in an organizer referred to as the REA (Restructuring Agent). The DRP enables a system to optimize its structure by reconfiguring network connections between the components. If a fractal’s workload exceeds a certain limit, the REA starts the DRP with the aid of other agents. A new fractal may be created, or existing fractals may be reorganized as a result of the DRP. When the DRP is needed in the FrMS, fractals first change their network connections, and then reorganize their structures to be more effective. In order to perform the DRP stably, it is assumed that there is always enough hardware suitable for use as a controller in a system. More details on the DRP will be presented in Section 4.2. 4. Fractal-specific characteristics and UML models Characteristics that differentiate an FrMS from other manufacturing systems include 1) selfsimilarity, 2) self-organization, and 3) goal-orientation. Specifically, the dynamic restructuring process (DRP), which is part of self-organization, is the most distinctive characteristic. This section describes fractal-specific characteristics with respect to UML models, focusing on their procedures and the relationships among participating agents. 4.1 Self-similarity Self-similarity, an inherent characteristic of a fractal, refers not only to the structural characteristics of organizational design, but circumscribes the manner of performing a job (service), as well as the formulation and pursuit of goals [13]. To achieve goals in a manufacturing system, there can be various possible solutions with respect to the individual problems. Even if there may exist several components with the same goal in the system, conditions or situations in the surrounding environment may be different for each

11

component. This can result in fractals that have identical goals, while their input and output variables have quite different internal structures. If two fractals return the same outputs for the same inputs, they are called “self-similar”, even if their internal structures are different. This characteristic can be affirmatively used to develop control software in the design phase because control modules or agents can be generated from the common structures. Therefore, a fractal designed at one level can be applied to other levels in the FrMS because of the self-similarity of fractals. 4.2 Self-organization Self-organization is related to a theoretical method and an operational method in the FrMS. The theoretical method referred to as self-optimization is defined as the application of suitable numerical approaches to optimize the performance of fractals in a system. It provides the FrMS with a mathematical background for designing the structures, compositions, and relationships of fractals. From various optimization techniques, fractals select and use a proper method to have a more optimal specification. Details on the optimization techniques are beyond the scope of this paper. The dynamic restructuring process (operational method) supports the reorganization of network connections between fractals so that the FrMS can be optimized and adapted to a dynamically changing environment. The DRP continuously changes the structure of the whole system depending on the fractals’ goals and external environmental conditions. For example, it is supposed that an unexpected event causes a controller to malfunction, or the type of parts that have to be produced in a system changes. In that case, controllers need to be changed or reorganized. The FrMS can perform these tasks automatically and dynamically with little intervention from human operators by using the DRP. The REA (Restructuring Agent) in an organizer leads the DRP. Fig. 8 illustrates the activities of the DRP using the activity diagram. If the REA decides to perform the DRP based on the results of periodic evaluations of a fractal’s performance, it first makes a new structure of fractals by employing a resource optimizer. The REA also employs the DMA (Decision-making Agent) if it needs to negotiate with other fractals. The REA sends a request for the address information to a NTA (Network Agent). It also sends a request for the specification for a new controller to the FSM (Fractal Status Manager) if the system needs more controllers. Then the REA sends a request to the FAM to get the addresses of fractals associated with the DRP. The REA creates a restructuring message, and informs the DMA of the DRP to make it generate the series of jobs for restructuring the fractals. The task executor in each of the TGAs (Task Governing Agents) conducts DRP-related jobs. Finally, the REA informs the FAM that fractal address information must be updated before the DRP can finish. [Insert Figure 8 about here] 4.3 Goal-orientation

12

Goal-orientation corresponds to the motivated activities of agents in fractals. To coherently achieve agents’ goals, goal consistency supported by an inheritance mechanism should be maintained during the process. The FrMS continues to develop goals autonomously in order to operate and harmonize the system by resolving conflicts. Basically, efficient production may be a usual goal. Such goals, however, change to other goals. But, in accordance with the surrounding environment, this goal may be changed to something like completing production at the earliest possible time or minimizing defects. The change of the goal in high level gives rise to the changes of the goal in sub-fractals. At the bottom level, if a fractal controls a machining center, shortening the processing time or the optimization of tool paths may be exemplary goals. From the goal of the top-level fractal, i.e., factory goal, the goals of lower-level fractals are generated and pruned by the goal-formation process. Warnecke [13] pointed out that the goal-formation process is a reliable method for revealing any conflicts between competing goals. The system should allow fractals to negotiate their goals with other fractals at any time, since it is very hard to anticipate which situations will require negotiation. The negotiation in the MANPro has four phases: 1) preparation, 2) cloning, 3) traveling and evaluation, and 4) awarding [27]. Figs. 9 and 10 illustrate the MANPro-based negotiation process and the activity diagram of NEA (Negotiation Agent), respectively. When a fractal needs to negotiate with others, the DMA (Decision-Making Agent) during the preparation phase determines a route for agent’s traveling and creates a NCA (Network Command Agent). Then, during the cloning phase, the DMA creates a NEA (Negotiation Agent) containing information about a negotiation, pre-evaluation methods, and conflictresolution methods. After moving to the reporter, the NEA is encrypted by the NCA and then starts the navigation following its traveling list to gather negotiation replies from others. During a traveling and evaluation phase, the NEA pre-evaluates negotiation replies from other fractals. If the reply does not meet the pre-evaluation requirement, then it is dropped. Otherwise, it is added to the reply_list. To simplify the UML model in Fig. 10, the pre-evaluation activity is modeled as one activity. After making a complete reply_list, the NEA goes back to the DMA and reports the results necessary for the decision-making. If DMA determines an awardee (fractal), then it generates TGAs (Task Governing Agents) and sends them to the awardee after they are encrypted by NCAs. When the fractal receives tasks from the issuer, it sends back an acceptance message so that the issuer can destruct the NEA that was used for the negotiation. [Insert Figure 9 about here] [Insert Figure 10 about here] 5. Data management in the FrMS 5.1 Data model for resources in the FrMS Resources in this paper mean physical equipment in the FrMS such as robots, milling machines,

13

turning machines, and so on. A manufacturing system is made up of a number of items of equipment. Wysk et al. [28] identified several classes of equipment, which have now been used as a basis for classification in this research. Equipment is classified into four major types including material processor (MP), material handler (MH), material transporter (MT), and buffer storage (BS). Each piece of equipment in the factory is classified as belonging to one and only one of these classes. Formally, the equipment (E) is defined according to the following set notation, and modeled with the UML class diagram as shown in Fig. 11. E = , where: MP = , MH = , MT=, BS = . [Insert Figure 11 about here] Equipment that transforms a product is classified as belonging to the MP class. MP is partitioned into four different classes including MRP (material removal processor), MFP (material forming processor), MIP (material inspection processor), and PD (passive device). Equipment belonging to MRP, MFP, or MIP requires an equipment controller whereas PD equipment does not need one. Equipment classified into MRP performs chip-making processes or material removal processes, e.g., machining centers, turning machines, drilling machines, and so on. Equipment classified into MFP performs shape-changing processes without making chips from a product, e.g. forming, forging, assembly, and so on. All equipment that inspects a product belongs to MIP. Equipment classified into PD performs auxiliary processes without changing material volume or shape. For example, PD equipment may change a product’s orientation or some nongeometrical property of the product. PD class equipment includes gravity-based inverters, heat lamps used for drying parts after a painting operation, etc. Equipment that transfers products between pieces of equipment is in the MH class . MH normally indicates several types of robots, and it is partitioned into FMH (fixed material handler) and MMH (movable material handler). The controller of MH class equipment requires synchronization with equipment associated with the transfer of products. If a robot operates within a designated position without moving, it belongs to FMH; otherwise it belongs to MMH. Human operators also can be classified as MMH. Equipment that moves products from one location to another location is in the MT class. MT is partitioned into FMT (fixed material transporter) and MMT (movable material transporter) in the same way that the MH class is partitioned. Conveyors belong to FMT, and AGVs, fork trucks, and human operators belong to MMT. Equipment that stores products is in the BS class. General equipment that stores products is classified into either ABS or PBS. If storage equipment requires its own controller, it belongs to the ABS class; otherwise it belongs to the PBS class. Some requirements for ABS equipment controllers include synchronization with MH class equipment, location allocation, capacity control, etc. Since an equipment item in the PBS class does not have its own controller, it must be controlled and maintained by some other

14

controller that uses it. 5.2 Information for controlling equipment The information and messages used in the FrMS can be classified into two major categories: 1) durable information and messages and 2) instantaneous information and messages. “Durable” means the operations and communication messages that exist during the entire lifecycle of a fractal. When a fractal is created for the purpose of controlling equipment, it can handle control-related operations and messages until it is destructed or its role is changed. On the other hand, “instantaneous” describes the operations and communication messages that can be changed at any time. Table 2 shows the information and messages that have been defined in this research. Operations and messages are clarified with several pieces of exemplary equipment in Table 2. If operations or messages are dependent upon specific hardware vendors, they are classified as “specific”. Otherwise, they are classified as “common”. Messages including commands and signals are italicized in Table 2. In addition, Table 3 describes the abbreviated information and messages in Table 2. For example, fr_id (durable common information) means the fractal identification, and reset_ml (instantaneous specific messages) means the operation for resetting the milling machine. [Insert Table 2 about here] [Insert Table 3 about here] 5.3 Management of resource data Fig. 12 shows a UML use-case diagram that models the management of resources in the FrMS. A use-case can be described as a specific way of using the system from a user’s perspective. A use-case diagram contains actors, use cases, and interactions or relationships between actors and use cases. Types of interactions include associations, dependencies, and generalizations. [Insert Figure 12 about here] The agent called FSM (Fractal Status Manager) manages information about the resources. If a fractal becomes an equipment controller, the FSM manages equipment status while dealing with equipment commands or signals as well as fractal status. In addition to the FSM, the following agents are also related to the equipment: 1) FAM (Fractal Address Manager), 2) NTA (Network Agent), 3) STA (System Agent), 4) EMA (Equipment Monitoring Agent), and 5) ECA (Equipment Command Agent). The EMA receives signals from equipment through the RS-232/422 protocol or an equipment interface that connects directly to the equipment from the equipment controller. The ECA sends equipment commands to the equipment in the same way as the EMA. The FAM manages equipment addresses such as the numbers corresponding to serial ports which indicate specific equipment connected to the controller. The NTA manages the addresses of the

15

unassigned controllers (fractals) that could be used as a controller in the system, and the STA manages the specification of controllers that are currently working in the system. The FSM (Fractal Status Manager) manages the following information that constitutes a fractal’s status: • Hierarchical position of the fractal Fractals are normally classified into hierarchical levels such as top, intermediate, and bottom. If a fractal belongs to the top level, it naturally does not have any information about the fractal in the level above it; in other words, it has a null character in the address field for the upper-level fractal. A fractal belonging to an intermediate level has information about both its upper-level and sub-level fractals. A bottom-level fractal does not have any sub-fractals and is directly connected to equipment. It also has a null character in the address field for the sub-level fractals in FAM (Fractal Address Manager). • Information about controlling equipment In fact, a fractal in any level in the hierarchy can control equipment. If a fractal is directly connected to and controls equipment, it has to manage information about the equipment. In such cases, the FAM (Fractal Address Manager) keeps and manages the equipment address, and the FSM (Fractal Status Manager) monitors the equipment status (e.g., busy, idle, or non-operational). • Information about currently processing jobs The FSM (Fractal Status Manager) manages information about the current work being processed according to job profiles or job schedules. It monitors and manages information about all of the jobs that have been or are being processed in the fractal. • Product information When a fractal controls machine equipment (e.g., machining center, lathe, and milling machine), it has to deal with a product. In that case, the FSM manages product information. 5.4 Management of product data The product class is created and managed by the FSM (Fractal Status Manager) in the FrMS. The attributes of the product class include 1) product_id, 2) priority, 3) processing status, and 4) time information such as arrival time, desired release time, expected machining time, and due date. Normally, the fractals (bottom-level fractals) that control equipment have detailed information about products, while upper-level fractals manage abstracted information. For example, a bottom-level fractal manages all of the aforementioned information about the product in the course of processing jobs, whereas a top-level fractal keeps only abstract information about the product such as product_ids, the number of products, and references to product classes. Information in a product class is passed to another fractal along with the movement of a physical part. Until a product is completely manufactured, information about the product is maintained by fractals through their coordination and cooperation. Unlike in the holonic manufacturing system, there is no particular component in charge of the products in the FrMS.

16

6. Development of prototype agents Before developing all eighteen agents of a fractal as described earlier in this paper, a DMA (Decision-Making Agent) and an NEA (Negotiation Agent) have first been developed as a prototype implementation. The major focus of this development was the implementation of the functions of MANPro. Each agent has been designed with UML and developed with AgletsTM [22,29]. AgletsTM is the JavaTM-based agent development tool developed by IBM Japan. Environments are provided on the host computers by specialized servers which understand the Agent Transfer Protocol (ATP) and provide security and other services. The most important reason to use a JavaTM-based language is to facilitate platform-independent systems. Furthermore, AgletsTM is an open source program so that programmers can customize their own programming environments while they develop agents. The latest version of AgletsTM supports Java2. Fig. 13 illustrates the procedure for creating DMA (Decision-Making Agent) and NEA (Negotiation Agent) from Tahiti, an agent server. Users, however, can operate agents without the Tahiti program by developing and using a customized program similar to Tahiti. The “create” button displays the list of registered agents to the users. When a user chooses DMA from the list, a DMA is created as illustrated in Fig. 13. The “Make NEA” button belonging to the DMA is used to create an NEA. [Insert Figure 13 about here] Fig. 14 illustrates the negotiations between the DMA and the NEA on the basis of the MANPro protocol. As shown in the current address field of each DMA, each DMA is expected to be on a different (distributed) server. As shown in the Fig., four prototype agents have been tested on the same machine (POSCIM) with different port numbers (e.g., 4434, 4444, 4445, 4446) for the ease of presentation. Similarly, the same system has been successfully tested on distributed machines. [Insert Figure 14 about here] The current status display of the agents in Fig. 14 shows that an NEA has been created by a DMA (port:4434), and it is currently traveling according to its traveling list. The status display also says that the NEA has just finished negotiating with a DMA (port:4445), and it is about to physically move to another DMA (port:4446). After finishing negotiations with all the other DMAs, it will be returned to the original place (DMA, port:4434) and will submit the final report to the DMA. The time taken for the NEA to travel these DMAs is less than a second, but will vary depending on the functions of the NEA. The execution time in a MANPro-based negotiation may be arguable by other researchers. However, owing to the rapid increase of computing power, the execution time will be significantly reduced, and, therefore, it will not be a major burden in the near future.

17

7. Conclusion The FrMS has autonomy, flexibility, and a high degree of self-similarity, and it is based on the concept of autonomous cooperating multi-agents referred to as fractals. The FrMS has many advantages that arise from fractal-specific characteristics including self-similarity, self-organization, and goal-orientation, particularly in a distributed and dynamic environment. The most outstanding function of the FrMS is the dynamic restructuring process (DRP), and it allows the FrMS to be more efficient and effective by reconfiguring fractals. In this paper, several fractal-specific characteristics and the DRP are described and modeled with UML diagrams. Agents for an FrMS are also described and modeled with UML. The use of UML allows not only an easy understanding of a system but also various other advantages mentioned in this paper. Through the dynamic modeling of the interactions among agents, an FrMS is now ready to be implemented containing several types of agents defined in this paper. This paper has also clarified the activities of agents based on inter- and intra-fractal activities. Information and messages regarding resources (equipment) are defined in detail along with exemplary equipment, and a method to deal with resource data and product data is presented. To test a new negotiation scheme for agents, the prototype agents (DMA and NEA) have been developed and tested based on the MANPro protocol. The implementation and testing of a complete FrMS is left for further research. References [1] T.C. Chang, R.A. Wysk, H.P. Wang, Computer Integrated Manufacturing, Prentice-Hall, 1998. [2] H. Cho, An Intelligent Workstation Controller for Computer Integrated Manufacturing, Ph.D. dissertation, Texas A&M University, USA, 1993. [3] Y. Son, Simulation Based Shop Floor Control: Automatic Model Generation and Control Interface, Ph.D. dissertation, The Penn State University, USA, 2000. [4] E.G. Mettala, Automatic Generation of Control Software in Computer Integrated Manufacturing, Ph.D. dissertation, The Penn State University, USA, 1989. [5] J. Smith, A Formal Design and Development Methodology for Shop Floor Control in Computer Integrated Manufacturing, Ph.D. dissertation, The Penn State University, USA, 1992. [6] N. Okino, Bionic manufacturing systems, Proceedings of the CIRP Seminar on Flexible Manufacturing Systems Past-Present-Future, Peklenik, J. (ed.), Bled, Slovenia, 1993, pp. 73-95. [7] N. Ueda, A concept for bionic manufacturing systems based on DNA-type information, Human Aspects in Computer Integrated Manufacturing (1992) 853-863. [8] H.V. Brussel, J. Wyns, P. Valckenaers, L. Bongaerts, P. Peeters, Reference architecture for holonic manufacturing systems: PROSA, Computers in Industry 37 (3) (1998) 255-274. [9] D. Seidel, M. Hopf, J.M. Prado, E. Garcia-Herreros, T.D. Strasser, J.H. Christensen, J.M. Oblak, HMS– Strategies, The Report of HMS Consortium, 1994.

18

[10] K. Ryu, M. Shin, K. Kim, M. Jung, Intelligent Control Architecture for Fractal Manufacturing System, Proceedings of 3rd Asia-Pacific Conference on Industrial Engineering and Management Systems, Hong Kong, 2000, pp. 594-598 [11] K. Ryu, M. Shin, M. Jung, A Methodology for Implementing Agent-based Controllers in the Fractal Manufacturing System, Proceedings of 5th Conference on Engineering Design & Automation, Las Vegas, NV, 2001, pp. 91-96. [12] T.M. Tirpak, S.M. Daniel, J.D. LaLonde, W.J. Davis, A note on a fractal architecture for modeling and controlling flexible manufacturing systems, IEEE Transactions on Systems, Man, and Cybernetics 22 (1992) 564-567. [13] H.J. Warnecke, The Fractal Company: a Revolution in Corporate Culture, Springer-Verlag, Berlin, 1993. [14] A. Tharumarajah, A.J. Wells, L. Nemes, Comparison of the bionic, fractal and holonic manufacturing system concepts. International Journal of Computer Integrated Manufacturing 9 (1996) 217-226. [15] Engineering Research Center for RMS, 2001, http://erc.engin.umich.edu/. [16] L. Chen, K. Sycara, Webmate: a personal agent for browsing and searching, Proceedings of the Second International Conference on Autonomous Agents and Multi Agent Systems (Agents ’98), Minneapolis/St Paul, MN, 1998, pp. 132-139. [17] S. Baek, J. Liebowitz, S. Prasad, M. Granger, Intelligent agents for knowledge management – toward intelligent web-based collaboration within virtual teams, Knowledge management handbook, CRC Press, 1999. [18] T. Kaihara, Supply chain management with market economics, International Journal of Production Economics 73 (2001) 5-14. [19] K. Fisher, Agent-based design of holonic manufacturing system, Robotics and Autonomous Systems 27 (1999) 3-13. [20] L.P. Khoo, S.G. Lee, X.F. Yin, Agent-based multiple shop floor manufacturing scheduler, International Journal of Production Research 39 (14) (2001) 3023-3040. [21] F.P. Maturana, D.H. Norrie, Multi-agent mediator architecture for distributed manufacturing, Journal of Intelligent Manufacturing 7 (1996) 257-270. [22] D.B. Lange, M. Oshims, Programming and developing JavaTM mobile agents with AgletsTM, AddisonWesley, 1998. [23] G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling Language User Guide, Addison-Wesley, 1999. [24] S.S. Alhir, UML in a Nutshell, O’Reilly & Associates, Inc., 1998. [25] OMG’s Unified Modeling Language, 2002, http://www.omg.org /gettingstarted/what_is_uml.htm. [26] R.G. Smith, The contract net protocol: high-level communication and control in a distributed problem solver, IEEE Trans. on Computers 29 (12) (1980) 1104-1113. [27] M. Shin, K. Ryu, M. Jung, A Novel Negotiation Protocol for Agent-based Control Architecture, Proceedings of 5th Conference on Engineering Design & Automation, Las Vegas, NV, 2001, pp. 700-705.

19

[28] R.A. Wysk, B.A. Peters, J.S. Smith, A Formal Process Planning Schema for Shop Floor Control, Engineering Design and Automation 1 (1995) 3-20. [29] IBM Japan, Aglets homepage, 2002, http://www.trl.ibm.com/aglets/index_e.htm.

20

1

Self-similar fractals (fractal = set of agents)

Level 0

2

Level 1

2

3

3

Level 1

A

T C

Level 2

R1

A R1

Level 2

T C

R2

R3

R2

M

Enabled by working mechanisms of agents

Facility Layout

Composition of Fractals

Level 0

1

Changes regarding equipment (e.g., addition or rearrangement, etc.) Before restructuring

After restructuring

Fig. 1. Reorganization of the system using a dynamic restructuring process in the FrMS

Request

Analyzer Observed Information

Observer Inputs

Plan Alternatives Delivered Message

Fractal Information Plan Results

Fractal Update

Organizer Fractal Status and Configuration Plans

Resolver

Status reports

Invoke Knowledge

Knowledge Request/Update

Fractal Addresses

Reporter Command Actions

Knowledge DB

Inner Fractal

Sensors

Actuators

Outer Fractal Events

Actions

Environment

Fig. 2. Functional modules and relationships of a fractal in an FrMS

21

Fig. 3. Class diagram of fractal agents

Fig. 4. The class diagram of DMA

22

Fig. 5. The activity diagram of DMA

Fractal Intra-fractal activity • Input/output control • Scheduling • Task generation • Real-time simulation • Information management • Job (task) processing • Database control • Equipment control • Intra-decision-making

Inter-fractal activity • Negotiation • Goal-orientation process • Dynamic restructuring process Fractal Intra-fractal activity

····

Fig. 6. Intra- and inter-activity of agents

23

CNP

MANPro TCP/IP

TCP/IP

Application

Application

Application

Controller A

Controller B

Controller A

Fig. 7. CNP-based negotiation vs. MANPro-based negotiation

Fig. 8. Activity diagram for dynamic restructuring process

24

Agent

Application

Controller B

Fractal A (Issuer) NCA

Preparation

NEA

(NCA generation)

Submission of Nego. Info.

Cloning

Pre-evaluation

(NEA generation)

Construction of Bid List

Observer Resolver

Fractal B

Reporter

Traveling NCA

Fractal C

NEA Bid Evaluation NCA

TGA generation Awarding NEA destruction

NEA Task

NCA acceptance message

Observer Resolver Reporter

Fig. 9. MANPro-based negotiation in the FrMS

Fig. 10. Activity diagram of NEA

25

Fractal n commands

Fig. 11. Class diagram for classification of equipment

Fig. 12. Use-case diagram for managing resources in the FrMS

26

Fig. 13. The procedure for making DMA and NEA from Tahiti

Fig. 14. Negotiations between NEA and DMAs

27

Table 1. Conditions for transitions in Fig. 5 Condition(s)

Meaning

Comments

c0

The negotiation process for the schedule is complete and the input matches the best job profile

–

c1 ~ c3 c2 ~ c4 c5 c6 ~ c8

The input is a conflict coming from the GFA (Goal Formation Agent) The input is a negotiation request from another agent in the same fractal The negotiation process for the decision is complete

(for c1) (for c4)

The input is a negotiation message coming from other NEAs (Negotiation Agents)

[c5] (for c6 and c7), (for c8)



Table 2. Information and communication messages of the FrMS equipment Type

Subtype MRP

MP

MFP

Exemplary equipment Mill Lathe Shaper Polisher

MIP

CMM

PD

Ori_Inverter Heat Lamp

FMH

fRobot

MMH

mRobot

FMT

Conveyor

MMT

AGV

MH

MT AS/RS BS

ABS PBS

L/U station Local buffer

Durable Information and Messages Common Specific pl_id, ml_cmds, fr_id, mid, fid, tid, ACK, chng_t, chng_pl load, unload, start, stop tn_cmds, chng_t fr_id, mid, fid, tid, ACK, sh_cmds, chng_t load, unload, start, stop po_cmds, chng_t fr_id, mid, fid, tid, ACK, te_cmds, chng_t load, unload, start, stop

Instantaneous Information and Messages Common Specific part_id, stime, etime, op_id, m_status, err part_id, stime, etime, op_id, m_status, err part_id, stime, etime, op_id, m_status, err

ml_cnd, reset_ml tn_cnd, reset_tn sh_cnd, reset_sh po_cnd, reset_po te_cnd, reset_te

Do not need a controller (usually use a manual switch for on and off) fr_id, rid, ACK, pick, put, m_part, wait, resume fr_id, rid, loc_id, ACK, pick, put, m_part, m_loc, wait, resume fr_id, tr_id, ACK, load, unload, stop_m, resume fr_id, tr_id, loc_id, ACK, fix_pl, unfix_pl, m_loc, stop_m, resume

bid, gid, fr_cmds, chng_g bid, gid, mr_cmds, chng_g

part_id, c_pos, s_pos, t_pos, fr_status, err part_id, c_pos, c_loc, s_pos, t_pos, s_loc, t_loc, mr_status, err

reset_fr reset_mr

cvr_cmds, pin_id

part_id, tr_status, err

reset_cvr

agv_cmds, bid

part_id, c_loc, s_loc, t_loc, tr_status, err

reset_agv

asrs_cmds, bay_id reset_asrs part_id, b_status, err stn_cmds, fix_pl, reset_stn unfix_pl Controlled by the nearest equipment controller (bid and buffer location info. are required)

fr_id, bid, ACK, load, unload

28

Table 3. Description of information and messages Information fr_id : fractal id mid : machine id fid : fixture id tid : tool id pl_id : pallet id ml_cmds : milling commands tn_cmds : turning commands part_id : part id stime : starting time of an operation etime : (expected) ending time of the operation op_id : operation id m_status : machine status ml_cnd : machining condition for a milling operation tn_cnd : machining condition for a turning operation sh_cmds : shaping commands po_cmds : polishing commands te_cmds : testing commands sh_cnd : machining condition for a shaping operation po_cnd : machining condition for a polishing operation te_cnd : machining condition for a testing operation r_id : robot id loc_id : location id bid : buffer id gid : grip id fr_cmds : fixed robot commands mr_cmds : movable robot commands c_pos : current position (w.r.t. the position of end-effecter) s_pos : starting position (w.r.t. the position of end-effecter) t_pos : target position (w.r.t. the position of end-effecter) fr_status : fixed robot status s_loc : starting location (place to pick a part) t_loc : target location (place to put a part) mr_status : movable robot status tr_id : transporter id cvr_cmds : conveyor commands pin_id : pin id agv_cmds : AGV commands tr_status : transporter status c_loc : current location asrs_cmds : AS/RS commands bay_id : id for bays in AS/RS stn_cmds : L/U stations commands b_status : buffer status

Messages (including commands or signals) ACK : acknowledgement load : load a part unload : unload a part start : start an operation stop : stop the operation chng_t : change tools chng_pl : change pallets err : error message reset_ml : reset milling machine reset_tn : reset turning machine reset_sh : reset shaping machine reset_po : reset polishing machine reset_te : reset testing device pick : pick a part put : put a part m_part : move a part from s_pos to t_pos wait : wait an operation until resume message resume : resume the operation which is in wait status m_loc : move location from s_loc to t_loc chng_g : change grippers reset_fr : reset a fixed robot reset_mr : reset a movable robot stop_m : stop moving fix_pl : fix the pallet unfix_pl : unfix the pallet reset_cvr : reset a conveyor reset_agv : reset an AGV reset_asrs : reset an AS/RS reset_stn : reset a L/U station

29