对车辆进行在途监控的方法、系统及存储介质与流程

本发明属于物流智能运输监控领域，尤其涉及一种对车辆进行在途监控的方法、系统及存储介质。

背景技术：

随着快递行业的蓬勃发展，快递量越来越大，路由规划车线的需求也在不断的增长。

在日常车辆运输管理过程中，存在着规划车线多，不能有效合理的安排车辆的问题。由于没有科学合理的安排车辆，导致部分车线运输资源紧张、运力不足或部分车线运力过剩的问题，对车线及车辆上的管理混乱，不但增加了物流运输的成本，还延迟了配送到货的时间。

重庆交通大学在cn201610731763.2中公开了一种基于互联网车辆在途监控管理系统,包括，

装在车上的车载终端，车载终端用于收集及传递车辆信息，且实时播放车辆信息；车载终端包括预警信息管理模块，预警信息管理模块用于监控车辆路线，并接收信息处理服务器发送的预警信息，并在预警位置播报语音和图像信息；

信息处理服务器，信息处理服务器用于接收所述车载终端信息，且实时监控所述车载终端路线；

信息管理终端，信息管理终端用于安排所述车载终端工作行车计划，并生成数据发布给所述信息处理服务；信息管理终端包括线路信息编辑模块，线路信息编辑模块用于编辑生成线路信息及离线预警数据，线路信息编辑模块内的文本数据可转化语音数据，且线路信息编辑模块将离线预警数据传给车载终端。

对应地方法为：预先设定在信息管理终端内的离线预警数据，离线预警数据包括线路数据采集以及线路数据编辑，其中，线路数据采集用于采集预警的位置的信息，线路数据编辑用于线路数据加工；车载终端获取位于信息处理服务器的临时预警数据，对临时预警数据进行处理并获得处理结果，信息处理服务器将处理结果发送至车载终端；当车载终端未接收信息处理服务器发送的临时预警数据，信息管理终端将下发离线预警数据，离线预警数据存储在车载终端，且离线预警数据具有预警位置信息、预警时间戳、预警临时图像、预警文本和预警语音的预警信息进行分发以完成预警提示

上述方案虽然原则上可以实现对车辆的行驶路线进行监控，但是在完成该监控功能的前提是需要对车辆进行二次改造，增加新的硬件车载终端，而且需要对车载终端开发相应的与信息处理服务器对接的软件。开发成本高、维护成本也高，同时当硬件发生故障时其维护的成本也高。还有，该方案只能对少量车子进行监控，当车辆达到一定数量级时，该系统不具有大数据量的并行处理能力，容易造成整个系统的崩塌。

驾驶员的疲劳驾驶和分心驾驶是造成交通事故的主要原因之一，特别是在高速公路等场景下，驾驶员长时间行车而且操作单调，极易造成疲劳或者注意力分散，不能够及时响应危险情况，造成交通事故。因此，在行车过程中对驾驶员的行驶状态进行监测，对危险驾驶即时预警尤为重要。现有最多被采用的疲劳检测手段是驾驶员驾车行为分析，即通过记录和解析驾驶员转动方向盘、踩刹车等行为特征，判别驾驶员是否疲劳。但是，这种方式受驾驶员驾驶习惯影响极大，判断结果不准确。为此，也有申请人提出驾驶行为分析方法，该方法包括：采集驾驶用户的驾驶图像数据和车辆的行驶信息；依据所述驾驶图像数据，分析所述驾驶用户的注意力信息；依据所述注意力信息和行驶信息，确定驾驶用户的驾驶状态，所述驾驶状态包括：异常驾驶状态；针对异常驾驶状态进行报警提示。可以拍摄驾驶用户的驾驶图像数据，然后分析驾驶用户的注意力信息，将注意力信息和车辆的行驶信息相结合，判断驾驶用户的驾驶状态，从而能够检测出异常驾驶状态并进行报警提示，基于驾驶员的注意力有效监控驾驶员是否处于危险驾驶状态，及时对危险驾驶进行预警，保证了行车安全。但是，算法的不准确性及驾驶员的个体差异性，上述的行为分析更多的是理论层面，那么如何在现有的物流运输过程中实现对大规模车辆在途监控，既具有一定监控实时性，又能考虑其成本性，这是现有极需要解决的问题。

技术实现要素：

本发明为解决上述大规模车辆在途监控在考虑成本的情况下兼顾并行问题和性能问题，提供一种对车辆进行在途监控的方法、系统、计算机设备和存储介质。

一种对车辆进行在途监控的方法，包括：

s1:后台服务端预先加载电子地图，所述电子地图包括坐标系各点的地理位置信息；

s2:所述后台服务端接收预行驶车辆从起始地到目标地的运行路径规划，并且映射至所述电子地图上从所述起始地到所述目标地的标准轨迹；

s3:所述后台服务端接收到在途车辆发送的包括车辆实时在途信息在内的在途监控请求报文，从中解析出所述车辆标识信息和车辆当前所在位置信息，并将解析出来的数据发送至所述后台服务端的mq集群；

s4：所述mq集群中对应的网络web服务器根据所述车辆标识信息找到相适配的标准轨迹信息；

s5:将所述车辆当前所在位置信息与所述标准轨迹信息的标准轨迹点进行比对，以确定所述车辆是否存在线路偏移。

在本实例中，步骤s5进一步包括：

s51:从所述车辆当前所在位置信息中找到包括经度和纬度信息在内的行驶地的地理信息；

s52:根据所述行驶地的地理信息，从所述电子地图的标准轨迹信息中找到与所述车辆当前所在位置距离最近的标准轨迹点作为监控点，如果所述监控点与所述车辆当前所在位置信息的距离小于报警阈值，则更新报警状态为“线路不偏移”；否则进行步骤s53；

s53:以所述监控点为中心，从所述电子地图的规划路线上分别取左参考点和右参考点，所述左参考点和所述右参考点构成一条直线，计算车辆当前所在位置到该直线的距离，求出其中的最小距离作为偏移距离，并将本次报警状态更新为“线路偏移”。

本发明的较佳实施方式中步骤s53之后还包括：

s54:将所述行驶地的地理信息显示在所述电子地图上，并将所述本次行驶地的地理信息与上一次的行驶地地理信息进行连接显示，形成本次的当前行驶路径图；

s55:当本次报警状态为“线路偏移”时，进一步判断上一次车辆的报警状态是否也是“线路偏移”的状态，如果是，则记录所述报警状态为“线路偏移”的持续时长；

s56:若所述持续时长达到阈值，则启动线路偏移的报警机制。

还有，步骤s4可以进一步包括：

s41:所述mq集群预先建立处理所述车辆在途监控与web服务器之间的映射表，所述映射表保存所述车辆标识信息与处理所述车辆在途监控的web服务器之间的对应关系；

s42:所述mq集群按照所述车辆标识信息查找所述映射表，找到对应的web服务器，将解析出来的在途监控请求发送至所述web服务器对应的mq消息队列，以便多个所述web服务器并行处理所述在途监控请求；

s43:当所述web服务器按照所述mq消息队列处理机制处理所述在途监控请求时，通过所述车辆标识信息分别查找预先存储的在途监控处理分表和标准轨迹存储表，找到所述车辆之前的在途监控记录和标准轨迹信息，以完成在途监控。

另外，步骤s2还可以进一步包括：

s21:所述后台服务端设置所述车辆的起始地、目标地和经过规划的运行路径，并在所述运行路径中确定包括高速入口地、出口地在内的关键地点；

s22:所述电子地图设置从所述起始地到目标地，以及途径该些所述关键地点的标准轨迹，并将标准轨迹按照预先设定的网格坐标系，获得网格上的标准轨迹点的坐标信息，所述坐标信息包括其经度、纬度在内的地理信息。

本实例步骤s3还包括：所述后台服务端接收到在途监控请求中还携带所述车辆的运行里程和发出请求的时间点；步骤s4还包括：所述web服务器通过发出请求的时间点和开始行驶的时间点来计算当前行驶所用时长，通过所述运行里程和所述当前行驶所用时长计算当前的行驶速度，当所述行驶速度低于预先设定值，则判定所述在途行驶为低速状态，当低速度状态持续时长超过预先设定阈值后，则进行低速报警操作。

本发明还提供一种对车辆进行在途监控的系统，其进一步包括：

多个车辆：所述车辆端上设置在途监控装置，所述在途监控装置可按照预先约定发送包括车辆实时在途信息在内的在途监控请求；

后台服务端，与所述车辆的在途监控装置进行通信，其进一步包括：

电子地图构建模块，用于预先构建电子地图，所述电子地图包括坐标系各点的地理信息；

mq集群,其进一步包括域名解析dns和多个网络web服务器，

所述dns：分别连接所述多个web服务器，用以将收到在途车辆发送包括车辆实时在途信息在内的在途监控请求，从中解析出所述车辆标识信息和车辆当前所在位置信息，并将所述在途监控请求路由至对应web服务器的mq消息队列；

所述web服务器：用于按照所述mq消息队列处理机制处理到所述在途监控请求，根据所述车辆标识信息找到相适配的标准轨迹信息,并且根据所述车辆当前所在位置信息与标准轨迹信息的标准轨迹点比对，以确定所述车辆是否存在线路偏移。

另外，所述后台服务端还可以包括：多个关系型数据库mqsql,其至少包括：

映射表：用于存储车辆标识和web服务器的映射关系，当解析报文中找到所述车辆标识，并根据车辆标识查找所述映射表获知是哪一个web服务器来处理该车辆的监控请求；

标准轨迹存储表，用于存储有所述车辆标识预先规划的标准轨迹信息；

在线监控处理分表，用于存储所处理的车辆的在线采集到的数据及所在的监控状态信息。

一种计算机设备，包括存储器和处理器，所述存储器中存储有计算机可读指令，所述计算机可读指令被所述处理器执行时，使得所述处理器执行上述所述的对车辆进行在途监控方法。

一种存储有计算机可读指令的存储介质，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行上述所述的对车辆进行在途监控方法。

本发明由于采用以上技术方案，使其与现有技术相比具有以下的优点和积极效果：

首先，本发明的车辆采用的在途监控装置可以是现有的智能设备，也可以直接是gps加个sim，硬件成本很低甚至没有，特别是车辆以万为单位的时候整个在途监控在车辆端的改造成本是很低，且能实现监控的实时性。

另外，后台服务端考虑到车辆需要增设的硬件或软件存在增强新的成本的问题，或者车辆驾驶者的能力或水平参差不齐，容易造成监控出现纰漏的问题。本发明直接采用在途车辆定期发送在途监控请求报文，由后台服务端来处理。当一个物流公司当前进行物流运输的车辆有可以能是万为单位，本发明的后台服务端dns采用预先将设置车辆id和web服务器212映射关系的映射表311，接收到相应的报文，直接解析出车辆id后通过映射表查找到对应的web服务器进行处理，本后台服务端通过上述的设置可以并行处理多个在途监控进程，并且本实例又采用mq集群技术，具有负载均衡能力和高扩展性、高处理能力。比如，一个web服务器可以处理千台车辆的在途监控进程，若有十几个web服务器组成集群，即可完成本发明后台服务端的几万个在途监控进程，而不会产生性能下降，具有极强的处理能力。

附图说明

图1为在途监控系统的系统架构原理图；

图2为在途监控装置的一种实现原理图；

图3为本发明后台服务端的一种原理图；

图4为本发明数据库的一种原理框图；

图5为本发明在途监控流程实例图；

图6为本发明线路偏移判断的举例图。

具体实施方式

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对照附图说明本发明的具体实施方式。显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图，并获得其他的实施方式。

为使图面简洁，各图中只示意性地表示出了与本发明相关的部分，它们并不代表其作为产品的实际结构。另外，以使图面简洁便于理解，在有些图中具有相同结构或功能的部件，仅示意性地绘示了其中的一个，或仅标出了其中的一个。在本文中，“一个”不仅表示“仅此一个”，也可以表示“多于一个”的情形。

第一实施例

请参阅图1，本实例的系统架构包括后台服务端10、网络20和多台车辆30。车辆30一般设置有在途监控装置31。车辆30的数量是多辆，甚至是达到以万为单位的多台运输途中的车辆，本实例需要对如此庞大运输过程中的车辆进行在途监控，因此开发了本系统架构及相应监控流程。

在途监控装置31可以包括gps和sim卡。随着gps越来越多的加入到车辆行业中，慢慢地成为每个车辆中必不可少的组成部分，甚至成为某些行业中的标准配件，尤其要求gps具有更高的稳定性，能更好地对车辆进行远程定位监控、跟踪，车况数据采集，以及远程遥控操作等相关命令；同时sim卡是整个gps设备中最基本的通讯工具。比如，以下提供一种在途监控装置的制作方式实例：

首先，将sim卡固定在带有凹槽的夹具上，夹具上的凹槽的外形尺寸与sim卡的外形尺寸相匹配，凹槽的深度低于sim卡的厚度；

接着，将一镂空的钢网罩装在sim卡上，钢网镂空部分应将sim卡非焊接区域露出；

随后，向钢网的镂空区域印刷或喷涂阻焊漆，形成阻焊漆层；

然后，将sim卡除芯片部分以外的区域裁剪掉，得到sim小卡；

最后，将sim小卡与过渡板焊接相连，将焊接有sim小卡的过渡板与gps电路板焊接相连即完成sim卡在gps中的永久固定。这种制作方式可实现sim卡与gps电路板的永久性牢固连接，不会出现因接触不良而导致通讯故障的现象，有利于提高车辆管理水平。

在途监控装置也可以是车辆驾驶者的手机等智能设备(如图2所示)。智能设备本身带有sim卡和gps定位装置。在现有的智能设备上按装一具有在途监控软件，如app等。其至少包括以下模块：

位置管理器模块311，用于获得包括经纬度、海拔等在内的当前位置信息及获得当前位置所在的时间。比如：用手机android系统的gps调用功能，可以为手机app提供与位置相关的所有功能。创建一locationmanage(位置管理器)：对locationmanager对象进行引用，然后把手机系统提供的数据赋值给它。通过location可以获取当前时间和经纬度、海拔等在内的当前位置信息。

通信交互模块312：用于在途监控请求报文按照预先设定的时间周期发文至后台服务端10，在途监控请求报文可以包括当前位置信息、当前发送报文的时间和本段运输的行驶里程等。通信交互模块还可以接收后台服务端10返回的信息，比如线路偏移的报警信息、低速或超速等的提醒信息。另外，接收后台服务端10的信息还可以通过声音、指示灯进行提示。

上述提及的手机也可以pda(personaldigitalassistant，个人数字助理)、膝上型计算机、掌上电脑等等，也可以应用在未具备触摸屏幕的电子设备中，例如个人电脑等等，本发明实施例对此不加以限制。考虑到手机，主要是只需要增加一软件即可，无需要增设新的硬件，成本低，实现方便。特别是系统需要增设新的功能或开发新的应用，只需要在手机上更新一下对应的软件即可，更新快速且方便。

综上所述，本实例提供的在途监控装置，仅给出一种硬件和一种软件的实现方案，主要是考虑到本实例的应用场景是大规模车辆需要同时进行在途监控，需要兼顾其成本且传输方式的通用性及方便性。本发明的gps和sim卡也可以用其它的当前位置采集装置和通信模块来替换，并不是用于局限本实例。还有，在途监控装置同样也可以用现有的胎压监测装置、行车纪录仪等智能车载设备进行二次改造，使其具有获得车辆当前位置信息，并按预设周期发送在途监控请求等功能。

网络20可以在后台服务端10和各个在途车辆30之间提供通信链路的介质。网络20可以包括各种连接类型，例如有线、无线通信链路。用户可以打开或关闭在途监控装置以接收或发送相应数据，建立与后台服务端10的通信。

请参阅图3，其为后台服务端10的一种原理结构图。本实例的后台服务端10可以采用mq集群来构建。

先简单介绍一下mq集群(面向消息的中间件)，mq具有群集(cluster)的功能，这是ibmmq的特有优势之一。多个应用服务器之间的群集功能不仅使服务器之间能够共享负载，并且当某一系统或网络出现故障时，能够自动进行负载均衡；同时同一群集中的服务器可以位于不同的平台和物理位置。另外，群集功能使对服务器的管理更加简单高效。

就mq的点对点的通讯模式而言，系统需要创建相应的对象才能实现两个队列管理器之间的通讯，例如，在发送方队列管理器上，我们要创建一个远程队列(指向远程的目的队列)，一个传输队列和一个发送类型的通道；在接收方队列管理器上，我们要创建一个本地队列和一个接收类型的通道。这样，当我们要实现一个网络当中的n个队列管理器之间的两两双向通讯时，我们需要配置的mq对象的个数就会大大增长，比如，我们需要在每个发送方队列管理器上建立n个远程队列，n个传输队列以及n-1个发送类型的通道，这将组成一个复杂的网状结构。

而采用群集的技术之后，可以大大简化系统配置，原因在于位于同一个群集当中的若干队列管理器之间互相通讯时，不需要在每一个队列管理器上创建消息通道、远程队列管理器以及与通道相关的传输队列的定义，相反，系统只需要为在每一个队列器上创建如下两个群集通道(mq的通道分为三种类型，即服务器与服务器之间的消息通道，客户端与服务器之间的mqi通道，以及用于群集内部通讯的群集通道)：

一个群集接收(cluster-receiver)通道，用来从群集中其他队列管理器接收应用消息和有关群集配置更新的消息；

一个群集发送(cluster-sender)通道，用来向群集发送应用消息和有关群集配置更新的消息。

这样，大大减少了位于群基内部的队列管理器上的mq对象的总数，从而大大简化了系统的配置。

仓储库(repository)：仓储库是关于群集的信息集合，这些信息包括队列管理器的名字，它们的位置，它们所拥有的通道和队列等。这些信息存储在一个名为system.cluster.repository.queue中。仓储库又分为完全仓储库(fullrepository)和部分仓储库(partialrepository)。完全仓储库包含了群集中所有队列管理器的有关群集的全部信息。与之对应，群集中的其他队列管理器拥有与其自身相关和它将要与之通讯的那些队列管理器的信息，成为部分仓储库队列管理器。部分仓储库队列管理器通过查询完全仓储库而得到群集信息的更新，为此，它们通过system.cluster.command.queue队列向完全仓储库发送请求和接收信息。

仓储库队列管理器(ropositoryqueuemanager)：群集中拥有完全仓储库信息的队列管理器，一般情况下，系统在群集中选择两个队列管理器作为完全仓储库，互相形成备份。

群集队列(clusterqueue)：在群集中共享的队列。宿主队列管理器拥有对该队列的本地定义，被共享后，群集中的其他成员都可以看到这个队列，并且向其发送消息，而不需要定义远程队列。

群集传输队列(clustertransmissionqueue)：群集中的每个队列管理器都有一个名为system.cluster.transmit.queue的传输队列。

mq集群21具有增强系统的高可用性和可扩展性。在本实例中，mq集群进一步包括：

dns(域名解析)211：分别连接多个web服务器(网络服务器)212，用以将收到在途车辆发送包括车辆实时在途信息在内的在途监控请求，从中解析出车辆标识信息和车辆当前所在位置信息，并将在途监控请求路由至对应web服务器212的mq消息队列。

dns211接收到在途监控请求，比如接收到在途监控请求报文，从中解析出发送车辆的车辆id、车辆当前所在位置信息(经度、纬度、海拨等)、发送的时间点。dns211在本端存储有车辆在途监控与web服务器212之间的映射表311。映射表311中是车辆id和web服务器212的映射关系表。当解析的报名中有该车辆的id，根据该车辆id访问映射表311可获知是哪一个web服务器212来处理该车辆的监控请求。

简单来说，dns211主要实现以下功能：1、解析相应请求报文；2、路由至对应的web服务器来处理；3、当增加新的web服务器时更新对应的映射表。

web服务器212：用于按照mq消息队列处理机制处理到在途监控请求，根据车辆标识信息找到相适配的标准轨迹信息,并且根据所述车辆当前所在位置信息与标准轨迹信息的标准轨迹点比对，以确定所述车辆是否存在线路偏移。

一般来说，web服务器212对应有自身的队列管理器，用来存储本服务器端212需处理的mq消息，即存储有mq消息的队列。没有设置优先级的情况下，web服务器212可以按照先进先处理的原则处理mq消息队列中的在途监控请求。每一个在途监控请求可以设置不同的监控处理规则，比如仅判断是否存在线路偏差，或者判断线路偏差之外，还判断其是否存在超速或慢速等的问题，或者进一步判断其是否存在疲劳驾驶的可能。

web服务器212可以进一步包括：

标准轨迹查找模块：用于根据车辆标识信息找到相适配的标准轨迹信息。在本web服务器212端或者数据库端(如关系型数据库mqsql23)存储有标准轨迹存储表312。标准轨迹存储表312存储有该车辆id预先规划的标准轨迹信息，可以是关键轨迹点的地理位置信息，也可以是可显示的标准轨迹图的接口信息等。

比对模块：根据所述车辆当前所在位置信息与标准轨迹信息的标准轨迹点比对，以确定所述车辆是否存在线路偏移；

线路偏移处理模块：用于当存在线路偏移时，可以进行线路偏移处理流程。比如，通过拨打该车辆id对应的手机号码，语音告知其存在线路偏移的情况，或者让客服人员直接联系该车辆id对应的驾驶员等。在线路偏移处理模块在处理线路偏移判断时，可以先当前解析出来的数据存储在在途监控处理分表313中。在线监控处理分表313可以存储在本端的web服务器212，也可以设置在数据库中，在线监控处理分表313用于存储所有处理的车辆的所有的在线采集到的数据(如当前地理位置信息、采集的时间点、速度等)及所在的监控状态(如线路是否偏移的报警状态、是否存在超速等)。在本实例中，在线监控处理分表313可以存储一千台车的在线监控状态和实时采集数据，其一般存储在数据库(如关系型数据库mqsql)中，多个web服务器212对应处理的在线监控处理分表313分别存储在多个数据库中或一个数据库。

电子地图构建模块22，用于预先构建电子地图，所述电子地图包括坐标系各点的地理信息。

电子地图构建模块22，一般是指电子地图的存储、展示、处理等模块。数字地图，可以指利用计算机技术、以数字方式存储和查阅的地图，一般利用地理信息系统gis来储存和传送地图数据，但也可以采用其他的信息系统储存和传送地图数据，本发明实施例对此不加以限制。

电子地图一般使用向量式图像储存地图数据，地图比例可放大、缩小或旋转而不影响显示效果。电子地图在绘制时可以以多个图层来构成相配合的，电子地图的图层可以包括基础地理信息(比如河流、山川、平原等等)、城市基础设施建筑及道路规划信息、poi(pointofinterest，兴趣点)标注信息等等。

应用本发明实施例，在电子地图构建模块22中启动电子地图后，可以在电子地图已有的道路(例如公路、铁路、河堤等等)上进行划线，例如可以电子地图上的“京密路”进行画线操作，获得划线(规划路径)，请求查询该划线旁边的业务对象。具体地，可以接受线路规划者主观在触摸屏幕等上进行触控操作以在电子地图上进行规划路径的画线操作，也可以通过鼠标在电子地图上进行画线操作。电子地图构建模块22也可以按照预先设定的算法自动的从出发地到目的地规划出路径来。电子地图构建模块22可以是服务器，也可以是其它电子设备。在本实例中，电子地图构建模块22是单独出来的设备，也可以集成是其中一web服务器中实现。

本实例还包括关系型数据库mqsql23。mqsql23可以采用主节点数据库和从节点数据库等结构方式，进行主从备份。本实例还可以包括多个并行的数据库mqsql23，用于存储所有的在线监控数据及其监控结果数据。从数据库的角度来说，本实例的数据库至少包括以下存储单元(如图4所示)：

映射表311：其用于存储车辆id和web服务器212的映射关系表。当解析的报文中有该车辆的id，根据该车辆id访问映射表311可获知是哪一个web服务器212来处理该车辆的监控请求。

标准轨迹存储表312，用于存储有该车辆id预先规划的标准轨迹信息，可以是关键轨迹点的地理位置信息，也可以是可显示的标准轨迹图的接口信息等，也可以是相应的图层信息等，标准轨迹存储表312可以和电子地图构建模块22集成在一起，也可以单独设置。

在线监控处理分表313用于存储所有处理的车辆的所有的在线采集到的数据(如当前地理位置信息、采集的时间点、速度等)及所在的监控状态(如线路是否偏移的报警状态、是否存在超速等)。

从上可知，本实例具有以下的优点：

首先，本发明采用的mq集群来处理车辆在途监控，web服务器会通过缓存服务来提高部分静态数据的访问速度.提高效率的同时也可以降低服务器的压力，提供更高的可用性。负载均衡：系统需要承担所有的监控请求以及各项操作的压力，所以采用负载均衡的方式，对系统进行分流操作，不同的车辆在提出监控请求的时候，进入到不同的web服务器中，做不同的操作。保证了各台服务器的压力均衡。同时负载均衡提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。当出现大量车辆提出请求时候产生大流量的时候，自由的增加服务器，进行横向扩展。是系统更加的高效而稳定。当流量下降的时候，减少服务器，降低服务器的使用成本，节约资源。

还有，本系统负载均衡的使用，也避免了单点故障的问题。使用时间越久，服务器出现问题的几率越大。从而出现宕机的情况，系统无法被使用。而采用了负载的策略之后。当其中一台服务器出现宕机的时候，其他的服务器还可以继续运行，系统不会出现无法使用的情况。这一点在很多重要的系统上都会进行使用。

再次，电子地图构建模块22指电子地图的存储、展示、处理等模块。当增加新的运输航线时，只需要将更新电子地图构建模块22中相应的电子地图内容即可，存在很好的扩展性。

第二实施例

请参阅图5，本发明提供了一种对车辆进行在途监控的方法的流程图。它包括以下步骤：

s110:后台服务端预先加载电子地图，所述电子地图包括坐标系各点的地理位置信息；

s120:后台服务端接收预行驶车辆从起始地到目标地的运行路径规划，并且映射至所述电子地图上从起始地到目标地的标准轨迹；

s130:后台服务端接收到在途车辆发送的包括车辆实时在途信息在内的在途监控请求报文，从中解析出车辆标识信息和车辆当前所在位置信息，并将解析出来的数据发送至后台服务端的mq集群；

s140：mq集群中对应的web服务器根据所述车辆标识信息找到相适配的标准轨迹信息；

s150:将车辆当前所在位置信息与标准轨迹信息的标准轨迹点进行比对，以确定所述车辆是否存在线路偏移。

以下具体介绍各个步骤。

一、步骤s110

一般利用地理信息系统gis来储存和传送地图数据，但也可以采用其他的信息系统储存和传送地图数据，本发明实施例对此不加以限制。电子地图一般使用向量式图像储存地图数据，地图比例可放大、缩小或旋转而不影响显示效果。电子地图在绘制时可以以多个图层来构成相配合的，电子地图的图层可以包括基础地理信息(比如河流、山川、平原等等)、城市基础设施建筑及道路规划信息、poi(pointofinterest，兴趣点)标注信息等等。

比如，后台服务端预先加载地理信息系统gis，该gis中设置坐标系，坐标系中单元点的信息。比如，是以50米为基本单位构建电子地图。在本实例中，也可以增加一新的图层，该图层中道路规划是以比如以50米为单位的poi兴趣点做为坐标系中的坐标点。

电子地图包括坐标系各点的地理位置信息，一般来说包括该点的地理位置信息，包括该点的经度、纬度，也可以包括该点的经度、纬度和海拨。为了降低其存储的数据量，在本实例中，只需要保存道路上坐标系各点(如上述提及的poi兴趣点)的地理位置信息。还有，当所在poi兴趣点的地理位置是在同一海拨或在预先设定海拨范围内，只需要保存该点的经度和纬度信息。只有在海拨超过预先设定的阈值时或者有类似有盘山公路时，才记录有该点的经度、纬度和海拨，通过上述的方法设定，可以提升其存储数据的有效性且占用相应较小的存储空间，提升资源的利用率。

当增加新的运输航线，比如增加印度的运输航线，则只需要更新电子地图，把增设的地图部分和增设新poi兴趣点的图层作替换，具有极强的扩展性。

二、步骤s120:后台服务端接收预行驶车辆从起始地到目标地的运行路径规划，并且映射至所述电子地图上从所述起始地到所述目标地的标准轨迹。

当某一车队加入该物流运输时，后台服务端先自动规划该车队中每一车辆的运行路径或接收人工规划该车队的运行路径请求。当该地图上增设新的图层时，接收人工输入的电子地图已有的道路(例如公路、铁路、河堤等等)上的划线，例如可以电子地图上的“京密路”进行画线操作，获得划线(规划路径)，请求查询该划线旁边的业务对象。具体地，可以接受线路规划者主观在触摸屏幕等上进行触控操作以在电子地图上进行规划路径的画线操作，也可以通过鼠标在电子地图上进行画线操作。电子地图构建模块也可以按照预先设定的算法自动的从出发地到目的地规划出路径来。

本实例可以采用以下实施方案来实现：

s21:后台服务端设置车辆的起始地、目标地和经过规划的运行路径，并在运行路径中确定包括高速入口地、出口地在内的关键地点；

s22:电子地图设置从起始地到目标地，以及途径该些关键地点的标准轨迹，并将标准轨迹按照预先设定的网格坐标系，获得网格上的标准轨迹点(如上述提及poi兴趣点)的坐标信息，坐标信息包括其经度、纬度在内的地理信息。

本实例中，主要的目的在于将规划路径映射至电子地图上从起始地到目标地的标准轨迹点的集合，可以在电子地图上进行显示，也可以仅在标准轨迹存储表312进行存储。标准轨迹通常是行驶道路上以基本单位(如50米)为单位标准轨迹点的集合。坐标信息主要是该标准轨迹点所在的地理位置信息，包括经度、纬度，也可以包括经度、纬度和海拨等的该点当前所在的地理位置信息。

当然，本实例也仅是具体的一实例，上述的实现方案有非常多种，本实例仅是举例之用，并非用来局限于本发明。

三、具体步骤s130

后台服务端的dns接收到在途车辆发送的包括车辆实时在途信息在内的在途监控请求报文，从中解析出所述车辆标识信息和车辆当前所在位置信息，并将解析出来的数据发送至所述后台服务端的mq集群。

在途车辆可以以分种为周期实时发送在途监控请求报文，也可以事件触发式发送在途监控请求报文。发送的时机在在途车辆的硬件上或软件内预先设置。比如，在途车辆以五分钟为周期上报在途监控请求报文，该在途监控请求报文包括在途车辆id、发送当前的时刻、发送当前的时速、发送当前与出发点相比的距离等。在途车辆在发生特殊的触发事件，如时速低于预设值时也可以发送在途监控请求报文。

以双11等特殊时期，一个物流公司可能会涉及几万台车辆需要进行在途监控，若每一台车都向后台服务端发送在途监控请求报文，整个后台服务端的处理量非常大，容易造成整个处理性能下降的问题。为此，还可以在在途车辆预先进行初步判断程序。比如，将在途车辆本次的物流运输的规划路径先下载至本端，预先在本端进行比对，若对比后存在与预定规划路径有偏差，则再后台服务端的dns发送在途监控请求报文。

以上仅是一个小实例，但是在本发明中，后台服务端考虑到车辆需要增设的硬件或软件存在增强新的成本的问题，或者车辆驾驶者的能力或水平参差不齐，容易造成监控出现纰漏的问题。本发明直接采用在途车辆定期发送在途监控请求报文，由后台服务端来处理。当一个物流公司当前进行物流运输的车辆有可以能是万为单位，本发明的后台服务端dns采用预先将设置车辆id和web服务器212映射关系的映射表311，接收到相应的报文，直接解析出车辆id后通过映射表311查找到对应的web服务器212进行处理，本后台服务端通过上述的设置可以并行处理多个在途监控进程，并且本实例又采用mq集群技术，具有负载均衡能力和高扩展性、高处理能力。比如，一个web服务器可以处理千台车辆的在途监控进程，若有十几个web服务器组成集群，即可完成本发明后台服务端的几万个在途监控进程，而不会产生性能下降。

在途监控请求报文通常预先设定报文的格式，比如哪几位表明的车辆id。哪几位表明的经度和纬度信息，哪几位是发送当前的时间信息、哪几位是路程信息等。考虑到报文传输的数据量，本发明还可以采用差值进行传输。比如，发送当前时刻以上一次发送时刻的间隔值，或者每次不发送当前的时间信息，默认为以5分钟为间隔进行发送，则将上一次发送的时刻直接加5分钟即可等。再比如路程信息字段也仅发送与上一次路程的差值。通过该些处理，可以降低整个字段传输的数据。

当后台服务端的dns通过映射表找到对应的web服务器后，将该解析后的数据发送至对应的web服务器。一般来说，每个web服务器有一个处理该请求的在途监控进程队列，直接将解析出来的进程放置于该在途监控进程队列。该在途监控进程队列处理的规则是先进先出的处理规则，当然，本实例还可以设置一些特殊的在途监控进程。比如，当接收到的在途监控进程是事件触发式后发送的。比如，发送的间隔时间超出预先设定的阈值，当所驶速度已高于预设阈值或低于预设某一阈值后发送的紧急处理的在途监控请求报文，则后台服务端接收并解析出该报文后，可以启动或触发特殊的在途监控进程处理，比如，将该在途监控请求报文直接发送至对应的web服务器，并且将该报文处理为优先处理程序进行处理。

四、步骤s140。mq集群中对应的web服务器根据车辆标识信息找到相适配的标准轨迹信息。

之前我们介绍过mq集群根据映射表可以将该车辆在途监控请求报文发送至对应的web服务器，一般会先发至处理在途监控请求的mq消息队列，由于web服务器整个响应速度有可能达到毫秒级，在以分为单位的处理周期，web服务器可以处理上百个，甚至上千个的在途监控请求。因此，web服务器一般将mq消息队列中的在途监控请求按照先进先出的原因进行处理，当接受到某一优先级高的在途监控请求，也可以按照优先级处理请求报文的原则预先进行处理。并且，web服务器可以通过车辆标识找到该车辆当前预先设定的标准轨迹信息。当然，当该车辆标识下设定的标准轨迹信息可以有多条，但是本次默认的标准轨迹仅有一条。具体来说，其包括以下步骤：

s41:mq集群预先建立处理车辆在途监控与web服务器之间的映射表，所述映射表保存车辆标识信息与处理车辆在途监控的web服务器之间的对应关系；

s42:mq集群按照车辆标识信息查找所述映射表，找到对应的web服务器，将解析出来的在途监控请求发送至所述web服务器对应的mq消息队列，以便多个所述web服务器两并行处理所述在途监控请求；

s43:当web服务器按照mq消息队列处理机制处理所述在途监控请求时，通过车辆标识信息分别查找预先存储的在途监控处理分表和标准轨迹存储表，找到车辆之前的在途监控记录和标准轨迹信息，以完成在途监控。

步骤s43中，标准轨迹存储表不仅局限于表的表现形式，可以是队列或其它缓存存储单元的形式进行存储。本实例仅要说明的是通过车辆id找到当前默认的车辆当前标准轨迹信息。该标准轨迹信息可以是标准轨迹点所在的地理位置信息。在途监控处理分表可以将该车辆所有的本次在途监控采集的数据(采集点的时间、地理信息等)和在途监控的判断结果(如是否偏移路线等)。因此，当找到在途监控处理分表就可以获得之前所有的数据记录和监控结果记录。另外，考虑到分表的存储量，本实例中采用以千为单位的车辆数据通常一并存储于该分表，或者将该web服务器处理的所有车辆id对应的数据记录和监控结果记录一并保存在该分表中。

五、步骤s150

步骤s150的一种实现方案为：

s51:从车辆当前所在位置信息中找到包括经度和纬度信息在内的行驶地的地理信息；

s52:根据行驶地的地理信息，从电子地图的标准轨迹信息中找到与所述车辆当前所在位置距离最近的标准轨迹点作为监控点，如果监控点与所述车辆当前所在位置信息的距离小于报警阈值，则更新报警状态为“线路不偏移”；否则进行步骤s53；

s53:以监控点为中心，从电子地图的规划路线上分别取左参考点和右参考点，左参考点和右参考点构成一条直线，计算车辆当前所在位置到该直线的距离，求出其中的最小距离作为偏移距离，并将本次报警状态更新为“线路偏移”。

s54:将所驶地的地理信息显示在电子地图上，并将所述本次行驶地的地理信息与上一次的行驶地地理信息进行连接显示，形成本次的当前行驶路径图；

s55:当本次报警状态为“线路偏移”时，进一步判断上一次车辆的报警状态是否也是“线路偏移”的状态，如果是，则记录所述报警状态为“线路偏移”的持续时长；

s56:若所述持续时长达到阈值，则启动线路偏移的报警机制。

请参阅图6，首先举个例子来说明步骤s51-53，假设a、b是起始地和目标地。a-b的线路为规划线路，为了说明方便，该规划线路为直线，但不并局限于直线。c为车辆当前所在位置，即采集到的车辆行驶所在地点。从标准轨迹点中找到离c最近的标准轨迹点d(即与c之间的距离最短)则计算出该cd的距离是否小于一预先设定的值，若是则说明其还是在规划线路上，预先设定的值可以是几十米。当cd的距离大于预先设定的值，则以监控点d为中心从电子地图的规划线路ab上找到最近的两点，分别取左参考点e和右参考点f,左参考点e和右参考点f构成一条直线，计算车辆当前所在位置c到该直线ef的距离,若还是小于预先设定的值，则认定为没有位置偏移。若ef已经是一条直线，则直接计算该c到该直接的垂直距离是否小于预先设定的值，若是，则认为为线路偏移。在本实例中，考虑到其全面性，可以用多种方式来验证其是否存在线路偏移。比如，将所驶地的地理信息显示在电子地图上，并将所述本次行驶地的地理信息与上一次的行驶地地理信息进行连接显示，形成本次的当前行驶路径图。通过人工查看该行驶路径图，进一步验证是否偏移。再比如，计算其线路偏移的时长，若超过预设时长，同样也可以认为为线路偏移。

线路偏移的报警机制可以是通过人工电话通知车辆的驾驶者，也可以短信或语音等通知，和驾驶者进一步了解情况，比如碰到堵车等特殊情况，也可以让系统手动接受在线监控线路偏移的合规性等。

除了线路偏移的在途监控之外，本发明还可以包括低速报警等在途监控。比如，后台服务端接收到在途监控请求中还携带所述车辆的运行里程和发出请求的时间点；web服务器通过发出请求的时间点和开始行驶的时间点来计算当前行驶所用时长，通过所述运行里程和所述当前行驶所用时长计算当前的行驶速度，当所述行驶速度低于预先设定值，则判定所述在途行驶为低速状态，当低速度状态持续时长超过预先设定阈值后，则进行低速报警操作。

本发明同样也可以启动超速报警等在途监控，机制是同样的，不再详细说明。当车辆端可以采集到驾驶员的驾驶行为时，本发明的在途监控还可以根据采集到的当前驾驶行为数据进一步判断是否存在疲劳驾驶，以上种种都在本发明的扩展方案内。

本发明提出了一种存储有计算机可读指令的存储介质，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行如上述第一实施例中所提及的在途监控的步骤。

对于上述实施例，本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器(rom，readonlymemory)、随机存取存储器(ram，randomaccessmemory)、磁盘或光盘等。

以上所述实施例仅表达了本发明一些示例性实施例，其描述较为具体和详细，但并不能因此而理解为对本发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。