车载基础软件——基础软件验证平台（网络管理和诊断）

我是穿拖鞋的汉子，魔都中坚持长期主义的工程师。

老规矩，分享一段喜欢的文字，避免自己成为高知识低文化的工程师：

我们并不必要为了和谐，而时刻保持通情达理；我们需要具备的是，偶尔有肚量欣然承认在某些方面我们可能会有些不可理喻。该有主见的时候能掷地有声地镇得住场，该沉默的时候也能专心安理得地躲起来不吭声，会关心和牵挂他人但绝不黏人，能为在乎的人放下身段,但除他们之外可以自由到不看任何人脸色行事。

本文主要介绍车载基础软件——基础软件验证平台关于网络管理和诊断测试相关内容。

文章主要有如下几个内容：

-> 1、网络管理测试验证

-> 2、诊断服务测试验证

-> 3、BSW层里的操作系统OS

一、网络管理测试验证

网络管理主要负责对汽车上控制器进行配置管理和协调工作的，无论是传统的汽油车，还是新兴的电动车，其控制器的供电均是通过蓄电池来提供的。网络管理可以通过车载网络，设计一套规则，来实现各控制器的睡眠和唤醒，以此来减少蓄电池的耗电。例如：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）的状态跳转是否受到影响。如下网络管理测试验证部分用例，详细测试用例中的每条用例应包含的内容与网络通信要求一致：

（1）、网络管理报文数据格式测试

-> 源地址测试CBV

-> CBV 未使用位测试

-> Userdata 未使用字节测试

-> 网络管理地址范围测试

(2)、网络管理状态转换策略测试

-> BSM状态测试

-> BSM-RMS转换测试

-> BSM-RMS-NOS转换测试

-> BSM-RMS-RSS转换测

-> BSM-RMS-NOS-RMS转换测试

（3）、特殊网络管理策略测试

-> 节点掉线错误测试

-> 高负载下的NM状态转换测试

搁笔分享完毕！

愿你我相信时间的力量

做一个长期主义者

二、诊断服务测试验证

网络诊断应用于车辆的初始目的是确定汽车工作状态，排查汽车故障。随着诊断协议的不断完善，其应用场景也不断在扩展，例如产品开发测试阶段的软件升级、生产阶段的下线配置、售后阶段的故障诊断、用户使用过程中的 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、验证范围

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

（1）、传输层测试（适用于CAN/CAN FD）

-> 停止发送后续连续帧

-> 不发送某连续帧

-> 延迟发送某连续帧

-> 确认控制器 N_Bs 满足规定

（2）、应用层自动测试

-> 无效子功能

-> 无效诊断服务

-> 无效 DID

-> 基本服务测试

（3）、应用层手动测试

-> 安全访问Service 27

-> 通信控制Service 28

-> 控制DTC设置Service 85

-> 软硬件版本号读取

-> 2E服务功能测试

通过如上测试内容，使软件基础平台网络管理和诊断功能更加完善。

搁笔分享完毕！

愿你我相信时间的力量

做一个长期主义者！