杨 健
(上汽大众汽车有限公司, 上海 201805)
在现代汽车电子的应用实践中,用户需求增长以及技术快速迭代导致整车电气功能的不断升级,电气平台与电气网络构架的复杂程度越来越高,实现电气功能的控制单元ECU(Electronics Control Unit)的软件算法、数据处理量以及ECU之间的信息交互、系统接口也是成倍的增长。为了保证整车功能的实现以及批量生产后可靠的产品质量,必须有一套严格的开发、测试、生产验证流程。
目前主流的整车电气系统软硬件开发测试验证采用的是ISO26262所定义的V模型开发流程。该流程基于模型化设计(Model-Based Design, MDB)的方法,具备完整的设计规划、系统安全分析以及开发过程中不断进行验证和排错,是目前最高效、最可靠的开发流程模型。
ISO-26262(Road Vehicles-Functional Safety)规范是以IEC61508标准为基础发展建立而来,从图1所示的架构中可以清楚的了解到不管是系统级别的功能开发,还是零件级别的硬、软件开发,都可采用V模型来实现。
图1 ISO 26262 架构
V模型作为一种高效的开发模型,其目的是实现RAD(Rapid Application Development快速应用开发),是为了改善早期在整车系统功能开发和软件开发所使用的瀑布模型中,错误直到开发后期的测试阶段才能发现的弊端,V模型将产品生命周期中的每一个开发活动,都对应一个测试活动,并且两者可以快速反馈和迭代优化,其核心就是一个并行的概念。
如图2所示,表示整车电气系统功能开发测试的V模型,左侧代表的是开发活动(各层级的功能需求定义和系统设计),右侧代表的是测试活动(对应各层级的功能测试以验证是否满足或符合左侧所定义的功能需求),每一个开发层级都有一个测试层级与之相对应。虚线上方属于系统整合级别的工作,一般由主机厂负责;虚线下方控制器零件级别的工作一般委托供应商实施。根据实车开发过程对每个栏目进行简单描述和说明。
图2 整车电气系统开发测试V模型
该模块的主要工作是结合客户需求和产品定位,将要实现的整车功能,具体用清单的方式进行表述。一般需要形成整车装备清单和整车功能定义以及针对每一项装备或功能的具体性的描述。
该模块的主要工作是结合整车功能定义以及当前技术手段从单个ECU选型到ECU之间信息交互的网络架构定义和硬件的实现路径。一般需要形成整车网络架构图,包括总线分类(CAN、LIN、FlexRay、MOST、Ethernet等)、数据传输波特率定义、通讯协议定义、主从ECU控制定义,带有数据传输接口的核心传感器等等。除此之外还会形成ECU整车、线束、接地点布置等核心文件。
该模块的主要工作是结合已经形成的整车功能定义和整车网络架构来合理分解形成各个子系统的功能定义。一般每个子系统都需要由多个ECU通过信息交互和数据处理配合完成。比如整车防盗系统、电源管理系统、灯光控制系统、自动泊车辅助系统等。
该模块的主要工作一般是由主机厂提供设计任务书(包含功能定义、输入输出定义、投产计划、尺寸和布置、机械条码和电子条码要求、法律法规要求、回收利用率要求、试验要求、测试要求、材料工艺要求、送样认可进度等等),交由供应商进行ECU的软硬件开发和具体实现。
该模块的主要工作也是在供应商端完成的,主机厂会参与评估或做一部分测试。一般需要根据设计任务书完成以下几项基础测试:
1) 零部件功能测试(单个ECU在虚拟环境中的功能测试);
2) 控制器通讯接口测试(物理层、数据链路层、网络管理、网络通讯诊断等等);
3) TP传输协议测试(通道建立、诊断连接、数据报文、中断管理等等);
4) UDS诊断协议测试(诊断模式切换、故障代码读取、数据块读写、编码参数读写等等)。
该模块的主要工作是验证分系统功能实现评估,测试的重点是物理层和数据链路层。主要实现手段一般是搭建面包板台架或者是硬件在环仿真(Hardware in Loop,HIL)。硬件在环是将一个或多个ECU连接到虚拟环境中,以数据接口、信号交互来进行协同工作的闭环测试系统,虚拟环境由上位机实现,并能模拟必要的传感器、执行器和CAN线上的相关信号。其最大的优点是可以模拟极端情况和错误状态下的控制器响应和反馈。
该模块的主要工作是在实车软硬件环境下模拟驾驶环境来测试所有系统定义的整车功能。测试的重点是应用层。实现手段是静态的实车环境加上模拟器产生的发动机控制器、变速箱控制器、ESP控制器等需要的各类传感器和外围信号,来模拟发动机和变速箱正常工作,形成虚拟的驾驶环境。主要的工作是按照测试手册(TestCase)逐项进行功能验证,除常规项目外,还会做一些自由测试,Miss-Use测试等等。
该模块的主要工作是在可驾驶的完整实车环境下做整车性能测试和模拟用户使用习惯下的功能测试。除了在高速环道以及城市工况道路的跑车动态试验以外,还会进行一些如EMC电磁兼容试验(Eletro Magnetic Compatibility)、整车静态电流测试、ADAS(Advanced Driver Assistance System,驾驶辅助系统)功能测试等等。
虽然整车开发V模型很好的指导了产品充分的开发测试并让整车能完整的实现项目所定义的功能。但这仅仅是基于样车或者少量成品车在软件和参数特殊调教情况下的结果,除此之外,整车开发成熟度以及产品质量最终还取决于批量生产条件下的整车功能是否能稳定和可靠的符合客户要求。批量生产过程中,车辆上所有零部件装配完毕后,大部分ECU控制器单元需要进行初始化操作,就像完成了一台PC机裸机的硬件装配后,在使用前必须进行一些软件的安装和配置一样。在这个过程中,产线需要使用专用的检测设备根据用户订单所定义的装备配置刷入相应的软件数据、编码、参数以及标定等一系列工作,以满足车型配置的多样化和精益生产的要求。另外在车辆流水线的最后工序还需要进行整车下线检测(EOL,End-of-Line Test ),专门针对整车进行故障诊断、功能验证等测试。
在实际整车项目实践过程中,由于生产环节的工艺、设备、流程的复杂性,以及大批量生产后发现的偶发性问题,会导致项目生产导入阶段,在生产验证环节反馈大量的问题并需要从开发端进行调整和优化来解决。为保证项目质量以及问题的快速响应,可针对整车开发V模型进行了拓展,增加了基于整车生产环节的电子电器功能验证的分级模型,并对应原开发V模型中的各个对应模块。
如图3所示,整车电气系统开发测试生产验证的VU模型,并对生产验证相关模块进行展开描述和说明。
图3 整车电气系统开发测试生产验证VU模型
该模块的主要工作是开发用于生产的通用检测系统环境下的单个ECU的初始化程序,又称为ECU Single Test。在最左侧的开发活动中,很重要的一个输出文档是关于单个ECU控制器的检测规范,其中详细定义了无论是在线还是离线情况下让ECU具备功能所需要进行的检测步骤。在本模块中,将按照开发所定义的检测规范和步骤通过开发对应用于产线的专用程序来验证产线测试设备和单个ECU之间的通讯、诊断模式切换、编码和参数写入、读取故障码等等工作,同时完成生产测试设备的输入输出等人机界面的程序以及ODX诊断数据文件(Open Diagnostic data eXchange)的验证。
该模块的主要工作是通过搭建相应的台架将实物线束、ECU控制器、部分传感器和执行器进行物理连接,可以结合2.1已经完成的单个ECU初始化后,对于电气功能进行检查和故障排查。
根据项目变更范围,可以选择使用如图4的简易电气台架,或者如图5的相对更完整的E-simulator台架,其区别在于E-simulator台架安装了更多的传感器和执行器等电器零件,可以进行更多的功能测试。一般在这个模块中将完成线束导通性测试、控制器零件号和软硬件版本比对、ECU软件编码和参数写入验证、部分电器功能逻辑验证等等。
图4 简易电气台架
图5 E-Simulator台架
本阶段还将完成一项很重要的测试工作,即整车防盗匹配的生产流程离线验证。在开发提供的电气网络构架中会定义哪些ECU属于防盗组件,而针对这些防盗组件需要有一个特殊的注册控制管理流程,在整车生产环节中一旦生成整车识别号VIN码(Vehicle Identification Number)后将通过生产检测系统在线实时申请与此车唯一对应的防盗秘钥并写入相关防盗组件控制器以完成相应的在线防盗匹配工作。由于防盗匹配失败将直接导致车辆无法发动,影响巨大,因此本阶段的离线防盗匹配验证工作尤其重要。
2.1和2.2这二个模块一般需要在新车型项目产线预批量试装前完成。
该阶段的主要工作是基于产线完整装配的整车条件下离线对车辆完成所有的软件刷写、编码和参数写入、EOL下线检测等等一系列验证工作。在这个阶段需要一份详细到具体工位工作步骤和内容的生产检测规范,它是结合开发版本的检测规范和该车型项目的生产设备选型和工艺布局综合考虑而形成的。
EOL下线检测是个很重要的环节,包含ECU自检、DTC(Diagnose Trouble Code)故障码检测、电器功能检查、普通标定(方向盘转角标定、四门玻璃自学习、后盖自学习、天窗自学习、空调自学习等)、ADAS标定(自适应巡航、变道辅助、后视成像、多功能摄像头、全景成像、抬头显示等等)、灯光和前束调校、转毂测试、排放测试、电子条码和机械条码上传等等一系列模块。
这个阶段需要完成所有和产线工艺相匹配的相关检测程序模块,并验证每个模块能顺利运行。所有选装和车型配置的控制器和整车功能都需要被检测和验证。一般需要在新车型项目产线预批量的前期和中期完成。
该阶段的主要特点是所有产线检测程序能在流水线各检测点自动运行,符合规划前提所定义的节拍要求,优化检测程序符合批量生产各种工况并建立防错机制,准确的实现用户订单中所包含的零件信息和数据信息在生产线系统中正确调用、匹配和写入。
除了2.3中完成的模块均能在线自动运行以外,还需要对于检测程序无法覆盖的功能检测项目定义人工检查清单,保证产品功能有效性和全覆盖。比如未加入诊断CAN的行李箱灯和四门氛围灯就需要安排相关的工艺进行人工检查。另外关于整车动态功能检查也需要安排生产环节路试100%全检,以及质检人员的抽检和全功能测试来验证。
该阶段一般在新车型项目产线预批量后期直至批量。
论文提出的基于汽车电气系统开发测试和生产验证的VU模型,很好的弥补了原开发测试V模型中未涵盖生产环节的不足,全面的描述和构建了全新整车项目电气功能从开发到产品测试再到生产验证的全流程框架。在实践中该模型很好的应用在新车型项目生产导入过程中,由单元到分系统再到整车集成分阶段同步进行开发、验证和生产测试,可以有效的提升开发成熟度、问题解决效率和最终产品质量。