CN114781879A

CN114781879A - Method, device, computer equipment and storage medium for rescuing vehicle personnel

Info

Publication number: CN114781879A
Application number: CN202210444227.XA
Authority: CN
Inventors: 章熠; 龚颖; 孙伟; 窦玲意; 金妍
Original assignee: Beijing Binli Information Technology Co Ltd
Current assignee: Beijing Binli Information Technology Co Ltd
Priority date: 2022-04-25
Filing date: 2022-04-25
Publication date: 2022-07-22

Abstract

There is provided a computer-implemented method for vehicle personnel rescue, the method comprising: determining that a person on the first vehicle is in a health emergency based on person health data monitored by one or more sensors of the first vehicle; in response to determining that a person on the first vehicle is in a healthy emergency state, determining an optimal junction of the first vehicle with a second vehicle of a medical rescue authority, wherein the optimal junction is determined such that when combined at the optimal junction, the first vehicle and the second vehicle are at the same level of an overpass and/or on the same side of a road; and transmitting the optimal junction point to the second vehicle.

Description

Method, device, computer equipment and storage medium for rescuing vehicle personnel

Technical Field

The present disclosure relates to the field of vehicle technology, in particular to a computer-implemented method, apparatus, computer device, vehicle, computer-readable storage medium and computer program product for vehicle personal rescue.

Background

In the modern society, with the increasing amount of automobile reserves, people have to face the growing hidden danger of safe driving while enjoying the convenience of travel brought by the automobile. When the personnel in the vehicle are in a health emergency, the personnel can be dead due to missing the optimal rescue time, so that the personnel can be rescued for the wounded in time. Therefore, how to quickly rescue the wounded after detecting that the person in the vehicle is in a healthy emergency state is a key direction in the technical field of vehicle safety.

At present, after the condition that people in a vehicle are in a healthy and urgent state is detected, a rescue vehicle is dispatched to a place of affairs to be converged with a wounded vehicle, or the rescue vehicle and the wounded vehicle travel together to a certain converging point to be converged. In this case, since the current road condition information (e.g., an overhead bridge) is complicated, the success rate and efficiency of merging the rescue vehicle and the injured vehicle are to be improved.

The approaches described in this section are not necessarily approaches that have been previously conceived or pursued. Unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section. Similarly, unless otherwise indicated, the problems mentioned in this section should not be considered as having been acknowledged in any prior art.

Disclosure of Invention

It would be advantageous for the present disclosure to provide a mechanism that alleviates, mitigates or even eliminates one or more of the problems described above.

According to a first aspect of the present disclosure, there is provided a computer-implemented method for vehicle personnel rescue, comprising: determining that a person on the first vehicle is in a health emergency based on person health data monitored by one or more sensors of the first vehicle; in response to determining that a person on the first vehicle is in a healthy emergency state, determining an optimal junction of the first vehicle with a second vehicle of a medical rescue authority, the optimal junction determined such that when combined at the optimal junction, the first vehicle and the second vehicle are at a same level of an overpass and/or a same side of a road; and transmitting the optimal junction point to the second vehicle.

According to a second aspect of the present disclosure, there is provided an apparatus for rescuing a person from a vehicle, comprising: a first module configured to determine that a person on the first vehicle is in a health emergency based on person health data monitored by one or more sensors of the first vehicle; a second module configured to determine an optimal junction of the first vehicle with a second vehicle of a medical rescue organization in response to determining that a person on the first vehicle is in a healthy emergency state, the optimal junction determined such that the first vehicle and the second vehicle are on a same level of an overpass and/or a same side of a roadway when merging at the optimal junction; and a third module configured to transmit the optimal junction point to the second vehicle.

According to a third aspect of the present disclosure, there is provided a computer device comprising: at least one processor; and at least one memory having a computer program stored thereon, which, when executed by the at least one processor, causes the at least one processor to perform a method according to the present disclosure.

According to a fourth aspect of the present disclosure, there is provided a vehicle comprising: one or more sensors configured to monitor a health status of a person on the vehicle; and an apparatus or computer device according to the present disclosure.

According to a fifth aspect of the present disclosure, there is provided a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, causes the processor to perform a method according to the present disclosure.

According to a sixth aspect of the present disclosure, there is provided a computer program product comprising a computer program which, when executed by a processor, causes the processor to carry out a method according to the present disclosure

According to one or more embodiments of the present disclosure, after one or more sensors of the vehicle monitor that a person on the vehicle is in a healthy emergency, an optimal junction is determined for the injured vehicle and the rescue vehicle such that when the two vehicles merge at the optimal junction, the injured vehicle and the rescue vehicle are at the same level of the overpass and/or the same side of the road. Therefore, the success rate of the confluence of the wounded vehicle and the rescue vehicle is improved, and the time for confluence is reduced, so that the wounded can be timely rescued.

These and other aspects of the disclosure will be apparent from and elucidated with reference to the embodiments described hereinafter.

Drawings

Further details, features and advantages of the disclosure are disclosed in the following description of exemplary embodiments, taken in conjunction with the accompanying drawings, in which:

fig. 1 is a schematic diagram illustrating an example system in which various methods described herein may be implemented, in accordance with some example embodiments;

FIG. 2 is a flow chart illustrating a computer-implemented method for vehicle personnel rescue, according to some exemplary embodiments;

FIG. 3 is a flowchart illustrating an example process of the determine optimal meeting point step of FIG. 2 in accordance with some example embodiments;

FIG. 4 is a schematic diagram illustrating a fusion path in determining an optimal fusion point in accordance with some demonstrative embodiments;

FIG. 5 is a schematic diagram illustrating a joining path in determining an optimal joining point in accordance with some demonstrative embodiments;

FIG. 6 is a flow chart illustrating a computer-implemented method for vehicle personnel rescue, according to further exemplary embodiments;

FIG. 7 is a schematic block diagram illustrating an apparatus for vehicle personnel rescue, according to some exemplary embodiments;

FIG. 8 is a block diagram illustrating an exemplary computer device that can be applied to the exemplary embodiments.

Detailed Description

In the present disclosure, unless otherwise specified, the use of the terms "first", "second", etc. to describe various elements is not intended to limit the positional relationship, the timing relationship, or the importance relationship of the elements, and such terms are used only to distinguish one element from another. In some examples, a first element and a second element may refer to the same instance of the element, and in some cases, based on the context, they may also refer to different instances.

The terminology used in the description of the various described examples in this disclosure is for the purpose of describing the particular examples only and is not intended to be limiting. Unless the context clearly indicates otherwise, if the number of elements is not specifically limited, the element may be one or a plurality of. As used herein, the term "plurality" means two or more, and the term "based on" should be interpreted as "based, at least in part, on. Further, the terms "and/or" and at least one of "… …" encompass any and all possible combinations of the listed items.

Exemplary embodiments of the present disclosure are described in detail below with reference to the accompanying drawings.

Fig. 1 is a schematic diagram illustrating an example system 100 in which various methods described herein may be implemented, according to an example embodiment.

Referring to FIG. 1, the system 100 includes an in-vehicle system 110, a server 120, and a network 130 communicatively coupling the in-vehicle system 110 and the server 120.

In-vehicle system 110 includes a display 114 and an Application (APP)112 that may be displayed via display 114. The application 112 may be an application installed by default by the in-vehicle system 110 or downloaded and installed by the user 102, or an applet that is a lightweight application. In the case where the application 112 is an applet, the user 102 may run the application 112 directly on the in-vehicle system 110 without installing the application 112 by searching the application 112 in a host application (e.g., by the name of the application 112, etc.) or by scanning a graphic code (e.g., a barcode, a two-dimensional code, etc.) of the application 112, etc. In some embodiments, the in-vehicle system 110 may include one or more processors and one or more memories (not shown), and the in-vehicle system 110 is implemented as an in-vehicle computer. In some embodiments, in-vehicle system 110 may include more or fewer display screens 114 (e.g., not including display screens 114), and/or one or more speakers or other human interaction devices. In some embodiments, the in-vehicle system 110 may not be in communication with the server 120.

Server 120 may represent a single server, a cluster of multiple servers, a distributed system, or a cloud server providing an underlying cloud service (such as cloud database, cloud computing, cloud storage, cloud communications). It will be understood that although the server 120 is shown in FIG. 1 as communicating with only one in-vehicle system 110, the server 120 may provide background services for multiple in-vehicle systems simultaneously.

The network 130 allows wireless communication and information exchange between vehicles-X ("X" means vehicle, road, pedestrian, or internet, etc.) according to agreed communication protocols and data interaction standards. Examples of network 130 include a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), and/or a combination of communication networks such as the Internet. The network 130 may be a wired or wireless network. In one example, the network 130 may be an in-vehicle network, an inter-vehicle network, and/or an in-vehicle mobile internet network.

Fig. 2 is a flowchart illustrating a computer-implemented method 200 for vehicle personnel rescue, according to an exemplary embodiment. The method 200 may be performed at an in-vehicle system (e.g., the in-vehicle system 110 shown in fig. 1), i.e., the subject of performance of the steps of the method 200 may be the in-vehicle system 110 shown in fig. 1. In some embodiments, method 200 may be performed at a server (e.g., server 120 shown in fig. 1). In some embodiments, method 200 may be performed by an in-vehicle system (e.g., in-vehicle system 110) and a server (e.g., server 120) in combination. Hereinafter, each step of the method 200 is described in detail by taking an execution subject as the in-vehicle system 110 as an example.

Referring to fig. 2, at step 210, it is determined that a person on the first vehicle is in a health emergency based on the person health data monitored by the one or more sensors of the first vehicle.

In some embodiments, the person health data monitored by the one or more sensors may include one or more of blood pressure, pulse, heartbeat, body temperature, facial image data of the person. It may be determined that a person (driver or other passenger) on the first vehicle is in a healthy emergency based on one or more anomalies in the data. The health state of the personnel is evaluated by collecting various personnel health data, so that the accuracy and stability of the evaluation result can be improved.

At step 220, in response to determining that the person on the first vehicle is in a healthy emergency, an optimal junction of the first vehicle with a second vehicle of the medical rescue authority is determined, wherein the optimal junction is determined such that when combined at the optimal junction, the first vehicle and the second vehicle are on the same level of the overpass and/or the same side of the roadway.

In some embodiments, in response to determining that a person aboard the first vehicle is in a health emergency, the person's seat back is optionally automatically reclined to enable the person to adjust to a lie flat condition. The seat is adjusted to enable the person in the healthy and emergency state to lie down, so that the disease symptoms of the person can be relieved, and time is won for rescue.

In some embodiments, in response to determining that a person aboard the first vehicle is in a healthy emergency, an identity of the person in the healthy emergency is optionally identified and historical health data corresponding to the identity of the person is transmitted to the second vehicle. In some embodiments, historical health data (e.g., physical examination reports, medical visit records, etc.) for the person may be obtained from at least one of an insurance platform, a medical platform, and a health platform. The historical health data facilitates carrying of relevant rescue tools and development of rescue strategies by rescuers on the second vehicle.

In some embodiments, the most suitable second vehicle is optionally selected, the selection method comprising: obtaining location information regarding a plurality of available rescue vehicles of a plurality of medical rescue authorities in proximity to a first vehicle; based on the location information, an available rescue vehicle closest in distance to the first vehicle is selected from the plurality of available rescue vehicles as the second vehicle. Through the selection of the second vehicle, the first vehicle can be converged with the second vehicle as soon as possible so as to rescue the personnel, and the utilization rate of the second vehicle can be improved.

At step 230, the optimal fusion point is transmitted to the second vehicle. And then the second vehicle drives to the optimal junction point to be merged with the first vehicle and carries out rescue based on the information of the optimal junction point.

In some embodiments, a digital key of the first vehicle may also be transmitted to the second vehicle, the digital key being used to authorize use of a function of the first vehicle. In some embodiments, a rescuer on the second vehicle can use the digital key to open the door of the first vehicle, thus delaying rescue because the door of the first vehicle is locked can be avoided.

In some embodiments, in response to determining that the driver on the first vehicle is in a healthy emergency, the first vehicle may be automatically steered to the optimal meeting point, thereby providing the driver with assistance as quickly as possible. In other embodiments, if the person in a healthy emergency within the first vehicle is a passenger, the driver on the first vehicle may navigate the vehicle to the optimal meeting point based on the information of the optimal meeting point.

According to an embodiment of the present disclosure, after one or more sensors of the vehicle monitor that a person on the vehicle is in a healthy emergency, an optimal point of convergence is determined for the injured vehicle and the rescue vehicle such that when the two vehicles converge at the optimal point of convergence, the injured vehicle and the rescue vehicle are at the same level of the overpass and/or the same side of the road. Therefore, the success rate of the confluence of the wounded vehicle and the rescue vehicle is improved, and the time for the confluence is reduced, so that the wounded can be timely rescued.

Fig. 3 is a flowchart illustrating an example process of the determine optimal meeting point step 220 of fig. 2, in accordance with some example embodiments. As shown in fig. 3, step 220 may include the steps of:

step 310, determining a first time when the second vehicle travels to a first junction, wherein the first junction is a position where the first vehicle stops at a roadside at the current travel position.

Step 320, determining a plurality of available junctions, the plurality of available junctions allowing the vehicle to park and the first vehicle and the second vehicle being at the same level of the overpass and/or the same side of the road when merging at each of the plurality of available junctions;

step 330, determining the time for the first vehicle and the second vehicle to converge respectively aiming at a plurality of available convergence points;

step 340, selecting an available merging point from a plurality of available merging points as a second merging point at least partially based on respective time spent of the available merging points, wherein the time spent corresponding to the second merging point is a second time spent; and

and 350, determining a junction point with short time in the first junction point and the second junction point as an optimal junction point according to the first time and the second time.

Steps 310 to 350 are further described below with reference to the embodiments in fig. 4 and 5.

At step 310, referring to fig. 4, in response to determining that the person aboard the first vehicle 404 is in a healthy emergency, the first vehicle 404 is parked at a roadside location at the current driving location, which is denoted as a first junction P1. The second vehicle 402 travels on a lane opposite the first vehicle and toward the first vehicle 404. The second vehicle 402 cannot turn around directly on the opposite side of the road from the first junction P1 due to a road closure (e.g., overpass or highway), thereby merging directly with the first vehicle 404 at the first junction P1. In contrast, the second vehicle 402 needs to continue traveling along the road, turning around where it is allowed to return to the first junction P1. The travel route of the second vehicle 402 is shown by a line L1, and the time taken is denoted as a first time T1.

At step 320, referring to fig. 5, the plurality of available junctions includes available junction P2 and available junction P3 (other possible available junctions are not shown), available junction P2 and available junction P3 are at the same level of the overpass and/or on the same side of the road as second vehicle 502, and allow the vehicle to park (note that the overpass or the road, e.g., highway, etc., may not be free to park). The first vehicle 504 may travel through the overpass or ramp of the highway (travel paths L2 and L3, respectively) to the opposite lane and stop at the available junction P2 or the available junction P3. In some embodiments, the first vehicle 504 is on the same side of the roadway at a different level than the second vehicle 502, and the first vehicle 504 may travel on a ramp to an available junction on the same side of the roadway at the same level as the second vehicle 502. In some embodiments, where the first vehicle 504 is on a different side of the roadway at the same level as the second vehicle 502, the first vehicle 504 may travel on a ramp to an available junction on the same side of the roadway at the same level as the second vehicle 502. In some embodiments, where the first vehicle 504 is on a different side of the roadway than the second vehicle 502, the first vehicle 504 may travel on a ramp to an available junction on the same side of the roadway and at the same level as the second vehicle 502.

At step 330, with continued reference to fig. 5, the time required for the first vehicle 504 to meet the second vehicle 502 at the available junction P2 and the available junction P3, respectively, is calculated. The elapsed time is a time when the median elapsed time for the first vehicle 504 to reach the available junction point and a time when the second vehicle 502 to reach the available junction point are greater. Calculating the time of use may involve factors such as the length of the path for the first vehicle 504 to reach the available junction, congestion conditions, etc., and factors such as the length of the path for the second vehicle 502 to reach the available junction, congestion conditions, etc.

At step 340, with continued reference to fig. 5, based on the first vehicle 504 and the second vehicle 502 meeting the available junction P2 and the available junction P3, one available junction is selected as the second junction, and the time of use corresponding to the second junction is the second time of use. In some embodiments, selecting an available meeting point from the plurality of available meeting points as the second meeting point comprises: and selecting the available meeting point with the shortest time consumption from the plurality of available meeting points as a second meeting point. Referring to fig. 5, the available junction P2 and the available junction P3 are used as a second junction, and the time of use of the second junction is denoted as a second time T2. In this manner, the selected second junction may reduce the merging time at which the first vehicle 504 and the second vehicle 502 merge at the second junction.

In some embodiments, selecting an available meeting point from a plurality of available meeting points as the second meeting point may further comprise: acquiring weather information about a current weather condition; and in response to the weather information indicating a weather condition including rain, snow, strong wind, or insolation, selecting, from the plurality of available meeting points, a meeting point having shelter and a shortest elapsed time as the second meeting point. In some embodiments, the second junction may be a location below the overpass where the junction is shortest in time. Therefore, the rescue of people can be prevented from being affected by severe weather.

In step 350, referring to fig. 4 and 5, assuming that the second meeting point in the previous step is determined as P3, the time-lapse meeting point is taken as the optimal meeting point according to the first time-lapse T1 of the first meeting point P1 and the second time-lapse T2 of the second meeting point P3. In response to the first time T1 being less than the second time T2, the optimal junction is the first junction P1, and the first vehicle 504 stops sideways waiting for the second vehicle 502 to travel to that location for merging. In response to the first time T1 being greater than the second time T2, the optimal junction is the second junction P3, and the first vehicle 504 and the second vehicle 502 simultaneously drive to the optimal junction and merge at that location.

Although the various operations are depicted in fig. 2 and 3 as occurring in a particular order, this should not be construed as requiring that the operations be performed in the particular order shown or in sequential order, nor that all illustrated operations be performed, to achieve desirable results. For example, step 320 may be performed prior to step 310, or concurrently with step 310.

Fig. 6 is a flowchart illustrating a computer-implemented method 600 for vehicle personnel rescue, according to further exemplary embodiments. Some steps in the method 600 are similar to the method 200 and are not described in detail herein for the sake of brevity. The various steps of method 600 are described below with reference to fig. 6. At step 602, the in-vehicle system obtains health data for the driver. At step 604, it is determined whether the driver is in a healthy emergency based on the driver's health data. In response to the driver not being in a health emergency, returning to step 602, the on-board system continues to acquire health data of the driver. Steps 606 through 612 are performed at the first vehicle in response to the driver being in a healthy emergency. Wherein, at step 606, autopilot takes over for the first vehicle; at step 608, the first vehicle determines an optimal junction point based on traffic congestion, weather conditions, distance, and other factors; at step 610, the driver's seat is automatically reclined so that the driver can adjust to a lie flat condition; at step 612, the first vehicle is automatically driven to the optimal merge point. Steps 614 to 620 are performed at the second vehicle in response to the driver being in a healthy emergency. Wherein, at step 614, the first vehicle communicates with the medical facility to dispatch a second vehicle; in step 616, the second vehicle obtains the optimal meeting point; at step 618, the second vehicle obtains the digital key for the first vehicle; at step 620, the second vehicle is driven toward the optimal merge point. Next, step 622 is executed, the second vehicle meets the first vehicle at the optimal junction, and the rescue personnel opens the door of the first vehicle and carries out rescue by using the digital key.

Although the various operations are depicted in fig. 6 as occurring in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, nor that all illustrated operations be performed, to achieve desirable results. For example, step 618 may be performed prior to step 616, or concurrently with step 616. As another example, step 610 may even be omitted.

Fig. 7 is a schematic block diagram illustrating an apparatus for vehicle personnel rescue, according to some exemplary embodiments. As shown in fig. 7, the apparatus 700 may include a first module 710, a second module 720, and a third module 730. A first module 710 configured to determine that a person on a first vehicle is in a healthy emergency based on person health data monitored by one or more sensors of the first vehicle. A second module 720 configured to determine an optimal junction point of the first vehicle with a second vehicle of the medical rescue authority in response to determining that a person on the first vehicle is in a healthy emergency, wherein the optimal junction point is determined such that the first vehicle and the second vehicle are on a same level of the overpass and/or a same side of the roadway when merging at the optimal junction point. A third module 730 configured to transmit the optimal junction point to the second vehicle.

According to an embodiment of the present disclosure, after one or more sensors of the vehicle monitor that a person on the vehicle is in a healthy emergency, an optimal point of convergence is determined for the injured vehicle and the rescue vehicle such that when the two vehicles converge at the optimal point of convergence, the injured vehicle and the rescue vehicle are at the same level of the overpass and/or the same side of the road. Therefore, the success rate of the confluence of the wounded vehicle and the rescue vehicle is improved, and the time for confluence is reduced, so that the wounded can be timely rescued.

It should be understood that the various modules of the apparatus 700 shown in fig. 7 may correspond to the various steps in the method 200 described with reference to fig. 2. Thus, the operations, features and advantages described above with respect to the method 200 are equally applicable to the apparatus 700 and the modules included therein. Certain operations, features and advantages may not be described in detail herein for the sake of brevity.

Although specific functionality is discussed above with reference to particular modules, it should be noted that the functionality of the various modules discussed herein can be separated into multiple modules and/or at least some of the functionality of multiple modules can be combined into a single module. Performing an action by a particular module discussed herein includes the particular module itself performing the action, or alternatively the particular module invoking or otherwise accessing another component or module that performs the action (or performs the action in conjunction with the particular module). Thus, a particular module performing an action can include the particular module performing the action itself and/or another module performing the action that the particular module invokes or otherwise accesses. For example, the second module 820 described above may include the third module 830 in some embodiments.

It should also be appreciated that various techniques may be described herein in the general context of software, hardware elements, or program modules. The various modules described above with respect to fig. 7 may be implemented in hardware or in hardware in combination with software and/or firmware. For example, the modules may be implemented as computer program code/instructions configured to be executed in one or more processors and stored in a computer readable storage medium. Alternatively, the modules may be implemented as hardware logic/circuitry. For example, in some embodiments, one or more of the first module 710, the second module 720, and the third module 730 may be implemented together in a System on Chip (SoC). The SoC may include an integrated circuit chip that includes one or more components of a Processor (e.g., a Central Processing Unit (CPU), microcontroller, microprocessor, Digital Signal Processor (DSP), etc.), memory, one or more communication interfaces, and/or other circuitry, and may optionally execute received program code and/or include embedded firmware to perform functions.

According to an aspect of the disclosure, a computer device is provided that includes at least one memory, at least one processor, and a computer program stored on the at least one memory. The at least one processor is configured to execute the computer program to implement the steps of any of the method embodiments described above.

According to an aspect of the present disclosure, there is provided a vehicle comprising an apparatus or a computer device as described above.

According to an aspect of the present disclosure, there is provided a non-transitory computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements the steps of any of the method embodiments described above.

According to an aspect of the present disclosure, a computer program product is provided, comprising a computer program which, when executed by a processor, performs the steps of any of the method embodiments described above.

Illustrative examples of such computer devices, non-transitory computer-readable storage media, and computer program products are described below in connection with FIG. 8.

Fig. 8 illustrates an example configuration of a computer device 800 that may be used to implement the methods described herein. For example, server 120 and/or in-vehicle system 110 shown in fig. 1 may include an architecture similar to computer device 800. The computer device/apparatus described above may also be implemented in whole or at least in part by the computer device 800 or a similar device or system.

The computer device 800 may include at least one processor 802, memory 804, communication interface(s) 806, display device 808, other input/output (I/O) devices 810, and one or more mass storage devices 812, which may be capable of communicating with each other, such as through a system bus 814 or other appropriate connection.

Processor 802 may be a single processing unit or multiple processing units, all of which may include single or multiple computing units or multiple cores. The processor 802 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitry, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor 802 can be configured to retrieve and execute computer-readable instructions, such as program code for an operating system 816, program code for an application program 818, program code for other programs 820, and the like, stored in the memory 804, mass storage device 812, or other computer-readable medium.

Memory 804 and mass storage device 812 are examples of computer-readable storage media for storing instructions that are executed by processor 802 to implement the various functions described above. By way of example, the memory 804 may generally include both volatile and nonvolatile memory (e.g., RAM, ROM, etc.). In addition, mass storage device 812 may generally include a hard disk drive, solid state drive, removable media, including external and removable drives, memory cards, flash memory, floppy disks, optical disks (e.g., CD, DVD), storage arrays, network attached storage, a storage area network, and the like. Memory 804 and mass storage device 812 may both be referred to herein collectively as memory or computer-readable storage media, and may be non-transitory media capable of storing computer-readable, processor-executable program instructions as computer program code that may be executed by processor 802 as a particular machine configured to implement the operations and functions described in the examples herein.

A number of programs may be stored on the mass storage device 812. These programs include an operating system 816, one or more application programs 818, other programs 820, and program data 822, and may be loaded into memory 804 for execution. Examples of such applications or program modules may include, for instance, computer program logic (e.g., computer program code or instructions) for implementing the following components/functions: method 200 and/or method 300 (including any suitable steps of methods 200, 300), and/or additional embodiments described herein.

Although illustrated in fig. 8 as being stored in memory 804 of computer device 800,

modules

816, 818, 820, and 822, or portions thereof, may be implemented using any form of computer-readable media that is accessible by computer device 800. As used herein, "computer-readable media" includes at least two types of computer-readable media, namely computer-readable storage media and communication media.

Computer-readable storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Computer-readable storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a computer device. In contrast, communication media may embody computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism. Computer-readable storage media, as defined herein, does not include communication media.

One or more communication interfaces 806 are used to exchange data with other devices, such as over a network, direct connection, and so forth. Such communication interfaces may be one or more of the following: any type of network interface (e.g., a Network Interface Card (NIC)), wired or wireless (such as IEEE 802.11 Wireless LAN (WLAN)) wireless interface, worldwide interoperability for microwave Access (Wi-MAX) interface, Ethernet interface, Universal Serial Bus (USB) interface, cellular network interface, Bluetooth^TMAn interface, a Near Field Communication (NFC) interface, etc. The communication interface 806 may facilitate communication within a variety of networks and protocol types, including wired networks (e.g., LAN, cable, etc.) and wireless networks (e.g., WLAN, cellular, satellite, etc.), the Internet, and so forth. The communication interface 806 may also provide for communication with external storage devices (not shown), such as in storage arrays, network attached storage, storage area networks, and the like.

In some examples, a display device 808, such as a monitor, may be included for displaying information and images to a user. Other I/O devices 810 may be devices that receive various inputs from and provide various outputs to a user, and may include touch input devices, gesture input devices, cameras, keyboards, remote controls, mice, printers, audio input/output devices, and so forth.

The techniques described herein may be supported by these various configurations of computer device 800 and are not limited to specific examples of the techniques described herein. The functionality may also be implemented, in whole or in part, on a "cloud" using a distributed system, for example. The cloud includes and/or represents a platform for resources. The platform abstracts underlying functionality of hardware (e.g., servers) and software resources of the cloud. The resources may include applications and/or data that may be used when performing computing processes on servers remote from the computer device 800. Resources may also include services provided over the internet and/or over a subscriber network such as a cellular or Wi-Fi network. The platform may abstract resources and functionality to connect the computer device 800 with other computer devices. Thus, implementations of the functionality described herein may be distributed throughout the cloud. For example, the functionality may be implemented in part on the computer device 800 and in part by a platform that abstracts the functionality of the cloud.

While the disclosure has been illustrated and described in detail in the drawings and foregoing description, such illustration and description are to be considered illustrative and exemplary and not restrictive; the present disclosure is not limited to the disclosed embodiments. Variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed subject matter, from a study of the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other elements or steps not listed, the indefinite article "a" or "an" does not exclude a plurality, the term "a" or "an" means two or more, and the term "based on" should be construed as "based at least in part on". The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Some exemplary aspects of the disclosure will be described below.

In aspect 1, a computer-implemented method for vehicle personnel rescue, the method comprising:

determining that a person on the first vehicle is in a health emergency based on person health data monitored by one or more sensors of the first vehicle;

in response to determining that a person on the first vehicle is in a healthy emergency state, determining an optimal junction of the first vehicle with a second vehicle of a medical rescue authority, wherein the optimal junction is determined such that when combined at the optimal junction, the first vehicle and the second vehicle are at the same level of an overpass and/or on the same side of a road; and

transmitting the optimal junction point to the second vehicle.

Aspect 2, the method of aspect 1, wherein determining the optimal meeting point comprises:

determining a first time for the second vehicle to travel to a first junction, wherein the first junction is a location at which the first vehicle stops at a curb at a current travel location;

determining a plurality of available junction points that allow vehicles to park and at which the first vehicle and the second vehicle are on the same level of an overpass and/or side of a road when merging at each of the plurality of available junction points;

determining, for the plurality of available merge points, a time of use for the first vehicle and the second vehicle to merge, respectively;

selecting an available meeting point from the plurality of available meeting points as a second meeting point at least partially based on respective times of use of the plurality of available meeting points, wherein the time of use corresponding to the second meeting point is a second time of use; and

and determining a short-time junction point of the first junction point and the second junction point as the optimal junction point according to the first time and the second time.

Aspect 3 is the method of aspect 2, wherein selecting an available meeting point from the plurality of available meeting points as the second meeting point comprises:

selecting the available meeting point with the shortest time consumption from the plurality of available meeting points as the second meeting point.

Aspect 4 is the method of aspect 2, wherein selecting an available meeting point from the plurality of available meeting points as the second meeting point comprises:

acquiring weather information about a current weather condition; and

selecting, as the second meeting point, a meeting point having a shelter and taking a shortest time from the plurality of available meeting points in response to the weather information indicating weather conditions including rain, snow, strong wind, or insolation.

Aspect 5, the method of aspect 1, further comprising:

automatically driving the first vehicle to the optimal junction in response to determining that a driver on the first vehicle is in a healthy emergency.

Aspect 6, the method of aspect 1, further comprising:

obtaining location information regarding a plurality of available rescue vehicles of a plurality of medical rescue authorities in proximity to the first vehicle; and

selecting an available rescue vehicle closest in distance to the first vehicle from the plurality of available rescue vehicles as the second vehicle based on the location information.

Aspect 7, the method of aspect 1, further comprising:

transmitting a digital key of the first vehicle to the second vehicle, the digital key for authorizing use of a function of the first vehicle.

Aspect 8, the method of aspect 1, further comprising:

in response to determining that a person on the first vehicle is in a healthy emergency, automatically recline a seatback of the person to enable the person to adjust to a lie flat condition.

Aspect 9, the method of aspect 1, further comprising:

identifying an identity of a person in a healthy emergency; and

sending historical health data corresponding to the identity of the person to the second vehicle.

Aspect 10 the method of any of aspects 1-9, wherein the person health data includes one or more of a blood pressure, a pulse, a heartbeat, a body temperature, facial image data of the person.

Aspect 11, an apparatus for vehicle rescue, comprising:

a first module configured to determine that a person on the first vehicle is in a health emergency based on person health data monitored by one or more sensors of the first vehicle;

a second module configured to determine an optimal junction point of the first vehicle with a second vehicle of a medical rescue organization in response to determining that a person on the first vehicle is in a healthy emergency state, wherein the optimal junction point is determined such that the first vehicle and the second vehicle are at the same level of an overpass and/or on the same side of a road when merging at the optimal junction point; and

a third module configured to transmit the optimal junction point to the second vehicle.

Aspect 12, a computer device, comprising:

at least one processor; and

at least one memory having a computer program stored thereon,

wherein the computer program, when executed by the at least one processor, causes the at least one processor to perform the method of any of aspects 1 to 8.

Aspect 13, a vehicle, comprising:

one or more sensors configured to monitor a health status of a person on the vehicle; and

the apparatus of aspect 11 or the computer device of aspect 12.

Aspect 14, a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, causes the processor to perform the method of any of aspects 1 to 10.

Aspect 15, a computer program product comprising a computer program which, when executed by a processor, causes the processor to perform the method of any of aspects 1 to 10.

Claims

1. A computer-implemented method for vehicle personnel rescue, the method comprising:

transmitting the optimal junction point to the second vehicle.

2. The method of claim 1, wherein determining the optimal meeting point comprises:

determining a plurality of available junction points that allow vehicles to park and at which the first vehicle and the second vehicle are at the same level of an overpass and/or the same side of a road when merging;

3. The method of claim 2, wherein selecting an available meeting point from the plurality of available meeting points as a second meeting point comprises:

and selecting the available junction point with the shortest time consumption from the plurality of available junctions as the second junction point.

4. The method of claim 2, wherein selecting an available meeting point from the plurality of available meeting points as a second meeting point comprises:

acquiring weather information about a current weather condition; and

in response to the weather information indicating a weather condition including rain, snow, strong wind, or insolation, selecting, from the plurality of available meeting points, a meeting point having shelter and having a shortest elapsed time as the second meeting point.

5. The method of claim 1, further comprising:

6. The method of claim 1, further comprising:

obtaining location information regarding a plurality of available rescue vehicles of a plurality of medical rescue authorities in the vicinity of the first vehicle; and

7. The method of claim 1, further comprising:

8. The method of claim 1, further comprising:

in response to determining that a person aboard the first vehicle is in a healthy emergency, automatically recline a seat back of the person to enable the person to adjust to a lie flat condition.

9. The method of claim 1, further comprising:

identifying an identity of a person in a healthy emergency; and

10. The method of any of claims 1 to 9, wherein the person health data comprises one or more of blood pressure, pulse, heartbeat, body temperature, facial image data of the person.