WORKSHOP ON MANUFACTURING SYSTEMS INTEGRATION Conducted November 6-8, 1985, St. Clair, Michigan Sponsored by the National Science Foundation Contract No. NSF-G-DMC 8516526 Richard A. Volz and Arch W. Naylor Robot Systems Division Center for Research on Integrated Manufacturing College of Engineering The University of Michigan Ann Arbor, Michigan 48109

Executive Summary EXECUTIVE SUMMARY On November 6 through 8, 1985, the National Science Foundation sponsored a workshop in St. Clair, Michigan on "Systems Integration Techniques for Manufacturing". The workshop was organized and hosted by the Robotics Research Laboratory of the University of Michigan. The workshop was held because, while it has been widely claimed for some time that "integrated manufacturing systems" offer the potential for major increases in manufacturing effectiveness, as industry has attempted to achieve these benefits, it has become apparent that integrating manufacturing systems is an extremely difficult undertaking. Even the phrase "manufacturing systems integration" is not precisely defined but is roughly interpreted as the use of computers and communications to create highly interconnected manufacturing systems that perform as one harmonious system. The purposes of the workshop were (1) to assess the nature of the difficulty, and (2) to suggest a research program for addressing the difficulty. Forty internationally recognized experts in manufacturing automation took part in the workshop. These people came approximately equally from industry, government laboratories, and universities. The workshop participants were divided into eight working groups (Sensors and Controls, Cell-Level Planning, Factory-Level Planning, Databases, Communications and Networks, Systems Integration Software, Artificial Intelligence, and Economic Evaluation). Overview and challenge presentations were made in each of these areas, and each working group met privately to formulate recommendations. Not surprisingly, the panel called for additional research in a wide variety of areas. A lengthy list of detailed recommendations is presented in the body of this report. Somewhat more surprising, and an important outcome of the workshop, is the degree of commonality in the recommendations of eight different subpanels, in spite of the wide variety of areas involved. Noteworthy is the fact that, by and large, the panel called for fundamental work rather than attacking superficial symptoms of the problems. Also important is the relative importance of the individual recommendations, as evidenced by the degree of overlap among the individual subpanel reports. Overall, five clear categories of recommendations emerged: * A great deal of research is needed on developing a conceptual framework and theoretical foundation for manufacturing systems. * Closely linked to the first point above, research is needed to develop general, portable and reusable tools for integrating highly complex manufacturing systems. * Though not the major outcome of the workshop, there was a strong call for immediate standards in several areas.

Executive Summary * The role of the human in both the development and operation of integrated manufacturing systems needs greater consideration. * Better models of the costs and benefits of systems integration are needed. It was significant that although a majority of the participants had a technical background, there was still a strong call for work in the last two areas. Each of these areas is elaborated upon below. Conceptual framework and theoretical foundation. The need for research on a conceptual framework and theoretical foundation was expressed in many different ways, both through direct calls for a theoretical base and indirectly through calls for better modeling, control, and design (of processes as well as products) techniques, which imply a need for the theoretical developments. Specifically, the following major needs and research topics were identified: * A framework and vocabulary that can be used to discuss integrated manufacturing systems. * Better models for almost every aspect of integrated manufacturing systems, including: - models of errors and their relationships to sensor data - models at hierarchical levels of abstraction, so that people at different levels of an organization can work with a model appropriate to their level. - models that include functional, material, and relational information as well as geometrical data - models that describe the organization of the process as well as the product * New control architectures for integrating systems at several different levels. * A combined view of product and process design. * A theory of manufacturing systems, not just the development of many special cases. All of these specifics require a better theoretical framework for integrated manufacturing. One can trace industry's current difficulties with integration to the ad hoc nature of solutions being pursued and the lack of such a framework. Systems Integration Tools. The need for tools to deal with large, complex, distributed manufacturing systems was repeatedly stated throughout the workshop. Many aspects of systems integration will be possible only if new tools can be developed to provide the foundation for integrated manufacturing systems and to aid in the manufacturing process design itself. Among the major specifics identified by the workshop are: * Tools for dealing with large, complex, distributed, manufacturing software, such as object- and task-oriented programming, mechanisms for concurrency and timing, distributed programming, and configuration support.

Executive Summary * Tools for managing high-speed real-time distributed manufacturing equipment, e.g., - a high-speed "sensor bus" - databases that can support distributed real-time access * New database and knowledge-base tools, databases that can support inferencing across a broad range of data types (geometrical, functional, material properties, orders, inventories, relations among parts, etc.). * Tools for automatically generating and simulating programs for manufacturing equipment from design and other database information. * High-speed computer network communications that can support distributed real-time applications. * Artificial intelligence tools such as distributed problem-solving, uncertainty management, knowledge representation, and temporal reasoning Obviously, the development of these tools depends upon development of an appropriate theoretical base, but as elements of this theory are developed it becomes possible to develop some of the needed tools. Standards. The importance of standards to the realization of integrated systems was recognized, and a number of areas in which standards should be immediately developed and adopted were identified. These included: * Robot controller interfaces * Representations of primitive data types (such as integers, floating point numbers, characters) for data interchange * Communication protocols for ISO/OSI level 3 and below. However, it was noted that standardizations occurring too early can stifle innovation. For example, many (but not all) felt that it was too early to standardize robot programming languages at the user level. In general, it was felt that both research and standards are important, and that one has to be careful to choose the right time for developing standards. It was significant that the theoretical issues received much more attention than pure standards development. The Human Interface. Although the participants were technologists for the most part, it is important that many raised the issue of the role of people in integrated manufacturing systems. Issues such as user interface design were raised. But more generally, there was a call for research on a better understanding of what a human can and should do in the factory of the future. However, the composition of the workshop limited the scope of discussion on this topic. Economic Models. Almost every group expressed a need for better measures of the benefits and costs of integrated manufacturing systems. This is, of course, really part of the needed conceptual framework, but groups tended to call for the two separately. Of particular concern in this area was identifying all of the interactions involved and their impact on the overall economics of the company,

Executive Summary not just production cost. How does increased systems integration affect product quality, consumer desire, field service costs, and time to reach market? In summary, while the workshop brought ot many specific areas that need research or standardization, a perhaps surprisingly large part of the deliberations pointed to the need for theoretical research. Without the foundation that such research will provide, industry will find it difficult to interconnect and integrate those famous islands of automation.

CONTENTS 1. INTRODUCTION 2 2. KEYNOTE ADDRESSES "Contemporary Manufacturing Systems Integration," Kenneth Ruff, GM 5 "Some Problems We Share," James Solberg, Purdue University 18 3. CONCLUSIONS AND RECOMMENDATIONS Sensors and Controls 26 Cell-Level Planning 30 Factory-Level Planning 34 Databases 37 Communications and Networks 39 Systems Integration Software 42 Artificial Intelligence 47 Economic Evaluation 51 APPENDICES: A. Program Schedule 55 B. Roster of Participants 58 C. List of Papers Presented 63

1. INTRODUCTION 1

Introduction INTRODUCTION Systems integration is a topic of great concern to U.S. industry. It has been widely claimed over the past several years that integration of manufacturing systems is the key to major increases in manufacturing productivity, quality, and rapid response to market demands. What has become apparent, however, is that such systems are extremely difficult to integrate. In the belief that it is now important to examine closely the reasons for this difficulty, the National Science Foundation sponsored a workshop to study the basic issues in manufacturing systems integration and recommend a course of action to address the problem. The workshop was organized and hosted by the Robotics Research Laboratory of the University of Michigan and was held on November 6-8, 1985, in St. Clair, Michigan. To focus the discussions that would take place and to try to ensure that useful results were obtained, a short list of basic questions was prepared and presented as a charge to the workshop participants: (1) Systems integration is not a well defined term. What does it mean in your area? (2) How much systems integration is desirable? Will it really be a major aid to manufacturing, or has it been oversold? (3) Is systems integration taking place at an unnecessarily slow pace? (4) What research would be appropriate for NSF to fund under the heading of systems integration? Characterize the difficulty of the problems, and if possible, group them into a small number of priority levels. (5) Is the necessary work in systems integration primarily research, or is it standards work? Manufacturing systems integration involves a wide range of technical topics. In addition to addressing the specific questions raised above, the workshop had an implicit goal of bringing together people from diverse areas so that they might become acquainted with broader views of systems integration problems and perhaps find common problems and/or solutions. Forty internationally recognized experts in manufacturing automation were invited to take part in the workshop. These people came somewhat equally from industry, government laboratories, and universities, both from the United State and abroad. The workshop participants were divided into eight working groups (Sensors and Controls, Cell-Level Planning, Factory-Level Planning, Databases, Communications and Networks, Systems Integration Software, Artificial Intelligence, and Economic Evaluation). The workshop was organized to have four kinds of complementary activities. Formal presentations reviewed the state of the art and stated challenge positions 2

Introduction for debate in each area. The state of the art reviews were intended to acquaint participants with the broad range of technical areas involved in manufacturing systems integration. Working group meetings were held to prepare answers to the above questions in the context of the specific areas of the working group. Full workshop discussions and deliberations gave all of the participants an opportunity to be involved with the whole spectrum of technical areas involved. And informal discussions among the participants were a step toward building a community of researchers and practitioners interested in the broad ramifications of manufacturing systems integration. Appendix A contains a copy of the agenda for the workshop, and Appendix B contains a list of the attendees. As a basis for initiating discussion, the following definition of systems integration was offered as a straw man: Systems Integration is the bringing together of two or more systems, be they information systems or physical systems, such that the resulting system is capable of modes of operation not possible with the individual systems. With minor variations, the workshop panel accepted this definition. Two keynote addresses were presented. Ken Ruff of General Motors Corporation presented an excellent overview of manufacturing systems integration to set the tone for the workshop, and Prof. James Solberg of Purdue described some of the cultural difficulties (and proposed solutions) we, as engineers, face in representing our work to the public at large. Both talks are presented in their entirety in the next section of this report. The major section of the report, Section 3, summarizes the results of each of the working groups. As might be expected, there were both areas of considerable overlap in recommendations and areas of disagreement. These have been left intact. The degree of overlap is a weighting on how important the panel felt a recommendation was, and the extent of contradicting opinions indicates the degree of uncertainty in the correct answer. Rather than repeat or summarize all of the formal presentations and open discussions that took place (which would be far too verbose for easy reading), we present selected quotations from the talks and discussions to present the key ideas that arose. Many of the speakers did bring written papers of their presentations. These are available from NSF. Appendix C contains a list of the materials available. In addition, all of the full workshop sessions were audio recorded. Transcripts of these sessions are also available upon request. Finally, the keynote addresses and final summary presentations were video recorded. The video recordings are available. 3

2. KEYNOTE ADDRESS CONTEMPORARY MANUFACTURING SYSTEMS INTEGRATION Ken Ruff SOME PROBLEMS WE SHARE James Solberg 4

Ruff Keynote Address CONTEMPORARY MANUFACTURING SYSTEMS INTEGRATION Ken Ruff INTRODUCTION For the past decade, we have been watching the U.S. industrial base lose its position as the dominant supplier to many international markets. We are no longer without peer in the production of automobiles, television sets, computers, video recorders, locomotives, machine tools, earth-moving equipment, or steel products. Indeed, in some of these areas, we have no significant share of the market at all. The stark realization of our diminishing industrial stature has take us from complacency through confusion to the brink of panic...and ultimately to analysis. As we gathered facts and assessed the situation it became clear that our prices were too high, our quality and reliability was too poor, we didn't understand what our customers wanted, and couldn't respond very quickly when we did. In attempting to determine why, we discovered flaws in the performance of all of the major players —politicians, managers, and educators. Our society in general is trying to sort out the problems of these groups of people and their associated institutions. We are here today to examine one particular technical issue associated with this dilemma. RATIONALE FOR MANUFACTURING SYSTEMS INTEGRATION That issue is manufacturing systems integration. What does this term mean, and what does it have to do with our waning industrial dominance? Manufacturing systems integration is the process of assuring that all the elements of a system-manufacturing equipment, computers, and people-work together to achieve the system purpose. If our factory systems lack this coherence they will have slow response times, produce poor quality output, utilize equipment ineffectively, and generate excessive costs. In contrast, if we learn to design, build, and maintain wellintegrated systems, we can expect significant improvement m all these measures of performance. 5

Ruff Keynote Address Well-integrated systems have smoothly functioning interfaces. Information passes quickly and accurately from one sub-system to another. Parts and tools move from one orientation and location to another when needed. If the system has these characteristics, and its components have a measure of multi-purpose functionality, then we have a responsive system —one that delivers the products customers want when they want them. Control of product quality is also enhanced by the timely information feedback provided by integration. Integration helps to assure that process deviations are recognized when they happen-there are no long delays at the interfaces between the sensors and the decision point. The person or the machine that needs to decide what to do about it gets the message quickly, and when he responds with an order for corrective action, that too happens quickly. Our loss of competence in quality control is more a matter of lack of attention than lack of information. The ability to generate defect reports is spectacular. It is the ability to react quickly and appropriately that seems to be the major weakness. High quality is also supported by effective integration of product and manufacturing engineering. The plant makes the product-so plant and product must be developed concurrently. This means that the engineering-manufacturing interface needs to be more like a porous membrane than a stone wall. Integration also attacks under-utilization. Machines are idle either because they are unable to run, or because there are no jobs to be done. In the first case the idle time is due to repairs or to changeovers. The time interval from the first awareness that a machine is down until repairs are completed and the equipment is restarted can be minimized in an integrated system. Attention can be quicker, diagnosis can be faster, the marshalling of maintenance tools and spare parts can take less time if the support system is well integrated. Changeovers are impacted in a similar manner. The situation in which machines are idle because there are no jobs to be done-if not simply due to a declining market —is frequently due to a failure in coordination or synchronization, fundamentally an integration problem. Lower labor costs and inventory costs are other potential benefits of factory integration. Well-synchronized production activities and the timely information flow across the plant-supplier interface are essential in order to make "just-intime" a reality instead of a buzz-word, and thus keep inventory costs to a minimum. The more effective decision-making and the faster information flow within an integrated system helps to focus people on the problem of the moment rather than the problem of yesterday. Thus, the use of labor is more effective. 6

Ruff Keynote Address SCOPE OF INTEGRATION OPPORTUNITIES Altogether this evidence concerning response-time, quality, utilization, and costs offers the promise that manufacturing systems integration may indeed provide a partial approach to the renewal of U.S. industrial vigor. During this workshop we will be trying to determine where, when, and how manufacturing integration can be built into our industrial base. We will try to discern how much this is a challenge in technology transfer, and how much it may depend on sound programs of basic research yet to be launched. We will be focusing intensely on a few targets of opportunity —recognized critical functional areas of all manufacturing plants. One of these targets is near the very base of the manufacturing hierarchy-right at the floor level, where traditional machines are combined into new functional units. The least extensive of such combinations has recently come to be known as the manufacturing cell. While it is a concept that is still being formulated, a consensus definition is emerging. The cell has come to be viewed as a fundamental building block of manufacturing systems. Like a biological cell, it is the smallest unit capable of sustained productive activity. It is an autonomous work station that can continue to function without assistance as long as materials are supplied and completed work is removed. It has sensory and decision capability sufficient to verify the quality of its output and recognize deterioration in its physical condition. Among the specific types of cells being implemented at GM's Saginaw factory of the future are several turning cells. A turning cell does about the same thing as an operator and a lathe might have done in the past. Its centerpiece is an NC lathe equipped with an automatic tool changer. It has a parts washer so that machined parts can be cleaned before they are inspected. The inspection itself is done by a gaging subsystem. This can determine that the dimensions produced by the lathe are within the specified tolerance. The part handling necessary to load and unload these devices is done by a robot. It gets raw workpieces from a parts tray in which they are carefully arranged and returns the completed parts to the same tray. The trays are picked up and delivered by an automatic guided vehicle. A cell control computer coordinates the activities of the devices. It assures that the movements of the robot and the lathe cooperate in the part-loading activity; that the readings of the gage are available to the lathe for tool compensation; that a tool change is initiated if the tool is broken or too worn for effective use. In addition to coordinating the devices during routine production, the cell controller also orchestrates the changeovers. If different parts are to be processed, different programs must be used, and different tools —robot grippers, 7

Ruff Keynote Address cutters, chucks —need to be loaded, attached, and calibrated. The cell controller must also continually monitor the state-of-health of the cell devices and determine their capability to perform effectively. If a spindle bearing overheats, a gage drifts, or a robot axis senses excess following error, the controller must behave appropriately-even if this means no more than suspending operations and calling for help. If help is called-or if for any other reason manual intervention occurs-the cell must be able to communicate intelligently with maintenance and setup people. During normal automatic operation it must communicate with the higher-level factory control system, and, at least for hand-off purposes, withi the automated guided vehicle system. This cellular concept is also beginning to be applied to assembly operations. This assembly cell combines the capabilities of two robots and a vision system to assemble a shaft and housing. Vision is used to assure alignment of the spider with the tripot housing prior to insertion. The robots do a hand-over-hand manipulation in completing the task. While the turning cell and the assembly cell do distinctly different things, they have a number of common functions. We can easily identify these similarities. Both cells display a high degree of autonomous behavior. They do their particular task continuously without any outside help over significant periods of time. Each of these cell types operates effectively by virtue of control structures that provide for close interaction among the cell devices. The individual device actions are sequential, but the several devices move in parallel. They must be coordinated asynchronously, since there is variation in the subtask times. Each of these cells must be sensitive to its own condition. They do not rely on external agents to notice that something is wrong. Cell monitoring components need to pick up sensory information from the devices and exercise enough perception to recognize that the cell is disfunctional, or at least in jeopardy of becoming so. In spite of their high degree of autonomy, each of these cells must frequently interact with its environment. They are told what to do by a high-level controller. They take direction and supply data to people involved in maintenance or changeover activities, and they communicate with peer systems, particularly the part and tool supply systems. Cell development offers one of the most important opportunities for manufacturing systems integration. In looking above the cell level, however, we seem to see the structure less clearly. There is certainly somewhat less of a 8

Ruff Keynote Address consensus as to the shape of things above the cell. All CIM definitions specify levels of control. Terms such as area control, supervisory control, floor control, shop control, and factory control are used with different meanings whenever integration is discussed. This apparent confusion seems to be due to the differing ideas as to what a typical manufacturing facility really is. Some of us are thinking job shops and some flow shops, some high volume and some low volume, some sheet metal and some mass metal; some iron chips and some silicon chips. Certainly, there is no reason to believe that a single factory architecture will suit all these needs. Hopefully, however, whatever the details of the superstructure, it will have some variety of characteristic forms. One of the simplest to discuss is the obvious supercell, a system which links many cells together to form a manufacturing unit for carrying out a complete process. The array of cells must be linked together with a material transport system to assure that each cell has, as near as possible, a continual supply of parts or assemblies on which to operate. In order for this flow of materials to be purposeful, the control system must coordinate the assignment of cell processing orders with the material movement. To do this it must have a model of the processes for creating and assembling parts as well as demand objectives. Given these minimal functions, our plant can produce-but only in a very rigid fashion, and only for a very short time. More is needed to sustain flexible manufacturing. Tools must be prepared. External assistance will frequently be required in reconfiguring cells to perform different task assignments. Equipment must be maintained, and sometimes repaired, if we are to have a robust system. Systems to perform these functions need to be appended to our simplified linked-cell array before we can call it a fully integrated factory system. This done, we have defined —in one of many possible ways —a logical extension of the manufacturing cell, and thus identified a second target of opportunity for manufacturing systems integration. A third target of integration is the engineering-manufacturing interface. Because the manufacturing system is almost always a system-in-being-a continually changing entity-the process by which it is created and modified is a fundamental concern. Manufacturing integration begins with system design. Cells are designed and built to perform operations for manufacturing products or families of products. If this is done well, it sets the stage for the concurrent development of cell coordination and device control programs, and the specification of any special tools required. This one facet of the engineering-manufacturing interface carries 9

Ruff Keynote Address the information —up as well as down-that facilitates efficient modification of cell functions. This activity is crucial to manufacturing flexibility. In a similar way, factory control depends on the engineering system for its process definitions. The routings, process times, and tool requirements are the basis for work dispatching and follow-up. THE CURRENT IMPACT VS. THE POTENTIAL Overall there is great potential for utilizing the concepts of integrationmanufacturing cells, factory control systems, and carefully developed engineering-manufacturing interfaces-in our plants. Where are we now with respect to these ideas? What is really going on now as far as integration is concerned? The cell concept is beginning to influence new manufacturing facilities. The Fanuc Motor Plant has gained world wide attention as a showplace of automation. The machining activities on its main floor are built according to the linked-cell architectural concept. Its individual cells fall largely within the definition I have used earlier. There are many other smaller-scale examples of the use of machining and processing cells-especially for rotational machining-in Japan, Europe, and the United States. General Motors Saginaw Factory of the Future Pilot is entering the implementation phase. It will be a proving ground for several types of cells. When it becomes operational, this factory will produce shafts, spiders, and tripot housings of several sizes and shapes. These parts, along with a number of purchased parts, will be assembled to form complete front wheel drive axles. Several types of metalworking cells and a system of assembly cells will be necessary in order to carry out this mission. All of these cells will conform to the definition presented earlier. Most of the cell-like systems actually making parts today are to be found in flexible machining systems. FMS architectures vary considerably, but in some cases their work stations tend to conform to the cell definition. They keep going as parts keep coming; they transform parts, they measure resulting part dimensions; they are partially self-diagnosing. However, in many cases, FMS work stations embody these capabilities in a single machining center. The interaction among cooperating devices, which is perhaps the most distinguishing characteristic of a cell, is missing. Right behind the machining systems, assembly cells are appearing in our plants. Today, the assembly line as a basic architectural unit is being challenged. Modular assembly based at least loosely on the cell concept is making inroads even in high-volume assembly environments. It lends itself better to handling 10

Ruff Keynote Address product variation, promoting a quality focus and engendering increased worker participation. The movement toward manufacturing integration at the factory control level has been approached from the top down and, more recently, from the bottom up. And, I suppose, FMS technology approaches from a midpoint. Currently, the top-down approach is by far the most prevalent. It grew out of the 1970's intensive plant monitoring movement. At the time it was believed that if we could only capture more shop floor information, we could run our plants better. Results prove this to be at best a half-truth. A new requirement for decision support then became the rallying cry. This helped, but the factory remained poorly controlled. Given this history, it is not surprising that the top-down approach has been taking on the aspects of a monolith. It tends to organize the plant according to the device type, or more precisely according to the proprietary programmable control vendor sub-nets-Modbus, Data Highway, etc. It does not lend itself particularly well to supporting lower-level integration constructs like the cell. There is currently a readjustment taking place, as proponents of this approach search for a graceful migration toward a more functional architecture. The bottom-up approach is based primarily on functional integration. It is becoming the dominant theoretical approach for greenfield manufacturing systems. However, there are too few examples of significant scale actually in operation for anyone to feel confident that it is necessarily the better practical approach. The Saginaw Factory of the Future architecture employs this functional organization to a considerable extent. We should know sometime late in 1987 how well it really lends itself to the control of integrated automatic manufacturing. Most of the 50 or so flexible manufacturing systems currently operating in the U.S. resulted from a third approach to integration. They were conceived before the robotics industry took off, and before machine vision systems were generally available. In contrast, the machining center was already proven as a viable component. As a result, part handling and process verification functions are frequently displaced from the basic metal-working function they support. Often this creates a greater degree of workstation interdependence than we would like to see. FMS experience, however, has exposed many of the mechanical interfacing problems. It has also provided some recognition of the difficulties of monitoring and controlling multiple work-streams. Most of all it has shown that flexibility in the physical linkage of workstations is feasible and valuable. Partly as a result of this, material handling is a segment of the manufacturing activity that appears ripe for widespread plant-wide implementation. Automated 11

Ruff Keynote Address guided vehicles and automated storage systems are beginning to appear in our plants with increasing frequency. They provide an important integrative influence. AGV's make it easy to link cells into a supercell. They are the major adhesive for physical integration. Analogously, the local area network is the essential base for information integration in our plants. Whatever technical limitations MAP-the manufacturing automation protocol-may have, it has focused most of the manufacturing engineering community on a fundamental prerequisite for factorylevel integration. While interconnection is not integration-and neither is message passing-both are essential to meaningful and timely communication among manufacturing subsystems. Overall... factory-level integration has barely begun-but it has begun. Some of the essential enabling technology is becoming widely available. We have reached a position where concentration on substantive problems is now possible. This is a remarkably good position, compared with where we are in perfecting the engineering-manufacturing interface. At this time that interface is nothing like the porous membrane we need. It is a solid wall with a few small windows beginning to appear. Product data is still translated into manufacturing data-usually too late. People are trying to engineer simultaneously, but the product and manufacturing subcultures tend to clash. It takes extraordinary efforts like the Saturn program to realize the potential of simultaneous engineering. The promise of CAD/CAM is still unrealized. Even though a new industry has been created. Even though drafting is becoming passe, and engineering analysis is now easier, CAD/CAM is still CAD?CAM. The vital interface linking design and manufacturing is still a barrier. Process planning, tool design, and NC programming are rarely done as take-offs from the product model. In most of the mechanical products industry, the product definition within the design files cannot be used easily for any of these purposes. There is a promisinm start in the use of tools for cell design and robotic programming. As the robot count has risen, the practical limitations of pendant and joy-stick teaching have been recognized. The graphics technology which supports CAD/CAM is being employed with sharper focus on the problem of laying-out the robot's work area, investigating reach and collision problems, and preprogramming robot moves. In spite of many current limitations, systems of this type are proving extremely helpful to manufacturing engineers in designing manufacturing and assembly cells. 12

Ruit Keynote Address ROADBLOCKS TO INTEGRATION Clearly, from an overall standpoint, U.S. industry has hardly started on the job of manufacturing systems integration. This workshop is a good place to evaluate this tortoise-like progress and ask what's holding us back. The major raw materials of integration are people, technology, standards, and methodology. Let's focus first on the people who must design, build, and operation integrated manufacturing systems. How well prepared are they for this challenge? My answer is-not very well prepared. Some people know how to run our current, out-of-date, fragmented operations. Some people understand the computer technology and control dynamics that we believe to be important for designing better systems. Some people understand metalworking, or assembly processes, or material handling and control. Generally, however, our people lack breadth of knowledge, depth of knowledge-or both. We have experts and we have generalists, but we have too few people who combine some depth of understanding of a particular function or discipline with a broad understanding of the relations among the various manufacturing functions. This is one of the principal reasons why efficient team activity is difficult. Planning and designing a major integrated manufacturing system requires both breadth and depth. Since no single individual has the knowledge or capacity to do the job alone, teams must be formed. However, any team will require a long and shallow learning curve unless there is a considerable body of knowledge that the team members share, in addition to the special knowledge each one possesses. The difficulties of engineering a system are further compounded by the scarcity of people skilled in applying system dynamics to manufacturing. Because there is very little intuition available, simulation becomes the primary fall-back. The approach is very much cut and try, with a simulation model as the object of manipulation and evaluation. Stating these limitations of knowledge and skill is perhaps just another way of saying that experience in manufacturing systems integration is lacking. But building experience is a long and costly process. We ought to supplement it with an analysis of the knowledge deficiences, and then design an educational process to reduce them as rapidly as possible. The second major component of manufacturing systems integration is technology. We need to ask how well the current base of technology can support the building of integrated systems. It is only due to relatively recent advances in computer technology that we dare even ask the question. 13

Ruff Keynote Address The ability of machines and systems of machines, and people, to communicate among themselves is a prerequisite of integration. Until very recently most machine-to-machine communication was difficult and costly. The situation has not completely turned around, but we can at least see ahead to the time when machine-to-machine communication will be easy and cheap. The currently defined manufacturing automation protocol is suitable for tying together the intermediate and upper levels of the plant hierarchy. An extension, which allows a similar degree of standardization, while providing for the shorter response times required at the cell level, is needed. Until it becomes available, integration efforts will be slowed by the special protocol requirement of each cell. For the most part the device controls available for today's machines were not designed with integration in mind. They are based on stand-alone N/C, or robotic record-and-playback specifications. They frequently lack robustness. In some cases they are overly complex. OEM's recently have begun to respond to interest in manufacturing cells by adding cell control features to their machine controllers. From the other direction, attempts are being made to create cell controllers based on programmable controllers, and from general-purpose minicomputers. As yet, however, the marketplace offers few if any completely suitable cell controllers. Many lack true control functionality, even though their monitoring capabilities may be extensive. The coordination of interacting devices has not been seen as a crucial requirement. In summary, cell controllers available today are usable for relatively high-risk development projects. They do not yet provide a component to be used by a manufacturing engineer attempting to build an integrated system on budget and on time. Technology also limits factory-control-level development. Distributed computing lacks definition and structure. The relational database model has provided a focus for research and development of factory databases and database managers. The potential for distribution of computing functions among the elements of the factory, however, has created a demand for a networked database. The market is not yet able to satisfy this demand. As a result, factory integration efforts must today include significant pioneering in data distribution and network access. More than this, the whole architectural substrate of computing —data, language, control, and communication-needs revamping to really suit the manufacturing environment. We are stretching things when we try to build integrated manufacturing with building blocks largely conceived during the infancy of the computer age. The conventional software world of Von Neuman languages, subroutines, datasets, and operating systems has limits in the level of complexity it can handle. In manufacturing systems, it has reached those limits. We will remain weak in our ability to create integrated manufacturing systems until the 14

Ruff Keynote Address computer industry succeeds in migrating to a higher level of abstraction-object based, knowledge based... or whatever. Standards are extremely important to efficient systems integration. The design and implementation of a major manufacturing system requires the cooperative efforts of hundreds of people in scores of companies. Whenever good standards are available they can simplify this interaction significantly. Conversely, clinging to ancient, irrelevant standards can severely retard progress and strain budgets. The fourth kind of limitation we should look at is methodology. Millions of dollars and thousands of man-years have been expended to create a methodology for manufacturing integration. However, when we try to employ the results of these efforts, we soon find that they are a weak support to our integration efforts. Generally, we have some pretty good methods for analyzing current manufacturing activities. People make reams and reams of "as is" functional models. At the other end of the process, once we have a concept of a "to be" manufacturing system, we have pretty good weapons for simulation modeling. You can buy simulation systems that make the modeling easy and provide good support for evaluating the results of simulation runs, up to and including animated color graphics. But between an understanding of yesterday's manufaeturing and a design evaluation for tomorrow's system lies the mainstream activity of specifying and designing that new system. Here the methodology is extremely weak. No doubt this is the innovative job-the hard cerebral nut to crack. But either we must breed more geniuses or create a teachable methodology for this task. For now, at any rate, the lack of a methodology of synthesis is a serious barrier to progress in manufacturing systems integration. During the course of this workshop we should be discussing the limitations of people, technology, standards, and methodology that I have just outlined, and perhaps a number of others that we will identify this week. A STRATEGY FOR ACCELERATING INTEGRATION Overcoming these barriers is the key to accelerating the rate of implementation of integrated systems in U.S. manufacturing plants. This is the target toward which we hope to direct a strategy. We can identify three major thrusts of an overall strategy —education, research, and consensus building. 15

Ruff Keynote Address Educating people to undertake significant roles as architects, designers, and implementers of integrated manufacturing systems is, in my opinion, the most important task. Within the last few years the academic community has begun to turn itself toward this task. The factory and the faculty have come face to face. This is a start. They need each other. Educators have the major role. They can deal with the problem of imparting depth of knowledge. They have the know-how to draw upon the physical sciences and symbolic arts and develop curricula suited to teaching manufacturing engineering and computer science topics that must form the primer for our system builders. They can also develop skill and appreciation for system dynamics and, if they have access to appropriate simulators, may even impart some essential intuition in their students. Industry can cooperate by building or supplying plant simulators. There is also a more direct role for industry in the educational process. They must orient the young manufacturing engineer to their business and their particular technical systems. They most allow time and money for learning in the manufacturing setting. Apprenticeship in systems integration is by no means a natural process. It requires that experiences which are meaningful be reinforced with instruction which reveals the context of the experience —its relationship with the whole manufacturing environment. The second attack on integration should come from the research community. There are four areas of research and development which seem to deserve major attention. We need to continue to probe the needs and the means for automatic control and coordination in the factory. This should include the search for better control structures for the highly interactive, fast-response activities at the cell level. It should also encompass efforts to define and explore the broad multi-modal coordination at the factory level. The variety of architectural schemes must be explored and evaluated, so that system builders can have more options available, and more hard data with which to make design decisions. A second field of investigation should cover the allied area of the manufacturing system's health care delivery system. Here we must find better ways to help people discover, diagnose, and repair the complex components of our integrated systems. We expect the factory to be able to function in spite of failures. But while adaptation strategies may contain failures to a local functional area, recovery speed will always have a significant impact on overall system performance. In addition to these research probes of the manufacturing system itself, we need to have continued work in the supporting technologies-particularly computer technology. We need a computer environment that is distributed throughout the plant, an environment that enables us to work at a level of abstraction as high as 16

Ruff Keynote Address the scope of manufacturing is wide, one that is fundamentally parallel rather than serial, one that supports system extension and the addition of subsystems as routine events, and that is functionally fault tolerant. Research is ongoing in all these areas. I believe the researchers will find familiarity with the manufacturing scene to be an effective stimulant to their creativity. As a final component of a research effort in manufacturing systems integration, we need to review what has been done to create a methodology for dealing with integrated systems, and try to outline the weaknesses and find some new approaches. The emphasis probably has to shift from documentation to team interaction, and from analysis to synthesis. In addition to the educational and research activities just outlined, a complete strategy needs to include vigorous effort to define appropriate standards and build a consensus to use them. We have made good progress in the communications area. The MAP effort can serve as an excellent model. It has been able to achieve consensus on a complex set of protocols for communication among manufacturing computers. As it continues it will no doubt deal with communication among devices requiring faster response times, and perhaps tackle the problems of standards for communication with mobile devices. However, above the seventh layer of the ISO model there is more fertile territory for standards and guidelines. To carry integration progress to a point of exponential growth, there will need to be agreement on some of the key functional building blocks and the interfaces among them. Some kind of architectural guidelines are crucial to the development of appropriate commercial software and hardware for use in manufacturing. CONCLUSION This kind of a three-pronged strategy will need to be undertaken cooperatively by the industrial and educational communities with the support of appropriate governmental agencies. If these resources are combined, the U.S. can regain its position as the world's most productive industrial nation. Manufacturing is the challenge of the next decade. Building integrated manufacturing systems is a fascinating pursuit. It is a rich arena that can absorb the intellect and energies of the academic and industrial community in a mission of unparalleled important to the economy. Our skill in playing this game may well determine our future as an industrial power. We have the opportunity to help write the game plan. So... let's get to work! 17

Solberg Keynote Address SOME PROBLEMS WE SHARE James Solberg I'd like to talk about some problems we share. By "we" I mean not just the people in this room but everyone involved with advancing of technology —people who believe that technology can solve some long-term problems. The "they" is all the rest of the world. We ought to realize that we're surrounded by an environment populated by people who don't understand technology and who distrust it. They don't know what makes us tick, perhaps even fear what we're doing. With that introduction, let me discuss five problems. First, the public doesn't understand the problem very well. By the "problem" I mean the very basic thing we're trying to do: improve productivity to get more wealth generated in the world, so that there's more to go around. That gives us the opportunity for justice and freedom and all the other things that civilization stands for. We don't say that very often. We tend to look like we're just playing with our toys, and sometimes we don't get across this message that we're really doing a more serious duty here. Second, there is a fear of technology. It goes beyond benign neglect. It's something that people really do fear. Thirdly, we have not expressed what we want to do, even among ourselves. That's partly what this conference is all about. But beyond that, we haven't expressed it to a wider audience. Fourth, we don't collaborate sufficiently. Again, this conference can be taken as an example of collaboration. But if you put that in the wider context of what's going on in the rest of society, if you think about the way the lawyers or doctors get together and speak with a single voice, we don't have anything comparable to that, and probably should. And, finally, we have insufficient resources to do our job. All of these things are linked, of course. If you begin looking for causes and effects, you run around in circles. Part of the reason we don't have sufficient resources to do the job is that people fear technology and we don't express ourselves very well, and that's partly because we don't collaborate enough, and that's partly because we don't have sufficient resources, and we end up competing for what we have, and so forth. To break those cycles, it seems to me the most appropriate place to start is trying to express what it is we're doing. And I'm not going to try and do that tonight. But I'll give you a few thoughts that would be productive, particularly with respect to this larger public-the people who don't understand very well our language when we talk among ourselves. It seems to me, although we don't often 18

Solberg Keynote Address think about it this way, we are operating in the belief that technological progress is good for humanity. If you took a survey and said "Technological progress is good for humanity-do you agree or disagree?", I think engineers would always strongly agree with that and say why do you even ask that question? But there are people in the population who really don't believe that technological progress is good. A lot of people say it's bad. There are these people who read their astrology charts regularly. There's a lot of those people. And of course, in the case of manufacturing, we're all operating under the assumption that greater productivity is something that's good for everybody. It's sometimes put in nationalistic terms-that we want to compete with the other countries, and so forth. But you don't have to argue that way. You can put it in global terms, that what we're trying to do is just create more wealth out of less, and that's an inherently good thing to be doing. But of course that's a long-term argument, one we rarely question. Of course, people who feel threatened by technology are fearful of more shortterm things, immediate threats to their way of life. So, it's my theory that this has something to do with our educational system, that somewhere along in the grade school or high school, a significant fraction of our population encounters some difficulty with science or math and starts putting up psychological defenses for why that's not important to them. My own feeling is that it has more to do with the teaching than anything else. But, regardless, it's a deep-seated psychological kind of thing which ought to be recognized for that; it's not something we can argue them out of. They, I think, rationalize, perhaps with parental support, that they don't really have to know science and math and all these technological things. They even get to the point of mocking the people who are good at it-you know, the nerds and so forth. This whole technological revolution is sometimes regarded as revenge of the nerds —people who in school were doing that science/math stuff. I'm talking about us, of course. Part of the reason I can think this way is that I went to Harvard, where the people at MIT were thought of in this way. So I know both sides of this. But now I'm proud to be an engineer. I feel that it's the proper thing to do. Now there's a long-term correction to this, perhaps, in changing our school system. But I think more short term; we have to realize that in dealing with these people, we are dealing with psychological barriers, and it doesn't do any good to present statistics or charts or quantitative models or any of the normal ways that we have of dealing with problems. Some of these people are very, very bright. In fact, our country has seemed to develop a class of lawyers and accountants and managers and so forth who have no technological base whatsoever-some of the brightest people we've got. And 19

Solberg Keynote Address there's something sad in all that, I think. Since I've been in this position at Purdue the past three or four years, I seem to get a lot of public relations opportunities that are not particularly welcome to me, but I get a lot of journalists coming and asking about the factory of the future. About once a week I get this question, what about the jobs? Journalists tend to be these humanities-oriented people who don't understand the technology. They're the ones who write about all of it. They are psychologically uncomfortable with it, and you can see it in their faces after talking to them for about twenty minutes about the really radical changes that I see coming in manufacturing in the next five years. It starts to show up in their eyes, and the question comes out, "What about the people in the jobs, and the employment? I used to give these two answers, which I now say are bad answers. The obvious thing is to say technology has always created more jobs than it destroyed. That is historically true and can be documented. Through history we've had advanced technology, and there have been more and more jobs created. But of course that's not what they're asking. They aren't concerned about jobs in some global, historical sense. They're concerned about their own jobs, and their families'. So that's not a satisfying answer at all to people like that. And furthermore they shed that answer because in the short term they don't believe it, and quite correctly. Their response tends to be, "If you're not eliminating jobs, why would you do it?" Presumably, if you install automation, you're doing it to save costs somehow. It makes common sense that you wouldn't go out and buy a robot if you weren't going to be able to fire somebody. You have a hard time getting past that barrier. The second answer I used to give for awhile was that we must eliminate jobs in order to compete with other countries that have much lower wage rates, and that's kind of a telling argument. People will sort of agree with that. It's better to lose a few jobs than the entire factory, or the entire industry. But they sure aren't happy about it. They go away sort of gloomy about the whole prospect. That's not the right environment to promote additional resources or speeded-up action. I suggest these are bad answers, and when you get this question yourself, I suggest you stay away from those answers. I have a better answer. Let me try to give what I think is a cogent argument for automation which does not require the elimination of jobs. I'm going to give you some charts, that you can play with yourself to maybe convince yourself of the truth of this statement that the principal motivation for automation is really to extend the workday, not to save labor. In batch manufacturing, which is 80% of the value of durable goods manufacturing, most operations are single-shift operations. They work eight hours a day. Because of the need for human attention, people don't want to 20

Solberg Keynote Address work at night and weekends. They get tired and want to go home. There is a penalty for multiple-shift operations, but it's not a heavy one. Really it's just that people don't want to work on off shifts. On single-shift operations, you're working less than a quarter of the time. That means your plant and all the equipment in it is utilized less than 25% of the time. Never mind the inefficiencies within the work day. And then, aside from the poor utilization of assets that's causing delays, if you start a twenty-hour job on Thursday or Friday, so that the weekend intervenes, it will take you five days to get that twenty-hour job done. That's an unnecessarily long time, it seems. And furthermore, the quality suffers, just from the startup and so forth. I think everybody knows from their own experience that if you want to get a job done, it's best to keep it going continuously. So there are a couple of motives there to suggest that there are opportunities for better use of assets and better quality. Now let me put some numbers behind this. I've created a hypothetical factory situation here. I'll give you just two cases, and you can play around on a personal computer and see some of the sensitivities. I set up a hypothetical situation in which some units of something or other are being produced at the rate of 50 per hour on a one-shift-per-day basis, which is 2,000 hours per year, producing 100,000 units per year. Nice round numbers, deliberately so. Here's a summary of the first case-the baseline case. BASELINE CASE Assume: 50 units/hour, one shift per day, 2,000 hours per year = 100,000 units per year. Costs Material (O $50 per unit) $5,000,000 Direct labor (30 workers Q $50K) 1,500,000 Interest on capital(12.5% of $20,000,000) 2,500,000 Other indirect 1,000,000 Total manufacturing cost $10,000,000 Unit costs: Material $50 50% Direct labor 15 15% Interest 25 25% Other indirect 10 10% $100 100% 21

Solberg Keynote Address I assume you have $20,000,000 worth of capital on which you're paying at least 12-1/2%, so you've got $2.5 million a year in interest charges. Part of the reason those numbers were put in that way was to come out in proportions which are matching typical figures. These days in metalworking, about 50% of the costs are material, 15% labor, and 35% other burden-type things. So I ended up here with a baseline unit cost of $100 per unit, working one-shift operations. Let's look now at the case of the automated system. Let's see what would happen to the cost. AUTOMATED SYSTEM CASE Assume: 50 units/hour, 2.5 shifts per day, 7,500 hours per year = 375,000 units per year Costs Material (Q $50 per unit) $18,750,000 Direct labor (30 workers O $50K) 1,500,000 Interest on capital (12.5% of $40,000,000) 5,000,000 Other indirect 1,000,000 Total manufacturing cost $26,250,000 Unit costs: Material $50 71% Direct labor 4 6% Interest 13 19% Other indirect 3 4% $70 100% I've assumed that the automation produces units no faster. It's still 50 units per hour, working 2-1/2 shifts per day. I've left a 1/2 shift for downtime maintenance, just to be conservative. So 7,500 hours per year would turn out 375,000 units. Now this is assuming, of course, that there's demand to take care of those units. I'll come back to that point. Material costs I assumed were the same, and I've kept exactly the same workers — didn't fire anybody, didn't hire anybody. That's a figure you might want to play with. I assume that the automation is more expensive. I've said that you've doubled the cost of your fixed investment. Your interest costs go way up. I left the other indirect costs the same. 22

Solberg Keynote Address When you recalculate your unit cost, you find that you are turning these out at $70 per unit now, instead of $100 per unit-a very significant cost savings, principally because of this wider distribution of costs over many more units. And of course, you're getting better utilization of the assets. So this shows a clearer picture than the normal intuitive sense that I think most people have about only the first-order effects of automation. They think you're replacing direct labor by a machine and that's the only substitution you make. There is of course a redistribution of the relative costs. But the most significant change is that you've lowered the total unit cost. It's more capital intensive, but you've lowered the cost. Presumably, at a much lower cost, the demand goes up. So that's the way I get back to that question. I leave it at that point, but I invite you to play with that situation and see if you can't agree with this conclusion that the really strongest economic motive for automation is this lowering of unit cost. Now how you achieve this, of course, requires a lot of technical work. Let me give you a couple of other thoughts that address some of these fears. It seems to. me we are counterproductive when we represent robotics and artificial intelligence in the way that appeals to us. We like to think that we're copying human abilities, and I suggest that's a dangerous notion. We'd be better off not threatening human abilities that way, and just admitting that what we're trying to do is find better ways of doing things. I sometimes think it was a big mistake to call industrial robots, robots. We maybe might have been better off if we had called them articulate manipulators, or something a little more machine-sounding than robot. We've got a similar problem coming up with artificial intelligence. I think a lot of people who don't understand this assume that what we're trying to do is get rid of some people here. A second point is that I think it is a mistake even among ourselves to try to mimic human methods of doing things. If you think of almost any example of automation in classical machine developments that have produced big breakthroughs, it was not done the way people did it. If you want to propel a boat, you don't build a motor that pulls oars; you use a propeller. If you want a sewing machine, you don't pull thread with a needle the way a person would; you build a sewing machine, and so on. We ought to talk about tools to help people. I think the notion of an automatic factory or unmanned factory or totally automated system is a useful concept among a group of people like us. It's a technical challenge. But I don't think it's really very practical as an objective. Certain jobs are done easily by people, and it would be very difficult to get a machine to replace them. At some point there, when we have reached a dividing line, and we don't know where that is yet, it would just be practically pointless to go any further. So it seems to me we ought to be careful about this phrasing, automatic factory, and know what we mean by it, particularly when we're talking to the journalists and the public. 23

Solberg Keynote Address Another idea that's causing a lot of confusion is the fear that a lot of people have that they're going to have to become computer programmers to hold a job. I think people who understand computers know that's not true. You can operate a computer without programming one, just as you can buy a television set and operate it without knowing the circuitry behind it. But that's a notion we ought to get corrected. In designing systems, we ought to be conscious of the fact that people who are not comfortable with technology may have to end up operating these things. Just a couple of words about collaboration and then I'll quit. There are really remarkably few of us. The community can look a lot larger than it is, because there are many interested bystanders. I get an awful lot of visitors, and it turns out they're Wall Street people who want to know what to invest in. But when you're really down to the people who are making significant technical contributions to the area of manufacturing productivity, it's a remarkable small work community, maybe 2,000 people. And there should be many more, considering the importance of the problem, the scale of the problem, the significance to society. We have failed to make that case. I think we've got a lot of work to do. I'll just leave the thought with you. I've got no particular suggestion. I think we need a sense of community in order to get the kind of collaboration we need so that we can achieve more effectiveness for the group than we now have. And we need an agenda —not just a research agenda of the kind we're talking about in this meeting, but a broader-scale social agenda. Finally, it seems to me if we are not just playing with our toys, we ought to think about ourselves as a system and how we can improve the effectiveness of that system. And that implies organizing ourselves better and expressing ourselves more clearly to all those other people. So with that I'll stop. Have I been productive? Thank you. 24

3. CONCLUSIONS AND RECOMMENDATIONS 26

Sensors and Controls SENSORS AND CONTROLS CHAIRMAN: Brian Carlisle, Adept Technology, Inc. RAPPORTEUR: Mark Cutkosky, Stanford University SPEAKERS: Ren C. Luo, N. Carolina State University, "Issues in the State of the Art of Robot Sensing and Controls" James S. Albus, National Bureau of Standards, "The Sensor Integration Problem in the Context of Control Systems" Slawomir Spiewak, University of Wisconsin, "Integration of Data Acquisition and Processing on the Level of Individual Machine Tools in Manufacturing Systems" OTHER MEMBER: Kang Shin, University of Michigan SELECTED QUOTATIONS: I think the hardware issues are largely solved or falling quickly, but there are a lot of software communication problems. -Brian Carlisle Handling of information about the manufactured part as it advances through the overall process is the first aspect of system integration. -Slawomir Spiewak We can't build integrated manufacturing systems with conventional software. The computer industry needs to migrate to a higher level 26

Sensors and Controls of abstraction: object based, knowledge based, whatever based. — Kenneth Ruff One thing we need is a well-documented, easy-to-use geometric modeling and reasoning system coupled to a planner. A second thing we need is some sort of standardized data formats for communication. -Brian Carlisle Geometric modeling does not begin to go far enough. We have to tie in functional information with process modeling and look to the design phase as well. We need to work out relationships that let us relate errors with sensor readings. -Richard Volz Research on robot sensors can be divided into four stages: sensor modeling; higher resolution and faster processing of sensor data; multi-sensor data fusion; sensor error detection, verification, and automatic recovery. — Ren Luo You really want to have a model that sits between the sensor system and the action-generating system and provides an internal best estimate of the state of the external world. And you use the sensory system to update that model. -James Albus A high-bandwidth "sensor bus" linking disparate sensors in a robot work cell would be very useful if it could be implemented without restricting the data rates available from devices such as vibration sensors. -Mark Cutkosky Integration is absolutely necessary, and standardization helps integration. -panel member There exist levels at which (one) should consider defining interface 27

Sensors and Controls specifications (without) restricting the robot manufacturers as to whether they are going to program their internal transformation in C, LISP, PROLOG, or Assembly code. -James Albus I think we have been fortunate, so far, not to have this curse of a minor breakthrough that becomes a defacto standard and stops innovation. -panel member CONCLUSIONS: * Integration remains desirable up to a point at which the performance of individual subsystems begin to suffer. * Integration is proceeding probably as rapidly as can be expected. * Major impediments to integration are: * lack of communications standards for real-time hardware * lack of data format and file structure standards * lack of standards for general-purpose real-time operating systems appropriate for a variety of applications * complexity of the software required to communicate between devices * lack of modeling, both for sensors and processes * poor definition and handling of errors * lack of suitable experimental testbeds and case histories * inexperience with distributed intelligence in the form of parallel processing and with mixed hierarchic and heterarchic control architectures * Major areas needing research * A high-bandwidth/low-cost "sensor bus" is needed so that sensors can be free-standing and shared by several other devices. * Basic research in error detection/understanding is essential. We barely know how to cope with errors in any way at present. 28

Sensors and Controls * Modeling is one of the most important areas needing extensive research. It is at the heart of systems integration. Mixtures of different kinds of models will be required. Both traditional and new approaches to modeling techniques, e.g., adaptive learning, must be explored. * Better hardware and software architectures for multirobot, multi-sensor systems are needed. * Techniques to reduce programming complexity, e.g., object-oriented programming systems and task-oriented programming are critical. * Sensor programming looms as an increasingly difficult and important area as more highly sensored robots and machine tools are developed. * Geometric, physical, and temporal reasoning need to be explored as ways of automatically generating programs or program parts. * The integration of multiple computer-driven devices leads naturally to a need for methods of distributed intelligence. * Many new sensing algorithms will require new parallel processing techniques. * Distributed database systems, particularly those providing rapid access to real-time data, are essential for achieving integration of low-level devices which operate at high speed. 29

Cell-Level Planning CELL-LEVEL PLANNING: CHAIRMAN: Michael Wesley, IBM, Inc. RAPPORTEUR: Matthew Mason, Carnegie-Mellon University SPEAKERS: Ulrich Rembold, University of Karlsruhe, "A Software System for the Simulation of Robot-Based Manufacturing Processes" Rangarajan Jayaraman, IBM, Inc., "Issues in Development of Work-Cell Applications" OTHER MEMBERS: Erwin Bauman, McDonnell Douglas, Inc. John Hopcroft, Cornell University David Williams, Cambridge University SELECTED OUOTATIONS: I think the exclusive consideration of manufacturing is fundamentally wrong.... We have to consider both the products and the processes involved... in the design of a work cell. — Michael Wesley A major software issue is the level of human interaction. Should we automate as much as we possibly can? Or should we try to understand what a human can do well and what a system can do well? — Michael Wesley 30

Cell-Level Planning In my judgment the gross (robot) motion field has reached a usable level of maturity, (but) fine motion still requires a lot of work to make it practical.... Also a very nice field for research is planning for inspection, given the design, tolerances, and set of sensor technologies. — Michael Wesley We need to view equipment in a generic way, so that we don't have to talk about robot programming and NC programming and vision programming, but just talk about programming of equipment that has certain physical, sensory, control, and process characteristics. -Rangarajan Jayaraman What we are trying to do in Europe is to set up a system where we can describe a product to the manufacturing system and have the entire planning done automatically. -Ulrich Rembold During my 18 years of industrial experience, I had been trying to teach manufacturing engineers how to program. I taught them BASIC, which was very difficult. I taught them FORTRAN, which was worse. The present type of robot programming languages are not suitable for any manufacturing engineer. We have to find something that is much simpler. If we don't, then I think we will have failed. -Ulrich Rembold The big problem is with sensors. We can't do any real sensor simulation at this point. — Erwin Bauman Different levels of detail are crucial. Symbolic structures associated with the model are necessary. -panel member We need a language that allows abstraction to be used by the engineer building the system, both in process control and in manufacturing. -panel member We came out with two emphases concerning heavyweight research: one on real-time control architecture for cooperating machines, the other on quick and dirty simulations —the capacity to simulate complex systems fast. -David Williams 31

Cell-Level Planning CONCLUSIONS: * Systems integration must be tackled at three levels: the conceptual design of the cell, the detail design of the cell, the operation of the cell. * Research in conceptual design is needed to achieve advances in: * "quick and dirty" simulators that have some sophistication * more abstract representation of what is being carried out in a cell, to allow a wider choice of cell processes * more general process planning to allow a wider choice of cell processes * development of a production "science" (not dependent on heuristics) * Research in detail design is needed to achieve advances in: * analytic techniques to represent the properties of synthesized systems from the properties of their elements, allowing measurement of system performance * a multi-level simulator for control (perhaps even one that would eventually run the cell) * representations of sensors for use in simulations * implicit robot languages, to curtail development or proliferation of explicit language * more standard low-level robot commands analogous to the cutter file in NC* * Research in cell operation is needed to achieve advances in: * definition of control architectures for machines cooperating in real time * determination of degree of autonomous activity desirable in a cell * rapid reconfiguration of systems for large and small design changes, in terms of both the physical layout and control * factory-floor simulators for "what-if's" and eventual error-recovery planning * geometric reasoning * multiple-sensor integration strategies *May be standards activities 32

Cell-Level Planning * sensors to detect blind features * robust cells for high-tech small output 33

Factory-Level Planning and Integration FACTORY-LEVEL PLANNING AND INTEGRATION CHAIRMAN: Arch Naylor, University of Michigan RAPPORTEUR: William Bolton, Cambridge University SPEAKERS: Lonnie Burnett, Cincinnati Milacron, Inc., "Knowledge Requirements for Integrated Manufacturing Systems" Arch Naylor, University of Michigan, "Integration, Flexibility, and Software" OTHER MEMBERS: Ralph Behler, General Motors Corporation James Solberg, Purdue University Kenneth Ruff, General Motors Corporation Richard Wilson, University of Michigan SELECTED QUOTATIONS: I like the definition of integration as performing all the operations of the merged subsystems plus some new functions that become possible by merging. -Lonnie Burnett People always want to change manufacturing systems after they are installed.... What I see is that changes in function within a hierarchical structure often require significant restructuring in the system. Heterarchical structures appear to accommodate change in a much better fashion. -Lonnie Burnett We need a unified way of representing commands and also communications between the NC machines, the robots, inspection 34

Factory-Level Planning and Integration machines, fixtures, workstations, controllers, cell controllers, shop controllers, and any other system component we haven't thought of yet.... And we need to have the unified command representation at the user level provide for transparent insertion of this common design language, so that you're able to shift to the system design approach, implement the functions that you want, and then continue on with the work. -Lonnie Burnett To develop generic control software, we need to carry out research directly on the problem of generic control of factory floors on the logical level. We can use results from various related research areas, put together multi-area research teams. The chances of success rest on identifying the peculiar theoretical nature and structure of real manufacturing systems and then exploiting that. -Arch Naylor Four areas of research and development deserve major attention. We need to develop better control structures for activities at the cell level and multimodal coordination at the factory level.... We must find better ways of diagnosing and repairing components of our integrated systems.... We need to have continued work in computer technology.... And we need to find some new approaches to creating a methodology for dealing with integrated systems. — Kenneth Ruff CONCLUSIONS: * Current computer-based integration at the factory level as well as speculation upon what is possible provide important evidence for the potential benefits of further integration. However, documenting and achieving these benefits at a quicker pace will require a far better understanding of this area, and this justifies research programs on and studies of integration. * The traditional boundaries of the factory are being challenged by new technology. Thus it would be a mistake to undertake research on integration of factory systems whose boundaries are outdated, without first considering where new boundaries might be drawn. * Boundary changes establish new interrelationships. Horizontal connections that need to be defined include those with purchasing, product design, and distribution. Vertical links are 36

Factory-Level Planning and Integration already becoming accepted as those between cell, super cell, and factory, with the inherent assumption that a hierarchic structure is the best solution. It is important to resolve this issue as soon as possible and to provide appropriate and flexible factory models. * Complexity is the primary characteristic of factory-level integration, and three general goals can be recognized: reduction of complexity, organization and evaluation of complexity, and the control of complex systems. * Standards are extremely important; however, once we have standards, we will still be faced with very complex systems problems. * The appropriate role of people in new, integrated manufacturing systems is not yet fully worked out. It will be a long time, if ever, before we have unmanned factories. Thus the factory of the future, just as the factory of today, will have people in it, and it will not succeed unless the people can use the automated equipment effectively. Research is needed in the following areas: (1) investigate and quantify the benefits of a CIM, and compare it with human-integrated systems (2) conduct case studies of actual computer-integrated manufacturing systems, and compare with human-integrated systems (3) develop a methodology for managing the design and implementation of CIM systems (4) investigate the restructuring required in manufacturing systems as they change from human-integrated to computer-integrated. (5) investigate various control system architectures, considering software and hardware structure (6) develop real-time control algorithms for the factory floor; consider scheduling and fault issues (7) develop methods for determining process (manufacturing system) errors based on part measurements. (8) define a language for machine-to-machine communication that would provide a standard and extensible means of expressing the semantics of inter-machine communication (9) investigate the interrelation between design of a CIM facility and its intended parts family. 36

Databases DATABASES CHAIRMAN: Stanley Su, University of Florida RAPPORTEUR: Randy Johnson, The Boeing Company SPEAKERS: Stanley Su, University of Florida, "Database Issues and Problems in Computer-Integrated Manufacturing" SELECTED QUOTATIONS: The existing computing environment is not quite suitable for CAD/CAM applications. We are using programming languages, database or file management systems, and analysis simulation tools that were designed a long time ago without CAD/CAM applications in mind. They do not provide high-level data abstraction nor adequate support for non-numeric processing. They are of low intelligence in the sense that they do not provide a convenient way to incorporate expert knowledge and artificial intelligence techniques to assist design and manufacturing engineers in their tasks. What is necessary is a new computing environment which provides object-oriented programming languages, data languages, and a knowledge base management system (the integration of database and A.I. technologies) to support the tasks of CAD/CAM integration. -Stanley Su Database management in the heterogeneous distributed database environment we face in factory automation presents many difficult conceptual and practical problems. Further, vendors of traditional database management systems have little incentive to address those problems. Vendors merely want to make their own systems work in a homogeneous environment, and CIM requires more than that. Thus NSF support is needed for research on those problems. -Randy Johnson 37

Databases CONCLUSIONS: Systems integration research is needed in the following areas: Data Modeling: * semantic models that can capture the structural properties, semantic constraints, and operational rules of complex data objects used in CIM * integration of database and AI technologies to develop a knowledge-base management technology * development of an object-oriented approach to database management system design and development User Interface: * development of high-level common-user interfaces for accessing facilities in the existing workstations (e.g., analysis packages, simulators, application programs) * development of supporting multiple-use interfaces (e.g., DB2, SQL, etc.) for incorporating existing and new languages Added Functionalities: * support for complex data types * version control * history information * temporal information handling * complex view transformation * integrity and concurrency control, and recovery in heterogeneous distributed database management * techniques for data, meta-data, and database command translation * configurability of data administration (e.g., from centralized to federated) * automatic triggering of processes Performance Enhancement: * physical data structures for supporting complex data objects * parallel algorithms for supporting database operations * parallel architectural support for distributed database management 38

Communications and Networks COMMUNICATIONS AND NETWORKS CHAIRMAN: David Morgan, Industrial Technology Institute RAPPORTEUR: Patrick Garrett, University of Cincinnati SPEAKERS: Thierry Billoir, INRIA, "Issues in Real-Time Local-Area Networks" David Morgan, Industrial Technology Institute, "Research Issues in MAP" SELECTED QUOTATIONS: Systems integration in communications and networks means adequate, standardized capabilities, both for the factory floor and between manufacturing and other parts of the organization. At least four recently developed network specifications-ETHERNET, MAP, Token-Ring, SCORE —are competing. Future provision for transmitting the accuracy of the data will be important for all communication networks to describe the quality of the transaction. — Patrick Garrett Does MAP accelerate or impede development of CIM? I can argue both sides of the question. But the topic should be researched. -David Morgan MAP is both the most complex and versatile specification, but it requires 100 ms for message transmission from the top of level 7 to the top of level 7 of any node in a network. A four-level MAP specification (1,2,4,7) now under consideration has expected transmission times in the 7-ms to 10-ms range. -David Morgan 39

Communications and Networks The SCORE project at INRIA (Systems COherent and REsilient) is concerned with two main fields of research: (1) real-time distributed operating systems (DELTA, SIGMA); and (2) real-time local area networks (CYCLADES, LYNX).... Compatibility with MAP is provided at level 4, and possibly also at level 3 through gateways. — Thierry Billoir CONCLUSIONS: The subpanel developed the following list of areas needing research * Research is needed to design a suitable high-level protocol and set of services to support machineindependent communications among computers, controllers, and intelligent machines. * While many agree that factories need fiber optics, research is needed to overcome today's technological limitations on its applications. * A good architecture together with a thorough performance study is needed to improve on the sevenlayer OSI model. * Research is needed to produce an architecture and operating system for distributed processing in manufacturing environments-something better suited than the OSI seven-layer architecture. The LOCUS system of UCLA shows promise as a place to start. * Because manufacturing networks are large and complex, and problems can be hard to find, research is needed in developing network management systems that incorporate technologies to aid in diagnosis and recovery. * Because today's models of manufacturing systems can consider only a few machines, research is needed to develop sound mathematics-based models that can analyze very large networks in assembly lines now being built with thousands of computers in them. * Studies are needed to determine where benefits from manufacturing networks can and do exist-whether, for example, a standard such as MAP benefits both vendors and users. 40

Communications and Networks * Research is needed to determine how to effectively test protocol conformance and interoperability. * Research is needed to understand the problem of loss of accuracy and precision in the process of converting floating point representations, and to find good solutions to it. 41

Systems Integration Software SYSTEMS INTEGRATION SOFTWARE CHAIRMAN: Ted Williams, Purdue University RAPPORTEUR: Insup Lee, University of Pennsylvania SPEAKERS: Richard A. Volz, University of Michigan, "Distributed Software Systems Integration" Lee Nackman, IBM, "Information Integration in CAD/CAM Systems:" William C.M. Vaughan, Honeywell, Inc., "Putting the User in'User-Friendly'" OTHER MEMBER: Stephen Schwarm, Axiom Technologies SELECTED QUOTATIONS: Software is a major component in the systems integration problem. 85% of computer costs are in software and the EIA has predicted that by 1i90, for embedded systems alone, costs will exceed $32 billion a year. -- Richard Volz I think that we have spent too little time looking at the systems implementation languages, the languages in which we implement (manufacturing) application programs. There can be very expensive consequences to ignoring the systems implementation language. -Richard Volz 42

Systems Integration Software Some of the key software engineering ideas you want your (systems implementation) language and compiler to support are program and data abstraction, information hiding, separate compilation of module specifications and implementations. -Richard Volz We need a (manufacturing) software components industry where you can purchase various software packages, plug them into any of several different computer systems, and have them work reliably. Second sourcing of a software package is important. -Richard Volz We must make good software engineering capabilities available in a distributed environment. We need distributed execution of a single program. -Richard Volz One of the things I want to argue is that we shouldn't just share data, we should share information. I suggest an object-oriented network approach (to sharing information). -Lee Nackman One of the drawbacks to data sharing is (the need to) define standard data formats. The usefulness of a standard depends on how many people you can get to sign up for that standard. -Lee Nackman What I think we can do is build an object-oriented system that can provide servers for various functions... by gift wrapping the servers, written in various languages, in a layer of AML codes. -Lee Nackman Assume we have a tool set for integrating a manufacturing system. Will the user be able to use.this tool set? I am going to argue that unless we consider the user himself, the answer is probably not. -Bill Vaughan Two golden rules for building our user interfaces are: (1) if it is 43

Systems Integration Software friendly to the software designer, then it is probably wrong, and (2) when in doubt, ask a user. -Bill C.M. Vaughan An interface that is natural for one problem domain is usually unnatural for others. And the level of expertise of a user in one domain is not related to his level of expertise in other domains. -Bill C.M. Vaughan The only good thing is either to have things task oriented, so the user can formulate things the way he thinks, or give the user pushbuttons. -Ulrich Rembold An object-centered view of programming seems to be a natural metaphor for manufacturing engineers. -Insup Lee 44

Systems Integration Software CONCLUSIONS: * In the area of software, systems integration means being able to combine modules into a coherent system. Those modules may be written in different languages suitable for their functions, and they will need to be executed on a set of processors likely to be non-homogeneous. * Systems software integration is not proceeding fast enough. The software problems are very important, because software expenditures are very large and need to be greatly reduced. * A principal source of difficulty is that five forms of heterogeneity are impeding software integration: * architectures, e.g., differences in floating point formats and byte orders; * communication protocols; * operating systems, e.g., file formats in UNIX & VMS; * programming languages, e.g., mismatched data types and different communication primitives; * different representations for the same abstract data type, e.g., complex numbers using polar coordinates vs. complex numbers using Cartesian coordinates. * Other sources of difficulty in software integration include the real-time nature of the problem and the need to express concurrent and distributed operations. * An effective approach to resolving software integration problems must involve a mixture of standardization and research. The two will have synergistic effects on each other. As research is conducted, more will become known about what standards are needed. * Notwithstanding the foregoing, standards need to be developed almost immediately for primitive data types such as integers, characters, floating point types, and communication protocols for level 3 and below of the ISO/OSI model. Such standards are crucial to any success in addressing systems integration software problems. * Research is needed on four types of software support required for real-time manufacturing: (1) mechanisms for expressing concurrency and timing; (2).object-oriented design support; (3) configuration support; and (4) distributed programming support. Further research is needed to determine precisely the language characteristics required for computer-aided 46

Systems Integration Software manufacturing. * Major research is necessary to develop a methodology and mechanisms to support dynamic modifications of an integrated software system, because such systems are bound to be changed to accommodate new hardware and incorporate new capabilities. * Research is needed to find ways of expressing both data flow and control flow of an integrated system. * Finally, major research is needed in the area of test and evaluation tools. How does one verify that a large, complex distributed program is correct? How does one verify that the same program compiled on two different machines will in fact be functionally the same, particularly in view of distributed real-time requirements? How does one best evaluate a set of programming tools? 46

Artificial Intelligence ARTIFICIAL INTELLIGENCE CHAIRMAN: Ruzena Bajcsy, University of Pennsylvania RAPPORTEUR: William Gevarter, NASA Ames Research Center SPEAKERS: Ruzena Bajcsy, University of Pennsylvania, "Robotics and AI - An Apparent or Real Dichotomy" Steve Smith, Carnegie-Mellon University, "AI and Systems Integration" OTHER MEMBERS: Stanley Rosenschein, SRI International Ramesh Jain, University of Michigan Steve LeClair, Air Force Materials Labs SELECTED QUOTATIONS: I have this really deep conviction that robotics needs AI, but AI needs robotics too, which is often forgotten. — Ruzena Bajcsy AI provides tools for reasoning, control, and distributed problemsolving. An important point we in robotics should remember is that there exists a theoretical foundation for this. (However,) expert systems are limited; they are not going to solve all of our problems. -Ruzena Bajcsy If we assume that systems integration is an experimental and multidisciplinary science, I claim a need for a testbed. There is a parallel, in this case, with a physics laboratory or accelerator. — Ruzena Bajcsy 47

Artificial Intelligence AI is applicable to a certain range of problems, but by no means is it a general panacea. I think that what AI does have to offer are new perspectives and approaches for addressing these (system integration) problems. — Steve Smith It appears to me that the knowledge needed for effective decisionmaking in a particular context typically cuts across all areas of the organization. To me this suggests the need for a common, shared model of the organization. One of our long-term goals is development of what might be called a semantics for factory modeling-a set of primitives and relationships between those primitives-to provide us with a means of appropriately modeling the organization, of expressing the necessary knowledge.... We are very much concerned with formalizing the knowledge surrounding constraints and preferential concerns. — Steve Smith I would suggest that process planning would be a useful problem to address (with AI techniques). — Steve Smith A lot of very good (AI) work has not been applied because it is still too expensive. It takes too many man-years of effort to solve the problem. -panel member The problem is that manufacturing engineers don't know how to express the problem to the AI and robotics people, the people who have the tools to solve the problem. -panel member CONCLUSIONS: * AI is not so much separate from CIM development activities as it is a supporting technology, much like mathematics, that can help developers achieve their goals. * To AI, systems integration means: 48

Artificial Intelligence * (1) distributed processing, * (2) combining hierarchical and heterarchical control, * (3) planning, and * (4) sensor fusion. * The AI techniques applicable to manufacturing were determined to be: * Knowledge representation —methods to easily and efficiently represent on a computer knowledge of the domain and the particular problem so as to facilitate the finding of a solution. * Heuristic search —empirical rules (usually domain dependent) that help guide the search for a solution through the many possibilities that might lead to a solution. * Common sense reasoning and logic —both informal and formal methods of reasoning about a problem. * AI languages and tools-computer languages and development tools for constructing AI programs and for making available (delivering) the completed system to the user. * There are many fruitful areas for application of these AI techniques to manufacturing problems, including: * monitoring and control, using models and heuristics for analysis, interpretation, and prediction of system activity, * planning, scheduling, and process design, using heuristic searching of alternatives to find near-optimal solutions, * database management and query, using natural languages, * expert systems for diagnosis and error recovery, and * perception and integration of information from a wide range of sensors. * There are several areas in which AI can make significant contributions to systems integration if additional research is conducted. These include: * Planning and scheduling-this is the key area. As yet there are few general AI planning systems capable of managing the complexity of system integration tasks. Research efforts that emphasize issues of scale are needed. Additionally, it is important to encourage planning and scheduling efforts that address interleaved 49

Artificial Intelligence plan expansion and execution, reactive replanning, resource allocation and planning in the face of a highly dynamic environment. * Distributed intelligence and problem-solving-for modularity and simplicity it would be desirable to have the intelligence at the point where it is needed. Continued research efforts into the development of multi-agent problem-solving models, strategies for knowledge sharing and cooperative negotiation, and methodologies for distributing and coordinating the overall effort are needed. AI efforts in parallel processing and object-oriented programming are also relevant here. * Combining evidence and managing uncertainty-often sensors and other information sources, as well as knowledge about future orders, etc., contain uncertain knowledge. Techniques for integrating the totality of the evidence available are critical for effective decisionmaking, and further work is needed in this area. * Knowledge representation-further work is needed in representing knowledge in an environment of interaction between objects involving geometrical, functional, symbolic, and temporal aspects. In dealing with distributed objects, an intelligent interface between different representation methods is important. Finally, knowledge representations appropriate for the 3D, temporally, varying, factory environment are needed. * Factory design —future integrated factories need to be designed to fully utilize manufacturing equipment, 24 hours a day. The equipment should be worn out before it becomes obsolete, so that the equipment in use can always be of current technology. Application of AI problem-solving techniques to the factory design problem, as well as further research into the development of mechanisms for compromising amongst conflicting objectives are needed. 50

Economic Evaluation ECONOMIC EVALUATION CHAIRMAN: Wolter J. Fabrycky, VPI and State University RAPPORTEUR: Michael Burstein, Industrial Technology Institute SPEAKERS: Wolter J. Fabrycky, VPI and State University, "Manufacturing Integration from the Perspective of LifeCycle Engineering" James Brimson, CAM-I, "New Approaches to Economic Evaluation" Michael Burstein, Industrial Technology Institute, "Research Planning in Engineering Economics" SELECTED QUOTATIONS: Product life-cycle engineering is a systematic approach to bringing products into being with a minimum of undesirable side effectsthat is, with good functional characteristics and desirable economic outcomes. - Wolter J. Fabrycky Fully 80 percent of the opportunity to influence life-cycle cost is gone by the time the design is completed. This is why life-cycle engineering economics is an approach that should originate during the preliminary design phase. — Wolter J. Fabrycky 61

Economic Evaluation Technology is changing what we call the cost behavior patterns within a factory. It is changing the whole way we measure ourselves and run our businesses. Successful companies are going to be those that can best manage that change. -James Brimson Product cost as we manage it today bears very little resemblance to reality. It's distorted by very high burden rates. The challenge is to find what effect the technology we're putting in is having on product cost. We talk about integrated systems. What is that going to do to your product cost? Today's accounting systems can't even begin to answer that question. -James Brimson Why is heavy stress being put on economic modeling of production systems? Well, we're all worried about the manufacturing engineer, who has to cope with a complete turnover in the manufacturing paradigm. Direct labor isn't what's important any more. What's important is a broad range of benefits and costs that affect the competitiveness of the company. We're going to try to provide that manufacturing engineer with decision-support tools, in the design phase, that enable him to model the potential cost behavior, just as he models the capacity and the product mix capabilities of a manufacturing system. -Michael Burstein CONCLUSIONS: * The economic evaluation of CIM refers to assessment of both short-term and life-cycle costs of products, processes, and facilities. * The greatest cost-saving aspect of CIM may well be its capacity for facilitating the effective utilization of expensive machinery that otherwise would be used about one-fourth of that time. * Durable goods manufacturers in the U.S. have been slow to introduce computer-based systems integration for several reasons, including high interest rates; dysfunctional economic controls; an absence of technologically appropriate tools for economic justification; and the "not invented here" syndrome. 62

Economic Evaluation Recommended research areas are: * Analysis of the economic control problem for programmably automated manufacturing, along with validation of prototypic software possessing real-time capabilities to supplement or supplant existing cost accounting approaches. * Identification of indices to measure the technological quality of any manufacturing asset. * Identification of essential factors that determine an optimal outcome from alternative allocations to various phases of the system life cycle. * Determination of appropriate modeling approaches to optimize life-cycle economic outcomes. * Construction of a framework for computer-aided estimating that could support the tightly coupled design of products and the processes required to manufacture them. * Identification of all economic factors that establish the desirable extent of system integration for any CIM facility. * Determination of a reasonable rule base for the economically appropriate introduction of programmable automation when further technical advances in the short term are anticipated. 63

APPENDIX A: PROGRAM SCHEDULE 54

Appendix A WORKSHOP on SYSTEMS INTEGRATION TOOLS IN MANUFACTURING November 6, 1985 8:00- 8:10 Introduction and Orientation - Richard A. Volz, Arch W. Naylor, Co-Chairmen 8:10-8:20 The National Science Foundation's Interest in Systems Integration - Howard Moraff, NSF 8:20- 9:00 Contemporary Manufacturing Systems Integration - Kenneth Ruff, General Motors 9:00-9:40 The Role of Economic Evaluation in Systems Integration - William Spurgeon, National Science Foundation (now University of Michigan (Dearborn)) 9:40 - 10:00 Break 10:00- 12:00 Sensors and Controls - Brian Carlisle, Adept Technologies, Chairman - Speakers: Ren Luo, North Carolina State Dr. James Albus, National Bureau of Standards Dr. Slawomir Spiewak, University of Wisconsin 12:00 - 2:00 Lunch 2:00- 3:30 Cell-Level Planning - Dr. Michael Wesley, IBM, Chairman - Speakers: Professor Ulrich Rembold, University of Karlesruhe Dr. Rangarajan Jayaraman, IBM 3:30 - 4:30 Break 4:30 - 6:30 Factory-Level Planning and Integration - A. W. Naylor, University of Michigan, Chairman - Speakers: Lonnie Burnett, Cincinnati Milacron Professor A. W. Naylor, University of Michigan 7:00 - 8:00 Hors d'oeuvre 8:00 - 9:00 Dinner 9:00 - 10:00 Keynote Speech - Professor James Solberg, Purdue University 10:00-? Informal Get-togethers 65

Appendix A November 7, 1985 8:00- 10:00 Manufacturing Database (Professor Stanley Su, Chairman) & Communications (Dr. D. Morgan, Chairman) - Speakers: Professor Stanley Su, University of Florida Dr. David Morgan, Industrial Technology Institute Dr. Thierry Billoir, INRIA 10:00 - 10:30 Coffee 10:30 - 12:00 Software Systems for Integration - Professor Theodore Williams, Purdue University, Chairman - Speakers: Professor R. A. Volz, University of Michigan Dr. Lee Nackman, IBM Dr. William Vaughan, Honeywell 12:00- 2:00 Lunch 2:00 - 3:30 Artificial Intelligence Tools for Systems Integration - Professor Ruzena Bajcsy, Chairperson - Speakers: Professor Ruzena Bajcsy, University of Pennsylvania Dr. Steve Smith, Carnegie Mellon University 3:30 - 4:30 Break 4:30 - 6:00 The Role of Economic Evaluation in Systems Integration - Professor Wolter J. Fabrycky, Chairman - Speakers: James Brimson, CAMI Professor W. J. Fabrycky, VPI Dr. Michael Burstein, ITI 7:00 - 8:00 Dinner 8:00 - 9:30 Working Group Meetings 9:30?? Informal Get-togethers November 8, 1985 8:30 - 10:00 Reporting Session 10:00 - 10:30 Break 10:30- 12:00 Reporting Session 66

APPENDIX B: ROSTER OF PARTICIPANTS 57

Appendix B SYSTEMS INTEGRATION WORKSHOP November 6,7,8 1985 Roster Dr. James S. Albus James Brimson Chief, Robot Systems Division V.P. of Business Development National Bureau of Standards CAM-T Building 220 - Room B124 611 Ryan Plaza Dr., Suite 1107 Gaithersburg, MD 20899 Arlington, TX 76011 301/921-2181 817/880-1654 Ms. Rusena Bajcsy Lonnie Burnett Computer & Information Science Manager University of Pennsylvania Advanced Software Room 262 Moore Building Cincinnati Milicron 200 South 33rd Street 4701 Marbug Philadelphia, PA 19104 Cincinnati, OH 45209 215/898-6623 513/841-8889 Erwin Baumann, Specialist Mike Burstein McDonnell Douglas CAD/CAM Senior Research Information Systems Group Center for Social and Economic Issues P.O. Box 516, C693/305/2E/299 Industrial Technology Institute St. Louis, MO 63166 P.O. Box 1485 315/233-0391 Ann Arbor, MI 48106 313/665/4168 Ralph Behler, Director Advanced Engineering Staff Mr. Brian Carlisle General Motors Tech Center President Warren, MI 48090-9040 Adept Technology, Inc. 313/575-0592 1212 Bordeaux Drive Sunnyvale, CA 94089 Mons. Thierry Billoir 408/747-0111 INRIA Domain de VoLuceau Professor Robert Carr Rocquencourt College of Engineering BP 105 The University of Michigan 78153 Le Chesnay CEDEX Ann Arbor, MI 48109 FRANCE 313/764-9420 011-3313954-9020 Professor Mark Cutkosky Dr. William Bolton Design Division Managing Director Mechanical Engineering Dept. Cambridge Robotics Limited Stanford University Cambridge Science Park Stanford, CA 94305 Milton Road 415/497-8100 Cambridge, ENGLAND CB4-4FZ 22367309 568

Appendix B Professor Wolter J. Fabrycky Dr. Steve LeClair Industrial Engineering Air Force Materials Labs and O.R. Manufacturing Technologies Division VPI and State University 1861 Stonewood Drive Blacksburg, VA 24060 Beaver Creek, OH 45432 703/961-5439 513/255-7371 Professor Patrick Garrett Professor Insup Lee University of Cincinnati University of Pennsylvania Electrical Engineering 274 Moore Building Mail Location 30 33rd and Walnut Cincinnati, OH 45221 Philadelphia, PA 19104 513/475-6326 215/898-3532 Dr. William Gevarter Professor Ren C. Luo Computer Scientist Electrical & Computer Engineering NASA Ames School of Engineering Mail Stop 244-7 North Carolina State University Moffitt Field, CA 94035 Box 7911 Computer Address: Raleigh, NC 27695-7911 PLU.GEVARTER 0 AMES-VMSB 919/737-2336 415/694/6525 Professor Matthew Mason Professor John Hopcroft Computer Science Dept. Engineering Cornell University Carnegie-Mellon University Ithaca, NY 14850 Schenley Park Computer Address: Pittsburgh, PA 15213 Hopcroft 0 Cornell 412/578-8804 607/256-7416 Dr. David Morgan Professor Ramesh Jain Director Communications and The University of Michigan Network Laboratory 1511 E. Engineering Industrial Technology Institute Ann Arbor, MI 48109 P.O. Box 1485 313/763-0387 Ann Arbor, MI 48106 313/769-4021 Dr. Rangarajan Jayaraman Research Staff Member Dr. Howard Moraff D432/3-225 Program Director IBM Corporation National Science Foundation T.J. Watson Research Center Automation & Systems Integration Yorktown Heights, NY 10598 Division of Design Manufacturing 914/945-3773 t Computer Engineering 1800 G. Street, N.W. Dr. H. Randall Johnson Washington, D.C. 20550 Boeing Computer Services 202/357-7678 P.O. Box 2434-6, MS 9C-03 Seattle, WA 98124-0346 206/575-7070 59

Appendix B Dr. Lee Nackman Professor Kang Shin Manager, Design Automation Sys. Electrical & Computer Engineering T.J. Watson Research Center College of Engineering P.O. Box 218 The University of Michigan Yorktown Heights, NY 10598 Ann Arbor, MI 48109 914/945-2788 313/783-0391 Professor Arch Naylor Dr. Steve Smith The University of Michigan Research Associate 2521 E. Engineering Carnegie-Mellon University Ann Arbor, MI 48109 Schenley Park 313/764-4307 Pittsburgh, PA 15213 412/578-8811 Prof. Dr. Ing Ulrich Rembold Institute fur Informatik III Professor James Solberg Lehrstuhl fur Prozessrechentechnik Purdue University Universitat Karlsruhe Engineering Research Zirkel 2 Center for Intelligent D-7500 Karlsruhe 1 Manufacturing Systems WEST GERMANY West Lafayette, IN 47907 011-49721-6080 317/494-5441 Dr. Stanley Rosenschein Professor Slawomir Spiewak Artificial Intelligence Center Mechanical Engineering Department SRI International University of Wisconsin 333 Ravenswood Avenue Madison, WI 53706 Menlo Park, CA 94025 608/262-0923 415/859-4167 Bill Spurgeon Ken Ruff The University of Michigan Manager of Advance Mfg. Eng. Faculty Office Building Advanced Engineering Staff Room 204 General Motors Tech Center Dearborn, MI 48128 EA Building 313/593-5119 30300 Mound Road Warren, MI 4809-99015 Professor Stanley Su 313/575-0663 Database Systems Research & Development Center Stephen Schwarm University of Florida Principal Software Engineer 545 Weil Hall Axiom Technologies Gainesville, Fl 32611 375 Elliott Street 904/392-7440 Newton, MA 02184 617/965-8010 60

Appendix B William C.M. Vaughan Process Management Systems Div. Honeywell, Inc. 16404 North Black Canyon Highway Mail Stop M/S B59 Phoenix, AZ 85023 602/863-5081 Professor Richard A. Volz The University of Michigan 2510A E. Engineering Ann Arbor, MI 48109 313/763-0035 Dr. Michael Wesley Manager of Design Automation Dept. IBM Corporation T.J. Watson Research Center P.O. Box 218 Yorktown Heights, NY 10598 914/945-2539 Dr. David Williams University Lecturer Manufacturing Engineering Group Trumpington Street Cambridge, ENGLAND CB2-1PZ Professor Ted Williams PLAIC Purdue University Potter Engineering Center Room 334 West Lafayette, IN 47907 317/494-7434 Professor Richard Wilson Industrial Engineering 230 IEO The University of Michigan Ann Arbor, MI 48109 313/783-4263 61

APPENDIX C: LIST OF PAPERS PRESENTED 62

Appendix C LIST OF PAPERS PRESENTED Albus, James S., "The Sensor Integration Problem in the Context of Control Systems" Bajcsy, Rusena, "Robotics and AI-An Apparent or Real Dichotomy" Billoir, Thierry, "Issues in Real-Time Local-Area Networks" Brimson, James, "New Approaches to Economic Evaluation" Burnett, Lonnie, "Knowledge Requirements for Integrated Manufacturing Systems" Burstein, Michael, "Research Planning in Engineering Economics" Fabrycky, Wolter J., "Manufacturing Integration from the Perspective of Life-Cycle Engineering" Jayaraman, Rangarajan, "Issues in Development of Work-Cell Applications" Luo, Ren C., "Issues in the State of the Art of Robot Sensing and Controls" Morgan, David, "Research Issues in MAP" Nackman, Lee, "Information Integration in CAD/CAM Systems" Naylor, Arch, "Integration, Flexibility, and Software" Rembold, Ulrich, "A Software System for the Simulation of Robot-Based Manufacturing Processes" Ruff, Ken, "Contemporary Manufacturing Systems Integration" Solberg, James, "Some Problems We Share" Smith, Steve, "AI and Systems Integration" Spiewak, Slawomir, "Integration of Data Acquisition and Processing on the Level of Individual Machine Tools in Manufacturing Systems" Spurgeon, William, "The Role of Economic Evaluation in Systems Integration" Su, Stanley, "Database Issues and Problems in Computer-Integrated Manufacturing" Vaughan, Will C.M., "Putting the User in'User-Friendly' " Volz, Richard A., "Distributed Software Systems Integration" 63

UNIVERSITY OF MICHIGAN 3 9015 03527 2270