基于模型的系統(tǒng)工程

基于模型的系統(tǒng)工程（MBSE）的案例研究第1部分:IBMRationalHarmony的集中式系統(tǒng)模型建模自出現(xiàn)以來(lái)，一直是系統(tǒng)工程的重要組成部分。在過(guò)去十年中，工程師們已經(jīng)大幅增加基于模型的技術(shù)的使用，并發(fā)展出一門新的學(xué)科，基于模型的系統(tǒng)工程（Model-BasedSystemsEngineering,MBSE）。這門學(xué)科與傳統(tǒng)的系統(tǒng)工程不同，它強(qiáng)調(diào)中央系統(tǒng)模型，該模型同時(shí)捕捉系統(tǒng)需求和滿足這些需求的設(shè)計(jì)決策。除了作為系統(tǒng)工程的工作構(gòu)件的知識(shí)庫(kù)之外，還可以通過(guò)模擬系統(tǒng)模型來(lái)驗(yàn)證成本、性能研究和設(shè)計(jì)選擇。IBMRationalHarmonyforSystemsEngineers等廣泛應(yīng)用的MBSE流程重點(diǎn)關(guān)注的是系統(tǒng)功能分析，也就是說(shuō)，關(guān)注如何將功能要求轉(zhuǎn)換為一致的系統(tǒng)操作描述。然后，使用系統(tǒng)操作獲得所分配系統(tǒng)架構(gòu)塊之間的端口和接口。這些接口形成了各子系統(tǒng)之間的正式切換的基礎(chǔ)。MohitChoudhary,系統(tǒng)工程師,RealTimeTechSolutions2012年3月23日內(nèi)容本系列的這一部分旨在通過(guò)一個(gè)案例研究來(lái)探討標(biāo)準(zhǔn)MBSE流程。首先，我們根據(jù)UAV（無(wú)人駕駛飛機(jī)）地面站控制器的設(shè)計(jì)來(lái)擬定這個(gè)案例研究的范圍。然后，我們會(huì)介紹RationalHarmony系統(tǒng)工程流程的基本概念、工作流和工作產(chǎn)品。最后，我們通過(guò)定義任務(wù)流來(lái)實(shí)現(xiàn)UAV地面站控制器的設(shè)計(jì)，同時(shí)構(gòu)造每個(gè)階段所需的構(gòu)件。案例研究本案例研究基于對(duì)少部分UAV地面站控制器的設(shè)計(jì)分析，這些控制器的功能必須符合表1中的要求。表1.UAV地面站控制器需求需求引用需求01實(shí)時(shí)飛行中的UAV的信息。（身份和傳感器負(fù)載）02允許操作員將搜尋區(qū)域分配給選定的飛行中的UAV。03以1次更新/秒的頻率接收來(lái)自UAV的傳感器追蹤信息。04在系統(tǒng)中保持30分鐘的追蹤歷史。05允許操作員維護(hù)包含所采用的系統(tǒng)追蹤信息的資料庫(kù)。06最多維護(hù)100條SystemTracks（系統(tǒng)追蹤信息）。07允許操作員對(duì)系統(tǒng)追蹤信息執(zhí)行生命周期操作（創(chuàng)建/刪除）。08每秒更新一次系統(tǒng)追蹤信息，如果主傳感器追蹤信息更新可用，則使用該值進(jìn)行更新，否則，使用DR的值進(jìn)行更新。09使系統(tǒng)追蹤信息可在顯示屏上顯示，并繪制其更新。10允許操作員將操作員輔助系統(tǒng)追蹤信息與另一臺(tái)UAV的傳感器追蹤信息相關(guān)聯(lián)。11允許操作員將兩條獨(dú)立的系統(tǒng)追蹤信息合并成一條。12將系統(tǒng)中的重要事件（比如創(chuàng)建和刪除系統(tǒng)追蹤信息）通知操作員。13允許操作員隨時(shí)中止UAV搜索。RationalHarmony系統(tǒng)工程中基于模型的系統(tǒng)工程RationalHarmonyforSystemsEngineering使您能夠識(shí)別并推導(dǎo)出所需的系統(tǒng)功能，還能夠確定相關(guān)的系統(tǒng)模式和狀態(tài)。此外，您還可以將已確定的系統(tǒng)功能和狀態(tài)分配給子系統(tǒng)結(jié)構(gòu)，并確定跨子系統(tǒng)的端口和接口。圖1顯示了您在每個(gè)工程階段為了完成系統(tǒng)設(shè)計(jì)而必須執(zhí)行的基本輸入和輸出。圖1.工程階段的生命周期用例狀態(tài)圖在下一步中，您可以使用序列圖獲得端口和接口。獲得端口和接口之后，必須在狀態(tài)圖中捕捉用例的狀態(tài)行為。最后，為了設(shè)定用例的黑盒行為的基線，需要執(zhí)行狀態(tài)機(jī)，并且將生成的序列圖與剛才創(chuàng)建為場(chǎng)景的序列圖進(jìn)行對(duì)比。本用例的狀態(tài)機(jī)如圖5所示。圖5.黑盒狀態(tài)圖狀態(tài)“SearchExecuted”有兩個(gè)‘a(chǎn)nd'子狀態(tài)：“PerformSensorTrackManagement執(zhí)行傳感器追蹤信息管理”和“PerformHistoryCheck”。第一個(gè)子狀態(tài)支持追蹤信息的建立或更新，第二個(gè)子狀態(tài)清除大于30分鐘的傳感器追蹤信息歷史，如果傳感器追蹤信息沒(méi)有歷史記錄，則清除傳感器追蹤信息本身。架構(gòu)設(shè)計(jì)在架構(gòu)設(shè)計(jì)階段，您需要重點(diǎn)關(guān)注結(jié)構(gòu)分解，以及如何將操作和行為分配給子系統(tǒng)組件。首先，我們描述了將系統(tǒng)結(jié)構(gòu)性分解成子系統(tǒng)的系統(tǒng)BDD（參見(jiàn)圖6），然后我們將獲得UseCaseWhite-BoxActivityDiagram，并通過(guò)它將用例的操作分配給分解后的子系統(tǒng)（參見(jiàn)圖7）。當(dāng)將系統(tǒng)分解成子塊后，它會(huì)以關(guān)鍵系統(tǒng)功能的定義為基礎(chǔ)。這一階段的目標(biāo)是對(duì)系統(tǒng)功能進(jìn)行分組，每個(gè)組可以通過(guò)一個(gè)子系統(tǒng)組件實(shí)現(xiàn)。第一步是將相關(guān)的系統(tǒng)功能劃分為關(guān)鍵系統(tǒng)功能。對(duì)于本用例，我們通過(guò)用例黑盒活動(dòng)圖的分析，確定了以下三個(gè)關(guān)鍵系統(tǒng)功能：管理傳感器追蹤信息控制人機(jī)界面執(zhí)行歷史管理圖6.UAV管理系統(tǒng)BDD考慮到要使用一些關(guān)鍵系統(tǒng)功能，我們獲得了如圖6所示的BDD。因?yàn)槲覀冇凶酉到y(tǒng)塊，所以接下來(lái)的任務(wù)是在各個(gè)泳道中執(zhí)行分配操作，以描繪每個(gè)獨(dú)立的子系統(tǒng)塊。以下是重要的分配規(guī)則：如果您無(wú)法將操作分配到單個(gè)塊，那么必須將操作分解。在這種情況下，已分解的相關(guān)業(yè)務(wù)必須通過(guò)各自的依賴關(guān)系鏈接到父操作。您可以將一個(gè)系統(tǒng)級(jí)的操作分配到多個(gè)塊。在這種情況下，需要將相關(guān)的操作復(fù)制到相應(yīng)的塊泳道，并將它們集成到功能流中。圖7.白盒活動(dòng)圖圖7.白盒活動(dòng)圖圖7.白盒活動(dòng)圖在圖7中，與操作員交互相關(guān)的操作已包含在人機(jī)界面(MMI)控制器組件中。同樣，與創(chuàng)建、更新和處理傳感器追蹤信息相關(guān)的操作被分配到TrackManager泳道。而與歷史數(shù)據(jù)管理有關(guān)的操作都推送到HistoryManager泳道。在將連續(xù)流拆分成兩個(gè)塊的地方，可以利用消息操作來(lái)表示從一個(gè)塊到另一個(gè)塊的轉(zhuǎn)發(fā)請(qǐng)求。這種模式的一個(gè)示例是，從HistoryManager組件到TrackManager組件的消息操作purgeSensorTrack()，該操作請(qǐng)求后一個(gè)組件執(zhí)行disposeSensorTrack()?，F(xiàn)在，已將操作分配給泳道，下一步就是執(zhí)行具體的架構(gòu)設(shè)計(jì)。具體的架構(gòu)設(shè)計(jì)在進(jìn)行具體的架構(gòu)設(shè)計(jì)階段，需要重點(diǎn)關(guān)注端口和接口的定義，以及實(shí)現(xiàn)子系統(tǒng)塊基于狀態(tài)的行為。為了做到這一點(diǎn)，必須使用白盒序列圖確定所子系統(tǒng)塊的端口和接口。黑盒活動(dòng)圖的重點(diǎn)是確定不同的系統(tǒng)功能（操作）流，而白盒活動(dòng)圖的重點(diǎn)則是不同子系統(tǒng)之間的協(xié)作，同時(shí)還要考慮到操作的分配。接收到服務(wù)請(qǐng)求定義一個(gè)塊的接口。在定義了端口和接口后，必須將所產(chǎn)生的每個(gè)葉塊基于狀態(tài)的行為捕獲到某個(gè)狀態(tài)圖中。代理白盒序列圖如圖8所示。序列圖顯示一個(gè)子系統(tǒng)塊為了滿足場(chǎng)景而向另一個(gè)子系統(tǒng)塊請(qǐng)求的服務(wù)。圖8.白盒序列圖圖8.白盒序列圖圖8.白盒序列圖我們繼續(xù)使用白盒序列圖來(lái)獲得子系統(tǒng)之間的端口和接口，并獲得代理子系統(tǒng)組件基于狀態(tài)的行為，如圖9、圖10和圖11所示。圖9.MMI控制器狀態(tài)圖10.追蹤信息管理器的狀態(tài)圖圖11.白盒端口和接口結(jié)束語(yǔ)我們描述了如何通過(guò)案例研究來(lái)應(yīng)用RationalHarmony系統(tǒng)工程流程。從系統(tǒng)工程切換到后續(xù)系統(tǒng)開(kāi)發(fā)的關(guān)鍵構(gòu)件是一個(gè)可執(zhí)行基線模型。該模型是生成規(guī)范文檔和操作ICD的資料庫(kù)。切換包中包含下列項(xiàng)目：可執(zhí)行子系統(tǒng)模型的基線子系統(tǒng)已分配的操作的定義子系統(tǒng)端口和邏輯接口的定義子系統(tǒng)行為的定義，捕獲在狀態(tài)圖中測(cè)試場(chǎng)景，從系統(tǒng)級(jí)用例場(chǎng)景中獲得參考資料學(xué)習(xí)查看本系列的第2部分：為分布式系統(tǒng)的分析和設(shè)計(jì)開(kāi)發(fā)以數(shù)據(jù)為中心的流程SystemsEngineeringBestPracticeswiththeRationalSolutionforSystemsandSoftwareEngineering，作者：HansPeterHoffman；工具書版本訪問(wèn)developerWorks的Rational軟件專區(qū)，獲得RationalSoftwareDeliveryPlatform產(chǎn)品的技術(shù)資源和最佳實(shí)踐。隨時(shí)關(guān)注developerWorks技術(shù)活動(dòng)和網(wǎng)絡(luò)廣播，包括各種IBM產(chǎn)品和IT行業(yè)主題。參加developerWorksLive!技術(shù)講座，快速了解IBM產(chǎn)品和工具，以及IT行業(yè)趨勢(shì)。觀看developerWorks演示中心，其中包括面向初學(xué)者的產(chǎn)品安裝和設(shè)置演示，以及為經(jīng)驗(yàn)豐富的開(kāi)發(fā)人員準(zhǔn)備的高級(jí)功能。提高您的技能。查看Rational培訓(xùn)和認(rèn)證目錄，其中包含了許多廣泛議題的課程類型。您可以隨時(shí)隨地學(xué)習(xí)它們，許多“入門”課程是免費(fèi)的。獲得產(chǎn)品和技術(shù)下載IBMWebSphereUDDI注冊(cè)中心預(yù)覽版FAQs的Rational軟件。以最適合您的方式IBM產(chǎn)品評(píng)估試用版軟件：下載產(chǎn)品試用版，在線試用產(chǎn)品，在云環(huán)境下試用產(chǎn)品，或者在IBMSOA人員沙箱中花費(fèi)幾個(gè)小時(shí)來(lái)學(xué)習(xí)如何高效實(shí)現(xiàn)面向服務(wù)架構(gòu)。第2部分:為分布式系統(tǒng)的分析和設(shè)計(jì)開(kāi)發(fā)以數(shù)據(jù)為中心的流程分布式系統(tǒng)本身是面向數(shù)據(jù)的，它通過(guò)數(shù)據(jù)實(shí)體規(guī)定子系統(tǒng)邊界，并通過(guò)特定數(shù)據(jù)交互來(lái)定義系統(tǒng)的動(dòng)態(tài)特性。數(shù)據(jù)實(shí)體及其在分布式環(huán)境中的行為是不容忽視的。因此，通過(guò)對(duì)IBM?Rational?Harmony系統(tǒng)工程流程等典型MBSE工作流中進(jìn)行功能分析，可以推導(dǎo)出端口和接口（數(shù)據(jù)交互和屬性）的來(lái)源，在這種情況下，這種結(jié)果似乎比較奇怪。在本文中，我們將探索如何開(kāi)發(fā)適用于分布式系統(tǒng)的分析和設(shè)計(jì)的MBSE流程。MohitChoudhary,系統(tǒng)工程師,RealTimeTechSolutions2012年3月23日內(nèi)容在本系列的第1部分中，我們獲得了UAV地面控制器的系統(tǒng)設(shè)計(jì)，我們使用IBMRationalHarmony系統(tǒng)工程作為一個(gè)流程，指引我們了解子系統(tǒng)和邏輯接口。不過(guò)，分布式系統(tǒng)的設(shè)計(jì)往往以數(shù)據(jù)為中心，而數(shù)據(jù)實(shí)體在系統(tǒng)設(shè)計(jì)中又占據(jù)最重要的位置。因此，很顯然，我們只好稍微調(diào)整一下RationalHarmony系統(tǒng)工程流程，讓設(shè)計(jì)流程把重點(diǎn)放在數(shù)據(jù)實(shí)體上，同時(shí)繼續(xù)將RationalHarmony系統(tǒng)工程等成熟的MBSE流程的優(yōu)勢(shì)融入設(shè)計(jì)中。在分布式系統(tǒng)設(shè)計(jì)中，使用一個(gè)先進(jìn)的接口語(yǔ)言來(lái)定義這些數(shù)據(jù)交互是有必要的，這樣做不僅可以在整個(gè)交互過(guò)程中確保各子系統(tǒng)的一致性，還可以捕獲設(shè)置在語(yǔ)言本身中的數(shù)據(jù)的交互目的和行為。在不斷變化的接口規(guī)范語(yǔ)言中，類似的步驟是通過(guò)OMG數(shù)據(jù)分發(fā)服務(wù)(DataDistributionService,DDS)規(guī)范（參閱參考資料）實(shí)現(xiàn)。在派生的邏輯接口中的子系統(tǒng)之間彈出操作性ICD（界面控制文件）時(shí)，標(biāo)準(zhǔn)的RationalHarmony系統(tǒng)工程流程結(jié)束時(shí)的切換（參閱參考資料）已經(jīng)足夠用，但是，在利用數(shù)據(jù)分發(fā)服務(wù)(DDS)將這些邏輯接口映射到信息交換結(jié)構(gòu)時(shí)，可能并不簡(jiǎn)單。在本文中，我們將嘗試調(diào)整標(biāo)準(zhǔn)的RationalHarmony系統(tǒng)工程流程的工作流，讓它支持分布式不協(xié)調(diào)性，而不是支持RationalHarmony。首先，我們將介紹DDS規(guī)范和Problem-frameAnalysis的結(jié)構(gòu)（請(qǐng)參閱參考資料）。然后，我們遵循修改過(guò)的MBSE流程中所涉及的步驟，這些步驟及時(shí)采用了DDS，并在整個(gè)分布式系統(tǒng)的分析和設(shè)計(jì)過(guò)程中體現(xiàn)它。最后，您應(yīng)該能夠通過(guò)使用與本文第1部分中相同的案例研究來(lái)運(yùn)行這些步驟。了解DDS和問(wèn)題框架分析OMG數(shù)據(jù)分布服務(wù)(DataDistributionService,DDS)規(guī)范被劃分為兩個(gè)架構(gòu)層次。下層是以數(shù)據(jù)為中心的發(fā)布和訂閱(DataCentricPublishandSubscribe,DCPS)層，其中包含了發(fā)布和訂閱通信機(jī)制的類型安全的接口。上層是數(shù)據(jù)本地重構(gòu)層(DataLocalReconstructionLayer,DLRL)，它使應(yīng)用程序開(kāi)發(fā)人員能夠在DCPS層上構(gòu)建本地對(duì)象模型，以屏蔽應(yīng)用程序?qū)CPS的感知。本文的內(nèi)容僅限于DCPS的一些特定結(jié)構(gòu)。以數(shù)據(jù)為中心的發(fā)布和訂閱DCPS層將數(shù)據(jù)從發(fā)布者傳播到感興趣的訂閱者。它的實(shí)現(xiàn)所使用的概念是，發(fā)布者和數(shù)據(jù)編寫器和在發(fā)送端，而訂閱者和數(shù)據(jù)讀取器在接收端。DCPS層由一個(gè)或多個(gè)數(shù)據(jù)域組成，其中每個(gè)域都包含通過(guò)DDS進(jìn)行通信的發(fā)布者和訂閱者。每對(duì)發(fā)布者和訂閱者都從屬于一個(gè)域。在所有數(shù)據(jù)域中，都是根據(jù)主題來(lái)識(shí)別數(shù)據(jù)，主題是一個(gè)類型特定的域段，使發(fā)布者和訂閱者能夠明確地指定數(shù)據(jù)。在一個(gè)域中，每個(gè)主題都將惟一的主題名稱、數(shù)據(jù)類型和一組服務(wù)質(zhì)量(QoS)策略與數(shù)據(jù)相關(guān)聯(lián)。每個(gè)主題都與一個(gè)數(shù)據(jù)類型相關(guān)聯(lián)，但多個(gè)不同主題可以發(fā)布相同的數(shù)據(jù)類型。發(fā)布者的行為由與發(fā)布者、數(shù)據(jù)創(chuàng)建者和特定數(shù)據(jù)源的主題元素關(guān)聯(lián)的QoS策略決定。同樣，訂閱者的行為由與訂閱者、數(shù)據(jù)讀取器和特定數(shù)據(jù)接收器的主題元素關(guān)聯(lián)的QoS策略決定。可以在語(yǔ)言中指定并在案例研究中使用的一些QoS策略和操作，如表1和表2所示。QoS策略和操作如下所示。表1.記錄相關(guān)的DDSQoS策略QoS描述Liveliness驗(yàn)證，確保系統(tǒng)中的預(yù)期實(shí)體仍然活著Reliability確定樣本交付所需的可靠性水平。History如果實(shí)例的值在與訂閱者通信之前發(fā)生變化，

則控制對(duì)該實(shí)例的處理Lifespan避免將“過(guò)時(shí)”的數(shù)據(jù)提供給應(yīng)用程序。Deadline確定主題預(yù)計(jì)在期限內(nèi)定期更新每個(gè)實(shí)例。表2.記錄相關(guān)的DDS操作操作描述Read數(shù)據(jù)讀取器對(duì)數(shù)據(jù)值集合的訪問(wèn)。Take從數(shù)據(jù)讀取器刪除一個(gè)樣本，這樣就不能對(duì)其執(zhí)行讀或獲取操作。Waitset&

Listener使應(yīng)用程序了解DCPS通信狀態(tài)的變化。Contentfilter基于屬性篩選傳入的主題樣本。Data_Available狀態(tài)變化標(biāo)志，指示在讀取器中的數(shù)據(jù)可用性。Readwith

condition對(duì)符合在條件中所指定標(biāo)準(zhǔn)的樣本具有“讀”訪問(wèn)權(quán)限。條件可以是只讀條件或查詢條件。問(wèn)題框架分析ProblemFramesApproach（問(wèn)題框架方法）是需求分析的方法。它使您能夠?qū)⑾到y(tǒng)需求歸類為一組預(yù)定義的問(wèn)題，類似于解決方案范疇的設(shè)計(jì)模式。在將問(wèn)題歸類后，就可以通過(guò)解答與每個(gè)問(wèn)題框架相關(guān)的一套標(biāo)準(zhǔn)題目來(lái)輕松地解釋這些問(wèn)題。圖1顯示了本文如何使用該技術(shù)來(lái)記錄案例研究的構(gòu)件。圖1.通過(guò)問(wèn)題框架進(jìn)行記錄建議的工作流建議的處理工作流如圖2所示。圖2.MBSE流程的工作流在需求分析階段已定義了系統(tǒng)級(jí)用例，該流程旨在通過(guò)問(wèn)題框架分析如何為每個(gè)系統(tǒng)用例定義數(shù)據(jù)實(shí)體、屬性和操作。您可以使用這些信息問(wèn)題框架來(lái)開(kāi)發(fā)模型實(shí)體及其屬性、連接和轉(zhuǎn)換問(wèn)題框架，然后定義這些實(shí)體的行為和工件問(wèn)題框架，從而在已定義的實(shí)體上進(jìn)行開(kāi)發(fā)操作。接下來(lái)，我們需要根據(jù)在問(wèn)題框架分析階段確定的實(shí)體來(lái)定義系統(tǒng)信息模型。通過(guò)分析所產(chǎn)生的構(gòu)件是一個(gè)主題模型，它定義了已確定的DDS主題的名稱、類型和QoS。因?yàn)槲覀円延辛酥黝}模型，所以在下一階段的實(shí)體功能分析中，將重點(diǎn)介紹如何圍繞已確定主題模型實(shí)體的生命周期操作來(lái)執(zhí)行功能分析。您可以使用黑盒活動(dòng)圖來(lái)捕獲每個(gè)已確定實(shí)體的生命周期并行流。此外，您必須通過(guò)組合一個(gè)或多個(gè)流來(lái)建立與序列圖一致的真正功能流，從而生成黑盒用例場(chǎng)景?？梢允褂眯蛄猩捎美龎K的端口和接口。然后捕獲用例的基于狀態(tài)的行為，驗(yàn)證所生成的序列圖，并將它們與黑盒場(chǎng)景序列圖進(jìn)行比較。設(shè)計(jì)合成從執(zhí)行系統(tǒng)結(jié)構(gòu)分解開(kāi)始，其依據(jù)不僅是關(guān)鍵功能，還有模型實(shí)體本身。在下一步中，在描述白盒活動(dòng)圖的同時(shí)，還需要將DDS-Data-space作為其中一個(gè)子系統(tǒng)組件包含在內(nèi)，以修補(bǔ)獨(dú)立的功能流。先將DDS-Data-space定義為一個(gè)子系統(tǒng)組件，然后使白盒狀態(tài)機(jī)作為一個(gè)可執(zhí)行模型來(lái)運(yùn)行，同時(shí)保留在使用DDS過(guò)程中所要求的時(shí)間和空間的分離?，F(xiàn)在，通過(guò)比較我們?cè)谶@里生成的序列圖與白盒場(chǎng)景所產(chǎn)生的序列圖，可以驗(yàn)證這個(gè)可執(zhí)行模型。最后，您需要生成系統(tǒng)內(nèi)部結(jié)構(gòu)框圖(IBD)，它將產(chǎn)生白盒端口和接口。毫不奇怪，在本例中的接口與信息模型中的主題是一一對(duì)應(yīng)的，這些主題已經(jīng)充分定義了屬性及其行為。問(wèn)題框架分析該分析的范圍由PerformAreaSearch用例定義，它檢測(cè)飛行中的UAV，將搜索區(qū)域分配給UAV，從傳感器獲取追蹤信息數(shù)據(jù)，并將該信息存儲(chǔ)在信息模型中。所執(zhí)行的分析如表3和表4所示。表3.信息和連接問(wèn)題框架分析實(shí)體屬性和描述UAVInfo：無(wú)人駕駛飛機(jī)。真實(shí)世界：對(duì)飛行中的無(wú)人機(jī)的特點(diǎn)進(jìn)行建模對(duì)象UAV在信息模型中，對(duì)象的事件和反應(yīng)無(wú)法聯(lián)系UAV在限期內(nèi)沒(méi)有提供UAV位置更新。丟失的更新都將丟失。屬性IdentificationVehicleid（飛機(jī)id），由UAV發(fā)送沒(méi)有其他身份屬性，沒(méi)有系統(tǒng)生成的IDTimeinformation（時(shí)間信息）Updatetime（更新時(shí)間）–是時(shí)間和位置更新的信息Availableflighttime（可用飛行時(shí)間）–是在飛行中剩余時(shí)間的信息UAVstate（UAV狀態(tài)）Searchassigned（已分配的搜索）Searchunassigned（未分配的搜索）Sensorinformation（傳感器信息）可用傳感器及其屬性的清單Ownvehicledata（自己的飛機(jī)數(shù)據(jù)）Positiondata（位置數(shù)據(jù)）Motiondata（移動(dòng)數(shù)據(jù)）數(shù)據(jù)沒(méi)有更新歷史。只有瞬時(shí)值。Sensor（傳感器）：由UAV用于檢測(cè)追蹤信息。傳感器類型SARFLIROPTICAL傳感器屬性Sensorstarttime（傳感器啟動(dòng)時(shí)間）–用于確定傳感器是否活動(dòng)。State（狀態(tài)）Active（活動(dòng)）Inactive（不活動(dòng)）Sensortracks（傳感器追蹤信息）：一組來(lái)自特定目標(biāo)的測(cè)量值，可以使用它們來(lái)計(jì)算目標(biāo)的位置和運(yùn)動(dòng)。追蹤信息作為獨(dú)立信息結(jié)構(gòu)存在，除非在針對(duì)該追蹤信息而給出的樣本中沒(méi)有提供追蹤信息級(jí)別所需的其他數(shù)據(jù)。真實(shí)世界：對(duì)傳感器發(fā)出的傳感器追蹤信息進(jìn)行建模。對(duì)象由傳感器檢測(cè)到發(fā)射器/觸點(diǎn)由傳感器發(fā)送的測(cè)量值。有一個(gè)與測(cè)量值相關(guān)的周期。在信息模型中，對(duì)象的事件和反應(yīng)無(wú)法聯(lián)系傳感器在限期內(nèi)無(wú)法提供追蹤信息測(cè)量值。丟失的追蹤信息測(cè)量值都將丟失，從我們?cè)俅潍@得連接開(kāi)始，傳感器追蹤信息繼續(xù)發(fā)送測(cè)量值。傳感器無(wú)法再獲得追蹤信息-在限期內(nèi)無(wú)法提供追蹤信息測(cè)量值。傳感器重新獲得追蹤信息-追蹤信息測(cè)量值再次可用。傳感器無(wú)法獲得追蹤信息與無(wú)法聯(lián)系傳感器之間的區(qū)別？傳感器活動(dòng)狀態(tài)的可用性屬性Identification（身份）ID，由外部傳感器發(fā)送–由以下屬性組成SensorID（傳感器ID）Track-ID（追蹤信息ID），數(shù)字1至50。沒(méi)有其他身份屬性，沒(méi)有系統(tǒng)生成的IDTimeinformation（時(shí)間信息）-<用每次轉(zhuǎn)換時(shí)的時(shí)間戳存儲(chǔ)每個(gè)狀態(tài)轉(zhuǎn)換的歷史記錄。>Createdtime（創(chuàng)建時(shí)間）–是來(lái)自傳感器測(cè)量時(shí)間的信息，指追蹤信息的第一次測(cè)量時(shí)間。Trackage（追蹤時(shí)間長(zhǎng)度）-是自上次測(cè)量值更新所經(jīng)過(guò)的時(shí)間。Trackstate（追蹤狀態(tài)）-取決于相關(guān)測(cè)量值的期限標(biāo)志Active（活動(dòng)）Lost（丟失）Sourcesensor（源傳感器）–來(lái)自任何測(cè)量值的傳感器ID，通常根據(jù)第一個(gè)樣本進(jìn)行設(shè)置數(shù)據(jù)由一個(gè)或多個(gè)追蹤信息測(cè)量值組成存儲(chǔ)超過(guò)30分鐘窗口的測(cè)量值歷史清除早于該時(shí)間段的測(cè)量值？傳感器特定的屬性這些屬性的基本信息：幾乎所有這些數(shù)據(jù)都直接從傳入的傳感器數(shù)據(jù)中取出，并用于向用戶顯示。4.SensorTrackMeasures（傳感器追蹤信息測(cè)量值）真實(shí)世界：對(duì)傳感器發(fā)送的單一數(shù)據(jù)樣本進(jìn)行建模屬性Identification（身份）–由傳感器發(fā)送SensorID（傳感器ID）TrackID（追蹤信息ID）–由傳感器發(fā)送MeasureID（測(cè)量值ID）-序列號(hào)Timeofthesample（采樣的時(shí)間）–由傳感器發(fā)送，必須保存有效或無(wú)效的數(shù)據(jù)（好/壞/延遲）-需要根據(jù)數(shù)據(jù)范圍驗(yàn)證來(lái)轉(zhuǎn)換，即基于傳感器進(jìn)行轉(zhuǎn)換。系統(tǒng)會(huì)拒絕無(wú)效的測(cè)量值。Data（數(shù)據(jù)）–一個(gè)樣本可以包含一個(gè)或多個(gè)以下屬性：Position（位置）–Latitude（緯度）和Longitude（經(jīng)度）Projectionused（使用的投影）Speed（速度）特征傳感器以1Hz的頻率發(fā)送TrackMeasures（追蹤信息測(cè)量值）表4.工件問(wèn)題框架分析實(shí)體分析Staticinformation（靜態(tài)信息）有否任何靜態(tài)信息與傳感器追蹤信息相關(guān)？傳感器的特性來(lái)自傳感器的表示錯(cuò)誤等信息的RMS值，一般是一個(gè)表，在系統(tǒng)中用于計(jì)算工件出問(wèn)題時(shí)的SensorTracks（傳感器追蹤信息）<在已實(shí)現(xiàn)的實(shí)體上的操作>操作員驅(qū)動(dòng)的操作創(chuàng)建從傳感器測(cè)量值直接創(chuàng)建從上次測(cè)量值更新計(jì)算的TrackAge（追蹤時(shí)間長(zhǎng)度）用于獲取追蹤信息ID的FirstMeasure（首次測(cè)量）選擇一個(gè)要轉(zhuǎn)換為系統(tǒng)追蹤信息的傳感器追蹤信息生命周期相關(guān)的操作根據(jù)追蹤信息新的可用更新（測(cè)量值）更新傳感器追蹤信息自動(dòng)清除在30分鐘歷史記錄內(nèi)沒(méi)有任何測(cè)量值的傳感器追蹤信息。歸檔無(wú)需求工件出問(wèn)題時(shí)的SensorTrackMeasures（傳感器追蹤信息測(cè)量值）操作員驅(qū)動(dòng)的操作無(wú)–由傳感器擁有生命周期相關(guān)的操作顯示錯(cuò)過(guò)期限的更新自動(dòng)清除超過(guò)30分鐘歷史的測(cè)量值。歸檔無(wú)需求信息模型分析在這一步中，您需要使用前一階段的信息和連接問(wèn)題框架分析來(lái)執(zhí)行信息模型分析。這一階段的目標(biāo)是，確定代表數(shù)據(jù)實(shí)體及其行為的DDS主題。所有這些主題共同構(gòu)成DDS環(huán)境中的交互單元，其行為的正確表示可以大大減輕子系統(tǒng)在維護(hù)和通用管理方面的責(zé)任。案例研究的一個(gè)有代表性的信息模型子集如圖2所示。在為主題“SensorTrackMeasure”定義的行為中，可以看到這種責(zé)任減少的示例。在這個(gè)主題上定義的鍵描述（其值構(gòu)成鍵的數(shù)據(jù)字段列表）是一種復(fù)合結(jié)構(gòu)，由SensorID和TrackID組成。具有相同鍵值的不同數(shù)據(jù)值代表相同實(shí)例的連續(xù)值，而具有不同鍵值的不同數(shù)據(jù)值則代表不同的實(shí)例。此外，主題的HistoryQosPolicy被定義為KEEP_ALL，其深度為1800，這表示在數(shù)據(jù)空間中為每個(gè)這樣的實(shí)例最多保存1800個(gè)樣本（按照@1Hz的頻率更新30分鐘時(shí)間）。最后，持續(xù)時(shí)間對(duì)應(yīng)為30分鐘的LifespanQosPolicy指定數(shù)據(jù)樣本在DDS空間的最長(zhǎng)有效時(shí)間，這段時(shí)間過(guò)去后，系統(tǒng)會(huì)自動(dòng)處理該樣本。有關(guān)SensorTrackMeasure實(shí)體這種行為的定義，明確地定義了DDS服務(wù)接管實(shí)體的歷史管理責(zé)任。現(xiàn)在，在用例中對(duì)該功能進(jìn)行建模會(huì)是重復(fù)操作。圖3.主題模型表示主題名稱（描述）主題定義QoS策略QoS理論值<<UC01_04Sensortrackmeasure>>本主題將發(fā)布傳感器追蹤信息測(cè)量值信息structidendity

{

unsignedlongulsensorID;

unsignedlongultrackID;

};

typedefunsignedlongmeasure_ID;

structSensorTrackMeasure

{

IdentityulSourceID;//ownerofmeassage

measure_IDulSeq_no;

unsignedlongullSystemTimemilliSecs;//currenttimeinmilliseconds

floatfLatitudeDeg;//latitude

floatfLongitudeDeg;//Longitude

doubledXSpeedMtrs;//Xcoordinate

doubledYSpeedMtrs;//Ycoordinate

};

#pragmakeylistSensorTrackMeasureulSourseIDDeadline1secDestinationorderBY_SOURCE_TIMESTAMPDurabilityVolatileHistoryKEEP_ALLHistorydepth30Lifespan1800000msLivelinessAUTOMATICLatencybudget30msOwnershipSHAREDReliabilityBEST_EFFORTResourcelimitDefault

max_samples,

max_instances,

max_samples_per_instance(allsettoLENGTH_UNLIMITED)Transportpriority1DurabilityserviceDefault備注：圖2中有代表性的主題模型描述了與主題“SensorTrackMeasure”相關(guān)的名稱、類型和QoS策略。我們使用一個(gè)類似的練習(xí)在用例的其余部分中描述以下主題：UAVInfoSensorTrackSensorTrackMeasureCommand這里需要重點(diǎn)注意的是，并非所有在問(wèn)題框架分析階段中確定的模型實(shí)體都與主題模型存在一一對(duì)應(yīng)關(guān)系。實(shí)體功能分析實(shí)體功能分析階段的輸入是主題模型和工件問(wèn)題框架分析模型。這個(gè)階段的重點(diǎn)是圍繞已確定主題的生命周期操作來(lái)執(zhí)行功能分析。在此步驟中產(chǎn)生的構(gòu)件是用例的黑盒活動(dòng)圖、場(chǎng)景和狀態(tài)圖。用例的黑盒活動(dòng)圖如圖4所示，而有代表性的場(chǎng)景和狀態(tài)圖分別如圖5和圖6所示。黑盒活動(dòng)圖表示基于read、write、content_filter或read_with_query_condition等DDS結(jié)構(gòu)的操作。這些結(jié)構(gòu)是簡(jiǎn)化功能流的一種途徑?？梢詫⑦@樣的綁定帶入活動(dòng)流程，這被認(rèn)為是通過(guò)使用DDS實(shí)現(xiàn)功能效率的必要條件。另一方面，可以創(chuàng)建黑盒場(chǎng)景，用它們代表現(xiàn)實(shí)世界的場(chǎng)景，將所產(chǎn)生的流的不同序列引入到代表該場(chǎng)景的主序列中。為了確保能夠滿足需求分析階段所了解的需求，這一步非常重要。反過(guò)來(lái)，這將有助于我們對(duì)詳細(xì)主題及圍繞這些主題的操作進(jìn)行效能分析。如果出現(xiàn)不匹配的情況，則有必要回頭修改信息模型，直到實(shí)現(xiàn)所需的現(xiàn)實(shí)世界功能序列。此外，獲得用例的狀態(tài)機(jī)也很簡(jiǎn)單。用例的狀態(tài)機(jī)由多個(gè)'AND'狀態(tài)組成，每個(gè)AND狀態(tài)分別代表活動(dòng)圖中的獨(dú)立功能流的狀態(tài)行為。雖然每個(gè)流都由一個(gè)AND狀態(tài)表示，并因此可以獨(dú)立執(zhí)行，但這些流都通過(guò)從一個(gè)AND狀態(tài)到其他等待子狀態(tài)的事件流被捆綁在一起，以便支持作為一個(gè)整體狀態(tài)機(jī)來(lái)執(zhí)行。通過(guò)模型執(zhí)行，參照之前生成的黑盒場(chǎng)景來(lái)驗(yàn)證自動(dòng)生成的序列，這樣做是有必要的。圖4.黑盒活動(dòng)圖（面向數(shù)據(jù)）圖5.黑盒場(chǎng)景（面向數(shù)據(jù)）圖6.黑盒狀態(tài)圖（面向數(shù)據(jù)）設(shè)計(jì)合成在這種方法中的系統(tǒng)結(jié)構(gòu)分解不僅基于關(guān)鍵系統(tǒng)功能的識(shí)別，還基于已獲得的主題模型。此外，白盒活動(dòng)圖的功能分配的執(zhí)行通過(guò)將黑盒活動(dòng)圖的完整流獨(dú)立分配到一個(gè)泳道來(lái)完成。這種分配是可以實(shí)現(xiàn)的，因?yàn)橥ㄟ^(guò)DDS全球數(shù)據(jù)空間可以跨子系統(tǒng)邊界訪問(wèn)所獲得的主題實(shí)例和樣本。為用例所生成的白盒活動(dòng)圖如圖7所示。分配給代表DDS數(shù)據(jù)空間的泳道的功能，是通過(guò)發(fā)布/訂閱模式將其余組件拼接在一起的功能。為了使子系統(tǒng)在模型級(jí)別共同參與現(xiàn)實(shí)世界的場(chǎng)景，并且使可執(zhí)行白盒狀態(tài)機(jī)生效，這種表示方式被認(rèn)為是必要的。該流程的下一步是發(fā)展用例的白盒場(chǎng)景，代表黑盒子場(chǎng)景的白盒視圖。有代表性的白盒場(chǎng)景如圖8所示。最后，我們從白盒場(chǎng)景推導(dǎo)出端口和接口，并實(shí)現(xiàn)子系統(tǒng)組件的白盒狀態(tài)行為，以準(zhǔn)備切換。有代表性的子系統(tǒng)的狀態(tài)行為以及白盒端口和接口分別如圖9和圖10所示。本例中的子系統(tǒng)狀態(tài)圖使用與相應(yīng)黑盒狀態(tài)圖完全相同的模式。兩者之間僅有的區(qū)別是從子系統(tǒng)等待狀態(tài)過(guò)渡的觸發(fā)事件，這些事件由組件DDS-Data-space產(chǎn)生。DDS-Data-space的狀態(tài)機(jī)是一種模擬表示形式，用于支持不同分離組件的執(zhí)行。立即執(zhí)行白盒狀態(tài)機(jī)，以便比較生成的序列圖與白盒場(chǎng)景，從而針對(duì)切換確定模型的基線。最后，明確映射到主題模型的子系統(tǒng)接口是根據(jù)確定基線的模型生成的，如表5所示。圖7.白盒活動(dòng)圖（面向數(shù)據(jù)）圖8.白盒序列圖（面向數(shù)據(jù)）圖9.白盒狀態(tài)行為（面向數(shù)據(jù)）圖10.白盒端口和接口（面向數(shù)據(jù)）表5.白盒接口列表塊端口名稱I/F類型接口事件主題名稱/描述MMIControllerpOperatorProvidedreqSelectUAVOperatorselectionthroughh/winterruptreqAbortSearchOperatorselectionthroughh/winterruptreqSelectSearchAreaOperatorselectionthroughh/winterruptreqExecuteSearchOperatorselectionthroughh/winterruptpDDSDataSpaceRequiredreqPublishCommandCommandTopicSensorTrackManagerpDDSDataSpaceProvidedreqOnDataAvailableSensorTrackMeasureTopicRequiredreqPublishSensorTrackSensorTrackTopicUAVBridgepDDSDataSpaceProvidedreqOnDataAvailableCommandTopicRequiredreqPublishUAVInfoUAVInfoTopicreqPublishSensorTrackMeasureSensorTrackMeasureTopicpUAVProvidedreqRecieveUAVInfoUAVInfomessageonUAVlinkreqRecieveSensorTrackMeasureSensorTrackMeasuremsgonUAVlinkRequiredevSendCommandCommandmessageonUAVlinkDisplayControllerpDDSDataSpaceProvidedreqOnDataAvailableSensorTrackTopicreqOnDataAvailableUAVInfoTopicpDisplayRequiredevUpdateDisplayInterfaceondisplaylinkDDSDataSpacepMMIControllerProvidedreqPublishCommandCommandTopicpUAVBridgeProvidedreqPublishUAVInfoUAVInfoTopicreqPublishSensorTrackMeasureSensorTrackMeasureTopicRequiredreqOnDataAvailableCommandTopicpDisplayControllerRequiredreqOnDataAvailableSensorTrackTopicreqOnDataAvailableUAVInfoTopicpSensorTrackManagerProvidedreqPublishSensorTrackSensorTrackTopicRequiredreqOnDataAvailableSensorTrackMeasureTopic結(jié)束語(yǔ)在把基于分布式組件的系統(tǒng)架構(gòu)放在一起時(shí)，主要需要考慮的事項(xiàng)是，能夠明確界定業(yè)務(wù)功能及其跨子系統(tǒng)的接口。如果系統(tǒng)遵循下面這些面向服務(wù)的架構(gòu)的OpenArchitecture原則（請(qǐng)參閱參考資料），那么我們完全可以解決上述這些問(wèn)題：模塊化：這意味著，架構(gòu)已仔細(xì)劃分業(yè)務(wù)和技術(shù)功能，使用戶能夠單獨(dú)訪問(wèn)它們，并在狀態(tài)之間保持最少量的交互需求。在分布式系統(tǒng)的設(shè)計(jì)中使用發(fā)布和訂閱模式，這從本質(zhì)上促進(jìn)了子系統(tǒng)設(shè)計(jì)的無(wú)狀態(tài)性質(zhì)的使用。從本文的案例研究中，顯然可以得出以下結(jié)論：每個(gè)獨(dú)立的活動(dòng)流應(yīng)當(dāng)代表組件的一個(gè)AND狀態(tài)，而每個(gè)AND狀態(tài)中惟一的主導(dǎo)狀態(tài)是每個(gè)流的等待狀態(tài)。行為主要是無(wú)狀態(tài)的，因此，已定義實(shí)體的創(chuàng)建或更新本身就是通過(guò)寫操作暴露給系統(tǒng)的其余部分，并且從不保存。這樣的設(shè)計(jì)自然地呈現(xiàn)模塊化系統(tǒng)的屬性，即在狀態(tài)之間保持最少交互。開(kāi)放式標(biāo)準(zhǔn)：使用開(kāi)放式標(biāo)準(zhǔn)對(duì)分布式系統(tǒng)的設(shè)計(jì)造成的最大影響最大是，這些標(biāo)準(zhǔn)必須在何處完成服務(wù)描述、發(fā)現(xiàn)和功能訪問(wèn)。SysML是基于開(kāi)放式標(biāo)準(zhǔn)的建模語(yǔ)言，所以也是DDS規(guī)范。SysML是用于明確定義系統(tǒng)或子系統(tǒng)功能的語(yǔ)言。而DDS是用于明確定義子系統(tǒng)接口的語(yǔ)言，它也在其自身中封裝了發(fā)現(xiàn)和訪問(wèn)機(jī)制?；ゲ僮?/p>