掌桥专利:专业的专利平台
掌桥专利
首页

数据处理方法、装置及存储介质

文献发布时间:2024-04-18 19:54:45


数据处理方法、装置及存储介质

技术领域

本申请实施例涉及计算机技术领域,具体涉及数据处理方法、装置及存储介质。

背景技术

随着科学技术的不断发展,生活水平的不断提高,机动车在人们日常生活中越来越常见,相应地,道路交通安全也越来越成为人们关注的焦点。

交通事故发生后,一般由调度中心的工作人员协调交通事故发生地所在辖区内的交警等事故处理人员进行事故处理。辖区内资源有限,并且,在很多事故场景中常常需要多次调配资源进行救援,处理事故的效率低。特别是在人烟稀少的山区或郊外,事故处理人员前往事故现场耗时较长。

发明内容

本申请的一个目的在于提供一种数据处理方法、装置及存储介质,其优势在于在事故发生后,基于获取的事故数据来判断事故等级,然后基于事故等级确定警力配置信息,提高了事故处理的效率,进一步地,提高了恢复道路通畅的效率。

本申请的另一个目的在于提供一种数据处理方法、装置及存储介质,其优势在于能够获取多个来源的事故数据,综合判断事故等级,使得数据处理装置获取的数据更加全面,提高数据处理装置判断出事故等级的概率。

本申请的另一个目的在于提供一种数据处理方法、装置及存储介质,其优势在于能够结合事故类型来确定事故等级,应对不同的交通事故处理场景。

本申请的另一个目的在于提供一种数据处理方法、装置及存储介质,其优势在于能够根据事故等级来配置不同的警力资源,提高警力资源的利用率,充分发挥不同警力资源的优势。

本申请的另一个目的在于提供一种数据处理方法、装置及存储介质,其优势在于能够根据统一的事故等级规则来配置警力资源,确保警力资源配置的一致性和合理性。

本申请的另一个目的在于提供一种数据处理方法、装置及存储介质,其优势在于能够根据事故数据来配置人力的警力资源和非人力的警力资源,提高警力资源配置的合理性和交通事故处理的效率。

本申请的另一个目的在于提供一种数据处理方法、装置及存储介质,其优势在于采集的事故数据包括生命体征数据,在警力配置中根据生命体征数据加入医护人员进行救援,从而提高保障用户的生命安全的概率。

为实现上述目的,第一方面,本申请实施例提供了一种数据处理方法,所述方法包括:响应于检测到事故发生,获取第一事故数据;基于所述第一事故数据,判断事故等级;以及在确定出所述事故等级的情况下,获取基于所述事故等级确定的警力配置信息。

本申请实施例中,数据处理装置在检测到事故发生后,获取第一事故数据;然后根据第一事故数据判断事故等级,在确定出事故等级后获取基于该事故等级确定的警力配置信息。由于先基于第一事故数据进行事故等级判断,且警力配置信息是根据事故等级得到的,使得警力资源配置更加合理,提高事故处理的效率。

在一种可能的实现方式中,所述在确定出所述事故等级的情况下,获取基于所述事故等级确定的警力配置信息之前,还包括以下步骤:

在不能确定出所述事故等级的情况下,基于所述第一事故数据获取第二事故数据;以及

基于所述第一事故数据和所述第二事故数据,重新判断所述事故等级。

所述方法在基于第一事故数据无法确定出事故等级的情况下,进一步获取第二事故数据,然后综合第一事故数据和第二事故数据来判断事故等级,提高数据处理装置判断出事故等级的概率。

在一种可能的实现方式中,所述第一事故数据由第一终端设备采集,所述第二事故数据由至少一个第二终端设备采集。

所述方法中,采集第一事故数据和第二事故数据的设备为不同的终端设备,通过获取多个来源的事故数据,综合判断事故等级,使得数据处理装置获取的数据更加全面,提高数据处理装置判断出事故等级的概率。

在一种可能的实现方式中,所述判断事故等级包括以下步骤:

根据所述第一事故数据和/或所述第二事故数据确定事故类型;

基于所述事故类型,从预设事故等级规则集合中确定与所述事故类型对应的预设事故等级规则;以及

根据所述预设事故等级规则判断所述事故等级。

本申请实施例中,该事故类型可以是机动车与机动车之间的事故、机动车与非机动车之间的事故、机动车与人之间的事故等,所述方法通过结合事故类型来确定事故等级,从而应对不同的事故场景。

在一种可能的实现方式中,所述警力配置信息指示无人机、机器狗、交警人员中的至少一项。

本申请实施例中,根据事故数据来配置人力的警力资源和非人力的警力资源,提高警力配置的合理性,事故处理的效率。

在一种可能的实现方式中,所述预设事故等级规则集合具有统一配置的标识号。

本申请实施例中,根据统一的事故等级规则来配置警力资源,确保警力配置的一致性和合理性。

在一种可能的实现方式中,所述第一事故数据还包括生命体征数据;所述警力配置信息指示无人机、机器狗、交警人员以及医护人员中的至少一项。

本申请实施例中,生命体征数据可以包括血压数据、心率数据、脉搏数据、呼吸数据以及血氧数据中的至少一项。本申请实施例中,采集的第一事故数据包括生命体征数据,在警力配置中根据生命体征数据加入医护人员进行救援,从而提高保障用户的生命安全的概率。

第二方面,本申请实施例提供了一种数据处理装置,包括:通信组件、至少一个传感器以及与所述通信组件和所述至少一个传感器可通信地连接的至少一个处理器;其中,

所述至少一个传感器,其被配置为检测事故的发生;

所述通信组件,其被配置为响应于检测到事故发生,获取第一事故数据;

所述至少一个处理器,其被配置为:基于所述第一事故数据,判断事故等级;以及在确定出事故等级的情况下,获取基于所述事故等级确定的警力配置信息。

在一种可能的实现方式中,所述通信组件,其进一步被配置为在不能确定事故等级的情况下,基于所述第一事故数据获取第二事故数据;

所述至少一个处理器,其进一步被配置为基于所述第一事故数据和所述第二事故数据,重新判断所述事故等级。

在一种可能的实现方式中,所述至少一个处理器,其进一步被配置为:根据所述第一事故数据和/或所述第二事故数据确定事故类型;

所述至少一个处理器,其进一步被配置为:基于所述事故类型,从预设事故等级规则集合中确定与所述事故类型对应的预设事故等级规则;以及

根据所述预设事故等级规则判断所述事故等级。

在一种可能的实现方式中,所述警力配置信息指示无人机、机器狗、交警人员中的至少一项。

在一种可能的实现方式中,所述预设事故等级规则集合具有统一配置的标识号。

在一种可能的实现方式中,所述至少一个处理器,其进一步被配置为:根据所述第一事故数据和/或所述第二事故数据确定事故类型;

基于所述事故类型,从预设事故等级规则集合中确定与所述事故类型对应的预设事故等级规则;以及根据所述预设事故等级规则判断所述事故等级。

在一种可能的实现方式中,所述第一事故数据由第一终端设备采集,所述第二事故数据由至少一个第二终端设备采集。

在一种可能的实现方式中,所述第一事故数据还包括生命体征数据;所述警力配置信息指示无人机、机器狗、交警人员以及医护人员中的至少一项。

第三方面,本申请实施例提供了一种计算机可读存储介质,所述计算机存储介质中存储有计算机程序,所述计算机程序包括程序指令,所述程序指令当被处理器执行时使所述处理器执行所述第一方面及任一种可选的实现方式的方法。

第四方面,本申请实施例提供了一种计算机程序产品,该计算机程序产品包括程序指令,该程序指令当被处理器执行时使该处理器执行如第一方面或者第一方面的任意一种可能的实现方式中的方法。

附图说明

为了更清楚地说明本申请实施例或背景技术中的技术方案,下面将对本申请实施例或背景技术中所需要使用的附图作简单的介绍。

图1是本申请实施例提供的一种车联网系统的架构图;

图2是本申请实施例提供的一种车载设备生成全景图像的场景示意图;

图3是本申请实施例提供的一种数据处理方法的流程示意图;

图4是本申请实施例提供的另一种数据处理方法的流程示意图;

图5是本申请实施例提供的一种两辆车发生事故的场景示意图;

图6是本申请实施例提供的又一种数据处理方法的流程示意图;

图7是本申请实施例提供的一种数据处理装置的结构示意图;

图8是本申请实施例提供的另一种数据处理装置的结构示意图。

具体实施方式

本申请以下实施例中所使用的术语只是为了描述特定实施例的目的,而并非旨在作为对本申请的限制。如在本申请的说明书和所附权利要求书中所使用的那样,单数表达形式“一个”、“一种”、“所述”、“上述”、“该”和“这一”旨在也包括复数表达形式,除非其上下文中明确地有相反指示。还应当理解,本申请中使用的术语“和/或”是指并包含一个或多个所列出项目的任何或所有可能组合。

为了更清楚地描述本申请提供的方案,下面先介绍本申请实施例涉及的术语。

1、车联网(internet of vehicle,IoV)

车联网是汽车互联网的简称。作为物联网在汽车领域的一个细分应用,车联网以行驶中的车辆为信息感知对象,借助新一代信息通信技术与通信技术,实现车与车、车与人、车与路以及车与服务平台之间的网络连接,让车辆对服务平台中的所有车辆动态信息进行有效利用,从而提升车辆整体的智能驾驶水平,为用户提供安全、舒适、智能、高效的驾驶感受与交通服务,同时提高交通运行效率,提升社会交通服务的智能化水平。

请参阅图1,图1是本申请实施例提供的一种车联网系统的架构图。如图1所示,车联网系统包括车载设备101,车联网云平台102以及终端设备103。其中,车载设备101通过远程信息处理器(telematics box,T-Box)1011与车联网云平台102进行第一通信连接,车联网云平台102与终端设备103进行第二通信连接。于是,车载设备101,车联网云平台102以及终端设备103之间可以进行数据交互,并且,用户可以通过终端设备103从车辆网云平台获取到车载设备101的相关信息。本申请实施例中,车联网云平台102也可以称为车辆网服务器、服务器或者云服务器等。

作为车辆与互联网进行交互的关键部件,T-Box可以通过控制器局域网络(controller area network,CAN)实现指令与信息的传递,从而采集车辆信息,例如位置信息、姿态信息以及车辆状态信息等;然后,T-Box通过上述第一通信连接将上述车辆信息传送到远程服务提供商(telematics service provider,TSP)平台,例如图1中的车联网平台102。

2、全景式监控影像(around view monitor,AVM)系统

AVM系统可以理解为通过多个(例如四个)超大广角鱼眼镜头拍摄图像,然后对所拍摄图像进行畸变矫正以及拼接,从而形成全景影像的系统。

示例性地,请参阅图2,图2是本申请实施例提供的一种车载设备生成全景图像的场景示意图。如图2所示,车载设备201可以包括4个摄像头,即左摄像头202、右摄像头203、前摄像头204以及后摄像头205。AVM系统利用上述4个摄像头采集图像,然后将采集的图像传输到系统主机206,系统主机206通过算法对4路图像进行同步、合成以及拼接等处理,最后将处理好的图像在显示屏207上进行显示。

随着科学技术的不断发展,生活水平的不断提高,汽车保有量越来越大,在人们日常生活中越来越常见,相应地,道路交通安全也越来越成为人们关注的焦点。

目前,交通事故发生后,一般由事故人员或其他目击人员报警,调度中心的工作人员协调交通事故发生地所在辖区内的交警等事故处理人员进行事故处理。辖区内的资源有限,并且,在很多事故场景中常常需要多次调配资源进行救援,处理事故的效率低。例如,在人烟稀少的山区或郊外,或者,前往事故现场的道路可能出交通拥堵,事故处理人员前往事故现场耗时较长。

基于上述问题,本申请实施例提供了一种数据处理方法,通过本申请的一些实施例,可以辅助事故处理人员处理事故,提高事故处理的效率,进一步地,提高了恢复道路通畅的效率。本申请实施例中,上述数据处理方法可以由终端设备执行,上述终端设备可以是手机(mobile phone)、车辆、车载设备(例如车载单元(on board unit,OBU))、平板电脑(pad)、带数据收发功能的电脑(如笔记本电脑、掌上电脑等)、移动互联网设备(mobileinternet device,MID)、工业控制(industrial control)中的终端、无人驾驶(selfdriving)中的无线终端、运输安全(transportation safety)中的终端、智慧城市(smartcity)中的终端、智慧家庭(smart home)中的终端、5G网络中的终端设备或者未来演进的公用陆地移动通信网络(public land mobile network,PLMN)中的终端设备等。

可选地,当上述终端设备为车辆时,可以是普通车辆,也可以是特种车辆(包括但不限于是警车、牵引车等等)或者救援车辆(包括但不限于是救护车、消防车、救险车等)。

可选地,当终端设备为手持终端时,可以是警务通等智能终端。

可理解,对于终端设备的具体形态,本申请不作限定。但凡可以与路侧装置、或者车辆、或者车辆管理平台等通信的设备,均落入终端设备的保护范围。在一些实施例中,上述终端设备可以是本申请实施例提供的数据处理装置,为了便于理解,后文实施例统一以数据处理装置为执行主体对本申请提供的方法进行介绍。

示例性地,请参阅图3,图3是本申请实施例提供的一种数据处理方法的流程示意图。

如图3所示,该方法包括:

301:响应于检测到事故发生,获取第一事故数据;

本申请实施例中,在一种检测事故发生的实现方式中,数据处理装置可以获取T-Box中车辆状态数据,通过车辆状态数据是否异常来判断是否发生事故;或者,数据处理装置可以通过传感器来判断是否发生事故,例如,通过速度传感器检测出车辆的速度是否骤降,通过碰撞传感器判断车辆是否发生碰撞、安全气囊是否弹出等。

在另一种检测事故发生的实现方式中,数据处理装置可以获取道路上的车辆行驶图像,通过目标检测(object detection)算法检测出图像中的车辆,通过目标跟踪算法(object tracking)检测出车辆的行驶轨迹,示例性地,电子设备可以确定图像中移动的目标的相对移动速率,在检测到图像中目标在移动中快速停止,而且静止的持续时间超过一定长度,则可以认为发生事故。

本申请实施例中,响应于检测到事故发生,数据处理装置获取第一事故数据。在一种实现方式中,数据处理装置先确定事故发生,然后响应于检测到事故发生,获取第一事故数据。在另一种实现方式中,数据处理装置可以接收其他电子设备的指示信息,该指示信息用于指示检测到事故发生,触发数据处理装置获取第一事故数据。

本申请实施例中,该第一事故数据可以理解为与事故相关的数据。示例性地,该第一事故数据可以包括事故发生过程中产生的视频或图像数据,示例性地,如图2所示的AVM系统可以得到上述视频或图像数据。该第一事故数据还可以包括事件数据记录(eventdata recorder,EDR)系统数据,应理解,EDR系统用于记录车辆碰撞前、碰撞时、碰撞后三个阶段中对应时间序列的车辆动力学数据以及汽车单元内不同控制模块的数据。EDR数据包括车辆碰撞前数秒内的车辆速度、发动机转速、油门踏板位置、制动踏板操作情况、转向输入、安全带状态、变速杆档位、驾驶模式、轮胎气压、警告信号及安全气囊展开的记录等参数,以及车辆碰撞后200ms内的速度变化情况。

302:基于该第一事故数据,判断事故等级;

本申请实施例中,数据处理装置在获取到该第一事故数据之后,基于该第一事故数据判断事故等级。

作为一种可选的实施方式,数据处理装置在执行步骤302的过程中执行以下步骤:

1、根据该第一事故数据确定事故类型;

可以理解的是,发生事故的场景有多种,本申请实施例中,该事故类型可以理解为事故的类别。例如,该事故类型可以是机动车与机动车之间的事故、机动车与非机动车之间的事故、机动车与人之间的事故等。在一些实施例中,事故类型也可以根据事故发生的场景来判别,例如,事故类型可以是是城市交通事故类型、山区公路交通事故类型、干线公路交通事故类等。

在确定事故类型的实现方式中,示例性地,如步骤301中,数据处理装置可以通过第一事故数据中的事故发生过程中产生的视频或图像数据,通过图像识别算法确定事故类型。

2、基于该事故类型,从预设事故等级规则集合中确定与该事故类型对应的预设事故等级规则;

应理解,按照交管中心或公安部出示的规定,交通事故被划分成4个等级,即轻微事故、一般事故、重大事故、特大事故;并给每个级别的事故指定了判别标准。本申请实施例中,该预设事故等级规则集合具有统一配置的标识号,数据处理装置通过预设事故等级规则集合的标识号来确定预设事故等级规则集合是否为统一配置的版本,例如,标识号可以是版本和时间。本申请实施例中,通过标识号对预设事故等级规则集合进行判断,从而确保预设事故等级规则集合的一致性,该预设事故等级规则集合是根据交管中心的规定统一配置的,从而避免因为评判标准不同导致判定的事故等级差异太大,进而导致警力配置不合理的情况,确保事故等级判决的一致性和合规性。另外,每一个预设事故等级规则也可以通过标识号进行区别,不同的事故类型对应不同的预设事故等级规则。

因此,本步骤中,数据处理装置在确定事故类型之后,再从预设事故等级规则集合中确定与该事故类型对应的预设事故等级规则。可以理解的是,不同的事故类型对应的预设事故等级规则的侧重点可以不同,例如,在判定事故类型为机动车与机动车之间的事故的情况下,数据处理装置将结合不同机动车的受损情况来综合判断事故等级;在判定事故类型为机动车与人之间的事故的情况下,数据处理装置将结合机动车的受损情况和人的受伤情况来综合判断事故等级。在一些实施例中,在道路发生塌陷、山体滑坡等场景中发生的事故,数据处理装置还可以结合事故现场的环境来判断事故等级,比如,车辆在山体滑坡中被掩埋,可以适应性提高事故等级,加急救援,使得事故人员可以得到及时的救援。

3、根据该预设事故等级规则判断该事故等级。

本步骤中,在一种实现方式中,数据处理装置可以预设每种事故类型的判别维度,例如,车辆发生事故过程中的最大震动幅度、车辆碰撞时的速度,车辆碰撞后滑行的最大距离等;然后,并对每个判别维度进行量化,例如,最大震动幅度在0-20记为1,最大震动幅度在20-30记为2,最大震动幅度在30-40记为3等;最后根据该第一事故数据中每种判别维度计算该事故数据对应的得分值。该预设事故等级规则20-40则认为是轻微事故、得分值在40-50则认为是一般事故、得分值在50-60则认为是重大事故,得分值在60以上则认为是特大事故。

应理解,不同的判别维度的重要程度不同,为了使结果更加合理,数据处理装置还可以给判别维度设定加权值,然后对各个判别维度进行加权求和得到相应的得分值。

本实施例中,数据处理装置结合事故类型来确定事故等级,可以应对不同的交通事故处理场景。

303:在确定出该事故等级的情况下,获取基于该事故等级确定的警力配置信息。

本步骤中,在确定出事故等级的情况下,数据处理装置获取基于该事故等级确定的警力配置信息。本申请实施例中,该警力配置信息可以理解为进行事故救援而需要警力配置。

本申请实施例中,警力配置信息根据事故等级来确定,也就是说,不同的事故等级对应不同的警力配置信息,根据事故等级来配置不同的警力资源,可以提高警力资源的利用率,充分发挥不同警力资源的优势。示例性地,在一些实施例中,该警力配置信息指示无人机、机器狗、交警人员中的至少一项。例如,若确定出事故等级为轻微事故,则警力资源选择范围包括无人机、机器狗,可以是无人机的优先级大于机器狗。例如,若无人机的状态为空闲,则派遣无人机;若无人机的状态为忙,则派遣空闲的机器狗。

若确定出事故等级为一般事故,则警力资源选择范围包括交警人员、无人机、机器狗,可以是无人机的优先级大于机器狗。例如,若无空闲交警人员或交警人员被分配给事故等级更高的交通事故,则派遣空闲的无人机,若无人机忙,则派遣机器狗。

若确定出事故等级为严重事故,则警力资源选择范围包括交警人员、无人机、机器狗,其中交警人员必须到事故现场,并且还包括无人机、机器狗中的一种。其中,无人机、机器狗可以先行出发,机器狗帮助维持事故现场交通秩序,无人机可以开展巡逻预警避免后车的二次撞击。

若确定出事故等级为特大事故,则警力资源选择范围包括交警人员、无人机、机器狗。无人机和机器狗可以先行出发,无人机用于空中侦测事故现场状态,辅助警示过往车辆等,机器狗可以携带各类传感器,侦测事故现场的危险性、人员状态以及辅助救援等,如大型机器狗负载能力强的可以辅助开车门、破窗等。

本申请实施例中,根据事故数据来配置人力的警力资源和非人力的警力资源,提高警力配置的合理性以及事故处理的效率。

本申请实施例中,数据处理装置在检测到事故发生后,获取第一事故数据;然后根据第一事故数据判断事故等级,在确定出事故等级后获取基于该事故等级确定的警力配置信息。由于先基于第一事故数据进行事故等级判断,且警力配置信息是根据事故等级得到的,使得警力资源配置更加合理,提高事故处理的效率。

在一些实施例中,在步骤303之前,数据处理装置还执行以下步骤:

在不能确定出该事故等级的情况下,基于该第一事故数据获取第二事故数据;

基于该第一事故数据和该第二事故数据,重新判断该事故等级。

示例性地,请参阅图4,图4是本申请实施例提供的另一种数据处理方法的流程示意图。

如图4所示,该方法包括:

401:响应于检测到事故发生,获取第一事故数据;

402:基于该第一事故数据,判断事故等级;

应理解,上述步骤401和步骤402可以参考前文实施例中步骤301和步骤302的描述。

403:在不能确定出该事故等级的情况下,基于该第一事故数据获取第二事故数据;

应理解,在步骤302中,数据处理装置基于该第一事故数据,判断事故等级,因此,在不能确定出该事故等级的情况下,数据处理装置基于该第一事故数据获取第二事故数据。本申请实施例中,该第二事故数据也可以理解为与事故相关的数据,作为第一事故数据的补充。本申请实施例中,该第一事故数据由第一终端设备采集,该第二事故数据由至少一个第二终端设备采集。

应理解,本申请实施例中,第一事故数据由第一终端设备采集,事故发生过程中可能导致第一终端设备的某些部件损坏导采集的第一事故数据不全面,例如,事故过程中某个摄像头被毁,或者,发生的事故的位置正好是第一终端设备的盲区,导致第一终端设备采集的事故过程中的影像数据不足等。本申请实施例中,该第二终端设备可以理解为除第一终端设备之外的,能够采集到与事故相关的数据的设备,示例性地,该第二终端设备可以是发生事故的车辆周边的其他车辆,或者,事故现场周围的路侧设备等。可以理解的是,不同类型的第二终端设备可以采集不同的第二事故数据,例如,可以是与事故相关的视频或图像,也可以是事故现场的定位数据,还可以是事故发生过程中的测速数据,还可以是事故发生的时间点数据等。

为便于理解,示例性地,请参阅图5,图5是本申请实施例提供的一种两辆车发生事故的场景示意图。

如图5所示道路被分成左车道和右车道,其中,车辆504在左车道上正常行驶,车辆503和车辆505在右车道上正常行驶,车辆501和车辆502之间发生碰撞,即发生事故(如图5中的50部分)。

示例性地,在该第一终端设备为车辆502的情况下,即在该第一事故数据由车辆502采集的情况下,该第二终端设备可以是事故发生前后的预设时间范围内与车辆502之间的距离小于或等于第一阈值的设备,应理解,该第一阈值可以根据实际情况做限定,例如可以是20米、30米以及50米等,本申请对此不作限定。

示例性地,如图5所示,该第二终端设备可以是与车辆503同一个车道上的车辆503,可以是摄像头506。可选地,该第二终端设备也可以是车辆502。可选地,该第二终端设备还可以是对面车道上的车辆504,或者,对面的摄像头508。可以理解的是,对于摄像设备来说,设备的设立位置和摄像角度不同将导致拍摄结果的不同,事故发生后,与事故车辆相对的车道上的第二终端设备采集的图像数据可能更加清晰或全面,更有利于分析出事故等级。

同理,在在该第一终端设备为车辆501的情况下,即在该第一事故数据由车辆501采集的情况下,该第二终端设备可以是事故发生前后的预设时间范围内与车辆501之间的距离小于或等于第二阈值的车辆504,或者车辆503,也可以是车辆502;还可以是对面的摄像头508,或者摄像头506,应理解,该第二阈值与该第一阈值类似,可以根据实际情况进行设定,本申请对此不作限定。

应理解,上述图5仅仅是一个场景示例,不构成本申请实施例的场景限定,在实际情况的其他场景中,该第二终端设备也可以是其他电子设备,例如,事故现场附近有无人机的情况下,该第二终端设备也可以是无人机。

404:基于该第一事故数据和该第二事故数据,重新判断该事故等级;

应理解,本步骤与302中,数据处理装置基于该第一事故数据判断事故数据类似,本步骤中,本步骤中,数据处理装置在获取到该第二事故数据后,综合该第一事故数据和该第二事故数据,重新判断事故等级,这里对判断过程不再赘述。

在基于第一事故数据无法确定出事故等级的情况下,进一步获取第二事故数据,然后综合第一事故数据和第二事故数据来判断事故等级,提高数据处理装置判断出事故等级的概率。

405:在确定出该事故等级的情况下,获取基于该事故等级确定的警力配置信息。

应理解,本步骤可以参考前文实施例中步骤303的相关描述。

在一些实施例中,该第一事故数据包括事故地点信息、事故时间信息和设备标识信息;数据处理装置在执行步骤404的过程中执行以下步骤:

基于该第一事故数据,获取与该事故地点信息、该事故时间信息和该设备标识信息相关联的该第二事故数据。

本申请实施例中,设备标识信息可以理解为可以识别车辆的标识性信息,示例性地,该设备标识信息可以是车辆的车牌号、车辆的颜色、车辆的品牌、车型以及设备唯一标识号等标识信息。通过该设备标识信息,可以有利于后续警力定位事故车辆,例如,可以有利于无人机通过识别辆的颜色、车牌号以及车型定位事故车辆,又例如,在一些停靠的车辆较多的街道旁发生轻微事故(例如剐蹭),如果事故车辆周围停靠着其他车辆,也没有人群围观,通过该设备标识信息就可以帮助警力人员快速定位事故车辆。通过该设备标识信息,还有利于定位第二事故数据,例如,由于拍摄角度的问题没有获取到车辆的车牌号,但是可以通过获取到的其他设备标识信息来获取第二事故数据。

在一种可能的实现方式中,数据处理装置从服务器(例如图1中的车联网云平台)中获取符合该事故地点信息、事故时间信息和设备标识信息的数据作为该第二事故数据。

在另一种实现方式中,数据处理装置可以与第二终端设备之间建立无线连接,通过该无线连接获取符合该事故地点信息、事故时间信息和设备标识信息的数据作为该第二事故数据。示例性地,在数据处理装置为车辆501的情况下,车辆501可以与车辆503,或者摄像头507之间建立无线连接。

在一些实施例中,在步骤404之后,数据处理装置还执行以下步骤:

在不能确定出该事故等级的情况下,生成指示信息。

可以理解的是,人烟稀少的山区或者郊外等场景中发生严重事故时,可能获取的第一事故数据和第二事故数据不足以判断出事故等级。本步骤中,在综合第一事故数据和第二事故数据依然不能确定出该事故等级的情况下,数据处理装置生成指示信息。

本申请实施例中,该指示信息也可以用于指示发生事故,还可以用于指示该第一事故数据和/或该第二事故数据。数据处理装置可以向相关的网络设备发送该指示信息,以便于相关人员(例如为交警人员)对事故进行分析,并及时处理。示例性地,数据处理装置可以向服务器(例如图1中的车联网云平台)发送该指示信息。

在一些实施例中,该第一事故数据还包括生命体征数据;该警力配置信息指示无人机、机器狗、交警人员以及医护人员中的至少一项。

本申请实施例中,生命体征数据可以包括血压数据、心率数据、脉搏数据、呼吸数据以及血氧数据中的至少一项。示例性地,可以设置生物传感器或通过可穿戴设备等来获取该生命体征数据、例如生物传感器可以包括血糖传感器、血压传感器、心电传感器、肌电传感器、体温传感器、脑电波传感器等。

通过该生命体征数据以及步骤301中的EDR数据,数据处理装置可以判断出事故发生后,相关人员的生命状态。示例性地,用户可能本身患有心脏相关的疾病,数据处理装置通过该生命体征数据确定用户需要心脏相关的救援,因此,警力配置信息就还可以包括心脏救治相关的医护人员。

本申请实施例中,采集的第一事故数据包括生命体征数据,在警力配置中根据生命体征数据加入医护人员进行救援,从而提高保障用户的生命安全的概率。

为便于理解,接下来以数据处理装置为车载设备为例对本申请提供的数据处理方法进行说明,示例性地,请参阅图6,图6是本申请实施例提供的又一种数据处理方法的流程示意图。如图6所示,该方法包括:

601:车载设备检测到发生事故。

本步骤中,车载设备可以通过获取T-Box中车辆状态数据,或者,通过传感器来判断是否发生事故等,具体可以参阅前文步骤301的相关描述。

602:车载设备获取事故数据A。

本步骤中,事故数据A可以理解为前文实施例中的第一事故数据。

603:车载设备判断根据事故数据A能否从预配置策略中确定事故等级。

本步骤中,预配置策略可以理解为前文实施例中的预设事故等级规则集合,具体的判断步骤可以参阅前文步骤302的相关描述。

在步骤603的判断结果为“是”的情况下,执行步骤604:车载设备向服务器发送指示信息A,指示信息A用于指示该事故等级;相应地,服务器接收指示信息A。

本步骤中,指示信息A指示的事故等级为步骤603中确定的事故等级。

在步骤603的判断结果为“否”的情况下,执行步骤605:车载设备获取事故数据B。

本步骤中,事故数据B可以理解为前文实施例中的第二事故数据。

然后执行步骤606:车载设备判断根据事故数据A和事故数据B能否从预配置策略中确定事故等级。

本步骤中,事故数据A和事故数据B判断事故等级的具体方式可以参阅前文步骤3、步骤4以及步骤5的相关描述。

在步骤606的判断结果为“是”的情况下,执行步骤607:车载设备向服务器发送指示信息B,指示信息B用于指示该事故等级;相应地,服务器接收指示信息B。

本步骤中,指示信息A指示的事故等级为步骤606中确定的事故等级。

应理解,在服务器接收到指示信息A或指示信息B后,可以根据事故等级配置警力信息,具体可参阅前文步骤303的相关描述。

在步骤606的判断结果为“否”的情况下,执行步骤608:车载设备向服务器发送指示信息C,指示信息C用于指示事故数据A和事故数据B;相应地,服务器接收指示信息C。

然后,执行步骤609:服务器根据历史情况判断事故等级。

本步骤中,应理解,服务器在接收到指示信息C后,根据指示信息C指示的事故数据A和事故数据B和历史情况判断事故等级,然后根据事故等级配置警力信息。

应理解,本申请实施例中,车载设备只会执行上述步骤604、步骤607以及步骤608中的一个步骤,在车载设备执行到步骤604的情况下,后续步骤将不再执行;同理,在车载设备执行到步骤607的情况下,后续步骤将不再执行。

本申请实施例中,通过步骤604向服务器指示事故等级后,车载设备还获取根据事故等级确定的警力配置信息;或者,通过步骤607向服务器指示事故等级后,车载设备还获取根据事故等级确定的警力配置信息;或者,步骤609后,即服务器根据历史情况判断事故等级后,车载设备还获取根据事故等级确定的警力配置信息。示例性地,车载设备可以接收服务器发送的警力配置信息,应理解,对警力配置信息的相关描述可以参考前文步骤303,这里不再赘述。

以上详细介绍了本申请实施例提供的方法,接下来介绍本申请实施例提供的装置。

示例性地,请参阅图7,图7是本申请实施例提供的一种数据处理装置的结构示意图。该数据处理装置70用于执行上述实施例中的数据处理方法,应理解,但凡能够实现本申请提供的数据处理方法的装置都属于本申请的保护范围。示例性地,该数据装置50可以为手机、车辆、车载设备、平板电脑、带数据收发功能的电脑、移动互联网设备等,本申请实施例不作限定。如图7所示,该数据处理装置70包括通信组件701、传感器702以及处理器703。本申请实施例中。不限定通信组件701、传感器702以及处理器703的个数,并且,处理器703与通信组件701和传感器702之间具有可通信的连接,对各个部分的描述如下:

传感器702,其被配置为检测事故的发生;

通信组件701,其被配置为响应于检测到事故发生,获取第一事故数据;

处理器703,其被配置为:基于所述第一事故数据,判断事故等级;以及在确定出事故等级的情况下,获取基于所述事故等级确定的警力配置信息。

在一种可能的实现方式中,通信组件701,其进一步被配置为在不能确定事故等级的情况下,基于所述第一事故数据获取第二事故数据;

处理器703,其进一步被配置为基于所述第一事故数据和所述第二事故数据,重新判断所述事故等级。

在一种可能的实现方式中,通信组件701,其进一步被配置为基于所述第一事故数据,获取与事故地点信息、事故时间信息和设备标识信息相关联的所述第二事故数据。

在一种可能的实现方式中,处理器703,其进一步被配置为在不能确定出所述事故等级的情况下,生成指示信息。

在一种可能的实现方式中,处理器703,其进一步被配置为根据所述第一事故数据和/或所述第二事故数据确定事故类型;基于所述事故类型,从预设事故等级规则集合中确定与所述事故类型对应的预设事故等级规则;以及根据所述预设事故等级规则判断所述事故等级。

本申请实施例中,关于第一事故数据、第二事故数据、警力配置信息、事故地点信息、事故时间信息、设备标识信息、指示信息以及预设事故等级规则集合等的说明还可以参考上文方法实施例中的介绍,这里不再一一详述。

请参阅图8,图8是本申请实施例提供的另一种数据处理装置的结构示意图。本申请实施例中,图8所示的数据处理装置80可以是数据处理装置70。

如图8所示。该数据处理装置80包括至少一个处理器802,用于实现本申请实施例提供的方法中数据处理装置的功能。收发器801用于通过传输介质和其他设备/装置进行通信,传感器805用于检测信号,并实现信号转换。处理器802可以对传感器805的处理结果进行相应,还可以利用收发器801收发数据和/或信令,用于实现上述方法实施例中的方法。

可选地,数据处理装置80还可以包括至少一个存储器803,用于存储程序指令和/或数据。存储器803和处理器802耦合。本申请实施例中的耦合是装置、单元或模块之间的间接耦合或通信连接,可以是电性,机械或其它的形式,用于装置、单元或模块之间的信息交互。处理器802可能和存储器803协同操作。处理器802可能执行存储器803中存储的程序指令。该至少一个存储器中的至少一个可以包括于处理器中。

本申请实施例中不限定上述收发器801、处理器802、存储器803以及传感器805之间的具体连接介质。本申请实施例在图8中以存储器803、处理器802、收发器801以及传感器805之间通过总线804连接,总线在图8中以粗线表示,其它部件之间的连接方式,仅是进行示意性说明,并不引以为限。该总线可以分为地址总线、数据总线、控制总线等。为便于表示,图8中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。

在本申请实施例中,处理器可以是通用处理器、数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件,可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成,或者用处理器中的硬件及软件模块组合执行完成。

可理解,在数据处理装置80为上述数据处理装置70时,通信组件701执行的动作可以由收发器801执行,传感器702执行的动作可以由传感器805执行,处理器703执行的动作可以由处理器802执行。

本申请还提供一种计算机可读存储介质,该计算机可读存储介质中存储有计算机代码,当计算机代码在计算机上运行时,使得计算机执行上述实施例的方法。

本申请还提供一种计算机程序产品,该计算机程序产品包括计算机代码或计算机程序,当该计算机代码或计算机程序在计算机上运行时,使得上述实施例中的方法被执行。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,上述流程可以由计算机程序相关的硬件完成,上述计算机程序可存储于计算机可读取存储介质中,上述计算机程序在执行时,可包括如上述各方法实施例的流程。而前述的存储介质包括:只读存储器ROM或随机存储记忆体RAM、磁碟或者光盘等各种可存储计算机程序代码的介质。

相关技术
  • 存储系统的数据处理方法、装置、系统及可读存储介质
  • 音频数据的处理方法及装置、存储介质、电子装置
  • 数据处理方法、装置、存储介质和电子装置
  • 数据处理方法、装置、存储介质和电子装置
  • 数据库集群数据处理方法及装置、存储介质和终端
  • PET 数据处理方法、PET 数据处理装置、计算机可读的存储介质、以及数据处理方法
  • 分布处理方法、分布处理装置、印刷数据处理方法、印刷数据处理装置、以及存储介质
技术分类

06120116380457