A steel structure calculation scheduling method and system based on dependency coding

Abstract

The application provides a steel structure calculation scheduling method and system based on dependency coding, and relates to the technical field of building engineering structure calculation and information processing. The calc_dependency and knowledge_code fields are extended on the basis of the standard MCP protocol, which are used for coding the data dependency, state dependency and trigger dependency relationship between calculation functions, and binding the corresponding specification clauses. The dependency relationship is analyzed to construct a directed acyclic graph, the dynamic priority combining in-degree and depth is calculated, the nodes without dependency are executed in parallel, the nodes with dependency are executed in series and the data is transmitted. The calculation results are checked in two dimensions through the specification review and logical consistency review driven by the knowledge base, and when the check fails, the feedback correction mechanism is formed by automatically searching for correction suggestions. Through the Prompt engineering injection protocol rule, the LLM can generate standard messages without retraining, and the automatic scheduling and compliance guarantee of the steel structure multi-function collaborative calculation are realized.

Description

Technical Field

[0001] This invention relates to the field of structural calculation and information processing technology in building engineering, specifically to a steel structure calculation scheduling method and system based on dependency coding. Background Technology

[0002] In the design, review, and construction phases of steel structure engineering, the verification of node connections (such as beam-column connections) is a core step in ensuring structural safety. These verifications typically involve multiple calculation functions, including anchor bolt bearing capacity verification, end plate thickness verification, weld strength verification, and node domain shear resistance verification. These functions are not logically isolated but rather follow a strict data flow and execution order: for example, the anchor bolt bearing capacity verification must be completed first to obtain the column base reaction force before this reaction force can be passed as an input parameter to the foundation bearing capacity verification; the external load distribution required for end plate verification often depends on the bolt force distribution results output by the anchor bolt verification.

[0003] In traditional workflows, engineers must manually execute each calculation program sequentially, copying intermediate data (such as reaction force, thickness, and stress ratio) generated in the previous step to the input interface of the next step. This approach is not only highly repetitive and labor-intensive, but also prone to design deviations due to parameter copying errors and unit conversion mistakes. With the application of language models in engineering, the technology of using Model Context Protocols (MCPs) as a communication framework to translate natural language commands into structured tool calls is gradually emerging. However, existing general MCP message structures reveal the following significant shortcomings when handling multi-function collaborative calculations for steel structures: First, there is a lack of a mechanism for representing dependencies between functions. The general MCP message does not define a dedicated field to describe "which output field of function A will serve as which input parameter of function B," preventing the system from automatically parsing data flow logic. Furthermore, the existing protocol is powerless when there are conditional triggering relationships such as "triggering a hardening check if utilization exceeds limits."

[0004] Secondly, the calculation logic is disconnected from the mandatory standard provisions. Every step of the steel structure verification must strictly follow the "Steel Structure Design Standard" GB 50017-2017 and other standards. The existing MCP message lacks a mechanism to bind the calculation task to the specific clause number on which it is based, making it impossible to automatically verify the source of the calculation results. During compliance audits, manual verification of the clauses is still required.

[0005] Third, the scheduling mechanism lacks dynamism. Existing MCP-based computation scheduling mostly uses fixed linear pipelines, which cannot dynamically adjust the serial or parallel strategy based on topological attributes such as in-degree and depth in the task graph. When multiple independent basic components are being verified, the system still queues them serially, resulting in idle computing resources.

[0006] Fourth, the verification of calculation results is isolated and the handling of anomalies is one-way. The existing process terminates after obtaining the numerical results, lacking automatic verification based on standard design indicators, and also lacking the ability to proactively retrieve and provide engineering-significant corrective measures (such as suggesting increasing the bolt diameter to a certain specification) and generate feedback for recalculation when the verification fails. Summary of the Invention

[0007] The technical problem to be solved by this invention is: in existing multi-function collaborative computing scheduling, due to the lack of semantics in MCP messages, the inability to automatically resolve data dependencies and conditional trigger dependencies between functions, the inability to bind traceability specification clauses, as well as the rigidity of scheduling strategies and the lack of feedback mechanisms for exception handling, a computing method and system that can explicitly encode dependency relationships and specification clauses and realize dynamic priority hybrid scheduling and structured correction is provided.

[0008] To achieve the above objectives, the technical solution adopted by the present invention is as follows: A steel structure computation scheduling method based on dependency coding includes the following steps: Step A: Construct a semantically enhanced MCP extension protocol message. The protocol header of this message contains a calc_dependency field, which uses a precondition operator to define the dependency type and data flow between tasks. The protocol body of this message contains a knowledge_code field, which establishes a mapping relationship with the clauses in the steel structure code knowledge base. Step B: Parse the `calc_dependency` field and construct a directed acyclic graph (DAG). When the overall depth of the DAG is greater than 0 and the maximum in-degree is also greater than 0, use the formula based on the in-degree and depth of each node in the DAG. Calculate the dynamic execution priority of each task ,in, This represents the value obtained from the schedule_priority field in the protocol header, after being normalized to the [0,1] range using the Min-Max method. Based on the priority normalized value, Let i be the in-degree of node i. The maximum in-degree in this directed acyclic graph. Let be the longest path depth of node i. Let α be the overall depth of the directed acyclic graph, β be the weight coefficients, and α + β + γ = 1. When the overall depth of the directed acyclic graph is 0, the depth term takes the value of 0. When the maximum in-degree is 0, the in-degree term takes the value of 0. Step C: Based on dynamic priority and dependencies, tasks with direct predecessor-successor relationships are executed sequentially in topological order. After the predecessor task is completed, the output data is extracted through the returned MCP response message and injected into the input parameters of the successor task. Tasks with zero in-degree and no resource conflicts are scheduled in parallel in batches. Tasks with zero in-degree but resource conflicts are scheduled sequentially according to priority. Step D: After the calculation results are returned, design indicators are extracted from the standard knowledge base based on the knowledge_code field for standardization review, and logical consistency review between multiple results is performed based on the threshold field in the message; if any review fails, a correction suggestion is retrieved from the correction strategy knowledge base using the error code and knowledge_code field as a joint index, and the correction suggestion is encapsulated in the MCP exception extension layer and returned.

[0009] On the other hand, the present invention also provides a steel structure calculation scheduling system based on dependency coding, comprising: The MCP protocol extension module is configured to generate and parse semantically enhanced MCP extension protocol messages. The protocol header of the message contains a calc_dependency field, which uses a precondition operator to define the dependency type and data flow between tasks. The protocol body of the message contains a knowledge_code field, which establishes a mapping relationship with specific clauses in the steel structure code knowledge base. The dependency resolution and scheduling module is configured to parse the `calc_dependency` field and construct a directed acyclic graph (DAG). When the overall depth of the DAG is greater than 0 and the maximum in-degree is also greater than 0, the module uses a formula based on the in-degree and depth of each node in the DAG. Calculate the dynamic execution priority of each task ,in, This represents the value obtained from the schedule_priority field in the protocol header, after being normalized to the [0,1] range using the Min-Max method. Based on the priority normalized value, Let i be the in-degree of node i. The maximum in-degree in this directed acyclic graph. Let be the longest path depth of node i. Let α, β, and γ be the overall depth of the directed acyclic graph, and let α, β, and γ be weight coefficients, with α + β + γ = 1. When the overall depth of the directed acyclic graph is 0, the depth term is 0. When the maximum in-degree is 0, the in-degree term is 0. According to dynamic priority and dependency, tasks with in-edges are executed serially, and the output data of the preceding task is transmitted and injected into the input parameters of the subsequent task through the MCP heartbeat message. Tasks with zero in-degree and no resource conflicts are scheduled in parallel batches. The steel structure code knowledge base is used to store code clauses, design indicators for the clauses, and templates for correction strategies, all of which have a knowledge_code. The dual-dimensional verification module is configured to extract design indicators from the standard knowledge base based on the knowledge_code for standardization review, and to perform logical consistency review between multiple results based on the threshold field in the message. The exception handling module is configured to retrieve a correction suggestion from the correction strategy knowledge base using the error code and knowledge_code as a combined index when any review fails, and then encapsulate the correction suggestion in the MCP exception extension layer and return it.

[0010] Compared with the prior art, the beneficial effects of the present invention are: First, by introducing the calc_dependency field, the implicit data flow from anchor bolt calculation output bolt force to end plate calculation input load is transformed into an explicit operator that can be parsed by the machine, eliminating the step of manually transmitting intermediate data and reducing the parameter transmission error rate.

[0011] Second, by using the knowledge_code field to deeply bind each calculation to specific clauses of standards such as GB 50017-2017, the subsequent verification module can directly extract the design indicators of the clauses for comparison. The calculation results are accompanied by traceable standard basis, which meets the requirements of engineering audit for compliance proof.

[0012] Third, the dynamic priority algorithm, which combines the in-degree and depth of the task graph, enables the key tasks that serve as convergence points of multiple paths to be reasonably scheduled. At the same time, it performs batch processing on independent parallel tasks, which can significantly reduce the total time of multi-node verification compared to fully serial static scheduling.

[0013] Fourth, a dual-dimensional verification and correction retrieval mechanism has been established. When the bolt utilization rate exceeds the standard design index or the end plate thickness is mismatched, the system not only reports the anomaly, but also automatically retrieves specific engineering correction strategies such as "suggest increasing the bolt diameter to M24" or "adding stiffening ribs", and returns the corrected parameters in a packaged form, supporting real-time recalculation after parameter adjustment.

[0014] Other features and advantages of the embodiments of the present invention will be described in detail in the following detailed description section. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of the hierarchical structure of the semantically enhanced MCP extension protocol message; Figure 2 The flowchart shows the steel structure calculation and scheduling method based on dependency coding proposed in this invention. Figure 3 This is a flowchart illustrating the two-dimensional verification and closed-loop correction process. Figure 4 This is a diagram of the steel structure computation scheduling system architecture based on dependency coding proposed in this invention. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of the present invention clearer, the specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings. It should be noted that the specific embodiments described herein are only for explaining the present invention and are not intended to limit the present invention.

[0017] The core of this invention lies in providing a steel structure computation scheduling method based on dependency coding. Starting from receiving the user's computation requirements, generating structured extended protocol messages, performing dynamic priority hybrid scheduling based on dependency graphs, and finally performing dual-dimensional verification of the computation results and retrieving correction suggestions in case of anomalies, this constitutes a complete processing process from input to feedback.

[0018] It should be noted that the data transmission and instruction interaction between the steps of the method proposed in this invention are all based on a set of semantically enhanced MCP extended protocol messages. Figure 1The hierarchical structure of this message is shown. This message extends the standard MCP protocol to four layers. The first layer is the protocol header (MCP_Header), containing the fields scene_id, param_id, schedule_priority, calc_dependency, retry_policy, status_code, and timeout. calc_dependency is a string array used to encode the dependencies between tasks, and retry_policy is a JSON object used to define the retry policy. The second layer is the protocol body (MCP_Payload), containing the fields basic_params, knowledge_code, calc_threshold, threshold_merge_rule, calc_rule, and knowledge_trace. knowledge_code is a two-dimensional string array used to bind the specification clauses upon which the computation task is based. The third layer is the response body (MCP_Response), which carries the output results, execution status codes, and intermediate data returned after each computation function has completed execution. The fourth layer is the exception extension layer (MCP_Error), which contains the fields error_code, modify_suggest, and related_param, used to return correction suggestions to the caller when verification fails. Below, following the actual processing sequence of the system, we will explain the specific implementation of each step, starting from message generation.

[0019] like Figure 2 As shown, the following describes in detail each step of the steel structure calculation scheduling method based on dependency coding proposed in this invention, according to the actual execution order of the process.

[0020] Step A: Generate semantically enhanced MCP messages; This step implements a lightweight "end-to-cloud-to-end" protocol conversion mechanism. The entire conversion and execution process is as follows: The user inputs computational requirements described in natural language on an edge device (such as a tablet terminal or industrial control computer) at the construction site; the language model deployed on the edge or lightweight cloud converts the natural language request into a structured MCP request message according to a preset Prompt instruction set; after receiving the message, the scheduling module executes subsequent steps of dependency resolution, hybrid scheduling, two-dimensional verification, and exception handling; finally, the MCP response message or exception message is parsed into natural language by the language model and displayed to the user. The above process achieves decoupling of language intelligence and computational rigidity: the language model is responsible for understanding the user's intent and filling in the message template, while the scheduling module and verification module perform computational orchestration and rule verification based on deterministic algorithms, and the two are connected through an extended MCP message interface. When the protocol rules need to be updated, only the Prompt instruction set text needs to be modified, without retraining the language model or changing the algorithm logic of the scheduling module.

[0021] In the message generation stage, the system supports two implementation methods. In one implementation method, users can directly configure the node type, material specifications, internal force design values, and execution logic to be verified through interface options. The message generation module fills the above configuration items into the basic_params field of MCP_Payload according to the preset mapping rule table, and automatically matches the corresponding knowledge_code and calc_dependency operators according to the selected verification items to assemble a complete extended MCP message.

[0022] In another implementation, the user can input a natural language description. The system then extracts parameters from the statement and generates a formatted MCP message using a language model deployed at the edge or in a lightweight cloud, along with the following Prompt instruction set. This Prompt instruction set injects structured text into the model context, and its core content is as follows: You are a steel structure engineering calculation and scheduling assistant, focusing on beam-column joint connection verification. User natural language requests need to be converted into JSON MCP request messages conforming to the following specifications: 1. Scene_id format: GJ-{scene abbreviation}-{serial number}, such as GJ-MJNT-001 indicating the connection of the beam-column node of the portal frame.

[0023] 2. Param_id format: PARAM-{YYYYMMDD}-{serial number}.

[0024] 3. Extract the required functions from the user description and fill them into the function_type array.

[0025] 4. Based on the function type, match the knowledge_code (two-dimensional array) from the standard knowledge base. For example, bolt verification corresponds to [["GB50017-2017_11.4.2_bolt_shear"]].

[0026] 5. If the user describes the computation order or dependencies, generate a calc_dependency array using the DATA / STATUS / TRIGGER syntax.

[0027] 6. Extract the parameters provided by the user and fill them into basic_params; extract the security requirements and fill them into calc_threshold.

[0028] After the Prompt project and before the scheduling module, the system sets up an MCP message verification and repair middleware. This middleware performs the following processing: First, syntax validation. Use JSON Schema to validate whether the required fields of the message are complete, whether the data types of each field are correct, and whether each operator in the calc_dependency array conforms to BNF syntax rules.

[0029] Second, automatic repair. Common problems found during validation are automatically corrected, including: when a required field is missing, the corresponding default value is automatically filled in according to scene_id, such as 5 for schedule_priority; when the calc_dependency expression is non-compliant, it attempts to complete it by splitting it with regular expressions, and if it cannot be repaired, the dependency is deleted and a warning log is recorded; when the knowledge_code format is incorrect, it attempts to automatically add the corresponding specification number prefix.

[0030] Third, handling of repair failures. If the message still does not meet the format requirements after the above automatic repair, an error message will be returned, requiring the language model to regenerate the message. The maximum number of retries for regeneration is 2.

[0031] Fourth, the middleware's repair rule set can be updated during system operation without restarting the service.

[0032] The message instance obtained after the above processing serves as the input data for subsequent steps. A complete example is given below: { "MCP_Header": { "scene_id": "GJ-MJNT-001", "param_id": "PARAM-20260509-001", "schedule_priority": 1, "calc_dependency": [ "DATA: bolt_check.bolt_force_distribution ->endplate_calc.input_bolt_forces", "DATA: endplate_calc.endplate_thickness ->weld_calc.connected_part_thickness", "TRIGGER: bolt_check.utilization_ratio>1.0 ->bolt_resize" ], "retry_policy": { "max_retries": 3, "interval_ms": 1000, "backoff_multiplier": 2.0, "timeout_ms": 60000 }, "status_code": 0, "timeout": 60 }, "MCP_Payload": { "basic_params": { "bolt_grade": "10.9", "bolt_diameter": 20, "bolt_count": 8, "endplate_material": "Q355B", "endplate_thickness": 25, "weld_size": 8, "moment": 180, "shear": 120 }, "knowledge_code": [ ["GB50017-2017_11.4.2_bolt_shear"], ["GB50017-2017_11.5.3_endplate_bending"], ["GB50017-2017_11.2.1_fillet_weld"] ], "calc_threshold": { "utilization_ratio_max": 1.0, "endplate_deflection_limit": "L / 250", "weld_stress_ratio_max": 1.0 }, "threshold_merge_rule": "USER_OVERRIDE", "calc_rule": "Portal Frame Light Steel", "knowledge_trace": true }, "MCP_Response": {}, "MCP_Error": {} } Definition of message core extended fields The `calc_dependency` field is used to encode dependencies between tasks, and its syntax follows Backus Normal Form (BNF): <pre_operator> ::=<dependency_type> ":"<condition_expr> ?<source_field> "->"<target_field> ? <dependency_type> ::= "DATA" | "STATUS" | "TRIGGER" | "OR_TRIGGER" | "AND_TRIGGER" <source_field> ::=<function_output_field> <target_field> ::=<function_input_param> <condition_expr> ::=<source_field> <comparison> <value> <comparison>::= ">" | "<" | ">=" | "<=" | "==" | "!=" The specific meanings of dependency types and their application scenarios in beam-column joints are shown in Table 1.

[0033] Table 1 Dependency Types and Project Semantics The `knowledge_code` field is a two-dimensional string array, encoded in the format "standard number_chapter number_article number_verification type". For example, "GB50017-2017_11.4.2_bolt_shear" points to Article 11.4.2 of GB 50017-2017 regarding the shear calculation of high-strength bolts. This code is used as the primary key for knowledge base retrieval.

[0034] Step B: Construction and loop detection of the directed acyclic graph for the task; After receiving the message generated in step A, the scheduling module extracts each operator string from the `calc_dependency` array and performs parsing and construction. Specifically, for each operator, the dependency type is obtained by separating it with a colon, and then the source and target function names are located using "->". Taking "DATA:bolt_check.bolt_force_distribution->endplate_calc.input_bolt_forces" as an example, the source node is parsed as "bolt_check" and the target node is "endplate_calc". A directed edge is added to the graph, with the edge attribute record type being DATA and the field mapping "bolt_force_distribution→input_bolt_forces". After all operators are parsed, the directed task graph G(V,E) is formed.

[0035] Subsequently, the scheduling module runs a topology sorting algorithm to check for cycles in the graph. If a circular dependency exists, such as a bidirectional dependency between bolt verification and endplate verification, scheduling is immediately terminated and error code 4.01 is returned. Simultaneously, the list of function names on the cycle is written to the MCP_Error message. If the graph is a valid directed acyclic graph, dynamic priority calculation is performed, as follows: When the overall depth of the directed acyclic graph is greater than 0 and the maximum in-degree is also greater than 0, calculate the dynamic execution priority for each task node i in the graph. The formula is: in, This represents the value obtained from the schedule_priority field in the protocol header, after being normalized to the [0,1] range using the Min-Max method. This is the base priority normalized value; a larger value indicates a higher base priority. Let i be the in-degree of node i. The maximum in-degree in this directed acyclic graph. Let be the longest path depth of node i. Let α be the overall depth of the directed acyclic graph (DAG), β be the weighting coefficients, and α + β + γ = 1. Preferably, α = 0.5, β = 0.2, and γ = 0.3. When the overall depth of the DAG is 0, the depth term is 0; when the maximum in-degree is 0, the in-degree term is 0. This formula design ensures that nodes with higher in-degrees (which need to wait for more predecessors) receive a reasonable relative priority, while nodes with higher depths achieve higher rankings by quickly releasing downstream computation.

[0036] Step C: Hybrid scheduling execution; Based on the priority ranking result calculated in step B, the scheduling module adds all nodes with an in-degree of 0 to the ready queue and schedules them in descending order of priority. The execution strategy is as follows: (1) For nodes with a non-zero in-degree, the sequential execution relationship is strictly maintained. After the current driver task is completed and returns an MCP response message, the scheduling module extracts the source_field output value specified by the edge attribute from the response, fills it into the corresponding target_field position in the request message of the successor node according to its mapping relationship, and then wakes up the successor node. For example, after the bolt verification is completed and bolt_force_distribution is output, this value is injected into the input_bolt_forces parameter of the end plate verification, and the end plate verification can be executed.

[0037] (2) For multiple nodes with an in-degree of 0 and no resource conflicts, parallel batch scheduling is adopted. Resource conflict detection is based on the resource_requirements field, which is optional in the MCP Payload for nodes, as shown in the example below: "resource_requirements":{"cpu_cores":1,"db_conn":1} The scheduling module maintains a global resource occupancy table. For two nodes to be executed in parallel, if their required resource types have no overlap, or if their resource types overlap but the current remaining resources meet the sum of their requirements, then they can be executed in parallel. Otherwise, if the two nodes are competing for resources, the node with the lower priority is kept in the ready queue until the required resources are released, and only the node with the higher priority is added to the parallel channel. During parallel execution, the module sends requests to multiple function instances simultaneously through the MCP multiplexing channel and waits for all parallel tasks to complete before continuing downstream scheduling. A 30-second timeout automatic release mechanism is set for resource locks to prevent deadlock.

[0038] During the execution of long-duration computations, the scheduling module monitors task progress via heartbeat messages. A heartbeat message is a periodically sent status synchronization message, sent by the computation function to the scheduling module every 5 seconds in the following format: { "function_type": "bolt_check", "execution_progress": 0.75, "param_status": { "input_received": true, "output_generated": false }, "estimated_remaining_ms": 2000, "status_code": 0 } The scheduling module maintains a default 60-second timeout timer for each call (which can be overridden by the `timeout` field in the header). If no heartbeat or completion message is received within the timeout period, and the message contains a `retry_policy`, the module retryes according to the policy. The retry policy field is a JSON object containing `max_retries` (maximum number of retries, default 3), `interval_ms` (initial retry interval, default 1000 milliseconds), `backoff_multiplier` (backoff multiplier, default 2.0), and `timeout_ms` (timeout for a single retry). Before the first retry, the module clears some intermediate states of the node and resends the request at exponentially increasing intervals. If the maximum number of retries is reached and the call still fails, the entire DAG enters exception handling, returning error code 501 along with a list of failed nodes.

[0039] In addition, the scheduling module maintains a consecutive failure count for each function type. When the number of consecutive failures for a certain function type reaches a set threshold (3 times by default), the circuit breaker mechanism is triggered. During the circuit breaker period (5 minutes by default), all calls to that function directly return error code 502 to avoid cascading failures. After the circuit breaker period ends, it enters a half-open state, allowing one trial call. If successful, the circuit breaker closes; if it fails, it re-enters the circuit breaker.

[0040] Step D: Two-dimensional verification and correction of the search.

[0041] After all functions have completed execution and returned results, the two-dimensional verification module starts. The verification process is as follows: Figure 3 As shown.

[0042] (1) Normative Review. The module extracts the calculation results and knowledge_code from the response. Using knowledge_code as the key, it retrieves the design parameters of the corresponding clauses from the steel structure code knowledge base. For example, for bolted shear connections, it retrieves the bolt bearing capacity design value and strength design value; for end plate bending, it retrieves the allowable deflection value. Before comparison, the module checks the threshold_merge_rule field in the message (with a value of STRICT_KNOWLEDGE, USER_OVERRIDE, AUTO_MIN, or AUTO_MAX) to determine the rules for using the design parameters. If the user does not explicitly set this field, the system defaults to the USER_OVERRIDE rule and generates a warning log to record this behavior. The comparison adopts a tolerance-based approach. For numerical design parameters, |calculated value - design parameter| ≤ ε_limit, where ε_limit defaults to 5% of the design parameter; for utilization rate parameters, it checks whether they are less than or equal to the specified upper limit of 1.0. If any discrepancy occurs, a corresponding error code is generated, such as 3_01 representing bolt bearing capacity exceeding the limit.

[0043] (2) Logical consistency check. The module has built-in multiple logical rules for beam-column node connections, some of which are shown in Table 2.

[0044] Table 2 Examples of Consistency Rules The module checks each rule individually, recording violations and ultimately calculating the consistency score C = 1 - (number of violating rules / total number of rules). If the `calc_threshold` in the message specifies `consistency_threshold`, this value is used as the judgment standard; otherwise, the system automatically maps according to the security level (Level 1 security requires C ≥ 0.9, Level 2 ≥ 0.8, Level 3 ≥ 0.65). The system also supports a historical statistics mode, i.e., dynamically calculating the threshold = the average consistency score of the most recent 100 successful tasks for the scene type corresponding to the current `scene_id` minus its standard deviation. This threshold is updated every 100 tasks completed. The system defaults to the standard level mapping mode, but allows switching to the other two modes via configuration files. When C falls below the selected threshold, a logical consistency exception is triggered, returning error code 4_02, and recording the actual threshold mode and value used.

[0045] (3) Correction strategy retrieval and encapsulation. When any dimension verification fails, the exception handling module uses "error code#knowledge_code" as a combined index to perform an exact match in the correction strategy knowledge base. An example of the structure of the correction library is shown in Table 3.

[0046] Table 3 Examples of Correction Strategy Knowledge Base If an exact match fails, a limited backtracking search is performed, with the following steps: The first step is to start with the complete knowledge_code and delete the last-level fields one by one. The deletion order is as follows: the first level deletes the function type (such as "_bolt_shear"), keeping "standard number_chapter number_article number"; the second level deletes the article number (such as "_11.4.2"), keeping "standard number_chapter number"; the third level deletes the last digit of the chapter number (such as "_11"), keeping "standard number"; until only the standard number (such as "GB50017-2017") remains.

[0047] The second step is to retrieve the newly generated code value from the knowledge base after each level is deleted.

[0048] The third step is to set the termination condition: if the search is successful at a certain level, the corresponding correction suggestion will be returned; if the search back to the last specification number is still unmatched, the search will stop, the general suggestion "Please check the input parameters or contact the administrator" will be returned, and error code 99 will be set.

[0049] The maximum backtrace depth of the above backtrace process is fixed at 5 levels, with a maximum of 5 steps from the original knowledge_code to the pure specification number to prevent infinite loops. The code value generated at each step in the entire backtrace path is recorded in the MCP_Error.backtrace field for debugging and auditing.

[0050] Example: The original knowledge_code is "GB50017-2017_11.4.2_bolt_shear". The backtracking path generates the following code values ​​sequentially and retrieves them one by one: GB50017-2017_11.4.2 GB50017-2017_11 GB50017-2017 If none of the above are found, stop backtracking and return to the general suggestion.

[0051] The retrieved array of suggested corrections and the list of related parameters are encapsulated in the `modify_suggest` and `related_param` fields of the `MCP_Error` message and returned to the calling end along the original path with the error message. Engineers or upper-level systems can adjust the parameters in `basic_params` based on the suggestions (e.g., changing `bolt_diameter` to 24) and re-initiate the calculation request, thus forming a complete processing flow of "calculation-verification-failure-suggestion-correction-recalculation".

[0052] In some implementations, refer to Figure 4 The system for implementing the steel structure calculation scheduling method based on dependency coding proposed in this invention includes: an MCP protocol extension module, a dependency resolution and scheduling module, a steel structure specification knowledge base, a two-dimensional verification module, and an exception handling module, as detailed below: The MCP protocol extension module, serving as the system's entry point, is configured to generate and parse enhanced MCP messages containing the calc_dependency and knowledge_code fields, providing a standardized data carrier for subsequent scheduling and verification.

[0053] The dependency resolution and scheduling module is configured to parse the `calc_dependency` field and construct a directed acyclic graph (DAG). When the overall depth of the DAG is greater than 0 and the maximum in-degree is also greater than 0, the module uses a formula based on the in-degree and depth of each node in the DAG. Calculate the dynamic execution priority of each task ,in, This represents the value obtained from the schedule_priority field in the protocol header, after being normalized to the [0,1] range using the Min-Max method. Based on the priority normalized value, Let i be the in-degree of node i. The maximum in-degree in this directed acyclic graph. Let be the longest path depth of node i. Let α be the overall depth of the directed acyclic graph, β be the weight coefficients, and α + β + γ = 1. When the overall depth of the directed acyclic graph is 0, the depth term is 0. When the maximum in-degree is 0, the in-degree term is 0. According to dynamic priority and dependency, tasks with in edges are executed serially, and the output data of the preceding task is transmitted and injected into the input parameters of the subsequent task through the MCP heartbeat message. Tasks with zero in-degree and no resource conflicts are scheduled in parallel batches.

[0054] The steel structure code knowledge base provides data support for the dependency parsing and scheduling module and the two-dimensional verification module, storing code clauses with knowledge_code, clause design indicators, and correction strategy templates.

[0055] The dual-dimensional verification module is started after the dependency resolution and scheduling module completes all computation tasks. It is configured to extract design indicators from the standard knowledge base based on the knowledge_code for standardization review, and perform logical consistency review between multiple results based on the threshold field in the message.

[0056] The exception handling module, which connects with the dual-dimensional verification module, is configured to retrieve a correction suggestion from the correction strategy knowledge base when any review fails, using the error code and knowledge_code as a joint index, and then encapsulate the correction suggestion in the MCP exception extension layer and return it.

[0057] The modules described above work together in the order of message generation, scheduling and execution, result verification and exception handling to complete the entire process from user request to result correction.

[0058] This invention proposes a steel structure calculation scheduling method and system based on dependency coding. The method uses extended MCP protocol messages as data carriers and structurally encodes data dependencies, state dependencies, and trigger dependencies between calculation tasks through the `calc_dependency` field. This enables the scheduling module to automatically parse and construct a directed acyclic graph of tasks. Based on this, combined with dynamic priority calculation formulas for node in-degree and depth, it achieves serial execution and data transfer of dependent tasks, as well as parallel batch scheduling of tasks without dependencies and resource conflicts. After calculation, the method associates the calculation results with specific clauses in the specification knowledge base based on the `knowledge_code` field, performing a standardization review based on design indicators and a consistency review based on logical rules, forming a two-dimensional verification. If the verification fails, a composite retrieval code formed by concatenating the error code and the `knowledge_code` is used to retrieve standardized engineering correction suggestions from the correction strategy knowledge base, which are then encapsulated and returned, forming a complete processing mechanism from calculation and verification to correction suggestion feedback. The system includes an MCP protocol extension module, a dependency parsing and scheduling module, a steel structure specification knowledge base, a two-dimensional verification module, and an exception handling module. These modules work together to implement the above method flow.

[0059] Although the present invention has been described in detail with reference to the accompanying drawings and preferred embodiments, the invention is not limited thereto. Various equivalent modifications or substitutions can be made to the embodiments of the invention by those skilled in the art without departing from the spirit and essence of the invention. Such modifications or substitutions should all fall within the scope of the invention, or any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the invention should be covered within the protection scope of the invention. Therefore, the protection scope of the invention should be determined by the scope of the claims.< / comparison> < / value> < / comparison>

Claims

1. A steel structure computation scheduling method based on dependency coding, characterized in that, Includes the following steps: Step A: Construct a semantically enhanced MCP extension protocol message. The protocol header of this message contains a calc_dependency field, which uses a precondition operator to define the dependency type and data flow between tasks. The protocol body of this message contains a knowledge_code field, which establishes a mapping relationship with the clauses in the steel structure code knowledge base. Step B: Parse the `calc_dependency` field and construct a directed acyclic graph (DAG). When the overall depth of the DAG is greater than 0 and the maximum in-degree is also greater than 0, use the formula based on the in-degree and depth of each node in the DAG. Calculate the dynamic execution priority of each task ,in, This represents the value obtained from the schedule_priority field in the protocol header, after being normalized to the [0,1] range using the Min-Max method. Based on the priority normalized value, Let i be the in-degree of node i. The maximum in-degree in this directed acyclic graph. Let be the longest path depth of node i. Let α be the overall depth of the directed acyclic graph, β be the weight coefficients, and α + β + γ = 1. When the overall depth of the directed acyclic graph is 0, the depth term is 0. When the maximum in-degree is 0, the in-degree term is 0. Step C: Based on dynamic priority and dependencies, tasks with direct predecessor-successor relationships are executed sequentially in topological order. After the predecessor task is completed, the output data is extracted through the returned MCP response message and injected into the input parameters of the successor task. Tasks with zero in-degree and no resource conflicts are scheduled in parallel in batches. Tasks with zero in-degree but resource conflicts are scheduled sequentially according to priority. Step D: After the calculation results are returned, design indicators are extracted from the standard knowledge base based on the knowledge_code field for standardization review, and logical consistency review between multiple results is performed based on the threshold field in the message; if any review fails, a correction suggestion is retrieved from the correction strategy knowledge base using the error code and knowledge_code field as a joint index, and the correction suggestion is encapsulated in the MCP exception extension layer and returned.

2. The method according to claim 1, characterized in that, The `calc_dependency` field is an array of strings, where the syntax of each precondition operator follows these rules: <pre_operator> ::=<dependency_type> ":"<condition_expr> ?<source_field> "->"<target_field> ?; in,<dependency_type> It can be one of DATA, STATUS, TRIGGER, OR_TRIGGER, or AND_TRIGGER.

3. The method according to claim 1, characterized in that, The weighting coefficients mentioned in step B are α=0.5, β=0.2, and γ=0.

3.

4. The method according to claim 1, characterized in that, The logical consistency review in step D includes: predefining a consistency rule base, checking each rule one by one and recording violations when they occur, and calculating a consistency score C = 1 - (number of violating rules / total number of rules); triggering an exception when C is lower than a preset threshold; the preset threshold is determined by using the consistency_threshold value specified by the user in the calc_threshold field of the message, or by mapping according to the security level, or by dynamically calculating the mean and standard deviation of historical consistency scores.

5. The method according to claim 1, characterized in that, Step D involves retrieving correction suggestions from the correction strategy knowledge base using the error code and the knowledge_code field as a combined index. This includes: the knowledge_code field is encoded in the format of "specification number_chapter number_article number_verification type"; first, an exact match is performed using "error code#knowledge_code" as a combined index; if an exact match fails, the last-level fields are pruned level by level starting from the complete knowledge_code field, generating a new index for each level pruning and retrieving it from the knowledge base; if backtracking continues until only the specification number remains unmatched, the backtracking stops and a preset general correction suggestion is returned; the backtracking path is recorded in the backtrace field of the MCP anomaly extension layer.

6. The method according to claim 1, characterized in that, The protocol body layer of the message in step A also includes a threshold_merge_rule field, which takes the value of STRICT_KNOWLEDGE, USER_OVERRIDE, AUTO_MIN, or AUTO_MAX. When the knowledge base design metric conflicts with the threshold set in the calc_threshold field in the message protocol body layer, the design metric to be adopted is determined based on this field. If this field is not set, USER_OVERRIDE is adopted by default.

7. The method according to claim 1, characterized in that, The protocol header of the message in step A also includes a `retry_policy` field, which is a JSON object containing subfields `max_retries`, `interval_ms`, `backoff_multiplier`, and `timeout_ms`. When the scheduling module does not receive a heartbeat or completion message after a task times out, it performs exponential backoff retries based on this `retry_policy` field. It also maintains a consecutive failure count for each function type. When the number of consecutive failures reaches a set threshold, a circuit breaker is triggered. During the circuit breaker's duration, calls to that function type directly return failure. After the circuit breaker ends, it enters a half-open state, allowing one trial call.

8. The method according to claim 1, characterized in that, In step C, parallel batch scheduling is used for tasks with zero in-degree and no resource conflicts. Resource conflict detection includes: obtaining the resource_requirements field declared by the node in the message protocol body layer, which specifies the required resource type and quantity; if the required resource types of two nodes do not overlap, or if the resource types overlap but the current remaining resource quantity meets the sum of their requirements, then it is determined that they can be executed in parallel; otherwise, the one with the lower priority is kept in the ready queue and only the node with the higher priority is added to the parallel channel; the resource lock adopts an automatic release mechanism upon timeout.

9. The method according to claim 1, characterized in that, Step A includes: filling the corresponding fields of the message with the structured or semi-structured configuration items input by the user through a preset mapping rule table, and automatically matching the knowledge_code and calc_dependency operators according to the selected verification items to assemble an extended MCP message; or, driving the language model through a preset Prompt instruction set to convert the natural language description into a request message conforming to the semantically enhanced MCP extended protocol format; and performing JSON Schema verification and automatic repair on the generated message through middleware. This verification includes checking required fields, data types, and BNF compliance of calc_dependency. If the repair fails, regeneration is required.

10. A steel structure calculation scheduling system based on dependency coding, characterized in that, include: The MCP protocol extension module is configured to generate and parse semantically enhanced MCP extension protocol messages. The protocol header of the message contains a calc_dependency field, which uses a precondition operator to define the dependency type and data flow between tasks. The protocol body of the message contains a knowledge_code field, which establishes a mapping relationship with specific clauses in the steel structure code knowledge base. The dependency resolution and scheduling module is configured to parse the `calc_dependency` field and construct a directed acyclic graph (DAG). When the overall depth of the DAG is greater than 0 and the maximum in-degree is also greater than 0, the module uses a formula based on the in-degree and depth of each node in the DAG. Calculate the dynamic execution priority of each task ,in, This represents the value obtained from the schedule_priority field in the protocol header, after being normalized to the [0,1] range using the Min-Max method. Based on the priority normalized value, Let i be the in-degree of node i. The maximum in-degree in this directed acyclic graph. Let be the longest path depth of node i. Let α, β, and γ be the overall depth of the directed acyclic graph, and let α, β, and γ be weight coefficients, with α + β + γ = 1. When the overall depth of the directed acyclic graph is 0, the depth term is 0. When the maximum in-degree is 0, the in-degree term is 0. According to dynamic priority and dependency, tasks with in-edges are executed serially, and the output data of the preceding task is transmitted and injected into the input parameters of the subsequent task through the MCP heartbeat message. Tasks with zero in-degree and no resource conflicts are scheduled in parallel batches. The steel structure code knowledge base is used to store code clauses, design indicators for the clauses, and revision strategy templates with knowledge_code. The dual-dimensional verification module is configured to extract design indicators from the standard knowledge base based on the knowledge_code for standardization review, and to perform logical consistency review between multiple results based on the threshold field in the message. The exception handling module is configured to retrieve a correction suggestion from the correction strategy knowledge base using the error code and knowledge_code as a combined index when any review fails, and then encapsulate the correction suggestion in the MCP exception extension layer and return it.

Images