基于NB-IoT技术的驻停车辆碰撞报警方法
技术领域
本发明属于驻车报警技术领域,尤其涉及一种基于NB-IoT技术的驻停车辆碰撞报警方法。
背景技术
现有技术中,车辆由其他车辆、坠物、异物撞击等碰撞后,注册报警***采集到碰撞数据后判断碰撞数据是否大于阈值,大于阈值则向车主发出示警。但是现有技术中存在如下问题:现有3G、4G等数据通信方式成本较高,带宽资源占用大、待机时间短。除此之外,现有判断过程简单,误报率及漏报率高。
发明内容
为解决上述技术问题,本发明提供一种基于NB-IoT技术的驻停车辆碰撞报警方法。为了对披露的实施例的一些方面有一个基本的理解,下面给出了简单的概括。该概括部分不是泛泛评述,也不是要确定关键/重要组成元素或描绘这些实施例的保护范围。其唯一目的是用简单的形式呈现一些概念,以此作为后面的详细说明的序言。
本发明采用如下技术方案:
在一些可选的实施例中,提供一种基于NB-IoT技术的驻停车辆碰撞报警方法,包括:建立模型算法;
所述建立模型算法的过程包括:
为各个车型建立独立的接触性碰撞数据库,单个车型数据字段包括:车型ID、损坏位置、损坏程度;
为各个车型建立独立的环境因素数据库;
建立经验算法数据库,数据采集方法为获取用户通过移动智能终端针对单次误报上传的错误记录。
在一些可选的实施例中,建立各个车型的独立接触性碰撞数据库时,模拟数据的采集过程包括:通过放置在车辆内部的振动数据采集器采集数据,在车辆的各个划分区域进行模拟碰撞测试,以损坏车漆的振幅为样本采集标准,针对损坏程度标定出等级。
在一些可选的实施例中,建立各个车型的环境因素数据库时,模拟数据的采集过程包括:通过放置在车辆内部的振动数据采集器采集环境因素对车辆造成损伤的振幅数据;所述环境因素包括:刮风、下雨、噪音、地震、大型物体经过。
在一些可选的实施例中,车辆的划分区域为七个,分别为车辆的左前、右前、左中、右中、左后、右后和顶部。
在一些可选的实施例中,所述的基于NB-IoT技术的驻停车辆碰撞报警方法,还包括:
车载数据采集终端通过复合传感器采集碰撞振幅数据,并判断碰撞事件的真伪;
当所述车载数据采集终端判定碰撞事件有效时,将报警信息上传至客户管理服务器集群;
所述客户管理服务器集群根据所述报警信息中的设备ID自动匹配当前车辆的车型ID及绑定的智能移动终端,并将所述碰撞振幅数据及车型ID发送至云计算服务器;
所述云计算服务器通过模型算法进行数据真伪判断,并将所述碰撞振幅数据通过所述模型算法进行比对以获得碰撞的位置、类型及程度;
当所述云计算服务器判定数据真实时,将所述报警信息以及碰撞的位置、类型及程度通过所述客户管理服务器集群下发至与所述设备ID绑定的移动智能终端。
在一些可选的实施例中,所述车载数据采集终端判断碰撞事件的真伪的过程包括:若车辆处于运动状态或车辆内部有人或宠物时,则判定碰撞事件无效。
在一些可选的实施例中,所述报警信息包括:碰撞振幅数据、设备ID、车辆位置坐标、碰撞发生时间。
在一些可选的实施例中,所述的基于NB-IoT技术的驻停车辆碰撞报警方法,还包括:所述移动智能终端将所述报警信息中的车辆位置坐标与本端当前位置坐标进行比对,判断是否重合,若不重合,则显示所述报警信息,以及碰撞的位置、类型及程度。
本发明所带来的有益效果:预先建立模型数据库,分析对比碰撞振幅数据,从而获取碰撞的位置、类型及程度,通过云计算服务器判断数据真伪,从而降低误报及漏报等问题。
为了上述以及相关的目的,一个或多个实施例包括后面将详细说明并在权利要求中特别指出的特征。下面的说明以及附图详细说明某些示例性方面,并且其指示的仅仅是各个实施例的原则可以利用的各种方式中的一些方式。其它的益处和新颖性特征将随着下面的详细说明结合附图考虑而变得明显,所公开的实施例是要包括所有这些方面以及它们的等同。
附图说明
图1是本发明基于NB-IoT技术的驻停车辆碰撞报警方法的原理图;
图2是本发明基于NB-IoT技术的驻停车辆碰撞报警方法的流程示意图;
图3是本发明模型算法示意图。
具体实施方式
以下描述和附图充分地示出本发明的具体实施方案,以使本领域的技术人员能够实践它们。其他实施方案可以包括结构的、逻辑的、电气的、过程的以及其他的改变。实施例仅代表可能的变化。除非明确要求,否则单独的部件和功能是可选的,并且操作的顺序可以变化。一些实施方案的部分和特征可以被包括在或替换其他实施方案的部分和特征。本发明的实施方案的范围包括权利要求书的整个范围,以及权利要求书的所有可获得的等同物。
如图1和2所示,在一些说明性的实施例中,提供一种基于NB-IoT技术的驻停车辆碰撞报警方法,包括:
101:车载数据采集终端感应到车辆被碰撞,车载数据采集终端通过复合传感器采集碰撞振幅数据。
复合传感器包括但不限于声、震动、红外、微波等多种传感器组合方式。具体的,复合传感器可包括:G-sensor、红外线探测器、麦克风、GPS模块等。
G-sensor:通过在车辆不同位置上进行的大量碰撞测试,将G-sensor的灵敏度调整至合理的范围,用以收集碰撞所产生振幅的强弱、碰撞位置等数据。
红外线探测器及麦克风:用以探测车内是否有人或宠物。
GPS模块:用以获取车辆位置数据。
102:当车载数据采集终端感应到车辆被碰撞后,车载数据采集终端通过复合传感器采集的数据,初步判断碰撞事件的真伪。判断过程由车载数据采集终端的MCU完成,以判断数据的真实性。
初步判断碰撞事件的真伪的具体过程包括:
若车辆处于运动状态或车辆内部有人或宠物时,则判定碰撞事件无效,即碰撞事件不是真实的。
由于车辆在静止状态下,且车内没有人或宠物时,此时若发生碰撞,则不是由于车主的操作造成的,即可判定碰撞事件有效。若车辆处于运动状态或车辆内部有人或宠物时,此时若发生碰撞,则为车主的操作造成碰撞,即可判定碰撞事件无效。初步的判断,可以滤除一部分误报警,减少分析资源的占用,而且使得流程更加准确、优化。
103:车载数据采集终端将报警信息上传至客户管理服务器集群。
报警信息包括:碰撞振幅数据、设备ID、车辆位置坐标、碰撞发生时间。
车载数据采集终端调用NB-IoT通讯模组,通过窄带物联网通讯技术将所述报警信息上传至客户管理服务器集群。利用新兴的NB-IoT通讯技术,取代现有采用2\3\4G乃至后续的5G移动通讯方式,具有低功耗、高效、带宽资源占用少、使用成本低,同时还能提供非常全面的室内蜂窝数据连接覆盖等诸多优势。
104:客户管理服务器集群根据报警信息中的设备ID自动匹配当前车辆的车型ID及绑定的智能移动终端,具体的,可以匹配智能移动终端上的APP。
客户管理服务器集群并将碰撞振幅数据及车型ID发送至云计算服务器。依据不同车型进行区别性的分析计算,使得计算结果更加准确。
105:云计算服务器通过模型算法进行数据真伪判断,若判定数据有效,则进行步骤106,若判定数据无效,则结束流程。云计算服务器将碰撞振幅数据通过模型算法进行比对,如发现上传的碰撞振幅数据与模型中的振幅数据符合,则判定数据有效,即数据时真实的。
106:云计算服务器将碰撞振幅数据通过模型算法进行比对以获得碰撞的位置、类型及程度。云计算服务器将碰撞振幅数据通过模型算法与预先建立的算法模型数据库中的数据进行比对,当符合时,即可对应的辨别出碰撞的位置、类型及程度。
107:当云计算服务器判定数据真实时,将报警信息以及碰撞的位置、类型及程度通过客户管理服务器集群下发至与设备ID绑定的移动智能终端。具体的,可以将报警信息以及碰撞的位置、类型及程度通过客户管理服务器集群下发至与设备ID绑定的APP上,APP安装于移动智能终端上。
移动智能终端为手机、平板电脑、计算机中的一种或几种。
108:当移动智能终端接收到报警信息后,将报警信息中的车辆位置坐标与本端当前位置坐标进行比对,判断是否重合,若不重合,则进行步骤109;若重合,则判定本次碰撞是车主本人动车所至,则忽略本次报警信息。
109:移动智能终端显示报警信息,以及碰撞的位置、类型及程度。具体的,可以通过安装于移动智能终端上的APP弹出报警信息,并显示碰撞的位置、类型及程度。
本发明还包括:建立模型算法。
建立模型算法的过程包括:
S1:为各个车型建立独立的接触性碰撞数据库,并对数据进行更新维护。
单个车型数据字段包括:车型ID、损坏位置、损坏程度。
模拟数据的采集过程包括:通过放置在车辆内部的振动数据采集器采集数据,在车辆的各个划分区域进行模拟碰撞测试,以损坏车漆的振幅为样本采集标准,针对损坏程度标定出等级。可实时的根据测试更新接触性碰撞数据库内的数据,即对数据进行维护,保证算法的准确性。
车辆的划分区域为七个,分别为车辆的左前、右前、左中、右中、左后、右后和顶部。
S2:为各个车型建立独立的环境因素数据库,即为各个车型建立独立的非接触性碰撞数据库,并不断加以完善。
模拟数据的采集过程包括:将车辆至于实际环境中,通过放置在车辆内部的振动数据采集器采集环境因素对车辆造成损伤的振幅数据。
环境因素包括:刮风、下雨、噪音、地震、大型物体经过,如车辆。
S3:建立经验算法数据库。数据采集方法为,获取用户通过移动智能终端针对单次误报上传的错误记录,用以不断完善模型算法。具体的,可以通过移动智能终端上的APP上传数据,以完善模型算法。
如图3所示,云计算服务器将碰撞振幅数据通过模型算法进行比对以获得碰撞的位置、类型及程度的过程为,首先输入碰撞振幅数据及车型ID,依据车型ID,搜索到适应的算法模型数据库;判断碰撞振幅数据是否与环境因素数据库中的数据符合,若符合,则碰撞是由环境因素造成的,忽略本次碰撞振幅数据,若不符合,则判断碰撞振幅数据是否与接触性碰撞数据库中的数据符合,若符合,则输出报警确认数据,则通过客户管理服务器集群下发报警信息、以及碰撞的位置、类型及程度。
本领域技术人员还应当理解,结合本文的实施例描述的各种说明性的逻辑框、模块、电路和算法步骤均可以实现成电子硬件、计算机软件或其组合。为了清楚地说明硬件和软件之间的可交换性,上面对各种说明性的部件、框、模块、电路和步骤均围绕其功能进行了一般地描述。至于这种功能是实现成硬件还是实现成软件,取决于特定的应用和对整个***所施加的设计约束条件。熟练的技术人员可以针对每个特定应用,以变通的方式实现所描述的功能,但是,这种实现决策不应解释为背离本公开的保护范围。