Cooperative command method, device and equipment for both flat and acute modes and medium

Abstract

Embodiments of the present disclosure disclose a method and device for coordinated command for both routine and emergency, equipment and medium. A specific implementation of the method includes: interfacing with each heterogeneous external communication system and each monitoring device to obtain a converged communication resource pool; constructing a digital plan library based on the converged communication resource pool; in response to receiving an emergency information, generating a target digital plan according to the received emergency information and the digital plan library; establishing a converged communication link based on the target digital plan; constructing a converged communication map based on the converged communication resource pool; in response to identifying that a user has performed a dispatch operation through the converged communication map, generating each dispatch instruction corresponding to the dispatch operation according to the target digital plan; and executing cross-departmental collaborative disposal based on each dispatch instruction through the converged communication link. The implementation improves the coordination and response speed of multi-department joint action, and provides a solution for building a smart city coordinated command system.

Description

Technical Field

[0001] The embodiments disclosed herein relate to the field of computer technology, and more specifically to collaborative command methods, apparatuses, devices, and media for both peacetime and emergency use. Background Technology

[0002] Collaborative command methods for both peacetime and emergency use are a key technological direction in the fields of smart cities and emergency management. Currently, the mainstream command model relies on the independent systems already established by various commissions and bureaus. During incident response, "point-to-point" instructions and force dispatch are carried out through various communication means such as telephone, walkie-talkie, instant messaging groups, and video conferencing, with regular meetings and contingency plan drills serving as the main means of capability improvement.

[0003] However, when adopting the above methods, the following technical problems often arise: Insufficient resource sharing: The communication, consultation, monitoring, and business systems of various departments are independent of each other, lacking a unified access and integration mechanism. This results in the inability to share and schedule resources such as voice, video, and data in real time across departments and levels. Inadequate monitoring and early warning, and difficulties in situational awareness: Due to the lack of unified standards in data formats, interface protocols, and presentation methods among the business systems of various functional units, massive amounts of heterogeneous data are difficult to integrate efficiently and present intuitively, failing to support comprehensive, three-dimensional, and dynamic monitoring of risks, hidden dangers, and emergencies. Inefficient command and coordination, and disconnected response and handling: Existing signal dispatching, communication transmission, and video surveillance systems often have different coverage areas, different technical standards, and are independent of each other. This results in the inability to synchronize the issuance of command instructions, the establishment of on-site communication, and the perception of real-time situational awareness, making it difficult to achieve rapid linkage and efficient handling under unified command. In addition, when applying digital contingency plans to actual combat, how to achieve rapid association and dynamic execution of contingency plans with real-time resources, geographic information, and communication capabilities also faces challenges such as rigid processes and insufficient flexibility.

[0004] The information disclosed in this background section is only intended to enhance the understanding of the background of the inventive concept, and therefore may contain information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] The summary portion of this disclosure is intended to provide a brief overview of the concepts, which will be described in detail in the detailed description portion. This summary portion is not intended to identify key or essential features of the claimed technical solutions, nor is it intended to limit the scope of the claimed technical solutions.

[0006] Some embodiments of this disclosure propose a collaborative command method, apparatus, electronic device, and computer-readable medium for both peacetime and emergency use to address one or more of the technical problems mentioned in the background section above.

[0007] In a first aspect, some embodiments of this disclosure provide a collaborative command method for both peacetime and emergency use, comprising: interfacing with various heterogeneous external communication systems and various monitoring devices to obtain a converged communication resource pool; constructing a digital contingency plan library based on the converged communication resource pool; generating a target digital contingency plan based on the received emergency information and the digital contingency plan library in response to receiving emergency information; establishing a converged communication link based on the target digital contingency plan, wherein the converged communication link is used to connect the command center, at least one on-site response party, and various related departments; constructing a converged communication map based on the converged communication resource pool, wherein the converged communication map presents various resources related to the received emergency and the spatial distribution of each resource; generating various dispatch instructions corresponding to the dispatch operation based on the target digital contingency plan in response to recognizing that a user has performed a dispatch operation through the converged communication map; and performing cross-departmental collaborative response based on the dispatch instructions through the converged communication link.

[0008] Secondly, some embodiments of this disclosure provide a collaborative command device for both peacetime and emergency use, comprising: a docking unit configured to dock with various heterogeneous external communication systems and various monitoring devices to obtain a converged communication resource pool; a first construction unit configured to construct a digital contingency plan library based on the converged communication resource pool; a first generation unit configured to generate a target digital contingency plan in response to receiving emergency information, based on the received emergency information and the digital contingency plan library; an establishment unit configured to establish a converged communication link based on the target digital contingency plan, wherein the converged communication link is used to connect a command center, at least one on-site response party, and various related departments; a second construction unit configured to construct a converged communication map based on the converged communication resource pool, wherein the converged communication map presents various resources related to the received emergency and the spatial distribution of each resource; a second generation unit configured to generate various dispatch instructions corresponding to the dispatch operation based on the target digital contingency plan in response to recognizing that a user has performed a dispatch operation through the converged communication map; and an execution unit configured to execute cross-departmental collaborative response based on the various dispatch instructions through the converged communication link.

[0009] Thirdly, some embodiments of this disclosure provide an electronic device, including: one or more processors; and a storage device having one or more programs stored thereon, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the method described in any implementation of the first aspect above.

[0010] Fourthly, some embodiments of this disclosure provide a computer-readable medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the method described in any of the implementations of the first aspect above.

[0011] Fifthly, some embodiments of this disclosure provide a computer program product, including a computer program that, when executed by a processor, implements the method described in any of the implementations of the first aspect above.

[0012] The above-mentioned technical solution of the present invention has the following beneficial effects: Through the collaborative command method of the present invention, which is designed for both normal and emergency use, it is possible to achieve integrated fusion of cross-departmental and cross-level resources, intelligent contingency plan matching, and visualized collaborative scheduling, fundamentally improving the command efficiency of routine management and emergency response. Specifically, the traditional command model relies on decentralized and independent communication and consultation systems, which may face problems such as insufficient resource sharing leading to "information silos," inconsistent data standards leading to difficulties in situational awareness, and system fragmentation leading to delayed collaborative response. If only point-to-point communication and manual coordination are relied upon, it will be difficult to quickly integrate information, accurately match contingency plans, and efficiently coordinate multiple forces in emergencies. Based on this, the collaborative command method of the present invention firstly connects various heterogeneous external communication systems and various monitoring devices to obtain a unified communication resource pool. Thus, through protocol adaptation and unified access, heterogeneous resources such as voice, wireless, video, and mobile terminals are integrated into a unified resource pool that can be scheduled on demand, breaking down departmental barriers and "information silos" from the source, laying the material foundation for subsequent unified command. Secondly, based on the above-mentioned unified communication resource pool, a digital contingency plan library is constructed. Therefore, textual and experience-based emergency plans are structured, digitized, and tagged to form a searchable, associative, and executable knowledge base. This solves the problems of slow plan searching, cumbersome content, and disconnect from actual resources in traditional plans, providing core decision-making basis for intelligent response. Next, upon receiving emergency information, the system generates a target digital plan based on the received information and the aforementioned digital plan database. Thus, the system can intelligently match and activate the most suitable emergency plan based on the type, level, and location of the event, realizing a shift from "people searching for plans" to "plans finding people," significantly shortening emergency response decision-making time. Then, based on the aforementioned target digital plan, a converged communication link is established. Based on the predefined command relationships in the plan, a communication channel connecting the command center, on-site personnel, and relevant departments is quickly constructed, ensuring that cross-level and cross-departmental instructions can be issued with one click and that communication is guaranteed to reach the recipient, solving the problem of poor coordination caused by the independent communication systems and inconsistent coverage in the traditional model. Finally, based on the aforementioned converged communication resource pool, a converged communication map is constructed. Therefore, by overlaying and rendering resources associated with the contingency plan, real-time alarm information, and geospatial information, a comprehensive three-dimensional command view is formed, enabling a holistic and intuitive grasp of resources, impact range, and response capabilities related to emergencies. This effectively overcomes the problem of incomplete situational awareness caused by data fragmentation. Subsequently, in response to the recognition that a user has performed a dispatch operation through the aforementioned converged communication map, the system generates various dispatch instructions corresponding to the aforementioned digital contingency plan. Thus, after the commander performs intuitive operations such as selecting boxes and points on the visual map, the system can automatically transform these into specific and executable dispatch instructions based on the contingency plan logic, achieving intelligent assisted decision-making with "humans in the loop," and improving the scientific nature and efficiency of command.Finally, through the aforementioned converged communication links, cross-departmental collaborative responses are executed based on the various dispatch instructions. This allows the generated instructions to be precisely and synchronously distributed to all responsible parties via the established unified communication links, driving relevant departments and resources to act collaboratively according to the contingency plan. Ultimately, this achieves an integrated, highly efficient closed-loop response from perception, decision-making, dispatching to execution. Furthermore, because this method employs a platform-based, structured, and intelligent design in core aspects such as resource integration, contingency plan management, communication establishment, situational awareness, and instruction generation, it can effectively adapt to diverse command scenarios ranging from routine planned tasks to sudden emergency events (i.e., "dual-use"). By driving the automatic association of resources and communications through digital contingency plans and enabling visualized interactive dispatching based on a single map, the coordination, response speed, and accuracy of multi-departmental joint actions are significantly improved, providing key methodological support for building a smart and efficient urban collaborative command system. Attached Figure Description

[0013] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and elements are not necessarily drawn to scale.

[0014] Figure 1 This is a flowchart of some embodiments of the collaborative command method for both peacetime and emergency use according to the present disclosure; Figure 2 These are structural schematic diagrams of some embodiments of a collaborative command device for both peacetime and emergency use according to the present disclosure. Figure 3 This is a schematic diagram of the structure of an electronic device suitable for implementing some embodiments of the present disclosure. Detailed Implementation

[0015] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0016] It should also be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings. Unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0017] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0018] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0019] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0020] This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0021] Figure 1 A flow 100 of some embodiments of a dual-use (peacetime and emergency) collaborative command method according to this disclosure is shown. This dual-use collaborative command method includes the following steps: Step 101: Connect various heterogeneous external communication systems and various monitoring devices to obtain a converged communication resource pool.

[0022] In some embodiments, the implementing entity (e.g., a computing device) of the collaborative command method for both peacetime and emergency use can interface with various heterogeneous external communication systems and various monitoring devices to obtain a converged communication resource pool.

[0023] In some optional implementations of certain embodiments, the aforementioned execution entity can obtain a converged communication resource pool by interfacing with various heterogeneous external communication systems and various monitoring devices through the following steps: Step one involves protocol adaptation processing between the voice communication system and the wireless trunking system to obtain unified signaling resources. The voice communication system can be a telephone switching network based on circuit switching or packet switching technologies, such as a program-controlled exchange in the Public Switched Telephone Network (PSTN), or a private branch exchange (PBX / IP-PBX) based on an IP network. The wireless trunking system can be a dedicated wireless communication system using dedicated frequencies and protocols to achieve group dispatch communication, such as a digital trunking system based on PDT, TETRA, or DMR standards, or an analog intercom system. Protocol adaptation processing can be a technical process of converting the proprietary signaling and control protocols of different communication systems into a unified signaling format (such as the SIP protocol) within the system through software or hardware gateways. Unified signaling resources can be a set of logical communication entities with unified identifiers, status attributes, and call control interfaces, abstracted within the system after the above protocol adaptation processing. In practice, the above-mentioned execution entity can call or run a dedicated protocol gateway (in software or hardware form) to implement protocol adaptation processing. For example, for traditional voice communication systems (PBX / IP-PBX), the gateway can interconnect via analog trunks (E&M), digital trunks (E1), or SIP trunks, converting received call control signaling (such as off-hook, on-hook, and number) into an internally unified Session Initiation Protocol (SIP) message. For wireless trunking systems (such as PDT and TETRA), the gateway can interface with the trunking system's dispatch console interface or wireless switch interface to receive call, status, and location information from wireless terminals, similarly converting it into an internally unified signaling format. Finally, all communication endpoints that have completed protocol conversion are registered in the system's resource management service (or resource catalog service), forming a unified signaling resource pool. Each resource has a unique ID, type, real-time status, and controllable signaling interface. For example, in a typical command center deployment, the protocol adaptation gateway successfully interconnected with the Huawei eSpace U1980 IP-PBX and PD780 digital trunking system. On the system interface, the dispatcher at the command center can see 100 extension numbers from the government intranet and 200 handheld terminals from the 350MHz wireless network, all presented in a unified “voice terminal” icon and list format, and can perform unified calls, monitoring, or forced insertion operations on them.

[0024] Step two involves performing national standard access processing on each video surveillance device to obtain standardized video resources. The video surveillance devices can be physical devices or systems used for acquiring, encoding, and transmitting video and related information, such as network cameras (IPCs), network video recorders (NVRs), or video surveillance management platforms. National standard access processing follows the signaling and media stream interaction procedures specified in the People's Republic of China National Standard GB / T 28181 "Technical Requirements for Information Transmission, Exchange, and Control of Security Video Surveillance Network Systems," achieving interconnection and interoperability with the aforementioned devices or platforms. Standardized video resources are logical video source objects that, after the national standard access processing, possess a unified encoding format, standard streaming media transmission protocols (such as RTP / RTSP over PS), and standardized control interfaces (such as PTZ control and video playback). In practice, the aforementioned execution entity can have a built-in or external network gateway conforming to the GB / T 28181 standard. This gateway can act as a national standard client, registering with and subscribing to device directories on various video surveillance platforms (acting as national standard servers). When video needs to be accessed, the gateway sends a standard real-time video-on-demand (INVITE) message to the target platform to negotiate media transmission parameters and receives standard-encapsulated audio and video streams (such as PS over RTP) from the platform. Simultaneously, the gateway can convert PTZ control commands into standard device control messages for distribution. Through this process, video streams from different manufacturers and platforms are converted into a unified format and access method, forming standardized video resources that can be played and controlled by upper-layer applications such as video playback components and dispatch console interfaces through a unified API. For example, the system connects to a video sharing platform and a traffic police road monitoring platform through a national standard gateway. Although the two platforms are built by different manufacturers, the commander can directly preview traffic police cameras at the "Zhongshan Road-Jiefang Road intersection" and security cameras at the "South Square of the Railway Station" through a unified video resource tree within the system. The commander can also perform unified left-right rotation and zoom-in / out control on PTZ-enabled cameras, and all video streams are presented in H.264 encoded format within the system.

[0025] Step 3 involves access processing for portable mobile terminals and vehicle-mounted terminals to obtain controllable mobile resources. Portable mobile terminals can be smart devices that are easy for a single person to carry and possess wireless communication and information processing capabilities, such as smartphones, law enforcement recorders, or dedicated individual soldier image transmission devices. Vehicle-mounted terminals can be devices fixedly installed in vehicles, integrating communication, positioning, and computing functions. Access processing refers to the process by which the aforementioned terminal devices initiate registration with the system core via a wireless network, establish a stable signaling connection, and report their own status and capability information. Controllable mobile resources are the logical representation of a terminal that, after successfully completing the above access processing, can be uniquely identified in the system's global view, has its status tracked in real time (e.g., online, location), and can receive remote dispatch instructions (e.g., audio / video calls, task assignment). In practice, the aforementioned executing entity can deploy a mobile access gateway. After startup, the dedicated APP installed on the terminal device or the communication components pre-installed in the device firmware initiate a registration request to the gateway via the operator's network (4G / 5G) or Wi-Fi network, reporting its device serial number, user identity, current location, supported media capabilities, and other information. After authenticating the terminal, the gateway assigns it a logical identifier (ID) within the system and maintains a persistent heartbeat or long connection for monitoring the terminal's online status, issuing commands (such as initiating voice / video calls and assigning tasks), and receiving information reported by the terminal (such as new locations, emergency alarms, and task feedback). All successfully registered terminals are included in the controllable mobile resource list, and their status, location, and capability information are updated in real time. For example, the individual image transmission equipment of the fire brigade, the smart law enforcement terminals of urban management officers, and the vehicle-mounted tablets on 120 ambulances automatically connect to the command system after being powered on. On the system's "Mobile Resources" panel, you can see icons of 50 individual firefighters, 100 urban management terminals, and 30 ambulances moving on the map in real time. Clicking on any icon allows you to view its detailed information and initiate a video call or issue a text command with one click.

[0026] Step four involves aggregating the aforementioned unified signaling resources, standardized video resources, and controllable mobile resources to obtain a converged communication resource pool. This aggregation process is a centralized management process for collecting, integrating, cataloging, and synchronizing the status of resource information from different sources and of different types. The converged communication resource pool is a logically unified resource repository formed after the aggregation process, encompassing various heterogeneous communication and sensing capabilities such as voice signaling, video streams, and mobile terminals, and providing consistent resource discovery, status query, and capability invocation interfaces for upper-layer applications. In practice, the aforementioned execution entities can perform the aggregation process through a centralized resource management service. This service synchronizes the static attributes (such as ID, name, type, and ownership) and dynamic status (such as online / offline, busy / idle, and location) of all resources periodically or in real-time from subsystems such as protocol adaptation gateways, national standard network gateways, and mobile access gateways. The service formats this information according to a unified resource data model, stores it in a resource catalog database, and establishes a global index. Simultaneously, this service provides unified resource query, status subscription, and capability invocation interfaces. Upper-layer applications (such as command and dispatch consoles) do not need to be aware of the underlying technical differences in resources. They can discover, view, and dispatch any voice, video, or mobile terminal resources through this unified interface, thus forming a logically fully integrated communication resource pool. For example, the resource management service aggregates information from 100 government telephones, 200 wireless terminals, 5,000 video surveillance feeds, and 180 mobile terminals accessed in the aforementioned steps. When a commander is handling a bridge traffic accident, they can use a search box on the dispatch console to simultaneously find four surveillance cameras near the accident site, three walkie-talkie numbers from the local traffic police squadron, two patrolling urban management vehicles, and a nearby fire and rescue team. They can also simultaneously pull these resources from completely different systems into a temporary collaborative response group for unified command, achieving true converged communication dispatch.

[0027] Step 102: Construct a digital contingency plan library based on the converged communication resource pool.

[0028] In some embodiments, the aforementioned implementing entity may construct a digital contingency plan library based on the aforementioned converged communication resource pool.

[0029] In some optional implementations of certain embodiments, the aforementioned execution entity may construct a digital contingency plan library based on the aforementioned converged communication resource pool through the following steps: Step one involves template-based processing of the pre-defined emergency incident classification system to obtain various structured contingency plan templates. The pre-defined emergency incident classification system can be a framework for event categories and levels predefined according to national or industry standards (such as the "National General Emergency Response Plan for Public Emergencies"). For example, primary categories may include natural disasters, accidents, public health emergencies, and social security incidents; each primary category can be further divided into secondary and tertiary subcategories (such as natural disasters - meteorological disasters - rainstorms and floods). Template-based processing involves creating a corresponding digital contingency plan skeleton or framework based on each specific event category in the above classification system, using software tools or a configuration interface. Structured contingency plan templates are digital document frameworks generated through the aforementioned template processing, targeting a specific type or event, and containing a series of predefined fields, logical relationships, and content structures. For example, a contingency plan template for a "hazardous chemical road transport leak accident" can have a fixed structure including main chapters such as "Event Scenario Description," "Emergency Command Organization and Responsibilities," "Monitoring and Early Warning Mechanism," "Emergency Response Process (including tiered response)," "Emergency Resource Support List," and "Post-Incident Handling." Each chapter contains several standardized data fields (such as the "Commander" field and the "Emergency Team" list field) and logical relationship definitions (such as "When the event level is Level II, automatically associate the second emergency team"). In practice, the implementing entities can perform template processing through a contingency plan template management service (or template design function). This service (or function) provides a graphical or form-based template designer, allowing administrators or contingency plan development experts to design a dedicated contingency plan structure for each type of event based on a preset classification system. The design process may include: defining the chapter tree of the contingency plan document, adding standardized text input boxes, drop-down selection boxes, personnel / resource association lists, and other controls to each chapter, and setting logical jumps or conditional display rules between chapters. The completed template is saved in a structured data format (such as XML, JSON, or stored in a specific database table), forming a structured contingency plan template library that can be used when developing specific contingency plans. For example, for an emergency such as "urban flooding," the administrator creates a structured contingency plan template in the template designer. The template predefines the following mandatory sections: 1) Event characteristics (including fields such as "flood depth threshold" and "estimated impact range"); 2) Command system (including an expandable list of "command center members", each associated with the name, position, contact number, and terminal ID in the converged communication resource pool); 3) Emergency response (including four sub-sections: "Level IV", "Level III", "Level II", and "Level I", each sub-section defining the handling procedures and resource types to be dispatched at that level); 4) Resource support (including a list of "materials and equipment", each of which can be associated with specific material warehouses, drainage vehicles, or equipment information in the converged communication resource pool).This template is a "structured contingency plan template".

[0030] Step two involves extracting elements from historical emergency plans and pre-prepared text plans to obtain digitized plan elements. Historical emergency plans can be previously prepared emergency plan documents (e.g., Word, PDF) that have been practiced or tested in real-world scenarios. Pre-prepared text plans can be draft emergency plans in text format, prepared based on the latest situation but not yet digitized. Element extraction involves automatically or semi-automatically identifying and extracting key information entities from these text plans using Natural Language Processing (NLP) technology, rule matching, or manual annotation. Digitized plan elements are structured plan information units obtained through the element extraction process; for example, elements extracted from the text such as "name of emergency command organization," "name and phone number of responsible person," "name and quantity of key emergency resources (e.g., a rescue team, a material warehouse)," "description of key handling steps," and "warning signal level and issuance conditions." Each element can include a type label, confidence level, and its location in the original document. In practice, the implementing entities can use an intelligent plan element extraction engine to perform element extraction. This engine can load OCR (Optical Character Recognition) processing functions (or OCR components) to process scanned documents and utilize NLP models for text analysis. First, the emergency plan document is parsed to obtain plain text. Then, using a pre-trained Named Entity Recognition (NER) model or rule-based keyword matching, entities such as names of people, organizations, places, materials, numbers, and times are identified in the text. Next, through relation extraction or document structure analysis, these entities are categorized into predefined element categories (such as "commanders," "emergency teams," "materials and equipment," and "response actions"). For parts that cannot be automatically and accurately identified, the system provides an interactive interface for compilers to manually check, correct, and supplement annotations. Finally, all extracted elements are converted into structured data objects (such as key-value pairs and lists) and stored as digital emergency plan elements. For example, the system imports a historical PDF document titled "Metro Fire Emergency Plan." The element extraction engine identified information in the text such as "On-site Commander: Zhang Xiaolin (Duty Leader, Phone 138xxxx)," "Evacuation Team: 10 Passenger Service Staff, 15 Security Guards," "Required Resources: 50 Fire Extinguishers, 200 Smoke Masks," and "Issuance of a Line-wide Shutdown Order," and categorized and labeled them as "Commander Element (Zhang Xiaolin, Role: On-site Commander)," "Emergency Team Element (Passenger Service Staff, Quantity: 10)," "Materials and Equipment Element (Fire Extinguishers, Quantity: 50, Location: Inside the Station)," and "Key Response Action Element (Issuance of a Line-wide Shutdown Order)." This structured set of information constitutes the digital emergency plan elements.

[0031] Step three involves digitally editing the structured contingency plan templates and digital contingency plan elements to obtain executable digital contingency plans. This digital editing process involves filling in, associating, validating, and integrating the digital contingency plan elements extracted in step two according to the framework and format of the structured contingency plan templates determined in step one, thereby generating a complete, machine-readable, and parsable digital contingency plan document. An executable digital contingency plan is a structured contingency plan data object generated after the digital editing process. It not only contains the entire text content of the contingency plan (stored in a structured form), but more importantly, its key entities (such as personnel, resources, and response steps) have established computable associations with dynamic data such as the integrated communication resource pool, organizational structure, and geographic information in the system, enabling the contingency plan to automatically associate and schedule actual resources and personnel upon activation. In practice, the aforementioned implementing entity can provide a visual contingency plan digital editing platform. The editor first selects a structured contingency plan template from the template library that matches the event type of the contingency plan to be edited. The platform presents the template in the form of a form or outline view. Then, editors can fill the corresponding fields and positions of the template with the digital contingency plan elements extracted in step two by dragging, selecting, or mapping. For example, by associating the extracted "command personnel element" with the "command center members" list under the "command system" section of the template, the system will automatically query and bind the personnel's contact phone number, walkie-talkie ID, and other communication resources from the integrated communication resource pool. Similarly, "emergency team elements" and "materials and equipment elements" can be associated with the corresponding positions in the template and linked to the actual teams and material inventory records in the resource pool. Editors can also supplement details not covered in the template or adjust the logic. After the editing is completed, the system saves the entire contingency plan as a structured data package, such as a document containing multiple JSON objects (corresponding to each chapter), which references the IDs, user IDs, etc. of the resource pool objects, forming an executable digital contingency plan. For example, editors can select the structured contingency plan template for "subway fire" and fill in the elements extracted from historical contingency plans. In the "command system" section, the system automatically associates "Zhang Xiaolin" with the government mobile phone and individual soldier equipment IDs under his name in the resource pool. In the "Resource Support" section, the "50 fire extinguishers" are linked to the subway station fire extinguisher inventory records in the asset management system. The resulting executable digital contingency plan is not just an electronic document, but also an action blueprint containing data linkages. When the plan is activated, the system can automatically send instructions to Zhang Xiaolin's mobile phone and individual soldiers based on these linkages, and check the real-time availability of fire extinguishers.

[0032] Step four involves classifying the aforementioned executable digital contingency plans to obtain a digital contingency plan library. Classification can be achieved by adding one or more category tags to each executable digital contingency plan based on its metadata attributes (such as event type, applicable region, drafting unit, version number, effective date, etc.), and storing and indexing it according to a predetermined organizational structure (such as a tree directory or tag cloud). The digital contingency plan library is a data set or database system that stores all classified executable digital contingency plans and provides fast retrieval, version management, and access control based on category tags, keywords, spatial scope, and other methods. In practice, the implementing entities can perform classification processing through the contingency plan library management service (or classification and version management functions). Whenever an executable digital contingency plan is revised and saved, the system automatically extracts its category tags based on the plan content, or the drafter manually assigns them. These tags are typically based on a preset emergency event classification system (such as the system used in Step one) and may be expanded to include dimensions such as administrative region, industry sector, and risk level. All contingency plans, along with their metadata and classification tags, are stored in a central database (such as a relational database or document database). The database uses efficient indexes to support multi-condition queries. This service (or function) also provides version management for the plans, tracking their revision history. The resulting digital contingency plan library provides the foundation for the command system to quickly retrieve, match, and activate the most relevant plans based on event information (type, location) when an emergency occurs. For example, when the system saves the revised "XX City Metro Fire Emergency Response Plan (V2.0)," it automatically tags it with categories such as "Accident / Disaster - Public Transportation - Fire," "Applicable Area: XX City Rail Transit Network," and "Prepared by: Municipal Transportation Commission, Metro Group." Simultaneously, another plan, "XX District Flood and Typhoon Prevention Emergency Response Plan," is tagged with "Natural Disaster - Meteorological Disaster - Typhoon and Rainstorm" and "Applicable Area: XX District." All these plans, along with their tags, are stored in the contingency plan database. When the command center receives an alarm about a suspected fire at a station on Metro Line 1, the system can quickly search and highlight the "XX City Metro Fire Emergency Response Plan (V2.0)" in the digital emergency plan database based on keywords such as "accident disaster", "fire", "XX city", and "metro", so that the commander can make a decision to activate it.

[0033] Step 103: In response to receiving emergency information, generate a target digital emergency plan based on the received emergency information and the digital emergency plan database.

[0034] In some embodiments, the aforementioned implementing entity may generate a target digital contingency plan based on the received emergency information and the aforementioned digital contingency plan database.

[0035] In some optional implementations of certain embodiments, the aforementioned implementing entity can generate a target digital contingency plan based on the received emergency information and the aforementioned digital contingency plan library through the following steps: Step 1 involves performing feature recognition processing on the received emergency information to obtain type, level, and location information. The emergency information can be preliminary descriptive data about the emergency reported from 110 / 119 / 120 emergency call systems, city operation management platforms, online public opinion monitoring systems, IoT sensors, or other information channels. This data can be structured (e.g., alarm work orders with fixed fields), semi-structured (e.g., SMS or WeChat messages), or unstructured text (e.g., brief descriptions entered by dispatchers). Feature recognition processing can utilize technologies such as natural language processing, regular expression matching, keyword extraction, or geocoding services to automatically or semi-automatically parse and extract key features representing the nature, severity, and location of the event from the above information. Type information can be an identifier representing the category to which the emergency belongs, such as "fire," "traffic accident," "mass incident," or "gas leak," which can correspond to the emergency classification system preset in Step 102. The level information can be the initial assessment of the urgency or scope of impact based on preset rules, such as "General (Level IV)," "Significant (Level III)," "Major (Level II)," and "Extremely Major (Level I)." Location information can be a specific or approximate description of the event's geographical location, such as latitude and longitude coordinates, a specific address (e.g., "No. XX, XX Road"), landmark building names, or administrative divisions (e.g., "XX District, XX Street"). In practice, the aforementioned implementing entity can deploy an information feature extraction service (or information feature extraction function). Upon receiving information about an emergency, this service (or function) first performs standardized preprocessing (e.g., encoding conversion, removal of irrelevant characters). For text information, the service loads a pre-trained natural language processing model (such as a BERT-based text classification and named entity recognition model) to perform word segmentation, part-of-speech tagging, and syntactic analysis on the text. It identifies keywords or phrases describing the event type and maps them to standard event type codes. Simultaneously, it identifies keywords describing casualties, losses, and the scope of impact, and preliminarily determines the event level based on a built-in hierarchical rule base (e.g., "more than 10 deaths" corresponds to Level I, "3-10 deaths" corresponds to Level II, etc.). For location descriptions, the service extracts address fragments using regular expressions and calls address parsing (reverse geocoding) APIs provided by Amap or Baidu Maps to convert the text address into standard latitude and longitude coordinates. For structured work orders, it directly reads the corresponding field values. For example, the emergency call center forwards a text message: "A citizen reported that a multi-vehicle rear-end collision occurred at the Guomao Bridge on Jianguomenwai Street in Chaoyang District, heading west. Vehicles are on fire, people are injured and trapped, and traffic is severely congested."After feature recognition processing, the type information is obtained as "traffic accident (subclass: road traffic accident - rear-end collision - fire)". Based on the keywords "vehicle fire, people injured and trapped", the level information is initially determined to be "major (level III)". The location information is obtained by address parsing, which yields the latitude and longitude coordinates (e.g., 116.46, 39.91) and the structured address "east to west direction under Guomao Bridge, Jianguomenwai Street, Chaoyang District, Beijing".

[0036] Step two involves performing a preliminary search on the digital emergency response plan database based on the aforementioned type and level information to obtain candidate digital emergency response plans. This preliminary search can be a process of matching and searching the digital emergency response plan database using the type and level information extracted in step one as query conditions. This process aims to quickly narrow down the selection of plans and return a batch of basic plans related in terms of event type and response level. Candidate digital emergency response plans can be a set of one or more executable digital emergency response plans obtained through the preliminary search that match the query conditions (type, level). In practice, the implementing entities can utilize the classification index (such as a tag index or inverted index based on event type and level) established in the digital emergency response plan database to perform efficient searches. The system converts the type and level information into corresponding classification tags or codes as query keys. The search process can support both exact and fuzzy matching. For example, for the "traffic accident-rear-end collision-fire" type, the system may precisely match the "Road Traffic Accident Emergency Rescue Plan" or fuzzily match a higher-level "General Traffic Accident Emergency Plan" or a "Hazardous Chemical Transportation Accident Emergency Plan" containing fire handling points. The search results (candidate contingency plans) are initially sorted according to their matching degree with the query conditions (such as the accuracy of type matching and the coverage of level). For example, after receiving information about an emergency with the type "hazardous chemical vehicle leak" and the level "Level II", the system searches the contingency plan database using "hazardous chemicals" and "leak" as keywords, combined with the "Level II (Major)" level tag. The search results may return several contingency plans, such as the "Special Emergency Response Plan for Road Transport Accidents of Hazardous Chemicals (Major Level)", the "Emergency Response Guidelines for Hazardous Chemical Leak Accidents", and the "Emergency Response Plan for Environmental Pollution Incidents", which together constitute the candidate digital contingency plan set.

[0037] Step 3: Obtain real-time resource status information. This real-time resource status information can be data on the current availability and status of various resources required for contingency plan execution, obtained in real-time from the integrated communication resource pool established in Step 101. These resources may include, but are not limited to: the deployment status (standby, deployed, in operation) of emergency teams (such as fire brigades and medical rescue teams); the inventory quantity and location of key equipment and materials (such as special rescue equipment, protective gear, and medicines); the online status and battery level of emergency communication terminals (such as command vehicles, individual soldiers, and satellite phones); the capacity and openness of emergency shelters; and the contactability status of relevant expert personnel. In practice, the implementing entities can obtain this information by calling the real-time status query interface provided by the integrated communication resource pool management service. When contingency plan optimization and evaluation are required, the system initiates a batch query request to the resource pool management service, listing the resource types or specific resource IDs that may need to be scheduled (which can be parsed from candidate contingency plans). The resource pool management service queries its maintained real-time status database and returns the current status of each resource (e.g., online / offline, idle / busy, sufficient / insufficient quantity), geographical location, and other key attributes (e.g., estimated arrival time, capability level). This information is dynamically changing and provides crucial evidence for assessing the "executability" of contingency plans. For example, to assess a chemical spill emergency plan, the system queries the resource pool for the real-time status of resources such as "Chemical Defense Firefighting Brigade," "Heavy Chemical Protective Suits," "Toxic Gas Detectors," "Decontamination Tents," and "Relevant Experts." The returned information shows: the First Chemical Defense Brigade is "in training" (ready for emergency deployment), the inventory of heavy chemical protective suits is "sufficient," a certain type of detector has "partial equipment malfunctions," the decontamination tents have been "deployed to other sites," and Professor Wang, the expert, can be contacted by phone. This constitutes the real-time status information of the resources at the current moment.

[0038] Step four involves optimizing and evaluating each candidate digital contingency plan based on the aforementioned location information and the acquired real-time resource status information, resulting in an optimized contingency plan sequence. This optimization and evaluation process can be a multi-factor comprehensive scoring and ranking algorithm. It utilizes the location information of the event and the real-time resource status information to quantitatively evaluate the "contextual suitability" of each candidate digital contingency plan obtained in step two. Evaluation dimensions may include: 1) Resource accessibility: the spatial distance or estimated arrival time between the current location of the resources (teams, equipment) required in the plan and the event site; 2) Resource availability: the degree of matching between the type and quantity of resources required by the plan and the actual available resources in the real-time status information; 3) Plan completeness: the completeness of the plan's structure, the clarity of its steps, and the accuracy of information association (based on historical initiation records). The optimized contingency plan sequence can be a list of candidate contingency plans ranked from highest to lowest based on their comprehensive scores after evaluation and scoring. The top-ranked contingency plans are considered superior and more feasible under the current spatiotemporal and resource constraints. In practice, the implementing entity can run a contingency plan intelligent recommendation engine to perform the optimization evaluation. The engine creates an evaluation context for each candidate contingency plan. First, it parses the list of associated key resources (personnel, teams, supplies, equipment, etc.) from the candidate plans. Then, for each resource, it calculates a "resource matching score" by combining location information (event location) and real-time resource status information (current location and status). For example, it calculates the geographical distance between the rescue team's base and the event point, and combines this with its current status (whether it is dispatchable) to obtain a score; it queries the distance and quantity of supplies stored between the location and the event point to obtain another score. Next, the engine uses a predefined weighting model (e.g., resource accessibility weight 0.4, availability weight 0.4, and plan quality weight 0.2) to weight and sum all resource matching scores for each candidate plan, resulting in a total "context suitability score." Finally, all candidate plans are sorted in descending order of this total score to generate an optimized plan sequence. For example, for the aforementioned hazardous chemical leak accident, both candidate plans A and B are applicable. Contingency Plan A requires mobilizing the "Municipal Chemical Defense and Rescue Brigade" and "Special Decontamination Vehicles," while Contingency Plan B requires mobilizing the "Dedicated Fire Brigade of a Chemical Plant in a Neighboring District" and "General Decontamination Equipment." The optimization assessment engine calculation reveals that the "Municipal Chemical Defense and Rescue Brigade" is currently 20 kilometers from the site and on standby, while the "Dedicated Fire Brigade of a Chemical Plant in a Neighboring District" is only 5 kilometers away but is conducting drills within the plant. The special decontamination vehicles are on duty elsewhere, while general decontamination equipment is sufficient within the district. After comprehensive calculation, Contingency Plan B, due to its closer overall resource proximity and better availability combination, is likely to receive a higher scenario fit score than Contingency Plan A, thus ranking higher in the optimized contingency plan sequence.

[0039] Step five involves processing the optimized contingency plan sequence to obtain the target digital contingency plan. This decision-making process involves selecting a single contingency plan from the optimized sequence as the authoritative basis for handling the current emergency. The decision can be based on automated rules (e.g., directly selecting the top-ranked plan) or incorporate manual confirmation (e.g., pushing the top N plans to the commander for final decision). The target digital contingency plan is a specific, executable digital plan selected after the decision-making process. It serves as the core input and action blueprint for subsequent steps (e.g., establishing communication links, map presentation, and command generation). In practice, the implementing entity can clearly display the optimized contingency plan sequence (e.g., the top 3) and its key evaluation information (e.g., total score, resource matching details) to the commander on a user interface (e.g., the command center screen or commander's terminal). The system provides a quick "one-click activation of the top-ranked plan" option, while also allowing the commander to view and compare details of each plan and manually select or fine-tune a plan before confirming its activation. The commander's confirmation (or the automatic selection rule set by the system) completes the contingency plan decision-making process. The selected contingency plan is locked as the "target digital contingency plan" for the current event, and the system loads it into memory. All its associated structured information, resource links, and handling procedures are activated, ready to drive subsequent command and dispatch actions. For example, the system pushes the optimized contingency plan sequence for a hazardous chemical leak accident (Plan B scores 85, Plan A scores 78) to the duty commander. The commander quickly reviews the brief information and resource scheduling list of Plan B, deems it conforms to the principle of "rapid initial response" on site, and clicks the "Start" button next to Plan B on the screen. Plan B is then identified as the target digital contingency plan by the system. The system interface automatically switches, begins the process based on Plan B, recommends establishing communication links, plotting associated resource points on the map, and prepares to generate initial dispatch instructions.

[0040] Step 104: Establish a converged communication link based on the target digital contingency plan.

[0041] In some embodiments, the aforementioned implementing entity can establish a converged communication link based on the aforementioned target digital contingency plan. This converged communication link can be a virtual communication channel that is logically unified at the communication session level and supports the transmission of multiple media types (such as voice, video, and data). The establishment of this link can be based on the predefined command relationship diagram, emergency organization structure, and associated communication resource identification information in the aforementioned target digital contingency plan. Its core function is to instantiate the abstract command relationships (such as "commander-in-chief," "on-site command group," "medical rescue group," and "transportation support group") in the contingency plan into a collaborative network capable of real-time, two-way, and multi-mode communication by invoking the actual communication capabilities in the converged communication resource pool constructed in step 101. This connects the command center (usually serving as the core node for dispatch), at least one on-site responder (such as the head of the first arriving rescue team and their associated terminal), and various related departments (such as the coordinating units specified in the contingency plan, such as fire, medical, and transportation departments). In practice, the aforementioned implementing entity can analyze the aforementioned digital contingency plan to extract the command structure and personnel or unit information associated with each role. Then, based on this information, it can query the aforementioned converged communication resource pool to obtain the identifier and access parameters of one or more specific communication terminals corresponding to each role (e.g., the SIP account of the command center dispatch console, the individual equipment ID of the on-site fire commander, the IP phone number of the hospital emergency office, the video conferencing system terminal number of the traffic police command room, etc.). Next, the implementing entity can use its internal session control and media exchange functions to simultaneously or sequentially initiate calls, invitations, or requests to join sessions to these terminals, and configure session attributes according to the contingency plan requirements (e.g., whether to enable video, whether to record audio or video, whether to set speaking priority, etc.), thereby establishing a shared, multi-party communication session among all invited terminals. This session constitutes the aforementioned converged communication link. Once this link is established, authorized personnel from the command center, on-site response teams, and related departments can access the same communication context through their respective terminal devices (such as large dispatch console screens, individual handheld screens, mobile apps, computer soft terminals, and physical phones) to conduct clear voice conversations, video conferences, screen sharing, and command confirmations. This achieves seamless communication integration across departments, regions, and terminal types. For example, when activating a digital emergency plan targeting "high-rise building fires," the plan defines the "on-site command center" members as including the fire commander, the on-site supervisor, and building property engineers. After system parsing, it retrieves the following information from the resource pool: the 4G individual image transmission device bound to the fire commander, the police mobile app account used by the supervisor, the government WeChat ID of the property engineer, and the soft terminal information of the command center's fixed seats. The system then initiates group calls or creates video conference rooms for these four terminals, successfully establishing a unified communication link.Afterwards, the command center operator can see the real-time fire scene transmitted by individual soldiers on the large screen, and at the same time conduct multi-party voice communication with the person in charge of the handheld communication device and the property engineer participating in the call via mobile phone to discuss the rescue plan, thus realizing rapid communication connection between the command and control of the emergency plan.

[0042] Step 105: Construct a converged communication map based on the converged communication resource pool.

[0043] In some embodiments, the aforementioned implementing entity may construct a converged communication map based on the aforementioned converged communication resource pool.

[0044] In some optional implementations of certain embodiments, the aforementioned execution entity may construct a converged communication map based on the aforementioned converged communication resource pool through the following steps: Step one: In the aforementioned converged communication resource pool, filter the resources related to the received emergency to obtain an initial target resource set, wherein the initial target resource set includes the resources associated with the aforementioned target digitization plan. The filtering can be a process of matching and selecting from the full resources of the converged communication resource pool based on the event's location information (from step 103), type information, and the resource list explicitly specified in the aforementioned target digitization plan. The initial target resource set can be a subset of resources obtained through screening. It contains resources that are theoretically most relevant to the handling of the current event. Its composition may include: 1) Resources directly related to the plan, i.e., specific personnel, teams, equipment, vehicles, etc., structured and bound in the "Resource Support" or "Emergency Force" sections of the target digital plan; 2) Spatially proximate resources, i.e., video surveillance points and mobile terminals (such as patrol vehicles, individual soldiers), which, although not explicitly listed in the plan, are available for dispatch within a certain geographical radius (e.g., 5 km, 10 km) based on the event location; 3) Functionally related resources, i.e., specific functional resources (such as fire hydrant locations, mini fire stations, members of the hazardous chemicals expert database) selected based on the event type (e.g., fire). In practice, the aforementioned implementing entity can run a resource intelligent screening engine. This engine receives the event location, type, and the activated target digital plan obtained in step 103 as input. First, the engine parses the plan and extracts its structured resource list. Then, the engine initiates a composite query to the converged communication resource pool: Query 1 requests all resources whose resource IDs match the contingency plan resource list; Query 2 requests all resources whose geographical location is less than a preset threshold from the event point; Query 3 requests all resources whose resource tags or type attributes match event type keywords (such as "firefighting" or "medical"). The engine deduplicates and merges the query results to form an initial target resource set. This set may contain hundreds or even thousands of resource entries, each with its detailed attributes. For example, for a "toxic gas leak" incident occurring in the "South Zone of the Chemical Industrial Park," the system activates the corresponding special contingency plan. The resource filtering engine first extracts bound resources such as "Park Emergency Team," "Environmental Monitoring Vehicle," and "Decontamination Station" from the contingency plan. Then, with the leak point as the center and a radius of 5 kilometers, it filters out all locations of "video surveillance cameras," "air monitoring stations," and "enterprise dedicated fire brigades" within this area. At the same time, based on the "toxic gas" type, it additionally filters out resources in the resource pool marked as "chemical protection experts," "heavy chemical protective suit warehouses," and "ambulances." All these resources together constitute the initial target resource set.

[0045] Step two involves performing availability checks on the initial target resource set to obtain an available resource set. This availability check involves querying the current real-time operating status and capabilities of each resource in the initial target resource set to determine if it is ready for immediate scheduling or use. The check dimensions can include: communication online status (e.g., whether video equipment is connectable, whether communication terminals are online), resource entity status (e.g., whether rescue teams are "on standby" rather than "on mission," whether emergency vehicles are "idle," whether material inventory is greater than zero), and functional integrity (e.g., whether equipment is reported for repair, whether sensor data is continuously updated). The available resource set is the set of resources that have been confirmed to be currently available after the availability check, by removing all unavailable resources. In practice, the executing entity performs the checks by calling the batch status query interface provided by the converged communication resource pool management service. The system sends the initial target resource set as a query list to the resource pool. The resource pool management service returns detailed real-time status for each resource in the list. The system determines availability based on predefined availability rules: for example, for video surveillance resources, a status of "online" and a reported stream within the last minute indicate availability; for mobile terminals, a status of "online" and a battery level above 20% indicate availability; and for rescue teams, a status of "standby" indicates availability. If any critical status is not met, the resource is marked as "unavailable" and filtered out from the current set. The final result is the available resource set. For example, in a chemical gas leak case, the initial target resource set contained 50 video surveillance feeds. Availability testing revealed that 8 feeds were offline due to network failure, and 2 were undergoing upgrades and maintenance. Meanwhile, the "Park Emergency Team" linked to the contingency plan was in "drill mode," but according to the rules, it could be interrupted urgently, so it was considered available; however, the GPS of an "Environmental Monitoring Vehicle" showed it was performing a mission in another area, so it was considered unavailable. Ultimately, 42 video feeds, the park emergency team, and other available resources constituted the available resource set.

[0046] Step 3: Extract the geospatial information of each resource in the available resource set to obtain a resource coordinate dataset. Extraction can be the process of reading pre-stored or real-time reported coordinate data from the attribute fields of each resource object in the available resource set. The resource coordinate dataset can be a structured collection of data containing the location information of all available resources, such as a list or table, where each record contains a resource ID, resource name, resource type, and corresponding latitude and longitude coordinates. In practice, the execution entity can iterate through the available resource set. For each resource object, the "latitude" and "longitude" fields are read from its attributes. For mobile resources (such as vehicles or soldiers), their coordinates are dynamically changing, and the system reads their latest reported GPS location. For fixed resources, their coordinates are pre-entered static data. All read coordinate information is organized and formatted into a standard dataset for use by the subsequent map rendering engine. The system also performs validity checks on the coordinates, such as checking whether they are within a reasonable latitude and longitude range. For example, available resources include: a fire station (coordinates: 39.456°N, 116.123°E), an emergency warehouse (coordinates: 39.460°N, 116.130°E), a mobile command vehicle (latest coordinates: 39.458°N, 116.125°E), and expert Zhang San (mobile phone location: 39.452°N, 116.128°E). The extraction process retrieves these coordinates one by one, forming a resource coordinate dataset. This dataset contains multiple records, each representing a resource and its location. For example, one record represents resource ID f1, name "XX Fire Station," type "Team," latitude 39.456, longitude 116.123; another record represents resource ID w1, name "Emergency Warehouse No. 3," type "Supplies Point," latitude 39.460, longitude 116.130; and so on.

[0047] Step four: Based on the aforementioned resource coordinate dataset, render the base map to obtain the basic resource distribution layer. The base map can be an electronic map provided by a professional map service (such as Tianditu, Gaode Map, or ArcGIS), containing basic geographic elements such as roads, buildings, water systems, and administrative divisions. Rendering involves drawing each coordinate point in the resource coordinate dataset, according to its resource type, using specific graphic symbols (icons), colors, and sizes, onto the corresponding location on the base map. The basic resource distribution layer can be a transparent graphic layer or map layer overlaid on the base map, specifically displaying the spatial distribution of resources. In practice, the above execution entity can be integrated with a map rendering engine (such as Leaflet, Mapbox GL JS, or a professional GIS client). The system first loads the base map. Then, the resource coordinate dataset is passed to the rendering engine. The engine generates and places icons (markers) at the corresponding latitude and longitude locations according to preset style configurations (e.g., red fire hydrant icons for fire-fighting resources, green cross icons for medical resources, and blue camera icons for video resources). Additionally, interactive features can be added to the icons, such as displaying the resource name and status when the mouse hovers over them. All icons together form an interactive resource distribution layer overlaid on the base map. For example, on a map of a chemical leak incident, the rendering engine draws red fire truck icons at the fire station coordinates around the leak point (incident location), orange warehouse icons at the emergency warehouse, and blue camera icons at each available video surveillance point. These icons clearly and intuitively demonstrate the distribution of emergency forces, supplies, and sensing equipment around the incident site, forming the basic resource distribution layer.

[0048] Step 5: Obtain real-time alarm information and event impact range data. Real-time alarm information refers to newly generated dynamic information requiring immediate attention during event handling. Its sources can include: IoT sensing alarms (such as detecting excessive gas concentration or abnormal temperature rise), business system alarms (such as 110 receiving new secondary accident alarms or public opinion monitoring detecting panic information), and terminal-initiated alarms (such as on-site individual SOS alarms or vehicle entering restricted areas alarms). Event impact range data can be the geographical area that the event may have or has already affected, calculated through analysis based on event type, diffusion models (such as gas diffusion models, fire thermal radiation models, and flood inundation models), or on-site measured data. It is typically represented in the form of polygons, buffer zones, or contour lines. In practice, the aforementioned implementing entities can obtain alarm information in real-time from various professional systems (such as environmental monitoring platforms, public opinion systems, and emergency response systems) through a message subscription mechanism. Simultaneously, the system can integrate or call professional model services, inputting parameters such as event type, location, and meteorological conditions (such as wind direction and speed) to simulate and calculate the event's impact range in real time. For example, in the case of a gas leak, a Gaussian plume model is used to calculate the range of the pollution cloud downwind at different concentrations; in the case of a fire, the safe distance for thermal radiation is estimated based on the fire intensity. This dynamic data is converted into a standard geospatial data format (such as GeoJSON). For example, during the handling of a chemical leak, the environmental monitoring network reports in real time: "Hydrogen sulfide concentration exceeds the standard at 100 meters to the east." Simultaneously, the meteorological system provides a wind direction of east and a wind speed of level 2. Based on these parameters, the system's built-in diffusion model calculates and generates a polygon representing the "potentially affected area," with the leak point as the source and spreading downwind (to the west) in a fan shape. Furthermore, the on-site commander reports individually: "There is a residential area 200 meters downwind; it is recommended to delineate a warning zone." This alarm and impact range data is acquired by the system in real time.

[0049] Step Six: Overlay the aforementioned real-time alarm information and event impact range data onto the aforementioned basic resource distribution layer to obtain the enhanced situational awareness layer. This overlay can be the process of drawing the dynamic geospatial data obtained in Step Five onto the existing basic resource distribution layer using specific visualization methods (such as flashing warning icons, semi-transparent colored overlay areas, and dynamic contour lines). The enhanced situational awareness layer can be a comprehensive map view that simultaneously displays resource distribution statically and real-time alarms and impact range dynamically, providing a more comprehensive and timely reflection of the dynamic evolution and risk situation at the event site. In practice, the map rendering engine of the aforementioned executing entity continuously monitors updates to alarm and impact range data. When new data arrives, the engine immediately visualizes it: for point alarms (such as concentration exceeding standards), a flashing yellow exclamation mark icon is added to the corresponding location on the map; for polygonal impact ranges, a semi-transparent red (representing high risk) or yellow (representing warning) overlay area is drawn on the map; for contour lines calculated by the model, curves of different colors are drawn. All these dynamic elements coexist with static resource icons in the same map view, forming the enhanced situational awareness layer. For example, a flashing warning icon representing "hydrogen sulfide concentration exceeding the standard" has been added to the basic resource distribution layer. Simultaneously, a semi-transparent red fan-shaped area representing a "high-risk area for gas diffusion" has been overlaid on the map, covering part of residential areas. A red dotted line representing the "recommended warning line" has also been overlaid on the map. At this point, the map not only shows "what we have" (resources) but also clearly marks "where the danger is" (warning and impact range), becoming a true "enhanced situational awareness layer."

[0050] Step seven involves integrating the functional interfaces of the enhanced situational awareness layer to obtain a converged communication map. This map presents the various resources related to the received emergency and their spatial distribution. Functional interface integration involves embedding a series of interactive controls and logical interfaces into the enhanced situational awareness layer's visual interface, transforming it from a "read-only" situational awareness display into an "operable" command and dispatch platform. The converged communication map is the final product after functional integration. Specifically, the "various resources related to the received emergency" presented in the converged communication map originate from and are based on the processing results of steps one and two, namely, the set of available resources determined after screening based on event information and digital contingency plans for the target, and after availability verification. The "spatial distribution of various resources" presented is specifically achieved through the processing results of steps three and four. This involves using graphics rendering technology to accurately overlay the resource coordinate dataset of the available resource set onto the corresponding latitude and longitude locations of the base geographic information map, using specific icons, colors, and styles. This creates a basic resource distribution layer, which is the core visual component of the aforementioned converged communication map. Simultaneously, the converged communication map also overlays the real-time alarm information and event impact range data acquired and processed in steps five and six (i.e., other dynamic elements of the enhanced situational awareness layer). Therefore, the converged communication map ultimately presents a comprehensive situational image with clear spatial relationships, integrating static resource distribution, dynamic environmental alarms, and model analysis results. Furthermore, through the integration of the aforementioned functional interfaces, every visual resource element (such as an icon) on the map interface is given interactivity. For example, clicking a resource icon can trigger operations such as viewing detailed information about the resource, making audio / video calls, and assigning tasks. The map interface also integrates tools such as box selection, circle selection, distance measurement, and plotting, allowing commanders to perform spatial analysis and dispatch decisions directly on the map, thereby achieving "what you see is what you get" command and control. In practice, when providing the map front-end interface, the aforementioned execution entity binds corresponding event handling functions to each visual element on the map (resource icon, alarm icon, affected area polygon). For example, clicking a fire truck icon will pop up a menu containing buttons such as "voice call," "video conferencing," "view details," and "assign tasks." At the same time, a series of tool buttons are provided in the sidebar or toolbar of the map interface, such as "box selection for dispatch," "draw warning zone," and "send map screenshot." The back-end logic of these interfaces is closely linked to the converged communication resource pool in step 101, the converged communication link in step 104, and the subsequent command generation engine (or command generation service).For example, on the final converged communications map, the commander can see icons precisely distributed around the chemical leak point (the location of the incident), representing available fire brigades, emergency warehouses, and online video monitoring points (showing the relevant resources and their spatial distribution). Simultaneously, the map overlays a high-risk area for gas diffusion downwind (a red semi-transparent area) and a new concentration exceeding alarm point (a flashing icon). The commander uses the map's "selection tool" to select several buildings within the high-risk area. Then, he clicks the "one-click call" button in the toolbar. The system automatically retrieves all online mobile terminals within the selected area (such as those of community workers) and initiates an emergency group voice call through the established converged communications link, quickly issuing evacuation orders.

[0051] Step 106: In response to the recognition that the user has performed a scheduling operation through the converged communication map, generate various scheduling instructions corresponding to the scheduling operation according to the target digital plan.

[0052] In some embodiments, the aforementioned execution entity may, in response to recognizing that a user has performed a scheduling operation through the aforementioned converged communication map, generate various scheduling instructions corresponding to the aforementioned scheduling operation based on the aforementioned target digitization plan. The scheduling operation may be an interactive behavior initiated by an authorized user on the interactive interface of the aforementioned converged communication map, using a mouse, touchscreen, or external controller, targeting specific resources, areas, or situational elements presented on the map, and intending to drive the system to perform a certain collaborative action. Specific operation types may include, but are not limited to, point selection operations (such as clicking or double-clicking a resource icon, alarm point, or blank area on the map), box selection or circle selection operations (such as dragging the mouse to form a rectangular or polygonal area to select multiple resources within that area), drawing operations (such as drawing a route, a warning zone, or a marker point on the map), and menu or button triggered operations (such as selecting "call" in the context menu that pops up when right-clicking a resource icon, or clicking the one-click scheduling button in the map toolbar). Identification can be defined as the process by which the system captures the aforementioned user interaction actions through the event listening mechanism of map interaction components (such as JavaScript-based WebGIS APIs), and parses the target object affected by the action (such as the list of clicked resource IDs, the selected latitude and longitude range, and the drawn graphic parameters) and the action type (such as click, selection, drawing). According to the aforementioned target digitization contingency plan, when generating specific instructions, it is necessary not only to consider the user's real-time scheduling operation, but also to combine the predefined handling logic, resource associations, command permissions, and response processes in the currently activated target digitization contingency plan to ensure that the generated instructions comply with the scientific and standardized requirements of the contingency plan. Generating various scheduling instructions corresponding to the aforementioned scheduling operations can be defined as the process by which the system, based on the identified scheduling operation details (operation type, target) and the constraints of the target digitization contingency plan, dynamically constructs one or more specific command messages or data structures that can be executed by the communication system or business system through pre-set instruction templates and logical rules. These dispatch instructions can be categorized into several types, including communication dispatch instructions (such as initiating a voice / video call to a specific person or terminal, establishing a multi-party conference, or sending an SMS or instant message), resource dispatch instructions (such as ordering a rescue team to assemble at a designated location, allocating supplies and equipment to the site, or assigning an emergency vehicle to perform a mission), task assignment instructions (such as creating a specific task, specifying the responsible person and completion deadline, and issuing it via a mobile application), and information collaboration instructions (such as pushing a video surveillance feed to relevant parties' screens or sharing an electronic document with meeting participants). In practice, the first step involves the aforementioned executing entities integrating the communication map's front-end interface to monitor user interaction events in real time.When a user performs actions such as clicking or selecting on the interface, the front-end code captures the event, extracts the operation type and target (e.g., a list of clicked resource IDs, or the geographical boundary coordinates of the selected area), and encapsulates this information into a dispatch operation request, which is then sent to the back-end service. The second step involves the back-end service receiving the dispatch operation request and loading the corresponding digital contingency plan. Then, it combines the command relationships, division of responsibilities, handling procedures, and resource usage rules specified in the contingency plan to perform compliance verification and a deeper understanding of the user's intent. For example, if a user selects an area and clicks the evacuation button, the system checks the evacuation responsibility department, evacuation route, and refuge location specified in the contingency plan to ensure the generated instruction conforms to the plan. The third step involves calling the corresponding instruction generation engine based on the parsed operation intent and contingency plan rules. This engine has a pre-built instruction template library for different operation types and contingency plan stages. For example, for clicking a resource icon and selecting a call operation, the engine searches the contingency plan for the communication contact method of the resource (e.g., a fire brigade) (obtained from the converged communication resource pool) and generates a standard SIP call signaling or instant message. When a selected area is selected and a meeting is initiated, the engine retrieves all online terminals (such as individual soldiers and command vehicles) within that area that are capable of conferencing, and generates an instruction to create a multi-party video conference. Simultaneously, it determines the meeting host based on the pre-planned schedule. During instruction generation, the system retrieves the target terminal's real-time access parameters (such as IP address and session ID) from the converged communication resource pool to ensure the instruction can be delivered. The fourth step involves encapsulating the generated instruction into a standard internal system format (such as a JSON object or XML message). This format typically includes the instruction type, a list of target objects, instruction parameters (such as call number, meeting topic, and task description), execution priority, and the associated pre-planned step ID. These instructions are then placed in a queue of pending instructions, ready to be issued via the established converged communication link or transmitted to other business systems for execution. For example, in handling a hazardous chemical leak, the commander observes on the converged communication map that a gas diffusion model indicates a certain area downwind is within a danger zone. He selects the area using the map tool and clicks the "Issue Evacuation Instruction" button in the map toolbar. The system recognizes this as a dispatch operation targeting a specific geographical area. The system then integrates with the currently implemented "Emergency Response Plan for Hazardous Chemical Leaks," which stipulates that street communities are responsible for organizing evacuations in such situations. Therefore, the instruction generation engine performs the following operations: First, based on the selected geographical area, it queries and lists the mobile terminals of online community workers and area managers located within the designated area from the converged communication resource pool. Then, it generates two dispatch instructions: 1) a group SMS instruction containing a pre-set evacuation notification template, filled with specific locations and precautions, targeting all the aforementioned terminals; 2) a voice broadcast instruction, which, through the converged communication link, invokes the emergency broadcast system covering the area to play evacuation audio.Simultaneously, the system also marks executed evacuation instructions in the contingency plan execution record. Thus, the system transforms a user's intuitive operation on the map into multiple specific, executable, and contingency plan-compliant dispatch instructions, achieving efficient and standardized command and dispatch.

[0053] After addressing the technical challenges of inefficient cross-departmental and cross-system resource integration and collaborative scheduling by employing a dual-use collaborative command approach, and obtaining unified and visualized dispatch instructions, the following technical problem arises in the application scenario: real-time changes and complex intertwined emergency response situations such as fires in large public places and hazardous chemical leaks in industrial parks. This is because when dispatch instructions from the command center need to drive various heterogeneous physical actuators widely distributed on-site, such as audible and visual alarms, emergency broadcasts, smoke exhaust fans, access control systems, and power supply units, relying solely on preset, static command-action mapping relationships is insufficient to handle real-time dynamic changes in the on-site environment (such as smoke concentration, personnel distribution, and equipment status). This can easily lead to a disconnect between control actions and the environmental situation, manifesting as over-response in unnecessary areas, conflicting action sequences of multiple devices, or failure of critical equipment to coordinate due to malfunctions. This impacts overall response efficiency and safety, and may even trigger secondary risks. Considering the following requirements for this application scenario: high real-time performance, adaptive multi-device collaboration, and closed-loop dynamic optimization, we have decided to adopt the following solution: Step 107: Through the converged communication link, cross-departmental collaborative processing is carried out based on various scheduling instructions.

[0054] In some embodiments, the aforementioned executing entities can perform cross-departmental collaborative processing based on the aforementioned scheduling instructions through the aforementioned converged communication link.

[0055] In some optional implementations of certain embodiments, the aforementioned executing entity can perform cross-departmental collaborative processing based on the aforementioned scheduling instructions through the aforementioned converged communication link via the following steps: The first step is to generate an action instruction set based on the aforementioned scheduling instructions. This action instruction set includes the identifiers of each target device and various control parameters. Each scheduling instruction can be a command generated in step 106 that encapsulates a specific operational intent (such as making a call or dispatching a task). Generating the action instruction set can refer to the process by which an instruction conversion and distribution center (or service) parses and translates these upper-layer business scheduling instructions. Its purpose is to convert scheduling instructions oriented towards "personnel and tasks" into a set of directly executable control commands oriented towards "physical devices." The target device identifier can be a unique code identifying a physical execution device to be controlled, such as the device serial number of an audible and visual alarm, the IP address of an emergency broadcast terminal, the bus address of a lighting controller, or the ID number of an access control controller. These identifiers are typically pre-entered and associated with corresponding resource items in the converged communication resource pool. Control parameters can be specific configuration values ​​required to drive the target device to perform specific actions. For example, for playing alarm audio, parameters may include audio file ID, playback volume, and loop count; for switching lighting modes, parameters may include target mode encoding (such as "emergency full brightness" or "50% brightness"); for opening a channel, parameters may include channel number and opening duration. In practice, the aforementioned execution entity can run an instruction adaptation engine. This engine receives various scheduling instructions from step 106. First, the engine parses the type and target of each scheduling instruction (such as "initiate a three-way voice call to terminals A, B, and C"). Then, based on a predefined mapping rule base and device information queried from the converged communication resource pool, the engine "decomposes" each abstract scheduling instruction into one or more control commands targeting specific physical devices. For example, the "initiate a three-way voice call" instruction may be decomposed into three commands: sending "establish voice session" commands to the communication modules of terminals A, B, and C respectively. Each such command, along with its target device identifier and required control parameters, constitutes an "action instruction" unit. All "action command" units generated in response to this dispatch operation are collected to form an action command set. For example, step 106 generates a dispatch command to "issue an evacuation broadcast to XX community". After the command adaptation engine parses the command, it determines that the emergency broadcast terminals and audible and visual alarms in the community need to be activated. The engine queries the converged communication resource pool and finds that there are 5 broadcast terminals (IDs B1 to B5) and 3 audible and visual alarms (IDs S1 to S3) in the community. Subsequently, the engine generates 8 action commands: 5 of them have target device identifiers B1 to B5 and control parameters of "play audio file: evacuation notice.mp3, volume level: 8"; the other 3 have target device identifiers S1 to S3 and control parameters of "activate alarm mode: rapid beeping, flashing frequency: 2Hz". These 8 commands together constitute the initial action command set for this coordinated response.

[0056] The second step involves generating a set of device control signals based on the aforementioned action instruction set. This set includes various device drive signals and programmable logic controller (PLC) instructions. Generating the device control signal set refers to the process of converting abstract control commands from the action instruction set, oriented towards different protocols and interfaces, into physical or logical signal formats that the underlying hardware can directly recognize and execute. Device drive signals can be data frames or electrical signals following specific industry or device-specific proprietary communication protocols, used to directly drive smart terminals or devices with standard communication interfaces. Examples include dimming command frames sent to a lighting controller via RS-485 / Modbus protocol, audio stream push command packets sent to a network broadcast terminal via TCP / IP and proprietary protocols, and call signaling sent to an IP phone via SIP protocol. Programmable Logic Controller (PLC) instructions can be logic control instructions (such as ladder logic and instruction lists) that conform to standards like IEC 61131-3 and can be interpreted and executed by the PLC. They are typically used to control industrial automation systems such as access control, ventilation, and power systems. For example, a PLC instruction might include "setting" an output point to open an electromagnetic lock or "resetting" an output point to close a damper. In practice, the execution entity can deploy various protocol conversion gateways or driver services. For different types of physical execution devices, the corresponding driver service is invoked. Each driver service maintains a communication protocol stack with a specific type of device. When an action instruction is received, the driver service determines the device type and communication method based on the target device identifier, and then "translates" the control parameters in the instruction into a specific protocol message or control logic that the device can understand. For example, for a network broadcast terminal, its driver service generates a push instruction packet (device drive signal) containing the target IP address, port number, and audio stream URL. For ventilation systems connected to a PLC, the drive service converts the parameter "adjust to smoke exhaust mode" into a series of read / write instructions (programmable logic controller instructions) targeting specific PLC input / output (I / O) addresses and internal registers. All these generated low-level signals and instructions are collectively referred to as the device control signal set. For example, for the broadcast terminal instructions (B1 to B5) in the aforementioned action instruction set, the network broadcast drive service generates five UDP / TCP data packets, each containing a "start playing specified audio stream" command sent to the corresponding terminal IP address. For the audible and visual alarm instructions (S1 to S3), its dedicated drive service (potentially based on Zigbee, LoRa, or dry contact control) generates three sets of switch control signals. For the instruction to open an emergency exit, the PLC drive service generates a list of instructions containing the logic "open the electromagnetic lock of passage 1 for 300 seconds," ready to be sent to the PLC responsible for access control. These are the generated device control signal sets.

[0057] The third step involves receiving an initial environmental state data stream via the aforementioned converged communication link. This initial environmental state data stream includes ambient temperature data, smoke concentration data, and personnel density data reported by field sensors. The converged communication link can be the unified communication channel established in step 104, connecting multiple parties (including the field sensor network gateway). Receiving data can be the process by which the system uses this link to monitor or actively subscribe to data from various IoT sensors deployed on-site in real time. The initial environmental state data stream can refer to a time-series data set reflecting the initial environmental conditions sensed from the event site before the physical actuator is activated or at the initial moment of action. Ambient temperature data can be measurements from temperature sensors (unit: degrees Celsius °C). Smoke concentration data can be measurements from smoke or gas concentration sensors (unit: such as ppm or mg / m³). Personnel density data can be estimated data on the number of people or their distribution in a unit area using video analysis, infrared sensing, or mobile terminal signal detection. These data collectively constitute an initial environmental "snapshot" for decision-making. In practice, the aforementioned implementing entities can establish data connections with the sensor data aggregation gateway deployed on-site or directly with smart sensors via a converged communication link. When the system initiates collaborative response, it sends a data subscription request to the sensor network through the link. Various sensors continuously collect raw data according to their sampling cycles, which is then aggregated and packaged through the gateway and pushed or reported to the command system in real time via the converged communication link (potentially reusing its data channels). Upon receiving these data streams, the system parses, unifies the format, and aligns the timestamps to form a continuous initial environmental state data stream. For example, in the early stages of a fire in a shopping mall, the system receives a real-time data stream from the fire alarm system gateway via the converged communication link: smoke concentration values ​​reported by multiple smoke detectors (rapidly rising from 0 to 15% obs / m), temperature gradient data reported by the temperature-measuring fiber optic cable (local temperature has risen to 45℃), and the preliminary estimate of the population density (high density) in the area near the fire point by the video analysis subsystem. This data, received by the system before the response actions are executed, constitutes the initial environmental state data stream used to evaluate and optimize control strategies.

[0058] The fourth step involves verifying the initial environmental state data stream to obtain the environmental control verification results. Verification processing involves quality checks, logical checks, and preliminary analysis of the received initial environmental state data. This aims to confirm the reliability, validity, and severity of the environmental situation represented by the data, providing a basis for subsequent decision-making. The environmental control verification results can be one or more conclusive indicators or judgments derived after verification processing, such as whether the data is reliable, whether the environment is abnormal and the level of abnormality, and whether key indicators (such as temperature and concentration) exceed preset safety thresholds. In practice, the implementing entity can run a data verification analysis service (or data verification analysis engine). This service (or engine) processes the continuously input data stream as follows: 1) Data quality verification: checking whether the data is continuous, within a reasonable range, and whether the sensors are offline, removing obvious outliers. 2) Threshold comparison: comparing key indicators such as temperature and smoke concentration with preset safety thresholds or warning thresholds in real time. 3) Initial Situation Assessment: Based on data from multiple relevant sensors, a simple fusion analysis is performed. For example, if multiple adjacent smoke sensors alarm simultaneously, the fire is considered highly credible. Combined with the temperature rise trend, the initial stage of fire development can be determined. The verification results can be output in a structured report format, including information such as "Data Quality Status" (credible / partially questionable / unreliable), "Environmental Anomaly Level" (none / mild / moderate / severe), and "List of Exceeding Parameters" (e.g., temperature has exceeded the 60℃ safety threshold). For example, after receiving the initial data stream of a shopping mall fire, the verification service (or engine) finds that: the sensor signal strength of all reported data is good, and the data is continuous; the smoke concentration value continues to rise rapidly at multiple points, far exceeding the warning threshold; the temperature near the ignition point has exceeded the safe operating temperature. Based on this, the verification service (or engine) generates the environmental control verification result: the data is credible, the environmental anomaly level is "severe," the key anomalies are "severely exceeded smoke concentration" and "localized high temperature," and it is recommended to immediately activate strong smoke extraction and emergency lighting, and pay attention to personnel evacuation.

[0059] The fifth step involves iteratively optimizing the parameters of the environmental control verification results and the equipment control signal set to obtain an optimized control signal set. This parameter iterative optimization can be an algorithmic process that dynamically adjusts and optimizes the equipment control commands to be issued based on real-time environmental feedback. Its core idea is to use the current environmental situation reflected in the verification results to correct the control parameters (such as intensity, duration, range, and target) in the preset or initially generated equipment control signals, making the control actions more targeted, safe, and efficient. The optimized control signal set can be the final set of equipment control signals prepared for execution after optimization. In practice, the execution entity can have a built-in or invoked control parameter optimization engine. This engine takes the environmental control verification results and the equipment control signal set as input. The engine has a pre-built optimization rule base or model for different emergency scenarios. For example, the rule might stipulate that when "smoke concentration is severely exceeded" and "personnel density is high," the power of the smoke exhaust fan should be adjusted from the preset "medium" to the "highest" level, and the volume of the emergency broadcast should be increased by one level. The engine matches relevant rules based on the verification results, then iterates through the set of device control signals to find the corresponding control signals (such as smoke exhaust fan control commands and broadcast volume parameters), and modifies their parameter values ​​according to the rules. This process may be a rapid iteration, generating an optimized signal set. For example, the initial set of device control signals might contain a command to "activate medium-speed smoke exhaust mode" for controlling the mall's smoke exhaust system. Based on the verification result "smoke concentration severely exceeds the standard," the engine optimizes the application rules, changing the control parameter from "medium speed" to "high speed." Simultaneously, for the emergency broadcast command, based on the verification result of "high personnel density," the preset "normal volume" parameter is modified to "increase volume." The optimized smoke exhaust and broadcast control signals, along with other unmodified signals, constitute the optimized control signal set.

[0060] Step 6: Based on the aforementioned set of device control signals, drive each of the first-type physical execution devices. Driving these devices includes controlling the audible and visual alarms to play preset alarm audio, controlling the emergency broadcast terminal to broadcast evacuation instructions, and controlling the lighting controller to switch emergency lighting modes. The first-type physical execution devices can be field devices primarily used to issue warning information and guide personnel behavior. Driving can involve sending the corresponding signals from the device control signal set to the target device via a corresponding network or line, triggering its execution. In practice, the aforementioned execution entity uses its integrated device driver services (as described in Step 2) to distribute optimized control signals to the first-type devices. For networked devices (such as IP broadcasting and smart lighting), signals are sent directly to the device via the IP network (possibly via the data channel of a converged communication link). For traditional or dedicated bus devices (such as some audible and visual alarms), signals may be forwarded via a serial server or dedicated gateway. The system monitors the status of instruction distribution and device execution feedback. For example, the system sends a drive signal to the network broadcast terminals (first-type devices) in each zone of the shopping mall via the IP network, instructing them to "play evacuation instruction audio and increase volume." Simultaneously, the fire alarm system's control module sent a "activate buzzer and flashing lights" signal to the audible and visual alarms on each floor. The intelligent lighting system's controller sent a signal to "switch public area lighting to 100% full brightness emergency mode." The mall's public address system began broadcasting evacuation instructions, the alarms sounded, and all lights turned on, effectively providing warnings and guidance.

[0061] Step 7: Based on the aforementioned set of equipment control signals, drive each of the second-type physical actuators. Driving these actuators includes controlling access control controllers to open emergency exits, controlling ventilation system controllers to adjust smoke extraction and air supply modes, and controlling power distribution units to ensure power supply to critical circuits. These second-type physical actuators can be field devices primarily used to alter the physical environment and ensure the operation of critical infrastructure. In practice, similar to step 6, the executing entity sends control signals through corresponding drive services (such as PLC drive services or power monitoring protocol drives). For access control and ventilation systems, signals are typically sent to the on-site PLC or Direct Digital Controller (DDC). For power distribution units, signals are sent to intelligent distribution cabinets or power management systems. The system ensures the reliable delivery of these critical control commands. For example, the system might send a command to the PLC in the shopping mall's fire control center to open the electromagnetic locks of all normally closed fire doors in evacuation stairwells (opening emergency exits). Send instructions to the HVAC system controller to forcibly switch the ventilation mode of the fire area and adjacent areas to "smoke exhaust mode," shut down the air conditioning supply, and turn on the smoke exhaust fan (adjust the smoke exhaust supply mode). Send instructions to the power distribution system to cut off non-fire-fighting power to the fire area and ensure continuous power supply to the circuits of critical fire-fighting equipment such as emergency lighting, fire pumps, and smoke exhaust fans (ensure power supply to critical circuits).

[0062] Step 8: Execute closed-loop control based on the optimized control signal set described above. Closed-loop control can refer to a continuous process that begins after the physical actuator starts operating. This process monitors the new environmental effects (physical execution effect feedback data stream) generated after the actuator's actions in real time, compares them with the control objectives anticipated by the optimized control signal set, and dynamically adjusts control parameters based on deviations, forming a "perception-decision-execution-re-perception" closed loop to ensure optimal handling or adaptation to changing circumstances. The detailed implementation logic of this process is defined in subsequent independent claim 8. In practice, after completing the initial drive in steps 6 and 7, the aforementioned actuator immediately activates and initiates the closed-loop control process (corresponding to the process described in claim 8). This process runs in parallel with the operation of the physical actuator. The system begins collecting new data from field sensors (no longer initial data, but effect data after actuator intervention) and invokes a specialized closed-loop control algorithm to fine-tune the operating parameters of still-operating devices (such as smoke exhaust fans and emergency broadcasts) or trigger new supplementary actions. For example, in the event of a fire in a shopping mall, after completing the initial series of actions such as smoke extraction, broadcasting, lighting, opening doors, and power cutoff, the system immediately enters a closed-loop control state. It continuously monitors changes in smoke concentration near the smoke extraction outlets. If the rate of decrease in concentration is slower than expected, the closed-loop control algorithm may generate instructions to further increase the power of the smoke extraction fans or adjust the opening of the air supply vents. Simultaneously, it monitors the personnel heat map; if it detects people lingering in a certain area, it may add directional voice prompts to that area via the broadcast system. This process continues until the fire is extinguished and environmental indicators return to normal, at which point the system controls the relevant devices to stop working or return to normal operation.

[0063] Steps one through eight of this disclosure are an inventive point of this disclosure, which solves the technical problem that "existing collaborative command systems lack an integrated, adaptive execution framework in the closed loop from the generation of dispatch instructions to the execution of on-site physical devices, which includes instruction semantic parsing, multi-protocol adaptation, environmental situation fusion perception, dynamic optimization of control parameters, multi-device collaborative driving to effect closed-loop control, resulting in long control response chains, rigid and disjointed actions, lack of real-time optimization and low collaborative efficiency". Existing technologies have the following shortcomings in closed-loop control from instruction to execution: Firstly, dispatch instructions are mostly abstract descriptions oriented towards personnel and tasks, lacking a mechanism for automatic conversion into specific equipment control commands, and highly dependent on manual interpretation and operation; secondly, field equipment brands, models, and communication protocols vary, lacking a unified protocol conversion and driver layer, making it difficult to achieve "one-click linkage"; thirdly, control decisions heavily rely on preset plans, unable to integrate real-time environmental perception data (such as smoke, temperature, and personnel density) for dynamic adjustment and optimization, resulting in rigid response measures; and fourthly, the control action is the endpoint once issued, lacking real-time monitoring of execution effects and feedback-based adaptive adjustment, making the entire process open-loop and blind. Solving these problems would enable safe and efficient output from visualized dispatch instructions to multi-departmental, multi-type physical device collaboration and adaptive control within minutes or even seconds, achieving a truly intelligent and reliable cross-departmental collaborative closed-loop. To achieve this effect, this disclosure proposes: First, generate an action instruction set based on the aforementioned dispatch instructions. Thus, the upper-level business instructions oriented towards "personnel and tasks" are precisely decomposed and translated into a set of action commands with clear control parameters for "specific physical devices" through the instruction adaptation engine, solving the core bottleneck problem of abstract scheduling instructions that cannot directly drive heterogeneous physical execution devices. The second step is to generate a set of device control signals based on the aforementioned action instruction set. Then, by deploying multiple protocol conversion gateways or driver services, the unified action instructions are "translated" into drive signals or programmable logic controller instructions that can be directly recognized and executed by various underlying devices, overcoming the technical challenge of unified control and scheduling of cross-brand and cross-protocol physical devices. The third step is to receive the initial environmental state data stream through the aforementioned converged communication link. This proactively acquires and aggregates real-time environmental data (such as temperature, smoke concentration, and personnel density) reported by various field sensors in front of the driving device, providing objective and quantitative on-site situational awareness input for control decisions, solving the problem of "disconnection" between control actions and the actual on-site environment. The fourth step is to verify the aforementioned initial environmental state data stream to obtain environmental control verification results. Thus, by using data verification and analysis services to perform quality checks, threshold comparisons, and preliminary situation assessments on the raw environmental data, a structured report on the level of environmental anomalies and key risks is generated. This ensures the reliability and effectiveness of the data on which subsequent optimization decisions are based, and resolves the risk of control optimization based on erroneous or noisy data.The fifth step involves iteratively optimizing the parameters of the aforementioned environmental control verification results and the aforementioned equipment control signal set to obtain an optimized control signal set. Thus, using the control parameter optimization engine, key parameters (such as intensity and mode) in the preset control signals are dynamically adjusted based on real-time environmental verification results, achieving a leap from "fixed-program control" to "data-driven intelligent control," solving the problems of rigid control strategies and inability to adapt to changing situations. The sixth step involves driving each of the first-type physical actuators according to the aforementioned equipment control signal set. Thus, through integrated drive services, the optimized control signals are reliably sent to devices used for warning and guidance, such as audible and visual alarms, emergency broadcasts, and emergency lighting, achieving efficient and coordinated guidance of on-site personnel behavior and solving the problems of delayed warning information dissemination and incoordination between different guidance methods. The seventh step involves driving each of the second-type physical actuators according to the aforementioned equipment control signal set. Thus, through corresponding drive services, control signals are precisely distributed to devices such as access control, ventilation, and power systems used to alter the physical environment and safeguard infrastructure. This enables rapid and coordinated intervention in critical physical states on-site, solving the problem of such critical intervention actions relying on manual intervention and being difficult to execute synchronously across departments. The eighth step involves executing closed-loop control based on the optimized control signal set. Therefore, after the device is started, the closed-loop control logic of "monitoring effect - calculating deviation - dynamic adjustment" continuously runs, ensuring that the handling actions continuously approach or maintain the expected goals. This achieves a fundamental shift from "open-loop execution" to "closed-loop optimization," solving the defects of the control process in not being able to guarantee the final effect or cope with the dynamic evolution of the situation. In summary, the first to eighth steps of this embodiment cooperate with each other, starting from the entire chain of "instruction translation, protocol adaptation, environmental perception, data verification, parameter optimization, classification-driven to closed-loop control," and by constructing an end-to-end, adaptive integrated execution framework, a high degree of automation, coordination, and intelligence is achieved in collaborative command from intelligent decision-making to precise physical execution. This effectively eliminates long command execution chains, disconnected actions of multiple devices, rigid control strategies, and blind spots in open-loop effects, ensuring the real-time, accurate, coordinated, and highly reliable nature of emergency response actions, and to a certain extent meeting the core requirements of modern emergency command for "efficient linkage and precise handling".

[0064] After adopting a cross-departmental collaborative control method based on scheduling instructions to solve the technical problems of "inefficient conversion from instruction to execution and rigid, disconnected control," and obtaining optimized control signal sets to drive the devices to start execution, the following technical problem often arises in the application scenarios: emergency response sites with real-time changes and multiple devices intertwined, such as fires in large public places and hazardous chemical leaks in industrial parks: when multiple physical execution devices such as smoke exhaust fans, emergency broadcasts, access control, and emergency lighting have been driven and have begun to intervene in the site environment, if their operation control lacks dynamic optimization and closed-loop management based on real-time response effects, it is difficult to ensure that the response action can accurately adapt to the rapidly changing site situation such as fire spread, changes in gas diffusion paths, and personnel evacuation progress. Specifically... The problems manifest in several ways: First, the equipment operates "blindly" due to a lack of real-time quantitative perception of intervention effects (such as the actual rate of decrease in smoke concentration and changes in personnel density), potentially leading to excessive smoke emission or broadcasting in safe areas, resulting in energy waste and panic. Second, the lack of intelligent analysis based on the deviation between effects and targets leads to "delayed adjustments," relying solely on fixed cycles or manual experience for mechanical adjustments, failing to achieve scientific and adaptive parameter optimization. Third, the lack of a continuous and self-disciplined "monitoring-evaluation-adjustment" cycle mechanism results in "process disconnect," making it unable to effectively respond to secondary disasters or sudden changes in the situation. Fourth, the lack of convergence judgment and graceful exit logic based on objective indicators leads to "improper termination," potentially causing premature shutdown leading to a resurgence of the emergency, or excessive operation causing equipment damage and secondary risks. To address the following requirements for this application scenario: perceptible effects, adaptive control, sustainable process optimization, and accurate termination determination, we have decided to adopt the following solution: In some optional implementations of certain embodiments, the aforementioned execution entity may perform closed-loop control based on the aforementioned optimized control signal set through the following steps: The first step involves executing the following cyclic control steps in response to the start of driving the aforementioned first-type and second-type physical execution devices. The "start of driving" step can be triggered when the system confirms that it has successfully issued initial control commands to the first-type and second-type physical execution devices (i.e., steps six and seven of step 107) and receives "execution start" confirmation feedback from some or all devices, thus setting the initiation condition for subsequent closed-loop control logic. The cyclic control step can be a repeatedly executed logic block containing multiple sub-steps. Its core purpose is to continuously monitor the effect and dynamically adjust the control during the execution of the physical devices to approach or maintain the expected target.

[0065] The first sub-step involves real-time acquisition of the physical execution effect feedback data stream. This data stream can be a set of time-series data collected and reported in real-time by various sensors deployed at the event site after the aforementioned first and second type of physical execution devices begin performing their assigned physical actions (such as playing a broadcast or initiating smoke extraction). This data stream reflects the actual environmental changes resulting from the actions of these devices. The key difference between this data stream and the initial environmental state data stream in step 107 (third step) is that it represents the environmental state after the device intervention, serving as a direct basis for evaluating the control effect. Its data content may also include ambient temperature, smoke concentration, and personnel density, but its values ​​and trends reflect the impact of the control actions. In practice, the aforementioned execution entity can re-subscribe to or continuously monitor the data stream from the field sensor network through the established converged communication link when initiating closed-loop control. At this time, the system focuses on the changes in key indicators under the influence of the control actions. For example, after initiating smoke extraction, continuously acquire smoke concentration data at the smoke extraction outlet and downwind; after playing an evacuation broadcast, continuously acquire heat map data of personnel density in key areas. For example, in a shopping mall fire response, once the smoke exhaust fans and emergency broadcasts are activated, the system continuously receives sensor data streams from several key areas: 1) smoke concentration sensor data near the smoke exhaust fan outlet (fluctuating from 15% obs / m); 2) personnel flow statistics camera data on the main evacuation routes; and 3) ambient temperature sensor data. These data collectively constitute a physical execution effect feedback data stream used to evaluate the "smoke exhaust effect" and the "evacuation guidance effect."

[0066] The second sub-step involves generating a control deviation dataset based on the acquired physical execution effect feedback data stream and the aforementioned optimized control signal set. "Based on" can refer to the process of comparing and analyzing real-time feedback data with pre-set control targets. The optimized control signal set can include the expected control targets or key performance indicators (KPIs) associated with each control command generated in step 5 of step 107. For example, for a smoke exhaust control command, the expected target could be "to reduce the smoke concentration in the core area to below 5% obs / m² within 10 minutes"; for an emergency broadcast command, the expected target could be "to reduce the personnel density in area A to below the safety threshold within 5 minutes." Generating the control deviation dataset can refer to the process of calculating the differences (including numerical differences, trend differences, and achievement time differences) between the real-time feedback data and these expected targets, and quantifying these differences into structured data. The control deviation dataset can be a collection of data containing multiple deviation items, each of which can include the deviation type, deviation magnitude, the ID of the relevant control command, and the timestamp of the deviation calculation. In practice, the aforementioned execution entity can run a deviation analysis engine. In each control cycle (e.g., every 10 seconds), the engine parses the expected targets of each instruction from the optimized control signal set, and simultaneously extracts the corresponding measured values ​​from the latest physical execution effect feedback data stream. The engine then calculates the difference or percentage error between the measured value and the target value. For trend-based targets (e.g., "concentration continues to decrease"), the engine also calculates the rate of change and compares it with the expected rate of change. All calculation results are encapsulated into a standard-format deviation dataset. For example, for the instruction "exhaust fan high-speed operation," the preset target is "the concentration at monitoring point 1 should be below 8% obs / m³ after 5 minutes." Three minutes after the instruction is executed, the deviation analysis engine reads the current concentration at monitoring point 1 as 12% obs / m³. The engine calculates the "current concentration deviation" as +4% obs / m³, and the "concentration decrease rate" is lower than expected. These two deviation items, along with the corresponding instruction ID and target parameters, are recorded in the control deviation dataset.

[0067] The third sub-step involves adjusting the parameters of the control signal set driving each physical actuator based on the control deviation dataset, resulting in a dynamic adjustment instruction set. The control deviation dataset can refer to using calculated deviation data as the core input to guide the adjustment of the control strategy. The device control signal set can be the set of control signals currently driving the physical actuators, which may have already been optimized in step 5 of step 107. Parameter adjustment processing can refer to a control algorithm or rule logic that determines how to adjust adjustable parameters in the device control signals (such as motor power, valve opening, audio volume, and light brightness) based on the magnitude and nature of the deviation to reduce or eliminate the deviation. Common adjustment strategies include proportional-integral-derivative (PID) control, fuzzy logic control, or adjustment based on preset rules. The dynamic adjustment instruction set can be a set of one or more updated control instructions generated after parameter adjustment processing, used to fine-tune the running physical actuators. In practice, the aforementioned execution entity can deploy a parameter adjustment controller (such as a software PID controller or rule engine). This controller receives the control deviation dataset as input. For each control loop requiring adjustment (such as the smoke exhaust fan control loop), the controller applies its algorithm: for example, a PID controller calculates a new fan speed setpoint based on the current deviation (P), historical cumulative deviation (I), and deviation trend (D). Then, the controller generates a new control instruction containing the updated speed parameter. All such new instructions constitute the dynamic adjustment instruction set. For instance, for a deviation where the rate of decrease in smoke exhaust concentration is lower than expected, the parameter adjustment controller (using a PID algorithm) calculates that the fan power needs to be further increased. Therefore, it generates a new "smoke exhaust fan control instruction," adjusting the speed parameter from the current "high speed" to "maximum speed." Simultaneously, for a deviation in personnel evacuation speed, the rule engine, based on the deviation of "slow decrease in personnel density," triggers the rule "increase broadcast frequency and directional reminders," generating a new "emergency broadcast instruction," modifying the parameter to "play evacuation prompts, shortening the cycle interval from 1 minute to 30 seconds." These two new instructions constitute the current dynamic adjustment instruction set.

[0068] The fourth sub-step involves distributing the generated dynamic adjustment instruction set to each physical execution device. This distribution refers to the process of reliably sending each instruction in the dynamic adjustment instruction set to its target physical execution device via the corresponding communication driver service (as described in step 107, second step). The aim is to enable the device to immediately adjust its operating state based on the new parameters. In practice, the aforementioned execution entity invokes the driver service corresponding to the device type. The driver service converts the adjustment instructions into device-recognizable protocol messages and sends them out via a converged communication link or direct network connection. The system waits for or actively queries the device for confirmation responses to ensure that the adjustment instructions are received and executed. For example, the system uses the PLC driver service to distribute a new "maximum speed" exhaust fan instruction to the controller of the shopping mall's HVAC system. Simultaneously, it uses the network broadcast driver service to distribute a new "30-second interval" broadcast instruction to the broadcast terminals in each area. Upon receiving the new instructions, the device will correspondingly increase the fan speed and broadcast frequency.

[0069] The fifth sub-step involves controlling each physical execution device to maintain its current state of operation when the real-time acquired physical execution effect feedback data stream meets the preset control convergence conditions. The control convergence conditions can be a predefined set of judgment criteria used to determine whether the closed-loop control process has reached a stable and satisfactory state, eliminating the need for further significant parameter adjustments. These conditions may include: 1) Key environmental indicators (such as smoke concentration and temperature) have decreased and stabilized within safe thresholds; 2) The rate of change of key indicators has approached zero (i.e., tending towards stability); 3) Personnel have been evacuated. Meeting these conditions can be achieved by continuously monitoring and judging to confirm that the real-time feedback data stream consistently and stably meets all preset convergence conditions. Controlling each physical execution device to maintain its current state of operation can mean that the system no longer sends new adjustment commands, but instead sends commands to the devices to "maintain current operating parameters" or "enter steady-state operation mode," keeping the devices in their current working state, which has achieved optimal or acceptable results. In practice, the aforementioned execution entity executes a "convergence judgment" logic (or calls a convergence judgment service) at the end of each control loop. This logic (or service) checks the preset convergence conditions item by item based on the latest physical execution effect feedback data stream. When all conditions are met and maintained for a certain period of time (e.g., three consecutive sampling cycles), the judgment logic (or service) outputs a "convergence" signal. The system then sends a "maintain" command to all relevant physical execution devices and marks their control mode as "steady state". For example, after multiple adjustments, monitoring shows that the smoke concentration in the shopping mall fire area has stabilized at 2% obs / m (below the safety threshold of 3%), and the temperature has dropped to normal, with zero personnel density in the main area. The convergence judgment logic (or service) determines that the conditions are met. The system then sends a "maintain current state" command to devices such as smoke exhaust fans, emergency broadcasts, and emergency lighting. The smoke exhaust fans maintain a low speed to maintain ventilation, the broadcasts stop looping but remain on standby, and the emergency lighting remains on.

[0070] The second step involves re-executing the aforementioned cyclic control steps in response to the real-time acquired physical execution effect feedback data stream failing to meet the preset control convergence conditions. This failure to meet the conditions can occur at the end of any control cycle when the convergence judgment logic (or service) detects that one or more preset convergence conditions have not been met. Re-executing the cyclic control steps means the system jumps back to the beginning of the first step, restarting from the first sub-step (acquiring new feedback data streams in real time) to begin the next control cycle and continue the closed loop of monitoring, analysis, and adjustment. In practice, this is a typical cyclic control logic. If convergence fails, the system will not issue a "maintain" command but will directly begin data acquisition for the next cycle. This ensures that the system will continuously and adaptively optimize and adjust as long as the effect does not meet expectations. For example, in a certain cycle, although the smoke concentration has decreased, it has not yet reached the safety threshold, and the convergence condition is not met. The system will not allow the device to enter a steady state but will immediately begin acquiring a new round of feedback data (which may show a slowdown in the concentration decrease trend), thereby calculating new deviations and possibly fine-tuning the fan power again, repeating this cycle until the concentration reaches the target.

[0071] The third step involves generating a task termination command and controlling the shutdown of all physical execution devices in response to the real-time data stream indicating that the received emergency has been handled. This response indicates the emergency has been handled, based on more comprehensive feedback or external instructions. This can be achieved through manual confirmation by a higher-level commander or automatic determination by the system based on broader rules (e.g., all disaster indicators have returned to normal for a certain period, and a "task completed" report is received from the on-site commander). Generating the task termination command can mean the system creates a global command to mark the end of the task. Controlling the shutdown of all physical execution devices can mean the system sequentially sends "stop," "shut down," or "return to normal standby mode" commands to all physical execution devices involved in the event. In practice, after receiving confirmation (manual or automatic), the execution entity first generates a task termination log record. Then, it iterates through the list of all driven physical execution devices in the event and sends stop commands in an orderly manner through their respective drive services. For example, the system can shut down smoke exhaust fans, stop all emergency broadcasts, switch lighting back to normal mode, close access control on open emergency exits, and restore normal power supply. The system then releases relevant control resources and generates a complete report of the handling process. For instance, the fire commander at the scene reports via the converged communication link: "The open flame has been extinguished, the hazard has been eliminated, and the situation is resolved." Upon receiving this message, the system automatically generates a task termination command. Subsequently, the system sequentially: 1) shuts down smoke exhaust fans, 2) stops emergency broadcasts and plays a "hazard cleared" message before silencing, 3) switches emergency lighting to normal lighting mode, 4) unlocks access control on evacuation routes, and 5) restores normal power supply to the mall's public areas. All devices cease operation, and the system's closed-loop control task ends.

[0072] The first to third steps and their sub-steps of this embodiment, as an inventive point of this embodiment, solve the technical problem that "existing emergency response lacks a continuous optimization closed loop based on real-time effect feedback, automatic deviation calculation, dynamic parameter adjustment, and intelligent judgment of convergence and termination after device activation, resulting in rigid open-loop control, unreliable effects, inability to adapt to dynamic situations, and unscientific termination." Existing technologies have the following shortcomings in post-execution control: Firstly, after device activation, it often operates in a preset mode or for a fixed duration, lacking real-time, quantitative monitoring and evaluation of its actual execution effect (such as whether smoke concentration decreases or personnel are evacuated); secondly, any necessary adjustments heavily rely on on-site personnel for manual observation, reporting, and re-instruction via communication links, resulting in low efficiency and poor reliability; thirdly, the entire execution process lacks an automated "perception-analysis-decision-execution" feedback adjustment loop, making precise and adaptive parameter fine-tuning impossible based on the degree of deviation from the target; and fourthly, the termination of the response process lacks intelligent judgment based on objective indicators (such as environmental indicators returning to safety or personnel evacuation being completed), often leading to premature cessation or over-operation. Solving the above problems will enable a fundamental shift in device execution from "open-loop blind operation" to "closed-loop intelligent control" throughout the entire treatment process, ensuring that each control action is continuously optimized based on effect feedback until the preset treatment goal is achieved safely and efficiently. To achieve this, this disclosure proposes the following sub-steps: First, (real-time acquisition of physical execution effect feedback data streams). This involves actively and continuously collecting environmental data streams (such as smoke concentration after exhaust and personnel density after broadcasting) reported by the field sensor network while the device performs its physical actions. This establishes a real and objective effect perception input for closed-loop control, solving the problem of the "unknowable and unmeasurable" intervention effect after device startup. Second, (generation of control deviation datasets). This involves using a deviation analysis engine to accurately compare and quantify the real-time feedback data with the expected targets (KPIs) of the control commands, generating a structured deviation dataset (such as concentration deviation values ​​and rate of decrease differences). This transforms the fuzzy judgment of "whether the effect meets the standard" into a precise and calculable numerical problem, solving the problem of lacking scientific and quantitative basis for control decisions. Third, (obtaining a dynamic adjustment instruction set). Therefore, by utilizing parameter adjustment controllers (such as PID controllers or rule engines), the optimized adjustment amount of the device operating parameters (such as fan speed and broadcast frequency) is intelligently calculated based on quantified deviation data, and new fine-tuning instructions are generated. This realizes the automatic generation from "effect evaluation" to "optimization strategy," solving the problem of blind adjustment relying on manual experience or fixed rules. The fourth sub-step (issuing the dynamic adjustment instruction set to each physical execution device).Thus, through the existing drive service network, fine-tuning instructions are reliably and promptly sent to the target device, and the drive device immediately operates according to the new parameters, ensuring that the optimization strategy can be quickly transformed into actual changes in the physical world, solving the delay problem of optimization decisions being "suspended in the air" and unable to be implemented. The fifth sub-step (controlling each physical execution device to maintain its current state). Thus, by running the convergence judgment logic, when real-time feedback data continuously meets preset convergence conditions such as safety and stability, the automatic control device enters a steady-state operation mode to maintain the current state, avoiding unnecessary adjustments or interventions after the goal has been achieved, solving the problem of resource waste and potential interference caused by over-control. The second step (re-executing the cyclic adjustment steps). Thus, a mandatory and uninterrupted optimization mechanism is established that "if the effect does not meet expectations, it will continuously monitor, analyze, and adjust in a cyclical manner," ensuring that the system can always adaptively track and optimize towards the preset goal when facing complex and dynamic emergencies, solving the problem that a single adjustment may be ineffective and the process cannot be continuously optimized. The third step (generating a task termination instruction and stopping the control device). Therefore, upon receiving confirmation of completion of macro-level handling, or automatically determining the end of the task based on broader rules, the system automatically generates a termination command and orderly and safely controls all related devices to stop working or return to normal operation. This achieves automated management of the entire lifecycle of the emergency response process, from initiation, optimization, steady-state operation to graceful exit, resolving issues of chaotic end-of-process operations and residual safety risks. In summary, the closed-loop control steps (steps one to three and their sub-steps) of this embodiment collaborate closely, constructing a complete, autonomous, adaptive control loop from "effect monitoring, deviation quantification, strategy generation, command issuance, steady-state maintenance to task termination." By creatively applying the closed-loop feedback principle of classical control theory to cross-departmental emergency collaborative handling scenarios, continuous, precise, and self-optimizing control of physical execution devices is achieved. This effectively overcomes the effect blind spots and rigidity defects of traditional open-loop control, significantly improving the scientific nature, adaptability, and reliability of the emergency response process, ensuring that each collaborative action intelligently approaches and locks in the optimal handling effect in a dynamic environment.

[0073] Optionally, the aforementioned implementing entity may also perform the following steps: Step one: In response to receiving planned task information, the planned task information is processed through structured parsing to obtain a task plan. This task plan includes information on sub-tasks, time nodes, responsible parties, and resource requirements. Each sub-task corresponds to a specific time node, and each sub-task corresponds to a specific responsible party. The planned task information can be predefined or issued by superiors, representing routine, periodic, or project-based work instructions requiring collaborative completion by multiple departments, such as security deployment for large-scale events, periodic maintenance of facilities and equipment, or joint exercise scripts. Structured parsing can be the process of automatically identifying and extracting key structured elements from the task information using natural language processing technology or parsing predefined formats (such as JSON, XML, or spreadsheets). The task plan is a digital task file generated after parsing, containing complete task decomposition and scheduling elements. Sub-tasks are the smallest work units with independent execution goals and deliverables obtained after the entire task decomposition. Time nodes are the planned start or mandatory completion times for each sub-task. The responsible party can be the organization, department, or individual responsible for executing or supervising the corresponding sub-task item. Resource requirement information can be a list of the types and quantities of communication, manpower, and material resources needed in advance to complete each sub-task item. In practice, the aforementioned executing entities can receive planned task information uploaded or filled in by users through their provided task import interfaces (such as web pages or APIs). Upon receiving the information, the system initiates a parsing process: for formatted files, it directly reads their row and column structure and maps it to fields; for unstructured text, it calls the built-in natural language processing function to identify keywords and entities describing tasks, times, responsible persons, and resources, and establishes the correspondence between them. The parsing process organizes all extracted elements according to a predetermined data model, forming a structured task plan data object, and persistently stores it in the system's task management database. For example, receiving a Word document instruction about "joint security operations in key areas during the National Day holiday," the system parses it, identifies the multiple work arrangements described within, and then generates a structured task plan. The plan includes the following sub-tasks: "October 1st, 08:00-12:00, Security check at the plaza entrance" (Time: October 1st, 08:00; Responsible party: Public Security Detachment; Resource requirements: 10 handheld security scanners, 5 350M digital walkie-talkies); "October 1st, 10:00-11:30, Patrol of the crowd gathering area" (Time: October 1st, 10:00; Responsible party: Special Police Detachment; Resource requirements: 2 patrol vehicles, 4 digital walkie-talkies). Each sub-task is clearly associated with a time frame, responsible party, and resources.

[0074] Step two involves matching the corresponding digital contingency plans from the digital contingency plan library based on the sub-task items in the task plan. Matching can be a process of searching and associating sub-task items within the digital contingency plan library according to their business nature, work content, and risk type. The corresponding digital contingency plans can be one or more digital contingency plans retrieved from the contingency plan library that match the business type or operational specifications of each sub-task item. These plans provide the process and rule basis for the standardized execution of planned tasks. In practice, the executing entity generates a set of search keywords (such as "security check" or "patrol") based on the text description or preset type tags of each sub-task item. The system uses the full-text search engine or category tag index of the digital contingency plan library to execute the search query and returns the most matching digital contingency plan based on relevance scores. The system associates and binds the returned contingency plan ID with the corresponding sub-task item and stores this association for subsequent steps. For example, for the sub-task item "Security Check at Plaza Entrance," the system searches using "security check" and "large-scale event" as keywords, and matches the digital contingency plan with ID "YA-2023-001" from the contingency plan database. Its title is "Standardized Operating Procedures for Security Checks of Personnel at Large-Scale Events." For the sub-task item "Patrol of Crowd Gathering Areas," the system searches using "patrol" and "dense crowds" as keywords, and matches the contingency plan with ID "YA-2023-002" entitled "Patrol of Dense Crowd Areas and Initial Response to Emergencies."

[0075] Step 3: Based on the matched digital contingency plans, establish communication links for each planned task. These communication links connect the command center and the responsible parties, and each corresponds to a sub-task item. Each planned task communication link can be a dedicated communication channel established before task execution, connecting the task command center and the responsible party, based on the command-reporting relationship defined in the matched digital contingency plan. Establishment can be a process of scheduling and binding specific communication terminals from the integrated communication resource pool according to the responsible party information, and pre-configuring a stable communication session or group. In practice, the executing entity performs the following operations for each sub-task item: First, read the responsible party information (e.g., "Public Security Detachment") from the task plan. Then, query the integrated communication resource pool for the communication resource identifiers (e.g., the detachment commander's dispatch console ID, group numbers of several digital walkie-talkies, mobile phone numbers or APP accounts of relevant personnel) of the personnel or positions typically responsible for such tasks under that responsible party. Next, the system's communication control function creates a logical communication group (such as a temporary call group or an instant messaging group) based on these resource identifiers, and sends "standby" or "pre-registration" instructions to these resources in advance, so that the communication link can be activated and used immediately when the subtask starts. Each subtask item has its own independent communication link configuration. For example, for the "security check at the plaza entrance" subtask item, the system queries the resource pool for the commander's seat ID (S-001) and the group number (G-101) of the 5 walkie-talkies in charge of this task from the security detachment. The system then creates a logical communication group named "security check command group", includes seat S-001 and walkie-talkie group G-101 in the group, and issues pre-configuration instructions. For the "patrol" subtask item, a communication link named "patrol command group" is established for the command vehicle terminal (V-005) and 4 walkie-talkies (G-102) of the patrol and special police detachment.

[0076] Step four involves pre-allocating the converged communication resource pool based on the matched digital contingency plans and the aforementioned resource requirements. This pre-allocation process involves logically "locking" or "reserving" the required resources in the converged communication resource pool before the actual task execution, based on the resource requirements in the task plan and the resource usage suggestions of the matched contingency plans. The resource pre-allocation scheme can be a detailed plan table recording which resources are reserved, within what time period, and for which sub-task item. In practice, the executing entity iterates through each sub-task item in the task plan. For each sub-task item, the system compares its resource requirements (e.g., "5 digital walkie-talkies") with the list of available resources matching that requirement type retrieved from the converged communication resource pool. The system selects a specific number of resource instances (e.g., walkie-talkies D001-D005) from the available list based on certain strategies (e.g., proximity, same model). It then sends a reservation request to the resource pool management service, requesting that the pre-allocation status be marked on the attributes of these resources and associated with the sub-task ID and reservation time window. After confirmation by the resource pool management service, the status of these resources is updated to "pre-allocated". All successful reservation records are aggregated to form a structured resource pre-allocation scheme. For example, for the sub-task item "Security Check at the Plaza Entrance", the system selects five walkie-talkies (D001, D002, D003, D004, and D005) from the available walkie-talkie list in the resource pool and reserves their usage rights from 08:00 to 12:00 on October 1st. For the sub-task item "Patrol", it reserves the usage rights of a patrol vehicle (license plate J-12345) and its vehicle-mounted terminal from 10:00 to 11:30 on October 1st. This reservation information is recorded in the resource pre-allocation scheme.

[0077] Step 5: In response to the arrival of the time node corresponding to any subtask item, execute the following steps. The "responding to the arrival of the time node" can be achieved by the system's built-in task scheduler continuously monitoring the system time. When the current system time matches the preset start time of a subtask item in the task plan, the subsequent execution logic for that subtask item is automatically triggered.

[0078] Sub-step one involves generating resource scheduling instructions based on the digital contingency plan corresponding to the aforementioned sub-task item and the aforementioned resource pre-allocation scheme. Generating resource scheduling instructions can refer to generating one or more executable instructions at the sub-task startup time, based on the standard operating procedures in the associated digital contingency plan and the specific resource identifiers reserved for the sub-task in the resource pre-allocation scheme, to actually drive and allocate these resources. In practice, when the task scheduler triggers a sub-task item, the system first loads the digital contingency plan associated with that sub-task item and parses the standard operating procedure description of its "startup phase." Simultaneously, it reads the list of specific resources reserved for the sub-task from the resource pre-allocation scheme (such as a list of walkie-talkie IDs and vehicle IDs). Then, the system's instruction generation function constructs executable instruction content based on the contingency plan steps and specific resource information. For example, if the contingency plan step is "distribute communication equipment to on-duty personnel and ensure it is online," the instruction content would be "command walkie-talkies D001-D005 to power on and automatically join the 'security inspection command group' communication link." For example, when the system time reaches 08:00 on October 1st, for the sub-task item "security check at the square entrance", the system generates two instructions: 1) a wireless device control instruction, which reads "instruct walkie-talkies D001, D002, D003, D004, and D005 to turn on and lock to group G-101 (security check command group)"; 2) a mobile application task push instruction, which reads "push the 'security check task start' notification and electronic checklist to seat S-001 (commander) and the associated police mobile phone APP".

[0079] Sub-step two involves sending the resource scheduling instructions to the responsible party corresponding to the sub-task through the planned task communication link corresponding to the sub-task item. This sending can refer to using the dedicated planned task communication link pre-established for this sub-task item in step three to send the resource scheduling instructions generated in sub-step one to the communication terminal held by the responsible party. In practice, the communication control function of the executing entity sends the instruction message through an established and standby communication link (such as the "Security Inspection Command Group" link), selecting an appropriate data channel (such as a signaling channel or accompanying data channel). For smart terminals, the instructions are parsed and displayed on the APP interface or trigger background actions; for traditional communication devices, the instructions may be converted into specific control signaling. For example, the system sends a wireless signaling containing a group addition instruction to walkie-talkies D001-D005 through the signaling channel of the "Security Inspection Command Group" communication link. Simultaneously, through the data channel of this link, the task details instruction is pushed as a message to the dispatch console interface of the commander's seat S-001 and the associated police mobile APP.

[0080] Step three involves receiving completion information for the corresponding sub-task item from the responsible party and recording that sub-task item. This completion information can be a proactive "task completed" confirmation from the responsible party via their terminal (e.g., a mobile app), or an automatic status determination by the system based on pre-defined completion conditions. Recording involves the system updating the sub-task item's status to "completed" in the task management database and storing process information such as completion time and feedback content. In practice, after the responsible party completes the operation on their terminal (e.g., clicking the "task completed" button in the app), the terminal sends a status confirmation message to the system via a communication link. Upon receiving this message, the system's task status management function verifies the sender's identity and the corresponding sub-task item, then updates the sub-task item's status field in the database from "in progress" to "completed," and records the completion timestamp and optional feedback information. For example, after completing all checks on the police mobile app, the security team leader clicks "Submit Complete, No Abnormalities." The app then sends this information back to the system via the communication link. After system verification, the status of the "Square Entrance Security Check" sub-task item will be updated to "Completed", the completion time will be recorded as "October 1, 11:50", and the note "No abnormality" will be stored.

[0081] Step Six: In response to the completion of all the above sub-task items, generate a planned task completion report corresponding to the planned task information, and release resources from the converged communication resource pool based on the above resource pre-allocation scheme. The completion of all the above sub-task items can be triggered when the system's task status management function detects that the status of all sub-task items in the task plan has been marked as "completed," thus initiating the task closure process. Generating a planned task completion report can mean that the system automatically summarizes the completion status of each sub-task item, resource usage records, time deviations, and other information to generate a structured task completion summary document. Releasing resources based on the above resource pre-allocation scheme can mean that the system, according to the reservation information recorded in the pre-allocation scheme, sends an instruction to the converged communication resource pool management service to change the logical status of all pre-allocated resources from "pre-allocated" or "in use" to "idle and available," thereby releasing the reservation. In practice, after the status of the last sub-task item is updated, the aforementioned executing entity initiates the report generation process: extracting the entire process data of this task from the task management database and logs, filling it into a preset report template, and generating a completion report (such as a PDF document). Simultaneously, the resource management function generates a batch of resource release instructions based on the resource pre-allocation plan and sends them to the converged communication resource pool management service. Upon receiving the instructions, the resource pool management service updates the status of all resources involved in the plan to "idle" and removes their association with the current task. For example, when both the sub-task items "security check at the square entrance" and "patrol of the mass assembly area" are completed, the system automatically generates a "National Day Security Joint Operation Task Completion Report," which includes a task overview, completion status of each location, actual resource usage statistics, and records of abnormal situations. At the same time, the system sends instructions to the resource pool to update the status of resources such as walkie-talkies D001-D005, patrol vehicle J-12345, and vehicle-mounted terminals to "idle," completing the resource release. The entire planned task collaborative command process ends.

[0082] Steps one through six of this disclosure are an inventive point of this disclosure, solving the technical problem that "the command and dispatch of existing planned tasks (such as large-scale event support and joint exercises) heavily rely on human experience for task decomposition, multi-party coordination, and resource allocation, resulting in cumbersome processes, low collaboration efficiency, frequent resource conflicts, and difficulty in process traceability." Existing technologies have the following shortcomings in the digitalization and automated collaboration of planned tasks: Firstly, task instructions are mostly issued in unstructured text or document form, requiring manual reading and understanding, and manual breakdown into specific sub-tasks, times, and responsible parties, which is labor-intensive and prone to errors; secondly, task execution lacks intelligent association with standard operating procedures (contingency plans), resulting in inconsistent action norms among responsible parties and uneven collaboration quality; thirdly, the establishment of communication and resource allocation are usually done manually just before the task begins, leading to insufficient preparation and potential chaos such as communication breakdowns and resource hoarding; and fourthly, the start, execution, and end status of the entire task highly depend on manual reporting and statistics, making the process opaque and difficult to control in real time and accurately review. Solving the above problems will enable "one-click" digital analysis of planned tasks, intelligent contingency plan matching, automated resource and communication preparation, and full-process status tracking and closed-loop management, achieving fully automated and standardized collaborative command from task issuance to completion report generation. To achieve this, this disclosure proposes the following steps: Step 1: In response to receiving planned task information, the information is structured and analyzed to obtain a task plan. Then, through natural language processing or template parsing technology, key structured elements such as sub-tasks, time nodes, responsible parties, and resource requirements are automatically identified and extracted from unstructured task instructions, forming a digital task plan. This solves the primary bottleneck problem of low efficiency and susceptibility to omissions and errors in manual task interpretation and decomposition. Step 2: Based on each sub-task item in the task plan, corresponding digital contingency plans are matched from the digital contingency plan library. Therefore, by leveraging the intelligent retrieval capabilities of the contingency plan database, the most suitable standardized operating procedures (digital contingency plans) are automatically associated with each sub-task item. This provides authoritative and unified operational rules for subsequent communication establishment, resource scheduling, and instruction generation, solving the problems of lack of standardized guidance and non-standardized collaborative actions in the execution of planned tasks. Step three: Based on the matched digital contingency plans, communication links for each planned task are established. Thus, before the actual start of the task, specific communication terminals are automatically scheduled and bound from the integrated communication resource pool according to the command relationships in the contingency plans. A dedicated communication group connecting the command center and the responsible party is pre-established for each sub-task item, ensuring that instructions can be delivered instantly and without delay when the task starts, solving the problems of delays and confusion caused by temporary communication establishment. Step four: Based on the matched digital contingency plans and the above-mentioned resource requirement information, the integrated communication resource pool is pre-allocated to obtain a resource pre-allocation scheme.Therefore, based on task requirements, the necessary communication equipment, vehicles, and other resources are logically locked and reserved in the resource pool, forming a precise resource allocation plan. This avoids resource contention and conflict between multiple tasks from the outset, ensuring a deterministic supply of resources for planned tasks. Step five: Upon reaching the time node corresponding to any sub-task item, resource scheduling and instruction issuance are automatically executed. Thus, through the built-in task scheduler, it automatically triggers at preset time points, combining pre-planned steps and pre-allocated specific resources to generate and issue executable start instructions to the corresponding responsible parties, achieving "timely and automatic" task execution and overcoming the shortcomings of manual triggering, such as easy forgetting and asynchrony. Step six: Upon completion of recording for all the above sub-task items, a planned task completion report is generated and resource release is performed. Thus, after all sub-tasks have been reported, the system automatically summarizes the entire process data to generate a structured report and simultaneously releases all pre-allocated resources, realizing digital closed-loop management of the entire task lifecycle and timely recycling and reuse of resources, solving the problems of difficulty in post-event review and legacy resource occupation. In summary, the planned task collaborative command steps (steps one to six) of this embodiment are closely linked, forming a complete automated pipeline of "intelligent task analysis - automatic plan matching - communication resource pre-setting - time-driven execution - automatic status feedback - report generation and resource release". By extending emergency command capabilities for sudden events to the realm of planned tasks, it achieves full coverage of both normal and emergency command scenarios. This solution transforms the traditional planned task organization work, which relies heavily on manual coordination, into a highly efficient model driven by data, guided by rules, and executed automatically by the system, improving the preparation efficiency, execution standardization, and process controllability of large-scale collaborative tasks.

[0083] The above-mentioned technical solution of the present invention has the following beneficial effects: Through the collaborative command method of the present invention, which is designed for both normal and emergency use, it is possible to achieve integrated fusion of cross-departmental and cross-level resources, intelligent contingency plan matching, and visualized collaborative scheduling, thereby improving the command efficiency of routine management and emergency response. Specifically, the traditional command model relies on decentralized and independent communication and consultation systems, which may face problems such as insufficient resource sharing leading to "information silos," inconsistent data standards leading to difficulties in situational awareness, and system fragmentation leading to delayed collaborative response. If only point-to-point communication and manual coordination are relied upon, it will be difficult to quickly integrate information, accurately match contingency plans, and efficiently coordinate multiple forces in emergencies. Based on this, the collaborative command method of the present invention firstly connects various heterogeneous external communication systems and various monitoring devices to obtain a unified communication resource pool. Thus, through protocol adaptation and unified access, heterogeneous resources such as voice, wireless, video, and mobile terminals are integrated into a unified resource pool that can be scheduled on demand, breaking down departmental barriers and "information silos" from the source, and laying the material foundation for subsequent unified command. Secondly, based on the above-mentioned unified communication resource pool, a digital contingency plan library is constructed. Therefore, textual and experience-based emergency plans are structured, digitized, and tagged to form a searchable, associative, and executable knowledge base. This solves the problems of slow plan searching, cumbersome content, and disconnect from actual resources in traditional plans, providing core decision-making basis for intelligent response. Next, upon receiving emergency information, the system generates a target digital plan based on the received information and the aforementioned digital plan database. Thus, the system can intelligently match and activate the most suitable emergency plan based on the type, level, and location of the event, realizing a shift from "people searching for plans" to "plans finding people," significantly shortening emergency response decision-making time. Then, based on the aforementioned target digital plan, a converged communication link is established. Based on the predefined command relationships in the plan, a communication channel connecting the command center, on-site personnel, and relevant departments is quickly constructed, ensuring that cross-level and cross-departmental instructions can be issued with one click and that communication is guaranteed to reach the recipient, solving the problem of poor coordination caused by the independent communication systems and inconsistent coverage in the traditional model. Finally, based on the aforementioned converged communication resource pool, a converged communication map is constructed. Therefore, by overlaying and rendering resources associated with the contingency plan, real-time alarm information, and geospatial information, a comprehensive three-dimensional command view is formed, enabling a holistic and intuitive grasp of resources, impact range, and response capabilities related to emergencies. This effectively overcomes the problem of incomplete situational awareness caused by data fragmentation. Subsequently, in response to the recognition that a user has performed a dispatch operation through the aforementioned converged communication map, the system generates various dispatch instructions corresponding to the aforementioned digital contingency plan. Thus, after the commander performs intuitive operations such as selecting boxes and points on the visual map, the system can automatically transform these into specific and executable dispatch instructions based on the contingency plan logic, achieving intelligent assisted decision-making with "humans in the loop," and improving the scientific nature and efficiency of command.Finally, through the aforementioned integrated communication links, cross-departmental collaborative responses are executed based on the various dispatch instructions. This allows the generated instructions to be precisely and synchronously distributed to all responsible parties via the established unified communication links, driving relevant departments and resources to act collaboratively according to the contingency plan. Ultimately, this achieves an integrated, highly efficient closed-loop response from perception, decision-making, dispatching to execution. Furthermore, because this method employs a platform-based, structured, and intelligent design in core aspects such as resource integration, contingency plan management, communication establishment, situational awareness, and instruction generation, it can effectively adapt to diverse command scenarios ranging from routine planned tasks to sudden emergency events (i.e., "dual-use"). By driving the automatic association of resources and communications through digital contingency plans and enabling visualized interactive dispatching based on a single map, the coordination, response speed, and accuracy of multi-departmental joint actions are improved, providing methodological support for building a smart and efficient urban collaborative command system.

[0084] Further reference Figure 2 As an implementation of the methods shown in the above figures, this disclosure provides some embodiments of a collaborative command device for both peacetime and emergency use. These device embodiments are similar to... Figure 1 Corresponding to the method embodiments shown, the device can be specifically applied to various electronic devices.

[0085] like Figure 2 As shown, some embodiments of the collaborative command device 200 for both peacetime and emergency use include: docking unit 201, first construction unit 202, first generation unit 203, establishment unit 204, second construction unit 205, second generation unit 206, and execution unit 207. The system comprises the following components: a docking unit 201, configured to dock with various heterogeneous external communication systems and monitoring devices to obtain a converged communication resource pool; a first construction unit 202, configured to construct a digital contingency plan library based on the converged communication resource pool; a first generation unit 203, configured to generate a target digital contingency plan in response to receiving emergency information, based on the received emergency information and the digital contingency plan library; an establishment unit 204, configured to establish a converged communication link based on the target digital contingency plan, wherein the converged communication link is used to connect the command center, at least one on-site response party, and various related departments; a second construction unit 205, configured to construct a converged communication map based on the converged communication resource pool, wherein the converged communication map presents various resources related to the received emergency and the spatial distribution of each resource; a second generation unit 206, configured to generate various dispatch instructions corresponding to the dispatch operation based on the target digital contingency plan in response to recognizing that a user has performed a dispatch operation through the converged communication map; and an execution unit 207, configured to execute cross-departmental collaborative response based on the various dispatch instructions through the converged communication link.

[0086] It is understandable that the units described in the device 200 are related to the reference. Figure 1 The steps in the described method correspond to each other. Therefore, the operations, features, and beneficial effects described above for the method also apply to the device 200 and the units contained therein, and will not be repeated here.

[0087] The following is for reference. Figure 3 It shows a schematic diagram of the structure of an electronic device 300 suitable for implementing some embodiments of the present disclosure. Figure 3 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of this disclosure.

[0088] like Figure 3 As shown, the electronic device 300 may include a processing unit 301 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 302 or a program loaded from a storage device 308 into a random access memory (RAM) 303. The RAM 303 also stores various programs and data required for the operation of the electronic device 300. The processing unit 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0089] Typically, the following devices can be connected to I / O interface 305: input devices 306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; and communication devices 309. Communication device 309 allows electronic device 300 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3 An electronic device 300 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively. Figure 3 Each box shown can represent a device or multiple devices as needed.

[0090] In particular, according to some embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, some embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 309, or installed from storage device 308, or installed from ROM 302. When the computer program is executed by processing device 301, it performs the functions defined in the methods of some embodiments of this disclosure.

[0091] It should be noted that, in some embodiments of this disclosure, the computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In some embodiments of this disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In some embodiments of this disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0092] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0093] The aforementioned computer-readable medium may be included within the aforementioned electronic device; or it may exist independently without being assembled into the electronic device. The aforementioned computer-readable medium carries one or more programs that, when executed by the electronic device, cause the electronic device to: interface with various heterogeneous external communication systems and various monitoring devices to obtain a converged communication resource pool; construct a digital contingency plan library based on the converged communication resource pool; in response to receiving emergency information, generate a target digital contingency plan based on the received emergency information and the aforementioned digital contingency plan library; establish a converged communication link based on the aforementioned target digital contingency plan, wherein the converged communication link is used to connect the command center, at least one on-site response party, and various related departments; construct a converged communication map based on the aforementioned converged communication resource pool, wherein the converged communication map presents various resources related to the received emergency and the spatial distribution of each resource; in response to recognizing that a user has performed a scheduling operation through the aforementioned converged communication map, generate various scheduling instructions corresponding to the aforementioned scheduling operation based on the aforementioned target digital contingency plan; and execute cross-departmental collaborative response based on the aforementioned scheduling instructions through the aforementioned converged communication link.

[0094] Computer program code for performing operations of some embodiments of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0095] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0096] The units described in some embodiments of this disclosure can be implemented in software or hardware. The described units can also be housed in a processor; for example, a processor may be described as including a docking unit, a first building unit, a first generating unit, an establishment unit, a second building unit, a second generating unit, and an execution unit. The names of these units do not necessarily limit the unit itself; for example, a docking unit may also be described as "a unit that docks with various heterogeneous external communication systems and various monitoring devices to obtain a converged communication resource pool."

[0097] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0098] Some embodiments of this disclosure also provide a computer program product, including a computer program that, when executed by a processor, implements any of the above-described collaborative command methods for both peacetime and emergency use.

[0099] The above description is merely a selection of preferred embodiments of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. A collaborative command method for both peacetime and emergency use, comprising: By connecting various heterogeneous external communication systems and monitoring devices, a unified communication resource pool is obtained; Based on the aforementioned converged communication resource pool, a digital contingency plan database will be constructed; In response to receiving emergency information, a target digital emergency plan is generated based on the received emergency information and the digital emergency plan database; Based on the aforementioned digital contingency plan, a converged communication link is established, wherein the converged communication link is used to connect the command center, at least one on-site response party, and various related departments; Based on the converged communication resource pool, a converged communication map is constructed, wherein the converged communication map presents various resources related to the received emergencies and the spatial distribution of each resource; In response to the recognition that a user has performed a scheduling operation through the converged communication map, various scheduling instructions corresponding to the scheduling operation are generated according to the target digital contingency plan. Cross-departmental collaborative processing is performed through the converged communication link based on the various scheduling instructions; In response to receiving planned task information, the planned task information is processed by structured parsing to obtain a task plan, wherein the task plan includes each sub-task item, each time node, each responsible party and resource requirement information, each sub-task item corresponds to each time node, and each sub-task item corresponds to each responsible party; Based on each sub-task item in the task plan, match the corresponding digital contingency plans from the digital contingency plan library; Based on the matched digital contingency plans, communication links for each planned task are established, wherein each planned task communication link is used to connect the command center and each responsible party, and each planned task communication link corresponds to each sub-task item. Based on the matched digital contingency plans and the resource demand information, the converged communication resource pool is pre-allocated to obtain a resource pre-allocation scheme. In response to the arrival of the time node corresponding to any subtask item, perform the following steps: Based on the digital contingency plan corresponding to the sub-task item and the resource pre-allocation scheme, a resource scheduling instruction is generated; The resource scheduling instruction is sent to the responsible party corresponding to the sub-task through the planned task communication link corresponding to the sub-task item; In response to receiving completion information for the corresponding sub-task item from the responsible party, the sub-task item is recorded; In response to the completion of recording for each of the sub-task items, a planned task completion report corresponding to the planned task information is generated, and resource release processing is performed on the converged communication resource pool based on the resource pre-allocation scheme.

2. The method according to claim 1, wherein, The process of connecting various heterogeneous external communication systems and monitoring devices yields a unified communication resource pool, including: Protocol adaptation processing is performed on the voice communication system and the wireless trunking system to obtain unified signaling resources; Standardized video resources are obtained by performing national standard access processing on various video surveillance devices; Access processing is performed on portable mobile terminals and vehicle-mounted terminals to obtain controllable mobile resources; The unified signaling resources, standardized video resources, and controllable mobile resources are aggregated and processed to obtain a converged communication resource pool.

3. The method according to claim 1, wherein, The construction of a digital contingency plan library based on the converged communication resource pool includes: The pre-defined emergency classification system is templated to obtain various structured contingency plan templates; Extract elements from historical emergency plans and pre-set text plans to obtain digital plan elements; The structured contingency plan templates and digital contingency plan elements are digitally edited to obtain executable digital contingency plans. The executable digital contingency plans are classified and processed to obtain a digital contingency plan library.

4. The method according to claim 1, wherein, The step of generating a target digital contingency plan based on the received emergency information and the digital contingency plan database includes: The received emergency information is processed by feature recognition to obtain type information, level information and location information; Based on the type information and the level information, a preliminary retrieval process is performed on the digital contingency plan database to obtain each candidate digital contingency plan; Obtain real-time resource status information; Based on the location information and the acquired real-time resource status information, the candidate digital contingency plans are optimized and evaluated to obtain an optimized contingency plan sequence. The optimized contingency plan sequence is processed to obtain the target digital contingency plan.

5. The method according to claim 1, wherein, The construction of the converged communication map based on the converged communication resource pool includes: In the converged communication resource pool, resources related to the received emergencies are filtered to obtain an initial target resource set, wherein the initial target resource set includes the resources associated with the target digital contingency plan; The initial target resource set is subjected to availability verification to obtain an available resource set; Extract the geospatial information of each resource in the available resource set to obtain a resource coordinate dataset; Based on the resource coordinate dataset, the base map of basic geographic information is rendered to obtain a basic resource distribution layer; Obtain real-time alarm information and data on the scope of event impact; The real-time alarm information and the event impact range data are overlaid onto the basic resource distribution layer to obtain an enhanced situational awareness layer. The enhanced situational awareness layer is integrated with functional interfaces to obtain a fused communication map.

6. A collaborative command device for both peacetime and emergency use, comprising: The docking unit is configured to dock with various heterogeneous external communication systems and various monitoring devices to obtain a converged communication resource pool; The first construction unit is configured to build a digital contingency plan library based on the converged communication resource pool; The first generation unit is configured to generate a target digital contingency plan in response to receiving emergency information, based on the received emergency information and the digital contingency plan database. The first establishment unit is configured to establish a converged communication link based on the target digital contingency plan, wherein the converged communication link is used to connect the command center, at least one on-site response party, and various related departments; The second construction unit is configured to construct a converged communication map based on the converged communication resource pool, wherein the converged communication map presents various resources related to the received emergencies and the spatial distribution of each resource; The second generation unit is configured to, in response to recognizing that a user has performed a scheduling operation through the converged communication map, generate various scheduling instructions corresponding to the scheduling operation according to the target digitization plan; The first execution unit is configured to perform cross-departmental collaborative processing based on the various scheduling instructions via the converged communication link; The parsing unit is configured to, in response to receiving planned task information, perform structured parsing processing on the planned task information to obtain a task plan, wherein the task plan includes each sub-task item, each time node, each responsible party, and resource requirement information, wherein each sub-task item corresponds to each time node, and each sub-task item corresponds to each responsible party; The matching unit is configured to match corresponding digital contingency plans from the digital contingency plan library based on each sub-task item in the task plan. The second establishment unit is configured to establish communication links for each planned task based on the matched digital contingency plans. The communication links for each planned task are used to connect the command center and the responsible parties. Each communication link for each planned task corresponds to the respective sub-task item. The allocation unit is configured to pre-allocate the converged communication resource pool based on the matched digital plans and the resource demand information to obtain a resource pre-allocation scheme. The second execution unit is configured to perform the following steps in response to the arrival of the time node corresponding to any subtask item: Based on the digital contingency plan corresponding to the sub-task item and the resource pre-allocation scheme, a resource scheduling instruction is generated; The resource scheduling instruction is sent to the responsible party corresponding to the sub-task through the planned task communication link corresponding to the sub-task item; In response to receiving completion information for the corresponding sub-task item from the responsible party, the sub-task item is recorded; The processing unit is configured to generate a planned task completion report corresponding to the planned task information in response to the completion of recording of each of the sub-task items, and to perform resource release processing on the converged communication resource pool based on the resource pre-allocation scheme.

7. An electronic device, comprising: One or more processors; A storage device on which one or more programs are stored; When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1 to 5.

8. A computer-readable medium having a computer program stored thereon, wherein, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 5.

Images