Emergency call method and device, vehicle-mounted TBox, vehicle and storage medium

Abstract

The application provides an emergency call method and device, a vehicle-mounted TBox, a vehicle and a storage medium. The method comprises: loading a preset behavior tree when an emergency call event is triggered, the behavior tree comprising behavior nodes and control nodes, each behavior node performing at least one operation associated with the emergency call event, and the control nodes being used to represent the logical relationship between the behavior nodes; and controlling each behavior node to perform the corresponding operation through the control nodes. The application uses a behavior tree to manage the operations performed by the emergency call and the logical relationship between the operations. Since the behavior tree has the characteristics of strong expansibility, simple and clear logic, etc., the operations in the emergency call scenario are managed and executed based on the behavior tree, so that the execution logic is clearer, the conversion between different operations is simpler, and the execution error rate and code complexity are reduced, and the adjustment and expansion of the execution logic are facilitated.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and more particularly to an emergency call method, device, vehicle-mounted TBox, vehicle, and storage medium. Background Technology

[0002] Emergency Call (eCall), triggered in the event of a vehicle accident, is a car alarm mechanism designed to ensure the safety of drivers and passengers while the vehicle is in motion. Once triggered, the eCall module installed in the vehicle performs a series of actions, such as sending accident-related information to a Public Safety Answering Point (PSAP) and calling the PSAP. Furthermore, depending on the execution status, it may perform further actions such as automatically redialing if the PSAP call fails and answering the PSAP callback if the call is successful.

[0003] The execution state of the eCall module is typically managed by a finite state machine. However, due to the high coupling between states, the transitions between states are complex and difficult to maintain. Furthermore, finite state machines have poor scalability; when new execution states need to be added, the complexity of the state machine increases significantly. Summary of the Invention

[0004] To overcome the problems existing in related technologies, this application provides an emergency call method, device, vehicle-mounted TBox, vehicle, and storage medium.

[0005] According to a first aspect of the embodiments of this application, an emergency call method is provided, the method comprising: loading a preset behavior tree when an emergency call event is triggered, the behavior tree including behavior nodes and control nodes, each of the behavior nodes performing at least one operation associated with the emergency call event, and the control nodes being used to characterize the logical relationship between the behavior nodes;

[0006] The control node controls each of the behavior nodes to perform corresponding operations.

[0007] According to a second aspect of the embodiments of this application, an emergency call device is provided, comprising:

[0008] A loading module is used to load a preset behavior tree when an emergency call event is triggered. The behavior tree includes behavior nodes and control nodes. Each behavior node performs an operation associated with the emergency call event. The control nodes are used to characterize the logical relationship between the behavior nodes.

[0009] The control module is used to control each of the behavior nodes to perform corresponding operations through the control node.

[0010] According to a third aspect of the embodiments of this application, an in-vehicle TBox is provided, comprising: a mobile communication module for providing a call data link; a GPS positioning module for collecting vehicle location information; and a CAN communication module for collecting vehicle driving data.

[0011] The system includes an emergency call module for acquiring the vehicle's location information and driving data, sending the vehicle's location information and driving data to the rescue platform based on the call data link, and establishing a call with the rescue platform to implement the method described in the first aspect above.

[0012] According to a fourth aspect of the embodiments of this application, a vehicle is provided, the vehicle being equipped with at least an airbag, an emergency call button, and the TBox described in the third aspect above.

[0013] According to a fifth aspect of the present application, a computer-readable storage medium is provided, the computer-readable storage medium storing a computer program, the computer program being used to instruct related hardware to perform the method described in the first aspect above.

[0014] The technical solutions provided by the embodiments of this application may include the following beneficial effects:

[0015] This application employs behavior trees to manage the various operations to be performed in an emergency call and the logical relationships between these operations. Because behavior trees are highly scalable and logically concise, managing and executing operations in an emergency call scenario based on behavior trees makes the execution logic clearer and the transitions between different operations simpler, thereby reducing execution error rates and code complexity. Furthermore, it facilitates the adjustment and expansion of the execution logic.

[0016] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this application, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] Figure 1A This is a behavior tree structure shown in this application.

[0019] Figure 1B This is a flowchart illustrating an emergency call method according to an exemplary embodiment of this application.

[0020] Figure 1C This application illustrates a behavior tree structure for an emergency call scenario according to an exemplary embodiment.

[0021] Figure 1D This application illustrates a flowchart of an operation associated with an emergency call scenario, according to an exemplary embodiment.

[0022] Figure 2 This is a block diagram illustrating an emergency call device according to an exemplary embodiment of this application.

[0023] Figure 3 This application illustrates a hardware structure diagram of an electronic device containing an emergency call device according to an exemplary embodiment.

[0024] Figure 4 This is a schematic diagram of an in-vehicle TBox according to an exemplary embodiment of this application. Detailed Implementation

[0025] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0026] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0027] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0028] To overcome the problems existing in related technologies, this application proposes an emergency call method. A behavior tree is pre-constructed for each operation required in an emergency call scenario. Control nodes in the behavior tree control the execution order and switching logic of each operation. Given the strong scalability and low coupling between nodes of the behavior tree, executing operations in an emergency call scenario based on the behavior tree makes the execution logic clearer and the transitions between different operations simpler. This helps reduce the execution error rate and code complexity, and facilitates adjustments or extensions to the execution logic.

[0029] First, to better understand the emergency call method proposed in this application, we will introduce the relevant content of behavior trees. A behavior tree is a tree-like structure used to represent execution logic, composed of different types of nodes, including root nodes, control nodes, and behavior nodes. The root node is the starting node of the behavior tree, and the operation of the behavior tree begins from the root node; the control node controls the execution direction, determining the next node to be executed; and the behavior node is the specific action to be executed. In a top-down behavior tree, with the root node as the first level, each node in each level is a child node of the node in the level above it and a parent node of the node in the level below it. For example... Figure 1A As shown, Figure 1A The present application illustrates a behavior tree structure, which, starting from the root node 100, includes, from top to bottom, the root node 100, the control node 110, the first behavior node 131, and the second behavior node 132. The control node 110 is a child node of the root node 100 and also the parent node of the first behavior node 131 and the second behavior node 132.

[0030] Each node in the behavior tree returns a success or failure result to its parent node after execution. The control node determines the logic for executing its child nodes based on their type, and determines its own execution result based on the execution results returned by its child nodes. For example... Figure 1A Taking the behavior tree shown as an example, assuming that the control node 110 is a sequence node, the first behavior node 131 is executed first. If the first behavior node 131 is executed successfully, the second behavior node 132 is executed. The sequence node is only executed successfully if both the first behavior node 131 and the second behavior node 132 are executed successfully.

[0031] The embodiments of this application will now be described in detail.

[0032] like Figure 1B As shown, Figure 1B This application illustrates an emergency call method according to an exemplary embodiment, comprising the following steps:

[0033] Step 102: When an emergency call event is triggered, load a preset behavior tree. The behavior tree includes behavior nodes and control nodes. Each behavior node performs at least one operation associated with the emergency call event. The control nodes are used to characterize the logical relationship between the behavior nodes.

[0034] Emergency calls can be automatically triggered when a vehicle accident occurs. The triggering condition can be an event indicating an accident, such as airbag deployment; or it can be actively triggered by the user, who typically has an emergency call button inside the vehicle to select it. In one embodiment of this application, the triggering condition for an emergency call event includes at least airbag deployment or the selection of a preset emergency call button. Furthermore, other events indicating a vehicle accident can also be set as triggering conditions for an emergency call event, such as detecting a collision, a rollover, or water ingress. This application does not impose any limitations on this.

[0035] A behavior tree is constructed for emergency call scenarios, where the actions performed by the behavior nodes are associated with the emergency call event. The EU's emergency call standard stipulates that when a vehicle is involved in a traffic accident, the in-vehicle system (IVS) should have the function of automatically initiating an alarm or allowing the user to manually trigger an alarm. When an alarm is triggered, it should send a minimum set of data (MSD) to the rescue platform, i.e., the Public Safety Answering Point (PSAP), and should automatically answer the PSAP's callback within a specified time after the call with the PSAP ends. The MSD contains accident-related information, including vehicle location, direction of travel, time of accident, severity of accident, vehicle identification, fuel type, number of passengers, etc.

[0036] Based on EU standards, in one embodiment of this application, the action node includes at least the following: an action node for acquiring accident-related information and sending it to the rescue platform, and establishing a call with the rescue platform; an action node for determining whether the call with the rescue platform has ended normally; or an action node for receiving a callback from the rescue platform within a preset waiting time. It is understood that establishing a call with the rescue platform is equivalent to calling the rescue platform. Accident-related information is sent to the rescue platform via the call's data link; acquiring and sending accident-related information and establishing a call with the rescue platform are coupled and therefore executed by the same action node.

[0037] Furthermore, considering that traffic accidents usually occur while the vehicle is in motion, to reduce accidental operation, it can be determined whether the vehicle is running when an emergency call is triggered. Only after confirming that the vehicle is running should the rescue platform be called. This avoids the problem of consuming rescue resources due to accidental pressing of the emergency call button or other misoperations by the user. There are various criteria for determining whether the vehicle is running. One embodiment of this application determines whether the vehicle is running based on its ignition status. The behavior node also includes an action node for determining whether the vehicle is running.

[0038] In emergency call scenarios, various operations are typically executed by the TBox (Telematics Box, wireless gateway) in the vehicle system. The TBox itself has functions such as real-time collection of driving data, recording of driving trajectory, monitoring of vehicle faults, analysis of driving behavior, and remote communication. Therefore, it can detect the triggering conditions of emergency call events such as airbag deployment or the selection of the emergency call button, and can also collect accident-related information, such as obtaining the vehicle's location information through the GPS positioning system.

[0039] Step 104: Control each behavior node to perform the corresponding operation through the control node.

[0040] There are various types of control nodes, each corresponding to a specific execution logic. A control node acts as a parent node to control at least one child node. The execution result of the parent node is determined based on the execution results of its child nodes. Child nodes can be behavior nodes or other control nodes. Commonly used control nodes when constructing behavior trees include the following:

[0041] (1) A Sequence Node has at least one child node. A sequence node succeeds if all its child nodes execute successfully. The execution logic is as follows: it executes its child nodes in a preset order; if one child node fails, the execution of the remaining child nodes stops, and the sequence node fails. The preset order is generally based on the left-to-right arrangement of the child nodes in the behavior tree. Figure 1A Taking the behavior tree shown as an example, assuming that the control node 110 is a sequential node, the first behavior node 131 will be executed first. If the first behavior node 131 fails to execute, the second behavior node 132 will not be executed.

[0042] (2) The selected node (Fallback Node) must have at least one child node. The selected node executes successfully if at least one of its child nodes executes successfully. The corresponding execution logic is to execute its child nodes sequentially according to a preset order, stopping the execution of other child nodes if one child node executes successfully, thus ensuring the selected node's successful execution. (Continuing with...) Figure 1A Taking the behavior tree shown as an example, assuming that the control node 110 is the selection node, the first behavior node 131 will be executed first. If the first behavior node 131 is executed successfully, the second behavior node 132 will not be executed.

[0043] (3) Retry Node: It has only one child node and is used to control its child node to execute cyclically a preset number of times. The loop ends when its child node executes successfully or the preset number of executions is reached. Its execution result is consistent with the execution result of its child node.

[0044] (4) Forcesuccess Node: It has only one child node and is used to output the execution result of successful execution after controlling the execution of its child node.

[0045] Or (5) Inverter Node, which has only one child node and is used to control the output of the opposite execution result of its child node after the child node is executed.

[0046] In addition, control nodes can be categorized into types such as Simple Parallel Nodes, Forcefailure Nodes, and Condition Nodes. The combination of control nodes and action nodes reflects the execution flow of each action node.

[0047] In one embodiment of this application, the steps of controlling various behavioral nodes to perform corresponding operations through a control node include: first, determining whether the vehicle is in an ignition state; if the vehicle is in an ignition state, acquiring accident-related information and sending it to the rescue platform, while simultaneously establishing a call with the rescue platform. The accident-related information is sent via the call's data link. To avoid interference from other signals, the vehicle's entertainment system speakers and microphone are muted when sending the accident-related information to the rescue platform. Furthermore, considering that manually triggering an emergency call might be due to accidental activation of the emergency call button, in another embodiment of this application, to prevent accidental emergency call activation, the trigger condition for the emergency call event is that a preset emergency call button is selected. When establishing a call with the rescue platform, a dialing prompt tone is played first, and the dialing operation is performed only after the prompt tone has lasted for a preset duration, providing the user with an opportunity to cancel the emergency call, thereby preventing accidental activation.

[0048] Considering that during the process of establishing a call with the rescue platform, there may be situations where the call establishment fails (i.e., the rescue platform does not successfully answer) or the call is abnormally interrupted, in another embodiment of this application, the above-mentioned step of controlling each behavior node to perform corresponding operations through the control node further includes: if the call with the rescue platform fails to be established and the number of attempts to establish the call does not exceed a threshold, re-establishing the call with the rescue platform; or, if the call with the rescue platform is successfully established, determining whether the call with the rescue platform has ended normally, and if the call is abnormally interrupted and no callback is received from the rescue platform within a preset waiting time, re-establishing the call with the rescue platform, wherein the number of attempts to establish the call does not exceed the threshold.

[0049] like Figure 1C The diagram illustrates a behavior tree structure applied to an emergency call scenario according to an exemplary embodiment of this application. As described above regarding the control node, its role is to determine the execution path. The purpose of determining the execution path is to identify the behavior node to be executed, and the execution result of the control node depends on the execution result of the behavior node. The execution path based on this behavior tree is as follows:

[0050] Starting from the root node 100, proceed through the sequential node 111, and execute the four child nodes of the sequential node 111 in order from left to right. Only if a child node is executed successfully will the next child node be executed; otherwise, the sequential node 111 will fail to execute.

[0051] 1. First, execute the behavior node 112 that determines the vehicle's ignition status.

[0052] 2. If the vehicle is determined to be in the ignition state (node ​​112 is executed successfully), the process proceeds through the first loop node 113 and the first selection node 114 in sequence, and then executes node 115 to establish a call with the rescue platform. First, the microphone and speaker of the in-vehicle entertainment system are muted, then relevant accident information is obtained and sent to the rescue platform, and then a call is established with the rescue platform.

[0053] If a call with the rescue platform is not successfully established (node ​​115 execution failure), then node 116, which acquires the duplicate dialing event, is executed to retry establishing a call with the rescue platform. The reason for setting up node 116 is that the duplicate dialing operation can only be performed if a duplicate dialing event is acquired. It should be noted that since the execution logic corresponding to a loop node is to execute its child nodes in a loop when the child node fails, node 116 must return the execution failure result to the first selected node 114 before node 115 can be executed again to retry establishing a call with the rescue platform upon acquiring a duplicate dialing event. The prerequisite for retrying to establish a call is that the number of attempts has not exceeded a threshold; otherwise, the repeated execution of node 115 stops, the call establishment fails, and the emergency call state is exited.

[0054] 3. If a call is successfully established with the rescue platform (node ​​115 executes successfully), the process proceeds sequentially through node 117 (forced success), node 118 (second loop), node 119 (second selection), and node 120 (determining whether the call with the rescue platform ended normally). If the call ended normally (node ​​120 executes successfully), node 126 (restoring to the state before the emergency call) is executed. Restoring to the state before the emergency call requires the following operations: removing the mute restriction and Tbox sleep restriction of the in-vehicle entertainment system, turning off the emergency call status indicator, turning off call-related functions, turning off voice playback-related functions, and entering idle state, i.e., exiting the emergency call state.

[0055] 4. If the call is abnormally interrupted (node ​​120 fails to execute), the process proceeds sequentially through inversion node 121, third loop node 122, third selection node 123, and then to node 124, which receives a callback from the rescue platform within a preset waiting time. If no callback is received from the rescue platform (node ​​124 fails to execute), node 125 is executed to re-establish the call with the rescue platform. If establishing the call fails (node ​​125 fails to execute), the process of executing node 124 and then node 125 after node 124 fails is repeated until node 124 or node 125 executes successfully, or the number of times node 124 is executed reaches a threshold to end the loop corresponding to the third loop node 122.

[0056] If a callback is received from the rescue platform (node ​​124 executes successfully) or a call is successfully re-established with the rescue platform (node ​​125 executes successfully), the process of determining whether the call with the rescue platform ended normally in steps 3 and 4 above is repeated in node 120 until the call ends normally (node ​​120 executes successfully) or the number of times node 120 is executed reaches a threshold, thus ending the loop corresponding to the second loop node 118. If no callback is received from the rescue platform and a call is not successfully established with the rescue platform (both nodes 124 and 125 fail), the reversal node 121 returns a successful execution result to the second selection node 119, thereby ending the loop corresponding to the second loop node 118. Regardless of whether the execution result of the second loop node 118 is successful or unsuccessful, the forced success node 117 returns a successful execution result to the sequential node 111, and then executes node 126 to restore the state before the emergency call.

[0057] To more clearly illustrate the execution process in the above emergency call scenarios, the following methods will be used: Figure 1D The flowchart shown includes the following steps:

[0058] Step S140: Determine whether the vehicle is in ignition mode. If it is in ignition mode, proceed to step S141; otherwise, proceed to step S150.

[0059] Step S141: Obtain accident-related information and send it to the rescue platform, establishing a communication with the rescue platform. If the communication fails, proceed to step S142; if the communication is successfully established, proceed to step S144.

[0060] Step S142: Obtain the repeated dialing event. If the event is successfully obtained, proceed to step S143; otherwise, proceed to step S150.

[0061] Step S143: Determine whether the number of attempts to establish a call with the rescue platform has reached the threshold. If the threshold is reached, proceed to step S150; otherwise, proceed to step S141.

[0062] Step S144: Determine whether the call with the rescue platform has ended normally. If it has ended normally, proceed to step S149; if it has been interrupted abnormally, proceed to step S145.

[0063] Step S145: Receive a callback from the rescue platform within a preset waiting time. If the callback from the rescue platform is successfully received, proceed to step S148. If the callback from the rescue platform is not successfully received, proceed to step S146.

[0064] Step S146: Re-establish communication with the rescue platform. If the communication is successfully established, proceed to step S148; otherwise, proceed to step S147.

[0065] Step S147: Determine whether the number of times to re-establish a call with the rescue platform has reached the threshold. If the threshold is reached, proceed to step S149; otherwise, proceed to step S145.

[0066] Step S148: Determine whether the number of abnormal call terminations has reached the threshold. If the threshold is reached, proceed to step S149; otherwise, proceed to step S144.

[0067] Step S149: Restore to the state before the emergency call.

[0068] Step S150: Exit emergency call status.

[0069] Corresponding to the embodiments of the aforementioned methods, this application also provides an embodiment of an emergency call device and the terminal used therein. For example... Figure 2 As shown, Figure 2 This is a block diagram illustrating an emergency call device 200 according to an exemplary embodiment of this application, the device comprising:

[0070] The loading module 210 is used to load a preset behavior tree when an emergency call event is triggered. The behavior tree includes behavior nodes and control nodes. Each behavior node performs an operation associated with the emergency call event, and the control nodes are used to represent the logical relationship between the behavior nodes.

[0071] The control module 220 is used to control each behavior node to perform corresponding operations through the control node.

[0072] The specific implementation process of the functions and roles of each module in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0073] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0074] The emergency call device embodiments in this application can be installed on electronic devices. The device embodiments can be implemented through software, hardware, or a combination of both. Taking software implementation as an example, as a logical device, it is formed by a processor reading the corresponding computer program instructions from non-volatile memory into memory and executing them. From a hardware perspective, such as... Figure 3 The diagram shown is a hardware structure diagram of the electronic device 300 where the emergency call device is located in an embodiment of this application. Except for... Figure 3 In addition to the processor 310, memory 330, network interface 320, and non-volatile memory 340 shown, the electronic device in which the device 331 is located in the embodiment may also include other hardware depending on the actual function of the electronic device, which will not be described in detail here.

[0075] like Figure 4 The diagram shown is a schematic of an in-vehicle TBox 400 according to an exemplary embodiment of this application, including: a mobile communication module 410 for providing a call data link;

[0076] GPS positioning module 420 is used to collect vehicle location information;

[0077] The CAN communication module 430 is used to collect vehicle driving data;

[0078] The system includes an emergency call module 440, which is used to obtain the vehicle's location information and driving data, send the vehicle's location information and driving data to the rescue platform based on the call data link, and establish a call with the rescue platform to implement the method described in any of the aforementioned method embodiments.

[0079] Accordingly, this application also provides a vehicle equipped with at least an airbag, an emergency call button, and the TBox described in the foregoing embodiments. This application also provides a computer-readable storage medium storing a computer program that instructs related hardware to perform the methods described in any of the foregoing method embodiments.

[0080] The foregoing has described specific embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0081] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention filed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not claimed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the claims.

[0082] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

[0083] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. An emergency call method, characterized in that, include: When an emergency call event is triggered, a pre-set behavior tree is loaded, which includes behavior nodes and control nodes. Each behavior node performs at least one operation associated with the emergency call event. The control node is used to characterize the logical relationship between the behavior nodes, and as a parent node, controls at least one child node and determines the logic to execute the child node, which is a behavior node or other control node. The execution result of the control node is determined based on the execution results returned by each child node; The behavioral nodes include at least: behavioral nodes that determine whether the vehicle is in an ignition state, as well as behavioral nodes that acquire accident-related information and send the accident-related information to the rescue platform and establish a communication with the rescue platform; The control node controls each of the behavior nodes to perform corresponding operations; the step of controlling each of the behavior nodes to perform corresponding operations via the control node includes: Determine whether the vehicle is in an ignition state; With the vehicle in the ignition state, acquire accident-related information and send it to the rescue platform; and establish a call with the rescue platform.

2. The method according to claim 1, characterized in that, The triggering conditions for the emergency call event include at least one of the following: the airbag deploys or a preset emergency call button is selected.

3. The method according to claim 1, characterized in that, The behavior node also includes: The action node that determines whether the call with the rescue platform ended normally; or The action node is to receive a callback from the rescue platform within a preset waiting time.

4. The method according to claim 3, characterized in that, The step of controlling each of the behavior nodes to perform corresponding operations through the control node further includes: If a call to the rescue platform fails to be established, and the number of attempts to establish a call does not exceed a threshold, a new call should be established with the rescue platform; or If the call is abnormally interrupted and no callback is received from the rescue platform within the preset waiting time, the call is re-established with the rescue platform, and the number of re-established calls does not exceed the threshold.

5. The method according to claim 1, characterized in that, The triggering conditions for the emergency call event include: the preset emergency call button being selected; Establishing a call with the rescue platform includes the following steps: Play a dial tone and then perform a dialing operation after the dial tone has been played for a preset duration.

6. The method according to claim 1, characterized in that, The step of sending the accident-related information to the rescue platform includes: Mute the speakers and microphone of the vehicle's in-vehicle entertainment system; The relevant information about the accident will be sent to the rescue platform.

7. The method according to claim 4, characterized in that, The control node determines the logic to execute for the child node based on its own type, and the types of the control node include at least: Sequential nodes are used to skip other child nodes if it is known that the child node has failed to execute. Select a node to skip other child nodes if it is known that the child node has executed successfully; A loop node is used to control the child nodes to execute cyclically a preset number of times; The forced success node is used to output the execution result of successful execution after controlling the execution of the child node; Alternatively, a reverse node can be used to control the output of an execution result that is the opposite of the execution result of the child node after the child node is executed.

8. An emergency call device, characterized in that, include: A loading module is used to load a preset behavior tree when an emergency call event is triggered. The behavior tree includes behavior nodes and control nodes. Each behavior node performs an operation associated with the emergency call event. The control node is used to characterize the logical relationship between the behavior nodes, and as a parent node, controls at least one child node and determines the logic to be executed by the child node, which is a behavior node or other control node. The execution result of the control node is determined based on the execution results returned by each child node; The behavioral nodes include at least: behavioral nodes that determine whether the vehicle is in an ignition state, as well as behavioral nodes that acquire accident-related information and send the accident-related information to the rescue platform and establish a communication with the rescue platform; The control module is used to control each of the behavior nodes to perform corresponding operations through the control node; the step of controlling each of the behavior nodes to perform corresponding operations through the control node includes: Determine whether the vehicle is in an ignition state; With the vehicle in the ignition state, acquire accident-related information and send it to the rescue platform; and establish a call with the rescue platform.

9. A vehicle-mounted TBox, characterized in that, include: The mobile communication module is used to provide a data link for calls; The GPS positioning module is used to collect vehicle location information; The CAN communication module is used to collect vehicle driving data; The system includes an emergency call module for acquiring the vehicle's location information and driving data, sending the vehicle's location information and driving data to the rescue platform based on the call data link, and establishing a call with the rescue platform to implement the method described in any one of claims 1 to 7.

10. A vehicle, said vehicle being equipped with at least an airbag, an emergency call button, and the TBox of claim 9.

11. A computer-readable storage medium storing a computer program that instructs associated hardware to perform the method according to any one of claims 1 to 7.

Images