A bridge cloud modeling method and system based on three-layer parameter deduction

Abstract

The present application relates to the field of bridge engineering digital design, in particular to a bridge cloud modeling method and system based on three-layer parameter deduction. The present application organizes bridge parameters into a three-layer structure, i.e. "bridge key parameters-derivative design parameters-model driven parameters"; and summarizes parameter deduction into two-layer algorithms, i.e. the deduction algorithm from bridge key parameters to derivative design parameters and the mapping algorithm from derivative design parameters to model driven parameters. The model driven parameters adopt a unified bridge semantic data file, send a modeling task to a cloud parameterized modeling engine, automatically match parameterized component templates, batch instantiate and assemble to form a whole bridge model. The present application can drive modeling through a small number of bridge key parameters, realize parameter checking, component automatic positioning, parameter conflict processing and modeling task life cycle management.

Description

Technical Field

[0001] This invention relates to the field of digital design of bridge engineering, specifically to a cloud-based modeling method and system for bridges based on three-layer parameter derivation. Background Technology

[0002] Conventional beam bridges, continuous rigid frame bridges, suspension bridges, arch bridges, and cable-stayed bridges are characterized by numerous component systems, complex spatial relationships, significant differences in structural forms, and high levels of parameter coupling. During the schematic design phase, designers can often only determine a limited number of general conditions, such as the center station number, span combination, bridge deck width, and structural type. However, the data required for creating a 3D model includes a wealth of details, such as beam segment divisions, cross-sectional variations, pier and tower dimensions, cable or hanger arrangement, foundation arrangement, component positioning points and lines, ancillary facilities, and template input parameters.

[0003] Current bridge BIM modeling primarily employs manual modeling, script development for individual bridges, or user-input of numerous template parameters. Manual methods require the creation and assembly of components one by one; dedicated scripts typically embed bridge type, components, and creation order into the program; while traditional parametric methods can alter the dimensions of individual components, they still require manual parameter preparation, template selection, positioning, and assembly. These methods typically maintain engineering design parameters, route data, general drawing data, and modeling template parameters separately, failing to establish a continuous calculation chain from a limited set of engineering conditions to the complete bridge model.

[0004] On the other hand, bridge models are large in scale, and their creation and format conversion are time-consuming. Directly launching desktop modeling software can easily lead to interface blocking and excessive service resource consumption. Existing cloud solutions often simply move the existing manual modeling software to the server, without addressing the issue of how to automatically convert engineering parameters into executable template inputs.

[0005] In summary, existing technologies have the problem of being unable to establish a continuous calculation chain from a small number of engineering conditions to the whole bridge model, and are unable to automatically convert engineering parameters into template-executable inputs. Summary of the Invention

[0006] The purpose of this invention is to overcome the shortcomings of existing technologies, such as the inability to establish a continuous calculation chain from a small number of engineering conditions to the whole bridge model and the inability to automatically convert engineering parameters into template-executable inputs, and to provide a cloud-based bridge modeling method and system based on three-layer parameter extrapolation.

[0007] To achieve the above-mentioned objectives, the present invention adopts the following technical solution:

[0008] A cloud-based bridge modeling method based on three-layer parameter extrapolation, comprising the following steps: S1: The client receives and verifies the key parameters of the bridge, and generates the project identifier and parameter version.

[0009] S2: Construct a three-layer parameter structure and source tracking records.

[0010] S3: Derive the derived design parameters based on the key parameters of the bridge.

[0011] S4: Derive the model driving parameters and component instance set based on the derived design parameters; store the bridge key parameters, the derived design parameters, and the model driving parameters in the three-layer parameter structure.

[0012] S5: Generate unified modeling data based on the project identifier, the parameter version, the three-layer parameter structure, and the component instance set.

[0013] S6: Send the unified modeling data to the cloud for modeling, output the parameterized whole bridge model, and save the modeling record.

[0014] As a preferred embodiment of the present invention, the key parameters of the bridge include any one or more of the following: bridge type, bridge name, left and right lane markings, control station number, span combination, bridge deck width, route data markings, component type, and general drawing markings.

[0015] The verification of the key parameters of the bridge is as follows: verifying the integrity of the fields, units, numerical range, chainage continuity, and data version.

[0016] As a preferred embodiment of the present invention, step S2 includes the following steps: S21: Construct a three-layer parameter structure.

[0017] The three-layer parameter structure includes: the first layer of key bridge parameters; the second layer of derived design parameters; and the third layer of model-driven parameters.

[0018] S22: Construct the data fields, encoding rules, inter-layer mapping relationships, and source tracing rules for each layer's parameters.

[0019] As a preferred embodiment of the present invention, step S3 includes the following steps: S31: Based on the reference relationships of each rule in the rule base, establish the prerequisite dependencies between the key parameters of each bridge.

[0020] The rule base is built on engineering specifications, engineering experience, general drawing data, and bridge types.

[0021] S32: Construct a parameter dependency graph using the key bridge parameters as nodes and the preceding dependencies as directed edges.

[0022] S33: Based on the rule base, the key parameters of the bridge, and the parameter dependency graph, obtain the deduction path and candidate value set corresponding to the current bridge.

[0023] S34: Establish a set of hard constraints, remove values ​​from the candidate set that do not meet the set of hard constraints, select components according to preset priorities and adjustment mechanisms, and output the selection results as derived design parameters.

[0024] The parameters in the set of hard constraints include at least: mandatory normative constraints, immutable project boundaries, geometric feasibility constraints, and template allowable ranges.

[0025] The preset priorities are as follows: manually confirmed values ​​that have passed verification, existing design values ​​of the project, general drawing matching values, standard recommended values, engineering experience recommended values, and system default values.

[0026] When multiple different candidate values ​​exist for the same priority, a conflict is recorded and manual confirmation is requested; when there is no valid candidate value, the parameter is marked as missing and subsequent nodes that depend on that parameter are stopped.

[0027] The adjustment mechanism is as follows: For candidate values ​​corresponding to quantity and spacing, first calculate the corresponding candidate quantity of the component based on the arable length of the corresponding component, the reserved distance at the end, the target spacing, and the allowable spacing range; then calculate the actual spacing based on the candidate quantity; then adjust the candidate quantity sequentially based on the relationship between the actual spacing and the allowable spacing range until the actual spacing falls into the allowable spacing range. If it cannot fall into the allowable spacing range after adjustment, output an uncoordinated conflict.

[0028] The adjustment mechanism is used for the closed arrangement of repeating components; the repeating components include: cables, hangers, diaphragms, beam segments, and supports.

[0029] As a preferred embodiment of the present invention, step S33 includes the following steps: S331: Perform loop detection and topological sorting on the parameter dependency graph.

[0030] If a circular dependency is found, the deduction branch involving that cycle is stopped, and the parameter code, rule number, and rule version constituting the cycle are output; if no circular dependency exists, the deduction path is determined according to the topological sort.

[0031] S332: Based on the deduction path, execute the rule set in the rule base on the key parameters of the bridge to obtain a set of candidate values.

[0032] As a preferred embodiment of the present invention, step S4 includes the following steps: S41: Based on the derived design parameters, determine the type, quantity, and assembly level of the component to be generated, and obtain the corresponding component instance identifier parameters.

[0033] The component instance identification parameters include: component instance identifier, component type, component template identifier, parent instance identifier, and assembly level.

[0034] S42: Calculate the positioning point of each component instance corresponding to the component instance identifier parameter, and generate positioning line data for each linear component; output the positioning point and the positioning line data as spatial positioning parameters.

[0035] The linear components include: straight line components, circular arc components, and spline curve components.

[0036] The positioning line data includes at least the following parameters: curve type, start point, end point, control point or discrete point, parameter domain, start and end tangents, direction markers, and allowable error.

[0037] S43: Perform data standardization mapping and parameter validity verification on the derived design parameters according to the preset template parameter mapping table; and after rounding or geometrical coordination of the reconcilable parameters, output them together with the component instance identifier parameters and the spatial positioning parameters as model driving parameters.

[0038] Specifically, for uncoordinated parameters, a new template is matched; if no suitable template is available, conflict information is output.

[0039] The data standardization mapping includes: parameter name mapping, unit conversion, data type conversion, coordinate direction conversion, and template version conversion.

[0040] The parameter validity verification includes: verifying required inputs, parameter range, geometric updability, and template applicability.

[0041] The conflict information includes: component identifier, parameter code, actual value, allowed range, and suggested handling method.

[0042] S44: Assign a unique identifier within the project to each component in the model-driven parameters and establish a set of relationships.

[0043] The set of relationships includes: containment relationships, connection relationships, adjacency relationships, and location dependency relationships.

[0044] S45: Generate a set of component instances based on the bridge type and the component decomposition rules in the rule base, and output the model driving parameters and the set of component instances.

[0045] S46: Store the key bridge parameters, the derived design parameters, and the model-driven parameters into the three-layer parameter structure.

[0046] As a preferred embodiment of the present invention, the unified modeling data includes at least: project identifier, parameter version, rule version, route data version, component template identifier and version, assembly level, model-driven parameters, target output format, and verification summary.

[0047] The unified modeling data is recorded in JSON, XML, or a database.

[0048] As a preferred embodiment of the present invention, step S6 includes the following steps: S61: The cloud receives the unified modeling data and creates a modeling task.

[0049] S62: The modeling engine models according to the component dependencies based on the modeling task.

[0050] S63: After modeling is completed, output the parameterized whole bridge model and save the modeling log, version information and input summary.

[0051] As a preferred embodiment of the present invention, when the key bridge parameters or the derived design parameters need to be modified, the affected derived design parameters, model-driven parameters and component instances are identified based on the parameter dependency graph and the source tracking records.

[0052] For unaffected components, the original version is retained; for affected components, the model is re-deduced, re-verified, and updated. After the update, a new parameter version and model version are generated, and the difference between the old and new versions is recorded.

[0053] A bridge cloud modeling system based on three-layer parameter derivation includes at least one processor and a memory communicatively connected to the at least one processor; the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to execute any of the bridge cloud modeling methods based on three-layer parameter derivation described above.

[0054] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention connects a small number of scheme conditions with complete modeling input through a three-layer parameter structure, eliminating the need for users to directly fill in all template parameters. Through dependency graph topology deduction, hard constraint filtering, and candidate value priority mechanisms, it ensures a definite processing order when conflicts arise between specifications, project design values, general diagrams, and engineering experience, and outputs specific conflict locations, reducing repeated manual verification. By calculating component positioning data using route 3D axes, local coordinate directions, cross slope or superelevation rotation, and shared control elements, it reduces misalignment, reversal, gap closure, and topology failure after parameter updates caused by manual assembly. Through template metadata matching and name, unit, data type, direction, and version conversion, the same set of engineering parameters can adapt to different versions of parameterized templates, improving template reusability. Through task management pools, message channels, execution locks, and checkpoint mechanisms, it decouples client requests from the long-running modeling process, supporting multi-task queuing, parallel processing by multiple engines, exception retries, and pause recovery, and can associate inputs, rules, templates, logs, and result versions. Incremental updates are achieved through dependency propagation and component stability identification, recalculating and rebuilding only the parts affected by parameter changes, reducing repetitive modeling of the entire bridge. Attached Figure Description

[0055] Figure 1 This is a schematic diagram of the overall architecture of a bridge cloud modeling method based on three-layer parameter derivation as described in Embodiment 1 of the present invention.

[0056] Figure 2 This is a diagram showing the three-layer parameter structure and source tracing diagram in a bridge cloud modeling method based on three-layer parameter derivation as described in Embodiment 2 of the present invention.

[0057] Figure 3 This is a flowchart illustrating the first-layer algorithm in a bridge cloud modeling method based on three-layer parameter derivation as described in Embodiment 2 of the present invention.

[0058] Figure 4 This is a flowchart illustrating the second-layer algorithm in a bridge cloud modeling method based on three-layer parameter derivation as described in Embodiment 2 of the present invention.

[0059] Figure 5 This is a schematic diagram of the cloud modeling and parameter change process in a bridge cloud modeling method based on three-layer parameter derivation as described in Embodiment 2 of the present invention.

[0060] Figure 6 This is a three-dimensional model of a continuous rigid frame bridge generated by a bridge cloud modeling method based on three-layer parameter derivation as described in Embodiment 3 of the present invention.

[0061] Figure 7This is a schematic diagram of a bridge cloud modeling system based on three-layer parameter deduction, which utilizes any of the aforementioned bridge cloud modeling methods based on three-layer parameter deduction, as described in Embodiment 4 of the present invention. Detailed Implementation

[0062] The present invention will be further described in detail below with reference to experimental examples and specific embodiments. However, this should not be construed as limiting the scope of the above-mentioned subject matter of the present invention to the following embodiments; all technologies implemented based on the content of the present invention fall within the scope of the present invention.

[0063] Example 1 like Figure 1 As shown, a cloud-based bridge modeling method based on three-layer parameter extrapolation includes the following steps: S1: The client receives and verifies the key parameters of the bridge, and generates the project identifier and parameter version.

[0064] S2: Construct a three-layer parameter structure and source tracking records.

[0065] S3: Derive the derived design parameters based on the key parameters of the bridge.

[0066] The derived design parameters include overall bridge layout parameters, structural parameters, and component size parameters.

[0067] S4: Derive the model driving parameters and component instance set based on the derived design parameters; store the bridge key parameters, the derived design parameters, and the model driving parameters in the three-layer parameter structure.

[0068] S5: Generate unified modeling data based on the project identifier, the parameter version, the three-layer parameter structure, and the component instance set.

[0069] S6: Send the unified modeling data to the cloud for modeling, output the parameterized whole bridge model, and save the modeling record.

[0070] Example 2 This embodiment is a specific implementation of the bridge cloud modeling method based on three-layer parameter extrapolation described in Embodiment 1, and includes the following steps: S1: The client receives and verifies the key bridge parameters, and generates a project identifier and parameter version. The key bridge parameters are the minimum necessary set of parameters to be input to start the simulation, and are not limited to a fixed number.

[0071] The key parameters of the bridge include any one or more of the following: bridge type, bridge name, left and right lane markings, control station number, span combination, bridge deck width, route data markings, component type, and general drawing markings.

[0072] The verification of the key parameters of the bridge is as follows: verifying the integrity of the fields, units, numerical range, chainage continuity, and data version.

[0073] S2: Construct as follows Figure 2 The three-layer parameter structure and source tracking records are shown.

[0074] A three-layer parameter structure is pre-established, comprising a bridge key parameter layer, a derived design parameter layer, and a model-driven parameter layer. The data fields, coding rules, inter-layer mapping relationships, and source tracing rules for each layer are defined. The first layer stores the bridge key parameters that determine the overall bridge structural system and parameter derivation path. The second layer is used to store derived design parameters describing the superstructure, substructure, foundation, cable or arch rib system, and ancillary structures. The third layer is used to store the model-driven parameters of the direct model-driven parametric template. .

[0075] In the subsequent parameter extrapolation process, the key bridge parameters obtained will be... Write to the key parameter layer, based on the bridge's key parameters Derived design parameters were obtained through deduction. And write it into the derived design parameter layer, and then according to the derived design parameters Generate model-driven parameters And write it into the model-driven parameter layer; at the same time, record the source of each parameter and the correspondence between layers, dynamically forming from arrive Then from arrive A two-way tracking chain.

[0076] S3: As Figure 3 As shown, derived design parameters (first-level algorithm) are derived based on the key bridge parameters.

[0077] S31: Based on the reference relationships between the input parameters, triggering conditions, constraint conditions and output parameters of each rule in the rule base, establish the prerequisite dependencies between the key parameters of each bridge.

[0078] The rule base is built on engineering specifications, engineering experience, general drawing data, and bridge types.

[0079] S32: When the derivation of the current parameter requires referencing another parameter, the referenced parameter is used as a preceding parameter, and a directed edge is established from the preceding parameter to the current parameter. A parameter dependency graph is constructed using the key bridge parameters as nodes and the preceding dependencies as directed edges.

[0080] S33: Based on the rule base, the key parameters of the bridge, and the parameter dependency graph, obtain the deduction path and candidate value set corresponding to the current bridge.

[0081] S331: Perform loop detection and topological sorting on the parameter dependency graph.

[0082] If a circular dependency is found, the deduction branch involving that cycle is stopped, and the parameter code, rule number, and rule version constituting the cycle are output; if no circular dependency exists, the deduction path is determined according to the topological sort.

[0083] S332: Based on the deduction path, apply a set of rules from the rule base applicable to the current bridge type, span range, material, component form, and specification version to the key bridge parameters. Each rule must include at least a trigger condition, input parameters, calculation function or lookup table range, output unit, priority, and valid version. Perform calculations, table lookups, or interpolation on rules whose trigger conditions are true to obtain a set of candidate values.

[0084] S34: Establish a set of hard constraints, remove values ​​from the candidate set that do not meet the set of hard constraints, select components according to preset priorities and adjustment mechanisms, and output the selection results as derived design parameters.

[0085] The parameters in the set of hard constraints include at least: mandatory normative constraints, immutable project boundaries, geometric feasibility constraints, and template allowable ranges.

[0086] The preset priorities are as follows: manually confirmed values ​​that have passed verification, existing design values ​​of the project, general drawing matching values, standard recommended values, engineering experience recommended values, and system default values.

[0087] When multiple different candidate values ​​exist for the same priority, a conflict is recorded and manual confirmation is requested; when there is no valid candidate value, the parameter is marked as missing and subsequent nodes that depend on that parameter are stopped.

[0088] The adjustment mechanism is used for the closed arrangement of repeating components including cables, hangers, diaphragms, beam segments, and supports. Specifically, the rule is: for candidate values ​​corresponding to quantity and spacing, first, based on the arrangeable length of the corresponding component... End reserved distance and Target spacing and the allowable spacing range Calculate the number of corresponding candidate components Its expression is:

[0089] Then, the actual spacing is calculated based on the number of candidates. Then, based on the actual spacing... Based on the relationship with the allowable spacing interval, the number of candidates is adjusted sequentially, and the adjustment rule is as follows: when At that time, Increment by 1 each time and recalculate ; when At that time, Decrease by 1 each time and recalculate ,and The number of components must not be less than the preset minimum number. Until Entering the allowed range, or reaching the quantity boundary, or reaching the preset iteration limit.

[0090] When there are multiple candidate numbers that satisfy the allowed interval, the number of candidates is selected such that the actual spacing is equal to the target spacing. The number of candidates with the smallest deviation. If no result satisfies the constraints within the allowed number, an unreconcilable conflict record is generated, subsequent nodes dependent on that parameter are stopped, and manual review is submitted. Manual review can adjust non-mandatory input parameters, change the layout scheme, or input manually confirmed values; after the manually confirmed values ​​pass the hard constraint verification, they are written to the corresponding parameter node, and the derivation of the relevant downstream nodes is restored. Mandatory constraints of the specification and immutable boundaries of the project cannot be removed by manual overriding.

[0091] S4: As Figure 4 As shown, the model-driving parameters and the set of component instances are derived from the derived design parameters (second-layer algorithm); the key bridge parameters, the derived design parameters, and the model-driving parameters are stored in the three-layer parameter structure.

[0092] S41: Based on bridge type and derived design parameters Based on the component decomposition rules, the system determines the type, quantity, and assembly level of the components to be generated, as well as the component instance identification parameters. The system assigns a unique and stable component identifier to each component instance within the project and establishes inclusion, connection, adjacency, and location dependencies between components.

[0093] S42: Calculate the positioning point of each component instance, and generate positioning line data for each linear component; output the positioning point and the positioning line data as spatial positioning parameters.

[0094] The linear components include: straight line components, circular arc components, and spline curve components.

[0095] The positioning line data includes at least the following parameters: curve type, start point, end point, control point or discrete point, parameter domain, start and end tangents, direction markers, and allowable error.

[0096] For the first component instance At each positioning point, the system reads the route data version specified for the current project and, based on the corresponding engineering control station number... Route break mapping and vertical offset Calculate the corresponding route parameters .

[0097] The system reads the route data version specified for the current project, and obtains the horizontal alignment data, vertical alignment data, and chainage break data from the route data version; it establishes a route plane coordinate function based on the horizontal alignment data, establishes a route elevation function based on the vertical alignment data, and combines them according to unified continuous route parameters to generate the route's three-dimensional axis.

[0098] in, These are the route parameters that change continuously along the three-dimensional axis of the route after the chain break mapping. The three-dimensional axes of the route; , For the plane coordinate function of the route; This is the route elevation function.

[0099] Based on the three-dimensional axis of the route Calculate route parameters Corresponding reference point and tangential unit vector ;Selection and tangential unit vector Non-parallel reference vectors are used to obtain the reference horizontal unit vector and reference vertical unit vector through vector projection and cross product operations. Then, based on the cross slope angle or superelevation angle at the corresponding position, the reference unit vector is used to circumferentially rotate around the tangential unit vector. Rotate to obtain the local horizontal unit vector. and vertical unit vector This establishes a local coordinate system at the component's positioning point. The first component instance... Each positioning point is calculated using the following formula:

[0100] in, For the first instance of the component Coordinates of each positioning point; This refers to the lateral offset relative to the three-dimensional axis of the route; This refers to the vertical offset relative to the three-dimensional axis of the route.

[0101] S43: The system matches the corresponding parametric template from the parametric template library according to the component type and template applicability conditions, and generates template binding relationships. It performs data standardization mapping and parameter validity verification on the derived design parameters according to the template parameter mapping table; and after rounding or geometrically harmonizing the harmonizable parameters, it outputs them together with the component instance identifier parameters and the spatial positioning parameters as model-driving parameters.

[0102] Specifically, for uncoordinated parameters, a new template is matched; if no suitable template is available, conflict information is output.

[0103] The data standardization mapping includes: parameter name mapping, unit conversion, data type conversion, coordinate direction conversion, and template version conversion.

[0104] The parameter validity verification includes: verifying required inputs, parameter range, geometric updability, and template applicability.

[0105] The conflict information includes: component identifier, parameter code, actual value, allowable range, and suggested handling method.

[0106] S44: Assign a unique identifier within the project to each component in the model-driven parameters and establish a set of relationships.

[0107] The set of relationships includes: containment relationships, connection relationships, adjacency relationships, and location dependency relationships.

[0108] S45: Generate a set of component instances based on the bridge type and the component decomposition rules in the rule base, and output the model driving parameters and the set of component instances.

[0109] S46: Store the key bridge parameters, the derived design parameters, and the model-driven parameters into the corresponding parameter layer of the three-layer parameter structure.

[0110] S5: Generate unified modeling data based on the project identifier, the parameter version, the three-layer parameter structure, and the component instance set.

[0111] The unified modeling data includes at least: project identifier, parameter version, rule version, route data version, component template identifier and version, assembly level, model-driven parameters, target output format, and verification summary.

[0112] The unified modeling data is recorded in JSON, XML, or a database.

[0113] The system generates a summary value for the data, which is used to verify whether the input has changed before and after cloud modeling.

[0114] S6: As Figure 5As shown, the unified modeling data is sent to the cloud for modeling, outputting a parameterized bridge model and saving the modeling record.

[0115] S61: The cloud receives the unified modeling data, creates a modeling task, and the task status includes at least pending, executing, paused, retrying, successful, and failed. It also saves the input location, parameter version, rule version, template version, priority, number of retries, progress, log location, and result location.

[0116] S62: Idle modeling engines compete for tasks and acquire execution locks to prevent the same task from being executed repeatedly. The modeling engine prioritizes creating routes, control points, and control lines based on component dependencies, followed by the superstructure, substructure, foundation, cable or arch rib system, and auxiliary components. For each component, it sequentially performs template matching, template instance creation, unique identifier writing, parameter writing, input reference binding, geometry update, assembly insertion, and result validation. A checkpoint is written after each recoverable stage is completed; if a retryable exception occurs, it continues from the most recent checkpoint; if a data or template unavailability exception occurs, the task terminates and the specific conflict is reported.

[0117] S63: After modeling is completed, output a parametric whole bridge model and at least one lightweight result from 3DXML, FBX, or 3D Tiles, and save the modeling log, version information, and input summary. The client can query the status, progress, error information, and result location based on the task identifier.

[0118] In this step, the client does not need to maintain a persistent connection with the cloud after submitting the task.

[0119] After modeling is completed, if key bridge parameters or derived design parameters need to be modified, the system identifies the affected derived design parameters, model-driven parameters, and component instances based on the parameter dependency graph and the source tracking records. For unaffected components, the original version is retained; for affected components, the model is re-deduced, re-verified, and updated. A new parameter version and model version are generated after the update, and the differences between the old and new versions are recorded.

[0120] Example 3 This embodiment is a specific implementation of the bridge cloud modeling method based on three-layer parameter derivation described in Embodiment 2, taking a three-span continuous rigid frame bridge as the implementation object. The specific content is as follows: First, input the bridge type, span combination, bridge deck width, control station number, route data, main girder structural type, pier type, and general diagram identifiers. The first-layer algorithm first establishes parameter nodes for the main girder, piers, foundations, supports, and auxiliary structures based on the bridge type and span. Then, it calls rules in topological order to obtain derived design parameters such as beam segment division, cross-sectional control dimensions, pier dimensions, and pile cap and pile foundation arrangement, and records the rule number and version of each parameter. For the arrangement of diaphragms or beam segments, a quantity-spacing back-calculation mechanism is used to ensure that the first and last components meet the end-reservation and closure constraints.

[0121] Subsequently, the second-layer algorithm maps the control station numbers of each component to the three-dimensional axis of the route, and generates positioning points, positioning lines and local coordinate directions by combining horizontal and vertical offsets. Then, the engineering units are uniformly converted into template units, the component types and parameter ranges are compared with the template metadata, the template is selected and the model driving parameters are generated.

[0122] Finally, the cloud-based modeling engine sequentially creates control elements, main beam segments, piers, abutments, pile foundations, supports, and auxiliary components. After assembly, it checks the component quantity, unique identifiers, input bindings, adjacent connections, and overall bounding boxes, generating a model like... Figure 6 The three-dimensional model shown.

[0123] If the bridge deck width changes, the system only recalculates the cross sections, lateral positioning, template parameters and corresponding components affected by the width along the dependency relationship, without recreating unrelated foundation components.

[0124] The above continuous rigid frame bridge is only an example. For conventional beam bridges, suspension bridges, cable-stayed bridges, and arch bridges, components such as main cables and suspenders, towers and stay cables, and arch ribs and hangers can be generated by replacing the bridge type rule set, component decomposition rules, and corresponding template library. Their three-layer parameter structure, two-layer algorithm, spatial positioning, and cloud task execution process are the same.

[0125] Example 4 like Figure 7 As shown, a bridge cloud modeling system based on three-layer parameter derivation includes at least one processor, a memory communicatively connected to the at least one processor, and at least one input / output interface communicatively connected to the at least one processor. The memory stores instructions executable by the at least one processor, which, when executed, enables the at least one processor to perform the bridge cloud modeling method based on three-layer parameter derivation described in the foregoing embodiments. The input / output interface may include a display, keyboard, mouse, and USB interface for inputting and outputting data.

[0126] Furthermore, this bridge cloud modeling system based on three-layer parameter deduction can be a bridge cloud modeling system based on three-layer parameter deduction that can perform deep information recognition, such as desktop computers, mobile phones, tablet computers, and wearable devices.

[0127] Furthermore, the processor may include one or more processing cores. The processor connects various parts of the bridge cloud modeling system based on three-layer parameter derivation using various interfaces and lines. It executes various functions and processes data within the three-layer parameter derivation-based bridge cloud modeling system by running or executing instructions, programs, code sets, or instruction sets stored in memory, and by calling data stored in memory. Optionally, the processor may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor may integrate one or more of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the displayed content; and the modem handles wireless communication. It is understood that the modem may also be implemented separately as a communication chip, without being integrated into the processor.

[0128] The memory may include random access memory (RAM) or read-only memory (ROM). The memory can be used to store instructions, programs, code, code sets, or instruction sets, such as instructions or code sets used to implement the bridge cloud modeling method based on three-layer parameter deduction provided in this application embodiment. The memory may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for implementing at least one function, instructions for implementing the various method embodiments described above, etc. The data storage area may also store data created during use by the bridge cloud modeling system based on three-layer parameter deduction (such as a mapping table of modulation sequences and depths, image data, spectrogram data, etc.).

[0129] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory, magnetic disks, or optical disks.

[0130] When the integrated units of the present invention are implemented as software functional units and sold or used as independent products, they can also be stored in a computer-readable storage medium. The computer-readable storage medium stores program code, which can be called by a processor to execute the methods described in the above method embodiments. Based on this understanding, the technical solution of the embodiments of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer system (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes electronic memory such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or ROM. Optionally, the computer-readable storage medium includes a non-transitory computer-readable storage medium. The computer-readable storage medium has storage space for program code that executes any of the method steps described above. This program code can be read from or written to one or more computer program products. The program code can be compressed, for example, in an appropriate form.

[0131] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A bridge cloud-based modeling method based on three-layer parameter extrapolation, characterized in that, Includes the following steps: S1: The client receives and verifies the key parameters of the bridge, and generates a project identifier and parameter version; S2: Construct a three-layer parameter structure and source tracking records; S3: Derive the derived design parameters based on the key bridge parameters; S3 includes the following steps: S31: Based on the reference relationships of each rule in the rule base, establish the prerequisite dependencies between the key parameters of each bridge; The rule base is established based on engineering specifications, engineering experience, general drawing data, and bridge types. S32: Construct a parameter dependency graph using the key bridge parameters as nodes and the preceding dependencies as directed edges; S33: Based on the rule base, the key parameters of the bridge, and the parameter dependency graph, obtain the deduction path and candidate value set corresponding to the current bridge; S34: Establish a set of hard constraints, remove the values ​​in the candidate set that do not meet the set of hard constraints, select components according to preset priorities and adjustment mechanisms, and output the selection results as derived design parameters. The parameters in the set of hard constraints include at least: mandatory specification constraints, immutable project boundaries, geometric feasibility constraints, and template allowable range; The preset priorities are as follows: manually confirmed values ​​that have passed verification, existing design values ​​of the project, general drawing matching values, standard recommended values, engineering experience recommended values, and system default values; When multiple different candidate values ​​exist for the same priority, a conflict is recorded and manual confirmation is requested; when there is no valid candidate value, the parameter is marked as missing and subsequent nodes that depend on that parameter are stopped. The adjustment mechanism is as follows: For candidate values ​​corresponding to quantity and spacing, first calculate the corresponding candidate quantity of the component based on the arable length of the corresponding component, the reserved distance at the end, the target spacing, and the allowable spacing range; then calculate the actual spacing based on the candidate quantity; then adjust the candidate quantity sequentially based on the relationship between the actual spacing and the allowable spacing range until the actual spacing falls into the allowable spacing range. If it cannot fall into the allowable spacing range after adjustment, output an uncoordinated conflict. The adjustment mechanism is used for the closed arrangement of repeating components; the repeating components include: cables, hangers, diaphragms, beam segments, and supports; S4: Derive the model driving parameters and component instance set based on the derived design parameters; store the bridge key parameters, the derived design parameters, and the model driving parameters into the three-layer parameter structure; S5: Generate unified modeling data based on the project identifier, the parameter version, the three-layer parameter structure, and the component instance set; S6: Send the unified modeling data to the cloud for modeling, output the parameterized whole bridge model, and save the modeling record.

2. The bridge cloud modeling method based on three-layer parameter extrapolation according to claim 1, characterized in that, The key bridge parameters mentioned in S1 include any one or more of the following: bridge type, bridge name, left and right lane markings, control station number, span combination, bridge deck width, route data markings, component type, and general drawing markings. The verification of the key parameters of the bridge is as follows: verifying the integrity of the fields, units, numerical range, chainage continuity, and data version.

3. The bridge cloud modeling method based on three-layer parameter extrapolation according to claim 1, characterized in that, S2 includes the following steps: S21: Construct a three-layer parameter structure; The three-layer parameter structure includes: first layer key bridge parameters; second layer derived design parameters; and third layer model-driven parameters. S22: Construct the data fields, encoding rules, inter-layer mapping relationships, and source tracing rules for each layer's parameters.

4. The bridge cloud modeling method based on three-layer parameter extrapolation according to claim 1, characterized in that, S33 includes the following steps: S331: Perform loop detection and topological sorting on the parameter dependency graph; If a circular dependency is found, the deduction branch involving that loop is stopped, and the parameter code, rule number, and rule version constituting the loop are output; if no circular dependency exists, the deduction path is determined according to the topological sort. S332: Based on the deduction path, execute the rule set in the rule base on the key parameters of the bridge to obtain a set of candidate values.

5. The bridge cloud modeling method based on three-layer parameter extrapolation according to claim 1, characterized in that, S4 includes the following steps: S41: Based on the derived design parameters, determine the type, quantity, and assembly level of the component to be generated, and obtain the corresponding component instance identifier parameters; The component instance identification parameters include: component instance identifier, component type, component template identifier, parent instance identifier, and assembly level; S42: Calculate the positioning point of each component instance corresponding to the component instance identifier parameter, and generate positioning line data for each linear component; output the positioning point and the positioning line data as spatial positioning parameters. The linear components include: straight line components, circular arc components, and spline curve components; The positioning line data includes at least the following parameters: curve type, start point, end point, control point or discrete point, parameter domain, start and end tangential directions, direction markings, and allowable error. S43: Perform data standardization mapping and parameter validity verification on the derived design parameters according to the preset template parameter mapping table; and after performing rounding or geometric coordination on the reconcilable parameters, output them together with the component instance identifier parameters and the spatial positioning parameters as model driving parameters; Among them, templates are rematched for uncoordinated parameters, and conflict information is output if no applicable template is found. The data standardization mapping includes: parameter name mapping, unit conversion, data type conversion, coordinate direction conversion, and template version conversion; The parameter validity verification includes: verifying required inputs, parameter range, geometric updability, and template applicability. The conflict information includes: component identifier, parameter code, actual value, allowed range, and suggested handling method; S44: Assign a unique identifier within the project to each component in the model-driven parameters and establish a set of relationships; The set of relationships includes: inclusion relationships, connection relationships, adjacency relationships, and location dependency relationships; S45: Generate a set of component instances based on the bridge type and the component decomposition rules in the rule base, and output the model driving parameters and the set of component instances; S46: Store the key bridge parameters, the derived design parameters, and the model-driven parameters into the three-layer parameter structure.

6. The bridge cloud modeling method based on three-layer parameter derivation according to claim 1, characterized in that, The unified modeling data in S5 includes at least: project identifier, parameter version, rule version, route data version, component template identifier and version, assembly level, model-driven parameters, target output format, and verification summary; The unified modeling data is recorded in JSON, XML, or a database.

7. The bridge cloud modeling method based on three-layer parameter extrapolation according to claim 1, characterized in that, S6 includes the following steps: S61: The cloud receives the unified modeling data and creates a modeling task; S62: The modeling engine models according to the component dependencies based on the modeling task; S63: After modeling is completed, output the parameterized whole bridge model and save the modeling log, version information and input summary.

8. The bridge cloud modeling method based on three-layer parameter extrapolation according to claim 1, characterized in that, When the key parameters of the bridge or the derived design parameters need to be modified, the affected derived design parameters, model-driven parameters and component instances are identified according to the parameter dependency graph and the source tracking records. For unaffected components, the original version is retained; for affected components, the model is re-deduced, re-verified, and updated. After the update, a new parameter version and model version are generated, and the difference between the old and new versions is recorded.

9. A bridge cloud-based modeling system based on three-layer parameter extrapolation, characterized in that, It includes at least one processor and a memory communicatively connected to the at least one processor; the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform a bridge cloud modeling method based on three-layer parameter derivation according to any one of claims 1 to 8.

Images