MBSE | 基于模型的系统工程系列之基础篇

在全球产业界多年系统工程实践的基础上，在信息技术和企业信息化建设的赋能下 ，基于模型的系统工程（MBSE）逐渐被公认为，在军用及民用在内的所有产业领域内，进行复杂产品研制和生存周期保障的新型研发范式 。

在此背景下，我们希望通过一系列围绕 MBSE 展开的文章，从 MBSE 的基础知识开始、与读者一起探讨基于模型的系统工程过程的最佳实践。同时，读者也可以通过这些文章了解到怎样使用 MathWorks 提供的工具开展 系统工程活动 。

本篇做为本系列文章的第一篇，主要和读者一起回顾和梳理 MBSE 的基础概念，为后续文章提供理论基础。

◆  ◆  ◆◆

根据国际系统工程协会（INCOSE）在 2007 年发布的《SE 愿景 2020》中的定义， MBSE 是建模方法在系统工程中的形式化应用，用以支持在系统全生命周期内开展需求、设计、分析、验证和确认相关的活动 。从定义可以看到，MBSE 是基于文档的传统系统工程工作模式的演进，力求以多视角的系统模型做为桥梁，将跨学科/领域的模型关联起来，实现跨学科/领域的模型追溯，从而驱动大型复杂系统生存周期内各阶段的工程活动，最终实现以模型驱动的方法来采集、捕获和提炼数据、信息和知识。

《INCOSE 系统工程手册》、《NASA 系统工程手册》、《FAA 系统工程手册》以及《中国商用飞机有限责任公司系统工程手册》中对系统工程实践有完善的描述，如果需要深入了解系统工程相关概念和具体实践，请参阅这些手册。

MBSE 是采用模型驱动的方式对系统工程的实践，本文就从系统工程要做的几个典型任务入手，介绍 MBSE 都做什么，帮助大家理解MBSE的内涵，并进一步开展 MBSE 的实践。

系统工程的主要活动包括：

• 任务/目标定义

• 需求工程

• 系统架构

• 系统集成

• 验证与确认

• 技术分析

• 范围管理

• 技术领导力和技术管理

下面就来看看每一项活动的具体内容。为了清晰展示各项活动的关联关系，下图展示了各项活动在我们熟知 V 流程 中的位置。

◆  ◆  ◆  ◆

任务/目标定义

创造新系统或对现有系统进行修改，都是从任务/目标定义开始，也就是捕获涉众需求。任务或目标定义并不聚焦在特定的待开发系统上，而是在一个更大的背景中识别潜在的需求，这种需求将成为开发某个系统的理由。这种需求通常用系统使用者的语言进行描述，而不是技术语言，很多时候也会包括一定程度的定量描述。一般通过 CONOPS（Concept of Operations）文件来描述待开发系统的任务和目标。

系统架构

系统工程中的架构设计主要是指定义其组成和各部分的关系，通常以示意图（Diagrams）的形式体现.包括在一定环境下的系统高层概念描述、系统的组成部分、系统各部分的交互、系统与环境的交互等。同时，系统架构设计也要描述系统产生的过程和对各备选方案的评估过程，并基于系统需求来定义低层需求，从而将需求分配到各组成部分。

工程实践过程中，我们常常会将待设计的系统或产品按照物理形式进行分解，称为 产品分解结构 PBS （Product Breakdown Structure），同时也会根据任务/目标定义的内容以及需求工程中获取的功能要求进行逻辑分解，形成 功能分解结构 FBS （Function Breakdown Structure），简单直观的可将 PBS 与 FBS 之间的映射关系称为系统架构。

需求工程

即需求生成和管理，通过正式的技术语言对系统的功能、属性以及质量因素等进行阐述，通常叫做“ 需求管理 ”或“ 需求工程 ”，包括对需求的定义、分析、确认和管理。需求工程的输入是任务/目标定义的输出，通过分析、综合、验证的迭代过程将涉众需求通过技术语言进行形式化表示，形成高层需求和底层需求，是需求工程的主要任务。

系统集成

系统集成包含设计、购买和创造各类系统组件，对系统组件进行测试，而系统组件包括硬件、软件或过程。这些组件由于庞大和复杂，而通常也被当作系统看待。系统集成主要完成构建符合预期系统框架要求的系统组件，这部分任务通常由一系列的组装和测试操作组成。

确认与验证

确认，是对开发完成的系统（或像需求和架构这样的开发成果）与系统的预期任务或目标进行比对，即要 确定“做正确的事” ，提供 需求一致性和完整性的证明 ；验证，是通过检查，分析，展示，测试或其他的客观证据，来对系统（开发成果）和需求进行比对，以此来 展示“正确的做事” 。确认和验证是整个系统生命周期过程中需要持续进行的系统工程活动，分析、测试、评审是进行验证的常用方法，追溯、分析、建模、测试、相似性度量（或经验）和评审是进行确认的常用方法。

技术分析

这里的技术分析是指系统级技术分析，尤其是对系统性能满足需求的满足度进行评估；包括性能分析，时序分析，容量分析，质量分析，趋势，敏感度，失效模式和影响性分析等，主要涉及技术性能度量，以及其他类似的对系统配置和组件的多学科评价；除非是与需求工程或系统架构设计不可分割，可能还需要进行功能分析，预测分析，权衡分析等。

这些技术分析一般都是基于不同的系统层级，使用不同的定量建模技术构建不同逼真度的分析模型进行计算和仿真而开展的，是为技术理解和决策提供严格的数据和信息基础的必要手段。

范围管理

采购和供应链问题的技术定义和管理，主要关注与上下游的合同关系：向上是开发合同，对整个系统开发的范围进行定义，主要涉及系统需求，向下是对委托出去开发的系统组件的范围进行定义。

技术领导力和技术管理

技术领导力和技术管理活动主要包括项目策划，技术过程评估，技术控制，团队建设，交叉协同，提供通用语言和目标，风险管理和接口管理等；与项目管理不同的是，技术领导力和技术管理主要关注技术目标和技术指导。

◆  ◆  ◆  ◆

相信通过上面对系统工程典型活动的介绍，我们对 MBSE 有了一个更加直观的认识。

那么，MBSE 和我们以前提到的 MBD 是什么关系呢？ 

简单来说，MBSE 重在跨学科的、基于模型的、不同视角的系统表达，力求为大型复杂系统提供一致的、完整的，相互关联的，贯穿系统生命周期的分层次的系统模型，覆盖和系统相关的问题域与方案域。而 MBD 侧重方案域的特定领域的系统设计与实现。

◆  ◆  ◆  ◆

文章来源：MATlab