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

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

活动进行时>>

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