庞鑫,陈雪华
(广汽菲亚特克莱斯勒汽车有限公司产品工程技术中心,湖南 长沙 410100)
目前整车电子电器架构正在经历由分布式向集中式电子架构的过渡阶段,车辆部分功能仍受不同且单一的电子控制单元控制,随着车辆功能迭代,车载模块数量递增,车辆下线电气检测的复杂程度也在同步提升。
下线电气检测是车辆出厂前的关键环节,为确保产品车的出厂品质,在车辆装配完成后,需使用全自动电气检测设备对车辆进行配置文件写入、参数标定及功能检测。因新车型试生产前没有理想的整车环境,电气检测程序也未就绪,因一些电气检测程序纰漏而报出的问题不能被有效识别,导致一些不必要的车辆拆装,零部件级的排查耗费较多工时,影响到生产节拍和项目的时间节点。本文对投产前下线电气检测的方案进行研究和设计,并在实际项目中采用了该方案,达到了理想的效果。
车辆下线电气检测系统主要包括:工厂服务器、手持多功能检测设备、四轮定位检测站、转毂测试检测站以及打印机等附属设备。
工厂服务器通过以太网与各检测装置相连接,并在整车集成检测过程中进行中央控制管理、储存、分析、处理不同源之间传送的数据。
手持多功能检测器通过无线连接的方式与服务器交互,通过其附带线束上的连接器与被检测车辆OBD接口相连,使多功能测试器能与车辆各控制单元通信,并对其进行初始化写入配置文件及相关检测;各检测站均配置手持多功能检测器配合检测站的测试设备执行下线检测工作。
电气检测工位具备车辆配置信息写入、电子追溯信息校验、电子系统控制(如灯光、空调)等功能,并将数据实时上传给服务器。
四轮定位检测站具备车辆数据采集、四轮定位标定、灯光系统调节、驾驶辅助传感器标定等功能,并将数据实时上传给服务器。
转毂测试检测站具备车辆动态测试、胎压传感器激活、制动力测试、加速度传感器标定等功能,并将数据实时上传给服务器。
各检测工位均配置打印机,用于打印该检测工位检测结果报告单,报告单上的不合格项描述信息可以指导工程人员进行问题排查。
车辆白车身投入总装车间后,经过内饰装配线、底盘装配线、油液加注后进入终装线,完成所有零件的装配工序后到达检测工位。检测员通过手持检测设备扫描车身上条码,获取车辆派生信息,执行对应的检测程序,检测完成后,根据打印出来的检测结果报告单,判断车辆是否能够继续往下工序流动。检测流程如图1所示:电气检测→四轮定位→转毂检测。
图1 下线检测流程
车辆下线检测结果基于UDS(Unified Diagnostic Services,统一诊断服务)来判断,诊断协议是ISO 15765和ISO 14229定义的一种汽车通用诊断协议,位于OSI模型中的应用层,UDS本质上是一系列的服务,共包含6大类26种。每种服务都有自己独立的ID,即SID(Service ID)。
在UDS的26种服务中,有7种比较常用。它们分别是:$10 Diagnostic Session Control(诊 断 会 话),$2F Input Output Control By Identifier(通过标识符控制输入输出),$14 Clear Diagnostic Information(清 除 诊 断 信 息),$19 Read DTC Information(读取故障码信息),$22 Read Data By Identifier(通过ID读数据),$2E Write Data By Identifier(通过ID写数据),$31 routinecontrol(例程控制),表1对这7个服务的具体应用进行了简要说明。
表1 诊断服务及其应用
在某型号试生产车型的下线电气检测过程中,有多台车辆的A模块报出了不合格项,通过分析打印出来检测结果报告单,发现A模块对写入车辆配置信息的0x2E 2023指令做出了否定响应。
为查明不合格项原因,通过CANoe软件对电气检测的日志进行分析,发现在电气检测过程中,当手持设备对该模块写入车辆配置信息时,该模块在否定响应0x78(Request Correctly Received-Response Pending)两次后,再次发送否定响应0x10(General Reject),详见图2,服务器识别该信息后,判断该检测项目不合格,并打印检查结果报告单提醒检测人员。
图2 电气检测日志分析
继续对该问题展开调查,最终确认车辆配置信息写入指令的发送时序存在问题,导致A模块无法做出肯定响应,在对相关指令的发送时序进行合理调整后,该问题没有再重复出现。在试生产过程当中,还出现过其他类型的不合格项,比如:对I/O控制指令的否定响应,基于例程控制的功能标定失效等,在此不一一列举。
随着新车型的控制系统复杂性不断提高,整车多达几十个模块需要基于诊断服务完成配置参数写入和标定等流程,单个模块响应的诊断指令最多可达到100余条,为避免生产线下线电气检测过程中因检出不合格项导致生产节拍降低,需要开发一种基于CAN总线的自动化车辆下线模拟检测方案,参照下线检测方式进行提前检测,并及时解决检测出来的问题,避免带入到生产线上。
CAPL是CAN总线访问编程语言(CANAccess Programming Language)的简称,是一种类C语言,应用于Vector CAN工具的节点编程。本方案主要基于CANoe软件的开发环境,由CAPL模块、Panel模块等构成,其中CAPL模块为系统的控制核心,负责测试用例的编辑、测试过程调度及测试结果判定,Panel模块负责生成人机交互界面,通过可视化的界面呈现自动化检测的结果,同时为目视检测项目提供输入接口。
模拟检测系统的硬件系统由安装了CANalyzer/CANoe软件的计算机、Vector CAN通信盒VN1640及整车电子电器台架构成(图3)。
图3 下线模拟检测方案硬件系统(局部图)
整车电子电器台架plywoodbuck(后称PWB)是电子电器领域测试的基础环境,是项目开发阶段和试验车辆生产出来之前进行电子协调性的重要平台。PWB主要模拟整车所有的电子回路,构建各电控单元及开关、传感器、执行器工作的基础条件。PWB基于新车型的零件清单进行搭建,同时可接入发动机仿真系统,可支持进行与动力总成信号相关的各项通信测试。
Vector CAN通信盒VN1640具有4个高速CAN总线通道,配合CAN总线收发器(CAN piggy),能够满足与当前车辆通信的要求。VN1640也支持基于CAPL语言的编程操作。
CANoe是德国Vector公司开发的CAN总线应用系统分析/开发软件,可通过接口硬件实现虚拟线与真实物理总线的连接,是目前最为通用的CAN总线开发、仿真软件。其高性能的函数和自由的可编程能力能够满足所有CAN总线系统仿真和实现的需要,可仿真和总线相连的全部网络节点。
本方案将通过CANoe与整车电子电器台架搭建测试环境,基于通信数据库文件(DBC),以及各模块的诊断规范文件,编写对应的测试脚本,并使用VN1640连接到车辆OBD接口向各模块发送诊断报文,通过Trace窗口可直接监控各模块对诊断指令的反馈信息,通过Panel模块可显示需重点关注的信息以及测试结果,并可设置进行多次重复的测试过程,图4为该方案的工作流程图,具体流程如下。
图4 下线检测模拟系统工作流程图
1)搭建整车电子电器台架,并完成电器回路检查及基本的调试工作。
2)根据通信数据库文件以及各模块的诊断规范文件,梳理待测试的诊断指令以及目标反馈状态,结合对诊断指令时序的考虑,编写测试用例文件。
3)通过VN1640连接台架,并在CANoe软件中完成工程文件配置,基于测试用例文件,编写CAPL测试脚本,配置Panel图形化模块,并完成脚本的编译。
4)运行CANoe,系统会模拟下线诊断设备逐一对各模块发送诊断指令,通过监控系统运行的情况,判断脚本是否存在bug,需要修正。
5)正式执行测试,监控测试结果,如有问题及时记录并制定对策。
测试脚本的编写需满足Vector CAPL的基本语法,对系统变量进行申明后,可基于具体事件过程进行编程,图5为测试脚本部分截图,包含了对车辆雨刮、前照灯以及车门解锁等功能的激活和检测。
图5 测试脚本的编写
为了更直观地监控测试结果,可以使用CANoe软件集成的Panel Designer工具。通过该工具可以创建面板,对放置的控件关联上信号变量,同时可以呈现测试结果,监控关注的各类信号,图6为该Panel的部分截图。
图6 测试面板Panel的部分截图
在Panel面板配置完成后,进行CAPL的编译,结果OK后,连接到整车电器台架,运行测试系统,监控其运行状态是否符合测试用例的需求,如存在bug,及时更新脚本直至满足需求。
图7为车辆电气下线模拟检测系统的运行效果的部分截图,Execute及Reset button的设置可以满足在测试过程中任何时间点重新执行测试的需求,OK及NOK button用于在执行目视检查项目(如单侧前照灯开启)时对系统的输入,通过input/output控件可监控到各测试项的执行结果,也可配合trace窗口检查各模块对诊断指令的反馈值,Meter控件用于显示车辆系统电压、冷却水温、发动机转速、胎压以及变速器挡位等信息,在一个界面集中展示这些信息更有利于测试人员在测试过程中整体把握车辆状态。
为提高新车型投入总装后的电气检测合格率,设计了一种用于基于CAPL语言的车辆电气下线检测模拟系统。该系统以Vector VN1640和整车电子电器系统台架为硬件平台,以CANoe作为基础软件,使用CAPL语言编写测试程序,结合图形化面板Panel的配置,在新车型正式生产前2个月,就实现了对整车环境的下线模拟检测。测试过程暴露出来的问题,很多都能在车辆正式投产前顺利解决,为项目的开发赢得了宝贵的时间。
该系统操作简便,人机界面友好,测试内容覆盖面广,既缩短了开发周期,又降低了开发成本,自开发完成以来,已成功应用在多个项目的开发过程中。