本篇屬于基于模型的系統工程(MBSE)專題系列第04篇內容，我們一起來聊MBSE終極方法論之RFLP相關內容。

閱讀之前強烈建議參考之前系列文章:

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

02 - MBSE系列: 方法論之OOSEM

03 - MBSE系列: 方法論之Arcadia

在上幾篇MBSE文章，我們聊到了MBSE基本概念及其重要性，以及不同方法論，包括汽車行業比較常見的OOSEM, Arcadia等。當然MBSE還包含很多其他的方法論，但這些方法論本質都離不開兩個內容:

• V模型

V模型屬于汽車工程師必修課，相信大家都不陌生，基本上現在大家熟悉的大部分系統，軟件等開發標準，例如MBSE, Aspice, ISO 26262等，其方法論基礎都離不開V模型，V模型左邊TopDown的開發思路，以需求為基礎，然后依次進行架構設計和詳細設計，V模型右邊以集成，驗證和確認為主，具體如下圖，在此不再贅述。

當然，隨著汽車產品，尤其是軟件的快速迭代要求，V模型也受到一些詬病，即不夠靈活，后序開發嚴重依賴于前序輸入，導致產品開發周期長，變更速度慢，開發成本難把控等，所以Agile開發模式逐漸得到汽車行業的青睞。這塊是個比較大的問題，我們后續專門詳聊。但不論如何，V模型重要性不可忽視。

• RFLP

MBSE方法論除基于V模型外，模型驅動是其主要特點。所謂的模型是指一切可以描述對象的載體，這個載體可以是文本，圖形，偽代碼等。

考慮到圖形化建模在可讀性，可視化方面的優勢，MBSE推薦使用圖形化建模，并且利用通用化建模語言，例如SysMl，這樣便于達成共識，避免歧義，將系統，軟件/硬件V流程中的開發產物在架構開發工具中，例如Enterprise Architect, Cameo等，通過不同的視圖模型化，以此實現模型驅動的目的。

但這些模型視圖不管怎么變化，方法論如何，其根本都是圍繞RFLP，所謂的RFLP，即:

R: 需求(Requirement)

F: 功能(Function)

L: 邏輯(Logical)

P: 物理(Physical)

以已介紹的兩種方法論OOSEM和Arcadia為例:

RFLP認為我們應該從以上四個角度(Viewpoint)去對待系統，通過建立相應的架構模型，將復雜產品的實現過程進行完整映射。

01

R Viewpoint

需求是產品開發的基礎，根據其性質不同，需求有很多種類，例如不同層級需求(用戶，系統，軟/硬件)，功能需求/非功能需求等。

很多朋友好奇，對于MBSE，到底什么是需求模型？

需求一般都是都過文本的形式進行呈現，并通過需求管理工具進行管理。文本形式的需求本身就屬于一種模型，對于MBSE而言，需求模型也還是以文本表達為主，只不過對于MBSE而言，R(需求)Viewpoint強調兩個方面:

1

導出需求: 

借助相關的視圖，例如SysML中用例視圖，分析產品不同用例及參與者交互關系，便于我們更好更完整地導出需求。

2

圖形化需求: 

通過視圖化的形式，將需求通過相關視圖，例如需求視圖，將需求層級化，條理化展示，也便于后續建立需求和其他架構模型之間的可追溯性。

02

F Viewpoint

F即功能，我們在03(點我)聊過， 功能的本質其實是需求，只不過功能是根據需求的相關性，被系統化集成和抽象后形成的需求集合 。

所以F(功能)Viewpoint的存在是為了從整體的角度明確產品或系統開發的任務，明確定義產品或系統應該給用戶提供什么樣的功能以及它們之類如何交互。

對于MBSE而言，F(功能)Viewpoint主要目的就是通過不同視圖模型，表達以下三個方面內容: 

1

表達結構及層級: 

通過組件視圖，例如類圖，組件圖，明確系統功能模塊組成及層級關系。

2

白盒接口: 

通過白盒結構視圖，例如，結構視圖，表達功能模塊之類的交互關系，即功能接口。

3

可追溯性: 

通過不同的關聯關系，例如實現，關聯等關系，建立需求視圖和功能視圖之類追溯關系。

除此之外，還可以根據需要，采用其他視圖，表達功能模塊之間信息動態交互過程，狀態遷移，執行順序等。

03

L Viewpoint

L，即邏輯Viewpoint，具體定義見02(點我)。

很多朋友還是搞不清到底什么是邏輯架構，什么時候需要建立邏輯視圖？

從概念的角度講，邏輯架構介于功能和物理實現架構之間，是功能架構的邏輯實現方式，它主要考慮通過哪些邏輯組件以及交互關系去實現功能架構中所需的功能，它屬于技術中立的解決方案，并不明確具體技術實現方式。

舉個簡單的例子，我們需要一杯熱水，為了實現能夠加熱這杯水這個功能:

• 從邏輯架構角度看，我們至少需要一個熱力源，一個熱力傳遞裝置，為了控制水的溫度，甚至還需要個溫度檢測裝置等，但我們并不明確具體技術實現方式。

• 從物理架構角度看，這個熱力源可能是我們升的一團火，也可能是用了電磁爐，也可能是直接放大太陽下。這些都是具體的不同的技術實現手段。

所以邏輯架構并沒有明確技術實現手段，只是從邏輯的角度去看怎么解決問題。

邏輯的存在目的在于:

1

復雜系統簡單化，系統化思考問題: 

邏輯架構符合我們的思維方式，在不考慮具體技術實施手段的情況下，簡化了系統，讓我們更容易理解復雜系統，讓我們在不受細節約束的情況下，從系統，整體，后續維護等角度，考慮問題，進而給出合理有效的邏輯解決方案，這也是MBSE應對系統復雜性的優勢之一。

2

技術中立: 

邏輯視圖技術中立，可以有效增加系統的復用性。

對于MBSE而言，我們需要采用哪些視圖表達邏輯架構呢？

本質上邏輯Viewpoint采取的視圖和功能Viewpoint類似，邏輯視圖同樣需要描述系統邏輯組件結構，層級關系，邏輯組件之間的交互關系，即邏輯接口，執行順序等。

需要注意的是，邏輯視圖不受技術實現的約束，甚至不同的邏輯組件在后續物理架構中可以分配到不同的控制單元中去，或者一個邏輯組件由多個物理組件實現，或者多個邏輯組件由一個組件組件實現等。

04

P Viewpoint

P(物理)Viewpoint是物理架構的表達方式，旨在基于邏輯視圖，進一步明確邏輯組件對應的物理或技術實現方式，這個相對比較好理解，在此不再贅述。

其采用的視圖和功能或邏輯Viewpoint基本一致，只是更加細致化，需要明確具體軟件或硬件組件，接口信號等，這個就和我們具體軟硬件開發相關。

此外，在物理視圖中，還需要體現具體的E/E架構，或者針對具體的某控制單元，其物理接口，連接方式等，并將邏輯架構組件分配至相應的物理架構，得以最終物理實現。

寫在最后:

MBSE終極方法論之RFLP我們就聊完了，希望能夠給朋友們理解MBSE應對系統復雜性帶來新的理解 。

END

文章來源：AUTO新世代