A Collaborative Design Method for Balcony Photovoltaic Supports Based on Federated Learning

Abstract

This invention relates to the field of federated learning, specifically to a collaborative design method for balcony photovoltaic (PV) brackets based on federated learning. This method involves multiple local design nodes converting balcony boundary dimensions, component specifications, installation restriction areas, and load constraints into local constraint tensors. A bracket parameter generation network and a feasibility discrimination network are trained locally. A feasible region sensitivity matrix is ​​established based on the local constraint tensors, and model updates are performed hierarchically using random masking, differential perturbation, interval encoding, and compressed uploading. The federated collaborative server calculates the feasible region overlap between nodes under secure aggregation conditions and, based on this, performs weighted aggregation of the globally generated model before distribution. Local nodes then combine hard constraints to output bracket design parameters. This method ensures that the original engineering data does not leave the local machine, reducing the risk of design data leakage and minimizing the output of infeasible parameters caused by the incorrect fusion of differentiated balcony constraints.

Description

Technical Field

[0001] This invention relates to the field of federated learning, and more specifically to a federated learning-based collaborative design method for balcony photovoltaic brackets in the area of ​​data confidentiality processing. Background Technology

[0002] Balcony photovoltaic (PV) bracket design is typically handled on a project-by-project basis. Designers or design software collect data such as balcony clearance dimensions, installable boundaries of the balustrade or wall, PV module specifications, module weight, allowable installation angle, fixing point layout restrictions, and local load design conditions. Then, bracket design parameters are generated based on preset rules or parametric templates. In conventional software implementations, the platform first abstracts the balcony boundary into a two-dimensional or three-dimensional constraint region, writes the module dimensions and arrangement into a fixed parameter table, and then determines the number of modules, boundary clearance, installation tilt angle, and candidate fixing points through rule matching. For the generated results, the platform typically uses static constraint verification to determine whether they exceed installation restrictions, meet module spacing requirements, and fall within preset load ranges. This type of solution relies on a centralized rule base and manually maintained templates, capable of handling balcony scenarios with clear rules and simple boundaries, but lacks adaptability to differentiated constraints arising from different buildings, facade limitations, and regional load conditions.

[0003] To improve the reusability of support structure design results, existing technologies include uploading historical engineering cases to a centralized design platform for model training. This approach typically involves each design node aggregating project dimensions, component specifications, installation constraints, historical feasible and infeasible solutions to a server. The server cleans, features, and labels the raw data before training a support structure parameter recommendation model or feasibility assessment model. After training, each node obtains recommended parameters by inputting balcony constraint information from a new project and performs subsequent verification locally. This method can utilize a large amount of historical data to form a unified model, but its training process requires centralized control of balcony geometric boundaries, installation restriction areas, load constraints, and project solution data. This data is directly related to specific building spaces and engineering conditions; centralized transmission and storage increase the risk of data manipulation, correlation, or leakage, making it difficult to meet the technical requirements for data security.

[0004] In situations where centralized data transmission is not feasible, federated learning can be used to allow multiple design nodes to retain original engineering data locally and participate in collaborative training by uploading model updates. Conventional federated learning typically involves each node training the same model based on local samples, then uploading gradients or model parameters to a server for secure aggregation. The server then uses average aggregation or weighted averaging to form a global model and distributes it. This approach reduces the outgoing transmission of raw data. However, in the collaborative design scenario of balcony photovoltaic supports, the local data of each node is not uniformly distributed. Different nodes have significant differences in balcony boundary morphology, installable area range, component arrangement restrictions, and load design conditions. Ordinary aggregation methods easily mix model updates with large constraints, causing the global model to learn fuzzy feasible domain boundaries. After receiving the global model, local nodes still need to make extensive corrections based on local hard constraints; otherwise, they may output support parameters that exceed installation boundaries or do not meet load constraints.

[0005] The main technical problem with existing federated learning-based collaborative training methods in balcony photovoltaic support design is that, without leaving the local nodes, the server struggles to understand the true differences between the feasible design domains of each node. Conventional secure aggregation also masks fine-grained information related to balcony boundaries, installation limitations, and load constraints during model updates, making it impossible for the global model to distinguish which model updates are suitable for co-aggregation and which should be isolated or have their weights reduced. If ordinary federated averaging is directly used, differential constraints may cancel each other out or be incorrectly merged in the parameter space, causing the installation angle, component spacing, boundary clearance, and fixed point distribution range output by the support parameter generation network to deviate from the local feasible range. The core issue arising from this is how to ensure the confidentiality of design data while allowing the federated training process to preserve the differences in feasible domains and form a support design model adapted to local constraints. Summary of the Invention

[0006] The purpose of this invention is to provide a collaborative design method for balcony photovoltaic brackets based on federated learning, which can solve the problems mentioned in the background art.

[0007] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0008] A collaborative design method for balcony photovoltaic brackets based on federated learning includes: Local balcony photovoltaic bracket design data are obtained from multiple local design nodes, and the balcony boundary dimensions, component specifications, installation restriction areas and load constraints are converted into local constraint tensors. Within the local design node, a scaffold parameter generation network and a feasibility discrimination network are trained to obtain a local model update. A feasible region sensitivity matrix is ​​established based on the local constraint tensor for updating the local model, and differentiated confidentiality processing is performed on the local model update according to the sensitivity level; The local model, after being encrypted, is updated and uploaded to the federated collaboration server. The federated collaboration server calculates the feasible domain overlap of each local design node under secure aggregation conditions, and aggregates the feasible domain overlap to form a global generated model. The method involves sending the global generated model to the local design node, which then combines the local design node with local hard constraints to output the design parameters for the balcony photovoltaic support.

[0009] Preferably, the formation of the local constraint tensor includes: The balcony installation boundary is discretized into a boundary occupancy sequence. The component length, width, mass, and allowable arrangement are encoded into a component constraint sequence. The installation restriction area is encoded into an unusable area mask. The wind load condition, snow load condition, and allowable range of support tilt angle are encoded into a constraint interval vector. The historical feasible design parameters and historical infeasible design parameters are mapped into positive sample labels and negative sample labels, respectively. The support parameter generation network uses the local constraint tensor as input to generate installation angle, component spacing, boundary avoidance amount, and fixed point distribution range. The feasibility discrimination network uses the generated results and the local constraint tensor as input to generate feasibility discrimination results.

[0010] Preferably, establishing the feasible region sensitivity matrix includes: Calculate the contribution of the local model update to the back-calculation error of balcony boundary dimensions, the back-calculation error of installation restriction area, the back-calculation error of load constraint interval, and the drift of design parameter output, and project the contribution values ​​onto the sensitivity coordinates corresponding to the model parameters; The local model update is divided into high-sensitivity update, constraint boundary update, and low-sensitivity update according to the sensitivity coordinates. The highly sensitive updates are subjected to random masking and differential perturbation, the constraint boundary updates are subjected to interval encoding and sign preservation processing, and the low-sensitivity updates are subjected to sparse compression and quantization processing before being uploaded.

[0011] Preferably, the federated collaboration server calculates the feasible domain overlap by: Extract the interval encoding of constraint boundary update, the direction vector of low-sensitivity update and the global common constraint sample response results from the local model update that has been confidentialized, and generate the node constraint similarity matrix without restoring the local balcony photovoltaic support design data. Based on the constraint similarity matrix between nodes, the aggregation weight of each local design node in different model branches is determined, and differentiated weighted aggregation is performed on the shared layer, constraint adaptation layer and output layer of the scaffold parameter generation network respectively.

[0012] Preferably, the construction of positive and negative sample labels includes: Within the local design node, constraint replay is performed on historical design parameters, and the balcony boundary occupancy status, component arrangement status, installation restriction zone crossing status, and load interval matching status corresponding to each historical design parameter are recorded as a constraint event sequence. Based on the constraint event sequence, feasible domain boundary samples, boundary-adjacent infeasible samples, and far-from-boundary infeasible samples are generated, and a constraint violation direction identifier is attached to each type of sample. During local training, the feasibility discrimination network learns both the feasibility discrimination result and the direction identifier, so that the training samples of the scaffold parameter generation network contain a hierarchical representation of the feasible region interior, feasible region boundary, and infeasible region.

[0013] Preferably, performing random masking and differential perturbation on the highly sensitive update includes: Within the local design node, a mask strength sequence is generated based on the sensitivity coordinates. Model parameters strongly correlated with balcony boundary dimensions and installation restriction areas are updated and assigned to the first mask group, and model parameters strongly correlated with load constraint intervals are updated and assigned to the second mask group. Additive masks generated by different random seeds are applied to the first mask group and the second mask group respectively, and the differential perturbation amplitude is constrained according to the loss reduction amount of this round of training. Before uploading, perform a direction consistency check on the updated content after the disturbance, and only retain the update component that is consistent with the direction of the decrease in local feasibility loss.

[0014] Preferably, the differentiated weighted aggregation includes: The model update of the shared layer is based on the safe aggregate average value of all local design nodes; The model update of the constraint adaptation layer is performed by subdomain aggregation according to the adjacency weight formed by the feasible domain overlap, and the corresponding subdomain adaptation parameters are saved for each local design node. The model updates of the output layer are filtered and aggregated according to the compliance of the violation direction of the common constraint sample response results; When there are constraint conflicts in the update direction of nodes corresponding to the same output dimension, aggregate compatible updates only within the same constraint subdomain and retain the conflict isolation marker.

[0015] Preferably, the generation of the constraint event sequence further includes: Local simulation verification was performed on the same historical design parameters under balcony boundary conditions and component arrangement conditions after multiple disturbances to obtain the corresponding boundary migration trajectory. The correspondence between the output dimension of the scaffold parameter generation network and the constraint violation direction is determined based on the boundary migration trajectory, and the correspondence is written into the constraint attention weights of the local training samples; When training the support parameter generation network, the constraint attention weights are used to limit the gradient sources of different output dimensions, so that the installation angle, component spacing, boundary avoidance amount and fixed point distribution interval correspond to their respective constraint event branches.

[0016] Preferably, the direction consistency check includes: Within the local design node, a local verification set that is not uploaded is set up. The model before and after the disturbance are applied to the local verification set to obtain the changing directions of the installation boundary violation rate, load interval violation rate, and component arrangement violation rate. The direction of change is matched with the decreasing direction of feasibility loss, boundary loss, and load loss in this round of training loss; When any perturbation-induced model update component causes a mismatch between the direction of change in the corresponding violation rate and the direction of loss decrease, the model update component is subjected to amplitude pruning or zeroing, and an upload summary consistent with the processing result is regenerated.

[0017] Preferably, the distribution of subdomain adaptation parameters includes: The federated collaboration server generates node subdomain identifiers based on the interval encoding, common constraint sample response results, and conflict isolation markers uploaded by each local design node in the most recent multiple rounds. The global generated model, the constraint adaptation layer parameters corresponding to the node subdomain identifier, and the output layer conflict isolation flag are all sent to the local design node. Upon receiving the data, the local design node performs a consistency check between the constraint adaptation layer parameters and the local hard constraints. If the consistency check fails, it only uses the global generation model and the local previous round of trusted constraint adaptation layer parameters to generate the balcony photovoltaic support design parameters.

[0018] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. With this invention, each local design node converts balcony boundary dimensions, component specifications, installation restriction areas, and load constraints into local constraint tensors, and completes the training of the support parameter generation network and feasibility discrimination network locally. The original balcony photovoltaic support design data does not need to be uploaded to the server. Before uploading the model update, a feasible region sensitivity matrix is ​​established based on the local constraint tensors. Random masking, differential perturbation, interval encoding, sign preservation, sparse compression, and quantization are performed according to high-sensitivity updates, constraint boundary updates, and low-sensitivity updates, respectively, so that update information strongly correlated with building geometric boundaries, installation restriction areas, and load constraints participates in federated training in a controlled manner. Under safe aggregation conditions, the server calculates the feasible region overlap using interval encoding, low-sensitivity direction vectors, and common constraint sample response results, and performs differentiated weighted aggregation on different model branches accordingly. This processing logic enables the federated training process to not rely on the centralized aggregation of the original engineering data, nor to use an indiscriminate averaging method to mix differential constraints. This ensures that the global generation model has a parameter generation basis that is compatible with the local feasible domain before local hard constraint correction, reducing the possibility of the generation results deviating from the installation boundary, component arrangement restrictions, and load range.

[0019] 2. This invention further constructs constraint event sequences, feasible region boundary samples, boundary-adjacent infeasible samples, and boundary-far-from-the-boundary infeasible samples, enabling local training samples to cover the hierarchical states of the feasible region, feasible region boundaries, and infeasible regions. By using constraint violation direction identifiers and constraint attention weights, the installation angle, component spacing, boundary avoidance amount, and fixed point distribution interval receive training constraints from corresponding constraint event branches, reducing gradient interference between different output dimensions. After applying random masks and differential perturbations to highly sensitive updates, the local validation set is used to verify the consistency of the changing directions of installation boundary violation rate, load interval violation rate, and component arrangement violation rate. Mismatched update components are pruned or zeroed out to ensure that the uploaded content after confidentiality processing remains consistent with the direction of local feasibility loss decrease. The server employs secure aggregation averaging, subdomain aggregation, and violation direction compatibility filtering for the shared layer, constraint adaptation layer, and output layer, respectively, and retains conflict isolation markers when constraints conflict, enabling the model parameters corresponding to differentiated balcony scenarios to be stored and distributed hierarchically. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating the overall process of a collaborative design method for balcony photovoltaic supports based on federated learning. Figure 2 Flowchart for constructing local constraint tensors and hierarchical local samples; Figure 3 Flowchart for updating sensitivity stratification and confidential uploading of local models; Figure 4A flowchart for the aggregation and local adaptation of the federated collaboration server. Detailed Implementation

[0021] refer to Figure 1 In one embodiment, the federated learning-based collaborative design method for balcony photovoltaic (PV) brackets is executed jointly by multiple local design nodes and a federated collaboration server. Each local design node corresponds to a design terminal capable of independently storing local balcony PV bracket design data. This local balcony PV bracket design data includes balcony boundary dimensions, component specifications, installation restriction areas, load constraints, historical feasible design parameters, and historical infeasible design parameters. The balcony boundary dimensions describe the geometric boundaries that can be used to arrange the balcony PV brackets; the component specifications describe the length, width, mass, and permissible arrangement of the PV components; the installation restriction areas describe the boundary areas where bracket parameters cannot be arranged or cannot be crossed; and the load constraints describe the constraint intervals related to wind load, snow load, and installation tilt angle. Each local design node does not transmit the above raw data to the federated collaboration server. Instead, it converts the data locally into a unified format of local constraint tensors, enabling subsequent model training to be performed without exposing the original engineering data.

[0022] In this embodiment, the local constraint tensor is denoted as ,in Indicates the first A local design node It is obtained by concatenating boundary code, component code, restricted area code, and load code, and its expression is: ; in, Indicates the first The balcony boundary code of each local design node has the physical meaning of the occupancy status of the installable boundary on discrete coordinates. This indicates the component specification code, which physically represents the constraints on the component's size, mass, and arrangement. This represents the code for the installation restriction area, which physically represents the positional constraint of the non-installable area in the boundary coordinates. This represents the load constraint code, which physically indicates the allowable range related to the installation angle and stress conditions. Operator This represents feature concatenation. For example, when a design node discretizes the balcony boundary into an occupancy sequence of length 4. , encode the component specifications as The installation restriction area is coded as Encode the load constraints as At that time, the local constraint tensor is This tensor does not directly contain the original balcony drawings or project address information.

[0023] Each local design node trains a scaffold parameter generation network and a feasibility discrimination network based on the local constraint tensor. The scaffold parameter generation network uses... The system takes the bracket parameter generation network as input and outputs design parameters for the balcony photovoltaic (PV) bracket, including installation angle, component spacing, boundary clearance, and fixed point distribution range. The feasibility discrimination network takes the output of the bracket parameter generation network and the local constraint tensor as input and outputs a feasibility discrimination result. During model training, local design nodes construct training samples based on historical feasible and infeasible design parameters, enabling the bracket parameter generation network to learn the mapping relationship from the constraint tensor to the bracket parameters, and enabling the feasibility discrimination network to learn whether the bracket parameters meet local installation boundaries, installation restriction areas, and load constraints. The bracket parameter generation network and the feasibility discrimination network can adopt a structure of shared encoding layer and branch output layer. The shared encoding layer is used to extract common constraint features from the constraint tensor, and the branch output layer corresponds to the installation angle, component spacing, boundary clearance, fixed point distribution range, and feasibility discrimination result, respectively.

[0024] After local model training is complete, the local design node receives local model updates. These updates are not directly uploaded; instead, a feasible region sensitivity matrix is ​​established based on the local constraint tensor. The feasible region sensitivity matrix characterizes the correlation strength between model parameter updates and balcony boundary dimensions, component specifications, installation restriction areas, and load constraints. Specifically, the local design node performs perturbation tests on model parameter updates. After setting a certain parameter update component to zero or scaling it, the degree of offset of the support parameter generation network output from the local feasible region boundary is compared. If this parameter update component causes an offset close to the constraint boundary in the installation angle, component spacing, boundary clearance, or fixed point distribution range, then this component corresponds to higher sensitivity. After sensitivity calculation, the local design node classifies local model updates into high-sensitivity updates, constraint boundary updates, and low-sensitivity updates according to their sensitivity level. High-sensitivity updates are processed with random masking and differential perturbation, constraint boundary updates are processed with interval encoding, and low-sensitivity updates are compressed before uploading.

[0025] After receiving the confidential local model updates, the federated collaboration server does not restore the balcony boundary dimensions, installation restriction areas, and load constraints of each local design node. The federated collaboration server obtains aggregated intermediate quantities that can be used for calculation through secure aggregation and calculates the feasible region overlap between local design nodes based on the interval encoding of constraint boundary updates and low-sensitivity update directions. Feasible region overlap represents the compatibility of two local design nodes within the feasible range of the support design. For nodes with high feasible region overlap, their model updates have higher aggregation weights in the constraint adaptation layer; for nodes with low feasible region overlap, their model updates have reduced weights or are isolated from aggregation in relevant constraint branches. After forming the global generated model, the federated collaboration server distributes the global generated model to each local design node. Each local design node receives the global generated model and performs local corrections based on local hard constraints to obtain the balcony photovoltaic support design parameters. The local hard constraints include that installation boundaries must not be crossed, installation restriction areas must not be traversed, component arrangements must not conflict, and load ranges must not exceed limits. The advantage of this embodiment is that the original design data is retained locally, and the server can still distinguish the differences in feasible domains between different nodes based on the confidential model update, so that the generation process of balcony photovoltaic bracket design parameters is consistent with local installation constraints.

[0026] refer to Figure 2 Preferably, the formation process of the local constraint tensor adopts a unified discrete encoding method. The installable boundary of the balcony is converted into a boundary occupancy sequence. Each element in the boundary occupancy sequence corresponds to a discrete boundary position. A value of 1 indicates that the position is allowed as a layout reference position, and a value of 0 indicates that the position is not usable as a layout reference. The component length, width, mass, and allowed arrangement are encoded into a component constraint sequence. The length and width are used to calculate the occupancy range of the component in the balcony boundary coordinates, the mass is used to participate in the load constraint encoding, and the allowed arrangement is used to limit the component to be arranged laterally, longitudinally, or in a single row. The installation restriction area is encoded into an unusable area mask. The unusable area mask has the same coordinate reference as the boundary occupancy sequence, enabling the support parameter generation network to identify the allowed and restricted areas in the same tensor space. Wind load conditions, snow load conditions, and the allowable range of support tilt angle are encoded into constraint interval vectors. Each set of intervals in the constraint interval vector includes a lower limit value and an upper limit value.

[0027] In this embodiment, historical feasible design parameters and historical infeasible design parameters are mapped to positive sample labels and negative sample labels, respectively. Positive sample labels correspond to support parameters that have passed local hard constraint verification, while negative sample labels correspond to support parameters that violate at least one of the following: installation boundary, installation restriction area, component arrangement, or load range. The output vector of the support parameter generation network is denoted as... Its expression is: ; in, Indicates the first The installation angle generated by each local design node is physically represented as the tilt angle of the photovoltaic module relative to the balcony installation reference plane. Indicates the component spacing, which physically means the interval between the projected boundaries of adjacent components; It represents the boundary clearance amount, which physically means the distance of the component or support parameter relative to the boundary that cannot be crossed; This represents the distribution range of fixed points, physically meaning the coverage area of ​​the candidate fixed point range in the discrete boundary coordinates. For example, if... , , , The model output indicates an installation angle of 12°, a component spacing encoding value of 8°, a boundary avoidance encoding value of 5°, and a fixed point that can be located between discrete boundary coordinates 2 and 6°. These values ​​are example values ​​within the encoding space; in actual implementation, they are generated by the local design node according to a unified dimension or normalization rule.

[0028] To enable the feasibility discrimination network to identify different types of constraints, feasibility labels are also included in the training samples. These feasibility labels are denoted as... When the scaffold parameters satisfy all the hard constraints corresponding to the local constraint tensor, When the stent parameters violate any hard constraint, Feasibility assessment of network reception The predicted value is then output. During local training, according to and The network parameters are updated based on the differences. For negative samples, the local design node further records the category of constraint violation, enabling the generative network to distinguish between boundary crossings, region crossings, component conflicts, and load overruns during subsequent training. Table 1 shows the correspondence between the local constraint tensor and the scaffold parameter output, which illustrates the data source and output constraint location of various input fields during model training.

[0029] Table 1. Correspondence between local constraint tensor fields and scaffold parameter outputs

[0030] In this embodiment, all fields in Table 1 are generated and saved by the local design node; the federated collaboration server does not receive the original field values. The support parameter generation network learns boundary avoidance amounts and fixed point distribution intervals through boundary occupancy sequences and unavailable area masks, and learns installation angles and component spacing through component constraint sequences and constraint interval vectors. The feasibility discrimination network concatenates the support parameter output with the local constraint tensor for discrimination, avoiding reliance solely on the generation network output without local constraint verification. The advantage of this embodiment is that the local constraint tensor unifies design constraints from different sources into the same input space, enabling the support parameter generation network and the feasibility discrimination network to form a mutually corrective training relationship locally, reducing training bias caused by inconsistent constraint formats.

[0031] refer to Figure 3 Furthermore, the feasible region sensitivity matrix is ​​not established using fixed rules, but rather calculated based on the contribution of the local model update to the constraint back-calculation error and the drift of the design parameter output. Let the local model update be... ,in Indicates the first Model parameters for each local design node. The first in After perturbing the parameter update components, the back-calculation errors for balcony boundary dimensions, installation restriction areas, load constraint intervals, and design parameter output drift are calculated respectively. The sensitivity elements in the feasible region sensitivity matrix are denoted as... The formula for its calculation is: ; in, Indicates the first The local design node Sensitivity of the feasible region for each model parameter update component; This indicates the back-calculation error of the balcony boundary dimensions corresponding to the updated component; This indicates the error in calculating the installation restriction area. This indicates the error in back-calculation of the load constraint interval; This indicates the amount of drift in the bracket parameter output; These represent the weights of the four categories of quantities mentioned above, and all are non-negative. Operators This indicates a weighted sum. For example, when... , , , ,and , , , hour, This result indicates that the updated component has a moderately strong association with the local feasible region.

[0032] Local design nodes based on The local model updates are categorized into high-sensitivity updates, constraint boundary updates, and low-sensitivity updates based on the sorting and distribution of parameters. High-sensitivity updates include parameter update components strongly correlated with balcony boundary dimensions, installation restriction areas, or load constraint intervals; constraint boundary updates include parameter update components that primarily affect the movement of feasible region boundaries but are difficult to directly deduce from the original data; low-sensitivity updates include parameter update components that primarily describe general feature representations or training stability. For high-sensitivity updates, the local design node generates a random mask and superimposes differential perturbations, preventing the server from reconstructing the balcony boundary or installation restriction area from a single update component. For constraint boundary updates, the local design node does not upload continuous original values ​​but instead maps the boundary movement magnitude to interval encoding, preserving the sign of the movement direction. For low-sensitivity updates, the local design node performs sparse compression and quantization, uploading only the direction components that contribute to model convergence.

[0033] In a preferred embodiment, interval encoding is discretized according to the boundary movement magnitude of the local feasible region. If an update of a parameter causes the feasible upper boundary of the installation angle to move upward, the update is encoded as an upward-moving interval; if it causes the feasible lower boundary of the boundary avoidance amount to shrink inward, the update is encoded as a shrinking interval. Symbol preservation processing is used to retain the boundary movement direction, preventing the server from treating boundary updates with opposite directions as the same type of update during aggregation. Low-sensitivity updates, after sparse compression, retain only the top-ranked directional components. Quantization processing maps continuous values ​​to finite codes, reducing the expressive power of uploaded content on local data. The advantage of this embodiment is that the feasible region sensitivity matrix matches the confidentiality processing strength with the data sensitivity of the model update, and allows the server to still obtain boundary direction information that can be used to determine feasible region compatibility.

[0034] refer to Figure 4 In one embodiment, when the federated collaboration server calculates the feasible region overlap, it generates a constraint similarity matrix between nodes based on the interval encoding of constraint boundary updates, the direction vector of low-sensitivity updates, and the response results of global common constraint samples. The global common constraint samples do not contain any node's private engineering data, but are abstract balcony constraint samples provided by the server, including typical boundary occupancy sequences, component constraint sequences, unavailable area masks, and constraint interval vectors. Each local design node uses its local model to infer the common constraint samples and only uploads a confidential response summary. The response summary may include the interval encoding of the generated result, the discrete level of the feasibility judgment result, and a violation direction summary. The server calculates the feasible region overlap between two nodes based on the above information, using the following formula: ; in, Indicates the first The local design node and the first The overlap of feasible domains between local design nodes; Indicates the first The set of feasible domain boundaries of each local design node after interval encoding; Indicates the first The set of feasible domain boundaries of each local design node after interval encoding; This indicates the number of elements in the intersection of two sets. This represents the number of elements in the union of two sets. This represents the directional compatibility coefficient between two nodes in their shared constraint sample responses, ranging from 0 to 1. For example, if... , ,but , .when hour, This indicates that two nodes have a constraint compatibility relationship that can be used for subdomain aggregation.

[0035] The federated collaboration server determines the aggregation weight of each local design node in different model branches based on the constraint similarity matrix between nodes. The shared layer of the support parameter generation network is used to learn the general feature representation in balcony photovoltaic support design, and its update can use safe aggregation averaging. The constraint adaptation layer is used to learn the local feasible region features related to balcony boundaries, installation restriction areas, and load constraints, and its update is based on the adjacency weights formed by the overlap of feasible regions for sub-domain aggregation. The output layer directly corresponds to the installation angle, component spacing, boundary avoidance amount, and fixed point distribution range. Its update needs to be screened for compliance with violation direction based on the response results of common constraint samples before aggregation. When the update direction of two nodes on the same output dimension will cause the common constraint samples to produce opposite violation directions, the server does not directly average the two update components, but aggregates them within their respective compatible constraint sub-domains.

[0036] Preferably, the federated collaboration server saves the node subdomain identifier after each round of aggregation. The node subdomain identifier is jointly determined by the feasible domain overlap matrix, the common constraint sample response summary, and the output layer conflict isolation marker. If a local design node maintains a high feasible domain overlap with the same group of nodes in consecutive training rounds, the node is stably assigned to the corresponding constraint subdomain. If the constraint boundary update of the node changes, the server updates its subdomain identifier according to the latest interval encoding. This mechanism ensures that federated aggregation is not a one-time static grouping, but rather that constraint compatibility is adjusted as the local data distribution changes. The advantage of this embodiment is that the server can calculate the feasible domain compatibility relationship between nodes without obtaining the original balcony constraint data, and allows the shared layer, constraint adaptation layer, and output layer to adopt aggregation methods adapted to their data sensitivity and constraint attributes.

[0037] In one embodiment, the construction of positive and negative sample labels is accomplished through local constraint replay. When the local design node performs constraint replay for each historical design parameter, it reapplies the historical support parameters to the corresponding balcony boundary code, component constraint code, unavailable area mask, and load constraint code, and records the balcony boundary occupancy status, component arrangement status, installation restriction area crossing status, and load interval matching status. The balcony boundary occupancy status indicates whether the support parameters cross the installable boundary; the component arrangement status indicates whether adjacent components meet the spacing and arrangement requirements; the installation restriction area crossing status indicates whether the fixed point distribution area or component projection overlaps with the unavailable area; and the load interval matching status indicates whether the force expression corresponding to the installation angle and fixed point distribution area is within the allowable range. The above statuses form a constraint event sequence according to time or verification order.

[0038] In this embodiment, the constraint event sequence is denoted as... Its expression is: ; in, This indicates a boundary occupancy event, which physically means whether the bracket parameters have exceeded the installable boundary. This indicates a component arrangement event, which physically means whether the component spacing and arrangement method meet the constraints. This indicates a restricted area event, which physically means whether the support parameters cross an unusable area; This represents a load matching event, which physically indicates whether the support parameters fall within the load constraint range. Each event value can be 0 or 1 to indicate a violation, or a directional discrete code can be used to represent the direction of the violation. For example, This indicates that boundary occupancy, component arrangement, and load matching did not violate constraints, but the installation restriction area was crossed; if directional coding is used, This can indicate crossing into the inner part of a restricted area. This can indicate a deviation from the outside of the restricted area.

[0039] Based on the constraint event sequence, the local design node generates feasible region boundary samples, boundary-adjacent infeasible samples, and far-from-the-boundary infeasible samples. Feasible region boundary samples refer to samples where the scaffold parameters do not violate hard constraints but any output dimension is close to the constraint boundary; boundary-adjacent infeasible samples refer to samples where only one or a few constraint events have slight violations; far-from-the-boundary infeasible samples refer to samples where multiple constraint events are violated simultaneously or where the violation direction is significant. Each type of sample is appended with a constraint violation direction label, allowing the feasibility discrimination network to learn both the feasibility discrimination result and the direction label during training. When the scaffold parameter generation network is trained using these samples, it can obtain a hierarchical representation of the feasible region interior, feasible region boundary, and infeasible region, avoiding the learning of only a rough feasible and infeasible boundary based on binary labels. Table 2 shows the relationship between the constraint event sequence and the sample hierarchy.

[0040] Table 2 Relationship between constraint event sequences and training sample stratification

[0041] In this embodiment, the training objectives of the feasibility discrimination network include feasibility label loss and orientation label loss. The feasibility label loss is used to determine whether the scaffold parameters satisfy hard constraints, and the orientation label loss is used to determine the direction of constraint violation or the nearest boundary direction. During the training of the generative network, the orientation label is used as constraint feedback, causing the output to be adjusted along the gradient away from the violation direction. The advantage of this embodiment is that historical design parameters are converted into training samples with boundary meaning, enabling the local model to identify fine-grained states near the feasible region boundary and providing a basis for constraint events in subsequent feasible region sensitivity calculations.

[0042] Furthermore, the random masking and differential perturbation of highly sensitive updates are completed internally by the local design node. Based on the sensitivity coordinates in the feasible region sensitivity matrix, the local design node assigns model parameter updates strongly correlated with balcony boundary dimensions and installation restriction areas to the first mask group, and model parameter updates strongly correlated with load constraint intervals to the second mask group. The first mask group is used to protect information related to geometric boundaries and unusable areas, while the second mask group is used to protect information related to load constraint intervals. Different mask groups use different random seeds to generate additive masks. The random seeds are stored only by the local node or negotiated with other nodes according to a secure aggregation protocol, preventing the server from removing the mask alone to obtain the original update components.

[0043] The differential perturbation amplitude is constrained by the decrease in loss during this training round. Let the perturbed component of the highly sensitive update be... Its expression is: ; in, Indicates the first The local design node Update components of the original model parameters; This represents the random mask corresponding to the updated component; Indicates differential perturbation; This represents the updated model parameters after confidentiality processing. Operators This indicates the addition of values ​​within the same dimension. For example, when... , , hour, The server received a value of 0.09, which cannot be used to directly reconstruct the original update component of 0.12. If the loss reduction in this round of training is small, the local node... The range of values ​​is narrowed to prevent the update direction from deviating from the local training direction after perturbation; if the loss decreases significantly in this round of training, a wider perturbation range is allowed, but it still needs to pass the direction consistency check.

[0044] Before uploading, the local design node performs a direction consistency check on the perturbed update. This check uses a local validation set that is not uploaded. The model before and after the perturbation are applied to the same validation sample to obtain the changing directions of the installation boundary violation rate, load interval violation rate, and component arrangement violation rate. These directions are then matched with the decreasing directions of the feasibility loss, boundary loss, and load loss in the current training loss. When an update component causes the direction of the violation rate change in the perturbed model for the corresponding constraint event to mismatch with the direction of loss decrease, the local design node performs amplitude pruning or zeroing on that update component before generating an upload summary consistent with the processing result. The advantage of this embodiment is that highly sensitive model updates undergo masking, perturbation, and local consistency checks before uploading, reducing the possibility of the original constraint data being reverse-engineered and preventing confidentiality processing from disrupting the constraint direction of the local model update.

[0045] In one embodiment, differentiated weighted aggregation is performed hierarchically, comprising a shared layer, a constraint adaptation layer, and an output layer. The shared layer model update is generated by averaging all local design nodes through secure aggregation. This is because the shared layer primarily expresses common coding characteristics in balcony photovoltaic support design, such as the local continuity of boundary occupancy sequences, the scale relationship of component specification sequences, and the normalized expression of constraint interval vectors. The constraint adaptation layer model update performs subdomain aggregation based on adjacency weights formed by feasible region overlap and saves corresponding subdomain adaptation parameters for each local design node. The output layer model update directly corresponds to installation angle, component spacing, boundary clearance, and fixed point distribution intervals; therefore, before aggregation, it is necessary to use the common constraint sample response results for violation direction compatibility screening.

[0046] In this embodiment, the aggregate weight of the constraint adaptation layer is denoted as . The formula for its calculation is: ; in, Indicates the first The model update of the local design node in the _th The aggregation weight in the subdomain adaptation parameters corresponding to each local design node; Indicates the first The local design node and the first The overlap of feasible domains between local design nodes; Indicates the relationship with the first A set of nodes with compatible relationships in a local design node; Represents a set Sum the feasible region overlap of all nodes in the equation. For example, when... Includes 3 nodes, and corresponding , , hour, ,therefore , , This weight is used to constrain the aggregation of the adaptation layer and is not used to directly expose the original design data of any node.

[0047] The compatibility screening of the violation direction in the output layer is accomplished by comparing response summaries on common constraint samples. If two nodes adjust the installation angle to the same feasible direction on the same common constraint sample, the two nodes are considered compatible in the installation angle output dimension. If the update of one node causes the installation angle to move closer to the upper boundary, while the update of another node causes the installation angle to move closer to the lower boundary, and the corresponding local constraint intervals cannot be proven to overlap through interval encoding, then the output dimension is marked as conflicting. The server retains conflict isolation markers for conflicting output dimensions and aggregates compatible updates only within the same constraint subdomain. The advantage of this embodiment is that the same global training process can simultaneously save the general model expression and subdomain adaptation parameters, avoiding the indiscriminate averaging of differentiated balcony constraints in the output layer.

[0048] In a preferred embodiment, the generation of the constraint event sequence further includes boundary perturbation simulation of historical design parameters. The local design node uses the same historical design parameters as a reference to perturb the balcony boundary conditions and component arrangement conditions in multiple directions. The perturbed balcony boundary conditions may include local shrinkage of the installable boundary, local expansion of the unusable area, or changes in boundary avoidance requirements; the perturbed component arrangement conditions may include changes in component arrangement, changes in component spacing constraints, or changes in the component projection area. After each perturbation, the local design node re-executes constraint verification to obtain the corresponding boundary migration trajectory. The boundary migration trajectory records the correspondence between each output dimension and constraint events when the support parameters change from a feasible state to an infeasible state, or from an infeasible state back to a feasible state.

[0049] In this embodiment, the constraint attention weight is denoted as... The formula for its calculation is: ; in, Indicates the first The first local design node The output dimension for the first Attention weights for class-constrained events; This indicates the output dimension, with values ​​corresponding to installation angle, component spacing, boundary clearance, or fixed point distribution range. Indicates the type of constraint event, with values ​​corresponding to boundary occupancy events, component arrangement events, restricted area events, or load matching events; Indicating the boundary migration trajectory of the first A change in the first output dimension triggers the... The number of times the state of a class constraint event changes; This represents the set of all constraint event categories. For example, when the installation angle output dimension causes 6 changes in load matching events, 2 changes in component arrangement events, 1 change in boundary occupancy events, and 1 change in restricted area events in the boundary migration trajectory, the denominator is 10, and the attention weight of the installation angle for the load matching events is... .

[0050] When training the scaffold parameter generation network, the local design node uses constraint attention weights to limit the gradient sources for different output dimensions. The installation angle output dimension primarily receives gradients corresponding to load matching and component arrangement events; the component spacing output dimension primarily receives gradients corresponding to component arrangement events; the boundary clearance output dimension primarily receives gradients corresponding to boundary occupancy and restricted area events; and the fixed point distribution interval output dimension primarily receives gradients corresponding to boundary occupancy, restricted area, and load matching events. This process does not delete other gradient sources, but rather adjusts the contribution of each event branch to different output dimensions according to the constraint attention weights. The advantage of this embodiment is that a data-driven correspondence is formed between the scaffold parameter output dimensions and constraint events, enabling local model training to reduce the interference of irrelevant constraint events on specific output dimensions.

[0051] Furthermore, directional consistency verification is performed using a local verification set and the direction of change in violation rate. The local verification set is stored by the local design node and is not uploaded. This verification set includes samples within the feasible region, samples at the feasible region boundary, infeasible samples adjacent to the boundary, and infeasible samples far from the boundary. After the unperturbed model and the post-perturbed model are applied to the local verification set, the local design node calculates the direction of change in the installation boundary violation rate, the load interval violation rate, and the component arrangement violation rate. If the post-perturbed model reduces a certain type of violation rate compared to the unperturbed model, the direction of change in that violation rate is recorded as a decrease; if it increases, it is recorded as an increase; if it remains unchanged, it is recorded as maintenance. Subsequently, the local design node matches the direction of change in violation rate with the direction of decrease in loss during this round of training.

[0052] In this embodiment, the change in the violation rate is denoted as... The formula for its calculation is: ; in, Indicates the first The local design node at the Changes in violation rate on class constraints; Indicates the constraint type, with values ​​corresponding to installation boundaries, load ranges, or component arrangements; This indicates that the perturbed model violates the first rule in the local validation set. Number of samples with class constraints; This indicates that the model before the perturbation violated the first rule in the local validation set. Number of samples with class constraints; This indicates the number of samples in the local validation set. For example, when Before the perturbation, the model had 6 samples violating the installation boundary constraints; after the perturbation, the model had 4 samples violating the installation boundary constraints. This indicates a decrease in the installation boundary violation rate. If the boundary loss in this round of training is also decreasing, then the updated component passes the directional consistency check on the installation boundary constraints.

[0053] When any perturbated model update component causes a mismatch between the direction of the corresponding violation rate change and the direction of loss decrease, the local design node performs amplitude pruning or zeroing on that model update component. Amplitude pruning can be limited by the upper limit of the absolute value of the update component before the perturbation, ensuring it does not exceed the maximum directional offset allowed by local training; zeroing is used to handle components that continuously cause an increase in the violation rate. After processing, the local design node regenerates the upload summary, ensuring that the uploaded summary is consistent with the actual confidential update, preventing the server from performing aggregation judgments based on inconsistent summaries. The advantage of this embodiment is that the confidentialized model update is verified and corrected locally, ensuring that the update component received by secure aggregation still retains the characteristic of being consistent with the direction of local constraint improvement.

[0054] In one embodiment, the distribution of subdomain adaptation parameters is generated by the federated collaboration server based on information uploaded in the most recent rounds. The server stores the interval encoding, common constraint sample response results, and conflict isolation markers for each local design node in the most recent rounds. The interval encoding describes the relative position and movement direction of the node's feasible domain boundary; the common constraint sample response results describe the output distribution of the node's model on the abstract constraint samples; and the conflict isolation markers describe which output dimensions the node cannot directly aggregate with other nodes. The server uses this information together to generate the node subdomain identifier. The node subdomain identifier does not contain original engineering data and is only used to determine which constraint adaptation layer parameters and output layer conflict isolation markers are distributed to the local design node.

[0055] In this embodiment, the server sends out a global generation model, constraint adaptation layer parameters corresponding to the node subdomain identifier, and output layer conflict isolation flags. Upon receiving this content, the local design node does not directly replace the local model. Instead, it performs a consistency check between the constraint adaptation layer parameters and the local hard constraints. The consistency check is performed using local constraint tensors and a local check set. The check includes whether the installation boundary has been exceeded, whether the installation restriction area has been crossed, whether the component arrangement conflicts, and whether the load range exceeds the limit. If the consistency check passes, the local design node uses the sent constraint adaptation layer parameters to generate balcony photovoltaic support design parameters. If the consistency check fails, the local design node only uses the global generation model and the previously passed trusted constraint adaptation layer parameters for generation, and uses the failed check summary as the local response basis for the next round of federated training. This process ensures that the parameters sent by the server are not used directly without considering the local hard constraints.

[0056] Specifically, when generating the final support structure design parameters, the local design node uses the shared layer output of the globally generated model as a general feature and the constraint adaptation layer parameters as local feasible domain correction features. It then generates the installation angle, component spacing, boundary clearance, and fixed point distribution range through the output layer. If there are conflict isolation markers in the output layer, the local design node prioritizes using the output channel consistent with its local subdomain in the corresponding output dimension. If this output channel fails the local hard constraint verification, it reverts to the previous round's reliable output channel. After the generation result is completed, the local node performs local hard constraint verification on the support structure design parameters and uses the verified result as the feasible output. The advantage of this embodiment is that the distributed model parameters undergo node subdomain identifier matching and local consistency verification before participating in the support structure parameter generation, enabling the federated collaborative training results to be used stably under local constraints.

[0057] In a preferred embodiment, local hard constraint correction is performed in conjunction with the model output process. After the support parameter generation network outputs the initial support parameters, the local design node inputs these initial support parameters into the feasibility judgment network to obtain the feasibility judgment result and the direction indicator of the constraint violation. If the feasibility judgment result is feasible, the local design node directly proceeds to hard constraint verification; if the feasibility judgment result is infeasible, the local design node performs local correction on the initial support parameters based on the direction indicator. Local correction does not regenerate all support parameters, but only corrects the output dimension that caused the violation. For example, when the direction indicator shows that insufficient boundary clearance causes the installation restriction area to be crossed, the local node only adjusts the boundary clearance and the distribution range of fixed points; when the direction indicator shows that the installation angle causes the load range to exceed the limit, the local node only adjusts the installation angle and keeps the component spacing and boundary clearance unchanged. The corrected support parameters are input into the feasibility judgment network again until they pass the judgment or reach a preset limited number of correction rounds.

[0058] In this embodiment, local corrections are calculated using feasible region boundary information. For each output dimension, the local design node stores the allowable interval determined by the local constraint tensor. If the generated value is below the lower bound of the allowable interval, it is projected to the lower bound; if the generated value is above the upper bound of the allowable interval, it is projected to the upper bound; if the generated value is within the allowable interval, it remains unchanged. For interval-type outputs such as fixed-point distribution intervals, the local node corrects the start and end points of the intervals respectively, ensuring that the start point is not greater than the end point. For component spacing outputs, the local node also checks whether the projections of adjacent components overlap, based on the component specification code. After local corrections are completed, a full verification using local hard constraints is still required to prevent corrections of a single output dimension from causing changes in other constraint events. The advantage of this embodiment is that the local hard constraint correction and the feasibility discrimination network form a closed-loop process, enabling the global generated model output to be corrected to the local feasible range without exposing local constraint data.

[0059] Furthermore, during the multiple iterations of federated training, the local design node stores the trusted constraint adaptation layer parameters from the previous round. Trusted constraint adaptation layer parameters refer to the adaptation layer parameters that have undergone local consistency verification and are used to generate feasible support parameters. Whenever the server issues new constraint adaptation layer parameters, the local design node first performs offline verification on its local verification set before deciding whether to replace the current trusted parameters. If the new constraint adaptation layer parameters increase the installation boundary violation rate, load interval violation rate, or component arrangement violation rate compared to the previous round of trusted parameters, then these parameters are not written into the trusted parameter area. If the new constraint adaptation layer parameters pass verification, they are written into the trusted parameter area and used as the fallback benchmark for the next round. This mechanism does not rely on the server to determine whether local constraints are satisfied; instead, the local node manages the trusted state itself.

[0060] In this embodiment, trusted parameter management also includes version tagging. Each round of constraint adaptation layer parameters has a corresponding round identifier and node subdomain identifier. The local node associates and saves the verified parameters with these two types of identifiers. When the server subsequently adjusts the node subdomain based on the conflict isolation marker, the local node can select the corresponding trusted parameter version based on the new subdomain identifier. If the new subdomain identifier does not have a trusted parameter version locally, the local node performs a more complete local verification before enabling the server to issue parameters. The verification samples cover feasible domain boundary samples and adjacent infeasible samples. If the verification fails, the node still uses the trusted parameter version under the atomic domain and uploads the subdomain inconsistency summary to participate in the next round of aggregation. The advantage of this embodiment is that the local node can retain a fallback trusted state in the federated model iteration, reducing the impact of subdomain changes or aggregation conflicts on the scaffold parameter generation results.

[0061] In one embodiment, when processing uploaded content under secure aggregation conditions, the server uses different aggregation entry points for different types of information. High-sensitivity updates only enter the secure aggregation channel; the server can only obtain the aggregated result and not the unmasked update of a single node. Constraint boundary updates enter the similarity calculation channel in interval-based encoding form; the server can only see the encoding results of the boundary movement interval and direction. Low-sensitivity updates enter the shared feature aggregation channel in sparse quantization direction; the server uses this to help determine whether the model training direction is stable. Public constraint sample response results enter the compatibility screening channel in discrete summary form; the server judges whether there are conflicts in the output layer based on the response direction rather than the specific scaffold design values. These channels are stored in isolation on the server side, and the required encoding results are only read when generating the constraint similarity matrix between nodes and the model aggregation weights.

[0062] In this embodiment, the server performs round consistency checks on uploaded content. Each local design node uploads confidential updates, interval encoding, low-sensitivity direction vectors, and common constraint sample response results, all bearing the same round identifier. If the round identifiers of the uploaded content from a node are inconsistent, the server will not use that round's data for feasible domain overlap calculation. If the rounds are consistent but the common constraint sample response results conflict with the interval encoding direction, the server will write the corresponding output dimension into the conflict candidate set and perform compatibility filtering on that dimension during subsequent aggregation. The server does not directly delete node updates based on a single anomaly summary; instead, it restricts the update to participate in shared layer aggregation within the common consistency portion and suspends its constraint adaptation layer updates from participating in subdomain aggregation. The advantage of this embodiment is that the server can distinguish the type of uploaded information without accessing the original design data and maintain consistency between the model aggregation process and the data confidentiality processing process.

[0063] In a preferred embodiment, the federated collaboration server maintains a global common constraint sample set. This global common constraint sample set consists of abstracted balcony boundary codes, abstracted component specification codes, abstracted unusable area masks, and abstracted load interval codes, and does not originate from the real project data of any local design node. Before each training round, the server distributes the common constraint sample set or its encoded summary to each local design node. The local design nodes use their current local model to infer the common constraint samples and convert the inference results into discrete response summaries for uploading. The discrete response summary includes the feasibility level, main violation direction, and output interval code corresponding to each common constraint sample. Based on this, the server compares the model response directions of different nodes and uses the response directions as the directional compatibility coefficient in the feasible region overlap.

[0064] In this embodiment, the update of the common constraint sample set does not depend on real engineering data. The server can generate new abstract samples based on the distribution of conflict isolation markers from the previous round. For example, when multiple nodes conflict in the boundary avoidance output dimension, the server adds abstract common samples related to boundary avoidance; when multiple nodes conflict in the load interval output dimension, the server adds abstract common samples related to installation angles and fixed point distribution intervals. The newly added samples still use abstract encoding and do not contain building information, owner information, specific balcony dimensions, or real project coordinates. The response summary of each node to the newly added samples is used for the next round of feasible domain overlap calculation. The advantage of this embodiment is that the common constraint sample set provides the server with a unified compatibility reference, enabling model updates from different nodes to be compared under the same abstract constraint conditions.

[0065] Furthermore, when generating design parameters for balcony photovoltaic supports, the local design node executes in the order of model output, feasibility judgment, local correction, and hard constraint verification. However, this order is not expressed by a fixed process number, but is completed continuously within the same inference process. The global generation model receives the local constraint tensor and generates the initial output; the feasibility judgment network generates the judgment result based on the initial output and the local constraint tensor; if the judgment result shows a violation direction, the local correction logic adjusts the corresponding output dimension according to the direction identifier; the hard constraint verification logic performs a final verification on the corrected output. Outputs that pass the verification are recorded as local feasible design parameters, and outputs that fail the verification are recorded as boundary-adjacent infeasible samples for subsequent local training. Thus, the inference result also becomes part of the subsequent training data, but is still retained within the local node.

[0066] In this embodiment, the generated results record includes a local constraint tensor summary, scaffold parameter output, feasibility judgment result, hard constraint verification result, and violation direction identifier. These records are used to update the local training sample library and participate in subsequent local model training. If a certain type of violation direction appears in multiple consecutive inferences, the local design node increases the sampling frequency of samples corresponding to that type of constraint event in the next round of training, allowing the model to learn more about the relevant feasible domain boundaries. The sampling frequency adjustment only affects the local training process and is not used as a direct basis for server aggregation weights. The server still aggregates based on the confidentialized model updates and response summaries. The advantage of this embodiment is that the local node can transform the verification results generated during the model inference process into new training samples, enabling the federated collaborative design model to gradually adapt to the local constraint distribution in multiple rounds of training, while keeping the original design data from being transmitted externally.

Claims

1. A collaborative design method for balcony photovoltaic brackets based on federated learning, characterized in that, include: Local balcony photovoltaic bracket design data are obtained from multiple local design nodes, and the balcony boundary dimensions, component specifications, installation restriction areas and load constraints are converted into local constraint tensors. Within the local design node, a scaffold parameter generation network and a feasibility discrimination network are trained to obtain a local model update. A feasible region sensitivity matrix is ​​established based on the local constraint tensor for updating the local model, and differentiated confidentiality processing is performed on the local model update according to the sensitivity level; The local model, after being encrypted, is updated and uploaded to the federated collaboration server. The federated collaboration server calculates the feasible domain overlap of each local design node under secure aggregation conditions, and aggregates the feasible domain overlap to form a global generated model. The method involves sending the global generated model to the local design node, which then combines the local design node with local hard constraints to output the design parameters for the balcony photovoltaic support.

2. The collaborative design method for balcony photovoltaic brackets based on federated learning according to claim 1, characterized in that, The formation of the local constraint tensor includes: The balcony installation boundary is discretized into a boundary occupancy sequence. The component length, width, mass, and allowable arrangement are encoded into a component constraint sequence. The installation restriction area is encoded into an unusable area mask. The wind load condition, snow load condition, and allowable range of support tilt angle are encoded into a constraint interval vector. The historical feasible design parameters and historical infeasible design parameters are mapped into positive sample labels and negative sample labels, respectively. The support parameter generation network uses the local constraint tensor as input to generate installation angle, component spacing, boundary avoidance amount, and fixed point distribution range. The feasibility discrimination network uses the generated results and the local constraint tensor as input to generate feasibility discrimination results.

3. The collaborative design method for balcony photovoltaic supports based on federated learning according to claim 1, characterized in that, Establishing the feasible region sensitivity matrix includes: Calculate the contribution of the local model update to the back-calculation error of balcony boundary dimensions, the back-calculation error of installation restriction area, the back-calculation error of load constraint interval, and the drift of design parameter output, and project the contribution values ​​onto the sensitivity coordinates corresponding to the model parameters; The local model update is divided into high-sensitivity update, constraint boundary update, and low-sensitivity update according to the sensitivity coordinates. The highly sensitive updates are subjected to random masking and differential perturbation, the constraint boundary updates are subjected to interval encoding and sign preservation processing, and the low-sensitivity updates are subjected to sparse compression and quantization processing before being uploaded.

4. The collaborative design method for balcony photovoltaic supports based on federated learning according to claim 1, characterized in that, The federated collaboration server calculates the feasible domain overlap by including: Extract the interval encoding of constraint boundary update, the direction vector of low-sensitivity update and the global common constraint sample response results from the local model update that has been confidentialized, and generate the node constraint similarity matrix without restoring the local balcony photovoltaic support design data. Based on the constraint similarity matrix between nodes, the aggregation weight of each local design node in different model branches is determined, and differentiated weighted aggregation is performed on the shared layer, constraint adaptation layer and output layer of the scaffold parameter generation network respectively.

5. The collaborative design method for balcony photovoltaic supports based on federated learning according to claim 2, characterized in that, The construction of positive and negative sample labels includes: Within the local design node, constraint replay is performed on historical design parameters, and the balcony boundary occupancy status, component arrangement status, installation restriction zone crossing status, and load interval matching status corresponding to each historical design parameter are recorded as a constraint event sequence. Based on the constraint event sequence, feasible domain boundary samples, boundary-adjacent infeasible samples, and far-from-boundary infeasible samples are generated, and a constraint violation direction identifier is attached to each type of sample. During local training, the feasibility discrimination network learns both the feasibility discrimination result and the direction identifier, so that the training samples of the scaffold parameter generation network contain a hierarchical representation of the feasible region interior, feasible region boundary, and infeasible region.

6. The collaborative design method for balcony photovoltaic supports based on federated learning according to claim 3, characterized in that, Performing random masking and differential perturbation on the highly sensitive update includes: Within the local design node, a mask strength sequence is generated based on the sensitivity coordinates. Model parameters strongly correlated with balcony boundary dimensions and installation restriction areas are updated and assigned to the first mask group, and model parameters strongly correlated with load constraint intervals are updated and assigned to the second mask group. Additive masks generated by different random seeds are applied to the first mask group and the second mask group respectively, and the differential perturbation amplitude is constrained according to the loss reduction amount of this round of training. Before uploading, perform a direction consistency check on the updated content after the disturbance, and only retain the update component that is consistent with the direction of the decrease in local feasibility loss.

7. The collaborative design method for balcony photovoltaic supports based on federated learning according to claim 4, characterized in that, The differential weighted aggregation includes: The model update of the shared layer is based on the safe aggregate average value of all local design nodes; The model update of the constraint adaptation layer is performed by subdomain aggregation according to the adjacency weight formed by the feasible domain overlap, and the corresponding subdomain adaptation parameters are saved for each local design node. The model updates of the output layer are filtered and aggregated according to the compliance of the violation direction of the common constraint sample response results; When there are constraint conflicts in the update direction of nodes corresponding to the same output dimension, aggregate compatible updates only within the same constraint subdomain and retain the conflict isolation marker.

8. The collaborative design method for balcony photovoltaic supports based on federated learning according to claim 5, characterized in that, The generation of the constraint event sequence also includes: Local simulation verification was performed on the same historical design parameters under balcony boundary conditions and component arrangement conditions after multiple disturbances to obtain the corresponding boundary migration trajectory. The correspondence between the output dimension of the scaffold parameter generation network and the constraint violation direction is determined based on the boundary migration trajectory, and the correspondence is written into the constraint attention weights of the local training samples; When training the support parameter generation network, the constraint attention weights are used to limit the gradient sources of different output dimensions, so that the installation angle, component spacing, boundary avoidance amount and fixed point distribution interval correspond to their respective constraint event branches.

9. The collaborative design method for balcony photovoltaic brackets based on federated learning according to claim 6, characterized in that, The direction consistency check includes: Within the local design node, a local verification set that is not uploaded is set up. The model before and after the disturbance are applied to the local verification set to obtain the changing directions of the installation boundary violation rate, load interval violation rate, and component arrangement violation rate. The direction of change is matched with the decreasing direction of feasibility loss, boundary loss, and load loss in this round of training loss; When any perturbation-induced model update component causes a mismatch between the direction of change in the corresponding violation rate and the direction of loss decrease, the model update component is subjected to amplitude pruning or zeroing, and an upload summary consistent with the processing result is regenerated.

10. The collaborative design method for balcony photovoltaic brackets based on federated learning according to claim 1, characterized in that, The distribution of subdomain adaptation parameters includes: The federated collaboration server generates node subdomain identifiers based on the interval encoding, common constraint sample response results, and conflict isolation markers uploaded by each local design node in the most recent multiple rounds. The global generated model, the constraint adaptation layer parameters corresponding to the node subdomain identifier, and the output layer conflict isolation flag are all sent to the local design node. Upon receiving the data, the local design node performs a consistency check between the constraint adaptation layer parameters and the local hard constraints. If the consistency check fails, it only uses the global generation model and the local previous round of trusted constraint adaptation layer parameters to generate the balcony photovoltaic support design parameters.

Images