近些年，隨著汽車電氣化，智能化，網聯化，汽車產品的功能和邊界不斷被拓展。電動汽車，智能駕駛等功能的出現使得汽車早已不再是簡單的出行工具，而更像一個智能移動終端。由此，整車電子電氣架構日趨復雜與集中化、汽車軟件代碼量激增，軟件服務化，OTA成為可能，軟件定義汽車世代來臨。

那么在這樣的大背景下，面對日益復雜的汽車系統，我們該如何應對？

從研發角度講，基于模型的系統工程(Model Based Sytem Engineering，MBSE)可能是應對系統復雜性的有效方法之一。

系統工程或者基于模型的系統工程雖然不是什么新鮮概念，甚至有些被過度使用，提到系統工程，大家第一反應就是實現產品的跨學科方法，通過系統思想解決復雜產品問題。但到底什么是系統？什么是系統工程？它的核心是什么？憑什么它能夠解決系統復雜問題？

這些年以來，個人越發覺得系統工程的重要性和必要性。帶著對這些問題的思考??，系統工程系列專題就和朋友們正式見面了，希望這個系列能給朋友們帶來啟發，我也會對其一些核心內容分別進行闡述。

由于系統工程涉及內容繁多，我們今天就先起個頭，聊一聊系統工程的一些基本問題，帶著對這些基本問題的理解，最后我會嘗試去回答: 為什么系統工程或基于模型的系統工程可能是應付系統復雜性的應對之道？

01

什么是系統？

系統(System)是相互關聯的元素或部分組合在一起構成的整體，它可以是物理或概念意義上的系統，或二者的結合。正是由于組成元素之間的關聯性，當它們組合在一起時，可以形成特定的功能。

系統的存在有兩方面意義: 

1

幫助我們理解復雜對象，通過將復雜對象拆分成不同系統及子系統，降低研究對象的復雜度，便于我們逐個理解和突破。

2

劃分職責，讓特定的人做特定的事，共同協作開發復雜的對象，畢竟我們每個人能力和時間都是有效的。

個人覺得以下兩處對系統定義比較有意思且相互補充:

• 國際系統工程學會(INCOSE)定義: 

"A combination of interacting elements organized to achieve one or more stated purposes."

• ISO 26262定義:

一個系統至少由一個傳感器，一個控制器和執行器構成，當然傳感器和執行器可以處于系統外部。

其中，INCOSE定義從功能上定義了系統的存在，簡言之，有特定意義或功能的集合即為系統，而ISO 26262從物理組成上定義了系統，傳感器，控制器，執行器三者缺一不可。

02

什么是系統工程？

系統工程(Sytem Engineering，SE)是一種跨學科的綜合性方法，系統工程強調使用系統的原理和概念，以及科學、技術和管理方法來實現系統設計與開發。

這個定義比較抽象，個人認為系統工程更多的是一種思維方式，重點在于系統一詞，它包含兩層含義: 

1

從系統或整體的角度看待和分析問題，關注系統之間因果和相互作用，而不只是局限于系統本身。

2

運用系統的技術手段，以需求為導向，架構為開發基礎，前期驗證和確認為及時發現解決問題。

如下圖所示，系統工程本身屬于方法論，同樣基于V模型，只不過它對需求，對架構以及驗證和確認在產品設計中的發揮的作用更為重視：

來源: MathWorks

需求的重要性在于:

現在的汽車產品早已不再是簡單的交通工具，汽車產品需求也是日益趨于復雜化，多樣化，除了用戶對產品功能方面的需求不斷復雜化，例如，電動化需求，自動駕駛需求，智能座艙需求等，市場及相關法律法規的約束也不斷增加，例如功能安全，信息安全，ASPICE等等。

需求是一切開發的基礎，它深刻體現了我們對用戶需求的理解以及產品定位的思考，直接決定了我們需要開發什么樣的產品。完善的需求管理是項目成功的關鍵因素之一，幫助我們:

• 揭示用戶對產品假定和潛在的需求

• 明確市場法律法規對產品的要求

• 明確定義交付成果并構建相關功能

• 衡量項目工作量，對項目周期和成本把控

糟糕的需求管理常常是項目失敗的首要原因。在實際項目中，很多人認為需求只是一堆可有可無的文檔，企業重視程度不高，導致需求質量低，書寫不規范，常常被弱化，經常為了評審，硬補需求，需求沒有被真正應用于產品開發，甚至很多中小型甚至大型企業需求管理都沒有專門的成型的需求管理體系，只是通過一些簡單定義的工作規范和工作流程來管理需求，需求管理工作也往往由一些沒有太多經驗的工程師承擔。

下圖充分說明了需求管理的重要性，錯誤或有問題的需求會直接導致產品開發的失敗，雖然圖片內容帶有夸張成分，但很多產品的開發從需求開始就注定是失敗的: 

有問題的需求 > 設計缺陷 > 開發 > 更高的解決難度和處理成本

好的需求應該充分體現用戶需求，市場現在及未來潛在要求，做到有層次，描述清晰無歧義，可追溯，可復用，可測試。

架構的重要性在于:

一旦確定了產品需求，我們就可以根據需求著手開發產品，但在產品具體詳細設計前，尤其對于復雜系統，我們往往需要大致確定下可行方案，或者說給系統實現打個草稿，這個就是所謂的架構。

架構是產品需求的實現的初步設想，它幫助我們在產品開發前期，根據需求構建所需的功能，并從復雜度，成本等角度對其進行綜合探討和評估，找出最合適的實施方案。

所以架構的重要性在于:

1

架構幫助我們在一些重要的事情上一開始就做正確的決定，系統規劃，確定方向，避免資源和時間浪費。

2

對系統或者產品形成統一的理解，幫助我們對內對外更好地溝通和決策，降低溝通成本。

3

對系統進行合理的抽象，便于復用。

4

架構模型為橋梁，有效統一產品需求，實現過程以及測試用例可追溯性。

尤其是對于基于模型的系統工程(MBSE)，架構是模型的重要體現，我個人一直認為在整個系統開發過程中，架構的設計可能是最困難同時也是最重要的過程，面對復雜的需求，如何對其進行功能抽象，以盡可能合理的方式對其功能進行組織，妥協，最終形成可實施的技術解決方案。

最后我想說架構是門藝術，任何重要的內容都屬于架構的范疇，詳細內容我們后面細聊。

驗證和確認的重要性在于:

驗證(Verification)和確認(Validation)是MBSE過程中重要的檢查措施，其區別見:

12 - 汽車功能安全(ISO 26262)系列: 軟件開發 - 軟件詳細設計及安全測試

確認和驗證是整個系統生命周期過程中需持續進行的系統工程活動，主要通過分析，評審，測試等手段進行，是檢查產品是否按照我們預期的方式和結果進行開發，是及時發現解決問題的有效途徑，也是保證產品質量的關鍵措施。

03

基于模型的系統工程MBSE

在傳統的系統工程應用過程中，不管是需求，還是架構都是以文檔為中心，每個階段工作輸出結果的載體都是文檔，不同團隊和階段的交流也都是基于文檔。

但隨著系統復雜性的上升，以文檔為中心的系統工程（Text Based Systems Engineering，TBSE）方法存在很多問題，例如:

• 系統復雜化，文檔數量增多，不便于書寫，管理

• 文字描述存在歧義，對團隊溝通協作不友好，不同部門及開發人員難以形成統一理解

• 需求變更，追溯困難

• 文檔無法仿真驗證

為了解決TBSE所存在的問題，國際系統工程學會(INCOSE)提出了基于模型的系統工程(Model Based Systems Engineering，MBSE)方法。

MBSE強調以圖形化模型為核心，將SE方法論過程中設計內容通過工具模型化，電子化，構建不同階段開發模型，例如需求模型，架構模型，詳細設計模型等，并彼此相互關聯，以此增加輸出內容的可復用性、形成系統一體化設計，可以有效解決隨著系統復雜度提高對傳統基于文檔的系統工程帶來的挑戰，這個也是目前大部分規范，例如ISO 26262，ASPICE等，對工作輸出產物的基本要求。

模型既然是MBSE的核心，那么如何建立模型是MBSE的關鍵任務，所以為建立系統化模型，MBSE在SE原有方法論的基礎上，新增了: 

• 建模語言

• 工具

這兩項內容，這也就構成了MBSE落地三大基本要素PMT，即:流程(Process), 方法(Method)和工具Tools，所以簡單地說:

MBSE = SE方法論 + 建模語言 + 工具

建模語言定義了建模過程中可以使用的可視化元素及其代表的意義。為消除歧義，MBSE要求使用統一化的建模語言SysML。它以圖像化的方式定義了不同類型的視圖表達方式，例如需求視圖，結構視圖，流程視圖，狀態視圖等等，這些視圖相互補充，可以用于表達MBSE設計過程中關注對象的不同側面(View)，進而形成完整的系統架構模型。

但應該如何通過這些視圖將SE方法論中的工作內容盡可能有層次地，可追溯地，完整地統一在一個系統化模型中，實現一體化的模型設計呢？

答案就是RFLP方法。

所謂的RFLP 方法就是：

R: 需求(Requirement)

F: 功能(Function)

L: 邏輯(Logical)

P: 物理(Physical)

RFLP認為我們應該從以上四個角度(Viewpoint)去對待系統，通過建立相應的架構模型，將復雜技術產品的實現過程進行完整映射。關于RFLP進一步內容我會在架構專題中進一步探討。

工具是指在實施MBSE過程中建立，建立及管理模型所使用的軟件工具，它們可能是多個工具，包括了需求定義及管理工具，架構建模工具，測試驗證管理工具等，它們之間通過接口可以進行交互，建立可追溯性，也可以是自主開發的綜合性設計工具，將MBSE過程建模統一在一起。

個人認為，MBSE方法論大家都比較熟悉，MBSE落地實施的關鍵除了思維轉換，擯棄原有基于零部件的開發，以及開發流程匹配外，模型的建立是關鍵，而有效的工具支持是建立及管理模型的必要條件，它能幫助將工程師從繁雜的文檔工作中解放出來，專注于可視化模型的建立，整個產品研發以模型作為驅動，提高產品開發效率。

聊了這么多關于SE或MBSE基本內容，我們現在回過頭來再看下標題中的問題:

為什么MBSE是系統復雜性的應對之道？

這個問題有點大，我嘗試回答如下:

所謂復雜性，主要是源于研究對象結構復雜，組成元素相互作用，存在錯綜復雜的關系，使得我們不能由局部來認識整體。所以解決復雜性的根本在于從整體上認識系統，將其進行系統化拆分，弄清其組成元素的相互作用關系，并通過有效的手段對其進行抽象化，直觀化，使得我們能夠從整體上認識和理解系統。

而SE或MBSE方法論的核心正是從系統角度認識整體，一方面通過系統的方法論，重視需求和架構的作用，及時對系統進行驗證和確認。另一方面，開發過程以模型為驅動，通過系統模型以圖像化方式直觀地揭示系統的組成及它們之間的聯系，讓工程師能夠以一種更加容易的方式掌控系統復雜性。

寫在最后:

系統工程開篇我們就聊完了，接下來我會針對其具體相關內容，包括需求，架構，語言等方面分別進行展開，希望能夠給朋友們理解系統工程，應對系統復雜性帶來新的理解 。

END

文章來源：AUTO世代