Modularized system for automatic registration and software design method

Abstract

The invention relates to the field of computer software development, and discloses an automatic registration modular system and a software design method.The method comprises the following steps that S1, functional attributes, resource demand attributes and operation dependency attributes of modules are collected; s2, establishing a constraint set for security decision according to the system state data and the external environment change information; s3, selecting a target action according to the system state and the candidate action set; s4, executing module registration and resource allocation according to the target action; s5, predicting the future operation reliability of the module based on the state data and historical records of the module; and S6, executing rollback processing when it is detected that the system state does not meet the preset condition. Each module only needs to complete respective independent functions, the system maintainability is good, due to the modular design, hardware circuits are relatively simple, the function is more single, troubleshooting and positioning are more accurate, the modules have the function of automatically registering IDs, the module interchangeability is enhanced, and the system debugging steps are simplified.

Description

Technical Field

[0001] This invention relates to the field of computer software development technology, specifically to an automatic registration modular system and software design method. Background Technology

[0002] Integrated hardware and software design is commonplace in most engineering applications. For a system, the advantages of integrated design are low hardware cost and simple structure; however, the disadvantages are also obvious: complex software design, poor versatility, and difficult product maintenance. Therefore, more and more developers are inclined towards modular design concepts, allowing independent modules to perform simple functions before system integration. Although modular design has the disadvantage of high design costs, its advantages such as simple software design, easy system maintenance, good portability, and high versatility have led to its increasing importance in engineering applications.

[0003] In related technologies, due to the lack of a unified automatic module identification and registration mechanism, each functional module needs to manually configure parameters, manually assign IDs, or rely on a fixed hardware interface order when accessing the system. This results in a cumbersome system debugging process, poor module interchangeability, and difficulty in error localization, thereby affecting the system's maintenance efficiency and scalability. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides an automatic registration modular system and software design method, which solves the problems of cumbersome system debugging process, poor module interchangeability, and difficulty in error localization, thereby affecting the system's maintenance efficiency and scalability.

[0005] To achieve the above objectives, the present invention provides the following technical solution: a modular software design method for automatic registration, comprising the following steps: S1. Before deploying the control module, collect the module's functional attributes, resource requirement attributes, and runtime dependency attributes, and construct a module description vector based on these attributes to describe the module. S2. Establish a set of constraints for safety decision-making based on system status data and external environment change information, and determine a candidate set of executable actions based on this set of constraints; S3. Invoke the reinforcement learning strategy and select the target action based on the system state and the candidate action set; S4. Execute module registration and resource allocation based on the target action; S5. Based on the module's status data and historical records, predict its future operational reliability and set the redundancy quantity according to the prediction results; S6. When the system state is detected to be not in accordance with the preset conditions, a rollback process is performed to restore the system to a runnable state.

[0006] Preferably, step S1 includes the following steps: The attribute collection module acquires functional attributes, resource requirement attributes, and dependency attributes. The above attributes are encoded and then concatenated in a preset order; The concatenated vector is used as the module description vector to represent the module in subsequent steps; The control module includes a central processing unit, an input unit, an output unit, and a control display unit. Each unit is hardware-independent and software-independent, allowing for modular design. When any input or output unit module in the system fails and needs to be replaced, the newly replaced module automatically registers its ID. Each unit has at least two communication interfaces, namely CAN bus and UART serial port. Data is exchanged between units via CAN bus, and the system can communicate with external devices via UART serial port or CAN bus.

[0007] Further technical features based on the above: Preferably, S2 includes the following steps: It is widely used in embedded system design, uses general software design methods, and can realize multi-module control. In this case, through general data structures and communication protocols, the nature of the modules can be distinguished and identified, so as to realize system control and data exchange.

[0008] Define constraints to characterize resource consumption, security limits, and dependencies; Analyze information on changes in the external environment to determine the extent to which constraints can be met; Actions that satisfy all constraints are included in the candidate action set.

[0009] Preferably, the determination of candidate actions includes: Calculate the resource usage for each action and determine whether the usage is within a safe range; Analyze the changes in dependency structure caused by each action and determine whether they conform to dependency rules; The safety parameters caused by each action are checked, and it is determined whether the change is within the allowable range.

[0010] Preferably, step S3 includes the following steps: Calculate the pre-evaluation value of the action based on the current state of the system; The candidate actions are sorted according to their pre-evaluation values; The target action is selected from the ranking results based on the reinforcement learning policy function, which is used to guide the module registration operation.

[0011] Preferably, the action pre-evaluation value is composed of multiple target indicators, including resource utilization, operational stability, reliability, and load balancing. The target indicators are weighted according to preset weights to obtain the action pre-evaluation value.

[0012] Preferably, step S5 includes the following steps: A predictive model for predicting future state changes is built based on the module's operational status data. The probability of future module anomalies is determined based on the reliability probability value output by the prediction model. The number of redundant instances is determined based on this reliability probability value to ensure the availability of the module.

[0013] Preferably, determining the number of redundant instances includes: Set cost parameters that represent resource costs and reliability parameters that represent reliability requirements; The redundancy compensation amount is calculated based on the difference between the reliability probability value and the reliability parameter. The final number of redundant instances is determined based on the result of matching the redundancy compensation amount with the resource cost parameters.

[0014] Preferably, step S6 includes the following steps: The status of the module after registration and resource configuration is checked. If the status data does not meet the preset conditions, a rollback operation is triggered. Search for reversible operations in the historical operation sequence, and select the target rollback operation based on the principle of minimizing rollback cost; Perform the target rollback operation to restore the system to a runnable state and re-enter the action decision process.

[0015] A modular system for automatic registration, the system comprising: The module vector building module is used to collect module attributes and construct module description vectors; The constraint set construction module is used to build constraint sets and determine candidate action sets based on system state and external environment information. The reinforcement learning decision-making module is used to select the target action from the set of candidate actions; The registration and allocation module is used to perform module registration and resource allocation. The fault prediction module is used to predict the operational reliability of the module and determine the number of redundant instances based on status data. The redundancy configuration module is used to deploy redundant instances; The rollback processing module is used to perform rollback processing when the state is detected to be not in accordance with preset conditions.

[0016] This invention provides a modular system and software design method for automatic registration. It has the following beneficial effects: 1. The software design of this invention is simple. Each module only needs to complete its own independent function, which makes the system maintainable. Due to the modular design, the hardware circuit is relatively simple, the function is more singular, and the troubleshooting and location of problems are more accurate. The function of automatic module ID registration enhances the interchangeability of modules and simplifies the system debugging process.

[0017] 2. This invention has good portability and high versatility. The design of the general data structure and communication protocol can be applied to various control systems to realize multi-module control. The modular design is conducive to the formation of standardized shelf products, reducing the design cycle and improving product development efficiency.

[0018] 3. This invention achieves the decoupling and automatic replacement identification of module hardware and software by constructing a unified module description vector and an automatic registration mechanism based on CANID, thereby realizing the effects of plug-and-play modules, reducing manual configuration costs, and improving system maintenance efficiency.

[0019] 4. This invention achieves the effect of making optimal module registration and resource allocation decisions in complex environments and significantly improving the system's adaptability and operating efficiency by establishing a multi-dimensional constraint set including resources, security, and dependencies, and by using a reinforcement learning strategy to select the optimal target action from candidate actions. Attached Figure Description

[0020] Figure 1 This is a schematic diagram of the control module logic of the present invention; Figure 2 This is a flowchart illustrating the automatic registration function logic of the present invention. Figure 3 This is a flowchart of the method of the present invention; Figure 4 This is a system architecture diagram of the present invention. Detailed Implementation

[0021] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. Example

[0022] Please see the appendix Figure 1 -Appendix Figure 3 This invention provides a modular software design method for automatic registration, comprising the following steps: S1. Before deploying the control module, collect the module's functional attributes, resource requirement attributes, and runtime dependency attributes, and construct a module description vector based on these attributes to describe the module. S1 includes the following steps: The attribute collection module acquires functional attributes, resource requirement attributes, and dependency attributes. The above attributes are encoded and then concatenated in a preset order; The concatenated vector is used as the module description vector to represent the module in subsequent steps; The control module includes a central processing unit (CPU), an input unit (DIU), an output unit (DOU), and a control display unit (CDU). Each unit is hardware-independent and software-independent, allowing for modular design. When any input unit (DIU) or output unit (DOU) module in the system fails and needs to be replaced, the newly replaced module automatically registers its ID. Each unit has at least two communication interfaces, namely CAN bus and UART serial port. Data is exchanged between units via CAN bus, and the system can communicate with external devices via UART serial port or CAN bus.

[0023] Specifically, a state deviation is set based on the deviation between the system's operating state and the target state. The state deviation measures the difference between the current state and the target state. To accurately control the stability and response speed of the system, the state deviation is calculated using the following formula: ; Let k be the state deviation at time k; Let k be the current state of the system at time k; The target state of the system is the state deviation, which reflects the error between the current state and the target state. Therefore, the control strategy should be based on this error, flexibly adjusting the system's behavior to make it as close as possible to the predetermined target. The control input cost is set according to the impact of changes in control input on system performance. The control input cost is a metric used to quantify changes in control input, avoiding unnecessary fluctuations or excessive adjustments during the control process. It is typically adjusted using weighted coefficients. The control input cost is defined as follows: ; in: The change in control input between time k and time k-1; The control input at time k; The weighting coefficients determine the cost of controlling the changes in the input. To define the control input cost, which represents the cost of changes in the control input, we can limit drastic changes in the system's control input, thereby avoiding excessive oscillations or unstable behavior. Then, based on changes in the system state, we set a state change cost, which quantifies the impact of system state changes on the target performance, particularly the rate of state change. This cost is defined as: ; in: Let be the rate of change of the system state, where For time intervals; The weighting coefficient represents the cost of controlling state changes.

[0024] This refers to the cost of state changes, reflecting the impact of state changes on system performance. Larger state changes lead to higher costs. The cost can be adjusted by adjusting the weighting coefficients. It can control the system's sensitivity to changes in state, thereby affecting the system's dynamic response; The target value for updating the control input is obtained by weighted summing of the state deviation, control input cost, and state change cost. This target value is the core indicator determining the optimal update of the control input, and its formula is as follows: ; in: The target value is used to update the control input; These are weighting coefficients used to balance the effects of state change costs, control input costs, and state deviations. The cost of state change; To control the input cost; As the state deviation, by using a weighted summation method, the influence of various factors on the target quantity can be comprehensively considered, thereby better balancing the system's stability, response speed, energy consumption constraints and other requirements in the control strategy; System structure principle as follows Figure 1 The DIU module collects input signal data from the device, and the CDU module collects control information from the operation panel. These data are then uploaded to the CPU module via the CAN bus. After data and logic processing, the CPU module sends output control data to the DOU module for control signal output and status information to the CDU module for display via the CAN bus. Simultaneously, based on different communication interfaces with external devices, the system status information is sent to the external devices to achieve system control and output.

[0025] In engineering control systems, there are often situations where there are many input and output ports for equipment, and a lot of data needs to be displayed and controlled. This often requires multiple DIU, DOU, and CDU modules, making it particularly important to design a universal data structure and communication protocol.

[0026] The software-defined data structure is as follows: enum { CANID_DIRECTION_OUT = 0, CANID_DIRECTION_IN = 1, CANID_DIRECTION_SET = 2, CANID_POS_LOCAL = 0, CANID_POS_REMOTE_CTRL1 = 1, CANID_POS_REMOTE_CTRL2 = 2, CANID_POS_REMOTE_CTRL3 = 3, ......... CANID_TYPE_CDU = 1, CANID_TYPE_DIU = 2, CANID_TYPE_DOU = 3 }; typedef union _canid { uint32_t u32Data; struct { uint8_t index; uint8_t type; uint8_t pos; uint8_t direction; }; CANID; typedef union _datainfo { uint32_t u32Data; uint8_t u8Data[4]; struct { uint32_t datal:1; uint32_t data2:1; uint32_t data3:1; ........ uint32_t data32:1; }; }DATA_INFO; typedef struct _caninfo { uint8_t ide; uint8_t dlc; CANID id; DATA_INFO data; }CAN_INFO; The CANID data definition is clearly defined using enumeration types. Utilizing the CAN bus data format, CANID is defined as an extended frame. In the CANID data structure, `index` is the module serial number, `type` is the device type, `pos` is the device location (local control unit / remote control unit), and `direction` is the data direction (input / output, here referring to the CPU module; `CANID_DIRECTION_SET` is defined as a registration parameter). For example, if the system has 2 DIU modules, 3 DOU modules, and 4 CDU modules in the local control box, then the CANID of the second DIU module is 0x01000202, the CANID of the first DOU module is 0x00000301, the CANID of the input control information of the third CDU module is 0x01000103, the CANID of the output status information of the third CDU module is 0x00000103, and so on. On the same CAN bus, the nature of each data item can be easily distinguished and identified through the CANID. The pos can be expanded according to the actual situation of the system; if there are other control modules, the type definition can also be expanded. Such a model can encompass almost all control systems, realizing the high versatility of the system.

[0027] See the logic flow of the DIU / DOU module automatic registration function. Figure 2 In the initial state, set the CANID of the replacement module to index=0, and define other parameters according to the actual situation. That is, the type of module is distinguished first, and the parameter we need to automatically register is the module serial number index.

[0028] Taking the local control unit as an example, the total number of DIU modules in the system is defined as NUM_DIU=4, and the DIU module count variable countDIU=0; the total number of DOU modules is defined as NUM_DOU=3, and the DOU module count variable countDOU=0; the automatic registration time is defined as REGISTER_TIME=5 (seconds), and the timing parameter r_time=0. After the system powers on, each module actively uploads data on the CAN bus (CANID is set to zero by default according to the protocol). The CPU module receives the CAN data from all modules in the interrupt service function and identifies the index value in the CANID. If CANID 0x01000201 is received, it indicates that the first DIU block is known, and countDIU|=1<<0, i.e., the first bit (bit0) is set to 1; if CANID 0x01000202 is received, it indicates that the second DIU block is known, and countDIU|=1<<1, i.e., the second bit (bit1) is set to 1; if CANID 0x00000301 is received, it indicates that the first DOU block is known, and countDOU|=1<<0, i.e., the first bit (bit0) is set to 1; if CANID 0x00000303 is received, it indicates that the third DIU block is known, and countDOU|=1<<2, i.e., the third bit (bit2) is set to 1; and so on. After the automatic registration time REGISTER_TIME expires, the values ​​of countDIU and countDOU are checked bit by bit, and the data with a bit value of zero is the module to be replaced.

[0029] For example, if countDIU=0x7, it indicates that the fourth DIU module is a replacement module. Assume the CPU module sends the setting parameter CANID canSet on the CAN bus; then... canSet.direction = CANID_DIRECTION_SET; canSet.pos = CANID_POS_LOCAL; canSet.type = CANID_TYPE_DIU; canSet.index = 4; That is, when `canSet.u32Data = 0x02000204`, the replaced DIU module receives the data with CANID 0x02000204, modifies its own index to 4, and saves the index value in FLASH. Afterwards, its transmitted CANID changes from 0x01000200 to 0x01000204. This method is only suitable for automatic registration of a single replacement of the same type of module.

[0030] In the CAN_INFO data structure, ide is the CANID type, dlc is the CAN data length, CANID is the CANID value, and DATA_INFO is the CAN communication data.

[0031] DATA_INFO defines a general union type data, which can use four bytes, one byte, and bits to represent different data information, and implement different functions such as data processing and logical judgment.

[0032] The device input signal data acquired by the DIU module can be defined using the DATA_INFO structure, i.e.: DATA_INFO DiuData; The control signal output data of the DOU module can be defined using the DATA_INFO structure, that is: DATA_INFO DouData; The panel control data acquired by the CDU module can be defined using the DATA_INFO structure, i.e.: DATA_INFO CduCtrlData; The system status data of the CDU module can be defined using the DATA_INFO structure, that is: DATA_INFO CduStatusData; Depending on the system requirements, DATA_INFO can be expanded into an 8-byte data structure or reduced to a 2-byte data structure, i.e.: typedef union _datainfo | typedef union _datainfo { | { uint64_t u64Data; | uint16_t u16Data; uint8_t u8Data[8]; | uint8_t u8Data[2]; struct | struct { | { uint64_t datal:1; | uint16_t datal:1; uint64_t data2:1; | uint16_t data2:1; uint64_t data3:1; | uint16_t data3:1; ........ | ........ uint64_t data64:1; | uint16_t datal6:1; }; |}; }DATA_INFO; |}DATA_INFO; Based on this software architecture design, the hardware and software of the DIU, DOU, and CDU modules are solidified, making them universal and interchangeable for different systems, and enabling them to form standardized off-the-shelf products. Developers only need to modify the data processing and logic processing code of the CPU module to implement the control functions of different systems. This simplifies the design process, shortens the product development cycle, and enhances the overall maintainability of the system.

[0033] S2. Establish a set of constraints for safety decision-making based on system status data and external environment change information, and determine a candidate set of executable actions based on this set of constraints; S2 includes the following steps: Define constraints to characterize resource consumption, security limits, and dependencies; Analyze information on changes in the external environment to determine the extent to which constraints can be met; Actions that satisfy all constraints are included in the candidate action set.

[0034] Specifically, constraints are defined to characterize resource consumption, security limitations, and dependencies. Resource consumption constraints describe the resource requirements of each module in the system, mainly including the consumption of resources such as CPU, memory, bandwidth, and storage. Security limitations define the security boundaries of the system during operation, and dependency constraints specify the interdependencies between modules or services, ensuring that collaboration between modules does not violate preset service level agreements or dependency requirements. These constraints are characterized by defining appropriate mathematical models and logical constraints, and security limitations are implemented through access control rules. Based on information about changes in the external environment, an analysis is conducted to determine the extent to which constraints can be met. These changes include, but are not limited to, fluctuations in electricity prices, load demand, and network bandwidth. These changes may affect the allocation of system resources or security requirements. By monitoring external environmental information in real time and comparing it with the system's constraints, it is determined which constraints can be met under the current environmental conditions. Finally, actions that satisfy all constraints are included in the candidate action set. Actions refer to operations that the system can perform, including resource scheduling, load allocation, service startup and shutdown, etc. Each action must be performed under the premise of satisfying resource consumption, security restrictions, and dependencies. By including actions that meet all constraints in the candidate set, the system can select the optimal execution strategy to optimize performance, save costs, and ensure security. Ultimately, these candidate actions will be further evaluated to select the strategy most suitable for the current environment and constraints. Through the above process, the system can adapt to changes in the external environment in real time, optimize resource usage and task scheduling while ensuring that constraints are met, and ensure the efficient and secure operation of the system under multiple constraints.

[0035] S3. Invoke the reinforcement learning strategy and select the target action based on the system state and the candidate action set; The determination of candidate actions includes: Calculate the resource usage for each action and determine whether the usage is within a safe range; Analyze the changes in dependency structure caused by each action and determine whether they conform to dependency rules; The safety parameters caused by each action are checked, and it is determined whether the change is within the allowable range.

[0036] Specifically, the resource usage for each action is calculated, and it is determined whether the resource usage is within a safe range. Resource usage includes indicators such as CPU usage, memory usage, bandwidth usage, and storage usage. Based on the execution characteristics of the action, the resulting resource consumption is estimated and recorded as follows: ; in, Indicates action Resource usage at the current moment, The resource evaluation function is used to estimate the consumption of resources such as CPU, memory, bandwidth, and storage during the execution of an action. The estimation result must meet the preset resource safety constraint range. ; in, This is the minimum resource consumption threshold used to ensure that the system has at least a minimum operating capacity. This is the maximum allowed resource usage threshold, used to prevent actions from consuming too many resources, which could lead to system congestion or performance degradation. and These represent the minimum and maximum allowed resource ranges, respectively. When the resources required for an action exceed the safe range, the action will be directly excluded to ensure that the system does not experience performance degradation or resource contention due to excessive resource consumption. The dependency structure changes caused by each action are analyzed, and their compliance with dependency rules is determined. Action execution may alter the dependencies between modules within the system; for example, starting a new module adds dependency paths, while pausing a task reduces dependency chains. The current dependency graph is constructed and denoted as... The dependency graph after the action is executed is noted as follows: ; in, This is a dependency structure update function. It is used to simulate the impact of actions on dependency chains, such as adding dependencies, removing dependencies, or adjusting dependency direction. The dependency graph is generated after the action is executed, and it is satisfied that: ; in: This is the set of allowed dependency structures, typically used to prevent circular dependencies, disrupt critical links, or violate mandatory dependency policies. If an action causes a dependency structure to enter an illegal state, that action is not included in the candidate action set. The system verifies the changes in security parameters caused by each action and determines whether the changes are within the acceptable security range. The system then processes the actions... The resulting changes in safety parameters are calculated using the following formula: ; in: For action At any moment The resulting change in safety parameters; This is a security assessment function used to analyze the impact of actions on access control levels, encryption levels, network isolation levels, or data risk indicators. The calculated security change must meet the security tolerance range. ; in: The minimum permissible values ​​for safety parameters are set to ensure that actions do not reduce system safety to an unacceptable level. This is the maximum permissible value for safety parameters, used to prevent actions from increasing sensitivity or exposing risks beyond the system's capacity. If the safety change exceeds this range, the action is considered unsafe and discarded. Through the three steps of resource verification, dependency legality analysis, and safety check, the system can comprehensively judge each candidate action and only include actions that simultaneously meet all constraints into the final candidate action set. This ensures that the system has feasibility, safety, and structural consistency when selecting execution strategies, thereby improving the overall efficiency and reliability of operation.

[0037] S3 includes the following steps: Calculate the pre-evaluation value of the action based on the current state of the system; The candidate actions are sorted according to their pre-evaluation values; The target action is selected from the ranking results based on the reinforcement learning policy function, which is used to guide the module registration operation.

[0038] Specifically, a pre-evaluation value is calculated for each candidate action based on the current system state. This pre-evaluation value measures the action's potential contribution to system performance. Taking into account the influencing factors of the current state, the formula for calculating the pre-evaluation value is: ; in: For action At any moment The preliminary assessment value; This is a pre-evaluation function used to evaluate the current state of the system. The benefits or costs of each candidate action are calculated. This pre-evaluation value can be based on a combination of factors, such as resource consumption, performance improvement, security risks, and load distribution. The goal of this process is to assign a quantified evaluation value to each action for subsequent ranking and selection. All candidate actions are ranked according to their pre-evaluation values. The purpose of this ranking is to prioritize the candidate actions based on their pre-evaluation values, ensuring that the action with the best benefits is selected. The ranking process is as follows: ; in: sorted For action sets The actions are sorted according to their pre-evaluation values; sort(·) represents a sorting operation, which sorts the candidate actions from highest to lowest pre-evaluation value; The ranking result yields a sequence of actions from best to worst. The system uses this sequence to guide subsequent action selection, choosing target actions from the ranking based on a reinforcement learning policy function to guide module registration. The reinforcement learning policy function determines the optimal execution strategy by selecting from the ranked candidate actions. This policy function is typically a decision function with exploration and exploitation mechanisms, such as an ε-greedy policy or a value-based policy. The process of selecting a target action can be represented as: ; in: For the selected target action; A reinforcement learning policy function is used to select the optimal action from the ranked action set. This function selects the most suitable action from the ranking results based on the current learning strategy and exploration needs. Through these steps, the system can accurately evaluate and rank candidate actions according to the current state, and then use the reinforcement learning policy function to select the most suitable target action to guide the module registration operation. This process enables the system to continuously learn and optimize decisions while performing tasks, improving the system's adaptability and overall performance in changing environments.

[0039] S4. Execute module registration and resource allocation based on the target action; The action pre-evaluation value consists of multiple target indicators, including resource utilization, operational stability, reliability, and load balancing. The target indicators are weighted according to preset weights to obtain the action pre-evaluation value.

[0040] Specifically, based on the current state of the system, multi-objective indicators for each candidate action are quantitatively calculated to obtain four core indicators constituting the pre-evaluation value. These multi-objective indicators include resource utilization, operational stability, reliability, and load balancing. The system then evaluates the actions... At any moment The resulting change in safety parameters is calculated and expressed as: ; in: action The resulting resource utilization indicators are used to reflect the rationality of resource use after the action is executed; The operational stability index is used to measure the impact of actions on system fluctuations, jitter, or state transitions. Reliability level indicators are used to reflect the risk of system failure, error, or inconsistency when performing this action; Load balancing metrics are used to reflect the degree of improvement in the load distribution balance of internal system resources or modules after an action is executed.

[0041] The above indicators are all standardized quantitative values ​​used for weighted calculation. The target indicators are weighted according to preset weights to form the final pre-evaluation value of the action. The calculation method of the pre-evaluation value is as follows: ; in: action The pre-evaluation value is used to measure the overall quality of the action; The weighting coefficients for resource utilization, operational stability, reliability, and load balancing are corresponding to meet the requirements. Each weight is used to adjust the degree of influence of different indicators on the comprehensive evaluation result, and can be preset or dynamically updated according to the system strategy requirements; The pre-evaluation values ​​of actions obtained through the weighted calculation described above serve as the basic input for ranking and action selection in reinforcement learning policies. Higher pre-evaluation values ​​indicate that the action performs better overall in the current state, providing clear quantitative basis for subsequent decisions. In this way, the system can achieve more reasonable candidate action evaluation under the combined influence of multiple objective factors, providing stable and unified input features for the reinforcement learning policy function, making the policy optimization process more efficient and easier to converge.

[0042] S5. Based on the module's status data and historical records, predict its future operational reliability and set the redundancy quantity according to the prediction results; S5 includes the following steps: A predictive model for predicting future state changes is built based on the module's operational status data. The probability of future module anomalies is determined based on the reliability probability value output by the prediction model. The number of redundant instances is determined based on this reliability probability value to ensure the availability of the module.

[0043] Specifically, a predictive model is built based on the module's operational status data to predict future state changes. During operation, the system collects various status data of the modules in real time, including but not limited to CPU load, memory usage, response latency, error rate, and call chain information. These historical state sequences are represented as follows: ; in: For a moment The module state vectors are used to train the future state prediction model on the historical sequence using a prediction function: ; in, For predicted future moments Module status; It is a state prediction model used to extract state evolution trends, such as prediction processes based on sequence analysis, statistical modeling, or machine learning.

[0044] The system determines the probability of future module anomalies based on the reliability probability value output by the prediction model. It compares the predicted future state with an anomaly detection threshold to calculate the probability of module failure or anomaly within a future time window. The anomaly probability calculation is as follows: ; in: This represents the probability of future anomalies occurring. This is a reliability assessment function used to determine whether risks such as performance degradation, resource exhaustion, latency anomalies, or error rate spikes may occur based on predicted conditions. The reliability probability value is... : ; in: The probability that the module will remain in a normal state in the future, i.e., the reliability probability value, when An increase in the reliability probability value indicates a higher risk of future module failures. Finally, the number of redundant instances is determined based on this reliability probability value to ensure module availability. The system adjusts the required number of redundant instances for the module according to the availability target based on the current reliability prediction results. The number of redundant instances can be determined using the following formula: ; in: The number of redundant instances required to be enabled; The module availability target is preset for the system; This is a redundancy allocation function used to dynamically determine the amount of redundancy based on reliability probability and availability requirements. A typical form can be expressed as: ; in: This indicates rounding up to the nearest integer to ensure that the number of redundant instances meets the target availability. This is used to indicate the number of redundant instances that need to be added based on the existing primary instance. Through the above mechanism, when the reliability probability given by the prediction model decreases, the system will automatically increase the number of redundant instances to improve the future availability of the system; conversely, when the reliability is high, the system can reduce redundant deployments to save resources.

[0045] Determining the number of redundant instances includes: Set cost parameters that represent resource costs and reliability parameters that represent reliability requirements; The redundancy compensation amount is calculated based on the difference between the reliability probability value and the reliability parameter. The final number of redundant instances is determined based on the result of matching the redundancy compensation amount with the resource cost parameters.

[0046] Specifically, the system sets cost parameters to measure resource consumption and reliability parameters to describe system reliability requirements. Resource cost parameters reflect the resource overhead required to create or maintain a redundant instance, including computing resources, storage resources, scheduling costs, etc.; reliability parameters represent the reliability goals that the system hopes to achieve in future operation. Based on the future reliability probability value obtained from the previous steps, it is compared with the preset reliability parameters. The comparison result determines whether there is a reliability gap, and the redundancy compensation amount is calculated accordingly. If the predicted reliability is lower than the target value, it indicates that there is a risk gap, and redundant instances need to be added accordingly to compensate. If the predicted reliability has met or exceeded the target requirements, no compensation is needed. Through this difference analysis, the system can determine the degree of redundancy compensation required to maintain reliability. Based on the obtained redundancy compensation amount and combined with resource cost parameters, the system determines the final number of redundant instances that can be deployed. The system determines the actual number of redundancies that can be invested based on the matching relationship between resource budget, compensation requirements, and cost constraints. The system ultimately determines the number of deployable redundancies, thereby ensuring reliability while taking into account resource utilization efficiency.

[0047] S6. When the system state is detected to be not in accordance with the preset conditions, a rollback process is performed to restore the system to a runnable state.

[0048] S6 includes the following steps: The status of the module after registration and resource configuration is checked. If the status data does not meet the preset conditions, a rollback operation is triggered. Search for reversible operations in the historical operation sequence, and select the target rollback operation based on the principle of minimizing rollback cost; Perform the target rollback operation to restore the system to a runnable state and re-enter the action decision process.

[0049] Specifically, the system status is checked after module registration and resource configuration. After completing module registration, resource allocation, or dependency adjustment, the system verifies the current status based on preset system operating conditions. The current status is denoted as: ; in: The system state before the action is executed; Actions that have already been performed; This refers to the system state after the action is executed. This is a system state update function used to record data such as resource status, load status, and dependency structure changes after module registration. Subsequently, the updated state is compared with a set of preset conditions. Perform a match: If the conditions are met, continue with the normal process; in, This is a set of states used to describe the requirements for normal operation, including resource range, dependency validity, security level, load threshold, etc.

[0050] If not satisfied: If the status is abnormal, a rollback process needs to be triggered immediately.

[0051] The system searches for reversible operations in the historical operation sequence and selects the target rollback operation based on the principle of minimizing rollback cost. The historical sequence of system maintenance actions is as follows: ; in: Create a set for executable rollbacks; For action The inverse operations, such as unregistering modules, releasing resources, and restoring dependency structures, are considered. To avoid additional resource loss or system instability, a rollback cost is calculated for each reversible action: ; in: This is the rollback cost function, used to measure the impact of reversing an action on system performance, resources, and dependency consistency. The cost evaluation function is used to evaluate the impact of performing reversible actions on performance, resource consumption, and system stability. The lower the cost, the safer and more efficient the rollback action is.

[0052] Finally, based on the principle of cost minimization, the target rollback operation is selected: ; in, The final selected and actually executed rollback operation.

[0053] Execute the selected rollback action to restore the system to a runnable state and re-enter the action decision process. Rollback execution can be represented as: ; in: The system state after rollback; The rollback handling function is used to restore resource configuration, undo module changes, and adjust load and dependencies based on the target rollback operation. The system then verifies the restored state. ; If the preset conditions are met, the system returns to the action decision-making process and continues to run; if the conditions are still not met, it continues to select the next minimum cost rollback action from the set of reversible actions until it returns to a runnable state.

[0054] Please see the appendix Figure 4 A modular system for automatic registration, comprising: The module vector building module is used to collect module attributes and construct module description vectors; The constraint set construction module is used to build constraint sets and determine candidate action sets based on system state and external environment information. The reinforcement learning decision-making module is used to select the target action from the set of candidate actions; The registration and allocation module is used to perform module registration and resource allocation. The fault prediction module is used to predict the operational reliability of the module and determine the number of redundant instances based on status data. The redundancy configuration module is used to deploy redundant instances; The rollback processing module is used to perform rollback processing when the state is detected to be not in accordance with preset conditions.

[0055] Specifically, firstly, the module vector construction module collects information on module functions, dependencies, resource requirements, and operating environment, and generates module description vectors to uniformly represent module attributes. Secondly, the constraint set construction module establishes a constraint set based on system state, resource status, dependency structure, and external environment, and selects a set of candidate actions that meet the conditions. Thirdly, the reinforcement learning decision module selects the optimal target action from the candidate actions based on the benefit evaluation of system state and candidate actions, which guides module registration and allocation. The registration and allocation module executes the target action, completing module registration, resource allocation, dependency adjustment, and operating environment preparation, so that the module is incorporated into the system execution process. The fault prediction module predicts the future reliability of the module based on the operating status data and determines whether there is insufficient reliability, thereby determining the number of redundant instances to be deployed. The redundancy configuration module deploys redundant instances according to the redundancy number result and completes resource preparation and scheduling access to enhance system fault tolerance and availability. When the rollback processing module finds that the system state after registration or configuration does not meet the preset conditions, it matches reversible operations based on historical operation records, selects the action with the lowest rollback cost and executes the rollback, so that the system is restored to a runnable state and re-enters the decision-making process.

[0056] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A modular software design method for automatic registration, characterized in that, Includes the following steps: S1. Before deploying the control module, collect the module's functional attributes, resource requirement attributes, and runtime dependency attributes, and construct a module description vector based on these attributes to describe the module. S2. Establish a set of constraints for safety decision-making based on system status data and external environment change information, and determine a candidate set of executable actions based on this set of constraints; S3. Invoke the reinforcement learning strategy and select the target action based on the system state and the candidate action set; S4. Execute module registration and resource allocation based on the target action; S5. Based on the module's status data and historical records, predict its future operational reliability and set the redundancy quantity according to the prediction results; S6. When the system state is detected to be not in accordance with the preset conditions, a rollback process is performed to restore the system to a runnable state.

2. The modular software design method for automatic registration according to claim 1, characterized in that: S1 includes the following steps: The attribute collection module acquires functional attributes, resource requirement attributes, and dependency attributes. The above attributes are encoded and then concatenated in a preset order; The concatenated vector is used as the module description vector to represent the module in subsequent steps; The control module includes a central processing unit, an input unit, an output unit, and a control display unit. Each unit is hardware-independent and software-independent, allowing for modular design. When any input or output unit module in the system fails and needs to be replaced, the newly replaced module automatically registers its ID. Each unit has at least two communication interfaces, namely CAN bus and UART serial port. Data is exchanged between units via CAN bus, and the system can communicate with external devices via UART serial port or CAN bus.

3. The modular software design method for automatic registration according to claim 1, characterized in that: S2 includes the following steps: Define constraints to characterize resource consumption, security limits, and dependencies; Analyze information on changes in the external environment to determine the extent to which constraints can be met; Actions that satisfy all constraints are included in the candidate action set.

4. The modular software design method for automatic registration according to claim 3, characterized in that: The determination of candidate actions includes: Calculate the resource usage for each action and determine whether the usage is within a safe range; Analyze the changes in dependency structure caused by each action and determine whether they conform to dependency rules; The safety parameters caused by each action are checked, and it is determined whether the change is within the allowable range.

5. The modular software design method for automatic registration according to claim 1, characterized in that: S3 includes the following steps: Calculate the pre-evaluation value of the action based on the current state of the system; The candidate actions are sorted according to their pre-evaluation values; The target action is selected from the ranking results based on the reinforcement learning policy function, which is used to guide the module registration operation.

6. The modular software design method for automatic registration according to claim 5, characterized in that: The action pre-evaluation value consists of multiple target indicators, including resource utilization, operational stability, reliability, and load balancing. The target indicators are weighted according to preset weights to obtain the action pre-evaluation value.

7. The modular software design method for automatic registration according to claim 1, characterized in that: S5 includes the following steps: A predictive model for predicting future state changes is built based on the module's operational status data. The probability of future module anomalies is determined based on the reliability probability value output by the prediction model. The number of redundant instances is determined based on this reliability probability value to ensure the availability of the module.

8. The modular software design method for automatic registration according to claim 7, characterized in that: Determining the number of redundant instances includes: Set cost parameters that represent resource costs and reliability parameters that represent reliability requirements; The redundancy compensation amount is calculated based on the difference between the reliability probability value and the reliability parameter. The final number of redundant instances is determined based on the result of matching the redundancy compensation amount with the resource cost parameters.

9. The modular software design method for automatic registration according to claim 1, characterized in that: S6 includes the following steps: The status of the module after registration and resource configuration is checked. If the status data does not meet the preset conditions, a rollback operation is triggered. Search for reversible operations in the historical operation sequence, and select the target rollback operation based on the principle of minimizing rollback cost; Perform the target rollback operation to restore the system to a runnable state and re-enter the action decision process.

10. A modular system for automatic registration, applied to a modular software design method for automatic registration as described in any one of claims 1-9, characterized in that, The system includes: The module vector building module is used to collect module attributes and construct module description vectors; The constraint set construction module is used to build constraint sets and determine candidate action sets based on system state and external environment information. The reinforcement learning decision-making module is used to select the target action from the set of candidate actions; The registration and allocation module is used to perform module registration and resource allocation. The fault prediction module is used to predict the operational reliability of the module and determine the number of redundant instances based on status data. The redundancy configuration module is used to deploy redundant instances; The rollback processing module is used to perform rollback processing when the state is detected to be not in accordance with preset conditions.

Images