CN117241217A - 车辆紧急呼叫方法、装置、设备、系统及存储介质 - Google Patents

Abstract

本申请公开了一种车辆紧急呼叫方法、装置、设备、系统及存储介质。其中，该方法包括：基站接收通信覆盖范围内各车载终端发送的心跳包；检测到目标车载终端的心跳包中断，则基于所述目标车载终端历史发送的心跳包，生成SAAI并向救援服务平台发送SAAI，如此，可以在车载终端无法有效发出eCall的严重事故场景下，由基站向救援服务平台发送SAAI，进而使得救援服务平台可以快速、可靠地获取可信的车辆事故信息，从而提升事故救援速度和质量。

Description

车辆紧急呼叫方法、装置、设备、系统及存储介质

技术领域

本申请涉及车辆救援领域，尤其涉及一种车辆紧急呼叫方法、装置、设备、系统及存储介质。

背景技术

车辆紧急呼叫(Emergency-Call，eCall)是指在车辆内的传感器或控制器(如气囊系统)监测并判断车辆发生了严重的事故，车载事故紧急呼叫系统即被自动激活，车载终端将自动拨打紧急救援电话或者车内人员手动拨打eCall。通过将指示车辆状态信息的最小数据集(Minimum Set of Data，MSD)发送给公共安全应答系统(Public Safety AnsweringPoint，PSAP)，也称为救援服务平台，并随后建立与PSAP的通信链路，从而有效缩短事故救援响应时间，为事故受伤人员提供有效的医疗援助，并在尽可能短的时间内恢复道路秩序。

虽然车载终端具备人员手动拨打eCall或者自动拨打eCall的功能，但如遇到严重事故，车内人员昏迷、车载终端毁坏的情况下，可能无法发出eCall呼叫。这样会严重影响事故救援，导致事故受伤人员无法得到及时的救治，交通秩序长时间无法恢复。

发明内容

有鉴于此，本申请实施例提供了一种车辆紧急呼叫方法、装置、设备、系统及存储介质，旨在有效提升事故救援的速度和质量。

本申请实施例的技术方案是这样实现的：

第一方面，本申请实施例提供了一种车辆紧急呼叫方法，应用于基站，该方法包括：

接收通信覆盖范围内各车载终端发送的心跳包；

检测到目标车载终端的心跳包中断，则基于所述目标车载终端历史发送的心跳包，生成疑似事故警告信息(Suspected accident alarminformation，SAAI)，并向救援服务平台发送SAAI。

上述方案中，所述检测到目标车载终端的心跳包中断，包括：

若确定未接收到所述目标车载终端发送的心跳包的时长达到第一设定时长，且基于所述目标车载终端的移动性管理消息，确定所述目标车载终端处于所述基站的通信覆盖范围以及所述目标车载终端未关机，则判定所述目标车载终端的心跳包中断。

上述方案中，所述心跳包携带车载终端的位置信息、速度信息、航向信息及时间信息中的至少之一，所述方法还包括：

存储各所述车载终端在历史的第二设定时长内发送的心跳包；

所述基于所述目标车载终端历史发送的心跳包，生成SAAI，包括：

解析所述目标车载终端在历史的第二设定时长内发送的心跳包；

基于解析心跳包得到的信息，预测所述目标车载终端的状态信息；

基于所述目标车载终端的状态信息和所述目标车载终端的注册信息，生成SAAI；

其中，所述状态信息包括以下至少之一：事故位置信息、事故航向信息和事故时间信息，所述注册信息包括以下至少之一：车辆标识、燃油类别和载客人数。

上述方案中，所述方法还包括：

接收所述救援服务平台基于所述SAAI生成的确认后的事故告警通知；

向所述基站的通信覆盖范围内的各车载终端广播所述事故告警通知。

第二方面，本申请实施例提供了一种车辆紧急呼叫方法，应用于救援服务平台，所述方法包括：

接收基站发送的疑似事故警告信息(SAAI)；

基于所述SAAI，生成事故确认信息。

上述方案中，所述SAAI包括目标车载终端的状态信息和注册信息，所述状态信息包括以下至少之一：事故位置信息、事故航向信息和事故时间信息，所述注册信息包括以下至少之一：车辆标识、燃油类别和载客人数；所述基于所述SAAI，生成事故确认信息，包括：

基于所述SAAI，与所述目标车载终端和/或根据所述目标车载终端的位置确定的设定车载终端建立通信链路，生成事故确认信息。

上述方案中，所述基于所述SAAI，与所述目标车载终端和/或根据所述目标车载终端的位置确定的设定车载终端建立通信链路，生成事故确认信息，包括：

基于所述SAAI中携带的所述目标车载终端的车辆标识，向所述目标车载终端发起第一通话请求；

若基于所述第一通话请求与所述目标车载终端建立通信链路，则基于与所述目标车载终端的通话内容，生成事故确认信息；

若基于所述第一通话请求与所述目标车载终端未建立通信链路，则基于所述SAAI中携带的所述目标车载终端的事故位置信息确定与所述目标车载终端位置相近的设定车载终端，向所述设定车载终端发起第二通话请求，若基于所述第二通话请求与所述设定车载终端建立通信链路，则基于与所述设定车载终端的通话内容，生成事故确认信息。

上述方案中，所述方法还包括：

若基于所述事故确认信息确定所述目标车载终端所在车辆发生事故，则触发救援流程并向所述基站发送事故告警通知。

第三方面，本申请实施例提供了一种车辆紧急呼叫装置，应用于基站，所述装置包括：

获取模块，用于接收通信覆盖范围内各车载终端发送的心跳包；

告警模块，用于检测到目标车载终端的心跳包中断，则基于所述目标车载终端历史发送的心跳包，生成疑似事故警告信息(SAAI)，并向救援服务平台发送SAAI。

第四方面，本申请实施例提供了一种车辆紧急呼叫装置，应用于救援服务平台，所述装置包括：

接收模块，用于接收基站发送的疑似事故警告信息(SAAI)；

事故确认模块，用于基于所述SAAI，生成事故确认信息。

第五方面，本申请实施例提供了一种基站，包括：处理器和用于存储能够在处理器上运行的计算机程序的存储器，其中，所述处理器，用于运行计算机程序时，执行本申请实施例第一方面所述方法的步骤。

第六方面，本申请实施例提供了一种救援服务平台，包括：处理器和用于存储能够在处理器上运行的计算机程序的存储器，其中，所述处理器，用于运行计算机程序时，执行本申请实施例第二方面所述方法的步骤。

第七方面，本申请实施例提供了一种车辆紧急呼叫系统，包括本申请实施例第五方面所述的基站和本申请实施例第六方面所述的救援服务平台，所述基站与所述救援服务平台通信连接。

第八方面，本申请实施例提供了一种计算机存储介质，所述计算机存储介质上存储有计算机程序，所述计算机程序被处理器执行时，实现本申请实施例任一方面所述方法的步骤。

本申请实施例提供的技术方案，基站接收通信覆盖范围内各车载终端发送的心跳包；检测到目标车载终端的心跳包中断，则基于所述目标车载终端历史发送的心跳包，生成SAAI，并向救援服务平台发送SAAI，如此，可以在车载终端无法有效发出eCall的严重事故场景下，由基站向救援服务平台发送SAAI，进而使得救援服务平台可以快速、可靠地获取可信的车辆事故信息，从而提升事故救援速度和质量。

附图说明

图1为本申请实施例一车辆紧急呼叫方法的流程示意图；

图2为本申请一应用示例中SAAI的结构示意图；

图3为本申请实施例另一车辆紧急呼叫方法的流程示意图；

图4为本申请一应用示例中基于基站的车辆紧急呼叫系统的结构示意图；

图5为本申请一应用示例中车载终端事故预判的流程示意图；

图6为本申请一应用示例中PSAP事故确认的流程示意图；

图7为本申请实施例一车辆紧急呼叫装置的结构示意图；

图8为本申请实施例另一车辆紧急呼叫装置的结构示意图；

图9为本申请实施例基站的结构示意图；

图10为本申请实施例救援服务平台的结构示意图。

具体实施方式

下面结合附图及实施例对本申请再作进一步详细的描述。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中在本申请的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本申请。

相关技术，车辆发生事故时，车载终端自动拨打eCall或者车内人员手动触发按键拨打eCall，建立与PSAP的通信链路，可以有效缩短事故救援响应时间，然而，当遇到严重事故，车载终端毁坏且车内人员昏迷等情形时，导致无法发出eCall呼叫，进而会影响事故救援，导致事故受伤人员无法得到及时的救治，交通秩序长时间无法恢复。

基于此，在本申请的各种实施例中，通过基于基站收集车辆信息并将疑似事故警告信息(SAAI)发送给救援服务平台(PSAP)，可以帮助PSAP快速、可靠地获取可信的车辆事故信息，从而提升事故救援速度和质量。

示例性地，本申请实施例提供了一种车辆紧急呼叫方法，应用于基站，如图1所示，该方法包括：

步骤101，接收通信覆盖范围内各车载终端发送的心跳包。

可以理解的是，本申请实施例中的各车辆均配置有与基站进行移动通信的车载终端，该车载终端可以支持eCall呼叫。示例性地，该车载终端可以配置相对精确的全球定位功能，例如，基于全球定位系统(GPS)、北斗卫星导航系统(BDS)、伽利略卫星导航系统(Galileo)或者格洛纳斯卫星导航系统(GLONASS)实现全球定位。该车载终端还可以接入车辆CAN(Controller Area Network，控制器局域网)线网络，获取车辆传感器的相关检测数据。该车载终端还可以包括用于MSD传输的带内调制解调器。

需要说明的是，车辆在正常的行驶过程中，车载终端会基于移动通信的移动性管理策略，在各基站的通信覆盖范围内接入相应的基站，并基于设定频率发送心跳包(Heartbeat packet)给基站，如此，基站可以接收通信覆盖范围内各车载终端发送的心跳包。这里，心跳包是指车载终端按照一定的时间间隔周期性发送的数据包，类似于心跳，所以叫做心跳包。示例性地，该心跳包可以携带车载终端的位置信息、速度信息、航向信息及时间信息中的至少之一。

在一应用示例中，车载终端发送心跳包的频率与卫星定位更新频率一致，例如，为1Hz，心跳包可以携带车载终端的位置信息、速度信息、航向信息及时间信息。

步骤102，检测到目标车载终端的心跳包中断，则基于所述目标车载终端历史发送的心跳包，生成SAAI，并向救援服务平台发送疑似SAAI。

这里，基站若确定目标车载终端发送的心跳包出现非正常中断，则可以判定车载终端可能出现故障，进而触发向救援服务平台发送SAAI的告警机制。

可以理解的是，本申请实施例的方法，可以在车载终端无法有效发出eCall的严重事故场景下，由基站向救援服务平台发送SAAI，进而使得救援服务平台可以快速、可靠地获取可信的车辆事故信息，从而提升事故救援速度和质量。

示例性地，所述检测到目标车载终端的心跳包中断，包括：

若确定未接收到所述目标车载终端发送的心跳包的时长达到第一设定时长，且基于所述目标车载终端的移动性管理消息，确定所述目标车载终端处于所述基站的通信覆盖范围以及所述目标车载终端未关机，则判定所述目标车载终端的心跳包中断。

这里，第一设定时长可以基于需求进行合理确定，例如，可以为1分钟。可以理解的是，若基站确定未接收到目标车载终端发送的心跳包的时长达到1分钟，且基于目标车载终端的移动性管理消息，确定目标车载终端处于基站的通信覆盖范围内以及目标车载终端未关机，则可以判断目标车载终端的心跳包出现非正常中断，进而触发向救援服务平台发送SAAI的告警机制，生成并发送SAAI给基站所属区域的救援服务平台。

示例性地，所述方法还包括：

存储各所述车载终端在历史的第二设定时长内发送的心跳包；

所述基于所述目标车载终端历史发送的心跳包，生成SAAI，包括：

解析所述目标车载终端在历史的第二设定时长内发送的心跳包；

基于解析心跳包得到的信息，预测所述目标车载终端的状态信息；

基于所述目标车载终端的状态信息和所述目标车载终端的注册信息，生成SAAI；

其中，所述状态信息包括以下至少之一：事故位置信息、事故航向信息和事故时间信息，所述注册信息包括以下至少之一：车辆标识、燃油类别和载客人数。

这里，历史的第二设定时长即当前时间之前的第二设定时长，该第二设定时长可以基于需求进行合理确定。需要说明的是，第二设定时长过长，则会影响占用过大的存储空间并影响解析数据的效率，第二设定时长过短则会影响基站预测目标车载终端的状态信息的精度。示例性地，第二设定时长可以为1分钟。

示例性地，基站存储各所述车载终端历史的第二设定时长内发送的心跳包，且不对存储的心跳包进行解析，而是在检测到目标车载终端的心跳包中断后，再解析所述目标车载终端历史所述第二设定时长内发送的心跳包，进而基于解析心跳包得到的信息，预测所述目标车载终端的状态信息，如此，可以有效节省基站的资源消耗。

示例性地，基于解析心跳包得到的信息可以为历史的第二设定时长内各心跳包对应的车载终端的信息，例如，各心跳包携带的位置信息、速度信息、航向信息及时间信息，基站可以基于车载终端的历史信息，采用时间序列的预测算法预测目标车载终端的状态信息，该状态信息可以包括以下至少之一：事故位置信息、事故航向信息和事故时间信息。

可以理解的是，基站可以获取与其通信连接的车载终端的注册信息，如此，基站可以基于目标车载终端的状态信息和目标车载终端的注册信息，生成并发送SAAI给救援服务平台。由于SAAI可以包括目标车载终端的状态信息和注册信息，便于PSAP快速、可靠性低获取相关事故信息，利于后续事故确认和救援展开。

在一应用示例中，心跳包内容和长度如下表1所示：

表1

其中，信息内容如下表2所示：

表2

日期时间	纬度	经度	速度	航向	保留字节
						6字节	4字节	4字节	1字节	2字节	1字节

可以理解的是，上述表1和表2所示的心跳包可以携带车载终端的位置信息、速度信息、航向信息及时间信息。

在一应用示例中，基站可以基于解析出车载终端的信息预测车载终端的事故位置信息、事故航向信息和事故时间信息，综合基站注册的车载终端注册信息，如车辆标识、燃油类别和载客人数等信息，合并生成SAAI，如图2所示。

示例性地，本申请实施例的方法还可以包括：

接收所述救援服务平台基于所述SAAI生成的确认后的事故告警通知；

向所述基站的通信覆盖范围内的各车载终端广播所述事故告警通知。

可以理解的是，基站收到PSAP发出的确认后的事故告警通知，可以向基站的通信覆盖范围内的各车载终端广播所述事故告警通知，例如，通过短消息形式向本基站区域内的车载终端广播事故告警通知，进而避免二次事故的发生，加速交通拥堵缓解速度。

示例性地，本申请实施例还提供了一种车辆紧急呼叫方法，应用于救援服务平台(PSAP)，如图3所示，该方法包括：

步骤301，接收基站发送的SAAI。

可以理解的是，基站若确定目标车载终端发送的心跳包出现非正常中断，则基于所述目标车载终端历史发送的心跳包，生成疑似事故警告信息(SAAI)并向救援服务平台发送SAAI。

步骤302，基于所述SAAI，生成事故确认信息。

PSAP可以基于接收到的SAAI，进行事故确认并生成事故确认信息。如此，PSAP可以基于SAAI确认事故的真实性，进而快速、可靠地获取可信的车辆事故信息，从而提升事故救援速度和质量。

示例性地，所述SAAI包括目标车载终端的状态信息和注册信息，所述状态信息包括以下至少之一：事故位置信息、事故航向信息和事故时间信息，所述注册信息包括以下至少之一：车辆标识、燃油类别和载客人数；所述基于所述SAAI，生成事故确认信息，包括：

基于所述SAAI，与所述目标车载终端和/或根据所述目标车载终端的位置确定的设定车载终端建立通信链路，生成事故确认信息。

可以理解的是，PSAP可以基于SAAI的信息，与目标车载终端和/或根据目标车载终端的位置确定的设定车载终端建立通信链路，基于通信链路的通信信息进行事故确认，生成事故确认信息，如此，可以有效排除实际不存在的事故信息，进而获取到可信的车辆事故信息，有效提升事故救援的速度和质量。

示例性地，所述基于所述SAAI，与所述目标车载终端和/或根据所述目标车载终端的位置确定的设定车载终端建立通信链路，生成事故确认信息，包括：

基于所述SAAI中携带的所述目标车载终端的车辆标识，向所述目标车载终端发起第一通话请求；

若基于所述第一通话请求与所述目标车载终端建立通信链路，则基于与所述目标车载终端的通话内容，生成事故确认信息；

若基于所述第一通话请求与所述目标车载终端未建立通信链路，则基于所述SAAI中携带的所述目标车载终端的事故位置信息确定与所述目标车载终端位置相近的设定车载终端，向所述设定车载终端发起第二通话请求，若基于所述第二通话请求与所述设定车载终端建立通信链路，则基于与所述设定车载终端的通话内容，生成事故确认信息。

可以理解的是，PSAP收到基站发出的SAAI后，可以优先与疑似事故车辆的目标车载终端建立通话联系，确认是否存在事故，若无法建立通话联系，则可以基于SAAI中携带的所述目标车载终端的事故位置信息确定设定车载终端，例如，依据距离优先原则选取距离疑似事故车辆最近的1～3台车载终端建立通信链路，确认是否存在事故，进而生成事故确认信息，如此，利于PSAP快速、可靠地获取可信的车辆事故信息，从而提升事故救援速度和质量。

示例性地，本申请实施例的方法还可以包括：

若基于所述事故确认信息确定所述目标车载终端所在车辆发生事故，则触发救援流程并向所述基站发送事故告警通知。

可以理解的是，PSAP若基于所述事故确认信息确定所述目标车载终端所在车辆发生事故，即确定疑似事故车辆为真实事故车辆，则可以基于SAAI的信息和通信链路确认的信息触发救援流程并向基站发送事故告警通知。

示例性地，PSAP可以基于SAAI的信息和通信链路确认的信息，生成事故车辆的MSD，并基于MSD触发救援流程，利于提高救援效率。示例性地，事故告警通知中亦可以携带该MSD，使得基站广播该MSD给基站区域内的车载终端，进而避免二次事故的发生，加速交通拥堵缓解速度。

示例性地，该MSD可以包括PSAP救援所需的信息，例如，包括：车辆位置、行驶方向、事故发生时间、事故严重程度、车辆标识、燃油类别和乘客人数等信息。

下面结合一应用示例对本申请再作进一步详细的描述。

图4示出了本应用示例中基于基站的车辆紧急呼叫系统的结构示意图。该车辆紧急呼叫系统包括：车辆、基站和PSAP，各车辆中配置车载终端，车载终端基于移动通信接入基站，基站与PSAP通信连接。本应用示例的技术方案涉及以下三个部分：车载终端事故预判、事故确认和基站广播事故告警通知。下面分别对上述三个部分进行示例性说明。

一、车载终端事故预判

图5示出了本应用示例中车载终端事故预判的流程示意图，如图5所示，车载终端事故预判的流程具体可以包括：

步骤501，车载终端向基站发送心跳包。

这里，车辆在正常的行驶过程中，车载终端会基于移动通信的移动性管理策略，在各基站的通信覆盖范围内接入相应的基站，并基于设定频率发送心跳包给基站，例如，发送频率为1Hz。

步骤502，基站为每个车载终端保存最近1分钟的心跳包，但不解析。

这里，基站若正常接收车载终端的心跳包，则为每个车载终端存储但不解析过去一分钟的心跳包作为备份。

步骤503，超过1分钟未收到心跳包。

这里，基站若超过1分钟未收到心跳包，则出现心跳包接收异常，则执行步骤504，进一步判断是否为心跳包非正常中断。

步骤504，判断是否收到关机信息，若是，则执行步骤505，若否，则执行步骤506。

这里，基站可以基于车载终端的移动性管理消息判断车载终端是否关机。可以理解的是，若车载终端关机，则会基于移动性管理消息提前上报关机信息给基站，如此，基站可以确定车载终端是否出现因关机导致的心跳包中断，从而排除该情形，得到车载终端是否出现心跳包非正常中断的判断结果。

步骤505，删除保存的心跳包。

这里，基站若确定车载终端关机，则可以删除保存的该车载终端的心跳包，并结束对该车载终端的心跳包的监测。

步骤506，解析保存的心跳包，预测车载终端的位置、航向和事故时间信息。

这里，基站若确定车载终端出现心跳包非正常中断，则可以解析保存的该车载终端的历史心跳包，基于该车载终端的历史信息，采用时间序列的预测算法预测该车载终端位置、航向和事故时间信息。

步骤507，读取车载终端的注册信息，并生成SAAI。

这里，基站可以读取该车载终端的注册信息，并结合前述预测的该车载终端位置、航向和事故时间信息，生成SAAI。

步骤508，向PSAP发送SAAI。

基站向所属区域的PSAP发送SAAI。

二、事故确认

图6示出了本应用示例中PSAP事故确认的流程示意图，如图6所示，PSAP事故确认的流程具体可以包括：

步骤601，接收基站发送的SAAI。

步骤602，向疑似事故车辆发起通话。

这里，PSAP收到基站发出的疑似事故警告信息(SAAI)后，可以优先向疑似事故车辆建立通话联系，例如，基于疑似事故车辆的车载终端的ID向该车载终端发起通话请求。

步骤603，判断是否建立通话，若是，则执行步骤604，若否，则执行步骤608。

这里，PSAP可以基于是否与疑似事故车辆建立通话的结果，触发不同的处理流程，对于已建立通话的情形，则可以基于该通话确认是否存在事故，排除无效的SAAI，对于未建立通话的情形，则需要进一步与其他车载终端建立通话，进而有效排除无效的SAAI。

步骤604，确认是否存在事故，若是，则执行步骤605和步骤606，若否，则执行步骤607。

步骤605，触发救援流程。

这里，PSAP可以基于SAAI的信息和通话确认的信息，触发救援流程，进而可信、准确、有效地开展救援，提高救援效率和质量。

步骤606，向基站发送事故告警通知。

这里，PSAP可以基于SAAI的信息和通话确认的信息，向基站发送事故告警通知。可以理解的是，上述步骤605和步骤606可以先后执行或者同步执行，本申请实施例对此不做限定。

步骤607，向基站发送无事故的通知。

这里，PSAP可以基于与疑似事故车辆建立的通话确认无事故后，向基站发送无事故的通知。在其他示例中，该步骤607亦可以省去。

步骤608，根据距离优先原则，选择离疑似事故位置最近的三个车载终端。

示例性地，PSAP可以基于SAAI中的位置信息、航向信息、事故时间信息等，根据距离优先原则，选择离疑似事故位置最近的三个车载终端，根据与该三个车载终端建立通话，进一步确认是否存在事故。

步骤609，向就近的车载终端1发起通话。

步骤610，确认是否存在事故，若是，则执行前述的步骤605和步骤606，若否，则执行步骤611。

步骤611，向就近的车载终端2发起通话。

步骤612，确认是否存在事故，若是，则执行前述的步骤605和步骤606，若否，则执行步骤613。

步骤613，向就近的车载终端3发起通话。

步骤614，确认是否存在事故，若是，则执行前述的步骤605和步骤606，若否，则执行步骤615。

步骤615，向基站发送无事故的通知。

这里，PSAP可以在上述车载终端1至3均确认无事故后，向基站发送无事故的通知。

三、基站广播事故告警通知

可以理解的是，基站收到PSAP发出的确认后的事故告警通知，可以向基站的通信覆盖范围内的各车载终端广播所述事故告警通知，例如，通过短消息形式向本基站区域内的车载终端广播事故告警通知，进而避免二次事故的发生，加速交通拥堵缓解速度。

可以理解的是，本应用示例的基于基站的车辆紧急呼叫系统，基站可以基于车载终端的心跳包，发送SAAI给PSAP，且PSAP可以基于SAAI进行事故确认，进而快速、可靠的获取可信的车辆事故信息，从而提升事故救援速度和质量。

为了实现本申请实施例的方法，本申请实施例还提供一种车辆紧急呼叫装置，应用于基站。该车辆紧急呼叫装置与上述基站侧的车辆紧急呼叫方法对应，上述基站侧车辆紧急呼叫方法实施例中的各步骤也完全适用于本车辆紧急呼叫装置实施例。

如图7所示，该车辆紧急呼叫装置包括：获取模块701和告警模块702。获取模块701用于接收通信覆盖范围内各车载终端发送的心跳包；告警模块702用于检测到目标车载终端的心跳包中断，则基于所述目标车载终端历史发送的心跳包，生成疑似事故警告信息(SAAI)，并向救援服务平台发送SAAI。

示例性地，告警模块702检测到目标车载终端的心跳包中断，包括：

若确定未接收到所述目标车载终端发送的心跳包的时长达到第一设定时长，且基于所述目标车载终端的移动性管理消息，确定所述目标车载终端处于所述基站的通信覆盖范围以及所述目标车载终端未关机，则判定所述目标车载终端的心跳包中断。

示例性地，所述心跳包携带车载终端的位置信息、速度信息、航向信息及时间信息中的至少之一，获取模块701还用于：存储各所述车载终端在历史第二设定时长内发送的心跳包；告警模块702基于所述目标车载终端历史发送的心跳包，生成SAAI，包括：

解析所述目标车载终端在历史的所述第二设定时长内发送的心跳包；

基于解析心跳包得到的信息，预测所述目标车载终端的状态信息；

基于所述目标车载终端的状态信息和所述目标车载终端的注册信息，生成并SAAI；

其中，所述状态信息包括以下至少之一：事故位置信息、事故航向信息和事故时间信息，所述注册信息包括以下至少之一：车辆标识、燃油类别和载客人数。

示例性地，该车辆紧急呼叫装置还包括：接收模块703和广播模块704，接收模块703用于接收所述救援服务平台基于所述SAAI生成的确认后的事故告警通知；广播模块704用于向所述基站的通信覆盖范围内的各车载终端广播所述事故告警通知。

实际应用时，获取模块701、告警模块702、接收模块703和广播模块704，可以由基站中的处理器来实现。当然，处理器需要运行存储器中的计算机程序来实现它的功能。

为了实现本申请实施例的方法，本申请实施例还提供一种车辆紧急呼叫装置，应用于救援服务平台。该车辆紧急呼叫装置与上述救援服务平台侧的车辆紧急呼叫方法对应，上述救援服务平台侧车辆紧急呼叫方法实施例中的各步骤也完全适用于本车辆紧急呼叫装置实施例。

如图8所示，该车辆紧急呼叫装置包括：接收模块801和事故确认模块802。接收模块801用于接收基站发送的疑似事故警告信息(SAAI)；事故确认模块802用于基于所述SAAI，生成事故确认信息。

示例性地，所述SAAI包括目标车载终端的状态信息和注册信息，所述状态信息包括以下至少之一：事故位置信息、事故航向信息和事故时间信息，所述注册信息包括以下至少之一：车辆标识、燃油类别和载客人数；事故确认模块802具体用于：

基于所述SAAI，与所述目标车载终端和/或根据所述目标车载终端的位置确定的设定车载终端建立通信链路，生成事故确认信息。

示例性地，所述基于所述SAAI，与所述目标车载终端和/或根据所述目标车载终端的位置确定的设定车载终端建立通信链路，生成事故确认信息，包括：

基于所述SAAI中携带的所述目标车载终端的车辆标识，向所述目标车载终端发起第一通话请求；

若基于所述第一通话请求与所述目标车载终端建立通信链路，则基于与所述目标车载终端的通话内容，生成事故确认信息；

若基于所述第一通话请求与所述目标车载终端未建立通信链路，则基于所述SAAI中携带的所述目标车载终端的事故位置信息确定与所述目标车载终端位置相近的设定车载终端，向所述设定车载终端发起第二通话请求，若基于所述第二通话请求与所述设定车载终端建立通信链路，则基于与所述设定车载终端的通话内容，生成事故确认信息。

示例性地，事故确认模块802还用于：

若基于所述事故确认信息确定所述目标车载终端所在车辆发生事故，则触发救援流程并向所述基站发送事故告警通知。

实际应用时，接收模块801和事故确认模块802，可以由救援服务平台中的处理器来实现。当然，处理器需要运行存储器中的计算机程序来实现它的功能。

需要说明的是：上述实施例提供的车辆紧急呼叫装置在进行车辆紧急呼叫时，仅以上述各程序模块的划分进行举例说明，实际应用中，可以根据需要而将上述处理分配由不同的程序模块完成，即将装置的内部结构划分成不同的程序模块，以完成以上描述的全部或者部分处理。另外，上述实施例提供的车辆紧急呼叫装置与车辆紧急呼叫方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

基于上述程序模块的硬件实现，且为了实现本申请实施例的方法，本申请实施例还提供一种基站。图9仅仅示出了该基站的示例性结构而非全部结构，根据需要可以实施图9示出的部分结构或全部结构。

如图9所示，本申请实施例提供的基站900包括：至少一个处理器901、存储器902、用户接口903和至少一个网络接口904。基站900中的各个组件通过总线系统905耦合在一起。可以理解，总线系统905用于实现这些组件之间的连接通信。总线系统905除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图9中将各种总线都标为总线系统905。

其中，用户接口903可以包括显示器、键盘、鼠标、轨迹球、点击轮、按键、按钮、触感板或者触摸屏等。

本申请实施例中的存储器902用于存储各种类型的数据以支持基站的操作。这些数据的示例包括：用于在基站上操作的任何计算机程序。

本申请实施例揭示的车辆紧急呼叫方法可以应用于处理器901中，或者由处理器901实现。处理器901可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，车辆紧急呼叫方法的各步骤可以通过处理器901中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器901可以是通用处理器、数字信号处理器(DSP，Digital SignalProcessor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。处理器901可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤，可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于存储介质中，该存储介质位于存储器902，处理器901读取存储器902中的信息，结合其硬件完成本申请实施例提供的车辆紧急呼叫方法的步骤。

在示例性实施例中，基站可以被一个或多个应用专用集成电路(ASIC，Application Specific Integrated Circuit)、DSP、可编程逻辑器件(PLD，ProgrammableLogic Device)、复杂可编程逻辑器件(CPLD，Complex Programmable Logic Device)、现场可编程逻辑门阵列(FPGA，Field Programmable Gate Array)、通用处理器、控制器、微控制器(MCU，Micro Controller Unit)、微处理器(Microprocessor)、或者其他电子元件实现，用于执行前述方法。

基于上述程序模块的硬件实现，且为了实现本申请实施例的方法，本申请实施例还提供一种救援服务平台。图10仅仅示出了该救援服务平台的示例性结构而非全部结构，根据需要可以实施图10示出的部分结构或全部结构。

如图10所示，本申请实施例提供的救援服务平台1000包括：至少一个处理器1001、存储器1002、用户接口1003和至少一个网络接口1004。救援服务平台1000中的各个组件通过总线系统1005耦合在一起。可以理解，总线系统1005用于实现这些组件之间的连接通信。总线系统1005除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图10中将各种总线都标为总线系统1005。

其中，用户接口1003可以包括显示器、键盘、鼠标、轨迹球、点击轮、按键、按钮、触感板或者触摸屏等。

本申请实施例中的存储器1002用于存储各种类型的数据以支持救援服务平台的操作。这些数据的示例包括：用于在救援服务平台上操作的任何计算机程序。

本申请实施例揭示的车辆紧急呼叫方法可以应用于处理器1001中，或者由处理器1001实现。处理器1001可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，车辆紧急呼叫方法的各步骤可以通过处理器1001中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器1001可以是通用处理器、数字信号处理器(DSP，Digital SignalProcessor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。处理器1001可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤，可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于存储介质中，该存储介质位于存储器1002，处理器1001读取存储器1002中的信息，结合其硬件完成本申请实施例提供的车辆紧急呼叫方法的步骤。

在示例性实施例中，救援服务平台可以被一个或多个ASIC、DSP、PLD、CPLD、FPGA、通用处理器、控制器、MCU、Microprocessor、或其他电子元件实现，用于执行前述方法。

可以理解，存储器902、1002可以是易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(ROM，Read OnlyMemory)、可编程只读存储器(PROM，Programmable Read-Only Memory)、可擦除可编程只读存储器(EPROM，Erasable Programmable Read-Only Memory)、电可擦除可编程只读存储器(EEPROM，Electrically Erasable Programmable Read-Only Memory)、磁性随机存取存储器(FRAM，ferromagnetic random access memory)、快闪存储器(Flash Memory)、磁表面存储器、光盘、或只读光盘(CD-ROM，Compact Disc Read-Only Memory)；磁表面存储器可以是磁盘存储器或磁带存储器。易失性存储器可以是随机存取存储器(RAM，Random AccessMemory)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(SRAM，Static Random Access Memory)、同步静态随机存取存储器(SSRAM，Synchronous Static Random Access Memory)、动态随机存取存储器(DRAM，Dynamic Random Access Memory)、同步动态随机存取存储器(SDRAM，SynchronousDynamic Random Access Memory)、双倍数据速率同步动态随机存取存储器(DDRSDRAM，Double Data Rate Synchronous Dynamic Random Access Memory)、增强型同步动态随机存取存储器(ESDRAM，Enhanced Synchronous Dynamic Random Access Memory)、同步连接动态随机存取存储器(SLDRAM，Sync Link Dynamic Random Access Memory)、直接内存总线随机存取存储器(DRRAM，Direct Rambus Random Access Memory)。本申请实施例描述的存储器旨在包括但不限于这些和任意其它适合类型的存储器。

在示例性实施例中，本申请实施例还提供了一种车辆紧急呼叫系统，包括前述的基站900和前述的救援服务平台1000，基站900与救援服务平台100通信连接。

在示例性实施例中，本申请实施例还提供了一种计算机存储介质，具体可以是计算机可读存储介质，例如包括存储计算机程序的存储器902，上述计算机程序可由基站的处理器901执行，以完成本申请实施例方法所述的步骤；又如，包括存储计算机程序的存储器1002，上述计算机程序可由救援服务平台的处理器1001执行，以完成本申请实施例方法所述的步骤。计算机可读存储介质可以是ROM、PROM、EPROM、EEPROM、Flash Memory、磁表面存储器、光盘、或CD-ROM等存储器。

需要说明的是：“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

另外，本申请实施例所记载的技术方案之间，在不冲突的情况下，可以任意组合。

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

Claims (14)

1.一种车辆紧急呼叫方法，其特征在于，应用于基站，包括：

接收通信覆盖范围内各车载终端发送的心跳包；

检测到目标车载终端的心跳包中断，则基于所述目标车载终端历史发送的心跳包，生成疑似事故警告信息SAAI，并向救援服务平台发送所述SAAI。

2.根据权利要求1所述的方法，其特征在于，所述检测到目标车载终端的心跳包中断，包括：

若确定未接收到所述目标车载终端发送的心跳包的时长达到第一设定时长，且基于所述目标车载终端的移动性管理消息，确定所述目标车载终端处于所述基站的通信覆盖范围以及所述目标车载终端未关机，则判定所述目标车载终端的心跳包中断。

3.根据权利要求1所述的方法，其特征在于，所述心跳包携带车载终端的位置信息、速度信息、航向信息及时间信息中的至少之一，所述方法还包括：

存储各所述车载终端在历史的第二设定时长内发送的心跳包；

所述基于所述目标车载终端历史发送的心跳包，生成SAAI，包括：

解析所述目标车载终端在历史的第二设定时长内发送的心跳包；

基于解析心跳包得到的信息，预测所述目标车载终端的状态信息；

基于所述目标车载终端的状态信息和所述目标车载终端的注册信息，生成SAAI；

其中，所述状态信息包括以下至少之一：事故位置信息、事故航向信息和事故时间信息，所述注册信息包括以下至少之一：车辆标识、燃油类别和载客人数。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

接收所述救援服务平台基于所述SAAI生成的确认后的事故告警通知；

向所述基站的通信覆盖范围内的各车载终端广播所述事故告警通知。

5.一种车辆紧急呼叫方法，其特征在于，应用于救援服务平台，所述方法包括：

接收基站发送的疑似事故警告信息SAAI；

基于所述SAAI，生成事故确认信息。

6.根据权利要求5所述的方法，其特征在于，所述SAAI包括目标车载终端的状态信息和注册信息，所述状态信息包括以下至少之一：事故位置信息、事故航向信息和事故时间信息，所述注册信息包括以下至少之一：车辆标识、燃油类别和载客人数；所述基于所述SAAI，生成事故确认信息，包括：

基于所述SAAI，与所述目标车载终端和/或根据所述目标车载终端的位置确定的设定车载终端建立通信链路，生成事故确认信息。

7.根据权利要求6所述的方法，其特征在于，所述基于所述SAAI，与所述目标车载终端和/或根据所述目标车载终端的位置确定的设定车载终端建立通信链路，生成事故确认信息，包括：

基于所述SAAI中携带的所述目标车载终端的车辆标识，向所述目标车载终端发起第一通话请求；

若基于所述第一通话请求与所述目标车载终端建立通信链路，则基于与所述目标车载终端的通话内容，生成事故确认信息；

若基于所述第一通话请求与所述目标车载终端未建立通信链路，则基于所述SAAI中携带的所述目标车载终端的事故位置信息确定与所述目标车载终端位置相近的设定车载终端，向所述设定车载终端发起第二通话请求，若基于所述第二通话请求与所述设定车载终端建立通信链路，则基于与所述设定车载终端的通话内容，生成事故确认信息。

8.根据权利要求7所述的方法，其特征在于，所述方法还包括：

若基于所述事故确认信息确定所述目标车载终端所在车辆发生事故，则触发救援流程并向所述基站发送事故告警通知。

9.一种车辆紧急呼叫装置，其特征在于，应用于基站，所述装置包括：

获取模块，用于接收通信覆盖范围内各车载终端发送的心跳包；

告警模块，用于检测到目标车载终端的心跳包中断，则基于所述目标车载终端历史发送的心跳包，生成疑似事故警告信息SAAI，并向救援服务平台发送SAAI。

10.一种车辆紧急呼叫装置，其特征在于，应用于救援服务平台，所述装置包括：

接收模块，用于接收基站发送的疑似事故警告信息SAAI；

事故确认模块，用于基于所述SAAI，生成事故确认信息。

11.一种基站，其特征在于，包括：处理器和用于存储能够在处理器上运行的计算机程序的存储器，其中，

所述处理器，用于运行计算机程序时，执行权利要求1至4任一项所述方法的步骤。

12.一种救援服务平台，其特征在于，包括：处理器和用于存储能够在处理器上运行的计算机程序的存储器，其中，

所述处理器，用于运行计算机程序时，执行权利要求5至8任一项所述方法的步骤。

13.一种车辆紧急呼叫系统，其特征在于，包括如权利要求11所述的基站和如权利要求12所述的救援服务平台，所述基站与所述救援服务平台通信连接。

14.一种计算机存储介质，所述计算机存储介质上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时，实现权利要求1至8任一项所述方法的步骤。