基于MBSE的系统设计和流程合规实例

摘要

Plastic Omnium（简称 PO 公司）为汽车制造商提供塑料燃油系统和减排流体系统。这些产品必须具备定制化能力，以满足不同制造商的需求，同时还要符合 ISO 26262 和 A-SPICE 标准。为满足这些需求，PO 公司采用了一种开发方法：系统功能规格说明基于文档，软件架构设计则遵循 AUTOSAR（汽车开放系统架构）标准。然而，这种方法需要在文本规格说明和软件模型之间进行手动转换，这通常会引发不一致性和可维护性问题。本文分享了 PO 公司引入全套基于模型的方法（MBSE）以解决其原有方法中存在问题的经验教训，并通过开源工具 Papyrus 在实际案例研究中对所提出的方法进行了评估。

1、引言

Plastic Omnium（PO 公司）是全球汽车吹塑燃油系统领域的领军企业。此外，PO 公司还是选择性催化还原（SCR）系统的主要供应商之一，这类系统可助力减少废气中的氮氧化物。自 2006 年起，PO 公司就开始设计由集成传感器、执行器和控制器（包含硬件和软件）组成的控制系统。这类产品具备流体管理功能，如加注、储存、通风、计量、供给和控制等。在产品开发过程中，PO 公司在规格说明、架构定义、集成以及鉴定与认证等方面面临诸多挑战，为此，该公司采用了基于文档的系统工程（DBSE）方法，并借助商业工具支持多个抽象层级的开发工作。

近年来，汽车产品开发的市场趋势对灵活性提出了更高要求。一个完整的系统可能由多个供应商共同参与研发，每个供应商负责传感器、执行器和控制器中一组连贯的子集。为应对这些新的业务场景，PO 公司决定通过将硬件控制器与应用软件解耦的方式来开发其系统。此后，应用软件按照基于模型的汽车开放系统架构（AUTOSAR）进行开发，而其他开发活动仍采用基于文本的规格说明方式。

在开发方法中引入 AUTOSAR 标准面临的一个重要挑战是，需要根据基于文本的规格说明在较低层级进行手动建模。鉴于涉及大量文档和不同的相关方，将规格说明手动转换为 AUTOSAR 模型不仅极为耗时，而且容易出错。由此导致可追溯性链条断裂，进而引发开发过程中的诸多问题，如不符合 ISO 26262 和汽车软件过程改进及能力评定（A-SPICE）标准等不一致性和可维护性问题。为克服这些缺陷，PO 公司自 2013 年起开始逐步采用全套基于模型的系统工程（MBSE）方法，并借助开源工具 Papyrus提供支持。

本文旨在阐述 PO 公司引入 MBSE 方法和工具后，对原有方法所面临挑战产生的影响。MBSE 方法旨在构建一个连贯且严谨的产品端到端开发流程，使可追溯性重新成为核心环节。同时，该方法还致力于更好地满足汽车系统在架构、鉴定和认证方面的要求，以符合 ISO 26262 和 A-SPICE 等标准的建议。该方法的关键组成部分包括建模语言、建模方法和建模工具。PO 公司选择系统建模语言（SysML）来开展系统层面的活动，SysML 是工业领域广泛采用的一种建模语言；软件层面的活动则遵循 AUTOSAR 标准。该方法在 Papyrus 工具中得以实现，Papyrus 是一款支持 SysML 和 AUTOSAR 的开源工具，能够提供模型在不同语言间自动转换和追溯的功能。

本文其余部分的结构如下：第 2 节着重阐述 PO 公司在原有 DBSE 方法中面临的挑战；第 3 节介绍所采用 MBSE 方法的概念组成部分；第 4 节通过实际案例研究对该方法的主要特性进行评估，并在第 5 节中讨论所观察到的结果；第 6 节对全文进行总结，并简要展望未来的发展方向。

2、基于文档的系统工程方法

2.1 基于文档方法概述

为制定和设计满足汽车制造商期望的控制系统，PO 公司一直采用 DBSE 方法。该规格说明和设计流程对应 V 型开发周期的左侧阶段。

如图 1 所示，开发流程通过 5 个抽象层级逐步细化：

· 项目需求层：确定系统目标和需满足的用例；

· 功能技术规格说明（FTS）层：定义系统功能、性能和安全要求以及接口；

· 架构技术规格说明（ATS）层：利用基本架构模块设计系统功能；

· 组件技术规格说明（CTS）层：明确并评估组件范围和技术要求；

· 组件实现层：设计和开发组件。

图 1、PO 公司的 DBSE 方法

DBSE 模式为 PO 公司提供了一个基于开发流程不同阶段的工作环境。在每个阶段，都会制定多种不同类型的文档，以满足客户、设计师、供应商、测试人员等不同相关方的特定需求。文档的结构化和组织方式从两个维度展开：

1. 纵向维度：确保同一文档内抽象层级信息的一致性，例如功能需求与组件需求的一致性；

2. 横向维度：突出同一抽象层级内的特定信息，例如算法描述和变量库。

原则上，根据开发流程，生成的文档在逻辑上是相互关联的。DBSE 方法能够描述不同文档之间以及文档内部所呈现概念之间的可追溯性关系。这些关系不仅可以明确文档的使用方和提供方，还能通过不同的语义（如使用、覆盖、验证等）将它们关联起来。

PO 公司部署了一套基于 IBM 的工具链，该工具链在需求管理、可追溯性、版本发布、评审流程、文档发布等方面提供支持，并尽可能减少手动操作，以更好地执行该方法。

2.2 基于文档方法的局限性

当 PO 公司为应对新业务机遇带来的约束而优化其开发流程时，DBSE 方法在项目规划与时间安排、设计信息规格说明、可追溯性、工具支持、协同工作以及标准合规性等方面暴露出诸多问题。

（1）项目工作流程与规划在 DBSE 方法中，文档是主要的工作成果，也是需求和设计信息的载体。项目团队的工作重心围绕文档流程展开，该流程包括文档的编写、评审、更新和发布等一系列顺序步骤。为了按照项目时间节点发布文档，需要将文档内容冻结。而这些时间节点主要依据业务目标确定，而非需求和设计问题。严格执行这种顺序式的文档流程需要承担巨大的工作量。为缩短延误并按时发布规格说明，团队会将高层级和低层级的活动并行开展。但这一做法需要额外投入精力来维护项目信息的连贯性和一致性。结果导致文档往往延迟制定，且在发布后可能立即过时。由于文档是信息的唯一呈现形式，因此在下次版本发布前，规格说明的更新内容无法及时获取。

（2）设计语义在 DBSE 方法中，规格说明文档以文本形式记录需求和设计信息。出于对文本说明进行补充说明的目的，部分设计方面会通过图表进行展示。但问题在于，自然语言并不适合描述某些设计概念（例如系统架构），而且技术选择可能会被错误地表述为需求。此外，文本信息与图表信息之间的一致性也难以确保：可能会出现过度规格说明的情况，进而给项目带来额外工作，如设计过于复杂、需要额外验证等。

（3）可追溯性DBSE 方法的核心是处理文本表述。由于图表元素不具备可追溯性，高层级与低层级设计信息之间的可追溯性受到极大限制。这使得跨抽象层级的设计分配工作变得困难，进而破坏了系统层面与 AUTOSAR 软件架构之间的连贯性。可追溯性主要体现在文档版本发布环节。当在版本发布间隔期间需要进行变更时，这种可追溯性的局限性就凸显出来，因为可追溯性无法充分支持变更所产生的影响评估。这使得评估完成变更请求所需的时间和成本变得十分困难。

（4）沟通团队沟通主要依靠文档发布来实现，而文档发布与文档版本更新保持同步。根据需求，还会制作额外的图表和演示文稿以支持外部沟通。然而，由于信息分散在多个文档中，或者文档格式未能充分突出关键信息，系统的某些特定方面难以被理解和有效传达。

（5）工具支持DBSE 方法依赖一套商业工具，但这些工具无法完全满足 PO 公司的需求，存在一定局限性。需求管理工具 DOORS用于处理 DBSE 方法中生成的所有文档（如 Word 文档、Excel 表格）（见图 1）。这些文档以树形结构存储，其中一个模块代表一个文档。每个模块包含标题、需求、图表等对象，并依据一个简单的元模型记录与每个对象相关的属性。然而，这些属性是在文档层面直接管理的，可能不符合元模型的要求。

图表在其他环境中编辑完成后，再复制到文档中。文档发布通过发布引擎完成，该引擎能够根据模块内容生成相应的文档。在 FTS 层面，使用商业工具 Plato和 Excel 表格进行安全性分析，同时使用 Matlab进行设计仿真（见图 1）。不同工具之间的集成并不完善，这就需要进行手动数据交换操作。例如，需求管理、设计和故障分析之间的同步工作既耗时又容易出错。此外，工具部署还需要投入大量精力来维护环境的更新。

（6）标准合规性随着市场环境的变化，PO 公司希望更好地符合相关标准。该公司开始按照 AUTOSAR 标准并使用 Matlab 开发其控制系统的应用软件。AUTOSAR 与 Matlab 类似，都基于复杂的元模型，而这些元模型难以与 DBSE 方法相适配。这导致开发流程中出现巨大断层，破坏了整体的可追溯性。有限的可追溯性和工具互操作性，使得 PO 公司难以达到 A-SPICE 2 级标准中关于需求可追溯性的要求。同时，这也成为该公司遵循 ISO 26262 标准中系统开发流程和安全性分析要求的一大障碍。

鉴于 DBSE 方法存在上述种种局限性，PO 公司决定从以文档为中心的方法转向以模型为中心的方法。

3、转向基于模型的系统工程方法

国际系统工程协会（INCOSE）将 MBSE 定义为 “建模的规范化应用，用于支持系统需求、设计、分析、验证和确认活动，从概念设计阶段开始，贯穿整个开发过程及后续生命周期阶段”。这种 MBSE 方法需要一种或多种建模语言、一套开发方法，以及一个实现这些建模语言的框架，该框架最好能根据开发方法进行定制化调整，以提供更好的支持。PO 公司在选择建模语言、方法和框架时，充分考虑了如何使 MBSE 方法能够覆盖从需求规格说明到软件开发的所有工程阶段。

3.1 建模语言

PO 公司在选择建模语言（ML）时考虑了以下标准：a) 建模语言应能够描述需求、结构化和行为化设计以及架构元素的实现；b) 建模语言应能为可追溯性提供通用支持；c) 建模语言应是标准语言，便于 PO 公司工程师学习，从而促进相关方之间的沟通，并更容易招聘到已接受过该语言培训的人员；d) 建模语言应得到现有可靠工具的支持；e) 建模语言应具备可扩展性和可定制性，以适应 PO 公司的流程需求。

在汽车领域，最知名的系统级架构描述语言包括 EAST-ADL2和 AADL。EAST-ADL2 是汽车系统开发领域的实际标准，它提供了用于需求规格说明、系统功能规格说明与设计以及可追溯性支持的相关概念。除语言本身外，还提供了一套规格说明和功能设计方法，并与 AUTOSAR 标准相关联。然而，其行为规格说明仅限于状态机的一个子集，可能无法满足 PO 公司的全部需求。

AADL 主要应用于航空航天领域。与 EAST-ADL2 相比，AADL 为较低抽象层级提供了软件和硬件相关概念，例如包含进程和线程等概念，但这些概念可能与 AUTOSAR 的相关概念不兼容，并且该语言的核心部分不支持需求描述。此外，AADL 和 EAST-ADL2 在工具支持方面都较为薄弱，且扩展和定制能力非常有限。

在文献的一项调查中，统一建模语言（UML）被认为是使用最广泛、工具支持最完善且传播最广泛的建模语言。UML 提供了一种名为 “profile”（概要文件）的标准扩展机制，能够通过领域特定概念丰富语言功能。SysML 就是这样一种 UML 概要文件，它专门针对系统工程对 UML 概念进行了定制，并且还可以通过概要文件进一步定制。SysML 满足 PO 公司对建模语言提出的上述四项标准，因此，SysML 和 AUTOSAR 被选为构建 PO 公司 MBSE 方法的基础。

3.2 建模方法

PO 公司基于 5 个抽象层级定义了其建模方法。规格说明工作在系统技术规格说明（SysTS）模型和功能技术规格说明（FTS）模型中完成；系统设计工作在架构技术规格说明（ATS）模型和组件技术规格说明（CTS）模型中实现；AUTOSAR 实现工作则在软件组件技术规格说明（SwCTS）模型中进行。列出了不同模型的主要目标，以及与之相关的图表和关键模型元素。通过 “实现（realize）”、“满足（satisfy）”、“细化（refine）”、“组装（assembly）” 等可追溯性关系，对上述模型进行追溯。图 4 展示了从 SysTS 到 SwCTS 层级的可追溯性跨领域视图。

图 2：MBSE 方法的组成部分

3.3 建模框架

PO 公司选择 Papyrus 工具来部署其 MBSE 方法。Papyrus 是一款开源工具，提供通用的 SysML 编辑器，支持 AUTOSAR 软件组件模板建模，并能以 ARXML 标准格式导出模型。Papyrus 基于概要文件和特定工具构件（包括模型浏览器、版本控制、源代码控制、模型并发访问、代码和文档生成、库、用户类型管理以及变更请求等）提供高级定制功能。该平台的优势在于能够灵活地与其他工具集成。因此，PO 公司构建了 DOORS 和 Papyrus 之间的网关。由于 Matlab 和 Papyrus 同属基于模型的环境，二者的集成相对更为简便。

4、案例研究

为启动从 DBSE 到 MBSE 的转型，PO 公司组织了多场培训，旨在让团队成员对 MBSE 形成统一的认知。研究选取了 PO 公司此前采用 DBSE 方法开发的选择性催化还原（SCR）系统中的一个典型示例，对其进行重新设计，以评估 MBSE 方法的效果。

4.1 案例研究描述

SCR 系统的主要功能是从储液罐向前排气管路和喷射器输送氮氧化物还原溶液（NRS）流体。该系统需依据储液罐的环境特征（如温度、大气压力等）以及车辆信息（如运行模式、唤醒状态等），为相关部件提供加热和电能。同时，SCR 系统还需监测 NRS 储液罐的温度、液位、溶液质量以及执行器的可用性，并通过通信总线接收车辆信息，同时向车辆反馈相关数据。

4.2 案例研究建模

在 SysTS 层级，通过用例图（图 3（A））对 SCR 系统的任务进行建模。在 FTS 层级的系统描述中，每个用例都对应一个系统功能（SF）（图 3（B）），并通过序列图进一步细化。每个系统功能都包含一个用于描述其行为的状态机图。在 ATS 层级，通过内部块图（图 3（C））将每个系统功能分解为传感模块、执行模块和处理模块。在 CTS 层级，将 ATS 层级的模块组合成机械模块（与物理世界 / 物理定律交互的接口）、硬件模块（传感器 / 执行器）、应用模块（纯软件模块）或驱动模块（需要与硬件进行特定接口交互的软件模块）。

图 3、SysTS、FTS、ATS、CTS、SwCTS 层级的图表示例

这些模块用于构建抽象的硬件 / 软件平台。通过参数图对这些模块进行细化，以实现由执行器指令触发的物理定律相关功能。在 SwCTS 层级，采用 AUTOSAR 复合或原子软件组件概念（图 3（D））来实现 CTS 层级的应用模块和驱动模块。

各抽象层级之间实现了可追溯性（图 4）。在 FTS 层级，系统功能对 SysTS 层级的用例进行细化；在 ATS 层级，系统功能设计实现系统功能；在 CTS 层级，将 ATS 层级的设计模块组装成模块，以构建硬件 / 软件平台，此时算法可作为活动图嵌入到处理模块中；在 SwCTS 层级，AUTOSAR 软件组件实现 CTS 层级的软件模块，并将算法映射到这些组件的可运行实体中。

图 4、从 SysTS 层级到 SwCTS 层级的可追溯性跨领域视图

5、讨论

本节将结合第 2 节中提到的 DBSE 方法的局限性，重点分析 MBSE 方法带来的优势与不足。

5.1 项目工作流程与规划

在 MBSE 方法中，全局模型取代文档，成为规格说明和设计环境。与 DBSE 方法中按顺序进行文档编写的工作流程相比，MBSE 方法下的项目规划约束显著减少。工程师能够在不同层级同时开展工作，设计工作可以更早启动，并通过迭代方式进行评估。可追溯性确保了这一过程中高层级模型元素与其低层级实现之间的一致性。不过，一个意外发现是，按照质量流程将模型转换为文档需要投入额外的发布工作。

5.2 设计语义

SysML 模型及相关图表取代了 DBSE 方法中用自然语言和图示对结构化与行为化设计的描述。研究结果表明，在以往采用 DBSE 方法的项目中，由于不当使用文本需求描述设计方面内容，存在过度规格说明的问题。而 MBSE 方法通过形式化、一致、可追溯且相互关联的模型元素，重新平衡了需求与设计活动的关系。此外，SysML 还通过在内部块图中复用块作为组成部分，有效应对了设计复杂性问题，并促进了设计复用。

5.3 可追溯性

MBSE 方法实现了可追溯性的自动化，这不仅为认证相关问题的论证提供了便利，还有助于保障整体一致性。SysML 的可追溯性关系类型不仅涵盖了 DBSE 方法中所有的可追溯性内容，还实现了重要改进 —— 将可追溯性集成到模型本身之中。该追溯模型确保了从系统描述到 AUTOSAR 可运行实体，在不同抽象层级之间保持可追溯性的连续性。这种可追溯性可用于自动化检查工作，例如验证规则检查、变更影响分析或需求覆盖度分析等。

5.4 沟通

MBSE 方法促进了与所研究系统相关的各相关方之间的沟通。首先，该方法采用 SysML 这一统一的半形式化规范语言，能够同时描述需求、架构设计和行为方面的内容。其次，根据方法需求或设计与沟通需求，可以从同一模型中构建特定视角或补充图表。尽管仍会根据相关方（如客户、设计师、供应商、测试人员等）的需求生成文档，但如今文档发布可根据需要，通过提取模型元素来实现，不再仅仅与项目发布里程碑挂钩。

然而，在使用 SysML 处理技术问题的工程师与文档评审者或审批者之间，出现了新的沟通挑战。为解决这一问题，需要努力简化查看工具中的 SysML，并开发 PO 公司专用的领域特定语言（DSL）。为降低这种技能差异带来的业务风险，PO 公司为员工提供相关培训，并在招聘新员工时将 SysML 技能作为一项要求。

5.5 工具支持

PO 公司部署了 Papyrus 工具来支持 MBSE 方法的实施，并利用该工具的定制功能构建了符合自身需求的工作环境。为简化从 DBSE 到 MBSE 的过渡，PO 公司开发了 DOORS 和 SysML 之间的网关，实现了将现有文本需求导入并替换为新模型元素的功能。PO 公司使用 Papyrus 原生的 SysML 和 AUTOSAR 编辑器，来支持其建模方法所需的各类模型定义工作。

为应对更多需求，PO 公司在系统建模基础上应用了多个概要文件。其中一个专用概要文件能够自动执行符合 ISO 26262 推荐实践的故障分析。另一个插件支持在 SysML 和 Matlab 之间导入和导出模块，并保持两者之间的同步。此外，Papyrus 还支持文档生成，为文档发布提供支持。而且，借助 Papyrus，可为小型专业团队轻松部署专用配置。但要在大型国际团队中大规模部署该工具，还需设立专门的工具链管理角色，并制定相应流程。

5.6 标准合规性

MBSE 方法实现了规格说明、设计和实现各层级之间的顺畅集成。采用该方法后，高层级系统规格说明与其 AUTOSAR 实现之间不再存在断层。在定义和分解过程中持续进行的自动化可追溯性机制，有助于满足 A-SPICE 标准的要求，并遵循 ISO 26262 标准倡导的自上而下的开发方法。

6、结论与未来展望

本文介绍了 PO 公司为控制系统规格说明和设计所部署的 MBSE 方法。该方法基于三个主要组成部分构建：SysML 和 AUTOSAR 建模语言、基于 5 个抽象层级定义的方法，以及支持上述语言和方法的 Papyrus 框架。文中分享了在汽车系统中应用该方法所获得的经验教训。实践表明，凭借增强的设计能力和开发过程中的端到端可追溯性，MBSE 方法成功解决了 PO 公司原有 DBSE 方法中存在的诸多问题。借助 Papyrus 工具，该方法还展现出在集成更多功能（如故障分析、设计仿真、代码生成等）方面的潜力。此外，MBSE 方法在简化流程和产品认证方面也具有良好前景。