A tower type light and heat distributed mirror field hybrid control system based on a blockchain consensus mechanism

Abstract

The present application relates to the field of tower type photothermal power station mirror field control system, specifically relates to a kind of tower type photothermal distributed mirror field hybrid control system based on block chain consensus mechanism, comprising: physical layer, data layer, network layer, consensus layer, contract layer, application management layer.Through the depth coupling control theory and block chain technology, the contradiction between the limited mirror power and the function demand of block chain full node is solved, the EFB is established as the sub-field agent full node, and the main and standby redundancy mechanism is designed, which guarantees the reliability of control link, realizes efficient distributed consensus and smart contract execution, the DW-PBFT consensus mechanism proposed reduces the consensus delay while improving fault tolerance through dynamic weight model, and the NTRU-SPHINCS+ hybrid quantum-resistant password architecture provides future-oriented security protection for the system.

Description

Technical Field

[0001] This invention relates to the field of mirror field control systems for tower-type solar thermal power plants, and more specifically to a hybrid control system for distributed mirror fields of tower-type solar thermal power plants based on a blockchain consensus mechanism. Background Technology

[0002] Against the backdrop of the accelerated global energy transition towards clean energy, solar energy has garnered widespread attention due to its abundant, clean, and sustainable characteristics. Tower solar thermal power generation technology, with its high conversion efficiency and excellent energy storage characteristics, has become a research hotspot in the field of solar energy utilization. The heliostat field control system, as the core of the tower solar thermal power generation system, directly determines the operational performance of the entire power generation system.

[0003] However, while large-scale mirror fields improve solar energy collection efficiency, they also expose many bottlenecks in traditional centralized control systems, including insufficient computing power of control nodes, slow response speed, low level of intelligence, and poor scalability.

[0004] Traditional centralized control systems rely on a central control unit to manage all heliostats uniformly. When dealing with large-scale heliostat fields, the central control unit must process massive amounts of control data, easily leading to computational resource constraints and control response delays, making it difficult to accurately control requirements. Simultaneously, the massive amount of communication data between the heliostats and the central control unit not only increases network load and causes transmission delays but may also lead to communication failures, affecting system stability and real-time performance. More importantly, the centralized architecture carries the risk of a single point of failure; if the central control unit fails, the entire heliostat field will be paralyzed, resulting in significant economic losses. Furthermore, existing control systems lack robust control interaction encryption mechanisms and audit traceability links, which is detrimental to the field's data privacy, control security, and information traceability. Summary of the Invention

[0005] To address the severe challenges in real-time performance, security, and reliability faced by existing tower-type solar thermal power plant mirror field control systems, the present invention aims to provide a hierarchical collaborative model designed for the massive, weak computational characteristics of heliostats in the mirror field. Simultaneously, by improving the consensus algorithm, the latency is compressed to within 150ms, filling the application gap of blockchain in real-time solar thermal control scenarios. Furthermore, the control process incorporates Dilithium quantum-resistant signatures and NTRU lattice cryptography encryption mechanisms, proactively establishing quantum-resistant security for the system. This results in a tower-type solar thermal distributed mirror field hybrid control system based on a blockchain consensus mechanism.

[0006] To achieve the above objectives, the technical solution adopted by this invention is: a tower-type distributed optical-thermal hybrid control system based on a blockchain consensus mechanism, comprising: Physical layer: This includes the underlying hardware carrier, which is used for field data acquisition, physical action execution, and basic operation support. It provides a real input source for upper-level control decisions and ultimately implements all control commands. Data layer: Used for data collection, sharing, synchronization and storage, ensuring data security and reliability and providing distributed file transfer service for historical data. Data collected from the physical layer is integrated, cleaned, configured with permissions and encrypted securely before being shared to the entire system. Network Layer: Constructing distributed blockchain nodes EFB, each sub-field EFB participates in the blockchain network as a full node, used for consensus execution, hybrid automaton maintenance, heliostat data collection, storage sharing and smart contract execution. The heliostat, as a light node, interacts with the chain through the EFB proxy. Consensus Layer: The consensus process takes place between EFB nodes. Dynamic weight calculation and leader election are performed based on the performance indicators of EFB nodes, taking into account both command response speed and mirror operation efficiency. Through a four-dimensional weight model of historical reputation, real-time performance, resource stability, and online duration, fault tolerance and real-time performance are optimized in a coordinated manner. Contract layer: As the core of the system's intelligent decision-making, its functions are distributed across the blockchain network and EFB nodes, forming a layered smart contract execution architecture; Application Management Layer: Provides users with an intuitive and convenient operating interface, covering human-computer interaction functions such as field management, monitoring, operation and maintenance, equipment monitoring, alarm monitoring, intelligent prediction, and data query.

[0007] The aforementioned tower-type distributed optical-thermal hybrid control system based on blockchain consensus mechanism deploys two EFB nodes—a primary blockchain distributed node and a backup blockchain distributed node—in the network layer of each subfield. These nodes form a high-availability cluster through heartbeat detection and state synchronization. When the primary EFB fails, the backup EFB automatically takes over within 100 milliseconds, broadcasting the identity change through the blockchain and updating the smart contract node status to switch between primary and backup identities.

[0008] The aforementioned tower-type distributed optical-thermal hybrid control system based on a blockchain consensus mechanism includes a control chain and an audit chain in the network layer. The control chain is used for real-time control command transmission. Control transactions are encrypted using Dilithium quantum-resistant signatures and NTRU lattice cryptography to prevent tampering and ensure transmission security. Command execution broadcasts are routed based on subfield IDs to reduce network load. The audit chain stores historical operation and status data, providing data traceability. The control chain and audit chain use an asynchronous event-driven mechanism to synchronize key metadata, ensuring audit integrity without affecting control real-time performance.

[0009] The aforementioned tower-type photothermal distributed mirror field hybrid control system based on blockchain consensus mechanism includes the following steps for processing instructions on the control chain: Step 1: Before the control command is issued, the owner completes the digital signature using the Dilithium quantum-resistant signature algorithm to generate a control transaction. The signed control transaction is then encrypted using the NTRU lattice cryptography algorithm and broadcast to all EFB full nodes. After receiving the encrypted transaction, the EFB nodes complete the decryption and three-layer verification and put the control transaction into the consensus queue. Step 2: Convert business urgency into consensus priority, sort consensus based on priority, and prioritize the processing of urgent control instructions; Step 3: Based on the DW-PBFT consensus mechanism, a deterministic leader election is adopted. The consensus efficiency and fault tolerance are optimized through a quantitative weight calculation model. The consensus process is initiated. After consensus is reached, the orderly control transaction list is submitted to the task scheduling contract for execution. The contract execution is atomic. The control logic is solidified into code to ensure the transparency and consistency of the control strategy. Step 4: After the contract is executed, the generated sub-field-level commands are issued through the instruction routing mechanism, seamlessly connecting the blockchain's global decision-making with EFB's local execution. After the heliostat executes the command, it sends the status receipt to EFB. EFB packages the command execution result, signs it with the Dilithium private key, generates an audit transaction, and uploads it to the audit chain for evidence storage.

[0010] In the aforementioned tower-type distributed optical-thermal hybrid control system based on blockchain consensus mechanism, after the control transaction enters the node's local memory pool in step 2, the priority calculation formula is as follows: ,in, , This represents the normalized weighting coefficients determined through sensitivity analysis. Indicates the current time. This indicates the maximum timeout period for executing control commands, set according to the requirements of the mirror field control. Indicates the level of control instructions determined by the command type.

[0011] In the aforementioned tower-type distributed optical-thermal hybrid control system based on a blockchain consensus mechanism, in step 3, the EFB node with the highest weight is the leader node, and the weight is determined by historical reputation. Performance indicators Resource stability and online time The weights are determined by a combination of four dimensions, and each EFB node calculates its dynamic weight in each consensus cycle. The formula for the quantization weight calculation model is: ,in, , , , These are the normalized weighting coefficients; Step 3 includes: Step 3-1: The leader node sorts the verified control transactions according to priority and generates an ordered list of control transactions as a proposal. The proposal contains the leader node's Dilithium signature. Step 3-2: The leader node broadcasts the proposal to other EFB consensus nodes. After receiving the proposal, the consensus nodes verify the correctness of the order and the executability of the control transaction. Step 3-3: If the verification is successful, the consensus node returns a Prepare message containing its own weight, valid identifier, and signature. When the sum of the weights of the valid Prepare messages collected by the leader node exceeds 2 / 3 of the total weight, it enters the Commit phase. Steps 3-4: The leader node broadcasts a Commit message, and the consensus nodes verify it and return a Commit confirmation. Consensus is reached when the sum of the weights of the collected valid Commit messages exceeds 2 / 3 of the total weight.

[0012] Steps 3-5: The contract calculates the specific control instructions for each sub-field based on the instruction content and the current system state, and the contract state and execution results are synchronously updated to the blockchain state database; Steps 3-6: If the execution result is abnormal, the contract will automatically roll back to the state before execution to avoid inconsistencies in the system state.

[0013] In the aforementioned tower-type distributed optical-thermal hybrid control system based on a blockchain consensus mechanism, in step 4, after the corresponding EFB node detects an event, it executes the following steps: Step 4-1: Verify the legality and timeliness of the command again; Step 4-2: The local control contract receives commands, drives the internal hybrid automaton to perform state transitions and continuous calculations, and generates heliostat drive signals; Step 4-3: Send the drive signal to the heliostat for execution.

[0014] The aforementioned tower-type photothermal distributed mirror field hybrid control system based on a blockchain consensus mechanism includes an audit chain that performs the following functions: Data tiered storage: Compressed data state snapshots are stored locally on the EFB node, and the data hash and storage address are recorded through the blockchain to achieve an efficient architecture of on-chain index and off-chain storage; Data lifecycle management: Data is stored hierarchically according to its importance. Control command execution records are retained for ≥3 years, device status data is retained for ≥1 year, operation logs are retained for ≥6 months, and expired data is archived to a CD-ROM. Data access control: A blockchain-based permission management mechanism that authorizes nodes to access data, and access records are written to the audit chain to achieve data traceability and non-repudiation.

[0015] The aforementioned tower-type distributed optical-thermal hybrid control system based on a blockchain consensus mechanism includes blockchain-level smart contracts and EFB-level smart contracts in its contract layer. The blockchain-level smart contract is the global decision-making and management hub of the system. It is deployed on the full nodes of the blockchain and executes a unified strategy across sub-fields based on distributed consensus. All decision-making processes and results are stored on the blockchain to ensure global consistency and auditability. The EFB-level smart contract is the execution strategy of the system's local real-time control execution unit. It is embedded in a single EFB node and is responsible for converting the sub-field-level instructions issued by the blockchain-level smart contract into executable signals for a single heliostat, undertaking local computing and control tasks with extremely high real-time requirements.

[0016] The aforementioned tower-type distributed optical-thermal hybrid control system based on a blockchain consensus mechanism, wherein the different functional contracts of the blockchain-level smart contracts are deployed independently, and contract modules can be upgraded or added individually, including: Define the device status monitoring contract that sets global status monitoring rules and thresholds for the mirror field equipment; Calculate the subfield instruction allocation strategy based on the mirror field instructions, and generate a task scheduling contract for subfield-level control instructions; Define a global protection policy, a smart protection contract that is automatically executed when environmental or device data triggers a threshold; Based on the energy required for the operation of the heliostat field, an energy scheduling contract is made to schedule the heliostat to track the sun and follow the sun. A node management contract responsible for EFB node registration, status monitoring, master / slave failover, and key management; Based on environmental data, operational data, and calibration records, identify smart calibration contracts that require heliostat calibration and initiate calibration tasks. The EFB-level smart contracts reduce the storage and communication pressure on the blockchain network, including: It receives sub-field level commands issued by the blockchain, decomposes them into heliostat control commands, maintains the local hybrid automaton state, and executes local control contracts that perform continuous dynamic equation calculations. The state transition contract is automatically executed according to control commands and the state switching and resetting mapping is completed without waiting for blockchain confirmation, ensuring real-time state transition contracts. A data preprocessing contract that cleans, aggregates, and compresses the raw data reported by the subfield heliostats to reduce the amount of data uploaded to the chain and network load; It enables heartbeat detection and status synchronization between primary and backup EFBs, monitors the health status of the primary node, and automatically initiates a takeover process and registers a redundant switchover contract with the new primary node identity on the blockchain in case of failure. Before sunrise, the heliostat calculates the daily tracking schedule for one day and sends it to the heliostat's tracking schedule calculation contract. In continuous tracking mode, the heliostat performs interpolation based on the tracking schedule's time and step count, and then moves smoothly.

[0017] The beneficial effects of this invention's hybrid control system for a tower-type solar thermal distributed heliostat field based on a blockchain consensus mechanism are: it deeply integrates the tower-type solar thermal heliostat field control system with blockchain technology to construct a cyber-physical system. Addressing the constraint of limited computing power (microcontroller level) of the heliostat, an EFB (Electric Field Controller) is introduced as a subfield agent full node, forming a three-layer collaborative control system of blockchain-EFB-heliostat. By increasing or decreasing the number of EFB nodes, the system can flexibly adapt to heliostat fields of different sizes, achieving smooth expansion from small demonstration projects to ultra-large commercial power plants, demonstrating excellent scalability. As an independently deployable and manageable control unit, the EFB node supports modular expansion without requiring reconstruction of the existing system architecture, significantly reducing the complexity and cost of system expansion. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of a blockchain-based control system architecture in an embodiment of the present invention; Figure 2 This is a schematic diagram of the control chain operation process in an embodiment of the present invention; Figure 3 This is a schematic diagram of the mirror field arrangement in an embodiment of the present invention; Figure 4 This is a schematic diagram comparing the fault tolerance ratio of malicious nodes in embodiments of the present invention; Figure 5 This is a schematic diagram comparing the consensus latency performance of different weights in an embodiment of the present invention; Figure 6 This is a schematic diagram of the primary / backup EFB switching time distribution in an embodiment of the present invention; Figure 7 This is a schematic diagram comparing the response times of different weighted systems in an embodiment of the present invention. Detailed Implementation

[0019] To enable those skilled in the art to better understand the technical solution of the present invention, the technical solution of the present invention will be described below in conjunction with specific embodiments and accompanying drawings.

[0020] Example 1 The convergence of artificial intelligence, 6G wireless networks, and smart grids has triggered transformative changes in the design, management, and security of energy systems. This convergence brings new complexities related to interoperability, privacy protection, and standardization. Therefore, security and privacy will be central to the sustainable development of the next generation of smart grids.

[0021] The centralized, immutable, transparent, and traceable characteristics of blockchain technology offer a new path to address the pain points of distributed mirror field control systems. Its decentralized nature avoids single points of failure, improving system reliability; its immutability and auditability ensure the authenticity and integrity of control data, preventing malicious tampering; and smart contracts enable automated energy management, improving system response speed and operational efficiency. The application of blockchain in energy cyber-physical systems has evolved from "data traceability" to "real-time control."

[0022] Recent research has proposed the application of blockchain in the control of distributed photovoltaic clusters, realizing intelligent power allocation optimization through smart contracts, and providing market matching and transaction record services for producers and consumers. However, it has not considered the adaptation problem of weak computing terminals, and the consensus latency exceeds 300ms, which cannot meet the real-time control requirements of solar thermal mirror fields.

[0023] In recent years, hybrid automata have demonstrated good applicability and effectiveness in power quality control of photovoltaic systems and optimized operation of off-grid hybrid energy systems, providing strong methodological support for renewable energy integration and smart energy management. Addressing the safety control requirements of large-scale tower-type solar thermal mirror fields, this embodiment employs hybrid automata theory to formally model the mirror field's operating state. Complex continuous angle tracking is simplified into transitions between discrete states, and system safety is ensured through strict guard conditions and reset mapping.

[0024] The tower-type distributed photothermal mirror field hybrid control system in this embodiment is based on hybrid automata for mirror field status management, including heliostat status acquisition and maintenance. The hybrid automata can be defined as a seven-tuple. The components are defined as follows.

[0025] 1. Discrete state set Q: The definitions are shown in Table 1.

[0026] Table 1: Definition of Discrete State Set Q .

[0027] 2. Continuous state variable X, ,in, Indicates the first The horizontal angle (rad) of each heliostat , Indicates the first The elevation angle (rad) of a heliostat. , Indicates the first The cumulative value of the current horizontal step count for each heliostat. Indicates the first The cumulative value of the current pitch step count for each heliostat. This indicates the total number of heliostats.

[0028] 3. Control input set U, control input The target cumulative step count is directly issued, and the motor's underlying layer automatically calculates the deviation through "target cumulative value - current cumulative value".

[0029] Core input variables: This represents the cumulative step count for the i-th horizontal target of the heliostat. This represents the cumulative step count for the i-th heliostat elevation target.

[0030] 4. Continuous dynamic equations: The mapping relationship between the heliostat angle and the number of steps is used as the continuous motion equations.

[0031] ,in: This indicates the cumulative horizontal / pitch steps. This indicates the cumulative pitch steps. This represents the horizontal step count - angle conversion factor (steps / rad). This represents the pitch step count - angle conversion factor (steps / rad). This represents the horizontal angle compensation value (rad). This represents the pitch angle compensation value (rad).

[0032] 5. Guarding condition G (triggering discrete events), typical guarding conditions are shown in Table 2.

[0033] Table 2: Typical Guarding Conditions .

[0034] 6. Reset mapping R. Typical reset mappings are shown in Table 3.

[0035] Table 3: Typical Reset Mapping .

[0036] 7. Invariance conditions: Constraints on heliostat angle and step number to ensure safe equipment operation. .

[0037] The hybrid automata of each subfield is embedded in the EFB node. The EFB node is responsible for maintaining the state updates, guard conditions, reset mappings and invariant conditions of the state automata to ensure the normal and safe operation of each heliostat.

[0038] like Figure 1As shown, a tower-type distributed optical-thermal hybrid control system based on blockchain consensus mechanism has a core architecture consisting of six layers: physical layer, data layer, network layer, consensus layer, contract layer, and application management layer.

[0039] I. Physical layer.

[0040] The physical layer is the underlying hardware carrier of the entire control system, the heliostat equipment, and the heliostat itself. It undertakes three core functions: field data acquisition, physical action execution, and basic operational support. It provides the real input source for upper-level control decisions and ultimately implements all control commands. By integrating multi-dimensional environmental and equipment sensing capabilities, it provides comprehensive real-time status input to upper-level control, ensuring the accuracy of control decisions.

[0041] The physical layer includes common physical entities such as heliostat units, receivers, infrared thermography systems, weather stations, field electrical systems, field DCS systems, and all-sky imagers.

[0042] Heliostat Unit: Each heliostat is equipped with a transmission mechanism, a drive motor, and an embedded electronic communication module.

[0043] Heat absorber: an energy receiving terminal that completes the photothermal conversion.

[0044] Infrared temperature measurement system: Real-time monitoring of temperature and light intensity distribution at the focal point.

[0045] Weather station: Collects environmental data such as light intensity, temperature, and wind speed.

[0046] Mirror field electrical system: provides stable power supply and UPS backup power.

[0047] The mirror field DCS system works in conjunction with the control system to switch between different operating conditions of the mirror field.

[0048] All-sky imager: Provides weather cloud images and supports dynamic prediction of cloud activity.

[0049] II. Data Layer.

[0050] Primarily responsible for data collection, sharing, synchronization, and storage, ensuring data security and reliability, and providing distributed file transfer services for historical data. Environmental and equipment operating status data are collected through weather stations and sensors, and after integration, cleaning, permission configuration, and security encryption, shared throughout the entire system.

[0051] The system leverages blockchain to achieve multi-source data fusion, ensuring data quality and consistency. It adopts a distributed storage model, with each node jointly maintaining the data and using encryption technology to guarantee data authenticity, security, and privacy. Expired data is transferred and archived to reduce the storage pressure on nodes.

[0052] III. Network Layer.

[0053] This includes blockchain distributed nodes (EFB) and EFB redundancy architecture.

[0054] In the blockchain distributed node (EFB), each sub-farm EFB participates in the blockchain network as a full node, responsible for consensus execution, hybrid automaton maintenance, heliostat data collection, storage sharing, and smart contract execution. The heliostat, as a light node, interacts with the chain through an EFB proxy. By changing the number of sub-farms and adding or removing EFB nodes, the system can flexibly adapt to heliostat farms of different sizes, achieving smooth scaling from small demonstration projects to ultra-large commercial power plants. EFB nodes, as independently deployable and manageable control units, support modular expansion without requiring reconstruction of the existing system architecture, significantly reducing the complexity and cost of system expansion.

[0055] EFB Redundancy Architecture: Each sub-farm deploys two EFB nodes, one primary and one backup, forming a highly available cluster through heartbeat detection and status synchronization; when the primary EFB fails, the backup EFB can automatically take over within hundreds of milliseconds, broadcasting the identity change through the blockchain and updating the smart contract node status to switch between primary and backup identities, ensuring the continuity and reliability of the control link.

[0056] Dual-chain structure: including a control chain and an audit chain.

[0057] Control Chain: Responsible for real-time control command transmission. Control transactions are encrypted using Dilithium quantum-resistant signatures and NTRU ciphers to prevent tampering and ensure transmission security. The final broadcast of command execution is routed based on the sub-farm ID to reduce network load.

[0058] Audit Chain: Stores historical operation and status data, providing data traceability capabilities. The control chain and audit chain use an asynchronous event-driven mechanism to synchronize key metadata, ensuring audit integrity without affecting control real-time performance.

[0059] IV. Consensus Layer.

[0060] The consensus process takes place only among EFB nodes. This embodiment employs an improved PBFT consensus mechanism (DW-PBFT), which performs dynamic weight calculation and leader election based on performance indicators such as EFB node response time and resource utilization, balancing command response speed and mirror field operation efficiency.

[0061] Existing consensus mechanisms have significant limitations in energy scenarios. For example, while lightweight PBFT reduces communication complexity, it fails to consider the heterogeneity of node performance, resulting in significant consensus latency fluctuations under unbalanced loads. Furthermore, schemes incorporating reputation weights do not integrate real-time performance metrics, failing to address the timeliness requirements of control commands. This embodiment proposes DW-PBFT, which addresses these issues through a four-dimensional weight model of "historical reputation + real-time performance + resource stability + online duration," achieving synergistic optimization of fault tolerance and real-time performance.

[0062] Specifically, the "consensus," "audit," and "immutability" characteristics of blockchain are deeply embedded into the control loop to form a controllable, measurable, and auditable cyber-physical system. Through a dual-chain structure, the real-time transmission of control commands and the traceability and verification of historical data are coordinated. At the same time, the NTRU-Dilithium hybrid quantum-resistant cryptographic scheme is introduced to provide forward-looking security guarantees for on-chain data transmission, identity authentication, and storage integrity.

[0063] In the network and consensus layers, the control chain processes instructions through a distributed, ordered control instruction processing pipeline based on blockchain consensus. This ensures global consistency, timing correctness, and non-repudiation of instructions. Combined with the security enhancement design of the NTRU-Dilithium hybrid algorithm, the control chain's operation includes the following steps: Figure 2 As shown.

[0064] Step 1: Before issuing the control command, the owner completes the digital signature using the Dilithium quantum-resistant signature algorithm to generate the control transaction. The signed control transaction is then encrypted using the NTRU lattice cryptography algorithm and broadcast to all EFB full nodes. After receiving the encrypted transaction, the EFB nodes complete the decryption and three-layer verification and put the control transaction into the consensus queue.

[0065] Specifically, it includes: A: Transaction generation and signing (Initiate).

[0066] Before control commands are issued, the owner must complete the digital signature using the Dilithium quantum-resistant signature algorithm to generate the control transaction. Tx_control = {TxID, Nonce, Command, Tsend,Texpire, Sig_owner}, where: TxID represents a unique identifier for a transaction. Nonce indicates Number Used Once to prevent replay attacks; Command indicates the specific control command and parameters; Tsend indicates the control command sending timestamp; Texpire indicates the absolute expiration timestamp of the command to prevent replay of outdated commands; and Sig_owner indicates that Dilithium signature is used for authentication and non-repudiation.

[0067] B: Transaction Encryption & Verification.

[0068] After the control transaction is signed, it needs to be encrypted using the NTRU lattice cryptographic algorithm and then broadcast to all EFB full nodes. After receiving the encrypted transaction, the EFB nodes need to decrypt it and perform three-layer verification before placing the control transaction into the consensus queue.

[0069] B1. Decryption operation: Use the NTRU private key to decrypt the ciphertext of the transaction and restore the original transaction data.

[0070] B2. Signature Verification: Verify the validity of Sig_owner using the owner's Dilithium public key to confirm the legitimacy of the command source.

[0071] B3. Format and Expiration Check: Verify the legality of the Command format and confirm that Texpire has not expired.

[0072] B4. Permission Check: Query the instruction management contract to verify whether the control instruction sender has the right to issue such instructions to the target EFB.

[0073] This step uses a hybrid design of "NTRU encryption + Dilithium signature" to build a security barrier from the aspects of transmission confidentiality and identity legitimacy, preventing illegal commands, forged commands and eavesdropping attacks.

[0074] Step 2: Convert business urgency into consensus priority, sort consensus based on priority, and prioritize the processing of urgent control instructions.

[0075] C: Priority-based consensus ordering.

[0076] Traditional sorting methods only prioritize transactions by receipt time, which can easily lead to inconsistencies in the global order due to network latency. This system transforms business urgency into consensus priority, ensuring that urgent control commands are processed first.

[0077] After a transaction enters the node's local memory pool, its priority is calculated using the following formula: , =0.6、 =0.4 is the normalized weighting coefficient, determined through sensitivity analysis. Enlarging can improve timeliness and meet the requirements. .

[0078] Indicates the current time. This indicates the maximum timeout for executing control commands, which is set according to the mirror field control requirements. Indicates the control command level, with a value range of 1 to 10, determined by the command type. Protective commands such as emergency stop and wind protection are assigned a higher execution level.

[0079] Step 3: Based on the DW-PBFT consensus mechanism, a deterministic leader election is adopted. The consensus efficiency and fault tolerance are optimized through a quantitative weight calculation model. The consensus process is initiated. After consensus is reached, the orderly control transaction list is submitted to the task scheduling contract for execution. The contract execution is atomic. The control logic is solidified into code to ensure the transparency and consistency of the control strategy.

[0080] D: Initiate consensus and confirm.

[0081] Based on the DW-PBFT consensus mechanism, a deterministic leader election is adopted, with the EFB node with the highest weight becoming the Leader and initiating the consensus process.

[0082] The traditional PBFT consensus mechanism assumes that all nodes are equal and requires... Only a few nodes can tolerate this. There are malicious nodes, and the communication complexity is... To address the heterogeneous performance of EFB nodes in the mirror field control system, this embodiment proposes a dynamic weight-based PBFT improvement mechanism (DW-PBFT), which optimizes consensus efficiency and fault tolerance through a quantized weight calculation model.

[0083] In the weight calculation model, each EFB node calculates a dynamic weight in each consensus cycle. The weights are determined by a comprehensive evaluation of four dimensions: historical reputation, performance, resource stability, and online duration. The quantification formula is as follows: ,in: , , , The normalized weighting coefficients satisfy... .

[0084] Let be the historical reputation value of node j, ranging from [0,1], with an initial value of 1.0, calculated as follows: , This refers to the number of times node j has not engaged in malicious behavior in the past 24 hours, such as correct voting or no data tampering. This represents the total number of actions taken in the past 24 hours.

[0085] Let j be the performance metric for node j, with a value range of (0,1], and the quantization formula is: , The maximum allowable timeout period, To mitigate the impact of "pseudo-high performance" attacks, given the node j's response time of approximately 5 minutes. The median is used instead of the mean.

[0086] The resource stability of node j is calculated based on CPU utilization and memory utilization, with a value range of (0,1]. , The average CPU utilization percentage of the server deployed on node j over the past 5 minutes. The average memory utilization of the server deployed on node j over the past 5 minutes.

[0087] Let be the percentage of time node j is online over 24 hours, with a value range of [0,1] and an initial value of 1.0. The calculation is as follows: .

[0088] Through grid search and sensitivity analysis, the default configuration was determined to be ( This configuration achieved the lowest consensus latency and a high tolerance for malicious nodes in the simulation.

[0089] DW-PBFT improves system security and consistency latency through integration and dynamic configuration of weight coefficients, enabling precise adaptation to mirror field control scenarios.

[0090] DW-PBFT inherits the four-phase protocol of PBFT (Pre-prepare, Prepare, Commit, Reply), with the core modification being the leader election and voting verification mechanism, which includes the following steps.

[0091] D1: The leader node sorts the verified control transactions according to priority and generates an ordered list of control transactions as a proposal. The proposal contains the leader node's Dilithium signature.

[0092] D2: The leader node broadcasts the proposal to other EFB consensus nodes. After receiving the proposal, the consensus nodes verify the correctness of the order and control the executableness of the transaction.

[0093] D3: If the verification is successful, the consensus node returns a Prepare message (including its own weight, valid identifier, and signature); when the sum of the weights of the valid Prepare messages collected by the leader node exceeds 2 / 3 (approximately 66.7%) of the total weight, it enters the Commit phase.

[0094] D4: The leader node broadcasts a Commit message, and the consensus nodes verify it and return a Commit confirmation; consensus is reached when the sum of the weights of the collected valid Commit messages exceeds 2 / 3 of the total weight.

[0095] This process ensures that all nodes achieve global consistency on the order of instruction execution.

[0096] E: Smart contract execution and atomic state update (Execute).

[0097] Once a consensus is reached, the orderly control transaction list is submitted to the task scheduling contract for execution, and the contract execution is atomic.

[0098] E1: The contract calculates the specific control instructions for each subfield based on the instruction content and the current system state.

[0099] E2: Contract status and execution results are synchronously updated to the blockchain state database.

[0100] E3: If the execution result is abnormal, the contract will automatically roll back to the state before execution to avoid inconsistencies in the system state.

[0101] This step solidifies the control logic into code, ensuring the transparency and consistency of the control strategy.

[0102] Step 4: After the contract is executed, the generated sub-field-level commands are issued through the instruction routing mechanism, seamlessly connecting the blockchain's global decision-making with EFB's local execution. After the heliostat executes the command, it sends the status receipt to EFB. EFB packages the command execution result, signs it with the Dilithium private key, generates an audit transaction, and uploads it to the audit chain for evidence storage.

[0103] F: Instruction dispatch and execution (Dispatch).

[0104] After the smart contract completes execution, the generated sub-farm level commands are issued via an instruction routing mechanism. Upon receiving the event, the corresponding EFB node performs the following operations.

[0105] F1: Re-verify the legality and timeliness of the command.

[0106] F2: The local control contract receives commands, drives the internal hybrid automaton to perform state transitions and continuous calculations, and generates heliostat drive signals.

[0107] F3: Send the drive signal to the heliostat for execution.

[0108] This step enables seamless integration between blockchain-based global decision-making and EFB local execution.

[0109] G: After the heliostat executes the command, it sends a status receipt to the EFB; the EFB packages the command execution result, signs it with the Dilithium private key, generates an audit transaction, and uploads it to the audit chain for evidence storage.

[0110] NTRU is used for transaction encryption in the control chain command transmission, ensuring the confidentiality of real-time command transmission and adapting to low-latency requirements. Dilithium is used for digital signatures in control command signing and audit chain data signing, achieving identity authentication, non-repudiation, and resistance to quantum attacks. In the control chain, NTRU and Dilithium form a complementary security architecture in the blockchain-control system coupling mechanism. The selection of Dilithium ensures security against MLWE problems while possessing a shorter signature length and the fastest verification speed, perfectly meeting the high-frequency, real-time authentication requirements of control commands. Through the hybrid design of "NTRU-Dilithium signature," the deep coupling of the two enables the system to form a full-link quantum-resistant security protection of "transmission encryption - identity authentication - storage tamper-proof."

[0111] The audit chain, serving as a trusted storage medium for historical system data, is responsible for storing critical information such as control command execution records, device status change data, and node operation logs. Its main functions include:

[0112] Data tiered storage: Compressed data state snapshots are stored locally on the EFB node, and the data hash and storage address are recorded through the blockchain to achieve an efficient architecture of "on-chain index - off-chain storage".

[0113] Data lifecycle management: Data is stored in a hierarchical manner according to its importance. Control command execution records (high importance) are retained for ≥3 years, device status data (medium importance) are retained for ≥1 year, operation logs (low importance) are retained for ≥6 months, and expired data is archived to a CD.

[0114] Data access control: A blockchain-based permission management mechanism that allows only authorized nodes (such as operation and maintenance nodes and audit nodes) to access data. Access records are written to the audit chain to achieve data traceability and non-repudiation.

[0115] V. Contract Layer.

[0116] As the core of the system's intelligent decision-making, its functions are distributed across the blockchain network and EFB nodes, forming a layered smart contract execution architecture.

[0117] 1. Blockchain-level Smart Contracts (Strategic Layer): The strategic layer is the central hub for the system's global decision-making and management. Deployed on full nodes of the blockchain, it executes unified strategies across sub-fields based on distributed consensus. All decision-making processes and results are recorded on the blockchain to ensure global consistency and auditability. Different functional contracts are deployed independently, and individual contract modules can be upgraded or added without reconstructing the overall system architecture.

[0118] Blockchain-level smart contracts include: Device Status Monitoring Contract: Defines global status monitoring rules and thresholds for the mirror field devices. When device status data exceeds the preset range, a contract event is triggered, generating an alarm event and recording it to the audit chain.

[0119] Task scheduling contract: Calculates subfield instruction allocation strategy based on field instructions and generates subfield-level control instructions; Smart protection contract: Defines global protection strategies (automatic wind protection, intelligent defocusing, intelligent predictive protection, etc.), which are automatically executed when environmental or equipment data triggers a threshold. Energy scheduling contract: Based on the energy required for the operation of the heliostat, schedule the heliostat to perform sun-tracking.

[0120] Node management contract: responsible for EFB node registration, status monitoring, primary / standby switching, key management, etc. Smart calibration contract: Based on environmental data, operational data, and calibration records, it identifies heliostats that need calibration and initiates calibration tasks.

[0121] 2. EFB-level Smart Contracts (Tactical Layer): The tactical layer is the execution strategy of the system's local real-time control execution unit, embedded in a single EFB node. It is responsible for converting subfield-level instructions issued by the strategic layer into executable signals for a single heliostat, undertaking local computation and control tasks with extremely high real-time requirements. This significantly reduces the storage and communication pressure on the blockchain network and improves the overall system operating efficiency.

[0122] EFB-level smart contracts include: Local control contract: Receives sub-field level commands issued by the blockchain, decomposes them into heliostat control commands, maintains the state of the local hybrid automaton and performs continuous dynamic equation calculations; State transition contract: Automatically executes state switching and resetting mapping according to control commands, without waiting for blockchain confirmation, ensuring real-time performance; Data preprocessing contract: cleans, aggregates, and compresses the raw data reported by the subfield heliostats, reducing the amount of data uploaded to the chain and network load; Redundancy failover contract: Enables heartbeat detection and status synchronization between primary and backup EFBs, monitors the health status of the primary node, and automatically initiates a takeover process and registers a new primary node identity with the blockchain in case of failure.

[0123] The sun-tracking table calculation contract: Before sunrise, the sun-tracking table for one day is calculated for the heliostat and sent to the heliostat. In continuous sun-tracking mode, the heliostat moves smoothly after interpolation based on the time and step number of the sun-tracking table.

[0124] VI. Application Management Level.

[0125] It provides users with an intuitive and convenient operating interface, covering human-computer interaction functions such as field management, monitoring, operation and maintenance, equipment monitoring, alarm monitoring, intelligent prediction, and data query.

[0126] By deeply coupling control theory and blockchain technology, the contradiction between the limited computing power of heliostats and the functional requirements of full-node blockchains is resolved. The EFB is established as the sub-field proxy full node, and a master-slave redundancy mechanism is designed, ensuring the reliability of the control link while achieving efficient distributed consensus and smart contract execution. The proposed DW-PBFT consensus mechanism, through a dynamic weight model, improves fault tolerance while reducing consensus latency. The NTRU-SPHINCS+ hybrid quantum-resistant cryptographic architecture provides future-proof security for the system.

[0127] Example 2 Based on Example 1, this example uses a 100 MW solar thermal (energy storage) project to build a simulation platform, simulating a mirror field containing 300,000 heliostats, divided into 9 subfields (each subfield deploying one main and one backup EFB). The simulation lasts 100 hours, analyzing the experimental simulation and performance. The mirror field layout is as follows. Figure 3 As shown.

[0128] I. Simulation Configuration.

[0129] 1. Lens field configuration, as shown in Table 4.

[0130] Table 4: Details of Heliostat Configurations .

[0131] 2. Server cluster configuration.

[0132] Simulation server cluster configuration: The experiment deployed 23 servers, including 18 primary and backup EFB nodes, 2 contract and audit servers, 2 primary and backup database servers, and 2 monitoring servers, as shown in Table 5.

[0133] Table 5: Server Cluster Configuration Table .

[0134] II. Consensus Performance Testing.

[0135] 1. Malicious node fault tolerance ratio.

[0136] Comparing the consensus success rates of DW-PBFT and classic PBFT (9 EFB nodes), the fault tolerance condition of classic PBFT is n≥3f+1 (when n=9, f=2, fault tolerance rate 22.2%). In the simulation, a malicious node was randomly selected. It was assumed that the malicious node's workload increased significantly (simulated response time increased to 400ms, CPU and memory utilization exceeded 85%). Its performance metric weight (P), historical reputation value weight (R), and resource stability weight (S) were dynamically reduced, and it submitted invalid votes in the consensus process. The results are as follows... Figure 4 As shown.

[0137] Simulation results show that DW-PBFT achieves a consensus rate of 65% even when the proportion of malicious nodes reaches 44.4% (4 malicious nodes), significantly outperforming the classic PBFT (whose consensus rate drops to 0% after the proportion of malicious nodes exceeds 22.2%). This result verifies the effectiveness of DW-PBFT in suppressing the influence of malicious nodes and increasing the system's fault tolerance through dynamic weight allocation.

[0138] 2. Consensus delay time for different weights The mirror field size was gradually increased (from 2 subfields to 9 subfields), and the consensus time was recorded for each test, with the average value taken over 100 tests. Four different weighting coefficient configurations were tested to analyze parameter sensitivity, and the results are as follows: Figure 5 As shown.

[0139] Simulation results: The consensus latency of all DW-PBFT variants is significantly lower than that of the classic PBFT. With 9 nodes, the consensus latency of the classic PBFT reaches 190ms, while the optimal DW-PBFT configuration (α=0.3, β=0.4, γ=0.2, δ=0.1) is only 98ms, a reduction of 48.4%. Weight configuration has a significant impact on consensus latency: the larger the β (performance weight), the lower the consensus latency, verifying that performance-prioritized weight allocation can improve consensus efficiency. As the number of nodes increases, the consensus latency of all algorithms increases, but the growth rate of DW-PBFT is more gradual (latency increases by 45% as the number of nodes increases from 2 to 9), while the classic PBFT increases by 70%, reflecting the adaptability of dynamic weights to the heterogeneity of EFB nodes.

[0140] 3. Redundancy switching performance test.

[0141] Simulate primary EFB node failure (such as service stoppage or network interruption) to test the system's service interruption time (the time from primary node failure to standby node takeover) under redundant architecture. The fault judgment logic is: if two consecutive heartbeat detections fail (with a time interval of 15ms), a primary-standby switchover is triggered. A total of 100 experiments were conducted, and the results are shown in Figure 6.

[0142] Experimental results: The average switchover time for EFB primary / standby was 70.8 ms, the median was 66.0 ms, the 95th percentile was 112.0 ms, the minimum switchover time was 45 ms, and the maximum switchover time was 126 ms. 95% of switchover events were completed within 112 ms, far less than the minutes required for manual intervention, meeting the real-time requirements of mirror field control (control latency ≤ 500 ms) and verifying the reliability of the redundant architecture.

[0143] 4. System response time test.

[0144] The mirror field consists of 9 sub-mirror fields and 300,000 heliostats. The system response time is defined as the time from the issuance of control commands from the operation interface to the generation of heliostat drive signals by the EFB (excluding heliostat execution delay). A total of 100 experiments were conducted, and the results are shown in Figure 7.

[0145] Simulation results: The average system response time with the optimal weight configuration (α=0.3, β=0.4, γ=0.2, δ=0.1) is 127.4 ms, which meets the real-time control requirements of large-scale mirror fields. The system response time trend is consistent with the consensus delay, indicating that the consensus mechanism is the core factor affecting the system's real-time performance, and DW-PBFT effectively improves the system response speed by optimizing the weight allocation.

[0146] Simulation experiments, based on a 300,000-mirror field, verified the system's real-time performance, security, and robustness, with control latency below 500ms and a malicious node tolerance rate increased to 44.4%. This provides a solid theoretical framework and feasible engineering implementation path for the safe, efficient, and intelligent operation of large-scale concentrated solar power (CSP) systems.

[0147] The above embodiments are merely illustrative of the structural concept and features of the present invention, intended to enable those skilled in the art to understand the content of the present invention and implement it accordingly, and should not be construed as limiting the scope of protection of the present invention. All equivalent changes or modifications made based on the essence of the present invention should be covered within the scope of protection of the present invention.

Claims

1. A tower-type photothermal distributed mirror field hybrid control system based on a blockchain consensus mechanism, characterized in that, include: Physical layer: This includes the underlying hardware carrier, used for on-site data acquisition, physical action execution, and basic operational support, providing a real input source for upper-level control decisions and ultimately implementing all control commands; Data layer: Used for data collection, sharing, synchronization and storage, ensuring data security and reliability and providing distributed file transfer service for historical data. Data collected from the physical layer is integrated, cleaned, configured with permissions and encrypted securely before being shared to the entire system. Network Layer: Constructing distributed blockchain nodes EFB, each sub-field EFB participates in the blockchain network as a full node, used for consensus execution, hybrid automaton maintenance, heliostat data collection, storage sharing and smart contract execution. The heliostat, as a light node, interacts with the chain through the EFB proxy. Consensus Layer: The consensus process takes place between EFB nodes. Dynamic weight calculation and leader election are performed based on the performance indicators of EFB nodes, taking into account both command response speed and mirror operation efficiency. Through a four-dimensional weight model of historical reputation, real-time performance, resource stability, and online duration, fault tolerance and real-time performance are optimized in a coordinated manner. Contract layer: As the core of the system's intelligent decision-making, its functions are distributed across the blockchain network and EFB nodes, forming a layered smart contract execution architecture; Application Management Layer: Provides users with an intuitive and convenient operating interface, covering human-computer interaction functions such as field management, monitoring, operation and maintenance, equipment monitoring, alarm monitoring, intelligent prediction, and data query.

2. The tower-type photothermal distributed mirror field hybrid control system based on blockchain consensus mechanism according to claim 1, characterized in that, In the network layer, each sub-farm deploys two EFB nodes: a primary blockchain distributed node and a backup blockchain distributed node. They form a high-availability cluster through heartbeat detection and state synchronization. When the primary EFB fails, the backup EFB automatically takes over within 100 milliseconds, and updates the smart contract node status to switch the primary and backup identities by broadcasting the identity change through the blockchain.

3. The tower-type photothermal distributed mirror field hybrid control system based on blockchain consensus mechanism according to claim 2, characterized in that, In the network layer, the blockchain network includes a control chain and an audit chain. The control chain is used for real-time control command transmission. Control transactions are encrypted using Dilithium quantum-resistant signatures and NTRU lattice cryptography to prevent tampering and ensure transmission security. The final broadcast of command execution is routed based on the sub-farm ID to reduce network load. The audit chain is used to store historical operation and status data, providing data traceability capabilities. The control chain and the audit chain use an asynchronous event-driven mechanism to synchronize key metadata, ensuring audit integrity without affecting control real-time performance.

4. The tower-type photothermal distributed mirror field hybrid control system based on blockchain consensus mechanism according to claim 3, characterized in that, The steps for the control chain to process instructions include: Step 1: Before the control command is issued, the owner completes the digital signature using the Dilithium quantum-resistant signature algorithm to generate a control transaction. The signed control transaction is then encrypted using the NTRU lattice cryptography algorithm and broadcast to all EFB full nodes. After receiving the encrypted transaction, the EFB nodes complete the decryption and three-layer verification and put the control transaction into the consensus queue. Step 2: Convert business urgency into consensus priority, sort consensus based on priority, and prioritize the processing of urgent control instructions; Step 3: Based on the DW-PBFT consensus mechanism, a deterministic leader election is adopted. The consensus efficiency and fault tolerance are optimized through a quantitative weight calculation model. The consensus process is initiated. After consensus is reached, the orderly control transaction list is submitted to the task scheduling contract for execution. The contract execution is atomic. The control logic is solidified into code to ensure the transparency and consistency of the control strategy. Step 4: After the contract is executed, the generated sub-field-level commands are issued through the instruction routing mechanism, seamlessly connecting the blockchain's global decision-making with EFB's local execution. After the heliostat executes the command, it sends the status receipt to EFB. EFB packages the command execution result, signs it with the Dilithium private key, generates an audit transaction, and uploads it to the audit chain for evidence storage.

5. The tower-type photothermal distributed mirror field hybrid control system based on blockchain consensus mechanism according to claim 4, characterized in that, In step 2, after a control transaction enters the node's local memory pool, the priority calculation formula is as follows: ,in, , This represents the normalized weighting coefficients determined through sensitivity analysis. Indicates the current time. This indicates the maximum timeout period for executing control commands, set according to the requirements of the mirror field control. Indicates the level of control instructions determined by the command type.

6. The tower-type photothermal distributed mirror field hybrid control system based on blockchain consensus mechanism according to claim 4, characterized in that, In step 3, the EFB node with the highest weight is the leader node, and the weight is determined by historical reputation. Performance indicators Resource stability and online time The weights are determined by a combination of four dimensions, and each EFB node calculates its dynamic weight in each consensus cycle. The formula for the quantization weight calculation model is: ,in, , , , These are the normalized weighting coefficients; Step 3 includes: Step 3-1: The leader node sorts the verified control transactions according to priority and generates an ordered list of control transactions as a proposal. The proposal contains the leader node's Dilithium signature. Step 3-2: The leader node broadcasts the proposal to other EFB consensus nodes. After receiving the proposal, the consensus nodes verify the correctness of the order and the executability of the control transaction. Step 3-3: If the verification is successful, the consensus node returns a Prepare message containing its own weight, valid identifier, and signature. When the sum of the weights of the valid Prepare messages collected by the leader node exceeds 2 / 3 of the total weight, it enters the Commit phase. Steps 3-4: The leader node broadcasts a Commit message, and the consensus nodes verify it and return a Commit confirmation. Consensus is reached when the sum of the weights of the collected valid Commit messages exceeds 2 / 3 of the total weight. Steps 3-5: The contract calculates the specific control instructions for each sub-field based on the instruction content and the current system state, and the contract state and execution results are synchronously updated to the blockchain state database; Steps 3-6: If the execution result is abnormal, the contract will automatically roll back to the state before execution to avoid inconsistencies in the system state.

7. The tower-type photothermal distributed mirror field hybrid control system based on blockchain consensus mechanism according to claim 4, characterized in that, In step 4, after the corresponding EFB node listens for the event, it executes the following steps: Step 4-1: Verify the legality and timeliness of the command again; Step 4-2: The local control contract receives commands, drives the internal hybrid automaton to perform state transitions and continuous calculations, and generates heliostat drive signals; Step 4-3: Send the drive signal to the heliostat for execution.

8. The tower-type photothermal distributed mirror field hybrid control system based on blockchain consensus mechanism according to claim 3, characterized in that, The audit chain performs the following functions. Data tiered storage: Compressed data state snapshots are stored locally on the EFB node, and the data hash and storage address are recorded through the blockchain to achieve an efficient architecture of on-chain index and off-chain storage; Data lifecycle management: Data is stored hierarchically according to its importance. Control command execution records are retained for ≥3 years, device status data is retained for ≥1 year, operation logs are retained for ≥6 months, and expired data is archived to a CD-ROM. Data access control: A blockchain-based permission management mechanism that authorizes nodes to access data, and access records are written to the audit chain to achieve data traceability and non-repudiation.

9. The tower-type photothermal distributed mirror field hybrid control system based on blockchain consensus mechanism according to claim 1, characterized in that, The contract layer includes blockchain-level smart contracts and EFB-level smart contracts. The blockchain-level smart contract is the global decision-making and management hub of the system. It is deployed on the full nodes of the blockchain and executes a unified strategy across sub-fields based on distributed consensus. All decision-making processes and results are stored on the blockchain to ensure global consistency and auditability. The EFB-level smart contract is the execution strategy of the system's local real-time control execution unit. It is embedded in a single EFB node and is responsible for converting the sub-field-level instructions issued by the blockchain-level smart contract into executable signals for a single heliostat, undertaking local computing and control tasks with extremely high real-time requirements.

10. The tower-type photothermal distributed mirror field hybrid control system based on blockchain consensus mechanism according to claim 9, characterized in that, The different functional contracts of the blockchain-level smart contracts are deployed independently, and contract modules can be upgraded or added individually, including: Define the device status monitoring contract that sets global status monitoring rules and thresholds for the mirror field equipment; Calculate the subfield instruction allocation strategy based on the mirror field instructions, and generate a task scheduling contract for subfield-level control instructions; Define a global protection policy, a smart protection contract that is automatically executed when environmental or device data triggers a threshold; Based on the energy required for the operation of the heliostat field, an energy scheduling contract is made to schedule the heliostat to track the sun and follow the sun. A node management contract responsible for EFB node registration, status monitoring, master / slave failover, and key management; Based on environmental data, operational data, and calibration records, identify smart calibration contracts that require heliostat calibration and initiate calibration tasks. The EFB-level smart contracts reduce the storage and communication pressure on the blockchain network, including: Receive sub-field level commands issued by the blockchain, decompose them into heliostat control commands, maintain the local hybrid automaton state, and execute local control contracts that perform continuous dynamic equation calculations. The state transition contract is automatically executed according to control commands and the state switching and resetting mapping is completed without waiting for blockchain confirmation, ensuring real-time state transition contracts. A data preprocessing contract that cleans, aggregates, and compresses the raw data reported by the subfield heliostats to reduce the amount of data uploaded to the chain and network load; It enables heartbeat detection and status synchronization between primary and backup EFBs, monitors the health status of the primary node, and automatically initiates a takeover process and registers a redundant switchover contract with the new primary node identity on the blockchain in case of failure. Before sunrise, the heliostat calculates the daily tracking schedule for one day and sends it to the heliostat's tracking schedule calculation contract. In continuous tracking mode, the heliostat performs interpolation based on the tracking schedule's time and step count, and then moves smoothly.

Images