Energy storage converter batch program production method and system

Abstract

The invention discloses an energy storage converter batch program production method and system. The method comprises the steps of obtaining a user configuration file and a historical project configuration template; generating target firmware for generating and burning the energy storage converter through the user configuration file and the historical project configuration template; when the configuration is changed, the content of the configuration change is uploaded to different blocks of the block chain network, and each block comprises the hash value of the previous block. According to the main technical scheme and the effects, the program configuration flexibility is remarkably improved, flexible combination of parameters and function modules is achieved by establishing a general core program and configuration file specifications, differential requirements of different projects and regions can be rapidly met, and the production efficiency is improved.

Description

Technical Field

[0001] This invention relates to the field of energy storage converters, and more particularly to a method and system for mass production of energy storage converters. Background Technology

[0002] As energy storage PCS equipment enters the mass production stage, different projects (such as photovoltaic energy storage and grid peak shaving) and different regions have different requirements for the equipment's parameters (such as voltage range and frequency response) and functions (such as islanding detection and harmonic compensation). In terms of equipment programs, a general version of the program is often released. Then, for different projects and regions, engineers customize the program based on this general version to meet their actual needs. This process is the batch program production process.

[0003] Customized processing may require not only customized parameter configurations but also customized functional modules. For example, Chinese patent applications CN112654940B and CN112987605A only solve the problem of automated parameter configuration, but do not support multi-person collaborative configuration or reliable traceability of configuration changes. Summary of the Invention

[0004] Purpose of the invention: The purpose of this invention is to solve the technical problems in the prior art and provide a method and system for mass production of energy storage converters.

[0005] Technical solution:

[0006] Firstly, this application proposes a method for batch production of energy storage converters, comprising:

[0007] Retrieve user configuration files and historical project configuration templates;

[0008] The target firmware for generating and burning the energy storage converter is generated using user configuration files and historical project configuration templates.

[0009] When a configuration change occurs, the changes are uploaded to different blocks in the blockchain network, and each block contains the hash value of the previous block.

[0010] Preferably, the user profile is obtained, including:

[0011] Task to retrieve basic project parameters created by user 1;

[0012] Classify the basic project parameter tasks;

[0013] Multiple users edited the basic project parameters of the category.

[0014] Perform a compliance check on the edited project parameters and tasks, generate a new version number, and generate a configuration file.

[0015] Preferably, the target firmware for generating and burning the energy storage converter is generated using user configuration files and historical project configuration templates, including:

[0016] Establish a general core program, including hardware driver interface, basic control algorithm framework, and status monitoring;

[0017] Generate a JSON-formatted definition file from the user configuration file;

[0018] Create a new project configuration file based on a historical project configuration template, building upon the user configuration file.

[0019] Merge the new project configuration file and the common core program to generate the target firmware;

[0020] The generated target firmware is burned into the energy storage converter device of the core control unit.

[0021] Preferably, the JSON format definition file includes:

[0022] Basic information: Project ID, Region, Rated power;

[0023] Parameter set: voltage threshold, frequency response parameters, protection limits;

[0024] Feature list: Feature modules that need to be enabled.

[0025] Preferably, it also includes uploading the configuration changes to different blocks of the blockchain network when configuration changes occur, with each block containing the hash value of the previous block, including:

[0026] In response to a change request triggered by the configuration management unit, transaction data containing operation type, project ID, user ID, configuration hash, and digital signature is generated.

[0027] The transaction data is sent to the blockchain master node for preliminary verification.

[0028] Once the initial verification is passed, the master node will broadcast the transaction to all nodes in the network;

[0029] Each full node independently repeats the preliminary verification steps;

[0030] The master node collects valid verification signatures from more than 2 / 3 of the full nodes and packages the transaction into a new block;

[0031] The new block is broadcast to all nodes on the network for consensus verification, and then appended to the blockchain after successful verification.

[0032] The configuration management unit receives the on-chain confirmation and updates the configuration version status.

[0033] Preferably, the preliminary verification includes:

[0034] Verify the validity of the digital signature using the user's public key;

[0035] The permission system verifies the user ID's execution permissions for the operation type.

[0036] Verify the integrity of the transaction data format.

[0037] Preferably, the operation types in the transaction data include at least one of the following:

[0038] Configuration creation, parameter modification, and function deletion;

[0039] The permission verification specifically includes:

[0040] Regular users are prohibited from performing the function deletion operation.

[0041] Preferably, the configuration hash is the SHA-256 hash value of the current configuration file, which is used for configuration integrity comparison during verification.

[0042] Preferably, the consensus verification includes:

[0043] Verify the match between the Merkle root of the new block and the transaction data;

[0044] Verify the continuity of the previous block hash in the block header;

[0045] Verify the validity of the timestamp.

[0046] Secondly, the present invention provides a batch production system for energy storage converters, comprising:

[0047] Database server, used to store project configuration files, historical versions, device information, and programs;

[0048] A configuration management server is configured to implement the method described in the above embodiments through the above program;

[0049] The local deployment unit is used by users to test and verify configuration files, new configurations, and programs, as well as monitor the server to collect and manage data from multiple PCS devices;

[0050] Blockchain nodes are used to record all configuration changes and operation history.

[0051] Beneficial effects:

[0052] The program configuration flexibility has been significantly improved. By establishing a general core program and configuration file standard, the parameters and functional modules can be flexibly combined, which can quickly adapt to the differentiated needs of different projects and regions, thereby improving production efficiency.

[0053] It enables efficient team collaboration, supports multiple users to edit, review and publish project configurations simultaneously with the help of a collaborative workflow engine, automatically detects and handles conflicts, significantly reduces communication costs and error rates, and improves team work efficiency.

[0054] To ensure the reliability and traceability of the configuration change process, blockchain technology is used to record the entire configuration change process, making all operations transparent and tamper-proof, effectively improving the reliability of configuration change records and meeting compliance audit requirements and security management requirements. Attached Figure Description

[0055] Figure 1 A schematic diagram of the method flow is provided for this invention;

[0056] Figure 2 A system structure diagram is provided for this invention;

[0057] Figure 3 A schematic diagram of the logic unit structure is provided for this invention;

[0058] Figure 4 This is a schematic diagram of the personnel configuration process for this invention;

[0059] Figure 5 This is a schematic diagram of the program generation process of the present invention;

[0060] Figure 6 The timing diagram for configuring and changing the on-chain function block of this invention. Detailed Implementation

[0061] To make the technical solution of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0062] Example 1

[0063] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions in the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without inventive effort are within the scope of protection of this invention. Unless otherwise defined, the technical or scientific terms used herein should have the ordinary meaning understood by those skilled in the art. The terms "comprising" and similar expressions used herein mean that the element or object preceding the word covers the element or object listed following the word and its equivalents, but do not exclude other elements or objects.

[0064] In response to the problems existing in the current technology, such as Figures 1-6As shown, a method for mass production of energy storage converters includes:

[0065] Retrieve user configuration files and historical project configuration templates;

[0066] The target firmware for generating and burning the energy storage converter is generated using user configuration files and historical project configuration templates.

[0067] When a configuration change occurs, the changes are uploaded to different blocks in the blockchain network, and each block contains the hash value of the previous block.

[0068] In some specific embodiments, combined with Figure 4 Obtain user configuration files, including:

[0069] Task to retrieve basic project parameters created by user 1;

[0070] Classify the basic project parameter tasks;

[0071] Multiple users edited the basic project parameters of the category.

[0072] Perform a compliance check on the edited project parameters and tasks, generate a new version number, and generate a configuration file.

[0073] Specifically, for example, the project manager (User 1) on the PC terminal (i.e. Figure 3 The user interface creates a project and defines basic parameters, and sends this operation to the collaboration management unit, which then assigns the task to multiple engineers based on the project type.

[0074] Multiple engineers (User 2) can simultaneously pull the same configuration from the configuration management unit for editing. The system provides a locking mechanism to prevent key parameters from being modified at the same time, and supports offline editing and change merging.

[0075] When submitting changes, it automatically detects conflicts with the current version and provides three conflict resolution modes: automatic merging (unambiguous changes), intelligent suggestions (based on historical patterns), and manual negotiation (complex conflicts).

[0076] The system automatically verifies the configuration compliance, and generates firmware and a new version number after the review is approved;

[0077] Recording and publishing on the blockchain.

[0078] By modularizing task division and enabling parallel editing by multiple users, this invention addresses the inefficiency of traditional "one-person full configuration" systems, significantly improving configuration progress and making it suitable for batch customization needs of PCS programs. The system automatically coordinates user editing permissions, detects and resolves conflicts, avoiding repetitive work and logical inconsistencies, and reducing communication costs. An automatic review mechanism ensures that generated configurations meet compliance standards, preventing system anomalies caused by human error. All generated configuration files have version numbers, allowing for comparison, rollback, and verification. Combined with blockchain technology, this ensures immutable records and supports security auditing. This invention is applicable to the rapid deployment and customized development of multiple energy storage converters or cross-regional multi-project scenarios, possessing good versatility and engineering application value.

[0079] In some specific embodiments, combined with Figure 4 The target firmware for generating and burning the energy storage converter is generated using user configuration files and historical project configuration templates, including:

[0080] Establish a general core program, including hardware driver interface, basic control algorithm framework, and status monitoring;

[0081] Generate a JSON-formatted definition file from the user configuration file;

[0082] Create new project configuration files based on historical project configuration templates (such as "North American Power Grid Template" and "PV Energy Storage Template"), with visual editing of parameters and function options; version control and difference comparison;

[0083] Merge the new project configuration file and the general core program to generate the target firmware. The execution unit generates a parameter configuration file (.cfg format) based on the configuration file and loads / disables functional modules as needed (the enabled status is marked by the file extension, such as ".disabled").

[0084] The generated target firmware is burned into the energy storage converter device of the core control unit.

[0085] The system first constructs a general core program that is independent of specific project parameters, including:

[0086] Hardware driver interface modules (such as voltage sampling and relay control);

[0087] Control algorithm framework modules (such as power scheduling and MPPT algorithm);

[0088] Status monitoring module (such as equipment status feedback and fault reporting).

[0089] Users input project parameters (such as rated power, voltage threshold, grid connection standard, etc.) through the configuration management interface. The system organizes these parameters into a structured JSON configuration file, which serves as the project configuration specification.

[0090] The system provides multiple historical project templates (such as "North American Power Grid Template" and "Photovoltaic Energy Storage Template"), from which users can choose one as a base and perform visual editing, including:

[0091] Fine-tuning parameters (such as adjusting the overvoltage protection range);

[0092] Enable / disable functional modules (e.g., enable AFCI detection, disable harmonic compensation);

[0093] The system version control supports rollback, difference comparison, and collaborative editing.

[0094] Merge configuration files and core programs to generate target firmware:

[0095] The execution unit reads the configuration file (JSON) and performs the following operations:

[0096] Generate a parameter configuration file (.cfg format);

[0097] Whether to activate or disable specific functional modules depends on the feature configuration (by removing / retaining the ".disabled" file marker).

[0098] Merge the general core program with the project configuration data to generate the final target firmware.

[0099] Burn the target firmware to the energy storage converter:

[0100] The generated firmware is burned into the core control unit via secure interfaces (such as CAN, UART, and JTAG), enabling the energy storage converter to run the new firmware. Through template-based and configurable methods, redundant development is avoided; only configuration adjustments are needed to adapt to different project requirements, shortening the development cycle. Complex control logic is encapsulated in the core program, requiring only parameter and module switching configurations, significantly simplifying maintenance. Using a unified core program reduces errors introduced by human intervention, improving version consistency and testability. By inheriting historical templates and editing to generate new configuration files, it supports rapid replication and deployment across different projects, adapting to the market's rapid delivery demands. Each configuration and firmware generation retains version records and difference comparisons, enabling issue rollback and audit trails, and achieving full traceability through blockchain mechanisms.

[0101] In some specific embodiments, the JSON format definition file includes:

[0102] Basic information: Project ID, Region, Rated power;

[0103] Parameter set: voltage threshold, frequency response parameters, protection limits;

[0104] Feature list: Feature modules that need to be enabled.

[0105] Specifically, basic information fields

[0106] Used to identify the basic attributes of a project, mainly including:

[0107] Project ID (project_id): Used to uniquely identify each project, for example: "ABC-2025";

[0108] Region: Identifies the geographical area where the project is deployed, such as "North America" ​​or "Europe";

[0109] Rated power: The maximum output power of the equipment as designed, such as "250kW".

[0110] Parameter collection fields

[0111] Used to define specific control and protection parameters, including but not limited to:

[0112] Voltage thresholds: such as minimum voltage 380V, maximum voltage 450V;

[0113] Frequency response parameter (frequency_response): for example, frequency droop factor of 5%;

[0114] Protection limits include over-temperature protection points, current limits, and short-circuit operation delay time.

[0115] Function list fields

[0116] Used to define the functional modules that need to be enabled, indicating whether they are enabled or not via a boolean value or option.

[0117] JSON has a simple and clear structure, is language-independent, and easy to parse, making it suitable for programmatic reading and management. It integrates basic information, control parameters, and functional modules to ensure precise and controlled device behavior. With the front-end interface, it enables visual operation, and the back-end automatically verifies the format and numerical range to reduce the risk of misoperation. Each project configuration file can be saved as an independent version for easy rollback, comparison, and auditing. With the help of templates and standard configuration structures, multiple JSON files can be generated in batches, and combined with a general program framework, it enables rapid delivery of large-scale projects.

[0118] In some specific embodiments, the method further includes uploading the configuration changes to different blocks of the blockchain network when a configuration change occurs, with each block containing the hash value of the previous block, including:

[0119] In response to a change request triggered by the configuration management unit, transaction data containing operation type, project ID, user ID, configuration hash, and digital signature is generated.

[0120] The transaction data is sent to the blockchain master node for preliminary verification.

[0121] Once the initial verification is passed, the master node will broadcast the transaction to all nodes in the network;

[0122] Each full node independently repeats the preliminary verification steps;

[0123] The master node collects valid verification signatures from more than 2 / 3 of the full nodes and packages the transaction into a new block;

[0124] The new block is broadcast to all nodes on the network for consensus verification, and then appended to the blockchain after successful verification.

[0125] The configuration management unit receives the on-chain confirmation and updates the configuration version status.

[0126] Specifically, in combination Figure 6 :

[0127] Step 1: The configuration management unit submits a change request to the blockchain (Configuration Management Unit → Blockchain Node 1);

[0128] Once the configuration management unit completes configuration editing and passes internal validation (e.g., parameter compliance, no functional conflicts), the system automatically initiates an on-chain request. This request is packaged into a transaction data set, containing the following key fields:

[0129] Operation types: such as configuration creation, parameter modification, function deletion, etc.;

[0130] Project ID: such as "ABC-2025", used to uniquely identify the target project;

[0131] User ID: such as "Engineer-A", indicates the identity of the person performing the operation;

[0132] Configuration hash: A digest of the configuration file calculated using the SHA-256 algorithm;

[0133] Digital signature: A signature generated by a user's private key to ensure that transactions are non-repudiable.

[0134] Transaction data is sent to the master node (node ​​1) via an encrypted transmission protocol (such as HTTPS).

[0135] Step 2: The master node performs preliminary verification (node ​​1);

[0136] After receiving the transaction data, the master node performs the following verification:

[0137] Signature verification: Verifies the legitimacy of the signature using the user's public key to prevent forgery;

[0138] Permission verification: The collaborative management system checks user operation permissions (e.g., ordinary users should not be allowed to perform deletion operations).

[0139] Format validation: Check whether the transaction data conforms to the predefined JSON structure (fields are complete and parameter types are correct).

[0140] Step 3: Broadcast the transaction to all nodes in the network (Node 1 → Node 2, Node 3);

[0141] After initial verification, the master node broadcasts the transaction to other blockchain nodes, and the consensus process begins across the network.

[0142] Step 4: Repeat the verification at each node (node ​​2, node 3).

[0143] Each node independently performs the same verification operations (signature, permissions, format) as the master node, ensuring that the system has "multi-party verification" capabilities and improving the security and trustworthiness of the blockchain.

[0144] In a consortium blockchain architecture, at least two-thirds of the nodes must confirm the validity before proceeding to the next step.

[0145] Step 5: The master node collects signatures and creates a new block (node ​​1);

[0146] When the number of nodes that pass verification meets the consensus requirement (e.g., using the PBFT algorithm), the master node packages the transaction data into a new block. The block header information includes:

[0147] Previous block hash: ensures the continuity of the chain structure and prevents tampering;

[0148] Timestamp: Records the precise time the data was uploaded to the blockchain;

[0149] Merkle root hash: The sum of all transaction hashes within this block.

[0150] The legitimacy of a new block can be confirmed using a **Proof-of-Work (PoW) or Proof-of-Stake (PoS)** algorithm.

[0151] Step 6: Broadcasting the new block and confirming it across the entire network (Node 1 → Node 2, Node 3);

[0152] After the master node completes the construction of the new block, it broadcasts it to other nodes. All nodes in the network then verify the block structure and content again (such as whether the Merkle root matches and whether the timestamp is valid), and append the new block to their local blockchain replicas.

[0153] Step 7: The configuration management unit receives the confirmation and updates the status;

[0154] Once a new block is added to the blockchain, the master node sends a "transaction confirmation" result to the configuration management unit. The system automatically updates the current project configuration status to "on-chain" and notifies relevant users (such as engineers and auditors) to ensure that all subsequent operations are performed based on the confirmed configuration version.

[0155] Data is non-repudiable; all changes are confirmed through digital signatures and cannot be altered once recorded on the blockchain. A distributed trust mechanism with multiple nodes jointly verifying data prevents single-point malicious activity. The entire process is traceable, with each configuration version precisely bound to the transaction time, user, and content. It is highly secure and compliant, separating configuration changes from blockchain actions and employing a rigorous verification process, making it compatible with highly reliable energy storage systems.

[0156] In some specific embodiments, the preliminary verification includes:

[0157] Verify the validity of the digital signature using the user's public key;

[0158] The permission system verifies the user ID's execution permissions for the operation type.

[0159] Verify the integrity of the transaction data format.

[0160] In some specific embodiments, the operation types in the transaction data include at least one of the following:

[0161] Configuration creation, parameter modification, and function deletion;

[0162] The permission verification specifically includes:

[0163] Regular users are prohibited from performing the function deletion operation.

[0164] Specifically, the operation type in the transaction data may include at least one of the following:

[0165] Configuration creation: Used to generate a complete configuration for a project for the first time;

[0166] Parameter modification: Used to adjust parameter items in existing configuration files, such as changing the settings for voltage, current, frequency, etc.

[0167] Function Deletion: Used to disable a specific function module in the target firmware, such as disabling island detection or harmonic compensation.

[0168] Implementation of the permission verification mechanism

[0169] To prevent unauthorized operations from interfering with the system or posing security risks, the system introduces a permission verification mechanism during the transaction verification phase. In some embodiments, permission verification specifically includes the following rules:

[0170] Regular users are prohibited from performing the function deletion operation:

[0171] Only users with advanced privileges (such as auditors or administrators) can perform configuration modification operations involving feature deletion. If a regular user attempts to submit such an operation, the system will directly determine it as an invalid transaction and refuse to upload it to the blockchain during the initial verification stage on the master node.

[0172] In some specific embodiments, the configuration hash is the SHA-256 hash value of the current configuration file, which is used for configuration integrity comparison during verification.

[0173] Specifically, the configuration hash is the digest value generated after processing the current configuration file using the SHA-256 hash algorithm. This hash value has characteristics such as uniqueness, fixed length, and irreversibility.

[0174] In some specific embodiments, the consensus verification includes:

[0175] Verify the match between the Merkle root of the new block and the transaction data;

[0176] Verify the continuity of the previous block hash in the block header;

[0177] Verify the validity of the timestamp.

[0178] Specifically, in one embodiment of the present invention, the consensus verification process is independently executed by each node in the consortium blockchain network after the new block is broadcast, aiming to ensure the integrity, continuity, and time validity of the new block content. This verification process includes, but is not limited to, the following three aspects:

[0179] Merkle root verification:

[0180] The Merkle root hash value contained in the new block is verified to be consistent with the hash value calculated from the actual transaction data, ensuring that the transaction set has not been tampered with after the new block is constructed. If any transaction data changes, the Merkle root will be inconsistent, and the node will reject the block.

[0181] Previous block hash continuity verification:

[0182] The hash of the previous block is compared with the hash of the latest block on the local blockchain to ensure that the new block is added on the existing chain, prevent "fork attacks" or rollback operations, and ensure the continuity and immutability of the chain structure.

[0183] Timestamp validity confirmed:

[0184] Verify whether the timestamp recorded in the new block matches the expected logic, that is:

[0185] The timestamp should be later than the previous block;

[0186] The time must not exceed the current system time (e.g., must not exceed 10 minutes).

[0187] It must not be earlier than the time of the previous transaction.

[0188] In some embodiments, a batch production system for energy storage converters is also provided, comprising:

[0189] Database server, used to store project configuration files, historical versions, device information, and programs;

[0190] A configuration management server is configured to implement the method described in claims 1-9 through the above-described program;

[0191] The local deployment unit is used by users to test and verify configuration files, new configurations, and programs, as well as monitor the server to collect and manage data from multiple PCS devices;

[0192] Blockchain nodes are used to record all configuration changes and operation history.

[0193] Specifically, in combination Figure 2 :

[0194] I. Cloud Management Unit

[0195] The cloud management unit includes a configuration management server, blockchain nodes, and a database server. Among them:

[0196] The configuration management server is responsible for creating, editing, and generating project configuration files and programs, enabling dynamic configuration of parameters and functional modules.

[0197] Blockchain nodes are used to maintain the consortium blockchain network, record all configuration changes and operation history, and ensure that the data is immutable.

[0198] The database server stores project configuration files, historical versions, and related device information, facilitating data retrieval and management.

[0199] II. Local Deployment Unit

[0200] The local deployment unit includes engineer workstations, development and testing equipment, and a production environment. Among these:

[0201] An engineer's workstation is a computer used by developers to access the configuration management server and edit and submit configuration files through a dedicated client or web interface.

[0202] Develop testing equipment to test and verify new configurations and programs, ensuring that the generated programs meet the expected requirements.

[0203] The production environment includes energy storage converters and monitoring servers. The monitoring server is responsible for collecting and managing data from the energy storage converters, providing real-time monitoring and remote management functions.

[0204] III. Remote Access Unit

[0205] The remote access unit includes mobile terminals and an operations and maintenance center. Among them:

[0206] Mobile terminals provide maintenance personnel with a secure channel to access the system for on-site configuration and troubleshooting, ensuring flexibility in on-site operations.

[0207] As the core node for centralized monitoring and management of all distributed energy storage converters, the operation and maintenance center provides equipment management and maintenance services from a global perspective, ensuring stable system operation.

[0208] In addition, at the logical layer, combined with Figure 3 :

[0209] The logic layer adopts a five-unit architecture, with each module working collaboratively through standardized interfaces to achieve end-to-end management from configuration definition to program generation. Specifically, this includes:

[0210] (1) Core control unit

[0211] Deployed in the production environment of the local deployment unit, it connects to hardware devices, provides drive interfaces (such as inverter control and battery communication), and runs general control algorithms (such as power regulation and grid synchronization), dynamically adjusting parameters through configuration files.

[0212] (2) Configuration Management Unit

[0213] The configuration management server deployed in the cloud unit includes:

[0214] Template library: Stores historical project configuration templates (such as "North American Power Grid Template" and "Photovoltaic Energy Storage Template").

[0215] Configuration editor: Supports graphical parameter adjustment (such as voltage threshold, protection delay) and function selection (such as islanding detection);

[0216] Version controller: Records configuration file versions and supports rollback and difference comparison;

[0217] Collaborative workflow engine: Defines editing, reviewing, and publishing processes, and tracks task status.

[0218] (3) Construct execution unit

[0219] The configuration management server deployed in the cloud unit includes:

[0220] Template copying: Copy the core program and functional framework from a base template;

[0221] Parameter generation: Write the configuration parameters to a file (such as parameters.cfg) and replace the placeholders;

[0222] Function filtering: Activate function modules based on configuration (e.g., remove the .disabled suffix to enable the corresponding function).

[0223] (4) Collaborative Management Unit

[0224] The configuration management server deployed in the cloud unit includes:

[0225] User permission management: Role-based permission allocation (e.g., engineers can only edit, while reviewers can publish);

[0226] Task allocation: Break down and assign project tasks (such as parameter configuration and function debugging);

[0227] Conflict detection: Identifies parameter conflicts (such as different settings for the same threshold) or mutually exclusive functions;

[0228] Change notification: Real-time push notifications of task status (e.g., "Review request has been sent").

[0229] (5) Blockchain Unit

[0230] A blockchain node deployed in a cloud-based unit includes:

[0231] Consortium blockchain network: Records configuration change operations (such as creation, modification, and approval);

[0232] Smart contracts: automatically execute rules (e.g., prohibiting changes from being uploaded to the blockchain without approval);

[0233] Encrypted storage: Sensitive data is encrypted, including user signatures and configuration hashes, to ensure privacy and security.

[0234] (6) User interface

[0235] Deployed in the remote access unit, it serves as the main entry point for the user's operating system and can be accessed via computer or mobile terminal.

[0236] The key interaction logic of the above six units is as follows: First, the user operates the configuration management unit through the user interface, and the generated configuration file drives the core control unit and the build execution unit—configuration flow; then, configuration changes trigger conflict detection through the collaboration management unit, and the finally confirmed operation is recorded in the blockchain unit—collaboration record; finally, the core control unit loads the generated firmware and controls the operation of the energy storage device through the hardware driver interface—hardware interaction.

[0237] The logic layer automates the entire process from "configuration definition → collaborative verification → program generation → hardware execution," supporting efficient collaboration among multiple teams and rapid deployment of cross-regional projects.

[0238] The above description is merely a specific implementation of the embodiments of the present invention, but the protection scope of the embodiments of the present invention is not limited thereto. Any changes or substitutions within the technical scope disclosed in the embodiments of the present invention should be covered within the protection scope of the embodiments of the present invention. Therefore, the protection scope of the embodiments of the present invention should be determined by the protection scope of the claims.

Claims

1. A method for mass production of energy storage converters, characterized in that, include: Retrieve user configuration files and historical project configuration templates; The target firmware for generating and burning the energy storage converter is generated using user configuration files and historical project configuration templates. Specifically, when a configuration change occurs, the changed configuration is uploaded to different blocks in the blockchain network, and each block contains the hash value of the previous block.

2. The system according to claim 1, characterized in that, Retrieve user profiles, including: Task to retrieve basic project parameters created by user 1; Classify the basic project parameter tasks; Multiple users edited the basic project parameters of the category. Perform a compliance check on the edited project parameters and tasks, generate a new version number, and generate a configuration file.

3. The system according to claim 1, characterized in that, The target firmware for generating and burning the energy storage converter is generated using user configuration files and historical project configuration templates, including: Establish a general core program, including hardware driver interface, basic control algorithm framework, and status monitoring; Generate a JSON-formatted definition file from the user configuration file; Create a new project configuration file based on a historical project configuration template, building upon the user configuration file. Merge the new project configuration file and the common core program to generate the target firmware; The generated target firmware is burned into the energy storage converter device of the core control unit.

4. The system according to claim 3, characterized in that, The JSON format definition file includes: Basic information: Project ID, Region, Rated power; Parameter set: voltage threshold, frequency response parameters, protection limits; Feature list: Feature modules that need to be enabled.

5. The system according to claim 3, characterized in that, This also includes uploading the configuration changes to different blocks of the blockchain network when configuration changes occur, with each block containing the hash value of the previous block, including: In response to a change request triggered by the configuration management unit, transaction data containing operation type, project ID, user ID, configuration hash, and digital signature is generated. The transaction data is sent to the blockchain master node for preliminary verification. Once the initial verification is passed, the master node will broadcast the transaction to all nodes in the network; Each full node independently repeats the preliminary verification steps; The master node collects valid verification signatures from more than 2 / 3 of the full nodes and packages the transaction into a new block; The new block is broadcast to all nodes on the network for consensus verification, and then appended to the blockchain after successful verification. The configuration management unit receives the on-chain confirmation and updates the configuration version status.

6. The system according to claim 5, characterized in that, The preliminary verification includes: Verify the validity of the digital signature using the user's public key; The permission system verifies the user ID's execution permissions for the operation type. Verify the integrity of the transaction data format.

7. The system according to claim 5, characterized in that, The operation types in the transaction data include at least one of the following: Configuration creation, parameter modification, and function deletion; The permission verification specifically includes: Regular users are prohibited from performing the function deletion operation.

8. The method according to claim 5, characterized in that, The configuration hash is the SHA-256 hash value of the current configuration file, which is used for configuration integrity comparison during verification.

9. The method according to claim 5, characterized in that, The consensus verification includes: Verify the match between the Merkle root of the new block and the transaction data; Verify the continuity of the previous block hash in the block header; Verify the validity of the timestamp.

10. A batch production system for energy storage converters, characterized in that, include: Database server, used to store project configuration files, historical versions, device information, and programs; A configuration management server is configured to implement the method described in claims 1-9 through the above-described program; The local deployment unit is used by users to test and verify configuration files, new configurations, and programs, as well as monitor the server to collect and manage data from multiple energy storage converters; Blockchain nodes are used to record all configuration changes and operation history.

Images