面向教育汽车软件工程的AUTOSAR静态测试策略

AUTOSAR（汽车开放系统架构）是欧洲汽车领域软件开发的领先架构基础。然而，由于存在大量不同的工具、规范和架构指南，其本身就很复杂，所以使用时更复杂。因此，汽车软件工程领域的学生需要指导和手段，以快速和可理解的方式评估他们的编程输出是否符合标准。基于之前提出的汽车软件工程的教育云平台，在本文中提出了一种评估基于AUTOSAR的软件开发质量的方法。这种方法被定位为开发过程中的一个步骤，学习者最终会在测试驱动过程中运行实现，以评估其实际性能。在这样的测试基础设施中，关于测试执行的资源总是短缺的，因为真正的测试驱动涉及相当复杂的准备工作和时间表。但在采用软件或硬件在环模拟的情况下，也需要协调执行。因此，本文描述的方法有两方面的重点。一方面，希望在更稀缺的资源（如模拟器或真正的测试车辆）被分配之前，尽快捕捉方法上的错误。为此，我们提出了专门用于评估基于AUTOSAR实现的静态测试方法。希望避免实际运行必然会失败的实现。另一方面，上述方法的输出应使学习者和开发者更容易评估和比较其结果的质量。

简介

在过去的15年里，汽车领域的软件开发经历了很多的重新调整和改进，包括对现有方法论的改进以及新方法的建立。今天，软件组件的模块化、可重用性和可测试性等方面被认为与实际功能同等重要。因此，旨在减轻确保这些特性所需精力的架构已经被开发出来。其中一个框架是AUTOSAR（Automotive Open System Architecture），它是欧洲汽车软件工程的事实上的标准。本质上，由于涉及许多不同的要求和企业，AUTOSAR是一个非常复杂的话题，拥有一个陡峭的学习曲线，需要大量的经验才能有效地工作。因此，开发人员需要应用不同领域的知识，如硬件开发、通信系统和软件工程。此外，汽车开发人员必须在资源受限的系统中操作，需要比非嵌入式编程（如网络开发）更有效地使用。AUTOSAR引入了以功能为导向的应用开发范式。它将电子控制单元（ECU）的系统结构分成三个水平层--应用层、运行时环境（RTE）和基本软件。应用层的开发是独立于目标平台的。因此，在开发新功能时，需要花费相对较长的时间，直到开发人员能够观察到他们的代码在真实车辆的真实硬件上运行，而这两者在开发开始时可能根本不存在。在此之前，将对实施方案进行大量的测试，以确保质量并且符合AUTOSAR标准，并暴露出需要返工的地方。此外，每个测试步骤都需要获得更多有限的测试资源，例如单元测试平台、硬件/软件在环解决方案和最终的真实测试车辆。图1说明了V型模型中开发过程中的各种测试步骤，这是在嵌入式汽车软件开发中使用的主要过程模型。然而，这种设置使得开发人员，特别是学习者，很难及时检索反馈信息，或者以简洁的方式评估、可视化以及比较他们的进展。因此，一个测试步骤越早进行，其结果就应该越快得到，对稀缺资源的依赖也就越少。满足这些要求的一种方法是静态代码分析。在本文中指出静态代码分析在多大程度上可用于基于AUTOSAR的软件的早期测试和评估。此外，将展示AUTOSAR特定的静态测试如何为汽车学习者和开发人员提供比通用静态代码分析更多的好处。

图 1.  标明测试阶段的V模型

相关工作

静态代码分析是软件测试方法学的一个重要组成部分。它是通过在语法和语义层面上分析源代码来进行的，但不需要实际编译和执行。静态代码分析被用作一种手段，以发现开发人员常犯的错误，这些错误不会导致编译器错误，但很可能表现为运行时故障—一个众所周知的例子是在Java中使用引用相等来比较字符串。此外，静态代码分析工具1也经常被用来确保遵守代码准则，如项目范围内一致的标识符命名。统一的风格是可取的，以减少团队成员在接手别人的源代码时的学习难度，并方便编码审查。此外，当还没有完全可编译和可执行的原型时，静态分析可以在早期开发阶段发现问题。这是一种节约成本和开发资源的手段，因为通常在开发过程中越晚发现缺陷，修复的成本就越高，这是由模型和现实世界研究提出的。此外，静态代码分析经常被用来搜索导致软件安全漏洞的缺陷。事实上，在行业中生效的一些安全规范要求使用静态代码分析2。根据所使用的编程语言，存在着大量不同的静态分析工具。由于AUTOSAR是C标准，可以使用针对C的静态分析工具。在这个领域，一些现有的和不断开发的工具是Infer、Coverity和Splint。作为一个特例，Clang3值得一提，它本身是一个编译器，但也提供一个静态分析器。这些工具是报告内容方面的通用工具。一方面，这些是警告或错误，暗示着可能的运行时问题，另一方面，可能的输出是代码质量指标。这样的指标提供了一种快速的方法来评估代码库的总体性质和质量。它们的范围可以从最简单的代码行数、评论与代码比率到更复杂的，如循环复杂性。然而，通用工具只能检查有关编程语言的常见错误，并执行风格指导，但不能详尽地分析AUTOSAR项目，因为它们没有考虑到领域知识。这主要是由于AUTOSAR项目由模块化的源代码文件和大量的配置文件组成，这些文件是相互依赖的。在此基础上，配置是AUTOSAR项目的一个非常复杂和关键的方面。因此，许多错误都与配置有关，特别是在早期开发阶段。例如，定义的端口或属性实际上没有被实现，或者配置和实现的行为之间不匹配。这些错误不可能用标准的C语言静态分析工具发现，因为这些工具只在源代码层面上操作。

在[7]中，作者使用三种常见的静态分析工具，对AUTOSAR软件组件的可测试性进行了研究。然而，他们只评估了有关C语言编程的常见错误，而没有评估与AUTOSAR配置有关的错误。因此，最近提出了专门为测试AUTOSAR项目设计的静态测试方法。  在教育背景下，为学习者提供一种简单易懂的方式来评估他们自己的表现或进步也很重要。此外，还需要一个指标来比较相互竞争的实施方案，以便选择应该被看好的解决方案进行进一步测试。因此，在本文中提出了一个在汽车软件工程教育背景下的AUTOSAR项目的静态分析方法。与一般用途的提示器一样，这种方法提供了质量指标和可能的错误检测，但以AUTOSAR特定的方式，使其对汽车领域的学习者和开发者更加有用。此外，还会根据检测到的问题提供纠正建议。本文展示了如何利用这些静态分析来评估和提高AUTOSAR项目的质量。

AUTOSAR特定静态分析

如前所述，本文提出的方法有两个目的，一方面是为开发人员，特别是学习者提供一个简单而便捷的方法来评估他们的表现，另一方面是在动态和集成测试阶段之前提高汽车软件项目的质量。提出方法与V型模型中的四个主要发展里程碑相结合，如图1所示（M1至M4）。在第一个里程碑中，支持的对象是单个功能的开发者，他们会根据所进行的静态分析得到提示。这提高了AUTOSAR项目在实施过程中的代码库质量，确保了与标准有关的一致行为，并通过纠正建议促进了学习效果。第二个里程碑在正常测试过程开始之前。这里进行的检查可能比在里程碑一的检查更严格。例如，对某些模式的遵守可以被强制执行，而在第一步中只建议更改。这是必要的，因为开发人员可能会在(原型)开发期间忽略提示，或者以非标准兼容的方式合并建议的纠正。因此，在这个里程碑的分析确保了测试过程开始前的预期质量水平。事实上，如果使用虚拟验证平台，这个里程碑可能存在两次。在这种情况下，在V模型中建立第二个测试分支（见图1），并在虚拟平台上测试AUTOSAR应用之前执行检查。然后在V模型的右侧分支中正常处理常规测试流程。在目标ECU上动态测试实际代码之前的第三个里程碑，不仅要检查应用程序的质量，还要检查基本软件（BSW）和RTE。这可能是这个过程中最重要的一步，因为AUTOSAR提供了大量的参数作为ECU配置的一部分。这个配置需要以一种特定于应用程序的方式创建，这意味着在这一点上的修改可能也需要对应用程序进行调整。第四个里程碑位于开发过程的后期，对整个 AUTOSAR 项目的质量进行评估，因此涉及的检查可能与之前的检查非常不同。这个里程碑的想法是确保应用程序的高质量，并评估它们是否适合被添加到跨项目的汽车库中。该库中的应用将在其他项目中以新的配置重新使用，因此要遵守更严格的合规性和兼容性要求。特别是通过第二和第四个里程碑的检查，可以对参与项目的开发人员进行分类或评估。因此，它们已被用作AUTOSAR软件工程自适应学习概念的一部分。总之，里程碑M1至M4的检查旨在实现AUTOSAR开发的以下方面：

M1  通过改正建议为个别开发者提供支持

M2 对AUTOSAR应用的分析，以及对目前开发草案RTE部分内容的分析

M3  对BSW和最终RTE应用特定的检查

M4  应用特定的BSW和RTE的动态测试，适合于整合到库中

图 2.  静态测试AUTOSAR

如图2所示，AUTOSAR项目主要由配置文件和源代码组成，这些文件都是由提出的静态测试来分析的。这些测试与实际使用的工具链无关，只要对正式的、标准化的文件进行分析即可。该分析建立在一个广泛的知识库上，其中包含AUTOSAR的架构信息。该知识库主要包括BSW及其模块以及RTE的信息。每个AUTOSAR版本的信息都是单独存储的，从而能够支持针对不同版本和供应商堆栈的并行开发。每个静态分析都可能产生一个修正建议，包括对程序员的解释。如果应用了此修正，并且项目文件发生了更改，那么该检查也将重新运行。这就避免了在项目中因错误应用纠正建议而造成的错误。如果在分析过程中确实发生了问题，但没有进行修正，则在分析报告中增加一个单独的报告条目。该报告条目包含关于文件、行号和分析模块的信息。

A. 分析的对象

静态分析的对象是某AUTOSAR项目的文件。这包括所有架构层，即应用、BSW和RTE。除了在每个文件的基础上进行分析外，我们还解决和比较不同位置和层之间的属性问题。 

虽然AUTOSAR项目可以由不同供应商的不同工具创建，但它通常由以下类型的文件组成：

●   源代码文件（c和h文件）

●   AUTOSAR标准规定的配置文件

●   供应商指定的配置文件

该静态分析是基于对所谓方面的定义。一个方面确定了相关分析的调查重点。目前，对于每个被分析的项目，可以定义一组具有以下属性的问题：

●  颗粒度

●   AUTOSAR 层

一个方面的粒度目前可以是三个不同的类别之一--文件、函数和代码/配置行，如表I所示。

相应的，AUTOSAR层方面是应用层、BSW和RTE。每一个方面a的分析都会产生一个相应的覆盖值cva，它是成功检查的实体数量(取决于粒度)和这个方面中实体总数之间的比率，例如cva = #检查的entitiesa /#entitiesa(#是基数)。

B. AUTOSAR一致性等级

一组覆盖率值可用于计算AUTOSAR软件项目或项目部分的单一、整体质量值。这种综合指标称为 AUTOSAR 一致性水平 CL。让cva指定给定方面a的一致性值和ωa的严重度，那么集合A中各方面的CL可以用以下方法计算:

其结果是一个单一的值，它提供了一个简明的方法来快速评估AUTOSAR项目在标准一致性方面的质量。在下一节中，将展示如何使用一致性值和级别来提高资源利用率和开发人员在基于AUTOSAR的汽车开发和测试基础设施中的反馈。

应用和用例

对于汽车软件工程研究课程的发展，我们已经建立了工作流程，如图3所示，该流程已在[4]中提出。在那里，学习者可以在基于AUTOSAR的实施方案的开发周期中承担不同的角色。它们得到了两个工具的支持。ASTAS（AUTOSAR系统的应用规格测试）和TUC驱动云。前者提供了测试AUTOSAR ECU的方法，而后者则提供了一个测试驱动管理接口，以及访问汽车测试驱动数据的大数据存储的标准化方法。

图 3.  已部署的汽车软件工程工具链与图1中注释的测试步骤

由于本文提出的AUTOSAR特定静态测试已被整合到ASTAS中，本节将把重点放在这里。图4说明了测试AUTOSAR项目的原型的工作流程，以及ASTAS在这个过程中的整合。ASTAS包含用于分析AUTOSAR项目的软件模块和用于AUTOSAR ECU动态测试的软件模块。除了AUTOSAR特定的静态测试，ASTAS还支持以连续的方式对BSW和RTE进行应用特定的测试。这种测试方法是用符合AUTOSAR的方法实现的，并支持错误定位。知识库包含了在目标平台上实现动态测试的所有必要信息。关于这种方法的细节在[18]中解释。除了自有的功能之外，还整合了一个商业工具链，用于代码分析、构建和测试。在开发和教学过程中，从以下方面检查项目：

●    AUTOSAR应用之间的连接(M1, M2)

●   符合AUTOSAR BSW（M2）的要求

●   产生的RTE与应用程序和BSW的一致性（M2, M3）

●   整个AUTOSAR应用的一致性（M1, M4）

图 4.  通过ASTAS和集成工具链测试AUTOSAR系统的工作流程

图 5.  应用程序中软件组件之间未连接端口的例子

第一个检查是评估应用程序内通信的一致性。AUTOSAR在应用中定义了所谓的软件组件，它代表了ECU的实际功能。为了实现部分或完整应用的可重复使用性，软件组件内的通信需要符合标准。然而，遵守标准通常意味着实施者要做额外的工作，而学习者往往在一开始就尽量避免。因此，在实施过程中，使用这种考核是确保软件质量的一个非常重要的辅助手段。AUTOSAR ECU的BSW是根据映射的应用进行配置的，由一组不同的模块组成。为了确保符合标准，第二次评估根据应用情况检查项目中的集成和配置模块。这一步骤确保了应用程序在以后开发中的可扩展性。在实施应用和配置BSW之后，AUTOSAR方法论规定了RTE的生成。这是在目标平台上测试前的最后一步。由于不同的层（RTE、BSW、Application）可以使用不同的工具进行开发，AUTOSAR ECU的所有三个层的一致性需要得到确认。这种检查避免了测试过程后面步骤中代价高昂的错误定位。第四个方面是单独测试应用程序。它包含关于代码合规性、架构和编码准则的检查。通过这种方式，希望确保AUTOSAR库的软件质量，其中包含用于教学、学生自我评估以及研究课题的应用程序。例如，我们正在使用这些评估层面，对研究示范车Yellow Car 进行持续测试，其中包括3个符合AUTOSAR的ECU。在汽车软件课程教学方面，最重要的应用之一是灯光控制，它管理着汽车的不同灯光（如内部、外部）。灯光控制的主要功能被映射到一个ECU，由11个软件组件组成，共有48个端口。AUTOSAR应用之间的联系评估了AUTOSAR规格化的配置文件，称为系统描述。就灯光控制而言，已经检查了3429行的配置和262行的代码。为了演示各层面检查的目的，想象一下图5中的情景：在当前的开发中，应该集成两个新的端口。这些端口能够集成一个活跃的信号，代表对其他ECU的可用性。被指定的开发者已经在软件架构中实现了这些端口，但它们在RTE中没有端点。因此，该评估将显示96%的符合性（见公式2）。但是，我们对连接端口的测试配置将100%定义为严格的要求。因此，程序员需要解决断

开连接的端口。这个检查乍一看可能是微不足道的，但是因为即使没有连接的端口，代码也是可编译的，它是在开发后期才会被检测到的方面，从而产生不必要的额外费用。此外，根据经验，这种错误经常发生，特别是对AUTOSAR新手来说。除此之外，ASTAS目前的检查还分析了端口的更多属性，而不仅仅是连接。

由于我们有两个端口，一个具有require属性，第二个端口具有provid属性，ASTAS建议用户用一个接口连接这两个端口。为此，用户可以选择发送者-接收器和客户端-服务器的通信原则。图6显示了程序员批准后进行的修正。在这种情况下，修正改变了系统描述，这是一个正式的标准化AUTOSAR配置文件。一个发送者-接收者接口已经创建，并被分配给两个新的端口。之后，在集成的商业工具链中触发RTE生成，以创建RTE端点。

图 6.  系统描述中对架构中断开的端口的更正

图7显示了在AUTOSAR项目中通过采用自动修正建议所能实现的改进。左边的条形图代表了在引入建议的静态分析之前的学生项目的CL。

图 7.  通过使用拟议的AUTOSAR特定静态测试改善CL

右边的条形图显示了运行静态分析后的CL值。可以看出，在开发过程中，不同架构层的组合获得了最大的改善。这一阶段对学生来说往往是一个挑战，因为它需要对整个标准有深刻的了解，包括其方法和异质的AUTOSAR工具链。

结论和未来的工作

本文提出的测试策略促进了AUTOSAR项目的发展。程序员可以通过AUTOSAR特定的静态分析来支持配置和C代码，而一般静态分析工具只支持C代码。静态分析涵盖了系统架构的所有架构层，并且独立于正在使用的AUTOSAR版本和工具链。使用建议的方法，通过提高学生AUTOSAR项目的质量来改善应用程序的可重复使用性。此外，该静态分析通过对AUTOSAR标准的解释和参考，帮助学习者了解软件质量的不同方面，这些问题在架构中都有显示。因此，ASTAS的静态分析是汽车软件工程硕士研究课程中的一个重要教学部分，特别是从电子学习的角度来看。

在未来，希望将这一概念进一步发展到自我学习和自我评估的方向，其中个人统计变得更加重要。例如，我们通过直接向学习者展示一致性值和水平随时间的变化来探索对学习者动机的影响。

文章转载自公众号：智能汽车开发者平台