应用 RFLP 框架开展基于模型的系统工程

在复杂系统的研发过程中，通常很难直接从用户需求对应到具体实现。

一般需要从应用场景分析梳理出系统应该具备的功能；

再将功能有机组合形成备选逻辑架构，根据成本质量等约束进行权衡分析；

最后在选定的逻辑架构基础上根据以往经验和现有平台考虑各逻辑单元对应的物理实现，形成最终的物理架构。

以上就是系统工程中常用的 R（需求）-F（功能）-L（逻辑）-P（物理）框架。
基于模型开展 RFLP 设计时有许多需要考量的因素，以下几个因素是其中比较重要的方面：

• 模型化的分层架构描述
• 各层之间的追溯或者分配关系
• 架构间的推导过程
• 灵活的权衡分析手段
• 组件级和架构级的验证

Simulink 平台在最近的更新中，陆续增加了许多功能用以更好地支持基于模型的系统工程流程，我们以电动车的开发为例来一探究竟。

1）架构分层描述

用户需求以层级化和条目化的形式在 Simulink Requirements 中创建和管理，或者直接从外部需求工具导入；

通过需求分析提取出系统的原子化功能，以图形化功能模块的形式创建；

在逻辑层中通过接口的定义和连接按逻辑单元将功能进行组合实现需求；

物理层则落实到具体的实现，比如电池、电机和控制器等。

功能、逻辑和物理三层架构均由 System Composer 实现（图1）。

图1 电动车的 RFLP 架构描述

2）追溯和分配

建立追溯和分配关系是防止系统过设计或漏设计的重要手段。

Simulink Requirements提供了需求的实现状态、对应的功能模块、是否有变更、特定的属性（如是否为安全需求）等重要功能（图2）。

图2 需求的追溯和管理

图形化的架构模型分配关系则可以通过分配矩阵进行管理，以逻辑-物理分配关系为例，分配矩阵清晰的展示了关键架构元素之间的对应关系，可以快速查找是否有逻辑单元没有落实到物理实现上（图3）。

图3 逻辑架构-物理架构的分配矩阵

3）基于时序图的架构推导

复杂系统或子系统的模块和模块间的信息流和能量流关系有时无法仅凭经验获得，可以借助于构建多个场景的时序图推导出最终的架构，比如叠加充电场景和行车场景的时序自动梳理出能量管理系统的参与组件、端口和连接关系（图4）。

图4 从场景时序图推导出逻辑架构

4）架构权衡和分析

架构分析的深度取决于信息的多寡，简单的 SWaP（Size、Weight、Power、Cost 等）分析通过汇总附着于架构元素的属性信息即可获得（图5），不同的属性要素可以通过创建构造型（Stereotype）定义（图6）。

图5 SWaP 分析

图6 构造型定义

凭借以往的工程经验或随着系统开发的深入，可以借助于 MATLAB 计算能力和 Simulink 的仿真能力进行不同层级的分析。

比如计算续驶里程时，在分析脚本中调用经验公式（低保真度）（图7）或仿真原型模型（高保真度）（图8），这些算法都可以集成到权衡分析的脚本中。

图7 基于经验公式（低保真度）分析

图8 基于原型模型（高保真度）仿真

5）组件和架构验证

在逻辑和物理架构中，我们不仅仅用 System Composer 对架构进行“描述”，还可以内嵌 Simulink, Stateflow 和 Simscape 等多学科模型对架构组件赋予“行为”（图9），作为系统的实现原型。

图9 架构的行为和验证

这样的架构模型其实也可以成为系统集成框架，借助于 Simulink Test 的测试管理能力直接从架构模型进行组件或集成级的需求验证（图10）。

图10 需求验证状态

总结

开发流程的“Front-Load（前置）”和“Shift-Left（左移）”是复杂系统设计的趋势，从基于模型设计到基于模型的系统工程是这一趋势的重要体现，RLFP 架构将系统的设计过程以模型的方式实现知识的资产化，是企业数字化转型的重要支撑。

以 Simulink 为依托的需求管理、架构设计、权衡分析、集成验证等功能正不断完善统一平台、高度集成的基于模型的系统工程设计流程。