概述

在本文中，我们介绍了汽车软件架构设计的过渡历程，从使用传统方法和工具链到在最新版本的 Matlab/Simulink （M/S） 中采用新的建模功能。我们介绍了在多核硬件平台上运行的混合关键电动动力总成控制器的软件架构建模所采用的无缝方法。通过我们的方法，我们可以实现双向可追溯性以及强大的创作过程，实现AUTOSAR系统的基于模型的详细软件架构设计，包括详细的数据字典，并进行无数的概念验证研究，假设场景模拟和安全软件的性能调整。在此背景下，我们讨论了一个行业案例研究，该案例研究采用了宝贵的经验教训，我们的经验报告提供了新的见解和遵循的最佳实践。

关键词：模型驱动的软件工程;软件架构建模;系统工程;建模工具;最佳做法;电动汽车动力总成;AUTOSAR系统

1. 引言

在过去十年中，对象管理组织 （OMG） 引入的模型驱动架构 （MDA） 被认为是软件和系统工程的下一个范式转变。模型驱动方法旨在将开发重点从编程语言代码转移到使用适当的特定领域建模语言表达的模型。因此，模型可以被理解，由自动化流程自动操作，或转换为其他工件。然而，人们必须承认，在行业的实际项目中，从基于模型（仅用作图表的模型）到完全基于模型的方法（用作中心工件的模型）的转变尚未发生[1]。为了这个方向，我们谈到了汽车领域软件架构的模型驱动工程解决方案的进展。在本文中，我们讨论了汽车组织的实践现状、实践中的主要陷阱以及我们提出的方法。基于我们在过去12个月中为OEM开发电动动力总成软件的实际项目经验，我们提出了一个工业案例研究，采用了宝贵的经验教训，我们的经验报告提供了新的见解和遵循的最佳实践。

1.1. 汽车组织的实践现状

全球电动汽车 （EV） 行业继续快速扩张，这得益于对节能、高性能和低排放汽车的需求增加。供应链复杂性的增加与软件实现的复杂性增加并行不悖[2]。考虑到这一点，汽车开放系统架构（AUTOSAR）[3]是汽车制造商、供应商、服务提供商和汽车电子、半导体和软件行业的公司之间的全球开发伙伴关系。为了实现模块化、可扩展性、可转移性和功能可重用性的技术目标，AUTOSAR提供了一个基于不同层标准化接口的通用软件基础设施。在此过程中，AUTOSAR采用基于组件的软件架构来设计和实现汽车软件系统。在这种背景下，汽车原始设备制造商 （OEM） 中基于 AUTOSAR 的模型驱动嵌入式软件工程 （ESE） 的大部分实践都分为两个主要领域。它们是统一建模语言 （UML） [4]/系统建模语言 （SysML） [5] 域和 Matlab/Simulink （M/S） 域 [6]。

在UML/SysML领域为基于AUTOSAR的ESE提供基于模型的工具支持（例如，架构设计、自动代码生成）的竞赛中，Enterprise architect [7]和IBM Rhapsody [8]等UML工具成为领跑者。例如，Rhapsody 支持与 AUTOSAR 相关的 SysML 配置文件，用于使用原生 AUTOSAR 概念的 AUTOSAR 模型的架构描述。然而，汽车行业的实践现状是，UML/SysML只在更高的抽象级别上使用。

例如，UML/SysML用于创建描述性UML模型，以描述整个软件和系统架构（参见图1（1））。在过去十年中，我们是几个在汽车OEM客户项目中采用这种方法的汽车组织之一。这涉及花费大量时间在UML/SysML领域培训人员。此外，它还导致了工具和培训的大量投资成本，但没有令人满意的结果。

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

此外，尽管这些模型处于更高的抽象级别，但包含这些模型的文档是巨大的。从这些图中，可以手动生成更细粒度的规范性模型体系结构，但不使用 UML/SysML。例如，这些高级图用于自动创建 Simulink 骨架，其中 Simulink 代码是手动编写或自动生成的。尽管在汽车行业的大多数情况下都是这种情况，但有些甚至具有更简单的流程，较少使用UML。

此外，汽车软件还加载了非功能性要求（例如，时序和内存限制）。在此类系统的软件架构设计过程中，需要考虑、优化和微调许多此类参数（例如，CPU 负载与安全约束）。然而，UML/SysML工具缺乏对非功能性需求（例如，性能参数）之间的这种权衡分析的支持。此外，在安全关键型汽车软件的开发中，必须具有双向可追溯性。尽管存在一些孤岛解决方案来实现UML/SysML工具和需求管理工具之间的可追溯性，但它们不支持双向可追溯性作为全面的解决方案。因此，在这场汽车软件/系统架构设计工具支持的竞赛中，UML/SysML工具仅被视为图表工具。

最新实践中的主要缺陷

迄今为止所描述的方法（以下简称传统方法）采用两种不同的建模域进行基于AUTOSAR的汽车嵌入式软件架构建模，本质上是高度复杂的，不是一个无缝的解决方案（参见图1（1）），并且存在以下主要缺陷，即：

缺乏对基于AUTOSAR的系统的详细建模和软件架构设计的功能丰富的工具支持（例如，没有详细的数据字典）;

在早期架构设计中，缺乏对假设场景的概念验证研究和性能要求（例如，时序、内存、能源和安全性）的权衡分析的支持（例如，模拟）;

缺乏双向需求可追溯性和全面的创作过程。

在我们的实际项目经验中，涉及为原始设备制造商开发电动动力总成软件（参见第 1.3 节）。最初，我们采用了图 1（1） 中的传统方法，并面临着上面列出的挑战。

1.2. 建议的方法

另一方面，在最近发布的 M/S（约 2019 年初）中引入了新的建模功能。基于上述差距，我们完成了基于AUTOSAR的多核混合关键电动动力总成控制器的软件架构建模的过渡之旅，从使用传统方法（参见图1（1））到使用图1（2）所示的方法）。在图1（2）中的方法中，

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

利用最新版本的 M/S 中的 Simulink System Composer 工具箱，我们创建了自定义配置文件，以支持安全软件的权衡分析（例如，安全与时序）;

使用 M/S 工具箱支持的强大模拟，我们还能够进行无数的概念验证研究和假设场景模拟;

借助最先进的需求管理工具插件（Polarion for Simulink [9]）和自定义脚本，我们实现了需求和架构设计之间的无缝双向可追溯性。此外，还支持全面的创作过程。

在此背景下，本文提出了一个行业案例研究，利用了宝贵的经验教训，我们的经验报告提供了新的见解和遵循的最佳实践。本文的其余部分组织如下。在此介绍之后，第

1.3 节提供了有关机动车辆电动动力总成的简要介绍（运行示例）。背景和相关工作见第2节。在第 3 节中，我们将讨论传统方法中的缺陷以及新方法中遵循的最佳实践。在第 4 节中，我们将讨论在新方法中吸取的经验教训。第5节提供了摘要和结论。

1.3. 电动动力总成示例

本节简要介绍了电动动力总成的背景知识，本文将作为运行示例。机动车辆的动力总成包括产生和输送动力（即为车辆提供动力）的主要部件。动力总成的最新发展是由多个部件的电气化推动的。全电动汽车完全消除了内燃机（ICE），这意味着它们完全依靠电动机进行推进。电动动力总成的主要部件是电池组（提供直流电（DC））、电动机、车载充电器、电池、热管理系统和AC-DC/DC-DC转换器[10]。图中显示了电动动力总成的主要部件（来源：https://evreporter.com/ev-powertrain-components/（2021年12月1日访问）。有兴趣的读者可以参考此来源了解图 2 的详细信息。

图2.全电动汽车中的典型组件。

电动动力总成软件具有混合的汽车安全完整性等级（ASIL）临界等级[11]，范围从A到D（D-最高临界）。此外，该软件在多核硬件平台上运行（例如：https://www.infineon.com/cms/en/product/microcontroller/32-bit-tricore-microcontroller/ 于 2021 年 12 月 1 日访问），该平台在汽车领域的使用越来越多。电动动力总成系统由液冷高压逆变器驱动和控制。动力总成的逆变器控制软件最初是使用传统方法开发的，然后在我们的现场/客户项目中改用 M/S。第 3 节和第 4 节中使用了该项目的示例。但是，本文中使用的数字不是我们实时项目中的原始工作项，而是它们的等效表示。

2. 背景及相关工作

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

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

如今，由不同制造商开发的多达 100 个电子控制单元 （ECU）（控制车辆中一个或多个电气系统或子系统的嵌入式系统）集成在现代汽车中，其中 ECU 软件也变得越来越复杂。为了解决此类系统开发中日益复杂的问题，模型驱动开发（MDD）[12]被认为是下一个范式转变。在 MDD 中，需求被指定为更高抽象级别的模型（例如，使用 UML/SysML、M/S）。然后，通过模型转换，从较高的抽象级别开始，然后移动到较低的抽象级别，从而对其进行优化。请注意，除了UML/SysML和M/S域之外，Rubus组件模型（RCM）和EAST-ADL [13]是车辆域中较小社区使用的其他解决方案[14]。

2.2. 使用UML和SysML进行建模和基于仿真的技术

在采用模型驱动方法和使用基于仿真的技术的方向上，在过去十年中，人们花费了大量精力来简化使用SysML模型（如[15,16,17,18,19,20]）的复杂系统的开发和仿真。

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

类似地，参考文献[17]旨在弥补E/E系统设计中硬件和机械工件表示缺失的缺陷，这些缺陷是通过利用Enterprise Architect或Artisan Studio等工具的常用方法在SysML或UML2配置文件中对E/E系统设计进行建模来实现的。因此，开发了一种基于模型的领域特定语言，以更全面的方式描述系统。此外，所提出的方法声称可以使不熟悉UML或SysML的领域专家更容易创建架构设计。此外，在所提出的方法中，已经存在的SysML模型没有被忽略，而是通过转换器支持，该转换器将DSL模型转换为SysML表示。在[18]中，主要目标是将安全分析集成到基于SysML的系统工程方法中，以使其更加有效和高效。所提出的名为系统工程安全集成（SafeSysE）的方法应用于航空领域的一个真实案例研究：机电执行器（EMA）。文献[19]提出了一种基于SysML的机电一体化系统架构设计方法。该方法由两个阶段组成：具有外部视角的黑盒分析，提供一组全面且一致的需求，以及白盒分析，逐步导致系统的内部架构和行为。尽管[15,16,17,18,19]是使用SysML领域进行的广泛研究，但它们都没有考虑使用AUTOSAR进行高级汽车架构设计和实现的用户案例。

然而，在[20]中，详细阐述了一种将SysML用于特定法雷奥产品线的嵌入式汽车系统的实用方法。本文明确指出，虽然SysML是所有领域系统工程的主要主题，但SE在汽车嵌入式系统和产品中尚无实用的实现。尽管这篇论文本身只提供了一个建议，并且该论文声称没有理论上的新颖性，但它也没有声称自己处于SysML建模的前沿。最后，本文提出，它可能有助于利用跨领域专业知识和需求的协同作用。尽管这些建议已有十多年的历史，但到目前为止，还没有具体的研究集中在嵌入式汽车领域中将SysML应用于具体的实际工业用例，特别是采用非常相关的AUOTSAR标准用于汽车领域，这是本文讨论的主要主题。

参考文献[21]的目的是开始为建模和基于仿真的系统工程奠定基础，这可能会在未来成为一本教科书。特别是，本书中讨论的支持系统建模的方法（第 2-4 章）、特定领域语言（第 6 章和第 10 章）和模型驱动的仿真工程（第 6 章和第 7 章）等主题与本文介绍的工作相关。第 2-4 章讨论了系统建模的过程，以及如何在此过程中应用建模和仿真，以及如何优化该过程。例如，第 2 章提出了系统工程师和仿真从业人员已经使用的过程、方法和手段的一致性。调整流程并使用系统架构工件作为通用存储库，可以生成一致的模型，该模型可以作为仿真执行，提供额外的数值见解，并最终根据客户的要求生成高质量、值得信赖的系统。这个想法与我们的工作有关;然而，整个系统架构设计是由我们客户项目中的系统架构师进行的。因此，不需要对流程和系统架构工件进行调整。然而，在我们的方法中，系统架构师能够执行此类模拟（例如，参见第 3.2 章早期性能分析），例如评估假设场景并提供早期性能结果，从而产生客户所需的高质量和值得信赖的系统，如第 2 章 [21] 所述。此外，需要注意的是，在我们的工作中，我们专注于 UML 和 M/S 的功能，以便对手头的用例进行详细的架构建模，以及其中涉及的最佳实践，而不是所涉及的过程。

在[21]的第6章中，作者讨论了使用分布式仿真技术对复杂系统的固有分布式架构进行建模的问题。本章提出了一种方法，该方法利用模型驱动工程领域中引入的原则、标准和工具，并支持从使用 SysML 指定的系统模型自动生成基于高级架构的分布式仿真。此外，在[21]的第7章中，分析了模型驱动的方法，以实现基于仿真的复杂系统分析。例如，这些章节讨论了最新的研究见解如何推动使用模型和仿真来推动系统工程的想法。例如，他们处理航天器在建模和仿真方面的协作和并行设计。着眼于系统工程生命周期，他们讨论了模型驱动设计方法的期望和优势，并强调了形式化设计在持续验证和确认方面的潜力。本章最后提出了一个有前途的想法，即将建模和仿真集成在一起，作为支持航天器设计过程的一种快速且易于使用的手段。这也是一项非常相关的工作，我们解决了早期性能分析的问题，以支持持续的设计改进和早期性能分析。在我们的工作中，这方面在第 3.2 章中得到了解决，我们在其中详细演示了早期基于模型的性能分析中的假设场景分析，并提供了现实生活中的例子。总之，参考文献[21]提供了与建模和基于仿真的系统工程相关的详细而重要的贡献。然而，[21]中的章节都没有涉及基于AUTOSAR的汽车实际用例的软件架构建模的具体用例研究，这是我们工作的主要主题之一。

在文献[22]中，提出了信息和通信技术供应链（SC-ICT）部门的互操作性建模、模型转换和仿真指南。作者声称，这种方法符合工业 4.0 原则，特别是它对信息物理系统 （CPS）、数据分析和物联网感兴趣。尽管模型驱动的互操作性（MDI）本身就是一个主题，但将[22]中这项工作的任何收获与基于AUTOSAR的真实项目（例如我们描述的项目）进行比较会很有趣。例如，文章[22]提供了一些关于MDISE在未来CPS框架中的兴趣的观点。类似地，对于从一种架构到另一种架构的迁移，使用[23]中描述的MDSE的虚拟组织将有助于建模和仿真的连续性。因此，[23]中提出的方法和[22]中提出的模型模板库，该模板库展示了CPS数据交换的经典活动和用于创建参考框架的模型转换引擎，可以扩展并用于我们论文中讨论的现实生活中项目的仿真研究。

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

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

除了通用系统和软件建模之外，UML 还支持使用特定的配置文件进行性能分析（例如，时间、能量和安全性）。[26]中提供了一些使用UML进行MDD和检查时序和可靠性等质量属性的例子。在文献[27]中，讨论了在基于AUTOSAR的汽车嵌入式软件系统中早期合成时序模型的方法。在这项工作中，该工作流程建议使用 AUTOSAR 时序规范在 Rhapsody 中创建时序注释的基于 AUTOSAR 的模型，并合成与 AUTOSAR 设计模型相对应的时序分析模型。但是，时序分析本身将在其他工具中执行，而不是 Rhapsody。除上述工作外，文献中未发现与基于AUTOSAR的系统相关的性能方面。这是因为UML/SysML工具主要不具备提供细粒度描述性模型的能力，这些模型可用于在AUTOSAR域中执行此类性能分析。因此，这些解决方案可能最适合通用UML/SysML建模，而不适合基于AUTOSAR的汽车嵌入式软件架构设计和分析。

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

M/S 是使用非 UML 建模语言的建模工具的流行示例。它是包括汽车领域在内的业界成熟工具[28,29]，尤其关注基于物理场的建模和控制回路。由混合动力系统组成的现代汽车是复杂的多域系统。由于 M/S 提供了广泛的基于模型的设计功能以及用于仿真的模块集，因此它似乎成为一种备受追捧的工具，可以在单一环境中捕获电气、机械、液压元件和控制系统 [30]。

在这种情况下，在最近发布的M/S中，新的建模功能，如AUTOSAR Blockset [31]和Simulink System Composer [32]工具箱，为基于AUTOSAR的系统增加了复杂的系统工程功能。然而，总的来说，目前还没有关于这些新功能的适用性和使用的研究发表。在此背景下，本文首次将 M/S 工具箱的新功能应用于基于 AUTOSAR 的电动汽车动力总成架构建模的最新现实项目，并概述了所吸取的经验教训和所涉及的最佳实践。

2.2.3. AUTOSAR框架

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

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

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

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

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

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

2.3. 需求管理（RM）工具

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

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

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

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

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

在本节中，我们将分三个主要部分来讨论传统方法的缺点（参见图 1），如第 1 节所述。因此，第3.1节讨论了在传统方法中对基于AUTOSAR的软件架构设计进行建模的工具支持方面的缺点，以及如何在新方法中克服这些缺点（参见图1（2））。接下来，第 3.2 节将详细讨论使用 M/S 工具进行性能权衡研究的新示例，以帮助系统架构设计决策，以在配置程序流监控时进行权衡分析。在第 3.3 节中，我们将讨论双向可追溯性。

3.1. 基于AUTOSAR的软件架构建模

3.1.1. 使用 SysML/EA

嵌入式汽车应用中的数据字典用于存储支持功能和软件开发的数据元素和定义。一个强大的基于模型的开发过程应该由数据字典驱动，该字典可以与支持基于模型的环境的工具进行交互，并在开发过程的不同阶段之间提供链接。数据字典可以显著提高流程建模、验证和编码阶段的自动化程度[40]。鉴于汽车系统是高度复杂的系统，端口和接口运行多达数千个，因此可以直观地感知到，在系统架构设计阶段支持数据字典是必不可少的。

AUTOSAR提供了使用UML工具（如EA）的AUTOSAR基础软件（参见图3的下半部分）的建模指南[41]。遵循这些准则并应用传统方法，我们最初开发了 EA 工具中的动力总成系统架构设计。在 EA 中使用 SysML 创建的电机控制静态架构设计示例如图 4 所示。

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

但是，如图 4 所示，仅列出了 SysML 模块和端口的名称。没有明确定义的数据字典。这不仅对系统架构师来说是一个很大的劣势，而且对整个软件开发团队来说都是一个很大的劣势，因为他们无法将关键的软件开发数据与系统架构一起随时可用。

3.1.2. 在 M/S 中使用 System Composer 和 AUTOSAR Blockset

另一方面，在我们的新方法中使用 System Composer 和 AUTOSAR 模块集在 M/S 工具中对相同的系统架构进行建模。在此示例中，可以清楚地看到对数据字典的支持（在图 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 的系统架构进行建模;

BP-2：使用 Simulink System Composer 数据字典支持创建细粒度 AUTOSAR 架构模型。

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

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

对于电动动力总成等复杂系统的架构设计，选择合适的设计参数并尽早做出设计选择，优化能量与时序、CPU负载与安全约束等各种参数，是一项势在必行且具有挑战性的任务。这些是假设场景的一些示例，可以使用我们提出的方法在系统架构建模和设计的早期阶段进行分析。在下文中，我们介绍了基于AUTOSAR的系统中功能安全机制[11]的概念，即程序流检查。我们讨论了涉及AUTOSAR看门狗管理器（WdgM）的程序流检查（也称为逻辑监督）中的时序开销计算场景[42]。

在行业实践中，在早期系统设计阶段，系统架构师遵循经验法则（例如，为每个受监督的功能分配一个监控调用）来配置程序流检查。由于没有工具来确定最佳和/或可行的检查点数量，这种经验法则的做法会导致系统架构设计的代价高昂的返工。例如，监控调用引入的大量定时开销仅在测试和定时分析阶段的后期（例如，当受监督的功能错过定时截止时间时）才会检测到。我们通过一个简单的示例来说明，在程序流检查期间，使用 M/S 基本函数和基于 Model 的配置，使用 System Composer 工具箱中新版 M/S 中引入的配置文件，对监控功能引入的时序开销进行有效评估。

3.2.1. AUTOSAR看门狗管理器（WdgM）

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

3.2.2. 监督实体、检查点和程序流程图

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

3.2.3. 检查点的粒度

WdgM 没有解决这个问题。例如，这由系统架构师在系统设计阶段确定。在受监督实体的控制流中，当到达每个检查点时，活动将报告给 WdgM，从而产生（访问）时间开销。很少有粗粒度的检查点限制了 WdgM 的检测能力，检查点的高粒度会导致 WdgM 的复杂和大型配置，从而在时间上也会带来显著的开销。因此，在早期系统设计阶段，必须在系统架构中配置（帕累托）最佳数量的检查点。需要执行此活动，以便检查点的粒度不会限制 WdgM 的检测能力，同时不会导致导致受监督实体错过最后期限的大量计时开销。在这种情况下，错过最后期限可能会导致系统功能安全方面的损害（例如，导致错过容错时间间隔-FTTI [11]）。

3.2.4. 电池管理系统示例

在电动动力总成中，电池管理系统组件（参见图 6）集成了能够计算电池参数（包括电池电压、电池温度和电池电流）的不同组件。必须对这些参数进行测量和控制，以提高实际应用中的状态跟踪能力[10]。在这种情况下，让我们考虑图 6 中电池管理系统中的温度控制模块（也称为任务）示例，该模块包含多个功能（也称为可运行）。为每个可运行的对象（即任务中的函数）分配一个检查点，会产生八个检查点（请注意，这里总是需要一个进入和退出检查点，这是配置工具的一个限制），如图 7（2） 所示）。可能的正确程序流程顺序如图7（3）所示。请注意，过渡 T1...T9 指定检查点之间的程序流。图 7（（3.1）–（3.3）） 中可能的执行序列的转换在矩阵中表示，如图 7（4） 所示。在此示例中，假设每个检查点访问需要 5 毫秒的访问时间。

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

图7.温控模块的程序流监控配置 （1）：该模块（任务）中的函数（可运行），（2）：被监督实体的可能检查点和 （3）：被监督实体的可能执行顺序和 （4）：函数/CP 的依赖关系——由它们之间的转换表示;对于可能的（正确的）执行顺序。

3.2.5. 使用Matlab脚本进行估计

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

3.2.6. 基于模型的估计

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

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

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

在如此早期的阶段（即在配置期间）确定计时开销，使系统架构师能够就满足任务的计时期限与为任务启用细粒度程序流监控之间的权衡做出明智的决定。这是在系统架构设计过程中需要解决的一个极其关键的点，因为检查点的粒度及其开销不得导致错过最后期限，从而使系统无法移动到安全状态。

与上述方法相比，在传统方法中，可以创建这种定制的配置文件，并且可以使用性能属性注释UML / SysML模型。但是，UML/SysML 建模工具缺乏强大的计算引擎等功能。因此，这些带注释的性能模型必须以一种或另一种格式（例如，Excel文件，XML文件等）导出到性能分析工具以进行性能分析。在文献中，可以在[27,44,45]中找到用于特定工具性能分析的此类性能模型的综合。

3.2.7. 项目的概念阶段——一个例子

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

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

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

3.3. 双向可追溯性

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

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

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

如图 9 所示，建模环境提供了指向需求数据库的可导航链接。此外，我们还能够在需求分析阶段或批准对需求的任何修改时输入注释和状态，从而在数据库中进行适当的通知和维护。作为一种很好的做法，该工具将可追溯性信息导出到报告中。无论该工具有多好，当它的功能得到充分理解和充分应用时，都可以获得最佳使用。需求管理工具还确保所有用户都根据指定的配置以及工具中实现的流程遵循相同的需求流。

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

3.3.1. 发布和创作

借助 Siemens Polarion ALM Connector for Simulink [9]，我们能够将众多需求与基于模型的架构联系起来，并且可以在两个方向上直观地进行跟踪（参见图 10）。这种无缝方法还帮助我们以无缝的方式将软件架构从设计环境发布到需求数据库。在汽车项目的概念阶段，需求的更新是一个明显的情况，可以很容易地推动到设计中。同样，更新的体系结构也可以发布回需求数据库。此外，该插件为我们提供了双向创作和更新过程，并建立了易于使用的双向可追溯性，这在传统方法中是没有的。

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

3.3.2. 使用ARXML模式进行基本软件配置

市场上有几种AUTOSAR基础软件配置工具，如DaVinci工具链[43]。配置模式可以导出为 ARXML 文件，并在 M/S 中导入，以便在基本软件模块有更新时进行无缝集成和更新。在EA中不可能实现这种无缝集成。

在SWE.2软件架构设计中，软件架构师提出软件组件架构设计，包括接口（输入和输出列表）、预期动态行为（SWC周期、优先约束等）、内存分配和预算。在所提出的方法的帮助下，他以建筑设计的形式全部或部分地提供了上述信息，这些信息可以进一步导出为ARXML文件。使用传统方法时，我们没有找到导出为 ARXML 的选项。然后，可以在DaVinci开发人员（或类似的AUTOSAR SWC导入器）处导入组件SWC的ARXML文件，以将上述架构细节交换给开发人员。

对于开发人员来说，这是一个非常有益的工作流程，因为他会收到有关接口（以及数据字典）和 SWC 动态行为的所有必要信息。这样，建议的工作流程大大缩短了开发时间。相比之下，使用传统方法时，开发人员花费了大量时间来了解体系结构注意事项。因此，我们从上述经验教训中吸取的最佳实践是：

BP-4：采用无缝方法进行高级系统和软件架构设计，并支持数据字典，有助于在建模环境和需求数据库之间建立双向可追溯性。在两个环境之间来回跟踪需求，以验证需求的满足情况;

BP-5：在需求管理工具（Polarion）和系统架构设计工具（M/S-SC）之间使用最先进的插件将需求和设计发布到需求数据库。此外，该方法在适应技术分析和讨论的变化时，以更有效的方式更新需求和设计;

BP-6：在架构建模环境和基础软件（BSW）配置和开发工具链之间导入和导出ARXML，以减少架构考虑和开发时间的歧义。

4. 经验教训

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

将整体系统架构和详细设计整合到一个工具中，帮助我们使用一个全局模型进行了多个基于模型的早期性能和视点分析。在电动汽车动力总成等复杂系统的设计中，有几个利益相关者需要满足他们的观点。例如，在这样的系统设计中，安全工程师的目标和保证是将 ASIL-D（最高关键性）组件的 100% 程序流程检查纳入其中。另一方面，控制工程师的目标是将控制参数的最小建立时间和减少过冲时间纳入其中。软件工程师的观点是，在多核硬件中，CPU 负载低于内核的 70%，从而交付调度软件。

在此背景下，我们进行的早期基于模型的程序流监控分析（参见第 3.2.6 节）是安全工程师的观点分析，它为我们提供了每个任务每个有效程序流序列的总 CP 访问时间的估计值（参见图 8）。然而，时序分析（在专门的时序分析工具中进行[47]）的结果是，温度控制任务（图8中的任务2）的最后期限尚未完成。这是因为 30 ms 的总 CP 访问时间超出了此温度控制任务的总 CP 访问时间允许的 20 ms 时序预算。

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

在B-Sample阶段，供应商应提供具有完全驾驶性能和高度成熟度的功能性基本原型。同样，在C-Sample阶段，供应商将交付使用批量生产工具制造的全功能样品。有几种AUTOSAR创作工具（AAT），例如DaVinci configurator [43]和Electrobit的EBTresos studio（https://www.elektrobit.com/，2021年12月1日访问）。在电动汽车动力总成项目的所有示例阶段，我们都采用了DaVinci配置器工具进行基础软件（BSW）配置。采用所提出的方法的主要优点是，我们能够通过从这两个工具生成的ARXML文件链接到基于模型的开发工具。AUTOSAR ARXML导入器将AUTOSAR软件组件描述文件导入到Simulink模型中，反之亦然。导入器为每个导入的 AUTOSAR 软件组件创建初始 Simulink 表示，并将 Simulink 模型元素初始默认映射到 AUTOSAR 组件元素。初始表示为进一步的AUTOSAR配置和基于模型的设计提供了一个起点。与 Simulink 原创设计一样，我们能够在 Simulink 中为导入的 ARXML 文件组件开发组件设计和行为。借助ARXML文件，AUTOSAR创作工具和M/S的集成和链接使我们能够无缝地满足（B-Sample和C-Sample）项目的最后期限。相反，这些工具在Enterprise Architect UML / SysML工具中不可用，我们在为同一项目建模系统架构设计的传统方法中采用了该工具。

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

5 总结与结论

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

然而，一个明显的缺点是，这种方法不适用于复杂系统（例如，汽车系统），因为系统过于复杂，无法完整或准确地进行描述性建模。对于此类系统，更细粒度的规范性模型架构（例如，使用 M/S）更适合。目前，几家汽车公司正面临着这种困境，即使用UML/SysML进行基于AUTOSAR的软件架构建模，并在UML/SysML领域（用于生成高级架构描述性图）和M/S域（用于从这些图中生成细粒度规范性Simulink模型）之间徘徊。

为了解决我们组织中的这一困境，我们在过去 12 个月的汽车软件架构设计中从使用传统方法/工具链过渡到在最新版本的 Matlab/Simulink 中使用新的建模功能;用于生成基于模型的高级系统架构设计以及细粒度规范模型。我们借助多核、混合关键、电动动力总成控制器项目软件架构建模的实际经验，详细阐述了我们的方法。通过使用单一工具和全局模型进行架构设计的方法，我们消除了因涉及两个不同领域而产生的模型间差距。此外，我们已经能够为各种利益相关者进行无数的概念验证研究、假设场景模拟，尤其是早期基于模型的性能和观点分析。在这方面，我们还总结了所遵循的最佳做法和宝贵的经验教训。

我们相信，这篇史无前例的文章介绍了从最先进的电动汽车动力总成项目中吸取的最佳实践和经验教训，将对整个基于模型的汽车软件工程社区有益。

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