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 为网络诊断基础验证的部分用例，详细测试用例中的每条用例应包含有唯一的编号、需明确需求点、测试目的、测试环境、测试步骤、评价标准等内容。时钟同步测试验证部分用例如下表所示：
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
了解详情》docs.qq.com/doc/DSlVlZExWQ0FRSE9H
