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.
DESIGNING AN INFORMATION SYSTEM FOR INTEGRATED MANUFACTURING SYSTEMS UERICH FLATAU ABSTRACT The development of improved software and the availability of low- cost computer hardware allow hard and soft automation to be combined in ways that can provide powerful complex manufacturing systems. In addressing the system issues, it is necessary to address the problems associated with total integration. This paper de- scribes a process by which complex integrated manufacturing systems can be systemati- cally planned. It discusses how the information system that will support the integrated system can be planned, including anticipating the need to make modifications to accom- modate future possible changes in both technology and function. INTRODUCTION The recognized decline in the productiv- ity of many U.S. companies over the past 15 years has been a strong stimulant for individual companies to search for ways to improve their operational efficiency and to become more competitive in the market- place. Many companies have achieved pro- ductivity improvements that place them among the most efficient in the world, whereas others continue to search for the reasons for their problems. Although blame is often placed on such issues as government intervention, increases in energy cost, and labor regulations, an analysis of successful companies suggests that a significant part of the problem often results from factors internal to the company. The general ap- proach to management, the concepts used to market the product, the policies followed in making investments, the importance as- 60 signed to product quality, and the reward system for employees have all been shown to critically influence the competitiveness of a company. The successful companies have changed their attitudes toward customers, their pro- duction processes, and their internal man- agement approaches. They have chosen to emphasize high-quality production rather than high-volume production. They have found that the production of higher quality products not only does not cost more money, it reduces costs. By reducing manufacturing costs, it helps achieve higher profit margins and offers the opportunity for the manufac- turer to achieve a larger share of the mar- ket. In many cases, it has been shown that higher quality products yield as much as 40 percent higher return on investment than do lower quality products. The achieve- ment of this competitive advantage is the challenge that confronts today's managers.
AN INFORMATION SYSTEM FOR INTEGRATED MANUFACTURING A review of successful companies also suggests that there is no single technical so- lution that can be easily copied or bought (Hall, 1987; Hayes and Wheelwright, 1984~. Quality circles, just-in-time manu- facturing, or automation must each be tailored to the needs of the individual com- pany. Managers of manufacturing enter- prises face a demanding complexity of indi- vidual functions as they attempt to achieve their business objectives. A process, not just a program, is required to achieve corporate goals and objectives. At Digital Equipment Corporation, this process is described as the "system improvement process" or, simply, striving for manufacturing excellence. Computer-integrated manufacturing (CIM) is the term often used to describe this improvement process. In this paper, CIM is used to mean the entire manufacturing en- terprise not just the production subsystem of a manufacturing operation. Current manufacturing enterprises are complex sys- tems with a multitude of internal and exter- nal relationships. These relationships must be optimized if the organization is to achieve the best possible performance. A principal corporate goal must be the development of clearly defined corporate objectives, including well-defined strategies for product, sales, marketing, finance, and manufacturing. Corporate strategies and functions must be integrated in support of the corporate objectives. The integration of the different strategies and functions in a manufacturing enterprise is critical to its success. Rather than each function attempt- ing to optimize individually its operation, optimization of the overall enterprise must be the primary objective. In addition, the criteria for measuring the performance must be clearly established by manage- ment, and these criteria must be consistent with corporate goals and objectives. SYSTEM INTEGRATION In considering the manufacturing enter- prise, one is immediately confronted with 61 the inconsistencies between the data that describe the product, the technology, or the know-how involved in the manufacturing processes, and the data used to describe the management or the business operation. At least three types of data sets are frequently used in an industrial enterprise. One data set is used in the CAD environment, an- other for process planning, and a third for manufacturing. All three of these are sup- posed to describe the same entity and the same object independently. Unfortunately, these data sets are frequently overlapping and incomplete. Only a few companies have been able to achieve a level of integra- tion that allows the use of a single data set. Integration is a difficult task because of its many different facets (Chestnut, 1967; Synnott, 1987~. As everyone knows, inte- gration is not a binary state. A system is neither completely integrated nor com- pletely unintegrated. In fact, every manu- facturing system in place today is partially integrated, for without some integration it would not be possible to produce complex products such as aircraft or automobiles. The problems that most frequently arise are with the accuracy of the data, the speed of transmission of the data among different functions, activities, and subsystems, and the difficulty in properly describing entities in the data bases. In attempting to integrate functions and subsystems into a total system, it is essential first to define the purpose, the boundaries, and the goals for such an integrated system. It is useful to start with the broad system model shown in Figure 1. This input- output model represents a manufacturing enterprise on the highest conceptual level. Inputs of material, energy, capital, and la- bor are transformed and transported and result in products, waste, and ultimately corporate profits. The system is kept in bal- ance by various feedback and control ac- tions. From an information system point of view, this simple model can be used to rep- resent a manufacturing system that consists
62 Inputs Process Outputs __ People Material ~ Transformation Energy activities Cap , I 1 ] Control 1 Products Waste Technology Profits , Environmental Feedback ~ FUGUE 1 Conceptual model of a manufacturing enterprise. Of processes and data, both of which can be handled by a computer. The first step in accomplishing this is to represent the phys- ical processes by algorithms so that appro- priate computer programs can be created to control these processes. The second step is to define the data needed by the control algorithms, namely, the data required to trigger processes, to track materials, and to control such items as tools. This model also illustrates how the exchange of data and messages between processes can lead to in- tegration. Enterprise functions Design Production User ~ _ FIGURE 2 Manufacturing enterprise view. ULRICH FLATAU ~ Environment Let us take a closer look at what integra- tion means in the context of an information system. Since programs and slate make up the system, the degree of integration is de- termined by an analysis of processes and data. Figure 2 is a representation of the manufacturing enterprise, the broad func- tion needs, and the data and information technology needs. Data in this context must have a name and a value. The problem in many of today's manufacturing systems is that different names and different values have been allowed to exist for the same en- Data sets Marketing and sales Administration `i Design data Product data Production data Control data Costs and prices J1 1t Information technologies Data processors Networks Data storage and retrieval Interfaces and protocols
AN INFORMATION SYSTEM FOR INTEGRATED MANUFACTURING tity. A principal reason for this is that ap- plications for different functions are fre- quently written by different groups. In addition, most of the current systems are batch-oriented so that timely updates of the data are nearly impossible. Let us assume that the data name and the data value have been defined for one object or entity. In a distributed system, multiply defined data names and multiple values are allowed for different states of the total system. In a distributed system having two distinct states, a name and value for an entity will possess four distinct values. A logical goal for data integration should be to achieve a single data name and a single data value definition for each of the four entities in the system. Adding the next ele- ment, the process, adds two more distinct quantities for each state, thus requiring eight distinct values for the name, value, and process description of the system. Since each of these data values can be stored lo- cally that is, on the same node or re- motely that is, on different nodes an- other factor of two in the values is introduced, bringing to 16 the different val- ues required if integration is to be achieved. When control is added to the matrix, we are confronted with a system that has 32 different values and thus 32 different stages that must be included in a total integration of the system. The degree of integration must be defined objectively to reduce am- biguity to the maximum degree possible. Meaningful comparison of differences in the stages of integration requires estab- lishing a set of criteria that reflect the system goals. System integration can be measured by the following criteria: performance, availability, maintainability, expendability, flexibility, system development time, cost of ownership, data integrity, and reusable code. The stages of integration and these criteria provide an objective way to mea- sure and to judge system development al- ternatives. This can be illustrated by con- sidering the implications of specifying a , ~ . 63 centralized system, namely, a system with a single data definition, single value defini- tion, and a singly defined process. Although such a system may operate satisfactorily, the performance is likely to be low and the costs high. If the resulting performance and cost cannot be tolerated, it will be necessary to select other criteria that will best support the business goals. Defining the integration criteria enables the designer to measure the level of integra- tion and to determine the value matrix in accordance with the attributes that will be obtained. These matrices help define the stages or levels of integration by assigning the costs and benefits and by helping de- velop a plan for implementation. Integration Criteria The starting point for the design of an integrated system is the ranking of the in- tegration criteria and the selection of the proper level of integration. If a very short development and implementation time is demanded, one will probably be forced to settle for a multiply defined data and pro- cess specification. The reason for this is that the application packages will likely come from different vendors, who will not have the time or incentive to coordinate to the degree needed to accomplish a high level of integration. Nevertheless, a reasonably in- tegrated system can be achieved if the right data and process update strategy are se- lected at the outset. Achieving a certain level of initial inte- gration is possible, but keeping an evolving system at that same level of integration is difficult. Ongoing change is difficult to handle if the level of integration is to be maintained. The impact of this process on ongoing system costs is important, since the cost of maintenance is normally much higher than the cost of installation. System integration improves the capabil- ity for achieving good communications within the system. There are three funda-
64 ULRICH FLATAU CIM - System Node A Node B l Subsy Tom | Rl7rP r SubSYStem l RDBA Shared LDBA data LDBA - Local data base access PTP - Program to program RDBA - Remote data base access RPTP - Remote program to program STS - System to system FIGURE 3 Physics data exchange methods. mental ways of communicating in distrib- uted systems. As shown in Figure 3, there is system-to-system, program-to-progran~, and program-to-data communication. These fundamental means of communicating can be implemented in three different modes: the batch or buffered mode, the segmented or partly buffered mode, and the real-time mode with immediate response. Implementation of these different meth- ods of communication requires specialized tools. Hardware, system software, and spe- cial application languages are needed. If these basic forms of communication are not supported in languages, operating systems, and hardware, it will be especially difficult to implement an integrated system. The alternative is to write libraries in different languages to compensate for the functional deficiencies and language extensions. The different forms of communication can be approximately divided into three broad classes. The first is process-to-process communication, which, as the name im- plies, is a one-to-one relationship. The sec- ond is a many-to-one relationship in which many processes talk to one process. And the third involves one process communicating with many others, a one-to-many relation- ship. Each of these relationships presents a unique set of issues. In most distributed integrated systems, a single process must be in communication with, or be able to receive messages from, many other processes. Thus, the one-to-one relationship is not generally appropriate for the distributed environment. Implementation of the many-to-one re- lationship is severely limited by currently available computer hardware. Most cur- rent systems are Von Neumann computers, and they can execute only one operation at a time. Therefore, with most available com- puters, there is no way to achieve real-time parallel communications. The one-to-many relationship is limited by system timing considerations. There is currently no way to update the data at dif- ferent locations in a single time frame. One needs many time frames to distribute data in a one-to-many relationship. Therefore, it is difficult to update data in distributed data bases in a circumstance in which multiple data definition and multiple process defini- tion has been allowed. This difficulty leads, therefore, to a concern about maintaining data consistency when it cannot be ensured that the time delays in updating have not
AN INFORMATION SYSTEM FOR INTEGRATED MANUFACTURING created a set of inconsistent data through- out the system. Current hardware limita- tions need to be critically examined. The exchange of physical data can help achieve a form of integration. Having a process running on Node A and another process running on Node B requires system- to-system communication. One needs sup- port in the form of language, operating sys- tem, and the network to implement this form of communication. Support for re- mote program communication that is, di- rect communication may be needed. A buffered communication for remote data base access or local data base access may be used. All of these different forms of com- munication need to be supported by lan- guages, by operating systems, and by net- works. It is not uncommon to find that the support for the network and the capabilities of the operating system are insufficient to ensure that CIM implementation will be successful. Subsystem Needs The next step is to look at the communi- cation needs of the subsystems. Figure 4 Node A PTP ~ DMA memory | DMA ~ Shared LDBA Shared data FIGURE 4 Communications now of subsystems. Node A 1 65 shows that in the subsystems program-to- program communication is needed on the same node as well as on different nodes. Communication in this sense means ex- changing data, exchanging commands, and exchanging events. Since real-time data are not stored, direct memory access may be needed in real time to both the local sys- tem and the remote system. All of these different communication functions must be functionally embedded, implemented, and supported by programming languages, op- erating systems, data management systems, and networks. Although this appears to be straightforward, few operating systems al- low for this range of functionality. There may be needs for access to local or remote data bases in a real-time environ- ment. The simplest task, of course, is ar- ranging for a single process to use its own data. One might also have local data base access, in which case the process and the data are located on the same node or two different applications share the same data base. One may also have remote data base access where the data may be somewhere in a remote system. Obtaining access to a remote data base is very tricky using a net- Node B Appilcatlon I ~ Application ~ I Application RPTP RDMA LDBA RDBA DMA - Direct memory access LDBA - Local data base access PTP - Program to program RDBA - Remote data base access RDMA - Remote memory access RPTP - Remote program to program
66 work and a programming language. These are the basic prerequisites for communica- tion or integration of distributed systems. Data Consistency Even this simple conceptual view of sys- tem integration shows how difficult system integration may be and the nature of the tools that are needed for integration. These aspects become even more complicated when one includes the aspects of real-time events, command translation, remote data base access, and control data. There may be many good reasons to accept an inte- grated system design with multiply defined processes and multiply defined data names and data values, but it is essential that the integration strategy include a procedure by which data and process consistency is en- sured. There are two basic philosophies to achieve the desired consistency a pull sys- tem, which requires the receiver to ask the sender for data, or a push system, in which the sender initiates transfer to the receiver. In a push system, the new data and pro- tion cesses will be automatically distributed to all receivers, as occurs for an electronic mail system with a distribution list. This ap- proach requires considerable control and system intelligence. In a pull system, the user is responsible for requesting the new data and programs before program execu- tion is initiated. Examples of this approach in manufacturing systems are cell control- lers and area controller links. System Planning It should be clear that integration re- quires a great deal of system planning. As an ongoing process, it requires a long-term commitment from high-level management, political unity and coordination of all ele- ments in the enterprise, and, finally, strict discipline in function, data, and process ULRICH FLATAU definition. System integration requires some of the same approaches required in the building of a house. For example, serious construction on a house would not be started without a plan. Although such a sequence of events would not be expected to occur in computer-integrated manufac- turing systems, systems continue to be started without a clear plan having been developed for the integration. All too often a detailed plan is replaced with a hope that somehow, sometime, all the disconnected pieces will come together to make a highly effective system. What must be made clear is that there are too many different technol- ogies, functions, and requirements in such a system to be left to chance. It will not work effectively without a plan and the commitment from all who are involved. The engagement of the necessary part- ners in achieving CIM solutions requires a clear strategic plan and a strategic partner- ship among all those concerned. The ele- ments of this strategic partnership include . Integrated planning and implementa- Computer technologies Factory automation Office automation Education and training The creation of a system of this complexity must be viewed as much more than simply writing an order for procurement. It in- volves the integration of the entire manu- facturing enterprise. Many partners have to be involved if all the different technologies, processes, people, and data are to be suc- cessfully brought together to form an inte- grated system. Not only are there no turn- key CIM systems available today, but also, in view of the complexity of the entire sys- tem, it seems unlikely that turnkey CIM solutions will be available in the foreseeable future. This suggests that an architectural system approach is essential.
AN INFORMATION SYSTEM FOR INTEGRATED MANUFACTURING ARCHITECTURAL FRAMEWORK FOR CIM TECHNOLOGIES CIM systems must be considered as be- longing to a class that can be described as human activity systems. Arriving at a clear definition of the problem in human activity systems is difficult. Identifying and solving a problem in physical systems may take considerable time and effort, but experts can usually reach an agreement on the statement of the problem. This is often not the case in social systems. In most social systems, there is no simple problem state- ment, and there is no simple right or wrong answer to that problem. There is just a problem area. The information that must be distributed in a human activity system indicates that two separate information systems must be considered. One is implemented through policies and processes (that is, the formal information system), whereas the other (the informal information system) ties the peo- ple in the organization together. Many cur- rent manufacturing systems still depend heavily on informal information systems. If something goes wrong with the formal sys- tem, we still need experienced people to fix it. One also sees the requirement for having an expert with many years of experience with the process, since a mathematical model of the process is not sufficient to al- low analysis of all likely problems. People An organized way to plan and imple- provide the learning capability and thus en- ment complex systems must be devised. able improvements to occur in the opera- Digital Equipment Corporation's CIM sys- tem architecture will be used as an example of how this problem can be approached (Digital Equipment Corporation, 1986~. The balance of this paper concentrates on the formal system that relies on procedures, protocols, and detailed specifications for its success. tions. 67 specialization. Division, classification, sep- aration, partition, and segmentation have characterized analysis. Much of the re- search in each of the separate fields of sys- tematic knowledge has resulted in a further narrowing of the specialization. To create a successful system that properly relates to the human system will require that more time be spent on synthesizing and assimilat- ing the existing knowledge. Accomplishing transformations is basic to human activity systems. The input-output model is a powerful tool in representing these systems, in that it can be used to de- scribe many different aspects of the system. Since a transformation process or activity can be executed by people or by machines, it is essential that the division of labor be- tween humans and machines be clearly considered. The technical systems, com- posed of machines and processes, though manageable and predictable, are relatively inflexible. By contrast, the human part of the system is somewhat unpredictable but flexible. Because CIM systems should be highly integrated and flexible, it will take careful analysis to determine the part that should be included in the technical system and the part that should remain in the so- cial system. To ensure that the system will be acceptable to the user, the planning and implementing processes for complex CIM systems must include those users. The currently available system analysis and design tools were developed for and by engineers to analyze and to plan complex physical systems. They do not, however, take the total system into account. In par- ticular, the human elements of the system are not represented in these methodologies. Furthermore, these techniques concentrate more on analysis than on design. In the effort to create effective analytic tools, there has been a movement toward Distributed Systems Manufacturing systems are distributed systems. They use distributed resources such
68 as hardware, data, events, and protocols. Their success is determined by the capabil- ity to control the processes that are used in the transformation of the resources. Con- trol of the processes involves monitoring the status of processes as well as the manage- ment of the resources. These systems use resources and process- ing software from different vendors. In this sense they are heterogeneous systems. To integrate these diverse resources it is neces- sary to use a variety of protocols, interfaces, handlers, and management tools. Many of these tools, however, are proprietary to the vendor that created them. This discussion leads to the following rather simple characterization of manufac- turing systems. They are distributed, het- erogeneous, and vendor-supported. It is the combination of these characteristics that led the Digital Equipment Corporation to ad- vocate "open systems." An "open system" is defined as one that allows the "open" exchange of information O .es among elements of the systems through the hi use of common standards. For such sys- tems, the exchange of data, either struc- tured or unstructured, files, events, com- mands, and application processes can be accomplished without regard for the partic- ular vendor that supplies the subsystems. Architecture for Distributed Open Heterogeneous Systems Proceeding with a successful development requires rules, blueprints, and guidance for system planning and process implementa- tion. This will provide a framework for systematically examining application devel- opment and selection, the integration of product development, the coordination of vendor developments, and the planning for services such as training. Having a plan in place is especially desirable for product de- velopment. If product developers agree on standards, the development of subelements can be done in parallel, thereby shortening ULRICH FLATAU the implementation time and reducing the cost of the system. Systems can be imple- mented one piece at a time, with confi- dence that system extension is possible and easy to accomplish. A successful plan for distributed, heterogeneous, and open sys- tems is critically dependent on standards. Thus, the need for a plan is clearly de- pendent on the creation of a system archi- tecture. In abstract terms, an architecture is the structure and relationship among sys- tem components. It is a framework for log- ical and functional implementation that uses the same rules and principles for prod- uct design as are used for system implemen- tation. The steps that must be taken in cre- ating an architecture are . els; · Establishment of goals; Identification of hypotheses and mod- . Establishment of principles and rules; Integration of available resources; and Identification of the necessary technol- The goals for a system architecture for discrete manufacturing must be to provide growth paths that build on investments in existing CIM systems and to provide a structure for CIM system optimization. The fundamental hypothesis in the creation of the CIM system and the hypothesis around which the architecture is developed is that all processing functions and related control functions are expressible in the form of data and that these data can be transferred, processed, and stored by computer technol- ogy. To be useful, a CIM architecture must consider a common language, system defi- nition, reference models, standards, and principles and rules for system and product design. Enabling technologies, techniques, operation policies, business rules, and so forth will change. Therefore, the architec- ture should allow for an infrastructure that anticipates that changes will be needed. Planning a CIM system requires that an- swers be developed for these basic ques-
AN INFORMATION SYSTEM FOR INTEGRATED MANUFACTURING tions: Why does the system exist? What is it going to produce? How will the product be produced? Because we do not often start from scratch, we usually take existing man- ufacturing systems and define and plan how to improve them. It is particularly helpful in the planning phase to have a conceptual model of the system in question. The com- ponents of the system mode! are people, processes, data, automation technologies, and material; the relationship among these components may be organizational, func- tional, logical, temporal, or physical. Tim- ing relations deserve a special comment be- cause they are so complicated. Information is valuable only when one receives it at the right time. This is one of the key goals of CIM systemsproviding the right infor- mation at the time that it is needed. Although one of the CIM system hypoth- eses is that the movement and transforma- tion of material can be triggered and con- trolled by data, this is not explicitly discussed here. White (1988, in this vol- ume) discusses this aspect of CIM systems. CIM systems are business-oriented hu- man activity systems that recognize that a minimum set of activities or processes must be executed to produce a product. There is also a minimum set of data that ties the dif- ferent activities together. Therefore, the ap- proach to system analysis and system syn- thesis is a business-based system approach, where the functional model reflects the bus- iness, its processes, and its data. This mode] will change only when the nature of the business changes. Since this is infrequent, the functional system mode} should be very stable. The system objectives dictate neces- sary activities or processes in a manufactur- ing system. Based on this assumption, the answer to the often-asked question "What comes first, data or processes?" is clear. The sequence that should be followed is 1. Identification of the business function, 2. Definition of the logical data that are needed; 69 3. Definition of the physical data that are needed; and 4. Definition of the physical functions. During the process of analysis and de- sign, it is essential that the user and the system people be brought together. It is use- ful to encourage the data structure defini- tion to be done by the system people in a top-down approach, with the activity and process definitions being done in a bottom- up approach. The user must be the one to identify what is needed to be successful. But the user is normally not an expert in information technology, and thus the data structure should be designed by system people. After both groups have completed their tasks, there should be a cross-check of whether all the data are available for the defined processes and vice versa. Before applying specific techniques such as structural analyses and design techniques to identify the system activities and the data needs, one must first define the boundaries of integration. Then it is necessary to de- compose the system into relevant functional subsystems and to define the basic business functions and entities. From there, it is nec- essary to define, in parallel, the data struc- ture and the business subfunctions. This procedure allows the development of any level of detail in the analysis. A functional model, on the highest con- ceptual level that reflects the business func- tion of the desired system, is useful in help- ing define the integration boundaries and in answering the question, "Where should we start to integrate?" According to the predefined business goals and objectives, one should select a functional subsystem and start system integration where it might be most desirable and successful. Although it is desirable to design subsystems so that they can work together, it is entirely impractical to plan or understand simultaneously all the subsystems that an enterprise will need to run the business. What is needed instead is freedom for user areas to employ their own
70 ULRICH FLATAU Corporate Goals and Objectives { MarkeUng | Sales/ services 1~- ~ 1 , It ~ 1 1 Business planning _1 ~1 Product engineering ~ 1 1 1 Process engineering , ~ t.~ Material and Ume management ~ , Shipping Storage Production _ and assembly ~- Flnlahed products FUGUE 5 Functions diagram of manufacturing enterprise. subsystems and at the same time to insist that they obey certain rules. These rules need to establish a stable framework for selection or development of an application and to set the conditions for data exchange in such a way that independent subsystem develop- ment can proceed. The outcome of an analysis of the form described can be demonstrated with the help of Figures 5 through 7. There would first be created, as in Figure 5, a high-level conceptual mode} of the manufacturing sys- tem. Second, as shown in Figure 6, a more detailed description of the subsystems would be developedfor example, the product design function. Figure 7 shows the infor- mation flow. On the next level of functional analysis, each of the entries in Figure 7 would be expanded for each specific task. An example of such a task might be struc- tural analysis. In this example, the next level of detail would include the logical connec- tion between topics such as thermoanalysis and static analysis. The data flow for a spe- cific subsystem must indicate the data cre- ated and when they are updated or used by the function. Inventory With the ongoing activities and the data flows having been identified, the layout of the physical system can be accomplished. An integrated functional model, both a data mode] and a physical mode! for the selected business subsystem, should be the result. It is important to note at this point that the integrated system that has been created can be entirely manually based. There is no need to use computer technology to support such a system. The principal reason for us- ing automation and information technol- ogy is to increase speed and performance so that the information and goods e.g., the material and tools will be delivered on time. Also, an automated system should im- prove the accuracy or quality of data over those systems in which data are normally reentered. After the task to be accomplished has been defined, it is necessary to answer the question, "How can it be done?" One goal of the architecture is to make independent, to the extent that it is possible, the business functions from the technology functions. As noted earlier, the business model changes slowly for a company, whereas the technol-
Order | Concopt r Engineerlng | . Alternative engineorlng design _ FIGU~ 6 Product design functions. Engineerlng changes/ part definlUo~_ Analysis data Test data ECO-FIIe Standard parts filos Part dennlUon nl. Product history data Management Decl~lon ~ ~ ~ InformaUon r , I T l l ! . Hltg. pre- Detall Mfg. analysis cons. BOM drawing 1 l Enginoorlng change control Per-product | r Hardwaro | I costing I l model l | Reloase l r Drawing~ | To Procoss Planning and Schodullng | Part geometry/ 1 material I r 1 , ECO Request BOM ontry coding and numborlng ~<_ ~ Product | design I On-llne data entries Engineerlng drawing data BOM : ~- : 1 ~ 1 1 1 ~ 1 | Tool data I l r I 7 | | Where used | | retrievals - I Part do11nitlon ~ / | Blil of I filo-malatenanco +~ | material | | (BOM) ~ I ~ I retrieval ~uct I ~ I ~ dennltlon ECOs J b~aintenanc FIGU~ 7 Information flow, file level. 71 | Test Parts cost flle I 1 ~ 1 Design onginoer data baso Part dennltion nl. Product deflnlUon nl.
72 ULRICH FLATAU User l User Interface I _ Graphic utility system Appilcatlons Processing Global data management 6 | Preseniatlon 5 | Session 4 | Transport 3 | Network l 2 | Unk 1 | Physical l User sublayer Processing sublayer Data management sublayer FUGUE 8 Proposed or available standardized interfaces and protocols for implementation of computer-integrated manufacturing. ogy used to support the business activities may change at any time. Thus, it is desir- able in the architecture to separate function from supporting technology. Functions can be grouped by different cri- teria. For example, functions can be grouped according to the same supporting technol- ogy or according to their use of the same or similar data. According to the simple pro- cess model being used here, only four ma- jor layers are considered in the technology model. There is the data creation or use layer (data sink and data source), the pro- cessing layer, the data storage and retrieval layer, and (for distributed systems) the net- working layer. The best way to separate distinct func- tions is by layering, as shown in Figure 8 (International Standards Organization, 1982~. Layering allows description of the desired capability, independent of the tech- nology used in the software or hardware. All layers are independent of one another. Although they use the functions, it is not important how that function is performed. One of the best-known layered models is the open-system-interconnect (OSI) model for networks. The proposed model shown in Figure 8 is an expansion of the OSI model in that it includes the data management sublayer, the application sublayer (in this case, processing), and the user interface sublayer. It also includes integration of re- sources (e.g., interfaces, handlers, and pro- tocols), and it shows how they are used to separate layer and sublayer from each other. Using this model allows us to de- scribe the desired functionality from one layer without defining how it should be im- plemented. Each layer contains functions that are manifestly different in the process per- formed or the technology involved. The purpose of layering is twofold: first, to take advantage of advances in hardware or soft- ware technology without changing the service expected from and provided to the adjacent layer and, second, to hide from the user everything that is not directly re- lated to the user's function. Interfaces are rules for the physical communication be- tween dissimilar layers or sublayers. The interfaces handle communication between dissimilar layers, provide access to service from the lower layers, define rules for ser- vice access from higher layers, and handle
AN INFORMATI ON S YS TEM FOR INTE GRATED MANUFAC T UR ING the process of exchanging data among lay- ers. Handlers define the connection be- tween the service layer and the supporting operating system and hardware. Their pur- pose is to provide access to operating system service, to provide access to device drives, and to decouple service layers from the hardware. In this sense, a language com- piler can be thought of as a handler. The user layer allows device-independent data input and output and user communication with the processing layer. It also provides the user an interface with the system ser- vice. The processing layer provides re- sources for process execution. The process- ing layer supports the execution of system management processes, application pro- cesses, and application management pro- cesses. It also allows applications to ex- change data automatically and to provide for message exchange between heterogene- ous applications. The data management layer provides data and device independ- ence for data storage and retrieval, and it provides all necessary functions for data and file management in open-distributed and heterogeneous systems. It also ensures data 73 consistency, security, and accuracy in dis- tributed and heterogeneous systems. For horizontal integration, networking tools are needed. Networking provides physical and logical connections to other open systems. It provides for data, file, and command exchange between distributed systems. Horizontal integration in distributed sys- tems requires a broader tool-set. Protocols are required. Since the protocol defines the communication rules between similar ser- vice layers, it is only a logical concept. There are three fundamental functions the proto- col performs: establishing a necessary con- vention, determining a standard communi- cation path, and identifying a standard data element. Protocols are required for network- ing in distributed systems and for stable ap- plication-layer integration and connection to other open-distributed and heterogeneous systems. Not only do they provide for data file and command exchange between differ- ent systems and applications, they are nec- essary to understand the meaning of data transported between applications. By using standard protocols, it is possible Systeml Information System 11 [~ ~ ~ ]D . ~ . k WE~:= ~ .~ . ~ . _ ~ red _ Data storage and Data Data storage and ~ vim retrieve ~ ~ . r ~ ~ ~ ~ Networking layer I = ~ ~ 1 1 Data storage and Data _ ~- retrieval layer Operating system Signals _ Hardware L] ~ ~ Data storage and retrieval layer .- 1 1 Operating system | | ~ Hardware FUGUE 9 Layered model of open system architecture for computer-inte~ated manufacturing.
74 / Marketing Business planning Sales/ services Material and time management / Product engineering ~ Shipping ~ Storage ~ Inventory (,L(' ' 11 19 ~ 111 1' ' 111 1p' FIGURE JO Enterprise function supposed by information technology. to reduce dramatically the total number of protocols that are needed for system integra- tion. The model shown in Figure 9 clearly indicates how one can separate function from technology, and where one needs pro- tocols, interfaces, and handlers to integrate heterogeneous systems. It is obvious that in- terfaces and handlers can be proprietary to achieve integration and data message pre- sentation, but protocols must be standard. Every activity or process that was iden- tified in the earlier functional analysis is a candidate to be supported according to the technology model. Manually supported activities and automated technology-sup- ported activities can coexist in systems that are planned and implemented according to the architecture described in this paper. One can automate and integrate a subsys- tem and later integrate this subsystem with other subsystems, as shown in Figure 10. Generally speaking, there are three ways to integrate systems. The first is to design, plan, and implement without regard to any existing system or physical entity. Seldom does one have the chance, however, to build an integrated system with a "clean piece of paper." The second approach is to extract data from existing systems to build an inte- grated system. A rare case occurs when data can be used "as is" that is, when an exist- ULRICH FLATAU ing system satisfies function and data mod- els. The third and most usual way is to design and implement a system in pieces over a period of time. This means replacing the old system with one that is new and more integrated. Such a migration does not contradict the goals of integration when the conceptual model for the total system is well defined. It is not possible, however, to ret- rofit a high level of integration into a sys- tem where the business function, analysis, design, and concept of data flow have not been included from the beginning. The conceptual model of the manufac- turing enterprise presented here allows the grouping of subsystems into logical business functions. These different subsystems ad- ministrative operations, graphical interac- tions, number crunching, batch processing, transaction processing, and real-time con- trol represent different user groups with unique requirements of the supporting in- formation technology. The users of these subsystems execute administrative opera- tions, work with interactive graphics, exe- cute CPU-intensive processes, work on transaction processing systems, and operate in the real-time environment. To reflect the different user needs, we have defined dif- ferent user profiles, using the general model shown in Figure 11. Each of these profiles
AN INFORMATION SYSTEM FOR INTEGRATED MANUFACTURING C User ~ - } User layer {1~ ~ Processing layer | l._ ~ 1 T ' rim {1~ ~ Neiworkin9 lay~r | 1 I Data storage and retrieval layer Operating system Hardware - 1~ FIGURE 11 System architecture for computer- integrated manufacturing: Layered model. (Figures 12 through IS) shows a different implementation of the same functional lay- ers. The unique communication, data man- agement, ant! operating system require- ments for a real-time environment lead to a different implementation in the different 75 functional layers. It is obvious that there is not one single application protocol or net- working protocol that fits all user profiles. The results show that the requirements for hardware, operating system, user interface, and data management differ from user pro- file to user profile. In planning for the r ~ ~ User layer . . Operating system l T GKS PHIGS Analysis Processing layer Planning Decision making Data storage and I COD retrieval layer - T l working layer ) DECnet, SNA Hardware Processing Support Transaction Processing ~ Report Generation ~ Inquiry Processing FIGURE 12 Planning and control profile.
76 ULRICH FLATAU Plotter Tablet ' . . ~ L! ' 11 Scanner (Engineering) ]1 ~ ~ User layer Processing layer data storage and u u L_~trleval layer ~ ~ Networking layer Operating system Hardware GKS, CALCOMP CORE, PHIGS PDDI IGES, EDIF DECnet, SNA, TOP Ethernet Processing Support ~ Number Crunching ~ Matrix Operations ~ Interactive InpuUOutput FIGURE 13 Interactive graphic profile. Vlslon-System Barcode CMM Sensors NC-Machines ~ Robots Readers Terminals User layer Processinglayer | RS 494 BCL Data storage and retrieval layer r T , MAP Networking layer | Ethernet, DECnet Proway Operating system Hardware Processing Support - Logic Operation · Scanning ~ Interrupt Support FUGUE 14 Real-time user profile. RS-232C, RS - 22 RS-499 20mACL
AN INFORMATION SYSTEM FOR INTEGRATED MANUFACTURING Scanner Printer Plotter Terminal . _ ~~t {1 ~ ~ Processing layer ~ _ ~ ~~eh~orking layer | TOP, Ethernet Operating system User layer Data storage and 1 retrieval lever J GKS PHIGS EDI, ODA DIF Hardware I 1 ~ 1 Processing Support sword Processing ~ Movement of Data ~ Filing/Archiving FIGURE 15 Office profile. New objectives Enterprise strategy Oblectives and Coals Strategic Business Planning Strategies for All Major Enterprise Functions 6__ . How to get there from here Technical strategic clan for future Strategy for Distributed Processing _ User interface strategy lo | Appl. strategy I ~ L Data met. strategy | Q O Network strategy Hardware strategy l Strategic Information Technology Plan Strat~lc plans for data structure definition Technology independent FIGURE 16 Strategic planning for computer-integrated manufacturing. 77 Information Engineering Strategies
78 implementation of an integrated system, it is essential that one select the right infra- structure for all five user profiles. CONCLUSION ULRICH FLATAU fered as one example of a strategic plan for CIM that incorporates all of these various attributes. Many people believe that integration can RE":RENCES be achieved by simply developing a net- working strategy. Others believe that a uni- fied user interface brings integration. This paper suggests that it takes much more to achieve integration. Management must cle- velop a business strategy, and this business strategy must be supported by a technical strategy that includes production process strategies and strategies for distributed processing. Management must agree on strategies for hardware operating systems, user interfaces, application data manage- ment, and networking for all five different user profiles. Therefore, management must take the lead in developing a strategic infor- mation technology plan. Figure 16 is of- Chestnut, H. 1967. Systems Engineering Methods. New York: Wiley. Digital Equipment Corporation. 1986. CIM-Archi- tecture Version 1.1. Marlborough, Mass. Hall, R. M. 1987. Attaining Manufacturing Excel- lence. Homewood, Ill.: Dow Jones-Irwin. Hayes, R. H., and S. C. Wheelwright. 1984. Restor- ing Our Competitive Edge: Competing Through Manufacturing. New York: Wiley. International Standards Organization. 1982. ISO/TC 97: Information Processing Systems. Draft Inter- national Standard ISO/DIS 7498. Synnott, W. R. 1987. The Information Weapon: Winning Customers and Markets with Technology. New York: Wiley. White, J. A. 1988. Material handling in integrated manufacturing systems. In Design and Analysis of Integrated Manufacturing Systems, W. Dale Comp- ton, ed. Washington, D.C.: National Academy Press.
