0026-雙柱機(jī)械式汽車(chē)舉升機(jī),機(jī)械式,汽車(chē),舉升機(jī) 附錄2——外語(yǔ)翻譯（原文） Computer aided process planning for sheet metal based on information management D. Lutters*, E. ten Brinke, A.H. Streppel, H.J.J. Kals Laboratory of Production and Design Engineering, University of Twente, PO Box 217, 7500 AE Enschede, Netherlands Abstract During the last few years, attention in the manufacturing cycle has shifted towards concurrent engineering (CE). With this, the integration of the different product life cycle processes has become a focus in both research and industry. However, it is obvious that the integration of all manufacturing processes, taking into account all life cycle aspects from initial functional requirements to final disposal, is hardly feasible in the traditional way. In this paper, the execution of the manufacturing cycle based on information management is explained by describing the development of a generic architecture for computer aided process planning. This architecture is elaborated upon for the field of sheet metal manufacturing in a small batch part environment. ＠2000 Elsevier Science S.A. All rights reserved. Keywords: Concurrent engineering; CAPP; Architecture 1. Introduction In the research presented here, it is advocated that the sheer integration of manufacturing processes within the product life cycle is insuf?cient to achieve true integrated product development. For this purpose, the main focus should be on the information that is applied and generated in these manufacturing processes. If the information of the separate processes can be made available during the entire development cycle, it can be the basis for the control of the entire manufacturing cycle. In order to take full advantage of the modi?ed role of information in the product development cycle, a different attitude with respect to the manufacturing processes is required. One of the main differences is, that the phases in the manufacturing process become instrumental to the information required in the manufacturing process. This immediately implies that processes in the manufacturing cycle haveto be defined as generic as much as possible. For example, it becomes practicable to interchange systems developed for different product types (prismatic, sheet metal, etc.). Moreover,if the interfaces of the mutual systems can be defined adequately, these systems can become independent modules,that are able to perform their tasks without being dependent on a predefined, sequential scenario. A ?rst prerequisite for this is the ability to effectively manage the information that becomes the basis of the manufacturing process. 2. Information management 2.1. Manufacturing engineering reference model In order to be able to deal with different views on a manufacturing system, the system is introduced by means of a reference model. A reference model represents a system as an organisation in terms of its structure of relatively independent,interacting components, and in terms of the globally defined tasks of these components [2]. The manufacturing engineering reference model proposed in the present context is shown in Fig. 1. This manufacturing engineering reference model is based on the manufacturing planning & control reference model introduced by Arentsen [1]. However, adaptations have been made, in order to emphasize the equivalent importance of products, orders and resources in the entire manufacturing cycle [4]. Company management is concerned with the control of customer orders. It is responsible for the strategic decisions concerning the range of products which will be produced and the processes and resources which are required to this end. Product engineering refers to all the engineering activities related to the product life cycle of a specific type of product.It is concerned with the design and development of a product type and its variants, starting from functional requirementsup to final recycling/disposal. Order engineering addresses those activities that relate a customer order to a specific (variant of a) product. It is the task of order engineering to compose production orders and to decide when given batches of products must be processed and with which resources. The objective of order engineering is the in-time execution of the production orders. Resource engineering refers to all (life cycle) aspects of the resources, required for the execution of the production activities. It therefore includes the specification, design,development, acquisition, preparation, use and maintenance of the resources of a company. Production is concerned with the actual execution of the plans generated by the engineering tasks. From production,information is fed back to these engineering tasks. In the manufacturing engineering reference model, information management is discerned as the kernel. This illustrates the opinion that the availability and accessibility of information is preferred over sheer data exchange. 2.2. Information management In recognising the fact that each of the departments in a company makes myriad decisions in order to generate required information, it is obvious that the reasoning behind all these decisions can hardly be transferred together with the information. Consequently, the need for feedback and interdepartmental communication increases, which may lead to extremely complex and uncontrollable flows of information between the separate departments. However, providing that information generated by the separate departments is attached to an overall and widely accessible model, this situation may change considerably. In this case, instead of `pushing' information from one department to another, departments can `pull' the information they require and are given access to. Hence, the focus can be on the information in support of the control of the manufacturing processes, and for this reason, the course of the manufacturing processes may be guided by the use of, and the need for information. The types of objects the information is concerned with(orders, products, operators, etc.) can vary considerably.Despite this variation, for the way the information is structured and attached to an overall model, it is unimportant whether information bears reference to, e.g. a product, a machine or its operator. Still, it is important to distinguish between different types of objects, as their different significance for the manufacturing processes is apparent. Each type of object can be attached to an overall model, a so-called information structure. In accordance with the three piles of the reference model, three of these information structures are discerned (see Fig. 2): ● product information structure; ● order information structure; ● resource information structure. Because the structures evolve independently of each other, whereas the way of their mutual interactions remains the same, the entire range of manufacturing environments can be addressed: from engineer-to-order to mass production.For example, in an engineer-to-order environment, the order information structure and the product information structure evolve almost simultaneously and the resource information structure remains relatively unchanged. In a mass production environment, the product information structure and the resource information structure are developed concurrently and remain rather static henceforth.Subsequently, the order information structure is used to specify the choice of a certain product variant, and to determine the lead time and other logistic consequences. The different behaviour of the information structures in different manufacturing environments implies that each of the structures has its own life cycle. In aiming for the integration of processes, the life cycles must be oriented on the information contained in the information structures, instead of on the processes concerned with this information.In elaborating this concept for the product information structure, the product life cycle is oriented upon the product instead of on the manufacturing processes.In this way, information management as part of the reference model, consists of an integrated collection of tasks that can be used as a basis to initiate, accompany, control and evaluate all the manufacturing processes in a structured and transparent way. These tasks are based on the information contained in the three information structures, as is shown in Fig. 2. It may be obvious that if the engineering tasks are based on information from one of the information structures, they can always be based on up-to-date information, not only from the structure they are directly related to, but from the other structures as well. Especially when applying the concurrent engineering principles, the simultaneous development of products and the related processes can be realised much easier. 3. An architecture for information management Based on a reference model, an architecture can be developed. An architecture is a specification of the functions of a system and the interactions between these functions in terms of input and output, as observed by the user. The architecture can be applied as the basis for the implementation and realisation of the intended functionality of the system. It is important to distinguish the different types of architectures that are required to establish the functionality represented in the reference model. On the one hand,architectures are to be developed for the engineering processes,e.g. for a design system or a process planning system.On the other hand, an architecture for information management plays a different, yet significant role. As information management is the kernel of the reference model proposed in Section 2.1, it is conducive to develop an architecture that in itself can constitute the footing for architectures outlining the engineering processes. Therefore,the main role of this architecture is to accommodate all functionality concerned with information processing to the architectures built upon it. Additionally, because information management is concerned with all information processing,it can also offer the possibility to initiate, accompany,control and evaluate development cycles by actuating the engineering processes. Moreover, even the entire manufacturing history can be captured. With this in mind, it is important to notice that no distinction is made between different types of information.The architecture has to deal with information concerningproducts as well as resources and orders. The architecture for information management is shown in Fig. 3. Before discussing the function blocks in the architecture,the contiguous parts are reviewed. First of all, the role of the user might easily be misconstrued; the above-mentioned task of the architecture implies that it is the basis for other systems. Consequently, what is called the `user' here, can only be a system based on this architecture. Even if aDhumanDuser wishes to access the information about, e.g. a product, it has to be done via a system that is built on top of information management. All users access information management through an interface. For systems that are designed according to the principles outlined in the above, this interface hardly influencesthe flow of information. For other systems, e.g.commercially available CAD or CAM systems, the interface accommodates the two-way exchange of information between the user and information management. The complexity of the interface can vary considerably, depending on the level of aggregation that has to be provided. The controller translates the exchanged information into actions. These actions can initiate, e.g. search, storage or retrieval procedures in information management, but they might also initiate actions of other users (e.g. a specific request for information, or the notification of a change that might influence actions of other users). It is important to recognise that information management in itself does not store information in a central database. It merely ‘redirects’information to and from databases owned by different users. For this purpose, a database interface is required. This interface provides low level access to different types of databases. The main function blocks of the architecture can therefore rely upon the database interface for the unformatted transfer of information. As mentioned before, the actual data is not stored in information management,but in several different types of databases owned by different users. As an example, a process planning department and a design department will have different databases.Information management virtually integrates these databases. In order to know which databases are involved in a certain project (concerning either products, resources or orders),meta-information is required. This meta-information is stored in one metabase per project. Such a metabase contains,e.g. the following information: ●specification of databases and database tables; ● specification of users and their access rights; ● specification of the information structure (including domains and views [5]); ●specification of the project ontology. Especially the use of an ontology (e.g. [3]) is very important. It offers the possibility of dynamically maintaining the meta-information of a project, without the need to predefine the type of information involved in the project. 3.1. Function blocks in the architecture Information exchange. The main function block in the architecture is information exchange. The task of this module is the translation of incoming user requests for information into actions that can be performed by the other modules. Information ontology. In order to be able to process any information request, it is essential to understand its contents.For this purpose, an ontological specification of the information is used. This is also required for –literally-translating a request into actions. Information structure. All information accessible via information management is structured, in order to allow for consequent settlement of information flows. The structure is established and maintained by this function block.More information on information structuring can be found in [5]. User access manager. Not every user has access to all types of information. For example, a process planner may be allowed to read design information, but he is not probably entitled to change it. This function block is therefore required to validate all user requests. User manager. As mentioned above, different users have different rights. Consequently, this function block acts as an account manager, specifying user access rights to (parts of)the structure, database tables and user groups. Life cycle conduct. This function block is concerned with the ontology of the manufacturing process. It specifies the required types of information and their mutual dependencies.Moreover, it is used to navigate the manufacturing process based on the information content. The need for information can be determined by comparing the current ontology of a product with the ontology describing the entire product life cycle. As a simple example,it is obvious that if production of a certain component is not outsourced, e.g. process planning information and production information have to become available. This, and the sequence in which it has to be generated can be deduced by life cycle conduct. Configuration and version manager. Many companies experience problems with version control, configuration management, etc. The apparent solution is to base PDM,ERP, etc. on the information content instead of on the processes. This additionally offers the possibility to maintain the manufacturing history. Another function of this block is the control of information integrity and transparency. 4. An architecture for process planning for sheet metal As mentioned before, the architecture for information management is meant to constitute the basis for other architectures. Therefore, an architecture for, e.g. a process planning system does not need to worry about data storage,etc. because this can be commissioned to information management effortlessly. Consequently, the architectures for engineering processes can be focused on their actual tasks. In this section, an architecture for process planning will be presented. Hitherto, these architectures were often designed for one specific product type (e.g. prismatic or sheet metal),which was reasonable, because most of the time, products were designed while implicitly presuming certain production processes. For the future we foresee a method of approach, where (in the utmost case) merely the functional faces of a design are specified, and knowledge of different candidate production processes can be applied to further specify the product geometry. This implies that process planning knowledge (and therefore its functionality) has to be available in a consistent way, based on a generic archetype. From this, it is clear that the strict borders that nowadays exist between, e.g. design and process planning are to be removed. This is merely possible if the manufacturing processes are dedicated to the product information instead of the other way around (see Section 3). Because the strict distinction between design and process planning disappears, consequently, it is difficult to circumscribe an architecture for any engineering process. Until now, this delineation has been made artificially, by defining distinct stages in the manufacturing process by means of scenarios. However, based on information management the possibility arises to deal with the engineering processes in a more flexible way. Obviously, we have to find a way of categorising engineering functionality that does justice to this flexibility. An example may help demystifying this reasoning. Until now, a design was finished, and transferred to the process planning department. When this department had finished its tasks, other departments had to carry on. In the desired situation, outlined in the above, a designer can exploit process planning knowledge and functionality the moment it is required. This implies that there is no need to make a process plan for an entire product in one go, but process planning information can be attached to, e.g. one feature as well. Even cost estimations or production planning information can be taken into account during the design phase or any other phase of the manufacturing process [8].This allows the designer to make well-founded decisions. Obviously, this has a considerable influence on the architectures that can be applied for process planning. As mentioned before, the template for the architecture must be independent of the type of production processes regarded.Moreover, while the function blocks in the architectures contain process type specific tasks, their mutual interaction should be generic. In the following, this template is presented and it is elaborated upon for the sheet metal type of product shown in Fig. 4 The architecture is shown in Fig. 5. It is partly based onthe PART-S architecture [7]. An important differencewith existing architectures is the fact that the input of a system based on this architecture is not prespecified. The input can be a product model, but might also be (a group of) features or faces. As mentioned before, the architecture is based on information management, which -strictly speaking- is therefore not a part of the CAPP architecture. The controller is dedicated to coordinating the functions provided in the architecture, and assuring consistent information flows with information management. The user can influence the behaviour of the system by means of the user interface. This interface has to provide more than just a view port on the activity in the system. The user must be able to pose directed questions, in order to engender specific operations. The other