Data updating method and system for multi-chip multi-stage architecture of inverter

Abstract

The application discloses a kind of data updating method and system of multi-chip multilevel architecture of inverter, and the application relates to the technical field of data updating method, based on the current data version of the sub-chip control node and corresponding data combination determines the sub-chip control node;According to the working process of inverter, corresponding lithium battery data to be updated and the current data version of each sub-chip control node determines the data updating system of each sub-chip control node, improves the accuracy of data updating system.Therefore, based on the data updating progress of each sub-chip control node and the multiple working data of inverter determines the autonomous update event of multi-chip multilevel architecture, according to the detection of autonomous update event determines abnormal update content, based on the abnormal update content, the data updating progress of each sub-chip control node and the current working state of inverter determines the dynamic maintenance event of multi-chip multilevel architecture, improves the accuracy of dynamic maintenance event.

Description

Technical Field

[0001] This invention relates to the technical field of data update methods, and more particularly to a data update method and system for a multi-chip, multi-level architecture inverter. Background Technology

[0002] With the development of technology, the multi-chip, multi-level architecture of inverters is a system design scheme that divides the complex inverter control system into multiple layers according to function, with different types of chips working together. Modern inverters, especially high-power inverters such as those for photovoltaics or automobiles, have very complex control systems. They typically do not rely on a single chip to perform all tasks, but rather employ a "master control chip + multiple slave control chips" architecture. In existing technologies, data acquisition based on the multi-chip, multi-level architecture and determination of the corresponding data version based on its detection is insufficient for updating data at each sub-chip management node, affecting the accuracy of the data update system for each sub-chip management node. Furthermore, it ignores abnormal updates and the data update progress of each sub-chip management node, resulting in low accuracy of dynamic maintenance events in the multi-chip, multi-level architecture. Summary of the Invention

[0003] The purpose of this invention is to overcome the shortcomings of the prior art. This invention provides a data update method and system for a multi-chip, multi-level architecture inverter.

[0004] This invention provides a data update method for a multi-chip, multi-level architecture inverter, comprising:

[0005] The chip control space is determined based on the detection of the inverter's database, and the multi-chip multi-level architecture of the inverter is determined based on the chip control space and the structural form of the inverter.

[0006] Multiple sub-chip control nodes are identified based on the chip control path identification of the multi-chip multi-level architecture. The data combination of each sub-chip control node is determined based on each sub-chip control node, the inverter's database, and the corresponding current working status.

[0007] The current data version of the sub-chip control node is determined based on the sub-chip control node and the corresponding data combination; the data update system of each sub-chip control node is determined based on the inverter's working process, the corresponding lithium battery data to be updated, and the current data version of each sub-chip control node.

[0008] Based on the data update paths of each sub-data in the data update system, the lithium battery data to be updated, and the node status of each sub-chip control node, determine the data update method of each sub-chip control node, and mark the data update progress of each sub-chip control node.

[0009] The autonomous update events of the multi-chip multi-level architecture are determined based on the data update progress of each sub-chip management node and multiple working data of the inverter. Abnormal update content is determined based on the detection of autonomous update events. Dynamic maintenance events of the multi-chip multi-level architecture are determined based on the abnormal update content, the data update progress of each sub-chip management node and the current working status of the inverter.

[0010] This invention provides a data update system for a multi-chip, multi-level architecture inverter. This data update system is applied to the aforementioned data update method for a multi-chip, multi-level architecture inverter. The multi-chip, multi-level architecture data update system includes:

[0011] A multi-chip multi-level architecture module is used to determine the chip control space based on the detection of the inverter's database, and to determine the multi-chip multi-level architecture of the inverter based on the chip control space and the structural form of the inverter.

[0012] The data combination module is used to determine multiple sub-chip control nodes based on the identification of chip control paths in a multi-chip, multi-level architecture, and to determine the data combination of each sub-chip control node based on each sub-chip control node, the inverter's database, and the corresponding current operating status.

[0013] The data update system module is used to determine the current data version of the sub-chip control node based on the sub-chip control node and the corresponding data combination; and to determine the data update system of each sub-chip control node based on the inverter's working process, the corresponding lithium battery data to be updated, and the current data version of each sub-chip control node.

[0014] The data update progress module is used to determine the data update method of each sub-chip control node based on the data update paths of each sub-data in the data update system, the lithium battery data to be updated, and the node status of each sub-chip control node, and to mark the data update progress of each sub-chip control node.

[0015] The dynamic maintenance event module is used to determine the autonomous update events of the multi-chip multi-level architecture based on the data update progress of each sub-chip management node and multiple working data of the inverter. It determines the abnormal update content based on the detection of autonomous update events, and determines the dynamic maintenance events of the multi-chip multi-level architecture based on the abnormal update content, the data update progress of each sub-chip management node and the current working status of the inverter.

[0016] Compared with the prior art, the beneficial effects of the present invention are:

[0017] In this embodiment of the invention, the method determines the chip control space based on the detection of the inverter's database, and determines the multi-chip, multi-level architecture of the inverter based on the chip control space and the inverter's structural form. Multiple sub-chip control nodes are determined based on the identification of the chip control paths in the multi-chip, multi-level architecture. Data combinations for each sub-chip control node are determined based on each sub-chip control node, the inverter's database, and the corresponding current operating state. The current data version of the sub-chip control node is determined based on the sub-chip control node and its corresponding data combination. A data update system for each sub-chip control node is determined based on the inverter's operating process, the corresponding lithium battery data to be updated, and the current data version of each sub-chip control node. This method introduces and further manages each sub-chip control node, taking into account the overall considerations of the inverter's operating process, the corresponding lithium battery data to be updated, and the current data version of each sub-chip control node, thereby improving the accuracy of the data update system for each sub-chip control node.

[0018] Therefore, based on the data update paths of each sub-data node in the data update system, the lithium battery data to be updated, and the node status of each sub-chip control node, the data update method of each sub-chip control node is determined, and the data update progress of each sub-chip control node is marked. Based on the data update progress of each sub-chip control node and multiple working data of the inverter, autonomous update events of the multi-chip multi-level architecture are determined. Abnormal update content is determined based on the detection of autonomous update events. Based on the abnormal update content, the data update progress of each sub-chip control node, and the current working status of the inverter, dynamic maintenance events of the multi-chip multi-level architecture are determined. The data update progress of each sub-chip control node is introduced to further control the abnormal update content. This achieves a holistic consideration of the abnormal update content, the data update progress of each sub-chip control node, and the current working status of the inverter, improving the accuracy of dynamic maintenance events of the multi-chip multi-level architecture. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating the data update method for a multi-chip, multi-level architecture inverter in an embodiment of the present invention.

[0020] Figure 2 This is a flowchart illustrating step S11 in the data update method of the multi-chip multi-level architecture of the inverter in this embodiment of the invention.

[0021] Figure 3 This is a flowchart illustrating step S12 in the data update method for the multi-chip, multi-level architecture of the inverter in this embodiment of the invention.

[0022] Figure 4This is a flowchart illustrating step S13 in the data update method of the multi-chip multi-level architecture of the inverter in this embodiment of the invention.

[0023] Figure 5 This is a flowchart illustrating step S14 in the data update method for the multi-chip, multi-level architecture of the inverter in this embodiment of the invention.

[0024] Figure 6 This is a flowchart illustrating step S15 in the data update method for the multi-chip, multi-level architecture of the inverter in this embodiment of the invention.

[0025] Figure 7 This is a schematic diagram of the structure of the data update system of the multi-chip, multi-level architecture of the inverter in this embodiment of the invention. Detailed Implementation

[0026] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0027] Please see Figures 1 to 7 A data update method for a multi-chip, multi-level architecture inverter, applied to data update scenarios; the data update method for a multi-chip, multi-level architecture inverter includes:

[0028] Step S11: Determine the chip control space based on the detection of the inverter's database, and determine the multi-chip multi-level architecture of the inverter based on the chip control space and the structural form of the inverter;

[0029] Step S12: Based on the identification of the chip control path of the multi-chip multi-level architecture, determine multiple sub-chip control nodes, and determine the data combination of each sub-chip control node based on each sub-chip control node, the inverter's database, and the corresponding current working status;

[0030] Step S13: Determine the current data version of the sub-chip control node based on the sub-chip control node and the corresponding data combination; determine the data update system of each sub-chip control node according to the inverter's working process, the corresponding lithium battery data to be updated, and the current data version of each sub-chip control node;

[0031] Step S14: Determine the data update method of each sub-chip control node based on the data update path of each sub-data in the data update system, the lithium battery data to be updated, and the node status of each sub-chip control node, and mark the data update progress of each sub-chip control node.

[0032] Step S15: Determine the autonomous update event of the multi-chip multi-level architecture based on the data update progress of each sub-chip management node and multiple working data of the inverter. Determine the abnormal update content based on the detection of the autonomous update event. Determine the dynamic maintenance event of the multi-chip multi-level architecture based on the abnormal update content, the data update progress of each sub-chip management node and the current working status of the inverter.

[0033] refer to Figure 2 In step S11, the specific steps are as follows:

[0034] S111: Collect the current position and communication signal of the inverter, determine the inverter's database based on the traceability of the inverter's current position and communication signal, determine the chip's control mark based on the detection of the inverter's database, and determine the corresponding chip control space based on the traceability of the control mark;

[0035] S112: Based on the identification of the chip control space, the corresponding chip control signal is determined. At the same time, the structural form of the inverter and the corresponding chip distribution diagram are collected. Based on the control signals of each chip, the structural form of the inverter and the corresponding chip distribution diagram, the multi-chip multi-level architecture of the inverter is determined. The multi-chip multi-level architecture is constructed by multiple chips, and the multiple chips have different data priorities.

[0036] In the embodiments of this application, the current location and communication signals of the inverter are collected, the inverter's database is determined based on the tracing of the inverter's current location and communication signals, the control mark of the chip is determined based on the detection of the inverter's database, and the corresponding chip control space is determined based on the tracing of the control mark. This approach is compatible with the overall consideration of the detection of the inverter's database and ensures the accuracy of the chip's control mark.

[0037] At this point, the system determines the device's logical location in the network topology, rather than its geographical coordinates, by reading the device_ID, Station_ID, and other identifiers preset in the device firmware. Subsequently, the system performs multi-dimensional communication signal evaluation, including measuring signal strength (such as the RSSI value of Wi-Fi), link quality (such as bit error rate and packet loss rate), network latency, and bandwidth. These parameters are usually driven by the underlying PHY layer or obtained through AT commands, providing a basis for decision-making on subsequent communication strategies.

[0038] After obtaining the device's identity and communication status, the system uses this information as an index to query and match in the central configuration server or local configuration matrix to determine the database corresponding to the device. This database is a structured collection of data containing a complete blueprint of the device, including its hardware model, software version, chip list, and communication protocol configuration. It is worth noting that this process is dynamic. If poor communication quality is detected, the system will proactively select a simplified version of the database or enable a data compression strategy to ensure that critical data can still be synchronized even under low-quality links.

[0039] Once the database is selected, the system assigns control tags to each chip. These tags are structured enumerations or bit fields used to precisely define the chip's role in the system (such as main controller, power module), permissions (such as read-only, read-write), and functions (such as DC conversion, security monitoring). This tagging system is the basis for permissions of all subsequent data operations, ensuring that access to different chips is controlled and secure.

[0040] Based on the assigned control tags, the system internally establishes a mapping relationship from tags to specific data address spaces. Each chip's control space is a logical data container that contains all readable and writable data points under the chip's jurisdiction. These data points have their addresses, types, and physical ranges explicitly defined in the data dictionary. This design ensures logical isolation between control spaces. For example, operations on the power module will not directly affect the sampling module, thereby enhancing the system's modularity and security.

[0041] Furthermore, based on the identification of the chip control space, the corresponding chip control signals are determined. At the same time, the structural form of the inverter and the corresponding chip distribution diagram are collected. Based on the control signals of each chip, the structural form of the inverter and the corresponding chip distribution diagram, the multi-chip multi-level architecture of the inverter is determined. The multi-chip multi-level architecture is constructed by multiple chips, and the multiple chips have different data priorities. It takes into account the overall consideration of the control signals of each chip, the structural form of the inverter and the corresponding chip distribution diagram, and ensures the accuracy of the multi-chip multi-level architecture of the inverter.

[0042] At this point, after defining the control space of each chip, the system needs to generate specific operation instructions, i.e., chip control signals, for the data points within these spaces. The system will generate an instruction set based on the attributes of the data points (such as read / write permissions and data types) and following specific communication protocols (such as Modbus, CANopen, or proprietary protocols). Each control signal is carefully encapsulated, containing elements such as the target node address, function code, register address, data length, and content. In addition, the system will assign signal types to different data points, such as periodic signals for real-time acquisition, event-triggered signals for fault reporting, and on-demand request signals for parameter configuration, thereby achieving refined management of data interaction.

[0043] The system reads the device's structure from its hardware abstraction layer or description file, such as whether it is a "star topology" or a "bus topology," and clarifies the hierarchical relationship of the data flow. At the same time, the system collects a more specific chip distribution map, which not only describes the physical location of the chips, but more importantly, defines the communication links (such as SPI, I2C, CAN) and master-slave relationships between them. This distribution map is the key basis for subsequent data request routing.

[0044] Based on the control signals, structural form, and chip distribution diagram, the multi-chip, multi-level architecture of the inverter is determined. The system integrates the information obtained in the first three steps to construct a dynamic and executable system architecture model. In this model, each chip control space becomes a network node, the chip distribution diagram establishes logical communication links between nodes, and the structural form defines the hierarchy and routing rules of the data flow. The system also binds the control signals generated in the first step with the corresponding communication links and protocol stacks. The final generated architecture instance is a runtime object containing a list of nodes, link status, routing rules, and protocol configuration.

[0045] To ensure the real-time performance and security of the system, the architecture model must incorporate a data prioritization strategy. Priorities are typically defined based on the impact of data on system security, functionality, and performance, forming a refined hierarchical system. For example, P0 is used for the highest priority safety signals such as emergency stop commands, P1 for critical control signals such as PWM updates, P2 for important status information such as SOC, and P3 for routine diagnostic data such as temperature readings. In implementation, priority transmission and processing of high-priority data can be guaranteed by setting priority bits in the communication protocol (such as the arbitration ID of CAN) or by using high-priority interrupts in the operating system.

[0046] refer to Figure 3 In step S12, the specific steps are as follows:

[0047] S121: Real-time monitoring of the multi-chip multi-level architecture of the inverter, determining the chip control path of the multi-chip multi-level architecture based on the detection of the multi-chip multi-level architecture, and determining multiple sub-chip control areas based on the identification of the chip control path of the multi-chip multi-level architecture.

[0048] S122: Determine the corresponding sub-chip control nodes based on multiple sub-chip control areas, the location of the corresponding chips, and the data control dimensions, so as to collect multiple sub-chip control nodes; at the same time, collect multiple working data of the inverter, determine the current working status of the inverter based on the multiple working data of the inverter, and determine the data combination of each sub-chip control node based on each sub-chip control node, the inverter's database, and the corresponding current working status.

[0049] In the embodiments of this application, the multi-chip multi-level architecture of the inverter is monitored in real time. The chip control path of the multi-chip multi-level architecture is determined based on the detection of the multi-chip multi-level architecture. Multiple sub-chip control areas are determined based on the identification of the chip control path of the multi-chip multi-level architecture. This approach is compatible with the overall consideration of the identification of the chip control path of the multi-chip multi-level architecture and ensures the accuracy of the multiple sub-chip control areas.

[0050] At this point, the system continuously assesses the health of the entire architecture through a state machine-based or event-driven monitoring mechanism, rather than simple polling. The monitoring controller (usually the main control chip) periodically or triggered by specific events (such as communication timeouts) detects the online status of each sub-chip, communication link quality (such as CRC error rate), and node load through heartbeat packets, reading link status registers, etc. All the collected information is integrated into a system health status table, providing real-time basis for dynamic decision-making.

[0051] After obtaining the real-time health status of the architecture, the system needs to determine or verify the valid data path to each target chip. The system will combine the static routing table built by S11 and the real-time monitoring results of S121 to dynamically calculate or confirm the optimal control path. At the same time, the system will maintain a dynamic routing table. If the communication quality of a certain path continues to decline or is interrupted, the system will try an alternative path (if one exists) or mark the node as "unreachable" and trigger an alarm. This dynamic path management ensures the reliability of data transmission.

[0052] The system instantiates a dynamic "sub-chip control area" for each reachable sub-chip. This area is not only a dynamic version of the "chip control space" in S11, but also bound to the currently valid control path, path quality indicators, and node online status. It can be understood as a dynamic data structure containing {target chip ID, control space definition, currently valid path, path quality, node status}. These control areas are updated in real time as the network status changes, providing the most direct and reliable input for the upper-layer data update strategy.

[0053] Specifically, the system has constructed a static architecture model and communication rules for the C inverter; the MasterMCU, acting as the monitoring controller, initiates its built-in monitoring task; it sends a status query command to the DSP_Power via the SPI bus and receives a correct response within 5ms, thus confirming that the DSP_Power is online and the SPI link is of good quality; immediately afterward, it sends a command to the BMS_Controller to read the status register via the I2C bus, and also receives a normal response, confirming that the BMS_Controller is also online and the I2C link is normal; the system updates this information to the internal "system health status table" in real time.

[0054] The system queries the static routing table built in phase S11 and, combined with the monitoring results just now, confirms that the currently effective control path is:

[0055] Path 1 (to DSP): MasterMCU (SPIMaster) > DSP_Power (SPISlave); Path 2 (to BMS): MasterMCU (I2CMaster) > BMS_Controller (I2CSlave); The system marks these two paths as "Active" in the dynamic routing table, indicating that they are currently available data channels.

[0056] Based on the confirmed paths and states, the system instantiates three dynamic sub-chip control regions:

[0057] Area_DSP:{Target_ID:DSP_Power,Control_Space:CS_Power,Active_Path:Master>DSP(SPI),Path_Quality:Good,Node_Status:Online};

[0058] Area_BMS:{Target_ID:BMS_Controller,Control_Space:CS_BMS,Active_Path:Master>BMS(I2C),Path_Quality:Good,Node_Status:Online};

[0059] Area_Master:{Target_ID:Master,Control_Space:CS_Master,Active_Path:Local,Path_Quality:N / A,Node_Status:Online}.

[0060] Furthermore, based on the multiple sub-chip control areas, the corresponding chip locations, and data control dimensions, corresponding sub-chip control nodes are determined to collect data from multiple sub-chip control nodes. Simultaneously, multiple operating data from the inverter are collected, and the current operating status of the inverter is determined based on these data. The data combination of each sub-chip control node is determined based on each sub-chip control node, the inverter's database, and the corresponding current operating status. This approach considers the overall factors of each sub-chip control node, the inverter's database, and the corresponding current operating status, ensuring the accuracy of the data combination from each sub-chip control node.

[0061] At this point, the system will create a "sub-chip management node" object for each management region generated by S121, combined with the chip's physical location (for diagnostic positioning) and data management dimensions (such as control class, status class, and diagnostic class). This object encapsulates all the metadata and runtime variables required to interact with the chip, including node ID, physical location, data dimension list, bound management region pointer, and communication protocol stack handle, forming a standardized interface abstraction for use by upper-layer task scheduling.

[0062] To achieve context-aware data management, the system must understand the current macroscopic operating status of the equipment. The system continuously collects high-level operating data from the monitoring controller (main control chip), such as system operating mode, active / reactive power, DC bus voltage, battery SOC, and fault codes. Subsequently, the system uses a built-in state machine or rule-based inference engine to fuse and analyze this data, ultimately arriving at a precise, macroscopic current operating status, such as "stable off-grid discharge," "fully charged standby," or "hardware fault protection."

[0063] By organically combining a static database, dynamic nodes, and real-time status, a data combination to be processed is dynamically generated for each node. This process follows the principles of context awareness and demand-driven: the database provides a list of all data points for each node, the current working status determines which data points are currently "relevant" and "important," and the management node defines the ownership and access methods of these data points; the system traverses the database, filters out matching data points based on the current status, and organizes them into an ordered list of "data combinations," which serves as the direct input for subsequent data update tasks.

[0064] Specifically, the system has dynamically confirmed control areas such as Area_DSP and Area_BMS; based on the control areas generated by S121, the system instantiates three specific control node objects:

[0065] Node_DSP_Handler: Created based on Area_DSP, its attributes include ID DSP_Power, location in Main_Power_Board, and data dimensions {Control, Status}; Node_BMS_Handler: Created based on Area_BMS, its attributes include ID BMS_Controller, location in Battery_Management_Board, and data dimensions {Status, Alarm}; Node_Master_Handler: Created by the master control chip itself, responsible for system-level data interaction. These node objects are now ready and waiting to receive specific task instructions.

[0066] The MasterMCU reads its internal status register and collects key operating data: the system mode is "off-grid discharge", the output power is 3000W, the battery SOC is 45%, and the fault code register is 0x0000. After receiving this data, the system's state machine makes a comprehensive judgment and finally determines that the current operating state is "off-grid stable discharge".

[0067] The system queries the database and dynamically generates precise data combinations for each node based on the specific state of "stable off-grid discharge": For Node_DSP_Handler: data points related to power control in the "off-grid discharge" state are selected in the database; the data combination is determined as: {output voltage setpoint, output frequency setpoint, PWM dead time, voltage loop PI parameters, current loop PI parameters}, which are the core control parameters for maintaining stable off-grid discharge; For Node_BMS_Handler: data points related to battery monitoring in the "discharge" state are selected in the database; the data combination is determined as: {total battery pack voltage, discharge current, minimum voltage of individual cells, real-time SOC value, cell temperature}, which are key data for monitoring the health and safety status of the battery during discharge; For Node_Master_Handler: the data combination is determined as: {system running status word, communication heartbeat with host computer, fault log buffer, cumulative discharge capacity}, which is the basic data for maintaining external communication, overall monitoring, and power statistics of the system.

[0068] refer to Figure 4 In step S13, the specific steps are as follows:

[0069] S131: Collect the data of the sub-chip control node, determine the corresponding data distance process based on the traceability of the sub-chip control node, and determine the current data version of the sub-chip control node according to the node position of the sub-chip control node, the corresponding data distance process and the corresponding data combination;

[0070] S132: Monitor the inverter in real time and mark the inverter's working process. Based on the identification of the inverter's working process, determine multiple sub-working contents. At the same time, collect the lithium battery data to be updated in the inverter and determine the first data update content according to the inverter's working process and the corresponding lithium battery data to be updated.

[0071] S133: Determine the second data update content based on the inverter's lithium battery data to be updated and the current data version of each sub-chip management node, and determine the data update system of each sub-chip management node based on the first data update content, the second data update content, and the multi-chip multi-level architecture.

[0072] In the embodiments of this application, the sub-chip management node is collected, the corresponding data distance process is determined based on the tracing of the sub-chip management node, and the current data version of the sub-chip management node is determined according to the node position of the sub-chip management node, the corresponding data distance process, and the corresponding data combination. This approach takes into account the overall consideration of the node position of the sub-chip management node, the corresponding data distance process, and the corresponding data combination, ensuring the accuracy of the current data version of the sub-chip management node.

[0073] At this point, the system obtains the sub-chip management node object created in S122 and delves into the data status held by the node through "tracing". The data distance process is a comprehensive quantitative indicator, and its calculation integrates multiple factors: the timestamp of the last update of the data point (timestamp decay), the recent historical performance of the node's communication link (communication quality factor), and the validity period preset for different types of data (data lifecycle TTL). The system will calculate the distance process of all data points in the data combination of the node, and then use aggregation algorithms such as weighted average or taking the maximum value to obtain a comprehensive data distance process value that represents the overall data timeliness of the node.

[0074] After obtaining the data distance process, the system needs to generate a version number for each node that can uniquely identify its current data snapshot status. The physical or logical location of the node will affect the version generation strategy, for example, a more lenient judgment strategy will be adopted for remote nodes. The version is usually generated by a hash algorithm: the system selects key data points from the data combination of the node, combines its value, timestamp, and comprehensive data distance process value into an input vector, and then applies algorithms such as CRC32 or MD5 to generate a fixed-length hash value. This version number allows the system to quickly determine whether the data of the node has changed without having to compare a large number of data points one by one, providing a decision basis for subsequent accurate data synchronization.

[0075] Specifically, building upon the achievements of S122, the system has created control nodes such as Node_DSP_Handler and Node_BMS_Handler. The system obtains the Node_DSP_Handler object and checks the key data points in its data combination: PWM dead time: last updated 10 minutes ago; voltage loop PI parameters: last updated 1 hour ago; current loop PI parameters: last updated 1 hour ago. Based on the preset TTL (control parameter TTL is 30 minutes) and timestamp decay, the system calculates that the voltage loop and current loop PI parameters have "expired," and their data is far from the progress value. Combining all data points, the system concludes that the overall data distance from the progress value of Node_DSP_Handler is "high," indicating that its data is not timely enough overall.

[0076] The system selects the voltage loop PI parameter and the current loop PI parameter as key data points; combines the current values ​​of these two parameters, their timestamps, and the "high" data distance process value into an input vector; performs CRC32 calculation on this vector to generate a hash value, such as 0xA3F2C8D1, which is the current data version of Node_DSP_Handler.

[0077] The system retrieves the Node_BMS_Handler object and checks its data combination: SOC real-time value: last updated 1 second ago; battery pack total voltage: last updated 1 second ago; discharge current: last updated 1 second ago. These are all real-time data with a TTL of 5 seconds. After calculation, the system concludes that all data points are very timely. Therefore, the overall data distance process value of Node_BMS_Handler is "low".

[0078] The system selects the real-time SOC value and discharge current as key data points; combines the current values ​​of these two parameters, their timestamps, and the "low" data distance process value into an input vector; the calculated hash value is 0xB8C1E5F0, which is the current data version of Node_BMS_Handler.

[0079] Furthermore, the inverter is monitored in real time, and its working process is marked. Based on the identification of the inverter's working process, multiple sub-work contents are determined. At the same time, the lithium battery data to be updated in the inverter is collected. The first data update content is determined according to the inverter's working process and the corresponding lithium battery data to be updated. This overall consideration of the inverter's working process and the corresponding lithium battery data to be updated ensures the accuracy of the first data update content.

[0080] At this time, a real-time operating system (RTOS) or a high-precision task scheduler usually runs inside the system, designing the main functions of the inverter (such as grid-connected control, MPPT, and battery management) as independent tasks or processes. The monitoring controller obtains the running status of each process in real time by reading the Task Status Control Block (TCB) provided by the operating system or a custom heartbeat mechanism, and marks it as RUNNING, READY, BLOCKED, or SUSPENDED. This status information is written to the shared system status register area, providing a precise basis for system resource allocation and functional activity for subsequent decisions.

[0081] A sub-work content is a semantic description of a specific state in the state machine; for example, the state machine of the "battery charging and discharging management process" includes states such as constant current charging (CC_CHARGE) and constant voltage charging (CV_CHARGE); when the process is in the RUNNING state and its state machine is in CC_CHARGE, the system recognizes that the current sub-work content is "execute the constant current charging algorithm"; the system will also combine the states of multiple processes to determine a more precise composite sub-work content, such as "perform constant current charging on the battery in grid-connected mode".

[0082] The system retrieves "lithium battery data to be updated" from sources such as the cloud, local storage, or user input and stores it in a buffer. Based on the sub-task content identified in the previous step, the system queries a preset "task process-data requirement" mapping rule library and intelligently filters out data strongly related to the sub-task content from the buffer. This filtered data is called "first data update content," and its core characteristic is behavior-driven. It is data that the system "urgently needs" to complete the current specific task and has the highest timeliness and task relevance.

[0083] Therefore, the second data update content is determined based on the inverter's lithium battery data to be updated and the current data version of each sub-chip management node. The data update system for each sub-chip management node is then determined based on the first and second data update content and the multi-chip, multi-level architecture. This approach considers the overall integration of the first and second data update content and the multi-chip, multi-level architecture, ensuring the accuracy of the data update system for each sub-chip management node. Furthermore, by introducing and further managing each sub-chip management node, the system considers the inverter's operating process, the corresponding lithium battery data to be updated, and the current data version of each sub-chip management node, thereby improving the accuracy of the data update system for each sub-chip management node.

[0084] At this point, the system will traverse each data item in the "data buffer to be updated" and use a version comparison mechanism to determine whether it needs to be updated. Specifically, the system will locate the target node based on the data point attributes and obtain the current data version of that node calculated in S131. The system will use the new data to be updated to simulate and generate an updated "expected data version". If this expected version is inconsistent with the current version of the node, it indicates that the data of that node needs to be refreshed, and this data to be updated is marked as "second data update content". This process ensures that even if the system does not trigger a specific action, expired or changed data can be synchronized in a timely manner.

[0085] The system merges and deduplicates the first data update content generated in S132 and the second data update content generated in S133, with the first update content having higher priority. Subsequently, the system sorts the merged tasks according to a comprehensive strategy that takes into account the task source, the priority of the data itself, and the dependencies between nodes. The system combines this sorted task list with the communication paths, protocols, and node states defined in the multi-chip architecture to build a structured and executable data update system, which is usually represented as an ordered task queue or a directed acyclic graph (DAG), providing precise action guidelines for data updates.

[0086] Specifically, the system has determined that the first data update is "new target charging current: 60A"; the system continues to check the remaining data in the "data buffer to be updated" and compare it with the current version of each node: the target node is Node_BMS_Handler; the system uses this new algorithm to simulate and calculate the expected version, and finds that it is different from the current version 0xB8C1E5F0 of Node_BMS_Handler; therefore, this item is marked as the second data update.

[0087] The target node is also Node_BMS_Handler; after version comparison, an inconsistency was found, and it was also marked as the second data update content; at the same time, the target node is Node_DSP_Handler; after comparison with the current version 0xA3F2C8D1 of Node_DSP_Handler, an inconsistency was found, and this item was also marked as the second data update content.

[0088] The system enters the final scheduling and planning phase, integrating all update requests into an ordered plan: First update content: {Target charging current: 60A}; Second update content: {SOH lookup table algorithm, equalization threshold: 3.65V, voltage loop PI parameters}.

[0089] Highest priority (P1): Target charging current: 60A > Target node Node_BMS_Handler > Path I2C. This is behavior-driven and must be executed immediately to adjust charging behavior. Second highest priority (P2): Balancing threshold: 3.65V > Target node Node_BMS_Handler > Path I2C. This is a charging-related configuration, but less urgent than the current value. Medium priority (P3): SOH lookup algorithm > Target node Node_BMS_Handler > Path I2C. This is an algorithm update that affects long-term accuracy and can be executed when communication is not busy. Lowest priority (P4): Voltage loop PI parameters > Target node Node_DSP_Handler > Path SPI. This is a performance optimization parameter, not directly related to the current charging task, and has the lowest priority.

[0090] The system generates an ordered task queue, which is the final data update system: Task 1: Immediately write the target charging current to Node_BMS_Handler via I2C; Task 2: After Task 1 is completed, write the balancing threshold to Node_BMS_Handler via I2C during the next communication idle period; Task 3: After Task 2 is completed, update the SOH lookup table algorithm to Node_BMS_Handler via I2C during low load periods; Task 4: After all BMS-related urgent tasks are completed, update the voltage loop PI parameters to Node_DSP_Handler via SPI during system idle periods.

[0091] refer to Figure 5 In step S14, the specific steps are as follows:

[0092] S141: In the data update system, multiple sub-data update items are determined based on the identification of the data update system. The corresponding sub-data update path is determined according to the item content, item order and corresponding sub-chip control node of each sub-data update item, so as to collect each sub-data update path of the data update system.

[0093] S142: Monitor each sub-chip management node in real time and mark the node status of each sub-chip management node. Determine the first update system parameters based on the sub-data update paths of the data update system and the lithium battery data to be updated. Determine the second update system parameters based on the sub-data update paths of the data update system and the node status of each sub-chip management node.

[0094] S143: Determine the data update method of each sub-chip management node based on the mapping relationship between the first update system parameters, the second update system parameters, and the data update method; trigger the data update of each sub-chip management node based on the data update method of each sub-chip management node, and dynamically record the data update progress of each sub-chip management node.

[0095] In the embodiments of this application, in the data update system, multiple sub-data update items are determined based on the identification of the data update system. The corresponding sub-data update path is determined according to the item content, item order and corresponding sub-chip control node of each sub-data update item, so as to collect each sub-data update path of the data update system. This takes into account the overall consideration of the item content, item order and corresponding sub-chip control node of each sub-data update item, and ensures the accuracy of the corresponding sub-data update path.

[0096] At this point, the system will parse this update system, which is represented as an ordered task queue or a directed acyclic graph (DAG), and encapsulate each independent and indivisible update operation into a standardized "sub-data update project" object. Each project object contains a clear set of attributes, such as project ID, target node ID, data content to be written, priority, and other project IDs it depends on, thereby transforming an abstract plan into a series of concrete work units.

[0097] For each sub-data update project, the system will use its target node ID as an index to query the multi-chip multi-level architecture model built in step S11. Based on this, the system will calculate a complete end-to-end communication path from the monitoring controller to the target node, which is a sequence of nodes and links spanning multiple buses. Subsequently, the system will bind this specific path information (such as protocol type, device address, register address) as an attribute to the corresponding project object, making it a quasi-executable instruction.

[0098] The system checks the current status of each path, such as whether the bus is occupied or whether the target node is online. Once the paths of all sub-data update projects have been determined and preliminarily verified, the output of S141 is a set consisting of multiple complete "execution units". Each execution unit contains all the information required to perform a data update: project ID, data content, priority, dependencies, and a fully resolved communication path. This set will be directly handed over to the next step for scheduling decision.

[0099] Specifically, the system has generated an ordered data update system (task queue); the system parses the update system generated by S13 and decomposes it into four independent sub-data update projects: Project P1:

[0100] {ID:T1,Target:Node_BMS_Handler,Content:{Target charging current:60A},Priority:P1}; Project P2: {ID:T2,Target:Node_BMS_Handler,Content:{Balancing threshold:3.65V},Priority:P2}; Project P3:

[0101] {ID:T3,Target:Node_BMS_Handler,Content:{SOH lookup table algorithm},Priority:P3}; Project P4: {ID:T4,Target:Node_DSP_Handler,Content:{voltage loop PI parameters},Priority:P4}.

[0102] The system queries the architecture model for each project to determine the specific communication path: For project P1: After querying, the system finds that Node_BMS_Handler is mounted on the I2C bus; therefore, its sub-data update path is determined as follows:

[0103] MasterMCU(I2CMaster)>BMS_Controller(I2CSlave,Address:0x5A); The specific protocol instruction is to write data to the target current register (0x200) of BMS_Controller.

[0104] For project P4: System queries revealed that Node_DSP_Handler is connected via the SPI bus; therefore, its sub-data update path is determined to be:

[0105] MasterMCU(SPIMaster)>DSP_Power(SPISlave,ChipSelect:CS0); The specific protocol instruction is to write data to the DSP_Power control parameter area offset by 0x1000 addresses; (The path determination process for projects P2 and P3 is the same as that for P1, and the target is Node_BMS_Handler).

[0106] The system binds the above path information to the project object, forming the final set of execution units, and performs path pre-checks: Execution Unit E1:

[0107] {ID:T1,Content:60A,Path:I2C@0x5A,Reg:0x200,…};

[0108] Execution unit E2:

[0109] {ID:T2,Content:3.65V,Path:I2C@0x5A,Reg:0x210,…};

[0110] Execution Unit E3:

[0111] {ID:T3,Content:SOH_Algo,Path:I2C@0x5A,Reg:0x300,…};

[0112] Execution Unit E4:

[0113] {ID:T4,Content:PI_Params,Path:SPI@CS0,Offset:0x1000,…};The system performs a quick path check to confirm that the I2C and SPI buses are currently available and the target node is online;At this point, step S141 is completed, and a list containing four complete, schedulable execution units is output, ready to be handed over to the next step for parameterized decision-making.

[0114] Furthermore, each sub-chip management node is monitored in real time, and the node status of each sub-chip management node is marked. The first update system parameters are determined based on the sub-data update paths of the data update system and the lithium battery data to be updated. The second update system parameters are determined based on the sub-data update paths of the data update system and the node status of each sub-chip management node. This approach takes into account the overall consideration of the sub-data update paths of the data update system and the node status of each sub-chip management node, ensuring the accuracy of the second update system parameters.

[0115] At this time, the monitoring controller continuously evaluates the health and activity level of all sub-chips through heartbeat mechanisms, status register polling, and communication link quality monitoring. The system integrates the collected information into a standardized node status enumeration value, such as ONLINE_READY (online and ready), ONLINE_BUSY (online but busy), DEGRADED (online but poor communication quality), or FAULT (node ​​failure). This status is updated in real time to a shared node status table, providing dynamic input for subsequent parameter calculations.

[0116] The system analyzes the data content to be updated and its communication path, and calculates a series of parameters describing its transmission characteristics. These parameters include data size (byte length), transmission delay budget allocated according to business importance (milliseconds or seconds), reliability requirements (whether ACK and retransmission strategies are needed), and bandwidth usage estimation based on path bandwidth. These "first update system parameters" constitute the static or semi-static identity of each task and define its basic requirements for the transmission process.

[0117] The system combines the current state of the communication path (such as whether the bus is idle) and the real-time state of the target node (obtained from the node status table) to calculate a series of dynamic parameters describing the execution environment. These parameters include path availability, node readiness, and system load factor derived from system-level performance metrics. Taking all these factors into account, the system also assesses the potential risks of executing this update to the core functions of the system and arrives at a safety margin assessment. These "second update parameters" provide crucial context for scheduling decisions, ensuring that tasks are not executed at inappropriate times.

[0118] Specifically, the system has generated four execution units (E1-E4); the MasterMCU's monitoring task reads the status table, and the current status is: Node_BMS_Handler: status is ONLINE_READY (I2C heartbeat is normal, status register shows idle); Node_DSP_Handler: status is ONLINE_BUSY (status register shows that a complex FFT calculation is being performed, and the SPI bus is occupied).

[0119] The system calculates the inherent attributes for each execution unit: For execution unit E1 (updating target charging current): Data size: 4 bytes (floating-point); Transmission delay budget: 50ms (high-priority control data); Reliability requirement: ACK required, maximum 3 retries; Bandwidth usage estimate: very low (<1%); For execution unit E4 (updating voltage loop PI parameters): Data size: 16 bytes (4 floating-point numbers); Transmission delay budget: 5000ms (low-priority configuration data); Reliability requirement: ACK required, maximum 2 retries; Bandwidth usage estimate: low (<5%).

[0120] The system evaluates the dynamic environment during the execution of each task: For execution unit E1 (path is I2C, target is BMS): Path availability: High (I2C bus is currently idle); Node readiness: 100% (Node_BMS_Handler status is ONLINE_READY); System load factor: 25% (CPU load is low); Safety margin assessment: High (execution of updates poses no risk to the system); For execution unit E4 (path is SPI, target is DSP): Path availability: Low (SPI bus is occupied by DSP computation tasks); Node readiness: 20% (Node_DSP_Handler status is ONLINE_BUSY); System load factor: 25% (CPU load is low); Safety margin assessment: Low (forced interruption of DSP tasks causes output voltage fluctuations).

[0121] The system attaches two sets of key context parameters to each task to be executed: the first update parameter describes the task's own "temperament" (how large and urgent the data is); the second update parameter describes the "current status" of the task execution environment (whether the road is open and whether people are available). These two sets of parameters together constitute the complete input for the next step of intelligent decision-making (choosing to execute immediately, wait in the queue, or delay execution), so that the data update strategy can perfectly match the dynamically changing system environment.

[0122] Therefore, the data update method of each sub-chip control node is determined based on the mapping relationship between the first update system parameters, the second update system parameters, and the data update method; the data update of each sub-chip control node is triggered based on the data update method of each sub-chip control node, and the data update progress of each sub-chip control node is dynamically recorded. This approach takes into account the overall consideration of the mapping relationship between the first update system parameters, the second update system parameters, and the data update method, and ensures the accuracy of the data update method of each sub-chip control node.

[0123] At this point, the system maintains a decision engine, which is essentially a complex mapping table or a rule-based expert system. This engine takes the first and second update parameters calculated by S142 as input and determines the data update method for each task through multi-dimensional decision logic. When making decisions, it prioritizes the urgency of the task, is strictly limited by the availability of the environment, and matches the system resources required for data transmission. The final determined update method is a predefined enumeration value, such as IMMEDIATE_SYNC (immediate synchronization), ASYNC_QUEUE (asynchronous queue), DELAYED_EXEC (delayed execution), or ABORT_AND_ALERT (abandon and alarm).

[0124] Once the update method is determined, the system will distribute it as a specific instruction to the corresponding execution module. For tasks requiring "immediate synchronization," the system will immediately call the underlying communication driver, blocking the current process until completion. For tasks in an "asynchronous queue," the system will place them in a background task queue, to be executed by a low-priority service task at an opportune time. For tasks requiring "delayed execution," the system will place them in a timed or conditionally triggered task list. For tasks requiring "abandonment and alert," the system will cancel the operation and generate an alert record. For critical data, the entire triggering process is typically designed as an atomic operation to ensure data consistency.

[0125] To enable full monitoring of the update process, the system creates or updates a progress tracking object for each task when an update is triggered. The object's status changes dynamically as the update process progresses, from PENDING (awaiting decision) to DISPATCHED (distributed), then to TRANSMITTING (transmitting), and finally to SUCCESS (success) or FAILED (failure). In addition, the object records rich metadata such as the actual start / end time, transmission time, and number of retries. This information is not only used for subsequent anomaly detection.

[0126] Specifically, the system has calculated two sets of update system parameters for execution units E1 and E4; the system decision engine selects the most suitable execution method for each task based on the input parameters: For execution unit E1 (updating target charging current): Input parameters: first update system (delay budget 50ms, high reliability), second update system (high path availability, 100% node readiness, high safety margin); the decision engine judges that this task is extremely urgent and the execution environment is perfect; determination method: IMMEDIATE_SYNC (immediate synchronization).

[0127] For execution unit E4 (updating voltage loop PI parameters): Input parameters: First update system (delay budget 5000ms, medium reliability), second update system (low path availability, node readiness 20%, low safety margin); The decision engine judges that this task is not urgent, but the current execution environment is harsh, and forced execution will interfere with the critical calculation of DSP; Determination method: DELAYED_EXEC (delayed execution).

[0128] The system performs specific operations according to the determined update method: For E1: The system immediately calls the I2C driver API to write a value of 60A to the 0x200 register at address 0x5A; the call is blocked until the BMS receives an ACK response; For E4: The system puts the execution unit E4 into the "maintenance window task list" and sets the trigger condition to "detects that the SPI bus has been idle for more than 500ms".

[0129] The system creates a progress tracking object for each task and updates its status in real time: For E1: When an I2C write is triggered, the system creates a Progress_T1 object and sets its status to TRANSMITTING; when an ACK is received from the BMS, the Progress_T1 status is updated to SUCCESS, and the transmission time is recorded as 5ms; For E4: When E4 is added to the delay list, the system creates a Progress_T4 object and sets its status to PENDING (waiting for trigger conditions). This status will remain until the SPI bus becomes idle at some point in the future, at which point the system retrieves it for execution, and the status will change to TRANSMITTING, and eventually to SUCCESS or FAILED.

[0130] refer to Figure 6 In step S15, the specific steps are as follows:

[0131] S151: In multiple sub-chip management nodes, determine multiple load contents of each sub-chip management node based on the load detection of each sub-chip management node, determine the data load status of the sub-chip management node based on the multiple load contents of the sub-chip management node, and determine the autonomous update event of the multi-chip multi-level architecture based on the data update progress of each sub-chip management node, the data load status of the sub-chip management node, and multiple working data of the inverter.

[0132] S152: Based on the detection of autonomous update events, determine multiple sub-autonomous update contents, determine the corresponding abnormal update contents based on the anomaly detection of multiple sub-autonomous update contents, and determine the first dynamic maintenance coefficient based on the abnormal update contents and the data update progress of each sub-chip management node.

[0133] S153: Determine the second dynamic maintenance coefficient based on the abnormal update content and the current operating state of the inverter, and determine the dynamic maintenance event of the multi-chip multi-level architecture based on the first dynamic maintenance coefficient, the second dynamic maintenance coefficient and the previous maintenance events of the multi-chip multi-level architecture.

[0134] In the embodiments of this application, among multiple sub-chip management nodes, multiple load contents of each sub-chip management node are determined based on the load detection of each sub-chip management node, and the data load status of the sub-chip management node is determined based on the multiple load contents of the sub-chip management node; the autonomous update event of the multi-chip multi-level architecture is determined based on the data update progress of each sub-chip management node, the data load status of the sub-chip management node, and multiple working data of the inverter. This approach takes into account the overall consideration of the data update progress of each sub-chip management node, the data load status of the sub-chip management node, and multiple working data of the inverter, ensuring the accuracy of the autonomous update event of the multi-chip multi-level architecture.

[0135] At this point, the system collects load data from multiple dimensions through the Performance Monitoring Unit (PMU) or status queries, including computational load (CPU utilization), memory load (RAM utilization), communication load (bus bandwidth usage), and task load (length of the pending queue). This multi-dimensional load data is input into a status evaluation model. The model uses methods such as weighted scoring or fuzzy logic to synthesize all inputs and finally outputs a qualitative data load status, such as IDLE, NORMAL, HEAVY, or OVERLOADED, thus intuitively reflecting the health of the node.

[0136] Based on the data update progress of each sub-chip management node, the data load status of that sub-chip management node, and multiple working data of the inverter, the autonomous update event of the multi-chip multi-level architecture is determined. The engine continuously integrates three types of key information: the data update progress from S143 (such as success, failure, timeout), the determined data load status, and the macroscopic working data of the inverter (such as operating mode, output power, system temperature). The system has a series of predefined event templates. When the combination of input information matches the conditions of a certain template, a structured "autonomous update event" object is generated, which contains the event type, source, severity level, and detailed description, providing a direct trigger for subsequent intelligent maintenance decisions.

[0137] Furthermore, multiple sub-autonomous update contents are determined based on the detection of autonomous update events, and corresponding abnormal update contents are determined based on the anomaly detection of multiple sub-autonomous update contents. The first dynamic maintenance coefficient is determined based on the abnormal update contents and the data update progress of each sub-chip management node. This approach takes into account both the abnormal update contents and the data update progress of each sub-chip management node, ensuring the accuracy of the first dynamic maintenance coefficient.

[0138] At this point, the system performs semantic parsing on the structured information of the event, breaking it down into multiple finer-grained, independently analyzable "sub-autonomous update content". For example, an event of "critical update failure under high load" can be decomposed into sub-contents such as "task update failure", "node overload", and "system in high power state". The goal of this process is to focus complex system-level problems on specific, evaluable sub-problems, providing clear input for subsequent anomaly detection.

[0139] The system equips each sub-content with an anomaly detector based on predefined rules, thresholds, or statistical models. For task-related sub-content, the detector checks its final state; if it is FAILED or TIMEOUT, it is directly marked as an anomaly. For load-related sub-content, the HEAVY or OVERLOADED state is marked as an anomaly. After this round of detection, all sub-autonomous update content marked as "anomaly" is officially defined as "anomaly update content," which is the fundamental reason why the system needs to take action.

[0140] The system uses a weighted summation model to calculate the "first dynamic maintenance coefficient". This model takes into account the severity weight of the anomaly and the priority weight of the task. For example, the weight of persistent failure is much higher than that of transient failure, and the weight of high-priority tasks is also higher than that of low-priority tasks. The higher the coefficient value is, the more serious the failure of the update process is and the greater the impact on the system reliability. This quantitative result provides key data support for subsequent determination of maintenance efforts.

[0141] Therefore, a second dynamic maintenance coefficient is determined based on the abnormal update content and the current operating status of the inverter. Dynamic maintenance events for the multi-chip, multi-level architecture are then determined based on the first and second dynamic maintenance coefficients and past maintenance events of the multi-chip, multi-level architecture. This approach integrates the first and second dynamic maintenance coefficients with a holistic consideration of past maintenance events for the multi-chip, multi-level architecture, ensuring the accuracy of the dynamic maintenance events. Furthermore, the data update progress of each sub-chip control node is introduced to further control the abnormal update content. This achieves a holistic consideration of the abnormal update content, the data update progress of each sub-chip control node, and the current operating status of the inverter, thereby improving the accuracy of the dynamic maintenance events for the multi-chip, multi-level architecture.

[0142] At this point, the system will use a contextual risk assessment model to combine the "abnormal update content" with key state parameters (such as operating mode, power level, and battery SOC) extracted from the current working data, and look up the corresponding risk level in an "abnormal-state-risk" mapping knowledge base. For example, the risk level of "BMS communication abnormality" in the "high-power discharge" state is much higher than that in the "standby float charging" state. This risk level is ultimately mapped to a specific value, namely the "second dynamic maintenance coefficient", which focuses on "how serious the consequences will be if things are done wrong", complementing the first dynamic maintenance coefficient.

[0143] The dynamic maintenance events for the multi-chip, multi-level architecture are determined based on the first dynamic maintenance coefficient, the second dynamic maintenance coefficient, and past maintenance events. This integrates information from three dimensions to make the final maintenance decision: the first dynamic maintenance coefficient (how severe is the process failure), the second dynamic maintenance coefficient (how severe is the potential impact), and past maintenance events (providing historical experience and trend analysis). A comprehensive decision engine (such as a multivariate weighted decision matrix or decision tree) analyzes these inputs and outputs a specific, immediately executable "dynamic maintenance event." This is no longer a state description but an operation command, such as: ROLLBACK_DATA (rollback data), ISOLATE_NODE (isolate the faulty node), REBOOT_NODE (reboot the node), or GENERATE_CRITICAL_ALARM (generate the highest level alarm).

[0144] Please see Figure 7 , Figure 7 This is a schematic diagram of the structure of the data update system for the multi-chip, multi-level architecture of the inverter in this embodiment of the invention; the data update system for the multi-chip, multi-level architecture of the inverter includes:

[0145] The multi-chip multi-level architecture module 21 is used to determine the chip control space based on the detection of the inverter's database, and to determine the multi-chip multi-level architecture of the inverter based on the chip control space and the structural form of the inverter.

[0146] The data combination module 22 is used to determine multiple sub-chip control nodes based on the identification of chip control paths in the multi-chip multi-level architecture, and to determine the data combination of each sub-chip control node based on each sub-chip control node, the inverter's database, and the corresponding current working status.

[0147] The data update system module 23 is used to determine the current data version of the sub-chip control node based on the sub-chip control node and the corresponding data combination; and to determine the data update system of each sub-chip control node according to the inverter's working process, the corresponding lithium battery data to be updated, and the current data version of each sub-chip control node.

[0148] The data update progress module 24 is used to determine the data update method of each sub-chip control node based on the data update path of each sub-data in the data update system, the lithium battery data to be updated, and the node status of each sub-chip control node, and to mark the data update progress of each sub-chip control node.

[0149] The dynamic maintenance event module 25 is used to determine the autonomous update event of the multi-chip multi-level architecture based on the data update progress of each sub-chip management node and multiple working data of the inverter. It determines the abnormal update content based on the detection of the autonomous update event, and determines the dynamic maintenance event of the multi-chip multi-level architecture based on the abnormal update content, the data update progress of each sub-chip management node and the current working status of the inverter.

[0150] The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

Claims

1. A data update method for a multi-chip, multi-level architecture inverter, characterized in that, include: The chip control space is determined based on the detection of the inverter's database, and the multi-chip multi-level architecture of the inverter is determined based on the chip control space and the structural form of the inverter. Multiple sub-chip control nodes are identified based on the chip control path identification of the multi-chip multi-level architecture. The data combination of each sub-chip control node is determined based on each sub-chip control node, the inverter's database, and the corresponding current working status. The current data version of the sub-chip control node is determined based on the sub-chip control node and the corresponding data combination; the data update system of each sub-chip control node is determined based on the inverter's working process, the corresponding lithium battery data to be updated, and the current data version of each sub-chip control node. Based on the data update paths of each sub-data in the data update system, the lithium battery data to be updated, and the node status of each sub-chip control node, determine the data update method of each sub-chip control node, and mark the data update progress of each sub-chip control node. The autonomous update events of the multi-chip multi-level architecture are determined based on the data update progress of each sub-chip management node and multiple working data of the inverter. Abnormal update content is determined based on the detection of autonomous update events. Dynamic maintenance events of the multi-chip multi-level architecture are determined based on the abnormal update content, the data update progress of each sub-chip management node and the current working status of the inverter.

2. The data update method for a multi-chip, multi-level architecture inverter according to claim 1, characterized in that, The chip control space is determined by detecting the inverter's database, and the multi-chip, multi-level architecture of the inverter is determined based on this chip control space and the inverter's structural form, including: The current location and communication signals of the inverter are collected. The inverter's database is determined based on the tracing of the current location and communication signals. The control flag of the chip is determined based on the detection of the inverter's database. The corresponding chip control space is determined based on the tracing of the control flag. Based on the identification of the chip control space, the corresponding chip control signal is determined. At the same time, the structural form of the inverter and the corresponding chip distribution diagram are collected. Based on the control signals of each chip, the structural form of the inverter and the corresponding chip distribution diagram, the multi-chip multi-level architecture of the inverter is determined. The multi-chip multi-level architecture is constructed by multiple chips, and the multiple chips have different data priorities.

3. The data update method for a multi-chip, multi-level architecture inverter according to claim 1, characterized in that, The process involves identifying multiple sub-chip control nodes based on the chip control path identification of a multi-chip, multi-level architecture, and determining the data combination of each sub-chip control node based on the sub-chip control node, the inverter's database, and the corresponding current operating status. This includes: Real-time monitoring of the multi-chip, multi-level architecture of the inverter; determination of the chip control path of the multi-chip, multi-level architecture based on the detection of the multi-chip, multi-level architecture; determination of multiple sub-chip control areas based on the identification of the chip control path of the multi-chip, multi-level architecture. The corresponding sub-chip control nodes are determined based on multiple sub-chip control areas, the location of the corresponding chips, and the data control dimensions, so as to collect multiple sub-chip control nodes; at the same time, multiple working data of the inverter are collected, the current working status of the inverter is determined based on the multiple working data of the inverter, and the data combination of each sub-chip control node is determined based on each sub-chip control node, the inverter's database, and the corresponding current working status.

4. The data update method for a multi-chip, multi-level architecture inverter according to claim 1, characterized in that, The current data version of the sub-chip control node is determined based on the sub-chip control node and the corresponding data combination; the data update system of each sub-chip control node is determined according to the inverter's working process, the corresponding lithium battery data to be updated, and the current data version of each sub-chip control node, including: The data of the sub-chip control node is collected, and the corresponding data distance process is determined based on the tracing of the sub-chip control node. The current data version of the sub-chip control node is determined according to the node position of the sub-chip control node, the corresponding data distance process, and the corresponding data combination.

5. The data update method for a multi-chip, multi-level architecture inverter according to claim 4, characterized in that, The process of determining the current data version of a sub-chip control node based on the sub-chip control node and its corresponding data combination, and determining the data update system for each sub-chip control node based on the inverter's operating progress, the corresponding lithium battery data to be updated, and the current data version of each sub-chip control node, further includes: The inverter is monitored in real time, and its working process is marked. Multiple sub-work contents are determined based on the identification of the inverter's working process. At the same time, the lithium battery data to be updated in the inverter is collected, and the first data update content is determined according to the inverter's working process and the corresponding lithium battery data to be updated. The second data update content is determined based on the lithium battery data to be updated in the inverter and the current data version of each sub-chip management node. The data update system of each sub-chip management node is determined based on the first data update content, the second data update content and the multi-chip multi-level architecture.

6. The data update method for a multi-chip, multi-level architecture inverter according to claim 1, characterized in that, The process of determining the data update method for each sub-chip control node based on the sub-data update paths of the data update system, the lithium battery data to be updated, and the node status of each sub-chip control node, and marking the data update progress of each sub-chip control node, includes: In the data update system, multiple sub-data update projects are identified based on the identification of the data update system. The corresponding sub-data update path is determined according to the project content, project order and corresponding sub-chip control node of each sub-data update project, so as to collect the sub-data update paths of the data update system.

7. The data update method for a multi-chip, multi-level architecture inverter according to claim 6, characterized in that, The step of determining the data update method for each sub-chip control node based on the various sub-data update paths of the data update system, the lithium battery data to be updated, and the node status of each sub-chip control node, and marking the data update progress of each sub-chip control node, also includes: Real-time monitoring of each sub-chip management node and marking the node status of each sub-chip management node; determining the first update system parameters based on the sub-data update paths of the data update system and the lithium battery data to be updated; determining the second update system parameters based on the sub-data update paths of the data update system and the node status of each sub-chip management node. The data update method of each sub-chip management node is determined based on the mapping relationship between the first update system parameters, the second update system parameters, and the data update method; the data update of each sub-chip management node is triggered based on the data update method of each sub-chip management node, and the data update progress of each sub-chip management node is dynamically recorded.

8. The data update method for a multi-chip, multi-level architecture inverter according to claim 1, characterized in that, The autonomous update events of the multi-chip multi-level architecture are determined based on the data update progress of each sub-chip management node and multiple working data of the inverter. Abnormal update content is determined based on the detection of these autonomous update events. Dynamic maintenance events of the multi-chip multi-level architecture are then determined based on this abnormal update content, the data update progress of each sub-chip management node, and the current working state of the inverter. These events include: In multiple sub-chip management nodes, multiple load contents of each sub-chip management node are determined based on the load detection of each sub-chip management node, and the data load status of the sub-chip management node is determined based on the multiple load contents of the sub-chip management node; the autonomous update event of the multi-chip multi-level architecture is determined based on the data update progress of each sub-chip management node, the data load status of the sub-chip management node, and multiple working data of the inverter.

9. The data update method for a multi-chip, multi-level architecture inverter according to claim 8, characterized in that, The process of determining autonomous update events for the multi-chip, multi-level architecture based on the data update progress of each sub-chip management node and multiple working data of the inverter, determining abnormal update content based on the detection of autonomous update events, and determining dynamic maintenance events for the multi-chip, multi-level architecture based on the abnormal update content, the data update progress of each sub-chip management node, and the current working status of the inverter, further includes: Multiple sub-autonomous update contents are determined based on the detection of autonomous update events. The corresponding abnormal update contents are determined based on the anomaly detection of multiple sub-autonomous update contents. The first dynamic maintenance coefficient is determined based on the abnormal update contents and the data update progress of each sub-chip management node. The second dynamic maintenance coefficient is determined based on the abnormal update content and the current operating status of the inverter. The dynamic maintenance events of the multi-chip multi-level architecture are determined based on the first dynamic maintenance coefficient, the second dynamic maintenance coefficient, and previous maintenance events of the multi-chip multi-level architecture.

10. A data update system for a multi-chip, multi-level architecture inverter, characterized in that, The data update system for the multi-chip, multi-level architecture of the inverter is applied to the data update method for the multi-chip, multi-level architecture of the inverter as described in any one of claims 1-9, and the data update system for the multi-chip, multi-level architecture of the inverter includes: A multi-chip multi-level architecture module is used to determine the chip control space based on the detection of the inverter's database, and to determine the multi-chip multi-level architecture of the inverter based on the chip control space and the structural form of the inverter. The data combination module is used to determine multiple sub-chip control nodes based on the identification of chip control paths in a multi-chip, multi-level architecture, and to determine the data combination of each sub-chip control node based on each sub-chip control node, the inverter's database, and the corresponding current operating status. The data update system module is used to determine the current data version of the sub-chip control node based on the sub-chip control node and the corresponding data combination; and to determine the data update system of each sub-chip control node based on the inverter's working process, the corresponding lithium battery data to be updated, and the current data version of each sub-chip control node. The data update progress module is used to determine the data update method of each sub-chip control node based on the data update paths of each sub-data in the data update system, the lithium battery data to be updated, and the node status of each sub-chip control node, and to mark the data update progress of each sub-chip control node. The dynamic maintenance event module is used to determine the autonomous update events of the multi-chip multi-level architecture based on the data update progress of each sub-chip management node and multiple working data of the inverter. It determines the abnormal update content based on the detection of autonomous update events, and determines the dynamic maintenance events of the multi-chip multi-level architecture based on the abnormal update content, the data update progress of each sub-chip management node and the current working status of the inverter.

Images