Model-Based Systems Engineering基于模型的系统工程 MBSE

基于模型的系统工程（MBSE）是一种对系统建模经济高效的应用，它通过在系统开发早期进行测试和验证，提升对系统属性和行为的了解，并实现需求和设计决策的快速反馈，从而探索和记录系统特性。模型提供了一种高效的，可以探索、更新和传达系统各个方面信息的方式，还能减少对传统文档的依赖。

MBSE历来注重表达和记录需求、设计、分析和验证信息[1]，随着建模技术的成熟，它通过加速学习（例如仿真）和更好地了解物理世界（例如数字孪生）从而提供更多价值[2]，这两者对于持续完善系统和实现企业解决方案都非常重要。

尽管模型并不能完美地展示系统，但它能比直接实施系统建设更早、更经济地提供知识和反馈。模型还能基本准确地模拟出复杂系统和系统间的互动来加速学习。在实践中，工程师使用模型获取知识，并作为系统实施的指南。在某些情况下，他们会在实际执行过程中直接使用模型（例如电气CAD、机械CAD）。

01

细节

精益实践支持通过持续的开发工作流程快速学习，以获得对决策的快速反馈。MBSE是一门学科同时也是精益工具，在使用过程中能够让工程师快速了解正在开发的系统而不会使成本变得过高。

模型用于探索系统元素的结构、行为和操作特性，评估备选设计方案，并在系统生命周期中更早、更快速地验证假设。这对于大型、复杂的系统来说特别重要（如卫星、飞机、医疗系统等），在这些系统中，解决方案必须提前进行可行性验证，如火箭发射升空或治疗首个病人。模型还记录和传达对其他人有用的决策。这些信息可用作合规性文件、影响分析文件以及满足其他需求的文档。在SAFe（ScaledAgile Framework：大规模敏捷框架）中，模型信息被视为解决方案意图的一部分，通常由Enablers创建。

下面的章节提供了MBSE的使用指导。

图 1 MBSE加速学习

02

探索替代方案并加快学习速度 

建模可以支持快速学习周期（参见SAFe原则＃4- 快速稳步建立集成学习周期）并帮助产品在生命周期的早期降低风险。通过测试和验证特定的系统特性、属性或行为，模型促进早期学习，从而在能够在实际决策时快速获取反馈。

模型有多种型态，如动态、实体、图形、方程、模拟和原型等。如图2所示，每种形式提供了一个或多个不同视角的系统特征，并能够创建新的功能和特性。

图 2. 模型和学习周期

模型可以预测性能（响应时间、可靠性）或者物理属性（热量、辐射、强度），也可以根据用户体验或外部刺激设计备选方案。当然，在探索设计备选方案时，除了使用模型之外，也可以采用设计思维和以用户为中心的设计思想与MBSE协同作用来更快地验证假设。

03

模型连接现实与虚拟世界 

数字孪生技术支持MBSE。数字孪生是物理系统的虚拟实例，与性能、功能、维护、NFRs（Nonfunctional Requirements：非功能需求）和系统运行状况等操作数据同步。通过结合物理和虚拟世界的数据可以验证虚拟的模型，并协助工程师改进系统分析，预测故障或停机时间，提供更准确的维护计划。

数字孪生通过更准确地预测未来增强和升级产品的时机，从而支持业务的敏捷性，并提供更精确的解决方案。此外，由于其学习速度快、成本低廉且可靠性高，在发现新商机方面也具有潜力。关于数字孪生的概述，请参见[3]。

04

支持合规性和影响分析

在过去，系统开发中的需求、设计、测试和接口分配等决策通常需要在不同来源中维护，如文件、电子表格和特定领域使用的设计工具。这使得系统文档难以维护和理解。而MBSE采用整体系统方法来管理系统信息和数据关系，将所有信息视为模型。图3展示了一种链接多类模型信息的通用结构。

图 3. 链接跨域模型

可追踪性有助于快速准确地了解需求调整对系统的影响，或在域层次的变动对系统其他部分和需求的影响。例如，在Epic审查流程中，敏捷团队和系统架构师可以利用模型信息进行审查。此外，可追踪性还提供客观证据来处理许多法规和合同遵从性问题，并将数字孪生集成到数字化线程中，从而实现跨系统生命周期内的连接。

精益、不断变化的环境增加了对相关模型的需求。在阶段式的项目中，用手动的方式还能够管理覆盖范围和合规性方面的相关信息，但在鼓励不断变化的敏捷环境中，手动解决方式将难以应对。

05

生成文档

许多产品领域需要应对监管的合规性文档（例如，FAA、FDA）或合同义务文档（例如，政府合同中的CDRL）。通过MBSE系统开发方法，模型将包含大部分合规性文档所需要的信息，并可用于生成必要的客观证据。模型作为唯一事实来源，可以确保各个文档之间的一致性。此外，模型可以根据不同利益相关者创建相应的文档，这些利益相关者可能具有各自的系统视角，或者只能查看子视角信息（例如，供应商）。

尽管所有产品和程序都可能需要正式文件，但建议系统工程师直接向客户/监管机构提供模型，以节省成本。因为工程模型中包含大多数甚至全部信息，足够用于检查和正式审查。

06

构建模型质量

在编辑人员众多、提供信息种类多样的情况下，模型可能会面临一个问题：缺乏适当监管时，多人不断调整导致模型质量下降。因此，系统架构师和团队应该合作定义质量实践（包括模型标准和测试），并确保所有人都能遵守。

以下讨论的质量实践有助于早期学习周期。正如SAFe所指出，“你无法扩展糟糕的代码”，对于系统模型也是如此。通过采用质量实践和强大的版本管理，工程师可以自信地频繁调整模型，并积极参与到实现系统目标的进程中。

07

模型标准

模型标准有助于控制质量并指导团队如何进行最佳建模，包括：

需要捕获的信息（包括合规性所需的信息）

要使用或排除的建模符号（例如SysML）和部分建模符号（例如用例）

解决方案和子系统模型元素的放置位置

应与不同类型的模型元素一起存储的元信息

模型内部或与其他跨学科模型之间的链接

系统中使用的常见类型和维度 

建模工具的属性和配置

协作实践和正确使用不同版本的控制系统

如果需要从模型中生成文档，应尽早定义文档模板，因为它会影响进程中的很多决策。系统设计人员需要知道在哪里存储模型元素，以及可用于查询、文档生成或合规性的所有元数据或链接。最好的做法是尽早创建顶层的、全系统的框架模型，以验证这些使用方案。然后，随着系统的发展，团队再填充模型。

08

创建可测试和可执行的模型

在敏捷软件开发过程中，测试优先的方式可以帮助团队尽早将质量控制融入产品中，不断促进软件迭代。测试优先创建了一套丰富的案例，使开发人员能可靠地进行调整，而不会在系统中的其他位置导致错误。丰富的自动化测试对于构建持续交付流程至关重要。

精益实践鼓励可测试和可执行的模型（如果可行），以减少与下游错误相关的浪费。模型应根据领域或学科所存在的评估标准进行测试： 

用于检测物理和环境问题的机械模型

用于逻辑测试的电气模型

用于边界条件和异常情况测试的软件模型

用于测试系统行为的可执行系统模型

大多数工具提供检查模型或创建脚本的功能来跨模型迭代并识别异常。

需求测试模型

几乎所有系统都采用文本式的需求，而且目前通常需要手动审核。敏捷方法中的行为驱动开发（BDD）定义了功能和故事的自动验收测试。这些测试会一直存在，并在解决方案出现时持续进行验证。虽然BDD对于测试敏捷积压项很有帮助，但其在大规模应用方面还具有一定局限性。不过，还是建议在可能的情况下实现自动验收测试，并确保测试结果与需求一致。

分析和设计测试模型

设计模型可以使用具有静态分析器或“检查器”的工具进行测试，这些工具可以识别偏离标准、常规或预期的内容。团队可以添加自己的规则——模型组织、建模约定和标准、所需的元信息等。如果没有这类工具，可以采用脚本循环检查模型以查找静态模型中的问题。模型也可以动态测试，工程学科的模型会有自己的解决方案来评估质量，也应作为测试实践的一部分加以利用。

可追踪性测试

为确保正确的查询、文档生成和合规性，模型必须符合链接结构的要求。

文档生成

尽管文档生成可能与上述的检查脚本有重叠之处，但文档生成的脚本主要用于确保模型结构适当，并且所有数据都存在，以支持所有文档模板的生成。对于大多数模型而言，调试脚本通常比调试或更新文档模板更容易一些。

文章来源：创景科技