adas功能的测试方法和测试标准（ADAS软件测试的代码生成器）

adas功能的测试方法和测试标准（ADAS软件测试的代码生成器）本文由五部分组成。第 2 节介绍了现有的测试环境生成器 (TEG) 及其实现方法。第 3 节中给出了对现有 TEG 的改进建议的详细信息。第 4 节介绍了使用改进后的 TEG 获得的结果，并附有讨论。最后给出了结论和对未来工作的建议。因此，增强的程序允许在现代多核处理器上对程序的整体运行进行多重加速，并能够跳过部分程序以节省时间。该测试环境允许在汽车计算机系统上工作的工程师能够实现流程和程序的自动化，否则由于物流和时间的限制，这些流程和程序是不可能人工完成的。它还允许他们对系统进行压力测试，而不必使用实际的组件并冒着失败的风险。一个高质量的测试环境是至关重要的，因为不正确的汽车部件模拟或不正确的数据处理会导致代码在实际执行中出现灾难性的故障。因此，模拟测试环境是一个细致和耗时的过程，但对于开发ADAS系统是必不可少的。本文对测试ADAS系统的软件解决方案进行了升级，重点是通信。所提出的解决

ADAS系统是协助司机驾驶车辆的电子系统。ADAS系统可以直接影响汽车的一些部件，目的是为了从完成更安全和更舒适的驾驶的角度开发各种有用的功能：从自动点火灯和交通标志识别到与智能手机的整合。

ADAS通信系统运行的一个关键因素是其组件之间的通信。利用该传感器，汽车的计算机系统接收有关汽车周边环境的信息，即感知环境。这些传感器是激光雷达、雷达、照相机和超声波传感器等。传感器提供的信息由适当的算法处理，并获得所需的输出：自动刹车、根据检测到的限速标志对车辆进行减速、司机监控、交通线检测和警告司机越线，等等。

由于ADAS系统本身会对交通、车辆和驾驶者本身产生重大影响，它们必须经过详细的测试并适应严格的标准。在 ADAS 中实施的软件系统必须结构稳健且能够适应变化，具有标准化的代码惯例，最重要的是，其测量和结果必须保持一致。

需要对标准化的通信进行测试，最好是在系统内开发测试代码，以测试AUTOSAR的通信模型。AUTOSAR是一个由汽车公司组成的国际伙伴关系，其目的是在汽车开发环境中的软件和硬件架构创建中引入标准化。

该测试环境允许在汽车计算机系统上工作的工程师能够实现流程和程序的自动化，否则由于物流和时间的限制，这些流程和程序是不可能人工完成的。它还允许他们对系统进行压力测试，而不必使用实际的组件并冒着失败的风险。一个高质量的测试环境是至关重要的，因为不正确的汽车部件模拟或不正确的数据处理会导致代码在实际执行中出现灾难性的故障。

因此，模拟测试环境是一个细致和耗时的过程，但对于开发ADAS系统是必不可少的。

本文对测试ADAS系统的软件解决方案进行了升级，重点是通信。所提出的解决方案使用创建的发生器和测试环境来测试汽车中或 ECU 的 CPU 内部的控制单元之间的通信。所提出的解决方案是基于加速现有的测试环境生成过程的方法，主要是在多个计算机进程中同时分配程序工作，但也可以使用在多个程序运行中消除冗余的解决方案。

因此，增强的程序允许在现代多核处理器上对程序的整体运行进行多重加速，并能够跳过部分程序以节省时间。

本文由五部分组成。第 2 节介绍了现有的测试环境生成器 (TEG) 及其实现方法。第 3 节中给出了对现有 TEG 的改进建议的详细信息。第 4 节介绍了使用改进后的 TEG 获得的结果，并附有讨论。最后给出了结论和对未来工作的建议。

II.测试环境生成器

用于汽车测试的测试环境生成器是基于AUTOSAR环境，有助于测试汽车系统和部件之间的通信。AUTOSAR采用三层架构：

• 基础软件：一套标准化的软件模块，包含操作顶层、应用层所需的服务。
• RTE：用于交换信息的中间层，即基础层和应用层之间的通信。
• 应用层：与 RTE 通信的应用软件组件。

TEG位于AUTOSAR通信的中间层。输入端的 TEG 收集特定 ECU 的信号数据，并以此为基础在输出端生成通信环境模型。本节更详细地描述了 TEG 的工作。更确切地说，本节分析了一个具体的现有解决方案，并在随后的章节中提出了修改意见。

A. 基于AUTOSAR的通信

ARXML（AUTOSAR XML）是一种特殊类型的XML文件，专门用于汽车开发环境，用于存储有关所使用的通信输入和输出的数据、发送的数据包和处理这些数据的软件组件。ARXML模式是XML数据语言的特殊定义，用于交换AUTOSAR通信模型，其中包含信号类型、组件和输入输出端口信息。

它是一个W3C矩阵，定义了AUTOSAR模型交换的语言。该矩阵源于AUTOSAR的主要描述性模型，并定义了AUTOSAR的数据交换格式。

ARXML 文档表示单个 ECU 的配置，该ECU解释了它使用的原始数据类型。它代表了每个ECU在两个或多个ECU之间通信时使用的特定端口、软件组件和信号。因此，ARXML定义了特定ECU通信所需的所有数据类型，从基本类型（int float string）到更复杂的类型（list objects）。

使用基本类型，ARXML以信号和发送这些信号的相关端口的形式建立了一个通信的数据模型。它还包含了进一步处理数据所需的软件组件清单。

ECU ARXML 文件是深度 XML 文件，其大小可能因 ECU 和应用程序而异，从几千字节到几百兆字节不等。这些文件中的数据从原始数据类型开始描述 然后ARXML 中的所有其他数据定义都引用到这些原始数据类型。

B. 测试环境发生器的工作原理

为了使用从ECU收集的信息来测试ECU模型，有必要将信号和通信分解成有意义的单元和软件组件（SWC）之间的关系，在此基础上可以生成一个测试环境。这就是 TEG 的任务。来自ARXML的分类数据首先被收集在一个复杂的数据结构中，该结构是在程序环境中创建的。所创建的结构比.arxml文件的访问速度更快，它形成了一个内部数据源，需要识别特定的代码，这些代码需要注入到共同构成模型的软件组件（SWC）的特定和预先确定的代码片段中。

在TEG的输入文件中，有一个包含模板的.c文件，这些模板被输送到由特定ECU配置预定义的SWCs中 。根据从ARXML文件中收集的数据，确定必要的模板（具体到每个SWC），然后将变量和值添加到SWC的模板中。

C. 现有解决方案的架构

现有的测试环境生成器有一个解析的文件结构，程序代码与生成的数据、数据库和输入分开。每次TEG运行时，它都会检查相应的.ini文件中配置的文件结构的布局。生成器代码本身被分成几个相关的函数，构成了前面提到的实体，并以Python编程语言实现。ython 2.7 版与其标准库一起使用，并带有一个用于解析 XML 和结构相似的文件类型的附加模块 - LXML。

解析后的数据存储是通过Python的标准Pickle模块完成的，随同生成的XML用于对解析后的数据的修订。程序生成器的组件使用存储的数据将代码片段放置在的用 C 编程语言编写的主 .c 文件中的模板中指定位置 （较小的C类文件，代表构成模型的组件）。然后，同样的代码被TEG再次传递过去，特定的变量或数值被放入片段中。因此，TEG被分为三个主要部分：

1) 解析器

解析器的目的是提取特定ECU的配置数据，在此基础上生成模型。解析器接收.arxml文件形式的数据，浏览其结构，并将解析后的数据以复杂的数据结构形式存储，并在整个TEG中进一步使用。现有的TEG的核心组件是一个高度复杂的Python对象，它由结构化的预定义类的模板初始化，这些模板都相互引用并形成底层对象，即所谓TOM。

TOM反映了ARXML的层次结构，它从层次结构中最高的对象开始，称为根--TOM根。TOM根，连同ARXML文件的位置，被作为参数传递给解析函数，该函数迭代地通过ARXML中的所有数据，并通过逻辑分支将它们存储在TOM子对象中。TOM的架构与ARXML的架构密切相关，它限制了解析器在XML格式中的顺序传递，使其速度变慢，因为ARXML架构需要由Python架构纪实地表示出来，而且随着ARXML文件越来越大，这一任务会成倍增加。

当所有来自ARXML的相关数据被传输到TOM Root时，解析器的操作就被认为是完成了，然后TOM Root被存储在RAM中供将来参考。

2) 数据存储

从.arxml文件解析出来的数据被储存起来，以便在出现错误或调整时进一步检查输入数据的有效性，并作为备份。收集的数据代表了TEG的生成器组件进一步运行所需的所有数据。

TEG的现有解决方案依赖于用于序列化存储的标准Python模块--Pickle。存储函数在解析器函数之后启动，并接收TOM Root和所需的.pickle文件的存储位置作为参数。有了这个功能，整个TOM Root被序列化为上述文件，即使在执行程序后，该文件仍被永久存储在输出目录中。

除了pickle功能外，TOM Root还以复杂的XML格式存储，作为一个次要的、更容易被人阅读的来源。这样做的目的是为了更容易调整程序，也更容易排除潜在的错误。XML存储功能，很像一个解析器，使用逻辑分支和递归，将TOM内容解析为链接的XML部分。XML文件也是用LXML模块生成的。

3) 代码生成器

从.arxml文档中解析出来的数据被注入到模板和软件组件中实现的C代码的特定切口中，同时还有变量的相应值。

测试代码生成函数接收 TOM Root 和主 .c 文件的位置作为参数，其中包含模板和所需的 SWC 组件，也是 .c 文件的形式。它使用正则表达式（RegEx）方法将TOM数据逻辑地过滤成上述模板，即代码片断。然后将模板插入到SWC .c文件中预定义的位置。

发电机操作是迄今为止要求最高的TEG组件，其运行时间取决于输入文件的大小。生成器还被设计为在组装模型组件时按顺序使用RegEx，因为输入量增加，这对程序性能（就时间而言）产生了负面影响。

III.测试环境生成器的改进

本文的基本目的是加速现有的TEG。随着输入数据的增加，整个程序的执行时间会明显增加，这是一个实际问题。此外，目标是创造一种更稳定的数据库存储形式，而不是将数据序列化作为一种存储方法。具体来说，对升级版的TEG的要求是：

• 加速现有的TEG，使其在解析和生成输出文件方面花费更少的时间。
• 利用更稳定和透明的存储方法。
• 拟议的解决方案是通过对现有解决方案实施代码更改来实现的。

这些变化是针对程序的每一部分的，但其结构和执行顺序保持不变。因此，提议的解决方案使用Python 2.7。TEG在启动时检查.ini配置文件，该文件包含一个独特的哈希字符串，代表其中的文件结构。TEG的主要组件，即解析器，以同样的方式运行--通过ARXML的可选Python LXML解析器模块。ARXML被解析成一个初始化的TOM--底层对象。然后Python多处理模块同时将TOM发送给生成器，并使用Python SQLite模块存储在SQL数据库中。生成器收到TOM后，通过一个新的多进程实例，在多个进程中同时生成SWC。当在一个相同的数据集上递归运行TEG时，TEG有能力跳过解析过程以节省时间。

A. 加速

由于ARXML文件的结构和底层对象的TOM结构，如果不彻底重组整个现有的解决方案，就不可能对解析器的操作进行重大改变以加速它。然而，开发了一种加速整个TEG运行的方法--更具体地说，就是完全避免运行解析器，以节省整个程序运行时间的形式。

加速是通过验证新版本TEG的结构与写入数据库文件的最后一个结构来实现的，这允许程序跳过冗余解析操作。为此使用了一个标准的 Python hashlib 模块。

还有一个问题是，生成器内部的累积操作会大大降低TEG的执行速度，特别是在数据量增加的情况下。显然，加速进程的最直接方法是将现有的算法进程划分给更多的处理器核心，从而利用现代硬件架构。通过使用多个进程，预计TEG的执行速度将大大加快，因为生成器是TEG中最耗时的部分。

因此，实现了Python的多进程模块，它将一个或多个函数的操作分解成多个进程。该解决方案将每个SWC分离成多个并发的进程。SWC根据计算机上可用的核心总数来分配计算机核心。来自主C文档的片段或模板使用正则表达式作为组件并行输入，然后与特定 ECU 相关的值也输入到预先批准的位置。

B. 储存

数据序列化被关系数据库所取代。关系数据库是基于关系数据模型的。在关系数据模型中，数据被表示为N对分组的表，即关系。因此，关系数据模型中的每一个n对实际上是一个表中的一行，有一定数量的命名列，代表了存储在表中的对象的属性名称。管理关系型数据库的系统被称为RDBMS(Relational Data BaseManagement System)。

本文采用SQLite作为关系数据库。SQLite允许我们使用Python命令来创建、写入、交互和删除SQL数据库。存储在SQLite文件中的数据库很容易被移动，因为它只是一个文件，通常非常小，并且独立于其他外部库和程序。此外，SQLite很容易获得（开放源码），而且非常流行，这意味着强大的软件支持。

在运行SQLite数据库的存储函数之前，现有TEG解决方案的父数据库功能用代表TOM Root的初始表创建了数据库的基础。数据存储函数接收参数Tom Root、初始表和文件系统中的数据库位置。该函数依次通过TOM中的每个对象，分别验证每个单独的属性。最初，每个属性通过一个逻辑过滤器来检测抛出的错误（错误的数据类型、语法错误、空白数据）。

然后，通过逻辑分支，确定它们是否是基本数据类型（整数、浮点数、字符串、长）、不可变的n元组列表、数据集还是嵌套对象。在第一种情况下，当前表中的数据库（与对象共享名称）会创建一个新的列（如果当前不存在此列）。

对于数据集、列表和嵌套对象，则启动一个递归函数，在一个单独的循环中存储数据。然后，该函数接收要进入递归的对象、它的表以及它将通过外键引用的父对象的表，作为参数。因此，数据存储函数递归地遍历整个TOM，并将其内容存储在一个复杂的关系数据库中。

在ARXML标准中，组件名称经常重复。由于这个原因，在创建表名时，由于SQL的特殊性，不允许两个表有相同的名字，因此在每个表上都加了一个数字前缀，以避免由于表名相同而产生的错误。在每次创建新表时，通过移动整数类型变量可以获得前缀，对于TOMRoot表来说，是从零开始的。哈希字符串也被存储在数据库中，以避免递归运行TEG时的冗余。对数据库的写入是与生成器的操作同时进行的。

IV.成果与讨论

根据本文框架内的变化或改进，包括多处理的逻辑、处理现有功能的逻辑、覆盖程序中的现有步骤以及过渡到存储相同数据的不同形式，有必要以下列方式检查改进：

• 验证在SQLite数据库中传输的数据记录是否正确，以及
• 测量改进后的的TEG的性能速度，并与现有的解决方案进行比较。

对现有的和升级后的测试环境发生器的所有测试都是在同一数据集上进行的，其执行形式是两个5.2和5.6MB的.arxml文件，同时进行处理。

测试是在一台运行Windows 10、Python 2.7版本的计算机上进行的，硬件规格见表1。

表I. 测试计算机硬件规格

A. 使用的测试描述

对SQLite数据库中传输数据的正确性的验证是通过手动比较从数据库传输到生成器的两个测试可用的值，可以对SQLite数据库中传输数据的正确性进行验证。生成器代码输入临时函数，打印它在一个单独的日志文件中所传递的所有数值，用于现有和新的解决方案，然后进行比较以确定有效性。

TEG加速性能的验证是通过一个单独的Python模块完成的，该模块在Windows命令行中列出了TEG各个部分(解析器、基础程序、生成器)的执行时间和总运行时间。时间以h:mm:ss.ss的格式表示。使用一个标准的Python时间模块来处理测量。

B. 有效性测试的结果

由于SQLite数据库由填满数据的表和列组成，而Pickle数据只是TOM代码的序列化形式，因此不可能直接比较两种解决方案的内容。因此，需要在TEG操作的下一步中进行比较，在不同的TEG版本之间匹配随机选择的存储数据。

通过测试，发现现有的解决方案需要大量的时间（超过6小时），并进一步解释了为什么本文的任务完全集中在时间性能上。

C. SQL数据库设置排列的效果测量

在制作SQLite数据库时，可以采取一定的安全措施来影响速度，但也可以影响他们所做的数据库的写入或读出的质量。在SQLite Python模块中，可以使用独特的PRAGMA语句来影响这些措施。PRAGMA作为关键词被调用，紧随其后的是要改变的数据库设置，然后是新的数值。以下测量有三种排列方式：

• 标准SQL数据库设置
• 同步查询写入数据库（SYNCHRONOUS）
• 在数据库中保存记录的日志(JOURNAL_MODE)

1) 标准设置

使用激活同步写入和日志记录的标准设置进行第一次测量。一个完全优化的SQLite数据库的标准设置将TEG的执行时间增加至11分钟到12分钟，而使用Pickle序列化的现有解决方案，其性能只持续了几秒钟（与程序的生成器部分并行工作）。

2) 同步关闭

在接下来的实验中，禁用对数据库的同步写入要求，写入工作由操作系统负责。这种方法极大地提高了每秒查询的速度，但可能会发生数据日志错误，影响数据库的稳定性。诚然，在测试过程中没有观察到记录中的错误，或改变这个度量的负面后果，至少在这种规模的测试数据中没有观察到。

经测量，TEG的平均运行时间为2分8秒。通过将控制权移交给操作系统，来加速对数据库的写入。这一措施将运行时间降低到与Pickle模块的并行TEG性能的时间差不多。这也是除标准配置外最稳定的方法。

3) 内存日志模式

最后，修改了将日志记录写入数据库的设置。这个设置可以有更多的值。标准值是一个日志条目，与数据库中的记录平行，位于与文档相同的目录中。本测试中使用的值将日志设置从ON改为MEMORY。MEMORY设置将运行和日志记录转移到计算机的工作存储器中，当数据库完成后，它将被删除。

这一措施还显著增加了每秒的查询数量，但更改此设置会影响创建和编写SQL数据库的安全性，因为在发生重大计算机故障(电源故障、手动程序中断等)时，可能会发生数据库完全丢失。

在采用了架构改进和实现了修正的JOURNAL_MODE设置SQL数据库的情况下，可以计算出TEG的平均运行时间为两分四十八秒。将日志保存在计算机的工作内存中的数据库中(而不保存到磁盘)，这一方法会导致性能略慢于上一种方法，但它也是标准之外最安全的方法。

D. 加速工作测量

第一个测量是在现有生成器上使用标准多处理Python模块的TEG的性能。与之前的6个小时相比，本示例的处理时间大约为1分30秒。从比较中可以了解到，由于使用了多处理模块，生成数据的TEG部分在时间方面显著减少。

TEG的平均持续时间约为1分31秒，比现有解决方案约少180倍。然后，使用采用的哈希字符串在生成器上执行测量，该哈希字符串允许程序跳过主组件——解析器的执行。引入哈希字符串后，TEG的运行时间减少了10%。使用多处理模块和能成功得识别哈希字符串的TEG平均运行时间为1分22秒。

E. 讨论

写入一个新的数据库，即不使用序列化，而是使用SQLite数据库，产生了的结果与现有解决方案类似（更准确地说，整个程序的最终执行是不可察觉的）。因此，不能说数据存储过程本身加快了，但如果配置得当，它的时间性能可以与现有解决方案相当，还能增加数据库的安全性、稳定性和透明度。此外，由于数据是在生成器运行的同时写入数据库的，这将花费更长的时间，所以优化配置的基库不会对TEG的整体时间产生很大影响。

根据执行记录获得的测量结果，即在TEG中的数据存储和它们的平均前置时间，推荐第三种方案，即改变计算机工作内存中的日志存储（保持SYNCHRONOUS测量开启）。由于增强型TEG的性能极短，相对于其他措施可能带来的错误记录数据的问题，重复性能的时间损失可以忽略不计。

然而，使用多处理和哈希模块极大地减少了总运行时间，而且没有不必要的副作用。然而，该模块的有效性取决于运行该程序的所使用的硬件。从图1中可以看出提议的pickle（带多处理）方案（E1）、提议的SQL安全优化（带多处理）方案（E2）和现有方案（E3）的性能差异。

V.结论及未来的工作

要测试汽车计算机硬件和软件之间的中间件层，需要使用测试环境生成器(TEG)。通过使用不同的TEG配置，可以进行多次测试和模拟，从而定性地检查ADAS系统的性能。TEG在ECU上获取通信数据，并在其测试环境中生成通信模拟，以验证ADAS系统是否正常工作。

图1 TEG平均运行时间（分钟）

TEG有三个主要组件:解析器、数据存储和生成器。本文的目的是提高各个组件的执行速度和稳定性。这种改进可以是基于算法和架构方面的，主要目标是缩短TEG的总执行时间，并引入更稳定、更安全的数据存储。TEG的核心组件是一个复杂的Python对象(TOM)，它被设计用来跟踪解析它的ARXML文件的结构。

TOM作为主要参数提交给代表TEG三个主要组件的三个主要函数，因此如果没有更充足的时间来了解现有解决方案，是不可能重新设计它的，而且可能超出一篇论文的范围。现有解析器的工作与通过ARXML并初始化和写入TOM的一个循环有关。需要做两次数据存储：用一个单独的XML文件进行数据解析以及Pickle序列化。生成器还迭代浏览了.c 代码模板，并将它们按顺序放入SWC组件。

如果不需要解析器的话，解析器可以通过一个哈希字符串来加速，该字符串将新的TEG的结构与旧的TEG进行比较，从而绕过解析器。数据存储的加速还没有实现，但可以认为可以与现有的解决方案相媲美。拥有一个更稳定、更安全、可读性更强的基库所带来的额外好处是非常重要的，特别是由于基库与明显更长的发电机寿命并排存放，所以不会影响整个TEG的执行时间。

工作生成器的特点是快速引入了单个SWC组件的并行处理，最初生成的SWC列表被划分为独立的计算过程。根据所有的测量和示例，很明显，本文开始时设定的目标已经成功实现，因为执行时间已经减少了大约180倍。

TEG未来可能的改进包括重新设计进入TEG的ARXML文件，使之成为较小的7arxml文件，每个文件代表一个SWC组件，以及重新设计底层对象的TOM结构，使之可以同时在多个进程中工作。为了降低处理时间，可以考虑将整个TEG移植到C语言中。