救援方法、救援装置、电子设备及计算机可读存储介质与流程

1.本技术属于数据处理技术领域，尤其涉及一种救援方法、救援装置、电子设备及计算机可读存储介质。


背景技术：

2.车辆在驾驶过程中，当车辆出现故障或者车内人员出现伤痛时，会通过拨打救援电话进行求救。当救援中心接到求救电话后，需要人工进行救援工作的安排，待救援工作安排结束后，被安排的救援人员才能前往求救地实施救援，导致救援效率低下。


技术实现要素：

3.本技术提供了一种救援方法、救援装置、电子设备及计算机可读存储介质，可以缩短车辆内被困人员获救所需的时间，提高救援效率。
4.第一方面，本技术提供了一种救援方法，包括：
5.获取求救信息，上述求救信息包括车内人员的体征信息；
6.判断上述体征信息是否正常，得到判断结果；
7.基于上述判断结果确定救援信息；
8.基于上述救援信息确定至少一个目标施救者；
9.向上述目标施救者推送上述救援信息。
10.可选地，上述基于上述判断结果确定救援信息，包括：
11.若上述判断结果为上述体征信息异常，则获取上述车辆的位置信息；
12.将上述位置信息及上述体征信息确定为上述救援信息。
13.可选地，上述基于上述判断结果确定救援信息，包括：
14.若上述判断结果为上述体征信息正常，则获取上述车辆的状态信息，上述状态信息用于描述上述车辆的行驶状态；
15.基于上述状态信息判断上述车辆是否故障；
16.若上述车辆故障，则获取上述车辆的故障信息以及位置信息；
17.将上述故障信息及上述位置信息确定为上述救援信息。
18.可选地，上述救援方法还包括：
19.若上述车辆未故障，则获取上述车辆所处环境的环境信息；
20.基于上述环境信息判断上述车辆周围是否出现灾情；
21.若上述车辆周围出现灾情，则获取上述车辆的位置信息；
22.将上述环境信息及上述位置信息确定为上述救援信息。
23.可选地，上述基于上述救援信息确定至少一个目标施救者，包括：
24.从预设的数据库中确定与上述体征信息匹配的候选施救者；
25.基于上述位置信息从上述候选施救者中确定上述目标施救者。
26.可选地，在上述向上述目标施救者推送上述救援信息之前，上述救援方法还包括：
27.基于上述体征信息确定施救所需物资的物资信息；
28.相应地，上述向上述目标施救者推送上述救援信息，包括：
29.向上述目标施救者推送上述救援信息以及上述物资信息。
30.可选地，在上述向上述目标施救者推送上述求救信息之后，上述救援方法还包括：
31.在预设时间段内统计反馈人数，上述反馈人数是上述目标施救者中已反馈确认救援信息的人数；
32.若上述反馈人数达到预设的人数阈值，则向未反馈确认救援信息的目标施救者发送提示信息，上述提示信息用于提示当前对上述车辆的救援人员已饱和。
33.第二方面，本技术提供了一种救援装置，包括：
34.第一获取模块，用于获取求救信息，上述求救信息包括车内人员的体征信息；
35.第一判断模块，用于判断上述体征信息是否正常，得到判断结果；
36.第一确定模块，用于基于上述判断结果确定救援信息；
37.第二确定模块，用于基于上述救援信息确定至少一个目标施救者；
38.推送模块，用于向上述目标施救者推送上述救援信息。
39.可选地，上述第一确定模块包括：
40.第一获取单元，用于若上述判断结果为上述体征信息异常，则获取上述车辆的位置信息；
41.第一确定单元，用于将上述位置信息及上述体征信息确定为上述救援信息。
42.可选地，上述第一确定模块还包括：
43.第二获取单元，用于若上述判断结果为上述体征信息正常，则获取上述车辆的状态信息，上述状态信息用于描述上述车辆的行驶状态；
44.第一判断单元，用于基于上述状态信息判断上述车辆是否故障；
45.第三获取单元，用于若上述车辆故障，则获取上述车辆的故障信息以及位置信息；
46.第二确定单元，用于将上述故障信息及上述位置信息确定为上述救援信息。
47.可选地，上述救援装置还包括：
48.第二获取模块，用于若上述车辆未故障，则获取上述车辆所处环境的环境信息；
49.第二判断模块，用于基于上述环境信息判断上述车辆周围是否出现灾情；
50.第三获取模块，用于若上述车辆周围出现灾情，则获取上述车辆的位置信息；
51.第三确定模块，用于将上述环境信息及上述位置信息确定为上述救援信息。
52.可选地，上述第二确定模块包括：
53.第三确定单元，用于从预设的数据库中确定与上述体征信息匹配的候选施救者；
54.第四确定单元，用于基于上述位置信息从上述候选施救者中确定上述目标施救者。
55.可选地，上述救援装置还包括：
56.第四确定模块，用于基于上述体征信息确定施救所需物资的物资信息；
57.相应地，上述推送模块具体用于向上述目标施救者推送上述救援信息以及上述物资信息。
58.可选地，上述救援装置还包括：
59.统计模块，用于在预设时间段内统计反馈人数，上述反馈人数是上述目标施救者
中已反馈确认救援信息的人数；
60.提示模块，用于若上述反馈人数达到预设的人数阈值，则向未反馈确认救援信息的目标施救者发送提示信息，上述提示信息用于提示当前对上述车辆的救援人员已饱和。
61.第三方面，本技术提供了一种电子设备，上述电子设备包括存储器、处理器以及存储在上述存储器中并可在上述处理器上运行的计算机程序，上述处理器执行上述计算机程序时实现如上述第一方面的方法的步骤。
62.第四方面，本技术提供了一种计算机可读存储介质，上述计算机可读存储介质存储有计算机程序，上述计算机程序被处理器执行时实现如上述第一方面的方法的步骤。
63.第五方面，本技术提供了一种计算机程序产品，上述计算机程序产品包括计算机程序，上述计算机程序被一个或多个处理器执行时实现如上述第一方面的方法的步骤。
64.本技术与现有技术相比存在的有益效果是：获取求救信息，求救信息包括车内人员的体征信息；判断体征信息是否正常，得到判断结果；基于判断结果确定救援信息；基于救援信息确定至少一个目标施救者；向目标施救者推送救援信息。本技术通过判断求救信息中的车内人员的体征信息是否正常，得到判断结果后，基于判断结果确定出救援信息，并基于救援信息确定出至少一个目标施救者，通过向目标施救者推送救援信息，可以无需人工进行救援工作安排，直接结合救援信息匹配得到目标施救者，进而通过向目标施救者推送救援消息以缩短车辆内被困人员获救所需的时间，提高救援效率。
附图说明
65.为了更清楚地说明本技术实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
66.图1是本技术实施例提供的救援方法的流程示意图；
67.图2是本技术实施例提供的救援装置的结构示意图；
68.图3是本技术实施例提供的电子设备的结构示意图。
具体实施方式
69.以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本技术实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本技术。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本技术的描述。
70.本技术实施例提供的救援方法可以应用于手机、平板电脑、车载设备、增强现实(augmented reality，ar)/虚拟现实(virtual reality，vr)设备、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，umpc)、上网本、个人数字助理(personal digital assistant，pda)等电子设备上，本技术实施例对电子设备的具体类型不作任何限制。
71.车辆在驾驶过程中，如果车内人员出现伤痛，一般是通过拨打救援电话进行求救。当救援中心接到求救电话后，需要人工进行救援工作的安排，救援工作安排结束后由救援
人员前往救援地。在该过程中，人工进行救援工作的安排存在两个问题，一个是安排效率较低，导致求救人员需要等待的时间加长；另一个是因车辆内人员处于被困的状态，可能会比较慌乱，无法准确描述伤员的症状，导致目标施救者确定的准确率较低。一旦求救需求对时效性要求较高，上述两个问题则有可能导致救援不及时以及救援效率较低的问题。针对该问题，本技术提出了一种救援方法，能够缩短车辆的被困人员获救所需的时间，并提高救援效率。
72.为了说明本技术所提出的技术方案，下面通过具体实施例来进行说明。
73.图1示出了本技术提供的救援方法的示意性流程图，作为示例而非限定，该救援方法可以应用于上述任意一种电子设备中，下面以电子设备为车载设备为例进行说明。具体地，该救援方法如下：
74.步骤101、获取求救信息。
75.一般，车辆出现事故时，车内人员的生命安全会被优先考虑。因此，为了让车内人员的生命安全得到保障，当车辆出现事故时，可以由车载设备获取求救信息。具体地，求救信息可以包括车内人员的体征信息。通过车内人员体征信息的获取，能够快速判断当前车内人员是否出现健康问题，以便于后续根据车内人员的体征信息实施救援。其中，体征信息可以依据车辆内配备的设备、仪器以及摄像头等获得，也可以通过同行人员依据经验或者出现异常体征的人员的过往病史进行确定。
76.步骤102、判断体征信息是否正常，得到判断结果。
77.异常的体征信息一般是疾病的病症，为了准确判断车内人员是否健康，可以在得到车内人员的体征信息之后，判断体征信息是否正常。其中，经过判断，可能得到两种判断结果中的任意一种，即体征信息异常或者体征信息正常。
78.步骤103、基于判断结果确定救援信息。
79.如上述步骤102所述，通过体征信息可能得到两种判断结果中的任意一种，而不同的判断结果，可以得到不同的救援信息。例如，针对体征信息异常的判断结果，可以确定车内人员出现了某种疾病，需要医护人员的救援，为了保障车内人员能够快速得到这类人员的救助，可以将体征信息作为救援信息中的一个子信息；而针对体征信息正常的判断结果，则可以确定车内人员是健康的，不需要医护人员的救援，也就无需将体征信息作为救援信息中的一个子信息。
80.步骤104、基于救援信息确定至少一个目标施救者。
81.在确定出救援信息之后，即可基于救援信息确定出至少一个目标施救者。其中，目标施救者指的是与救援信息相匹配的可以实施救援的人员。为了便于理解，举例说明：假设救援信息包括异常的体征信息，那么可以将能够对该异常的体征信息实施救援的人员中确定出至少一个目标施救者。
82.步骤105、向目标施救者推送救援信息。
83.在确定出目标施救者之后，可以将救援信息推送给目标施救者，以便于求救方能够顺利得到救助。通过将救援信息推送给目标施救者，当目标施救者查阅该救援信息后，便可以根据该救援信息进行救援准备，以提高救援效率。
84.本技术实施例的救援方法实现过程如下：通过判断求救信息中的车内人员的体征信息是否正常，得到判断结果，而后基于判断结果确定出救援信息，之后基于救援信息确定
出至少一个目标施救者，通过向目标施救者推送救援信息，可以无需人工进行救援工作安排，直接结合救援信息匹配得到目标施救者，进而通过向目标施救者推送救援消息以缩短车辆内的被困人员获救所需的时间，提高救援效率。
85.在一些实施例中，为了进一步提高救援效率以及救援的可靠性，上述步骤103具体包括：
86.a1、若判断结果为体征信息异常，则获取车辆的位置信息。
87.a2、将位置信息及体征信息确定为救援信息。
88.当判断结果为体征信息异常时，则说明车内人员的健康出现了问题，即可能出现了疾病。在该情况下，可以获取车辆的位置信息，并将位置信息以及体征信息确定为救援信息，之后基于位置信息和体征信息快速确定出目标施救者，并向目标施救者发送这两个消息，以便于目标施救者能及时赶往求救地实施救援。
89.为了便于理解上述救援方法，举例说明：假设车辆a在行驶的途中，车内人员出现了异常的体征信息b1，此时车辆a内的终端设备可以获取体征信息b1，并对该体征信息b1进行判断。经过判断，确定体征信息b1属于异常的体征信息，这时可以进一步获取车辆的位置信息b2，并在获取到位置信息b2之后，将b1和b2确定为救援信息，之后基于救援信息确定出两个目标施救者c和d。为了寻求救援，可以将求救信息分别推送给目标施救者c和d，以等待目标施救者c和d的救援。可以理解的是，推送的求救信息中，除了体征信息b1及位置信息b2以外，还可以对求救的原由进行说明，并表明期望得到救助。作为示例而非限定，推送的救援信息可以是“您好！车辆a因车内人员出现体征信息b1，需要您的救援，求救的位置信息为b2”。
90.在一些实施例中，为了提高救援的可靠性，上述步骤103具体包括：
91.b1、若判断结果为体征信息正常，则获取车辆的状态信息。
92.b2、基于状态信息判断车辆是否故障。
93.b3、若车辆故障，则获取车辆的故障信息以及位置信息。
94.b4、将故障信息及位置信息确定为救援信息。
95.需要救援的状况，除了车内人员出现健康问题以外，还可以是车辆出现了故障。因此，在判断结果为体征信息正常后，可以获取车辆的状态信息。其中，状态信息用于描述车辆的行驶状态，基于车辆的行驶状态，可以确定车辆是否出现故障。如果车辆出现了故障，可以进一步获取车辆的故障信息以及车辆的位置信息，并将车辆的故障信息以及车辆的位置信息确定为救援信息。
96.在一些实施例中，为了提高救援的可靠性，上述步骤103具体包括：
97.c1、若车辆未故障，则获取车辆所处环境的环境信息。
98.c2、基于环境信息判断车辆周围是否出现灾情。
99.c3、若车辆周围出现灾情，则获取车辆的位置信息。
100.c4、将环境信息及位置信息确定为救援信息。
101.当然，车辆在行驶的过程中，除了车内人员的健康问题以及车辆故障两种状况以外，还有可能是车辆所处的周围环境出现了灾情。因此，在得到车内人员并未出现健康问题以及车辆也未发生故障这两个判断结果后，可以获取车辆所处环境的环境信息，并基于环境信息确定车辆周围是否有灾情发生。如果经过判断，车辆周围有灾情发生，则可以获取车
辆的位置信息，并将环境信息以及位置信息确定为救援信息，以提高救援的全面性和可靠性。
102.在一些实施例中，上述三种情形可能会同时发生，为了提高救援的全面性，只要在得到体征信息的判断结果后，便获取车辆的状态信息；同时，在得到车辆是否故障的判断结果后，便获取车辆所处环境的环境信息。在经过三次判断后，即可得到较为全面的救援信息，从而提高救援的全面性。应当理解的是，上述三种信息的获取顺序也可以是随机的，再本技术实施例中不做限定。例如先获取车辆状态信息，再获取体征信息，最后获取环境信息。
103.在一些实施例中，为了提高目标施救者确定的准确性，上述步骤104具体包括：
104.d1、从预设的数据库中确定与体征信息匹配的候选施救者。
105.d2、基于位置信息从候选施救者中确定目标施救者。
106.要确定出能够对异常的体征信息实施救援的目标施救者，可以先基于体征信息从预设的数据库中确定出候选施救者，以确保目标施救者是能够对异常的体征信息实施救援的人员；而后，为了进一步缩短救援所需的时长，可以基于位置信息从候选施救者中确定出目标施救者。经过以上两个步骤确定出来的目标施救者，不仅够符合救援需求，而且还能够缩短救援时长。
107.在一些实施例中，为了有效缩短获救等待时长，上述步骤d2具体包括：将距离目标位置最近的指定数量个候选施救者确定为目标施救者，目标位置为位置信息所指示的位置。
108.获救等待时长一般包括救援准备工作时间和目标施救者前往求救地所花费的时间，如果目标施救者距离求救地越远，那么目标施救者前往求救地的时间则越长，即获救等待时长也就越长。在某些情况下，由于救援的时效性要求较高，则可以尽可能的缩短目标施救者前往求救地的时间，以确保救援的时效性。例如某辆车内的人员，因突发心脏病发出求救信息，在该情况下，可以将距离求救地最近的候选施救者确定为目标施救者，从而避免目标施救者因赶往求救地花费了大量的时间而导致错失抢救的最佳时机，从而降低该人员的生命安全受到威胁的几率，提高救援的时效性。
109.由于不一定每个目标施救者都能对求救信息及时响应，那么目标施救者的个数可以是指定数量个，从而提高救援的可靠性。为了便于理解，延用上述例子进一步说明，假设车辆a内的人员突发心脏病，此时的体征信息为b1，可以基于体征信息确定出候选施救者，已知该车辆的位置信息为b2，那么可以基于位置信息b2计算与各个候选施救者之间的距离，并按照距离进行排序。例如采用降序的排序方法，即距离位置信息b2指向的位置最近的候选施救者排在首位，假设指定数量为7，那么可以将排在前的7位候选施救者确定为目标施救者，通过向这7位目标施救者发送求救信息来寻求援助。该方法能够有效缩短目标施救者前往求救地所需的时长，一定程度上提高救援效率。
110.在一些实施例中，如果救援信息包括故障信息，则可以通过以下步骤来提高目标施救者确定的准确性：
111.e1、从预设的数据库中确定与故障信息匹配的候选施救者。
112.e2、基于位置信息从候选施救者中确定目标施救者。
113.当救援信息包括故障信息时，则需要能够对车辆进行维修的人员前往求救地实施
救援。在该情况下，可以先基于故障信息匹配出候选施救者，例如车辆维修工人，然后再基于位置信息从候选施救者中确定出目标施救者，这里的目标施救者与步骤d1和d2中的目标施救者有所区别，此处的目标施救者主要是针对车辆的故障信息实施救援的人员，可以距离求就地较近的车辆维修工人；而步骤d1和d2中的目标施救者主要时针对车内人员的健康问题实施救援的人员，可以是距离求就地较近的医护人员。为了便于后续描述，步骤d1和d2中的目标施救者可以记作第一目标施救者；步骤e1和e2中的目标施救者可以记作第二目标施救者。
114.在一些实施例中，如果救援信息包括环境信息，则可以通过以下步骤来提高目标施救者确定的准确性：
115.f1、从预设的数据库中确定与故障信息匹配的候选施救者。
116.f2、基于位置信息从候选施救者中确定目标施救者。
117.当救援信息包括环境信息时，则说明车辆周围出现了灾情，可以先基于灾情匹配出候选施救者，再基于位置信息从匹配得到的候选施救者中确定出目标施救者相应地，为了便于描述，此处的目标施救者可以记作第三目标施救者。
118.在一些实施例中，如果救援信息包括体征信息、故障信息以及环境信息中的至少两种信息的组合信息，可以先基于组合信息匹配得到对应的候选施救者，而后基于位置信息从候选施救者中确定出目标施救者。若组合信息为体征信息、故障信息以及环境信息，那么最终确定出的目标施救者包括第一目标施救者、第二目标施救者以及第三目标施救者；而如果组合信息为故障信息以及环境信息，那么最终确定出的目标施救者包括第二目标施救者以及第三目标施救者，对于其他组合，依次类推。
119.在一些实施例中，为了确保能够找到与第一、第二以及第三目标施救者，可以通过构建救援平台，然后让个人、企业或者个体经营户在该救援平台上进行注册。例如可以通过手机号、邮箱或者微信等进行注册，注册通过后，用户需要填写相关的身份信息，例如医生、护士、维修技师或者个体经营者等。
120.可选地，为了进一步提高目标施救者确定的准确性，可以让用户补充更详细的信息，假设用户的身份信息是医生，那么可以让用户具体补充属于哪一类型的医生，例如心脏科医生、内科医生以及外科医生等。通过用户的相关信息，可以对用户进行分类，例如医生和护士可以归为第一类，与异常体征信息对应；维修技师为一类，与车辆的故障信息对应。归类完成后，可以将每类人员与对应的异常信息对应存储在数据库中，以便于快速确定出目标施救者。
121.应当理解的是，为了提高目标施救者确定的准确性，可以以更详细的用户身份信息进行更细致的分类，例如将外科医生划分为一类；相对应的，人员异常信息也更具体地细分，例如将人员异常信息细分外伤。在完成划分后，可以将外伤这一人员异常信息与外科医生这一分类对应记录并存储到数据库中，以便于更准确的确定出某一异常状况所对应的目标施救者。
122.在一些实施例中，为了提高救援的可靠性，在向目标施救者推送求救信息之前，上述救援方法还包括：
123.g、基于体征信息确定施救所需物资的物资信息。
124.相应地，上述步骤103包括：向目标施救者推送救援信息以及物资信息。
125.为了便于目标施救者顺利开展救援，还可以基于体征信息确定施救所需物资的物资信息。并在得到物资信息之后，将求救信息和物资信息一并推送给目标施救者，以便于目标施救者做足救援前的准备工作。具体地，目标施救者可以依据物资信息所罗列的物品进行准备，以提高救援的可靠性。
126.在一些实施例中，上述步骤g具体包括：
127.g1、则查找与体征信息相匹配的疾病。
128.在判断出体征信息异常后，可以确定出与该体征信息对应的疾病。例如车内乘客的体征信息为呼吸困难和心脏骤停，在获得该这两个异常的体征信息之后，可以依据这两个人员异常信息初步确定出对应的疾病为心脏病。
129.g2、基于疾病确定施救手段及施救药物。
130.在确定出疾病后，可以依据该疾病进一步确定施救手段以及施救药物。假设某辆车发生了车祸，其中一名乘客出现了腿骨骨折，基于该腿骨骨折这一疾病，可以确定施救过程中的施救手段为先进性消毒，然后固定腿骨，相对应的可以确定出施救药物为消毒药品和绷带。
131.g3、基于施救手段及施救药物生成物资信息。
132.在确定出施救手段和施救药物后，可以基于施救手段确定所需的仪器或者物件，然后基于仪器、物件以及施救药物确定对应的物资信息。
133.在一些实施例中，若救援信息包括车辆的故障信息，则可通过如下方式确定对应的物资信息：
134.h1、基于故障信息确定车辆故障类型。
135.h2、基于车辆故障类型确定车辆修理方案。
136.h3、基于车辆修理方案生成物资信息。
137.在获取到车辆的故障信息后，可以基于该故障信息确定车辆的故障类型。其中故障类型可以依据故障原因分类，这是因为对于相同类型的故障，其解决手段基本相同或相似，对应所需的物资更接近，该分类方法确定车辆的故障类型，有助于提高物资信息生成的准确性。在确定出车辆故障类型之后，可以进一步确定对应的车辆修理方案。不同的车辆修理方案，其用到的工具和配件各不相同，因此在得到车辆修理方案之后，可以进一步基于车辆修理方案生成较为准确全面的物资信息。
138.在一些实施例中，若救援信息包括环境信息，则可通过如下方式确定对应的物资信息：
139.i1、基于环境信息确定灾害类型。
140.i2、基于灾害类型确定救灾方案。
141.i3、基于就在方案生成物资信息。
142.在确定出环境信息异常后，可以基于该环境信息可确定当前的行驶环境所面临的具体灾害的灾害类型，然后可基于该灾害类型确定救灾方案。例如，若基于环境信息分析出当前可能出现了水灾，针对水灾这一灾害类型，其救灾方案可以为：考虑到人员可能被困在车内，需要锤子将窗敲碎救以便于出受困人员；而如果在水流湍急的情况下，可以采用绳子将受困人员救援到安全地带。基于该救灾方案，可以生成对应的物资信息，且该物资信息指示当前需要的物资为绳子和锤子。
143.上述三种场景中均有物资信息，为了区别不同场景下的物资信息，可以将步骤g及g1～g3中的物资信息记作第一物资信息，将h1～h3中的物资信息记作第二物资信息，将i1～i3中的物资信息记作第三物资信息。在一些实施例中，如果救援信息包括体征信息、故障信息以及环境信息中的至少两种信息的组合信息，可以将基于组合信息匹配得到对应的物资信息。举例说明，若组合信息为体征信息、故障信息以及环境信息，则可以分别基于上述三种物资确定方法分别确定出物资信息，最终得到的物资信息可以包括第一物资信息、第二物资信息以及第三物资信息；而如果组合信息为故障信息以及环境信息，则可以分别基于上述第二种及第三种物资确定方法分别确定出物资信息，最终得到的物资信息可以包括第二物资信息以及第三物资信息，对于其他组合，依次类推。
144.在上述三个场景中，对于不同的救援信息，提出针对性的物资信息确定方法，有助于目标施救者基于物资信息准确且全面的准备救援所需物资，从而提高救援质量。可选地，上述物资信息可以表现为清单的形式，该形式便于目标施救者快速的完成救援前的物资准备，以提高救援效率。
145.在一些实施例中，为了避免多方人员前往求救地施救，在向目标施救者推送求救信息之后，上述救援方法还可以包括：
146.j1、在预设时间段内统计反馈人数，反馈人数是目标施救者中已反馈确认救援信息的人数。
147.j2、若反馈人数达到预设的人数阈值，则向未反馈确认救援信息的目标施救者发送提示信息，提示信息用于提示当前对车辆的救援人员已饱和。
148.在求救信息向各个目标施救者推送后，为了避免过多的目标施救者前往求救地实施救援，可以在预设时间段内对反馈确认救援信息的目标施救者的人数进行统计，得到反馈人数，然后将该反馈人数与预先设定的人数阈值进行比较。如果反馈人数达到人数阈值，则说明当前确认前往求救地施救的目标施救者的数量已经能够顺利完成救援。为了避免过多的施救者前往求救地，可以对暂未反馈确认救援信息的目标施救人员发送提示信息，以提醒该目标施救人员当前对车辆的救援人员已经饱和，不用再前往救援地实施救助。
149.应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本技术实施例的实施过程构成任何限定。
150.对应于上文实施例所述的救援方法，图2示出了本技术实施例提供的救援装置2的结构框图，为了便于说明，仅示出了与本技术实施例相关的部分。
151.参照图2，该救援装置20包括：
152.第一获取模块21，用于获取求救信息，求救信息包括车内人员的体征信息；
153.第一判断模块22，用于判断体征信息是否正常，得到判断结果；
154.第一确定模块23，用于基于判断结果确定救援信息；
155.第二确定模块24，用于基于救援信息确定至少一个目标施救者；
156.推送模块25，用于向目标施救者推送救援信息。
157.在一些实施例中，第一确定模块23包括：
158.第一获取单元，用于若判断结果为体征信息异常，则获取车辆的位置信息；
159.第一确定单元，用于将位置信息及体征信息确定为救援信息。
160.在一些实施例中，第一确定模块23还包括：
161.第二获取单元，用于若判断结果为体征信息正常，则获取车辆的状态信息，状态信息用于描述车辆的行驶状态；
162.第一判断单元，用于基于状态信息判断车辆是否故障；
163.第三获取单元，用于若车辆故障，则获取车辆的故障信息以及位置信息；
164.第二确定单元，用于将故障信息及位置信息确定为救援信息。
165.在一些实施例中，救援装置20还包括：
166.第二获取模块，用于若车辆未故障，则获取车辆所处环境的环境信息；
167.第二判断模块，用于基于环境信息判断车辆周围是否出现灾情；
168.第三获取模块，用于若车辆周围出现灾情，则获取车辆的位置信息；
169.第三确定模块，用于将环境信息及位置信息确定为救援信息。
170.在一些实施例中，第二确定模块24包括：
171.第三确定单元，用于从预设的数据库中确定与体征信息匹配的候选施救者；
172.第四确定单元，用于基于位置信息从候选施救者中确定目标施救者。
173.在一些实施例中，救援装置20还包括：
174.第四确定模块，用于基于体征信息确定施救所需物资的物资信息；
175.相应地，推送模块具体用于向目标施救者推送救援信息以及物资信息。
176.在一些实施例中，救援装置20还包括：
177.统计模块，用于在预设时间段内统计反馈人数，反馈人数是目标施救者中已反馈确认救援信息的人数；
178.提示模块，用于若反馈人数达到预设的人数阈值，则向未反馈确认救援信息的目标施救者发送提示信息，提示信息用于提示当前对车辆的救援人员已饱和。
179.需要说明的是，上述装置/单元之间的信息交互和执行过程等内容，由于与本技术方法实施例基于同一构思，其具体功能及带来的技术效果，具体可参见方法实施例部分，此处不再赘述。
180.图3为本技术一实施例提供的电子设备的结构示意图。如图3所示，该实施例的电子设备3包括：至少一个处理器30(图3中仅示出一个)处理器、存储器31以及存储在存储器31中并可在至少一个处理器30上运行的计算机程序32，处理器30执行计算机程序32时实现上述任意救援方法实施例中的步骤，例如图1所示出的步骤101-105。
181.所称处理器30可以是中央处理单元(central processing unit，cpu)，该处理器30还可以是其他通用处理器、数字信号处理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit，asic)、现成可编程门阵列(field-programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
182.存储器31在一些实施例中可以是电子设备3的内部存储单元，例如电子设备3的硬盘或内存。存储器31在另一些实施例中也可以是电子设备3的外部存储设备，例如电子设备3上配备的插接式硬盘，智能存储卡(smart media card，smc)，安全数字(secure digital，sd)卡，闪存卡(flash card)等。进一步地，存储器31还可以既包括终端设备3的内部存储单
元也包括外部存储设备。存储器31用于存储操作装置、应用程序、引导装载程序(bootloader)、数据以及其他程序等，例如计算机程序的程序代码等。存储器31还可以用于暂时地存储已经输出或者将要输出的数据。
183.所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本技术的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
184.本技术实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现可实现上述各个方法实施例中的步骤。
185.本技术实施例提供了一种计算机程序产品，当计算机程序产品在移动终端上运行时，使得移动终端执行时实现可实现上述各个方法实施例中的步骤。
186.所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术实现上述实施例方法中的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质至少可以包括：能够将计算机程序代码携带到拍照装置/电子设备的任何实体或装置、记录介质、计算机存储器、只读存储器(rom，read-only memory)、随机存取存储器(ram，random access memory)、电载波信号、电信信号以及软件分发介质。例如u盘、移动硬盘、磁碟或者光盘等。在某些司法管辖区，根据立法和专利实践，计算机可读介质不可以是电载波信号和电信信号。
187.在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。
188.本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术的范围。
189.在本技术所提供的实施例中，应该理解到，所揭露的装置/网络设备和方法，可以通过其它的方式实现。例如，以上所描述的装置/网络设备实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置
或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。
190.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
191.以上所述实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的精神和范围，均应包含在本技术的保护范围之内。