0026-雙柱機(jī)械式汽車舉升機(jī)
0026-雙柱機(jī)械式汽車舉升機(jī),機(jī)械式,汽車,舉升機(jī)
旋風(fēng)分離器對(duì)稱蝸管進(jìn)口的實(shí)驗(yàn)室研發(fā)
Bingtao Zhao, Henggen Shen, Yanming Kang
翻譯：于亮亮
摘要：設(shè)計(jì)三種具有不同幾何形狀進(jìn)口的旋風(fēng)分離器,一種是傳統(tǒng)的單一切向進(jìn)口(CTSI),一種是對(duì)稱的直蝸管進(jìn)口(DSSI),還有一種是對(duì)稱的收斂蝸管進(jìn)口(CSSI)。進(jìn)口類型對(duì)旋風(fēng)分離器工作特性的效果,包括收集效率和壓降,本文研究并比較其與粒子大小和流速的關(guān)系。實(shí)驗(yàn)結(jié)果表明對(duì)稱的蝸管進(jìn)口(SSI),尤其是CSSI形狀進(jìn)口,隨著新增的可忽略壓降的條件下越來越多的對(duì)收集效率有重要的影響。另外,收集效率和壓降的研究結(jié)果也包括試驗(yàn)數(shù)據(jù)和理論模型之間的比較。
關(guān)鍵字:旋風(fēng)分離器;對(duì)稱的蝸管進(jìn)口;收集效率;壓降。
⒈介紹：
旋風(fēng)分離器廣泛應(yīng)用于空氣污染控制領(lǐng)域，為含懸浮微粒氣體進(jìn)行氣–固分離等工業(yè)應(yīng)用[1］。由于其制造簡(jiǎn)單,操作成本低,和對(duì)極端的苛刻條件的適應(yīng)性好,因此無論是應(yīng)用在工程上還是操作過程上旋風(fēng)分離器成為最主要的除塵裝置之一。然而,越來越多的提倡環(huán)境保護(hù)，氣–固分離都強(qiáng)調(diào)應(yīng)該分離出最大量的微塵粒子。為達(dá)到這個(gè)要求,旋風(fēng)分離器幾何學(xué)和性能的改善要比替換可更換件來得重要。許多專家認(rèn)為擴(kuò)大旋風(fēng)室是提高旋風(fēng)分離器性能的主要因素,通過引進(jìn)新設(shè)計(jì)的進(jìn)口與操作變量。這包括對(duì)一臺(tái)分離試樣的旋風(fēng)分離器的裝有多個(gè)進(jìn)口葉片的分餾器的測(cè)試并結(jié)合其他的研究[2］,德奧特建立一個(gè)數(shù)學(xué)模型來預(yù)算小型圓柱多諧振蕩器旋風(fēng)分離器的收集效率[3］,穆爾和麥克法倫以萊普勒的典型幾何學(xué)為基準(zhǔn)測(cè)試一個(gè)有多個(gè)進(jìn)口的旋風(fēng)分離器[4］,高塔姆和斯蒂納斯設(shè)計(jì)和測(cè)試一個(gè)可換氣的多進(jìn)口旋風(fēng)分離器取樣器的最小方向偏差[5］,通過分離后的清潔空氣來比較一個(gè)雙進(jìn)口旋風(fēng)分離器的性能[6］。在本文中,介紹了一些形狀研究員設(shè)計(jì)的不同形狀進(jìn)口的新式進(jìn)口,和它們對(duì)旋風(fēng)分離器的性能效果的實(shí)驗(yàn)性研究。
⒉試驗(yàn)性的研究
三種具有不同幾何形狀進(jìn)口的旋風(fēng)分離器,包括傳統(tǒng)的單一切向進(jìn)口(CTSI),對(duì)稱的直蝸管進(jìn)口(DSSI),和對(duì)稱的收斂蝸管進(jìn)口(CSSI),已經(jīng)研制出了。它們的幾何形狀和尺寸見Fig1和Table⒈為了測(cè)試不同的進(jìn)口類型所帶來的效果,其它的尺寸設(shè)計(jì)完全相同,僅進(jìn)口的幾何形狀不同。
Fig.1 旋風(fēng)分離器形狀示意圖：(a) Model A 傳統(tǒng)的單一切向進(jìn)口 (b) Model B 對(duì)稱的收斂蝸管進(jìn)口 (c) Model C 對(duì)稱的收斂蝸管進(jìn)口。.
Table 1：旋風(fēng)分離器尺寸統(tǒng)計(jì)：（單位mm）
Fig.2：試驗(yàn)結(jié)構(gòu)系統(tǒng)示意圖
圖⒉所示為實(shí)驗(yàn)系統(tǒng)機(jī)構(gòu)。 壓降是由接在旋風(fēng)分離器進(jìn)口和出口管的兩壓力計(jì)測(cè)量的。通過一數(shù)字微壓計(jì)(SINAP ,壓差1000-IIIC )讀得。收集效率是通過微顆粒大小分析器(SPSI,LKY -2)所得粒度分布計(jì)算的。由于Model B,C具有一樣對(duì)稱的進(jìn)口,所以組合式旋風(fēng)分離器各進(jìn)口的流速是相等的。并且流速可由閥來控制;運(yùn)行條件也相同,將濃度為5.0g/m3的粒子用雙噴管螺旋給料機(jī)喂到進(jìn)口管中。固體顆粒為滑石粉核心密度的2700kg/m3,按原標(biāo)準(zhǔn)尺寸分配,平均直徑的5.97Am,幾何偏差為2.08。在這次測(cè)試過程中平均大氣壓,環(huán)境溫度,和相對(duì)濕度分別是99.93kPa,293K,75%。
⒊結(jié)果和討論
3.1 收集效率
圖3顯示所測(cè)量的旋風(fēng)分離器總效率與流速或者進(jìn)口速度的關(guān)系。正如預(yù)料的那樣收集效率隨進(jìn)口速度的增加而增加。然而,Model B Model C兩旋風(fēng)分離器有著對(duì)稱的蝸管進(jìn)口,在同一進(jìn)口速度下,兩者的總效率永遠(yuǎn)要高于傳統(tǒng)的單一切向進(jìn)口旋風(fēng)分離器(Model A)，特別是有CSSI的旋風(fēng)分離器(Model C)的總效率最高。在測(cè)試給定的相同速度條件下,通過改善進(jìn)口幾何形狀所帶來的旋風(fēng)分離器總效率的增加率分別為0.15–1.15%和0.40–2.40%。
圖4(a)–(d) 比較不同進(jìn)口類型的旋風(fēng)分離器的分級(jí)收集效率。在進(jìn)口速度分別為11.99,16.04,20.18,和23.85m/s時(shí)的流速分別為388.34,519.80,653.67,和772.62 m3/h。可見,旋風(fēng)分離器的摩擦效率隨粒子大小的增加而增加。所有旋風(fēng)分離器的分級(jí)收集效率曲線都呈S形。DSSI(Model b)和CSSI(Model c)旋風(fēng)分離器的摩擦效率分別比CTSI旋風(fēng)分離器(Model a)大2–10%,5–20%。這表明進(jìn)口的幾何形狀對(duì)旋風(fēng)分離器的收集效率有著重要的影響。進(jìn)入有對(duì)稱的蝸管進(jìn)口的旋風(fēng)分離器(Model B和C)的粒子容易聚集在旋風(fēng)分離器壁上,因?yàn)榱Ｗ又荒芤苿?dòng)很短的位移,尤其CSSI(Model C)改變了粒子分布濃度并使粒子在進(jìn)入旋風(fēng)分離器的筒體前就從氣體中分離了出來.圖5根據(jù)傳統(tǒng)的理論[7–11］比較了流速為653.67m3/h(進(jìn)口速度為20.18m/s)時(shí)的試驗(yàn)數(shù)據(jù)。很明顯,以Mothes /Loffler模型Iozia/ Leith 理論得出的效率曲線比其它的學(xué)說所得的曲線更符合試驗(yàn)結(jié)果。這些結(jié)果與研究進(jìn)行經(jīng)過Dirgo、Leith 和Xiang 等人的研究結(jié)果相吻合。
Fig.3 不同進(jìn)口速度下旋風(fēng)分離器的總效率
比較表明有些模型可以推斷一個(gè)還沒有公開的理論結(jié)果。但是現(xiàn)有的試驗(yàn)數(shù)據(jù)理論還不足以推斷出流態(tài)和粒子濃度分布的變化是對(duì)稱的蝸管進(jìn)口對(duì)旋風(fēng)分離器性能產(chǎn)生的效果。為了更清楚地驗(yàn)證對(duì)稱的蝸管進(jìn)口對(duì)旋風(fēng)分離器性能的作用效果,再看圖6,表示隨著流速或進(jìn)口速度的變化引起的各個(gè)模型的50%切截尺寸。在相同進(jìn)口速度下model c和model b的50%切截尺寸比model a要低。與進(jìn)口速度的減少一樣,50%切截尺寸也是近似呈線性減少的。例如，當(dāng)進(jìn)口速度為20.18m/s時(shí),50%切截尺寸的減少率由model b的9.88%和model c的24.62%決定。這表明新型進(jìn)口可以促進(jìn)旋風(fēng)分離器的收集效率。
3.2.壓降
旋風(fēng)分離器得壓差數(shù)值通常表示為一定數(shù)量的氣體入口速度壓頭高度差，用壓差數(shù)值系數(shù)表示，壓差數(shù)值系數(shù)是進(jìn)口動(dòng)壓壓差數(shù)值的分度。表2列出了在不同的入口速度時(shí)這三個(gè)旋風(fēng)分離器的壓差數(shù)值系數(shù)值。
顯然,旋風(fēng)分離器的壓降高低與流速高低有關(guān)。然而,一定流速或者入口速度下,A、B和C模式的壓力降系數(shù)有所不同，在5.21和5.76之間變化，其平均值為5.63。例如模式B在5.22–5.76之間變化，平均值為5.67；模式C在5.16–5.70之間變化平均值為5.55；模式A根據(jù)回歸分析計(jì)算。這是一個(gè)重點(diǎn)，因?yàn)橛纱擞锌赡茉跊]有有效的壓差值增加的情況下提高氣旋收集效率。
表3列出了壓降的試驗(yàn)數(shù)據(jù)與電流理論的比較結(jié)果。結(jié)果顯示Alexander和Barth模式與試驗(yàn)數(shù)據(jù)最符合,盡管Shepherd ，Lapple 和Dirgo 氣旋模式推算也很出色。
Fig.4 不同進(jìn)口速度時(shí)的選粉效率等級(jí)：(a)進(jìn)口速度為11.99 m/s (b)進(jìn)口速度為16.04 m/s (c) 進(jìn)口速度為20.18 m/s (d) 進(jìn)口速度為23.85 m/s.
Fig.5 試驗(yàn)所得效率等級(jí)與理論的比較 Fig.6 旋風(fēng)分離器的50%切截尺寸
Table 2 ：旋風(fēng)分離器的壓力損失系數(shù)：
Table 3 ：與理論壓力損失系數(shù)比較：
4、結(jié)論
人們發(fā)明了一種具有對(duì)稱的蝸管進(jìn)口(SSI)，DSSI和CSSI的新型旋風(fēng)分離器,并且測(cè)試和比較了這種進(jìn)口類型的旋風(fēng)分離器的性能。實(shí)驗(yàn)結(jié)果顯示這種DSSI旋風(fēng)分離器和CSSI旋風(fēng)分離器的總效率分別比CTSI旋風(fēng)分離器高出0.15–1.15%和0.40–2.40%。此外,DSSI旋風(fēng)分離器、CSSI旋風(fēng)分離器和CTSI旋風(fēng)分離器的壓力損失系數(shù)分別是5.63、5.67和5.55。盡管這些并聯(lián)進(jìn)口增加了旋風(fēng)分離器的復(fù)雜程度并加大了其成本,然而具有SSI尤其是CSSI的旋風(fēng)分離器具有更好的收集效率,而且顯著的減少了壓力損失。這篇文章介紹了借助于改進(jìn)進(jìn)氣道幾何形狀設(shè)計(jì)而改善旋風(fēng)分離器性能的可能性。
參考資料：
[1] Y.F. Zhu, K.W. Lee, Experimental study on small cyclones operating at high flow rates, Aerosol Sci. Technol. 30 (10) (1999) 1303– 1315.
[2] J.B. Wedding, M.A.Weigand, T.A. Carney, A 10 Am cut point inlet for the dichotomous sampl Environ.Sci.Technol. 16 (1982) 602– 606.
[3] R.E. DeOtte, A model for the prediction of the collection efficiency characteristics of a small, cylindrical aerosol sampling cyclone, Aerosol Sci. Technol. 12 (1990) 1055– 1066.
[4] M.E. Moore, A.R. Mcfarland, Design methodology for multiple inlet cyclones, Environ. Sci. Technol. 30 (1996) 271–276.
[5] M. Gautam, A. Streenath, Performance of a respirable multi-inlet cyclone sampler, J. Aerosol Sci. 28 (7) (1997) 1265– 1281.
[6] K.S. Lim, S.B. Kwon, K.W. Lee, Characteristics of the collection efficiency for a double inlet cyclone with clean air, J. Aerosol Sci. 34 (2003) 1085–1095.
[7] D. Leith, W. Licht, The collection efficiency of cyclone type particle collectors: a new theoretical approach, AIChE Symp. Ser. 68 (126) (1972) 196– 206.
[8] P.W. Dietz, Collection efficiency of cyclone separators, AIChE J. 27(6) (1981) 888– 892.
[9] H. Mothes, F. Loffler, Prediction of particle removal in cyclone separators, Int. Chem. Eng. 28 (2) (1988) 231– 240.
[10] D.L. Iozia, D. Leith, The logistic function and cyclone fractional efficiency, Aerosol Sci. Technol. 12 (1990) 598– 606.
[11] R. Clift, M. Ghadiri, A.C. Hoffman, A critique of two models for cyclone performance, AI ChE J. 37 (1991) 285–289.
[12] J. Dirgo, D. Leith, Cyclone collection efficiency: comparison of experimental results with theoretical predictions, Aerosol Sci. Technol. 4 (1985) 401–415.
[13] R.B. Xiang, S.H. Park, K.W. Lee, Effects of dimension on cyclone performance, J. Aerosol Sci. 32 (2001) 549– 561.
[14] C.B. Shepherd, C.E. Lapple, Flow pattern and pressure drop in cyclone dust collectors: cyclone without inlet vane, Ind. Eng. Chem. 32 (1940) 1246–1256.
[15] R.M. Alexander, Fundamentals of cyclone design and operation, Proc. Aust. Inst. Min. Met. (New Series) (1949) 152– 153, 202– 228.
[16] M.W. First, Cyclone dust collector design, Am. Soc. Mech. Eng. 49(A) (1949) 127–132.
[17] C.J. Stairmand, Design and performance of cyclone separators, Trans .Inst. Chem. Eng. 29 (1951) 356–383.
[18] W. Barth, Design and layout of the cyclone separator on the basis of new investigations, Brennst. Wa¨rme Kraft 8 (1956) 1 – 9.
[19] J. Casal, J.M. Martinez-Bennet, A batter way to calculate cyclone pressure drop, Chem. Eng. 90 (3) (1983) 99– 100.
[20] J. Dirgo, Relationship between cyclone dimensions and performance, Doctoral Thesis, Harvard University, USA, 1988.
5
附錄2——外語翻譯（原文）
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
收藏