引言

　　 地面導航裝備維修保障系統是一個包含裝備、人員、備件、信息和管理等因素的離散事件復雜大系統,由于導航裝備維修保障系統的離散性、隨機性和復雜性決定了在對它進行建模描述和分析時的困難性,

　　使用仿真技術開展導航裝備維修保障研究,可以全面地考慮可能發生的問題,準確反映動態與隨機的系統特性,節約研究時間與費用,是進行維修保障研究的最佳方法。作為戰場保障裝備的重要組成部分,

　　導航裝備的維修保障過程具有自身的特點,不僅需要考慮裝備本身的功能、結構、任務范圍和使用特點,同時也必須考慮整個使用與維修環境、保障資源的數量與配置,以及保障系統中人力、物力、信息和管理等方面的特性。

　　這是一個復雜與動態的相互作用過程,如何運用仿真語言正確描述維修過程是導航裝備維修保障建模中的主要問題之一。

　　1.Petri網和UML的層次建模分析方法的特點任何一個離散動態系統都有著靜態部分和動態部分。

　　基于UML 和Petri網的層次建模分析方法就是將一個系統一分為二動態部分則采用Petri網來描述,靜態部分是由UML 來描述,用例圖和類圖來描述系統的靜態屬性,通過兩者結合來描述系統的整個組織結構以及子系統之間的連接關系包括資源共享、消息傳遞和同步。Petri網和UML具有不同的特征:

　　1) Petri網具有形式化的嚴格性,UML有友善的用戶界面;

　　2) Petri網可以直接分析驗證系統,UML可以有效地描述系統;

　　3) Petri網善于模擬仿真系統的動態特性,UML模型能夠容易編程實現。

　　基于Petri網和UML 的互補性,本文試圖綜合UML對用戶友好、能夠有效描述系統和Petri網具有形式化的嚴密性、能夠嚴密地分析系統動態性能的這兩種方法。運用UML 和Petri網各自的優點,采取向面向對象Petri網模型向UML模型的映射方法把它們集成起來。

　　2.基于UML和Petri網方法建模思路

　　首先分析系統,建立了系統運行過程的面向對象的Petri網模型,而后按照UML模型提取仿真實體,使用UML 狀態視圖分別表示每個實體對象的狀態變化及相關事件;使用順序圖表述各個實體消息交互,并使用協作圖將各個實體連接成一個大系統。

　　因為UML狀態視圖包含了對象狀態變化的控制條件、活動、操作以及消息傳遞;而順序圖則表現了消息傳遞的時序性,因而結合兩者可以表現仿真過程的控制流。以上建模過程對照了面向對象Petri網的構建過程,所建立的UML 模型既是仿真模型,也是軟件模型,因此可以直接用rational rose軟件實現。

　　第一步:根據對象Petri網轉化為UML 模型的狀態圖:1)對于相對應的對象著色Petri網的庫所都映射為各個被轉變為無子狀態的所有狀態;

　　3.基于OPN的導航裝備維修保障過程描述

　　1)按照面向對象Petri網的組織結構模型描述,每個子系統都有端口與外界通過端口交換信息。端口從功能上分為輸入端口和輸出端口,從用途上來分有消息端口和資源端口,因此子系統的端口可分為四類:消息輸入端口(▽)、資源輸入端口(▼)、消息輸出端口(△)、資源輸出端口(▲)。對應的面向OPN模型圖,限于篇幅本文給出了導航裝備和中繼級修理機構和備件倉庫的庫所、端口和變遷說明,

　　2)將對象Petri網的弧映射為所有無子狀態的狀態遷移;

　　3)將對象Petri網的變遷映射為所有無子狀態的遷移動作。第二步:從對象Petri網提取出UML 模型的仿真實體。第三步:將Petri網轉換為UML順序圖。

　　1)UML中的順序圖將交互關系表示為一個二維圖;

　　2)按照對象分類的庫所組表示對象在其生命周期中的各個狀態;

　　3)將消息分為對象之間通訊和對象自身調用。

　　具體方法是:按弧指向的順序逐個考察庫所組中的相鄰庫所之間的變遷,如果變遷的前置集包含不屬于該庫所組的庫所,那么將該庫所到此變遷的弧轉換為UML消息。如果是庫所組內的則轉化為本對象自身操作調用。根據狀態機圖、和原Petri網可以容易順序圖。Rational Rose也提供了直接轉化功能,這里不再詳述。

　　4. 2　導航裝備指揮中心模型

　　導航裝備指揮中心模塊的模型,該模塊驅動整個仿真系統的運行。在仿真進程啟動后,該模塊即開始生成導航任務,并向相應的導航裝備對象下達任務,發送“下達任務”消息。當預定仿真的導航任務完成后,模塊停止運行,退出仿真進程。

　　4. 3　導航裝備模型

　　導航裝備是維修保障過程的主體,圖5是使用狀態視圖表示的導航裝備模型。在仿真過程中,導航分隊在接到“下達任務”消息后,進入“準備等待”狀態。

　　4.基于UML的導航裝備維修建模分析

　　4. 1　仿真實體的提取與相互關系

　　根據導航裝備維修保障的實際過程,整個模型可分為導航裝備指揮中心、導航裝備、本機修理機構和備件倉庫四個模塊。其中,導航指揮中心負責導航任務的下達;各導航裝備負責完成下達的任務;本機修理機構分為基層級、中繼級、基地級修理機構,各修理機構負責導航裝備的維修和送修,中繼級和基地級修理機構有所屬的備件倉庫;備件倉庫負責導航裝備備件的供應與存貯運輸。

　　所有實體相互協作完成所有使用、維修和保障任務。開始人員準備和裝備調試檢查;在得到來自導航指揮中心的“準備響應”后,導航裝備進入“任務前準備”狀態,準備實施保障,并實時上報裝備狀態;在“任務前準備”結束后向導航指揮中心發出“準備結束”的消息,接到導航指揮中心命令開始實施導航保障;在裝備完成預定任務后,裝備重新進入“待命”狀態,
并向導航裝備指揮中心報告自身狀態。

　　如果在準備過程中或者實施導航過程中發現故障,則裝備進入“維修等待”狀態,本級維修對損傷裝備進行損傷評估后,發出“維修響應”,調度人員、備件、維修工具等資源等待維修,若無法完成本級維修,向上級維修機構發出“維修申請”,在得到“維修響應”后進入“維修”狀態,完成維修后發送“維修結束”信息,并返回“待命”狀態。

　　4. 4　維修機構模型

　　基層級維修機構建模,中繼級維修機構和基地級維修機構原理基本相同,這里不再贅述。該模塊負責維修保障仿真過程的人員與設備等維修保障資源的調度。在接到導航裝備的維修申請后,維修機構將根據當前的資源狀況調度資源,如果資源滿足需求,則向相應的裝備對象發送維修與準備響應,并將所需的資源轉入維修與準備狀態。當接到維修結束消息后,將相應資源轉入可用狀態。

　　4. 5　備件倉庫模型

　　備件倉庫模型。在接到導航裝備維修機構或下級備件倉庫的“備件申請”消息后,該模塊將對可用備件進行調度,檢查備件狀況,如果滿足需求,則發出“備件響應”,并在可用備件中去除相應的備件,如果不滿足需求,則進行相應的延遲。

　　4. 6　維修時序

　　按照仿真過程進行中各個對象進行消息交互的順序圖。圖中按照各消息發生的時序描述了準備過程中各個對象間的消息傳遞、維修過程的消息交互與其類似這種消息的交互過程反映了最后就是集成所有的UML模型,使用以上建立的系統模型進行了進一步細化與設計并在Rational Rose軟件中直接生成導致代碼的產生。運用此模型可以對導航裝備維修保障過程中的可靠性、維修性、保障性等各種因素進行全面的仿真與分析,對導航裝備的維修保障優化參考有著一定的理論與應用價值。

　　5.結束語

　　本文主要目的是為了探討Petri網和UML 相結合方法在導航裝備維修保障模型的應用,該方法是一種從上到下的層次建模分析方法能夠對不同層次的系統進行研究。通過Petri網模型向UML模型的轉化改變了傳統方法不足使UML模型能夠充分的描述系統的并發同步和沖突性質,

　　這樣就使一個復雜的導航裝備維修保障系統模型變得容易理解,下一步筆者將進一步深人研究Petri網向UML轉化的嚴密性,如:順序圖中如何描述資源共享、并發;如何更好地描述狀態圖之間的關系以及該方法在Web程序開發中的應用等方向。

it知識庫：基于OPN和UML的導航裝備維修建模方法研究，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。