前文回顧：MBSE | 基于模型的系統工程系列之基礎篇

◆  ◆  ◆  ◆

從上一篇文章我們可以看到，系統工程的活動種類比較多，包括了技術過程的相關活動、技術管理過程相關的活動，以及項目使能過程相關的活動。

這些活動的概念和內容我們已經有了基本的了解， 接下來我們看一看，怎樣使用 MathWorks 提供的工具鏈執行這些活動。

大家知道，MathWorks 在 2019 年推出了一個面向系統工程應用的工具——System Composer，從 2019a 版本發展到今天的 2020b 版本，經過多個版本的迭代，功能更加完備，和 MATLAB/Simulink 的其他工具集成的越來越好，正在得到越來越多系統工程師的關注和使用。

但在這里有必要強調一下，正如前面所說， 系統工程涉及的工程活動非常多，這些工程活動的實施不僅需要 System Composer，還需要 MATLAB 和 Simulink 以及其他 Tooblox/Blockset 的支持。

總體來說，System Composer 在系統層面的描述能力、MATLAB 提供的分析能力以及 Simulink 提供的系統級建模仿真能力，讓使用 MathWorks 的工具鏈開展的系統工程活動，在 “定性” 和 “定量” 方面均有更好的工具基礎。

下面我們通過一個實例來看一看，采用 MathWorks 提供的工具鏈怎么開展系統工程的各項活動。

◆  ◆  ◆  ◆

假設我們接收到的任務是開發一個實時跟蹤綠色球的系統。

任務/目標定義 和 需求工程

首先，基于這個任務定義，我們需要細化這項任務需求，比如回答下列問題：

• 目標球的材質是什么？

• 目標球有多大？

• 目標球向幾方向運動？

• 目標球是在水下，天空，戶外還是戶內？

• 需要系統以多快的速度追蹤到這個球？

這時，我們使用 Simulink Requirements 來定義和管理這些細化的需求。這里我們將需求大致細化為兩類， 一類 是目標球屬性的需求（待設計的系統的外部約束）， 第二類 是系統本身特性的需求。

每一類都盡量細化為可定量描述的條目，比如對系統本身的需求描述：

• 支持持續追蹤的時長大于等于4分鐘；

• 所設計系統在尺寸上，能夠容納于可登機的標準行李箱內。

在這一階段，我們通?；诮涷灪托袠I知識對涉眾需求進行歸納和梳理，初步形成專業化語言表達的系統層面的工程需求。

很多時候，我們是憑借專家系統的監督和評審來保證系統需求分解的質量，而在設計復雜系統時，系統涌現性凸顯，要想達到如 ARP4754 所提出的系統需求一致性和完整性要求，還需要在架構設計和詳細設計等環節，逐步對各條需求進行綜合分析和論證（包括：任務/目標定義階段，MATLAB/Simulink 環境下，構建可仿真的系統級模型，逐條根據需求構建運行場景開展仿真），才能進一步保障系統需求分解的質量。

系統架構

下面我們根據需求使用模型來對這個系統進行設計和描述。

• 整個系統在架構上由三個部分組成：位于地面的控制終端、飛行器（追蹤目標）以及目標；

• 控制終端和飛行器間的接口定義為 GCSCmds；

• 通過使用構造型為飛行器和目標定義一些關鍵屬性（基于這些屬性可以進一步開展一系列的分析）。

同時，建立清晰的需求和架構模型之間的關聯，這也是很多 Safety-Critical 系統設計的時候，相關最佳實踐和規范所提倡和要求的。

如上圖所示，我們基本完成初步的架構設計：

其中，使用方框圖（1）表示 SoS（System of Systems，此處指我們待設計的復雜系統）的組成部分（系統/目標），

Port（2）表示端口（物理屬性），

而（4）中的數據結構表示端口（2）關聯的接口定義（信息屬性），

線（3）表示 SoS 組成部分之間的“關系”，

需求窗口（5）顯示了開始系統建模的輸入，即前面定義的需求，

而（6）展示了這些需求和SoS組成部分之間的聯系，

每一個方框圖（1），即每一個SoS組成部分都具有的屬性信息，

我們通過（7）中的構造型來表示。

至此，我們使用 MATLAB/Simulink 實現了如下圖顏色部分所示的三個關鍵部分： SoS 需求定義，架構設計（System Architecture，SA），以及架構和需求的關聯（追溯） 。

技術分析

我們知道系統工程一個核心任務是確定"做什么"，即在工程域對涉眾需求進行完整且一致的描述，從而為下一步的設計和實現提供有效的輸入。

確認（Validation），是我們保證這種完整性和一致性的主要活動。正如 ARP4754 中所闡述的，確認的方法可以包括：

追溯（Traceability），

分析(Analysis），

建模（Modeling），

測試（Test），

引用/類比（Similarity）

以及工程評審（Engineering Review）。 

追溯和建模的活動從前面的描述中我們基本已經看到其涵蓋的內容，而測試、引用/類比（即基于其他工程的工程經驗進行評估）、工程評審是我們當前比較常用的手段，在此我們看一下，在 MATLAB 工具具有的數據科學能力的基礎上，我們在“分析”方面還能做哪些事情。

我們以分析機身為例看看怎么開展技術分析（Technical Analysis，TA）。

在這個示例中，假設我們已經確定是要在室內追蹤一個泡沫球，當前設計的追蹤裝置是一個小型的、無人的飛行器，在這種約束下，我們發現貨架（COTS）的可選飛行器類型是四旋翼飛行器。

進一步，經過調研，我們發現三種類型的飛行器可能滿足我們的初步需求。我們通過圖形化的方式，在模型中定義這三種飛行器，并通過構造型對這三種類型的飛行器進行特征描述，包括載荷容量、成本以及可編程的能力。

那么接下來，我們就要采用技術分析的手段，來看一下那種機身更符合當前的涉眾需求。這時，我們使用“載荷成本”這個指標做為評價標準：

載荷成本 = 成本/載荷重量 * 可編程性；（具體的評價標準在工程實踐中往往要進行科學的設計）

當我們把諸如載荷重量、成本支出以及可編程性等數據與前面提到的構造型建立聯系后，即可開展這項成本分析。

從定量的分析結果上看，Crazepony Mini 和 Crazyfile 2.0 兩款具有可編程性（2），而 Crazepony Mini 具有更低的成本（1）（每載荷重量下的成本）——90。

這樣，基于這些量化的分析，我們可以比價科學的確定采用 Crazepony Mini 的機身設計方案。

隨著系統復雜度的增加，我們需要評估和權衡的指標會變得越來越多，需要開展的技術分析也相應增多，而這些多樣化、多角度的技術分析將為系統需求的確認提供更為科學的支撐。

系統分解與功能分配

下面，我們要將 SoS，即系統之系統的需求，也就是前面提的涉眾需求，繼續細化為對各個組成部分的需求，即都要使用什么樣的系統來實現，每個系統完成哪些任務？ 即 Physical Allocation 和 Functional Allocation。

以當前這個示例的基礎，我們要回答的問題就變成： 對于 AirVehicle 來說，從實物的角度看是由什么來組成（Physical Allocation），每個組成部分應該承擔什么任務/實現什么需求（Functional Allocation）？

采用前面提到的需求確認的方法和手段，我們可以設計出最頂層的物理組成：

其中，Quacopter 的各個部分以及與功能的對應關系模型如下圖所示，其中，經過前面的架構設計和需求確認相關的分析，我們已經能夠細化出 Quadcopter 的需求

（1），進一步，將這些需求映射到 Quadcopter 的物理組件上

（2），這也對應著 Functional Allocation 的活動。

在進行 Physical Allocation 的時候，我們可以充分利用 MATLAB 提供的篩選功能，靈活的調整物理組件的實現形式。

下面就是基于構造型的篩選來構建 Physical Allocation 視圖：

首先確認篩選條件

然后，由 MATLAB 自動化生成滿足篩選條件的視圖：

我們可以看到，Quadcopter 從物理實現的角度，主要由 Payload, Motors, IMU, Battery，OnboardProcessor（承載軟件 SW）組成。

Physical Allocation 和 Functional Allocation 是一個持續交互的過程，需要持續不斷的在不同的分配策略上做工程權衡，這種權衡有時能夠直接根據專家判斷得出結論，大多數情況下，需要我們不斷的開展工程分析，利用工程分析來科學的指導設計。

系統驗證

最后就是開展 SoS Verification 了，即需求的驗證，也就是所實現的系統在多大程度上滿足需求。

工程實踐中的驗證過程，往往也帶有“確認”的屬性，即在驗證的過程中，進一步確認需求的完整性和一致性。

因為，雖然在理想的情況下，所有的需求應該在開發開展前進行確認，但實際的工程實踐中，特別是當面對的是復雜和高度集成的系統時，直到待設計的系統進入到實際的運行環境，并開始運行和測試時，我們才能最終確認某些需求是不是合理、在工程上是不是可行。

所以，對于復雜系統的工程實現，我們基本上采用階段性確認的方式開展需求確認，即在整個系統研發生命周期內，持續的開展確認活動，盡可能在每一個研發階段開展確認活動，盡早的發現那些還有待完善、不一致的需求條目，從而達到減少設計迭代的目標（迭代的產生，要么是因為需求無法實現，要么是因為設計考慮不周）。

這樣，測試或驗證也會成為確認過程的一部分，這也是“ 持續的確認和測試 ”說法的由來。

以往我們經常在各個系統都已經實現，有物理樣機了才能開始驗證工作。現在，有了 MATLAB/Simulink，我們可以采用 仿真 的方式，在很早期還沒有實物或只有部分實物的時候就開始驗證工作。

我們可以對系統架構設計中的各個組成單元建立仿真模型，將整個待設計的系統使用可仿真模型進行表達，再進一步構建系統運行的外部環境模型，然后開展“驗證”活動。

◆  ◆  ◆  ◆

至此，我們以一個非常簡單的示例向大家簡要展示怎樣在 MATLAB/Simulink 下開展系統工程的各項活動。

限于篇幅和系統工程本身的復雜性，還有許多內容沒能深入闡述，后面會有專門的文章更進一步和大家探討。 非常期待您的反饋和意見，讓我們共同探索系統工程的最佳實踐。

◆  ◆  ◆  ◆

文章來源：matlab