毕业论文

打赏
当前位置: 毕业论文 > 自动化 >

ECU汽车厂总装车间静态电气检测设计仿真(4)

时间:2017-06-13 21:39来源:毕业论文
{ errInfo ( OK, Starting write compare VIN CTS ); } 用于进行程序调试时可以通过人为的控制DEBUG这个常量的值,然后从日志文件里查看程序进行情况。 程序的逻辑为


{ errInfo ( OK, ">>>> Starting write compare VIN CTS" ); }
用于进行程序调试时可以通过人为的控制DEBUG这个常量的值,然后从日志文件里查看程序进行情况。
    程序的逻辑为:开始必要的测试程序检测之前,首先读取该ECU的一些必要的信息,在这里的车身控制单元,我们选择读取ECU的车辆识别号,ECU的零件版本号,ECU的软件版本号以及ECU的硬件版本号。这些信息是最为普遍以及基本的信息,基本每个ECU都有。对于读取哪些信息进行比对由SPEC文件决定。
所有的模块都是ODX文件中所包含。ODX文件通过由标准的UDS协议制定。这边用到的ECU_Identification_Read_VIN(读取汽车识别码)为UDS协议中Service ID 0x22的命令 。ECU_Identification_Read_Hardware_ Version_Numbe(读取硬件版本号)ECU_Identification_Read_Software_Version_Number(读取软件版本号)以及ECU_Identification_Read_Manufacturer_ SparePart_Number(读取生产商零件版本号)都是UDS协议中Service ID 0x22的命令。那么如何区分读取的不同信息?这就要通过DateID来区别,一般Service ID之后还要跟4位Date ID来明确读取那一部分的信息。比如:最为标准的读取车辆识别号的Date ID是0xF1 0x90。
    当完成所有必要信息的输入与校对以后,我们将会进行下一步验证,对于ECU(电子控制单元)的故障代码进行清除(UDS协议中Service ID 0x14的命令)然后重启BCM(车身控制模块),等待五秒钟的重启时间后,再次对于ECU进行故障码读取(UDS协议中Service ID 0x19的命令)。包含着这段程序的是一个判断语句模块。给他设置了一个判断条件,由图可见判断语句为IF...OK则整段程序继续进行下一个操作电动防夹车窗的检测。
  (2) APWL(电动防夹车窗)测试
APWL,Anti-Pinch Window Lifter,电动防夹车窗概述
    这是一项国际最新的汽车安全技术。当乘客在电动车窗自动上升过程中,如果不小心把肢体伸出窗外,很可能被夹伤甚至有生命危险,尤其对那些自控能力稍弱的儿童、老人、宠物等造成不必要的伤害。即使是成年驾驶员,有可能在加头倒车时发生被夹伤事故。
    电动车窗防夹系统是未来轿车的必备功能之一,在车窗上升过程中,车窗机构可以检测到运动方向上的障碍物或夹紧力,一旦有异常现象,就会迅速停止电机或改变电机的运动方向。目前大部分车型已经具备这种安全特性。
    测试准备阶段,当现场的所有有关电动防夹车窗的设备仪器都准备就绪后,才开始电动防夹车窗的功能测试。
    现场通过人为控制车窗的升降过程触发防夹,停止电机,当检测到防夹时,车窗向下运行一定的时间(由厂家具体制定)。在整个车窗运动区域,只在特定的区域有防夹功能,并不是整个区域都防夹。电机速度可控制,在车窗的中间部位,电机全速运行;当车窗到达最顶端或最底端时,电机减速防止玻璃破碎和产生撞击声。
需要我们完成的是设计一个屏幕上面显示不同位置车窗的测试名称,在右下角提供通过与不通过两个选项。在工人完成人为检测后,人为的选择检测结果。所以整个程序的主逻辑非常简单,显示窗口最后输出结果如果是通过检测,那么程序继续进行,如果没有通过测试,程序也继续执行,进行下一个测试项目。因为在进行测试的过程中需要多次调用屏幕,如果分别做不同显示结果的屏幕,工作量巨大,并且会造成测试程序本身容量变大,在工厂环境中对不同车辆下载不同检测程序时,会影响程序下载到设备中的时间,从而影响生产节拍。
所以我选择设计一个公用的屏幕,在进行APWL(电动防夹车窗检测)的时候每次都调用同一个屏幕,然后在这个屏幕的外部给这个屏幕的不同区域进行赋值。这样实现功能,并且所需要附加的只是很少的几个字符串。大大缩减了程序的大小,并且简化了程序的结构。 ECU汽车厂总装车间静态电气检测设计仿真(4):http://www.youerw.com/zidonghua/lunwen_9170.html
------分隔线----------------------------
推荐内容