摘要:提出了協同設計工作模式,給出了系統的工作流程,定義了用戶的權限分配,研究了基于交互日志的傳輸方式,討論了協同設計過程中的實時更新機制#65377;最后采用了基于MVC的體系結構構建了一個原型系統,該系統在實際應用中,驗證了該技術思路的正確性#65377;
關鍵詞:協同設計; 批注; 實時更新
中圖分類號:TP391.72文獻標志碼:A
文章編號:1001-3695(2007)04-0285-03
0引言
隨著經濟全球化進程的加速,虛擬企業得到了快速發展,許多復雜產品的設計要求由分布在不同地域的產品設計者協同完成#65377;Internet的快速發展則為這一需求提供了有力的條件#65377;產品協同設計是由分布在不同地理位置的設計者通過網絡進行產品信息的共享和交換并對設計方案進行討論,實現方案的協調#65380;設計決策的優化,動態實時地對設計結果進行檢查與修改,從而快速高效地完成產品的設計任務#65377;協同設計系統支持多個設計者異地同步參與產品的設計過程,能夠大幅度地縮短產品的設計周期,降低產品開發成本,提高個性化產品開發能力[1]#65377;因此探索和研究產品協同設計新的理論#65380;方法和技術具有非常重要的意義#65377;早在20世紀90年代,斯坦福大學設計研究中心的Cutkosky就已經開始了這一領域的研究#65377;十幾年來產品協同設計得到了研究者的廣泛響應和極大的關注#65377;基于網絡的協同設計在產品的設計過程中正逐漸體現出越來越重要的作用,出現了許多有價值的成果#65377;但是,產品的協同設計對群體性#65380;動態性#65380;并行性#65380;異地性和實時性等方面提出了很高的要求,這通常是大多數簡單的協同應用軟件或系統所不能滿足的#65377;有的系統為了達到瘦客戶端的目的,將建模和約束操作都放在了服務器端來解決[2~5]#65377;這類系統的結構簡單#65380;并發控制容易,但三維產品的CAD模型通常比其他文件具有更大的數據量;并且在協同設計過程中,要求實時刷新產品模型的設計結果,這要求網絡中頻繁進行大數據量的傳輸,從而造成了網絡負載過重#65380;通信延遲明顯等現象#65377;有的系統為了減輕網絡傳輸負擔,增強交互響應能力,采用各個客戶端放置建模系統進行同步協同造型的方法[6~11]#65377;這類系統帶來的問題是,多個站點的數據一致性#65380;實時更新#65380;安全性問題難以得到保證,對系統的并發控制困難#65377;
基于上述問題,筆者提出了一個支持產品外形協同設計系統#65377;該系統的工作模式是:在各個客戶端放置建模系統,由一個人負責主操作,其他人瀏覽模型的設計結果#65377;在瀏覽過程中可以在批注面上添加批注信息并通過服務器實時反饋給主操作者與其他的客戶端進行意見交流#65377;為了減輕網絡中數據的傳輸負擔,系統采用了交互事務日志的傳輸方法#65377;該系統在實踐中取得了滿意的效果#65377;
1產品外形協同設計的研究及應用現狀
在產品協同設計過程中,動態地對產品的設計結果添加批注信息,并實時反饋給其他的客戶端,能夠支持不同領域協同者從不同角度對產品模型進行意見的共享和交流,達到異地協同設計的目的#65377;1998年Kim等人開發了一個基于Web的三維協同標注系統CyberView[12],該系統支持各客戶端的用戶通過Web對服務器端的三維模型進行瀏覽并添加標注#65377;隨著對該領域的關注和大量研究者的參與,出現了一些商業系統,如Webscope[13]允許多用戶同時對CAD模型及文檔瀏覽#65380;標注和查詢;OneSpace Designer[14]提供了協同數據的瀏覽#65380;標注#65380;編輯和保存功能;DIVISON[15]具有對二維及三維產品的標注功能#65377;Alventive公司也開發了一個系統[16]用來支持協同瀏覽和信息標注#65377;但這些系統的目標主要集中在產品模型的數據交換#65380;協同瀏覽和標記功能上,對產品模型的協同創建#65380;刪除以及模型的協同編輯操作等功能支持不足#65377;
2系統功能分析和工作流程
2.1系統功能分析
系統的框架結構如圖1所示#65377;在圖中,筆者給每個客戶端站點都放置建模系統,使造型的過程發生在客戶端;客戶端與服務器端之間傳輸的是交互事務日志,而非交互信息量和模型信息量,從而大大減少網絡負擔#65377;造型過程發生在客戶端,服務器端創建事務緩沖區負責保存交互事務日志集,并實時地將日志集廣播發送給各個客戶端,促使各客戶端模型的更新顯示#65377;
2.2系統工作流程
系統的工作流程圖如圖2所示#65377;根據需求,筆者在系統中定義了兩類客戶,即主操作者(Main Designer)和普通操作者(Ordin Designer)#65377;系統對不同的客戶賦予不同的權限,主操作者登錄后,可以創建#65380;修改三維模型,編輯過程中可調整觀察視點,當視點被調整到普通客戶添加標注時的視角方位時,就可以查看其他人添加的標注信息,也可以自己添加標注信息;普通用戶登錄后,不能對模型進行修改,但可以旋轉視點,從不同角度瀏覽查看模型的設計結果,并添加標注信息#65377;
3設計
3.1數據結構設計
本系統中的標注信息被保存在與物體表面成一定角度的標記平面上#65377;協同設計過程中,用戶A將視點旋轉到某個方位通過筆在屏幕上添加標注,此時的標記平面與系統的視平面重合,系統保存下標記平面的坐標信息,并以交互日志的方式傳送到服務器端,服務器再采用實時更新機制將日志廣播給其他客戶端,從而使其他客戶端在瀏覽三維模型時只需將視點旋轉到一定的角度,即可看到用戶A所做的標記#65377;標記平面定義如下:
objList記錄當前MarkFace對應的場景中的對象模型集合#65377;
為了減少網絡中數據的傳輸量,本文采用了交互日志的傳輸方法#65377;交互日志的定義如下:
其中各個參數的含義如下:
Opi為某一客戶端發出的交互操作命令#65377;
UserID為用戶角色,主操作者或一般客戶#65377;
tag為標志位,表示命令的類型#65377;0表示創建型,1表示編輯型,2表示標注型#65377;
Command為創建型或編輯型的具體哪一種,即確定為一個具體的操作命令#65377;
BaseFace為用戶編輯的幾何模型的當前表面#65377;
MarkFace為存放標注信息的標注面#65377;
parameterList為參數集合,記錄了三維模型的位置和形狀等幾何信息的參數#65377;
Offset為創建型命令的偏移量#65377;
BeginTime為交互事務開始時間#65377;
EndTime為交互事務結束時間#65377;
3.2系統體系結構設計
三維模型的設計系統需要有良好的體系結構#65377;本文采用標準的MVC(ModelViewControl)設計模式,使視圖層與數據層分離,更為重要的是將交互與建模#65380;繪制分離,能夠大大有利于交互設計的擴充#65377;利用MVC設計模式構建的系統框架結構如圖3所示#65377;
MVC設計模式中,View用來接收用戶輸入的筆#65380;鼠標#65380;鍵盤等輸入事件,但View自身并不處理這些事件,而是將它們發送給Control#65377;當Model發生變化時,View接收來自Control的消息,并通知視圖模型進行更新#65377;系統中View不僅提供了幾何模型的顯示功能,而且提供了編輯功能#65380;回顯(FeedBack)#65380;工具提示(ToolTip)等#65377;
Model只與Control打交道,而不知道任何與View相關的東西#65377;為了能讓Control知道Model的變化,筆者將Control作為事件監聽者注冊在Model中,當Model發生變化時,就觸發相應的事件給Control,后者負責通知View進行更新#65377;在模型對象中,定義了一個TransformNotify成員變量,用來維護監聽器成員,即Control#65377;在圖3中,Modellor類是所有幾何模型的基類,2DModellor與3DModellor對應二維和三維的幾何模型對象#65377;
Control是MVC結構中Model與View之間溝通的橋梁,也是整個系統體系結構的核心#65377;它不僅要監聽模型的變化,當用戶操作改變視圖時,還要把變化結果反映到模型上#65377;在Control中,筆者設計了一個CStateFactory對象,在設計過程中系統每生成一個模型,CStateFactory都負責給該模型創建一個CState對象,所有的CState對象共同組成了Control部分,而這個CStateFactory類將會被View所利用#65377;在協同設計過程中,客戶端用戶的操作被轉換為一系列請求(Request),請求分三大類,即創建型請求#65380;編輯型請求#65380;標注型請求#65377;所有的請求被當做交互日志發送到服務器端進行處理#65377;服務器端先根據實時更新策略對不同的請求作出不同的處理,然后再將處理完的請求以廣播的形式發送回各個客戶端#65377;各客戶端的造型解釋模塊在接收到服務器端發送過來的Request后,將其轉換為具體的Command并發送給造型器進行幾何模型的刷新#65377;
4關鍵技術
4.1批注面的計算
當用戶旋轉視點到某一位置后,此時的標注面也就隨著視點的確定而確定下了#65377;批注面的計算方法描述如下:
(1)計算當前視點EyePoint的世界坐標值#65377;
(2)計算當前視線L的法向量Vector#65377;
(3)無論視點怎么改變,視點到視平面的距離始終是定值z,利用EyePoint#65380;Vector和z計算出視點在視平面上的投影點AtPoint#65377;
(4)利用AtPoint和Vector可以確定出當前的視平面方程#65377;
(5)將點AtPoint賦值給MarkFace中的Point進行初始化,MarkFace的法向量Normal取視線L的向量#65377;當用戶添加批注時,批注內容的文字信息被保存在Description中,同時批注者的ID信息以及批注時間(取系統的當前時間)以及當前視平面中所見場景中的模型對象都將保存到MarkFace中#65377;
當用戶旋轉視點到一個新的位置和角度時,由于視點的世界坐標發生了變化,利用新的視點可以計算出新的標注面方程,從而支持用戶從另一個角度觀看時添加其他的批注信息#65377;當用戶批注完畢提交時,客戶端將用戶的標記信息保存后再以交互日志的形式傳送給服務器,并由服務器廣播給各個客戶端#65377;其他客戶端瀏覽時,只要將視點旋轉到相應位置,便可以查看用戶在該位置添加的批注,從而達到協同交流的目的#65377;
4.2實時更新機制
如前面所述,服務器端在接收到客戶端發送過來的交互日志后,先依照提交時間的先后順序將交互日志存放到交互事務緩沖區中,然后按照先進先出的機制將日志廣播給其他客戶端,促使其他客戶端實時更新幾何模型#65377;本文提出了交互日志的實時更新算法#65377;其過程如下:
(1)若交互事務隊列不為空,從交互事務隊列取出下一個交互事務#65377;
(2)判斷當前事務的UserID#65380;tag#65377;
①如果UserID是MainDesigner,tag=0,或者UserID是MainDesigner,tag=1,則為主操作者發出的創建型或編輯型命令手勢,根據Command#65380;BaseFace#65380;parameterList和Offset計算出創建命令的具體參數#65377;轉至步驟(3)#65377;
②如果UserID 是MainDesigner,tag=2,則為主操作者發出的添加標注命令,根據MarkFace提取出標記信息#65377;轉至步驟(3)#65377;
③如果UserID是OrdinDesigner,tag=0或UserID是OrdinDesigner,tag=1,則為普通客戶發出的創建型或編輯性命令#65377;不進行任何操作,轉至步驟(3)#65377;
④如果UserID是OrdinDesigner,tag=2,則為普通客戶發出的添加標注命令,根據MarkFace提取出標記信息#65377;轉至步驟(3)#65377;
(3)將交互事務廣播發送給所有客戶端#65377;返回步驟(1)#65377;
以上算法保證了協同設計過程中只有MainDesigner負責操作模型,其他客戶端在MainDesigner操作模型時,只能瀏覽設計結果并添加標注信息,并能實時反饋到其他客戶端,進行意見的交流#65377;主操作者在匯總其他人的意見后,可以重新對模型進行修改或編輯,從而達到協同的目的#65377;與其他協同設計方法相比,本算法既保證了異地多人參與協同設計的目的,又有效避免了多人同時參與創建#65380;編輯模型帶來的沖突問題,從而保證了協同設計的順利進行#65377;
5應用實例
本文設計的系統的運行界面如圖4所示#65377;
在以上分析的基礎上,筆者在Windows 2000系統下,采用VC++6.0,MS SQL Server 2000數據庫,在OpenCascade平臺上開發了一個產品外形協同設計系統#65377;
6結束語
三維產品的協同設計系統對網絡帶寬和客戶端的軟硬件配置都提出了很高的要求,而現在的網絡帶寬
以及客戶端的配置常常不能滿足其要求,從某種意義上講,True Internetbased Collaborative Product Design Systems are not Yet Available。本文在分析比較了以往研究成果的優缺點的基礎上,提出了一人操作眾人觀看的協同設計模式,減少了并發沖突發生的可能性。在研究的基礎上,開發了一個原型系統。該系統在客戶端放置建模系統,客戶端與服務器端傳輸的是交互事務日志,大大減少了網絡中傳輸的數據信息量,從而減輕了網絡負擔。目前系統存在的問題是交互過程不夠自然,下一步的工作重點是:研究自然有效的交互手段,進一步研究基于日志的傳輸算法以提高模型的實時更新。
本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文。