淺析客車制造企業PDM應用系統的開發_第1頁
淺析客車制造企業PDM應用系統的開發_第2頁
淺析客車制造企業PDM應用系統的開發_第3頁
淺析客車制造企業PDM應用系統的開發_第4頁
已閱讀5頁,還剩10頁未讀 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1、HYPERLINK N:整理后.N:整理后.HYPERLINK N:整理后.N:整理后.更多企業學院:./Shop/中小企業治理全能版183套講座+89700份資料./Shop/40.shtml總經理、高層治理49套講座+16388份資料./Shop/38.shtml中層治理學院46套講座+6020份資料./Shop/39.shtml國學智慧、易經46套講座./Shop/41.shtml人力資源學院56套講座+27123份資料./Shop/44.shtml各時期職員培訓學院77套講座+ 324份資料./Shop/49.shtml職員治理企業學院67套講座+ 8720份資料./Shop/42.s

2、html工廠生產治理學院52套講座+ 13920份資料./Shop/43.shtml財務治理學院53套講座+ 17945份資料./Shop/45.shtml銷售經理學院56套講座+ 14350份資料./Shop/46.shtml銷售人員培訓學院72套講座+ 4879份資料./Shop/47.shtml客車制造企業PDM應用系統的開發1. 引言 在客車制造企業的產品開發中,許多企業利用cad/cae/cam/capp等技術成功實現了整車的數字化定義、整車結構的模擬和優化分析,極大地提高了客車的設計質量和設計速度。然而在開發過程中設計部門和工藝部門也逐漸積存起了數量龐大的、以電子形式存在的圖紙和文

3、檔。這些圖紙和文檔的共享程度低、數據傳遞速度慢、業務數據難以集成、數據的治理水平落后,這直接導致了研發中一些失誤,制約了企業進一步縮短產品的研發周期。為了解決那個問題,該企業決定采納PDM來對產品信息進行有效的組織和治理,通過PDM的實施來構造一個企業信息共享的環境。 PDM以產品為中心,通過計算機網絡和數據庫技術,把企業設計過程和生產過程中所有與產品相關的信息和過程集成起來統一治理,使產品數據在其生命周期內保持一致、最新和安全,為工程技術人員提供一個協同工作的環境。目前,PDM已成為企業降低成本、縮短產品的設計與制造周期、準確的捕捉市場、提升客戶的中意度的重要工具,成為提升企業競爭力的重要手

4、段。 . 要緊問題的分析與解決 PDM系統的開發和實施是一個特不復雜的系統過程。必須要考慮到被實施企業的實際特點,結合該企業的產品特點、經營模式和現有的、可實施的計算機技術,從PDM的差不多思想入手,建立企業PDM系統的差不多框架,然后在此基礎上分時期的實施具體工作。 2.1. 對客車產品和其開發流程的特點進行分析 相關于其它產品,客車產品以下特點: 1. 客車產品特點 1) 客車產品零部件種類多,數量多;集成化、模塊化程度更高,例如作為一般汽車制造企業所專門生產的發動機系統、燃油供給系統、制動系統、變速操縱系統等被整合成一個底盤系統,作為了整車中的一個組件。 2) 客車產品種類多,內部結構變

5、化多,同樣一種大類的客車(主參數為車輛的長度),依照用戶的需要會衍生出一般型、豪華型、都市客車等系列車型,相應的動力系統、內部飾件和空調系統等也會有變化。 3) 大部分客車產品的生產綱領屬于小批量生產,還有部分產品是按照用戶需求單臺設計生產。但同時它又是一種系列化的產品,能夠充分利用原有的產品數據,減少新開發的工作量 4) 客車產品的技術更新快,對新技術的應用要求高,同時作為一種和人民生命安全有緊密聯系的產品,國家對客車產品的安全性、環保性也有嚴格的規定。如國家就強制要求總質量超過12噸的客車必須安裝abs系統。 2 客車產品開發流程的特點 1) 層次性強,層次間數據交流量大 客車產品從概念設

6、計、外形工業設計、總體布置、零部件設計、工藝設計等層次分明。上一層的設計必須兼顧考慮下一層,而但下一層設計完成時又需要返回上一層去檢查工藝性以及匹配性。 2) 繼承性強 目前的情況下,在一個新的客車產品中,超過90的零件和工藝技術是通過繼承和汲取以往的技術資料得到的,真正的完全的創新不到10。在同種型號的客車車型之間零部件的借用特不普遍, 3) 涉及學科眾多 客車設計涉及汽車、機械、電氣、液壓和氣動、動力、人機工程等,所產生的與產品相關的文檔類型也專門多。 4) 客車產品更新快,用戶的需求多樣化,產品開發的周期短。 3 客車產品文檔類型 1) 文本文件:描述產品性能的、以文字描述為主的文件。如

7、設計任務書、產品講明書等。 2) 數據文件:描述產品的以數據為主的文件。如三坐標測量報告、有限元分析文件、nc加工代碼文件等。 3) 圖形文件:描述產品及其零部件的二維、三維圖等由cad繪圖軟件生成的文件。 4) 表格文件:描述具有類似屬性的零部件和結構關系。如材料明細表(bom)。 5) 多媒體文件:為了某種專門用途,為了方便用戶生成的聲音文件、視頻效果圖等。 2.2 確定企業的產品開發方式和流程 不同的企業其產品開發的方式和流程是不同的,同一個企業對不同的產品其也有不同的產品開發方式和流程。清晰地了解企業產品設計開發方式和流程是十分重要的。目前在客車行業要緊有以下幾種開發方式:能夠看到,不

8、同的產品開發流程造成的數據庫的結構和數據庫的容量是不同的,在第一種設計方式中,參與的人員和這些人員相應的角色都比較簡單,PDM中的產品文檔類型也相應較簡單,而第三中設計方式就要多的多了,在數據庫開發之前,開發人員必須清晰地明白被實施企業產品設計開發方式和流程,才能保證數據庫的設計符合企業的需求。因此必須在PDM的項目規劃時期進行這方面的調研工作。圖1 被實施企業客車產品開發的流程3. 系統功能需求分析及需求分析模型建立需求分析是PDM規劃實施中特不重要的時期。需求分析的好壞直接阻礙系統今后運行的成敗。PDM系統在企業中的實施目標可分為大小兩種: 大目標:將PDM作為集成平臺或集成框架,在cim

9、s、并行工程等復雜大系統中,對產品設計、工藝、制造、打算、銷售、維護等環節的相關數據與產品開發全生命周期進行治理。 小目標:僅指在產品的工程設計與工藝設計中治理相關的數據及相關的過程。 通過調研和與企業相關人員的協商,該企業希望在客車產品的開發過程中治理相關的設計、工藝等數據,能方便實行零部件間的借用、查詢,能對正在進行的工程項目進行治理。其PDM系統實施目標為小目標。需求模型如下: 1. 客車產品編碼 原有的編碼體系差不多不適應于產品日益增多的需要。因此在以gb/t17350-1998專用汽車和專用半掛車術語和代號的基礎上建立新的一套能涵蓋所有產品范圍的,便于計算機查詢的客車產品編碼體系 2

10、. 零件總庫的治理 按照客車車型數據庫編碼屬性和組件、零件數據庫的零件號屬性之間的函數依靠關系,實現組件、零件之間的數據重用。使用戶能方便地查找到與組件、零件有關的圖紙、技術文檔和產品數據等。 3. 圖文檔治理 建立一套圖紙、文檔的歸檔、存放和查詢系統,使用戶能夠快速、方便地查找到所需的圖紙和文檔,能快速掃瞄圖紙和文檔。 4. 工作流程治理和項目治理 依照該企業客車研究所內部的工作流程治理的模型,建立工作流程治理。要緊在審批治理和更改治理兩個方面,通過計算機提交一項作業或任務給研究所的相關人員,進一步開發、編輯、審核或批準工作,對流程進行操縱。 5. 產品配置治理 以產品結構樹的方式反映客車車

11、型、組件、零件之間的層次關系。在結構樹的基礎上查詢這些零部件的其它屬性,如材料、重量、供應商等信息。使描述組件和零件的文件信息與樹結點上相關零件有機地連接起來,實現不同車型的產品數據治理。 6. 用戶權限治理 關于各職能部門而言,不同的級不和部門的人員對PDM系統應具有不同的使用權限,以保證數據信息的安全和保密。依照各職能部門的組織結構圖和人員職能分布表, 4. 系統數據庫的規劃和設計 4.1. 系統數據庫的特點 1. 信息量大 一個客車產品包含幾千個差不多零件和部件每個部件又能夠由許多差不多零件組成。產品信息能夠是結構化的數值信息,也能夠使非結構化信息,包含眾多的屬性、材料、特征信息,包含大

12、量的數學模型和圖紙信息。 2. 數據結構復雜 在本系統中,一份工程圖至少由一條工程圖差不多記錄(元數據)和一張圖紙組成,一個用來進行數據治理的業務對象至少要有一個標識號、一個更改標記(版本號)和一個處理狀態。圖號被作為標識號,圖號能夠是一個由編碼發生器生成的連續的數字編號,必要時增加前綴和后綴。版本號和處理狀態通常為字符和字符串。在工程圖差不多記錄中,版本號通常由某個初始值(如版本a)開始計數,每一次更改后該版本號加一(如版本b)。處理狀態被用來標識該對象在發放往常的各種處理狀態。因此數據庫的數據結構都比較復雜。 3. 數據類型多樣 在客車設計的進程中,設計信息隨著進程的進展不斷變化,設計數據

13、版本也要隨之更新和對往常版本進行保存。在客車產品中,一個零件可包括多個數據對象,如幾張圖紙、用光柵或矢量表示的圖形、文本描述、圖表和其它形式的文檔。數據對象圖紙則包括一條元數據記錄和由該元數據記錄治理的cad圖或紙質工程圖。零件差不多記錄是對零件進行治理的要緊對象,那些對所有數據對象都有效的屬性,如圖號或名稱等,被作為零件差不多記錄,在數據對象中,用戶不得隨意更改這些屬性(能夠采納凍結的方式),而數據對象的專用屬性,如頁號、圖幅或所采納的cad系統等,可由用戶自己輸入,圖紙、文檔等被存放在文件系統中,而不是在數據庫中 4.2. 系統數據庫的設計 4.2.1. 數據庫的設計步驟 在設計數據庫時,

14、一般按照收集信息、識不對象、對象建模、確定每個對象的信息類型、確定對象間的關系的步驟進行。 通過對客車產品特點的分析我們進行了信息的收集,在對這些收集信息的分析過程中,我們找出要緊的對象。這些我們在2.1對客車產品的特點進行分析中差不多闡述了。 在數據庫中要緊的對象被識不出來以后,就需要確定每個對象所包含的信息了。如對“底盤”對象,我們需要讓它包含型號、外形尺寸、發動機、變速箱、制動系、燃油系等信息。 通過分析對象間的關系,建立表示每個對象之間的不同關系。用對象之間的關系來建立數據庫中不同實體之間的關系模型(e-r模型)。如在制動系中要包含不同剎車種類的信息,abs剎車系統就要依照客車車型中包

15、含的信息來定,一旦客車車型的總質量大于12噸,那么底盤中的制動系必須采納abs剎車系統,這就確定了制動系和客車車型之間的一種約束關系。4.2.2詳細講明了這一模型的建立過程。 4.2.2. 實體關系模型的建立和規范化 e-r(實體-關系)模型的組件是廣泛和通用的,正確建立的e-r模型能夠客觀地反映其所在的業務環境,是數據庫構建的基礎。圖2為客車產品結構的e-r模型。在那個模型中,首先反映了客車車型、底盤、車身附件、選裝配置等實體之間的二元聯系。客車車型和底盤、車身內飾、選裝配置等實體之間是一對多的關系,即一種車型能夠裝有不同底盤和車身、內飾,能夠選裝不同的配置。在一個客車的產品結構中,一個客車

16、車型必須安裝有底盤、車身和內飾,但選裝配置則要依照顧客的需要來決定。因此在客車產品結構e-r模型中,通過放置的穿過聯系線的脈沖線表示在聯系中必須存在一個實體, 放置穿過聯系線的橢圓表示聯系中可能有一個實體,也可能沒有。在一些實體之間還存在約束關系,如車型要和底盤長度匹配,空調系統要和發動機功率匹配。圖2 客車產品的e-r模型(實體-關系)在關系模型建立起來之后,我們還要對那個模型進行規范化。規范化是把有問題的關系轉化為兩個或多個沒有這些問題的關系的過程。規范化可用作檢查關系合乎需要的程度和正確性的指南。 4.2.3. 數據庫的安全治理和操縱 本系統提供用戶名和口令級的安全。當一個用戶登錄時,依照其權限,訪問被限定在一定的窗體、報表、表甚至表的某些列上。 作為一個多用戶系統,操縱的關鍵部分是確定必須作為一單元完成的工作界限,即與事務有關的操縱類型。 5. 網絡模式:客戶機/服務器 網絡是PDM實現分布式處理的基礎。依照該企業的實際生產和辦公情況,采納中央數據庫,分散在企業的客車研究所和各個部門的計算機作為客戶機的客戶機服務器結構(clientserver)是最適合企業的分布式數據治理模式。與傳統資源共享模式相比,采納客戶機服務器模式的PDM系統有多個優點。 (1)網絡通信量小,響應時刻短,能為用

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

最新文檔

評論

0/150

提交評論