通过动态和静态测试保障AUTOSAR系统的软件质量

随着 AUTOSAR（汽车开放系统架构）标准在汽车行业的引入，如今能够以功能为导向、独立于硬件的方式开发和复用软件。在 AUTOSAR 中，这一目标通过横向分层模型实现，该模型定义了基础软件、运行时环境（RTE）和应用程序这几个领域。这种清晰的分层使得众多包含不同专业化产品的异构工具链得以建立，但同时也为汽车行业带来了新的挑战 —— 软件质量以及为控制器寻找最优配置的重要性日益凸显。本文提出的方法在 AUTOSAR 控制器开发过程中，通过静态分析为保障软件质量及符合标准提供支持；此外，还能半自动生成动态测试并在目标平台上执行，以验证基础软件和运行时环境的功能可用性。该方法采用符合 AUTOSAR 标准的机制，且不受版本和制造商限制。

AUTOSAR（汽车开放系统架构）的系统架构支持独立于硬件开发应用程序，这一特性通过横向分层架构实现 —— 该架构将控制器划分为应用层（Applikationsschicht）、运行时环境（Runtime Environment，RTE）和基础软件（Basissoftware）三个部分。借助这种方法，可存储以功能为导向开发的成果，并在需要时通过配置大量参数，将其适配到具体的硬件平台上。用于开发基础软件或运行时环境的工具制造商，可能与用于开发应用层的工具制造商不同，这种异构工具链给汽车行业带来了巨大挑战。无论是在静态分析领域还是动态测试领域，都需要在不依赖于制造商或所使用工具的前提下，开展用于保障功能有效性和质量的分析与测试工作，且需始终提供可比较的结果。此外，开发人员常会面临这样的疑问：某一 AUTOSAR 系统的配置是否适用于具体应用场景，或是否能满足不同的重点需求。

本文提出一种不受 AUTOSAR 版本和制造商限制的方法，通过对源代码和 AUTOSAR 配置进行分析，保障软件质量；同时，在控制器运行时，针对基础软件和运行时环境执行生成的特定于应用程序的测试。该方法基于一个 AUTOSAR 知识库，该知识库包含制造商特定知识和版本特定知识，分析与动态测试均会调用生成的 AUTOSAR 知识库中的知识。

在控制器总线侧测试领域，存在大量商用工具，这些工具经过多年完善，已在工业界以较高的自动化程度投入使用；在源代码静态分析领域，也有诸多成熟工具。然而，这两个领域均缺乏针对 AUTOSAR 系统架构的精准适配。

在软件开发中，静态分析主要通过 SPLINT 等工具自动执行，借助这些工具可对源代码及其复杂度本身进行详细分析，但目前尚无针对 AUTOSAR 环境的具体适配方案。部分工具制造商在其开发环境中提供了检查功能，但这些功能大多依赖于特定制造商，且极少会同时对源代码和配置进行联合检查。

在 AUTOSAR 系统动态测试领域，已引入 XCP（通用测量与标定协议，Universal Measurement and Calibration Protocol）。通过额外配置和钩子函数（Hook Funktionen），XCP 能够在运行时对 AUTOSAR 系统进行读写访问。但 XCP 的实现仅从 AUTOSAR 4.0 版本开始被正式规范，且并非适用于所有硬件平台；此外，XCP 设置所需的额外配置工作量也不可忽视。文献中提出的方法与之类似，该方法在 AUTOSAR 基础软件内部提供了日志和跟踪功能。

本文提出的方法在软件架构实现与开发阶段提供专门的静态分析功能，在此过程中，会检查源代码与配置之间的一致性，以及是否符合 AUTOSAR 标准。其目标是在不依赖于版本和制造商的前提下，确保较高的软件质量。所实现的分析功能还可提供修正建议，以修复错误。

3.1 前提条件

要实现本文提出的方案，首先需要所有 AUTOSAR 分层（或其软件模块）的配置文件和源代码；此外，AUTOSAR 知识库中还需包含硬件平台、基础软件制造商以及 AUTOSAR 版本相关的数据。因此，该方法的实施需具备以下数据：

· 基础软件和运行时环境的源代码与配置，以及应用程序的系统描述；

· 用于动态测试的 AUTOSAR 工具链（含硬件）。

3.2 工作流程

AUTOSAR 系统开发过程中的伴随式分析与测试流程如图 1 所示。该方法以 AUTOSAR 项目为基础，包含源代码和配置（既含 AUTOSAR 特定配置，也含制造商特定配置），这些构成了针对各横向分层的专项静态分析的基础。若静态分析未触发终止条件（如语法错误、非法调用等），则可启动动态测试。

图 1：AUTOSAR 系统静态分析与动态测试工作流程

3.3 AUTOSAR 系统静态分析流程

静态分析针对特定的 AUTOSAR 分层实现（参见图 1）。在此过程中，会从 AUTOSAR 项目中提取源代码、AUTOSAR 标准格式文件以及制造商特定配置文件进行分析。一方面，检查这些文件是否符合 AUTOSAR 标准；另一方面，检查源代码与现有配置之间的一致性。例如，可发现软件组件之间未使用 RTE 进行通信的调用行为。在静态分析过程中，AUTOSAR 知识库会被用于确认有效配置、允许的调用方式及通信路径等。

本文提出的方法中，静态分析可选择性提供修正建议（如图 2 所示）。例如，对于明显未连接但相互匹配的通信连接，可建议将其连接；若执行了修正操作，则需针对修改后的项目重新进行分析。此外，静态分析还会向测试人员提供统计信息，这些信息可用于评估项目的软件质量，统计内容包括代码行数、注释行数、空行数，以及每个操作系统任务中可运行实体（Runnables）的数量等。

图 2：含修正功能的 AUTOSAR 系统静态分析流程

3.4 AUTOSAR 系统动态测试流程

动态测试分为测试用例生成和测试模块生成两个部分。在测试用例生成阶段，会基于 AUTOSAR 控制器的特定应用配置，生成针对基础软件模块和运行时环境的测试用例；在第二阶段，将这些测试用例转换为测试模块（含 C 语言源代码和配置），并作为复杂设备驱动模块（Complex Device Driver Modul）集成到 AUTOSAR 控制器中。在基础软件测试过程中，测试对象会在控制器上通过测试数据进行激励，测试结果也会直接在测试模块中进行评估。

基础软件中协议栈（Stacks）的测试流程具有特殊性。以通信协议栈（Kommunikationsstack）为例，首先单独测试某一个模块（如 CAN 驱动，CAN Treiber）；若测试成功，则将测试对象扩展为协议栈中的下一个模块（如 CAN 接口，CAN Interface），并使用相同的测试用例进行激励；之后，再将测试对象扩展为协议栈中的后续模块（如 PDUR 模块）。这一过程会持续进行，直到测试对象涵盖整个协议栈。

图 3 展示了动态测试的结构。图左侧为集成了生成的测试模块的 AUTOSAR 控制器，测试模块在此处对控制器中的基础软件和运行时环境进行验证；图右侧为测试计算机（Test PC），用于执行测试用例生成和测试模块生成操作。在测试执行过程中，测试模块与测试计算机上同样生成的测试控制程序（Teststeuerung）会进行通信，因此两者的同步至关重要。

图 3：AUTOSAR 系统动态测试流程

本文提出的方法以模块化系统的形式，采用 C# 编程语言实现。其中集成了 AUTOSAR 知识库，目前该知识库包含 AUTOSAR 2.1、3.1 和 4.1 版本的相关条目。可定义由分析模块和测试模块组成的序列，并针对某一 AUTOSAR 项目逐步执行。每个模块均可返回大量分析结果或测试结果，这些结果会以分析报告和测试报告的形式呈现，并存储在数据库中。

该实现方式的一个特点是，为每个分析结果和测试结果关联一个测试对象 ID（如图 4 所示）。该 ID 对应 AUTOSAR 知识库中的一条记录，例如，某一被引用的测试对象可以是单个基础软件模块，也可以是整个协议栈。由于该 ID 在不同 AUTOSAR 版本和产品中保持一致，因此可轻松对比不同时间点（图中标记为 t1 和 t2）的结果。

AUTOSAR 知识库主要通过专门实现的解析器（Parser）填充数据，这些解析器从经验证且定义正确的项目中提取数据。除源代码外，AUTOSAR 标准格式文件以及制造商特定的可读文件也可作为数据提取的基础。此外，知识库也支持手动填充数据。显然，知识库的数据填充过程需谨慎对待 —— 若填入错误或有缺陷的数据，将无法为 AUTOSAR 项目生成正确的测试用例和目标值（Sollwerte），因此必须高度重视这一过程的准确性。

图 4：AUTOSAR 知识库为分析报告和测试报告中的测试对象提供 ID

本文提出的方法为汽车行业 AUTOSAR 系统的开发提供了支持路径。该支持一方面体现在静态分析上 —— 静态分析可验证 AUTOSAR 标准符合性，以及源代码与配置之间的正确性；另一方面体现在动态测试上 —— 可在控制器上直接执行动态测试，通过半自动生成的测试模块验证基础软件和运行时环境针对特定应用的正确性。与静态分析类似，这些动态测试同样符合 AUTOSAR 标准，并借助 AUTOSAR 知识库实现。