协同呼救方法、装置、可穿戴设备和存储介质与流程

【技术领域】

本申请涉及通信技术领域，尤其涉及一种协同呼救方法、装置、可穿戴设备和存储介质。

背景技术：

目前，用户在乘车、驾驶等情况下发生危险状况时，通常都是利用手机、平板的联网功能，通过基站2g/3g/4g/5g网络发送报警消息，或者拨打电话呼叫110报警求救，或者通过打车应用程序发送报警消息，这些做法都存在较明显的缺陷，难以实现安全便捷的呼救目的。

技术实现要素：

有鉴于此，本申请实施例提供了一种协同呼救方法、装置、可穿戴设备及存储介质，用以解决目前用户在乘车、驾驶等情况下发生危险状况时难以实现安全便捷的呼救目的的问题。

第一方面，本申请实施例提供了一种协同呼救方法，包括：

采集v2x信息，通过所述v2x信息确定用户所在车辆的车辆标识；

根据所述用户所在车辆的车辆标识，获取所述用户所在车辆的车辆信息；

采集传感器数据，并根据所述传感器数据对用户是否存在危险进行检测；

若确定用户存在危险，则发起救援请求，其中，所述救援请求包括所述车辆信息和呼叫信息。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述v2x信息中包括gps数据，所述采集v2x信息，通过所述v2x信息确定用户所在车辆的车辆标识，包括：

根据所述gps数据计算用户和周边车辆的距离，其中，预设地理范围内的车辆为所述周边车辆；

在预设时间段内，将与所述用户的距离持续在1.5米内的所述周边车辆确定为所述用户所在车辆；

根据所述用户所在车辆确定所述用户所在车辆的车辆标识。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述传感器数据包括角速度、加速度和心率，所述采集传感器数据，并根据所述传感器数据对用户是否存在危险进行检测，包括：

采集角速度、加速度和心率；

根据所述角速度、所述加速度和所述心率是否满足预设的危险判定条件检测用户是否存在危险，其中，当所述角速度、所述加速度和所述心率满足预设的危险判定条件时，确定所述用户存在危险。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述若确定用户存在危险，则发起救援请求，包括：

若确定用户存在危险，则按不同紧急等级发起所述救援请求，其中，所述紧急等级根据时间进行划分。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述若确定用户存在危险，则按不同紧急等级发起所述救援请求，包括：

在第一预设时间段内，根据所述v2x信息得到紧急车辆提醒数据；

根据所述紧急车辆提醒数据寻找第一预设搜索范围内是否存在紧急车辆；

若存在所述紧急车辆，则周期性地向所述紧急车辆发起救援请求。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述若确定用户存在危险，则按不同紧急等级发起所述救援请求，包括：

若在所述第一预设时间段内，所述第一预设搜索范围内不存在所述紧急车辆，则在第二预设时间段内，对所述第二预设搜索范围内的车辆发起所述救援请求。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述若确定用户存在危险，则按不同紧急等级发起所述救援请求，包括：

若在所述第二预设时间段内，所述第二搜索范围内不存在车辆，则向路侧单元发起所述救援请求，以使所述路侧单元在接收所述救援请求后对交通指示设备进行控制。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述救援请求采用点对点通信的方式发起，其中，通信过程采用v2x通信协议。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述v2x通信协议传输的数据段中包括用户字段，所述用户字段中包括发送方设备id、接收方设备id、发送方公钥和所述数据段是否进行加密的加密标志。

第二方面，本申请实施例提供了一种协同呼救装置，包括：

第一采集模块，用于采集v2x信息，通过所述v2x信息确定用户所在车辆的车辆标识；

车辆信息获取模块，用于根据所述用户所在车辆的车辆标识，获取所述用户所在车辆的车辆信息；

第三采集模块，用于采集传感器数据，并根据所述传感器数据对用户是否存在危险进行检测；

救援请求模块，用于若确定用户存在危险，则发起救援请求，其中，所述救援请求包括所述车辆信息和呼叫信息。

进一步地，所述v2x信息中包括gps数据，所述第一采集模块，具体用于：

根据所述gps数据计算用户和周边车辆的距离，其中，预设地理范围内的车辆为所述周边车辆；

在预设时间段内，将与所述用户的距离持续在1.5米内的所述周边车辆确定为所述用户所在车辆；

根据所述用户所在车辆确定所述用户所在车辆的车辆标识。

进一步地，所述传感器数据包括角速度、加速度和心率，所述第三采集模块，具体用于：

采集角速度、加速度和心率；

根据所述角速度、所述加速度和所述心率是否满足预设的危险判定条件检测用户是否存在危险，其中，当所述角速度、所述加速度和所述心率满足预设的危险判定条件时，确定所述用户存在危险。

进一步地，所述救援请求模块，具体用于：

若确定用户存在危险，则按不同紧急等级发起所述救援请求，其中，所述紧急等级根据时间进行划分。

进一步地，所述救援请求模块，还具体用于：

在第一预设时间段内，根据所述v2x信息得到紧急车辆提醒数据；

根据所述紧急车辆提醒数据寻找第一预设搜索范围内是否存在紧急车辆；

若存在所述紧急车辆，则周期性地向所述紧急车辆发起救援请求。

进一步地，所述救援请求模块，还具体用于：

若在所述第一预设时间段内，所述第一预设搜索范围内不存在所述紧急车辆，则在第二预设时间段内，对所述第二预设搜索范围内的车辆发起所述救援请求。

进一步地，所述救援请求模块，还具体用于：

若在所述第二预设时间段内，所述第二搜索范围内不存在车辆，则向路侧单元发起所述救援请求，以使所述路侧单元在接收所述救援请求后对交通指示设备进行控制。

进一步地，所述救援请求采用点对点通信的方式发起，其中，通信过程采用v2x通信协议。

进一步地，所述v2x通信协议传输的数据段中包括用户字段，所述用户字段中包括发送方设备id、接收方设备id、发送方公钥和所述数据段是否进行加密的加密标志。

第三方面，一种可穿戴设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述第一方面所述方法的步骤。

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

在本申请实施例中，通过采集的v2x信息确定用户所在车辆的车辆标识，能够基于v2x的通信方式，快速确认用户所乘坐的车辆，并根据用户所在车辆的车辆标识，使得用户能够在众多车辆中获取用户所在车辆的车辆信息；通过对传感器数据的采集，可根据传感器数据对用户是否存在危险进行检测，当检测确定用户存在危险时，可及时将包括车辆信息和呼叫信息的救援请求发送到接收设备。该救援请求可实现自动发送，无需用户主动触发，无需依赖打车应用程序，能够实现安全便捷的呼救目的。

【附图说明】

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

图1是本申请一实施例中协同呼救方法的一流程图；

图2是本申请一实施例中协同呼救方法的一应用场景示意图；

图3是本申请一实施例中协同呼救方法的又一流程图；

图4是本申请一实施例中传输的数据段的数据结构示意图；

图5是本申请一实施例中协同呼救装置的一原理框图；

图6是本申请一实施例中可穿戴设备的一示意图。

【具体实施方式】

可以理解地，目前常用的乘客保护方案，其原理是利用手机、平板的联网功能，通过基站2g/3g/4g/5g网络发送报警消息，或者拨打电话呼叫110报警求救，或者通过打车应用程序发送报警消息。以打车应用程序为例，乘客可以通过在打车应用程序上点击安全中心-一键报警-视频报警/呼叫110等方式实现报警求救，然而，这种乘客保护方案存在以下较明显的缺陷：

该报警求救方式需要乘客在打车应用程序上执行多个步骤进行报警，这种情况容易被歹徒发现，引发进一步的冲突；即使在报警时歹徒没有发现，警方通过询问获取到用户的地理位置信息后，也需要较长的时间才能追踪定位到歹徒，此时乘客仍将面临较长时间的危险；若乘客从一开始就被劫持，那么乘客将难以进行操作，连报警都做不到。

可以理解地，除了通过打车应用程序报警的方式，通过基站2g/3g/4g/5g网络发送报警消息，或者拨打电话呼叫110报警求救的方式同样容易影响歹徒的注意，乘客仍有较大危险。该报警求救方式依赖于基站，警察一般都是在某个固定办公场所收到报警消息后，经过确认报警无误才进行下一步的救援，在该救援期间乘客可能出现各种意外，无法实现高效的救援目的。

为了更好的理解本申请的技术方案，下面结合附图对本申请实施例进行详细描述。

图1示出本实施例中协同呼救方法的一流程图。该协同呼救方法可应用在可穿戴设备上，能够在(可穿戴设备)用户乘车、驾驶等状态发生危险时，提供安全便捷的呼救功能。该可穿戴设备包括但不限于智能手环、智能手表、智能戒指、智能项链等可穿戴设备。如图1所示，该协同呼救方法包括：

s10：采集v2x信息，通过v2x信息确定用户所在车辆的车辆标识。

其中，v2x(vehicletoeverything)表示车辆与万物的基于lte(longtermevolution，长期演进)-v(vehicle)或dsrc(dedicatedshortrangecommunications，专用短程通信技术)的通信互联，能够以车辆作为主体与其他事物进行通信互联，例如，车与车、车与可穿戴设备、车与路侧单元等之间的通信互联。

在一实施例中，可穿戴设备通过v2x通信采集v2x信息，其中，该v2x信息包括bsm(basicsafetymessage，基础安全消息)，该基础安全消息为车辆进行v2x通信时所广播的信息，包括车辆vin(vehicleidentificationnumber)码、车辆行驶速度、形式航向、地理位置、加速度、预测路径、历史路径和车辆类型等。可以理解地，用户在驾驶或乘坐车辆时，可通过身上的可穿戴设备采集v2x信息，建立起用户的可穿戴设备、用户所在车辆与通信范围内其他车辆的通信互联关系。

车辆标识是指能够唯一识别车辆的标识，本实施例中具体可以将v2x信息中的车辆vin码作为车辆标识。其中，该车辆vin码是一组由十七个英数组成，用于汽车上的一组独一无二的号码，可以识别汽车的生产商、引擎、底盘序号及其他性能等资料。本申请实施例能够基于v2x的通信方式，快速确认用户所在车辆的车辆标识。

进一步地，在步骤s10中，v2x信息中包括gps数据，通过v2x信息确定用户所在车辆的车辆标识，具体包括：

s11：根据gps数据计算用户和周边车辆的距离，其中，预设地理范围内的车辆为周边车辆。

具体地，可将以用户所在地理位置为中心，半径150m范围内的车辆作为周边车辆。

可以理解地，v2x信息中包括gps(globalpositioningsystem)数据，也即车辆的地理位置的数据，用户可通过车辆的gps数据确定用户所在车辆的车辆标识。

在一实施例中，用户在通过可穿戴设备的v2x通信模块接收周边车辆的广播信息，得到基础安全消息后，将根据基础安全消息中的gps数据计算用户和周边车辆的距离，以对用户和周边车辆的距离进行分析，确定用户所在车辆。

s12：在预设时间段内，将与用户的距离持续在1.5米内的周边车辆确定为用户所在车辆。

可以理解地，前后车在行驶状态下安全距离应在10米以上，因此用户在正常车辆行驶的情况下与前后车的距离基本不可能一直在1.5米内；而对于左右车距，安全行驶的平均左右车距为1.2米，而车身宽度为1.5米以上，因此，用户上车车辆从静止起步到用户遇到危险，始终有车辆与本车并行行驶导致人车距离在1.5米内也基本不可能。

在一实施例中，在预设时间段内，若用户和周边车辆的距离持续在1.5米内，则将该周边车辆确定为用户所在车辆，若在用户遇到危险时，可将用户所在车辆标记为危险车辆，并生成呼救信息，其中，呼救信息包括vrucw(vulnerableroadusercollisionwarning，弱势交通参与者碰撞预警)用户数据：包括用户的使用状态为“sos求救”，包括用户的个人健康状况等。该呼叫信息能够在用户遇到危险时及时发送到其他车辆或者路侧单元等接收方，以使用户遇险的情况被快速获知。

s13：根据用户所在车辆确定用户所在车辆的车辆标识。

在一实施例中，当确定用户所在车辆后，可选取能够唯一识别的标识作为车辆标识。具体地，可以将用户所在车辆的车辆vin码作为车辆标识，可方便后续可穿戴设备根据车辆的车辆vin码对用户所在车辆通过广播发送的v2x信息进行采集。

步骤s11-s13中，提供了一种通过v2x信息确定用户所在车辆的车辆标识的具体实施方式，通过利用用户和周边车辆的距离，能够确定用户所在车辆的车辆标识。

s20：根据用户所在车辆的车辆标识，获取用户所在车辆的车辆信息。

其中，用户所在车辆的车辆信息是指对用户正在乘坐、驾驶的车辆采集得到的v2x信息中，包括用户所在车辆的基础安全消息。

可以理解地，假设用户遇到了危险，则在呼救时需要发送用户所在车辆的车辆信息，才能够让援救方快速确定用户所在地理位置进行援救。

在一实施例中，可根据车辆vin码，在步骤s10中众多车辆采集的v2x信息中获取得到用户所在车辆的车辆信息，也可以根据车辆标识，采用可穿戴设备的通信数据模块，如支持lte-v通信数据的rfic(射频集成电路)，接收车辆的v2x通信模块发出的广播信息，采集得到用户所在车辆的车辆信息。本申请实施例中，能够使用户在众多车辆中获取用户所在车辆的车辆信息，以在用户发生危险时，能够快速将用户所在车辆的车辆信息及时发送到其他车辆或者路侧单元等接收方，使得救援人员能够快速准确地确定用户当前的地理位置等信息。

s30：采集传感器数据，并根据传感器数据对用户是否存在危险进行检测。

其中，可穿戴设备包括多种传感器，传感器采集的传感器数据能够体现出用户的个人健康状况，如用户是否有受惊吓、恐惧等不良精神状态出现；如用户身体状态是否发生异常情况，例如身体移动速度变化的幅度、翻转幅度是否过大等异常情况出现，通过这些传感数据能够对用户是否存在危险进行检测。

进一步地，在步骤s30中，传感器数据包括角速度、加速度和心率，采集传感器数据，并根据传感器数据对用户是否存在危险进行检测，包括：

s31：采集角速度、加速度和心率。

在一实施例中，可穿戴设备包括陀螺仪传感器、加速度传感器和心率传感器等传感器，可根据陀螺仪传感器、加速度传感器和心率传感器等传感器采集的角速度、加速度和心率等数据检测用户的个人健康状况，有助于判断用户是否存在危险。

s32：根据角速度、加速度和心率是否满足预设的危险判定条件检测用户是否存在危险，其中，当角速度、加速度和心率满足预设的危险判定条件时，确定用户存在危险。

在一实施例中，当角速度、加速度和心率满足预设的危险判定条件时，如在第一时间区间内同时满足角速度的平均值大于第一预设阈值，以及加速度的平均值大于第二预设阈值，则认为用户存在危险；或者，在第二时间区间内心率的平均值大于第三预设阈值时，认为用户存在危险。

步骤s31-s32中，提供了一种根据传感器数据对用户是否存在危险进行检测的具体实施方式，通过角速度、加速度和心率快速确定用户是否受到危害，以达到及时发送救援请求的目的。

s40：若确定用户存在危险，则发起救援请求，其中，救援请求包括车辆信息和呼叫信息。

其中，呼救信息包括用户的使用状态，具体为“sos求救”状态，以及包括用户的个人健康状况等信息。该呼叫信息能够在用户遇到危险时及时发送到其他车辆或者路侧单元，以使用户遇险的情况被快速获知。可以理解地，除了呼救信息，为了使救援人员更有效的资源，还需要提供用户所在车辆的车辆信息，包括车辆行驶速度、形式航向、地理位置、加速度、预测路径与历史路径、车辆类型等基础安全消息。通过车辆信息和呼叫信息能够将用户的当前状况及时地发送出去，提高救援效率。

进一步地，在步骤s40中，若确定用户存在危险，则发起救援请求，包括：

s400：若确定用户存在危险，则按不同紧急等级发起救援请求，其中，紧急等级根据时间进行划分。

在一实施例中，具体可以根据时间划分救援请求的紧急程度。根据不同的紧急程度发起的救援请求具有更强的针对性，能够更加合理地利用周边资源进行求救，提高救援效率和救援成功率。

进一步地，在步骤s400中，步骤若确定用户存在危险，则按不同紧急等级发起救援请求，其中，紧急等级根据时间进行划分，具体包括：

s411：在第一预设时间段内，根据v2x信息得到紧急车辆提醒数据。

其中，紧急车辆提醒(emergencyvehiclewarning，evw)是识别紧急车辆的类型标识。

v2x信息中包括车辆类型，根据车辆类型能够将采集到的v2x信息进行筛选。在一实施例中，在用户发生危险的前30秒内，以优先寻找紧急车辆作为目标，其中，紧急车辆包括警车、救护车和消防车等。

s412：根据紧急车辆提醒数据寻找第一预设搜索范围内是否存在紧急车辆。

在一实施例中，将在第一预设搜索范围内搜索紧急车辆，如以汽车的gps定位为中心，以该中心为圆心的半径150m内的范围进行搜索。

s413：若存在紧急车辆，则周期性地向紧急车辆发起救援请求。

在一实施例中，当在第一预设搜索范围内搜索到紧急车辆时，可以每隔五秒向紧急车辆发起救援请求，以引起紧急车辆的注意，使紧急车辆能够及时发现用户处于危险中。

在一实施例中，当第一预设搜索范围内同时存在警车、救护车和消防车时，将优先对警车发起救援请求；当第一预设搜索范围内同时存在救护车和消防车时，将优先对救护车发起救援请求。可以理解地，紧急车辆对用户可提供救援报警的相关程度不同。本实施例中可以按警车-救护车-消防车的优先级顺序发起救援请求，以使用户能够在同时搜索到多种类型的紧急车辆时，向可提供救援报警的相关程度较高的紧急车辆发起救援请求，达到更优的救援效果。

步骤s411-s413中，提供了一种按不同紧急等级发起救援请求的具体实施方式，通过采集v2x信息寻找紧急车辆，能够有针对性地发起救援请求，让紧急车辆更快速地发现处于险情的用户。该基于v2x信息寻找紧急车辆，发起救援请求的方式能够在不依托打车应用程序、打车服务平台等服务商的情况下实现通信交互，能够自动发起救援请求，无需用户主动触发，呼救的效率更高。

进一步地，在步骤s400中，步骤若确定用户存在危险，则按不同紧急等级发起救援请求，其中，紧急等级根据时间进行划分，具体还包括：

若在第一预设时间段内，第一预设搜索范围内不存在紧急车辆，则在第二预设时间段内，对第二预设搜索范围内的车辆发起救援请求。

可以理解地，找寻紧急车辆寻求救援是一种具有针对性的做法，紧急车辆上的人员若获知用户发起了救援请求，将会快速地安排人员进行救援。但是用户所在车辆不一定能够顺利搜索到紧急车辆，因此，在第二预设时间段内，若30秒内搜索不到紧急车辆，则向第二预设搜索范围内的车辆发起救援请求，其中，第一预设搜索范围和第二预设搜索范围可以是相同的。

在一实施例中，通过在第二预设时间段内，对第二预设搜索范围内的车辆发起救援请求，可以在搜索不到紧急车辆的情况下，向其他车辆进行求助，发起救援请求，以使其他乘客、或驾驶人员能够及时发现用户存在危险。

进一步地，在步骤s400中，若确定用户存在危险，则按不同紧急等级发起救援请求，具体还包括：

若在第二预设时间段内，第二搜索范围内不存在车辆，则向路侧单元发起救援请求，以使路侧单元在接收救援请求后对交通指示设备进行控制。

其中，路侧单元(roadsideunit，简称rsu)是指安装在路侧，能够与车辆的通信模块进行通讯，实现车辆身份识别、电子扣分、道路限速、障碍预警等功能的电子设备。

在一实施例中，当用户所在车辆附近没有可接收救援请求的车辆时，还可以通过向路侧单元发起救援请求。路侧单元可将救援请求发送到警局系统，实现快速报警，并且，还可以根据救援请求中包括的车辆信息控制交通指示设备，如在车辆到达红绿灯前将灯切换为红灯。

进一步地，救援请求采用点对点通信的方式发起，其中，通信过程采用v2x通信协议。

在一实施例中，救援请求采用点对点通信的方式发起，能够实现用户所在车辆和其他车辆一对一地进行通信，提高通信的安全性。此外，通信过程中采用的是v2x通信协议，采用该v2x的通信方式能够不依托打车应用程序、打车服务平台等服务商实现通信交互，能够自动发起救援请求，无需用户主动触发。

进一步地，为了实现救援请求采用点对点通信的方式，在一实施例中，具体可以在v2x通信协议传输的数据段中添加用户字段，该用户字段中包括发送方设备id、接收方设备id、发送方公钥和数据段是否进行加密的加密标志，采用该方式的点对点通信进行数据传输，能够提高救援请求的安全性，防止被歹徒截取破解。

图2示出了本申请实施例的一应用场景示意图，其中，哭脸表示处于危险中的用户，该用户可以是乘客，也可以是驾驶员，配备有可穿戴设备，该可穿戴设备具备v2x通信功能。

具体地，用户所在车辆上装有v2x通信模块，用户可通过可穿戴设备对用户所在车辆进行v2x信息的采集，得到用户所在车辆的车辆信息；如图2所示，图中右上车为警车，属于紧急车辆，其广播的v2x消息中的车辆类型为紧急车辆。图中右下车为普通车辆，非紧急车辆，在用户没找寻到紧急车辆时，可转向附近的普通车辆进行求助。左边道路上的设备为路侧单元。该路侧单元通过地下线缆与交通管理局、警局系统、支付系统等相连接，能够完成诸如近场支付、道路数据预警、接警报案等功能。乘客通过具备v2x通信功能的穿戴设备与路侧单元进行通信，可将救援请求自动发送出去，快速传达救援请求。

图3示出了本申请实施例的又一流程图，其中，配备可穿戴设备的用户在本实施例中具体是指一名乘客。

步骤一：乘客设置可穿戴设备进入乘车模式。

步骤二：可穿戴设备采集v2x信息，通过距离确定用户所在车辆的车辆标识，并根据车辆标识收集用户所在车辆的车辆信息。

步骤三：可穿戴设备通过分析传感器数据检测到用户存在危险。

步骤四：按不同救援等级周期性地执行救援请求，直到救援请求被停止。

步骤五：可穿戴设备通过车辆类型，寻找是否有警车在附近。

步骤六：若30秒内寻找到警车，跳转到步骤九；若30秒内没有寻找到警车，往下执行步骤七。

步骤七：若30秒内寻找到普通车辆，跳转到步骤十一；若30秒内没有寻找到普通车辆，往下执行步骤八。

步骤八：可穿戴设备发起救援请求到路侧单元，并请求下一个红绿灯为红灯。

步骤九：可穿戴设备向警车发送救援请求。

步骤十：警车展开救援。

步骤十一：可穿戴设备向普通车辆发送救援请求。

步骤十二：普通车辆的车机显示与救援请求相关的信息，车主协助报警。

具体地，乘客乘车时，将可穿戴设备设置成乘车模式，其中，可穿戴设备包括支持lte-v通信数据的rfic(集成电路)、gps定位芯片、陀螺仪传感器、加速度传感器、心率传感器。可穿戴设备进入乘车模式后，利用v2x通信模块(基于支持lte-v通信数据的rfic组成)接收车辆的广播消息，通过距离确定用户所在车辆的车辆标识，并根据车辆标识收集用户所在车辆的车辆信息，当穿戴设备通过分析传感器数据检测到用户存在危险时，将进入报警等级一，通过解析基础安全消息中的紧急车辆提醒数据，识别周边是否有警车。一旦发现有警车出现，则立即周期性的向警车发起救援请求；若持续30秒都没有找到紧急车辆，则进入报警等级二。报警等级二增加对周边普通车辆的寻找。寻找过程的优先级按人车距离排序，若持续30秒后用户所在车辆附近没有可接收救援请求的普通车辆时，还可以通过向路侧单元发起救援请求。路侧单元可将救援请求发送到警局系统，实现快速报警，并且，还可以根据救援请求中包括的车辆信息进行决策，控制交通指示设备。例如，在车辆到达红绿灯前将道路指示灯切换为红灯。以上，在用户未停止呼救请求前，会持续执行救援请求。

图4示出一传输的数据段的数据结构示意图。

可以理解地，为了实现点对点通信，使救援请求无法被用户所在车辆解析感知，可以在v2x通信协议中增加用户字段，如图4所示，用户字段中包括发送方设备id、接收方设备id、发送方公钥和数据段是否进行加密的加密标志。其中，当加密标志为真时，除用户字段外其他字段均由接收方设备的公钥进行加密，只有接收方设备使用自己的私钥方可解密。可以理解地，发送方公钥具体为非对称加密公钥。进一步地，若数据段加密过程支持多种公钥，则还应增加标识体现使用何种加密算法，以确定公钥长度和使用的加密算法。

在本申请实施例中，通过采集的v2x信息确定用户所在车辆的车辆标识，能够基于v2x通信方式，快速确认用户所乘坐的车辆，并根据用户所在车辆的车辆标识，使得用户能够在众多车辆中获取用户所在车辆的车辆信息；通过对传感器数据的采集，可根据传感器数据对用户是否存在危险进行检测，当检测确定用户存在危险时，可及时将包括车辆信息和呼叫信息的救援请求发送到接收设备。该救援请求可实现自动发送，无需用户主动触发，无需依赖打车应用程序，能够实现安全便捷的呼救目的。

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

基于实施例中所提供的协同呼救方法，本申请实施例进一步给出实现上述方法实施例中各步骤及方法的装置实施例。

图5示出与实施例中协同呼救方法一一对应的协同呼救装置的原理框图。如图5所示，该协同呼救装置包括第一采集模块10、车辆信息获取模块20、第三采集模块30和救援请求模块40。其中，第一采集模块10、车辆信息获取模块20、第三采集模块30和救援请求模块40的实现功能与实施例中协同呼救方法对应的步骤一一对应，为避免赘述，本实施例不一一详述。

第一采集模块10，用于采集v2x信息，通过v2x信息确定用户所在车辆的车辆标识。

其中，v2x(vehicletoeverything)表示车辆与万物的基于lte(longtermevolution，长期演进)-v(vehicle)或dsrc(dedicatedshortrangecommunications，专用短程通信技术)的通信互联，能够以车辆作为主体与其他事物进行通信互联，例如，车与车、车与可穿戴设备、车与路侧单元等之间的通信互联。

在一实施例中，可穿戴设备通过v2x通信采集v2x信息，其中，该v2x信息包括bsm(basicsafetymessage，基础安全消息)，该基础安全消息为车辆进行v2x通信时所广播的信息，包括车辆vin(vehicleidentificationnumber)码、车辆行驶速度、形式航向、地理位置、加速度、预测路径、历史路径和车辆类型等。可以理解地，用户在驾驶或乘坐车辆时，可通过身上的可穿戴设备采集v2x信息，建立起用户的可穿戴设备、用户所在车辆与通信范围内其他车辆的通信互联关系。

车辆标识是指能够唯一识别车辆的标识，具体可以将v2x信息中的车辆vin码作为车辆标识。其中，该车辆vin码是一组由十七个英数组成，用于汽车上的一组独一无二的号码，可以识别汽车的生产商、引擎、底盘序号及其他性能等资料。本申请实施例能够基于v2x的通信方式，快速确认用户所在车辆的车辆标识。

车辆信息获取模块20，用于根据用户所在车辆的车辆标识，获取用户所在车辆的车辆信息。

其中，用户所在车辆的车辆信息是指对用户正在乘坐、驾驶的车采集得到的v2x信息，包括用户所在车辆的基础安全消息。

可以理解地，假设用户遇到了危险，则在呼救时需要发送用户所在车辆的车辆信息，才能够让援救方快速确定用户所在地理位置进行援救。

在一实施例中，可根据车辆vin码，在众多车辆采集的v2x信息中获取得到用户所在车辆的车辆信息，也可以根据车辆标识，采用可穿戴设备的通信数据模块，如支持lte-v通信数据的rfic(射频集成电路)，接收车辆的v2x通信模块发出的广播信息，采集得到用户所在车辆的车辆信息。本申请实施例中，能够使用户在众多车辆中获取用户所在车辆的车辆信息，以在用户发生危险时，能够快速将用户所在车辆的车辆信息及时发送到其他车辆或者路侧单元，使得救援人员能够快速准确地确定用户当前的地理位置等信息。

第三采集模块30，用于采集传感器数据，并根据传感器数据对用户是否存在危险进行检测。

其中，可穿戴设备包括多种传感器，传感器采集的传感器数据能够体现出用户的个人健康状况，如用户是否有受惊吓、恐惧等不良精神状态出现；如用户身体状态是否发生异常情况，例如身体移动速度变化的幅度、翻转幅度是否过大等异常情况出现，通过这些传感数据能够对用户是否存在危险进行检测。

救援请求模块40，用于若确定用户存在危险，则发起救援请求，其中，救援请求包括车辆信息和呼叫信息。

其中，呼救信息包括用户的使用状态，具体为“sos求救”状态，以及包括个人健康状况等信息。该呼叫信息能够在用户遇到危险时及时发送到其他车辆或者路侧单元，以使用户遇险的情况被快速获知。可以理解地，除了呼救信息，为了使救援人员更有效的资源，还需要提供用户所在车辆的车辆信息，包括车辆行驶速度、形式航向、地理位置、加速度、预测路径与历史路径、车辆类型等基础安全消息。通过车辆信息和呼叫信息能够将用户的当前状况及时地发送出去，提高救援效率。

可选地，v2x信息中包括gps数据。

可选地，第一采集模块10，具体用于：

根据gps数据计算用户和周边车辆的距离，其中，预设地理范围内的车辆为周边车辆。

在预设时间段内，将与用户的距离持续在1.5米内的周边车辆确定为用户所在车辆。

根据用户所在车辆确定用户所在车辆的车辆标识。

具体地，可将以用户所在地理位置为中心，半径150m范围内的车辆作为周边车辆。

可以理解地，v2x信息中包括gps(globalpositioningsystem)数据，也即车辆的地理位置的数据，用户可通过车辆的gps数据确定用户所在车辆的车辆标识。

在一实施例中，用户在通过可穿戴设备的v2x通信模块接收周边车辆的广播信息，得到基础安全消息后，将根据基础安全消息中的gps数据计算用户和周边车辆的距离，以对用户和周边车辆的距离进行分析，确定用户所在车辆。

可以理解地，前后车在行驶状态下安全距离应在10米以上，因此用户在正常车辆行驶的情况下与前后车的距离不可能一直在1.5米内；而对于左右车距，安全行驶的平均左右车距为1.2米，而车身宽度为1.5米以上，因此，用户上车车辆从静止起步到用户遇到危险，始终有车辆与本车并行行驶导致人车距离在1.5米内也基本不可能。

在一实施例中，在预设时间段内，若用户和周边车辆的距离持续在1.5米内，则将该周边车辆确定为用户所在车辆，若在用户遇到危险时，可将用户所在车辆标记为危险车辆，并生成呼救信息，其中，呼救信息包括vrucw(vulnerableroadusercollisionwarning，弱势交通参与者碰撞预警)用户数据：包括用户的使用状态为“sos求救”，包括个人健康状况等。该呼叫信息能够在用户遇到危险时及时发送到其他车辆或者路侧单元，以使用户遇险的情况被快速获知。

在一实施例中，当确定用户所在车辆后，可选取能够唯一识别的标识作为车辆标识。具体地，可以将用户所在车辆的车辆vin码作为车辆标识，可方便后续可穿戴设备根据车辆的车辆vin码对用户所在车辆通过广播发送的v2x信息进行采集。

可选地，传感器数据包括角速度、加速度和心率。

可选地，第三采集模块30，具体用于：

采集角速度、加速度和心率。

根据角速度、加速度和心率是否满足预设的危险判定条件检测用户是否存在危险，其中，当角速度、加速度和心率满足预设的危险判定条件时，确定用户存在危险。

在一实施例中，可穿戴设备包括陀螺仪传感器、加速度传感器和心率传感器等传感器，可根据陀螺仪传感器、加速度传感器和心率传感器等传感器采集的角速度、加速度和心率等数据检测用户的个人健康状况，有助于判断用户是否存在危险。

在一实施例中，当角速度、加速度和心率满足预设的危险判定条件时，如在第一时间区间内同时满足角速度的平均值大于第一预设阈值和加速度的平均值大于第二预设阈值，则认为用户存在危险；或者，在第二时间区间内心率的平均值大于第三预设阈值时，认为用户存在危险。

可选地，救援请求模块40，具体用于：

若确定用户存在危险，则按不同紧急等级发起救援请求，其中，紧急等级根据时间进行划分。

在一实施例中，具体可以根据时间划分救援请求的紧急程度。根据不同的紧急程度发起的救援请求具有更强的针对性，能够更加合理地利用周边资源进行求救，提高救援效率和成功率。

可选地，救援请求模块40，还具体用于：

在第一预设时间段内，根据v2x信息得到紧急车辆提醒数据。

根据紧急车辆提醒数据寻找第一预设搜索范围内是否存在紧急车辆。

若存在紧急车辆，则周期性地向紧急车辆发起救援请求。

其中，紧急车辆提醒(emergencyvehiclewarning，evw)是识别紧急车辆的类型标识。

v2x信息中包括车辆类型，根据车辆类型能够将采集到的v2x信息进行筛选。在一实施例中，在用户发生危险的前30秒内，以优先寻找紧急车辆作为目标，其中，紧急车辆包括警车、救护车和消防车等。

在一实施例中，将在第一预设搜索范围内搜索紧急车辆，如以汽车的gps定位为中心，以该中心为圆心的半径150m内的范围进行搜索。

在一实施例中，当在第一预设搜索范围内搜索到紧急车辆时，可以每隔五秒向紧急车辆发起救援请求，以引起紧急车辆的注意，使紧急车辆能够及时发现用户处于危险中。

在一实施例中，当第一预设搜索范围内同时存在警车、救护车和消防车时，将优先对警车发起救援请求；当第一预设搜索范围内同时存在救护车和消防车时，将优先对救护车发起救援请求。可以理解地，紧急车辆对用户可提供救援报警的相关程度不同。本实施例中可以按警车-救护车-消防车的优先级顺序发起救援请求，以使用户能够在同时搜索到多种类型的紧急车辆时，向可提供救援报警的相关程度较高的紧急车辆发起救援请求，达到更优的救援效果。

可选地，救援请求模块40，还具体用于：

若在第一预设时间段内，第一预设搜索范围内不存在紧急车辆，则在第二预设时间段内，对第二预设搜索范围内的车辆发起救援请求。

可以理解地，找寻紧急车辆寻求救援是一种具有针对性的做法，紧急车辆上的人员若获知用户发起了救援请求，将会快速地安排人员进行救援。但是用户所在车辆不一定能够顺利搜索到紧急车辆，因此，在第二预设时间段内，如30秒内搜索不到紧急车辆，则向第二预设搜索范围内的车辆发起救援请求，其中，第一预设搜索范围和第二预设搜索范围可以是相同的。

在一实施例中，通过在第二预设时间段内，对第二预设搜索范围内的车辆发起救援请求，可以在搜索不到紧急车辆的情况下，向其他车辆进行求助，发起救援请求，以使其他乘客、或驾驶人员能够及时发现用户存在危险。

可选地，救援请求模块40，还具体用于：

若在第二预设时间段内，第二搜索范围内不存在车辆，则向路侧单元发起救援请求，以使路侧单元在接收救援请求后对交通指示设备进行控制。

其中，路侧单元(roadsideunit，简称rsu)是指安装在路侧，能够与车辆的通信模块进行通讯，实现车辆身份识别、电子扣分、道路限速、障碍预警等功能的电子设备。

在一实施例中，当用户所在车辆附近没有可接收救援请求的车辆时，还可以通过向路侧单元发起救援请求。路侧单元可将救援请求发送到警局系统，实现快速报警，并且，还可以根据救援请求中包括的车辆信息控制交通指示设备，如在车辆到达红绿灯前将灯切换为红灯。

可选地，救援请求采用点对点通信的方式发起，其中，通信过程采用v2x通信协议。

可选地，v2x通信协议传输的数据段中包括用户字段，用户字段中包括发送方设备id、接收方设备id、发送方公钥和数据段是否进行加密的加密标志。

在一实施例中，救援请求采用点对点通信的方式发起，能够实现用户所在车辆和其他车辆一对一地进行通信，能够提高通信的安全性。此外，通信过程中采用的是v2x通信协议，采用该v2x的通信方式能够不依托打车应用程序、打车服务平台等服务商实现通信交互，能够自动发起救援请求，无需用户主动触发。

进一步地，为了实现救援请求采用点对点通信的方式，在一实施例中，具体可以在v2x通信协议传输的数据段中添加用户字段，该用户字段中包括发送方设备id、接收方设备id、发送方公钥和数据段是否进行加密的加密标志，采用该方式的点对点通信进行数据传输，能够提高救援请求的保密性，防止被歹徒截取破解。

在本申请实施例中，通过采集的v2x信息确定用户所在车辆的车辆标识，能够基于v2x的点对点短距通信方式，快速确认用户所乘坐的车辆，并根据用户所在车辆的车辆标识，使得用户能够在众多车辆中获取用户所在车辆的车辆信息；通过对传感器数据的采集，可根据传感器数据对用户是否存在危险进行检测，当检测确定用户存在危险时，可及时将包括用户所在车辆的车辆标识和车辆信息的救援请求发送到接收设备。该救援请求可实现自动发送，无需用户主动触发，无需依赖打车应用程序，能够实现安全便捷的呼救目的。

本实施例提供一计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现实施例中协同呼救方法，为避免重复，此处不一一赘述。或者，该计算机程序被处理器执行时实现实施例中协同呼救装置中各模块/单元的功能，为避免重复，此处不一一赘述。

图6是本申请一实施例提供的可穿戴设备的示意图。如图6所示，该实施例的可穿戴设备50包括：处理器51、存储器52以及存储在存储器52中并可在处理器51上运行的计算机程序53，该计算机程序53被处理器51执行时实现实施例中协同呼救方法。或者，该计算机程序53被处理器51执行时实现实施例中与协同呼救方法一一对应的协同呼救装置中各模型/单元的功能。

可穿戴设备50可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。可穿戴设备50可包括，但不仅限于，处理器51、存储器52。本领域技术人员可以理解，图6仅仅是可穿戴设备50的示例，并不构成对可穿戴设备50的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如可穿戴设备还可以包括输入输出设备、网络接入设备、总线等。

所称处理器51可以是中央处理单元(centralprocessingunit，cpu)，还可以是其他通用处理器、数字信号处理器(digitalsignalprocessor，dsp)、专用集成电路(applicationspecificintegratedcircuit，asic)、现场可编程门阵列(field-programmablegatearray，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器52可以是可穿戴设备50的内部存储单元，例如可穿戴设备50的硬盘或内存。存储器52也可以是可穿戴设备50的外部存储设备，例如可穿戴设备50上配备的插接式硬盘，智能存储卡(smartmediacard,smc)，安全数字(securedigital,sd)卡，闪存卡(flashcard)等。进一步地，存储器52还可以既包括可穿戴设备50的内部存储单元也包括外部存储设备。存储器52用于存储计算机程序以及可穿戴设备所需的其他程序和数据。存储器52还可以用于暂时地存储已经输出或者将要输出的数据。

应当明确，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在本申请实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。

应当理解，本文中使用的术语“和/或”仅仅是一种描述关联对象的相同的字段，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

应当理解，尽管在本申请实施例中可能采用术语第一、第二、第三等来描述预设范围等，但这些预设范围不应限于这些术语。这些术语仅用来将预设范围彼此区分开。例如，在不脱离本申请实施例范围的情况下，第一预设范围也可以被称为第二预设范围，类似地，第二预设范围也可以被称为第一预设范围。

取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”或“响应于检测”。类似地，取决于语境，短语“如果确定”或“如果检测(陈述的条件或事件)”可以被解释成为“当确定时”或“响应于确定”或“当检测(陈述的条件或事件)时”或“响应于检测(陈述的条件或事件)”。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。

以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。