一種基于MBSE 的飛行傳感器系統需求建模方法?

韋彩色 曹云峰

（南京航空航天大學航天學院 南京 210016）

1 引言

隨著計算機技術和航空航天技術的快速發展，新一代飛行器任務日益增加，促進了其各系統規模不斷龐大，組成結構不斷復雜，對系統的設計要求不斷提高。有關研究表明，大量系統研制項目的失敗是由于不合格的需求信息導致的［1～2］。因此，在系統設計開發的早期，有必要先對系統的需求進行詳細分析。

傳統的需求工程方法由于基于文檔形式而不能進行需求跟蹤以及檢查各種錯誤和沖突；而且文檔偏向于自然語言的表達方式，容易造成需求表達不充分性和二義性；甚至文檔的不可執行性，使得系統需求缺乏必要的驗證手段，降低了系統開發效率和質量［3～4］。為解決這些不足，國際系統工程學會（INCOSE）聯合對象管理組織（OMG）提出了“基于模型的系統工程”的思想［4］。該思想通過模型從不同角度全面展示系統需求的內容，消除信息表達的二義性，可視性強，修改方便，具有可執行性。

傳感器系統是一種涉及電子、機械等多學科領域的復雜系統。它相當于飛行器的感應器官，負責采集飛行器的姿態、高度等信息，是飛控系統等系統做出控制的判斷依據。隨著新一代飛行器高安全性和高可靠性的要求，使傳感器系統變得種類繁多、功能復雜、需求多變［5］。在傳感器系統需求分析和驗證上，目前的研究大多采用有限元分析、Simulink仿真等方法［6，9］對單個傳感器進行分析，無法對系統的需求進行整體分析與集成驗證。鑒于此，本文提出一種基于MBSE 的飛行傳感器系統需求建模分析方法，輔以DOORS對其需求進行管理。

2 飛行傳感器系統需求管理

正如上面所述，飛行傳感器系統種類繁多、功能復雜，需求多變，有必要對其需求進行管理。直接從用戶捕獲得的需求在系統工程中被稱為涉眾需求，其存在信息表達的不明確性和二義性等問題，需將涉眾需求翻譯成系統需求，即明確系統必須做什么（功能需求）以及如何執行好（服務需求的質量），方便設計人員的理解［10］。它們往往以Word形式存在。本文采用DOORS 作為需求管理工具，DOORS 在需求修改歷程的記錄、需求變更、需求跟蹤、與Word 等軟件的集成等方面顯示出很大的優勢［11］。設計人員可點擊Word 工具欄中超鏈接Ex?port to DOORS 圖標將需求導入DOORS 中；也可手動輸入需求。系統涉及的傳感器種類繁多，功能多樣，因此，在DOORS中可按照傳感器種類或者功能來劃分，以文件夾方式進行組織。系統中每個部件涉及需求內容復雜多變，其需求在DOORS 中以條目化、分層級結構存在［12］，如：第一級描述初始需求，第二級用于對初始需求進行篩選、添加等變更，以此類推，直到形成完整的、明確的需求描述。這不僅便于修改需求，而且提高了瀏覽的便捷性，方便設計人員與用戶之間的溝通。此外，設計人員可借助視圖、鏈接等功能，對飛行傳感器系統的需求進行跟蹤管理，避免某需求的遺漏和需求之間的矛盾沖突。

3 飛行傳感器系統需求建模

為應對復雜系統需求復雜性和多樣性的挑戰，MBSE 思想已逐漸應用于需求工程，SysML 則作為系統建模規范的手段，以構建需求模型，通過模型的執行，實現對需求分析和驗證［13］。Rhapsody是由IBM 公司提供的、支持SysML 的工具，其提供與配置管理工具、需求管理工具等集成的接口［14］。本文通過集成接口Gateway，將飛行傳感器系統需求從DOORS 導入Rhapsody 中，便于在后續設計中確立需求的可跟蹤性；采用SysML用例圖對飛行傳感器系統需求進行靜態建模，從每個參與者的角度分析系統需求，逐層細化，獲得需求的元模型，使不同背景的設計人員對需求達成統一認識和理解，便于后期設計開發。用例圖是設計人員常用于分析系統的一種圖型。用例模型包含參與者（Actor）、用例（Use Case）以及關聯（Association）三個模型元素［15］。

從參與者的角度分析飛行傳感器系統的功能性需求和非功能性需求。根據飛行傳感器系統的特點，將參與者進行簡單分類。主要分為以下四大類：1）消費者（客戶）。表示使用飛行傳感器系統的利益相關者；2）供應商。代表參與項目交付的所有利益相關者，又細分為：設計人員、維修人員；3）系統外部環境。表示以某種方式約束傳感器系統的利益相關者，例如：飛控系統；4）質量監管部門。表示負責驗收系統相關質量指標是否達標的利益相關者。

圖1 各個參與者對應的系統需求用例模型

圖1 顯示從各個參與者角度描述飛行傳感器系統需求的用例模型。例如：從用戶的角度，主要要求是“獲取飛行器信息、高可靠性、高穩定性、容錯性、經濟性”，其中飛行器信息包含“高度、姿態、位置、相關溫度”等，“容錯性”包含“具有自檢測功能、具有冗余通道”。即使所得的每個用例模型不完整，但也會帶來三個好處：1）單獨從每個參與者的角度考慮系統用例，確保每個系統用例都被捕獲；2）通過一起查看這些用例模型，可捕獲系統的所有需求；3）參與者可只關注其感興趣的相關用例。通過比較每個用例模型，可發現潛在的沖突或重復。雖然表達方式可能不同，但最終從系統本身角度看，其需求的本質是一樣的。例如，消費者、設計人員以及飛控系統都要求該系統能夠獲取飛行器的姿態、高度等信息。因此，為了避免需求之間的重復沖突，整理圖1 中的所有用例模型，從系統本身的角度出發，最終建立完整的，無重復的飛行傳感器系統需求的用例模型如圖2 所示，獲得了系統的需求用例元模型。

圖2 飛行傳感器系統需求的用例模型

4 需求建模實例分析

本節以某型號無人機傳感器系統為例，利用上文建立的元模型庫，搭建該系統需求模型。將根據用戶得出的涉眾需求轉化成對應的系統需求，分別在DOORS 中進行描述。通過DOORS 中Link Mod?ule 將涉眾需求與系統需求關聯起來，建立滿足（satisfy）關系，保證系統需求完整地覆蓋涉眾需求，從而保證后續系統建模與涉眾需求的一致性，如圖3所示。

通過Gateway將DOORS中的需求導入到Rhap?sody 飛行傳感器系統項目中。該無人機傳感器系統需求為：能夠與飛行控制系統進行信息交互，將姿態、位置等信息反饋給飛行控制系統［16］；系統本身具有穩定性、可靠性以及容錯性。利用上文獲得的飛行傳感器系統需求用例元模型，搭建該系統需求模型如圖4 所示。系統用例模型中的參與者與用例之間存在關聯（link）關系，用例之間存在包含（include）關系等。

圖3 關聯系統需求到涉眾需求

圖4 某型號傳感器系統用例模型視圖

5 結語

針對飛行傳感器種類繁多，功能復雜，需求多變的特點，本文通過DOORS對系統需求進行管理，不僅可實現多人對需求更改，而且能實現需求的跟蹤性，直觀地描述需求之間的關系。通過Gateway集成Rhapsody 與DOORS，實現需求的動態轉移。基于MBSE 采用用例圖對系統需求進行建模，獲得飛行傳感器系統的需求元模型。以某型號無人機傳感器系統為例進行分析與驗證。可以發現，基于MBSE 的思想對飛行傳感器系統需求進行分析，不僅可以消除信息表達的二義性，便于需求變更；而且需求模型具有重用性，方便系統后續的開發。本文主要工作是對飛行傳感器系統需求進行靜態建模，下一步可通過使用SysML 序列圖、狀態圖等行為圖對需求進行動態描述與進一步驗證。