MBSE系列: 方法论之RFLP

本篇属于基于模型的系统工程(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新世代