CN111726256B - 车辆指令下发处理方法和系统及车辆数据处理方法和系统 - Google Patents

车辆指令下发处理方法和系统及车辆数据处理方法和系统 Download PDF

Info

Publication number
CN111726256B
CN111726256B CN202010604450.7A CN202010604450A CN111726256B CN 111726256 B CN111726256 B CN 111726256B CN 202010604450 A CN202010604450 A CN 202010604450A CN 111726256 B CN111726256 B CN 111726256B
Authority
CN
China
Prior art keywords
vehicle
instruction
data
target
service
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202010604450.7A
Other languages
English (en)
Other versions
CN111726256A (zh
Inventor
唐能
欧阳青
陈雪
瞿静
夏磊
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ecarx Hubei Tech Co Ltd
Original Assignee
Ecarx Hubei Tech Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ecarx Hubei Tech Co Ltd filed Critical Ecarx Hubei Tech Co Ltd
Priority to CN202010604450.7A priority Critical patent/CN111726256B/zh
Publication of CN111726256A publication Critical patent/CN111726256A/zh
Application granted granted Critical
Publication of CN111726256B publication Critical patent/CN111726256B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H04L67/025Protocols based on web technology, e.g. hypertext transfer protocol [HTTP] for remote control or remote monitoring of applications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/04Network management architectures or arrangements
    • H04L41/044Network management architectures or arrangements comprising hierarchical management structures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0803Configuration setting
    • H04L41/0823Configuration setting characterised by the purposes of a change of settings, e.g. optimising configuration for enhancing reliability
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • H04L67/146Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02PCLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
    • Y02P90/00Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
    • Y02P90/02Total factory control, e.g. smart factories, flexible manufacturing systems [FMS] or integrated manufacturing systems [IMS]

Abstract

本发明提供了一种车辆指令下发处理方法和系统,以及车辆数据处理方法和系统。该车辆指令下发处理方法应用于云端,云端包括多个业务处理单元以及多个虚拟车辆映射单元,每一业务处理单元用于执行不同的业务,该方法包括:接收下发的车辆指令,车辆指令携带车辆标识以及指令类型;将车辆指令发送至车辆标识对应的目标虚拟车辆映射单元;根据目标虚拟车辆映射单元中的映射状态数据,判断车辆指令是否可执行;若是,将车辆指令发送至指令类型对应的目标业务处理单元以对车辆指令进行处理;将处理后的车辆指令下发给车辆标识对应的目标车辆。本发明的方案实现了高并发、高容错、易扩展,减少指令下发延迟。

Description

车辆指令下发处理方法和系统及车辆数据处理方法和系统
技术领域
本发明涉及计算机网络通信技术领域,特别是一种车辆指令下发处理方法、车辆指令下发处理系统、车辆数据处理方法以及车辆数据处理系统。
背景技术
目前,车联网领域的研究和应用日益发展。车联网的概念是以行驶的车为数据主体,通过数据传输协议,实现车与云端的数据通讯及数据分析,从而为驾驶者提供安全、智能、舒适的驾驶感受。车联网产品还可以实现远程车辆控制、行车日志、车辆状态提醒等功能。然而,此类车联网云产品的设计普遍存在并发量高时命令下发设备的响应延迟问题。如此,在早晚高峰时期爆发大并发量的车辆连接服务器时,大量需要下发给车辆的命令会出现下发长时间延迟和无效的情况,极大地影响用户的使用体验。
现有技术中采用多线程、异步的处理方式来解决上述问题,但这种方式同样存在最大线程数限制的瓶颈。由于线程的最大数量为31842,当达到最大数量时,系统无法再增加线程,需要通过扩容或其他方式来增加线程,大大增加了系统的复杂度。并且,多线程也会因需使用线程锁而造成阻塞。
发明内容
鉴于上述问题,提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的车辆指令下发处理方法、车辆指令下发处理系统、车辆数据处理方法以及车辆数据处理系统。
本发明的一个目的是提供一种高并发、高容错、易扩展的车辆指令下发处理方法。
根据本发明实施例的一方面,提供了一种车辆指令下发处理方法,应用于云端,所述云端包括多个业务处理单元以及多个虚拟车辆映射单元,所述方法包括:
接收下发的车辆指令,所述车辆指令携带车辆标识以及指令类型;
将所述车辆指令发送至所述车辆标识对应的目标虚拟车辆映射单元;
根据所述目标虚拟车辆映射单元中的映射状态数据,判断所述车辆指令是否可执行;
若是,将所述车辆指令发送至所述指令类型对应的目标业务处理单元以对所述车辆指令进行处理;
将处理后的所述车辆指令下发给所述车辆标识对应的目标车辆。
可选地,所述业务处理单元包括多个指令处理单元,
所述将所述车辆指令发送至所述指令类型对应的目标业务处理单元以对所述车辆指令进行处理包括:
将所述车辆指令发送至所述指令类型对应的目标指令处理单元以将所述车辆指令转换为车辆标识对应的目标车辆可识别的执行指令,并将所述执行指令下发给车辆标识对应的目标车辆。
可选地,所述接收下发的车辆指令,包括:
通过调用的应用程序接口接收服务端下发的车辆指令。
可选地,将处理后的所述车辆指令下发给所述车辆标识对应的目标车辆包括:
通过Kafka生产者向所述目标车辆下发所述车辆指令。
可选地,所述业务处理单元以及所述虚拟车辆映射单元通过AKKA框架下的Actor机制实现。
根据本发明实施例的另一方面,还提供了一种车辆指令下发处理系统,包括:
数据处理模块,包括多个虚拟车辆映射单元;
业务处理模块,包括多个业务处理单元;以及
数据交互模块,与多个车辆设备通信;
其中,所述车辆指令携带车辆标识以及指令类型;
所述车辆标识对应的目标虚拟车辆映射单元接收下发的所述车辆指令,并根据自身的映射状态数据,判断所述车辆指令是否可执行,若是,则将所述车辆指令发送至所述指令类型对应的目标业务处理单元;
所述目标业务处理单元用于对所述车辆指令进行处理,并将处理后的所述车辆指令发送至所述数据交互模块;
所述数据交互模块用于将所述处理后的所述车辆指令下发给所述车辆标识对应的目标车辆。
可选地,车辆指令下发处理系统还包括接口调用模块,与下发车辆指令的服务端通信;
所述接口调用模块用于调用应用程序接口以接收所述服务端下发的车辆指令,并将所述车辆指令发送给所述车辆标识对应的目标虚拟车辆映射单元。
根据本发明实施例的再一方面,还提供了一种车辆数据处理方法,应用于云端,所述云端包括多个业务处理单元以及多个虚拟车辆映射单元,所述方法包括:
根据前文中任一项所述的车辆指令下发处理方法向车辆下发指令后,接收车辆反馈的车辆数据,其中,所述车辆数据携带车辆标识以及业务标识;
将所述车辆数据发送至所述业务标识对应的目标业务处理单元以对所述车辆数据进行处理,获得目标车辆数据;
将所述目标车辆数据发送至所述车辆标识对应的目标虚拟车辆映射单元,根据所述目标车辆数据修改所述目标虚拟车辆映射单元中的映射状态数据并存储。
可选地,所述业务处理单元包括与所述业务标识一一对应的多个数据解析单元;
所述将所述车辆数据发送至所述业务标识对应的目标业务处理单元以对车辆数据进行处理,获得目标车辆数据,包括:
将所述车辆数据发送给所述业务标识对应的目标数据解析单元进行解析获得所述目标车辆数据。
根据本发明实施例的又一方面,还提供了一种车辆数据处理系统,包括
包括前文任一项所述的车辆指令下发处理系统;其中,
所述数据交互模块还用于接收所述多个车辆上报的携带车辆标识以及业务标识的车辆数据,并将所述车辆数据发送至所述业务标识对应的目标业务处理单元;
所述目标业务处理单元用于对所述车辆数据进行处理,获得目标车辆数据,并将所述目标车辆数据发送至所述车辆标识对应的目标虚拟车辆映射单元;
所述目标虚拟车辆映射单元用于根据所述目标车辆数据修改所述目标虚拟车辆映射单元中的映射状态数据并存储。
本发明实施例提出的车辆指令下发处理方法和车辆指令下发系统中,在接收到车辆指令后,通过与车辆标识对应的目标虚拟车辆映射单元根据目标虚拟车辆映射单元中的映射状态数据判断车辆指令是否可执行,并由指令类型对应的目标业务处理单元对可执行的车辆指令进行处理,最后,将处理后的车辆指令下发给车辆标识对应的目标车辆,以实现从云端下发指令来控制车辆。本发明的方案通过与车联网中的现实车辆一对一映射的虚拟车辆映射单元来判断针对对应车辆的车辆指令是否可执行,并由匹配不同指令类型的业务处理单元对不同类型的车辆指令分别进行处理,保证了高并发量下云端向车辆下发指令的正常运行。本发明的方案无需基于线程编程,也无需使用任何线程锁,避免了线程锁造成的阻塞。由于虚拟车辆映射单元和业务处理单元的并发量可达百万级,打破了线程数量的限制,减少云端响应延迟,可缓解甚至解决高并发量下指令长时间延迟和无效的问题,极大地提升了高并发量下的性能。并且,对于百万级别的虚拟车辆映射单元和业务处理单元来说,即使有虚拟车辆映射单元和业务处理单元异常或崩溃也不会影响整个系统的运行,从而大大提高了系统的容错性,减少系统宕机的可能。同时,由于不同类型的车辆指令是分别由匹配不同指令类型的业务处理单元来处理,当存在新的车辆网业务需求而产生新类型的车辆指令时,能够通过增加相匹配的新的业务处理单元来实现,从而能够容易地扩展功能以应对新的业务需求。
上述说明仅是本发明技术方案的概述,为了能够更清楚了解本发明的技术手段,而可依照说明书的内容予以实施,并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂,以下特举本发明的具体实施方式。
根据下文结合附图对本发明具体实施例的详细描述,本领域技术人员将会更加明了本发明的上述以及其他目的、优点和特征。
附图说明
通过阅读下文优选实施方式的详细描述,各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的,而并不认为是对本发明的限制。而且在整个附图中,用相同的参考符号表示相同的部件。在附图中:
图1示出了一种基于AKKA框架的领域模型的示意性结构框图;
图2示出了根据本发明一实施例的车辆指令下发处理方法的流程示意图;
图3示出了根据本发明一实施例的车辆指令下发处理系统的结构示意图;
图4为图3所示的车辆指令下发处理系统的应用场景示意图;
图5示出了根据本发明一实施例的车辆数据处理方法的流程示意图;
图6示出了根据本发明一实施例的车辆数据处理系统的结构示意图;
图7为图6所示的车辆数据处理系统的应用场景示意图。
具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例,然而应当理解,可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反,提供这些实施例是为了能够更透彻地理解本公开,并且能够将本公开的范围完整的传达给本领域的技术人员。
现有的车联网云产品的设计普遍容易遭遇如下瓶颈:并发量高时,命令下发设备响应延迟。在早晚高峰时期,车连接的并发量会是非高峰期的3-5倍,短时间内大数量的车辆连接服务器,会给服务器带来极大的压力。如果无法良好处理并发问题和消息阻塞问题,就会造成命令下发长时间延迟和无效。现有技术中多线程、异步的处理方式由于受到最大线程数的限制,并不能很好地解决上述问题。
为解决上述技术问题,本申请提出了一种车辆指令下发处理方法。
参见图1所示,本申请的方法所基于的领域模型被设计成为以下三层:基础层、领域层和服务层。基础层负责给其他层(即领域层和服务层)提供支撑,与平台接口相关的部分以及数据存储和数据通道等都在基础层实现。领域层负责抽象车联网领域中的车辆的实体,将现实中的车辆映射到虚拟的系统内存中。领域层是整个系统的核心设计层。服务层主要负责实现车联网的业务逻辑,以及业务相关的特性处理。
本发明提出了一种车辆指令下发处理方法,该处理方法应用于云端,以实现云端向车辆下发车辆指令。本发明中提及的云端指相对于车辆以及用户客户端(如手机应用APP客户端)而言的后台服务端。图2示出了根据本发明一实施例的车辆指令下发处理方法的流程示意图。该处理方法应用于云端。云端包括多个业务处理单元以及多个虚拟车辆映射单元。每一业务处理单元用于执行不同的业务。每一虚拟车辆映射单元匹配一车辆。参见图2所示,该方法至少可以包括以下步骤S202至步骤S210。
步骤S202,接收下发的车辆指令,车辆指令携带车辆标识以及指令类型。
步骤S204,将车辆指令发送至车辆标识对应的目标虚拟车辆映射单元。
步骤S206,根据目标虚拟车辆映射单元中的映射状态数据,判断车辆指令是否可执行。若是,继续执行步骤S208。
步骤S208,将车辆指令发送至指令类型对应的目标业务处理单元以对车辆指令进行处理。
步骤S210,将处理后的车辆指令下发给车辆标识对应的目标车辆。
本发明实施例的方案通过与车联网中的现实车辆一对一映射的虚拟车辆映射单元来判断针对目标车辆的车辆指令是否可执行,并由匹配不同指令类型的业务处理单元对不同类型的车辆指令分别进行处理,保证了高并发量下云端向车辆下发指令的正常运行。本发明的方案无需基于线程编程,也无需使用任何线程锁,避免了线程锁造成的阻塞。
在一个优选的实施例中,业务处理单元以及虚拟车辆映射单元可通过AKKA框架下的Actor机制实现。基于上述领域模型的分层设计,AKKA框架的模块可被划入不同的层级,每个Actor可以收发消息并自己执行任务。Actor之间相互独立,且Actor之间收发消息均是并行且异步的。因此,一个Actor对应一辆现实车辆或者一个业务,车辆的实时状态数据都会同步对应到虚拟Actor里。当Actor收到同步数据后,可以按照预设业务逻辑进行自动操作。由此,利用AKKA框架的Actor机制,避免基于线程编程,打破线程数量的限制,也无需使用任何线程锁从而造成阻塞,极大地提高了高并发量下的系统性能。其中,领域层部分可包括与车辆对应的Actor。服务层部分可包括抽象出的不同服务的功能模块,这些不同服务的功能模块可由Actor来执行。同时,由于不同类型的车辆指令是分别由匹配不同指令类型的业务处理单元和虚拟车辆映射单元来处理,当存在新的车辆网业务需求而产生新类型的车辆指令时,能够通过增加相匹配的新的业务处理单元和虚拟车辆映射单元来实现,从而能够容易地扩展功能以应对新的业务需求。此外,框架中各模块之间的耦合度也大大降低,无论是基础层还是服务层,各层的模块都可以被其他实现方式替换。
上文步骤S202中,云端可以通过调用应用程序接口接收服务端下发的车辆指令。服务端可指本系统上游的云端微服务或APP应用等,对车辆状态、车辆业务进行管理。应用程序接口设置有调用参数,服务端通过调用参数来调用相应的应用程序接口。调用参数可包括车辆标识(例如,车联网设备ID等)。
车辆标识用于区分不同车辆。具体地,车辆标识可以是下列车辆标识信息:车联网设备ID、车辆识别码(Vehicle Identification Number,VIN)、与车辆硬件相关的移动台国际综合业务数字网号码(Mobile Subscriber International ISDN number,MSISDN)、国际移动用户识别码(International Mobile Subscriber Identity,IMSI)、集成电路卡识别码(Integrate circuit card identity,ICCID)、信息娱乐主机识别码(InfotainmentHead Unit Identity,IHUID)等。
车辆指令携带的指令类型可以包括远程控制命令(如远程开关门命令、发动机启动和停止命令、空调开关命令)、报警触发命令、车辆状态判断命令等。
上文步骤S204中,云端包括多个虚拟车辆映射单元,一个车辆标识可以与一个虚拟车辆映射单元相匹配,即一个虚拟车辆映射单元与一个车辆标识具有唯一的映射关系。因此,通过车辆指令携带的车辆标识可以确定该车辆标识对应的虚拟车辆映射单元即目标虚拟车辆映射单元。
在一种实施方案中,每一虚拟车辆映射单元具有其自己的特征属性,虚拟车辆映射单元与车辆标识的映射关系是虚拟车辆映射单元的特征属性与车辆标识的映射关系。实施例中的虚拟车辆映射单元的特征属性可包括与其对应车辆的车辆标识。具体地,虚拟车辆映射单元的特征属性可以包括下列车辆属性信息中的至少之一:车联网设备ID、车辆识别码、移动台国际综合业务数字网号码、国际移动用户识别码、集成电路卡识别码、信息娱乐主机识别码等。
由于同一车辆的上述车辆属性信息之间是一一对应的,由此,可方便准确地通过车辆标识与虚拟车辆映射单元的特征属性之间的映射关系将车辆标识与虚拟车辆映射单元一一映射关联。
上文步骤S206中,目标虚拟车辆映射单元根据自身的映射状态数据,判断车辆指令是否可以执行。若是,则执行步骤S208。若否,则可以向服务端反馈不可执行提示。其中,所述映射状态数据是指虚拟车辆映射单元内存储的对应的车辆的当前车辆状态数据。例如,服务端下发一开门指令,该开门指令携带车辆标识,则该车辆标识对应的目标虚拟车辆映射单元接收的这一为对目标车辆进行开门的指令,若目标虚拟车辆映射单元中映射状态数据表示目标车辆已处于安全停止状态,即该车辆的当前车辆状态数据表明该车辆处于安全状态,则判断该开门的车辆指令可以执行,否则,判断该车辆指令不可执行。
在一实施例中,若目标虚拟车辆映射单元判断车辆指令可执行,则可执行上文步骤S208,根据车辆指令携带的指令类型,目标虚拟车辆映射单元将车辆指令发送至指令类型对应的目标业务处理单元。每一车辆指令均有一标识表示其指令类型,指令类型与业务处理单元具有对应的关系,例如远程开关门命令、空调开关命令等均有其各自的标识表示其指令类型。因此,在实施例中,可以根据指令类型确定与该指令类型对应的业务处理单元即目标业务处理单元。
在一个实施例中,业务处理单元包括多个指令处理单元。指令处理单元与下发的车辆指令携带的指令类型对应,不同的指令处理单元用于处理不同类型的车辆指令。因此,目标业务处理单元可以为指令处理单元,相应地,步骤S208中可以将车辆指令发送至指令类型对应的目标指令处理单元。
目标业务处理单元(具体可为目标指令处理单元)在接收到车辆指令后,对车辆指令进行处理。具体地,目标业务处理单元将车辆指令转换为车辆标识对应的目标车辆可识别的执行指令。例如,对车辆指令进行格式转化,或者对车辆指令进行编码规则的转化等,使车辆指令转换为目标车辆可识别的信号,以使车辆指令可被目标车辆识别并执行。
通过与车辆指令的指令类型匹配的目标业务处理单元对车辆指令进行处理。由此,当存在新的车联网业务需求而产生新类型的车辆指令时,能够通过增加与新的指令类型相匹配的新的业务处理单元(具体可为指令处理单元)来实现,从而能够容易地扩展功能以应对新的业务需求。
上文步骤S210中,将处理后的车辆指令下发给车辆标识对应的目标车辆。在一实施例中,所述目标业务处理单元为指令处理单元,所述指令处理单元对车辆指令进行处理后生成执行指令,所述执行指令可以被目标车辆接收并识别,目标车辆接收执行指令后根据该执行指令控制对车辆进行具体的控制操作,例如打开车窗、锁上车门或者上报车辆数据等。
在一个实施例中,可以通过Kafka生产者向目标车辆下发处理后的车辆指令。其中,Kafka数据通道是一种消息中间件,可由Kafka服务器结合软件构成,包括Kafka消费者和Kafka生产者。在本申请的实施例中,下发的车辆指令会通过数据下行通道发送到Kafka数据通道,通过Kafka生产者将处理后的车辆指令下发给目标车辆。通过Kafka生产者来实现指令的下发,保证了高并发下信息传递的可靠性和稳定性。
进一步地,Kafka生产者与目标车辆之间还可以基于MQTT协议建立通信通道,进而基于MQTT协议,将处理后的车辆指令通过Kafka生产者下发给车辆指令中车辆标识对应的目标车辆。在硬件实现上,处理后的车辆指令由Kafka服务器发送给MQTT服务器,MQTT服务器再将车辆指令发送给目标车辆。
基于同一发明构思,本发明还提出了一种车辆指令下发处理系统,该系统应用于云端,用于实现前述的车辆指令下发处理方法。
图3示出了根据本发明一实施例的车辆指令下发处理系统20的结构示意图。图4示出了图3所示的车辆指令下发处理系统20的应用场景示意图。本发明中提及的云端指相对于车辆以及用户客户端(如手机应用APP客户端)而言的后台服务端,车辆指令下发处理系统20部署于云端。
参见图3和图4所示,车辆指令下发处理系统20一般性地可包括数据交互模块100、数据处理模块200和业务处理模块300。数据处理模块200包括多个虚拟车辆映射单元,该多个虚拟车辆映射单元与接入车辆指令下发处理系统20的多个车辆之间存在一一对应的映射关系。业务处理模块300可包括多个业务处理单元。每一业务处理单元用于执行不同的业务。数据交互模块100与多个车辆设备(例如图4中所示的TEM1至TEM5)通信。需要说明的是,图3和图4中,在业务处理模块300中仅示意性地示出了具体的业务处理单元(如指令处理单元等)。
在进行车辆指令下发时,与车辆标识对应的目标虚拟车辆映射单元接收下发的车辆指令,并根据自身的映射状态数据(即,目标虚拟车辆映射单元中的当前车辆状态数据),判断车辆指令是否可执行,若是,则将车辆指令发送至指令类型对应的目标业务处理单元。目标虚拟车辆映射单元判断车辆指令是否可执行的方式如前文所介绍,此处不另赘述。
目标业务处理单元对接收到的车辆指令进行处理,并将处理后的车辆指令发送至数据交互模块。具体地,目标业务处理单元将车辆指令转换为车辆标识对应的目标车辆可识别的执行指令。
在一个实施例中,业务处理单元至少包括指令处理单元。不同的指令处理单元用于处理不同类型的车辆指令。在这种情况下,目标虚拟车辆映射单元将车辆指令发送至指令类型对应的目标指令处理单元,目标指令处理单元对车辆指令进行处理,并将处理后的车辆指令发送至数据交互模块100。
进一步地,业务处理单元还可以包括类型匹配单元。类型匹配单元接收目标虚拟车辆映射单元发送至的车辆指令,根据车辆指令的指令类型匹配确定目标指令处理单元,并将车辆指令发送至目标指令处理单元。具体地,车辆指令的指令类型可以包括远程控制命令、报警触发命令、车辆状态判断命令等。进而,目标指令处理单元对车辆指令进行处理,并将处理后的车辆指令发送至数据交互模块100。
数据交互模块100将处理后的车辆指令下发给车辆标识对应的目标车辆,从而实现指令从云端的下发。
在一个实施例中,数据交互模块100可包括Kafka生产者102。Kafka生产者102从业务处理模块300的目标业务处理单元(具体可为目标指令处理单元)接收处理后的车辆指令,并将车辆指令推送给车辆。
进一步地,参照图4所示,车辆(具体为例如图4中的车联网设备TEM1至TEM5,具体可以为车载T-BOX)与数据交互模块100之间建立数据通道以进行数据传输。具体地,车联网设备TEM1至TEM5经MQTT节点(MQTT节点1和MQTT节点2)和Kafka节点(Kafka节点1和Kafka节点2)与数据交互模块100建立数据通道。MQTT节点为基于MQTT通信协议进行信息转发的服务器设备及搭载于设备内用于处理数据的软件,Kafka节点为基于的服务器设备及搭载于设备内用于处理数据的软件。如此,云端的Kafka生产者102可以基于MQTT协议将处理后的车辆指令下发给目标车辆。
在一个实施例中,车辆指令下发处理系统20还可以包括接口调用模块500。接口调用模块500可供服务端调用应用程序接口(Application Programming Interface,API),以供与服务端交互。具体地,接口调用模块500供服务端调用应用程序接口,以接收服务端下发的车辆指令,并将车辆指令发送给车辆标识对应的目标虚拟车辆映射单元。服务端包括本系统20上游的微服务端或APP应用等。
接口调用模块500的应用程序接口设置有调用参数,服务端通过调用参数来调用相应的应用程序接口。调用参数可包括目标车辆的车辆标识(例如,车联网设备ID等)。基于车辆标识可确定车辆指令应下发到的目标车辆。应用程序接口的调用参数可通过服务端进行设置。在应用程序接口被调用以下发车辆指令时,可获取调用参数中的车辆标识,进而可根据车辆标识以及虚拟车辆映射单元的特征属性与车辆标识的映射关系匹配出与车辆标识对应的虚拟车辆映射单元。
另外,在一些实施方案中,不同类型的车辆指令可以对应不同的应用程序接口。也就是说,在下发不同类型的车辆指令时会通过调用参数调用不同的应用程序接口,即调用参数可以反映车辆指令的类型。由此,在应用程序接口被调用以下发车辆指令时,类型匹配单元可以获取应用程序接口的调用参数,进而可以根据调用参数确定车辆指令的类型。
在一个实施例中,车辆指令下发处理系统20还可以包括数据存储模块400,用于存储前文所述的虚拟车辆映射单元与车辆标识的映射关系、虚拟车辆映射单元的映射状态数据(即当前车辆状态数据)等。具体地,数据存储模块400可包括缓存层DB(Caching layerDatabase)402。虚拟车辆映射单元的映射状态数据以及虚拟车辆映射单元与车辆标识的映射关系可以存储在缓存层DB402中。
在被调用的应用程序接口将车辆指令下发给车辆标识对应的目标虚拟车辆映射单元时,通过从数据存储模块400中读取虚拟车辆映射单元与车辆标识的映射关系来确定对应的目标虚拟车辆映射单元。在目标虚拟车辆映射单元判断车辆指令是否可执行时,从数据存储模块400中获取自身的映射状态数据,并根据获取的映射状态数据判断车辆是否可执行。
本发明通过领域驱动模型的设计将现实中的车辆映射到虚拟内存(Actor在计算机的内存中)中,并巧妙设计了系统框架,充分利用Actor特性,不仅实现高并发、高容错、无线程锁的架构设计,还将架构中的耦合度减少到最低,解决车联网领域早晚高峰的车辆高连接、海量命令下行的问题,以及减少服务器响应延迟,提升平台服务质量。
基于同一发明构思,本发明还提出了一种车辆数据处理方法,应用于云端。图5示出了根据本发明一实施例的车辆数据处理方法的流程示意图。该处理方法应用于云端。云端包括多个业务处理单元以及多个虚拟车辆映射单元。每一车辆可对应有不同的多个业务处理单元,用于执行该车辆对应的不同的业务。每一虚拟车辆映射单元匹配一现实车辆。参见图5所示,该方法至少可以包括以下步骤S502至步骤S506。
步骤S502,向车辆下发指令后,接收车辆反馈的车辆数据,其中,车辆数据携带车辆标识以及业务标识。
具体地,本步骤中向车辆下发指令是通过根据前述任意实施例或实施例组合的车辆指令下发处理方法进行的。
步骤S504,将车辆数据发送至业务标识对应的目标业务处理单元以对车辆数据进行处理,获得目标车辆数据。
步骤S506,将目标车辆数据发送至车辆标识对应的目标虚拟车辆映射单元,根据目标车辆数据修改目标虚拟车辆映射单元中的映射状态数据并存储。
本发明实施例提出的车辆数据处理方法,在保证高并发量下云端向车辆下发指令的正常运行的同时,保证高并发量下车辆向云端上报数据的正常运行。本发明的方案无需基于线程编程,也无需使用任何线程锁,避免了线程锁造成的阻塞,打破了线程数量的限制,可缓解甚至解决高并发量下消息阻塞问题,极大地提升了高并发量下的性能。
在一个优选的实施例中,业务处理单元以及虚拟车辆映射单元可通过AKKA框架下的Actor机制实现。基于上述领域模型的分层设计,AKKA框架的模块可被划入不同的层级,每个Actor可以收发消息并自己执行任务。Actor之间相互独立,且Actor之间收发消息均是并行且异步的。因此,一个Actor对应一辆现实车辆或者一个业务,车辆的实时状态数据都会同步对应到虚拟Actor里。当Actor收到同步数据后,可以按照预设业务逻辑进行自动操作。由此,利用AKKA框架的Actor机制,避免基于线程编程,打破线程数量的限制,也无需使用任何线程锁从而造成阻塞,极大地提高了高并发量下的系统性能。其中,领域层部分可包括与车辆对应的Actor。服务层部分可包括抽象出的不同服务的功能模块,这些不同服务的功能模块可由Actor来执行。同时,由于不同类型的业务指令数据是分别由匹配不同业务类型的业务处理单元和虚拟车辆映射单元来处理,当存在新的车辆网业务需求而产生新类型的业务指令数据时,能够通过增加相匹配的新的业务处理单元和虚拟车辆映射单元来实现,从而能够容易地扩展功能以应对新的业务需求。此外,框架中各模块之间的耦合度也大大降低,无论是基础层还是服务层,各层的模块都可以被其他实现方式替换。
上文步骤S502中,接收的车辆数据内可包含车辆状态数据、业务指令数据等。车辆状态数据为用于表示车辆实时状态的数据,例如车辆油量、车辆发动机温度、车辆门窗开闭情况等。业务指令数据例如可以为车辆状态选择和控制、车辆执行指令后的反馈数据、车辆运行管理数据(如电源模式管理数据等)、行车日志数据、仪表盘处理数据等。
车辆反馈的车辆数据携带有车辆标识和业务标识。车辆标识如前文所介绍。业务标识用于区分不同类型的车辆数据。例如,与仪表盘相关的数据(如车速、油量等车辆状态数据,或仪表盘处理数据等业务指令数据)为一种类型,与开关窗相关的数据(如车辆门窗开闭情况等车辆状态数据,或开关窗指令数据等业务指令数据)为一种类型,等等。由于不同类型的这些车辆数据的封装和转换规则各不相同,因此,通过不同的业务标识进行区分,以便由业务标识对应的目标业务处理单元相应地进行处理。业务标识的具体形式可以根据实际应用需求进行设置,例如可以设置为A、B、C等字符类标识,或者1、2、3等数字类标识,本发明对此不做具体限定。
在一个实施例中,车辆向云端上报车辆数据,云端可以通过Kafka消费者接收车辆上报的车辆数据。在本申请的实施例中,车辆上报的车辆数据首先会通过数据上行通道发送到Kafka数据通道,然后Kafka数据通道中的车辆数据会形成数据队列,基于数据队列原则(例如先进先出等原则),Kafka消费者主动消费Kafka数据通道中的车辆数据,从而使云端接收到车辆数据。通过Kafka消费模式来接收车辆数据,保证了高并发下信息传递的可靠性和稳定性。
此处的数据上行通道可以是基于MQTT(Message Queuing Telemetry Transport,消息队列遥测传输)通信协议建立的车辆(具体地,车辆的通信设备,如车联网设备)与Kafka消费者所在的服务器之间的数据通道。
上文步骤S504中,云端包括若干个业务处理单元,用于处理不同的车辆数据,每一业务处理单元与一业务标识对应,业务标识对应的业务处理单元为此次车辆数据上报的目标业务处理单元,因此,可以根据业务标识将车辆数据发送至业务标识对应的目标业务处理单元。在一些实施例中,可以由接收车辆上报的车辆数据的Kafka消费者根据业务标识确定目标业务处理单元,进而将车辆数据发送至该目标业务处理单元进行处理。业务处理单元与业务标识的对应关系可以预先存储在kafka数据通道中,当接收到车辆上报的数据时,通过查找业务处理单元与业务标识的对应关系来确定目标业务处理单元。
在一个实施例中,业务处理单元可以包括多个数据解析单元。数据解析单元与业务标识一一对应。不同的数据解析单元用于处理不同业务标识的车辆数据。因此,目标业务处理单元可以为目标数据解析单元,相应地,步骤S504中可以将车辆数据发送至业务标识对应的目标数据解析单元。
目标业务处理单元(具体为目标数据解析单元)接收到车辆数据后,对车辆数据进行解析,获得目标车辆数据。
在一个实施例中,目标车辆数据可以包括目标车辆状态数据。相应地,步骤S504可以实施为:将车辆数据发送给业务标识对应的目标业务处理单元(具体为目标数据解析单元)进行解析获得车辆数据内的车辆状态数据。此处提及的解析为根据既定的规则对车辆数据解封装,获得车辆数据中的车辆状态数据。并且,该目标业务处理单元(具体为目标数据解析单元)还将解析获得的车辆状态数据处理为虚拟车辆映射单元可识别的形式后,作为目标车辆状态数据。即,目标业务处理单元(具体为目标数据解析单元)对获得的车辆数据内的车辆状态数据按照设定的规则转换成虚拟车辆映射单元可识别的形式,并将转换后的数据作为目标车辆状态数据。
在一种实施方案中,目标业务处理单元(具体为目标数据解析单元)解析车辆数据以获得车辆数据内的车辆状态数据的步骤可以如下实施:
首先,目标业务处理单元(具体为目标数据解析单元)根据车辆数据携带的业务标识,获取车辆数据的解析参数。
具体地,目标业务处理单元(具体为目标数据解析单元)可通过查找预先存储在云端的存储模块中的业务标识与车辆数据的解析参数之间的对应关系表,来获取车辆数据的解析参数。车辆数据的解析参数可以包括车辆数据的加密方式和通讯协议类型。
车辆上报的车辆数据在发送过程中是经过封装的数据,且该封装的数据包有多层。具体地,每一车辆或者每一车型都有对应的加密方式和通讯协议,可由车辆设备(如车联网设备TBOX)根据本车采用的数据加密方式和本车与云端进行通信的通讯协议类型对要上报的车辆数据进行加密和第一层封装,随后,将封装后的车辆数据与车辆标识、业务标识一起进行第二层封装,得到封装后的车辆数据。当车辆数据上报时,目标业务处理单元(具体为目标数据解析单元)可以针对车辆对应的加密方式和通讯协议对该数据进行解封装。
在这种情况下,步骤S504可以进一步实施为:首先,目标业务处理单元(具体为目标数据解析单元)先对接收的车辆数据进行第一层解封装,得到车辆数据携带的车辆标识以及业务标识。然后,根据所得到的业务标识,确定获取车辆数据采用的加密方式和通讯协议类型。本文中的通讯协议可以为车辆设备(如车联网设备)与云端进行数据通信的VDS(Virus Detection System,病毒检测系统)协议等。加密方式在车辆与云端通信中可以为AES(Advanced Encryption Standard,高级加密标准)等。
然后,在获取车辆数据的解析参数后,目标业务处理单元(具体为目标数据解析单元)可以根据获取的解析参数(具体为车辆数据的加密方式和通讯协议类型),对车辆数据进行第二层解封装,得到车辆数据内的车辆状态数据。
不同的车辆数据上报时具有不同的加密方式和通讯协议类型,不同的加密方式和通讯协议类型对应不同的业务标识,不同的业务处理单元(数据解析单元)可以根据业务标识的不同解析不同的加密方式以及通讯协议。目标业务处理单元(具体为目标数据解析单元)在接收同一业务标识的车辆数据后,根据该标识对应的加密方式和通讯协议类型对车辆数据进行解析,增强了车辆向云端上报的数据安全性。
在另一个实施例中,目标车辆数据可以包括业务指令。相应地,步骤S504可以实施为:将车辆数据发送给业务标识对应的目标业务处理单元(具体为目标数据解析单元)进行解析获得车辆数据内的业务指令数据。并且,目标业务处理单元(具体为目标数据解析单元)将获得的业务指令数据按照预设的规则进行处理为虚拟车辆映射单元可识别的形式获得业务指令,并发送给车辆标识对应的虚拟车辆映射单元。
在一种实施方案中,首先,目标业务处理单元(具体为目标数据解析单元)在接收到车辆数据后,采用前文所述的方式获取车辆数据的解析参数,并根据获取的解析参数对车辆数据进行解析,获得车辆数据内的业务指令数据。例如,步骤S502中接收的车辆数据携带业务标识,云端能够根据该业务标识确定其对应的业务处理单元作为目标业务处理单元(具体为目标数据解析单元),进而将该车辆数据发送给该目标业务处理单元。该业务标识可以表明所述业务指令数据用于处理远程控车、获取云端音乐等业务,不同的业务标识对应不同的业务。此时,目标业务处理单元(具体为目标数据解析单元)可以根据该业务标识对应的解析参数对该车辆数据进行解析,从而获得车辆数据内的业务指令数据。
然后,目标业务处理单元(具体为目标数据解析单元)根据预设的规则对业务指令数据进行处理,将业务指令数据转化为可以被车辆标识对应的目标虚拟车辆映射单元所识别的业务指令,将转化得到的业务指令发送给车辆标识对应的目标虚拟车辆映射单元。例如,车辆数据携带的业务标识为远程控车的业务,则将该车辆数据发送给用于远程控车的业务处理单元(数据解析单元),该业务处理单元(数据解析单元)对该车辆数据进行解析后获得相应的业务指令数据,业务指令数据可以为允许远程控制或不允许远程控车。在一个实施例中,车辆上报的允许远程控车的业务指令数据为第一编码形式,而目标虚拟车辆映射单元能识别的允许远程控车的业务指令为第二编码形式,因此,在车辆上报允许远程控车的业务指令数据时,目标业务处理单元(具体为目标数据解析单元)需要将车辆上报的业务指令数据按照预设的规则,将该业务指令数据由第一编码形式转换为第二编码形式。此实施例仅为示例,包括但不仅限于远程控制、开关窗、获取云端数据等业务指令数据。
最后,在步骤S506中,目标业务处理单元(具体为目标数据解析单元)将处理后的目标车辆数据发送至车辆标识对应的目标虚拟映射单元,该目标虚拟映射单元根据接收的目标车辆数据修改映射状态数据并存储。虚拟车辆映射单元与车辆标识的映射关系如前文所介绍。
在目标业务处理单元(具体为目标数据解析单元)解析获得车辆数据内的车辆状态数据,并将车辆状态数据处理为虚拟车辆映射单元可识别的目标车辆状态数据的情况下,目标业务处理单元(具体为目标数据解析单元)将处理后的目标车辆状态数据发送至车辆标识对应的目标虚拟车辆映射单元。在接收到目标业务处理单元发送的目标车辆状态数据后,目标虚拟车辆映射单元根据接收到的目标车辆状态数据修改自身的映射状态数据,并存储目标车辆状态数据作为当前车辆状态数据。具体地,目标虚拟车辆映射单元可将目标车辆状态数据存储至云端的缓存装置,目标虚拟车辆映射单元在修改自身的映射状态数据时,从缓存装置中拉取车辆状态数据并根据目标车辆状态数据修改后再次存储。由此,高效、可靠地实现了高并发下将每个车辆的实时车辆状态数据同步至云端。
在目标业务处理单元(具体为目标数据解析单元)解析获得车辆数据内的业务指令数据,并将业务指令数据处理为虚拟车辆映射单元可识别的业务指令的情况下,目标业务处理单元(具体为目标数据解析单元)根据车辆标识将处理后的业务指令发送给车辆标识对应的目标虚拟车辆映射单元。目标虚拟车辆映射单元根据业务指令进行业务处理,并根据业务处理的结果修改自身的映射状态数据并存储。具体地,目标虚拟车辆映射单元判断指令是否可执行并根据业务指令进行具体的处理,根据业务处理的结果车辆会再次上报车辆状态的车辆数据,根据车辆数据修改目标虚拟车辆映射单元内的映射状态数据。例如,在通过与仪表盘处理数据类型匹配的业务处理单元(数据解析单元)对仪表盘处理数据进行处理之后,与车辆标识对应的虚拟车辆映射单元判断该业务指令数据是否可执行,如果可执行,则反馈给车辆进行执行(例如调整发动机转速),当车辆执行结束后,会将执行后的数据(例如仪表盘中发送机转速变化数据)再次上报给云端,虚拟车辆映射单元根据执行后的结果修改映射状态数据,并存储,以调整后的数据作为当前车辆状态数据。
通过根据对业务指令数据的业务处理结果对车辆状态数据进行实时调整,进一步保证当前车辆状态数据的实时性和同步性。
基于同一发明构思,本发明还提出了一种车辆数据处理系统。该系统应用于云端,用于实现前述的车辆数据处理方法。
图6示出了根据本发明一实施例的车辆数据处理系统30的示意图。图7示出了图6所示的车辆数据处理系统30的应用场景示意图。本发明中提及的云端指相对于车辆以及用户客户端(如手机应用APP客户端)而言的后台服务端,车辆数据处理系统30部署于云端。参见图6和图7所示,车辆数据处理系统30可包括根据前文介绍的任意实施例或实施例组合的车辆指令下发处理系统20。具体地说,车辆数据处理系统30可包括数据交互模块100、数据处理模块200和业务处理模块300。数据交互模块100与多个车辆设备(例如图7中所示的TEM1至TEM5)通信。数据处理模块200包括多个虚拟车辆映射单元,每一虚拟车辆映射单元与车辆标识唯一对应,换言之,每个虚拟车辆映射单元与接入车辆数据处理系统30的车辆之间存在一一对应的映射关系。业务处理模块300包括多个业务处理单元,其中,一部分的业务处理单元中的每一业务处理单元与指令类型唯一对应,另一部分的业务处理单元中的每一业务处理单元与业务标识唯一对应,用于执行不同的业务。
在车辆数据处理系统30中,除前文所介绍的数据交互模块100、数据处理模块200和业务处理模块300执行的功能外,数据交互模块100还用于接收多个车辆上报的携带车辆标识以及业务标识的车辆数据,并将车辆数据发送至业务标识对应的目标业务处理单元。具体地,数据交互模块100可根据业务处理单元与业务标识的对应关系确定目标业务处理单元。数据交互模块100确定目标业务处理单元的方式如前文所述,不再重复。
目标业务处理单元对车辆数据进行处理,获得目标车辆数据,并将目标车辆数据发送至车辆标识对应的目标虚拟车辆映射单元。目标虚拟车辆映射单元根据目标车辆数据修改映射状态数据并存储。
在一个实施例中,业务处理单元包括多个数据解析单元和多个指令处理单元。指令处理单元与指令类型一一对应,用于处理不同类型的车辆指令。数据解析单元与业务标识一一对应,用于处理不同业务类型的车辆数据。
在一个实施例中,目标车辆数据可包括目标车辆状态数据。相应地,目标业务处理单元(具体为目标数据解析单元)接收数据交互模块发送的车辆数据,对车辆数据进行解析获得车辆数据内的车辆状态数据,并将车辆状态数据处理为虚拟车辆映射单元可识别的目标车辆状态数据。目标业务处理单元(具体为目标数据解析单元)解析车辆数据获得车辆状态数据并处理车辆状态数据的具体方式如前文所述,不再重复。目标虚拟车辆映射单元根据处理后的目标车辆状态数据修改目标虚拟车辆映射单元中的映射状态数据并存储。目标虚拟车辆映射单元修改映射状态数据并存储的具体方式亦如前文所介绍,不另赘述。
在另一个实施例中,目标车辆数据可包括业务指令。相应地,目标业务处理单元(具体为目标数据解析单元)对车辆数据进行解析获得车辆数据内的业务指令数据,并将业务指令数据处理为虚拟车辆映射单元可识别的业务指令。目标虚拟车辆映射单元根据业务指令进行业务处理,并根据业务处理的结果修改目标虚拟车辆映射单元中的映射状态数据并存储。目标业务处理单元(具体为目标数据解析单元)解析获得业务指令数据并处理业务指令数据的具体方式,以及目标虚拟车辆映射单元根据业务指令进行业务处理,并根据业务处理的结果修改映射状态数据并存储的具体方式亦如前文所述,不再重复。
在一个实施例中,车辆数据处理系统30还可以包括数据存储模块400,用于存储前文所述的业务处理单元(数据解析单元)与业务标识的对应关系、业务标识与车辆数据的解析参数之间的对应关系表、虚拟车辆映射单元与车辆标识的映射关系、虚拟车辆映射单元的特征属性、目标车辆状态数据等。
具体地,数据存储模块400可包括持久性DB(Persistence Database)401和缓存层DB(Caching layer Database)402。目标车辆状态数据、虚拟车辆映射单元与车辆标识的映射关系、业务处理单元(数据解析单元)与业务标识的对应关系可以存储在缓存层DB 402中,虚拟车辆映射单元的特征属性以及业务标识与车辆数据的解析参数之间的对应关系表可以存储在持久性DB 401中。
在一个实施例中,数据交互模块100可包括Kafka消费者101和Kafka生产者102。Kafka消费者101通过Kafka消费者模式接收车辆上报的车辆数据。
具体地,参照图7所示,车辆上报的车辆数据首先会通过数据上行通道发送到Kafka数据通道。Kafka数据通道为消息中间件,可由Kafka服务器(图7中的Kafka节点1和Kafka节点2可分别视为Kafka服务器)结合软件构成。此处的数据上行通道指基于MQTT通信协议建立的车辆中的车联网设备(图7中的TEM1至TEM5设备,具体例如车载T-BOX)与数据交互模块100所在的服务器之间建立的数据通道。设备TEM1至TEM5经MQTT节点(MQTT节点1和MQTT节点2)和Kafka节点(Kafka节点1和Kafka节点2)与数据交互模块100建立数据通道以进行数据传输。MQTT节点为基于MQTT通信协议进行信息转发的有源电子设备(如图7所示的MQTT网关)。
当Kafka数据通道有消息(即数据)时,Kafka消费者101会主动消费数据,并将数据推送给业务处理模块300中的相应业务处理单元(数据解析单元)。
在一个实施例中,车辆数据上报系统30还可以包括接口调用模块500。接口调用模块500还可以为服务端提供可调用的应用程序接口,以供服务端获取所存储的当前车辆状态数据。具体地,服务端通过接口调用模块500调用应用程序接口,经由数据处理模块200的虚拟车辆映射单元从数据存储模块400获取当前车辆状态数据。服务端可通过调用应用程序接口获取车辆的当前车辆状态数据以进行数据分析处理等。例如,用户通过手机应用APP客户端向对应的APP服务端发送指定车辆的车辆状态获取请求,则APP服务端响应该请求,经由数据处理模块200中与指定车辆对应的虚拟车辆映射单元从数据存储模块400获取指定车辆的当前车辆状态数据,并将当前车辆状态数据返回给手机应用APP客户端以向用户展示该车辆的状态。
本发明通过领域驱动模型的设计将现实中的车辆映射到虚拟内存(Actor在计算机的内存中)中,并巧妙设计了系统框架,充分利用Actor特性,不仅实现高并发、高容错、无线程锁的架构设计,还将架构中的耦合度减少到最低,解决车联网领域早晚高峰的车辆高连接、海量数据上行的问题,以及减少服务器响应延迟,提升平台服务质量。
根据上述任意一个可选实施例或多个可选实施例的组合,本发明实施例能够达到如下有益效果:
本发明实施例提出的车辆指令下发处理方法和车辆指令下发系统中,在接收到车辆指令后,通过与车辆标识对应的目标虚拟车辆映射单元根据目标虚拟车辆映射单元中的映射状态数据判断车辆指令是否可执行,并由指令类型对应的目标业务处理单元对可执行的车辆指令进行处理,最后,将处理后的车辆指令下发给车辆标识对应的目标车辆,以实现从云端下发指令来控制车辆。本发明的方案通过与车联网中的现实车辆一对一映射的虚拟车辆映射单元来判断针对对应车辆的车辆指令是否可执行,并由匹配不同指令类型的业务处理单元对不同类型的车辆指令分别进行处理,保证了高并发量下云端向车辆下发指令的正常运行。本发明的方案无需基于线程编程,也无需使用任何线程锁,避免了线程锁造成的阻塞。由于虚拟车辆映射单元和业务处理单元的并发量可达百万级,打破了线程数量的限制,减少云端响应延迟,可缓解甚至解决高并发量下指令长时间延迟和无效的问题,极大地提升了高并发量下的性能。并且,对于百万级别的虚拟车辆映射单元和业务处理单元来说,即使有虚拟车辆映射单元和业务处理单元异常或崩溃也不会影响整个系统的运行,从而大大提高了系统的容错性,减少系统宕机的可能。同时,由于不同类型的车辆指令是分别由匹配不同指令类型的业务处理单元来处理,当存在新的车辆网业务需求而产生新类型的车辆指令时,能够通过增加相匹配的新的业务处理单元来实现,从而能够容易地扩展功能以应对新的业务需求。
所属领域的技术人员可以清楚地了解到,上述描述的系统、装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,为简洁起见,在此不另赘述。
另外,在本发明各个实施例中的各功能单元可以物理上相互独立,也可以两个或两个以上功能单元集成在一起,还可以全部功能单元都集成在一个处理单元中。上述集成的功能单元既可以采用硬件的形式实现,也可以采用软件或者固件的形式实现。
本领域普通技术人员可以理解:所述集成的功能单元如果以软件的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明的技术方案本质上或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,其包括若干指令,用以使得一台计算设备(例如个人计算机,服务器,或者网络设备等)在运行所述指令时执行本发明各实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM)、随机存取存储器(RAM),磁碟或者光盘等各种可以存储程序代码的介质。
或者,实现前述方法实施例的全部或部分步骤可以通过程序指令相关的硬件(诸如个人计算机,服务器,或者网络设备等的计算设备)来完成,所述程序指令可以存储于一计算机可读取存储介质中,当所述程序指令被计算设备的处理器执行时,所述计算设备执行本发明各实施例所述方法的全部或部分步骤。
最后应说明的是:以上各实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述各实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:在本发明的精神和原则之内,其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分或者全部技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案脱离本发明的保护范围。

Claims (9)

1.一种车辆指令下发处理方法,应用于云端,其特征在于,所述云端包括多个业务处理单元以及多个虚拟车辆映射单元,每一所述虚拟车辆映射单元匹配一车辆,所述方法包括:
接收下发的车辆指令,所述车辆指令携带车辆标识以及指令类型;
将所述车辆指令发送至所述车辆标识对应的目标虚拟车辆映射单元;
根据所述目标虚拟车辆映射单元中的映射状态数据,判断所述车辆指令是否可执行;
若是,将所述车辆指令发送至所述指令类型对应的目标业务处理单元以对所述车辆指令进行处理;业务处理单元通过AKKA框架下的Actor机制实现,一个Actor对应一个业务,车辆的实时状态数据会同步对应到虚拟Actor里,当Actor收到同步数据后,按照预设业务逻辑进行自动操作;
将处理后的所述车辆指令下发给所述车辆标识对应的目标车辆;
其中,将处理后的所述车辆指令下发给所述车辆标识对应的目标车辆包括:
通过Kafka生产者向所述目标车辆下发所述车辆指令。
2.根据权利要求1所述的处理方法,其特征在于,
所述业务处理单元包括多个指令处理单元,
所述将所述车辆指令发送至所述指令类型对应的目标业务处理单元以对所述车辆指令进行处理包括:
将所述车辆指令发送至所述指令类型对应的目标指令处理单元以将所述车辆指令转换为车辆标识对应的目标车辆可识别的执行指令,并将所述执行指令下发给车辆标识对应的目标车辆。
3.根据权利要求1所述的处理方法,其特征在于,所述接收下发的车辆指令,包括:
通过调用的应用程序接口接收服务端下发的车辆指令。
4.根据权利要求1所述的方法,其特征在于,所述业务处理单元以及所述虚拟车辆映射单元通过AKKA框架下的Actor机制实现。
5.一种车辆指令下发处理系统,其特征在于,包括:
数据处理模块,包括多个虚拟车辆映射单元,每一所述虚拟车辆映射单元匹配一车辆;
业务处理模块,包括多个业务处理单元;以及
数据交互模块,与多个车辆设备通信;
其中,所述车辆指令携带车辆标识以及指令类型;
所述车辆标识对应的目标虚拟车辆映射单元接收下发的所述车辆指令,并根据自身的映射状态数据,判断所述车辆指令是否可执行,若是,则将所述车辆指令发送至所述指令类型对应的目标业务处理单元;
所述目标业务处理单元用于对所述车辆指令进行处理,并将处理后的所述车辆指令发送至所述数据交互模块;业务处理单元通过AKKA框架下的Actor机制实现,一个Actor对应一个业务,车辆的实时状态数据会同步对应到虚拟Actor里,当Actor收到同步数据后,按照预设业务逻辑进行自动操作;
所述数据交互模块用于将所述处理后的所述车辆指令下发给所述车辆标识对应的目标车辆;
数据交互模块包括Kafka生产者,Kafka生产者从业务处理模块的目标业务处理单元接收处理后的车辆指令,并将车辆指令推送给车辆。
6.根据权利要求5所述的车辆指令下发处理系统,其特征在于,还包括接口调用模块,与下发车辆指令的服务端通信;
所述接口调用模块用于调用应用程序接口以接收所述服务端下发的车辆指令,并将所述车辆指令发送给所述车辆标识对应的目标虚拟车辆映射单元。
7.一种车辆数据处理方法,应用于云端,其特征在于,所述云端包括多个业务处理单元以及多个虚拟车辆映射单元,每一所述虚拟车辆映射单元匹配一车辆,所述方法包括:
根据权利要求1-4任一项所述的处理方法向车辆下发指令后,
接收车辆反馈的车辆数据,其中,所述车辆数据携带车辆标识以及业务标识;
将所述车辆数据发送至所述业务标识对应的目标业务处理单元以对所述车辆数据进行处理,获得目标车辆数据;
将所述目标车辆数据发送至所述车辆标识对应的目标虚拟车辆映射单元,根据所述目标车辆数据修改所述目标虚拟车辆映射单元中的映射状态数据并存储。
8.根据权利要求7所述的处理方法,其特征在于,所述业务处理单元包括与所述业务标识一一对应的多个数据解析单元;
所述将所述车辆数据发送至所述业务标识对应的目标业务处理单元以对车辆数据进行处理,获得目标车辆数据,包括:
将所述车辆数据发送给所述业务标识对应的目标数据解析单元进行解析获得所述目标车辆数据。
9.一种车辆数据处理系统,其特征在于,包括
如权利要求5或6所述的车辆指令下发处理系统;其中,
所述数据交互模块还用于接收所述多个车辆上报的携带车辆标识以及业务标识的车辆数据,并将所述车辆数据发送至所述业务标识对应的目标业务处理单元;
所述目标业务处理单元用于对所述车辆数据进行处理,获得目标车辆数据,并将所述目标车辆数据发送至所述车辆标识对应的目标虚拟车辆映射单元;
所述目标虚拟车辆映射单元用于根据所述目标车辆数据修改所述目标虚拟车辆映射单元中的映射状态数据并存储。
CN202010604450.7A 2020-06-29 2020-06-29 车辆指令下发处理方法和系统及车辆数据处理方法和系统 Active CN111726256B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010604450.7A CN111726256B (zh) 2020-06-29 2020-06-29 车辆指令下发处理方法和系统及车辆数据处理方法和系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010604450.7A CN111726256B (zh) 2020-06-29 2020-06-29 车辆指令下发处理方法和系统及车辆数据处理方法和系统

Publications (2)

Publication Number Publication Date
CN111726256A CN111726256A (zh) 2020-09-29
CN111726256B true CN111726256B (zh) 2023-04-25

Family

ID=72569518

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010604450.7A Active CN111726256B (zh) 2020-06-29 2020-06-29 车辆指令下发处理方法和系统及车辆数据处理方法和系统

Country Status (1)

Country Link
CN (1) CN111726256B (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113411771B (zh) * 2021-08-20 2021-11-09 湖北亿咖通科技有限公司 车辆的蓝牙控制方法和装置
CN114785832B (zh) * 2022-04-25 2024-01-23 北京兴竹同智信息技术股份有限公司 一种预警数据传输方法及系统
CN115442767B (zh) * 2022-11-08 2023-03-24 上海银基信息安全技术股份有限公司 车控事件关联方法、装置及系统、介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110650203A (zh) * 2019-09-26 2020-01-03 广州视源电子科技股份有限公司 数据传输方法、装置和系统、计算机存储介质及电子设备

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105812484B (zh) * 2016-04-25 2019-03-12 奇瑞汽车股份有限公司 车载交互系统
WO2019222452A1 (en) * 2018-05-16 2019-11-21 Burkin Donald Vehicle messaging system and method of operation thereof
CN108924194A (zh) * 2018-06-20 2018-11-30 北京车和家信息技术有限公司 车联网通信方法、车联网关及数据传输系统
CN109714420A (zh) * 2018-12-28 2019-05-03 北京车和家信息技术有限公司 一种数据同步的方法、装置及系统
CN110232073A (zh) * 2019-05-10 2019-09-13 中国联合网络通信集团有限公司 一种数据处理分析系统及方法
CN111124392A (zh) * 2019-12-30 2020-05-08 江苏徐工信息技术股份有限公司 一种提高物联网平台规则引擎高并发能力的方法

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110650203A (zh) * 2019-09-26 2020-01-03 广州视源电子科技股份有限公司 数据传输方法、装置和系统、计算机存储介质及电子设备

Also Published As

Publication number Publication date
CN111726256A (zh) 2020-09-29

Similar Documents

Publication Publication Date Title
CN111726414B (zh) 一种车辆上报数据的处理方法和车辆数据上报系统
CN111726256B (zh) 车辆指令下发处理方法和系统及车辆数据处理方法和系统
CN112291124B (zh) 一种基于some/ip协议的车载网络ecu通信方法
US11689606B2 (en) Communication method, system and apparatus
CN112367233B (zh) 基于面向服务的架构下车载网络ecu通信方法及装置
KR101228277B1 (ko) 메시징에 관한 장치 및 방법
CN111930598B (zh) 基于区块链和大数据分析的信息处理方法及大数据平台
CN114449459B (zh) 消息传输方法、平台功能应用功能
KR20120063454A (ko) 장치 관리 클라이언트에 의한 비세션 보고 방법 및 장치
CN112600881A (zh) 提供物联网服务的方法、设备、服务器及存储介质
CN117201579A (zh) 一种基于udp与dds架构的半实物仿真通信系统
CN113259874A (zh) 消息处理方法、电子设备及存储介质
CN109766347B (zh) 一种数据更新方法、装置、系统、计算机设备及存储介质
KR20200087673A (ko) 전자 메시지 적응
CN115001897A (zh) 通信方法、装置、电子设备及自动驾驶车辆
CN111865935A (zh) 一种数据传输系统
CN116074399B (zh) 基于可视化配置灵活接入的数据采集及控制系统与方法
CN112383924B (zh) 基站设备管理方法、装置及系统
CN113572854B (zh) 基于Kafka组件的数据传输方法及系统
CN117082017B (zh) 一种白盒交换机扩展卡管理的方法及装置
CN112188244B (zh) 一种前端摄像头实时视频点播方法及装置、电子设备
US20240073280A1 (en) Edge configuration server, multi-access system, method, and computer-readable medium
CN112740635B (zh) 报文解析的方法、数据发送端、数据接收端和系统
CN117793220A (zh) 用于数据审计查询的系统、方法及计算机设备
CN117119014A (zh) 域控制器之间的通信数据的处理方法、装置及设备

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
TA01 Transfer of patent application right

Effective date of registration: 20220323

Address after: 430051 No. b1336, chuanggu startup area, taizihu cultural Digital Creative Industry Park, No. 18, Shenlong Avenue, Wuhan Economic and Technological Development Zone, Wuhan, Hubei Province

Applicant after: Yikatong (Hubei) Technology Co.,Ltd.

Address before: No.c101, chuanggu start up area, taizihu cultural Digital Industrial Park, No.18 Shenlong Avenue, Wuhan Economic Development Zone, Hubei Province

Applicant before: HUBEI ECARX TECHNOLOGY Co.,Ltd.

TA01 Transfer of patent application right
GR01 Patent grant
GR01 Patent grant