A CORBA-based agent-driven design for distributed ... - Springer Link

Journal of Intelligent Manufacturing (1998) 9, 457±465

A CORBA-based agent-driven design for distributed intelligent manufacturing systems LEI MING,1,2 YANG XIAOHONG,1 MITCHELL M.TSENG2 and Y A N G SH U Z I 1 1

School of Mechanical Engineering and Technology, Huazhong University of Science and Technology, Wuhan, 430074, China 2 Department of Industrial Engineering and Engineering Management, Hong Kong University of Science and Technology, Clear Water Bay, Hong Kong

Received May and accepted October 1997

An agent-oriented methodology is presented for representation, acquisition, and processing of manufacturing knowledge along with analysis and modeling of an intelligent manufacturing system (IMS). An intelligent manufacturing system adopts heterarchical and collaborative control as its information system architecture. The behavior of the entire manufacturing system is collaboratively determined by many interacting subsystems that may have their own independent interests, values, and modes of operation. The subsystems are represented as agents. An agent's architecture and task decomposition method are presented. The agentoriented methodology is used to analyze and model an intelligent machine cell. An intelligent machine center is considered as an autonomous, modular, recon®gurable and fault-tolerant machine tool with self-perception, decision making, and self-process planning, able to cooperate with other machines through communication. The common object request broker architecture (CORBA) distributed software control system was developed as a simple prototype. A case study illustrates an intelligent machine center. Keywords: Agent-based analysis, autonomous, cooperation, CORBA, intelligent manufacturing system

1. Introduction The new generation of advanced manufacturing systems is forcing a shift from mass production to mass customization (Tseng et al., 1997a,b), the ability to manufacture in small batches. To achieve this, it is becoming increasingly important to develop manufacturing systems and equipment control architectures that are modi®able, extensible, recon®gurable, adaptable, and fault tolerant. Centralized control architectures have given way to hierarchical schemes, where higher levels of the hierarchy control the lower level via a master±slave relationship. However, to achieve even greater levels of recon®gurability and adaptability, the newer manufacturing systems are adopting heterarchical control structures that are made up of multiple, distributed, locally autonomous entities, thus allowing a cooperative approach to global decision making (Ditts and Whorms, 1993). Conventional ¯exible manufacturing systems imply centralized or ®xed hierarchical control. Work cell functionality and product description are ®xed for optimal or 0956-5515

Ó 1998 Kluwer Academic Publishers

near-optimal performance based on a narrow product mix. Given current trends, where customer demands cause large variations on product mixes, and new technology is continually introduced into the manufacturing process, a predetermined ®xed hierarchy is not likely to produce good performance over extended periods of time. This motivates research on dynamically recon®gurable hierarchies in order to meet customer demands while striving to maintain high productivity in the manufacturing system. The next generation of advanced manufacturing systems need to incorporate three characteristics: (1) More distributed (heterarchical) control to achieve fault tolerance and robustness; (2) Work cell and machine ¯exibility, the ability to change and recon®gure work cell functionality to handle a greater variety of product mixes e€ectively; (3) Product ¯exibility adapts part selection and assembly sequencing to the current system con®guration. Other factors that need to be addressed are dynamic recon®guration to accommodate unusual events, such as

458 machine breakdowns and the introduction of new technology and processes as they become available. The goal is to maintain e€ective and ecient manufacturing operations with minimum downtime in recon®guring, replanning, and rescheduling manufacturing operations. IMS TC-5 proposes the concept of a holonic manufacturing system (HMS) as a framework for allowing adaptive recon®guration (http://www.ims.org/holonic.htm). An intelligent manufacturing system (IMS) can be regarded as the complex whole of various subsystems (http://www. ims.org/). Because of the rapidly changing market, the subsystems must cooperate very well with each other to achieve high eciency under small-lot or job-lot production. The manufacturing is thus the process of distributed cooperative problem solving by exchanging and sharing of materials, energy and information between the subsystems. Before the realization of such a large intelligent system, proper methods should be used for system analysis and modeling. A few methodologies for manufacturing system analysis, such as GRAI (Pun, 1986) and IDEF (Mackulak, 1984), had been used during research on computer integrated manufacturing systems (CIMS). These methodologies were useful in developing CIMS, but have a low eciency for IMS because of the system integration on the level of intelligence. Although an organism-oriented modeling approach (Lefrancois and Montreuil, 1994) had been proposed to design the manufacturing system tools are still lacking for analysis and processing of the manufacturing knowledge. The concept of an (intelligent) agent is proposed as the essential technique for IMS analysis and modeling. An agent-oriented methodology is proposed for representation, acquisition, and processing of manufacturing knowledge along with analysis and modeling of the IMS. The manufacturing system is viewed as an organization composed of intelligent entities called agents. Section 2 describes the conception and architecture of the agent; Section 3 describes the agent-oriented analysis and modeling methodology. Section 4 introduces a CORBA-based manufacturing cell control environment. Section 5 describes a case study for implementing an intelligent machine center. 2. Conception and architecture of an agent The term agent is mostly used in the arti®cial intelligence (AI) domain as a high-level concept for analyzing AI problems. Usually an agent means an entity that can perform a task continuously and autonomously in the nondeterminacy environment where there exist other processes and entities. Although the term agent is used frequently, it has no universal meaning, de®nition and structure. Shoham (1993) de®ned an agent to be any hardware or software component that has such mental states as beliefs, capabilities, choices, and commitments. Genesereth et al.

Lei Ming et al. (1987) suggested that an agent can be analyzed by its state activities and perception. For representing and analyzing the IMS and considering its realization, the following de®nition is appropriate: an agent is an entity that can perform some tasks and achieve the predetermined goal autonomously. The autonomy in the de®nition does not mean the agent must be fully independent, but means that it can automatically ask for assistance and services from other agents whenever necessary. According to this de®nition, human experts, intelligent CAD systems, and intelligent machining cells are all agents of the IMS. An agent in the IMS consists of two parts: the set of tasks and the set of activities. The task is the work to be done or the activities to be performed. For each agent there exists a set of tasks it is capable of performing. Every task is given a name as its only label when it is to be processed. The names of all the tasks form a task list. From the task list, other agents get information about what tasks an agent can ful®l. The performance of a task can usually be described as a series of activities that begins with a start-event and is directed toward a goal-event. The agent in the IMS should satisfy the following requirements: (1) Each agent has the knowledge necessary for performing its tasks. Most knowledge exists when the agent is constructed. The agent can also get knowledge by selflearning or by learning from other agents. The agent must process its knowledge to select proper actions. Knowledge may be expressed implicitly, perhaps in the architecture of the networks, the weights of the links, the algorithms, the software, or the computing hardware. Knowledge may also be explicitly represented by the data structures, e.g., as facts or frames. (2) Each agent has an interface to interact with the environment and other agents. The agent may ask for assistance from or give assistance to other agents including human experts. Furthermore, as the subsystem of an intelligent system, the agent must cooperate with other agents so as to integrate all the subgoals to the system goal. Agents must have the ability to cooperate. Cooperation is one of the tasks of all agents. (3) Each agent is hierarchically constructed; this means an agent may consist of ®nite subagents or it may be the subagent of ®nitely many other agents. An agent has some aspects in common with an object of the object-oriented method. From the engineering viewpoint, an agent is a specialization of an object (Baker, 1996). The object-oriented method can be used as the operational model for an agent. Frames are used here to represent the agent class and instance agents. In particular, the dynamic slots are the activities. The architecture of the agent is presented as follows: (1) An agent consists of a set of tasks and a set of activities.

CORBA-based design for distributed systems (2) A task is represented by the task frame, which includes task name, activity names, start-event, goal-event, task state, task priority, and time requirement. (3) Activities are divided into three types: domain activities, interfacing activities, and interchanging activities. The domain activities are limited within the agent. The interfacing activities are for asking assistance from other agents; the interchanging activities are for giving assistance to other agents. (4) Activities are composed of knowledge and knowledge processing units. (5) The task frames are accessible to the environment, and the activities are encapsulated within the environment. (6) Agents interact with the environment by message passing. The di€erence between an agent and an object is that the agent is autonomous and cooperative. The commonly used object-oriented method cannot support an agent. An independent task scheduling mechanism is provided for the object acting as an agent. It is used to interpret and process the messages. Agents are divided into several groups to support the cooperation within the groups. 3. Agent-oriented analysis and modeling of IMS The IMS can be viewed as the organization of a ®nite set of agents according to the previous de®nition of an agent. The system analysis may begin with task decomposition, because every agent can perform a set of tasks. As a result, a set of primary tasks of the IMS is obtained, from which a set of agents that forms the IMS can be developed. Based on the architecture, the system analysis can be carried out hierarchically. For instance, the manufacturing system can be decomposed into business and management, research and development, design, manufacturing, and marketing; then manufacturing can be decomposed into scheduling, part manufacturing, production control, and assembly.

459 The agent-oriented methodology for analysis and modeling is a four-step procedure: (1) Decomposing the system tasks; (2) Forming a set of primary agents which can cover the whole system; (3) Realization of each agent; (4) Organization of the primary agents to construct high-level agents until the original system becomes an agent. When these procedures have been completed, we get the agent models of the system for all levels of the architecture. The following principles must be satis®ed when the primary agents are formed from the decomposed tasks and when the high-level agents are organized: (1) An agent must be logically and physically practical. (2) Every primary task of the system must be covered by at least one agent. (3) Interaction exists within the agents so that the local function of each agent can be synthesized properly to support the performance of the system. As an example, consider the methodology for designing an intelligent machining center (IMC). The IMC (Fig. 1) is an intelligent machining agent in the IMS. It receives the machining tasks from other agents and determines whether the tasks are suitable according to its abilities and current state. Then it negotiates with the agents in the same ma-

Fig. 1. Intelligent machine center.

Fig. 2. Relationships between agents in the intelligent machine center.

460

Lei Ming et al.

chining group if it is necessary to adjust the job load (Fig. 2). When the job is settled, the IMC inspects whether the workpiece is correctly prepared and set up before scheduling the operation plans. During the machining process, multisensors are used to monitor the state of the IMC and the environment. The activities of the IMC are controlled in-process on the basis of state variables. 4. A CORBA-based manufacturing cell control environment 4.1. Distributed objects Distributed object technology allows computing systems to be integrated such that objects or components work together across machine and network boundaries. Examples of current distributed object or component technologies include CORBA (Object Management Group, 1995), OLE (Orifali and Harkey, 1996). A distributed object is not necessarily a complete application but rather a reusable, self-contained piece of software that can be combined with other objects in a plug-and-play fashion to build distributed object systems (Fig. 3). A distributed object can execute either on the same computer or on another networked computer with other objects. Thus a client object may make a request of a server object and the operation proceeds una€ected by their respective locations. 4.2. Common object request broker architecture (CORBA) CORBA (Object Management Group, 1995) is an industry middleware standard for building distributed, heterogeneous, object-oriented applications. CORBA is speci®ed by the Object Management Group (OMG), a non-pro®t consortium of computer hardware and software vendors. CORBA currently provides the best technical solution for integrating our manufacturing test bed; it is robust, heterogeneous, interoperable, multiplatform, and multivendor

Fig. 4. CORBA object model.

supported. Figure 4 shows the CORBA reference model. The object request broker (ORB) is the communication hub for all objects in the system; it provides the basic object interaction capabilities necessary for components to communicate. When a client invokes a method on a remote object, the ORB is responsible for marshaling arguments for the call, locating an object server, physically transmitting the request, unmarshaling the arguments in a format required by the server, marshaling return values or exceptions for the response, transmitting the response, and unmarshaling the response at the client end. CORBA object services in Figure 4 are common services needed by a distributed object system; these services add functionality to the ORB. CORBA object services include standards for object life cycle, naming, persistence, event noti®cation, transactions, and concurrency. Common facilities provide a set of general-purpose application capabilities for use by object systems, including accessing databases, printing ®les, document management, and electronic mail in a distributed system. Finally, application objects in Figure 4 are the developed software which make use of the other three categories. 4.3. OMG interface de®nition language (IDL)

Fig. 3. Con®guration of an agile manufacturing cell.

The OMG interface de®nition language (IDL) is used to de®ne interfaces in CORBA. An IDL interface ®le describes the data types and methods or operations that a server provides for an implementation of a given object. IDL is not a programming language; it describes only interfaces and it has no implementation-related constructs. The OMG does specify mappings from IDL to various programming languages, including C, C++, and Smalltalk. IDL is used here to show interfaces to manufacturing devices, the task sequencer, and other CORBA objects in the system. All the manufacturing implementations were written in C‡‡, though other languages (e.g., Tcl and Visual Basic) were chosen to write client-only applications using CORBA objects. Even without a detailed description,

CORBA-based design for distributed systems

461

the OMG IDL language is fairly readable and we present an informal introduction by describing a simple interface within an environment called INotify. As its name suggests, this interface is used to communicate noti®cations of events. For example, when some asynchronous process is requested, success or failure may be later reported back through an object INotify interface. The OMG IDL code for INotify interface is as follows: interface INotify

{

readonly attribute string str; readonly attribute boolean isEmpty; readonly attribute long exceptCode; readonly attribute string exceptString; oneway void SetString (in string str); oneway void SetExcept(in long code, in string str); oneway void Clear(); INotify New(); }; INotify is declared as an interface in the ®rst line of the ®le. A description of the interface is provided in subsequent lines, between the curly braces. This interface consists of four attributes followed by four operations. Attributes correspond conceptually to state variables for the object. For example, the ®rst attribute listed, str, is declared to be of type string. Thus each INotify object has a string of text called str that can be queried. The leading readonly keyword in the declaration of str indicates that its value cannot be directly modi®ed. Without this keyword, the value of the attribute could be set as well as queried. Subsequent attribute declarations use some of the other basic types available in IDL. These include long, short, boolean, and double. New types can also be de®ned as structures, arrays, and sequences. And interfaces themselves represent types. Thus, an attribute might be of type INotify, for example. 4.4. Interfaces for manufacturing devices We have used OMG IDL to specify standard software interfaces to the various manufacturing devices in the agile manufacturing cell. A goal of this e€ort is illustrated in Fig. 5. At the bottom of the ®gure are the various machine tools. On the PC associated with each machine tool, we implement software which provides the OMG IDL interface. By manipulating the software interface, a client program can control the corresponding machine. With this, then, we can write client software illustrated in Fig. 5 as the cell management software components, which controls the manufacturing activities. Thus, each of the physical manufacturing objects in the agile manufacturing cell is controlled by a corresponding

Fig. 5. Cell management software.

CORBA software object. In spite of the apparent di€erences among the various devices (lathe, robot, storage table, etc.), they all support the same software interface: an OMG IDL interface called IDevice. This section presents a description of our IDevice interface. For brevity and for clarity, an abbreviated IDL will be shown. The ®rst declaration line for interface IDevice illustrates the inheritance feature of OMG IDL. The declaration of IDevice as an interface is followed by a colon, then a list of other interface names, starting with IBaseDev. IDevice therefore inherits operations and attributes from the following other interfaces: (1) IBaseDev ± naming and operational status for the machine; (2) IAllocaDev ± controlling access to the machine; (3) IRunDev ± running processing activities on the machine (machining a part); (4) IMovePart ± transfering material into and out of the machine. Here is some of the relevant IDL code: interface IBaseDev

{

readonly attribute string DeviceClass; readonly attribute string DeviceID; readonly attribute string VersionString; readonly attribute string Status; long Advise (in Inotify hnotify); boolean UnAdvise (in long advisedID);

};

interface IRunDev

{

boolean Pause(); boolean Resume(); boolean Abort(); };

462 interface IMovePart

{

boolean SetPartner(); boolean TakeFromPartner(); boolean GiveToPartner();

};

interface ICellSeq

{

long AddJob (in string JobName, in string JobText, in string PartName, in Inotify WhenDone); void Pause(in long JobID); void Resume(in long JobID); void Abort(in long JobID); boolean DeletJob (in long JobID); boolean AddDevice

};

4.5. Integration of devices in a manufacturing cell As a research facility, IDevice objects were among the ®rst software modules created for this project. Our experience has been that the IDevice design and implementation is suciently ¯exible and adaptable to accommodate both the addition of new machine tools and the evolution of more sophisticated cell management software. As a CORBA object itself, the cell sequencer is also a client to the IDevice objects. This con®guration can be seen in Fig. 6. The cell sequencer dynamically attaches to devices, hence there is no need to recompile when a new machine tool comes on-line or a machine tool disappears. The sequencer accepts jobs, dispatches tasks in the cell, prevents deadlock situations and guards against starvation of any single job. An abbreviated IDL code for the sequencer ICellSeq is as follows: interface ICellSeq

{

long AddJob (in string JobName, in string JobText, in string PartName, in INotify WhenDone);

Fig. 6. Cell sequencer manipulating several IDevice objects.

Lei Ming et al. void Pause(in long JobID); void Resume(in long JobID); void Abort(in long JobID); boolean DeleteJob(in long JobID); boolean AddDevice(in string DevName, in IDevice Dev); boolean AddRobotDevice(in string DevName, in IDevice Dev); boolean RemoveDevice(in string DevName); IDevice QueryDevice(in string DevName);

};

A new job can be added to the sequencer with the AddJob() operation. This operation takes three input strings as arguments: JobName, a unique name within the cell; JobText, a script of high-level instructions to be accomplished in the cell; and PartName, which identi®es the part to be manufactured. The AddJob() operation also takes an INotify object reference so that the sequencer's client can be noti®ed of job completion or any error conditions encountered. The return value of the AddJob() operation is of type long, indicating the assigned JobID given by the sequencer; this JobID can then be used to Pause(), Abort(), Resume(), or Delete() a job in the sequencer, even while the task dispatcher is operating. The task sequencer parses JobText, written in a simple scripting language developed for our manufacturing cell. The language supports manufacturing setup operations, material transfer between two IDevice objects, access to IDevice objects, and program execution at IDevice objects. Though the cell sequencer coordinates cell activities, many operations can be accomplished intelligently by the devices. For example, we have mentioned that all material transfer is performed as peer-to-peer object interaction, independent of the supervisory control of the task sequencer. There are four operations in ICellSeq which allow a client to manipulate devices known to the sequencer; AddDevice(), AddRobotDevice(), RemoveDe-

CORBA-based design for distributed systems vice(), and QueryDevice(). Notice that there are two di€erent operations to add a device to the sequencer: the AddRobotDevice() is necessary to distinguish robot and transport vehicles from all other manufacturing and storage devices known by the sequencer. The sequencer must know if a device is a transport device in order to prevent certain deadlock conditions in the cell. By including operations for dynamically adding and removing devices in a cell sequencer, the sequencer will never have to be recompiled or restarted when a new IDevice object is available on the network. In theory, this architecture supports a cell sequencer remotely dispatching jobs to any IDevice objects. The current task dispatcher is quite simple, with no scheduling optimization criteria. This task dispatcher will be used by a smart scheduling object, ICellSched. This elaborate scheduler will call ICellSeq to dispatch jobs once it has optimized on time, cost, and priority values on jobs. We expect the current interface and implementation of ICellSeq to remain as described above. Allowing for this type of growth is a strength of using this distributed object architecture. 5. Intelligent control for an open architecture system Open architecture controllers are designed to eliminate the problem of implementation by creating a ¯exible control system which can be attached to a wide variety of machine tool systems. The open architecture control system for the machining process is designed to replace or supplement an existing CNC controller while leaving the original axis, spindle drive-motors and supporting electronic interfaces intact. Open architecture controllers are usually constructed using standard minicomputers, usually running in a DOS or UNIX environment such as an IBM-type personal computer or workstation. Several open architecture controller schemes have been introduced. Altintas proposed a hierarchical open architecture CNC (HOAM-CNC) which provided an open platform for implementing machining algorithms (Altintas, 1994; Altintas, 1996; Altintas and Newell, 1996). This system used a 486 PC with an o€-the-shelf digital signal processing (DSP) board. Its multiprocessor setup consisted of a system master, which maintained overall control of the system; a CNC master, which maintained the CNC functions of workpiece position and velocity; and individual machine axis controllers, which were designed in-house. Mosaic, a system of Sun workstations based on a VME bus, controls a tree-axis machining center using o€-theshelf components for the axis and spindle controllers (Green®eld, 1989). The system also integrates touch probes, basic adaptive control for cutting, and interfaces with programs such as Machinist, an expert system for setup and clamping procedures.

463 The implementation of control strategies to machining processes often requires the use of application-speci®c knowledge and procedures, known as skilled technology. An intelligent machining will normally succeed when the following procedure is observed: (1) Feed is maximized such that tool breakage is avoided. (2) Depth of cut is maximized within the chatter limit. (3) Velocity is adjusted to achieve acceptable tool life. The objective of the controller is to increase the utilization of the machine tool by coordinating event-design chatter control and adaptive force control subsystems. This is accomplished by using an intelligent agent (Lei, 1995; Lei et al., 1996). The overall control system consists of several control tasks operating under a small multitasking kernel. A realtime inference engine, operating as a high priority task, regularly evaluates events and performs coordination and recovery operations. A frame-based knowledge base is used to store and process information. The use of an intelligent agent is shown to achieve a coordinated and uni®ed control objective. The system is implemented on a vertical milling machine center having a 7.5 kW spindle motor. A two-axis numerical controller coordinates the tool movement. Tool force measurements are taken from load cells at the tool post, and vibration signals are taken from accelerometers at the tool post. These signals are digitally sampled by the control microcomputer. The numerical controller has an optional programmable logic controller (PLC) that allows for NC programming using variables in place of geometric coordinates. A dedicated interface allows for tool paths to be commanded externally. Variation in the feed rate is achieved using a feed-rate override circuit. A 4-bit binary signal applied to the override circuit will vary the actual tool feed rate from 0 to 150% of the programmed value. This variation occurs in discrete steps of 10%. The knowledge-based controller resides in a 32-bit microprocessor-based computer. These symbolic algorithms encode a priori de®ned reasoning about indicated process system conditions and the actions required to maintain a desired performance. At the lowest level of intelligence are the process level tasks. These include individual loop controllers and more computationally demanding signal analysis algorithms. Such operations involve numeric data processing, as opposed to the symbolic processing performed at the highest level. The controller software is executed under control of a real-time, multitasking operation system. Utilities are provided for task synchronization and intertask communication. The knowledge base exists as a global blackboard entity. The remaining elements of the system are realized as four separate concurrent tasks:

464 (1) The intelligent monitor's real-time inference engine; (2) A signal processing task for force and vibration monitoring; (3) A force controller task; (4) A task to send tool path commands to the CNC. An approach to achieving these goals would involve the separation of knowledge representation issues, and event evaluation and recovery action issues. The frame-based approach to knowledge representation o€ers many advantages for control applications. However, the inherent backtracking inference mechanism and its associated diculties in real time imply that knowledge evaluation should be separated from the frame-based knowledge base. In the system presented here, the intelligent system supervisor is therefore divided into three distinct parts: (1) A frame-based knowledge base for maintenance of system knowledge and evaluation of single events related to signal or alarm conditions. The evaluations convert the numeric process data into a symbolic form required by the inference engine. Such actions require low system overhead and represent the minimal extent of real-time activities in the knowledge base. (2) A logic structure relating each of the signal or alarm events in the knowledge base to the recovery actions required to bring about stable and coordinated system operation. (3) An inference engine to direct searching of the logic structure. Rules are evaluated symbolically and the associated recovery actions are systematically executed. As a task in the multitask system, the inference engine executes concurrently with the conventional control systems. These are implemented in the C‡‡ programming languages for fast and ecient execution. The uses of objected-oriented C allowed for the development of a frame-based knowledge base while retaining the execution speed of C. 6. Conclusion A distributed object CORBA framework has been presented for the management of a manufacturing cell. This architecture is robust, allowing for easy addition, deletion, and updating of manufacturing devices in a plug-and-play manner. Several di€erent implementations were shown for a CORBA IDevice interface and the corresponding C‡‡ class, CDevice. These well-de®ned common interfaces hide from the cell management software their implementation details, including the machine controller and the communications to the machine tool. The IDevice interface also supports automated and manual machine operations and/or material transport. The CDevice class allows a wide range of machining, storage, or transport devices to be encapsulated. A CORBA interface to a cell sequencer has

Lei Ming et al. been de®ned and implemented. The cell sequencer manipulates IDevice objects and coordinates manufacturing jobs on a shop ¯oor. CORBA enhances the system integration because it is an industry standard for interoperable, distributed objects across heterogeneous hardware and software platforms. In time, as commercial software vendors provide CORBA interfaces to various software components, it will be easy to integrate them with the software developed here. The resulting architecture is scalable across a wide-area enterprise (Mratin and Spooner, 1997; Tseng et al., 1997a). Our future work includes adding support for a more information-intensive environment available at the shop ¯oor. Intelligent cell management components must have access to design and planning information in order to make well-informed decisions about scheduling jobs and managing manufacturing devices. The bidding scheme based collaborative control system (Tseng et al., 1997a, b) can be implemented with this kind of information infrastructure.

References Altintas, Y. (1994) A hierarchical open architecture CNC system for machine tools. Annals of CIRP, 43(1), 349±354. Altintas, Y. (1996) Modular CNC design for intelligent machining, part 2: modular integration of sensor-based milling process monitoring and control tasks. Journal of Manufacturing Science and Engineering, 118(4), 514±521. Altintas, Y. and Newell, N. (1996) Modular CNC design for intelligent machining, part 1: design of hierarchical motion control module for CNC machine tools. Journal of Manufacturing Science and Engineering, 118(4), 506±513. Baker, A. D. (1996) Metaphor or reality: a case study where agents bid with actual costs to schedule a factory, in MarketBased Control, Clearwater, S. H. (ed.), World Scienti®c, London, pp. 184±223. Ditts, D. and Whorms, H. (1993) The evolution of control architectures for automated manufacturing systems. Journal of Manufacturing Systems, 12(1), 79±93. Du€e, N. A. (1990) Synthesis of heterarchical manufacturing systems. Computers in Industry, 14, 167±174. Genesereth, M. R. (1987) Logical Foundations of Arti®cial Intelligence, Morgan Kaufmann, San Francisco, CA. Greenfeld, I. (1989) Open system machine controllers ± the MOSAIC concept and implementation. Transactions of ACM, 18, 91±97. Lefrancois, P. and Montreuil, B. (1994) An organism-oriented modeling approach to support the analysis and design of manufacturing systems. Journal of Intelligent Manufacturing, 5(4), 121±142. Lei, M. (1995) Research on intelligent cutting monitoring and manufacturing intelligence cooperating, PhD Dissertation, Huazhong University of Science and Technology. Lei, M., Tseng, M. M., Yang, X. H. and Yang, S. Z. (1996) Agent-oriented analysis methodology in intelligent manufacturing system in Proceedings of the Fourth International Conference on Control, Automation, Robotics and Vision, Singapore, World Scienti®c, pp. 1299±1303.

CORBA-based design for distributed systems Lin, G. Y. and Solberg, J. J. (1992) Integrated shop ¯oor control using autonomous agents. IIE Transactions, 24(3), 57±71. Luscombe, A. M., Toncich, D. J., Thompson, W. and Dluzniak, R. (1984) A new type of machine control system to replace traditional CNC. International Journal of Advanced Manufacturing Technology, 9(6), 369±374. Mackulak, G. T. (1984) High-level planning and control: an IDEF0 analysis for airframe manufacturing. Journal of Manufacturing Systems, 3(2), 121±132. Mratin, H. and Spooner, D. L. (1997) Data protocols for the industrial virtual enterprise. IEEE Internet Computing, 1(1) 20±30. Object Management Group (1995) The Common Object Request Broker: Architecture and Speci®cation, OMG Technical Document PTC/96-03-04, Framingham, Massachusetts. Orifali, R. and Harkey, D. (1996) The Essential Distributed Objects Survival Guide, John Wiley, New York. Pun, L. (1986) Arti®cial Intelligence Systems and Applications to Industrial Production Systems, Plenum, New York.

465 Rober, S. J. and Shin, Y. C. (1995) Modeling and control of CNC machines using a PC-based open architecture controller. Mechatronics, 5(4), 401±420. Shoham, Y. (1993) Agent oriented programming. Arti®cial Intelligence, 60(1), 51±92. Sta€ Writer (1990) Concept of IMS and its stagnant progress. Techno Japan, 23(11), 48±63. Tseng, M. M., Lei, M. and Su, C. J. (1997a) A collaborative control system for mass customization manufacturing. Annals of CIRP, 46(1), 373±376. Tseng, M. M., Lei, M., Su, C.J. and Wang Wei (1997b) A marketlike coordination for mass customization manufacturing in Proceedings of the 6th Industrial Engineering Research Conference, Miami Beach, FL, pp. 972±977. Wright, P. K. (1994) Principles of Open-Architecture Manufacturing, ESRC 94-26, Engineering Systems Research Center, University of California at Berkeley.