汽车领域：基础软件验证平台

01.验证平台概要

汽车电子的高速发展决定了基础软件所面临的要求将会更加严格，其要求会覆盖软件的安全性、稳定性、可扩展性等方方面面。为了提高软件质量，降低软件应用风险，构建高安全、高可靠性、高效率实施的基础软件验证平台则是必不可少的一环。 

当前，汽车电子厂商大多采用V模式进行新产品开发，相应的，基础软件验证也可以参照V模型流程，持续进行不同层面的验证，如图1.1所示。

▲图1.1 V模式研发流程

充分的测试验证需实现需求阶段至系统阶段的全覆盖。

例如：

在需求分析阶段，要考虑系统验证的计划，包括确保每一个需求点都是可验证的，并设计相应的初步系统验证用例；

在概要设计阶段，要考虑部件验证计划，设计相应用例，验证高级模块的功能以及模块之间的接口关系；

在详细设计阶段，要考虑单元验证计划，编制单元验证用例。

进行基础软件验证时需按照顺序开展代码静态验证、单元验证、部件验证（包括软软集成、软硬集成）、系统验证等测试执行工作。其验证类型可分为白盒测试、黑盒测试两类。白盒测试包含代码静态验证、单元验证，重点侧重于代码逻辑、接口实现等内容。黑盒测试包含部件验证、系统验证，重点侧重于硬件功能实现、人机交互实现及通信功能实现等内容。例如，后文提及的时间特性分析验证平台属于单元验证的内容，通信相关技术验证平台属于部件验证内容。

▲图1.2 基础软件验证过程

总体而言，每部分的软件验证包括五个基本过程：测试需求分析、测试策划、设计与实现、测试执行、测试总结，其流程如图1.2所示。

同时，为了提高效率，节约人力和成本，可用适宜的自动化测试工具以及相应的管理措施与管理工具，以保障需求得到充分的验证。

此外，基础软件验证平台还应该通过静态分析、仿真、在环测试等手段验证设计和实现的有效性。其中，仿真验证平台因为有利于前期验证及特殊测试用例注入，可以节省测试环境成本及缩短开发周期。而且由于基于分布式开发需求，验证平台目前正往云端迁移。

02.验证平台典型案例

2.1 通信相关验证技术

随着汽车智能网联化、新型电子电气架构的发展，作为车辆神经系统的汽车通信技术也面临着越来越多的新需求。基础软件所具备软硬件分离、软件接口的互换及重复使用特性等特点可以更好地实现车载网络现阶段发展中所遇到的总线类型多元化、协议应用多元化等需求。为保证基础软件在车载通信上的应用，其验证相关技术是必不可少的环节。结合基础软件COM、CANNm、CANTp等基础模块单元，通信相关验证平台需包括通信验证、网络管理验证、诊断服务验证、时间同步验证等方面。

2.1.1 网络通信测试验证

网络通信是实现汽车各控制器进行信息交互的桥梁，无论是传统的分布式电子电气架构，还是域控制器架构，或是基于中央大脑的电子电气架构，其在汽车主干网中常用的总线通信类型大致包含CAN总线、LIN总线、以太网三类。此外，智能网联化的发展也对车辆的网络通信提出了大带宽、高时效，功能及信息安全防护等要求。上述三类网络通信方式的组合及其在基础软件验证平台的应用，基本能够满足汽车在不同架构类型及不同功能场景下的通信需求。与之相对应的基础测试验证则成为了检验基础软件是否满足通信需求的重要一环。 

1. 需求分析

基础软件虽然具备软硬件的解耦、接口的可复用性、平台的可移植性等优势，但是其可灵活配置的特性也决定了其面向整车系统时配置参数具有差异化或在基础软件代码开发移植阶段存在不满足整车通信需求的情况。例如某一车型平台或某一架构下各个控制器的基础软件在开发阶段的通信参数设置、信号交互、总线通信故障处理逻辑等与期望不一致的情况。这些差异化的内容往往会导致汽车总线无法通信、功能无法正常执行等问题，因此网络通信测试的验证务必在单个控制器开发完成后进行，以保证装车后的通信质量。

2. 验证方法

CAN/LIN网络通信的验证主要针对通信配置参数、总线容错处理及恢复逻辑、报文交互等内容进行验证，因此测试设计方法主要为需求分析方法、边界值分析、等价类法。为实现网络通信验证，需视不同的需求搭建测试环境。网络通信验证的测试环境可分为基于示波器的测试、基于总线分析仪的测试、基于总线干扰仪的测试三类。

3. 验证范围

依据OSI模型，为保证基础软件开发严格按照需求进行，需针对通信需求内容进行覆盖。网络通信的测试验证主要包含数据链路层、交互层、应用层测试。数据链路层主要针对采样点、波特率、帧类型兼容等层面进行基础软件通信配置参数的验证；交互层主要针对车辆的报文交互是否严格按照通信定义开发进行验证，应用层主要针对总线故障及busoff等网络容错处理恢复策略进行验证。此外，如有功能或信息安全的应用，需基于交互层进行算法逻辑的验证。如表1.1为网络通信基础验证的部分用例，详细测试用例中的每条用例应包含有唯一的编号、需明确需求点、测试目的、测试环境、测试步骤、评价标准等内容。

CAN验证范围

▲表2.1 CAN网络通信基础验证部分用例示例

LIN验证范围

▲表2.2 LIN网络通信基础验证部分用例示例

Ethernet验证范围

▲表2.3 Ethernet网络通信基础验证部分用例示例

2.1.2 网络管理测试验证

网络管理主要负责对汽车上控制器进行配置管理和协调工作的，无论是传统的汽油车，还是新兴的电动车，其控制器的供电均是通过蓄电池来提供的。网络管理可以通过车载网络，设计一套规则，来实现各控制器的睡眠和唤醒，以此来减少蓄电池的耗电。例如AUTOSAR-NM是基于AUTOSAR架构提出的网络管理方案，通过BusSleep、PreSleep、Network三个状态及其子状态，来实现整车控制器的协同睡眠和唤醒。因此，网络管理测试对于协同睡眠和唤醒功能的验证是整车功能实现的重要保障。

1. 需求分析

AUTOSAR架构虽然完整定义了网络管理组件中网络状态的类型以及不同网络状态之间跳转的条件，但是实际控制器的网络管理协议栈成熟度各不相同，并且软件模块之间如果没有较好地进行解耦，进而就会造成车辆上下电的不稳定性，某些功能场景也会受到影响。所以不论是单部件环境下的休眠和唤醒还是整车环境下协同休眠和唤醒，都是保障汽车通信和功能实现的重要前提。

2. 验证方法

控制器的网络状态往往在总线中即可获取到，影响其状态跳转的因素基本可分为本地条件与远程条件两类。本地条件与供电关联较强，远程条件与总线状态交互较强，因此结合影响因素，其网络管理的测试验证环境如图2.1所示：

▲图2.1 基于总线分析仪的测试

总线分析仪：用来模拟除控制器外的其他节点发送和接收报文；记录监测总线报文；对控制器进行ACK应答。

电源：通过PC可控模拟不同供电电压。

R1：120Ω；R2:120Ω。

注：若控制器内部含有120Ω终端电阻则无需匹配R2；若控制器内部不含有120Ω终端电阻则需同时匹配R1和R2。

注：若控制器为Ethernet控制器，CAN_H/CAN_L为ETH_P/ETH_N，无终端电阻。

3. 验证范围

为保证单部件控制器网络管理行为的正确性，需要对控制器的网络管理策略进行全方位的测试。网络管理的测试验证主要包含网络管理报文数据格式测试、网络管理状态转换策略测试、特殊网络管理策略测试。网络管理报文数据格式测试主要用来验证控制器的网络管理报文格式是否和需求定义保持一致。网络管理状态转换策略测试主要用来验证控制器的网络状态跳转是否满足规范要求。特殊网络管理策略测试主要用来验证控制器在极端总线条件下（如总线高负载率或总线busoff）的状态跳转是否受到影响。如表2.4为网络管理测试验证部分用例，详细测试用例中的每条用例应包含的内容与网络通信要求一致。

▲表2.4 网络管理测试验证部分用例

2.1.3 诊断服务测试验证

网络诊断应用于车辆的初始目的是确定汽车工作状态，排查汽车故障。随着诊断协议的不断完善，其应用场景也不断在扩展，例如产品开发测试阶段的软件升级、生产阶段的下线配置、售后阶段的故障诊断、用户使用过程中的OTA远程升级以及远程诊断等。这些诊断功能场景基本涵盖了车辆的全生命周期，诊断协议则是实现这些功能的基础原则。因此，诊断服务测试验证是实现诊断功能场景的基本保证。

1. 需求分析

ECU诊断功能是由内部自诊断功能及相关诊断协议组成。通常大多数诊断功能是由两者共同完成的，诊断服务中包含ECU自诊断的数据，维修车辆则是通过诊断协议读取自诊断的数据。例如车辆行驶过程中可能会发生一些故障 , 当故障发生时会以点亮报警灯等方式来提示驾驶员。但具体故障的原因是无法通过报警灯体现的，这时则需要通过车上的OBD接口连接诊断仪来将故障代码读取出来。而诊断测试可实现ECU诊断功能的验证及诊断协议一致性检测，从而确保装车后车辆诊断功能能够正常运行。

2. 验证方法

诊断测试的验证主要针对控制器收发多帧报文情况、诊断服务、子功能、诊断会话控制、安全状态和相关定时参数等内容进行验证。为实现网络诊断验证，搭建下面基于总线分析仪的测试环境。基于总线分析仪的测试设备包括电源、总线分析仪，测试环境如图2.2所示：

▲图2.2 基于总线分析仪的测试

总线分析仪：用来模拟除控制器外其他节点发送和接收报文；记录监测总线报文；对控制器进行ACK应答。

电源：可模拟不同供电电压。

R1\R2：选配型终端电阻120 Ω。对于终端型控制器，需选配R1或R2；对于非终端型控制器，需同时配置R1与R2。

注：若控制器为Ethernet控制器，CAN_H/CAN_L为ETH_P/ETH_N，无终端电阻。

3.验证范围

网络诊断的测试验证主要包含传输层及应用层测试。传输层主要针对控制器能够进行多帧报文的收发等层面进行诊断配置参数的验证；应用层主要针对诊断服务、子功能、诊断会话控制、安全状态和相关定时参数进行验证。如表2.5为网络诊断基础验证的部分用例，详细测试用例中的每条用例应包含有唯一的编号、需明确需求点、测试目的、测试环境、测试步骤、评价标准等内容。

▲表2.5 网络诊断基础验证部分用例

2.1.4 时间同步测试验证

时钟同步功能给车载系统提供统一的时间基准，在高级别智能驾驶、视音频时钟同步、数据上传分析等场景中发挥着越来越重要的作用。目前以太网时钟同步协议中，使用最多的为精准时钟同步协议（Generalized Precision Time Protocol，gPTP），遵循IEEE 802.1AS标准。在AUTOSAR中也有对应的模块eth_stync实现该协议。

1.需求分析

gPTP分为Grand Master和slave，顾名思义，前者为系统中提供授时的节点，后者将自己的本地时间同步到Grand Master的时钟进行同步。gPTP网络拓扑示意图入图2.3所示：

▲图2.3 gPTP 网络拓扑示意图

2.验证方法

gPTP测试的验证与被测件的角色相关，有针对Endpoint的测试以及Bridge的测试，测试环境如图2.4和2.5所示：

▲图2.4 gPTP Endpoint测试环境

▲图2.5 gPTP Bridge测试环境示意图

电源：可模拟不同供电电压。

转换板：100/1000base-T1转换为100base-Tx/1000base-T。

流量仪：包含多个车载以太网接口的流量发生设备。

电脑：安装了测试软件的测试电脑。

3. 验证范围

时间同步测试主要包含gPTP协议一致性测试和gPTP配置测试，如表2.6为网络诊断基础验证的部分用例，详细测试用例中的每条用例应包含有唯一的编号、需明确需求点、测试目的、测试环境、测试步骤、评价标准等内容。时钟同步测试验证部分用例如表2.6所示：

▲表2.6 时钟同步测试验证部分用例

2.2 嵌入式系统时间特性分析

近年来，随着汽车功能的不断完善和多样化，车载电子系统日益复杂。从控制器层面看，集成度越来越高，CPU负载不断增加。如何确保软件集成安全、优化设计、提高资源利用率、降低成本成为相关设计人员亟待解决的问题；另一方面，ISO26262及ASPICE等相关标准中分别在软件架构、单元和集成阶段对性能分析提出了明确的需求。如何验证满足实时系统的时间性能需求，构建符合ISO26262和ASPICE标准的产品也越来越引起相关人员的重视。

针对上述问题，AUTOSAR标准在4.0版本以后即对嵌入式系统性能分析提出了相关方法论指导。其中，《AUTOSAR Specification of Timing Extensions》主要定义了不同级别的时间行为需求/规范标准，《Recommended Methods and Practices for Timing Analysis and Design within the AUTOSAR Development Process》（以下简称Timing Analysis）主要提供了性能问题方法论指导。如图2.6所示：

▲图2.6 时间特性分析层级概览（截图自AUTOSAR标准）

就分析内容而言，根据相关标准的定义，嵌入式系统的性能问题主要分为控制器级、网络级和功能级（端到端）三个维度。本文主要关注控制器级别的相关性能问题。结合欧洲相关标准的定义，控制器级别的性能分析问题又可以进一步分为代码级分析和调度级分析。其中，代码级分析的对象为单个的任务（Task）/中断（Interrupt），不考虑任务/中断/进程间的抢占情况。而调度级分析则主要考虑多任务/中断间相互抢占的情况下，各任务/中断的响应时间的结果（包括本身的代码执行时间和被抢占的时间）。

如图2.7所示：

▲图2.7 不同时间特性分析方法的相互关系（来源：AUTOSA标准）

就分析方法而言，可以分为理论分析、仿真和追踪三种，或者基于模型和基于追踪两种。后者与时间特性流程/研发流程更相契合。在本文中，我们采取后一种分类方法进行相关介绍。

2.2.1 基于模型的分析

基于模型的分析按照分析内容，又分为代码级分析和调度级分析。

根据ISO26262及ASPICE标准，代码级的相关指标主要包括最差情况代码执行时间（WCET，WorstCase Execution Time）和最差情况堆栈用量分析。调度级分析要求指标主要包括CPU负载、Task\Interrupt\Event Chain最差情况响应时间（WCRT，WorstCase Reaction Time）等。

1. 代码级基于模型的分析方案

代码级基于模型的分析方法是指不需要在实际的目标硬件环境中运行，而是通过直接从程序结构中计算出代码最差情况执行时间，或者在目标环境仿真器中仿真而得出代码执行时间分布范围的方法。

为了满足功能安全和ASPICE中对性能问题最差情况的分析要求，一般推荐使用基于模型的分析方案。常见的分析方案如图2.8所示：

▲图2.8 代码级基于模型的性能分析方案

常见的代码级基于模型的性能分析工具有aiT、TimingProfiler、StackAnalyer等。

2. 调度级基于模型的分析方案

调度级基于模型的分析方法是指不需要在实际的目标硬件环境中运行，而是基于目标操作系统、代码执行时间范围和调度配置进行静态数值分析而计算出最差情况任务/中断响应时间，或者在调度仿真器中仿真而得出任务/中断响应时间分部范围的方法。

为了满足功能安全和ASPICE中对性能问题最差情况的分析要求，一般推荐使用基于模型的分析方案。常见的分析方案如图2.9所示：

▲图2.9 调度级基于模型的性能分析方案

常见的调度级基于模型的性能分析工具有Symtavision、Inchron、Timing-Architects等。

嵌入式实时系统必须保证每一个操作系统的任务均在规定的时间内作正确的响应，如果由于某个任务执行时间过长或者调度设计不合理而影响其他的任务的正常执行，进而超出任务规定响应时间的情况，会对系统的正常运作造成很大的影响。根据软件的严重度等级，这些潜在安全隐患的排除需要通过形式化的验证方法或者具有充分的测试覆盖度的测试方法进行证明。针对性能问题，在适航标准DO178B的第六章中明确指出“Testing，in general，cannot show the absence of errors”，也就是说，测试一般不能用来证明某些性能问题的清除，比如代码执行时间、堆栈用量、代码运行时错误等，一般通过测试来证明是不足够的，因为没有一种测试的手段可以对性能问题达到100%的覆盖度，即无法找出WorstCase的工况。因而，标准中提出某些性能错误的排除可以通过形式化的方法（Formal methods）进行证明，而形式化方法即为一种基于模型的分析方法。此外，由于基于模型的分析方法不需要硬件环境，使得在设计阶段即对性能问题进行分析成为可能，从而尽早地发现和排除相关问题，避免在集成阶段再发现问题而导致时间和成本的浪费。

2.2.2 基于追踪的分析

基于追踪的分析按照分析内容，又分为代码级追踪和调度级追踪。追踪的对象是实际目标系统，一般通过代码插桩等手段，持续地进行事件（events）及对应时间戳（time stamp）的采集和记录，这些记录的数据可以存放在目标硬件的内存或者通过相关接口实时导出。这些事件的选择可以是代码块级别、函数级别或任务/中断级别等，也可以细化到机器指令级别。根据不同的事件级别可以基于追踪文件分别重建代码块、函数、任务/中断、甚至是每个机器指令的实际执行时序情况。相应的，对机器指令、代码块、函数等基于追踪文件的时序重建，可以分析得到代码执行时间最小值、最大值、平均值等数据，即为代码级追踪分析的内容。而对任务/中断基于追踪文件的时序重建，可以分析得到任务/中断延时和CPU实时负载的最小值、最大值、平均值等数据，即为调度级追踪分析的内容。

常见的追踪分析方案如图2.10所示：

▲图2.10 基于追踪的性能分析方案

常见的基于追踪的代码级性能分析工具有TimeWeaver+Lauterbach、Gliwa、RapiTime等；常见的基于追踪的调度级性能分析工具有TraceAnalyzer、Lauterbach、iSystem、Greenhill、RapiTask、Gliwa等。

文章来源：

AUTOSEMO《中国汽车基础软件发展白皮书 3.0》