一种车辆数据处理方法和装置
技术领域
本发明涉及汽车电子技术领域,特别是涉及一种车辆数据处理方法和装置。
背景技术
车联网系统,是指是利用先进传感技术、网络技术、计算技术、控制技术、智能技术,对道路和交通进行全面感知,实现多个系统间大范围、大容量数据的交互,对每一辆汽车进行交通全程控制,对每一条道路进行交通全时空控制,以提供交通效率和交通安全为主的网络与应用。
而车联网系统中,OBD(On-Board Diagnostics,车载自动诊断系统)是该系统中非常重要的一部分。OBD获取车辆数据,并将获取到的车辆数据上报至车联网系统中的服务器,服务器通过OBD上报的车辆数据对车辆运行状况、以及车辆健康状况进行实时监控。
目前,OBD在向服务器上报车辆数据时,通过车载诊断系统中的自带的3G模块上报车辆数据,这样的传输方式,一方面,仅能保证车辆数据成功传出OBD,而不能保证车辆数据能够成功上报至服务器,例如:网络发生异常则上报的数据将会丢失。另一方面,服务器端口仅能同时处理一定数量的OBD上报的车辆数据,而一旦处理数量达到了服务器端口的处理上限,则无法再接收其他OBD上报的车辆数据,可见,现有的车辆数据处理方案中OBD的并发量受服务器处理能力的限制。
发明内容
鉴于上述问题,提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的车辆数据处理方法和装置。
为了解决上述问题,本发明公开了一种车辆数据处理方法,包括:接收车载自动诊断系统上报车辆数据的请求,其中,所述请求中携带有待上报的车辆数据、服务器IP地址以及服务器端口;将所述待上报的车辆数据存储于消息队列中;通过所述请求中携带的服务器IP地址以及服务器端口,将存储于消息队列中的待上报的车辆数据上报至服务器。
优选地,在所述接收车载自动诊断系统上报车辆数据的请求步骤之前,所述方法还包括:接收所述车载自动诊断系统的访问请求;响应所述请求,为所述车载自动诊断系统分配服务器IP地址以及服务器端口,将分配的所述服务器IP地址以及服务器端口反馈至所述车载自动诊断系统。
优选地,所述请求中还携带有上报频率,所述将存储于消息队列中的待上报的车辆数据上报至服务器的步骤包括:依据所述请求中携带的上报频率,将存储于消息队列中的待上报的车辆数据上报至所述服务器。
优选地,所述将所述待上报的车辆数据存储于消息队列中的步骤包括:按照接收到的请求的数量设置消息队列的数量;为每个请求分配一个消息队列,将请求携带的待上报的车辆数据存储于请求对应的消息队列中。
优选地,所述将存储于消息队列中的待上报的车辆数据上报至所述服务器的步骤包括:将存储于多个消息队列中的待上报的车辆数据上报至所述服务器对应的入库服务进程,通过所述服务进程采用多线程方式将接收到的所述多个消息队列中的数据上报至所述服务器。
为了解决上述问题,本发明还公开了一种车辆数据处理装置,包括:接收模块,用于接收车载自动诊断系统上报车辆数据的请求,其中,所述请求中携带有待上报的车辆数据、服务器IP地址以及服务器端口;存储模块,用于将所述待上报的车辆数据存储于消息队列中;上报模块,用于通过所述请求中携带的服务器IP地址以及服务器端口,将存储于消息队列中的待上报的车辆数据上报至服务器。
优选地,所述车辆数据处理装置还包括:访问请求接收模块,用于在所述接收模块接收车载自动诊断系统上报车辆数据的请求之前,接收所述车载自动诊断系统的访问请求;分配模块,用于响应所述请求,为所述车载自动诊断系统分配服务器IP地址以及服务器端口,将分配的所述服务器IP地址以及服务器端口反馈至所述车载自动诊断系统。
优选地,所述请求中还携带有上报频率,所述存储模块将存储于消息队列中的待上报的车辆数据上报至服务器时:依据所述请求中携带的上报频率,将存储于消息队列中的待上报的车辆数据上报至所述服务器。
优选地,所述存储模块包括:消息队列设置模块,用于按照接收到的请求的数量设置消息队列的数量;消息队列分配模块,用于为每个请求分配一个消息队列,将请求携带的待上报的车辆数据存储于请求对应的消息队列中。
优选地,所述上报模块将存储于消息队列中的待上报的车辆数据上报至所述服务器时:将存储于多个消息队列中的待上报的车辆数据上报至所述服务器对应的入库服务进程,通过所述服务进程采用多线程方式将接收到的所述多个消息队列中的数据上报至所述服务器。
与现有技术相比,本发明具有以下优点:
本发明提供的车辆数据处理方案,将接收到的OBD数据存储于消息队列中,再通过消息队列将存储的车辆数据上报至服务器,一方面,由于消息队列在向服务器发送消息时仅在确保与服务器之间的连接正常的情况下,才会将存储的车辆数据上报至服务器,因此,能够确保车辆数据成功上报至服务器,从而有效避免现有的车辆数据上报方法中存在的上报的车辆数据丢失的问题。另一方面,本发明提供的车辆数据处理方案,将接收到的OBD数据缓存在消息队列中,即便是当前处理的OBD数量达到了服务器端口的处理上限,依然可以继续接收其他的OBD上报的车辆数据,而将接收到的车辆数据缓存在消息队列中,对于上传车辆数据的OBD端不会受到任何的影响,待当前处理的OBD对应的车辆数据上报完成后,继续上传缓存的车辆数据。相较于现有的仅能够同时处理服务器端口能够承受的上限数量的OBD数量,本发明提供的车辆数据处理方案,处理OBD的数量不受服务器处理能力的限制,能够提高OBD的并发量。
附图说明
图1是根据本发明实施例一的一种车辆数据处理方法的步骤流程图;
图2是根据本发明实施例二的一种车辆数据处理方法的步骤流程图;
图3是根据本发明实施例三的一种车联网系统的结构框图;
图4是根据本发明实施例四的一种车辆数据处理装置的结构框图。
具体实施方式
为使本发明的上述目的、特征和优点能够更加明显易懂,下面结合附图和具体实施方式对本发明作进一步详细的说明。
实施例一
参照图1,示出了本发明实施例一的一种车辆数据处理方法的步骤流程图。
本实施例的车辆数据处理方法包括以下步骤:
步骤S102:接收OBD上报车辆数据的请求。
其中,请求中携带有待上报的车辆数据、服务器IP地址以及服务器端口。本实施例中的车辆数据处理方法可以同时对多个OBD上报的数据进行处理。
OBD安装在车辆上,每个车辆对应一个OBD。OBD从车辆的发动机的运行状况能够获得车辆的相关数据,如:车速、车辆的瞬时油耗、发动机冷却液温度、以及发动机进气温度等,服务器通过这些数据可以对车辆的累计里程、平均油耗、车主驾驶行为(急加速、急减速行为)、车辆健康状态等进行分析。
OBD向网关发送上报车辆数据的请求时,在请求中携带服务器IP地址以及服务器端口,网关则可通过请求中携带服务器IP地址确定接收车辆数据的服务器,通过服务器端口确定将车辆数据通过哪个具体端口发送至服务器。
步骤S104:将待上报的车辆数据存储于消息队列中。
网关在接收到OBD上报的车辆数据后,将OBD上报的车辆数据存储于消息队列中。
消息队列的设置可以由网关依据OBD的访问量灵活进行设置,例如:可以为访问网关的各OBD各设置一个消息队列;再例如:为每两个网关设置一个消息队列。本申请对于消息队列的数量不作具体限制。
消息队列遵循数据先进先出的规则,因此OBD上传的车辆数据即时不能实时上报至服务器也可以由消息队列进行缓存,待先存储的车辆数据上报完毕后则可继续向服务器上报缓存的数据,OBD在上传数据时不会受到任何的影响,更不会收到上报数据被拒绝的消息。可见,同一个消息队列在处理某一个OBD上报的车辆数据时,还可以同时接收另一个OBD上报的车辆数据,将接收到另一个OBD上报的车辆数据缓存在该消息队列中,后上报数据的OBD不会受到任何影响。
步骤S106:通过请求中携带的服务器IP地址以及服务器端口,将存储于消息队列中的待上报的车辆数据上报至服务器。
现有的OBD向服务器上报车辆数据方法中,均采用背景技术部分所描述的通过OBD内设的3G模块直接将上报的数据通过网络上报至服务器,而并没有通过消息队列来上报数据的方法。现有的这种方法不仅会造成上报数据的丢失,并且处理OBD的数量还要受服务器处理能力的限制,即OBD并发量会受限。而通过本实施例提供的车辆数据处理方法,将接收到的OBD数据存储于消息队列中,再通过消息队列将存储的车辆数据上报至服务器,一方面,由于消息队列在向服务器发送消息时仅有确保与服务器之间的连接正常的情况下才会将存储的车辆数据上报至服务器,因此,能够确保车辆数据成功上报至服务器,能够有效避免现有的车辆数据上报方法中存在的上报的车辆数据丢失的问题。另一方面,将接收到的OBD数据缓存在消息队列中,即便是当前处理的OBD数量达到了服务器端口的处理上限,依然可以继续接收其他的OBD上报的车辆数据,而将接收到的车辆数据缓存在消息队列中,对于上传车辆数据的OBD端不会受到任何的影响,待当前处理的OBD对应的车辆数据上报完成后,继续上传缓存的车辆数据。相较于现有的仅能够同时处理服务器端口能够承受的上限数量的OBD数量,本实施例提供的车辆数据处理方法,处理OBD的数量不受服务器处理能力的限制,能够提高OBD的并发量。
实施例二
参照图2,示出了本发明实施例二的一种车辆数据处理方法的步骤流程图。
本实施例的车辆数据处理方法具体包括以下步骤:
步骤S202:网关接收OBD的访问请求。
本实施例中,网关分为两部分,一部分是网关域名系统另一部分则是OBD网关。网关域名系统负责为访问请求分配服务器IP、服务器端口和上报频率。OBD网关负责接收OBD上报的车辆数据,并将上报的车辆数据存储在消息队列中。
本实施例中的网关基于MINA架构开发,其中,MINA(MultipurposeInfrastructure for Network Applications)是Apache组织一个较新的项目,它为开发高性能和高可用性的网络应用程序提供了非常便利的框架。本实施例中网关支持集群部署,其主要负责与OBD通讯,处理OBD的访问请求以及OBD上报的车辆数据,将OBD上报的车辆数据存储于消息队列中发送至服务器。
每个OBD预上报车辆数据时均会向网关发送一个访问请求,该访问请求可以请求网关为预上报的数据分配服务器地址以及服务器端口。
步骤S204:网关响应该请求,为OBD分配服务器IP地址以及服务器端口,将分配的服务器IP地址以及服务器端口反馈至该OBD。
网关接收到OBD的访问请求后,可以依据各服务器、以及服务器各端口的负载情况灵活地为OBD分配服务器IP以及服务器端口,以保证服务器的负载均衡。
优选地,网关不仅可以为OBD访问请求分配服务器IP地址以及服务器端口,还可以对OBD上报数据的频率进行灵活控制,为OBD访问请求分配上报速率。
步骤S206:网关接收OBD上报车辆数据的请求。
其中,请求中携带有待上报的车辆数据、服务器IP地址、服务器端口以及上报频率。
网关依据各OBD上报车辆数据的请求中的携带的服务器IP地址、服务器端口来确定将车辆数据发送至哪个服务器,而通过请求中携带的上报频率来控制上报车辆数据的频率。
步骤S208:网关按照接收到的请求的数量设置消息队列的数量。
网关在接收到OBD上报的车辆数据后,根据接收到的请求的数量设置消息队列的数量。在设置消息队列时,可以为OBD分配一个消息队列,将一个消息队列分配给多个OBD,消息队列处理上报一个OBD请求上报的车辆数据时,将其他的OBD请求上报的车辆信息缓存在该消息队列中。
例如:同时有100个OBD请求上报车辆数据,网关可以设置100个消息队列,每个消息队列处理一个OBD上报的车辆数据;网关也可以设置50个消息队列,每个消息队列处理两个OBD上报的车辆数据,当然,可以是设置成20个消息队列,每个消息队列处理五个OBD上报的车辆数据。需要说明的是,消息队列可以设置在网关中,但不限于此,其他适当的消息队列的设置方式也同样适用,如设置在其他装置中供网关调用。
步骤S210:网关为每个请求分配一个消息队列,将请求携带的待上报的车辆数据存储于请求对应的消息队列中。
本实施例中,网关为每个请求即每个OBD分配一个消息队列,将请求中携带的车辆数据存储在消息队列中,通过消息队列将车辆数据上报至服务器。
本实施例中,通过采用消息队列将车辆数据进行存储,起到了数据入库缓存的作用,针对OBD侧可以接收大量的OBD上报的车辆数据,而对于服务器侧则可以根据服务器的接收能力上报车辆数据,对于来不及上报的数据则可缓存在消息队列中,既可以保证对OBD上报数据的接收,又可以解决大量OBD同时上报车辆数据时服务器接收数据压力过大的问题。
步骤S212:网关通过请求中携带的服务器IP地址以及服务器端口,将存储于消息队列中的待上报的车辆数据上报至服务器。
需要说明的是,本领域技术人员可以预先对网关上报车辆数据的频率进行设置,网关在处理所有的OBD上报的车辆数据时,均按照设定的上报频率向服务器上报数据。当然,网关可以根据每个OBD请求中携带的上报频率来上报请求中的车辆数据。优选地,网关依据OBD上报数据的请求中携带的上报频率,将存储于消息队列中的待上报的车辆数据上报至服务器。
一种优选的将存储于消息队列中的待上报的车辆数据上报至服务器的方式为:将存储于多个消息队列中的待上报的车辆数据上报至服务器对应的入库服务进程,通过服务进程采用多线程方式将接收到的多个消息队列中的数据上报至服务器。
入库服务进程可以根据上报车辆数据的消息队列的数量灵活调整线程数量,采用合理数量的线程来向服务器上报车辆数据,既能保证车辆数据及时上报至服务器,又不会因过多的分配线程造成线程资源浪费。优选地,入库服务进程为每个消息队列分配一个线程向服务器上报车辆数据。
通过本实施例提供的车辆数据处理方法,将接收到的OBD数据存储于消息队列中,再通过消息队列将存储的车辆数据上报至服务器,一方面,由于消息队列在向服务器发送消息时仅有确保与服务器之间的连接正常的情况下才会将存储的车辆数据上报至服务器,因此,能够确保车辆数据成功上报至服务器,能够有效避免现有的车辆数据上报方法中存在的上报的车辆数据丢失的问题。另一方面,将接收到的OBD数据缓存在消息队列中,即便是当前处理的OBD数量达到了服务器端口的处理上限,依然可以继续接收其他的OBD上报的车辆数据,而将接收到的车辆数据缓存在消息队列中,对于上传车辆数据的OBD端不会受到任何的影响,待当前处理的OBD对应的车辆数据上报完成后,继续上传缓存的车辆数据。相较于现有的仅能够同时处理服务器端口能够承受的上限数量的OBD数量,本实施例提供的车辆数据处理方法,处理OBD的数量不受服务器处理能力的限制,能够提高OBD的并发量。
实施例三
参照图3,示出了本发明实施例三的一种车联网系统的结构框图。
如图3所示,车联网系统包括:OBD、网关、由网关控制的消息队列、入库服务进程、数据中心即服务器、数据分析服务器、静态化缓存、Tomcat服务器、Memcache即高性能缓存、双机集群系统(HA系统)、手机以及WEB(网站)。下面以一个OBD向数据中心上报车辆数据,车联网系统对上报的车辆数据进行处理为例,对本实施例中的车联网系统的各个部分进行说明。
OBD按照设定的时间间隔通过车辆的发送机获取相关的车辆数据,例如:车速、车辆的瞬时油耗、发动机冷却液温度、以及发动机进气温度等。在获取到车辆数据后,向网关中的网关DNS(Domain Name System,域名系统)发送访问请求,其中,网关包括:网关DNS以及OBD网关。网关DNS在收到OBD发送的访问请求后,根据服务器各端口的负载情况为OBD分配服务器IP地址和服务器端口,以及车辆数据的上报频率。OBD接收网关DNS为其访问请求分配的服务器IP地址、服务器端口和上报频率后,将这些信息与待上报的车辆数据携带在向OBD网关上报的请求中发送至OBD网关。
OBD网关接收到OBD上报的请求后,为该OBD分配消息队列,将请求中携带的车辆数据存储至消息队列中。按照请求中携带的配服务器IP地址和服务器端口确定接收车辆数据的服务器端口,并按照请求中携带的上报频率上报车辆数据。
本实施例中使用的是RabbitMQ,RabbitMQ是流行的开源消息队列系统,用Erlang语言开发的。本实施例中采用消息队列存储车辆数据,起到了车辆数据入库缓冲的作用。需要说明的是,本实施例中是以接收一个OBD上报的车辆数据为例进行的说明,在具体实现过程中可能同时有多个OBD向OBD网关发送上报车辆数据的请求,OBD则可根据请求的数量即访问量灵活设置消息队列的数量,具体数量的设置本实施例中对此不作具体限制。
服务器对应的入库服务进程接收OBD网关通过消息队列上报的车辆数据,获取消息队列中的车辆数据。入库服务进程灵活设置线程将获取到的车辆数据上报至服务器。
在服务器中设置有两个数据库分别为:Mysql和MongoDB,其中,Mysql是一个小型关系型数据库管理系统,在本实施例中用于存储时效性较强的数据,例如:车辆位置信息,而MongoDB是一种分布式文档存储数据库,其具有很强的大数据量读写性能。鉴于MongoDB具有强的大数据量读写系统,本实施例中入库服务进程将获取到车辆数据保存在MongoDB中,并且MongoDB设置有多个存储集合,将接收到的各OBD上报的车辆数据均匀存储至各存储集合中,这样,不仅可以降低单个存储集合记录的数据量,由于数据分析服务器需要从MongoDB中提取车辆数据,将各OBD上报的车辆数据存储至多个存储集合中,数据分析服务器便可以同时从多个存储集合中提取车辆数据,相较于从一个存储集合中提取车辆数据,能够提高数据分析服务器并发处理数据的能力。优选地,在保存车辆数据时,由于每个OBD对应有一个TUID即车载终端机器码,在将各OBD上报的车辆数据均匀存储至各存储集合中时,可以通过分配TUID来实现。
数据服分析服务器从MongoDB中提取车辆数据,在提取数据时可以采用线程模式进行车辆数据的提取。在提取到车辆数据后,数据服分析服务器采用多进程处理模式对获取到的车辆数据进行分析,对于进程数量的设置可以根据上报车辆数据的OBD的数量来决定,对于每个进程还可以采用所线程并发的处理模式,以保证能够及时的对各OBD上报的车辆数据进行分析。这些进程都程序脚本进行守护,程序脚本定时检查各进程状态,确保各进程的正常运行。数据分析服务器将分析后的数据分别存储至服务器中的Mysql和MongoDB。其中,Mysql中仍然存储的是一些对时效性要求较高的数据,例如:车辆的累积里程、瞬时车速等数据,而在MongoDB中则存储一些时效性较低的数据,例如:车辆健康状态数据。
存储至服务器Mysql和MongoDB中的分析后的数据按照设定的规则传送至Tomcat。静态化缓存则从Tomcat服务器中获取Mysql传送的时效性较强的数据,在Memcache中则对Tomcat服务器中存储的分析数据进行备份。
当用户通过手机、或WEB向HA发送访问某OBD对应的车辆的信息的请求时,例如:请求查询车辆的累计里程,HA接收到该请求后访问静态化缓存,从静态化缓存中获取该车辆对应的累计里程信息,将获取到的该车辆对应的累计里程信息发送至手机。由于静态化缓存相较于Tomcat服务器访问更便捷,而各用户对于时效性较强的这些数据的访问还非常频繁,如果用户从Tomcat服务器中读取这些数据,必定会为Tomcat服务器带来繁重的数据读取负担,因此,本实施例中将各车辆时效性较强的数据存储于静态化缓存中,这样不仅便于数据的访问,同时,还可以避免Tomcat服务器频繁读取数据。
通过本实施例提供的车联网系统,网关将接收到的OBD数据存储于消息队列中,再通过消息队列将存储的车辆数据上报至服务器,一方面,由于消息队列在向服务器发送消息时仅有确保与服务器之间的连接正常的情况下才会将存储的车辆数据上报至服务器,因此,能够确保车辆数据成功上报至服务器,能够有效避免现有的车辆数据上报方法中存在的上报的车辆数据丢失的问题。另一方面,网关将接收到的OBD数据缓存在消息队列中,即便是当前处理的OBD数量达到了服务器端口的处理上限,依然可以继续接收其他的OBD上报的车辆数据,而将接收到的车辆数据缓存在消息队列中,对于上传车辆数据的OBD端不会受到任何的影响,待当前处理的OBD对应的车辆数据上报完成后,继续上传缓存的车辆数据。相较于现有的仅能够同时处理服务器端口能够承受的上限数量的OBD数量,本实施例提供的车联网系统,处理OBD的数量不受服务器处理能力的限制,能够提高OBD的并发量。
实施例四
参照图4,示出了本发明实施例四的一种车辆数据处理装置的结构框图。
本实施例的车辆数据处理装置包括:接收模块402,用于接收车载自动诊断系统上报车辆数据的请求,其中,请求中携带有待上报的车辆数据、服务器IP地址以及服务器端口;存储模块404,用于将待上报的车辆数据存储于消息队列中;上报模块406,用于通过请求中携带的服务器IP地址以及服务器端口,将存储于消息队列中的待上报的车辆数据上报至服务器。
优选地,本实施例的车辆数据处理装置还包括:访问请求接收模块408,用于在接收模块402接收车载自动诊断系统上报车辆数据的请求之前,接收车载自动诊断系统的访问请求;分配模块410,用于响应请求,为车载自动诊断系统分配服务器IP地址以及服务器端口,将分配的服务器IP地址以及服务器端口反馈至车载自动诊断系统。
优选地,请求中还携带有上报频率,存储模块将存储于消息队列中的待上报的车辆数据上报至服务器时:依据请求中携带的上报频率,将存储于消息队列中的待上报的车辆数据上报至服务器。
优选地,本实施例的存储模块404包括:消息队列设置模块4042,用于按照接收到的请求的数量设置消息队列的数量;消息队列分配模块4044,用于为每个请求分配一个消息队列,将请求携带的待上报的车辆数据存储于请求对应的消息队列中。
优选地,上报模块406将存储于消息队列中的待上报的车辆数据上报至服务器时:将存储于多个消息队列中的待上报的车辆数据上报至服务器对应的入库服务进程,通过服务进程采用多线程方式将接收到的多个消息队列中的数据上报至服务器。
本实施例的车辆数据处理装置用于实现前述方法实施例一、实施例二中相应的车辆数据处理方法,并且具有相应的方法实施的有益效果,在此不再赘述。
本说明书中的各个实施例均采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似的部分互相参见即可。对于系统实施例而言,由于其与方法实施例基本相似,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
以上对本发明所提供的一种车辆数据处理方法和装置进行了详细介绍,本文中应用了具体个例对本发明的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本发明的方法及其核心思想;同时,对于本领域的一般技术人员,依据本发明的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本发明的限制。