【车载开发系列】EOL整车下线流程

【车载开发系列】EOL整车下线流程

一. 什么是EOL

EOL是整车下线流程的意思，它的英文全称是End of Line。传统的下线流程主要涉及动力和车身两大部分内容，一般是车辆完成装配后，离开生产线以前进行的一系列准备工作，比如制动油液的加注、动力系统自检、门窗天窗的自学习等。近年来智能驾驶和网络安全相关功能在车内得以应用，与之相关的部分流程，例如雷达标定、安全信息写入/校验等也被加入了下线流程。得益于目前车内总线式的通信方式，目前大部分的下线流程，均可通过上位机下发诊断指令来完成，也即通过ISO-14229中定义的2F服务（输入输出控制）和31服务（例程控制）来控制对应控制器执行相关步骤。

二. EOL的作用

随着整车功能复杂程度的提升，整车下线流程除了传统的动力、车身部分的下线流程扩充外，更有智能驾驶，网络安全相关的新流程加入。而下线流程作为整车生产环节末端的一部分，一旦出现问题，则会对生产效率产生较大影响，甚至导致生产停滞。因此，在车型研发过程中，越来越需要在量产之前基于单部件和实车环境测试验证整车下线流程相关需求，确保产线装车过程中下线流程的功能稳定性。
具体来说，EOL可以验证产品的硬件版本、软件版本、诊断数据版本，用于对产品的变更跟踪及管理等，检测各种可能存在的问题，确保产品的质量。

三. 生产产线的检测流程

该检测逻辑基本通过UDS诊断协议实现，避免正常软件逻辑增加检测过程复杂度。

1. 版本号的验证基本通过数据读取服务(0x22)来实现；
2. 电路检查基本通过IO控制服务(0x2F)或者例程控制服务(0x31)实现；
3. 休眠唤醒主要检测休眠电流，而DTC故障码检测通过DTC读取服务(0x19)来实现。
4. 产线EOL过程建议与正常产品逻辑进行区分，通过定义一个EOL模式或者叫做工程模式(不必对OEM开发此类接口)，通过该方式来避免仅用于EOL过程的某些操作被OEM错误使用。

1）软件测试（下载测试）

(1)、更新控制器软件及标定参数，并且在此过程中对生产信息及特定信息进行改写。
(2)、基本下载流程由OEM决定或者供应商决定，包括flash driver下载、软件更新、标定参数改写、其他信息写入等
标定参数、生产或出厂日期及安全访问算法参数等参数一般放在flash中，而ECU一般不会把驱动放在软件中(避免非法改写flash内容)，只有当软件更新时才会将相应的flash driver下载在ram中，因此一些参数只会在软件更新时进行改写。

2）参数校准流程

(1)、针对某些功能，一些参数需要学习(与执行结构状态相关)，比如车窗的上升功能等，此过程会存在一些参数(如零点、最大行程等)
(2)、定义自动学习例程(0x31)，此过程中不断读取相应学习状态，当学习完成后返回例程学习结果

3）电路检测流程

(1)、电路检测一般通过定义自检例程(0x31)，在进行自检之前需要将对应车型的配置参数进行下载，确保与硬件对应
(2)、检测完成后需要检测故障码(0x19)，确认自建例程运行结果(总装完成后不会存在电路问题，保证产品质量)，当然在运行自建例程之前需要清除故障码(0x14)

四. 实现难点

下线流程相较于传统的诊断协议和诊断功能，更注重与控制器功能上的交互；而与功能测试相比，为了提升效率，部分流程可能会通过诊断仪或者产线设备来自动化执行。因此下线流程测试综合了传统诊断测试与功能测试，对测试上位机有更高的要求，我们总结了如下常见的实现难点，并针对这些难点开发了对应的解决方案。

①多控制器兼容性

由于下线流程往往涉及多个控制器，因此需下线设备可同时兼容对多个不同功能控制器的测试

②下线流程灵活调配

开发阶段的下线流程往往尚处于调试过程中，可能会随需求及实际项目进度发生改变，这就要求测试设备可以灵活的增减下线流程，便于开发阶段的调试

③多控制器并行诊断

随着目前车内网络带宽的提升，越来越多的网络架构支持并行诊断或控制器并行升级，下线流程也往往使用并行诊断的方式，这就要求下线流程测试设备也可以做到对诊断请求的并行诊断。