Fire and Rescue Command Center Unit Dispatch System
By locking in event information and determining initial response needs based on templates, filtering and recording unit codes, generating capability statistics, filling resource gaps, and solidifying instructions, the problem of inconsistent decision-making caused by information changes in the existing system was solved, and an efficient and traceable dispatch process for the fire and rescue command system was realized.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- NINGBO DINGXIANG FIRE TECH CO LTD
- Filing Date
- 2026-04-09
- Publication Date
- 2026-07-31
AI Technical Summary
The existing fire and rescue command system is prone to information changes after receiving an alarm, resulting in inconsistent decision-making. It lacks a unified data link for resource screening and demand matching, and it is difficult to form structured archiving and consistency verification for multi-stage dispatch. Furthermore, it does not uniformly manage the unit availability status and capability data.
The system employs a four-element locking module to lock the event location, category, level label, and initial functional requirement label. The template dispatch module determines the first-strike one-click template, the organization screening module forms a candidate unit pool, the first dispatch determination module records the code, the force aggregation module generates capability statistics, the gap reinforcement module fills the resources, and the compilation and issuance module solidifies the instructions.
It ensured consistency of input criteria during the dispatch process, improved the certainty and continuity of decision-making, ensured the traceability and verifiability of dispatched objects, and enhanced the certainty and verifiability of the dispatch process in the fire and rescue command center.
Smart Images

Figure CN121998457B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of emergency dispatch management technology, specifically relating to a unit-based dispatch system for fire and rescue command centers. Background Technology
[0002] With the expansion of urban areas and the frequent occurrence of various emergencies, the complexity of information processing in fire and rescue command centers during alarm reception, analysis, dispatch, and handling is constantly increasing. Existing fire and rescue command systems typically require commanders to manually or semi-automatically select dispatching agencies and rescue forces based on the location, type of incident, and empirical rules after receiving an alarm, and then generate dispatch instructions level by level. While such systems can complete basic alarm reception and force dispatch, they still have shortcomings in data consistency, decision-making verifiability, and the continuity of multi-stage dispatch.
[0003] On the one hand, in existing technologies, event information acquired during the alarm reception phase is often referenced or modified multiple times during subsequent dispatch. Inconsistencies in the reference criteria for event location, event category, and demand judgment between different modules can easily lead to deviations in template matching conditions, distance ranking benchmarks, or demand calculation results, affecting the stability of dispatch decisions. On the other hand, after the initial dispatch force is determined, most systems lack structured statistics on the capabilities of the selected forces and a systematic comparison with demand templates. Reinforcement decisions usually rely on manual judgment or simple rules, making it difficult to form a repeatable and verifiable processing flow.
[0004] In addition, existing dispatch systems mostly target organizations or vehicles for dispatch, without subdividing and modeling units that undertake different handling responsibilities. There is a lack of unified management of the relationship between unit availability status, capability data and dispatch codes, which makes it difficult to accurately trace the basis and execution order of dispatch when determining the formation, issuing instructions and reviewing the event. Summary of the Invention
[0005] This invention provides a unit-based dispatch system for fire and rescue command centers, which solves the technical problems in related technologies, such as the easy changes in alarm information during the dispatch process leading to drift in decision-making, the lack of a unified data link for resource screening and demand matching, and the difficulty in forming structured archives and consistency verification for multi-stage dispatch.
[0006] This invention provides a unit-based dispatch system for fire and rescue command centers, comprising: The quadruple locking module is used to acquire and lock the dispatch input quadruple, which includes event location, event category, level label, and initial functional requirement label. The template dispatch module is used to determine the first-battle one-click template from the regular dispatch scenario library based on the event category and level label in the dispatch input quadruple, and trigger one-click dispatch to obtain the first dispatch unit requirement list. The agency screening module is used to sort the agencies by distance based on the event positions in the dispatch input quadruple to obtain a candidate agency sequence, and to obtain a candidate unit pool by filtering based on the unit availability tri-state. The first dispatch determination module is used to determine the first dispatch package in the candidate unit pool according to the candidate organization sequence based on the first dispatch unit requirement list, and record the minimum dispatch unit code corresponding to the first dispatch package. The Force Aggregation Module is used to include the first dispatch package into the selected forces, forming a mixed dispatch of selected forces, and generating a list of selected forces and statistical data on the capabilities of the selected forces. The gap reinforcement module is used to extract standard demand data based on the first battle one-click template, compare it with the selected force capability statistics to obtain capability gap data, retrieve the list of reinforcement units in the candidate unit pool based on the capability gap data, and update the selected force list and the selected force capability statistics. The compilation and distribution module is used to compile and confirm the updated list of selected forces and issue dispatch instructions, and solidify the re-dispatch package; the re-dispatch package includes the updated list of selected forces and the updated statistical data on the capabilities of the selected forces.
[0007] The beneficial effects of this invention are as follows: This invention uses units as the basic dispatch objects. During the alarm reception and case establishment stage, it assembles and locks the event location, event category, event level tags, and initial functional requirement tags, unifying the input criteria for subsequent template matching, distance sorting, requirement calculation, and reinforcement retrieval, reducing decision-making biases caused by information changes or inconsistent references during dispatch. The system determines the first-response one-click template based on a conventional dispatch scenario library, solidifies the first dispatch unit requirement list, and forms the first dispatch package under the constraints of the candidate organization sequence and candidate unit pool. It also records the dispatch unit code and the minimum dispatch unit code, improving the traceability of dispatch object identification. By generating a list of selected forces and capability statistics and comparing them with standard requirement data, the system can generate capability gap data and drive reinforcement to fill gaps. Updated data objects can directly enter the formation determination and instruction issuance process. Simultaneously, the re-dispatch package is archived to key process data for easy review and debriefing, improving the certainty, continuity, and verifiability of the fire and rescue command center's dispatch process. Attached Figure Description
[0008] Figure 1 This is a schematic diagram of the modular dispatch system of the fire and rescue command center of the present invention. Detailed Implementation
[0009] The subject matter described herein will now be discussed with reference to exemplary embodiments. It should be understood that these embodiments are discussed only to enable those skilled in the art to better understand and implement the subject matter described herein, and changes may be made to the function and arrangement of the elements discussed without departing from the scope of this specification. Various processes or components may be omitted, substituted, or added as needed in the examples. Furthermore, features described in some examples may be combined in other examples.
[0010] like Figure 1 As shown, the fire and rescue command center's unit-based dispatch system includes: Quadruple locking module 1 is used to acquire and lock the dispatch input quadruple including event location, event category, level label, and initial functional requirement label; Template dispatch module 2 is used to determine the first-battle one-click template from the regular dispatch scenario library based on the event category and level label in the dispatch input quadruple, and trigger one-click dispatch to obtain the first dispatch unit requirement list. The organization screening module 3 is used to sort the organizations by distance based on the event positions in the dispatch input quadruple to obtain a candidate organization sequence, and to obtain a candidate unit pool by filtering based on the unit availability tri-state. The first dispatch determination module 4 is used to determine the first dispatch package in the candidate unit pool according to the candidate organization sequence based on the first dispatch unit requirement list, and record the minimum dispatch unit code corresponding to the first dispatch package. The Force Aggregation Module 5 is used to include the first dispatch package into the selected forces, forming a selected force after mixed deployment, and generating a list of selected forces and statistical data on the capabilities of the selected forces. The gap reinforcement module 6 is used to extract standard demand data based on the first battle one-click template, compare it with the selected force capability statistics to obtain capability gap data, retrieve the list of reinforcement units in the candidate unit pool based on the capability gap data, and update the selected force list and the selected force capability statistics. The compilation and distribution module 7 is used to compile and confirm the updated list of selected forces and issue dispatch instructions, and solidify the re-dispatch package; wherein, the re-dispatch package includes the updated list of selected forces and the updated statistical data on the capabilities of the selected forces.
[0011] In one embodiment of the present invention, the command center's alarm receiving interface creates an event record after receiving an alarm message. This event record serves as a data carrier established by the command center system for a single event, carrying basic information and dispatch process data for that event. After the event record is created, the system obtains the event location, event category, level label, and initial functional requirement label from the alarm receiving interface and writes these four items into the event record. Specifically, the event location refers to the coordinate representation of the event's location within the command center system; the event category refers to the identifiable handling category to which the event belongs, such as fire, traffic accident, or trapped personnel; the level label refers to the marking information used to characterize the event's handling level, such as using level one, level two, and level three to characterize the event's handling level; and the initial functional requirement label refers to the initial marking information based on the handling capabilities required at the alarm receiving stage, used to constrain the determination of subsequent dispatch needs and the scope of reinforcement retrieval, such as fire extinguishing, demolition, search and rescue, water supply, and smoke extraction requirements. All four items serve as core input data items in the alarm handling and dispatch decision-making stages of the present invention and form traceable original evidence in the event record. After writing is complete, the system assembles the event location, event category, level label, and initial functional requirement label into a dispatch input quadruple. This dispatch input quadruple is a unified data object composed of the above four inputs. Subsequently, the system sets a locked state for the dispatch input quadruple, which is an unmodifiable control flag applied to the dispatch input quadruple and its components. Once the locked state is in effect, the system prohibits modification of the event location, event category, level label, and initial functional requirement label within the dispatch input quadruple, thus ensuring a consistent input boundary for the event throughout the dispatch process. This prevents deviations in template matching conditions, distance sorting benchmarks, and capacity gap calculation methods due to input changes during dispatch. This locking mechanism enables the command center to form a verifiable data link in alarm handling and dispatch management information processing. Inputs are solidified during the alarm reception and case creation stage, and the same input object is consistently referenced in subsequent decision-making stages. This meets the requirements of certainty, traceability, and consistency for emergency dispatch and reduces the risk of instruction generation deviations caused by inconsistent cross-module data references.
[0012] In one embodiment of the present invention, the system first reads the locked dispatch input quadruple and extracts the event category and level label from the locked dispatch input quadruple; using the event category and level label as search conditions, it determines the first-battle one-click template in the regular dispatch scenario library. The regular dispatch scenario library is a set of scenario templates pre-set by the command center system, storing multiple first-battle one-click templates with at least event category and level label as index dimensions; the first-battle one-click template is a template object corresponding to a specific event category and level label, internally pre-defined with the unit types and required quantity configurations to be deployed in the first-battle phase. After the system completes the template determination in the regular dispatch scenario library, it triggers one-click dispatch based on the first-battle one-click template. One-click dispatch is a trigger action that automatically generates the first-battle dispatch requirement in the command center system based on the template, and its output is a structured result of the requirement consistent with the template configuration, so that the first-battle requirement generation process after receiving the alarm has a definite input condition and a definite template mapping relationship.
[0013] After triggering one-click dispatch, the system further reads the main combat unit type and functional unit type defined in the first-combat one-click template, and determines the required quantity and type for each main combat unit type. The main combat unit type refers to the unit type category undertaking the main on-site handling tasks, and the functional unit type refers to the unit type category providing professional support capabilities for main combat handling; the required quantity is the quantity requirement for the corresponding unit type, and the required type is a clear assignment identifier for the unit type category. The system organizes the required content corresponding to the main combat unit type and functional unit type into main combat unit requirements and functional unit requirements respectively, and writes and solidifies these requirements into the first-dispatch unit requirement list. The first-dispatch unit requirement list is a structured requirement data object output by the command center system, used to uniformly carry the unit type and required quantity information in the first-combat phase, and serves as the sole source of requirements for agency screening and first-dispatch package determination in subsequent steps.
[0014] Through the above processing, this invention enables the fire and rescue command center's unit-based dispatch system to use unified event categories and level labels as template retrieval criteria, and to output the initial response requirements in the form of a first-response unit requirement list in a structured manner. Compared with the traditional method of relying on manual experience to select forces item by item, this processing can reduce the subjective differences in the formation of requirements after receiving the alarm, and enable the generation of initial response requirements to have a verifiable template basis and consistent data standards. It also provides a unified upstream input for subsequent construction of candidate resource pools based on distance and availability, determination of the first dispatch package based on demand, and execution of reinforcement retrieval based on capacity gaps, thereby improving the certainty and continuity of the command center's dispatch decision-making process.
[0015] In one embodiment of the present invention, a candidate mechanism sequence is obtained by sorting the mechanisms by distance based on the event positions in the dispatch input quadruple, and a candidate unit pool is obtained by filtering based on the unit availability tri-state, including: Step 11: The system first reads the locked dispatch input quadruple and extracts the event location from it. Since the dispatch input quadruple is locked, the event location remains unchanged during this dispatch process, thus ensuring the consistency and traceability of the distance sorting benchmark.
[0016] Step 12: After extracting the event location, the system obtains the location corresponding to each participating organization and determines the organization distance based on the event location and the corresponding organization location. The organization is a dispatchable organizational unit entity of the command center system, capable of being associated with the locations of organizations within its coverage area or location. The corresponding organization location is the organization's positional representation in the system, used to determine the distance to the event location. The organization distance is the distance value between the event location and the corresponding organization location, used to characterize the spatial reachability of the organization to the event. The system establishes a one-to-one correspondence record between organization distances and corresponding organizations, ensuring each organization has a unique organization distance record for subsequent verifiable sorting based on organization distance. The determination of organization distance can be achieved using a location distance determination method commonly used in command center systems. The system takes the event location and the corresponding organization location as input, outputs the organization distance according to preset distance determination rules, and forms an organization distance record.
[0017] Step 13: After obtaining the distance records of each institution, the system generates a candidate institution sequence by sorting the institutions in ascending order of distance. The candidate institution sequence is an ordered set of institutions arranged from smallest to largest distance, used to limit the priority of institutions for subsequent unit screening and selection. The system then obtains the unit set corresponding to each institution in sequence according to the candidate institution sequence, and performs filtering based on the three states of unit availability, eliminating units in occupied and unavailable states, and collecting the remaining available units to form a candidate unit pool. The unit is a collective term for resource objects participating in the dispatch, including main combat units and functional units; main combat units are units that undertake the main on-site handling tasks, and functional units are units that provide professional support capabilities for main combat handling. The unit set is a collection of data objects of units subordinate to or associated with an institution. The three states of unit availability are a set of status markers of the unit at the time of dispatch, including available state, occupied state, and unavailable state; where, available state indicates that the unit is in a state that can be dispatched in this event, occupied state indicates that the unit is performing other tasks or has been occupied by other events, and unavailable state indicates that the unit is in a state of failure, maintenance, or other unavailable state. By reading and filtering the three states of unit availability, the candidate unit pool is limited to the set of units that can be dispatched at the current moment, so that the subsequent determination of the first dispatch packet and the retrieval of reinforcement units are only performed within the range of available state units.
[0018] Through the above processing, the present invention enables the fire and rescue command center unit-based dispatch system to quickly form spatial priorities centered on the event location, and outputs the candidate resource range as a structured object of candidate organization sequence and candidate unit pool. Compared with the method of selecting neighboring organizations based solely on manual experience or without distinguishing unit status, this processing incorporates both organization accessibility and unit availability status into the candidate range construction process. This ensures that the subsequent matching and selection based on the first dispatch unit demand list has clear organization order constraints and availability constraints, reduces the risk of including occupied or unavailable units in the dispatch decision, and ensures the consistency and verifiability of the dispatch decision process in terms of data caliber.
[0019] In one embodiment of the present invention, the first dispatch package is determined from the candidate unit pool according to the candidate organization sequence based on the first dispatch unit demand list, and the minimum dispatch unit code corresponding to the first dispatch package is recorded, including: Step 21: Read the first dispatch unit demand list, candidate organization sequence and candidate unit pool, and determine the first dispatch unit demand list as the sole source of unit type and demand quantity, thereby limiting the reference scope of unit type and demand quantity in the subsequent selection process and avoiding inconsistencies in selection rules caused by multiple demand sources.
[0020] Step 22: Read the unit type and quantity of each item in the first dispatch unit requirement list, and retrieve the unit set corresponding to the current institution from the candidate unit pool in the order of the candidate institution sequence. Perform unit type matching and filtering on the unit set to obtain matching units. To ensure that the constituent units of the first dispatch package have a unique inclusion relationship, the system only includes matching units that have not been included in the first dispatch package, and continues to include them with the required quantity as the stopping condition until the required quantity corresponding to the requirement is met. After completing the current requirement, the system continues to perform the same processing on the next requirement in the first dispatch unit requirement list until all requirements in the first dispatch unit requirement list have been processed, thereby forming a first dispatch package candidate result consistent with the first dispatch unit requirement list.
[0021] Step 23: After the candidate results of the first dispatch package are formed, the system aggregates and solidifies the units contained in the first dispatch package into a single package, and records the dispatch unit code of each unit in the first dispatch package. The dispatch unit code is a unique identifier used by the command center system to identify units and support the generation and issuance of dispatch instructions. The system uses the dispatch unit code as a traceable marker within the first dispatch package. The system further compares the dispatch unit codes recorded in the first dispatch package, determines the dispatch unit code with the smallest value as the minimum dispatch unit code, and binds and records the minimum dispatch unit code in the first dispatch package to form a deterministic identification benchmark for the first dispatch package. This facilitates the use of the same minimum dispatch unit code to establish consistent sorting and association criteria during subsequent compilation and structured generation of dispatch instructions.
[0022] This invention unifies the selection criteria for the first dispatch package by defining the first dispatch unit demand list as the sole source of unit type and demand quantity. It also ensures the sequential determination and verifiability of the first dispatch package formation process by sequentially screening and incorporating candidate units into the candidate unit pool according to the candidate organization sequence. Furthermore, it achieves unique anchoring of the first dispatch package identifier and unified reference for subsequent compilation and dispatch instruction generation by recording the dispatch unit code in the first dispatch package and determining the minimum dispatch unit code.
[0023] In one embodiment of the present invention, the first dispatch package is included in the selected forces to form a mixed dispatch selected forces, and a list of selected forces and statistical data on the capabilities of the selected forces are generated, including: Step 31: Read the first dispatch packet and obtain the units contained in it. Read the dispatch unit code corresponding to each unit one by one. The system determines the units contained in the first dispatch packet as constituent units of the selected forces and establishes a one-to-many inclusion relationship between the selected forces and the constituent units. Simultaneously, it records the dispatch unit code corresponding to each constituent unit in the selected forces, thus forming the selected forces after mixed dispatch. The selected forces are data objects used by the command center system during the current event dispatch process to carry the set of units selected to participate in the handling and their dispatch identifiers. The selected forces after mixed dispatch serve as the sole carrier object for subsequent statistics and comparisons.
[0024] Step 32: After the selected forces are formed through mixed deployment, the system lists each of the selected forces and its corresponding deployment unit codes, forming a selected force list. This list is a structured representation of the constituent units and deployment unit codes within the selected forces, serving as a verifiable unit and identifier directory in subsequent steps. The system further reads the capability data corresponding to each unit within the selected forces and aggregates this data by unit type to form selected force capability statistics. This capability data is capability information data associated with units in the command center system, representing the unit's capability values in handling tasks. The selected force capability statistics are statistical results of aggregating the capability data of the units within the selected forces by unit type, used to output a capability summary that aligns with the standard requirements data of the first-strike one-click template, thereby supporting the determination of subsequent capability gap data.
[0025] Step 33: Perform consistency verification on the selected force list and the selected force capability statistics. The verification rule is that the set of units listed in the selected force list is consistent with the set of units included in the selected forces after the mixed deployment, and the collection scope of the selected force capability statistics is consistent with the set of units included in the selected forces after the mixed deployment. After the verification is passed, the system binds and records the selected force list and the selected force capability statistics in the selected forces after the mixed deployment, so that the selected forces after the mixed deployment have both a traceable composition list and comparable capability statistics, which serve as a stable input object for the subsequent gap reinforcement module.
[0026] Through the above processing, the present invention achieves unified carrying of selected force objects by including the first dispatch package in the selected forces and recording the dispatch unit code in the selected forces; it achieves structured output of capability comparison caliber by generating a list of selected forces and aggregating capability data according to unit type to form selected force capability statistics; and it achieves verifiability and consistent reference of data links by performing consistency verification on the list of selected forces and the selected force capability statistics and binding records.
[0027] In one embodiment of the present invention, standard requirement data is extracted based on the first-battle one-click template, and capability gap data is obtained by comparing it with the capability statistics of the selected forces. Based on the capability gap data, a list of reinforcement units is retrieved from the candidate unit pool, and the list of selected forces and the capability statistics of the selected forces are updated, including: Step 41: Read the initial combat one-click template and the selected force capability statistics. Based on the initial combat one-click template, aggregate the demand content by unit type to form standard demand data. The standard demand data is a demand benchmark data object extracted from the initial combat one-click template and aggregated by unit type, used as the demand caliber for comparison with the selected force capability statistics. After the standard demand data is formed, the system reads the standard demand data and the corresponding capability summary value of the same unit type in the selected force capability statistics for each unit type, and performs difference determination to obtain the capability gap value: when the standard demand data is greater than the capability summary value, the difference between the standard demand data and the capability summary value is determined as the capability gap value; when the standard demand data is not greater than the capability summary value, the capability gap value is determined as zero. The system aggregates the capability gap values corresponding to each unit type to form capability gap data. The capability gap data is a gap result set data object aggregated by unit type, used to indicate the reinforcement demand boundary of each unit type under the current selected force configuration.
[0028] Step 42: After the capacity gap data is formed, the system reads the capacity gap data, the candidate unit pool, and the candidate organization sequence. For unit types with capacity gap values greater than zero, the system determines the target unit type and sets the corresponding capacity gap value as the reinforcement requirement quantity, thus forming the reinforcement retrieval conditions. The system then selects units matching the unit type from the candidate unit pool according to the candidate organization sequence and adds matching units not yet included in the reinforcement unit list until the reinforcement requirement quantity corresponding to the target unit type is met. After the reinforcement units for one target unit type are included, the system continues to perform the same retrieval and inclusion process for other target unit types in the capacity gap data until the target unit types with capacity gap values greater than zero are processed, thereby obtaining a reinforcement unit list covering all target unit types.
[0029] Step 43: After the reinforcement unit list is formed, the system reads the list and the corresponding dispatch unit code for each unit, appending the unit and dispatch unit code to the selected force list to form an updated selected force list. The system further reads the capability data of the newly added units and merges this data into the selected force capability statistics data according to unit type, forming an updated selected force capability statistics data. To ensure consistency in the scope of data collection between the updated list and the updated statistics data, the system performs a consistency check on the updated selected force list and the updated selected force capability statistics data. The check rule is that the set of units listed in the updated selected force list must be consistent with the scope of data collection in the updated selected force capability statistics data. After successful check, the system binds the updated selected force list and the updated selected force capability statistics data into a single record.
[0030] Through the above processing, this invention achieves a unified definition of requirements by aggregating requirements by unit type based on the first-response one-click template to form standard requirements data. It achieves a deterministic expression of reinforcement requirements by determining the difference between the standard requirements data and the capability summary value of the same unit type in the selected force capability statistics and aggregating them to form capability gap data. It achieves an executable link and data loop for reinforcement completion by selecting matching units from the candidate unit pool according to the candidate organization sequence to form a reinforcement unit list and updating the selected force list and the selected force capability statistics. This enables the fire and rescue command center's unit-based dispatch system to quickly compare the first-response requirements with the capabilities of the selected forces and trigger reinforcement, ensuring that the subsequent formation and command issuance processes are consistent and verifiable.
[0031] In one embodiment of the present invention, the updated list of selected forces is compiled and a deployment order is issued, thus solidifying the re-deployment package; wherein, the re-deployment package includes a first-battle one-click template, a list of selected forces, statistical data on the capabilities of selected forces, and capability gap data, including: Step 51: Read the updated selected force list and use it as the sole source of units for formation determination, thereby limiting the input boundaries of the formation process and preventing the introduction of units not included in the updated selected force list during formation determination. The system then performs formation determination on the units listed in the updated selected force list to form a formation result, which is used as the sole basis for generating dispatch instructions. The one-to-one correspondence between units and dispatch unit codes is maintained in the formation result, ensuring that units can be located using a consistent identification relationship in the subsequent instruction generation stage.
[0032] Step 52: After the formation result is formed, the system generates a dispatch instruction based on the formation result. The dispatch instruction includes a set of dispatch unit codes and the units corresponding to each dispatch unit code. The dispatch instruction maintains a one-to-one correspondence between dispatch unit codes and corresponding units, thus giving the dispatch instruction a definite code index and unit assignment content. The system issues the dispatch instruction and records the issuance time and issuance status. The issuance time and issuance status are written into the dispatch instruction to form an issuance record, so that the dispatch instruction has traceable record information corresponding to the issuance action, meeting the command center's need for review of the dispatch instruction generation and issuance process.
[0033] Step 53: After the dispatch order is issued, the system reads the initial combat one-click template, the updated selected force list, the updated selected force capability statistics, and capability gap data. It then aggregates and solidifies these data objects into a re-dispatch package and establishes a one-to-one correspondence record between the re-dispatch package and the dispatch order. The re-dispatch package is a data object that archives and solidifies the key inputs and outputs of this dispatch process, used to form a verifiable snapshot of the dispatch process in the command center system. By establishing a one-to-one correspondence record with the dispatch order, the re-dispatch package and the dispatch order form a definite binding relationship at the data level. The system further performs a consistency check on the re-dispatch package and binds the record. The check rules are that the updated selected force list in the re-dispatch package is consistent with the unit and dispatch unit code set included in the dispatch order, and the capability gap data in the re-dispatch package is consistent with the read capability gap data. After the check passes, the check result is bound and recorded in the re-dispatch package, thus ensuring that the re-dispatch package simultaneously possesses the deterministic constraints of complete process elements and consistent key objects.
[0034] Through the above processing, this invention achieves the determinization of the input boundary for generating dispatch instructions by determining the updated selected force list as the sole source of units for the formation and the formation result as the sole basis for generating dispatch instructions. By maintaining a one-to-one correspondence between dispatch unit codes and corresponding units in the formation result and dispatch instructions, and recording the issuance time and issuance status, it achieves the structured issuance and traceable recording of dispatch instructions from the command center. By aggregating and solidifying the first-strike one-click template, the updated selected force list, the updated selected force capability statistics data, and capability gap data into a re-deployment package and performing consistency verification, it achieves the archiving, solidification, and consistent referencing of key data objects in the dispatch process. This enables the system to review the formation and issuance process of dispatch instructions and output the formation, instructions, and archived objects with a unified standard, supporting subsequent queries, traceability, and dispatch review.
[0035] In one embodiment of the present invention, after determining the minimum dispatch unit code, the system reads the encoding result and generates a dispatch instruction based on the encoding result. The dispatch instruction includes a set of dispatch unit codes and units corresponding to each dispatch unit code. To determine the order of the dispatch instructions, the system performs a numerical comparison on the set of dispatch unit codes contained in the dispatch instruction, determines the order of the dispatch unit codes based on the comparison result, and writes this order into the dispatch instruction to form an internal sequence field of the dispatch instruction. The system further determines the unit corresponding to the dispatch unit code that matches the minimum dispatch unit code as the first unit in the dispatch instruction, and writes the first unit mark into the dispatch instruction, so that the dispatch instruction can be parsed and processed by the dispatch execution stage according to the internal order after it is issued. The numerical comparison is a processing rule for determining the relative size of the numerical values of the dispatch unit codes, used to generate a unique sequence result without changing the one-to-one correspondence between the dispatch unit codes and the corresponding units, thereby avoiding different parsing orders for the same dispatch instruction at different execution ends.
[0036] Through the above processing, this invention achieves the determination of the internal arrangement order of dispatch instructions by performing a numerical comparison of the set of dispatch unit codes contained in the dispatch instructions and writing it into the dispatch instructions. By determining the unit corresponding to the dispatch unit code that is consistent with the smallest dispatch unit code as the first unit in the dispatch instructions, the unified anchoring of the dispatch execution order is achieved. This enables the system to organize dispatch execution in a consistent order, improves the controllability and verifiability of instruction execution, and makes the structured output of dispatch instructions have a traceable sorting basis, reducing the risk of dispatch deviation caused by inconsistent order during the cross-terminal issuance and execution process of the command center.
[0037] In one embodiment of the present invention, after the updated list of selected forces and the updated statistical data on the capabilities of the selected forces are formed, the system reads the first-strike one-click template and extracts standard demand data based on the first-strike one-click template. Then, the standard demand data is compared with the statistical data on the capabilities of the selected forces to obtain capability gap data. The capability gap data is used to indicate the capability gap value of each unit type. The system judges the capability gap data. When there is a unit type in the capability gap data with a capability gap value greater than zero, the system repeatedly performs the reinforcement unit list retrieval process: the system determines the number of reinforcement requirements based on the capability gap value, and uses the target unit type and the number of reinforcement requirements as retrieval constraints to select units with matching unit types from the candidate unit pool to form reinforcement units. The reinforcement units are then added to the updated list of selected forces and the updated statistical data on the capabilities of the selected forces, so that the composition and capability statistical scope of the selected forces are updated synchronously with the inclusion of reinforcement. After completing one round of reinforcement inclusion and update, the system extracts standard requirement data based on the first battle one-click template and compares it with the updated selected force capability statistics to update the capability gap data. When there are still unit types with capability gap values greater than zero in the capability gap data, the system continues to repeat the above retrieval and update process until the capability gap values of all unit types in the capability gap data are determined to be zero, thereby ending the loop completion process and outputting the final updated selected force list and updated selected force capability statistics.
[0038] Through the above processing, this invention achieves continuous updating of the gap status by extracting standard demand data based on the first-battle one-click template and comparing it with the updated selected force list and updated selected force capability statistics after the updated selected force list and updated selected force capability statistics are formed. By repeatedly executing the reinforcement unit list retrieval when the capability gap value is greater than zero and adding the reinforcement units to the updated selected force list and updated selected force capability statistics, a closed loop of reinforcement replenishment action is achieved. This enables the system to continuously replenish reinforcements when the initial force is insufficient and form an input scale consistent with the template requirements. The demand comparison, gap update, retrieval selection and data update are solidified into a verifiable cyclic processing link, reducing the risk of repeated manual intervention and inconsistent standards caused by insufficient replenishment at one time.
[0039] It should be noted that the range and threshold size are set for ease of comparison. The size of the threshold depends on the amount of sample data and the number of bases set by those skilled in the art for each set of sample data, as long as it does not affect the ratio between the parameter and the quantized value.
[0040] The embodiments of the present invention have been described above, but the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms based on the guidance of the present embodiments, all of which are within the protection scope of the present embodiments.
Claims
1. A unit-based dispatch system for fire and rescue command centers, characterized in that: include: The quadruple locking module is used to acquire and lock the dispatch input quadruple, which includes event location, event category, level label, and initial functional requirement label. The template dispatch module is used to determine the first-battle one-click template from the regular dispatch scenario library based on the event category and level label in the dispatch input quadruple, and trigger one-click dispatch to obtain the first dispatch unit requirement list. The agency screening module is used to sort the agencies by distance based on the event positions in the dispatch input quadruple to obtain a candidate agency sequence, and to obtain a candidate unit pool by filtering based on the unit availability tri-state. The first dispatch determination module is used to determine the first dispatch package in the candidate unit pool according to the candidate organization sequence based on the first dispatch unit requirement list, and to record the minimum dispatch unit code corresponding to the first dispatch package, including: Step 21: Read the first dispatch unit demand list, candidate organization sequence and candidate unit pool, and determine the first dispatch unit demand list as the sole source of unit type and demand quantity; Step 22: Read the unit type and required quantity of each item in the first dispatch unit requirement list. According to the candidate organization sequence, obtain the unit set corresponding to the current organization from the candidate unit pool and filter the units with matching unit types. Add the matching units that have not been included in the first dispatch package to the first dispatch package until the required quantity of the item is met. Step 23: Collect and solidify the units contained in the first dispatch package into the first dispatch package, and record the dispatch unit code of each unit in the first dispatch package; compare the dispatch unit codes and determine the dispatch unit code with the smallest value as the smallest dispatch unit code and bind and record it in the first dispatch package. The force aggregation module is used to include the initial deployment package into the selected forces, forming a mixed deployment of selected forces, and generating a list of selected forces and statistical data on their capabilities, including: Step 31: Read the first dispatch packet and obtain the units contained in the first dispatch packet. Read the dispatch unit code corresponding to each unit one by one. Determine the units contained in the first dispatch packet as the constituent units of the selected forces, and establish a one-to-many inclusion relationship between the selected forces and the constituent units. Record the dispatch unit code corresponding to each unit in the selected forces to form the selected forces after mixed dispatch. Step 32: Based on the selected forces after mixed deployment, list the included units and corresponding deployment unit codes to form a selected forces list; read the capability data corresponding to each included unit, and collect the capability data according to unit type to form selected forces capability statistics. Step 33: Perform consistency verification on the selected force list and the selected force capability statistics. The verification rules are that the set of units listed in the selected force list is consistent with the set of units included in the selected forces after mixed deployment, and the collection scope of the selected force capability statistics is consistent with the set of units included in the selected forces after mixed deployment. After the verification is passed, bind and record the selected force list and the selected force capability statistics in the selected forces after mixed deployment. The gap reinforcement module is used to extract standard demand data based on the first-battle one-click template, compare it with the selected force capability statistics to obtain capability gap data, retrieve a list of reinforcement units from the candidate unit pool based on the capability gap data, and update the selected force list and the selected force capability statistics, including: Step 41: Read the first battle one-click template and the selected force capability statistics. Based on the first battle one-click template, collect the demand content by unit type to form standard demand data. For each unit type, read the standard demand data and the capability summary value corresponding to the same unit type in the selected force capability statistics to determine the difference. When the standard demand data is greater than the capability summary value, the difference is determined as the capability gap value. When the standard demand data is not greater than the capability summary value, the capability gap value is determined as zero. Collect the capability gap values to form capability gap data. Step 42: Read the capacity gap data, candidate unit pool, and candidate organization sequence; determine the target unit type for unit types with capacity gap values greater than zero and use the capacity gap value as the reinforcement requirement quantity to form the reinforcement search condition; select units with matching unit types from the candidate unit pool according to the candidate organization sequence, and add matching units that are not included in the reinforcement unit list to the reinforcement unit list until the reinforcement requirement quantity corresponding to the target unit type is met; Step 43: Read the reinforcement unit list and the corresponding dispatch unit code for each unit. Add the unit and dispatch unit code to the selected force list to form an updated selected force list. Read the capability data of the newly added units and merge them according to the unit type to form an updated selected force capability statistics. Perform a consistency check on the updated selected force list and the updated selected force capability statistics. The check rule is that the set of units listed in the updated selected force list is consistent with the collection range of the updated selected force capability statistics. After the check passes, bind the record. After the updated list of selected forces and the updated statistics on the capabilities of the selected forces are formed, standard demand data is extracted based on the first-battle one-click template and compared with the statistics on the capabilities of the selected forces to obtain capability gap data. When there are unit types in the capability gap data with capability gap values greater than zero, the retrieval of the reinforcement unit list is repeated. Units are selected from the candidate unit pool according to the capability gap value and the number of reinforcement requirements, and the reinforcement units are added to the updated list of selected forces and the statistics on the capabilities of the selected forces. This process is repeated until the capability gap value of all unit types is zero. The compilation and distribution module is used to compile and confirm the updated list of selected forces and issue dispatch instructions, and solidify the re-dispatch package; the re-dispatch package includes the updated list of selected forces and the updated statistical data on the capabilities of the selected forces. The compilation and distribution module includes: Step 51: Read the updated list of selected forces and determine it as the sole source of units for formation determination; perform formation determination on the units listed in the updated list of selected forces to form formation results, and determine the formation results as the sole basis for generating dispatch instructions, while maintaining the one-to-one correspondence between unit and dispatch unit codes in the formation results. Step 52: Generate a dispatch instruction based on the compilation result. The dispatch instruction includes a set of dispatch unit codes and the units corresponding to each dispatch unit code. The dispatch instruction maintains a one-to-one correspondence between the dispatch unit code and the corresponding unit. The dispatch instruction is issued and the issuance time and issuance status are recorded. The issuance time and issuance status are written into the dispatch instruction to form an issuance record. Step 53: Read the first battle one-click template, the updated selected force list, the updated selected force capability statistics and capability gap data, collect and solidify them into a re-deployment package, and establish a one-to-one correspondence record between the re-deployment package and the deployment instruction; perform consistency verification on the re-deployment package and bind the record. The verification rule is that the updated selected force list in the re-deployment package is consistent with the unit and deployment unit code set contained in the deployment instruction, and the capability gap data in the re-deployment package is consistent with the read capability gap data. After determining the minimum dispatch unit code, when generating dispatch instructions based on the compilation results, the numerical values of the dispatch unit code set contained in the dispatch instructions are compared to determine the order of the dispatch instructions. The unit corresponding to the dispatch unit code that matches the minimum dispatch unit code is determined as the first unit in the dispatch instructions, ensuring the priority dispatch order of the first unit in dispatch execution.
2. The fire and rescue command center unit-type dispatch system according to claim 1, characterized in that, After creating an event record on the command center alarm receiving interface, obtain the event location, event category, level label, and initial functional requirement label, and write them into the event record; assemble the event location, event category, level label, and initial functional requirement label into a dispatch input quadruple, and set the dispatch input quadruple to a locked state. After locking, it is forbidden to modify the event location, event category, level label, and initial functional requirement label in the dispatch input quadruple.
3. The fire and rescue command center unit-type dispatch system according to claim 1, characterized in that, Read the locked dispatch input quadruple and extract the event category and level label. Determine the first-battle one-click template in the regular dispatch scenario library based on the event category and level label, and trigger one-click dispatch based on the first-battle one-click template. Read the main combat unit type and functional unit type defined in the first-battle one-click template, determine the quantity and type of requirements corresponding to each main combat unit type, and write and solidify the main combat unit requirements and functional unit requirements into the first dispatch unit requirement list.
4. The fire and rescue command center unit-type dispatch system according to claim 1, characterized in that, Based on the event locations in the dispatch input quadruple, a candidate mechanism sequence is obtained by sorting the mechanisms by distance, and a candidate unit pool is obtained by filtering based on unit availability tri-states, including: Step 11: Read the locked dispatch input quadruple and extract the event location from the locked dispatch input quadruple. Step 12: Obtain the location corresponding to each institution, determine the institution distance based on the event location and the institution's corresponding location, and establish a one-to-one correspondence record between the institution distance and the corresponding institution. Step 13: Sort candidate organization sequence in ascending order by organization distance, obtain the unit set corresponding to each organization in sequence according to the candidate organization sequence, read the three states of unit availability and remove units in occupied and unavailable states, and gather the remaining available units to form a candidate unit pool; wherein, the unit includes main combat unit and functional unit, and the three states of unit availability include available state, occupied state, and unavailable state.