新闻  |   论坛  |   博客  |   在线研讨会
速锐得新型智能车载CANBUS数据采集OBD接口传输及取电安装应用方式
suruide | 2024-03-27 16:31:06    阅读:44   发布文章

OBD串口图1.jpg

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

OBD串口图2.jpg

那么,我们需要解决几个问题:

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

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

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

OBD串口图3.jpg

二、OBD采集数据的频率

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

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

OBD串口图4.png

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

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

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

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

OBD串口图5.jpg

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

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

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

OBD串口图6.png

其中的逻辑包括:

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

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

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

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

OBD串口图7.jpg

五、结语

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

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

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

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

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

OBD串口图8.png


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

参与讨论
登录后参与讨论
推荐文章
最近访客