|
|
|
|
移动端

挨踢部落故事汇(40)汽车通信诊断开发-带领程序员走向现实世界

一段漂浮在内存中的灵魂,通过VCI(Vehicle Communication Interface)序列化为一股带有动力、智慧、扭矩、稳定算法、启动涡轮增压的报文,连接在崭新的、预备妥当的汽车上——像打扮漂亮的新娘;强大的灵魂注入沉重的汽车,她就闪烁着眸子、心潮澎湃,焕发生机。金属,在程序员的再创造进程中,能反映出造物主的无上荣光。

作者:51CTO开发者交流群来源:51CTO|2018-07-17 14:52

技术沙龙 | 邀您于8月25日与国美/AWS/转转三位专家共同探讨小程序电商实战

【51CTO.com原创稿件】一段漂浮在内存中的灵魂,通过VCI(Vehicle Communication Interface)序列化为一股带有动力、智慧、扭矩、稳定算法、启动涡轮增压的报文,连接在崭新的、预备妥当的汽车上——像打扮漂亮的新娘;强大的灵魂注入沉重的汽车,她就闪烁着眸子、心潮澎湃,焕发生机。金属,在程序员的再创造进程中,能反映出造物主的无上荣光。

Ivan·项目管理

Ivan·项目管理

本期主人公Ivan,从事汽车通信诊断开发。2009年开始步入社会,是一名很低调的程序员,这么多年总结一下,莫不如尚未下线而强行上道的汽车——缺的模块太多,一边加油,一边缝缝补补。每天敲代码、听歌、写文档、收邮件,加班。直到有一天,他终于厌倦了异乡孤独的街灯,收拾了行囊,回到家乡。2013年底,他加入D有限公司,见到了一直认为缥缈的软件作用于一台汽车后产生的神奇变化——在此之前,他从不认为计算机程序和现实可见的事物有什么直接关联。然而在这里,当Ivan看到一批批汽车自动配置完成,在公路上自由奔驰,真正的服务于人,工业,让他遥望见自己的初心。

到今天为止,Ivan已经从事近5年的EOL开发工作,汽车在这里下线,带着轻微的汽油味离开工厂,被物流车发往世界各地。他喜欢轻微的汽油味,喜欢新车干干净净的颜色,也喜欢听尾气冲击歧管的清脆声,当然他最喜欢的,是汽车跟随指令产生的一系列变化。

汽车通信诊断开发现场试炼考验

先来了解一些汽车通信开发定义:

·         EOL,End Of Line,一般指汽车下线(即将离开生产线)诊断系统

·         ECU,Electronic Control Unit,电子控制单元,车载电脑等。

·         ABS,Antilock Breaking System,防抱死装置(一种ECU)

·         ESC,Electronic Stability Controller,车身稳定控制装置(一种ECU)

·         EMS,Engine Management System,发动机管理系统(一种ECU)

·         CAN,Control Area Network,ISO 11898控制器局域网

·         UDS,Unified Diagnostic Services,统一诊断服务(与CAN的关系可以类比为HTTP与TCP/IP的关系,CAN相当于TCP/IP,UDS相当于HTTP)

真正广阔的天地,是在生产现场遇到的各种试炼。Ivan记得曾参与某省汽车厂新车项目,当所有设备入厂调试完成,根据各零部件供应商提供的诊断规范(简称Spec)要求开发了第一版程序,第一批测试车辆按计划下线,当诊断仪通过OBD-II接口接入车辆总线,屏幕密密麻麻的红色错误项告诉他,在当前状态,系统要改的路尚远。那是Ivan第一个项目,他跟着单位老大哥学习,完全遵照Spec,任何责任都能够定位(得益于产品质量过硬,Ivan从不怀疑他们的产品、设备存在任何问题)。后来也确实按他所说,所有的问题一经确认,相关责任方就会调集人马入厂解决,最终的结果不是更换软硬件就是升级Spec。

EOL开发使Ivan在虚拟的计算机中看到现实汽车驰骋在道路上,内心充满了成就感。有一段时间,进行ESC(车身稳定系统)、DVT(动态车辆测试)等,需要在DURR转毂间进行,转毂间是车间的一个独立测试工位,一般常见的转毂间都是DURR生产和提供支持的,车辆在转毂间里可以在平面上模拟爬坡、颠簸、刹车、加速等等许多复杂力学测试,当时要计算车辆的车重、轴重等等,Ivan的同事龙哥直接用Java计算重力公式G=mg、杠杆原理等生成协议参数,另一边与DURR工程师拟定通信协议,实现车辆在转毂间,由诊断仪同时控制车辆和转毂间协调二者执行测试,当那阶段完成时,Ivan看着诊断仪屏幕上车辆运行曲线直逼150Km/h,真心钦佩他龙哥的专业态度,试问高中毕业后,谁还记得重力公式!在这里他也意识到对安全的重视,为防止诊断仪在转毂外控制转毂,设备上预置了红外线接口,通过与另一种设备进行红外通信、定位,最大限度保障在转毂间工作的工人人身安全(150km/h的速度,哪怕飞出一个螺丝钉也会伤到人)。

当然Ivan也见过追求规范、标准和干净的实例。在北方某一线城市,Ivan参与其越野车诊断开发工作。呈于领导的故障,有时会得到领导亲自下车间跟踪排查,少了任务的层层委派、信息的层层传递,执行效率提高很多。当然,如果他遇到协调多个部门解决问题时,也会遇到互相推脱,有些说不清的责任划分。记得当时针对某新车型开发检测系统,当系统接入车辆总线时,他发现DTC(故障码)完全无法识别,经过核对Spec,定位原因在于该车型安装的某国产ECU并不完全遵照UDS协议,而是自行设计了一套与任何标准都不兼容的故障码体系,没办法的情况下,Ivan只能针对他们的协议,重新编写协议实现。

诊断开发注意事项

Ivan在这里经历很多酸甜苦辣,见过太多倾轧、指责,欣慰的是体验到工业扩展了技术的实现范畴。那几年他在北方几大城市飞来飞去,现场的诊断开发让他学会了很多:

1.不要过早、过乐观的估测总线上的情况,你永远猜不到什么东西挂在了总线上。

2.遵照Spec开发,就算Spec再怎么啰嗦,遵命是最好的选择。

3.掌握英语,是良好理解Spec的基础。

4.一个问题,哪怕再小,都要及时、清晰的反馈,因为不知道小冰山下面是多大的体量。

5.底层知识,就算很少用到,也应尽量掌握,因为不知道什么奇葩需求,会要改你的底层。

6.对领域的认识(或重定义)是指导开发的目标和方向。

7.解决人的问题比解决技术的问题更急迫,也更具决定性。

许多年过去了,Ivan已经很少做现场的开发,而更多的转做服务架构、协议实现等。他曾经在某电影中看到自己参与开发检测系统的汽车,飘扬着旗帜驰骋在非洲荒原,忽然觉得好眼熟,感觉心头暖暖的,那是青春的一点痕迹吧。

在程序员的再创造进程中,汽车通信诊断开发——带领程序员走向了现实世界。

如果你也愿意分享你的故事,请联系小助手(小助手微信号:CTO51shequn)投稿,期待你精彩的故事!

活动进行时>>

【51CTO原创稿件,合作站点转载请注明原文作者和出处为51CTO.com】

【责任编辑:何星 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢
24H热文
一周话题
本月最赞

读 书 +更多

网络工程师必读——网络工程基础

本书是一本知识全面、系统、专业的网络工程基础知识必备图书。全书条理清晰、逻辑性强,遵循从全局到细节,从底层基础到高层应用的顺序全面...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊