Emergency equipment intelligent sensing system and method thereof

Abstract

The invention relates to the technical field of equipment intelligent sensing, and discloses an emergency equipment intelligent sensing system and method, and the method comprises the steps: collecting data at an equipment end, storing the data to a PLC, connecting an intelligent communication module with the PLC, analyzing the data returned by the PLC into a JSON format message, and publishing the JSON format message to a server through an MQTT protocol; the application side selects a plurality of device identifiers and specifies a batch control task template, sends a task execution request to the server side, and generates a device-level control instruction queue; the server side issues a control message to a plurality of devices in the device-level control instruction queue, the intelligent communication module receives the control message, constructs a write-in request frame, sends the write-in request frame to the PLC and returns an execution response frame, and the intelligent communication module analyzes the execution response frame, extracts a feedback message and reports the feedback message to the server side; according to the method, the user can master the execution condition of the batch control tasks in real time, so that the intelligent, batch and credible management of the emergency equipment is realized.

Description

Technical Field

[0001] This invention relates to the field of intelligent sensing technology for equipment, and in particular to an intelligent sensing system and method for emergency equipment. Background Technology

[0002] Traditional emergency equipment management cannot monitor key operating parameters such as battery power, fuel tank level, and equipment tilt angle in real time, making it difficult to detect equipment malfunctions in a timely manner and affecting emergency response efficiency. When an emergency scenario requires the simultaneous activation of multiple lighting vehicles, generator vehicles, and other equipment, operators must perform operations such as powering on each device, starting the generator, and turning on the lights one by one. This is labor-intensive and slow, making it difficult to meet emergency dispatch needs. Summary of the Invention

[0003] This invention provides an intelligent sensing system and method for emergency equipment. This invention enables users to monitor the execution status of batch control tasks in real time, thereby realizing intelligent, batch, and reliable management of emergency equipment.

[0004] In a first aspect, the present invention provides an intelligent sensing method for emergency equipment, the intelligent sensing method for emergency equipment comprising: Data is collected at the device end and stored in the PLC. The intelligent communication module connects to the PLC, parses the data returned by the PLC into JSON format messages and publishes them to the server using the MQTT protocol. The server receives the JSON format message, configures the batch control task template, the application selects multiple device identifiers and specifies the batch control task template, sends a task execution request to the server, and generates a device-level control instruction queue. The server publishes control messages to multiple devices in the device-level control instruction queue. The intelligent communication module receives the control messages, constructs a write request frame, sends it to the PLC, and returns an execution response frame. The intelligent communication module parses the execution response frame, extracts feedback messages, and reports them to the server.

[0005] In conjunction with the first aspect, in a first implementation of the first aspect of the present invention, data is collected at the device end, the data is stored in a PLC, an intelligent communication module connects to the PLC, and the data returned by the PLC is parsed into a JSON format message and published to the server using the MQTT protocol, including: At the device end, data is collected through a sensor network and transmitted to a PLC, which stores the data in a DB data block according to a preset address mapping rule. The intelligent communication module connects to the PLC, periodically sends read request frames to the PLC, parses the data returned by the PLC into JSON format messages, and publishes them to the server using the MQTT protocol.

[0006] In conjunction with the first aspect, in a second implementation of the first aspect of the present invention, the intelligent communication module connects to the PLC, periodically sends read request frames to the PLC, parses the data returned by the PLC into a JSON format message, and publishes it to the server using the MQTT protocol, including: The intelligent communication module is connected to the PLC. The intelligent communication module periodically constructs read request frames and sends them to the PLC. It receives the data returned by the PLC and parses it into physical quantity values. The physical quantity value is encapsulated into a JSON format message. The intelligent communication module connects to the MQTT broker server via a 4G network and constructs an MQTT publish message, which is then published to the corresponding MQTT topic on the server.

[0007] In conjunction with the first aspect, in a third implementation of the first aspect of the present invention, the server receives the JSON format message, configures a batch control task template, the application selects multiple device identifiers and specifies the batch control task template, sends a task execution request to the server, and generates a device-level control instruction queue, including: The server receives the JSON format message and checks whether the physical quantity value is within the valid range of the physical quantity. The data that passes the check is converted into a real-time data table of the device. When the server creates a batch control task template, it encapsulates multiple device identifiers into a device list JSON array and multiple control operations into an operation sequence JSON array. The device list JSON array and the operation sequence JSON array are then stored together with the task identifier and task name in the batch task table. The application selects multiple device identifiers and specifies the batch control task template, and sends a task execution request to the server to generate a device-level control instruction queue.

[0008] In conjunction with the first aspect, in the fourth implementation of the first aspect of the present invention, the application selects multiple device identifiers and specifies the batch control task template, and sends a task execution request to the server to generate a device-level control instruction queue, including: On the device list page, the application selects multiple device identifiers and chooses a pre-configured batch control task template, then sends a task execution request to the server. The server receives the task execution request, queries the task details corresponding to the task identifier from the batch task table, extracts multiple device identifiers from the device list JSON array and multiple operation steps from the operation sequence JSON array, and generates a device-level control instruction queue.

[0009] In conjunction with the first aspect, in the fifth implementation of the first aspect of the present invention, the server publishes control messages to multiple devices in the device-level control instruction queue, the intelligent communication module receives the control messages and constructs a write request frame to send to the PLC, returns an execution response frame, and the intelligent communication module parses the execution response frame, extracts feedback messages, and reports them to the server, including: The server extracts multiple instruction records with the same step number from the device-level control instruction queue, constructs a corresponding MQTT topic name based on the device identifier in the instruction record, and concurrently publishes control messages to the MQTT topic name through the message queue; The intelligent communication module receives the control message, constructs a write request frame and sends it to the PLC. The PLC drives the corresponding relay or intelligent circuit breaker to perform on / off actions and returns an execution response frame to the intelligent communication module. The intelligent communication module receives the execution response frame, parses the return code in the execution response frame to determine whether the execution status is successful or failed, encapsulates it into a feedback message, and reports it to the server via the MQTT protocol.

[0010] In conjunction with the first aspect, in a sixth implementation of the first aspect of the present invention, the intelligent communication module receives the control message, constructs a write request frame and sends it to the PLC, the PLC drives the corresponding relay or intelligent circuit breaker to perform an on / off action, and returns an execution response frame to the intelligent communication module, including: The intelligent communication module receives the control message and parses the PLC address field and write value field in the control message. According to the preset address mapping table, it maps the PLC address field to the corresponding relay or intelligent circuit breaker in the output area. The intelligent communication module constructs a write request frame and sends the write request frame to the PLC. The PLC receives the write request frame and drives the corresponding relay or intelligent circuit breaker to perform on / off actions. After completing the on / off control, the PLC constructs an execution response frame and sends it to the intelligent communication module.

[0011] In conjunction with the first aspect, in the seventh implementation of the first aspect of the present invention, after extracting the feedback message and reporting it to the server, it further includes: The server receives the feedback message and extracts the task progress message from the feedback message; The server pushes the task progress message to the application. After receiving the task progress message, the application parses the progress percentage and updates the display value of the progress bar component. When the server determines that the progress percentage has reached 100%, it confirms that the task is completed and constructs the operation data structure.

[0012] In conjunction with the first aspect, in the eighth implementation of the first aspect of the present invention, after the server determines that the task is completed when the progress percentage reaches 100%, and after constructing the operation data structure, it further includes: The blockchain client node on the server performs a hash operation on the operational data structure to obtain a hash value, and constructs blockchain transaction data based on the hash value; The blockchain client node broadcasts the blockchain transaction data to multiple consensus nodes in the consortium blockchain network. After receiving the blockchain transaction data, the consensus nodes verify the transaction format and signature validity. After successful verification, the blockchain transaction data is packaged into a new block, the new block is appended to the end of the distributed ledger blockchain to complete the on-chain process, and the transaction hash value is returned to the server.

[0013] Secondly, the present invention provides an intelligent sensing system for emergency equipment, the intelligent sensing system for emergency equipment comprising: The data acquisition module is used to collect data at the device end and store the data in the PLC. The intelligent communication module connects to the PLC, parses the data returned by the PLC into JSON format messages and publishes them to the server using the MQTT protocol. The task control module is used for the server to receive the JSON format message, configure the batch control task template, the application to select multiple device identifiers and specify the batch control task template, send a task execution request to the server, and generate a device-level control instruction queue. The response feedback module is used by the server to publish control messages to multiple devices in the device-level control instruction queue. The intelligent communication module receives the control messages, constructs a write request frame and sends it to the PLC, and returns an execution response frame. The intelligent communication module parses the execution response frame, extracts feedback messages and reports them to the server.

[0014] The technical solution provided by this invention constructs a three-layer architecture consisting of the device side, server side, and application side. At the device side, a complete local control loop is established for sensors, PLCs, and relays, enabling the device to operate on-site even during network interruptions. Simultaneously, remote data transmission and control command issuance are achieved through the 4G+S7Comm dual-layer protocol conversion of the intelligent communication module. The server side automatically generates a device-level control command queue by expanding the device list and operation sequence of the batch control task template using a Cartesian product. This queue, combined with a message queue, enables concurrent command issuance to multiple devices, significantly improving batch operation efficiency compared to traditional sequential control methods. The intelligent communication module records and reports the reception and completion timestamps of each command in real time. The server then calculates the number of successes, failures, and progress percentages and pushes them to the application side via WebSocket to dynamically refresh the progress bar and device status icons, allowing users to monitor the execution status of batch control tasks in real time. After task completion, the operation data is hashed using SHA256 and written to a distributed ledger via a blockchain smart contract. The immutability of the blockchain ensures the authenticity and traceability of device operation records, thereby achieving intelligent, batch, and reliable management of emergency equipment.

[0015] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained in accordance with the structures particularly pointed out in the description, claims and drawings.

[0016] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of one embodiment of the intelligent sensing method for emergency equipment in this invention. Figure 2 This is a schematic diagram of one embodiment of the intelligent sensing system for emergency equipment in this invention. Figure 3 This is a schematic diagram of the intelligent sensing system architecture for emergency equipment in an embodiment of the present invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] The terms "comprising" and "having," and any variations thereof, used in the embodiments of this invention are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the steps or units listed, but may optionally include other steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0020] To facilitate understanding of this embodiment, a detailed description of an intelligent sensing method for emergency equipment disclosed in this invention will be provided first. For example... Figure 1 As shown, this method includes the following steps: 101. Collect data at the device end, store the data in the PLC, connect the intelligent communication module to the PLC, parse the data returned by the PLC into JSON format messages and publish them to the server using the MQTT protocol; 102. The server receives a JSON message, configures a batch control task template, and the application selects multiple device identifiers and specifies the batch control task template. It then sends a task execution request to the server and generates a device-level control instruction queue. 103. The server publishes control messages to multiple devices in the device-level control instruction queue. The intelligent communication module receives the control messages, constructs a write request frame, sends it to the PLC, and returns an execution response frame. The intelligent communication module parses the execution response frame, extracts the feedback message, and reports it to the server.

[0021] In one specific embodiment, data is collected at the device end, stored in the PLC, and the intelligent communication module connects to the PLC, parses the data returned by the PLC into JSON format messages, and publishes them to the server using the MQTT protocol, including: On the device side, data is collected through a sensor network and transmitted to the PLC. The PLC stores the data in the DB data block according to the preset address mapping rules. The intelligent communication module connects to the PLC, periodically sends read request frames to the PLC, parses the data returned by the PLC into JSON format messages, and publishes them to the server using the MQTT protocol.

[0022] Specifically, an alarm system deploys a sensor network containing multiple types of sensors. This sensor network covers the environment and operating parameters involved in the equipment's operation, including temperature sensors, barometric pressure sensors, and tilt sensors to collect external environmental data, and current sensors, voltage sensors, fuel level sensors, support leg force sensors, and power monitoring modules to obtain the real-time operating status of the equipment. All sensors are connected to the PLC's serial input channel via RS-485 or RS-232 industrial bus protocols. The PLC centrally receives signals from each sensor and performs data parsing and structured processing. After data reception, the PLC allocates the sensor data to different byte offset positions in the internal DB data block according to the preset address mapping rules. For example, the battery charge is stored in DB1.DBD0 address, the equipment tilt angle is written to DB1.DBD4 address, and the obstacle distance is written to DB1.DBD8 address. This ensures that all sensor data forms a unified, clearly defined, and indexable data model within the PLC. Meanwhile, to enable remote transmission of equipment status, an intelligent communication module is deployed in the system. The intelligent communication module establishes a TCP / IP connection channel with the PLC through an Ethernet interface and adopts the Siemens S7Comm protocol as the application layer data interaction protocol. The intelligent communication module integrates a timed scheduling mechanism and a data synchronization strategy. Within the set acquisition cycle, it actively generates a read request frame of the S7Comm protocol. The request frame carries the read function code (such as 0x04) and the target address parameter, pointing to the starting address of the DB data block inside the PLC, and defines the read length range (for example, reading a continuous area of ​​64 bytes starting from DB1.DBD0). The request frame is sent to port 102 of the PLC, which parses it and returns a response data frame containing the current status data of the equipment. The data frame is in binary form and is encapsulated in Siemens S7 format. After receiving the returned data frame, the intelligent communication module unpacks each field and parses it into actual physical quantity values ​​according to the IEEE 754 floating-point standard. Then, it constructs a standardized JSON structure message body, which contains the device's unique identifier, the acquisition timestamp, and key-value pair descriptions of all acquired fields. The JSON message is published to a topic named after the device ID using the MQTT protocol's PUBLISH method, and the QoS level is set to 1 to ensure reliable message delivery. After the server subscribes to this topic, it can obtain the device status in real time.

[0023] Before data collection at the device end, the process includes: the application sending a one-click self-test request containing the device identifier and self-test type to the server; the server constructing a self-test start command and sending it to the intelligent communication module corresponding to the device identifier via the MQTT protocol; after receiving the self-test start command, the intelligent communication module writes the self-test program start flag to the PLC; the PLC sequentially executes the preset test process of power self-test, voltage and current detection, lamp lighting test, support leg movement test, and sensor data acquisition, and records the pass or failure status code of each test item; the PLC uploads the test results, including the number of pass items, the number of failure items, and the list of abnormal items, to the server; the server generates a self-test report and pushes it to the application for display.

[0024] In one specific embodiment, the intelligent communication module connects to the PLC, periodically sends read request frames to the PLC, parses the data returned by the PLC into JSON format messages, and publishes them to the server using the MQTT protocol, including: The intelligent communication module connects to the PLC. The intelligent communication module periodically constructs read request frames and sends them to the PLC. It receives the data returned by the PLC and parses it into physical quantity values. The physical quantity values ​​are encapsulated into JSON format messages. The intelligent communication module connects to the MQTT broker server via the 4G network and constructs an MQTT publish message, which is then published to the corresponding MQTT topic on the server.

[0025] Specifically, an Ethernet connection is established between the intelligent communication module and the PLC on the device side via a network cable, forming a stable local TCP / IP communication channel. The intelligent communication module has a pre-installed S7Comm protocol communication stack, enabling it to initiate standard industrial protocol read / write requests to the PLC. The intelligent communication module starts an internal timer task according to a set time period, dynamically constructing a read request frame according to the S7Comm protocol format. The request frame specifies the read function code (e.g., function code 0x04 indicates a read operation), the target data block type (e.g., DB block), the starting byte address (e.g., DB1.DBD0), and the length of bytes to be read consecutively (e.g., 64 bytes). The request frame is then sent to the PLC's standard communication port (port 102) through the established TCP connection. After receiving the request, the PLC locates the internal data block according to the request parameters and reads the data in the corresponding address range. It then encapsulates the result into a response frame and returns it to the intelligent communication module. Upon receiving the binary data frame, the intelligent communication module initiates the parsing process. Based on the address mapping rules of each field in the PLC, it extracts key segments and reconstructs the actual physical quantities such as battery power, tilt angle, equipment input voltage, current value, and fuel tank level segment by segment according to the IEEE 754 floating-point format. After data parsing, the intelligent communication module encapsulates each physical quantity field along with the device ID and timestamp into a JSON message body with a standard key-value pair structure. It then activates the built-in 4G communication module to establish a network connection with the server-side MQTT broker. The connection uses TLS encryption to ensure data transmission security. After establishing the connection and completing authentication, the intelligent communication module constructs and publishes a message based on the MQTT protocol, specifying the publishing topic as a path named after the device ID, the message body as a JSON structure, and the message service level (QoS) set to 1 to ensure at least one transmission. The message is then completely sent to the MQTT broker server via the MQTT PUBLISH command for reception and processing.

[0026] When the device identifier selected by the application belongs to another user, before sending the task execution request to the server, the process includes: the application initiating a device authorization request, which includes the lender's user identifier, the borrower's user identifier, the device identifier, the authorization duration, and the scope of permissions; the server constructing a smart contract transaction and setting the authorization start time to the current timestamp and the authorization end time to the current timestamp plus the authorization duration; the server broadcasting the smart contract transaction to the blockchain network; after the smart contract verifies that the lender's user identifier owns the device identifier, it stores the authorization record on the chain; the server simultaneously inserts an authorization record containing the borrower's user identifier, the device identifier, and the authorization end time into the device authorization table; the smart contract checks the authorization end time of the authorization record when each new block is generated; if the authorization end time is earlier than the current block timestamp, it automatically deletes the authorization record and triggers a callback to notify the server; the server updates the status field of the corresponding record in the device authorization table to expired.

[0027] Before selecting multiple device identifiers on the application side, the process includes: the application side inputting emergency event information containing event type, event location latitude and longitude coordinates, and a demand description text; the server side calling the natural language processing module to extract keywords from the demand description text, retrieving similar event records from the historical rescue database based on the keywords, and extracting a list of device types and device quantity statistics used in the similar event records; the server side calling the meteorological API to obtain real-time weather data for the event location, including rainfall and wind speed, and calling the traffic condition API to obtain the traffic congestion index for the event location; adaptively filtering the device type list based on the weather data and traffic congestion index, excluding device types unsuitable for the current weather conditions; the server side querying the available devices corresponding to the device type list from the device location table, calculating the distance between each device and the event location latitude and longitude coordinates, calculating the arrival time of each device using the shortest path algorithm, generating a recommended device list in ascending order of arrival time, and pushing it to the application side for user selection.

[0028] In one specific embodiment, the server receives a JSON-formatted message, configures a batch control task template, the application selects multiple device identifiers and specifies the batch control task template, sends a task execution request to the server, and generates a device-level control instruction queue, including: The server receives JSON format messages and checks whether the physical quantity values ​​are within the valid range of physical quantities. It then converts the data that passes the check into a real-time data table for the device. When the server creates a batch control task template, it encapsulates multiple device identifiers into a device list JSON array and multiple control operations into an operation sequence JSON array. The device list JSON array and the operation sequence JSON array are then stored together with the task identifier and task name in the batch task table. The application selects multiple device identifiers and specifies a batch control task template, and sends a task execution request to the server to generate a device-level control instruction queue.

[0029] Specifically, when the device's intelligent communication module publishes a JSON-formatted data message to a specified topic on the server via the MQTT protocol, the server's MQTT broker component forwards the message to the subscription module. Upon receiving the JSON data, the subscription module passes it to the data processing module for structured parsing. During parsing, fields are extracted from the JSON, including device identifier, acquisition timestamp, and multiple physical quantity fields, such as voltage, current, battery charge, tilt angle, fuel tank level, and obstacle distance. The server then calls validation logic to check the validity of each physical quantity value, applying threshold judgments based on the physical range corresponding to the device type. For example, the input voltage must be between 180 and 240 volts, the battery charge must be between 0% and 100%, and the tilt angle must not exceed 90 degrees. If any values ​​exceed these limits, they are marked as abnormal data and not stored. Data that passes the check is converted into standard records in a structured form and inserted into the device's real-time data table. The data table structure includes fields such as device ID, timestamp, and various physical quantity values. Meanwhile, the server has the ability to create and manage batch control task templates. Administrators can initiate the task template creation process through the web management interface. During the creation process, the server packages multiple device identifiers selected by the user into a device list JSON array. The user defines a multi-step control operation sequence according to business needs. Each operation consists of execution order, PLC address, target value, and execution delay. For example, the first step is to turn on the power, the second step is to start the generator, and the third step is to turn on the lighting group. The server packages all operation steps into an operation sequence JSON array and stores the device list array, operation sequence array, task name, task identifier, etc. into a batch task table to form a complete task template record. After the task template is created, the user can access the batch control interface through the application (such as the mini-program or web platform of the intelligent sensing system), select multiple device identifiers to be controlled, and select a preset operation task from the existing task templates as the current scheduling content. When the user clicks the "Execute Task" operation, the application sends a task execution request to the server via the HTTPS protocol. The request content includes parameters such as task identifier, device ID array, operator ID, and whether to execute immediately. After receiving the request, the server reads the corresponding operation sequence and device list from the batch task table, and generates device-level control instructions one by one using the Cartesian product of the number of devices and operation steps. Each instruction includes device ID, execution step number, target PLC address, control value, delay duration, and unique task identifier, forming a set of device-level control instruction queues and storing them in the control instruction buffer.

[0030] After the server converts the inspected data into a real-time data table, the process also includes: the server periodically reading the latest battery power, tilt angle, obstacle distance, input voltage, input current, support leg force, fuel tank level, and runtime data from the real-time data table; and reading user-preset anomaly judgment rules from the rule configuration table. These rules include a rule identifier, monitoring parameter field, comparison operator field, threshold field, duration field, and alarm level field. The monitoring parameter field specifies the type of physical quantity being monitored; the comparison operator field includes logical operators such as greater than, less than, equal to, and OR; the threshold field sets the critical value for triggering an alarm; the duration field sets the minimum duration the abnormal state must last; and the alarm level field is set to Level 1 Emergency, Level 2 Important, or Level 3 General. The server substitutes the values ​​of the corresponding monitoring parameters from the real-time data table into the conditional expression constructed by the anomaly judgment rule for logical operation. When the result of the conditional expression is true, a timer is started. The system records the duration of the anomaly. When the duration exceeds the preset value of the duration field, the anomaly is confirmed. Based on the alarm level field, the alarm level is determined as either a Level 1 emergency alarm, a Level 2 important alarm, or a Level 3 general alarm. An alarm record is generated containing the device identifier, alarm timestamp, alarm rule identifier, current monitoring parameter value, threshold value, and alarm level. The server selects the notification channel based on the alarm level field in the alarm record. When the alarm level is Level 1 emergency alarm, an SMS alarm is sent to a preset mobile phone number via the SMS gateway API, and a push alarm is simultaneously sent to a preset user identifier via the application push service, forming a dual-channel alarm. When the alarm level is Level 2 important alarm, only a push alarm is sent via the application push service, forming a single-channel alarm. When the alarm level is Level 3 general alarm, the alarm record is inserted into the alarm log table without triggering real-time notification. The message body of the SMS alarm and push alarm includes the device name, alarm type description, comparison of the current value with the threshold, and suggested handling measures.

[0031] After the server receives the task execution request but before generating the device-level control instruction queue, the process includes: Upon receiving the task execution request from the application, the server parses the priority field in the request to obtain the current task priority value; queries the task execution queue list to retrieve the task record with the status field indicating it is currently executing; extracts the priority field from the currently executing task record to obtain its priority value; compares the current task priority value with the currently executing task priority value (a smaller priority value indicates higher priority); when the current task priority value is less than the currently executing task priority value, a priority preemption operation is required; the server constructs a pause control message containing a pause instruction identifier and a currently executing task identifier, and publishes the pause control message to the MQTT topic corresponding to all device identifiers associated with the currently executing task record via the message queue; after receiving the pause control message, the intelligent communication module of each device sends a stop instruction to the PLC; the PLC stops the currently executing relay or intelligent circuit breaker operation and updates the sequence number of the currently executed steps and the steps not yet executed. The instruction list is saved to the execution progress cache. After receiving the pause confirmation message from each device, the server updates the status field of the executing task record to "paused," the execution progress field to the executed step number, and the pause time field to the current timestamp. The server generates a device-level control instruction queue for the task execution request and inserts a new task record into the task execution queue list. The priority field of the new task record is set to the current task priority value, the status field is set to "in execution," and the start time field is set to the current timestamp. The device-level control instruction queue is executed according to the steps of claim 6 until the task is completed. After the task is completed, the server queries the task execution queue list to retrieve task records with the status field set to "paused." If a paused task record exists, the execution progress field of the paused task record is extracted. The device-level control instruction queue is regenerated starting from the steps after the executed step number recorded in the execution progress field. The status field of the paused task record is updated to "in execution," and the resumption time field is updated to the current timestamp. The paused task continues to be executed until completion.

[0032] In one specific embodiment, the application selects multiple device identifiers, specifies a batch control task template, and sends a task execution request to the server, generating a device-level control instruction queue, including: On the device list page, the application selects multiple device identifiers and chooses a pre-configured batch control task template, then sends a task execution request to the server. The server receives the task execution request, queries the task details corresponding to the task identifier from the batch task table, extracts multiple device identifiers from the device list JSON array and multiple operation steps from the operation sequence JSON array, and generates a device-level control instruction queue.

[0033] Specifically, users access the device list page through the device management interface, select multiple online or selected device identifiers, and choose a pre-configured batch control task template from the dropdown menu. The system then automatically encapsulates a task execution request message containing an array of device identifiers and a task template identifier, and sends this message to the server's task execution interface via an HTTPS POST request. Upon receiving the task execution request, the server invokes the task execution microservice and, based on the task identifier field in the request, queries the batch task table in the task management database to retrieve the complete task configuration data corresponding to that task identifier. This data structure includes the task name, task priority, task creation time, a device list JSON array, and an operation sequence JSON array. The server parses the device list JSON array to obtain the identifier set for the selected devices and sequentially unfolds the preset control steps in the operation sequence JSON array. Each control step includes control instruction elements such as execution sequence number, PLC address, target boolean or numerical value, and delay parameters. The server generates a device-level control command queue by combining each operation step with each device identifier through the Cartesian product of the device list and the operation sequence. It also assigns a unique command number to each command and adds fields such as execution ID, task ID, device ID, control address, control value, planned issuance time, and delay duration to form a batch control command set.

[0034] When the server issues control messages to multiple devices in the device-level control command queue, specifically in the scenario of emergency sprinkler system linkage activation, the process includes: the server receiving temperature data and smoke concentration data collected and reported by the devices through the sensor network in real time; comparing the temperature data with preset temperature thresholds and the smoke concentration data with preset smoke concentration thresholds; determining that a fire anomaly has occurred when the temperature data exceeds the temperature threshold or the smoke concentration data exceeds the smoke concentration threshold; the server querying the device location table to obtain the latitude and longitude coordinates of the abnormal device based on the device identifier of the reported abnormal data; querying the list of device identifiers configured with sprinkler function within the linkage radius centered on the latitude and longitude coordinates and within the preset linkage radius; automatically generating an emergency sprinkler linkage activation task and setting the task priority to the highest level; the emergency sprinkler linkage activation task includes the device identifiers... The system identifies the device list, performs spray pump start-up operations, and spray pressure adjustment operations. The server calculates the Euclidean distance between the latitude and longitude coordinates of each device in the device identifier list and the latitude and longitude coordinates of the malfunctioning device. It then sorts the device identifier list in ascending order of distance, obtaining a distance-sorted device sequence. Based on this distance-sorted sequence, a linkage control command sequence is generated. Each command in the linkage control command sequence includes a device identifier, a spray pump start-up time parameter, and a spray pressure setpoint parameter. The spray pump start-up time parameter is calculated based on the device's position in the sequence, multiplied by a fixed delay interval. The spray pressure setpoint parameter is set to an inverse relationship of increasing pressure the closer the device is to the malfunctioning device. The server concurrently publishes each command in the linkage control command sequence to the corresponding MQTT topic of the device identifier via a message queue.After receiving the command sequence belonging to their own device from the linkage control command sequence, the intelligent communication module of each device parses the sprinkler pump start-up time parameter and starts the local timer. When the timer reaches the delay duration set by the sprinkler pump start-up time parameter, the intelligent communication module constructs an S7Comm write request frame to set the address mapped to the sprinkler pump relay in the PLC output area. The PLC drives the sprinkler pump relay to close, starting the sprinkler pump. At the same time, the intelligent communication module parses the sprinkler pressure setpoint parameter and adjusts the PWM duty cycle of the sprinkler pump motor according to the sprinkler pressure setpoint parameter through the PLC's built-in PID control algorithm to achieve speed regulation. The water pressure sensor at the device end collects the water pressure value of the sprinkler pipeline in real time and transmits it through the serial port. The data is transmitted to the PLC for storage. The intelligent communication module periodically reads the water pressure values ​​and encapsulates them into JSON format water pressure feedback messages, which are then reported to the server. The server receives water pressure feedback messages from all devices within the linkage radius and calculates the average water pressure value. When the deviation between the water pressure value reported by a device and the average water pressure value exceeds a preset pressure balance threshold, the server issues a spray pressure adjustment command to that device. This command includes the adjusted spray pressure setpoint. Upon receiving the command, the device updates the target pressure parameters of its PID control algorithm and dynamically adjusts the spray pump speed until the actual water pressure approaches the adjusted spray pressure setpoint, thus achieving pressure balance and coordinated control of the multi-device spray system.

[0035] In one specific embodiment, the server publishes control messages to multiple devices in the device-level control instruction queue. The intelligent communication module receives the control messages, constructs a write request frame, sends it to the PLC, and returns an execution response frame. The intelligent communication module parses the execution response frame, extracts feedback messages, and reports them to the server, including: The server extracts multiple instruction records with the same step number from the device-level control instruction queue, constructs the corresponding MQTT topic name based on the device identifier in the instruction record, and concurrently publishes control messages to the MQTT topic name through the message queue; The intelligent communication module receives control messages, constructs a write request frame and sends it to the PLC. The PLC drives the corresponding relay or intelligent circuit breaker to perform on / off actions and returns an execution response frame to the intelligent communication module. The intelligent communication module receives the execution response frame, parses the return code in the execution response frame to determine whether the execution status is successful or failed, encapsulates it into a feedback message, and reports it to the server via the MQTT protocol.

[0036] Specifically, the task execution module extracts all control instruction records with the same current step number from the instruction queue. These records represent operation steps that need to be executed simultaneously by multiple devices in the same control phase, such as simultaneously turning on the power of multiple devices or starting a generator set. The server extracts the device identifier field from each control instruction and constructs a unique MQTT publication topic name based on the device identifier, for example, using "device / device ID / command" as the naming format, thereby ensuring that each instruction can accurately match its corresponding device's subscription channel. The server uses a built-in asynchronous message queue mechanism (such as RabbitMQ) to start a concurrent control channel, converting each control instruction into a standard MQTT control message body. The message content is represented in JSON structure, including control fields such as command ID, target address, write value, and delay parameters. The control message is then simultaneously published to the corresponding MQTT topic path, realizing concurrent distribution of multiple instructions across devices. Once the intelligent communication module on the device subscribes to an MQTT topic that matches its own device ID, it can receive control messages published by the server in real time. After receiving the control message, the communication module immediately starts the instruction parsing module. Based on the operation field in the message body, it identifies this task as a PLC write operation. Then, based on the address field, it extracts the target PLC output address (e.g., Q0.0 represents a power relay or Q0.3 represents an LED lighting relay) and the Boolean value or control quantity to be written. Subsequently, in the internal protocol conversion module, a standard write request frame is constructed according to the S7Comm protocol. The write request frame includes TPKT and COTP network encapsulation headers. The function code in the S7 protocol header is set to 0x05 to indicate a write variable operation, and the parameter field specifies the data area type, address number, data format, and target value. After construction, the write request frame is sent to port 102 of the PLC via a TCP connection. After receiving a write request frame, the PLC controller decodes the protocol and parses out the target address and target value. Then, it drives the corresponding relay coil or intelligent circuit breaker module to perform on / off operations, completing the actual physical control actions, such as closing the relay to control the circuit to power on or opening the circuit to complete the power-off process. After the action is completed, it generates an S7Comm response frame based on the execution result and returns it to the intelligent communication module. The return code field is used to indicate whether the operation is successful, such as 0xFF indicating successful writing, and 0x05 or 0x06 indicating an error.After receiving a response frame from the PLC, the intelligent communication module initiates the execution result parsing process. It reads the return code field in the response frame and determines whether the current control command was successfully completed. If the return code is 0xFF, the control action is considered successful; otherwise, it is recorded as a failure. The module then constructs a feedback message body, which is encapsulated in JSON format. The message includes the original command ID, execution status field (Success or Failure), device ID, reception time, execution completion time, and optional error codes and error messages. It is then published to the server's listening result feedback topic path (e.g., "device / device ID / result") via the MQTT protocol. After receiving the feedback message, the server updates the task execution status database table, recording the execution result of each device in each control step in real time.

[0037] In one specific embodiment, the intelligent communication module receives a control message, constructs a write request frame and sends it to the PLC. The PLC drives the corresponding relay or intelligent circuit breaker to perform an on / off action and returns an execution response frame to the intelligent communication module, including: The intelligent communication module receives control messages and parses the PLC address field and write value field in the control messages. According to the preset address mapping table, it maps the PLC address field to the corresponding relay or intelligent circuit breaker in the output area. The intelligent communication module constructs a write request frame and sends it to the PLC. The PLC receives the write request frame and drives the corresponding relay or intelligent circuit breaker to perform on / off actions. After completing the on / off control, the PLC constructs an execution response frame and sends it to the intelligent communication module.

[0038] Specifically, the intelligent communication module subscribes to a dedicated topic path matching its own device identifier via the MQTT protocol, such as "device / DEV001 / command". When the server publishes a control message to this topic, the intelligent communication module receives message data containing the target control action in real time. The intelligent communication module starts a message parsing program to extract the PLC address field and the target write value field from the message body. The address field is the logical address of the PLC output area, such as "Q0.3" indicating the third output channel. The write value field is a Boolean type, used to control the setting or resetting of the target address, that is, to control the closing or opening of the relay or intelligent circuit breaker. The intelligent communication module performs logical mapping on the extracted PLC address fields according to a pre-configured address mapping table. This table stores the correspondence between each PLC output address and the actual hardware control object. For example, Q0.0 corresponds to the main power relay, Q0.1 to the generator relay, Q0.2 to the intelligent circuit breaker, and Q0.3 to the LED light control relay. Through a lookup operation in the mapping table, the intelligent communication module identifies the control object targeted by the current write operation and determines whether it belongs to relay control or intelligent circuit breaker control. After completing the address mapping, the intelligent communication module constructs a write request frame conforming to the S7Comm industrial communication protocol specification. The write request frame includes TPKT and COTP transport layer encapsulation and an S7 protocol layer data structure. In the S7 protocol segment, the function code is set to 0x05 to indicate a write operation, the data area type is labeled as the output area (Q area), and the address segment is set to the specific address bit parsed, such as Q0.3. The data type is BOOL, and the data value is a Boolean 1 or 0, representing the control intent of on or off, respectively. After the write request frame is encapsulated, it is sent to the PLC's standard port 102 via the established TCP / IP link between the intelligent communication module and the PLC. Upon receiving the write request, the PLC starts the communication processing module, parses the protocol frame structure, extracts the control address and corresponding write value, and maps them to its own output register space, triggering the corresponding relay or intelligent circuit breaker module to complete the actual on / off action. When a relay receives a closing command, its internal coil receives excitation current, thereby closing the contacts and forming a closed circuit to power on the device or control circuit. If it receives an opening command, the contacts are released, disconnecting the control path. For intelligent circuit breakers, the PLC's output logic level changes guide its on / off operation, such as initiating a circuit break or closing. After the action is completed, the PLC constructs an execution response frame according to the S7Comm protocol response specification, which includes a command confirmation field and an execution status field. If the operation is successful, a response code of 0xFF is filled in, indicating successful writing; if the operation fails, such as address out of bounds or target address write protection, an error code field, such as 0x05 or 0x06, is filled in. The execution response frame is returned to the intelligent communication module through the same TCP / IP channel.

[0039] When the PLC drives the corresponding relay or smart circuit breaker to perform on / off actions to start the generator set or LED lighting assembly, the process includes: Before performing the on / off action, the PLC collects the voltage and current values ​​of the input power supply in real time through voltage and current transformers. The voltage value is compared with the rated voltage upper and lower limit thresholds stored in the PLC's database block. If the voltage value is between the rated voltage upper and lower limit thresholds, the power supply is considered normal. If the voltage value exceeds this range, the power supply is considered abnormal, and the startup operation is aborted. Simultaneously, the intelligent communication module sends a power abnormality message containing the device identifier, abnormal voltage value, and abort timestamp to the relevant department. The system reports to the server. When the power supply is determined to be normal, the PLC queries the device parameter table for the corresponding rated power value based on the type of device to be started. When the rated power value is greater than the preset high-power threshold, a step-by-step soft-start strategy is activated. The step-by-step soft-start strategy divides the relay closing process into three stages: a pre-charging stage, a low-speed operation stage, and a full-speed operation stage. The PLC first sets the output value of the corresponding address in the output area to the first PWM duty cycle to enter the pre-charging stage. The first PWM duty cycle is set to 30%. By reducing the duty cycle, the initial current flowing into the device is limited. After a first preset duration, the output value is adjusted to the second PWM duty cycle to enter the low-speed operation stage. The duty cycle is set to 60%, and after a second preset duration, the output value is adjusted to 100% full duty cycle to enter the full-speed operation phase. During each stage of the step-by-step soft-start strategy, the PLC continuously collects the current voltage and current values ​​through voltage and current transformers, calculates the voltage drop percentage relative to the voltage value before startup, and determines a severe voltage drop when the voltage drop percentage exceeds the preset voltage drop protection threshold. The PLC immediately reduces the output value to the PWM duty cycle of the previous stage and extends the duration of that stage. Only after the voltage drop percentage falls back below the voltage drop protection threshold is the output value increased to the PWM duty cycle of the next stage increased. If the voltage drop percentage cannot be controlled within a safe range after three consecutive reductions in the duty cycle, the startup operation will be terminated and a startup failure message will be reported. The PLC records startup process data including device identifier, startup timestamp, duration of each stage, voltage value sequence of each stage, and current value sequence of each stage. The intelligent communication module encapsulates the startup process data into a JSON format message and reports it to the server via the MQTT protocol. The server analyzes the voltage drop percentage and current peak value in the startup process data. When it finds that the startup process of a certain device frequently triggers the duty cycle reduction protection or the current peak value is continuously high, it generates a device aging warning and pushes it to the application, prompting the user to arrange equipment maintenance or replacement.

[0040] In one specific embodiment, after extracting the feedback message and reporting it to the server, the method further includes: The server receives the feedback message and extracts the task progress information from it. The server pushes task progress messages to the application. After receiving the task progress messages, the application parses the progress percentage and updates the displayed value of the progress bar component. The server confirms task completion when the progress percentage reaches 100%, and then constructs the operation data structure.

[0041] Specifically, during the batch control task execution process, the server continuously receives instruction execution results from the device to update the overall task progress status in real time and push synchronization information to the application, achieving visualized task execution feedback. When the device's intelligent communication module completes each PLC write operation, it publishes a feedback message via the MQTT protocol to a feedback topic with the device ID as the path (e.g., "device / DEV001 / result"). The server's MQTT broker routes this message to the feedback processing module of the task execution microservice. The feedback message is encapsulated in JSON format and includes fields such as command ID, device ID, task execution ID, current step number, execution result status (Success or Failure), timestamp, and time consumed. After receiving the feedback message, the server performs message parsing and field extraction operations, and matches the extracted task execution ID with the task record in the task control table. The server locates the corresponding task instruction queue based on the task execution ID and updates the execution status field of the feedback message to the corresponding instruction record. Simultaneously, it counts the number of completed (including successful and failed) instructions across all records for the current task and calculates the ratio with the total number of instructions to determine the current task's execution progress percentage. The server constructs a task progress message structure containing information such as the task execution ID, total number of instructions, number of completed instructions, number of successful instructions, number of failed instructions, current progress percentage, current step number, and device status list. This message is then pushed in real-time to the application client via a WebSocket push channel, such as the mini-program interface or web console of the intelligent sensing system. Upon receiving the task progress message, the application client enters the front-end parsing logic module, parses the progress percentage field (e.g., currently 66.7%), and dynamically assigns this value to the numerical attribute of the task progress bar component on the page. This allows the progress bar to update and display the current task execution progress on the user interface in real-time, providing a visual perception of the batch control task execution status for the user. When the server receives the remaining device feedback messages again and finds that all instruction records have been fed back and the execution status is no longer "Pending", the calculated task progress percentage is set to 100%, thus confirming that the batch control task has been completed. After confirming the task completion, the server constructs a task operation data structure, which includes information such as task ID, task execution ID, task template name, operator ID, device list, operation step sequence, execution time of each step, execution result of each device, time consumption statistics, and a list of faulty device numbers (if any failures exist).

[0042] In one specific embodiment, after the server determines that the task is complete when the progress percentage reaches 100%, and after constructing the operation data structure, the method further includes: The blockchain client node on the server side performs hash calculations on the data structure to obtain hash values, and constructs blockchain transaction data based on the hash values; The blockchain client node broadcasts blockchain transaction data to multiple consensus nodes in the consortium blockchain network. After receiving the blockchain transaction data, the consensus nodes verify the transaction format and signature validity. After successful verification, the blockchain transaction data is packaged into a new block, appended to the end of the distributed ledger blockchain to complete the on-chain process, and the transaction hash value is returned to the server.

[0043] Specifically, after the task is completed, the server initiates a blockchain notarization process. The blockchain client nodes deployed on the server hash the operation data structure, construct transactions, and submit them to the consortium blockchain network for consensus writing. Once the server confirms that all device control commands for a batch control task have been executed and complete feedback has been received, the task execution microservice summarizes the execution information of all commands based on the task execution ID and assembles an operation data structure. The structure includes the task ID, execution ID, device ID list, operation step sequence, execution status and timestamp of each device, execution result statistics, operator identification, and task start and end times. The operation data structure is then input into the hash module integrated into the blockchain client node, and a hash value is calculated using the SHA-256 hash algorithm to obtain a unique hash value string. The hash value is used to identify the uniqueness of the task operation record in the current state and also has the ability to verify content integrity. Blockchain client nodes embed hash values ​​as a core field into blockchain transaction data. The blockchain transaction data structure also includes the target contract address of the smart contract being called, the contract function name, the parameter structure (including task ID, execution ID, hash value, timestamp, operator ID, etc.), and the digital signature of the transaction initiator. After construction, the client node broadcasts the blockchain transaction data to multiple consensus nodes in the consortium blockchain network via a P2P protocol. These consensus nodes are distributed across different systems within the consortium blockchain member units, jointly participating in the transaction verification and block production consensus process. Upon receiving the transaction data, the consensus nodes verify whether its basic format conforms to the on-chain transaction structure specifications, such as whether the parameter structure is complete and whether the data types match. They also verify the validity of the transaction initiator's signature to confirm that the sender of the transaction has the authority to write to the chain and that the data has not been forged or tampered with. If all consensus nodes complete verification and reach a consensus confirming that the transaction is legitimate, the block production process begins according to the adopted consensus mechanism (such as PBFT, RAFT, or improved DPoS). The transaction is packaged together with other pending transactions into a new block, and block header information is attached, including the hash of the previous block, the timestamp of the current block, the Merkle root hash, the signature of the block-producing node, etc. The new block is written into the distributed ledger of the consortium blockchain and appended to the end of the chain, completing the on-chain operation. At the same time, the block-producing node returns the transaction hash value (i.e., the unique identifier of the transaction on the chain) to the server. The server binds the hash value with the task execution ID and stores it in the blockchain evidence table of the local database, forming an on-chain and off-chain correspondence.

[0044] The above describes the intelligent sensing method for emergency equipment in the embodiments of the present invention. The following describes the intelligent sensing system for emergency equipment in the embodiments of the present invention. Please refer to [link / reference]. Figure 2 One embodiment of the intelligent sensing system for emergency equipment in this invention includes: The data acquisition module 201 is used to collect data at the device end and store the data in the PLC. The intelligent communication module connects to the PLC, parses the data returned by the PLC into JSON format messages and publishes them to the server using the MQTT protocol. Task control module 202 is used for the server to receive JSON format messages, configure batch control task templates, and for the application to select multiple device identifiers and specify batch control task templates, send task execution requests to the server, and generate a device-level control instruction queue. The response feedback module 203 is used by the server to publish control messages to multiple devices in the device-level control instruction queue. The intelligent communication module receives the control messages, constructs a write request frame and sends it to the PLC, and returns an execution response frame. The intelligent communication module parses the execution response frame, extracts the feedback message and reports it to the server.

[0045] Figure 3 This is a schematic diagram of the intelligent sensing system architecture for emergency equipment of the present invention. It adopts a three-layer architecture, including an application layer, a server layer, and a device layer. The device layer consists of a sensor network, a PLC controller, and an intelligent communication module. It is responsible for collecting operational data such as battery power and tilt angle, and reporting it to the server via the MQTT protocol over a 4G network. The server layer includes data processing services, task orchestration services, and message queue services. It is responsible for receiving JSON format messages, configuring batch control task templates, generating device-level control instruction queues, and concurrently issuing control instructions through the message queue. The device receives control messages, writes the PLC execution address to drive relays or intelligent circuit breakers, and feeds back the execution results to the server via the intelligent communication module. The server pushes the task progress to the application in real time for display via a WebSocket push service.

[0046] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0047] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0048] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. An emergency equipment intelligent sensing method, characterized in that, The application relates to a batch control method and system, comprising: Collecting data at the device end, storing the data to a PLC, connecting the PLC by an intelligent communication module, parsing the data returned by the PLC into a JSON format message and publishing the message to the server in an MQTT protocol; The server receives the JSON format message, configures a batch control task template, the application end selects multiple device identifiers and specifies the batch control task template, sends a task execution request to the server, and generates a device-level control instruction queue; The server publishes a control message to multiple devices in the device-level control instruction queue, the intelligent communication module receives the control message and constructs a write request frame to send to the PLC, returns an execution response frame, and the intelligent communication module parses the execution response frame and extracts a feedback message to report to the server. 2.The emergency equipment intelligent sensing method according to claim 1, characterized in that, Collecting data at the device end, storing the data to a PLC, connecting the PLC by an intelligent communication module, parsing the data returned by the PLC into a JSON format message and publishing the message to the server in an MQTT protocol, comprising: At the device end, data is collected through a sensor network and transmitted to a PLC, and the PLC stores the data to a DB data block according to a preset address mapping rule; The intelligent communication module connects the PLC, sends a read request frame to the PLC at a fixed time, parses the data returned by the PLC into a JSON format message and publishes the message to the server in an MQTT protocol. 3.The emergency equipment intelligent sensing method according to claim 2, characterized in that, The intelligent communication module connects the PLC, sends a read request frame to the PLC at a fixed time, parses the data returned by the PLC into a JSON format message and publishes the message to the server in an MQTT protocol, comprising: The intelligent communication module connects the PLC, and the intelligent communication module constructs a read request frame and sends the frame to the PLC at a fixed time, receives the data returned by the PLC and parses the data into a physical quantity value; The physical quantity value is packaged into a JSON format message, the intelligent communication module connects an MQTT proxy server through a 4G network and constructs an MQTT publishing message, and publishes the message to a corresponding MQTT topic of the server. 4.The emergency equipment intelligent sensing method according to claim 1, characterized in that, The server receives the JSON format message, configures a batch control task template, the application end selects multiple device identifiers and specifies the batch control task template, sends a task execution request to the server, and generates a device-level control instruction queue, comprising: The server receives the JSON format message, and checks whether the physical quantity value is within a physical quantity effective range, converts the data checked to a device real-time data table; When the server creates a batch control task template, a plurality of device identifiers are packaged into a device list JSON array, a plurality of control operations are packaged into an operation sequence JSON array, and the device list JSON array and the operation sequence JSON array are stored into a batch task table together with a task identifier and a task name; The application end selects multiple device identifiers and specifies the batch control task template and sends a task execution request to the server, and generates a device-level control instruction queue.

5. The method of claim 4, wherein, The application end selects multiple device identifiers and specifies the batch control task template and sends a task execution request to the server, and generates a device-level control instruction queue, comprising: The application end checks multiple device identifiers on a device list page and selects a preconfigured batch control task template, and sends a task execution request to the server; The server receives the task execution request, queries task details corresponding to the task identifier from the batch task table, extracts multiple device identifiers in the device list JSON array and multiple operation steps in the operation sequence JSON array, and generates a device-level control instruction queue. 6.The emergency equipment intelligent sensing method according to claim 1, characterized in that, The server publishes control messages to multiple devices in the device-level control instruction queue, and the intelligent communication module receives the control messages and constructs a write request frame to send to the PLC, returns an execution response frame, and the intelligent communication module parses the execution response frame and extracts feedback messages to report to the server, including: The server extracts multiple instruction records of the same step number from the device-level control instruction queue, constructs a corresponding MQTT topic name according to the device identifier in the instruction record, and publishes control messages to the MQTT topic name through the message queue; The intelligent communication module receives the control messages, constructs a write request frame and sends it to the PLC, and the PLC drives the corresponding relay or intelligent air switch to perform on-off action and returns an execution response frame to the intelligent communication module. The intelligent communication module receives the execution response frame, parses the return code in the execution response frame to determine the execution state as success or failure and encapsulates it as a feedback message, and reports it to the server through the MQTT protocol.

7. The method of claim 6, wherein, The intelligent communication module receives the control messages, constructs a write request frame and sends it to the PLC, and the PLC drives the corresponding relay or intelligent air switch to perform on-off action and returns an execution response frame to the intelligent communication module, including: The intelligent communication module receives the control messages and parses the PLC address field and write value field in the control messages, and maps the PLC address field to the corresponding relay or intelligent air switch in the output area according to the preset address mapping table; The intelligent communication module constructs a write request frame and sends it to the PLC, and the PLC receives the write request frame, drives the corresponding relay or intelligent air switch to perform on-off action, and constructs an execution response frame and sends it to the intelligent communication module after completing the on-off control. 8.The emergency equipment intelligent sensing method according to claim 1, characterized in that, After extracting the feedback message and reporting it to the server, it further includes: The server receives the feedback message and extracts the task progress message in the feedback message; The server pushes the task progress message to the application end, and the application end receives the task progress message and parses the progress percentage to update the display value of the progress bar component; When the server determines that the progress percentage reaches 100%, it confirms that the task is completed and constructs an operation data structure. 9.The emergency equipment intelligent sensing method according to claim 8, characterized in that, After the server determines that the progress percentage reaches 100% and confirms that the task is completed, it further includes: The blockchain client node of the server performs hash operation on the operation data structure to obtain a hash value, and constructs a blockchain transaction data according to the hash value; The blockchain client node broadcasts the blockchain transaction data to a plurality of consensus nodes in the consortium chain network, the consensus nodes verify the transaction format and signature validity after receiving the blockchain transaction data; After verification, the blockchain transaction data is packaged into a new block, the new block is appended to the end of the distributed ledger blockchain to complete the chain and return the transaction hash value to the server.

10. An emergency equipment intelligent sensing system, characterized in that, A method for performing the emergency equipment intelligent perception method as claimed in any one of claims 1-9, comprising: A data acquisition module for collecting data at the device end, storing the data to the PLC, and connecting the PLC with the intelligent communication module, parsing the data returned by the PLC into a JSON format message and publishing it to the server in MQTT protocol; A task control module for receiving the JSON format message at the server, configuring a batch control task template, selecting multiple device identifiers at the application end and specifying the batch control task template, sending a task execution request to the server, and generating a device-level control instruction queue; A response feedback module for publishing control messages to multiple devices in the device-level control instruction queue at the server, receiving the control messages by the intelligent communication module and constructing a write request frame to send to the PLC, returning an execution response frame, parsing the execution response frame by the intelligent communication module, and extracting feedback messages to report to the server.

Images