Design an intelligent machine center strategy and practice

P E R G A M O N Mechatronics 8 (1998) 271-285

MECHATRONICS

Design an intelligent machine center strategy and practice

Ming Lei a'b*, Xiaohong Yang a, Mitchell M. Tseng b, Shuzi Y a n g a

School of Mechanical Engineering and Technology, Huazhong University of Science and Technology, Wuhan, 430074, P.R. China

b Department of Industrial Engineering and Engineering Management, Hong Kong University of Science and Technology, Clear Water Bay, Hong Kong

Received 20 March 1996; revised 22 October 1997; accepted 29 October 1997

Abstract

This paper presents an agent-oriented methodology for representation, acquisition, processing of manufacturing knowledge and analysis, modeling of Intelligent Manufacturing System (IMS). 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 agent-oriented methodology is used to analyze and model as an intelligent machine cell. An intelligent machine center is considered as an autonomous module, a reconfigurable and fault tolerant machine tool with self-perception, decision making and self-process planning ability with cooperation to other machines through communication. As a simple prototype, a CORBA (Common Object Request Broker Architecture) based distributed software control system was developed. Finally, a case study of an intelligent machine center detailing a self-perception open controller is presented. © 1998 Published by Elsevier Science Ltd. All rights reserved.

I. Introduction

The new genera t ion o f advanced manufac tu r ing systems is forcing a shift f rom mass p roduc t ion to mass cus tomiza t ion and the abi l i ty to manufac tu re in small

* Corresponding author

0957~4158/98 $19.00 © 1998 Published by Elsevier Science Ltd. All rights reserved. P I I :S0957-4158(97)00054 8

272 M. Lei et al/Mechatronics 8 (1998) 271 285

batches. To achieve this, it is becoming increasingly important to develop manufacturing systems and equipment control architectures that are modifiable, extensible, reconfigurable, 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 reconfigurabitity 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.

Conventional FMS imply centralized or fixed hierarchical control. Workcell functionality and product description are fixed for optimal or near-optimal performance based on a narrow product mix. Given current trends, where customer demands cause large variations on product mixes, and new technology being continually introduced into the manufacturing process, a predetermined fixed hierarchy is not likely to produce good performance over extended periods of time. This motivates research on dynamically reconfigurable 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:

• more distributed (heterarchical) control to achieve fault tolerance and robustness; • workcell and machine flexibility, the ability to change and reconfigure workcell

functionality to handle a greater variety of product mixes effectively; and • product flexibility adapt parts selection and assembly sequencing to best suit current

system configuration.

Other factors that need to be addressed are dynamic reconfiguration to accommodate unusual events, such as machine breakdowns and the introduction of new technology and processes as they become available. The goal is to maintain effective and efficient manufacturing operations with minimum downtime in reconfiguring, replanning, and rescheduling manufacturing operations.

IMS TC-5 proposes the holonic manufacturing systems (HMS) [1] concept as a framework for allowing adaptive reconfiguration. An intelligent manufacturing system (IMS) [2] can be regarded as the complex whole of various subsystems. Because of the rapid changing market, the subsystems must cooperate very well with each other to achieve high efficiency 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 [3] and IDEF [4], have been used during the research of the computer integrated manufacturing systems (CIMS). These methodologies were found useful in developing the CIMS. With regard to the IMS, the existent methodologies have low efficiency because of the system integration on the level of intelligence. Tools are lacking for analysis and processing of the manufacturing knowledge.

This paper brings forward the concept of an (intelligent) agent as the essential technique for IMS analysis and modeling. An agent-oriented methodology is proposed for representation, acquisition, processing of manufacturing knowledge and analysis,

M. Lei et al/Mechatronics 8 (1998) 271-285 273

and modeling of the IMS. The manufacturing system is viewed as an organization composed of intelligent entities called agents. This paper is organized as follows. In Section 2, the conception and architecture of an agent are described in Section 3, the agent-oriented analysis and modeling methodology is discussed in Section 4, a CORBA-based manufacturing cell control environment is introduced and in Section 5, a case study for the implementation of an intelligent machine center is described.

2. Conception and architecture of agent

The term of agent is mostly used in the artificial 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 non-determinacy environment where other processes and entities exist. Although the term of agent is used frequently, it has no unified meaning, definition or structure. Y. Shoham [5] defined the agent to be any hardware or software component that has such mental states as beliefs, capabilities, choices and commitments. M.R. Genesereth [6] suggested that an agent can be analyzed by its state activities and perception. For representing and analyzing the IMS and considering its realization, a definition of the agent used in the research is given as follows.

An agent is an entity that can perform some tasks and achieve the predetermined goal autonomously. The autonomy in the definition does not mean that 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 definition human experts, intelligent CAD systems and intelligent machining cells are all agents of the IMS.

An agent in the IMS is constituted 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 they are capable of performing. Every task is given a name as a label of when it is to be processed. The names of all the tasks form a task list. Other agents get information about what tasks the agent can fulfill by the task list. 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:

• 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 self- learning or by learning from other agents. The agent must process its knowledge to select proper actions. Knowledge may be expressed implicitly, for example, 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 such as facts or frames.

• Each agent has the 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

274 M. Lei el al/Mechatronics 8 (1998) 271 285

cooperate with other agents so as to integrate all the subgoals to the system goal. Agents must have cooperation ability. Cooperation is one of the tasks of all agents.

• Each agent is hierarchically constructed which means that an agent may either be made up by finite sub-agents or be the sub-agent of other finite agents.

The agent here has some common ideas as the object in the object-oriented method. From an engineering point of view, the agent is a specialization of the object [7]. The object-oriented method can be used as the operation model of the agent. Frames are used in the research to represent the agent class and instance agents. What is par- ticularly interesting is that it has activities such as dynamic slots. The architecture of the agent is presented as follows:

• an agent is constituted of a set of tasks and a set of activities; • the task is represented by the task frame which includes task name, activity names,

start event, goal event, task state, task priority and time requirement; • 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 those related to asking for assistance from other agents, and the interchanging activities are those related to giving assistance to other agents;

• activities are also composed of knowledge and knowledge processing units; • the task frames are accessible to the environment, and the activities are encapsulated

to the environment; • agents interact with the environment by message passing.

The difference between agent and object is that the agent is autonomous and cooperative. The commonly used object-oriented method cannot support these. 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 INIS

The IMS can be viewed as the organization of a finite set of agents according to the definition of the agent given previously. The system analysis may begin with task decomposition because every agent can perform a set of tasks. As the 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 with business and management, research and development, design, manufacturing and marketing, and manufacturing being decomposed with scheduling, part manufacturing, production control and assembly.

The procedures of the agent-oriented methodology for analysis and modeling is as follows:

• decomposing the system tasks; • forming a set of primary agents which can cover the whole system;

M. Lei et al/Mechatronics 8 (1998) 271 285 275

• realization of each agent; • organization of the primary agents to construct high-lever agents until the original

system becomes an agent.

When the above procedures are completed, we get the agent models of the system for all levels of the architecture. The following principles must be satisfied when the primary agents are formed from the decomposed tasks and when the high level agents are organized.

• an agent must be logically and physically practical; • every primary task of the system must be covered by at least one agent; and • 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, the methodology for designing an intelligent machining center (IMC) is discussed.

collaborative input collaborative output

Machining task ~ T ~ waste . product data ~ [ finished~duct raw material .,~.,~q Intelligent Machine Center ] produ~ ~-ta

space/Ve 4 ~unication

infrastructure Fig. 1. Intelligent machining center.

l Image processing Agent [

q Analysis agent Process [ planning [ Agent [

~onfiguration ]

cooperation information ~ [ Cooperation communication / [ Agent [ ~ )

cMachining [ /

Machining H Sensor fusion I Agent ~_.~ ~ Agent [

cooperation information output Fig. 2. Relationship between agents in intelligent machining center.


The IMC 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 machining group if it is necessary to adjust the job load. When the job is settled, the IMC inspects whether the workpiece is rightly prepared and set up, and then schedules the operation plans. During the machining process multi-sensors 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 [8], OLE [9]. 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. 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 unaffected by their respective locations.

4.2. Common Object Request Broker Architecture (CORBA)

CORBA [8] is an industry middleware standard for building distributed, heterogeneous, object-oriented applications. CORBA is specified by the Object Man-

Ethemet

PC, Sun Sparc 20

IJ J ( Fig. 3. Agile manufacturing cell configuration.

M. Lei et al/Mechatronics 8 (1998) 271-285

Application objects Common Facilities : . . . . . . . . . : . . . . . . . . . ..

t ' x Object Request Broker ] "N~

b/

Object Services Fig. 4. CORBA object model.

277

agement Group (OMG), a non-profit consortium of computer hardware and software vendors. It is robust, heterogeneous, interoperable, multiplatform, and multivendor supported. Fig. 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 Fig. 4 are common services needed by a distributed object systems; these services add functionality to the ORB. CORBA object services include, for example, standards for object life cycle, naming, persistence, event noti- fication, transactions, and concurrency. Common facilities provide a set of general- purpose application capabilities for use by object systems, including accessing data- bases, printing files, document management, and electronic mail in a distributed system. Finally, application objects in Fig. 4 are the developed software which make use of the other three categories.

4.3. OMG Interface Definition Language (IDL)

The OMG Interface Definition Language (IDL) is used to define interfaces in CORBA. An IDL interface file 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, but rather a language that describes only interfaces: there are no implementation-related constructs in the language. The OMG does specify mappings from IDL to various programming languages including C, C + + , and Smalltalk. We will use IDL to show the interfaces to manufacturing devices, the task sequencer, and other CORBA objects in our system. Our particular manufacturing implementations have all been written in C + + , though we have used other languages (Visual Basic, for example) to write client-only applications which use our CORBA objects. Though


we will not give a detailed description of the OMG IDL language, it is fairly readable, and we present an informal introduction to IDL by describing a simple interface that is used in our environment called INotify. As its name suggests, this interface is used to communicate notifications 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 for our INotify interface is as follows:

interface f

readonly readonly readonly

lNotify

attribute string str; attribute boolean isEmpty; 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 first line of the file. 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 con- ceptually to state variables for the object. For example, the first 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 modified. 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 defined as structures, arrays, and sequences. Further, interfaces themselves represent types. Thus, an attribute might be of type INotify, for example.

4.4. lnterJaces for manujacturing devices

OMG IDL is used to specify standard software interfaces to the various manufacturing devices. A goal of this effort is illustrated in Fig. 5. At the bottom of the figure 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 CORBA software object. In spite of the apparent differences among the various devices (lathe, robot, storage table, etc.), these objects all support the same software interface: an OMG IDL interface called IDevice. This

M. Lei et al/Mechatronics 8 (1998) 271-285

Software i " " . . . . . .

I Fig. 5. Cell management software.

279

section presents a description of our IDevice interface. For brevity and for pres- entation clarity, an abbreviated IDL will be shown.

The first 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 other interfaces as follows:

• IBaseDev--naming and operational status for the machine • IAllocaDev--vontrolling access to the machine • IRunDev--running processing activities on the machine (machining a part) • IMovePart--transferring material in and out of the machine

interface IBaseDev { readonly attribute string DeviceClass; readonly attribute string DevicelD; readonly attribute string VersionString; readonly attribute string Status; long Advise (in Inotify hnotify); boolean UnAdvise (in long advisedlD); }; interface IRunDev { boolean Pause( ); boolean Resume(); boolean Abort( ); }; interface IMovePart { boolean SetPartner( ); boolean TakeFromPartner( );

280 M. Lei et al Mechatronics 8 (1998) 271 285

boolean GiveToPartner( ); ),.

interface ICellSeq { long Add Job (in string JobName, m string JobText, in string PartName, in lnotify WhenDone); void Pause (in long JoblD); void Resume (in long JoblD); void Abort (in long JoblD); boolean DeletJob (in long JoblD); boolean AddDevice }:

4.5. Integration of devices in a manujkwturin9 cell

As a CORBA object itself, the cell sequencer is also a client to the IDevice objects. This configuration can be seen in Fig. 6.

The cell sequencer dynamically attaches to devices, hence, no need to re-compile 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 for the sequencer, ICellSeq, is as follows:

interface ICellSeq { long Add Job (in string JobName, in string JobText, in string PartName, in INotify WhenDone); void Pause (in long JobID); void Resume (in long JobID);

I i I,

TRANSFER Staubli in Table Fanuc [ [

RUN Fanuc Machine, Part i [-~I Transfer Staubli Fanuc CMM [ . ~

RUN CMM Measu.l~xt J TRANSFER S t a u b l i ~

I Cell ~clucncer L~ Fig. 6. Cell sequencer manipulating several 1Device objects.

I I

Measurement [ Report

I I "----EMM

Lathe


void Abort (in long JoblD); boolean Delete Job (in long JoblD); 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 Add Job() 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 Part- Name, which identifies the part to be manufactured. The Add Job operation also takes an INotify object reference so that the sequencer's client can be notified of job completion or error conditions encountered. The return value of the Add Job() operation is of type long, indicating the assigned JoblD given by the sequencer; this JoblD 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 the 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(), RemoveDevice(), and QueryDevice(). Notice that there are two different 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 sequence 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 one of the strengths of using this type of distributed object architecture.

5. Intelligent open architecture for numerical control system

Open architecture controllers are designed to eliminate the problem of implementation by creating a flexible 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 whilst leaving the original axis and 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 [11~ 12] proposed a hierarchical open architecture CNC (HOAM-CNC) which provided an open platform for implementing machining algorithms. This system used a PC 486 with an off-the-shelf digital signal processing (DSP)board. The system used a multi- processor setup which 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 [13] is a Sun workstation VME bus-based system which controls a tree-axis machining center using off-the-shelf components for the axis and spindle controllers. The system also integrates touch probes, basic adaptive control for cutting, and interfaces with programs such as "Machinist", which is an expert system for setup and clamping procedures.

The implementation of control strategies to machining processes often requires the use of application-specific knowledge and procedures, i.e., skilled technology.

Normally, an intelligent machining will be found when the following procedure is followed:

• feed is maximized such that tool breakage is avoided; • depth of cut is maximized within chatter limit; • 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.

The overall control system consists of several control tasks operating under a small multi-tasking kernel. A real time 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 allow for a coordinates and unified control objective to be achieved.

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 four-bit binary signal applied to the override circuit will vary the actual tool feed rate between


0-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 defined 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, multi-tasking 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 five separate concurrent tasks. These tasks are: • the intelligent monitor's real time inference engine; • a signal processing task for force and vibration monitoring; • a force controller task; and • 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 offers many advantages for control applications. However, the inherent backtracking inference mechanism and its associated difficulties 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: • 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.

• 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.

• 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 multi-task system, the inference engine executes concurrently with the conventional control systems.

These are implemented in the C + + programming languages for fast and efficient execution. The uses of objected oriented C allowed for the development of a frame- based knowledge base while retaining the execution speed of C.

The prototyping system is developed in Huazhong University of Science and Tech- nology [21].

6. Conclusion

We have presented a distributed object CORBA framework for 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. Further, this architecture supports not only manufacturing automation, but human integration by providing console interfaces to manufacturing devices. We have defined and implemented a CORBA interface to a cell sequencer. The cell sequencer manipulates IDevice objects and coordinates manufacturing jobs on a shop floor. 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 our developed manufacturing software. The resulting architecture is scalable across a wide-area enterprise. Our future work includes adding support for a more information-intensive environment available at the shop floor. 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.

Based on this information infrastructure, or mass customization manufacturing system [32, 33] can be tested in these manufacturing devices.

References

[1] http://www.ims.org/holonic.htm [2] http://www.ims.org/ [3] Pun L, Artificial Intelligence System and Applications to Industrial Production Systems. Plenum, NY,

1986. [4] Mackulak GT, High level planning and control: An EDEFO Analysis for Airframe Manufacturing.

Journal of Manufacturing Systems 1984;3(2): 121 --32. [5] Shoham Y, Agent Oriented Programming. Artificial Intelligence 1993;60(1):51-92. [6] Genesereth MR, et al, Logical Foundations of Artificial Intelligence. Morgan Kaufmann, CA, 1987. [7] Baker AD, Metaphor or reality: a case study where agents bid with actual costs to schedule a factory.

In Market-based Control, Chapter 8, ed. S. H. Clearwater. World Scientific 1996;184-223. [8] The Common Object Request Broker: Architecture and Specification, OMG Technical Document

PTC/96-03-04, Object Management Group, Framinham, Massachusetts, July, 1995. [9] Smith CS, Wright PK, Cybercut: a World Wide Web based design-to-fabrication tool, Journal of

Manufacturing Systems 1996; 15(6):432 ~,2. [10] Altintas Y, A hierarchical open architecture CNC system for machine tools. Annals of CIRP,

1994;43(1):349-54. [11] Altintas Y, Newell N, Modular CNC design for intelligent machining: part 1: design of hierarchical

motion control module for CNC machine tools. Journal of Manufacturing Science and Engineering, 1996;118(4):506~13.

[12] Altintas Y, Modular CNC design for intelligent machining: part 2: Modular Integration of Sensor based milling process monitoring and control tasks. Journal of Manufacturing Science and Engin- eering 1996;118(4):514-21.

[13] Greenfeld I, Open system machine controllers the MOSAIC concept and implementation, Trans ACM 1989;18:91 7.

[14] Ditts, D and Whorms H, The evolution of control architectures for automated manufacturing systems. Journal of Manufacturing Systems 1993;12(1):79 93.

[15] Duffe NA, Distributed computing systems for multiple-processor industrial control. Annals of CIRP 1980;358-61.

[16] Duffle NA, Synthesis of heterarchical manufacturing systems. Computer in Industry 1990;14:167 74.


[17] Guan Zailin, Lei Ming and Yang Shuzi, Application of decentralized cooperative problem solving in dynamic flexible scheduling. Proceedings of the SPIE 1995;2620:179-83.

[18] Hasegawa T, Lin Guo, Luh PB, Holonic planning and scheduling architecture for manufacturing, CKBS94, Proceeding of the Second International Working Conference on Cooperating Knowledge Based Systems 1994. p. 125-39.

[19] Kao YC, Lin GC I, CAD/CAM collaboration and remote machining, Computer Integrated Manu- facturing Systems 1996;9(3): 149-60.

[20] Lefrancois P, Montreuil B, An organism-oriented modeling approach to support the analysis and design of manufacturing systems. Journal of Intelligent Manufacturing 1994;5(4): 121~,2.

[21] Lei M, Research on intelligent cutting monitoring and manufacturing intelligence cooperating. Ph.D. dissertation, Huazhong University of Science & Technology, 1995.

[22] Lei M, Tseng MM, Yang XH, Yang SZ, Agent-oriented analysis methodology in intelligent manufacturing system. The Fourth International Conference on Control, Automation, Robotics and Vision (1CARCV'96). p. 129~303, Singapore, December, 1996.

[23] Lei M, Tseng M, Su C J, Conen W, A Microeconomics Coordination Model for Mass Customization Manufacturing, Poster-proceedings of MAAMAW'97, European Workshop on Modeling on Auton- omous Agent in a Multi-Agent World, held in May 1997, Ronneby, Sweden, 1997.

[24] Lin GY, Solberg J J, Integrated shop floor control using autonomous agents. IIE Transactions, 1992;24(3):57-71.

[25] Luscombe AM, Toncich D J, Thompson W, Dluzniak R, A new type of machine control system to replace traditional CNC. International Journal of Advanced Manufacturing Technology 1994;9(6):369-74.

[26] Maffeis S, Piranha: a CORBA tool for high availability. IEEE Computer 1997, 59 66. [27] Mratin, H, Spooner DL, Data protocols for the Industrial Virtual enterprise. IEEE Internet Com-

puting 1997;1(1):20-30. [28] Mitsuishi M, Atamura Y, Nakao M, System construction for intelligent manufacturing. Proceedings

of the 3rd CIRP Workshop on Design and Implementation of Intelligent Manufacturing Systems, Tokyo, Japan, 1996. p. 51-66.

[29] Orifali R, Harkey D, The essential distributed objects survival guide: New York, John Wiley and Sons, Inc, 1996.

[30] Rober S J, Shin YC, Modeling and Control of CNC Machines Using a PC-based Open Architecture Controller. Mechatronics 1995;5(4):401-20.

[31] Staff Writer, Concept of IMS and its stagnant progress. Techno Japan 1990;23(11):48-63. [32] Tseng MM, Lei M, Su, CJ, Wang Wei, A market-like coordination for mass customization manu-

facturing. Proceedings of 6th Industrial Engineering Research Conference, IERC6. Miami Beach, Florida, 1997; 972-7.

[33] Tseng MM, Lei M, Su CJ, A collaborative control system for mass customization manufacturing. Annals of CIRP 1997;46(1):373-6

Documents

Design an intelligent machine center strategy and practice