Task prompt-based vehicle-mounted emergency rescue on-site command system and method

Abstract

The invention provides a vehicle-mounted emergency rescue on-site command system and method based on task prompt, relates to the technical field of emergency rescue command, and solves the technical problems that a command decision excessively depends on personal experience and rescue efficiency and risk control are restricted due to the fact that an existing command system lacks intelligent dynamic research and judgment ability. The method comprises the following steps: acquiring emergency rescue task information, and matching the emergency rescue task information with a preset scene task template to obtain a task index set; defining quantitative parameters for a plurality of task indexes and performing dynamic maintenance; iterative calculation and screening are carried out on the quantization parameters through an adaptive evolutionary algorithm strategy, and task prompt indexes are obtained; the task prompt index is visually presented in a highlight mode, and an action instruction of a commander for the task prompt index is received; and assigning the action instruction to a specified mobile terminal, and receiving task execution state feedback of the mobile terminal. The method is used in the emergency rescue on-site command process.

Description

Technical Field

[0001] This application relates to the field of emergency rescue command technology, and in particular to a vehicle-mounted emergency rescue on-site command system and method based on task prompts. Background Technology

[0002] In current emergency rescue command practices, there is a widespread reliance on static emergency plans, command platforms based on universal maps, and traditional voice radio dispatching. These existing technologies have significant shortcomings: First, static plans are ill-suited to the rapidly changing dynamics of disaster sites, failing to provide commanders with real-time, accurate decision-making support. Second, command platforms primarily focus on location and resource display, lacking the ability to transform massive amounts of complex on-site information into structured, quantifiable decision-making data. This makes it difficult for commanders to quickly prioritize key tasks amidst the chaos and high stress levels, leading to decision delays or omissions. Finally, existing systems often suffer from isolated information modules, failing to form an effective collaborative and intelligent feedback loop, thus hindering improvements in command efficiency and accuracy. Summary of the Invention

[0003] This application provides a vehicle-mounted emergency rescue on-site command system and method based on task prompts, which solves the technical problem that the existing command system lacks intelligent dynamic analysis capabilities, leading to excessive reliance on personal experience in command decisions and restricting rescue efficiency and risk control.

[0004] To achieve the above objectives, this application adopts the following technical solution: Firstly, a vehicle-mounted emergency rescue on-site command system based on task prompts is provided. The system is deployed on an onboard computer in an emergency command vehicle and communicates with the mobile terminals of on-site rescue personnel via a network. The system includes: Task Management Module: Used to acquire emergency rescue task information, match the emergency rescue task information with preset scenario task templates to obtain a set of task indicators; wherein, the scenario task templates are constructed based on several task indicators corresponding to different emergency scenarios; Dynamic indicator quantification module: used to define quantification parameters for several task indicators and perform dynamic maintenance; wherein, the quantification parameters include key values, weights, and expected values; Task prompting module: Used to iteratively calculate and filter quantified parameters using an adaptive evolutionary algorithm strategy to obtain task prompting indicators; Human-computer interaction interface module: used to visualize task prompt indicators in a highlighted form and to receive action instructions from the commander for task prompt indicators; Action execution and feedback module: used to dispatch action instructions to designated mobile terminals and receive task execution status feedback from the mobile terminals.

[0005] Based on the above technical solution, the vehicle-mounted emergency rescue on-site command system based on task prompts provided in this application transforms ambiguous and complex on-site rescue tasks into a structured set of task indicators by constructing a closed-loop command system. Through dynamic quantification of key values, weights, and expected values, the importance, urgency, and expected goals of rescue tasks become measurable and calculable. Furthermore, an adaptive evolutionary algorithm strategy is used to intelligently iterate and filter the aforementioned quantified parameters, automatically identifying the most critical task prompt indicators from a massive amount of data. This effectively overcomes the oversights, delays, and subjective biases that can easily occur with human judgment in stressful environments. Finally, through the closed-loop of highlighted prompts and mobile terminal commands, the cognitive load and decision-making difficulty of commanders are greatly reduced, and the precise and rapid issuance of command intentions and the visualized feedback of execution status are achieved, thereby improving the overall command efficiency and accuracy of emergency rescue operations.

[0006] In conjunction with the first aspect above, in one possible implementation, the method for obtaining the task prompt indicator includes: S21, through formula Calculate the expected mean of the task indicators and weighted mean Where N is the number of task indicators, Let be the expected value of the i-th task indicator. Let be the weight of the i-th task indicator, i=1,2,...,N; S22, through formula Calculate the expected second-order variance of the task indicator. and weighted second-order variance ; S23, through formula Calculate the key parameter values ​​of the task indicators ; S24, through formula Hint key values ​​for calculating task metrics ;in, Let i be the key value of the i-th task metric; S25. Select the prompt key value Top The proportion of the task indicators is marked as candidate indicators; among them, This is a preset percentage; S26. Repeat steps S21-S25 to iteratively filter the candidate indicators until the number of candidate indicators reaches the preset number, and mark the candidate indicators as task prompt indicators.

[0007] In conjunction with the first aspect above, in one possible implementation, the dynamic maintenance of several task metrics includes: For task prompt indicators, use the formula Update the corresponding expected value and weight; For the remaining task indicators, use the formula Update the corresponding expected value and weight.

[0008] In conjunction with the first aspect above, in one possible implementation, the vehicle-mounted emergency rescue on-site command system based on task prompts further includes an on-board monitoring module, wherein the on-board monitoring module includes: A single GIS map unit is used to integrate and display positioning data from vehicle-mounted GPS and mobile terminal GPS, and to present the location information of command vehicles, rescue teams and key facilities on the map in real time. The vehicle communication monitoring unit obtains the status data of the communication device in real time by calling the software interface or hardware diagnostic interface of the vehicle communication device, performs anomaly analysis on the status data, and generates an alarm event when an anomaly occurs and sends it to the task prompt module. The OBD vehicle status monitoring unit acquires the vehicle's operating parameters in real time through the CAN bus interface and protocol parsing module, performs threshold comparison analysis on the operating parameters, and generates alarm events to be sent to the task prompt module when an anomaly occurs.

[0009] In conjunction with the first aspect above, in one possible implementation, the human-computer interaction interface module includes a main screen, a first auxiliary screen, and a second auxiliary screen. The main screen displays a single GIS map unit; The first auxiliary screen displays an action map driven by the action execution and feedback module, which includes the task execution status and feedback information of each team. The second auxiliary screen visualizes the set of task indicators in the form of an interactive mind map, and receives instructions from the task prompt module to highlight the task prompt indicators.

[0010] In conjunction with the first aspect above, in one possible implementation, the vehicle-mounted emergency rescue on-site command system based on task prompts further includes a materials and equipment management module, the workflow of which includes: Acquire and input initial data on materials and equipment to obtain a basic database; Rescue teams apply for and return supplies and equipment by scanning QR codes. The system simultaneously deducts and updates the basic database in real time to obtain dynamic inventory status. The system compares the dynamic inventory status with a preset warning threshold. When the dynamic inventory status falls below the warning threshold, an alarm message is generated and sent to the task prompt module.

[0011] In conjunction with the first aspect above, in one possible implementation, the vehicle-mounted emergency rescue on-site command system based on task prompts further includes a specialized rescue knowledge base module, which includes: The initial phase of the rescue operation includes the process and key points of team formation, inventory of supplies, and coordination with local governments. Rescue execution phase: including professional response plans for different disaster situations, resource allocation principles, and safety risk assessment standards; The final stage of rescue efforts includes information gathering, report writing, and the standardization and templates for press releases. The specialized rescue knowledge base module is associated with the task management module and the human-computer interaction interface module. When the commander selects a task scenario or clicks on a specific task indicator, the relevant knowledge base entries can be displayed in the sidebar of the interface.

[0012] In conjunction with the first aspect above, in one possible implementation, the prompt information types of the task prompt module include resource-related prompts, vehicle alarm-related prompts, and rescue-related prompts; wherein, the resource-related prompts are alarm information output by the materials and equipment management module, the vehicle alarm-related prompts are alarm events output by the vehicle monitoring module, and the rescue-related prompts are knowledge base entries output by the specialized rescue knowledge base module.

[0013] In conjunction with the first aspect above, in one possible implementation, the set of task metrics includes: Surrounding conditions, used to characterize the external environment and resource status of the rescue site; The mission focus is used to characterize the core objectives of the rescue operation and instructions from higher authorities. Risk items are used to characterize potential safety hazards and secondary disaster risks during the rescue process; Task coordination points are used to represent internal coordination matters that require multi-party collaboration. Milestone events are used to characterize key milestones that mark the completion of the rescue phase.

[0014] Secondly, an electronic device is provided, comprising: a communication unit and a processing unit; the communication unit is used to acquire emergency rescue mission information; the processing unit is used to match the emergency rescue mission information with a preset scenario mission template to obtain a set of mission indicators; define quantitative parameters for several mission indicators and dynamically maintain them; iteratively calculate and filter the quantitative parameters using an adaptive evolutionary algorithm strategy to obtain mission prompt indicators; visualize the mission prompt indicators in a highlighted form and receive action instructions from the commander for the mission prompt indicators; assign the action instructions to designated mobile terminals and receive mission execution status feedback from the mobile terminals.

[0015] Thirdly, this application provides an electronic device, including: a processor and a storage medium; the storage medium includes instructions, and the processor is configured to execute the instructions to implement the methods described in the first aspect and any possible implementation thereof. This electronic device may be an electronic device or a chip within an electronic device.

[0016] Fourthly, this application provides a vehicle-mounted emergency rescue on-site command system based on task prompts, including: a task management module, a dynamic indicator quantification module, a task prompt module, a human-computer interaction interface module, and an action execution and feedback module; wherein, the task management module is used to acquire emergency rescue task information, match the emergency rescue task information with preset scenario task templates to obtain a set of task indicators; the dynamic indicator quantification module is used to define quantification parameters for several task indicators and dynamically maintain them; the task prompt module is used to iteratively calculate and filter the quantification parameters through an adaptive evolutionary algorithm strategy to obtain task prompt indicators; the human-computer interaction interface module is used to visualize the task prompt indicators in a highlighted form and receive action instructions from the commander for the task prompt indicators; the action execution and feedback module is used to assign action instructions to designated mobile terminals and receive task execution status feedback from the mobile terminals.

[0017] Fifthly, this application provides a computer-readable storage medium storing instructions that, when executed on an electronic device, cause the electronic device to perform the methods described in the first aspect and any possible implementation thereof.

[0018] In a sixth aspect, this application provides a computer program product containing instructions that, when run on an electronic device, cause the electronic device to perform the methods described in the first aspect and any possible implementation thereof.

[0019] This application provides a vehicle-mounted emergency rescue on-site command system and method based on task prompts. By constructing a closed-loop command system, the system transforms ambiguous and complex on-site rescue tasks into a structured set of task indicators. Through dynamic quantification of key values, weights, and expected values, the importance, urgency, and expected goals of rescue tasks become measurable and calculable. Furthermore, an adaptive evolutionary algorithm is used to intelligently iterate and filter the aforementioned quantified parameters, automatically identifying the most critical task prompt indicators from a massive amount of data. This effectively overcomes the oversights, delays, and subjective biases that can easily occur with human judgment under stress. Finally, through the closed-loop of highlighted prompts and mobile terminal commands, the system not only significantly reduces the cognitive load and decision-making difficulty of commanders but also achieves accurate and rapid delivery of command intentions and visualized feedback on execution status, thereby improving the overall command efficiency and accuracy of emergency rescue operations.

[0020] It should be understood that the descriptions of technical features, technical solutions, beneficial effects, or similar language in this application do not imply that all features and advantages can be achieved in any single embodiment. Rather, it is understood that the description of a feature or beneficial effect means that a specific technical feature, technical solution, or beneficial effect is included in at least one embodiment. Therefore, the descriptions of technical features, technical solutions, or beneficial effects in this specification do not necessarily refer to the same embodiment. Furthermore, the technical features, technical solutions, and beneficial effects described in this embodiment can be combined in any suitable manner. Those skilled in the art will understand that embodiments can be implemented without one or more specific technical features, technical solutions, or beneficial effects of a particular embodiment. In other embodiments, additional technical features and beneficial effects may be identified in specific embodiments that do not embody all embodiments. Attached Figure Description

[0021] Figure 1 A system architecture diagram of a vehicle-mounted emergency rescue on-site command system based on task prompts is provided for embodiments of this application; Figure 2 A flowchart illustrating a vehicle-mounted emergency rescue on-site command system based on task prompts, provided as an embodiment of this application; Figure 3 A schematic diagram of another task-prompt-based on-site command process for vehicle-mounted emergency rescue, provided as an embodiment of this application; Figure 4 A schematic diagram of another task-prompt-based on-site command process for vehicle-mounted emergency rescue, provided as an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application; Figure 6 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0022] In the description of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. The "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Furthermore, "at least one" means one or more, and "multiple" means two or more. The terms "first," "second," etc., do not limit the quantity or order of execution, and "first," "second," etc., do not necessarily imply differences.

[0023] It should be noted that, in this application, the terms "exemplary" or "for example" are used to indicate that something is being described as an example, illustration, or illustration. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0024] The task-prompt-based vehicle-mounted emergency rescue on-site command system provided in this application embodiment can be applied to, for example... Figure 1 In the vehicle-mounted emergency rescue on-site command system 100 shown, based on task prompts, such as Figure 1 As shown, the communication system includes: a task management module 10, a dynamic indicator quantification module 20, a task prompting module 30, a human-computer interaction interface module 40, and an action execution and feedback module 50.

[0025] Among them, the task management module 10 is used to obtain emergency rescue task information, match the emergency rescue task information with the preset scenario task template, and obtain a set of task indicators.

[0026] The dynamic indicator quantification module 20 is used to define quantification parameters for several task indicators and perform dynamic maintenance.

[0027] The task prompting module 30 is used to iteratively calculate and filter the quantification parameters through an adaptive evolutionary algorithm strategy to obtain task prompting indicators.

[0028] The human-computer interaction interface module 40 is used to visualize the task prompt indicators in a highlighted form and to receive the commander's action instructions for the task prompt indicators.

[0029] The action execution and feedback module 50 is used to dispatch action instructions to designated mobile terminals and receive task execution status feedback from the mobile terminals.

[0030] To address the technical problem that existing command systems lack intelligent dynamic analysis capabilities, leading to excessive reliance on personal experience in command decisions and hindering rescue efficiency and risk control, this application provides a vehicle-mounted emergency rescue on-site command system based on task prompts. This system is deployed on the onboard computer of an emergency command vehicle and communicates with the mobile terminals of on-site rescue personnel via a network, including: Task Management Module: Used to acquire emergency rescue task information, match the emergency rescue task information with preset scenario task templates to obtain a set of task indicators; wherein, the scenario task templates are constructed based on several task indicators corresponding to different emergency scenarios; Dynamic indicator quantification module: used to define quantification parameters for several task indicators and perform dynamic maintenance; wherein, the quantification parameters include key values, weights, and expected values; Task prompting module: Used to iteratively calculate and filter quantified parameters using an adaptive evolutionary algorithm strategy to obtain task prompting indicators; Human-computer interaction interface module: used to visualize task prompt indicators in a highlighted form and to receive action instructions from the commander for task prompt indicators; Action execution and feedback module: used to dispatch action instructions to designated mobile terminals and receive task execution status feedback from the mobile terminals.

[0031] Based on this, the technical problem of the lack of intelligent dynamic analysis capabilities in the existing command system, which leads to excessive reliance on personal experience in command decisions and restricts rescue efficiency and risk control, has been solved.

[0032] like Figure 2 As shown in the embodiment of this application, the vehicle-mounted emergency rescue on-site command system based on task prompts includes: Task Management Module: Used to acquire emergency rescue task information, match the emergency rescue task information with preset scenario task templates, and obtain a set of task indicators.

[0033] The scenario task template is constructed based on several task indicators corresponding to different emergency scenarios.

[0034] In some implementations, the set of task metrics includes: Surrounding conditions, used to characterize the external environment and resource status of the rescue site; The mission focus is used to characterize the core objectives of the rescue operation and instructions from higher authorities. Risk items are used to characterize potential safety hazards and secondary disaster risks during the rescue process; Task coordination points are used to represent internal coordination matters that require multi-party collaboration. Milestone events are used to characterize key milestones that mark the completion of the rescue phase.

[0035] It should be noted that each task metric can be customized, added, deleted, and modified through the backend management module.

[0036] For example, in the task management module, input the following information for this emergency rescue mission: scene location, scene center latitude and longitude, start time of outbreak, current scene area, scene geology, scene slope, material viscosity, material velocity, material width, material composition, etc.; match the scene for this mission as mudslide; obtain the set of task indicators for this scene; the defined indicators corresponding to the surrounding conditions include on-site conditions, on-site early warning, material prompts, equipment prompts, news releases, and rescue cases; the indicators defined for the task focus points include leadership instructions, property damage, casualties, communication support, engineering rescue, medical support, and emergency rescue; the indicators defined for the risk items include personnel safety, secondary disasters, information transmission, and resource allocation; the indicators defined for the task coordination points include personnel evacuation, personnel resettlement, rescue coordination, and tasks assigned by superiors; the indicators defined for the milestone events include completing personnel search and rescue, completing the treatment of the wounded, completing the resettlement of the masses, completing the road clearing, and completing the instructions from superiors.

[0037] Dynamic indicator quantification module: used to define quantification parameters for several task indicators and perform dynamic maintenance.

[0038] The quantization parameters include key values, weights, and expected values.

[0039] It should be noted that the key value represents the inherent importance of the task indicator; the larger the key value, the more important the matter itself. The weight represents the urgency of the task indicator in the current rescue stage; the larger the weight, the more urgent the indicator. The weight is a dynamic indicator that changes continuously based on the unit period and the emergency rescue process. The expected value represents the degree to which the task indicator is expected to be addressed under the current situation; the higher the expected value, the more necessary it is to provide a reminder for this indicator within the current time period and under realistic conditions. The expected value is an indicator that changes dynamically as the emergency rescue deepens.

[0040] For example, in debris flow disaster relief, in the early stages of the disaster, the dynamic indicator quantification module assigns initial parameters to various task indicators. Among them, "personnel casualties" is given extremely high inherent importance due to its connection to the core principle of life safety, and its key value is initially set to 90. At the same time, due to the unclear disaster situation and communication interruption, the weight of the milestone event "completing personnel search and rescue," which represents the core goal of the rescue, is set to 95, but its expected value is temporarily set to 70 due to the harsh on-site conditions and doubts about the feasibility of the rescue. This reflects the system's assessment of the current severe situation. As the rescue progresses, when the self-organizing network devices restore communication and receive reports of signs of life, the module dynamically updates the parameters: First, the weight of "completing personnel search and rescue" rises to 98 due to the clarity of information, and the expected value also jumps to 85 due to the improvement of rescue conditions and the increased probability of success. Secondly, this key development also triggered updates to related indicators: as the search and rescue operation was about to begin, the weight of the "personnel safety" risk item, which was strongly correlated with it, was increased to warn of the risk of secondary disasters; while the weight and expected value of the "press release" indicator were relatively lowered by the system because it was not the core of the current direct rescue operation, reflecting the intelligent judgment that resources and attention should be concentrated on key tasks.

[0041] Task prompting module: Used to iteratively calculate and filter quantified parameters using an adaptive evolutionary algorithm strategy to obtain task prompting indicators.

[0042] In some implementations, the methods for obtaining the task prompt indicators include: S21, through formula Calculate the expected mean of the task indicators and weighted mean Where N is the number of task indicators, Let be the expected value of the i-th task indicator. Let be the weight of the i-th task indicator, i=1,2,...,N; S22, through formula Calculate the expected second-order variance of the task indicator. and weighted second-order variance ; S23, through formula Calculate the key parameter values ​​of the task indicators ; S24, through formula Hint key values ​​for calculating task metrics ;in, Let i be the key value of the i-th task metric; S25. Select the prompt key value Top The proportion of the task indicators is marked as candidate indicators; among them, This is a preset percentage; S26. Repeat steps S21-S25 to iteratively filter the candidate indicators until the number of candidate indicators reaches the preset number, and mark the candidate indicators as task prompt indicators.

[0043] For example, after system initialization, all twenty-odd indicators are loaded. First, the expected value of all indicators, the global mean of their weights, and their second-order variance are calculated. Then, the first iteration is completed, calculating the key value for each indicator. Using a value set to 1 minus the golden ratio, the algorithm selects the top 38% (approximately 8 indicators) based on the golden ratio principle (such as "personnel search and rescue," "secondary disasters," and "communication support") as the first-round candidate set. This candidate set then serves as the input for the second round of calculations. The algorithm recalculates the local statistical characteristics of these 8 indicators and again selects the top 38% (approximately 3 indicators) based on the golden ratio. After several rounds of such iterative calculations, the number of candidate indicators continuously converges, eventually stabilizing at the preset 2. The final calculation shows that the combined key values ​​for "secondary disasters" (due to the rapidly increasing risk caused by continuous rainfall at the scene) and "completing personnel search and rescue" (due to the discovery of signs of life, greatly increasing urgency) significantly outperform other indicators. The system then identifies these two as the task prompt indicators for this round and highlights them on the command interface.

[0044] In some implementations, the dynamic maintenance of several task metrics includes: For task prompt indicators, use the formula Update the corresponding expected value and weight; For the remaining task indicators, use the formula Update the corresponding expected value and weight.

[0045] It should be noted that the dynamic update mechanism ensures that the system can adapt to changes in the rescue situation, reducing the importance of previously prioritized task indicators and increasing the importance of previously unmentioned indicators, focusing on the latest and most urgent matters.

[0046] For example, at the end of a calculation cycle, the system prompts two indicators, "personnel casualties" and "secondary disasters," based on the algorithm. The dynamic indicator quantification module then updates the parameters: for the two prompted indicators, their expected values ​​and weights are reduced according to a preset formula (for example, the expected value of "personnel casualties" decreases from 90 to 85, and the weight decreases from 95 to 90). At the same time, for all indicators that are not prompted (such as "medical security" and "mass resettlement"), their expected values ​​and weights are slightly increased according to the formula (for example, both the expected value and weight increase by 1-2 points). This mechanism ensures that critical matters such as "emergency rescue" that are not prompted in this round, if their actual urgency has not decreased, will receive higher prompt priority in subsequent cycles due to the cumulative gain of parameters, thus enabling the system to dynamically and adaptively focus on the latest and most urgent tasks.

[0047] In some implementations, the prompt information types of the task prompt module include resource-related prompts, vehicle alarm-related prompts, and rescue-related prompts; wherein, the resource-related prompts are alarm information output by the materials and equipment management module, the vehicle alarm-related prompts are alarm events output by the vehicle monitoring module, and the rescue-related prompts are knowledge base entries output by the specialized rescue knowledge base module.

[0048] For example, the task prompt module processes three types of prompts simultaneously: resource prompts are triggered first, as the inventory of "demolition tools" falls below a critical value, prompting the module to receive an "equipment prompt" alarm from the materials and equipment management module; almost simultaneously, vehicle alarm prompts are activated, as the onboard monitoring module detects that the command vehicle's fuel level is too low, generating a "vehicle alarm" event; at the same time, based on the current rescue progress, the system intelligently pushes a rescue affairs prompt from the specialized rescue knowledge base module, suggesting attention to the medical resource coordination plan for "casualty treatment." These three types of prompts with different priorities are integrated by the module and presented to the commander in a layered and orderly manner on the command interface.

[0049] Human-computer interaction interface module: used to visualize task prompt indicators in a highlighted form and to receive action instructions from the commander for task prompt indicators.

[0050] In some implementations, the human-computer interaction interface module includes a main screen, a first auxiliary screen, and a second auxiliary screen; The main screen displays a single GIS map unit; The first auxiliary screen displays an action map driven by the action execution and feedback module, which includes the task execution status and feedback information of each team. The second auxiliary screen visualizes the set of task indicators in the form of an interactive mind map, and receives instructions from the task prompt module to highlight the task prompt indicators.

[0051] It should be noted that in the mind map interface, the commander's operation on the highlighted indicators can be synchronously linked to and located to the corresponding task node in the action map.

[0052] For example, the three screens in front of the commander work together: the main screen displays the location of all rescue units in real time on a GIS map; the first auxiliary screen dynamically updates the task status of each team on an action map, such as showing that a team is performing a "personnel search and rescue" task; at this time, the task prompt module highlights "secondary disasters" in the indicator mind map on the second auxiliary screen; when the commander double-clicks the highlighted node in the mind map, the system immediately and automatically shifts the action map view on the first auxiliary screen to the corresponding team and its task node that is responsible for risk monitoring, realizing seamless linkage between key prompts and specific action status.

[0053] Action execution and feedback module: used to dispatch action instructions to designated mobile terminals and receive task execution status feedback from the mobile terminals.

[0054] For example, after the commander sees the highlighted "Personnel Evacuation" in the indicator mind map on the second auxiliary screen, he selects the node and designates the "Third Rescue Team," and issues the instruction "Immediately Evacuate the People in Zone B" through the action execution and feedback module. The mobile terminals of the team members immediately receive this instruction and detailed coordinates. During the execution, the team provides real-time feedback through its terminals, such as "Evacuation has begun," "50 people have been evacuated," and "One injured person has been found requiring medical support." After these feedback messages are received by the action execution and feedback module, they are synchronously updated to the action map on the first auxiliary screen, enabling the commander to clearly grasp the real-time progress of the key coordination point of "Personnel Evacuation."

[0055] Based on the above technical solution, the vehicle-mounted emergency rescue on-site command system based on task prompts provided in this application transforms ambiguous and complex on-site rescue tasks into a structured set of task indicators by constructing a closed-loop command system. Through dynamic quantification of key values, weights, and expected values, the importance, urgency, and expected goals of rescue tasks become measurable and calculable. Furthermore, an adaptive evolutionary algorithm strategy is used to intelligently iterate and filter the aforementioned quantified parameters, automatically identifying the most critical task prompt indicators from a massive amount of data. This effectively overcomes the oversights, delays, and subjective biases that can easily occur with human judgment in stressful environments. Finally, through the closed-loop of highlighted prompts and mobile terminal commands, the cognitive load and decision-making difficulty of commanders are greatly reduced, and the precise and rapid issuance of command intentions and the visualized feedback of execution status are achieved, thereby improving the overall command efficiency and accuracy of emergency rescue operations.

[0056] In one possible implementation, the vehicle-mounted emergency rescue on-site command system based on task prompts provided in this application embodiment further includes the following modules: Vehicle-mounted monitoring module.

[0057] In some implementations, the vehicle monitoring module, such as Figure 3 As shown, it includes: A single GIS map unit is used to integrate and display positioning data from vehicle-mounted GPS and mobile terminal GPS, and to present the location information of command vehicles, rescue teams and key facilities on the map in real time. The vehicle communication monitoring unit obtains the status data of the communication device in real time by calling the software interface or hardware diagnostic interface of the vehicle communication device, performs anomaly analysis on the status data, and generates an alarm event when an anomaly occurs and sends it to the task prompt module. The OBD vehicle status monitoring unit acquires the vehicle's operating parameters in real time through the CAN bus interface and protocol parsing module, performs threshold comparison analysis on the operating parameters, and generates alarm events to be sent to the task prompt module when an anomaly occurs.

[0058] It should be noted that the alarm event is displayed at the top of the human-machine interface module as the highest priority prompt indicator; the vehicle communication monitoring unit includes communication equipment and vehicle network equipment, the communication equipment includes a satellite antenna, self-organizing network equipment, communication terminal, and audio / video matrix; the vehicle network equipment includes a power distribution box, computer, and vehicle router.

[0059] For example, during a mudslide rescue mission, the vehicle-mounted monitoring module operates continuously and stably: the GIS map unit gathers and displays the precise locations of the command vehicle and various rescue teams (such as teams performing "personnel search and rescue" tasks) in real time; suddenly, the vehicle-mounted communication monitoring unit detects a sharp drop in the signal strength of the satellite communication link, determines it as an anomaly, and immediately generates a "communication interruption" alarm event; at the same time, the OBD vehicle status monitoring unit reads that the engine coolant temperature exceeds the safety threshold, and also generates a "vehicle overheating" alarm event; these two highest priority alarms are immediately sent to the task prompt module and displayed at the top of the commander's interactive interface as critical matters that need to be dealt with immediately, temporarily surpassing routine task prompts such as "engineering rescue".

[0060] Materials and Equipment Management Module.

[0061] In some implementations, the workflow of the materials and equipment management module is as follows: Figure 4 As shown, it includes: Acquire and input initial data on materials and equipment to obtain a basic database; Rescue teams apply for and return supplies and equipment by scanning QR codes. The system simultaneously deducts and updates the basic database in real time to obtain dynamic inventory status. The system compares the dynamic inventory status with a preset warning threshold. When the dynamic inventory status falls below the warning threshold, an alarm message is generated and sent to the task prompt module.

[0062] For example, during the rescue preparation phase, the administrator enters the information of the rescue equipment carried in the vehicle (such as life detectors and demolition tools) into the materials and equipment management module, generating an asset tag with a unique QR code. After the mission begins, the captain of the "first rescue team" applies for a life detector by scanning the QR code. The system updates the inventory in real time, and the number of this equipment is reduced from 3 to 2. When subsequent applications cause the dynamic inventory of the critical material "demolition tools" to drop to only 1 set, which is lower than the preset warning threshold of 2 sets, the module immediately generates an alarm message of "demolition tool inventory is critically low" and sends it to the mission prompt module. This alarm is then displayed as a high-priority "equipment prompt" on the command interface, reminding the commander to urgently allocate materials.

[0063] Specialized rescue knowledge base module.

[0064] In some implementations, the specialized rescue knowledge base module includes: The initial phase of the rescue operation includes the process and key points of team formation, inventory of supplies, and coordination with local governments. Rescue execution phase: including professional response plans for different disaster situations, resource allocation principles, and safety risk assessment standards; The final stage of rescue efforts includes information gathering, report writing, and the standardization and templates for press releases. The specialized rescue knowledge base module is associated with the task management module and the human-computer interaction interface module. When the commander selects a task scenario or clicks on a specific task indicator, the relevant knowledge base entries can be displayed in the sidebar of the interface.

[0065] It should be noted that the professional rescue knowledge base module is a knowledge system summarized from front-line rescue practice, covering the entire life cycle of emergency rescue.

[0066] For example, in a debris flow disaster relief mission, after the commander selects the "debris flow" scenario through the task management module, the system loads the corresponding professional knowledge system. When the rescue enters a critical stage, the commander notices the continuously rising expected value of the milestone event "mass resettlement" in the indicator mind map of the human-computer interaction interface, and clicks on the node to formulate a detailed plan. At this time, the professional rescue knowledge base module is automatically triggered, intelligently pushing relevant content on the "rescue execution stage" in the sidebar of the interface: first, it displays "safety specifications for the selection of temporary resettlement sites," emphasizing the need to avoid areas threatened by secondary disasters; then it lists "standards for the configuration of resettlement tents and living supplies"; finally, it provides "procedures for setting up health and epidemic prevention and medical points." These precisely pushed knowledge items directly assist the commander in quickly making decisions to establish resettlement areas on nearby high ground and immediately coordinate the deployment of "medical support" resources, greatly improving the scientific nature and efficiency of decision-making.

[0067] Based on the above technical solutions, the vehicle-mounted monitoring module, by real-time sensing of vehicle location, communication status, and its own operational health, constructs the "nerve endings" of the command system. This enables comprehensive, real-time situational awareness and self-monitoring of the command center—the emergency command vehicle—ensuring the stability and reliability of the command platform. The materials and equipment management module, through QR code identification and dynamic inventory management, achieves transparent and precise control over the entire process of rescue resources from warehousing and requisition to consumption, forming the "bloodstream" of the command system. This effectively avoids resource misallocation and shortages, ensuring the sustainability of rescue operations. The specialized rescue knowledge base module systematizes and structures scattered rescue knowledge that relies on individual experience, becoming the commander's "external brain," providing precise decision support at critical moments and significantly improving the scientific and standardized nature of command decisions. Ultimately, these three modules provide strong support from the three dimensions of "platform stability," "resource security," and "scientific decision-making," respectively, and together empower the intelligent prompt engine. This ensures that every task prompt it generates is based on a solid foundation of real-time data, accurate resources, and professional knowledge, thereby greatly improving the overall command efficiency and success rate of emergency rescue.

[0068] The foregoing mainly describes the solutions of the embodiments of this application from the perspective of device implementation. It is understood that each device, such as an electronic device, includes at least one of the hardware structures and software modules corresponding to the execution of each function in order to achieve the above-mentioned functions. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in a hardware or computer software-driven hardware manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0069] This application embodiment can divide the electronic device into functional units according to the above method example. For example, each function can be divided into a separate functional unit, or two or more functions can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software functional unit. It should be noted that the unit division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0070] When using integrated units, Figure 5 A possible structural schematic diagram of the electronic device (denoted as electronic device 50) involved in the above embodiments is shown. The electronic device 50 includes a processing unit 501 and a communication unit 502, and may also include a storage unit 503. Figure 5 The structural diagram shown can be used to illustrate the structure of the electronic device involved in the above embodiments.

[0071] when Figure 5 The schematic diagram shown is used to illustrate the structure of the electronic device involved in the above embodiments. The processing unit 501 is used to control and manage the operation of the electronic device, the communication unit 502 is used for the electronic device to communicate with other devices, and the storage unit 503 is used to store the program code and data of the electronic device.

[0072] For example, communication unit 502 is used to acquire emergency rescue mission information; The processing unit 501 is used to match emergency rescue mission information with preset scenario mission templates to obtain a set of mission indicators; define quantitative parameters for several mission indicators and maintain them dynamically; perform iterative calculation and filtering of the quantitative parameters through an adaptive evolutionary algorithm strategy to obtain mission prompt indicators; visualize the mission prompt indicators in a highlighted form and receive the commander's action instructions for the mission prompt indicators; assign the action instructions to designated mobile terminals and receive the mission execution status feedback from the mobile terminals.

[0073] The processing unit 501 can be a processor or a controller, and the communication unit 502 can be a communication interface, transceiver, transceiver circuit, transceiver device, etc. The term "communication interface" is a general term and may include one or more interfaces. The storage unit 503 can be a memory. When the electronic device 50 is a chip, the processing unit 501 can be a processor or a controller, and the communication unit 502 can be an input interface and / or an output interface, pins, or circuits, etc. The storage unit 503 can be a storage unit within the chip (e.g., a register, cache, etc.) or a storage unit located outside the chip (e.g., read-only memory (ROM), random access memory (RAM, etc.).

[0074] The communication unit can also be called a transceiver unit. The antenna and control circuit with transceiver functions in the electronic device 50 can be considered as the communication unit 502 of the electronic device 50, and the processor with processing functions can be considered as the processing unit 501 of the electronic device 50. Optionally, the device in the communication unit 502 used to implement the receiving function can be considered as the communication unit. The communication unit is used to execute the receiving steps in the embodiments of this application, and the communication unit can be a receiver, a receiver circuit, etc. The device in the communication unit 502 used to implement the transmitting function can be considered as the transmitting unit. The transmitting unit is used to execute the transmitting steps in the embodiments of this application, and the transmitting unit can be a transmitter, a transmitter, a transmitting circuit, etc.

[0075] Figure 5 If the integrated units in the process are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, in essence, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. Storage media for storing computer software products include various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory, random access memory, magnetic disks, or optical disks.

[0076] Figure 5 The units in the process can also be called modules; for example, a processing unit can be called a processing module.

[0077] This application also provides a hardware structure diagram of an electronic device (denoted as electronic device 60), see [link to diagram]. Figure 6 The electronic device 60 includes a processor 601, and optionally, a memory 602 connected to the processor 601.

[0078] In the first possible implementation, see Figure 6 The electronic device 60 also includes a transceiver 603. The processor 601, memory 602, and transceiver 603 are connected via a bus. The transceiver 603 is used to communicate with other devices or communication networks. Optionally, the transceiver 603 may include a transmitter and a receiver. The device in the transceiver 603 that implements the receiving function can be considered as a receiver, which is used to perform the receiving steps in the embodiments of this application. The device in the transceiver 603 that implements the transmitting function can be considered as a transmitter, which is used to perform the transmitting steps in the embodiments of this application.

[0079] Based on the first possible implementation method Figure 6 The structural diagram shown can be used to illustrate the structure of the electronic device involved in the above embodiments.

[0080] in, Figure 6 This can also be illustrated by a system chip in an electronic device. In this case, the actions performed by the aforementioned electronic device can be implemented by this system chip; the specific actions performed can be found above and will not be repeated here.

[0081] In implementation, each step of the method provided in this embodiment can be completed by integrated logic circuits in the processor or by instructions in software form. The steps of the method disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or being executed by a combination of hardware and software modules in the processor.

[0082] The processor in this application may include, but is not limited to, at least one of the following: a central processing unit (CPU), a microprocessor, a digital signal processor (DSP), a microcontroller unit (MCU), or an artificial intelligence processor, etc., which are various computing devices that run software. Each computing device may include one or more cores for executing software instructions to perform calculations or processing. The processor may be a separate semiconductor chip or integrated with other circuits into a single semiconductor chip. For example, it may be integrated with other circuits (such as encoding / decoding circuits, hardware acceleration circuits, or various bus and interface circuits) to form a SoC (System-on-a-Chip), or it may be integrated as a built-in processor within an ASIC. The ASIC with the integrated processor may be packaged separately or together with other circuits. In addition to the cores for executing software instructions to perform calculations or processing, the processor may further include necessary hardware accelerators, such as field-programmable gate arrays (FPGAs), PLDs (programmable logic devices), or logic circuits that implement dedicated logic operations.

[0083] The memory in the embodiments of this application may include at least one of the following types: read-only memory (ROM) or other types of static storage devices capable of storing static information and instructions; random access memory (RAM) or other types of dynamic storage devices capable of storing information and instructions; or electrically erasable programmable-only memory (EEPROM). In some scenarios, the memory may also be a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media, or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto.

[0084] This application also provides a computer-readable storage medium including instructions that, when run on a computer, cause the computer to perform any of the methods described above.

[0085] This application also provides a computer program product containing instructions that, when run on a computer, cause the computer to perform any of the methods described above.

[0086] This application also provides a chip including a processor and an interface circuit. The interface circuit is coupled to the processor, which is used to run computer programs or instructions to implement the above-described method. The interface circuit is used to communicate with other modules outside the chip.

[0087] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software programs, implementation can be, in whole or in part, in the form of a computer program product. This computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device containing one or more servers, data centers, etc., that can be integrated with the medium. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state disks (SSDs)).

[0088] Although this application has been described herein in conjunction with various embodiments, those skilled in the art, by reviewing the accompanying drawings, disclosure, and appended claims, will understand and implement other variations of the disclosed embodiments in carrying out the claimed application. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude multiple instances. A single processor or other unit can implement several functions listed in the claims. While different dependent claims may recite certain measures, this does not mean that these measures cannot be combined to produce good results.

[0089] Although this application has been described in conjunction with specific features and embodiments, it is obvious that various modifications and combinations can be made thereto without departing from the spirit and scope of this application. Accordingly, this specification and drawings are merely exemplary illustrations of this application as defined by the appended claims, and are considered to cover any and all modifications, variations, combinations, or equivalents within the scope of this application. Clearly, those skilled in the art can make various alterations and modifications to this application without departing from the spirit and scope of this application. Thus, if such modifications and modifications of this application fall within the scope of the claims of this application and their equivalents, this application is also intended to include such modifications and modifications.

Claims

1. A vehicle-mounted emergency rescue on-site command system based on task prompts, characterized in that, The system is deployed on the onboard computer of the emergency command vehicle and communicates with the mobile terminals of on-site rescue personnel via a network, including: Task Management Module: Used to acquire emergency rescue task information, match the emergency rescue task information with preset scenario task templates to obtain a set of task indicators; wherein, the scenario task templates are constructed based on several task indicators corresponding to different emergency scenarios; Dynamic indicator quantification module: used to define quantification parameters for several task indicators and perform dynamic maintenance; wherein, the quantification parameters include key values, weights, and expected values; Task prompting module: Used to iteratively calculate and filter quantified parameters using an adaptive evolutionary algorithm strategy to obtain task prompting indicators; Human-computer interaction interface module: used to visualize task prompt indicators in a highlighted form and to receive action instructions from the commander for task prompt indicators; Action execution and feedback module: used to dispatch action instructions to designated mobile terminals and receive task execution status feedback from the mobile terminals.

2. The system according to claim 1, characterized in that, The methods for obtaining the task prompt indicators include: S21, through formula Calculate the expected mean of the task indicators and weighted mean Where N is the number of task indicators, Let be the expected value of the i-th task indicator. Let be the weight of the i-th task indicator, i=1,2,...,N; S22, through formula Calculate the expected second-order variance of the task indicator. and weighted second-order variance ; S23, through formula Calculate the key parameter values ​​of the task indicators ; S24, through formula Hint key values ​​for calculating task metrics ;in, Let i be the key value of the i-th task metric; S25. Select the prompt key value Top The proportion of the task indicators is marked as candidate indicators; among them, This is a preset percentage; S26. Repeat steps S21-S25 to iteratively filter the candidate indicators until the number of candidate indicators reaches the preset number, and mark the candidate indicators as task prompt indicators.

3. The system according to claim 2, characterized in that, The dynamic maintenance of several task indicators includes: For task prompt indicators, use the formula Update the corresponding expected value and weight; For the remaining task indicators, use the formula Update the corresponding expected value and weight.

4. The system according to claim 1, characterized in that, The vehicle-mounted emergency rescue on-site command system based on task prompts further includes an on-board monitoring module, which includes: A single GIS map unit is used to integrate and display positioning data from vehicle-mounted GPS and mobile terminal GPS, and to present the location information of command vehicles, rescue teams and key facilities on the map in real time. The vehicle communication monitoring unit obtains the status data of the communication device in real time by calling the software interface or hardware diagnostic interface of the vehicle communication device, performs anomaly analysis on the status data, and generates an alarm event when an anomaly occurs and sends it to the task prompt module. The OBD vehicle status monitoring unit acquires the vehicle's operating parameters in real time through the CAN bus interface and protocol parsing module, performs threshold comparison analysis on the operating parameters, and generates alarm events to be sent to the task prompt module when an anomaly occurs.

5. The system according to claim 4, characterized in that, The human-computer interaction interface module includes a main screen, a first auxiliary screen, and a second auxiliary screen. The main screen displays a single GIS map unit; The first auxiliary screen displays an action map driven by the action execution and feedback module, which includes the task execution status and feedback information of each team. The second auxiliary screen visualizes the set of task indicators in the form of an interactive mind map, and receives instructions from the task prompt module to highlight the task prompt indicators.

6. The system according to claim 1, characterized in that, The vehicle-mounted emergency rescue on-site command system based on task prompts also includes a materials and equipment management module. The workflow of the materials and equipment management module includes: Acquire and input initial data on materials and equipment to obtain a basic database; Rescue teams apply for and return supplies and equipment by scanning QR codes. The system simultaneously deducts and updates the basic database in real time to obtain dynamic inventory status. The system compares the dynamic inventory status with a preset warning threshold. When the dynamic inventory status falls below the warning threshold, an alarm message is generated and sent to the task prompt module.

7. The system according to claim 1, characterized in that, The vehicle-mounted emergency rescue on-site command system based on task prompts also includes a specialized rescue knowledge base module, which includes: The initial phase of the rescue operation includes the process and key points of team formation, inventory of supplies, and coordination with local governments. Rescue execution phase: including professional response plans for different disaster situations, resource allocation principles, and safety risk assessment standards; The final stage of rescue efforts includes information gathering, report writing, and the standardization and templates for press releases. The specialized rescue knowledge base module is associated with the task management module and the human-computer interaction interface module. When the commander selects a task scenario or clicks on a specific task indicator, the relevant knowledge base entries can be displayed in the sidebar of the interface.

8. The system according to claim 4, 6, or 7, characterized in that, The task prompting module provides prompts of the following types: resource prompts, vehicle alarm prompts, and rescue task prompts. The resource prompts are alarm information output by the materials and equipment management module, the vehicle alarm prompts are alarm events output by the vehicle monitoring module, and the rescue task prompts are knowledge base entries output by the specialized rescue knowledge base module.

9. The system according to claim 1, characterized in that, The set of task metrics includes: Surrounding conditions, used to characterize the external environment and resource status of the rescue site; The mission focus is used to characterize the core objectives of the rescue operation and instructions from higher authorities. Risk items are used to characterize potential safety hazards and secondary disaster risks during the rescue process; Task coordination points are used to represent internal coordination matters that require multi-party collaboration. Milestone events are used to characterize key milestones that mark the completion of the rescue phase.

10. An electronic device, characterized in that, include: Communication unit and processing unit; The communication unit is used to acquire emergency rescue mission information; The processing unit is used to match emergency rescue mission information with preset scenario mission templates to obtain a set of mission indicators; define quantitative parameters for several mission indicators and maintain them dynamically; perform iterative calculation and filtering of the quantitative parameters through an adaptive evolutionary algorithm strategy to obtain mission prompt indicators; visualize the mission prompt indicators in a highlighted form and receive the commander's action instructions for the mission prompt indicators; assign the action instructions to designated mobile terminals and receive the mission execution status feedback from the mobile terminals.

Images