摘要

本文介绍了汽车软件架构设计的转型历程，即从使用传统方法和工具链，转变为在 Matlab/Simulink（M/S）的最新版本中采用新的建模功能。我们展示了一种无缝衔接的方法，用于在多核硬件平台上运行的混合关键度电动动力总成控制器的软件架构建模。通过这种方法，我们不仅实现了双向可追溯性和强大的创作过程，还完成了基于 AUTOSAR 系统的详细模型化软件架构设计，包括详细的数据字典。此外，我们还进行了大量的概念验证研究、情景模拟和安全软件的性能优化。在此背景下，我们将通过一个工业案例研究，分享宝贵的经验教训、新颖的见解以及遵循的最佳实践。

1. 引言

在过去十年里，对象管理组织（OMG）推出的模型驱动架构（MDA）被视为软件和系统工程领域的下一个范式转变。模型驱动方法旨在将开发重点从编程语言代码转移到使用特定领域建模语言表达的模型上。这样，模型既能被理解，也能被自动化流程自动处理，或者转换为其他工件。然而，必须承认的是，在行业实际项目中，从基于模型（模型仅作为图表使用）完全转变为模型驱动方法（模型作为核心工件使用）的情况尚未发生。朝着这个方向，我们将探讨汽车领域软件架构的模型驱动工程解决方案的进展。在本文中，我们将讨论汽车行业的实践现状、现有实践的主要缺陷以及我们提出的方法。基于我们在过去十二个月中为一家原始设备制造商（OEM）开发电动动力总成软件的实际项目经验，我们将通过一个工业案例研究，分享宝贵的经验教训、新颖的见解以及遵循的最佳实践。

1.1 汽车组织的实践现状

全球电动汽车（EV）行业持续快速扩张，这得益于对燃油效率高、性能卓越和低排放车辆的需求不断增加。供应链复杂性的提升，与软件实现的日益复杂同步。考虑到这一点，汽车开放系统架构（AUTOSAR）应运而生。它是由汽车制造商、供应商、服务提供商以及汽车电子、半导体和软件行业的公司共同建立的全球开发合作项目。为了实现模块化、可扩展性、可转移性和功能可重用性的技术目标，AUTOSAR 基于标准化接口，为不同层次提供了通用的软件基础设施。在这个过程中，AUTOSAR 采用基于组件的软件架构，用于汽车软件系统的设计和实现。在这种背景下，汽车原始设备制造商（OEM）在基于 AUTOSAR 的模型驱动嵌入式软件工程（ESE）方面，大多数实践分为两个主要领域：统一建模语言（UML）/ 系统建模语言（SysML）领域和 Matlab/Simulink（M/S）领域。

在为 UML/SysML 领域基于 AUTOSAR 的 ESE 提供基于模型的工具支持（如架构设计、自动代码生成）的竞争中，诸如 Enterprise Architect 和 IBM Rhapsody 等 UML 工具脱颖而出，成为领先者。例如，Rhapsody 支持使用原生 AUTOSAR 概念的 AUTOSAR 模型架构描述的相关 SysML 配置文件。然而，汽车行业的实际情况是，UML/SysML 仅在较高的抽象层次使用。例如，UML/SysML 用于创建描述性 UML 模型，以描述整体软件和系统架构（见图 1（1））。在过去十年中，我们是众多汽车组织之一，在为汽车 OEM 客户项目中采用了这种方法。这需要在 UML/SysML 领域投入大量时间培训人员，并且在工具和培训方面投入了大量成本，但结果却不尽如人意。

图1.基于AUTOSAR的汽车嵌入式软件架构建模步骤：（1）汽车原始设备制造商遵循的实践步骤；（2）我们在多核、混合关键电动动力总成控制器的现实汽车项目中的方法（在过去的十二个月里）

此外，尽管这些模型处于较高的抽象层次，但包含这些模型的文档却非常庞大。从这些图表中，需要手动生成更细粒度的规范模型，但并非使用 UML/SysML。这些高层次图表通常用于自动创建 Simulink 框架，在其中，Simulink 代码既可以手动编写，也可以自动生成。尽管这是汽车行业的普遍情况，但有些公司的流程更为简单，对 UML 的使用更少。

而且，汽车软件有很多非功能需求（如时间和内存限制）。在设计这类系统的软件架构时，需要考虑、优化和微调众多此类参数（如 CPU 负载与安全约束）。然而，UML/SysML 工具缺乏对这些非功能需求之间的权衡分析（如性能参数）的支持。此外，在开发安全关键型汽车软件时，双向可追溯性至关重要。虽然存在一些孤立的解决方案，可实现 UML/SysML 工具与需求管理工具之间的可追溯性，但它们并不能作为全面的解决方案，支持双向可追溯性。因此，在汽车软件 / 系统架构设计的工具支持竞争中，UML/SysML 工具仅被视为绘图工具。

1.2 提出的方法

另一方面，M/S 在 2019 年初的最新版本中引入了新的建模功能。鉴于上述差距，我们经历了基于 AUTOSAR 的多核混合关键度电动动力总成控制器软件架构建模的转型，从使用传统方法（见图 1（1））转变为图 1（2）所示的方法。在图 1（2）的方法中：

· 利用 M/S 最新版本中的 AUTOSAR 特定模块集，我们能够实现基于 AUTOSAR 系统的详细模型化软件架构设计，包括详细的数据字典。

· 借助 M/S 最新版本中的 Simulink System Composer 工具箱，我们创建了自定义配置文件，以支持安全软件的权衡分析（如安全性与时间的权衡）。

· 利用 M/S 工具箱支持的强大模拟功能，我们还能够进行大量的概念验证研究和情景模拟。

· 通过使用先进的需求管理工具插件（适用于 Simulink 的 Polarion）和自定义脚本，我们实现了需求与架构设计之间的无缝双向可追溯性，这一过程还得到了全面创作流程的支持。

在此背景下，本文通过一个工业案例研究，分享宝贵的经验教训、新颖的见解以及遵循的最佳实践。本文的其余部分安排如下：在本引言之后，第 1.3 节将简要介绍机动车辆的电动动力总成（作为贯穿全文的示例）。第 2 节介绍背景和相关工作。第 3 节讨论传统方法的缺陷和新方法中遵循的最佳实践。第 4 节讨论新方法中的经验教训。第 5 节进行总结和得出结论。

1.3 电动动力总成示例

本节简要介绍电动动力总成，它将作为本文的一个示例。机动车辆的动力总成由产生和传递动力的主要部件组成（即为车辆提供动力）。动力总成的最新发展，得益于多个部件的电气化。全电动汽车完全摒弃了内燃机（ICE），这意味着它们完全依靠电动马达来驱动。电动动力总成的主要部件包括电池组（提供直流电）、电动马达、车载充电器、电池、热管理系统以及 AC-DC/DC-DC 转换器。

图2:全电动汽车中的典型部件

电动动力总成软件具有不同的汽车安全完整性等级（ASIL）关键度，范围从 A 到 D（D 为最高关键度）。此外，该软件在多核硬件平台上运行，这种平台在汽车领域的应用越来越广泛。电动动力总成系统由液冷高压逆变器驱动和控制。在我们的实际客户项目中，动力总成的逆变器控制软件最初采用传统方法开发，后来改用 M/S。第 3 节和第 4 节将使用该项目中的示例。不过，本文中使用的图表并非实际项目的原创内容，而是其等效表示。

2. 背景和相关工作

第 2.1 节介绍了汽车嵌入式软件系统建模替代方案的背景和相关工作。第 2.3 节介绍了需求管理（RM）的背景和相关工作。

2.1 汽车嵌入式软件系统建模

如今，一辆现代汽车中集成了多达 100 个由不同制造商开发的电子控制单元（ECU，一种控制车辆中一个或多个电气系统或子系统的嵌入式系统），而且 ECU 软件也变得越来越复杂。为了应对这类系统开发中日益增加的复杂性，模型驱动开发（MDD）被视为下一个范式转变。在 MDD 中，需求在较高的抽象层次被指定为模型（例如，使用 UML/SysML、M/S）。然后，通过模型转换，从较高抽象层次逐步细化到较低层次。需要注意的是，除了 UML/SysML 和 M/S 领域，Rubus 组件模型（RCM）和 EAST-ADL 也是车辆领域中一小部分人使用的解决方案。

2.2 使用 UML 和 SysML 的建模与基于仿真的技术

在采用模型驱动方法和使用基于仿真的技术方面，过去十年里人们付出了巨大努力，以简化使用 SysML 模型开发和仿真复杂系统的过程。

在文献中，提出了一种基于软件即服务（SaaS）的自动化框架，用于从系统模型构建和执行分布式仿真。文献提出了一种模型驱动的分布式仿真工程方法。该方法围绕 “DSEEP” 标准定义的开发过程构建，应用于基于高层架构的分布式仿真，并专注于一系列自动模型转换。文献中使用的案例研究，基于将该方法应用于开发基于高层架构的空间系统分布式仿真的示例。

2.2.1 用于基于 AUTOSAR 架构建模的 UML/SysML 工具

UML/SysML 工具，如 EA、Rhapsody 等，在软件开发过程中已经得到广泛应用。有时，建模指南遵循自定义建模，例如使用特定的配置文件。例如，Rhapsody 支持使用原生 AUTOSAR 概念的 AUTOSAR 模型架构描述的相关 SysML 配置文件。然而，汽车行业的系统架构师对这些配置文件的抱怨是，它们不够全面，无法捕获基于 AUTOSAR 的软件系统的所有设计工件。因此，在汽车行业的实际实践中，UML/SysML 工具仅在较高的抽象层次使用。它们主要用于创建描述性 UML 模型，以描述整体软件和系统架构。然后，这些高层次模型用于在其他开发工具（如 M/S）中创建更细粒度的规范模型。

UML 除了支持通用的系统和软件建模外，还支持使用特定的配置文件进行性能分析（例如，时间、能量和安全性）。文献中提供了一些使用 UML 进行 MDD 并检查诸如定时和可靠性等质量属性的示例。在文献中，讨论了一种在基于 AUTOSAR 的汽车嵌入式软件系统中早期合成定时模型的方法。在这项工作中，工作流程建议使用 AUTOSAR 定时规范在 Rhapsody 中创建带定时注释的 AUTOSAR 模型。

2.2.2 用于基于 AUTOSAR 架构建模的 Matlab/Simulink（M/S）工具

M/S 是一种使用非 UML 建模语言的流行建模工具。它在工业领域，包括汽车行业，都是一种成熟的工具，尤其专注于基于物理的建模和控制回路。现代汽车的混合动力系统是复杂的多领域系统。由于 M/S 提供了广泛的基于模型的设计能力以及用于仿真的模块集，它似乎成为了在单一环境中捕捉电气、机械、液压部件以及控制系统的理想工具。

在这种背景下，M/S 最新版本中的新建模功能，如 AUTOSAR 模块集和 Simulink System Composer 工具箱，为基于 AUTOSAR 的系统增添了复杂的系统工程能力。然而，总体而言，关于这些新功能的适用性和使用方法，目前还没有相关研究发表。在此背景下，本文首次将 M/S 工具箱的新功能应用于基于 AUTOSAR 的电动汽车动力总成架构建模的前沿实际项目中，并概述了所学到的经验教训和涉及的最佳实践。

2.2.3 AUTOSAR 框架

汽车领域一种很有前景的方法是对用于 ECU 开发的软件架构进行标准化。汽车行业广泛使用的一个全面且成熟的解决方案是 AUTOSAR 标准。它强调将 ECU 开发从以 ECU 为中心的方法转变为基于功能的方法。

AUTOSAR 采用基于组件的分层软件架构，其核心建模元素称为软件组件（SWCs 或 SW-Cs ）。SWCs 描述了一组完整、自包含的功能。AUTOSAR 方法描述了开发过程中涉及的各个步骤，即系统配置、ECU 配置和组件实现。它还描述了在这些步骤中创建和交换的工件。在这些步骤之间，ARXML 文件格式用于开发工件的交换，这是一种基于 XML 的文件格式。基于功能的方法旨在首先在所谓的系统配置中指定整车的功能，然后提取规范供供应商实现 ECU。通过这种方式，汽车软件可以在功能层面而不是 ECU 层面进行互换，从而提高了其可重用性。

图3.将软件组件映射到ECU

图 3 展示了 AUTOSAR 框架的各个组件，以及在系统配置步骤中软件组件到 ECU 的映射。软件组件（见图 3 顶部，如 SW-C1）用于构建 AUTOSAR 模型，并将功能分组到各个组件中。这些组件可以相互连接，而无需考虑它们将在何种硬件上运行。这由虚拟功能总线（VFB）来处理，它为 SWC 之间的通信提供了一个抽象层。然而，分布在不同 ECU 上的组件可能会使用网络总线进行通信。这由运行时环境（RTE）自动确定，RTE 是软件组件的通信接口。

图 3 的下部展示了在系统配置步骤中 ECU 到 SWC 的映射。在这里，可以看到 ECU 1、2、...、n 通过网络总线（如 FlexRay、CAN）进行通信。在每个 ECU（例如图 3 下部的 ECU 1）中，RTE 在 SWC（例如 ECU 1 中的 AUTOSAR SW-C 1 和 AUTOSAR SW-C 2）之间以及 SWC 与基础软件（BSW）之间提供接口。此外，它还向 SWC 提供 BSW 服务（作为 API 抽象）。

实现给定需求的底层软件功能包含在 SWC 中。这些功能随后由软件开发人员手动实现。RTE 和基础软件（BSW）由第三方 AUTOSAR 软件供应商提供，供开发人员用于通信和硬件抽象。应用程序和传感器 / 执行器 SWC 的内部功能在内部行为元素中定义。它们封装了可运行实体，这些实体在代码层面对应于原子函数，将在开发过程的后续阶段实现。在文献 [30] 中，提出了一项关于电动汽车电池感知汽车气候控制的设计与分析的研究。然而，目前在文献中还没有关于电动汽车部件（如动力总成）基于 AUTOSAR 的系统架构建模过程中涉及的最佳实践的讨论。

2.3 需求管理（RM）工具

需求管理（RM）工具，如 DOORS、Polarion 和基于 Eclipse 的 ProR，都是一些先进的 RM 工具。这些工具在管理需求方面比文本编辑器强大得多。在这些工具中，需求像面向对象编程（OOP）中的对象一样被处理。此外，需求交换格式（ReqIF）已成为需求领域中在 RM 工具之间交换需求的标准。在 ReqIF 文件中，需求存储为 SpecObjects，需求类型存储为 SpecObjectTypes，链接存储为 SpecRelations。在实际应用中，ReqIF 甚至允许不同细化级别的需求，如用户需求和系统规范，由不同的合作伙伴在不同的 RM 工具中进行管理。

然而，建立从需求到设计、实现和验证工件的可追溯性可能是一项具有挑战性的任务。例如，在对汽车用例进行架构设计建模时，需求存储在 RM 工具（Doors、Polarion）中，而架构设计则在诸如 M/S、Rhapsody 或 Enterprise Architect 等工具中。因此，需要与 MDD 工具兼容的专用工具插件来建立双向（向前和向后）的需求可追溯性，也称为双向可追溯性。

双向可追溯性是所有过程评估和改进模型的关键概念。可追溯性有助于影响分析和变更管理 —— 当需求发生变化时，更容易识别受影响的工作项。一个好的软件工具应该能够指定、相互链接、分析、管理、显示和报告需求可追溯性，在整个开发过程中提供清晰的可见性。该工具可以轻松识别某个需求是否是孤立的、不相关的，例如，如果它是由于缺少上游需求而成为孤立项，或者缺少对下游需求的覆盖。在与安全相关的项目中，满足需求可追溯性有助于确定产品的安全案例是否已经达成。

尽管存在用于 EA 的 RM 插件，但我们使用 EA 作为软件架构建模工具来绘制 UML/SysML 图，然后手动将它们发布到需求数据库中。因此，在采用传统方法时，我们手动将 UML/SysML 图存储在 Polarion RM 工具中。在我们的新方法中，我们使用了适用于 M/S 的 Polarion 扩展，以建立双向可追溯性和创作功能。由于传统工具链不太适合符合 AUTOSAR 的架构，我们无法借助它实现需求到架构之间的双向可追溯性。

3. 传统方法的缺陷和新方法的最佳实践

在本节中，我们按照第 1 节中讨论的内容，将传统方法的缺点分为三大类进行探讨。相应地，第 3.1 节讨论了传统方法中对基于 AUTOSAR 的软件架构建模的工具支持方面的不足，以及新方法（见图 1（2））是如何克服这些不足的。接下来，第 3.2 节详细讨论了一个使用 M/S 工具进行性能权衡研究的新示例，该示例有助于在配置程序流监控时进行系统架构设计决策中的权衡分析。在第 3.3 节中，我们讨论双向可追溯性。

3.1 基于 AUTOSAR 的软件架构建模

3.1.1 使用 SysML/EA

嵌入式汽车应用中的数据字典用于存储支持功能和软件开发的数据元素和定义。一个强大的基于模型的开发过程应该由一个数据字典驱动，该数据字典能够与支持基于模型环境的工具进行交互，并在开发过程的不同阶段之间提供链接。数据字典可以显著提高建模、验证和编码阶段的自动化程度。鉴于汽车系统是高度复杂的系统，其端口和接口数量可达数千个，在系统架构设计阶段对数据字典的支持显然是至关重要的。

AUTOSAR 为使用 UML 工具（如 EA）对 AUTOSAR 基础软件（见图 3 下部）进行建模提供了指导方针。遵循这些指导方针并采用传统方法，我们最初在 EA 工具中开发了动力总成系统架构设计。图 4 展示了一个使用 EA 中的 SysML 创建的电机控制静态架构设计示例。

图4.在EA中使用SysML进行架构设计

然而，如图 4 所示，其中仅列出了 SysML 模块和端口的名称，没有明确定义的数据字典。这不仅对系统架构师不利，对整个软件开发团队也是一个很大的劣势，因为他们无法在系统架构的同时随时获取关键的软件开发数据。

3.1.2 使用 M/S 中的 System Composer 和 AUTOSAR 模块集

另一方面，在我们的新方法中，使用 M/S 工具中的 System Composer 和 AUTOSAR 模块集对相同的系统架构进行建模。在这个示例中，可以清楚地看到对数据字典的支持（见图 5 插图中突出显示的部分）。

图5.在具有数据字典的M/S中使用System Composer和AUTOSAR块集进行架构设计

所有端口的详细信息，以及必须实现的端口类型（在此示例中为布尔型）都可以获取到。因此，我们不仅能够生成完全符合 AUTOSAR 标准的系统 / 软件架构设计，还能对其数据集进行明确的定义，使其在代码开发活动中清晰可用。

通过图 4 和图 5 中的示例，我们展示了在 SysML/EA 工具中，只能定义没有接口名称且没有数据字典的静态架构模型。这意味着使用 EA 工具的 SysML 建模能力可能适合通用的架构建模，但不适合高度详细和精细的 AUTOSAR 架构建模（即从软件架构师的角度来看）。根据汽车软件性能改进和能力确定（ASPICE）过程模型，我们清楚地认识到，即使在架构建模阶段（在 ASPICE 术语中为 SWE.2），架构师也有必要部分或完全定义数据字典信息。这对于在软件集成测试（在 ASPICE 术语中为 SWE.5）的验证阶段验证软件架构至关重要。

只有当架构师在 SWE.2 阶段提供数据字典部分时，验证工程师才能编写测试用例。例如，在软件集成测试期间，验证工程师必须检查有效数据范围。显然，只有当建模环境提供这种可能性时，这才是可行的。否则，就必须使用需求数据库手动记录。如果是这种情况，验证工程师在编写每个测试用例时，通常都需要与软件架构师进行跟进。显然，这不是一个有效的解决方案，而这正是我们采用传统方法时的情况（见图 1）。因此，在上述情况下的最佳实践是：

· 最佳实践 - 1（BP - 1）：在 M/S 的最新版本中，使用 AUTOSAR 模块集和 System Composer 工具箱对基于 AUTOSAR 的系统架构进行建模；

· 最佳实践 - 2（BP - 2）：利用 Simulink System Composer 对数据字典的支持，创建精细的 AUTOSAR 架构模型。

3.2 早期基于模型的性能分析

在电动汽车中，设计现在围绕电池和一个或多个电机展开，而不是内燃机。因此，设计空间比以前更大、更多样化。由于这些车辆中不同物理因素相互影响的方式，工程师需要从系统层面进行分析和仿真。这意味着工程师需要在系统层面更多地关注复杂性，并在早期设计过程中将越来越多的系统结合起来。

对于像电动动力总成这样的复杂系统的架构设计，选择合适的设计参数、做出早期设计选择以及优化各种参数（如能量与时间、CPU 负载与安全约束）是一项至关重要且具有挑战性的任务。这些是在使用我们提出的方法进行系统架构建模和设计的早期阶段可以分析的假设情景的一些示例。接下来，我们介绍基于 AUTOSAR 的系统中的一种功能安全机制 —— 程序流检查的概念。我们讨论一个涉及 AUTOSAR 看门狗管理器（WdgM）的程序流检查（也可互换地称为逻辑监控）中的时间开销计算场景。

3.2.1 AUTOSAR 看门狗管理器（WdgM）

看门狗管理器是 AUTOSAR 标准化基础软件架构服务层中的一个基础软件模块。WdgM 能够监控程序执行，抽象掉硬件看门狗实体的触发。当 WdgM 检测到程序执行违反配置的时间和 / 或逻辑约束时，它会采取一系列可配置的措施来从故障中恢复。这里，我们以逻辑监控为例，它是检查嵌入式系统软件正确执行的一种基本技术。

3.2.2 被监控实体、检查点和程序流图

被监控实体是 WdgM 模块的监控单元。被监控实体中的重要位置被定义为检查点。当被监控实体的代码到达一个检查点时，它会调用 WdgM。对于每个逻辑监控，都有一个由转换连接的检查点图。该图为 WdgM 模块抽象了被监控实体的行为。检查点和转换构成了被监控实体的程序流图。这些图在 WdgM 的配置过程中静态定义，从而表示被监控代码的执行顺序。在运行时，当被监控实体到达一个检查点时，它会调用 WdgM API。然后，WdgM 会验证从任何初始检查点开始到任何最终检查点结束的接收检查点序列是否正确。因此，WdgM 通过这个图跟踪检查点，以确定执行序列的有效性。请注意，在 AUTOSAR 基础软件配置和系统架构设计中，检查点的配置是通过诸如 DaVinci 配置器等工具完成的。

3.2.3 检查点的粒度

检查点的粒度不是由 WdgM 固定的。例如，这由系统架构师在系统设计阶段决定。在被监控实体的控制流中，每当到达一个检查点时，相关活动就会报告给 WdgM，这会导致一个（访问）时间开销。较少的粗粒度检查点会限制 WdgM 的检测能力。而高粒度的检查点会导致 WdgM 的配置复杂且庞大，从而也会引入显著的时间开销。因此，在系统设计的早期阶段，在系统架构中配置一个（帕累托）最优数量的检查点至关重要。执行这项活动时，要确保检查点的粒度不会限制 WdgM 的检测能力，同时也不会导致显著的时间开销，使被监控实体错过截止期限。在这种情况下，错过截止期限可能会损害系统的功能安全方面（例如，导致错过容错时间间隔 - FTTI）。

3.2.4 电池管理系统示例

在电动动力总成中，电池管理系统组件集成了能够计算电池参数（包括电池单元电压、电池温度和电池电流）的不同组件。为了提高实际应用中的状态跟踪能力，必须对这些参数进行测量和控制。在此背景下，让我们考虑图 6 中电池管理系统中一个温度控制模块（也称为任务）的示例，该模块包含几个功能（也称为可运行实体）。为每个可运行实体（即任务中的功能）分配一个检查点，会导致有八个检查点（请注意，这里始终需要一个入口和一个出口检查点，这是配置工具的限制），如图 7（2）所示。图 7（3）展示了可能的正确程序流序列。请注意，转换 T1...T9 指定了检查点之间的程序流。图 7（4）以矩阵形式展示了图 7（3.1） - （3.3）中可能执行序列的转换。对于这个示例，我们假设每个检查点的访问需要 5 毫秒的访问时间。

图6.使用ProgramFlowCheck配置文件对程序流检查参数进行基于模型的配置

图7.温度控制模块的程序流监控配置（1）：该模块（任务）中的功能（可运行），（2）：受监管实体的可能检查点，（3）：受监控实体的可能执行顺序，（4）：由它们之间的转换表示的功能/CP的依赖关系；以确定可能的（正确的）执行顺序

3.2.5 使用 Matlab 脚本进行估计

凭借强大的计算引擎和数据结构，M/S 能够以一种直接的方式进行此类计算。图 7（3.1） - （3.3）中执行序列的总检查点访问时间估计分别为 25 毫秒、25 毫秒和 30 毫秒。请注意，对于这样一个小示例，也可以手动计算。然而，对于涉及数百个组件的复杂架构设计，可以使用用 Matlab 编写的脚本，利用其强大的计算引擎来进行计算。在我们简单的 Matlab 脚本中，我们使用一个 n * n 矩阵来表示每个正确程序流序列中的检查点，以估计这个温度控制任务的总检查点访问时间。

3.2.6 基于模型的估计

对于上述示例，我们还使用自定义配置文件和构造型，借助新引入的 SC 工具箱对检查点访问时间进行了基于模型的估计。对于这个示例，我们创建了一个 ProgramFlowCheck 配置文件，这是一个自定义配置文件，包含诸如 NrOfCheckPoints、NrOfPossibleExecSeq、PossibleExecSeq 和 CPAccessTime 等构造型，如图 6 所示。

使用 SC 工具箱创建的配置文件可以导出并保存为 XML 文件，以便在任何项目中导入。使用上述示例中三个不同任务（即 TemperatureControl、BatteryCurrentCheck 和 CellVoltageCheck）的输入参数，我们估计了每个任务以及每个任务的每个程序流序列的检查点访问时间开销，如图 8 所示。系统 composer 工具箱中规范 API 的 iterate 方法用于遍历模型的每个元素，并使用构造型属性运行分析。这是一种高度可扩展的方法，如果需要，可以通过迭代更改配置参数来使用（例如，从硬件测量 / 测试中获取的检查点访问时间）。

图8.每个程序流序列、每个任务的CP访问时间

在如此早期的阶段（即在此处的配置阶段）确定时间开销，使系统架构师能够在满足任务的时间截止期限与为任务启用精细的程序流监控之间做出明智的权衡决策。这是系统架构设计过程中需要解决的一个极其关键的问题，因为检查点的粒度及其带来的开销绝不能导致错过截止期限，否则系统将无法进入安全状态。

与上述方法相比，在传统方法中，可以创建这样的自定义配置文件，并且可以使用性能属性对 UML/SysML 模型进行注释。然而，UML/SysML 建模工具缺乏强大的计算引擎等功能。因此，这些带有注释的性能模型必须以某种格式（例如 Excel 文件、XML 文件等）导出到性能分析工具中，才能进行性能分析。在文献中，可以找到关于在特定工具中合成此类性能模型以进行性能分析的内容。

3.2.7 项目概念阶段的示例

在这个客户项目的概念阶段，我们被要求向 OEM 展示并讨论我们围绕 AUTOSAR 和多核挑战的技术概念。一些具有挑战性的概念包括核心之间的诊断事件管理（DEM）以及不同安全级别核心（从 QM 到 ASIL D）之间的非易失性内存（NVM）存储概念。所有这些概念都与诸如功能安全和时间约束等非功能属性相关。借助系统 composer 和 AUTOSAR 基础软件模块对自定义元模型的支持，我们能够对这些非功能属性进行建模（例如，通过在系统 composer 的构造型和配置文件中指定它们），类似于 3.2.6 节中程序流检查的示例。

此外，M/S 还支持广泛的仿真和分析。在传统方法中，这是一个缺失的功能。在新采用的方法中，仿真和分析在更大程度上有助于在开发的早期阶段发现非功能属性缺陷。最后，整个方法有助于更便捷地生成定制化的软件架构文档，推动软件设计以及开发生命周期的后续阶段。因此，上述情况下的最佳实践是：

· 最佳实践 - 3（BP - 3）：使用自定义配置文件（例如，利用 M/S - SC 工具箱）对非功能需求进行早期基于模型的性能和权衡分析。

3.3 双向可追溯性

ASPICE 是国际认可的过程模型，为汽车行业的软件和嵌入式系统开发定义了最佳实践。它提供了改进软件开发过程和评估供应商的指导方针，在汽车行业被广泛采用。在 ASPICE 中，过程性能数据的衡量标准是在开发的每个阶段都有明确的输入和输出工作产品。因此，遵循 ASPICE，在基于模型的架构系统设计中，输入是需求规范，输出是基于模型的架构设计。此外，ASPICE 列出的最佳实践之一是在软件需求和（基于模型的）软件架构设计元素之间建立双向可追溯性。因此，需要在需求管理工具（如 DOORS、Polarion）和基于模型的系统架构设计工具（Rhapsody、Matlab/Simulink）之间使用工具插件，以实现双向可追溯性。

在传统方法中，我们使用基于模型的软件架构建模工具绘制图表（如 EA），然后手动将其导入需求数据库。通过这种方法，我们无法在需求和架构设计之间建立双向可追溯性，尤其是在 AUTOSAR 环境中。这是因为传统工具链本身并不适合符合 AUTOSAR 标准的架构。

在需求分析阶段，通常一个工具允许用户从利益相关者需求文档或通过 ReqIF 导出从客户需求数据库创建各种类型的需求，如软件需求、系统需求、电气需求等。虽然我们创建了需求，但推进需求开发的典型期望是需求数据库与架构和设计环境（建模工具）的连接和同步程度，以及建模工具在将模型发布到需求数据库并在建模环境中跟踪需求方面的支持程度。

图9.需求可追溯性需求数据库具有可导航链接，用于跟踪驱动模型中相应架构块的所有需求。此外，该块列出了与软件组件（SWC1）对应的所有需求，从建模环境中，我们可以追溯到需求数据库

如图 9 所示，建模环境提供了到需求数据库的可导航链接。此外，我们能够在需求分析阶段输入注释和状态，或对需求的任何修改进行审批，从而在数据库中实现适当的通知和维护。作为一种良好实践，该工具会将可追溯性信息导出到报告中。无论工具多么优秀，只有在充分理解并完全应用其功能时，才能发挥其最佳作用。需求管理工具还确保所有用户按照指定的配置以及工具中实施的流程遵循相同的需求流程。

3.3.1 发布和编写

借助适用于 Simulink 的西门子 Polarion ALM 连接器，我们能够直观地在双向将众多需求与基于模型的架构进行链接并跟踪（见图 10）。这种无缝的方法还帮助我们将软件架构从设计环境无缝发布到需求数据库。在汽车项目的概念阶段，需求更新是常见的情况，此时可以轻松将更新后的需求推送到设计中。同样，更新后的架构也可以发布回需求数据库。此外，这个插件为我们提供了双向编写和更新过程，同时轻松建立双向可追溯性，而这在传统方法中是无法实现的。

3.3.2 使用 ARXML 架构进行基础软件配置

市场上有几种 AUTOSAR 基础软件配置工具，如 DaVinci 工具链。配置架构可以导出为 ARXML 文件，并在基础软件模块有更新时导入到 M/S 中，以实现无缝集成和更新。在 EA 中无法实现这样的无缝集成。

图10.新方法中实践的架构模型创作和更新提供了一种将设计发布到需求数据库的无缝方式。此外，对于现有需求，它提供了一个链接它们的选项。每当模型因项目的成熟而更新时，刷新选项都可以将相同的模型更新到需求数据库中。相反，在需求数据库上更改的任何需求属性都可以很容易地推回到建模环境中

在 SWE.2 软件架构设计阶段，软件架构师提出软件组件架构设计，包括接口（输入和输出列表）、预期的动态行为（SWC 周期、优先级约束等）、内存分配和预算。借助所提出的方法，架构师可以将上述信息全部或部分以架构设计的形式提供，这些设计可以进一步导出为 ARXML 文件。在传统方法中，我们找不到导出为 ARXML 的选项。然后，组件 SWC 的这个 ARXML 文件可以导入到 DaVinci 开发者（或类似的 AUTOSAR SWC 导入器）中，将上述架构细节传达给开发者。

对于开发者来说，这是一个非常有益的工作流程，因为他们可以收到关于接口（以及数据字典）和 SWC 动态行为的所有必要信息。通过这种方式，所提出的工作流程显著减少了开发时间。相比之下，在使用传统方法时，开发者需要花费大量时间来理解架构方面的考虑因素。因此，从上述情况中吸取的经验教训得出的最佳实践是：

· 最佳实践 - 4（BP - 4）：采用支持数据字典的高级系统和软件架构建模的无缝方法，有助于在建模环境和需求数据库之间建立双向可追溯性。在两个环境之间来回跟踪需求，以验证需求是否得到满足；

· 最佳实践 - 5（BP - 5）：在需求管理工具（Polarion）和系统架构设计工具（M/S - SC）之间使用先进的插件，将需求和设计发布到需求数据库中。此外，每当由于技术分析和讨论而进行更改时，该方法能够更高效地更新需求和设计；

· 最佳实践 - 6（BP - 6）：在架构建模环境与基础软件（BSW）配置和开发工具链之间导入和导出 ARXML 文件，以减少架构考虑因素的模糊性并缩短开发时间。

4. 经验教训

汽车行业使用所谓的样品（A、B、C……），将开发中的组件作为功能逐渐增强的原型，并集成到测试车辆中。作为供应商，在 A 样品阶段，我们通常需要向 OEM 交付功能有限、成熟度较低的功能原型。A 样品阶段平均持续一年，在此期间，我们与 OEM 就电动汽车动力总成项目的架构建模、分析和设计概念进行了一系列讨论。在这个阶段很明显，我们在传统方法中使用的 UML/SysML 工具无法用于展示我们设计方法的概念验证。另一方面，使用来自两个不同领域的工具，即使用 UML/SysML 工具进行高级架构设计，使用 M/S 进行详细设计和分析，会导致模型之间的差距。随着 M/S 中系统架构建模能力（AUTOSAR 工具箱、Simulink System Composer）的引入，我们采用了新的方法，即使用单个工具（M/S）进行系统架构和详细设计的建模。

在单个工具中拥有整体系统架构和详细设计，帮助我们使用一个全局模型进行了多项早期基于模型的性能和视角分析。在设计复杂系统（如电动汽车动力总成）时，有多个利益相关者，他们的观点需要得到满足。例如，安全工程师在这样的系统设计中的目标和保证是为 ASIL - D（最高关键度）组件纳入 100% 的程序流检查。而控制工程师的目标可能是，例如，使控制参数的稳定时间最短且超调时间减少。软件工程师的观点则是交付一个 CPU 负载低于多核硬件中某个核心 70% 的调度软件。

在这种情况下，我们进行的早期基于模型的程序流监控分析（见 3.2.6 节），这是安全工程师的视角分析，让我们能够估计每个任务的每个有效程序流序列的总 CP 访问时间（见图 8）。然而，在专门的时序分析工具中进行的时序分析结果表明，一个温度控制任务（图 8 中的任务 2）未能满足截止期限。这是因为总 CP 访问时间为 30 毫秒，超过了该温度控制任务总 CP 访问时间允许的 20 毫秒预算。

在上述场景中，温度控制任务是一个 ASIL - D 任务，必须为其配置程序流检查。然而，我们还必须确保总 CP 访问时间不超过 20 毫秒（这是允许的预算；但在图 8 中任务 2 的总 CP 访问时间为 30 毫秒）。为了满足不同利益相关者的观点和目标（在这种情况下是安全工程师和软件工程师），这个 ASIL - D 任务被替换并分解为两个 ASIL - A 任务。ASIL - A 任务的关键度较低，不像 ASIL - D 任务那样必须进行程序流检查。如果我们在早期设计阶段就进行了 3.2.6 节中描述的基于模型的性能分析，就可以避免这个问题。因此，早期基于模型的性能和视角分析使我们能够满足多个利益相关者的观点和保证。在某些情况下，这样的解决方案可能是帕累托最优解（例如，时间与安全的权衡），但仍然是一个可接受的解决方案。

在 B 样品阶段，供应商需要交付功能齐全、基本成熟且具有完全可驾驶性的原型。同样，在 C 样品阶段，供应商需要交付使用批量生产工具制造的完全功能样品。有几种 AUTOSAR 编写工具（AAT），如 DaVinci 配置器和 Electrobit 的 EBTresos studio。在电动汽车动力总成项目的所有样品阶段，我们都使用 DaVinci 配置器进行基础软件（BSW）配置。采用所提出的方法的主要优势在于，我们能够通过两个工具生成的 ARXML 文件链接到基于模型的开发工具。AUTOSAR ARXML 导入器将 AUTOSAR 软件组件描述文件导入到 Simulink 模型中，反之亦然。导入器为每个导入的 AUTOSAR 软件组件创建一个初始的 Simulink 表示，并将 Simulink 模型元素初始默认映射到 AUTOSAR 组件元素。这个初始表示为进一步的 AUTOSAR 配置和基于模型的设计提供了起点。对于源自 Simulink 的设计，我们能够在 Simulink 中为导入的 ARXML 文件组件开发组件设计和行为。借助 ARXML 文件对 AUTOSAR 编写工具和 M/S 的这种集成和链接，使我们能够无缝地满足（B 样品和 C 样品）项目的截止日期。相反，我们在传统方法中用于该项目系统架构建模设计的 Enterprise Architect UML/SysML 工具没有这样的功能。

最后，可追溯性在定义、培训、评审和软件工具方面都需要付出努力。然而，在如此复杂的项目中，双向需求可追溯性的好处远远超过了投入，这对汽车产品开发至关重要。此外，ISO 26262 标准对安全相关项目强制要求可追溯性。在我们的电动汽车动力总成项目中，使用 Polarion 工具和 M/S 实现的双向需求可追溯性和编写过程，为我们组织的各个层级提供了统一的开发流程，以及用于明智决策的实时数据。因此，由于所有需求都与最终确认相关联，没有任何需求被遗漏。不仅可以动态分析变更请求的影响，还可以检查产品（A、B、C…… 样品）是否满足所有需求。这成为了衡量电动汽车动力总成产品交付准备情况的一个指标。需求流程和需求管理过程是提高产品质量的关键要素，同时确保通过所需的验证方法实现并涵盖功能安全产品的目标。拥有一个良好的需求管理系统作为质量流程，可以帮助组织实现更高的目标，如 ISO 9001 认证。

5. 总结和结论

解决复杂性约束的标准方法是对系统的部分进行建模，一旦理解了这部分，就有助于解决问题。这样一个系统的描述性模型（例如，使用 UML/SysML）可以以直观易懂的方式提供系统的高级概述。这在软件工程和其他学科中得到了广泛应用。这种方法已成功用于对高度复杂的软件系统进行建模，如航空航天和国防领域。另一方面，在基于 AUTOSAR 的汽车领域，缺乏这样广泛的案例研究，特别是专注于具体实际项目的研究。

然而，一个显著的缺点是，这种方法对于复杂系统（例如，汽车系统）效果不佳，因为系统过于复杂，无法完全或准确地进行描述性建模。对于这类系统，更精细的规范模型架构（例如，使用 M/S）更合适。目前，一些汽车公司在将 UML/SysML 用于基于 AUTOSAR 的软件架构建模时面临两难境地，在使用 UML/SysML 生成高级架构描述图和使用 M/S 领域从这些图生成精细的规范 Simulink 模型之间犹豫不决。

为了解决我们组织中的这一困境，在过去的十二个月里，我们实现了汽车软件架构设计的转变，从使用传统方法 / 工具链转向在 Matlab/Simulink 的最新版本中采用新建模功能；既用于基于模型的高级系统架构设计，也用于生成精细的规范模型。我们借助一个多核、混合关键度电动动力总成控制器项目的软件架构建模实际经验，详细阐述了我们的方法。通过使用单个工具和全局模型进行架构设计的方法，我们消除了涉及两个不同领域所产生的模型间差距。此外，我们能够进行大量的概念验证研究、情景模拟，尤其是为不同利益相关者进行早期基于模型的性能和视角分析。在此背景下，我们还总结了遵循的最佳实践和获得的宝贵经验教训。

我们相信，这篇首次从前沿电动汽车动力总成项目中总结最佳实践和经验教训的文章，将对基于模型的汽车软件工程领域有很大的帮助。

在本文中，我们主要关注了软件架构的静态视图，如接口定义、需求可追溯性和模块之间的连接。在未来的工作中，我们计划研究与动态架构相关的方面，这是 M/S 工具链目前不支持的。例如，我们正在开发一个基于模型的导出 / 导入工具插件，用于将带时序注释的 M/S 模型自动导出到专门的时序分析工具（如 Gliwa T1 工具），并将时序分析结果（从专门的分析工具）反馈回 M/S 工具。