汽车ECU通信相关验证项有哪些？

已剪辑自: https://mp.weixin.qq.com/s/-fIAXkS37r6jvnuA7yIQDA

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

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

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

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

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

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

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

那对于车载ECU通信而言，有哪些验证项呢？

网络通信测试验证

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

1.需求分析

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

2.验证方法

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

3.验证范围

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

网络管理测试验证

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

1.需求分析

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

2.验证方法

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

• 总线分析仪：用来模拟除控制器外的其他节点发送和接收报文；记录监测总线报文；对控制器进行 ACK 应答。
• 电源：通过 PC 可控模拟不同供电电压。
• R1：120Ω；R2:120Ω。

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

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

3.验证范围

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

诊断服务测试验证

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

1.需求分析

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

2.验证方法

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

• 总线分析仪：用来模拟除控制器外其他节点发送和接收报文；记录监测总线报文；对控制器进行ACK 应答。
• 电源：可模拟不同供电电压。
• R1\R2：选配型终端电阻 120 Ω。对于终端型控制器，需选配 R1 或 R2；对于非终端型控制器，需同时配置 R1 与 R2。

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

3.验证范围

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

时间同步测试验证

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

1.需求分析

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

2.验证方法

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

• 电源：可模拟不同供电电压。
• 转换板：100/1000base-T1 转换为 100base-Tx/1000base-T。
• 流量仪：包含多个车载以太网接口的流量发生设备。
• 电脑：安装了测试软件的测试电脑。

3.验证范围

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