一种救援消息推送方法及装置与流程

本申请涉及安全技术领域，尤其涉及一种救援消息推送方法、装置及计算机存储介质和电子设备。

背景技术：

随着互联网的不断发展，基于互联网的出行方式(如网约车，共享单车等)不断出现。这些出行方式的出现，在方便了大众出行的同时，也带来了一定的安全隐患。

以网约车出行为例，乘客上车后，司机和乘客需要在相对封闭的环境中相处较长时间；期间如果发生安全事件(如交通事故、违法犯罪行为)，平台无法相应做出处理。

在实际发生安全事件后，司机或乘客往往需要自己联系救援，平台主要是在事后进行处理，无法提供及时的帮助。

因此，需要提供一种针对出行场景下发生安全事件后及时救援的方案。

技术实现要素：

有鉴于此，本申请提供一种救援消息推送方法、装置及计算机存储介质和电子设备，用于解决上述的救援不及时的问题。

具体地，本申请是通过如下技术方案实现的：

一种救援消息推送方法，所述方法包括：

监控进行中的出行订单；

如果接收到所述出行订单的相关方发出的救援请求，获取所述出行订单中车辆的行驶记录；

根据所述行驶记录确定用于进行救援的目标救援方；

将包含所述行驶记录的救援消息推送给所述目标救援方。

可选的，还包括：

根据所述救援请求中携带的求救信息，确定救援类型；

将包含所述行驶记录的救援消息推送给所述目标救援方，具体包括：

将所述救援类型对应的救援消息推送给所述目标救援方；其中，所述救援信息中包含有所述行驶记录。

可选的，所述求救信息包括文字、语音、视频、图片中的至少一种；

所述救援类型包括转送乘客、协调处理、追踪车辆中的至少一种。

可选的，所述行驶记录包括最新的车辆位置信息；

所述根据所述行驶记录确定用于进行救援的目标救援方，具体包括：

根据所述车辆位置信息匹配该车辆位置信息周边预设范围内的目标救援方；

所述将包含所述行驶记录的救援信息推送给所述目标救援方，具体包括：

将包含所述车辆位置信息的救援消息推送给所述目标救援方。

可选的，根据所述车辆位置信息匹配该车辆位置信息周边预设范围内的目标救援方，具体包括：

根据所述车辆位置信息确定预设范围；

获取所述预设范围内所有可用的救援方；

计算每个救援方与所述车辆位置信息的距离；

将所述距离满足预设条件的救援方确定为目标救援方。

可选的，所述行驶记录包括最新的车辆行驶信息；

所述根据所述行驶记录确定用于进行救援的目标救援方，具体包括：

根据所述车辆行驶信息，计算预设时长内的车辆行驶轨迹；

根据所述车辆行驶轨迹，匹配该车辆行驶轨迹周边预设范围内的目标救援方；

所述将包含所述行驶记录的救援消息推送给所述目标救援方，具体包括：

将包含所述车辆行驶轨迹的救援消息推送给所述目标救援方。

可选的，所述车辆行驶信息包括车辆位置信息、行驶方向和行驶速度；所述根据所述车辆行驶信息，计算预设时长内的车辆行驶轨迹，具体包括：

根据所述车辆位置信息，确定车辆所在的道路；

根据所述行驶方向和行驶速度，生成所述车辆在预设时长内沿所述道路进行的行驶轨迹。

可选的，所述根据所述车辆行驶轨迹，匹配该车辆行驶轨迹周边预设范围内的目标救援方，具体包括：

将所述车辆行驶轨迹两侧预设长度内的区域确定为预设范围；

获取所述预设范围内所有可用的救援方；

计算每个救援方与所述车辆行驶轨迹的距离；

将所述距离满足预设条件的救援方确定为目标救援方。

可选的，还包括：

当所述出行订单为骑行订单时，所述车辆的行驶记录由骑车用户端上传；

当所述出行订单为打车订单时，所述车辆的行驶记录由乘客端和/或司机端上传。

一种救援消息推送装置，所述装置包括：

监控单元，监控进行中的出行订单；

获取单元，如果接收到所述出行订单中用户端发出的救援请求，获取所述用户端的行驶记录；

匹配单元，根据所述行驶记录确定用于进行救援的目标救援方；

推送单元，将包含所述行驶记录的救援消息推送给所述目标救援方。

一种计算机可读存储介质，所述存储介质存储有计算机程序，所述计算机程序用于执行上述任一项所述的救援消息推送方法。

一种电子设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

所述处理器被配置为上述任一项所述的救援消息推送方法。

本申请实施例，提供了一种救援消息推送方案，通过监控进行中的出行订单，当接收到该出行订单的救援请求后，可以及时通知到该出行订单中车辆所在位置附近的救援方，以使救援方在第一时间前去实施救援，大大降低了安全风险。

附图说明

图1是本申请一示例性实施例示出的一种救援消息推送方法的流程图；

图2是本申请一示例性实施例示出的一种救援消息推送装置的硬件结构图；

图3是本申请一示例性实施例示出的一种救援消息推送装置的模块示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

图1是本申请一示例性实施例示出的一种救援消息推送的方法流程图，所述方法可以应用在救援消息推送的服务端(以下简称为服务端)中，该方法具体可以包括如下步骤：

步骤110：监控进行中的出行订单；

步骤120：如果接收到所述出行订单的相关方发出的救援请求，获取所述出行订单中车辆的行驶记录；

步骤130：根据所述行驶记录确定用于进行救援的目标救援方；

步骤140：将包含所述行驶记录的救援消息推送给所述目标救援方。

本申请中，所述服务端具体可以是指出行应用对应的服务器、服务器集群或者由服务器集群构建的云平台。

所述行驶记录可以由用户端上传。所述用户端可以是指软件上的应用客户端；具体地可以是指用户终端上安装的出行应用app和或车辆内置终端上安装的出行应用app。

所述出行订单可以是指打车订单，当所述出行订单为打车订单时，所述车辆的行驶记录可以由乘客端和/或司机端上传，也可以由车辆内置的终端上传。

所述出行订单还可以是指骑行订单(例如共享自行车、共享电动自行车)，当所述出行订单为骑行订单时，所述车辆的行驶记录可以由骑车用户端上传，也可以由共享自行车或共享电动自行车内置的终端上传。

所述出行订单还可以是指共享汽车订单，当所述出行订单为共享汽车订单时，所述车辆的行驶记录可以由使用该共享汽车的用户端上传，也可以由共享汽车内置的终端上传。

以下介绍骑行订单的示例：

所述骑行订单具体可以是指共享单车的订单，当用户成功扫码共享单车后就可以形成骑行订单。

所述骑行订单具体还可以是指共享电动自行车，当用户成功扫码共享电动自行车后就可以形成骑行订单。

所述骑行订单具体还可以是指具有固定停放点的单车或电动自行车。这里的固定停放点可以是指设置有固定桩的用于停放单车或电动自行车的地点；其中所述固定桩设置有用于固定单车或电动自行车的锁。

需要说明的，通常共享单车(或称为共享自行车)以及共享电动自行车(或称为共享电瓶车)可以是指无固定停放点的、随停随走的单车或电动自行车。其区别与那些需要停放到固定停放的租赁单车或电动自行车。

以下介绍打车订单的示例：

所述打车订单具体可以是指网约车、出租车等出行订单。当用户成功预约网约车或出租车后就可以形成打车订单。

所述网约车具体可以是指快车、拼车、顺风车、专车等不同类似的网约车。

以下介绍共享汽车订单的示例：

所述共享汽车，是一种短期或长期租赁汽车的方式。共享汽车与传统汽车租赁的区别在于，共享汽车运营方将汽车停放到某些位置后，无需实时管理；用户通过app成功租赁后，可以在任意可停放的位置停车并可以在线完成退车手续，无需将车辆规划到指定位置。

本申请实施例中，服务端可以实时监控进行中的出行订单；所述进行中的出行订单可以是指已经开始并且还未完成的出行订单。

所述出行订单的相关方，可以是指用户端，例如司机使用的终端、乘客使用的终端；还可以是指司机或者乘客预先设置的紧急联系人。

其中，所述相关方在出行订单还在进行中时，可以提供发送救援请求的功能；例如用户可以在出行界面中点击发送救援请求，从而向服务端发送救援请求。或者，用户可以配置快捷发送救援请求，例如按下用户端所在终端上的某个按键或组合键就可以自动向服务端发送救援请求。再例如，紧急联系人发现无法联系到乘客后，可以向出行平台发起救援请求。

在一实施例中，所述救援请求可以携带具体的求救信息。所述求救信息可以包括文字、语音、视频、图片中的至少一种。

举例说明，用户可在出行界面中点击发送救援请求，并且输入求救信息，可以是一段文字，也可以是一段语音，还可以是一段视频；待确认输入的求救信息后即可以发送救援请求。

在一实施例中，所述服务端还可以根据所述救援请求中携带的求救信息，确定救援类型；

相应地，所述将包含所述行驶记录的救援消息推送给所述目标救援方，具体包括：

将所述救援类型对应的救援消息推送给所述目标救援方；其中，所述救援信息中包含有所述行驶记录。

其中，所述救援类型包括转送乘客、协调处理、追踪车辆中的至少一种。

以打车订单为例，当服务端接收到乘客端或司机端发送救援请求后，可以根据救援请求中的求救信息确定救援类型。例如，求救信息为“车辆追尾，需要转送乘客”，则可以确定救援类型为“转送乘客”；这里的转送乘客具体可以是指请求目标救援方将乘客送达目的地。再例如，求救信息为“车辆追尾，需要转送乘客”，则可以确定救援类型为“转送乘客”；这里的转送乘客具体可以是指请求目标救援方将乘客送达目的地。

在一实施例中，所述根据所述救援请求中携带的求救信息，确定救援类型，可以是由服务端根据预设的救援类型识别模型或算法自动识别出的救援类型。所述模型或算法可以是基于机器学习模型训练得到的。

在另一实施例中，所述根据所述救援请求中携带的求救信息，确定救援类型，还可以基于人工客服工人识别后提交给服务端的。

本申请中，服务端在接收到所述出行订单中相关方发出的救援请求后，进一步可以获取所述出行订单中车辆的行驶记录。

在一实施例中，所述行驶记录可以包括最新的车辆位置信息。其中，所述车辆位置信息可以是指用户端(乘客端、司机端和/或车辆内置终端)所在中的位置信息，

可以是指用户端所在终端的位置信息。

具体地，所述位置信息是指终端的定位装置记录下的位置，该位置可以是代表地理位置的坐标信息。常见的定位装置可以是采用美国gps卫星导航系统，欧洲“伽利略”卫星导航系统，俄罗斯glonass卫星导航系统，或者中国“北斗”卫星导航系统等，或者类似的组合。这类定位的坐标信息也称为移动定位。并且，通常情况下上报的位置还携带有上报的时间戳，所述时间戳可以是上述定位装置确定位置时的时间；或者，可以是终端上报位置时的时间。根据时间戳可以确定最接近当前时刻下终端的位置。

所述位置信息，可以是网络设备基于所述终端的信号特点转换得到的，例如由网络运营商利用基站覆盖原理，通过所述终端的信号通过基站定位计算得到的位置。在后者的定位计算中，一般由终端测量不同基站的下行导频信号，得到不同基站下行导频的到达时刻(timeofarrival，toa)或到达时间差(timedifferenceofarrival，tdoa)，根据该测量结果并结合基站的坐标，一般采用三角公式估计算法，从而计算出终端的位置。实际的位置估计算法需要考虑多基站(3个或3个以上)定位的情况，现有技术中有多种算法，较为复杂。一般而言，移动台测量的基站数目越多，测量精度越高，定位性能改善越明显。

此外，所述位置信息，还可以是通过基站辅助定位并结合终端中的定位装置共同定位得到的较为精确的位置。

所述步骤130，根据所述行驶记录确定用于进行救援的目标救援方，具体包括：

根据所述车辆位置信息匹配该车辆位置信息周边预设范围内的目标救援方；

在获取到车辆位置信息后，服务端可以根据所述车辆位置信息，匹配该车辆位置信息周边预设范围内的目标救援方。

在一实施例中，根据所述车辆位置信息匹配该车辆位置信息周边预设范围内的目标救援方，具体包括：

根据所述车辆位置信息确定预设范围；

获取所述预设范围内所有可用的救援方；

计算每个救援方与所述位置信息的距离；

将所述距离满足预设条件的救援方确定为目标救援方。

在一实施例中，将所述距离满足预设条件的救援方确定为目标救援方，具体包括：

将所述距离小于阈值的救援方确定为目标救援方；

或者，将距离最短的预设数量的救援方确定为目标救援方。

这里的距离最短的预设数量是指，距离从短开始排名前预设数量。

举例说明，假设计算的距离分别为1km、3km和2km，并且预设数量为2；那么需要从这3个距离中选取距离最短的2个救援方作为目标救援方，即将1km和2km的救援方确定为目标救援方。

其中，根据所述车辆位置信息确定预设范围，可以包括：

以该位置信息为圆心，以预设长度为半径，确定圆形的预设范围。

需要说明的是，圆形的预设范围仅是一种示例，在实际应用中，可以根据实际需要确定任意形状的预设范围。

所述步骤140所述将包含所述行驶记录的救援信息推送给所述目标救援方，具体包括：

将包含所述车辆位置信息的救援消息推送给所述目标救援方。

该实施例中，救援方可以包括出行平台下的其它用户，例如网约车的司机；还可以是有合作关系的用户，例如外卖平台的骑手；还可以是国家救援单位，例如医院、公安等。

服务端可以第一时间调动发生安全事件的车辆周边一定范围内具备救援资质的救援方前去救援用户。由于这些救援方距离用户较近，可以在发生险情后第一时间前往事发地进行救援，缩短了救援时间降低了安全风险。

上述实施例是针对车辆的位置不变的情况下进行快速救援的方案，而在有的情况下，车辆的位置信息可能是移动的，随着时间发生移动。例如，打车场景下，用户的位置会由于车辆行驶发生改变。当前确定的目标救援方可能需要花很长时间进行追赶，无疑增加了救援时间；如何减少救援时间，以最快完成救援是一个亟须解决的问题。为此本申请提供了一个可选的方案，在图1所示实施例基础上，结合出行订单的车辆行驶信息，预测车辆行驶轨迹，以获取最优的目标救援方，具体地所述方法还可以包括：

所述行驶记录包括最新的车辆行驶信息；

所述步骤130根据所述行驶记录确定用于进行救援的目标救援方，具体包括：

根据所述车辆行驶信息，计算预设时长内的车辆行驶轨迹；

根据所述车辆行驶轨迹，匹配该车辆行驶轨迹周边预设范围内的目标救援方；

所述步骤140将包含所述行驶记录的救援消息推送给所述目标救援方，具体包括：

将包含所述车辆行驶轨迹的救援消息推送给所述目标救援方。

其中，所述车辆行驶信息包括车辆位置信息、行驶方向和行驶速度。

在一实施例中，所述根据所述车辆行驶信息，计算预设时长内的车辆行驶轨迹，具体包括：

根据所述车辆位置信息，确定车辆所在的道路；

根据所述行驶方向和行驶速度，生成所述车辆在预设时长内沿所述道路进行的行驶轨迹。

其中，车辆位置信息可以是与用户端的位置信息相同。

服务端可以结合导航地图确定车辆位置信息当前所行驶的道路；再结合行驶方向确定车辆在该道路上的行驶方向；最后根据行驶速度，预测预设时长内车辆到道路上可能行进的行驶轨迹。

所述行驶方向，可以根据车辆先后两个时刻的位置信息确定，假设前一时刻车辆的位置信息位于后一时刻的位置信息的东方，则可以确定车辆行驶方向为向西。

为了提升准确率，本申请中的车辆行驶信息可以实时的车辆行驶信息。如此，服务端不断根据最新的车辆行驶信息规划最新的车辆行驶轨迹，以匹配最优的目标救援方。

所述根据所述车辆行驶轨迹，匹配该车辆行驶轨迹周边预设范围内的目标救援方，具体包括：

将所述车辆行驶轨迹两侧预设长度内的区域确定为预设范围；

获取所述预设范围内所有可用的救援方；

计算每个救援方与所述车辆行驶轨迹的距离；

将所述距离满足预设条件的救援方确定为目标救援方。

与前述实施例中相同的，所述将所述距离满足预设条件的救援方确定为目标救援方，具体可以包括：

将所述距离小于阈值的救援方确定为目标救援方；

或者，将距离最短的预设数量的救援方确定为目标救援方。

该实施例中，服务端在确定了车辆行驶轨迹后，可以将车辆行驶轨迹两侧预设长度内的区域确定为预设范围，之后步骤与前述实施例相同，此处不再进行赘述。

通过将所述车辆行驶轨迹推送给所述目标救援方，使得目标救援方可以实时获取车辆位置，从而可以快速规划最优路径，以缩短救援时间。

值得一提的是，服务端还可以获取目标救援方的救援状态，以根据救援状态安排后续工作的进行。例如，当目标救援方到达求救用户时，服务端可以停止计算行驶轨迹，不再推送救援信息。再例如，当目标救援方无法完成救援时，服务端还可以呼叫更多救援方或者联系专业人员进行远程指导、联系最近的专业救援力量赶往支援、再例如，当目标救援方完成救援后，可以安排平台人员跟进，例如电话联系用户进行事后调查等。

综上，本申请实施例提供了一种救援消息推送方案，通过监控进行中的出行订单，当接收到该出行订单的救援请求后，可以及时通知到该出行订单中车辆所在位置附近的救援方，以使救援方在第一时间前去实施救援，大大降低了安全风险。

与前述救援消息推送方法的实施例相对应，本申请还提供了救援消息推送装置的实施例。

本申请救援消息推送装置的实施例可以应用在服务端上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图2所示，为本申请救援消息推送装置所在的一种硬件结构图，除了图2所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中通常根据该救援消息推送的实际功能，还可以包括其他硬件，对此不再赘述。

请参考图3，在一种软件实施方式中，该救援消息推送装置可以包括：

监控单元210，监控进行中的出行订单；

获取单元220，如果接收到所述出行订单的相关方发出的救援请求，获取所述出行订单中车辆的行驶记录；

匹配单元230，根据所述行驶记录确定用于进行救援的目标救援方；

推送单元240，将包含所述行驶记录的救援消息推送给所述目标救援方。

在一可选的实施例：

所述装置还包括：

类型确定子单元，根据所述救援请求中携带的求救信息，确定救援类型；

所述推送单元240，具体包括：

将所述救援类型对应的救援消息推送给所述目标救援方；其中，所述救援信息中包含有所述行驶记录。

在一可选的实施例：

所述求救信息包括文字、语音、视频、图片中的至少一种；

所述救援类型包括转送乘客、协调处理、追踪车辆中的至少一种。

在一可选的实施例：

所述行驶记录包括最新的车辆位置信息；所述匹配单元230，具体包括：

匹配子单元，根据所述车辆位置信息匹配该车辆位置信息周边预设范围内的目标救援方；

所述推送单元240，具体包括：

将包含所述车辆位置信息的救援消息推送给所述目标救援方。

在一可选的实施例：

所述匹配子单元，具体包括：

范围确定子单元，根据所述车辆位置信息确定预设范围；

目标获取子单元，获取所述预设范围内所有可用的救援方；

距离计算子单元，计算每个救援方与所述车辆位置信息的距离；

目标确定子单元，将所述距离满足预设条件的救援方确定为目标救援方。

在一可选的实施例：

所述行驶记录包括最新的车辆行驶信息；所述匹配单元230，具体包括：轨迹计算单元，根据所述车辆行驶信息，计算预设时长内的车辆行驶轨迹；

第二匹配单元，根据所述车辆行驶轨迹，匹配该车辆行驶轨迹周边预设范围内的目标救援方；

所述推送单元240，具体包括：

将包含所述车辆行驶轨迹的救援消息推送给所述目标救援方。

在一可选的实施例：

所述车辆行驶信息包括车辆位置信息、行驶方向和行驶速度：

所述轨迹计算单元，具体包括：

道路确定子单元，根据所述车辆位置信息，确定车辆所在的道路；

轨迹生成子单元，根据所述行驶方向和行驶速度，生成所述车辆在预设时长内沿所述道路进行的行驶轨迹。

在一可选的实施例：

所述第二匹配单元，具体包括：

范围确定子单元，将所述车辆行驶轨迹两侧预设长度内的区域确定为预设范围；

目标获取子单元，获取所述预设范围内所有可用的救援方；

距离计算子单元，计算每个救援方与所述车辆行驶轨迹的距离；

目标确定子单元，将所述距离满足预设条件的救援方确定为目标救援方。

在一可选的实施例：

当所述出行订单为骑行订单时，所述车辆的行驶记录由骑车用户端上传；

当所述出行订单为打车订单时，所述车辆的行驶记录由乘客端和/或司机端上传。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上图3描述了业务监控装置的内部功能模块和结构示意，其实质上的执行主体可以为一种电子设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为：

监控进行中的出行订单；

如果接收到所述出行订单的相关方发出的救援请求，获取所述出行订单中车辆的行驶记录；

根据所述行驶记录确定用于进行救援的目标救援方；

将包含所述行驶记录的救援消息推送给所述目标救援方。

可选的，还包括：

根据所述救援请求中携带的求救信息，确定救援类型；

将包含所述行驶记录的救援消息推送给所述目标救援方，具体包括：

将所述救援类型对应的救援消息推送给所述目标救援方；其中，所述救援信息中包含有所述行驶记录。

可选的，所述求救信息包括文字、语音、视频、图片中的至少一种；

所述救援类型包括转送乘客、协调处理、追踪车辆中的至少一种。

可选的，所述行驶记录包括最新的车辆位置信息；

所述根据所述行驶记录确定用于进行救援的目标救援方，具体包括：

根据所述车辆位置信息匹配该车辆位置信息周边预设范围内的目标救援方；

所述将包含所述行驶记录的救援信息推送给所述目标救援方，具体包括：

将包含所述车辆位置信息的救援消息推送给所述目标救援方。

可选的，根据所述车辆位置信息匹配该车辆位置信息周边预设范围内的目标救援方，具体包括：

根据所述车辆位置信息确定预设范围；

获取所述预设范围内所有可用的救援方；

计算每个救援方与所述车辆位置信息的距离；

将所述距离满足预设条件的救援方确定为目标救援方。

可选的，所述行驶记录包括最新的车辆行驶信息；

所述根据所述行驶记录确定用于进行救援的目标救援方，具体包括：

根据所述车辆行驶信息，计算预设时长内的车辆行驶轨迹；

根据所述车辆行驶轨迹，匹配该车辆行驶轨迹周边预设范围内的目标救援方；

所述将包含所述行驶记录的救援消息推送给所述目标救援方，具体包括：

将包含所述车辆行驶轨迹的救援消息推送给所述目标救援方。

可选的，所述车辆行驶信息包括车辆位置信息、行驶方向和行驶速度，具体包括：

所述根据所述车辆行驶信息，计算预设时长内的车辆行驶轨迹，具体包括：

根据所述车辆位置信息，确定车辆所在的道路；

根据所述行驶方向和行驶速度，生成所述车辆在预设时长内沿所述道路进行的行驶轨迹。

可选的，所述根据所述车辆行驶轨迹，匹配该车辆行驶轨迹周边预设范围内的目标救援方，具体包括：

将所述车辆行驶轨迹两侧预设长度内的区域确定为预设范围；

获取所述预设范围内所有可用的救援方；

计算每个救援方与所述车辆行驶轨迹的距离；

将所述距离满足预设条件的救援方确定为目标救援方。

可选的，还包括：

当所述出行订单为骑行订单时，所述车辆的行驶记录由骑车用户端上传；

当所述出行订单为打车订单时，所述车辆的行驶记录由乘客端和/或司机端上传。

在上述电子设备的实施例中，应理解，该处理器可以是中央处理单元(英文：centralprocessingunit，简称：cpu)，还可以是其他通用处理器、数字信号处理器(英文：digitalsignalprocessor，简称：dsp)、专用集成电路(英文：applicationspecificintegratedcircuit，简称：asic)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等，而前述的存储器可以是只读存储器(英文：read-onlymemory，缩写：rom)、随机存取存储器(英文：randomaccessmemory，简称：ram)、快闪存储器、硬盘或者固态硬盘。结合本发明实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

本申请中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于电子设备实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。