陳 亮 王 偉
福州大學,福州,350002
在產品多學科協同設計中,各學科間存在著多方面的差異,易引起學科間的歧見,產生設計沖突,因此需要通過合適的機制和策略,盡早發現和解決沖突,協調并維護學科間設計的一致性,這也是保證協同設計成功的關鍵,是協同設計研究的重點問題之一。
文獻[1]使用約束來表達工程要求,求解這些約束可得出設計變量的可行解空間,利用可行解空間可以避免設計者間的人工沖突,改進協同設計的效率。文獻[2-3]對多設計主體間的協調問題進行了研究,當某處的模型數據發生變化時,這種變化信息要及時地傳播到相關的地方,其數據要作出相應的變化,從而維護模型數據的一致性。它們主要考慮產品物理結構層的約束關系,對于處理數值型約束是有效的。文獻[4-6]認為產品模型包含功能、行為、幾何與物理結構等數據,彼此之間也存在著約束關系,設計中需要綜合考慮。多學科協同設計具有多域性、多視圖性等特點,產品最終的物理結構是功能語義推理的結果,多學科視圖模型間除了在物理結構層存在約束關系外,在功能、行為等語義層上也存在著關聯關系,所以將多學科視圖模型間的關聯關系擴展到語義層,對有效維護多學科視圖模型間的一致性是至關重要的。本文借鑒已有的研究工作,并結合產品多學科協同設計的特點,對產品多學科協同設計的約束-關系網絡模型進行研究,探討多學科設計間一致性維護的方法和策略。
多學科協同設計是多個學科設計者并行地進行從功能空間到物理空間的映射過程的設計,在映射過程中經歷功能、行為和結構的各個階段。功能、行為和結構三者密不可分,功能對象、行為對象和結構對象之間存在著關聯關系,在各對象內部參數屬性之間以及不同對象的參數屬性之間存在著各種約束。此處,關系是指對象之間(包括同類對象之間以及不同類對象之間)存在的結構和語義關聯;約束是指對象的屬性之間(包括同一個對象的內部屬性之間以及不同對象的屬性之間)存在的關聯。簡單地說,即對象之間存在關系,對象的屬性之間存在約束。
多學科協同設計的約束-關系網絡具有多域性、多層次性、動態性、分布性和多視圖性等幾個特點。①多域性和多層次性:產品的設計經歷功能域、行為域和結構域的迭代映射,在各個域中還存在著從產品到部件到零件的層次分解過程,從而呈現出多域性和多層次性的特點。②動態性:設計過程是一個不斷探索和不斷進化的過程,往往需要根據當前的情況來動態地修改、添加和刪除對象的組件及其約束,從而呈現出動態性的特點。③多視圖性:各學科基于自身的視角觀察產品對象,產生學科視圖模型,多學科視圖模型之間是共進化的關系,彼此間存在著約束和關聯關系。④分布性:不同學科位于不同的地理位置完成自身的設計任務,從而呈現出分布性的特點。
根據這些特點和一致性維護的需要,定義如下約束-關系網絡:
(1)項目約束-關系網絡(project constraint and relation net,PCRN)。PCRN={Rp,Cp},其中,Rp為隸屬于項目p的關系集,Cp為隸屬于項目p的約束集。在產品設計時,先要進行產品配置設計,本文將產品及其組件均作為設計項目進行管理,每個組件的設計均是一個設計項目。PCRN主要是對產品總體規范、產品的配置和構成、各組件的初始設計要求及其學科聯盟等方面的各學科共同遵守的一般性約束-關系進行描述,而關于組件更詳細的約束 -關系信息需要在學科模型中定義。
(2)學科約束-關系網絡(discipline constraint and relation net,DCRN)。DCRN ={Rd,Cd},其中,Rd為隸屬于學科d的關系集,Cd為隸屬于學科d的約束集。對于產品及其組件,不同學科有不同的設計要求,當然就有不同的約束信息,深入組件內部的更詳細的約束-關系信息應該在各學科內部來確定和定義。一個學科依據本學科的設計要求和專業知識來定義其學科約束-關系網絡。由于一個產品或組件可能為多個學科所關注,不同學科關注產品的不同側面,所以學科約束-關系網絡并不是獨立的,而是相互關聯的。當某個學科改動組件對象的關系或屬性參數時,不僅需要在本學科約束-關系網絡中檢測這種變動是否可行,還需要將這種變化傳播到其他相關學科的約束-關系網絡進行檢測,只有在所有學科的約束-關系網絡中都可行時,該改動才可予以實施。
(3)多學科協同設計的約束-關系網絡(multidisciplinary collaborative design constraint and relation net,MCDCRN)。MCDCRN ={PCRNi,DCRNi1,DCRNi2,…,DCRNik}, 其中,i為設計項目的序號,i={1,2,…,n|n≥1};k表示參與該項目設計的學科序號,k={1,2,…,m|m ≥2}。產品的項目約束-關系網絡與相關的多學科約束 -關系網絡共同組成該產品的多學科協同設計的整體約束-關系網絡,以維護多學科模型間的協調和一致性。
約束-關系模型是產品模型的一部分,兩者結構應相適應并同時構建,以使約束模型與產品模型相協調。基于面向對象的方法來構建約束 -關系模型,關系R表達為

式中,RCid為關系對象的唯一標識;RName為關系名稱;RDis為關系所隸屬的學科,對于項目關系,其名稱統一為RProj,其他學科則根據項目構建時對學科名稱的設置而定;RInfo為關系說明,可選;MO為關系中的主對象;CO為關系中的其他相關對象(一個或多個)。
MO和CO均可表示為三元組(O Type,O Name,O Info),O Type為對象類型(對于項目關系來說,對象亦指學科,此時O Type值為Discipline,通過關系將幾個相關學科關聯起來;在學科內,O Type值分別為Function、Behavior、Principle、Structure),OName為 對象名稱,O Info為對象說明。
約束C隸屬于關系R,即由關系R關聯起來的幾個對象的屬性參數之間的約束(零個或多個)。約束有2種情況,一種是對象自身內部的約束,即對象自身屬性參數之間的約束,在組件對象模型內部定義;另一種是不同對象屬性參數之間的約束,在組件對象的關系模型中定義。約束C表達為

式中,CName為約束對象的唯一標識,也就是約束對象的名稱;CBody為約束體,即約束的表達式,用來表示該約束的具體內容;CDis為約束所隸屬的學科,對于項目約束,其名稱統一為CProj,其他學科則根據項目構建時對學科名稱的設置而定;CInfo為對該約束的說明,可選。
M為約束對象的方法集。每個方法都是一個多元組(M Name,ret,{ipt}0)。其中,M Name為該方法的名稱,這個名稱在方法集M中是唯一的;ret為該方法的返回值的類型;ipt為輸入參數的類型(零個或多個)。
A為約束的屬性。A=(CType,PAttr),PAttr=(P Name,P Info,P Value)。其中,C Type為約束的域別,有Function、Behavior和 Structure三種取值,分別表示該約束屬于功能域、行為域和物理結構域。PAttr為約束所涉及的參數集,其中PName是在約束體C Body和方法集M中引用到的參數名,表示方式為“對象名稱.參數名稱”;P Info是參數說明,可選;P Value是參數當前取值。
基于前述的約束網絡,綜合采用項目管理、語義推理、關系及約束等多種途徑來實現多學科視圖模型間的協調與一致性維護。當有設計變更發生時,一般先通過項目管理、關系、語義推理等實現學科間相關組件對象的關聯,再通過約束保證各組件對象參數屬性之間的協調。
在產品建模過程中,若學科模型組件間的約束-關系被確定下來,此時的約束-關系網絡處于穩定狀態。當某個學科模型組件的狀態發生了變化,則根據組件間已存在的約束-關系網絡觸發各學科模型的相關組件作出相應的變化,實現協調和一致性維護,稱之為學科模型間的靜態協調。
2.1.1 通過物理結構關系和約束實現一致性維護
根據產品的物理結構組成,定義表1所示的物理結構關系集,利用這些結構關系以及相應的約束來實現協調與一致性維護。一般是通過關系將相關的組件對象關聯起來,再通過約束保證各組件對象參數屬性之間的協調。

表1 組件對象在物理結構上的關系集
圖1為單級減速器結構約束-關系網絡圖(部分),其中的一些關系和約束的表達見表2。比如,在齒輪副gearpair組件對象、齒輪gear1組件對象和齒輪gear2組件對象之間存在著Has_Component關系對象RLT231和K_Joint關系對象RLT341,以及隸屬于這些關系對象的約束對象 CS231、CS232、CS341 和 CS342 等,它們共同組成了一個局部的約束-關系網絡,當某組件(如gear1)的屬性發生變化時,則先通過關系對象RLT231和 RLT341將受影響的組件對象(gear2、gearpair等)關聯起來,再利用隸屬的約束對象CS231、CS232、CS341和 CS342等使受影響的組件對象的相應屬性值產生變化,以維護幾個組件對象之間的協調與一致。同理可分析其他組件間的協調與一致性維護。

圖1 單級減速器的結構約束-關系網絡圖

表2 單級減速器中的一些結構約束-關系表達(簡化)
2.1.2 通過語義關系、語義推理和約束實現一致性維護
由于在組件的功能、行為和結構之間存在一定的映射關系,故定義如表3所示的組件對象之間的語義關系集,據此給出單級減速器中的一些語義關系實例(表4),可以通過這些語義關系結合語義推理來實現相關組件對象間的關聯和協調。功能域、行為域和結構域之間通常是雙向映射的,所以實現相關組件對象間關聯和協調的語義推理一般也需要經歷正向推理和逆向推理兩個過程。

表3 組件對象之間的語義關系集

表4 單級減速器中的一些語義關系表達(簡化)
(1)逆向推理過程。假設設計者對組件A進行操作,引起其結構屬性的變化,組件A結構屬性的變化又引起其相關的行為屬性(通過Achieve關系來確定)的變化,進而又影響到組件A相關的功能(通過Assure關系來確定)。
(2)正向推理過程?;诮M件A的功能變化,通過功能連接關系Correlate來確定在功能上與組件A變化的功能語義相關的組件B,然后檢查組件B相應的功能,找出影響該功能的相應行為(通過Assured_by關系來確定),再找出影響該行為的相應物理結構屬性(通過Achieve_by關系來確定),對組件B的受影響的物理結構屬性進行更新以便與組件A變化了的結構屬性相協調,從而維護組件B與組件A之間的一致性。
假設取組件A為齒輪gear2,改變其結構屬性參數(如齒數、模數等)將導致其強度性能行為(承載行為)變化(通過Achieve關系推理確定),而承載行為的變化將影響到其傳遞功率的功能(通過Assure關系推理確定)。基于受影響組件gear2的傳遞功率功能的變化,通過語義推理發現軸組件axis2的功能是傳遞功率與扭矩以及支承的回轉零件,這與齒輪gear2變化的功能是相關的,因此可推理確定組件 B為 axis2(經由Correlate關系確定);而axis2的相應的行為主要是其承載能力,包括軸強度性能行為和軸剛度性能行為(通過Assured_by關系推理確定);進而推理確定影響axis2承載能力行為的相應的物理結構 axis2.OSru1(經由 Achieved_by關系確定),在結構對象OSru1中包含了axis2的結構屬性參數(如直徑、長度和材料等)及相應的約束、分析計算方法和知識;然后用這些約束、方法和知識對這些結構屬性進行分析并作出更新,以便同齒輪gear2變化了的結構屬性參數相協調。這種語義推理的方法更為靈活和柔性,也與設計人員的思維推理過程相吻合。
2.1.3 通過項目管理、關系和約束實現一致性維護
多個學科模型間有一些共同關注的組件,可通過項目管理和組件學科聯盟關系將與共享組件相關的學科模型關聯起來,再通過項目約束和相關學科模型的約束來實現不同學科模型間共享組件對象間屬性參數的協調。項目管理模塊負責進行產品設計項目配置,對各組件項目建立項目數據表等。當某學科基于產品設計項目配置進行學科視圖模型構建時,若繼承并實例化了某組件,則該學科的相關信息(如學科領域、地址、權限等)就被上傳和記錄在項目管理模塊中關于該組件的項目數據表中,并生成該組件的學科聯盟關系對象為學科關系名稱,Rproj為該關系屬于一種項目關系,MO指主學科對象,{CO}1指從學科對象(一個或多個),{C}0為隸屬于關系R的多學科之間的項目約束。
當某學科對組件對象的屬性進行了修改操作時,則組件對象的狀態發生變化,經由項目管理模塊和組件的學科聯盟關系找到相關學科,并將變化了的狀態信息傳輸給相關的學科模型,在項目管理模塊和項目約束的控制和協調下,各相關學科模型依據自身的組件約束屬性進行檢測、判斷和響應,實現彼此間的協調和一致性維護。
一般可設定在一次交互循環中,以一個學科為主學科,它擁有組件對象的改變權,而其他學科則為從學科,只有響應權和建議權。一次交互循環定義為從一個學科改變組件對象開始,直至學科間實現協調為止。若多學科設計者在同一時間內對產品模型進行并發操作,則需要采用特定的并發控制策略進行控制,其本質就是在一個學科對組件對象的相關數據進行修改和更新等操作時,使得其他學科暫停對這些數據的操作,即一個數據(集)在同一時間內只能被一個學科操作,以獨占方式調用,從而避免出現并發沖突,保持產品數據的一致性。
如圖2所示,齒輪副是結構設計、強度設計和摩擦學設計這三個學科共同關注的組件,當構建各自學科模型時,三個學科的相關信息就被記錄在齒輪副項目的數據表中,并生成齒輪副學科聯盟關系對象PRL1等(其他關系對象省略),PRL1將三個學科對象DStru、DStre和DTri關聯起來,其中DStru為主學科。當DStru對齒輪副的參數值進行修改時,根據關系對象PRL1和齒輪副項目數據表,修改信息由項目管理模塊自動傳遞到相關的學科對象DStre和DTri,而后面這兩個相關學科則根據自身學科模型中的齒輪副約束集進行檢測并作出響應,彼此進行協調,以維護學科模型間的一致性,同時,各學科模型均應遵守齒輪副組件項目中的約束規范 PCS1、PCS2、PCS3,即關于齒輪副輸入功率、傳動比和輸入轉速的約束。

圖2 不同學科模型間共享組件間的協調
當某學科設計者對其學科模型進行改變時,通過綜合應用上述關系、語義推理及項目管理等多種途徑,將相關組件對象和相關學科視圖模型關聯起來,并應用相應的操作策略和方法實現多學科視圖模型間的協調與一致性維護。
在產品建模過程中,若某學科出于自身的考慮,在其現有模型的基礎上,動態地添加或刪除一些新的組件對象,此時的約束-關系網絡處于變動狀態,其他學科根據各自的需要,對自身的學科模型進行變動和更新,實現協調和一致性維護,約束-關系網絡達到新的穩定狀態,稱之為學科模型間的動態協調。
通過語義推理來實現這種協調,關鍵是這些新添加的組件是否有其他學科所關注的功能語義。如圖3所示,當某學科模型添加了新組件后,項目管理模塊就將新組件的功能語義添加到動態功能語義庫(為各學科共享的功能語義黑板)中?;趧討B功能語義庫,其他學科通過自身的組件選擇知識庫進行推理,判斷新組件的功能語義是否是自己所關注的,若為自己所關注,則將新組件添加進自身的學科模型中,否則就忽略新組件。動態功能語義庫按照設計項目進行分組管理,以提高推理時搜索和匹配的效率。

圖3 基于功能語義的多學科模型間的動態協調
如圖3所示,若結構設計學科在其學科模型中添加一個鍵組件(用虛線框表示,它具有兩個一般的功能:周向固定和傳遞轉矩),同時項目管理模塊將其功能語義信息(鍵,“周向固定”,“傳遞轉矩”)添加到動態功能語義庫中,向其他學科進行發布,其他學科判斷該組件功能語義是否為自己所關注。通過推理,強度設計學科認為“傳遞轉矩”是它要關注的功能,因為載荷直接關系到鍵的抗剪強度與擠壓強度問題,所以將鍵組件加入到本學科模型中;而摩擦學設計學科并不關注這兩個功能(此處鍵為靜連接),所以就不將鍵組件加入到本學科模型中。再如套筒組件(用虛線框表示),它的主要功能是實現軸上零件的軸向固定,當結構設計學科添加了該組件后,功能語義信息(套筒,“軸上零件的軸向固定”)被添加到動態功能語義庫中,通過推理判斷,強度設計學科和摩擦學設計學科都不關注套筒的這個功能,所以套筒組件就不會出現在強度設計學科模型和摩擦學設計學科模型中。同理,箱蓋、箱座、軸1和軸 2等組件對象也不會出現在摩擦學設計的學科模型中,這是因為摩擦學設計主要關注的是動連接的組件對象。在具體實現上,各學科添加組件是通過從分布式組件類庫中繼承相應的組件類,再添加學科自身屬性和方法的途徑,在項目管理模塊的管理下完成的,這樣就便于維護和管理各學科模型間的約束和關系網絡。
若在產品建模過程中,某學科出于自身的考慮要動態地刪除一些組件對象,則需根據不同的情況分別進行處理。若組件對象僅隸屬于該學科自身,則該學科可以從自身學科模型中刪除組件對象,與這些組件相關的所有關系和約束一并刪除,同時要從項目管理模塊中將相應的組件項目刪除;若組件對象同時還隸屬于其他學科,則需所有相關學科均認可才能刪除,且所有相關學科均應從自身學科模型中刪除這些組件對象及相關的關系和約束,項目管理模塊中相應的組件項目也同時刪除。
產品設計始于功能需求,終于功能需求的滿足,進行多學科視圖模型間的協調和一致性維護,應該綜合考慮多學科視圖模型間在功能、行為和物理結構上多域多層次的關聯關系,探討相應的協調機制和一致性維護方法。本文對此進行了研究,在產品建模過程中,建立多學科視圖模型間的功能-行為-結構多層次動態約束-關系網絡,通過關系、約束、語義推理和項目管理等綜合應用的約束-關系網絡操作策略和方法,來實現多學科視圖模型間的協調及共進化。以圓柱齒輪減速器為例的初步運行,表明了本文所述思想的可行性。
[1] Lottaz C,Smith I F,Nicoud Y R,et al.Constraintbased Support for Negotiation in Collaborative Design[J].Articial Intelligence in Engineering,2000,14(3):261-280.
[2] Xue D,Xu Y.Web-based Distributed System and Database Modeling for Concurrent Design[J].Computer-aided Design,2003,35(5):433-452.
[3] 何德林,王耕耘,李志剛.基于分布式約束網絡的協同設計研究[J].計算機輔助設計與圖形學學報,2002,14(4):329-332.
[4] Gorti S R,Gupta GJ,Sriram RD,et al.An Object-oriented Representation for Product and Design Processes[J].Computer-aided Design,1998,30(7):489-501.
[5] Roy U,Pramanik N,Sudarsan R,et al.Function-to-Form Mapping:Model,Representation and Applications in Design Synthesis[J].Computer-aided Design,2001,33(10):699-719.
[6] Steven J F,Sebti F,Conrad B,et al.CPM2:a Core Model for Product Data[J].Journal of Computing and Information Science in Engineering,2008,8(1):1-6.