A multi-stage configuration method and system for non-standard mechanical and electrical equipment, electronic equipment and storage medium

Abstract

The application relates to the technical field of electric digital data processing, and discloses a multi-stage configuration method and system for non-standard electromechanical equipment, electronic equipment and a storage medium, which comprises the following steps: obtaining parameters and environmental constraints of the non-standard electromechanical equipment, generating an initial state object and expanding default fields; constructing a directed dependency graph, wherein the directed edges at least include a derivation edge from product parameters to structure results, a geometric constraint edge from structure to layout, a selection edge from layout to components, an interface edge between components and a check edge from components to check results; calling a multi-stage decision-making agent chain, and sequentially executing structure decision-making, spatial layout calculation of geometric engine output installation boundary and position, and component selection according to a preset stage sequence; writing the results of structure decision-making, layout calculation and component selection into a state object, recording the source labels and dependency lists of the respective results, and outputting product data. The problems of process fragmentation, insufficient linkage and late checking are solved, and the purposes of high integration and high linkage are achieved.

Description

Technical Field

[0001] This invention relates to the field of electronic digital data processing technology, and in particular to a multi-stage configuration method, system, electronic device, and storage medium for non-standard electromechanical equipment. Background Technology

[0002] The design process for complex industrial products is typically not a single-parameter lookup, but a collaborative solution process spanning multiple design domains. In current engineering practice, this is usually dispersed across multiple systems or roles. Common practices include: sales or configuration personnel first inputting key parameters; then civil engineering or design tools calculating spatial dimensions; then component selection systems or manual experience determining drive, door, and structural components; and finally, engineers performing feasibility reviews, price calculations, and BOM breakdown. This approach struggles to handle frequent requirement changes and complex collaboration. Existing technologies primarily involve writing common product parameters, selection criteria, and component results into rule tables or expert systems, directly matching rules based on input and outputting solutions. This works in standard product scenarios, but as parameter combinations, structural styles, and local selections increase, the number of rules rapidly expands, leading to high maintenance costs. Another approach involves one system handling parameter selection and another handling geometry and layout, with the two connected via an intermediary form or manual communication. This method frequently encounters problems such as geometry changes without synchronized selection or component replacement without re-triggered verification. The process involves reverse engineering from a standard BOM or standard component template to assemble the solution and then working backward to determine the product configuration. This method is suitable for highly standardized scenarios, but it lacks sufficient support for non-standard, semi-standard, and mid-process modification scenarios. Another approach involves inputting a large number of constraints into the solver at once to obtain results. While mathematically feasible, this approach typically lacks mid-process interaction, process interpretation, local back-calculation, and result source tracing capabilities in engineering. Furthermore, typical technical problems with non-standard electromechanical equipment lie in the strong dependencies between structural schemes, spatial layouts, component selection, electromechanical interfaces, and assembly relationships. Changes in parameters or project constraints can easily lead to problems such as geometry changes without component synchronization, component changes without interface re-verification, and local modifications resulting in global rework.

[0003] For example, patent application CN102831283B discloses a method for constructing complex product models based on surface features, providing the following technical solution: instantiating surface features by setting feature parameter values; secondly, positioning the instantiated surface features on the surface model; then automatically generating a transition surface feature to smoothly connect the surface features with the dependent surface; finally, building the surface feature model using a "building block" approach until the product model is completed. This invention can effectively use surface features as design units, similar to a regular feature modeling system, to conveniently use surface features with specific functional semantics to build feature models. When applied to CAD model construction, this invention can give products a smooth shape and stronger functionality, thereby better meeting consumer needs, effectively improving product competitiveness and design efficiency. However, the aforementioned method for constructing complex product models based on surface features only solves the modeling and transition of surface geometric features, and cannot handle problems such as multi-domain parameter linkage, configuration decisions, dependency propagation, and incremental updates for complex industrial products. It lacks support for engineering aspects such as product structure, component selection, and verification rollback, and cannot explain the source of the results. Summary of the Invention

[0004] This invention solves the problems of fragmented processes, insufficient linkage, and late verification in the prior art. It proposes a multi-stage configuration method, system, electronic equipment, and storage medium for non-standard electromechanical equipment, achieving the goals of unified processes, high integration, high linkage, interpretable output, and low computational redundancy.

[0005] Furthermore, this invention aims to unify the design state object, and through dependency graph-driven multi-stage decision-making and local failure recalculation, realize the engineering closed loop and efficient incremental update of complex product configuration design. It solves the problem of linkage consistency across structure, layout, components, interfaces, assembly and verification in the configuration design of non-standard electromechanical equipment, as well as the problem of modified local failure propagation and local recalculation.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: A multi-stage configuration method for non-standard electromechanical equipment, comprising: Obtain the parameters and environmental constraints of non-standard electromechanical equipment, generate an initial state object, and expand the default fields; Construct a directed dependency graph, wherein the directed edges include at least the derivation edges from product parameters to structural results, the geometric constraint edges from structure to layout, the selection edges from layout to components, the interface edges between components, and the verification edges from components to verification results. The multi-stage decision agent chain is invoked to execute structural decisions, spatial layout calculations of installation boundaries and locations output by the geometry engine, and component selection in a preset stage order. Write the results of structural decisions, layout calculations, and component selections into a state object, record the source tags and dependency lists of each result, and output product data.

[0007] A multi-stage configuration system for non-standard electromechanical equipment, comprising: The State Management module maintains a unified design state object; the Dependency Graph module connects to the State Management module and maintains a directed dependency graph with design objects as nodes and derivation or constraint relationships as edges; the Multi-Stage Decision Agent Scheduling module connects to the State Management module and the Dependency Graph module respectively, and calls the geometry engine, physics engine, and component library interface modules in stages; the Impact Analysis and Local Recalculation module connects to the Dependency Graph Management module, the State Management module, and the Scheduling module respectively, and determines the affected subgraphs based on the dependency graph and triggers local recalculation.

[0008] By unifying the design process of complex industrial products into a coherent state object management, dependency graph-driven, and local recalculation mechanism, the problems of process fragmentation, insufficient linkage, and late verification are solved. It enables automatic impact propagation and minimized recalculation after parameter changes, thereby improving engineering efficiency and maintainability.

[0009] Preferably, the construction of the directed dependency graph includes loading the basic dependency template corresponding to the product family, defining the main link of the stage, parsing the field reference relationships in the parameter rules, component application conditions and verification rules, and automatically generating object-level dependency edges; during the execution of each stage, the runtime dependency edges are dynamically supplemented according to the actual set of objects read and the set of objects written.

[0010] By using a hybrid construction method that combines basic templates with dynamic supplementation, the determinism of the main project path is ensured, while automatically adapting to non-standard extensions and actual runtime paths. This solves the problem that static dependency graphs cannot reflect the true derivation path, improving the accuracy and flexibility of the dependency graph.

[0011] Preferably, marking failed nodes according to the dependency graph includes starting from the source node of the change, traversing backward along the dependent edges, and judging the propagation condition of each edge in turn; if the propagation condition of the edge is not met, or the value of the target node after recalculation has not changed, or the target node is locked by the user, then the failure propagation is blocked and a conflict prompt is generated; only the successor nodes that meet the propagation conditions and are not blocked are added to the set of affected nodes and marked as failed.

[0012] The multi-condition blocking mechanism avoids unnecessary cascading failures and prevents large-scale invalid recalculations caused by small changes. It also supports user priority locking and conflict warning functions, making local updates more accurate and controllable, and reducing computational waste and accidental overwriting.

[0013] Preferably, the partial recalculation from the earliest rollback stage includes splitting each result object into multiple field-level results, with dependent edges pointing to specific fields within the object; when an upstream field changes, only downstream fields that directly or conditionally depend on that field become invalid; for strongly coupled scenarios, the invalidation granularity is increased to the object level or stage level based on edge type or rule declaration.

[0014] It achieves precise failure propagation at the field level, reduces the scope of local recalculation, and retains the ability to improve granularity for strongly coupled scenarios. It solves the problem of excessive recalculation caused by coarse object-level failure granularity, and balances flexibility and engineering determinism.

[0015] Preferably, before outputting product data, if parameters change or verification fails, the failure node is marked according to the dependency graph, and the local recalculation is performed from the earliest rollback stage. After updating the state object, the product data is output. If the recalculation is triggered by verification failure, the root cause object and suggested rollback stage information in the failure reason are parsed: if it is due to insufficient space size, the rollback is performed to the layout stage; if it is due to unsatisfactory physical performance, the rollback is performed to the structure stage or physical selection stage; if it is due to incompatible component interfaces, the rollback is performed to the component selection stage.

[0016] By intelligently selecting the fallback entry point based on the root cause of the verification failure, the system avoids treating all failures as global rework, shortens the time for problem location and correction, and improves the self-correction capability and engineering practicality of the design system.

[0017] Preferably, the multi-stage decision agent chain is invoked, specifically including the collaborative solution of the geometry engine, the physics engine, and the interface relationship. The geometry engine outputs spatial layout nodes based on the structural results, and the physics engine outputs a candidate set of performance components based on the main specifications and geometric boundaries. The component library and the interface relationship module calculate the intersection of the geometric candidate set, the physical candidate set, and the feasible set of interfaces. If the intersection is empty, the root cause is located and the local rollback of the corresponding stage is triggered until a feasible result is found.

[0018] By unifying the geometric domain, physical domain, and interface domain into a single solution loop, and through candidate set intersection and root cause localization, the problem of overall unassembleability or unmanufacturability caused by insufficient cross-design domain collaboration is solved, and a conflict handling mechanism that is rollbackable and convergent is provided.

[0019] Preferably, the expanded default field adopts a hierarchical priority mechanism to assign priority to the field source, with explicit user input taking precedence over the standard template; when switching the standard configuration template, fields that have been locked by the user are retained, new template values ​​are used for unmodified fields, and conflict nodes are generated for conflicting fields, with local recalculation triggered by the dependency graph.

[0020] It achieves the integration and coexistence of standard configuration and user customization, which not only ensures the efficiency of rapid template expansion, but also respects the user's explicit modification and locking intentions, avoids the incorrect overwriting of customized content when switching templates, and ensures the entry of new template constraints through conflict nodes and partial recalculation.

[0021] Preferably, the construction of the directed dependency graph also includes, when a new custom parameter declaration is received, if the parameter is referenced by a calculation formula, component application conditions or verification rules, or is explicitly mapped to an existing standard field, then a directed edge pointing to the relevant result node is established for the node of the parameter in the dependency graph; if the parameter is not referenced by any rule and has no mapping relationship, it is only saved as a display field and does not participate in automatic propagation and recalculation.

[0022] It provides a secure and controllable custom parameter access mechanism, which allows users to extend new business fields and automatically integrate them into dependency propagation, while preventing redundant parameters with irregular references from triggering invalid recalculation, thus enhancing the scalability and stability of the system.

[0023] Preferably, in the state object, each result object includes at least an object identifier, a generation stage identifier, a list of dependent objects, a source tag, a version number, and a validity flag; the distinguishing field of the source tag is generated by explicit user input, standard template expansion, rule deduction, or system default; when an object is marked as invalid, the system locates all subsequent affected objects according to the list of dependent objects and the dependency graph, and only sets the validity flag of the affected objects to invalid.

[0024] The system achieves refined management through object-level metadata, which solves the problems of unclear source of system results and unclear scope of impact, and provides data proof for retrospective lookup and incremental updates.

[0025] An electronic device includes a memory and a processor, the memory storing a program that is executed by the processor to perform a multi-stage configuration method for non-standard electromechanical equipment.

[0026] A computer-readable storage medium having a computer program stored thereon, the program being executed by a processor to perform a multi-stage configuration method for non-standard electromechanical equipment.

[0027] Compared with the prior art, the beneficial effects of the present invention are as follows.

[0028] 1. This invention solves the problem of fragmented processes by unifying input, structure, layout, component selection, and verification output into a coherent technical chain through a unified design of state objects and dependency graphs. When parameters or configurations are modified, the system automatically propagates the impact along the dependency graph, enabling local failures and local recalculations, avoiding manual oversights, and improving the linkage response capability in the design of complex industrial products.

[0029] 2. This invention employs object-level validity management and a stage-level rollback mechanism, recalculating only the affected objects rather than performing a global recalculation, significantly shortening the design cycle in scenarios with frequent modifications. Simultaneously, it retains result source tags, dependent objects, and version information, clearly tracing the inputs, rules, and stages from which each design result was derived, facilitating subsequent review, delivery, and accountability.

[0030] 3. This invention integrates standard configuration expansion and explicit user modification within a unified state object. Through source priority and conflict handling mechanisms, it ensures both rapid expansion of standard templates and respect for customer customization. Furthermore, the dependency graph supports automatic edge creation during rule parsing and dynamic edge completion at runtime. Adding new product types, components, or interface rules does not require overhauling the overall framework, making it easy to extend and maintain. Attached Figure Description

[0031] Figure 1 This is an overall flowchart of a multi-stage configuration method for non-standard electromechanical equipment according to the present invention.

[0032] Figure 2 This is a diagram showing the overall architecture of a multi-stage configuration system for non-standard electromechanical equipment according to the present invention. Detailed Implementation

[0033] See Figure 1 As shown, a multi-stage configuration method for non-standard electromechanical equipment includes: Obtain the parameters and environmental constraints of non-standard electromechanical equipment, generate an initial state object, and expand the default fields; Construct a directed dependency graph, wherein the directed edges include at least the derivation edges from product parameters to structural results, the geometric constraint edges from structure to layout, the selection edges from layout to components, the interface edges between components, and the verification edges from components to verification results. The multi-stage decision agent chain is invoked to execute structural decisions, spatial layout calculations of installation boundaries and locations output by the geometry engine, and component selection in a preset stage order. Write the results of structural decisions, layout calculations, and component selections into a state object, record the source tags and dependency lists of each result, and output product data.

[0034] A multi-stage configuration system for non-standard electromechanical equipment, comprising: The State Management module maintains a unified design state object; the Dependency Graph module connects to the State Management module and maintains a directed dependency graph with design objects as nodes and derivation or constraint relationships as edges; the Multi-Stage Decision Agent Scheduling module connects to the State Management module and the Dependency Graph module respectively, and calls the geometry engine, physics engine, and component library interface modules in stages; the Impact Analysis and Local Recalculation module connects to the Dependency Graph Management module, the State Management module, and the Scheduling module respectively, and determines the affected subgraphs based on the dependency graph and triggers local recalculation.

[0035] The non-standard electromechanical equipment referred to in this invention refers to equipment products in discrete manufacturing scenarios that consist of multiple structural components, functional parts, electromechanical interfaces, and assembly relationships, and require configuration design based on order parameters, customer needs, installation environment, or project constraints. The non-standard electromechanical equipment may include elevators, air conditioning or HVAC equipment, industrial robotic arms, construction machinery, electrical control cabinets, automated production line units, and other discrete manufacturing equipment that requires structural scheme determination, spatial layout calculation, component selection, and interface verification.

[0036] This invention constructs a multi-stage decision agent chain for complex industrial products, maintains a unified design state object, explicitly establishes a dependency graph from parameters to structure, layout, components and verification results, and performs local failure and local recalculation according to the dependency relationship when modification or verification fails, thereby forming an engineering closed loop of "input-standard expansion-structure determination-layout derivation-component selection-constraint verification-incremental update-result output".

[0037] like Figure 1 In one embodiment shown, the specific steps of the present invention are as follows: Initialization State and Standard Expansion: After obtaining the design input parameters, the system generates an initial state object and automatically completes the default fields according to the standard configuration template. Each result object in the state object contains at least an object identifier, a generation stage identifier, a list of dependent objects, a source tag, a version number, and a validity flag. The source tag is used to distinguish whether a field was explicitly entered by the user, expanded from a standard template, derived from rules, or generated by the system by default.

[0038] Constructing a Directed Dependency Graph: The system constructs a directed dependency graph, where directed edges include at least: derivation edges from parameters to structures, geometric constraint edges from structures to layouts, selection edges from layouts to components, interface edges between components, and validation edges from components to validation results. During construction, the basic dependency template corresponding to the product family is first loaded to define the main link of the stage. Then, the field reference relationships in parameter rules, component application conditions, and validation rules are parsed to automatically generate object-level dependency edges. During the execution of each stage, runtime dependency edges are dynamically supplemented based on the actual set of objects read and written. In addition, when a new custom parameter declaration is received, if the parameter is referenced by a calculation formula, component application condition, or validation rule, or is explicitly mapped to an existing standard field, a directed edge pointing to the relevant result node is established for the parameter node in the dependency graph; if the parameter is not referenced by any rule and has no mapping relationship, it is only saved as a presentation field and does not participate in automatic propagation and recalculation.

[0039] Execution of the multi-stage decision agent chain: The multi-stage decision agent chain is invoked, sequentially executing structural decisions, layout calculations, and component selection. This involves a collaborative solution using the geometry engine, physics engine, and interface relationships: the geometry engine outputs spatial layout nodes based on the structural results, the physics engine outputs a candidate set of performance components based on key specifications and geometric boundaries, and the component library and interface relationship module calculate the intersection of the geometric candidate set, the physical candidate set, and the feasible interface set. If the intersection is empty, the root cause is located, and a local rollback is triggered for the corresponding stage until a feasible result is found. The result object generated at each stage is written to a state object, recording its source tag and dependency list.

[0040] Local recalculation upon change or failure: When input parameters change or validation fails, the system identifies affected nodes and marks them as invalid based on the directed dependency graph. Specifically, starting from the source node of the change, the system traverses along the dependent edges, sequentially determining the propagation condition of each edge: if the propagation condition is not met, or the recalculated value of the target node remains unchanged, or the target node is locked by the user, then the failure propagation is blocked and a conflict warning is generated; only successor nodes that meet the propagation condition and are not blocked are added to the affected node set and marked as invalid. When an object is marked as invalid, the system locates all subsequent affected objects based on the list of dependent objects and the dependency graph, and only invalidates the validity flags of these objects.

[0041] Determine the rollback phase and granularity control: The system only recalculates failed parts starting from the earliest rollback phase. Each result object can be broken down into multiple field-level results, and dependent edges can point to specific fields within the object; when an upstream field changes, only downstream fields that directly or conditionally depend on that field become invalid. For strongly coupled scenarios, the failure granularity is raised to the object level or phase level based on edge type or rule declaration. If a recalculation is triggered by a validation failure, the system parses the root cause object and suggested rollback phase information from the failure reason: if it is due to insufficient space size, rollback to the layout phase; if it is due to insufficient physical performance, rollback to the structure phase or physical selection phase; if it is due to incompatible component interfaces, rollback to the component selection phase.

[0042] After completing the local recalculation and updating the state objects, the system outputs the final design results.

[0043] This invention also includes priority handling for standard templates and user input: A hierarchical priority mechanism is used to expand default fields based on the standard template and user input, assigning priority to field sources, with explicit user input taking precedence over the standard template. When switching standard configuration templates, fields locked by the user are retained, new template values ​​are used for unmodified fields, and conflict nodes are generated for conflicting fields, triggering local recalculation via the dependency graph.

[0044] In another embodiment, the core steps of the present invention are as follows: S1: Based on user input, standard configuration identifiers, and environmental constraints, standardize fields, unify units, enumerate mappings, and fill in default fields to output a standardized set of input parameters. S2: Based on the standardized input parameter set, expand the standard configuration, generate default values ​​and record the source tag source_tag=standard, and output the initial DesignState; S3: Based on the initial DesignState, perform parameter linkage verification, identify mutual exclusion, dependency, range out-of-limit and missing item conflicts, and output feasible input domains or conflict item descriptions; S4: Based on the feasible input domain and strategy library, initialize the multi-stage execution plan, create a stage list and execution record, and output the queue of stages to be executed; S5: Based on the main specifications and structural strategies, determine the structural form, key layout directions and core structural variables, and output the structural result nodes; S6: Based on structural result nodes and environmental constraints, the geometry engine calculates spatial dimensions, positional relationships, and layout boundaries, and outputs layout result nodes; S7: Based on the structure / layout results and physical rules, the physics engine filters the range or model of performance-related components and outputs a candidate set of physical components; S8: Based on the layout results, physical component candidate set and component library, match specific component models and perform interface compatibility checks, and output component combination candidate schemes; S9: Based on candidate component combination schemes and verification rules, perform multi-dimensional verifications including geometry, interface, physics, price, and weight, and output verification result nodes; S10: When a user modification instruction or verification failure signal is received, perform impact analysis based on the DependencyGraph, determine the affected object subgraph, perform local failure marking and local recalculation, and output the updated DesignState. S11: Based on the final DesignState after convergence, output the scheme parameters, structural results, component list, modification comparison, verification results, and data interface for downstream systems.

[0045] In this context, DesignState refers to a unified state object throughout the entire design process, storing inputs, results, sources, dependencies, and execution records. DependencyGraph represents the directed influence relationships between design objects, used for influence analysis and local recalculation. Multi-stage decision agents are not limited to large models; they can be implemented using rule engines, workflow orchestrators, state machines, script engines, policy schedulers, or model-assisted sorters. Their commonality lies in controlling the reading and writing of DesignState according to stages and being responsible for data dependencies between stages.

[0046] This invention maintains a unified design state object, DesignState, throughout the entire design process. This object is not a simple parameter dictionary, but a container for project state with version, source, dependencies, and validity flags. Each stage only reads the fields it needs and updates the fields it is responsible for, avoiding different modules maintaining isolated data. See Table 1 below for details.

[0047] Table 1:

[0048] In this embodiment, each result object in DesignState contains at least the following metadata: object_id, object_type, stage_id, dependency_ids, source_tag, version, valid_flag, and updated_at. Therefore, when an object fails, the system can accurately locate the affected successor object, rather than simply recalculating the entire round.

[0049] In this embodiment, a directed dependency graph (DependencyGraph) is provided. This graph can be implemented using relation tables, graph databases, adjacency lists, or in-memory graph structures. Its nodes represent design objects, and edges represent derivation, constraint, or reference relationships. Unlike a general flowchart, this dependency graph is used to drive incremental updates. Specifically, it includes derivation edges, geometric constraint edges, selection edges, interface edges, validation edges, and source edges. Among them, the derivation edge starts with a parameter node and ends with a structure node, indicating that the endpoint is calculated or filtered from the starting point, such as load--motor_model; the geometric constraint edge starts with a structure node and ends with a layout node, indicating that the endpoint is restricted by the spatial boundary of the starting point, such as counterweight_pos--shaft_size; the selection edge starts with a layout node and ends with a component node, indicating that the candidate set of endpoints is narrowed by the starting point, such as door_width--door_model; the interface edge starts with a component node and ends with a component node, indicating that the two components must meet the assembly or connection compatibility requirement, such as guide_rail--guide_shoe; the verification edge starts with a layout / component node and ends with a verification node, indicating that the endpoint is verified by multiple predecessor objects, such as car_size + frame_model--geom_check; the source edge starts with standard configuration / user modification and ends with an object node, indicating that the source from which the object is generated or overridden is recorded, such as std_pkg_A--door_type; In this embodiment, the nodes in the dependency graph are categorized by granularity into parameter nodes, structural nodes, layout nodes, component nodes, interface nodes, and verification nodes. The system configures the stage to which each node belongs and its recalculation priority. For example, changes in parameter nodes first trigger failures in structural nodes, which then propagate to layout and component nodes, ultimately triggering failures in verification nodes.

[0050] In another embodiment, the edges in the dependency graph can also carry propagation conditions, such as "propagate only when the field value changes by more than a threshold," "propagate only when the source label is modified by the user," and "propagate only when the associated component is still in the candidate state." This makes local recalculation accurate not only to the object but also to the condition.

[0051] Dependency graphs are not limited to pre-hard-coded static templates. In another embodiment, a hybrid construction method of "basic dependency template + rule parsing edge construction + runtime dynamic edge completion + versioned maintenance" is adopted to simultaneously satisfy engineering determinism and non-standard scalability.

[0052] During system initialization or product family selection, the dependency graph management module first loads the basic dependency template corresponding to the product family, ladder type, or equipment category. The basic dependency template describes the stable main engineering chain; for example, major specifications affect the structural scheme, the structural scheme affects the geometric layout, the geometric layout affects component selection, and component selection affects interface verification and weight / price calculation. This template only defines the general skeleton and stage boundaries, and does not require enumeration of all parameter combinations.

[0053] After loading the basic template, the system further parses the field reference relationships in parameter rules, component application conditions, interface rules, calculation formulas, verification rules, and strategy rules, and automatically generates object-level dependency edges accordingly. For example, if a door operator model rule references the fields `door_width`, `door_height`, `door_type`, and `speed`, the system establishes a selection edge or verification edge between the door operator model node and the aforementioned parameter or layout nodes; if a weight calculation rule references `car_frame_model`, `car_panel_material`, and `counterweight_block_count`, the system establishes a verification edge between the weight verification node and the corresponding component node.

[0054] During execution, if new intermediate results or candidate objects are generated at a certain stage, the dependency graph management module automatically supplements the derivation edges based on the read object set and write object set of that stage. Specifically, each stage records read_set, write_set, rule_id, stage_id, and source_tag during execution; after the stage is completed, for each new object in write_set, the read_set actually read in this execution is established as its direct predecessor, thus forming runtime dependency edges consistent with the actual computation path. Therefore, even if the same product uses different computation rules under different strategy paths, the dependency graph can still reflect the true derivation chain.

[0055] Runtime dynamic edge completion occurs after each stage is completed and the stage results are written back to DesignState, but before the next stage starts. Edge completion can also be performed immediately before impact analysis begins if validation fails and triggers a rollback, or if user modifications trigger impact analysis. Edge completion is based on the read_set, write_set, rule_id, stage_id, source_tag, and condition_expr records from that stage's execution, as well as the field references actually hit in the component library rules, interface rules, and calculation formulas during this execution. For objects added or updated in write_set, the dependency graph management module establishes the read_set actually involved in the calculation as its direct predecessor. For field references that only exist in candidate rules but are not hit in this instance, the system can mark the corresponding edge as inactive_in_current_state, preventing it from participating in the failure propagation of the current solution. Edges generated at runtime are marked as runtime_edge by default and are only bound to the current solution instance, the current DesignState version, and the current graph_version. After administrator confirmation, rule library publication, or template solidification, they can also be retained as reusable template edges for subsequent solutions.

[0056] In this embodiment, when a user, implementer, or enterprise administrator adds a custom parameter, the system identifies its dependency relationship through three types of information: "parameter declaration + rule reference + mapping binding". The parameter declaration includes at least the parameter identifier, data type, unit, value range, design domain, source priority, and affected stage; rule reference means that the parameter is referenced by a certain calculation formula, filtering condition, validation expression, or interface rule; mapping binding means that the parameter is explicitly mapped to an existing standard field, component attribute, or interface attribute.

[0057] If a custom parameter is mapped to an existing standard field, the system inherits the downstream dependency edges of that standard field and records the `alias_of` or `mapped_to` relationship in the dependency graph. If a custom parameter is directly referenced by a regular expression, the system establishes a direct edge from the parameter node to the structure, layout, component, or validation node that references the parameter. If a custom parameter only declares its design domain but has not yet been referenced by any rule, the system treats it as a node to be bound, participating only in input records and difference outputs, without triggering automatic recalculation; a valid dependency edge is then established when a subsequent rule or component attribute references the parameter.

[0058] To prevent error propagation, the system requires custom parameters to meet at least one of the following conditions to participate in automatic propagation: referenced by a calculation formula, referenced by a component's application conditions, referenced by an interface rule, referenced by a validation rule, referenced by a policy rule, or explicitly bound to an existing field by an administrator. Otherwise, the parameter will only be saved as an annotation or business demonstration field and will not affect the design result.

[0059] For example, an enterprise administrator adds a custom parameter `fire_rating_custom` (fire door rating), whose parameter declaration includes `datatype=enum`, `domain=door_system`, `range={A,B,C}`, and `affects_stage={component, interface, validation}`. If this parameter is mapped to the standard field `door_fire_rating`, the system establishes a mapping relationship `fire_rating_custom mapped_to door_fire_rating` in the dependency graph and inherits the existing downstream dependency edges of `door_fire_rating`. If the gantry crane selection rule R_door_01 contains the expression `door_model.fire_rating≥fire_rating_custom`, and the output object of this rule is `door_model_candidate`, then the rule parser can identify `fire_rating_custom` as the input node and `door_model_candidate` as the output node, and automatically create a selection edge of `fire_rating_custom--door_model_candidate`. If the validation rule R_fire_check outputs `fire_door_check`, then a validation edge of `fire_rating_custom--fire_door_check` is further created. Conversely, if the newly added field is only "customer remarks" and is not referenced by any formula, component application conditions, interface rules, or validation rules, and is not mapped to a standard field, then the system only saves it as an input parameter object and does not establish a valid dependency edge that would trigger automatic recalculation.

[0060] Each node and edge in the dependency graph can carry metadata such as `graph_version`, `created_by`, `created_by_stage`, `rule_id`, `condition_expr`, `priority`, and `enabled_flag`. When the rule base, component library, or standard configuration template is updated, the system does not directly overwrite the existing dependency graph, but instead generates a new graph version or local edge version. Completed solutions can continue to be bound to the old version to ensure traceability, while new solutions or recalculated solutions can use the new version. In a solution calculation, if the propagation condition of an edge is not met, the system can mark the edge as `inactive_in_current_state`, but does not delete it from the graph definition; if an edge is generated due to the actual execution path, it is marked as `runtime_edge`. Through the above mechanism, the dependency graph can express both the stable structure of product knowledge and record the actual impact path of a solution solution.

[0061] The partial failure and partial recalculation mechanism is as follows: when a user modifies a parameter, the default configuration changes, a certain verification fails, or a certain strategy is switched in the middle of the solution, the system will not simply return to the starting point and re-execute all stages. Instead, it will perform an impact propagation on the dependency graph to obtain the affected subgraph, and only recalculate the nodes and stages involved in the subgraph.

[0062] The first step is to identify the source of the change. The source of the change can be a single parameter, such as a change in load capacity; it can also be a configuration package, such as switching the standard configuration from Option A to Option B; or it can be a policy switch, such as prioritizing price or delivery time.

[0063] The second step is to search backward along the dependency graph. Starting from the source node of the change, the system recursively or iteratively finds all subsequent affected nodes according to the edge type and propagation conditions, forming the set of affected nodes, affected_nodes.

[0064] The third step involves partial failure. For objects in `affected_nodes`, `valid_flag` is set to `false`, and `recompute_mark = true` is recorded, but unaffected objects are not deleted. The purpose of this is to maximize the reuse of existing results.

[0065] The fourth step is to determine the earliest rollback stage. The system iterates through the stages to which each node in `affected_nodes` belongs, selecting the stage with the earliest sequence number as the local rollback entry point. For example, if only component selection and interface verification are affected, there is no need to return to the structural stage.

[0066] Step 5, Local Recalculation. Starting from this entry point, the scheduler only recalculates objects related to `affected_nodes`. During the recalculation, the new results are written back to `DesignState` with the new version number, replacing the original invalidated objects.

[0067] Step 6: Difference Output. The system generates comparison items for key results before and after the change, such as changes in size, changes in component model, price increases or decreases, and changes in verification status.

[0068] The earliest rollback stage refers to the smallest execution entry point in the affected node set `affected_nodes` that is closest to the input and must be re-executed to bring the affected subgraph back to a valid state, according to the stage topology order or stage number. This stage is not the starting point of the entire process, but rather the smallest common pre-order execution entry point for the affected subgraphs. When determining this stage, the system first reads the `stage_id` of each node in `affected_nodes`, filters out verification nodes that are only used for prompts and do not require recalculation, and then selects the smallest stage number according to `stage_order`. If the failure reason includes `suggested_backtrack_stage`, or if a strongly coupled edge declares that it must roll back to an earlier stage, then that earlier stage is used as the local rollback entry point. For example, if only `door_model` and `interface_check` fail, the entry point can be the component selection stage; if the failure reason is due to insufficient `door_width`, the entry point is elevated to the layout stage; if insufficient `door_width` is caused by a structural scheme switch, the entry point is further elevated to the structural stage.

[0069] Local failures employ a propagation mechanism combining field-level, object-level, and stage-level mechanisms. The failure of a structural node does not necessarily lead to the failure of all its downstream layout nodes; instead, the decision to continue propagation is based on the target field of the edge, the propagation conditions, and the granularity of the failure. Specifically, each design object can be further broken down into one or more field-level results. For example, a structural result object may contain fields such as `counterweight_pos`, `machine_room_mode`, and `suspension_mode`; a layout result object may contain fields such as `shaft_width`, `shaft_depth`, `door_offset`, and `rail_layout`. Dependency edges can point to the entire object or to specific fields within the object. If the user only modifies `counterweight_pos`, the system only disables layout fields, component fields, and validation fields that depend on `counterweight_pos`; decoration options, brand preferences, and certain price surcharges that have no direct or conditional dependency on this field remain valid.

[0070] For nodes that cannot be split at the field level, the system can degrade to an object-level failure; for strongly coupled phases, such as when a complete structural change causes multiple layout boundaries to change simultaneously, the system can escalate to a phase-level failure. This granularity escalation is determined by the edge type, rule declaration, or validation failure reason and is recorded in `recompute_mark`.

[0071] To avoid unnecessary cascading failures, blocking conditions are set during propagation. First, value unchanged blocking: if the normalized value, candidate set, or key summary of the upstream node remains unchanged after recalculation, propagation continues. Second, condition unmet blocking: if the condition_expr of an edge is false in the current DesignState, the edge is not propagated. Third, user-locked blocking: if a downstream field is explicitly locked by the user and locking is allowed, the system does not directly overwrite the field but generates a conflict warning or alternative candidate. Fourth, candidate equivalence blocking: if upstream changes do not alter the feasibility ranking or final selection of the downstream candidate set, deeper recalculation is not triggered. Fifth, stage boundary blocking: some validation nodes only output risk warnings without changing the design object; their failures can proceed to manual confirmation or strategy switching, without necessarily reverting to all upstream stages.

[0072] In terms of the propagation algorithm, the system can traverse successor edges in topological order starting from the source of the change. For each edge, it sequentially checks whether the edge is enabled, whether the propagation condition is met, whether the target field is affected, and whether the target node has been covered by a higher-priority failure marker. Only target nodes that meet the conditions are added to affected_nodes. This algorithm makes local recalculation deterministic and interpretable.

[0073] When a validation failure triggers a recalculation, the system doesn't just backtrack based on the failed node itself. Instead, it analyzes the `cause_objects` and `suggested_backtrack_stage` in the failure reason. For example, if interface incompatibility is caused by insufficient doorway width, it backtracks to the layout stage; if it's caused by mismatched component interface types, it backtracks to the component selection stage; and if it's caused by load or speed exceeding the product family's capabilities, it backtracks to the structure stage or input validation stage. This avoids treating all failures as global rework.

[0074] In this embodiment, at least two heterogeneous computational units are included: a geometry engine and a physics engine. These two units can be pre-computed either serially or in partial parallel, but ultimately converge to a unified result through DesignState.

[0075] The geometry engine is responsible for solving spatial problems, including installation boundaries, component positions, assembly clearances, relative arrangements, and local dimensional linkages. Its inputs mainly come from structural results, environmental constraints, and certain explicit parameters; its outputs are primarily layout nodes.

[0076] The physics engine is responsible for solving performance problems, including drive capability, load capacity, speed adaptation, strength, and related empirical constraints. Its inputs mainly come from the main specifications, some geometric results, and policy constraints; its outputs are mainly performance-related component candidates.

[0077] The component library and interface relationship module is responsible for mapping geometric and physical results to a set of procurable or manufacturable components. Each component object in the component library must include at least the applicable conditions, size range, interface type, brand attributes, priority, price range, and substitutability.

[0078] The interface relationship module does not only perform a simple "match" judgment, but also records assembly eccentricity, boundary clearance, installation direction, and upstream dependency conditions. Therefore, the system can not only know whether a component is usable, but also "why it is unusable".

[0079] In the execution sequence of this embodiment, the structure stage first converges the structural form; the geometry engine outputs the key layout boundaries accordingly; the physics engine provides performance component candidates under the constraints of the main specifications and layout boundaries; finally, the component library and interface relationship module perform compatibility filtering on the candidate combinations. If no usable combination is found after interface filtering, a local fallback to the layout stage or component stage is triggered.

[0080] When conflicts arise between the outputs of the geometry engine and the physics engine, the system uses a unified state object and a monitoring and verification module to perform conflict attribution and rollback. Conflicts include: the allowable component size range in the geometric space cannot cover the performance components selected by the physics engine; components that meet physical performance requirements cannot meet installation clearances, interface directions, or shaft boundaries; or the interface relationship module cannot find a common candidate set between geometrically assemblable and performance-available components.

[0081] This embodiment employs the following conflict handling sequence: First, the intersection of the geometric candidate set G, the physical candidate set P, and the interface feasible set I is calculated. If the intersection is not empty, the results are sorted and output according to price, delivery date, brand, remaining quantity, or standardized priority in the strategy library. If the intersection is empty, the monitoring and verification module generates a conflict object set conflict_set and determines the root cause of the conflict as insufficient space, insufficient performance, interface incompatibility, excessive user locking, or inappropriate standard template.

[0082] When the root cause is insufficient space, the system first reverts to the layout stage, attempting to adjust local dimensions, eccentricity, guide rail arrangement, door width, or installation gaps; when the root cause is insufficient performance, the system first reverts to the physical selection or structural stage, attempting to change the drive scheme, load-bearing scheme, or structural path; when the root cause is incompatible interfaces, the system first reverts to the component selection and interface filtering stage; when the root cause is an explicit user lock that leads to no solution, the system does not forcibly overwrite the user input, but instead outputs a conflict description and unlockable items.

[0083] The technical effect of this conflict resolution mechanism is that the three design domains of geometry, physics, and interface do not each give isolated results, but form a closed loop in DesignState that is reversible, interpretable, and convergent through candidate sets, failure reasons, and dependency graphs.

[0084] This embodiment also includes a hierarchical priority mechanism between standard configuration templates and user modifications. The system can categorize field sources as explicit_user, locked_user, standard_template, derived_by_rule, system_default, and historical_default. Normally, explicit user input takes precedence over standard templates, and standard templates take precedence over system defaults; however, when user input violates mandatory regulations, physically infeasible constraints, or hard interface constraints, the system does not directly use the input but instead generates a conflict state and requires adjustment or switching of strategies.

[0085] When a user modifies parameters and then switches to the standard configuration template, the system does not simply overwrite all fields with the new template. Instead, it performs a three-step merging process: First, it retains fields marked as `locked_user` or `explicit_user`; second, it adopts the new template values ​​for fields not explicitly modified by the user; and third, it generates `conflict_node` for objects that conflict with user fields due to the template switch, and triggers a local recalculation of the affected fields through the dependency graph. This ensures that customer customizations are not unintentionally overwritten while also ensuring that the structure and component constraints of the new template can be incorporated into subsequent solutions.

[0086] In this embodiment, an object-level state management approach is used instead of a simple field tree structure. Each object carries information about its source, version, validity, and dependencies to support local failure propagation and incremental recalculation. See Table 2 below for details.

[0087] Table 2:

[0088] Each object establishes a directed dependency relationship through dependency_ids; when an object fails, the system only performs a local recalculation on the affected object, while reusing the unaffected object.

[0089] In another embodiment, the following is a set of optional data structures: DesignState = { version: integer, input_params: { ...}, structure_nodes: [...] layout_nodes: [ ... ], component_nodes: [ ... ], validation_nodes: [...] dependency_edges: [ ... ], stage_trace: [...] } Among them, dependency_edges can contain fields such as from_id, to_id, edge_type, condition_expr, priority, and created_by_stage; stage_trace can record stage identifier, start time, end time, list of read and write objects, execution status, and failure reason.

[0090] In another embodiment, taking an elevator product as the engineering solution of this embodiment, it specifically includes: User input includes: elevator type, load capacity, speed, lifting height, presence of machine room, door opening method, shaft-related boundaries, car boundary preferences, function options, and interior decoration options.

[0091] Standard configuration expansion: Based on the selected ladder type and standard configuration template, the system automatically completes the default component preferences, default counterweight arrangement method, standard shaft assumption, default door system strategy, etc., and marks these fields as source_tag=standard in DesignState.

[0092] Parameter linkage verification: If the door opening type entered by the user is incompatible with the selected ladder type, or if some building boundaries conflict with the main specifications, the parameter linkage and verification module will directly generate conflict items; if only non-critical fields are missing, it is allowed to proceed to the next stage and be filled in by the default strategy.

[0093] Structural Stage: Based on key specifications such as ladder type, load capacity, speed, and whether or not there is a machine room, determine the framework of the structural scheme, including the core structural path, counterweight position pattern, and whether or not there are special functional components.

[0094] Geometric Phase: Based on the structural design and hoistway boundaries, calculate the car dimensions, door width, guide rail layout, top floor height, pit depth, and installation space for each component. Dimensions explicitly specified by the customer are preferentially retained by the system; for unspecified dimensions, they are automatically derived from rules.

[0095] Physical phase: Based on load, speed, lifting height, and geometric boundaries, determine the candidate range of drive-type, rope-type, gate system-type, or load-bearing-type components.

[0096] Components and Interfaces Stage: The system matches specific models from the component library and checks the compatibility of interfaces such as guide rails and guide shoes, car and car frame, and door system and door opening dimensions.

[0097] Monitoring and Verification Phase: The system calculates weight, price, and various rationality verification results. If all door system candidates fail due to non-compliance with installation boundaries, a partial recalculation is triggered during the layout phase or the door system selection phase.

[0098] Modification scenario: If a user changes the alignment position from scheme A to scheme B, the dependency graph will identify that layout nodes, related component nodes, and validation nodes are invalid, but will not affect decoration option nodes unrelated to the modification. Based on this, the system only recalculates the affected objects and outputs the differences before and after the modification.

[0099] like Figure 2 In one embodiment shown, the system portion of the present invention specifically includes: Interactive input module: Receives basic specification parameters, requirement parameters, environmental constraints, standard configuration identifiers, and mid-process modification information, and performs standardization and field mapping for heterogeneous inputs.

[0100] Standard configuration expansion module: Based on standard templates, standard parameters, or historical default configurations, it generates default parameters, default component preferences, and initial design status, and records the source identifier.

[0101] State Management Module: Maintains a unified design state object and is responsible for storing and updating object version numbers, validity flags, source information, dependencies, and stage execution records.

[0102] Dependency graph management module: Establishes dependency edges between parameter nodes, structure nodes, layout nodes, component nodes, and verification nodes for impact analysis and local recalculation.

[0103] Parameter linkage and verification module: handles parameter range, mutual exclusion, dependency, missing items and logical contradictions, and forms a feasible input domain or provides conflict explanation.

[0104] Multi-stage decision agent scheduling module: Schedules structure decision, layout decision, component decision, interface verification, monitoring and evaluation, and feedback calculation according to preset stage sequence, conditional branches, or strategy rules.

[0105] Geometry Engine: Calculates geometric results such as spatial dimensions, positional relationships, installation boundaries, assembly spacing, and layout.

[0106] Physics Engine: Determines the candidate range or model of drive class, load class, and performance-related components based on performance, load, or operating conditions.

[0107] The component library and interface relationship module maintains component attributes, applicable conditions, interface rules, and combination constraints, and completes candidate component matching and compatibility checks.

[0108] Monitoring and Verification Module: Performs geometric, interface, physical, price, weight and business indicator verifications on the current solution, and outputs risk, score and failure reason.

[0109] Impact Analysis and Local Recalculation Module: When input is modified, strategy is changed, or validation fails, the module determines the affected subgraph based on the dependency graph and performs local failure and local recalculation.

[0110] Results output module: Outputs final scheme parameters, structural results, component list, modification comparison, verification results, and data interface for order breakdown.

[0111] All data collection and extraction in this invention are carried out under compliant and legal conditions.

Claims

1. A multi-stage configuration method for non-standard electromechanical equipment, characterized in that, include: Obtain the parameters and environmental constraints of non-standard electromechanical equipment, generate an initial state object, and expand the default fields; Construct a directed dependency graph, wherein the directed edges include at least the derivation edges from product parameters to structural results, the geometric constraint edges from structure to layout, the selection edges from layout to components, the interface edges between components, and the verification edges from components to verification results. The multi-stage decision agent chain is invoked to execute structural decisions, spatial layout calculations of installation boundaries and locations output by the geometry engine, and component selection in a preset stage order. Write the results of structural decisions, layout calculations, and component selections into a state object, record the source tags and dependency lists of each result, and output product data.

2. The multi-stage configuration method for non-standard electromechanical equipment according to claim 1, characterized in that, The construction of the directed dependency graph includes loading the basic dependency template corresponding to the product family, defining the main link of the phase, parsing the field reference relationship in the parameter rules, component application conditions and verification rules, and automatically generating object-level dependency edges. During the execution of each stage, runtime dependency edges are dynamically supplemented based on the actual set of objects read and written.

3. The multi-stage configuration method for non-standard electromechanical equipment according to claim 1, characterized in that, Before outputting product data, if parameters change or verification fails, the failure node is marked according to the dependency graph, and the local recalculation starts from the earliest rollback stage. After updating the state object, the product data is output. If the recalculation is triggered by verification failure, the root cause object and suggested rollback stage information in the failure reason are parsed. If it is due to insufficient space size, the rollback is to the layout stage. If the physical performance is not met, the process will revert to the structural stage or the physical selection stage; if the component interfaces are incompatible, the process will revert to the component selection stage.

4. The multi-stage configuration method for non-standard electromechanical equipment according to claim 3, characterized in that, The step of marking failed nodes according to the dependency graph includes starting from the source node of the change, traversing backward along the dependent edges, and judging the propagation condition of each edge in turn; if the propagation condition of the edge is not met, or the value of the target node after recalculation has not changed, or the target node is locked by the user, then the failure propagation is blocked and a conflict prompt is generated; only the successor nodes that meet the propagation conditions and are not blocked are added to the set of affected nodes and marked as failed.

5. The multi-stage configuration method for non-standard electromechanical equipment according to claim 3, characterized in that, The partial recalculation from the earliest rollback stage includes splitting each result object into multiple field-level results, with dependent edges pointing to specific fields within the object; when an upstream field changes, only downstream fields that directly or conditionally depend on that field become invalid; for strongly coupled scenarios, the invalidation granularity is increased to the object level or stage level based on edge type or rule declaration.

6. The multi-stage configuration method for non-standard electromechanical equipment according to claim 1, characterized in that, The multi-stage decision agent chain is specifically implemented by using a collaborative solution of a geometry engine, a physics engine, and interface relationships. The geometry engine outputs spatial layout nodes based on the structural results, and the physics engine outputs a candidate set of performance components based on the main specifications and geometric boundaries. The component library and interface relationship module calculate the intersection of the geometric candidate set, the physical candidate set, and the feasible set of interfaces. If the intersection is empty, the root cause is located and a local rollback of the corresponding stage is triggered until a feasible result is found.

7. The multi-stage configuration method for non-standard electromechanical equipment according to claim 1, characterized in that, The expanded default field adopts a hierarchical priority mechanism, which prioritizes the field source. User explicit input takes precedence over standard templates. When switching standard configuration templates, fields that have been locked by the user are retained, new template values ​​are used for unmodified fields, and conflict nodes are generated for conflicting fields, triggering local recalculation by the dependency graph.

8. A multi-stage configuration method for non-standard electromechanical equipment according to claim 1 or 2, characterized in that, The construction of the directed dependency graph also includes, when a new custom parameter declaration is received, if the parameter is referenced by a calculation formula, component application conditions or verification rules, or is explicitly mapped to an existing standard field, then a directed edge pointing to the relevant result node is established for the node of the parameter in the dependency graph; if the parameter is not referenced by any rule and has no mapping relationship, it is only saved as a display field and does not participate in automatic propagation and recalculation.

9. The multi-stage configuration method for non-standard electromechanical equipment according to claim 1, characterized in that, In the state object, each result object includes at least an object identifier, a generation stage identifier, a list of dependent objects, a source tag, a version number, and a validity flag; the distinguishing field of the source tag is generated by explicit user input, standard template expansion, rule deduction, or system default; when an object is marked as invalid, the system locates all subsequent affected objects according to the list of dependent objects and the dependency graph, and only sets the validity flag of the affected objects to invalid.

10. A multi-stage configuration system for non-standard electromechanical equipment, employing the multi-stage configuration method for non-standard electromechanical equipment as described in any one of claims 1-9, characterized in that, include: The State Management module maintains a unified design state object; the Dependency Graph module connects to the State Management module and maintains a directed dependency graph with design objects as nodes and derivation or constraint relationships as edges; the Multi-Stage Decision Agent Scheduling module connects to the State Management module and the Dependency Graph module respectively, and calls the geometry engine, physics engine, and component library interface modules in stages; the Impact Analysis and Local Recalculation module connects to the Dependency Graph Management module, the State Management module, and the Scheduling module respectively, and determines the affected subgraphs based on the dependency graph and triggers local recalculation.

11. An electronic device, characterized in that, It includes a memory and a processor, the memory storing a program that is executed by the processor to perform a multi-stage configuration method for non-standard electromechanical equipment as described in any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, It stores a computer program, which is executed by a processor to perform a multi-stage configuration method for non-standard electromechanical equipment as described in any one of claims 1-9.

Images