Urban LED street lamp lighting system emergency control method and system

Abstract

The application discloses an emergency control method and system for a city LED street lamp lighting system, and relates to the technical field of data processing.The method comprises the following steps: continuously acquiring operation state data automatically fed back by each lighting subsystem in the city lighting system; taking the operation state data as an initial transaction, and performing consensus and archiving in a blockchain network; dynamically generating and updating rule configuration items matched with the environment of each lighting subsystem; identifying the real-time acquired operation state data in a preset multi-level early warning processing node to determine whether an emergency takeover condition is triggered; if yes, generating a high-priority emergency takeover instruction transaction through a supervision node, archiving after consensus in the blockchain network, and switching the control authority of the corresponding lighting subsystem to a connection system based on the archived instruction.The application not only ensures the authority of the emergency takeover instruction and the traceability of the execution process, but also greatly enhances the overall reliability and transparency.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, specifically to an emergency control method and system for urban LED street lighting systems. Background Technology

[0002] With the deepening of smart city construction, urban LED street lighting systems have become a critical public infrastructure, and their stable operation is of paramount importance. Modern urban lighting systems typically adopt a hierarchical architecture, consisting of local lighting subsystems (lower level) distributed in various locations and a central emergency system (upper level) to achieve zoned management.

[0003] Currently, common emergency control practices in the industry primarily rely on centralized system architectures and pre-defined static rules. Specifically, when a lower-level subsystem experiences an anomaly, such as a lost heartbeat or server crash, it reports the anomaly to the central emergency system. The central system then judges the situation based on a set of pre-defined, fixed threshold rules. If the conditions are met, the central system directly issues an instruction to take over control of the devices in the anomaly subsystem. Throughout this process, the storage of operational status data, the logic for anomaly judgment, and the generation of takeover instructions are all completed independently by the central system, lacking an effective distributed verification mechanism. Furthermore, the rule base used for judgment is usually set and remains unchanged for a long period, making it difficult to personalize it according to the specific environment of each subsystem.

[0004] However, the use of static, universal rule thresholds for a "one-size-fits-all" approach fails to adapt to the environmental differences of different subsystems, easily leading to misjudgments. For example, in areas with large network signal fluctuations, a fixed heartbeat timeout threshold may cause frequent false takeovers, while in high-humidity areas, a fixed equipment temperature alarm threshold may fail to detect real risks in a timely manner, resulting in low overall reliability of emergency judgments. Summary of the Invention

[0005] In view of the shortcomings of the prior art, the purpose of this invention is to provide an emergency control method and system for urban LED street lighting systems, aiming to solve the above-mentioned problems described in the prior art.

[0006] A first aspect of the present invention is to provide an emergency control method for an urban LED street lighting system, the method comprising: Continuously acquire operational status data automatically fed back from various lighting subsystems in the urban lighting system; The operational status data is used as the initial transaction, and consensus and evidence are obtained in the blockchain network composed of the subsystem nodes and the regulatory nodes corresponding to each of the lighting subsystems. Based on the operational status data stored in the blockchain network, rule configuration items that match the environment of each lighting subsystem are dynamically generated and updated. According to the rule configuration items, the real-time acquired operation status data is identified in the preset multi-level early warning processing nodes to determine whether the emergency takeover conditions are triggered. When the emergency takeover conditions are triggered, a high-priority emergency takeover instruction transaction is generated through the regulatory node, which is then stored after consensus by the blockchain network. Based on the stored instruction, the control authority of the corresponding lighting subsystem is switched to the associated system.

[0007] According to one aspect of the above technical solution, the steps of using the operational status data as the initial transaction and achieving consensus and notarization in the blockchain network composed of subsystem nodes and supervisory nodes corresponding to each of the lighting subsystems include: The subsystem nodes and the supervisory nodes in the blockchain network communicate in P2P via the Gossip protocol. The PBFT consensus algorithm is used to enable all honest nodes in the blockchain network to reach a consensus on the transaction block containing the running state data; The data structure for evidence storage includes a block header and a block body. The block header contains a consensus signature and a parent hash, and the block body contains at least one of the following: heartbeat data transaction, status information transaction, emergency takeover instruction transaction, and control log transaction.

[0008] According to one aspect of the above technical solution, the step of using the PBFT consensus algorithm to enable all honest nodes in the blockchain network to reach a consensus on the transaction block containing the running state data includes: The currently rotating ledger node in the blockchain network will attach a digital signature to the packaged transaction block and broadcast it as a pre-preparation message to all nodes in the network. The pre-preparation message includes the block content, view number, and sequence number. After receiving the pre-preparation message, each node in the blockchain network verifies the signature validity of the accounting node, the correctness of the view number, and the compliance of the transaction format. After successful verification, each node in the blockchain network enters the preparation phase and broadcasts a preparation message to the entire network. When a node collects at least 2f+1 valid prepare messages from different nodes, it enters the commit phase and broadcasts a commit message; where f is the maximum allowed number of Byzantine fault nodes. Once a node has collected at least 2f+1 valid commit messages, it confirms the transaction block as the final valid block and writes it into the local ledger. If consensus is not reached within a preset time, the node will trigger a view replacement protocol to re-elect the ledger node and update the view number, so as to ensure that the blockchain network continues to operate and eventually reaches a consensus state even if some nodes fail or act maliciously.

[0009] According to one aspect of the above technical solution, the step of dynamically generating and updating rule configuration items that match the environment of each lighting subsystem based on the operational status data stored in the blockchain network includes: Obtain the operational status data of any lighting subsystem and its corresponding environmental parameters from the blockchain network, and analyze the correlation between the environmental parameters and the operational status parameters in the operational status data; Based on the aforementioned relationship, the threshold range of each rule parameter in the pre-built rule parameter library is dynamically adjusted to adapt the threshold to different environmental conditions, thereby updating the rule configuration items corresponding to each of the lighting subsystems. The adjusted rule configuration items and their version information are recorded as transactions on the blockchain, forming a traceable rule update history.

[0010] According to one aspect of the above technical solution, the step of dynamically adjusting the threshold range of each rule parameter in the pre-built rule parameter library based on the aforementioned correlation, so that the threshold adapts to different environmental conditions, to update the rule configuration items corresponding to each of the lighting subsystems, includes: Based on the correlation between environmental parameters and operating status parameters, the threshold range of the corresponding parameters in the rule parameter library is automatically adjusted to generate dynamic threshold ranges that adapt to different environmental conditions. Based on the preset rule parameter association matrix, when any parameter threshold is adjusted, the thresholds of its associated parameters are automatically triggered to adjust in a coordinated manner, ensuring the internal logic consistency of the rule configuration items.

[0011] According to one aspect of the above technical solution, based on a preset rule parameter association matrix, when any parameter threshold is adjusted, the thresholds of its associated parameters are automatically triggered for coordinated adjustment to ensure the internal logical consistency of the rule configuration items. This includes the following steps: When an adjustment to the threshold of any target rule parameter is detected, the rule parameter association matrix is ​​queried to identify all associated parameters that are related to the target rule parameter; based on the predefined weight coefficients in the rule parameter association matrix, the impact coefficient of the target parameter threshold adjustment on each associated parameter is calculated. Based on the aforementioned influence coefficient, the threshold of each associated parameter is automatically adjusted proportionally. After the adjustment is completed, a logical consistency check is performed on all updated rule configuration items to ensure that the constraint relationship between the threshold parameters meets the preset conditions, and the version information corresponding to the finally effective rule configuration items is recorded in the blockchain network.

[0012] According to one aspect of the above technical solution, after the adjustment is completed, the following steps are performed: logical consistency verification is performed on all updated rule configuration items to ensure that the constraint relationships between the threshold parameters meet the preset conditions, and the version information corresponding to the finally effective rule configuration items is recorded in the blockchain network: Read the updated rule configuration items and verify whether the threshold values ​​of each parameter meet the predefined constraints, including the compatibility of the numerical ranges of the parameters, the logical order, and the mutual exclusion relationship. When a parameter threshold is found to violate the constraint relationship, an alarm is automatically triggered and the rule configuration item is marked as pending correction. The rule configuration item that passes the logical consistency check will be bound to a new version identifier, and the check result, version information and effective timestamp will be used to generate a check record transaction, which will be submitted to the blockchain network for evidence storage. If the verification fails, the alarm information and the rule configuration items to be corrected will be recorded as transactions on the blockchain network, forming an auditable verification history.

[0013] A second aspect of the present invention is to provide an emergency control system for an urban LED street lighting system, applied to the method described in the above-mentioned technical solution, the system comprising: The data acquisition module is used to continuously acquire the operating status data automatically fed back by various lighting subsystems in the urban lighting system; The data storage module is used to take the operating status data as the initial transaction and conduct consensus and storage in the blockchain network composed of the subsystem nodes and the supervision nodes corresponding to each of the lighting subsystems. The rule generation module is used to dynamically generate and update rule configuration items that match the environment of each lighting subsystem based on the operational status data stored in the blockchain network. The condition judgment module is used to identify the real-time acquired operating status data in the preset multi-level early warning processing nodes according to the rule configuration items, so as to determine whether the emergency takeover conditions are triggered. The takeover execution module is used to generate a high-priority emergency takeover instruction transaction through the supervisory node when the emergency takeover conditions are triggered. After consensus is reached through the blockchain network, the transaction is stored as evidence, and the control authority of the corresponding lighting subsystem is switched to the associated system based on the stored instruction.

[0014] A third aspect of the present invention is to provide a readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the steps of the method described in the above-described technical solution.

[0015] A fourth aspect of the present invention is to provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method described in the above technical solutions.

[0016] Compared with the prior art, the emergency control method for urban LED street lighting systems shown in this invention has the following advantages: By constructing a technical framework that deeply integrates blockchain's trusted mechanisms and intelligent decision-making algorithms, a substantial improvement in the reliability, accuracy, and transparency of emergency control has been achieved. First, by using the operational status data of each lighting subsystem as initial transactions for consensus-based notarization on the blockchain network, the immutability of data sources and full-chain traceability are ensured, building a solid and reliable data foundation for subsequent analysis and decision-making. Second, rule configuration items are dynamically generated and updated based on trusted historical data and environmental parameters accumulated on the blockchain, enabling emergency takeover triggering conditions to adapt to specific situations in different regions and environments. This effectively avoids misjudgments caused by general rules and significantly improves the accuracy of condition judgments. Finally, the entire emergency decision-making and execution process, from the collaborative judgment of multi-level early warning nodes to the consensus-based notarization of high-priority emergency command transactions generated by regulatory nodes, and finally to the switching of control authority, is fully recorded on the blockchain, forming a closed-loop trusted audit chain. This not only ensures the authority of emergency takeover commands and the traceability of the execution process but also greatly enhances overall reliability and transparency. Attached Figure Description

[0017] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which: Figure 1 This is a flowchart illustrating an emergency control method for an urban LED street lighting system according to an embodiment of the present invention. Figure 2 This is a structural block diagram of an emergency control system for an urban LED street lighting system according to an embodiment of the present invention. Detailed Implementation

[0018] To make the objectives, features, and advantages of the present invention more apparent and understandable, specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Several embodiments of the present invention are shown in the drawings. However, the present invention can be implemented in many different forms and is not limited to the embodiments described herein. Rather, these embodiments are provided so that the disclosure of the present invention will be more thorough and complete.

[0019] It should be noted that when a component is said to be "fixed to" another component, it can be directly on the other component or there may be an intervening component. When a component is said to be "connected to" another component, it can be directly connected to the other component or there may be an intervening component. The terms "vertical," "horizontal," "left," "right," and similar expressions used in this document are for illustrative purposes only.

[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0021] Example 1 Please see Figure 1 The first embodiment of the present invention provides an emergency control method for an urban LED street lighting system, the method comprising steps S10-S50: Step S10: Continuously acquire the operating status data automatically fed back by each lighting subsystem in the urban lighting system.

[0022] First, it should be noted that urban lighting systems are lighting systems that serve urban areas, such as road street light systems and building light curtain systems. These systems are connected to numerous lighting IoT devices, and lighting control is achieved by controlling the corresponding lighting fixtures through these IoT devices.

[0023] In this embodiment, during the operation of the urban lighting system, the system continuously acquires operational status data automatically fed back from each lighting subsystem according to a preset time period. Specifically, this data consists of periodic data on the operation of the lighting subsystems. The transmitted periodic data includes four categories: heartbeat data, server status information, lighting platform and IoT platform status information, and lighting operation status data, including light-on / off times and brightness adjustments.

[0024] Preferably, heartbeat data is transmitted repeatedly at 30-second intervals to determine whether the lighting subsystem is operating normally at the current moment; server status information monitors the resource usage of the lighting server as a basis for judging its operational status; and the connection status information between the lighting platform and the IoT platform determines the network status between the lighting subsystem and the IoT platform, and whether the current network status can control its devices normally. More specifically, the latest operational status data is transmitted to the emergency takeover system every day, enabling emergency takeover in the event of any abnormal situation in the lighting subsystem, thus allowing the lighting fixtures to still be controlled according to the pre-set control logic.

[0025] Step S20: The operating status data is used as the initial transaction, and consensus and evidence are obtained in the blockchain network composed of the subsystem nodes and the regulatory nodes corresponding to each of the lighting subsystems.

[0026] In this embodiment, the steps of using the operational status data as the initial transaction and achieving consensus and notarization within the blockchain network composed of the subsystem nodes and monitoring nodes corresponding to each of the lighting subsystems include: The subsystem nodes and the supervisory nodes in the blockchain network communicate in P2P via the Gossip protocol. The PBFT consensus algorithm is used to enable all honest nodes in the blockchain network to reach a consensus on the transaction block containing the running state data; The data structure for evidence storage includes a block header and a block body. The block header contains a consensus signature and a parent hash, and the block body contains at least one of the following: heartbeat data transaction, status information transaction, emergency takeover instruction transaction, and control log transaction.

[0027] Specifically, in this embodiment, after obtaining the operating status data automatically fed back by each lighting subsystem, the operating status data is used as the initial transaction in the blockchain network composed of the subsystem nodes and regulatory nodes corresponding to the lighting subsystems. The PBFT consensus algorithm is used to enable all honest nodes in the blockchain network to reach a consensus on the transaction block containing the operating status data. The honest nodes include subsystem nodes and regulatory nodes.

[0028] More specifically, the data structure of the notarized operational status data includes a block header and a block body. The block header includes the consensus signature and parent hash after consensus, while the block body includes at least one of the following: heartbeat data transaction, status information transaction, emergency takeover instruction transaction, and control log transaction. For example, it may only include heartbeat data transaction, but it usually includes all four of them: heartbeat data transaction, status information transaction, emergency takeover instruction transaction, and control log transaction.

[0029] Furthermore, the steps of employing the PBFT consensus algorithm to ensure that all honest nodes in the blockchain network reach a consensus on transaction blocks containing the operational state data include: The currently rotating ledger node in the blockchain network will attach a digital signature to the packaged transaction block and broadcast it as a pre-preparation message to all nodes in the network. The pre-preparation message includes the block content, view number, and sequence number. After receiving the pre-preparation message, each node in the blockchain network verifies the signature validity of the accounting node, the correctness of the view number, and the compliance of the transaction format. After successful verification, each node in the blockchain network enters the preparation phase and broadcasts a preparation message to the entire network. When a node collects at least 2f+1 valid prepare messages from different nodes, it enters the commit phase and broadcasts a commit message; where f is the maximum allowed number of Byzantine fault nodes. Once a node has collected at least 2f+1 valid commit messages, it confirms the transaction block as the final valid block and writes it into the local ledger. If consensus is not reached within a preset time, the node will trigger a view replacement protocol to re-elect the ledger node and update the view number, so as to ensure that the blockchain network continues to operate and eventually reaches a consensus state even if some nodes fail or act maliciously.

[0030] Specifically, when using the PBFT consensus algorithm, a ledger node is first elected in the blockchain network and rotated. The currently rotating ledger node packages the transaction blocks, adds a digital signature (i.e., a consensus signature), and broadcasts it as a pre-preparation message to all nodes in the blockchain network. The pre-preparation message includes the specific block content, view number, and corresponding sequence number. After each node in the blockchain network receives the pre-preparation message, it verifies the validity of the ledger node's signature, the correctness of the view number, and the compliance of the transaction format. After successful verification, each node in the blockchain network enters the formal preparation phase and broadcasts the formal preparation message to the entire blockchain network. When a node collects at least 2f+1 valid preparation messages from different nodes, it enters the subsequent commit phase and broadcasts the commit message, where f is the maximum allowed number of Byzantine fault nodes and is an integer. When a node collects at least 2f+1 valid commit messages, the corresponding transaction block is determined as the final valid block and written into the local ledger in the blockchain network for recording.

[0031] If consensus is not reached within a preset time, such as not receiving 2f+1 valid preparation messages or not receiving 2f+1 valid commit messages, it is considered that the initial transaction corresponding to the running state data has not reached consensus in the blockchain network. At this time, the corresponding node will trigger a view update, re-elect a ledger node in the blockchain network and update the corresponding view number. This ensures that the blockchain network can continue to operate even if some nodes in the blockchain network are faulty or malicious, and eventually achieve a consistent state of the initial transaction corresponding to the running state data. Finally, the running state data is used as the initial transaction for consensus and evidence storage in the blockchain network.

[0032] Step S30: Based on the operational status data stored in the blockchain network, dynamically generate and update rule configuration items that match the environment of each lighting subsystem.

[0033] Specifically, in this embodiment, the system first queries the blockchain network ledger for all stored operational status data of the target lighting subsystem within a specific historical period. This data possesses high credibility due to its blockchain recording. Simultaneously, environmental parameters of the subsystem are collected or acquired in real time via an IoT sensor network, including but not limited to temperature, humidity, light intensity, network signal strength, and even seasonal weather patterns. Then, data mining is used to analyze the correlation between these environmental parameters and key operational status parameters (such as lamp failure rate, brightness decay rate, and communication latency), constructing a correlation model.

[0034] Based on the aforementioned correlation model, the thresholds preset in the rule parameter library are dynamically adjusted. It's important to note that this process is not a simple one-to-one mapping, but rather considers the combined influence of multiple environmental factors. By employing regression analysis or lightweight machine learning models, a rule parameter threshold range matching the unique environmental conditions of each lighting subsystem is fitted. More importantly, a rule parameter correlation matrix is ​​pre-defined within the system, defining the logical relationships and weights between different rule parameters.

[0035] For example, when a parameter is adjusted due to environmental changes, such as when the maximum allowable communication delay is attenuated due to heavy rain, the associated parameters are automatically triggered to adjust in a coordinated manner according to the above-mentioned rule parameter association matrix, such as the heartbeat timeout judgment threshold, thereby ensuring the internal logic self-consistency and consistency of the entire rule configuration item.

[0036] After the adjustments are completed, a new version of the rule configuration items is generated. It should be noted that the new rules are not applied immediately after generation; instead, they are first verified in a simulation or test environment to ensure that their accuracy meets the preset standards.

[0037] After successful verification, a unique version number will be generated for the new rule configuration item, and the complete rule content, version number, effective timestamp, and adjustment basis will be submitted to the blockchain network as a transaction. After consensus is reached, this record will be permanently stored, forming an immutable rule update history. This not only ensures the transparency and auditability of rule changes but also provides a reliable data foundation for subsequent analysis of rule effectiveness.

[0038] S40, according to the rule configuration items, the real-time acquired operating status data is identified in the preset multi-level early warning processing node to determine whether the emergency takeover conditions are triggered.

[0039] Specifically, in this embodiment, a topology architecture comprising primary nodes, intermediate nodes, and advanced nodes is constructed. Each lighting subsystem is bound to a primary node, which acts as a front-line monitoring unit, responsible for receiving and parsing the operational status data uploaded by its bound subsystem in real time. The primary node does not use fixed rules for judgment; instead, it proactively retrieves the latest dynamically generated rule configuration items for that subsystem from the blockchain and quickly matches and initially identifies the real-time data against the dynamic thresholds in the configuration items.

[0040] When a primary node identifies a potential anomaly, it does not immediately trigger a global emergency response. For general anomalies, the node will first attempt localized recovery operations, such as re-requesting data or sending a reset command. If the anomaly persists or its severity exceeds the primary node's processing threshold, it will submit an alert report containing a snapshot of the anomaly data, the version identifier of the applied rule, and preliminary analysis results to its upper-level intermediate node.

[0041] Upon receiving an alert from the primary node, the intermediate node plays a role in regional collaborative verification. It proactively retrieves similar data from other normal subsystems within its jurisdiction for horizontal comparative analysis to determine whether the anomaly is an isolated event or a regional problem. If necessary, the intermediate node will issue further diagnostic commands to the target subsystem for verification. Based on a comprehensive assessment of data from multiple sources, the intermediate node makes a preliminary decision on whether to trigger emergency takeover conditions.

[0042] For major or complex anomalies, decision requests can be further reported to higher-level nodes with a global perspective. These higher-level nodes will make the final decision based on the overall system status. Thus, the multi-level early warning processing nodes mentioned above identify the operational status and determine whether emergency takeover conditions have been triggered.

[0043] Step S50: When the emergency takeover condition is triggered, a high-priority emergency takeover instruction transaction is generated through the regulatory node, and after consensus by the blockchain network, it is stored as evidence. Based on the stored instruction, the control authority of the corresponding lighting subsystem is switched to the associated system.

[0044] Specifically, in this embodiment, once the multi-level early warning processing nodes determine that a lighting subsystem meets the emergency takeover conditions, the permission switching process is immediately activated. First, the supervisory node, as the authorized privileged node, generates a high-priority emergency takeover instruction transaction. This transaction is digitally signed by the supervisory node and explicitly includes key information such as the unique identifier of the target lighting subsystem, a summary of the abnormal event triggering the takeover, and the version hash of the rule configuration item on which it is based. By assigning a high-priority tag, the aforementioned emergency takeover instruction transaction ensures that it will be prioritized by the network in the subsequent consensus process, thereby minimizing the delay in emergency response.

[0045] Subsequently, the emergency takeover order transaction is broadcast to the blockchain network consisting of all subsystem nodes and supervisory nodes, and enters the PBFT consensus process. Honest nodes in the blockchain network will verify the legality and validity of the emergency takeover order transaction. For example, after reaching a consensus of more than 2 / 3 of the nodes, the emergency takeover order transaction will be packaged into a new block and permanently recorded on the immutable distributed ledger.

[0046] Compared with existing technologies, the emergency control method for urban LED street lighting systems shown in this embodiment has the following advantages: By constructing a technical framework that deeply integrates blockchain's trusted mechanisms and intelligent decision-making algorithms, a substantial improvement in the reliability, accuracy, and transparency of emergency control has been achieved. First, by using the operational status data of each lighting subsystem as initial transactions for consensus-based notarization on the blockchain network, the immutability of data sources and full-chain traceability are ensured, building a solid and reliable data foundation for subsequent analysis and decision-making. Second, rule configuration items are dynamically generated and updated based on trusted historical data and environmental parameters accumulated on the blockchain, enabling emergency takeover triggering conditions to adapt to specific situations in different regions and environments. This effectively avoids misjudgments caused by general rules and significantly improves the accuracy of condition judgments. Finally, the entire emergency decision-making and execution process, from the collaborative judgment of multi-level early warning nodes to the consensus-based notarization of high-priority emergency command transactions generated by regulatory nodes, and finally to the switching of control authority, is fully recorded on the blockchain, forming a closed-loop trusted audit chain. This not only ensures the authority of emergency takeover commands and the traceability of the execution process but also greatly enhances overall reliability and transparency.

[0047] Example 2 The second embodiment of the present invention also provides an emergency control method for an urban LED street lighting system, which is basically similar to the method shown in the first embodiment, except that: In this embodiment, the step of dynamically generating and updating rule configuration items that match the environment of each lighting subsystem based on the operational status data stored in the blockchain network includes: Obtain the operational status data of any lighting subsystem and its corresponding environmental parameters from the blockchain network, and analyze the correlation between the environmental parameters and the operational status parameters in the operational status data; Based on the aforementioned relationship, the threshold range of each rule parameter in the pre-built rule parameter library is dynamically adjusted to adapt the threshold to different environmental conditions, thereby updating the rule configuration items corresponding to each of the lighting subsystems. The adjusted rule configuration items and their version information are recorded as transactions on the blockchain, forming a traceable rule update history.

[0048] The step of dynamically adjusting the threshold range of each rule parameter in the pre-built rule parameter library according to the association relationship, so that the threshold adapts to different environmental conditions, in order to update the rule configuration items corresponding to each of the lighting subsystems, includes: Based on the correlation between environmental parameters and operating status parameters, the threshold range of the corresponding parameters in the rule parameter library is automatically adjusted to generate dynamic threshold ranges that adapt to different environmental conditions. Based on the preset rule parameter association matrix, when any parameter threshold is adjusted, the thresholds of its associated parameters are automatically triggered to adjust in a coordinated manner, ensuring the internal logic consistency of the rule configuration items.

[0049] The step of automatically triggering the coordinated adjustment of the thresholds of its associated parameters when any parameter threshold is adjusted, based on a preset rule parameter association matrix, to ensure the internal logical consistency of the rule configuration items, includes: When an adjustment to the threshold of any target rule parameter is detected, the rule parameter association matrix is ​​queried to identify all associated parameters that are related to the target rule parameter; based on the predefined weight coefficients in the rule parameter association matrix, the impact coefficient of the target parameter threshold adjustment on each associated parameter is calculated. Based on the aforementioned influence coefficient, the threshold of each associated parameter is automatically adjusted proportionally. After the adjustment is completed, a logical consistency check is performed on all updated rule configuration items to ensure that the constraint relationship between the threshold parameters meets the preset conditions, and the version information corresponding to the finally effective rule configuration items is recorded in the blockchain network.

[0050] The steps, including performing logical consistency checks on all updated rule configuration items after adjustments are completed to ensure that the constraint relationships between the threshold parameters meet preset conditions, and recording the version information corresponding to the finally effective rule configuration items in the blockchain network, include: Read the updated rule configuration items and verify whether the threshold values ​​of each parameter meet the predefined constraints, including the compatibility of the numerical ranges of the parameters, the logical order, and the mutual exclusion relationship. When a parameter threshold is found to violate the constraint relationship, an alarm is automatically triggered and the rule configuration item is marked as pending correction. The rule configuration item that passes the logical consistency check will be bound to a new version identifier, and the check result, version information and effective timestamp will be used to generate a check record transaction, which will be submitted to the blockchain network for evidence storage. If the verification fails, the alarm information and the rule configuration items to be corrected will be recorded as transactions on the blockchain network, forming an auditable verification history.

[0051] Specifically, in this embodiment, obtaining operational status data from the blockchain network and analyzing its correlations is the foundation of the entire process. The notarized operational status data possesses the characteristics of being immutable and traceable, providing a high-quality data foundation for analysis. Through data mining techniques, the causal relationships or strong correlations between specific environmental parameters and key operational status parameters are analyzed, such as the causal relationships or strong correlations between the number of consecutive high-temperature days, average humidity, and LED light decay rate, and driver failure rate.

[0052] After confirming the correlation, the thresholds are dynamically adjusted while ensuring logical consistency. This stage comprises two levels. The first level is direct adjustment, which automatically modifies the threshold range of the target parameter in a pre-defined rule parameter library based on the analysis results, thereby generating a dynamic threshold range adapted to specific environmental conditions. More importantly, the second level is collaborative adjustment. This involves a pre-defined rule parameter correlation matrix, which defines the logical relationships and influence weights between different parameters. When a parameter is increased due to environmental changes, such as a network latency threshold being increased due to severe weather, its related parameters are immediately retrieved from the matrix, such as heartbeat timeout thresholds and packet retransmission count thresholds. The thresholds of these related parameters are then automatically adjusted proportionally according to their weight coefficients. This ensures that the entire rule configuration item, as a whole, has self-consistent and consistent internal logic, preventing contradictory or conflicting judgment conditions between parameters.

[0053] Finally, in some feasible implementations, after the parameters are adjusted, the complete rule configuration items are automatically verified to check whether they meet the predefined business logic constraints, such as the lower limit of the alarm threshold must be less than the upper limit, and there must be a reasonable interval between alarm thresholds of different levels.

[0054] After verification, the final rule configuration items, version number, effective timestamp, and verification result itself are combined to generate a transaction and submitted to the blockchain network for notarization. This not only creates an immutable audit trail for rule changes, making the reasons, content, and results of each rule update traceable, but also provides reliable data for rule rollback or effect analysis.

[0055] In addition, if the verification fails, the alarm information and the problematic configuration items will be recorded on the blockchain, thereby forcibly triggering the manual intervention process and ensuring overall stability.

[0056] Example 3 The third embodiment of the present invention also provides an emergency control method for an urban LED street lighting system, which is basically similar to the method shown in the second embodiment, except that: In this embodiment, the step of obtaining operational status data of any lighting subsystem and its corresponding environmental parameters from the blockchain network, and analyzing the correlation between the environmental parameters and the operational status parameters in the operational status data, includes: Obtain operational status data and corresponding environmental parameters of any lighting subsystem within multiple consecutive time windows from the blockchain network, and align the operational status data with the environmental parameters; The nonlinear correlation strength between each operating status parameter and the environmental parameter in the operating status data is quantified, and strong correlation feature pairs are selected. Based on the strongly correlated feature pairs, key operating state parameters that have a causal driving effect on changes in the environmental parameters are identified.

[0057] The step of quantifying the nonlinear correlation strength between each operational status parameter and the environmental parameters in the operational status data, and selecting strongly correlated feature pairs, includes: Calculate the nonlinear correlation between various environmental parameters and operating status parameters; The marginal probability distribution and joint probability distribution of the parameters are fitted by kernel density estimation to quantify the amount of information about the operating state parameters contained in the changes of the environmental parameters, and a correlation strength matrix is ​​generated accordingly. Based on a preset dynamic threshold, strongly correlated feature pairs with mutual information values ​​higher than the dynamic threshold are selected from the correlation strength matrix.

[0058] Specifically, in this embodiment, in the process of dynamically generating and updating rule configuration items that match the environment of each lighting subsystem based on the operational status data stored in the blockchain network, the correlation between environmental parameters and operational status parameters in the operational status data will be analyzed first, so as to set rule configuration items for condition judgment according to the correlation between environmental parameters and operational status parameters in the operational status data.

[0059] More specifically, in this embodiment, the operational status data and corresponding environmental parameters of any lighting subsystem obtained from the blockchain network within multiple consecutive time windows after consensus and notarization are first processed. The operational status data and environmental parameters are then standardized and aligned using a sliding window. Next, the nonlinear correlation strength between the operational status parameters and environmental parameters in the operational status data is precisely quantified, and strong correlation feature pairs are selected, that is, feature pairs where the operational status parameter features and environmental parameter features are strongly correlated. Finally, based on these strong correlation feature pairs, a causal inference method based on convergent cross-mapping is used to distinguish between causal relationships and simple correlation relationships, and to identify key operational status parameters that have a significant causal driving effect on changes in environmental parameters.

[0060] The process of quantifying the nonlinear correlation strength between various operating state parameters and environmental parameters, and selecting strongly correlated feature pairs, includes fitting the marginal probability distribution and joint probability distribution of the operating state parameters and environmental parameters through a kernel density estimation algorithm, thereby quantifying the amount of information about the operating state parameters contained in the changes of environmental parameters, generating a correlation strength matrix accordingly, and finally selecting strongly correlated feature pairs with mutual information values ​​higher than the aforementioned dynamic threshold from the correlation strength matrix based on a pre-set dynamic threshold.

[0061] Example 4 Please see Figure 2 The fourth embodiment of the present invention provides an emergency control system for an urban LED street lighting system, applied to the method described in any of the above embodiments, the system comprising: Data acquisition module 10 is used to continuously acquire the operating status data automatically fed back by each lighting subsystem in the urban lighting system; The data storage module 20 is used to take the operating status data as the initial transaction and perform consensus and storage in the blockchain network composed of the subsystem nodes and the supervision nodes corresponding to each of the lighting subsystems. The rule generation module 30 is used to dynamically generate and update rule configuration items that match the environment of each lighting subsystem based on the operational status data stored in the blockchain network. The condition judgment module 40 is used to identify the real-time acquired operating status data in the preset multi-level early warning processing node according to the rule configuration items, so as to determine whether the emergency takeover condition is triggered. The takeover execution module 50 is used to generate a high-priority emergency takeover instruction transaction through the regulatory node when the emergency takeover conditions are triggered, store the transaction after consensus through the blockchain network, and switch the control authority of the corresponding lighting subsystem to the associated system based on the stored instruction.

[0062] Compared with existing technologies, the advantages of using the emergency control system for urban LED street lighting systems shown in this embodiment are as follows: By constructing a technical framework that deeply integrates blockchain's trusted mechanisms and intelligent decision-making algorithms, a substantial improvement in the reliability, accuracy, and transparency of emergency control has been achieved. First, by using the operational status data of each lighting subsystem as initial transactions for consensus-based notarization on the blockchain network, the immutability of data sources and full-chain traceability are ensured, building a solid and reliable data foundation for subsequent analysis and decision-making. Second, rule configuration items are dynamically generated and updated based on trusted historical data and environmental parameters accumulated on the blockchain, enabling emergency takeover triggering conditions to adapt to specific situations in different regions and environments. This effectively avoids misjudgments caused by general rules and significantly improves the accuracy of condition judgments. Finally, the entire emergency decision-making and execution process, from the collaborative judgment of multi-level early warning nodes to the consensus-based notarization of high-priority emergency command transactions generated by regulatory nodes, and finally to the switching of control authority, is fully recorded on the blockchain, forming a closed-loop trusted audit chain. This not only ensures the authority of emergency takeover commands and the traceability of the execution process but also greatly enhances overall reliability and transparency.

[0063] Example 5 A fifth embodiment of the present invention provides a readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the steps of the method described in any of the above embodiments.

[0064] Example 6 A sixth embodiment of the present invention provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method described in any of the above embodiments.

[0065] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0066] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the protection scope of the present invention. Therefore, the protection scope of this patent should be determined by the appended claims.

Claims

1. An emergency control method for an urban LED street lighting system, characterized in that, The method includes: Continuously acquire operational status data automatically fed back from various lighting subsystems in the urban lighting system; The operational status data is used as the initial transaction, and consensus and evidence are obtained in the blockchain network composed of the subsystem nodes and the regulatory nodes corresponding to each of the lighting subsystems. Based on the operational status data stored in the blockchain network, rule configuration items that match the environment of each lighting subsystem are dynamically generated and updated. According to the rule configuration items, the real-time acquired operation status data is identified in the preset multi-level early warning processing nodes to determine whether the emergency takeover conditions are triggered. When the emergency takeover conditions are triggered, a high-priority emergency takeover instruction transaction is generated through the monitoring node, which is then stored after consensus by the blockchain network. Based on the stored instruction, the control authority of the corresponding lighting subsystem is switched to the associated system. The step of dynamically generating and updating rule configuration items that match the environment of each lighting subsystem, based on the operational status data stored in the blockchain network, includes: Obtain operational status data and corresponding environmental parameters of any lighting subsystem within multiple consecutive time windows from the blockchain network, and align the operational status data with the environmental parameters; Calculate the nonlinear correlation between various environmental parameters and operating status parameters; The marginal probability distribution and joint probability distribution of the parameters are fitted by kernel density estimation to quantify the amount of information about the operating state parameters contained in the changes of the environmental parameters, and a correlation strength matrix is ​​generated accordingly. Based on a preset dynamic threshold, strongly correlated feature pairs with mutual information values ​​higher than the dynamic threshold are selected from the correlation strength matrix. Based on the strongly correlated feature pairs, key operating state parameters that have a causal driving effect on the changes in the environmental parameters are identified; Based on the correlation between environmental parameters and operating status parameters, the threshold range of the corresponding parameters in the rule parameter library is automatically adjusted to generate dynamic threshold ranges that adapt to different environmental conditions. Based on the preset rule parameter association matrix, when any parameter threshold is adjusted, the threshold of its associated parameters is automatically triggered to adjust in a coordinated manner, ensuring the internal logic consistency of the rule configuration items. The adjusted rule configuration items and their version information are recorded as transactions on the blockchain, forming a traceable rule update history.

2. The emergency control method for urban LED street lighting system according to claim 1, characterized in that, Based on a preset rule parameter association matrix, when any parameter threshold is adjusted, the thresholds of its associated parameters are automatically triggered for coordinated adjustment. This ensures the internal logical consistency of the rule configuration items. The steps include: When an adjustment to the threshold of any target rule parameter is detected, the rule parameter association matrix is ​​queried to identify all associated parameters that are related to the target rule parameter; based on the predefined weight coefficients in the rule parameter association matrix, the impact coefficient of the target parameter threshold adjustment on each associated parameter is calculated. Based on the aforementioned influence coefficient, the threshold of each associated parameter is automatically adjusted proportionally. After the adjustment is completed, a logical consistency check is performed on all updated rule configuration items to ensure that the constraint relationship between the threshold parameters meets the preset conditions, and the version information corresponding to the finally effective rule configuration items is recorded in the blockchain network.

3. The emergency control method for urban LED street lighting system according to claim 2, characterized in that, After the adjustment is completed, the following steps are performed: Logical consistency verification is performed on all updated rule configuration items to ensure that the constraint relationships between the threshold parameters meet the preset conditions; and the version information corresponding to the finally effective rule configuration items is recorded in the blockchain network. Read the updated rule configuration items and verify whether the threshold values ​​of each parameter meet the predefined constraints, including the compatibility of the numerical ranges of the parameters, the logical order, and the mutual exclusion relationship. When a parameter threshold is found to violate the constraint relationship, an alarm is automatically triggered and the rule configuration item is marked as pending correction. The rule configuration item that passes the logical consistency check will be bound to a new version identifier, and the check result, version information and effective timestamp will be used to generate a check record transaction, which will be submitted to the blockchain network for evidence storage. If the verification fails, the alarm information and the rule configuration items to be corrected will be recorded as transactions on the blockchain network, forming an auditable verification history.

4. An emergency control system for an urban LED street lighting system, characterized in that, The system, applicable to the method of any one of claims 1-3, comprises: The data acquisition module is used to continuously acquire the operating status data automatically fed back by various lighting subsystems in the urban lighting system; The data storage module is used to take the operating status data as the initial transaction and conduct consensus and storage in the blockchain network composed of the subsystem nodes and the supervision nodes corresponding to each of the lighting subsystems. The rule generation module is used to dynamically generate and update rule configuration items that match the environment of each lighting subsystem based on the operational status data stored in the blockchain network. The condition judgment module is used to identify the real-time acquired operating status data in the preset multi-level early warning processing nodes according to the rule configuration items, so as to determine whether the emergency takeover conditions are triggered. The takeover execution module is used to generate a high-priority emergency takeover instruction transaction through the supervisory node when the emergency takeover conditions are triggered. After consensus is reached through the blockchain network, the transaction is stored as evidence, and the control authority of the corresponding lighting subsystem is switched to the associated system based on the stored instruction.

5. A readable storage medium having computer instructions stored thereon, characterized in that, When executed by the processor, this instruction implements the steps of the method as described in any one of claims 1-3.

6. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method as described in any one of claims 1-3.

Images