CN118212763A - 处理交通事故的方法、装置、设备以及存储介质 - Google Patents

Abstract

本申请实施例公开了一种处理交通事故的方法、装置、设备以及存储介质。方法包括以下步骤：响应于检测到交通事故,向交警服务器发送出警请求消息，出警请求消息包括事故车辆的标识信息和事故地点信息；接收交警服务器发送的出警提示消息，出警提示消息包括出警成员、预计到达时间和出警成员的实时位置信息；以及呈现出警提示消息。实施本申请实施例，可以实现信息互通和提高用户的体验度，有利于缓解用户的焦急心理。

Description

处理交通事故的方法、装置、设备以及存储介质

技术领域

本申请涉及信息处理技术领域，尤其涉及一种处理交通事故的方法、装置、设备以及存储介质。

背景技术

随着人们生活水平的提高，机动车数量的持续增加，但随之而来的交通事故也逐年增多，频繁的交通事故严重威胁人们的生命财产安全。传统的交通事故的处理方法往往需要事故人员先进行现场报警、拍照等，交警到达之后再进行责任认定和疏导交通。然而，上述交通事故处理方式，事故人员在报警之后，不知道具体的出警相关信息，信息交互性较差，并且事故人员在等待交警到达的过程中，容易产生焦急心理，用户体验度也较低。

发明内容

本申请的一个目的在于提供一种处理交通事故的方法、装置、设备以及存储介质，其优势在于，通过在交通事故发生后向用户呈现的出警提示消息中携带出警成员的实时位置信息，可以实现信息互通和提高用户的体验度，有利于缓解用户的焦急心理。

本申请的另一个目的在于提供一种处理交通事故的方法、装置、设备以及存储介质，其优势在于，能够在检测到交通事故后自动控制智能助手向用户提供报警入口，便于用户及时报警，可以提高交通事故的处理过程的智能性。

本申请的另一个目的在于提供一种处理交通事故的方法、装置、设备以及存储介质，其优势在于，能够在交通事故发生后基于事故地点和事故等级来确定对应的出警成员，可以提高警力资源分配的合理性以及出警效率。

本申请的另一个目的在于提供一种处理交通事故的方法、装置、设备以及存储介质，其优势在于，在交通事故发生后通过控制智能助手呈现并更新出警提示消息给用户，可以提高用户的体验度。

本申请的另一个目的在于提供一种处理交通事故的方法、装置、设备以及存储介质，其优势在于，在交通事故发生后通过向事故车辆的预设范围内的非事故车辆广播出警提示消息，以提示非事故车辆进行避让，有利于避免道路拥堵，便于警力更顺利地抵达事故现场，同时有利于防止发生二次交通事故。

本申请的另一个目的在于提供一种处理交通事故的方法、装置、设备以及存储介质，其优势在于，根据出警路线的路段特征确定警力的预计到达时间，可以提高出警提示消息的准确性。

为实现上述目的，第一方面，本申请实施例提供了一种处理交通事故的方法，包括以下步骤：

响应于检测到交通事故，向交警服务器发送出警请求消息，出警请求消息包括事故车辆的标识信息和事故地点信息；

接收交警服务器发送的出警提示消息，出警提示消息包括出警成员、预计到达时间和出警成员的实时位置信息；以及

呈现出警提示消息。

可以看出，当车载终端检测到交通事故之后，会向交警服务器发送出警请求消息。车载终端接收交警服务器根据出警请求消息中的事故车辆标识信息和事故地点信息生成出警提示消息之后，呈现出警提示消息。其中，出警提示消息包括出警成员、预计到达时间和出警成员的实时位置信息。如此，车载终端在检测到交通事故时，可以及时报警，节省用户的时间和精力，有助于提高交通事故的处理效率。此外，用户可以从出警提示消息中及时获取交警的实时位置信息，以实现信息互通，有助于提升用户的体验度以及缓解用户的焦急心理。

在一种可能的实施方式中，响应于检测到交通事故，向交警服务器发送交警请求消息，包括以下步骤：

响应于检测到交通事故，控制智能助手向用户提供报警入口；以及

响应于接收到用户在报警入口输入的报警指令，向交警服务器发送出警请求消息。

可以看出，车载终端在检测到交通事故之后，可以自动触发智能助手的开启。智能助手开启后，可以控制智能助手向用户提供报警入口，便于用户及时报警，从而提高交通事故的处理过程的智能性。在接收到用户的报警指令之后，可以向交警服务器发送出警请求消息，通过在交通事故发生后向用户呈现的出警提示消息中携带出警成员的实时位置信息，可以实现信息互通和提高用户的体验度，有利于缓解用户的焦急心理。

在一种可能的实施方式中，出警请求消息包括事故图像，事故图像基于以下步骤确定：

获取预设时间段内事故车辆的环境图像；以及

从事故车辆的环境图像中确定事故图像。

可以看出，车载终端通过获取预设时间段内事故车辆的环境图像，再从事故车辆的环境图像中确定事故图像。如此，可以提高事故图像获取的效率和准确性。

在一种可能的实施方式中，出警成员根据事故地点信息和事故等级确定，事故等级根据事故图像确定。

可以看出，根据事故图像确定事故等级，然后根据事故等级和事故地点信息确定出警成员，可以快速确定对应的出警成员，从而可以提高警力资源分配的合理性以及出警效率。

在一种可能的实施方式中，呈现出警提示消息，包括以下步骤中的至少一项：

控制智能助手向用户呈现出警提示消息，以及控制智能助手基于预定时间间隔更新实时位置信息和预计到达时间；以及

向事故车辆的预设范围内的非事故车辆广播出警提示消息，以提示非事故车辆进行避让。

可以看出，车载终端接收到出警提示消息之后，可以控制智能助手向用户呈现并更新该出警提示消息。如此，可以整个交通事故的处理过程具有较高的智能性，便于提高用户的体验。在交通事故发生之后，还可以事故车辆的预设范围内的非事故车辆广播出警提示消息，以提示非事故车辆进行避让，有利于避免道路拥堵，便于警力更顺利地抵达事故现场，同时有利于防止发生二次交通事故。

第二方面，本申请实施例提供另一种处理交通事故的方法，包括以下步骤：

获取车载终端发送的出警请求消息，出警请求消息包括事故车辆的标识信息和事故地点信息；以及

根据出警请求消息，生成出警提示消息以发送至车载终端，出警提示消息包括出警成员、预计到达时间和出警成员的实时位置信息。

在一种可能的实施方式中，出警请求消息包括事故图像，根据出警请求消息，生成出警提示消息以发送至车载终端，包括以下步骤：

根据事故图像确定事故等级；

根据事故地点信息和事故等级确定出警成员；

获取出警成员的实时位置信息；以及

生成出警提示消息以发送至车载终端，出警提示消息包括出警成员、预计到达时间和出警成员的实时位置信息。

可以看出，根据事故图像确定事故等级，然后根据事故等级和事故地点信息确定出警成员，可以快速确定出警成员，以提高出警效率。

在一种可能的实施方式中，根据事故图像确定事故等级，包括以下步骤：

对事故图像中各个特征进行聚类，得到目标特征集合；

将目标特征集合输入至事故等级检测模型中，得到各个特征的事故等级检测结果；以及

根据各个特征的事故等级检测结果确定事故等级。

可以看出，交警服务器通过对事故图像中各个特征进行聚类，得到目标特征集合，并将其输入至事故等级检测模型中，得到各个特征的事故等级检测结果。最后，再根据各个特征的事故等级检测结果确定事故等级。通过实施本申请实施例，能够在交通事故发生后基于事故地点和事故等级来确定对应的出警成员，可以提高警力资源分配的合理性以及出警效率。

在一种可能的实施方式中，根据事故地点信息和事故等级确定出警成员，包括以下步骤：

根据事故等级确定出警人数；

根据事故地点信息确定出警名单；以及

根据出警人数和出警名单确定出警成员。

可以看出，根据事故等级确定出警人数之后，根据事故地点信息确定出警名单，最后再根据出警人数和出警名单确定出警成员。如此，可以快速确定能够最快抵达事故现场的出警人员，有利于提高出警的效率。

在一种可能的实施方式中，根据事故地点信息确定出警名单，包括以下步骤：

根据事故地点信息确定事故地点信息所指示区域内的至少一个空闲警员；

计算至少一个空闲警员的至少一个预计到达时间；以及

基于至少一个预计到达时间，确定出警名单。

可以看出，通过事故地点信息确定事故地点信息所指示区域内的至少一个空闲警员，然后基于至少一个空闲警员的至少一个预计到达时间确定出警名单，可以缩短出警的时间，从而提高交通事故的处理效率。

在一种可能的实施方式中，预计到达时间基于以下步骤确定：

根据事故地点信息确定待出发路线，待出发路线至少包括一条路段；

获取待出发路线的路段特征，路段特征包括路段长度、红绿灯数量和平均限速；以及

根据路段特征确定预计到达时间。

可以看出，交警服务器根据事故地点信息确定待出发路线之后，获取待出发路线的路段特征，最后可以根据出警路线的路段特征确定警力的预计到达时间，从而可以提高出警提示消息的准确性。

第三方面，本申请实施例提供了一种处理交通事故的装置，包括：至少一个传感器、显示组件以及与至少一个传感器和显示组件可通信地连接的至少一个处理器；其中，

至少一个传感器被配置为检测是否发生交通事故；

至少一个处理器被配置为：

响应于至少一个传感器检测到发生交通事故，向交警服务器发送出警请求消息，出警请求消息包括事故车辆的标识信息和事故地点信息；以及

接收交警服务器发送的出警提示消息，出警提示消息包括出警成员、预计到达时间和出警成员的实时位置信息；

显示组件被配置为呈现出警提示消息。

第四方面，本申请实施例提供了一种计算机设备，包括处理器、存储器和通信接口，其中，存储器存储有计算机程序，计算机程序被配置由处理器执行，计算机程序包括用于如本申请实施例第一方面或第二方面中所描述的部分或全部步骤的指令。

第五方面，本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质存储计算机程序，计算机程序使得计算机执行如本申请实施例第一方面或第二方面中所描述的部分或全部步骤。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以基于这些附图获得其他的附图。其中：

图1为本申请实施例提供的一种***架构示意图；

图2A为本申请实施例提供的一种处理交通事故的方法的流程示意图；

图2B为本申请实施例提供的一种事故图像确定方法的流程示意图；

图2C为本申请实施例提供的一种确定预计到达时间的方法的流程示意图；

图3为本申请实施例提供的另一种处理交通事故的方法的流程示意图；

图4A为本申请实施例提供的另一种处理交通事故的方法的流程示意图；

图4B为本申请实施例提供的另一种处理交通事故的方法的流程示意图；

图4C为本申请实施例提供的另一种处理交通事故的方法的流程示意图；

图4D为本申请实施例提供的另一种处理交通事故的方法的流程示意图；

图5为本申请实施例提供的一种处理交通事故的装置的结构示意图；

图6为本申请实施例提供的一种计算机设备的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书及附图中的术语“第一”、“第二”、“第三”和“第四”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、***、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结果或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

为了更好地理解本申请实施例的技术方案，先对本申请实施例可能涉及的***架构进行介绍。请参见图1，本申请实施例提供的一种***架构示意图，该***架构可以包括：车载终端100和交警服务器200。其中车载终端和交警服务器之间可以通过网络通信。网络通信可以基于任何有线和无线网络，包括但不限于因特网、广域网、城域网、局域网、虚拟专用网络(virtual private network，VPN)和无线通信网络等等。

车载终端，又称为车载设备、车载电脑或者车机。在本申请实施例中，车载终端可以用于向交警服务器发送出警提示消息，也可以用于接收交警服务器发送的出警提示消息，还可以用于控制智能助手向用户提供报警入口等等。

在本申请实施例中，交警服务器是部署在交警***里的服务器。交警服务器可以是独立的服务器，也可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(content delivery network，CDN)、以及大数据和人工智能平台等基础云计算服务的云服务器。交警服务器或者可以通过多个服务器组成的服务器集群来实现。

传统的交通事故的处理方法往往需要事故人员先进行现场报警、拍照等，交警到达之后再进行责任认定和疏导交通。这些操作过程繁琐且需要占用大量的时间。此外，事故人员如果已经受伤，还可能会导致报警不及时，进而导致出警不及时、长时间道路拥堵等问题，严重的还会造成二次交通事故。

为了解决上述问题，本申请实施例提供了一种处理交通事故的方法，通过实施该方法，可以提高交通事故处理的效率。

请参照图2A，图2A是本申请实施例提供的一种处理交通事故的方法的流程示意图，可以包括以下步骤S201-S204，其中：

步骤S201：车载终端响应于检测到交通事故，向交警服务器发送出警请求消息。

相应地，交警服务器获取该出警请求消息。在本申请实施例中，交通事故可以是指行驶的两辆车或两辆车以上的车辆相撞，也可以是行驶的车辆与行人相撞，还可以是行驶的车辆与其他的物体相撞等。事故车辆可以是指发生交通事故的车辆。

具体地，当车载终端检测到交通事故时，可以向交警服务器发送出警请求消息，以提示交警有交通事故发生。其中，出警请求消息可以包括事故车辆的标识信息和事故地点信息。事故车辆的标识信息可以包括事故车辆的车牌号码、车辆识别码(vehicleidentification number，VIN)等唯一标识车辆身份的信息，也可以包括事故车辆的车主的驾驶证以及车主的联系方式等信息，还可以包括事故车辆的颜色、型号等信息。

在本申请实施例中，车载终端可以预先存储有这些标识信息，当检测到发生交通事故时，可以向交警服务器上传车辆的标识信息。其中，车牌号码、事故车辆的颜色和型号等信息可以帮助交警快速找到事故车辆。而VIN、驾驶证以及车主的联系方式等信息可以方便交警对本次交通事故进行存档。此外，交警还可以通过预留的车主联系方式联系车主，以提高交通事故处理的效率。

事故地点信息可以是指交通事故发生的地点。事故发生的地点可以通过全球定位***(global positioning system，GPS)获取。事故地点信息还可以包括交通事故发生的地点附近标志性的建筑物。如此，通过在出警提示消息中携带事故地点信息，有利于交警快速赶往事故地点。

示例地，出警提示消息可以是“人民路1052-1058号(马路尾)地段发生交通事故，事故车辆的车牌号码为某A12345”或者可以是“123线AB线(600km+800m)处有交通事故，事故车辆为橙色大货车，车牌号码为某A12453”等。

可以看出，车载终端检测到交通事故时，向交警服务器发送出警请求消息，出警请求消息包括事故车辆的标识信息和事故地点信息。便于交警快速赶往事故地点和快速找到事故车辆，从而快速开展调解工作和道路疏通工作，有利于提高交通事故处理的效率。

在一种可能的实施方式中，出警请求消息可以包括事故图像。请参阅图2B，图2B是本申请实施例提供了一种确定事故图像的方法的流程示意图，可以包括以下步骤S2B1-S2B2，其中:

步骤S2B1：车载终端获取预设时间段内事故车辆的环境图像。

其中，环境图像可以包括环境照片和/或环境视频。预设时间段是预先设定的参数，具体可以根据历史经验进行设置。示例地，预设时间段可以是检测到发生交通事故的前后30秒或者可以是检测到发生交通事故的前后60秒，还可以是检测到发生交通事故前后的其他时间段，本申请实施例对此不做限定。

在本申请实施例中，可以在车辆前后窗或者两侧玻璃上安装摄像头，该摄像头用于拍摄车内外环境。车内外环境可以包括车辆前方的环境、车辆后方的环境、车辆两侧的环境，或者还可以是车辆内部的环境等等。安装的具***置可以是车辆前后窗或者两侧玻璃的竖直中心线上等，在此不做限定。其中，该摄像头与车载终端可以通过有线或无线方式进行通信。

在车辆的行驶过程中，车载终端可以调用摄像头对车内外环境进行拍照或录像，以得到车辆的环境图像。此外，还可以将车辆的环境图像存储在车载终端的存储模块中，方便后续使用。因此，当检测到发生交通事故时，车载终端可以获取到预设时间段内事故车辆的环境图像。在一种可能的实施方式中，还可以定时删除车载终端内存储的车辆环境图像，以节省内存。

步骤S2B2：车载终端从事故车辆的环境图像中确定事故图像。

其中，事故图像可以是用于对交通事故进行评估的图像。事故图像可以包括事故车辆损伤图像、事故人员的伤亡图像等。在本申请实施例中，车载终端可以将事故车辆的环境图像输入至预先训练完成的机器学习模型中，得到机器学习模型输出的识别结果，根据识别结果确定该环境图像是否为事故图像。由于该机器学习模型是预先经过大量的训练样本训练完成得到的，因此，可以用于识别事故车辆的环境图像是否为事故图像。

可以看出，车载终端通过获取预设时间段内事故车辆的环境图像，再从事故车辆的环境图像中确定事故图像。如此，可以提高事故图像获取的效率和准确性。

步骤S202：交警服务器根据出警请求消息，生成出警提示消息。

具体地，交警服务器在获取到出警请求消息之后，可以根据出警请求消息中携带的事故车辆的标识信息、事故地点信息和事故图像等信息生成出警提示消息。该出警提示消息用于指示交警即将出警。出警提示消息可以包括出警成员、预计到达时间和出警成员的实时位置等信息。其中出警成员可以包括出警人数、出警名单、警号和出警人员的联系方式等信息。

示例地，出警提示消息可以是“出警人数：1人，出警名单：小A，警号：123456，目前位于人民路100号，预计5分钟到达事故发生地”，也可以是“出警人数：2人，出警名单：小A，警号：123456，小B，警号：654321。小A目前位于人民路100号，预计5分钟到达事故发生地；小B目前位于民族路300号，预计8分钟到达事故发生地”等。

在本申请实施例中，交警可以随身携带执法设备，该执法设备包括位置服务装置。该执法设备可以包括但不限于智能手机、可穿戴设备(例如智能手环)、对讲机、平板电脑(pad)、膝上型计算机(laptop)、导航仪等电子设备。该执法设备与交警服务器可以通过有线或无线方式进行通信，可以实时将自身的位置信息发送给交警服务器。交警服务器可以根据接收到的执法设备的实时位置信息获取交警的实时位置信息。并且可以将交警的实时位置信息生成出警提示消息，发送给事故车辆的车载终端，使得在交通事故发生后向用户呈现的出警提示消息中可以携带出警成员的实时位置信息，事故人员可以根据出警提示消息快速了解交警的实时位置信息，有利于提高用户的体验度以及缓解用户的焦急心理。

请参阅图2C，图2C是本申请实施例提供了一种确定预计到达时间的方法的流程示意图，可以包括以下步骤S2C1-S2C3，其中:

步骤S2C1：交警服务器根据事故地点信息确定待出发路线。

步骤S2C2：交警服务器获取待出发路线的路段特征。

其中，待出发路线是指交警赶往事故地点的路线。具体地，交警服务器在确定出警成员后，可以获取出警成员的位置信息，然后根据出警成员的位置信息以及事故地点信息确定待出发路线。确定出警成员的具体实现方式可以参考下文的描述，在此不做赘述。待出发路线可以是基于出警成员的位置和事故地点确定的完整路线；具体地，待出发路线可以是跟出警的交通工具相适配的驾驶路线或者骑行路线，出警的交通工具可以是汽车或者摩托车等等。可以理解的是，待出发路线可以是距离最近的路线，也可以是红绿灯数量最少的路线等，对此不做限定。

在本申请实施例中，待出发路线可以包括一条路段，或者包括多条路段。待出发路线可以用路段序列来表征。每条路段分配与之对应的唯一的路段标识，即link ID。每条路段都对应有至少一个路段特征，这些路段特征可以影响该路段的通行时长。其中，路段特征可以包括路段长度、红绿灯数量和平均限速，还可以包括拥堵路段和当前时刻的路况等信息。

步骤S2C3：交警服务器根据路段特征确定预计到达时间。

其中，预计到达时间可以是指按照通行方式预估通行一条路线所需耗费的估计时长。在本申请实施例中，交警服务器在获取到待出发路线的路段特征之后，可以针对路段特征进行权重分配，不同路段特征分配的权重值不同。示例地，拥堵路段越多，权重值越大；红绿灯数量越少，权重值越小等。此外，路段特征权重值越大，预计耗费时间也越长。最后对待出发路线的所有路段特征进行加权计算，得到加权计算结果，根据加权计算结果，得到待出发路线对应的预计到达时间。

可以看出，交警服务器根据事故地点信息确定待出发路线之后，获取待出发路线的路段特征，最后可以根据出警路线的路段特征确定警力的预计到达时间，从而可以提高出警提示消息的准确性。

步骤S203：车载终端接收交警服务器发送的出警提示消息。

交警服务器根据出警请求消息，生成出警提示消息之后，将出警提示消息发送至车载终端。相应地，车载终端接收交警服务器发送的出警提示消息。

步骤S204：车载终端呈现出警提示消息。

车载终端接收到交警服务器发送的出警提示消息之后，可以将该出警提示消息显示在车载终端显示屏或抬头显示器(HUD)中，还可以语音播报该出警提示消息，以便车载终端对应的用户能够及时接收到该出警提示消息。其中，用户可以是驾驶员或者乘车人员等。

可选地，车载终端还可以向用户相关联的移动终端发送出警提示消息，便于用户及时接收到该出警提示消息。移动终端可以包括但不限于智能手机、可穿戴设备(例如智能手环)、对讲机、平板电脑(pad)、膝上型计算机(laptop)、导航仪等电子设备。该移动终端与车载终端可以通过有线或无线方式进行通信，因此可以接收该出警提示消息。

在图2A所示的方法中，可以看出，当车载终端检测到交通事故之后，会向交警服务器发送出警请求消息。交警服务器根据出警请求消息中的事故车辆标识信息和事故地点信息，生成出警提示消息以发送至车载终端。车载终端接收交警服务器发送的出警提示消息，并呈现出警提示消息。其中，出警提示消息包括出警成员、预计到达时间和出警成员的实时位置信息。如此，车载终端在检测到交通事故时，可以及时报警，节省用户的时间和精力，有助于提高交通事故的处理效率。此外，用户可以从出警提示消息中及时获取交警的实时位置信息，以实现信息互通，有助于提升用户的体验以及缓解用户的焦急心理。

请参照图3，图3是本申请实施例提供的另一种处理交通事故的方法的流程示意图，可以包括以下步骤S301-S308，其中：

步骤S301：车载终端获取车辆内外的环境图像，根据车辆内外的环境图像检测是否发生交通事故。

车辆内外的环境图像的定义可以参考前文的定义，车辆内外的环境图像获取的具体实现方式可以参考前文的描述，在此不做赘述。

在本申请实施例中，车载终端可以通过图像处理技术监测是否发生交通事故。具体地，可以将车辆内外的环境图像输入至预先训练完成的机器学习模型中，得到机器学习模型输出的识别结果，根据识别结果确定是否发生交通事故。由于该机器学习模型是预先经过大量的训练样本训练完成得到的，因此，可以用于检测是否有交通事故发生。

以下对该机器学习模型的预训练过程可以包括以下步骤：

预先收集车辆内外的多个样本环境图像；标记各个样本环境图像对应的标准识别结果，标准识别结果包括发生交通事故或未发生交通事故；将多个样本环境图像作为输入至机器学习模型，得到机器学习模型输出的训练识别结果；获取训练识别结果和标准识别结果之间的误差函数，误差函数或训练次数满足预设条件，比如误差小于5％，训练次数大于或等于样本环境图像的数量等，则确定该机器学习模型训练完成。否则，基于误差函数对机器学习模型的模型参数进行调整。

步骤S302：车载终端根据传感技术检测是否发生交通事故。

在一种可能的实施方式中，步骤S302可以包括以下步骤：

获取车辆的重力加速度以及角速度；根据重力加速度以及角速度，确定车辆是否发生交通事故。

在本申请实施例中，可以在车辆上安装有重力加速度传感装置和角速度传感装置，传感装置安装的位置可以是车辆前窗玻璃上或者车辆的其他位置，在此不做限定。其中，重力加速度传感装置可以用于检测车辆的重力加速度，角速度传感装置可以用于检测车辆的角速度。重力加速度传感装置和角速度传感装置均可以与车载终端通过有线或无线方式进行通信。车载终端通过获取重力加速度传感装置采集的车辆重力加速度和角速度，然后根据采集到的车辆重力加速度和角速度确定车辆是否发生交通事故。

在一种可能的实施方式中，根据重力加速度以及角速度，确定车辆是否发生交通事故，具体可以包括以下步骤：

响应于重力加速度大于预设重力加速度以及角速度大于预设角速度，确定车辆发生交通事故。

在本申请实施例中，预设重力加速度可以为车辆正常行驶，未发生交通事故时的重力加速度；预设角速度可以为车辆正常行驶，未发生交通事故时的角速度。预设的重力加速度和角速度是预先设定的参数设数，重力加速度和预设角速度的具体可以根据历史经验进行设置，也可以根据实际情况进行具体分析设置，对此不做限定。示例地，预设重力加速度可以是0g-1g；预设角速度可以是-10°/秒-10°/秒。

除此之外，也可以通过超声波雷达或者其他传感器判定目标车辆发生交通事故，在此不做限定。

需要说明的是，在本申请实施例中，可以执行步骤S301或步骤S302中的一个步骤来确定车辆是否发生交通事故，也可以同时执行步骤S301和步骤S302来确定车辆是否发生交通事故，在此不做限定。

可以看出，车载终端通过图像处理技术和/或传感技术检测车辆是否发生交通事故，有利于提高交通事故确定的准确性和效率。

步骤S303：车载终端响应于检测到交通事故，控制智能助手向用户提供报警入口。

步骤S304：车载终端响应于接收到用户在报警入口输入的报警指令，控制智能助手向交警服务器发送出警请求消息。

在本申请实施例中，车载终端可以安装有智能助手，该智能助手能够与用户进行语音、文字等方式的交互。可以用于帮助用户处理交通事故，包括但不限于向用户提供报警入口、与移动终端或交警服务器进行通信等。

具体地，智能助手在没有发生交通事故的时候，可以处于休眠状态，有助于节约能耗。当车载终端检测到发生交通事故时，则可以自动触发智能助手的开启。智能助手开启后，可以在车载终端显示屏上向用户提供报警入口，便于用户及时报警，从而提高交通事故的处理过程的智能性。可以理解的是，用户可以根据实际需要确定是否报警。此外，智能助手还可以以语音播报等方式询问用户是否需要报警，在此不做限定。

在一种可能的实施方式中，车载终端还可以根据事故图像初步判定事故等级，具体的实现方法可以参考图4B中交警服务器根据事故图像确定事故等级的方法，在此不做赘述。车载终端根据初步判定的事故等级可以向用户提供是否报警的建议，并控制智能助手向用户展示该建议。示例地，该建议可以是“初步判定事故等级为轻微事故，建议私下协商，无需报警，请选择是否需要提供报警入口”，或者可以是“初步判定事故等级为严重事故，建议报警，请选择是否需要提供报警入口”。

当车载终端接收到用户在该报警入口输入的报警指令之后，可以控制智能助手向交警服务器发送出警请求消息。出警请求消息的定义可以参考前文的描述，在此不做赘述。

可选地，车载终端若在预设时长内(例如5分钟等)未接收到用户是否报警的反馈，还可以控制智能助手向车载终端相关联的移动终端提供该报警入口，便于用户及时接收到该报警入口。若车载终端在预设时长内(例如3分钟等)仍然未接收到用户是否报警的反馈，车载终端可以控制智能助手自动发送该出警请求消息。如此，可以避免出现用户受伤无法报警的情况，可以提高报警的及时性。

可以看出，车载终端在检测到交通事故之后，可以自动控制智能助手向用户提供报警入口，供用户及时报警，可以提高交通事故处理过程的智能性。

步骤S305：交警服务器根据出警请求消息，生成出警提示消息。

步骤S306：车载终端接收交警服务器发送的出警提示消息。

应理解，步骤S305和步骤S306与步骤S202和步骤S203对应，步骤S305和步骤S306中的相关描述可以参见上述步骤S202和步骤S203的描述，此处为了避免重复，不再赘述。

步骤S307：车载终端控制智能助手向用户呈现出警提示消息，以及控制智能助手基于预定时间间隔更新实时位置信息和预计到达时间。

其中，预设时间间隔可以是原先设定的参数，其具体取值可以根据实际应用场景进行设置。示例地，可以是1分钟或2分钟。在本申请实施例中车载终端接收到交警服务器发送的出警提示消息之后，可以将控制智能助手向用户呈现出警提示消息。交警出发之后，交警服务器可以实时获取出警人员的实时位置。预计到达时间的具体确定方式可以参考前文的描述，在此不做赘述。预计到达时间可以根据事故地点信息和出警人员的实时位置动态变化。在本申请实施例中，交警服务器可以实时更新出警提示消息中出警人员的实时位置信息和预计到达时间，并可以将更新后的出警提示消息发送给车载终端，车载终端在接收到更新的出警提示消息后可以控制智能助手基于预定时间间隔对出警人员的实时位置信息和预计到达时间进行更新，以便呈现给用户。

步骤S308：车载终端向事故车辆的预设范围内的非事故车辆广播出警提示消息，以提示非事故车辆进行避让。

其中，预设范围可以是预先设定的参数，具体可以根据历史经验进行设置，也可以根据实际情况进行具体分析设置。示例地，预设范围可以设置为1公里或者3公里等。

非事故车辆可以是指没有发生交通事故或者暂时没有被交通事故波及的车辆。其中，广播的方式可以是设备到设备(device to device，D2D)技术向预设范围内的用户呈现出警提示消息，D2D技术可以不需要通过中心节点，即基站进行转发，有利于提高传输的效率。当发生交通事故时，车载终端可以采用D2D技术向事故车辆的预设范围内的非事故车辆通过直连链路进行数据包传输的方式传递出警提示消息。

在本申请实施例中，出警提示消息中可以携带事故车辆的位置信息以及警车的实时位置信息。具体地，出警提示消息可以显示有具体的车道级地图，以便非事故车辆对应的驾驶员可以通过车道级地图确定事故发生的具体车道，以及警车在哪个车道上行驶，从而更精细化引导非事故车辆避开事故车辆以及警车所在的车道。在一种可能的实施方式中，可以通过全球定位***(global positioning system，GPS)，并结合地图匹配方法(mapmatching，MM)来定位事故车辆的精确位置和警车的精确位置。GPS/MM的基本思路是将事故车辆和警车的GPS定位信息与路网数据库中的路网信息进行比对，校正GPS定位信息的误差，由此确定事故车辆的精确位置信息和警车的精确位置信息。在另一种可能的实施方式中，还可以通过路侧设备采集到的信息定位事故车辆的精确位置信息和警车的精确位置信息；其中，路侧设备可以包括摄像头、交通灯等等。具体地，交警服务器可以通过与路侧设备进行交互，获取路侧设备采集到的信息(例如，道路图像信息，交通灯位置等信息)，然后根据路侧设备采集到的信息定位事故车辆的精确位置信息和警车的精确位置信息。当然，上述定位事故车辆的精确位置信息和警车的精确位置信息的方式在实际应用中可以单独实施，也可以相互结合实施，本申请实施例对此不做限定。在本申请实施例中，出警提示消息可以显示在非事故车辆的车载终端显示屏或抬头显示器(HUD)中，还可以语音播报该出警提示消息，以便非事故车辆对应的驾驶员能够及时接收到该出警提示消息，从而对事故车辆以及警车进行及时避让。

可以看出，车载终端接收到出警提示消息之后，可以控制智能助手向用户呈现并更新该出警提示消息。如此，可以使得整个交通事故的处理过程具有较高的智能性，便于提高用户的体验。在交通事故发生之后，还可以向事故车辆的预设范围内的非事故车辆广播出警提示消息，以提示非事故车辆进行避让，有利于避免道路拥堵，便于警力更顺利地抵达事故现场，同时有利于防止发生二次交通事故。

在图3所示的方法中，可以看出，车载终端采用图像处理技术和/或传感技术检测到是否交通事故，有利于提高交通事故确定的准确性和效率。在检测到发生交通事故之后，控制智能助手向用户提供报警入口，供用户选择是否报警，使得整个交通事故的处理过程具有较高的灵活性、适用性和智能性。车载终端在接收到可以交警服务器根据出警请求消息生成的出警提示消息之后，通过制智能助手向用户呈现并更新该出警提示消息，可以使得整个交通事故的处理过程具有较高的智能性，便于提高用户的体验。或者车载终端向事故车辆的预设范围内的非事故车辆广播出警提示消息，以提示非事故车辆进行避让，可以避免道路拥堵，防止发生二次交通事故。

请参照图4A，图4A是本申请实施例提供的另一种处理交通事故的方法的流程示意图，可以包括以下步骤S401-S407，其中：

步骤S401：车载终端响应于检测到交通事故，向交警服务器发送出警请求消息。

应理解，步骤S401与步骤S201对应，步骤S401中的相关描述可以参见上述步骤S201的描述，此处为了避免重复，不再赘述。

步骤S402：交警服务器根据事故图像确定事故等级。

其中，事故等级用于表征交通事故的严重程度。示例地，事故等级可以是轻微事故、一般事故、严重事故、特大事故等。事故图像可以是从出警请求消息中获取。可选地，也可以从预设范围内的其他车辆中获取，或者还可以根据道路监控摄像头拍摄的图像中获取事故图像。

在一种可能的实施方式中，步骤S402具体可以包括图4B所示的步骤S4B1-S4B3。其中：

步骤S4B1：交警服务器对事故图像中各个特征进行聚类，得到目标特征集合。

在本申请实施例中，事故图像的各个特征可以包括事故车辆、人物、斑马线、被撞物体等特征。交警服务器可以通过时间差分法或者光流法等方法从事故图像中检测出现的各个特征，进而将各个特征从事故图像中提取出来。

在本申请实施例中，交警服务器可以对事故图像的各个特征进行聚类，将同一特征划分到一个聚类中，得到目标特征集合。其中，目标特征集合至少有一个特征。也就是说，目标特征集合为具有相同特征的集合。示例地，目标特征集合可以是发生过形变的事故车辆，也可以是倒在地上的行人，还可以是被撞物体等等。

步骤S4B2：交警服务器将目标特征集合输入至事故等级检测模型中，得到各个特征的事故等级检测结果。

在本申请实施例中，事故等级检测模型记录有目标特征集合与事故等级检测结果的映射关系。其中，事故等级检测结果可以用文字或者是数值等形式来表示。例如，当目标特征集合为事故车辆对应的特征以及人物对应的特征，且事故车辆的具体特征表现为车体严重变形的车辆，人物的具体特征表现为倒地的行人时，其对应的事故等级检测结果可以是严重事故；或者，当目标特征集合为事故车辆对应的特征，且事故车辆的具体特征表现为后视镜轻微刮擦时，其对应的事故等级检测结果可以是轻微事故等等。因此，将目标特征集合输入至预先训练好的事故等级检测模型中，可以得到各个特征的事故等级检测结果。

事故等级检测模型是基于机器学习算法训练得到的。可以是基于聚类算法训练得到的聚类模型，也可以是神经网络模型，还可以是深度学习模型或者是卷积神经网络模型等等。示例地，可以是极端梯度提升(eXtreme gradient boosting，Xgboost)、卷积神经网络(convolutional neural networks，CNN)、循环神经网络(recurrent neural network，RNN)、全卷积网络(fully convolutional networks，FCN)；也可以是长短期记忆网络模型(long short-term memory，LSTM)、支持向量机(support vector machine，SVM)等模型中的一种或多种，对此不做限定。

步骤S4B3：交警服务器根据各个特征的事故等级检测结果确定事故等级。

交警服务器通过事故等级检测模型得到各个特征的事故等级检测结果之后，可以对各个特征的事故等级检测结果分别赋予预设权值，然后根据预设权值对各事故等级检测结果进行加权计算，根据加权计算得到的结果确定事故等级。各个特征的事故等级检测结果的预设权值具体可以根据历史经验进行设置，也可以根据实际情况进行具体分析设置。示例地，事故等级检测结果可以用事故分值的形式进行表征，不同的事故分值对应不同的事故等级。例如，当事故等级检测结果对应的事故分值的取值范围为[0,1]时，其对应的事故等级可以为轻微事故；当事故等级检测结果对应的事故分值的取值范围为[1,2]时，其对应的事故等级可以为一般事故；当事故等级检测结果对应的事故分值的取值范围为[2,3]时，其对应的事故等级可以为严重事故；当事故等级检测结果对应的事故分值的取值范围为[3,4]时，其对应的事故等级可以为特大事故。可以理解的是，事故分值越高，其对应的事故等级越严重。示例地，特征为人物时，其对应的事故等级检测结果的预设权值可以设置为0.9；特征为事故车辆时，其对应的事故等级检测结果的预设权值可以设置为0.8；特征为被撞物体时，其对应的事故等级检测结果的预设权值可以设置为0.7；其中，特征为人物时，其对应的事故分值可以为3；特征为事故车辆时，其对应的事故分值可以为4；特征为被撞物体时，其对应的事故分值可以为2；对各个特征的事故等级检测结果进行加权计算后，得到的加权计算结果S可以是：

可以理解的是，对各个特征的事故等级检测结果进行加权计算后，得到的加权计算结果为3.4，属于[3,4]的范围内，因此，对应的事故等级为特大事故。

可以看出，交警服务器通过对事故图像中各个特征进行聚类，得到目标特征集合，并将其输入至事故等级检测模型中，得到各个特征的事故等级检测结果。最后，再根据各个特征的事故等级检测结果确定事故等级。通过实施本申请实施例，能够在交通事故发生后基于事故地点和事故等级来确定对应的出警成员，可以提高警力资源分配的合理性以及出警效率。

步骤S403：交警服务器根据事故地点信息和事故等级确定出警成员。

其中，出警成员可以包括出警人数和出警名单。在一种可能的实施方式中，步骤S403具体可以包括图4C所示的步骤S4C1-S4C3。其中：

步骤S4C1：交警服务器根据事故等级确定出警人数。

在本申请实施例中，交警服务器可以根据事故等级的高低来确定出警人数。事故等级越高，出警人数越多。示例地，若事故等级为轻微事故，则出警人数可以是1人；若事故等级为严重事故，则出警人数可以为5人或以上。

步骤S4C2：交警服务器根据事故地点信息确定出警名单。

其中，出警名单可以是出警的具体人员。在一种可能的实施方式中，步骤S4C2具体可以包括图4D所示的步骤S4D1-S4D3。其中：

步骤S4D1：交警服务器根据事故地点信息确定事故地点信息所指示区域内的至少一个空闲警员。

在本申请实施例中，事故地点信息所指示区域可以是事故地点附近的辖区。示例地，可以是事故发生地方圆内3公里或者5公里的辖区。空闲警员可以是对应辖区内的事务相对较少的交警。

步骤S4D2：交警服务器计算至少一个空闲警员的至少一个预计到达时间。

预计到达时间的计算方法可以参考图2C的方法，在此不做赘述。

步骤S4D3：基于至少一个预计到达时间，确定出警名单。

在得到至少一个空闲警员的至少一个预计到达时间的计算结果之后，根据出警人数，出警名单为预计到达时间最短的几名空闲警员。示例地，出警人数为2人，出警名单可以是预计到达时间最短的两名空闲警员。

可以看出，通过事故地点信息确定事故地点信息所指示区域内的至少一个空闲警员，然后基于至少一个空闲警员的至少一个预计到达时间确定出警名单，可以缩短出警的时间，从而提高交通事故的处理效率。

步骤S4C3：交警服务器根据出警人数和出警名单确定出警成员。

示例地，“出警人数：1人，出警名单：小A”，也可以是“出警人数：2人，出警名单：小A，小B”。

可以看出，根据事故等级确定出警人数之后，根据事故地点信息确定出警名单，最后再根据出警人数和出警名单确定出警成员。如此，可以快速确定能够最快抵达事故现场的出警人员，有利于提高出警的效率。

步骤S404：交警服务器获取出警成员的实时位置信息。

在本申请实施例中，出警成员中的每一位交警在出警之前，可以配置有执法设备。执法设备的定义和功能可以参考前文的描述，在此不做赘述。交警服务器可以根据接收到的执法设备的实时位置信息获取出警成员的实时位置信息。

步骤S405：交警服务器生成出警提示消息。

交警服务器可以根据出警成员、出警成员的实时位置信息生成出警提示消息。出警提示消息还可以包括预计到达时间、出警人员的身份信息和出警人员的联系方式等信息。具体的示例可以参考前文的描述，在此不做赘述。

步骤S406：交警服务器向车载终端发送出警提示消息。

相应地，车载终端接收该出警提示消息。

步骤S407：车载终端在与用户关联的车载终端或者移动终端上呈现出警提示消息。

车载终端接收到交警服务器发送的出警提示消息之后，可以将该出警提示消息显示在车载终端显示屏或抬头显示器(HUD)中，还可以语音播报该出警提示消息，以便车载终端对应的用户能够及时接收到该出警提示消息。或者，车载终端也可以向用户相关联的移动终端发送出警提示消息，便于用户及时接收到该出警提示消息。

在一种可能的实施方式中，出警成员的实时位置信息在与用户关联的车载终端或者移动终端的地图模块上显示。其中，地图模块可以是车载终端和移动终端自带的地图软件，也可以是第三方的地图软件。

可以看出，将出警成员的实时位置信息在于用户关联的车载终端或者移动终端的地图模块上显示，可以使得用户能更直观地获取出警成员的实时位置信息，以提高用户的体验。

在图4A所示的方法中，可以看出，车载终端在检测到交通事故之后，向交警服务器发送出警请求消息。交警服务器根据出警请求消息生成包括出警成员和出警成员的实时位置在内的出警提示消息之后，将其发送给车载终端。其中，出警成员根据事故地点信息和事故等级确定，事故等级根据事故图像确定。如此，可以使得生成的出警提示消息更有针对性，从而提高处理交通事故的效率。车载终端接收到该出警提示消息之后，在与用户关联的车载终端或者移动终端上呈现出警提示消息，有助于用户及时接收到该出警提示消息。

上述详细阐述了本申请实施例的方法，下面提供了本申请实施例的装置。

请参照图5，图5是本申请实施例提供的一种处理交通事故的装置的结构示意图。如图5所示，该处理交通事故的装置可以包括至少一个传感器501、至少一个处理器502和显示组件503。其中，传感器501、处理器502和显示组件503通过总线505可通信地连接。

当处理交通事故的装置为车载终端时，各个模块的详细描述如下：

传感器501，可以是重力加速度传感器、角速度传感器、超声波雷达等，可与处理器502通信连接，其被配置为：

检测是否发生交通事故。

处理器502，可以是数字处理器，其被配置为：

响应于至少一个传感器检测到发生交通事故，向交警服务器发送出警请求消息，出警请求消息包括事故车辆的标识信息和事故地点信息；以及

接收交警服务器发送的出警提示消息，出警提示消息包括出警成员、预计到达时间和出警成员的实时位置信息。

显示组件503，可以是车辆显示屏、抬头显示器(HUD)或者是移动终端显示屏等，其被配置为：

呈现出警提示消息。

在一种可能的实施方式中，处理器502进一步被配置为：

响应于至少一个传感器检测到交通事故，控制智能助手向用户提供报警入口；以及

响应于至少一个处理器接收到用户在报警入口输入的报警指令，向交警服务器发送出警请求消息。

在一种可能的实施方式中，处理器502进一步被配置为：

获取预设时间段内事故车辆的环境图像；以及

从事故车辆的环境图像中确定事故图像。

在一种可能的实施方式中，出警成员根据事故地点信息和事故等级确定，事故等级根据事故图像确定。

在一种可能的实施方式中，显示组件503进一步被配置为：

控制智能助手向用户呈现出警提示消息，以及控制智能助手基于预定时间间隔更新实时位置信息和预计到达时间；以及

向事故车辆的预设范围内的非事故车辆广播出警提示消息，以提示非事故车辆进行避让。

在一种可能的实施方式中，显示组件503进一步被配置为：

在与用户关联的车载终端或者移动终端上呈现出警提示消息，其中，实时位置信息在与用户关联的车载终端或者移动终端的地图模块上显示。

在一种可能的实施方式中，处理器502进一步被配置为：

获取车辆内外的环境图像；以及

根据车辆内外的环境图像检测是否发生交通事故；

传感器501进一步被配置为：

根据传感技术检测是否发生交通事故。

当处理交通事故的装置为交警服务器时，各个模块的详细描述如下：

处理器502被配置为：

获取车载终端发送的出警请求消息，出警请求消息包括事故车辆的标识信息和事故地点信息；以及

根据出警请求消息，生成出警提示消息以发送至车载终端，出警提示消息包括出警成员、预计到达时间和出警成员的实时位置信息。

在一种可能的实施方式中，出警请求消息包括事故图像，处理器502进一步被配置为：

根据事故图像确定事故等级；

根据事故地点信息和事故等级确定出警成员；

获取出警成员的实时位置信息；以及

生成出警提示消息以发送至车载终端，出警提示消息包括出警成员、预计到达时间和出警成员的实时位置信息。

在一种可能的实施方式中，处理器502进一步被配置为：

根据事故等级确定出警人数；

根据事故地点信息确定出警名单；以及

根据出警人数和出警名单确定出警成员。

在一种可能的实施方式中，处理器502进一步被配置为：

根据事故地点信息确定事故地点信息所指示区域内的至少一个空闲警员；

计算至少一个空闲警员的至少一个预计到达时间；以及

基于至少一个预计到达时间，确定出警名单。

在一种可能的实施方式中，处理器502进一步被配置为：

根据事故地点信息确定待出发路线，待出发路线至少包括一条路段；

获取待出发路线的路段特征，路段特征包括路段长度、红绿灯数量和平均限速；以及

根据路段特征确定预计到达时间。

请参照图6，图6是本申请实施例提供的一种计算机设备的结构示意图。如图6所示，该计算机设备600包括处理器601、存储器602和通信接口603，其中，处理器601、存储器602和通信接口603之间可以通过总线604连接。存储器602中存储有计算机程序6024，计算机程序6024被配置由上述处理器601执行，计算机程序6024以实现如上述方法实施例对应的方法步骤。

处理器601用于执行该存储器602存储的指令，以控制通信接口603接收和发送信号，完成上述方法中的步骤。其中，存储器602可以集成在处理器601中，也可以与处理器601分开设置。

存储器602中还可以包括存储***6021、高速缓存6022和随机存取存储器(randomaccess memory，RAM)6023。其中高速缓存6022是存在于RAM6023与中央处理器(centralprocessing unit，CPU)之间的一级存储器，由静态存储芯片(SRAM)组成，容量比较小但速度比主存高得多，接近于CPU的速度；RAM6023是与CPU直接交换数据的内部存储器，可以随时读写(刷新时除外)，而且速度很快，通常作为操作***或其他正在运行中的程序的临时数据存储介质。三者结合实现存储器602功能。

作为一种实现方式，通信接口603的功能可以考虑通过收发电路或者收发的专用芯片实现。处理器601可以考虑通过专用处理芯片、处理电路、处理器或者通用芯片实现。

作为另一种实现方式，可以考虑使用通用计算机的方式来实现本申请实施例提供的装置。即将实现处理器601，通信接口603功能的程序代码存储在存储器602中，通用处理器通过执行存储器602中的代码来实现处理器601，通信接口603的功能。

该装置所涉及的与本申请实施例提供的技术方案相关的概念，解释和详细说明及其他步骤请参见前述方法或其他实施例中关于装置执行的方法步骤的内容的描述，此处不做赘述。

作为本实施例的另一种实现方式，提供一种计算机可读存储介质，其上存储有指令，该指令被执行时执行上述方法实施例中的方法。

作为本实施例的另一种实现方式，提供一种包含指令的计算机程序产品，该指令被执行时执行上述方法实施例中的方法。

根据本申请实施例提供的方法和装置，本申请实施例还提供一种***，其组成方式可以参见图1所示，执行的方法可以参见方法实施例中的描述，此处不再赘述。

作为本实施例的另一种实现方式，计算机设备600可以与一个或多个外部设备605(例如车载终端、移动终端或可穿戴设备)通信，和/或与使得该计算机设备能与一个或多个其它计算设备进行通信的任何设备(例如网卡，调制解调器等等)通信。这种通信可以通过通信接口603进行。应当明白，尽管图中未示出，可以结合另一种计算机设备使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID***、磁带驱动器以及数据备份存储***等。

本领域技术人员可以理解，为了便于说明，图6中仅示出了一个存储器和处理器。在实际的终端或服务器中，可以存在多个处理器和存储器。存储器602也可以称为存储介质或者存储设备等，本申请实施例对此不做限定。

应理解，在本申请实施例中，处理器601可以是中央处理单元(centralprocessing unit，CPU)，该处理器还可以是其他通用处理器、数字信号处理器(digitalsignal processing，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现成可编程门阵列(field－programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。

还应理解，本申请实施例中提及的存储器602可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic RAM，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double datarate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器synchronize link DRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。

需要说明的是，当处理器601为通用处理器、DSP、ASIC、FPGA或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件时，存储器(存储模块)集成在处理器中。

应注意，本文描述的存储器602旨在包括但不限于这些和任意其它适合类型的存储器。

该总线604除包括数据总线之外，还可以包括电源总线、控制总线和状态信号总线等。但是为了清楚说明起见，在图中将各种总线都标为总线。

在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。为避免重复，这里不再详细描述。

在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各种说明性逻辑块(illustrative logical block，ILB)和步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

在本申请所提供的几个实施例中，应该理解到，所揭露的***、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本申请实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘)等。

本申请实施例还提供一种计算机存储介质，计算机可读存储介质存储有计算机程序，计算机程序被处理器执行以实现如上述方法实施例中记载的任何一种处理交通事故的方法的部分或全部步骤。

本申请实施例还提供一种计算机程序产品，计算机程序产品包括存储了计算机程序的非瞬时性计算机可读存储介质，计算机程序可操作来使计算机执行如上述方法实施例中记载的任何一种处理交通事故的方法的部分或全部步骤。

以上，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (16)

1.一种处理交通事故的方法，其特征在于，包括以下步骤：

响应于检测到交通事故,向交警服务器发送出警请求消息，所述出警请求消息包括事故车辆的标识信息和事故地点信息；

接收所述交警服务器发送的出警提示消息，所述出警提示消息包括出警成员、预计到达时间和所述出警成员的实时位置信息；以及

呈现所述出警提示消息。

2.根据权利要求1所述的方法，所述响应于检测到交通事故，向交警服务器发送交警请求消息，包括以下步骤：

响应于检测到所述交通事故，控制智能助手向用户提供报警入口；以及

响应于接收到所述用户在所述报警入口输入的报警指令，向所述交警服务器发送所述出警请求消息。

3.根据权利要求1或2所述的方法，所述出警请求消息包括事故图像，所述事故图像基于以下步骤确定：

获取预设时间段内所述事故车辆的环境图像；以及

从所述事故车辆的环境图像中确定事故图像。

4.根据权利要求3所述的方法，所述出警成员根据所述事故地点信息和事故等级确定，所述事故等级根据所述事故图像确定。

5.根据权利要求1所述的方法，所述呈现所述出警提示消息，包括以下步骤中的至少一项：

控制智能助手向用户呈现所述出警提示消息，以及控制所述智能助手基于预定时间间隔更新所述实时位置信息和所述预计到达时间；以及

向所述事故车辆的预设范围内的非事故车辆广播所述出警提示消息，以提示所述非事故车辆进行避让。

6.根据权利要求1或5所述的方法，所述呈现所述出警提示消息，包括以下步骤：

在与用户关联的车载终端或者移动终端上呈现所述出警提示消息，其中，所述实时位置信息在所述与用户关联的车载终端或者移动终端的地图模块上显示。

7.根据权利要求1所述的方法，所述响应于检测到交通事故，向交警服务器发送出警请求消息之前，还包括以下步骤：

获取车辆内外的环境图像；以及

根据所述车辆内外的环境图像检测是否发生交通事故；或者

根据传感技术检测是否发生交通事故。

8.一种处理交通事故的方法，其特征在于，包括以下步骤：

获取车载终端发送的出警请求消息，所述出警请求消息包括事故车辆的标识信息和事故地点信息；以及

根据所述出警请求消息，生成出警提示消息以发送至所述车载终端，所述出警提示消息包括出警成员、预计到达时间和所述出警成员的实时位置信息。

9.根据权利要求8所述的方法，所述出警请求消息包括事故图像，所述根据所述出警请求消息，生成出警提示消息以发送至所述车载终端，包括以下步骤：

根据所述事故图像确定事故等级；

根据所述事故地点信息和所述事故等级确定出警成员；

获取所述出警成员的实时位置信息；以及

生成出警提示消息以发送至所述车载终端，所述出警提示消息包括所述出警成员、预计到达时间和所述出警成员的实时位置信息。

10.根据权利要求9所述的方法，所述根据所述事故图像确定事故等级，包括以下步骤：

对所述事故图像中各个特征进行聚类，得到目标特征集合；

将所述目标特征集合输入至事故等级检测模型中，得到各个特征的事故等级检测结果；以及

根据所述各个特征的事故等级检测结果确定事故等级。

11.根据权利要求9所述的方法，所述根据所述事故地点信息和所述事故等级确定出警成员，包括以下步骤：

根据所述事故等级确定出警人数；

根据所述事故地点信息确定出警名单；以及

根据所述出警人数和所述出警名单确定出警成员。

12.根据权利要求11所述的方法，所述根据所述事故地点信息确定出警名单，包括以下步骤：

根据所述事故地点信息确定所述事故地点信息所指示区域内的至少一个空闲警员；

计算所述至少一个空闲警员的至少一个预计到达时间；以及

基于所述至少一个预计到达时间，确定出警名单。

13.根据权利要求8-12任一项所述的方法，所述预计到达时间基于以下步骤确定：

根据所述事故地点信息确定待出发路线，所述待出发路线至少包括一条路段；

获取所述待出发路线的路段特征，所述路段特征包括路段长度、红绿灯数量和平均限速；以及

根据所述路段特征确定预计到达时间。

14.一种处理交通事故的装置，其特征在于，包括：至少一个传感器、显示组件以及与所述至少一个传感器和所述显示组件可通信地连接的至少一个处理器；其中，

所述至少一个传感器被配置为检测是否发生交通事故；

所述至少一个处理器被配置为：

响应于所述至少一个传感器检测到发生交通事故，向交警服务器发送出警请求消息，所述出警请求消息包括事故车辆的标识信息和事故地点信息；以及

接收所述交警服务器发送的出警提示消息，所述出警提示消息包括出警成员、预计到达时间和所述出警成员的实时位置信息；

所述显示组件被配置为呈现所述出警提示消息。

15.一种计算机设备，其特征在于，包括处理器、存储器和通信接口，其中，所述存储器存储有计算机程序，所述计算机程序被配置由所述处理器执行，所述计算机程序包括用于执行权利要求1-7或8-13中任一项方法中的步骤的指令。

16.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储计算机程序，所述计算机程序使得计算机执行以实现权利要求1-7或8-13中任一项所述的方法。