海 軍 裝 備 部 胡晉銘 拜 斌
飛機產品的研制過程中,不可避免地發(fā)生更改。尤其對于新設計的飛機產品,在形成完整的產品基線過程中,設計更改量相當巨大。如何合理高效地對飛機產品零部件的更改進行控制和追溯,對于理清飛機產品的技術狀態(tài),減少研制過程的人力、物力耗費,具有相當重要的意義[1-3]。而目前的零部件更改管理現(xiàn)狀并不理想,管理模式的發(fā)展沒有跟上設計模式的變更,甚至阻礙了先進設計模式的應用,因此開展零部件更改管理方法的探討十分必要。
零部件的更改,實際上是對零部件在設計、生產乃至使用維護的全壽命周期中所形成的產品數(shù)據(jù)的更改。在以往的概念中,提到產品數(shù)據(jù),馬上會想到零部件的二維圖樣、三維模型和驗收技術條件,以及生產加工用的工藝文件,但這并不全面,零部件的產品數(shù)據(jù)還應包含前期的設計文檔、試驗文檔以及后期的使用維護資料等,因此在建立零部件的更改機制時,必須考慮到這些產品數(shù)據(jù)的變化和影響[4-5]。
版本是記錄和追溯更改歷程的標識,版本的演變規(guī)則是零部件更改管理的核心組成[6]。根據(jù)版本的衍生及追溯關系,版本模型分為線性模型和樹狀結構模型,如圖1所示。
圖1 版本模型Fig.1 Model of version
由圖1可以看出,線性追溯模型是按版本生成的時間順序進行排列的,而樹狀的追溯模型不光考慮了生成的先后順序,并且考慮了版本之間的衍生關系。在實際工程應用中,線性追溯模型的管理更簡單清晰,計算機管理更易實現(xiàn)。所以目前在航空行業(yè)內部管理中,均采用線性追溯模型。
確立了版本追溯模型,再結合有效性管理規(guī)則建立版本管理模型,具體見圖2。
圖2 版本管理模型Fig.2 Management model of version
由圖2(a)可以看出,版本變化而有效性始終保持不變,即新版替代舊版,稱之為串行版本管理。由圖2(b)可以看出,版本變化的同時,對應了不同的架次有效性,即各個版本均對應了不同狀態(tài)的零部件,稱之為并行版本管理。
在零部件更改過程中,還需要考慮的一個問題就是更改追溯,即較低層次的零部件發(fā)生更改,對較高層次的零部件的關聯(lián)影響。由于飛機的產品結構層次深、產品數(shù)據(jù)量大,更改追溯是一項過程較為復雜、工作量較大的工作,一直以來都是更改管理的一個難點。
(1)版本管理模式分析。
航空行業(yè)內基本都是采用并行版本管理模式。在設計試制過程中,這種管理模式因其變更簡單、追溯性強、變更工作量小,較為適宜。但到了交付使用維護階段,由于維護資料均是以零部件編號為依據(jù)判斷維護對象的,不同版本的差異使得零部件的真實狀態(tài)很難被確定,維護工作無法準確實施,具有安全隱患。特別對于交付后仍需改裝的飛機,改裝時沒有一個明確的狀態(tài)基準,發(fā)圖難度大,容易引起設計錯誤和工作反復。因此對于產品數(shù)據(jù)整個生命周期的管理來說,目前的管理模式存在一定的弊端。
(2)更改追溯模式分析.
目前,行業(yè)內對于更改追溯的管理均是按照航標所規(guī)定的,是一種基于圖樣的管理方式,而不是基于零部件的管理方式,詳見圖3。
由圖3可見,追溯的判斷依據(jù)為是否影響裝配關系,即裝配圖樣是否需要更改,這種基于圖樣的管理模式不能反映零部件的真實變化。
(3)現(xiàn)行零部件更改管理模式存在的問題。
圖3 更改追溯邏輯推斷Fig.3 Logical deduction of retrospective change
通過對目前行業(yè)內零部件更改管理中的版本管理模式以及更改追溯模式的分析,可以看出其存在問題主要體現(xiàn)在以下幾點:
a.由于使用版本控制和區(qū)分零件,因此版本標識必須作為零件標識的一部分,所以當試制現(xiàn)場出現(xiàn)臨時性更改時,零件上的版本標識會與圖樣的版本標識不一致,造成實物與圖樣不一致的情況;
b.由于目前的產品保障體系與研制體系的管理模式不配套,會造成試制批的產品狀態(tài)與保障資料中所列的產品狀態(tài)不一致,導致后期的使用維護沒有依據(jù),存在安全隱患;
c.對于裝配件來說,編號和版本并不能區(qū)分其真實狀態(tài),這部分不可控,不符合技術狀態(tài)管理的要求。
以波音公司為例,更改管理采取的是換版與變號相結合的更改管理模式。即對于同一編號的零部件來說,使用串行版本進行管理,永遠保持最新版有效,當該零部件的外形、配合、功能(3F)或適用有效性發(fā)生變化時,均采取變號的方式。其更改邏輯推斷模型如圖4所示。
串行的零部件更改管理模式,過程簡單清楚,但是按上述的邏輯推斷,變號較為頻繁,作為零部件的產品數(shù)據(jù)集合,變號就要按新號重新建立產品數(shù)據(jù)。且需要逐層進行更改追溯,即每一層裝配均需變號。對于飛機這種隸屬關系深,數(shù)據(jù)量龐大的產品來說,這種追溯工作量是很大的,那么波音是如何解決的呢?
圖4 零部件更改邏輯推斷圖Fig.4 Logical deduction scheme of aircraft part and assemble rejigger
波音公司采用了模塊化設計的手段,將產品數(shù)據(jù)結構扁平化,大大簡化了追溯。傳統(tǒng)的產品結構完全是按飛機的隸屬關系進行分解和構成的,一旦進行變號更改追溯,就需要追溯至頂層裝配圖樣。波音采用模塊化設計方法將產品數(shù)據(jù)結構扁平化,將追溯控制在模塊級以下,且模塊級以下的裝配關系不會超過三層,更改追溯層級不多,大大簡化了追溯過程。波音的這種做法是基于零組部件的管理,能夠清晰有效地控制和掌握零組部件的狀態(tài),滿足產品的技術狀態(tài)管理需求。
經過上述分析,結合目前國內的模塊化設計現(xiàn)狀,可以采取下述方案進行解決 。
首先根據(jù)更改的性質,將更改分為“糾正型更改”和“適應與改進型更改”,然后根據(jù)兩種更改的特點分別建立更改機制,以達到最優(yōu)最簡的更改實施效果。
更改前的對象將不應用于最終產品中。在詳細設計過程中為了糾正設計制造錯誤、提高性能等,需對零部件的幾何設計、工藝加工方法、材料等進行更改,更改前的內容不應用于任何一個或一批產品中。這種投產前對零部件進行的更改稱之為糾正型更改。糾正型更改應使用換版管理的方法處理。
更改前的零部件已應用于最終產品中。形成最終產品后,由于用戶對產品提出了新的要求,或設計方為了改進性能和增強功能,需要對零部件進行更改,并應用于后續(xù)全部或部分架次中,將此類更改稱之為適應與改進型更改。
對于適應與改進型更改,如零部件的外形、配合、功能和互換性發(fā)生變化,應根據(jù)具體情況按一定的邏輯判斷進行變號處理,否則仍可使用換版更改。
依據(jù)上述概念,可以建立如圖5所示的零部件換版與變號的邏輯推斷圖。
由圖5可以看出,在整個邏輯推斷中,并沒有考慮有效性(架次)變化的影響,而主要是以零部件的互換來進行推斷的,這樣一來可以有效地減少變號次數(shù),簡化更改管理。在工程設計階段,對于零部件的更改往往是為了完善設計,由于各種原因更改前的對象已形成了最終產品,但在后續(xù)架次,該零部件將不再應用,在不影響零部件互換的情況下,可以采用換版更改,以簡化更改管理。所以在實際的工程應用中,進行邏輯推斷時可不考慮有效性變化帶來的影響,而應以互換性影響判斷為主。
零部件的更改追溯,建立如圖6所示的邏輯推斷,作為解決方案。
圖5 換版與變號的邏輯推斷圖Fig.5 Logica l deduction schem e of vision and num ber change
從邏輯推斷圖可以看出,由于更改引起的不同版本的變化,可能分布于不同的飛機架次上,所以向上追溯時必須考慮有效性(架次)變更造成的影響,所以針對有效性(架次)是否改變采用不同的追溯辦法,對于有效性不變的采取最新版有效的方法,對于有效性發(fā)生改變的則版本向上追溯直至頂層裝配,這樣就能滿足有效性過濾的管理需求。
圖6 更改追溯邏輯推斷圖Fig.6 Logical deduction schem e of retrospective change
上述管理方案的科學性、合理性毋庸置疑,短期來看,由于模塊化設計水平較低,追溯層級較多的問題仍然存在,長遠來看,隨著模塊化設計的進一步發(fā)展,該方法的優(yōu)勢必將體現(xiàn)出來。
零部件更改管理是產品技術狀態(tài)管理的一個核心環(huán)節(jié),上述管理方案雖然實施條件上仍有些欠缺,但該方法能夠有效地控制零部件技術狀態(tài),滿足管理需求,其思路和邏輯是正確的、值得借鑒的,因此在后續(xù)的型號應用中有一定的參考價值。
[1] 劉曉冰,孟永勝,邢英杰,等. 制造領域工程更改管理系統(tǒng)的技術研究. 中國機械工程, 2005(15):23-29.
[2] 潘翔,王云鵬,郭學旭,等. 協(xié)同設計中的版本管理解決方案. 航空制造技術, 2004(1):16-21.
[3] 柏彥春,于勇,范玉青,等. 工程更改在飛機項目中的應用.航空制造技術, 2003(9):38-43.
[4] 約琴夫·蕭塔納.制造企業(yè)的產品數(shù)據(jù)管理.祁國寧譯. 北京:機械工業(yè)出版社, 2000:67-91.
[5] 胡斌. 變更信息管理機制及其在PDM變更管理中的應用[D]. 杭州 :浙江大學,2004:13-24.
[6] 萬立,羅新星. 產品數(shù)據(jù)管理中的工程變更管理的建模與實現(xiàn). 計算機輔助工程, 2004(2):25-30.