大数据时代的当下，作为车载行业的设备终端，基本要与数据挂钩，不仅要连接OBD或者CANBUS，还要求有大量的数据交互，在ADAS、DMS、车辆动态监控、发动机性能检测、公车及出租车的车队管理，还是矿卡工作时长监控等方面，应用都非常广泛。

那么，我们需要解决几个问题：

一、车载设备要的数据从哪里来？

基于车辆本身的数据，在行业这边的应用，主要有2端，A、OBD接口。绝大部分车型都标配了OBD接口，不管是汽油车、柴油车、还是新能源及商用车等智能汽车，就连叉车，新款的也是带有OBD自动诊断系统接口的；B、CAN总线网络。据统计，国内的汽车在2013年后就标配了OBD2标准，当时的年代里，有85%以上用的是CAN2.0的数据接口网络，我们在2016年做4S集团试乘试驾管理系统中，实际测试满足CAN网络标准的车型就达到了96.5%，可见，当下的情况，几乎99%用的是CAN网络了。

那么，通过OBD接口来采集数据，无疑是最简单的方式。OBD在整车网络上，本身就是一个重要的节点，但是真的把这一块做好，做深是有难点的。之前的文章中也有提到过一些特殊情况，比如造成汽车不休眠、发动机起停技术的误判、干扰ECU、CAN网络通信故障、速率控制不对，请求指令错误、锁车报警等等一系列的问题，这里不再赘述。

二、OBD采集数据的频率

我们的方法是默认采用240ms对ECU请求，这个速率下，98%以上的车型都不会造成干扰，因为速率足够慢，如果ECU不返回的数据，我们就跳过，显示为空白。那么在下一包数据过来的时候，基本会有，大家可能认为，哎呀，数据这么慢，我怎么处理我们的上位机系统呢，这就要根据数据的多少，紧急性来区别。部分数据本身在整车上就传输得比较快，这种数据，反馈自然也就快，有的数据传输得慢，请求快了会造成网络堵塞，还没有数据返回。行业里，大多的通病就是“越快越好”，其实这里边的“节奏”就体现了对车的理解，存在的高低之分，所以也决定了企业的生死。

这是个哲学问题，所有快的东西，绝大部分都不是好的，花开需要时节，稻穗成熟需要时间，孩子长大需要经历，太早凋谢，催熟都是手段，而不是目的。比如我们要把一个芯片测试好，我们就需要大量的样本，没有大量的样本，我就不能说我的“好”，测试样本需要时间、需要周期、需要不同的环境，经过大量测试的样本，那就是好的定义。

三、通过OBD接口采集车身私有协议下的控制系统数据，可能会存在的问题：

1、网关数据隔离，车载网关直接把数据隔离起来，不对OBD接口输出数据，所有OBD请求的数据过来，网关这边都要做识别，包括指令、速率、反馈。

2、指令不对。涉及的车型越多，指令越复杂，很多车都没有指令可供请求，那么我们就需要破解诊断仪的“动作测试”中的请求与反馈，那么我们采用中断式诊断请求，进入诊断仪请求模式。诊断请求数据是再比如停车、修理、维护的条件下，车是不运动的情况，请求一个的CAN ID 获得 ECU反馈。以喇叭鸣笛信号举例，我们需要连接通用诊断仪X431，然后通过X431发送鸣笛信号，界面上是“动作测试”。这个情况，在停车情况下，修车情况下可以用，因为接入了X431，并获得X431授权，ECU处于诊断模式，通过CAN监听工具，抓取X431发送请求的指令（车厂授权诊断仪厂家的），然后，X431给出反馈，请求后会有对应回复一包数据，通过这个方法，获得喇叭信号。

3、对ECU造成干扰。我们还以喇叭信号举例的话，你要请求多快？项目就只用这么一个信号吗？这就造成了单一信号，或者不是多个信号请求频率的问题，可能X431也没办法请求获得这个指令，比如涉及汽车安全的“一票否决”的控车指令及其他涉及行车安全的指令，或者X431也没有这么快的反馈，又回到第二大点的问题，造成各种困扰，这些困扰，其实都是请求数据过程中对ECU造成的干扰，为什么有的OBD就是活不了，为什么有的就越做越好，值得思考。

四、速锐得结合OBD特性给了新方法

首先是数据部分，OBD部分根据上述的经验和磨合，这一块，不要客户自己去开发。因为开发OBD这个领域是跟车型、年份、总线、车载通信网络、速率、零部件等相关的，有的高精度的传感器数据每秒是300万的单个数据量，这个一般企业没涉及过的根本处理不过来。思拓的办法是把OBD集成到一个小组件里，直接通过串口，比如TTL、RS232、RS485对外输出数据，这个形态可能有多种，包括对接车载上位机的接口也存在多种多样，但是至少有一点，OBD的核心部件是不用太担心的。

其次是供电部分，OBD能有效地对上位机提供供电功能，在OBD接口的16脚就是一个常电，不管是停车熄火还是启动汽车状态，都具备供电的特性。看上去这里只是需要连接一条线，但会引申出一个问题，车载设备，比如ADAS、DMS、驾校学时机、4G网关或者别的，如何来保证功耗。汽车的电瓶是有容量的，有容量那么在停车熄火的时候就会有功耗。那么就要结合OBD的数据来做判定了，判定的条件还不止于一种。

其中的逻辑包括：

1、电压：基本的逻辑为汽车熄火状态一般为12V，最低点火电压10.8V，汽车点火后一般在13.5V，最高达到14.8V，大型硬派越野车电压可以达到15V；

2、转速：常规熄火转速为0，点火后的转速最低位大概在550转，部分冷车点火转速达到2200转，只要设置400转速的阈值，另外补充熄火后部分车型固定转速不变的情况做排除；

3、水温：汽车点火后的水温一般都不会为0或者为空，熄火后的水温有华氏度和摄氏度两个类别；

4、发动机运行时长，汽车点火工作后，发动机开始运行，ECU控制单元会记录发动机运行时长，就像飞机一共多少飞行时间的结果一样，这个数据有点火到熄火的值，也有累计值，但是累计值，我们一般不做参考，其他汽车市场应用也极少，我们只作为判断逻辑之一。在发动机自动启停下，转速为0，水温不为0，电压变低，但有发动机运行时长。

五、结语

以上，当数据和供电结合到一起，再结合最后客户端上位机的应用，基本上都能解决大部分项目中的问题，这也是速锐得新型智能车载CANBUS数据采集OBD接口传输及取电安装应用方式核心所在。

应用举例：商用车里面还有个典型的应用，就是通过CAN数据获取左右转向信号，基于这个信息来处理ADAS车道偏离报警，比如核心要解决误判报警的问题。如果ADAS摄像头识别到车辆跨越车道线，且有转向信号，AI算法就判断为正常变道。如果没有转向信号，ADAS主机即刻发出车道偏离预警信息，在本地提醒司机做出纠正，同时上报平台主动安全报警事件。现在很多都是通过IO信号线，接车辆左右转向灯的信号来获取，前装车厂的ADAS是通过CAN来获取转向信号，这也是为什么以色列我们搞后装的接触不到这块，那么对这个数据的要求，可能实时性可能就没那么快

我们采集的数据，都是工具，完成匹配好项目所需，才是目的。很多项目中，客户不懂汽车、电子、总线、逻辑，一再强调功能、功能、功能，就会陷入“功能误区”，功能越多，系统越复杂，涉及面就越是广泛，另外还有车型、品牌、年份、总线通信逻辑等多种的不同。测试的范围越广、车型越多，暴露出来的问题也就越多。像第一章节中所说的问题，很多就是致命的，这些问题处理不到，就会导致一个项目挂上东南枝，或者让一个数据开发企业走向无尽深渊。

并不是不知者无畏，而是成本太高。

附上PPT首页，请各位需要的朋友联系，获取完整28页应用介绍。

*博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。