基于對象過程方法論的體系需求分析方法

任天助，辛萬青，嚴晞雋，吳雄清

（1. 北京宇航系統工程研究所，北京，100076；2. 中國運載火箭技術研究院，北京，100076）

0 引 言

體系需求分析是體系工程的基本活動之一，一般認為是開展體系設計的預先過程。體系相比一般的系統而言組成要素更多，更加關注整體的能力而非單一系統性能，使得需求分析更加復雜。國內外對于體系需求分析問題開展了很多研究，其中DoDAF多視圖的架構建模方法是目前國內外最流行的體系需求設計框架，并在其基礎上發展出面向基于MBSE的UPDM、UAF描述框架，以UML/SySML建模語言實現了對體系需求的規范化、模型化描述。盡管其建模的具體步驟只有幾步，但12大項百余條小項的龐大術語集要求架構設計人員對DoDAF冗雜的建模范式有深刻理解。而UAF、UPDM這兩者都采用UML/SySML建模語言，同樣也增加了建模的門檻。更關鍵的是這類方法以既定的概念作為輸入，但是沒有明確給出概念的產生過程，也不對能力的產生機制進行解釋。換言之，DoDAF這類需求分析模型更多是采用逆向工程的方法，將已經在文檔中甚至是大腦中建立好的體系概念用一套完善的架構模板表示出來。然而在設計之初，需求提出方與體系架構師往往只有大致的目標實現流程和可能適合的組成系統方案，需要正向地去確定體系應該具備的能力以及如何組織體系的組成系統去實現所有目標。這種方法的欠缺使得長期以來各類體系架構并沒有在體系工程中起到預期作用。因此，體系需求設計方法不應該只是看重最后的結果形式，而是能夠依照一定步驟，構成體系概念、分析體系具備的能力、開展需求分析的綜合方法論。

除了采用基于DoDAF及其衍生框架的體系需求分析方法之外，一些學者也嘗試構建其他形式的體系需求分析建模方法。孫長龍[1]將作戰體系的概念定義為使命任務、平臺單元或設施和信息網絡的三元組，通過信息鏈對防空作戰體系開展能力分析。Teddy Bouziat[2]則從多Agent建模的角度，將體系定義為組成系統和使命目標的二元組，并將組成系統以獨立Agent的形式開展需求的分析。Eduardo Silva[3]提出了一種名為mKAO的描述體系概念的語言，以任務為線索串起整個體系的需求分析與開發流程。這些方法有一個共同的思路，旨在以多元組的形式給出體系概念建模的模板，結合網絡、解析、仿真等手段對體系的任務過程與能力需求開展分析。但這些方法由于沒有形成具有通用性的建模語言與方法，導致應用只集中在特定領域，沒有形成廣泛的影響力。

本文試圖以簡潔高效的OPM語言建立體系概念模型，形成具有可操作性的需求概念獲取方法。并將OPM概念模型融合到聯合能力開發（Joint Capabilities Integration and Development System，JCIDS）流程中作為概念支撐，結合OPM語言特點對JCIDS中的能力分析過程進行改進，形成對體系能力需求的分析。以目標實現通路為藍本，逐漸豐富體系的概念。并在每條回路中分析物質、信息的流向，得出體系的任務-能力生成機制。最后以海上救援體系為案例，驗證了該方法的有效性。

1 系統建模語言OPM

以色列系統科學家Dori[4]提出了對象過程方法論（Object-process Methodology），以對象和過程這兩個最基礎的概念，建立了一種簡潔而強大的系統建模范式，被公認學習難度遠低于UML與SySML，是被國際系統工程委員會（International Council on Systems Engineering，INCOSE）官方認證的MBSE方法之一。該方法被廣泛應用在從分子生物學到航天推進系統的復雜性建模研究中。國內外學者均對OPM語言及其建模方法有許多工程應用，包括周波[5]、李紫漠[6]、黃其旺[7]等。由于篇幅有限，下面僅對這種語言的部分建模機制做簡要的介紹。

1.1 OPM語言的基本要素

OPM語言的基本建模要素分為實體和連接關系兩類。實體是 OPM 系統建模的基本模塊，連接關系則是表示實體之間的相關性。對象（Object）、過程（Process）和狀態（State）是OPM的3種基本實體，其中對象負責描述系統的物理和信息，狀態則是對象所處的狀況，而過程則負責描述對象的生成、消耗以及對象自身狀態的遷移轉變。

實體之間的連接關系分為靜態的結構性連接關系和動態的過程性連接關系兩大類。4種基礎性的結構連接為：整體-部分，展示-特征，一般-特殊，類型-實例連接。過程連接包括表示過程產生對象、消耗對象、改變對象狀態的變換連接，表示對象中人對過程主導關系、工具對過程支撐關系的支持連接和表示事件的觸發與調用的事件連接。

1.2 OPM語言的特點

SysML語言是目前應用最廣泛的系統架構建模語言，這里將OPM語言與SysML建模語言進行比較，以此說明一下OPM語言的特點，如表1所示。SysML語言的建模方式來源于軟件編程領域的面向對象范式，主要突出對象本身，過程是對象的一種依附物。而OPM采用的是基于最小本體理論，以對象-過程作為描述系統結構、功能和行為的二元組。過程不再是面向對象范式中依附于對象的“二等公民”，而是作為變換對象狀態、產生與消耗對象的基本實體，與對象同等重要。這對于體系問題來說是一個得天獨厚的優勢，因為體系中的過程往往是多個組成系統協同參與的，依附單獨的任意一個系統都難以表示體系在實現目標過程的全貌。而且OPM中多層次而非多視圖的表現形式對復雜系統建模問題而言更有助于從整體去構建各組成系統之間的關系。對于關鍵系統可以根據需要在統一視圖的基礎上進一步添加顆粒度，對特定的過程和對象進行“展開”。此外，OPM的建模規則和元素要明顯少于SysML語言，這樣能夠降低系統建模人員學習語言的難度，讓各個領域的系統工程師能夠專注于需求分析與架構設計，而非對建模語言語法的深究。

表1 OPM語言與SysML語言的比較 Tab.1 Comparison between OPM and SysML

2 基于OPM的體系概念生成方法

2.1 基于OPM的體系概念模型

圖1是利用OPM的基本語言對體系概念定義，其思路在于將體系按照過程-對象的二元理論定義為任務和系統的二元組。體系的組成系統之間以功能過程為紐帶相聯系，并通過參與任務改變目標的狀態，實現體系的目標。任務由功能過程組成，組成系統通過執行功能過程或是影響其他系統狀態使之處于相應的能力狀態，以此實現的任務目標。

圖1 基于OPM的體系概念組成 Fig.1 System of Systems Concept Composition based on OPM

2.2 體系概念的分析設計流程

結合OPM語言的特點，這里將體系概念的分析設計流程分為以下3個步驟：

a）構建體系概念中目標的實現流程。

在體系概念設計的最開始階段，與體系的利益相關者溝通一同梳理體系的目標，獲取初始的需求。在開始階段，需求往往是模糊與片段化的，如果存在多個利益相關者他們的需求可能還存在沖突，因此需要對各個利益相關者的需求進行梳理，明確體系的使命目標和體系實現目標的大致流程步驟。并在流程步驟中，為各項主要活動分配所依賴的對象或所要影響的對象，實現的OPM模型如圖2所示。這里需要說明的是，本文中的“活動”對應對象-過程方法論中的“過程”，而“系統”則對應“對象”。

圖2 構建目標的實現流程 Fig.2 Building the Realization Process of Goals

b）構建系統-活動解決方案組合。

在a步驟中，只確定了體系實現目標的基本流程，而不涉及體系選用何種具體的解決方案。這里將解決方案定義為系統-活動的組合，即利用“何種對象”以“什么樣的方式”實現，是對上一步驟的特征化。

這一步驟，在相關技術專家的指導下，對每個活動考慮各種可能的實現方式進行枚舉。各個實現方式里，在OPM模型中將同一類系統進行具體化，并為每個系統分配其所要執行的活動，將解決方案帶入到下一步的設計中，該步驟如圖3所示。

圖3 系統-活動解決方案組合 Fig.3 System-activity Solution Composition

c）為體系的關鍵系統設計狀態，并對體系概念進行邏輯驗證。

體系架構師根據各系統特質，對系統類型進行細分，定義系統的各自狀態，并與流程中的活動相關聯，描述各個流程的轉換關系。同時利用OPM語言的優勢，對體系所有組成系統的交互關系開展邏輯驗證。

至此，一個OPM概念模型已經基本形成，但還不是一個完整的體系需求模型。這是因為體系除了組成系統及其之間的作用關系之外，還有一個重要的抽象概念：能力。在許多體系研究者眼中，能力是體系的靈魂。可以說體系需求設計就是一個能力獲取的流程。但是目前的步驟只形成了體系的需求藍圖，依然沒有對體系需求開展詳細分析，還不能對后續體系設計與開發形成有效的指導。因此，本文將OPM建模方法與JCIDS能力需求分析流程相結合，形成一套能夠簡潔高效、并具有較高可操作性的體系需求分析方法。

3 結合JCIDS的OPM體系能力需求分析

3.1 JCIDS能力需求生成步驟

聯合能力集成與開發系統是美軍為完成聯合作戰任務、實現聯合作戰目標創建的一種作戰需求生成系統。其結果用于指導裝備采辦階段中完成裝備的設計與選型。其流程大致包括以下5個步驟：

a）國防部戰略指南：自頂向下給出體系需求的原則和依據。

b）聯合作戰概念：形成描述裝備作戰形式的藍圖。

c）功能域分析（Functional Area Analysis，FAA）：輸出需求的任務、條件、標準。

d）功能需求分析（Functional Needs Analysis，FNA）：比較和確認能力現狀和存在的差距。

e）功能解決方案分析（Functional Solutions Analysis，FSA）：針對能力差距需求尋求功能解決方案。

JCIDS中具備可操作性的需求分析步驟和對能力差距的分析，能夠提高體系架構設計人員對需求的把控力，為體系架構設計提供充分的依據。在這套方法論中，聯合作戰概念的建立起到了承上啟下的作用，即承接戰略目標的要求，通過對概念中任務-能力的分析建立一體化的體系架構。

對于更一般的非軍事體系，本文中將OPM概念模型替換JCIDS中的聯合作戰概念，用于承接利益相關者要實現的目標，并對功能域分析和功能需求分析步驟進行適應性改進。

3.2 面向目標實現通路內的流程組合確定任務及其條件

在原有OPM概念模型建立基礎上，為了實現JCIDS中對能力的需求分析，需要對原有的流程進行重新劃分。在建立OPM模型中，一開始的活動只是粗略地勾勒了實現目標的藍圖。而后建立的活動又都是相對碎片化的，不能夠反映體系能力特征。因此本文提出了目標實現通路的概念，即在OPM概念模型的基礎上，分析體系內物質、信息的流轉關系。以目標相關物質轉移、目標相關信息傳遞的鏈條構成以系統實體為節點，流轉關系活動為邊的體系要素網絡。并以流轉的信息、物質的不同從中劃分出不同的系統-活動組合，將其稱之為目標實現通路。將該通路內的活動聚合，提煉該回路內要實現的目標，并列舉影響目標實現的任務條件，梳理不同條件對目標實現回路走向的影響。

3.3 從評估角度定義能力并制定評價標準

從需求分析的角度來講，評估體系是否能夠滿足要求需要一個載體，對不同利益相關者的需求實現情況，不同任務的滿足情況，都能由這個載體來度量。在體系工程中，這個度量就是體系能力。許多文獻中能力都是由利益相關者直接給出的，但是在實際情況中，需求提出方更多情況下只能說明一些概念，難以說明體系具體需要哪些能力，也無法建立能力與任務的關系。考慮能力是為了評估體系而存在的，本文在體系層面提煉不同任務中的評估指標聚合，對共通性的效能指標進行整合，歸納出體系的能力。這種方法解決了能力需求提出的問題，便于需求提出方和架構設計方快速形成能力清單，開展后續評估工作，而非在體系能力流程的組成上遲遲難以達成共識。并將由任務到能力的分析流程中，評估指標這一中間流程固化下來，形成評估指標生成表。

3.4 評估當前解決方案對體系需求的滿足程度

在OPM模型的基礎上，建立基于系統-活動的解決方案和體系能力的關系。結合解決方案的技術特性和需求方的要求，按照任務-能力指標生成表評估當前體系概念模型內各種解決方案的能力水平，分析與需求期望能力水平的差距。

4 海上救援體系應用案例

海上救援體系被認為是典型的體系問題，被許多體系研究者用于驗證相關方法。本文結合相關文獻[8,9]，以天基信息支持下的海上救援體系作為應用案例，驗證前文的體系需求分析方法的有效性。

4.1 海上救援體系OPM概念模型建立流程

對于海上救援體系，其使命目標比較明確，就是為了在海上救援遇險人員和遇險船只。其主要的利益相關者包括政府海洋監測部門、救援執行部門以及海上作業人員、游客等可能在海上需要救援的人員。對于海洋監測部門來說，需求是能在各種條件下盡可能快地發現海上遇險人員。對于救援部門來說，在有限的成本下建立快速反應的海上救援力量。對于海上遇險人員來說，則是能夠使用有效的報警裝置讓救援力量發現自己，并盡可能長時間地在救援力量到達前保障自身安全。由利益相關者的描述我們可以梳理出海上救援體系大致流程為：由救遇險員進行報警，定位系統對遇險人員進行定位，通信系統將遇險定位信息上報到指揮節點，指揮節點分配救援力量前往遇險位置開展救援。因此，以OPM語言繪制海上救援體系的目標實現流程如圖4所示。

圖4 海上救援體系目標實現流程 Fig.4 Target Realization Process of Maritime Rescue SoS

對這6個活動匹配系統-活動功能解決方案，得到如圖5所示的系統-活動解決方案組合。海上救援體系中，傳統的定位解決方案是采用多顆低軌救援衛星進行雙星或三星定位，然后利用靜止軌道上的衛星對定位信息向地面站轉發。但是低軌衛星的軌道覆蓋做不到實時定位，定位延遲有時會達數個小時。因此后續又有采取以中軌衛星定位，靜止軌道衛星進行轉發的解決方案。隨著北斗、格洛納斯等新型中軌星座的普及，不僅可以不依賴傳統的靜止軌道衛星轉發信息，直接依靠中軌星座進行通信，并且由傳統的由遇險方到救援方的單向通信提升為雙向通信，依靠諸如北斗短報文的通信模式能夠將救援信息反饋給救援者，大大提升了搜救的通信水平與遇險者的獲救信心。但是，目前諸如北斗的中軌衛星救援系統只能實現小范圍區域的覆蓋，傳統的高低救援衛星組合的覆蓋范圍要遠遠超過中軌衛星。因此，圖中的體系概念包括了多種衛星類型的解決方案。

圖5 海上救援體系解決方案組合 Fig.5 Maritime Rescue SoS Solution Portfolio

接下來對體系的系統-活動組合進一步細化，明確系統種類。如圖6所示，將聯結多個要素的關鍵系統，如中軌救援衛星、衛星地面終端等添加狀態，并對整個體系的運行機制進行邏輯驗證。至此，海上救援體系的OPM概念模型基本完成。

圖6 海上救援體系概念與可執行邏輯驗證 Fig.6 Validation of Concept and Executable Logic of Marine Rescue SoS

4.2 海上救援體系目標實現回路分析

按照前文提出的方法，將體系內系統的活動簡化為邊，系統為節點，得到海上救援體系的要素關系網絡，如圖7所示。根據上述要素關系網絡，進行分析發現海上救援體系的目標實現主要體現在遇險信息的流轉、救援反饋信息的流轉和救援力量的實體位置的轉移。由此得出主要有如下的4條目標實現回路：第1，遇險定位信息的生成回路，即從遇險人員發出請求，經衛星或電臺定位計算生成；第2，遇險定位信息的轉發回路，定位信息由天基衛星或岸基電臺進行轉發，地面終端進行解算，直至當地搜救協調中心收到位置信息并分發給最近的救援力量；第3，救援力量的派遣回路，即救援力量從當前所在位置出發，根據提供的信息前往遇險海域搜索，直至到達人員遇險位置；第4，救援信息的反饋回路，即從救援指揮中心經衛星通信反饋給遇險人員，使得遇險人員配合救援行動，增強獲救信心。

圖7 海上救援體系組成要素網絡 Fig7 The Elements Network of Maritime Rescue System

4.3 海上救援體系的任務與能力

將上述4條目標實現通路歸結為4項任務，可知該體系的4大任務分別為生成遇險定位信息、傳遞遇險定位信息、派遣救援力量和反饋救援信息4項。接下來討論任務執行的條件，以生成遇險定位信息任務為例，影響目標實現通路走向的環境條件包括遇險位置離岸距離、緯度。因為依靠目前常用的AIS系統進行定位時，信號距離一般不超過30海里，所以離岸距離影響了定位回路能否從岸基定位向后推進。同時，在高緯地區衛星覆蓋存在盲區，定位任務只能通過岸基系統，因此遇險位置緯度也是條件之一。

按照前文的方法，從對各個目標實現通路評估的角度進行能力定義。例如，評估遇險定位信息的生成好壞，可以從定位的延遲與精度兩方面，將這兩方面聚合而成得到的則是海上救援體系的定位能力。而評估傳遞遇險信息和反饋遇險信息這兩項任務時，都可以從信息傳遞時延、信息容量和信息抗干擾性這3個方面進行。因此可將其合并為同一項能力，稱為信息傳輸能力。按照該方法得到海上救援體系任務-能力評估指標生成表，如表2所示。

表2 任務-能力評估條目生成表 Tab.2 The Mission-capability Evaluation Construction

4.4 對海上救援體系解決方案的評估

按照前文的方法，為了對目標實現回路內的不同解決方案開展評估。這里再次以生成遇險定位信息回路為例，將分析得到的任務條件、能力評估指標和系統解決方案建立聯系用OPM語言描述，如圖8所示。

圖8 用OPM語言描述任務條件-能力指標-系統解決方案 Fig. 8 Mission Condition, Capability Index and System Solution in Object-process Diagram

圖8 表示了任務條件對解決方案的影響，以及解決方案的能力評估水平。在離岸距離小于30海里以外時，岸基定位無法發揮作用。遇險位置處于高緯地區時，天基定位無法發揮作用。利用OPM的狀態表示能力評估水平，從圖中可以看出采用岸基定位、中軌衛星定位和低軌衛星定位的能力水平。在近岸條件下岸基定位的能力基本能滿足體系需求，但是離岸較遠的條件下，采用低軌衛星開展天基定位對需求滿足情況最差，中軌衛星好于低軌衛星，但在定位延遲方面還存在一定差距。

在圖8中，利用OPM語言表現了體系任務條件、能力指標、系統解決方案3個重要方面的關系，盡管不能實現定量計算，但這種基于模型的描述方法為后續進行體系評估模型的詳細設計確定了輸入輸出和基本框架。

5 總結與展望

本文提出的需求分析方法有如下特點：

a）該方法從正向工程的角度，將初始模糊的需求逐漸完善形成完整的任務、能力、組成系統的需求要素集，使得體系需求分析按照邏輯變得有跡可循。

b）該方法的可操作性強，從概念設計，任務劃分，能力評估的閉環鏈條中，每一步都有對應的操作步驟，為體系需求分析找到了可執行的方法論。

c）基于OPM的語言描述方法大大簡化了概念描述、流程建模和能力表示的難度。以這種基于模型的系統工程范式，將體系要素更清晰地表示出來。

目前的研究局限在依托體系概念開展定性的需求分析上，對于定量的分析尚存在困難。在后續的研究中，將探索OPM語言與其他基于模型的體系分析方法相結合，開展定量的解析、仿真計算，進一步提升需求分析評估的可信度。