National Academies Press: OpenBook

Design and Analysis of Integrated Manufacturing Systems (1988)

Chapter: Integration and Flexibility of Software for Integrated Manufacturing Systems

« Previous: Designing an Information System for Integrated Manufacturing Systems
Suggested Citation:"Integration and Flexibility of Software for Integrated Manufacturing Systems." National Research Council. 1988. Design and Analysis of Integrated Manufacturing Systems. Washington, DC: The National Academies Press. doi: 10.17226/1100.
×
Page 79
Suggested Citation:"Integration and Flexibility of Software for Integrated Manufacturing Systems." National Research Council. 1988. Design and Analysis of Integrated Manufacturing Systems. Washington, DC: The National Academies Press. doi: 10.17226/1100.
×
Page 80
Suggested Citation:"Integration and Flexibility of Software for Integrated Manufacturing Systems." National Research Council. 1988. Design and Analysis of Integrated Manufacturing Systems. Washington, DC: The National Academies Press. doi: 10.17226/1100.
×
Page 81
Suggested Citation:"Integration and Flexibility of Software for Integrated Manufacturing Systems." National Research Council. 1988. Design and Analysis of Integrated Manufacturing Systems. Washington, DC: The National Academies Press. doi: 10.17226/1100.
×
Page 82
Suggested Citation:"Integration and Flexibility of Software for Integrated Manufacturing Systems." National Research Council. 1988. Design and Analysis of Integrated Manufacturing Systems. Washington, DC: The National Academies Press. doi: 10.17226/1100.
×
Page 83
Suggested Citation:"Integration and Flexibility of Software for Integrated Manufacturing Systems." National Research Council. 1988. Design and Analysis of Integrated Manufacturing Systems. Washington, DC: The National Academies Press. doi: 10.17226/1100.
×
Page 84
Suggested Citation:"Integration and Flexibility of Software for Integrated Manufacturing Systems." National Research Council. 1988. Design and Analysis of Integrated Manufacturing Systems. Washington, DC: The National Academies Press. doi: 10.17226/1100.
×
Page 85
Suggested Citation:"Integration and Flexibility of Software for Integrated Manufacturing Systems." National Research Council. 1988. Design and Analysis of Integrated Manufacturing Systems. Washington, DC: The National Academies Press. doi: 10.17226/1100.
×
Page 86
Suggested Citation:"Integration and Flexibility of Software for Integrated Manufacturing Systems." National Research Council. 1988. Design and Analysis of Integrated Manufacturing Systems. Washington, DC: The National Academies Press. doi: 10.17226/1100.
×
Page 87
Suggested Citation:"Integration and Flexibility of Software for Integrated Manufacturing Systems." National Research Council. 1988. Design and Analysis of Integrated Manufacturing Systems. Washington, DC: The National Academies Press. doi: 10.17226/1100.
×
Page 88
Suggested Citation:"Integration and Flexibility of Software for Integrated Manufacturing Systems." National Research Council. 1988. Design and Analysis of Integrated Manufacturing Systems. Washington, DC: The National Academies Press. doi: 10.17226/1100.
×
Page 89
Suggested Citation:"Integration and Flexibility of Software for Integrated Manufacturing Systems." National Research Council. 1988. Design and Analysis of Integrated Manufacturing Systems. Washington, DC: The National Academies Press. doi: 10.17226/1100.
×
Page 90
Suggested Citation:"Integration and Flexibility of Software for Integrated Manufacturing Systems." National Research Council. 1988. Design and Analysis of Integrated Manufacturing Systems. Washington, DC: The National Academies Press. doi: 10.17226/1100.
×
Page 91

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

INTEGRATION AND FLEXIBILITY OF SOFTWARE FOR INTEGRATED MANUFACTURING SYSTEMS ARCH W. NAYLOR AND RICHARD A. VOW ABSTRACT This paper suggests a new, integrated approach to research on real- time control software for integrated manufacturing systems. The approach is based on five assumptions about how control software should be designed and developed. They are (1) that control software should be written as assemblages of software components, (2) that this writing should be done in a largely common distributed language and associated software environment, (3) that explicit formal semantic models are required, (4) that generics will significantly expand software reusability, and, finally, (5) that these concepts are entangled and should not be researched separately. INTRODUCTION In this paper we discuss two things, both of which are prescriptions for manufactur- ing research. The first might be described as a general goal for manufacturing re- search. The second is a research approach that moves, to a limited extent, toward this goal. One must be somewhat humble when attempting to prescribe a plan for U.S. manufacturing, even if only for the re- search. Over the past 5 or 10 years so many medicine men have touted their magic cures that audiences and readers have become a bit skeptical. We have had just-in-time de- livery, quality circles, robots, computer- integrated manufacturing, Japanese indus- trial democracy a la Fremont, yen-dollar realignment, and so on. Perhaps the most popular cure one that any eighteenth cen- tury physician would recognize has been 79 good old-fashioned bloodletting. But these cures have not been found completely suc- cessful, thus raising the possibility that new approaches are needed. The difficulty is, of course, that man- ufacturing is an extremely complex activ- ity with intertwined social, economic, or- ganizational, and technical aspects (Volz and Naylor, 1986~. Unfortunately, studying "complex activities with intertwined social, economic, organizational, and technical aspects" is difficult. Even with the best of initial intentions, we almost invariably end up following the path of reductionism and studying one aspect of the problem from the viewpoint of one intellectual discipline. The usually unspoken assumption is that somewhere else, at some time in the future, somebody else will bring it all together. Indeed, we follow this path even with purely technical problems that are com- plex. Research is usually concerned with

80 specialized techniques, not complex appli- cations. Perhaps this is unavoidable, but one does have the nagging worry that it will never "all be brought together" and that practitioners will continue to grapple with the problems as best they can, without the , lip aid of meaningful foundations. Although it ' ... . ~ L will not be easy, we believe that "bringing it all together" should be a general goal for manufacturing research. Although we would have liked to intro- duce a dramatic new paradigm for the in- tegrated study of manufacturing systems, we do not have one. The proposed prescrip- tions will be far more modest, but at least they will be an attempt to move in the right direction. The discussion will deal with an integrated, mildly nonreductionist ap- proach to one technological aspect of inte- grated manufacturing; in particular, it is concerned with the design and develop- ment of real-time control software for the control of the flow of parts, tools, material, and information in a computer-integrated manufacturing system. The approach is nonreductionist in the sense that major as- pects of the problem are confronted simul- taneously in a unified manner. This paper first describes the systems of interest in some detail. This is followed by a review of how control software is cur- rently being realizecl, and the limitations of current practice are highlighted. The bulk of the paper presents the proposed ap- proach to research on control software and an example of an application of this ap- ARCH W. NAYLOR AND RICHARD A. VOLZ :: I M2 f I 1 ! 1 ~ Road System Path ~ 1 1 1 Ma 1 1 M4 FIGURE 1 Mechanical perspective of the man- ufacturing system. preach. Finally, some proposals are made for the research questions that result from this approach. SYSTEMS OF INTEREST A rather simple, and undoubtedly famil- iar, version of a system of interest is shown in Figures 1 and 2. Figure 1 shows the phys- ical layout of various devices, that is, nu- merically controlled (NC) machines, mea- suring machines, robots, and so forth. The backbone of the system from this perspec- tive is the material transport system. It pro- vides the physical integration of the system. Figure 2 shows the same system from the perspective of information and software. Here the integrating backbone is the local- area network. The device controllers and the control computer are connected to it. More elaborate systems might have more Controller M1 1 1 M2 Controller Local-area Network Ma M4 IP Controller Controller Controller ~ . IP Controller r 'AGV1 Road Controller system cone oiler coAnG ~ ]T FIGURE 2 Software perspective of the system shown in E; igure 1.

SOFTWARE FOR INTEGRATED MANUFACTURING SYSTEMS devices, more device controllers, more ma- terial transport systems, more local-area networks, or more control computers. This simple version will suffice, however, for the present discussion. A PERCEPTION OF CURRENT PRACTICE A few years ago a discussion about cur- rent practice would probably have focused on "islands of automation" and agonized over the difficulty of making low-level in- terconnections. It might have been noted that the interfaces for NC machine control- lers were either poor or nonexistent, and surely there would have been comments on the lack of standardization in local-area networks. Today, such problems, although not behind us, are recognized, and progress is being made. For example, manufactur- ing automation protocol (MAP), a local- area network standard for manufacturing (Kaminski, 1986), is being widely accepted. Thus, it is probably fair to say that, over the next few years, low-level interconnec- tion will cease to be a problem. However, once the low-level interconnection prob- lems are behind us, we immediately come face-to-face with far more daunting prob- lems. The root problem is that so far it has been extremely difficult to reuse or port manufacturing software. The typical situa- tion is that software is tailored to a partic- ular manufacturing system that is designed to make a particular mix of parts. This is not surprising, for a number of reasons. First, there is a very large number of can- didate devices from which a manufacturing system may be constructed, and some of them come with their own languages. Sec- ond, the structures of systems that is, the physical and electronic arrangement of the system can vary markedly. Third, the ex- ecution environment for the software is in- herently distributed, and explicit handling of communication presents a surprisingly 81 heavy programming overhead. Moreover, debugging and software reliability, always difficult because of the size of the pro- grams, become all the more so because of distribution. Fourth, the systems to be con- trolled are usually stochastic, because of such things as device breakdown and ran- dom material arrivals, making the formu- lation of the needed control algorithms ex- tremely difficult. Since a practical general approach to such algorithms is missing, the algorithms are invariably quite specific. Consequently, the software is expensive because its cost is difficult to spread over several systems. It is inflexible in the sense that it is difficult to change to make new parts. And its reliability is achieved at a further cost in flexibility that is, the sys- tems are potentially so complex that flexi- bility is sacrificed just to achieve reasonable confidence that the system will work. This, then, is our perception of current practice. It should not be taken as a criti- cism of those writing real-time control soft- ware, rather, it should be taken as a state- ment of the "software facts of life." THE APPROACH TO SOFTWARE COMPONENTS AND THEIR ASSEMBLAGES The balance of this paper is concerned with research on real-time control soft- ware. As will immediately become evident, our approach starts with some basic assump- tions about how control software should be designed and developed, and therefore the research issues become, on the one hand, an exploration of the consequences of these basic assumptions and, on the other hand, the testing of their appropriateness. The ba- sic assumptions are (1) that control software should be written as assemblages of soft- ware components, (2) that this writing should be done in a largely common distrib- uted language and associated software en- vironment, (3) that explicit formal seman- tic models are required, (4) that generics

82 will significantly expand software reusabil- ity, and, finally, (5) that these concepts are entangled with one another and should not be researched separately. The first part of this approach may not seem terribly revolutionary. Since the prob- lems to be addressed are large, complex software systems, it seems reasonable to pre- scribe modern software engineering con- cepts. But beyond this general prescription, it appears that the wide application of one particular concept could have a major im- pact. The concept comes under labels such as software components, objects (Rentsch, 1982), and abstract data types (Straw, 1980~. Other applicable terms are data abstraction and data hilling. We will use the term soft- ware component (Volz et al., 1986) to de- scribe all of these elements. It is easy for anyone with a background in systems to appreciate what a software component is: It is the software equivalent of a black box. It has inputs and outputs to which the user has access. Software com- ponents are generalizations of things such as subroutines, procedures, and functions. Typically, a software component is a col- lection of functions and procedures that operate on some common something inside the component, or, if you will, inside the black box. Consider a simple example. A software component that establishes the public interface for a stack or last-in, first-out queue is as follows: package STACK is procedure PUSH(X:INTEGER); function POP return INTEGER, end STACK Although this example happens to be written in Ada, it could just as easily have been written in Modula 2 or C++. The significant aspect of this example is what it makes available to the user, in particular, the procedure PUSH and the function POP. PUSH adds an integer this STACK stacks up integers to the queue, and the function POP takes one off. This public interface ARCH W. NAYLOR AND RICHARD A. VOLZ and an understanding of how last-in, first- is, a semantic model tor stacks, Is all the user needs to know to use this software component. In particular, the user does not have to know the details of the internal part of the component, and one can appreciate that the stack could be implemented in various ways. Let us imag- ine a bizarre example. The stack is not im- plemented in main memory or even second- ary storage. Instead, we have a robot that writes integers on a large blackboard in a long line. We also have a vision system that reads these integers, and the robot has an eraser. This admittedly silly example makes two points. First, the user really has access to the public interface only; second, one can imagine manufacturing devices as be- ing inside a software component. The sec- ond point is important. We believe that robots, NC machines, material transport vehicles, and so forth should be incorpo- rated into a manufacturing software system in exactly the same way that our simple stack is that is, through a public interface. The ability to create and use soft- ware components is not simply a matter of programming style. It requires that the language used have specific capabilities. FORTRAN and BASIC, for example, do not have these capabilities. The component must be capable of being compiled sepa- rately from the software that uses it, but, more importantly, the interface and inter- nals must be able to be compiled sepa- rately. The public interface is like a control panel for the component. It contains the names of procedures and functions together with their associated parameters. The fact that this interface can be compiled sepa- rately from the internals of the component means that users can have compilers auto- mat?~ally test the compatibility of the com- ponent with the system in which they will use it. Separate compilation opens the possibil- ity of a true software components industry, and that in turn promises a reduction in out queues work, that ~ . . . .. ..

SOFTWARE FOR INTEGRATED MANUFACTURING SYSTEMS software costs. If it becomes possible to purchase software components "off the shelf" and incorporate them into larger software systems, this will create competi- tion for producing software components. Indeed, larger software systems will largely be assemblages of components, and these assemblages will themselves usually be soft- ware components. Separate compilation is important because the vendor can deliver the compiled component together with the source code for the public interface. That is, the vendor can sell the component with- out having to reveal the source of its inter- nal implementation. The user, knowing the public interface, will know enough to use the component; in particular, separate com- pilation of the interface and internals will allow the compiler to check that the com- ponent has been integrated into the user's software system in the proper manner. A1- ternatively, the purchaser might specify the public interface, verify that it is compatible with the system in which it will be used, and include that specification as part of the requirements for the component. The inter- face can become part of the contract be- tween the purchaser and the supplier. This would mean that the internals might be Cell C Machine 83 purchased from another vendor, thereby · . · . Increasing competition. A software components industry (Vo~z et al., 1986) becomes particularly interesting when one considers manufacturing devices and systems. In particular, one can, as sug- gested earlier, imagine treating robots, NC machines, vehicles, and so forth as software components (Volz and Mudge, 1984~. Ig- noring for the moment the inevitable dis- tributed nature of a manufacturing system, the integration of a robot into the software system becomes merely a matter of calling the procedures and functions in the robot's public interface. In fact, the robot might be part of a manufacturing cell, and this cell might incorporate a number of other manufacturing devices that are treated as software components. Figure 3 shows a simple example of seven software compo- nents: cell, machines, transport, two NC machines, robot, and vehicle. The Lotted horizontal line divides the purely "software world" from the "mechanical world" that is, the actual factory floor. The private in- ternals of the component machines contain the two NC machine components plus soft- ware for creating the assemblage of these two components. This latter software is ~ . ~ I Mac :3 Transport ~ a= NC Machine _ _ Robot ~ r L Vehicle "Software World" FIGURE 3 Software components of a representative manufacturing cell.

84 represented in Figure 3 by the bottom half of machines, whereas the top half repre- sents the public interface of machines. Since the NC machines' components span the software and mechanical worlds, the com- ponent machines must also. Indeed, each component in Figure 3 spans both worlds for the same reason. The user of cell has access to the other components only to the extent that their function somehow evi- denced in the public interface of cell. Simi- larly, if a number of cells are assembled into a component factory floor, the user of factory floor will have to interact with only its public interface and will not have direct access to any of the cells. Part of this approach, then, is to use soft- ware components as building blocks to cre- ate other software components. In a certain restricted sense, this suggests a common language (Volz et al., 1986) one that sup- ports software components in which the system integration is carried out. It would be unrealistic, however, to rule out other languages completely. For example, the language used for NC machines is unlikely to change. But this does not preclude a cen- tral role for a common language. In partic- ular, if we distinguish between what we call the Euclidean and logical views of manufacturing systems, we believe that us- ing a largely common language is reason- able and desirable. EUCLIDEAN AND LOGICAL VIEWS The Euclidean view of a manufacturing system is characterized by locations, orienta- tions, and movements of objects expressed in finite-dimensional Euclidean spaces. Models are typically coordinate transformations, kinematic constraint equations, differential equations, and so forth. Tools come from a variety of sources, including control theory, elasticity, and optics. Typical problems in- clude moving from one geometric point to another, following a path, determining a path, locating a point with a vision system, ARCH W. NAYLOR AND RICHARD A. VOLZ or inserting a peg in a hole. Usually the Euclidean view effectively divides the fac- tory floor into largely independent or loosely coupled subsystems for example, a robot's motion or an NC machine's actions. The logical view is, as the name suggests, largely concerned with logical conditions and transformations of logical conditions. Variables simply identify things and, except for time, are usually not real-valued. A typical condition might be stated as "the material transport vehicle is at machine number seven." Here the phrases "material transport vehicle" and "machine number" identify two entities in the environment of interest. The phrase "is at" establishes a log- ical relation between these two entities. Ex- amples of conditions that involve logical quantifiers are "there is something on the material transport vehicle" and "there is nothing on the material transport vehicle." Transformations of conditions involve ac- tions such as moving a vehicle from one place to another or loading a machine with a part. The essence of the logical view is that two things cannot be in the same place at the same time and that it takes time to carry out actions. In addition, the logical view recognizes that events may not turn out the way we thought they would that is, it allows randomness. The importance of this distinction be- tween the Euclidean and logical views is that it largely separates local problems from global integration problems. Local prob- lems are typically Euclidean with some log- ical overtones, but global problems are usu- ally logical. In particular, system-wide real- time control problems must typically be considered logical as, for example, is real- time scheduling. Thus, there are really two kinds of real-time control software: one for controlling the Euclidean view and one for controlling the logical view. Although much of what is proposed here applies to both, the balance of this paper focuses on the logical view. Returning to the question of the lan-

SOFTWARE FOR INTEGRATED MANUFACTURING SYSTEMS guage environment, one can foresee a com- mon language for the logical view and a general way of handling a local subsystem that is programmed in another language. This can be accomplished by encapsulating the subsystem in a software component that externally appears to be written in the common language (Volz et al., 1986~. One can imagine encapsulating a robot in this manner. Distributed Language Environment There is, however, another important language issue. As was already noted, the software execution environment for a man- ufacturing system is inevitably distributed. There are three obvious ways to reflect this fact in the language environment. One way is to program each processor separately, with part of the programming task being the development of required in- terprocessor communication software on a case-by-case basis. This is typical of current practice and has the obvious disadvantage that writing ad hoc communication soft- ware is expensive. Another disadvantage is that debugging and error checking are es- sentially limited to single processors. That is, the software must be treated as a collec- tion of pieces rather than a single system. Still another disadvantage is that the soft- ware is partitioned along processor bound- aries, and these may not be the natural or logical boundaries. An alternative to this approach is based on a distributive operating system. Presum- ably this would significantly diminish the need to program communications explic- itly; however, debugging and error check- ing would still be fragmented, and so would unnatural program partitioning. Unfortunately, neither of these ap- proaches adequately supports the concept of software components. The problem is that a software component can extend over more than one processor. For example, the robot component shown in Figure 4 has its ~ . ~ . ~ ~ 85 System Control Computer Robot Intertace Robot Controller FIGURE 4 A software component spanning two processors. public interface visible on the system con- trol computer, and most of its private inter- nals are contained in the robot's controller. We believe that the programmer should not have to worry about this separation. In other words, in addition to the language environment being common, it should also be a distributed language (Volz et al., 1987~. In this way, it should be possible to write the real-time control software as one pro- gram, where a component might encom- pass several processors. The power of a common distributed lan- guage environment is that it simplifies in- tegration. Since the communication paths are transparent to the programmer, the programmer is allowed to think about the entire program without having to be con- cerned with processor boundaries. Further, debugging and compile time error checking take place over the entire program. This approach requires, however, a language translation system that is more than just a conventional compiler. Such a system is currently not available. Indeed, distributed languages are currently an active area of research. Our research on language translation sys- tems has focused on a distributed version of Ada (Volz and Mudge, 1987; Volz et al., 1985, 1987, 1988~. Ada was selected for various reasons, including the fact that Ada will be widely used and supported. This is important because manufacturing software must be in the mainstream if it is to benefit from progress in modern software engineer- ing and if it is to have access to a software components industry. Although Ada satis-

86 fies these requirements, further experimen- tation will indicate whether it is a proper choice for manufacturing. The language translation that we have developed is a pretranslator whose input is the entire Ada program and whose output is a collection of Ada programs, one for each target processor. Each of these in turn is compiled for its target processor using the pertinent compiler. A major function of the pretranslator is to insert Ada statements that handle interprocessor communication. As indicated in Figure 4, the part of the robot's internals shown in the system control com- puter could be the communication software inserted in this way. Formal Semantic Models Turning now to formal semantic models, the obvious questions are (1) what is being modeled and (2) why are the models needed? The logical views of such things as cells, factory floors, and process plans are being modeled, and these models are needed to develop the real-time control algorithms. Each manufacturing situation involves what is essentially a real-time probably sto- chastic scheduling problem. To control a manufacturing situation, it must be de- scribed and a scheduling algorithm devel- oped. In addition, models are needed as a tool to treat exceptional conditions in an orderly manner and as a foundation for cre- ating generic software components. This can be best illustrated by again re- ferring to Figure 3. To achieve a formal semantic model for the logical view of the component cell, it is necessary to have mod- els for all the components shown in the fig- ure. In addition, there must be an orderly means of combining these models as new components are created by assembling other components. For example, the model of cell will be some combination of the models of machines and transport, and the model of transport, in turn, will be some combina- tion of the models of robot and vehicle. Use ARCH W. NAYLOR AND RICHARD A. VOLZ of the phrase "some combination" is meant to emphasize that merely knowing the mod- els for the logical view of the individual devices that is, for the NC machines, the robot, and the vehicle is not enough. The individual models obviously do not encom- pass information on the logical aspects of the mechanical interactions of the devices and the constraints of the factory floor. For example, the model of the robot says abso- lutely nothing about the vehicle. In addi- tion to mechanical interactions, an under- standing must exist of the way the devices are interconnected by the software in ma- chines, transport, and cell. In other words, the approach to software components and the needs for models are entangled with each other. The formal modeling system (Naylor and Maletz, 1986) employed here grows natu- rally out of the logical view. The state of the model is, roughly speaking, all the log- ical conditions that are true at a given moment, and state transitions are caused by the execution of "changes," where a change causes logical conditions to be al- tered. "Changes" are similar to rules in rule- based systems. They differ from rules in that their execution typically has an associ- ated delay (for example, moving a vehicle from A to B takes time), and changes may occur simultaneously because the factory floor is a highly parallel system. Process plans are another source of en- tanglement of software and formal models. In a sense, process plans can be thought of as a kind of program; the factory floor can be viewed as a kind of computer on which these programs execute; and the real-time control software can be thought of as an operating system that ensures the efficient execution of process plans. Scheduling pro- cesses in the manufacturing system is far more complicated, however, than schedul- ing program elements in a computer oper- ating system. In computer operating sys- tems so little is known about future jobs that scheduling has to be simple, and some

SOFTWARE FOR INTEGRATED MANUFACTURING SYSTEMS version of a "fairness" criterion of efficiency is usually the only practical alternative. By contrast, in a manufacturing system a job can be considered as a part going through a step in a process plan. Thus, a great deal can be said about future jobs merely by knowing where each part is in its process plan. How to use this additional informa- tion is both a complication and a challenge. One is attempting to orchestrate the physi- cal movement of parts on the factory floor simultaneously with their movement through the appropriate process plan. Constraints on both of these environments make the scheduling difficult. There are two important things to be said about this approach to process plans. First, process plans are treated as separate and identifiable. That is, the description of a process plan is never to be intermingled with the description of the factory floor. In fact, a process plan is incorporated as a software component in much the same way that, say, a robot is. Figure 5 shows two process plan components and a factory floor component. Each process plan component contains information about steps in the plan and the ordering of these steps. The three components are assembled into the Manu- facturing System component. The impor- tance of the sharp separation between pro- cess plans and the factory floor is the reusability of each component. The factory Man. System - 'l 1 I Process Pro. fess plan plan - 1 Factory floor FIGURE 5 Assemblage of process plans compo- nent and factory floor component. 87 floor component can be used with other process plans, and, where meaningful, a process plan component can be used with other factory floors. It is clear that allowing the process plans and factory floor descrip- tions to be intermingled would severely limit such flexibility. The other thing to be said about this ap- proach is that the process plans are modeled formally in exactly the same way as any other component. The state of the model shows the parts that are currently progress- ing through the process plan and where each part is in the plan. Changes show what process plan steps are allowed next for a given part. In effect, this is a model of a logical view of the process plan. This means, among other things, that models of the process plans and the factory floor can be combined into a model that simulta- neously exhibits the constraints of the fac- tory floor, the constraints of the process plans, and the interconnections among these constraints. In other words, these compo- nents are assembled in basically the same way that any components are assembled. Of course, each step in a process plan is not an atomic action, as has been implied by the discussion to this point. However, most of the details of a step can be sup- pressed when one is concerned with con- trolling the logical view of a manufacturing system. For example, a step might be the execution of a parts program. In the logical view this execution would usually simply be a change that takes a certain amount of time. The individual statements in the parts program would be irrelevant. Generic Software Components The research approach proposed here is a coordinated blending of software compo- nents, a common distributed language, and formal semantic models. Although we be- lieve that this approach alone will have a major impact on software costs and flexibil- ity, there is more that can be done. In par-

88 ticular, "generic software components" can significantly improve software reusability. This phrase is used far more generally than computer language specialists normally use system. it. Indeed, some might take exception to this usage. Still, for present purposes a ge- neric software component will be some- thing to which one adds information and, perhaps, other components to obtain a soft- ware component. Rather than becoming entangled in a definition, let us present two examples one fairly simple and the other quite ambitious. Consider a family of similar material transport systems. They all use the same kind of vehicle, but the number of vehicles may differ from system to system. Although each system has a "road system" or geo- graphic layout, the road systems for two material transport systems may differ. As shown in Figure 6, any one ot these mate- rial transport systems is a software com- ponent that is, in turn, an assemblage of vehicle software components and a road system software component. Although dif- ferent from system to system, it should be obvious that the software that implements these various assemblages can have much in common. Each is doing essentially the same thing with similar software components. The goal of a generic component in this case would be to write one piece of software that would work for any one of the material transport systems. It would be supplied with information about the road system and Material transport _, ~ _ van 3 Vehicle 2 = _ 1. ~ 1 FIGURE 6 One of a family of material transport systems. ARCH W. NAYLOR AND RICHARD A. VOLZ the number of vehicles. Further, it would be supplied with components to be assem- bled that is, the vehicles and the road The key point, then, is that one piece of software can be used, even "reused," over the entire family of material transport sys- tems. Moreover, in this simple example it seems practicable and it is not difficult to imagine similar cases in which such generic software components would work. From the earlier discussion of a software compo- nents industry, one can also imagine buying such generic components. Next, consider a far more ambitious case, one involving a family of factory floor and process plans. In a manner similar to the previous example, one would like to have a generic software component that would, in effect, be a completely flexible factory "a ~ controller. The concept is as follows: The generic component would be given descrip- tions of a particular factory floor, a partic- ular set of process plans, and a description of the interconnections between them, then, based on these descriptions, a real-time controller would be realized without the need for reprogramming. This is obviously a very ambitious goal, one that is probably not completely attainable. In a sense, how- ever, it constitutes an upper limit for ge- neric components. It is also an instance of generics touching the world of artificial in- telligence (AI), since, to the extent that such a controller would be realizable, it would undoubtedly rely on AI techniques. Finally, given this concept of generic software components, an obvious issue is the form of the information given to the controller. The approach proposed here is to use formal models. For example, the in- formation given to the generic factory con- troller would be a formal model of the as- semblage of the factory floor and process plans. This, then, is the other use of formal models and another blending of the various parts of this research approach.

SOFTWARE FOR INTEGRATED MANUFACTURING SYSTEMS 89 device components such as robots and NC AN APPLICATION Let us now consider an experiment that applies this approach. This is an experiment with a partially generic factory floor con- troller. Figure 7 gives an overview of the experiment. A real-time simulator of a factory floor is contained on one VAX com- puter, and the generic factory floor control- ler is on another VAX. The common distrib- uted language is the distributed version of Ada. Software components are Ada pack- ages and tasks. An advantage of treating the factory floor as an assemblage of software components, for which we have formal semantic models, is that simulation is extremely easy. One merely replaces the private internals of lower-level components and leaves the pub- lic interfaces and their interconnections un- changed. "Lower-level component" means ONVAX] I Communications Factory Floor Controller Specl~cphon Factory Floor Specification Factory Floor Slmub~cr Simulator Database 1+ r ~ . Factory Floor Tracking Model Factory Floor Search Model 1 ~ 1 F' Search Database Tracking Model Database FIGURE 7 Factory floor simulator and controller. machines. The replacements are easily se- lected so that the real factory floor and the simulation have the same formal model. The simulator on VAX 1 is created in this way. As far as the controller on VAX 2 is concerned, VAX 1 behaves exactly as the real factory floor would. Now consider the factory floor controller on VAX 2. It contains another simulator of the factory floor, the tracking model, whose function is to keep track of the current state of the factory floor, that is, the current state of the simulator on VAX 1. The controller also contains a simulator, the search model, of the combination of the factory floor and process plans. It is used by the controller to explore alternative future scenarios, and it uses these explorations to select the next commands to send to the factory floor on VAX 1. The tracking model and the search ON VAX 2 Communications Factory Floor ~ Specification I 1 ~ . Factory Floor Controller Simulator Databass 4L di A Process Plan Models 3:

so model are created in essentially the same way as the factory floor simulator on VAX 1. Each is an assemblage of software com- ponents. This is also true of the factory floor part of the search model. In other words, the same assemblage of software compo- nents and semantics is used in three differ- ent places in this application. Since the purpose was to experiment with software components, their assemblages, and formal models, the controller is quite simple. After each change in the state of the factory floor, the controller explores differ- ent future scenarios using the search model, starting from the state contained in the tracking model. A few simple pruning rules keep the search manageable; clearly, more could be done. In a sense, this application creates a test bed within which various control algorithms can easily be examined. In any event, the controller is partially generic in the sense that it will work with almost any tracking model and associated search model. That is, the two models are the information supplied to the generic controller. Figure 7 also shows a typical result of using the distributed language pretransla- tor. The two dashed boxes labeled "Com- munications" would be inserted by the pre- translator. RESEARCH QUESTIONS We have stated our basic assumptions about how control software should be de- signed and developed, and we have dis- cussed each of them. However, this is only a beginning. It is certainly not a detailed recipe for software development, nor can one currently purchase control software de- veloped following this prescription. It will take about 10 years to realize this vision, particularly the generic part of it. Ten years may sound pessimistic, but considering how long the Ada and MAP efforts are taking, ARCH W. NAYLOR AND RICHARD A. VOLZ 10 years appears to be realistic. After all, this is a far more complex problem than MAP. It is relatively easy to see the major re- search directions that should be followed initially. Although the fundamental ideas of software components are known, much remains to be done in the area of distrib- uted languages to support them, particu- larly considering real-time issues and the fact that one is almost certainly dealing with heterogeneous systems. There are also many important issues at the boundaries between the basic assump- tions contained in this proposal. One is the boundary between software components and formal semantic models. We need a better understanding of this interplay. For- mulating a model for a factory floor is, among other things, an awesome task; there- fore, assembling a model from models of software components as the components are assembled perhaps with computer aids becomes extremely attractive. We also need to extend those ideas to the assembly of ge- neric software components. Furthermore, the development of control algorithms eventually generic ones should take ad- vantage of the system description as an assemblage of smaller descriptions. In par- ticular, the application of artificial intelli- gence techniques to such assemblies must be explored. At the boundary between software com- ponents and distributed languages, the ba- sic question is: Can all this be done without a crippling sacrifice of real-time perfor- mance? One must be concerned whether the assemblage-of-software-components structure and the relegation of this struc- ture to the distributed language translation system may combine to produce unaccept- able delays. Another issue concerns distri- bution, specifically, how the distribution of a software component over several proces- sors should be evidenced in the assembly of software components and their models.

SOFTWARE FOR INTEGRATED MANUFACTURING SYSTEMS SUMMAF~l We have argued that research on inte- grated manufacturing systems should be integrated in the sense that a number of interrelated problems should be attacked together in a unified manner. We have also admitted that we do not know how to do this in general. However, we have been able to make some progress on a particular prob- lem, and we believe that we can see how to carry out the required further research in a unified manner. REFERENCES Kaminski, M. A. 1986. Protocols for communicating in the factory. IEEE Spectrum 23~4~:5~62. Naylor, A. W., and M. C. Maletz. 1986. The manu- facturing game: A formal approach to manufactur- ing software. IEEE Transactions on Systems, Man, and Cybernetics SMC-16:321-334. Rentsch, T. 1982. Object oriented programming. Sig- plan Notices 1~9~:51-57. Shaw, M. 1980. The impact of abstraction concerns on modular programming languages. Proceedings, IEEE 68~9~: 1119-1130. Volz, R. A., and T. N. Mudge. 1984. Robots are (nothing more than) abstract data types. In Pro- ceedings of the SME Conference on Robotics Re- 91 search: The Next Five Years and Beyond. Robotics International. Dearborn, Mich.: Society of Manu- facturing Engineers. Volz, R. A., and T. N. Mudge. 1987. Timing issues in the distributed execution of Ada programs. IEEE Transactions on Computers, Special Issue on Par- allel and Distributed Processing, C-364:449-459. Volz, R. A., and A. W. Naylor. 1986. Final Report of the NSF Workshop on Manufacturing Systems In- tegration. Technical Report RSD-TR-17-86. Ro- botic Systems Division, Center for Research on In- tegrated Manufacturing, College of Engineering, University of Michigan, Ann Arbor. Volz, R. A., T. N. Mudge, A. W. Naylor, and J. H. Mayer. 1985. Some problems in distributing real- time Ada programs across machines. Pp. 71-84 in Ada in Use: Proceedings of the 1985 International Ada Conference. New York: Cambridge University Press. Volz, R. A., T. N. Mudge, A. W. Naylor, and B. Brosgol. 1986. Ada in a manufacturing environ- ment. Pp. 433-440 in Proceedings of the Fifth An- nual Control Engineering Conference, Rosemont, Ill. Volz, R. A., P. Krishnan, and R. Thierault. 1987. An approach to distributed execution of Ada programs. Pp. 187-197 in Proceedings of the Workshop on Space Telerobotics. Pasadena, Calif.: Jet Propul- sion Laboratory. Volz, R. A., T. N. Mudge, G. D. Buzzard, and P. Krishnan. In press. Translation and execution of distributed Ada programs: Is it still Ada? IEEE Transactions on Software, Special Issue on Ada.

Next: Process and Economic Models for Manufacturing Operations »
Design and Analysis of Integrated Manufacturing Systems Get This Book
×
Buy Hardback | $55.00
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

Design and Analysis of Integrated Manufacturing Systems is a fresh look at manufacturing from a systems point of view. This collection of papers from a symposium sponsored by the National Academy of Engineering explores the need for new technologies, the more effective use of new tools of analysis, and the improved integration of all elements of manufacturing operations, including machines, information, and humans. It is one of the few volumes to include detailed proposals for research that match the needs of industry.

  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  6. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  7. ×

    View our suggested citation for this chapter.

    « Back Next »
  8. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!