智能网联服务器在汽车远程控制的探索 4（整车通讯协议）

上一篇文章中，我们已经详细的接受了Canbus总线的数据流定义和解析，解析后的数据还需要和汽车各个设备一一应起。

比如汽车的舒适总线中有车门状态、灯光状态、后视镜状态等，当对应的数据存在(为1)时说明设备在响应变化。汽车这些设备状态的默认数据一直为0，当数据变为1时说明设备进行了某种操作，我们把这类数据叫做开关变量。

类似的，在汽车动力总线中会有车辆的速度、转速、功率等信息，这些数据往往是比较大的数值，例如发动机转速为x2000r/min，因为一个字符的最大值为255（十六进制FF），此时我们解析协议时就需要知道对应的解析几个数值根据高低位计算，数据一般可以分为十六位或二十四位。下一篇文章具体介绍这两种数值转换，这里不再展开。

言归正传说一下汽车各个设备和数据的对应关系。也就是汽车各个设备说明书。这可能是我遇到最大的坑。举例：下图是一个DSP的开发板，如果硬件经验的开发者，应该很容易理解，对硬件设备的读取和操作，无论是简单的控制开关还是模拟量数字量控制，都必须找到设备的开发说明书找到各个线的对应关系，也就是说设备必须是开源的。于是当我翻阅汽车车辆信息时，我发现我自己进入了死胡同，汽车的车辆信息不可能开源的。这和当初预想的工业控制设备联网开发差别很大。

（汽车的开源程度和DSP完全不是一个量级）

车辆因为稳定性、安全性等方面的考虑，对控制单元(ECU)的通信协议都是保密的，甚至有些中国自主品牌在车辆设计前专门去欧洲找团队设计一整套通讯协议。感觉凉凉咯。。。。。。

可车到山前必有路，上周汽车工程的同事告诉我，还有一个办法就是服务器收到数据之后，自己一个汽车部件一个汽车部件测试，一个汽车设备被开启或关闭时，找到与之同步变化的那一组，然后再找下一个。

这是我找的洗涤器、转向灯、雨刮器的部分信息截图，虽然很麻烦但是比较靠谱，我向汽车工程部借来故障分析仪、CAN协议分析仪、解码器等工具来提升效率，接来下两天就开始整理汽车通讯协议。。。。。