车辆与异构信息源的连接是导致汽车软件架构复杂性的关键因素之一。来自外部通信源的信息会修改控制算法的结构、内容和同步方式。此外，软件开发的时间和成本约束也颇具挑战性。随着复杂性的增加和开发时间的缩短，确保软件质量成为汽车制造商的首要任务之一。软件架构通过实施增强汽车软件非功能性质量属性的设计原则，在确保质量方面发挥着重要作用。软件架构定义满足质量要求的程度在开发的早期阶段并未得到验证，结果导致设计问题被转移到开发的后期阶段，从而需要对软件工件进行返工。本文重点关注基于持续集成概念的工具化评估方法，用于评估基于 AUTOSAR 的传输控制软件的非功能性质量特性，该方法能够对软件架构进行早期和持续的评估，从而提高软件质量。

动力总成软件架构的复杂性正呈指数级增长。造成这种复杂性的主要原因包括排放法规、效率要求、大量变体、动力总成的数据连接以及自动驾驶。严格的排放法规导致了动力总成的电气化，这需要各种动力总成组件之间的协调配合。车对车、车对 X 以及基于云的技术的出现，为动力总成增加了更多的数据输入，有助于优化燃料消耗并减少温室气体排放。由于时间约束，动力总成控制算法与外部数据源之间的同步增加了复杂性。随着自动驾驶车辆的发展，大部分关键任务功能将通过软件来实现，因此，确保高质量的软件对于在汽车软件领域采用新技术至关重要。软件复杂性的增加使得软件难以维护、测试，也难以识别质量缺陷。市场需求缩短了汽车控制软件开发的可用时间，结果导致车辆中的软件质量缺陷不断增加。考虑到修复软件质量缺陷所涉及的返工成本和保修成本，在开发的早期阶段识别这些缺陷非常重要。

1.1 研究问题

软件架构是开发生命周期中最早的活动之一，它涉及将复杂功能分解为更小的、可管理的部分。在项目开始时做出的架构决策对软件的结构和动态方面有着深远的影响。在过去几年中，AUTOSAR 已成为表达软件架构、确保软件组件的可移植性以及实现供应商和车辆制造商之间软件共享的标准方式。

软件架构日益增加的复杂性导致人们无法对软件架构有一个一致的全面了解。开发时间的缩短导致软件中纳入了 “快速而粗糙” 的更改，结果导致质量问题在开发的后期阶段才被发现。汽车软件还必须遵守大量标准，这就引出了我们的研究问题（RQ1）。

RQ1：动力总成领域软件架构的质量要求是什么？

AUTOSAR 标准化了基础软件的接口和工作流程，如今各种商业工具都支持这一点。然而，架构设计决策（例如功能分解、接口定义）对 AUTOSAR 软件组件软件质量的影响尚未得到详细探讨。当前的软件架构评估方法侧重于对架构草案和设计指南的手动评估。鉴于动力总成软件架构的高度复杂性，手动评估软件质量非常困难。随着复杂性的增加，软件架构也在不断发展。在缺乏客观、持续的软件架构质量评估方法的情况下，设计缺陷会被传递到开发的下一阶段，这些设计缺陷导致软件工件需要返工，从而增加了开发成本。因此，软件架构的持续演进需要对软件质量属性进行高频评估，这就引出了第二个研究问题（RQ2）。

RQ2：如何持续评估 AUTOSAR 软件架构的质量？

1.2 现有技术

AUTOSAR 提出的分层架构在最高抽象级别大致可分为三个层，即基础软件（BSW）、实时环境（RTE）和应用层（APSW）[AU]。基础软件为软件提供通信框架，实时环境（RTE）为应用程序软件提供通信服务，使 AUTOSAR 软件组件独立于特定 ECU 的映射。应用层（APSW）由控制算法组成，这些算法在 AUTOSAR 框架之上实现，该框架以组合、组件和可运行实体的形式实现，软件架构的分析重点是应用程序软件。

AUTOSAR 侧重于非功能性质量特性，例如软件架构的可移植性。然而，要确保软件质量，还需要满足许多其他质量标准（例如可测试性、可维护性等），而 AUTOSAR 软件架构并未直接解决这些问题。现有的验证工具侧重于验证架构规范的语法，但它们没有解决架构参数与软件质量之间的关系。本文致力于填补这一技术空白，实现对基于 AUTOSAR 的应用程序软件的早期评估。

评估软件架构存在两种基本方法，即基于场景的方法和基于度量的方法。基于场景的方法涉及基于场景对软件架构质量进行主观评估，这些场景由项目中的关键利益相关者创建，无论是否有正式的架构规范。基于场景的方法的结果再现性无法保证。另一方面，基于度量的方法需要半正式或正式的架构规范，但能确保结果的可再现性。

作者提出了一种 “基于度量的持续评估” 方法来对动力总成软件架构进行早期、客观和重复的评估。该基本方法基于作者之前的研究成果。本文涉及基于度量的评估概念在 AUTOSAR 架构中的扩展。一般来说，所提出的基于度量的方法包括以下步骤，下文将对其进行描述：

· 质量模型和度量的定义

· 度量的持续测量和评估

· 利用度量改进架构设计

2.1 质量模型和度量的定义

架构评估的第一步是定义质量模型。我们在本节中要解决的关键研究问题是：

图1：基于ISO 25010标准的AUTOSAR软件架构的质量模型

RQ1：动力总成领域软件架构的质量要求是什么？

遵循目标 - 问题 - 度量方法，基于质量标准来定义度量。质量模型中描述了与软件架构相关的质量标准，该质量模型基于 ISO 25010 和 ISO 26262 标准。此外，还需要考虑某些组织目标，例如软件组件的可重用性，模块化。因此，通过考虑标准和组织要求来创建质量模型。存在各种描述软件质量属性的模型。

在软件开发的早期阶段，只能测量少数质量特性。通过文献调查确定了受软件架构影响的质量特性。下一步是确定质量标准与架构参数之间的映射关系。对在开发早期阶段使用架构参数测量这些质量属性的程度进行评估。基于此，我们基于抽象级别确定用于评估软件质量的度量。

2.2 软件架构的持续测量和评估

动力总成功能的复杂性以及架构评估可用时间的缩短，使得必须采用基于工具的方法来测量软件架构质量。第 2.2 节和第 2.3 节涉及以下研究问题：

RQ2：如何持续评估 AUTOSAR 软件架构的质量？

所提出的工具框架有两个主要部分，涉及软件架构的测量和评估。第一步涉及从 ARXML 文件格式中提取架构信息。从 ARXML 文件中提取的信息基于计算度量所需的架构参数。测量框架使用从各种动力总成软件项目中提取的架构信息，基于质量标准计算度量（定义见第 2.1 节）。

评估框架使用来自各个项目的测量信息，并基于统计数据计算阈值。度量评估的结果可能会因阈值的定义而异。单个度量无法确定质量标准的满足程度，因此需要结合各种度量来确定质量标准的满足程度。评估框架基于质量标准对度量进行聚合和加权。根据质量标准的重要性，为各种质量标准分配相应的权重。作者在之前的研究中详细解释了评估框架。本文重点关注基于 AUTOSAR 概念的测量框架的扩展。这些度量是在 MATLAB/Simulink® 工具框架上开发的。

如前所述，这项工作的核心重点是扩展对 AUTOSAR 软件架构质量的测量，因此概念扩展仅影响测量框架（见图 2）。ARXML 是描述软件架构的标准化文件格式，被用作提取架构信息的工件。在作者之前的研究中，重点是结构方面。然而，ARXML 文件格式提供了关于软件架构中时序和内存消耗的详细信息，因此对这些质量特性进行了评估。

图2：用于使用度量对软件架构进行持续评估的工具框架

2.3 架构设计改进

了解架构参数和质量特性之间的关系有助于我们提出软件架构的改进措施。表 1 展示了一些度量、它们的设计后果以及用于更好的软件架构设计的改进措施。对于每个度量，都提出了这样的设计后果和应对措施。

表1：使用度量的设计结果和架构改进示例

基于度量的架构评估概念被应用于基于 AUTOSAR 的传输控制单元软件。目前的实现是针对从基于 AUTOSAR 4.0 规范的 Systemdesk® 生成的 ARXML 文件进行验证的。然而，该测量框架也可以评估由其他工具生成的 ARXML 文件。由于仅考虑了一个传输控制单元项目来评估度量概念，因此无法进行统计评估。因此，通过与专家的经验验证，对度量值与软件质量标准进行了经验评估。如果有更大的数据集，则可以使用图 2 所示的统计评估。作者提出的度量概念的经验验证包括宏观层面的验证，评估该方法是否解决了处理复杂性、确保软件质量和提高开发效率的关键问题。在微观层面，评估架构度量概念详细处理这些问题的程度。

3.1 处理软件架构的复杂性

这种基于工具的方法能够处理具有 62 个应用程序软件组件和从 CAN 总线接收 300 多个信号的传输控制单元。工具生成的结果的正确性已通过对一组软件组件的手动验证。基于工具的方法在处理架构复杂性方面没有限制。

3.2 评估软件质量

验证的第二个方面涉及确定度量在评估质量方面的可用性。评估架构度量可用性的方法有三种。其中一种方法是将该度量与开发后期阶段（模型或代码）的另一个已建立的度量相关联。第二种方法涉及将该度量与缺陷密度相关联。第三种方法是与专家进行经验验证。第三种方法包括与项目中的开发人员进行讨论，以确定代码生成和软件集成中面临的问题与度量之间的概念关系。与其他方法不同，这种方法更具概念性，并在 AUTOSAR 概念和软件质量之间建立了因果关系，因此采用了这种方法。

3.3 减少开发时间和工作量

高度的自动化为软件开发提供了更快的反馈循环，以应对更短的开发时间并降低成本。持续集成框架为实施技术解决方案提供了基础，该技术解决方案为软件评估提供了快速反馈循环。传统的基于场景的软件架构分析估计需要 70 人天的工作量。架构度量的构思、开发和部署所需的工程工作量估计很高。然而，度量在软件产品线或一组项目中的适用性减少了大量项目的工作量。

这项工作的重点是开发一种基于工具的评估方法，用于 AUTOSAR 软件架构。图 1 展示了基于第一个研究问题（RQ1）的动力总成软件架构质量模型。图 2 展示了基于第二个研究问题的用于软件架构持续评估的工具架构。

该解决方案基于两个关键研究问题。第一个研究问题（RQ1）侧重于开发软件架构质量模型，该模型概述了可以在开发早期阶段评估的那些质量属性。质量目标源自各种标准，如 ISO 25010和 ISO 26262。图 1 展示了可以在开发早期阶段测量的软件架构质量目标。

下一个关键研究问题（RQ2）侧重于持续评估软件架构。已定义的质量度量被编程到持续集成环境中（如图 2 所示）。这些度量是针对传输控制单元软件进行评估的。这些度量基于软件架构中元素的抽象级别。图 3 展示了在 AUTOSAR 软件组件抽象级别上的一些度量结果。表 2 展示了系统级别的一些度量，包括基于 ARXML 文件的架构中的各种电子控制单元。类似于表 1，这些不同抽象级别的结果用于确定软件架构的改进措施。

图3：基于AUTOSAR的变速器控制单元的度量结果

表2：从具有测量值的ARXML文件中导出的系统级指标

基于度量的软件架构分析解决了一些与质量和开发时间相关的关键问题。尽管 AUTOSAR 标准化了基础软件的接口，但尚未深入研究可测试性、可维护性及其与架构参数的关系。这种方法从根本上侧重于量化架构决策对软件质量的影响。基于工具的实现在处理动力总成的架构复杂性方面提供了一个框架，并提供了关于质量属性的反馈。持续集成框架提供了在修改后评估软件架构的可能性，从而降低了返工成本。因此，它支持在不牺牲软件架构原则的情况下，对车辆的软件功能进行敏捷开发。

为大量 AUTOSAR 度量定义阈值仍然是一个开放的课题。作者在之前的研究中提出的评估框架基于多个项目的统计数据。由于统计数据的可用性有限，因此采用的方法是基于与专家的咨询，为各种度量定义经验阈值。这些经验阈值将成为跟踪未来 AUTOSAR 项目设计指南满足程度的基础。