10月21日,365体育官方唯一入口通信工程学院教授韩庆文在人民邮电报社主办的“2015中国车联网大会”专题研讨会上,发表了《车联网中的智能行车安全系统》的主题演讲。
以下是演讲实录:
非常高兴,我也非常荣幸有这样一个机会,也非常感谢车联网联盟和人民邮电报社能够给我们365体育官方唯一入口一个展示的机会,我们365体育官方唯一入口成立了汽车的协同创新中心,并加入了国家“2011计划”,希望通过这种模式,整合车辆、汽车电子、通信、自动控制、计算机的老师,组成一个团队,我所在的团队现在主要关注汽车的智能安全系统的研究。
目前我们最关注的是标准问题,整个学术界也特别地关注标准问题,标准将决定未来研究的走向,另一个问题是车联网的框架,这是我们2011年提出来的一个基本框架,这个框架概括了从车间的信息交互,到云端的信息交互的问题。我们的研究即是基于这个框架展开的,我想介绍的是我们在研究过程当中遭遇的一些问题。
车辆安全性能评价
这是我们给出来的三个比较关注的问题,第一个是车辆本身的安全性能评价,第二个是安全信息的交互,最后是一个云端数据处理及反馈,这些问题都是车联网的基本问题,但是研究者和制造商们的观点并不一致,从而导致车联网概念的模糊,我觉得研究车联网的第一步是应该确定车联网到底是要做什么?它的目的是什么?当你把这个目的确定了以后,我们自然也就知道车联网到底应该往哪里走了。
从我个人的观点来说,我觉得安全行驶是最重要的一点,也就是说如何避免道路车祸,所以我们做的第一个项目就是这个车辆健康度评价。对车辆进行健康度评价是基于我们的一个想法,就像刚才那位先生说的一样,道路上的车辆到底需要传一些什么样信息,我是做通信的,从做通信的角度上来看,车间通信信道拥挤非常明显,也不可避免的。如果车联网在一个局部区域内一下出现两百辆车,大家都有信息等待发送的话,信道时延肯定非常大。
我们做过一个实测,在一个区域内设置了20辆车,全部用通播方式(broadcast),信息的传输成功率大概只有30%到40%,这是非常低的,所以必须控制车辆待发送的信息量,我们的想法是,进行信息交互的这些车辆之间应该是有需求关系的,也就是说需要传信息的时候,才能传信息。那么到底什么样的信息需要传,这就需要根据健康度评价来确定了,有些车天然对行车有威胁,比如载重货车,泥头车,在道路上诱发危险的可能性非常大;导致车辆不健康的另一个因素是由于驾驶问题导致的一些瞬时的危险状态;因此,应该根据车辆的健康状态确定安全信息传输的优先级,所以我们做第一个事情是车内的健康评价,健康评价包括车况的评价和驾驶行为的评价。
在这个问题上我们现在遇到最关键的问题就是数据问题,就像刚才那位先生说了CAN总线和现在的这个OBD,我记得昨天方竹秘书长说,OBD本来是用于检测维修的,用来做信息收集并不那么给力,就好像一个跑短跑的人你老是问他有没有吃饭,有没有睡觉似的,我个人认为,觉得车辆制造业界应该做的一件事情就是产生一个规范,定义一个独立于传统CAN总线和OBD的,用于车辆安全信息数据生成的一个接口。这个接口的输入端涉及到的数据并不多,只需安全数据,我们可以把它理清一下,一个是制动,一个是发动机的各种参数,这个接口的输出端则只需要给出健康评价结果及影响范围,即可确定信息的传输优先级和传输方向,通信信道拥挤问题可以大大改善。
驾驶行为评价
第二个问题非常麻烦,昨天也有这个同仁提到定位问题, GPS定位精度不够,大约10米以内,因此常有一些研究致力于去提高GPS的定位精度。那么反过来我想问一句,你们认为GPS的这种定位精度,对于道路的紧急避险到底有多少作用,它做出来是否得不偿失?
车上现在雷达非常多,有前雷达、侧雷达、后雷达,雷达能获得车间距离数据,并可确定车间相对关系,一旦获得这种相对关系,车和车之间的位置关系就确定了,根据车间位置关系去进行信息交互,我觉得从某种意义上来说对于实现道路车辆紧急避险更加有效。但问题在于现在所有的雷达数据全部都没有进入OBD,或者是进入CAN总线。我前一段时间跟德国宝马做了核实,他们所有的雷达数据都没有进入CAN总线。我的想法是应该把这些数据加上去,和汽车本身的数据合成一个标准的接口,我觉得这是车辆的制造商最应该关注的内容,如果把这一点解决了,车辆安全信息的产生就很容易了,当然我们之前研究了一些关联的模型,比如驾驶行为和行车舒适度及油耗关联模型,研究这些模型的目的很简单,就是为了去产生这样一个安全信息,这是我们做第一个原型系统。并且发明了《基于关键区域的良好驾驶技术参数获取方法》,以及《车辆驾驶教学智能辅助指导方法及系统》两个专利。
车间安全信息交互
我们关注的第二个内容是车间的信息交互,也就是V2V的问题。V2V涉及到另外一个标准问题,就是刚才沈博士说的这个标准问题,802.11P是我们一直关注的标准,现在有一个比较困惑的问题,即它的频点问题。我们知道,这个802.11P它提供的信道数量非常有限,一个控制用的CCH信道,四个服务信道SCH,加上两个长距离传输信道,最多6个信道,但是那个长距离信道现在一般来说是不用它的。可用的一共就是4个SCH信道。
这四个SCH信道是否传安全信息,标准中没有明确说明,如果用来传安全信息,即可在小范围内做信道复用。我们国家做D2D标准,是否能够考虑多个信道的复用?其实安全信息的数据量并不大,需要的带宽也不大,如果多几个信道做复用,在一个比较小的区域内,车间信息交互能获得的资源就比较多,如果频点资源不够还可以用时分,做了时分传输的时延肯定会比较大。这也是我们比较关注的一个问题。
另外一个问题时V2V究竟应该如何建立,还做通播吗,通播在CCH做也就可以了,我们的想法是,如果能推进多频点复用机制,可以考虑在一个局部区域内,形成一个车辆簇,一个车辆簇内车辆之间的相互影响比较大,在这个簇内做频点分配,或者是做一个时隙的分配。信息交互效率会大大提高,但是这个肯定需要标准方面做一些对应的支持,我觉得这应该是通信制造商最为关心的问题。
云端数据处理及反馈
第三个是云端的问题,云端处理目前受关注最多,我们也很关注,但随着研究的深入,却感觉很纠结,第一个纠结是交通历史数据的问题,国内的交通历史数据非常有限的,而且这些历史数据真实性也需要打一个问号。我在这上面做了很多的工作,却难以获得可信度较高的数据,如果要做交通数据挖掘,这个横在面前的障碍难以逾越。交通历史数据挖掘对车联网,对于车辆行驶驾驶指导,以至于自动驾驶,都是非常重要的,所以我觉得如果真要在车联网上做数据挖掘,并以之为依据进行交通引导或堵点预测,那么首先得保证历史数据库得完善与真实,否则挖掘出来的信息可能就是错的,比如说一个车本身就已经发生车祸了,然后被什么人为因素它处理掉了,最后我们从交通统计来说,那块有一个堵点,堵点生成原因不知道,分析到最后可能这个堵点生成原因完全就是错的,所以说要做车联网的安全预测首先需要解决数据库的问题。
另外一个问题就是信息的回馈;我们前期做了一个智能驾驶的预测模型,这是一种综合预测模型,通过分析驾驶员驾驶特征,以及周边的影响环境的特征,做综合评价;评价的反馈依旧是困扰我们的问题,就是说你这个信息究竟是应该从什么方向去做反馈,这依旧是一个标准问题。
我们做了一个eMote的测试平台,我们的V2V实验基本都在这个平台上做,另外还拓展做一些应用的一些实测,我们跟中汽院有一些合作,旨在做路测。
几个有待探讨的问题
下面我谈一下目前几个有待谈讨的问题:
第一个问题手机和这个接口的问题。这个接口我们也一直在考虑,到底是用蓝牙,还是做WIFI?当然了,如果说是能够产生一个新的接口标准,这个问题就比较好解决了。
第二个问题,车载系统的车间通信模式的问题,是V2V标准还是LTE?LTE的D2D到底做到一个什么样的程度,运营商和V2V之间的关系,其实就我个人来说,我觉得V2V本身就是一个模块,这个模块只需要做车间的交互,然后上云部分可以通过这个运营商来做,运营商上云不见得一定要通过车上云,通过手机上云也是一样的,只要车与手机的接口友好就可以实现,这是我个人的一种想法。
第三个问题,反馈途径问题,你到底是用车系统来做反馈,还是用手机来反馈?
第四个,反馈信息的控制度问题,你到底要反馈一些什么样的信息,比如说是很多人不愿意反馈GPS信息,那么这个GPS信息你到底要拿来做什么。假如说是你仅仅是做堵点分析的话,我觉得其实很简单,它只需要做车辆密度的收集,而根本不需要车辆本身的数据。
最后一个问题就是我刚才说的车辆本身的问题,需要关注车载设备的测试方法,比如雷达行车环境的处理,处理以后最终产生的是一种什么样的信息,这个信息怎么样去生成安全信息,以此来做车间的信息交互?好,谢谢大家,我大致就讲这些,谢谢。