A MagicGrid framework model semi-automatic generation method based on historical data

Abstract

This application relates to the field of model building technology, specifically to a semi-automatic generation method for the MagicGrid framework model based on historical data. It constructs business objects by semantically parsing the descriptive information of the target business scenario and retrieving corresponding implementation instances from a historical engineering database, extracting implementation domain features such as structure, behavior, interface, and performance. Based on these features, it performs functional reverse abstraction, generating a functional domain model covering requirements, structure, behavior, and quality attributes, and forming a structured description according to the MagicGrid hierarchy specification. It constructs an architecture evolution hypergraph, jointly evaluating the risks, costs, and migration costs of multiple candidate evolution paths to determine the target system configuration and corresponding hardware and software implementation schemes. This achieves a closed-loop automated design driven by historical experience, encompassing system architecture reverse abstraction and forward generation, improving the consistency, feasibility, and engineering controllability of complex system designs.

Description

Technical Field

[0001] This application relates to the field of model building technology, specifically to a semi-automatic method for generating MagicGrid framework models based on historical data. Background Technology

[0002] With the development of software-defined complex systems, system architecture design is gradually evolving from static modeling to data-driven and model-driven approaches. The traditional MagicGrid framework, as a relatively mature systems engineering method, typically relies on top-down requirements decomposition during the system design process, starting from the requirements layer and deriving the functional architecture, logical architecture, and physical implementation scheme layer by layer. However, in large-scale engineering projects, requirements are often difficult to express completely and accurately in the early design stages, and different project teams have different understandings of the requirements, leading to significant deviations in the final system architecture regarding feasibility, stability, and performance optimization.

[0003] On the other hand, many engineering organizations have accumulated a wealth of implementation data from real-world projects, including structural configurations, behavioral trajectories, operational logs, and evolutionary change records. This data contains empirical information about the system's evolution from its initial configuration to a stable one. However, most existing technologies use historical data as reference material and lack the ability to systematically map historical implementation data to the various layers of the MagicGrid model, failing to achieve automatic abstraction and structured modeling based on historical experience. Furthermore, existing backward optimization methods typically only perform static optimization within the target configuration space, failing to consider the path and risk characteristics of the system's gradual migration from the current state to the target state. This means that even if the target configuration is theoretically feasible, its practical engineering implementation may still face high costs, high risks, or difficulties in rollback. Summary of the Invention

[0004] The technical problem this application aims to solve is to address the shortcomings of existing technologies by providing a semi-automatic generation method for the MagicGrid framework model based on historical data. This method involves semantically parsing the descriptive information of the target business scenario to construct business objects, retrieving corresponding implementation instances from a historical engineering database, and extracting implementation domain features such as structure, behavior, interface, and performance. Based on these features, functional reverse abstraction is performed to generate a functional domain model covering requirements, structure, behavior, and quality attributes, and a structured description is formed according to the MagicGrid hierarchy specification. Furthermore, an architecture evolution hypergraph is constructed, and the target system configuration and corresponding hardware and software implementation scheme are determined by jointly evaluating the risks, costs, and migration costs of multiple candidate evolution paths. This achieves a closed-loop automated design driven by historical experience, encompassing both reverse abstraction and forward generation of system architecture, which improves the consistency, feasibility, and engineering controllability of complex system designs.

[0005] To achieve the above objectives, this application provides the following technical solution:

[0006] A semi-automatic method for generating MagicGrid framework models based on historical data, the method comprising:

[0007] The business object is obtained by parsing the description information of the target business scenario, and the historical implementation data corresponding to the target business scenario is obtained based on the business object;

[0008] The historical implementation data is subjected to implementation domain feature extraction to obtain the feature elements of each implementation scheme at the physical implementation level.

[0009] Based on the aforementioned feature elements, a functional reverse abstraction is performed to obtain the corresponding functional domain model, and a structured description corresponding to the functional domain model is generated. The functional domain model is used to represent the set of functions, functional logic, and functional relationships that each implementation scheme satisfies in the target business scenario.

[0010] Based on the structured description, reverse optimization is performed. Under preset design constraints, the target system configuration and corresponding software and hardware implementation scheme are determined. The target system configuration and corresponding software and hardware implementation scheme are then encapsulated according to the hierarchical organization method of the MagicGrid framework to generate a MagicGrid framework model to support the target business scenario.

[0011] Based on the structured description, reverse optimization is performed to determine the target system configuration and corresponding hardware and software implementation schemes under preset design constraints, including:

[0012] Based on the requirements of the target business scenario, the functional requirements, performance requirements, reliability requirements, and security requirements of the target business scenario are parsed, and the requirements are mapped into design constraints and optimization objectives.

[0013] Based on the structured description and the historical implementation data, an architecture evolution hypergraph is constructed, wherein the hypergraph nodes of the architecture evolution hypergraph are used to represent candidate system configurations adapted to some of the required information, and the hyperedges are used to represent migration steps generated by a combination of multiple software and hardware component migration operations, and each hyperedge is weighted by migration cost, migration risk and downtime.

[0014] Based on the candidate system configuration, multiple target evolution paths are determined;

[0015] By comprehensively considering the migration costs, risks, and downtime of multiple target evolution paths, a unique evolution path is determined. The system configurations corresponding to the unique evolution path are combined to form the target system configuration. Based on the software and hardware component migration operations corresponding to each migration step in the unique evolution path, a software and hardware implementation scheme corresponding to the target system configuration is generated.

[0016] Based on the candidate system configuration, multiple target evolution paths are determined, including:

[0017] Select a current system configuration from the candidate system configurations, determine the current child node of the current system configuration based on the control flow graph and physical deployment graph in the structured description, and determine the set of candidate child nodes corresponding to the remaining system configurations in the candidate system configurations based on the design constraints, wherein the current child node and candidate child nodes represent the hardware and software components of the system configuration;

[0018] In the architecture evolution hypergraph, starting from the current child node and ending at any candidate child node in the candidate child node set, multiple evolution paths connecting the starting point and the ending point are optimized based on the optimization objective to obtain the target evolution path.

[0019] Combining the system configurations corresponding to the unique evolution path into the target system configuration includes:

[0020] The data flow graphs and control flow graphs in the structured descriptions of each system configuration on the unique evolution path are compared, and the input-output relationships, behavioral links and dependencies between functional units are merged to obtain the target functional layer description.

[0021] Based on the physical deployment diagram of each system configuration in the unique evolution path, the deployment locations of the hardware and software components in the multi-hop migration step are extracted, and the deployment is adjusted according to the new deployment requirements to obtain the target physical deployment diagram.

[0022] Generate the target system configuration based on the target functional layer description and the target physical deployment diagram.

[0023] The process of parsing the description information of the target business scenario to obtain the business object includes:

[0024] Semantic parsing is performed on the description information of the target business scenario to identify semantic entities that match business activities, operational targets, interactive subjects, and resource objects, and a business semantic graph is constructed.

[0025] The business semantic graph is extended with semantic relationships and nodes are aggregated. Based on the action chain, dependency chain and constraint chain between entities, corresponding business objects are generated.

[0026] Based on the business object, obtain historical implementation data corresponding to the target business scenario, including:

[0027] Determine the associated query conditions for the business object, and retrieve the implementation instances that match the associated query conditions from the preset historical project database, wherein the retrieval is achieved through semantic similarity matching based on the domain knowledge graph;

[0028] Based on the implementation example, historical implementation data, including structural data, behavioral data, interface data, performance data, and runtime log data, is extracted through data parsing.

[0029] The implementation example of retrieving data from a preset historical project database that matches the associated query conditions includes:

[0030] Based on the aforementioned association query conditions, index information of candidate implementation instances is obtained from the historical project database. The index information includes function tags, module tags, interface categories, engineering domain tags, and version identifiers.

[0031] The index information of the candidate implementation instance is semantically vectorized to obtain a semantic feature vector, wherein the semantic vectorization process includes mapping the function label, module label and interface category to a semantic feature vector according to a preset domain knowledge graph.

[0032] The semantic similarity is calculated based on the semantic feature vector and the semantic vector of the associated query conditions, and the semantic similarity is weighted and corrected according to the time sequence of the version identifier.

[0033] Candidate implementation instances with semantic similarity greater than a preset similarity threshold are selected as implementation instances that match the associated query conditions.

[0034] The historical implementation data includes structural data, behavioral data, interface data, and performance data. Implementation domain features are extracted from the historical implementation data to obtain the feature elements of each implementation scheme at the physical implementation level, including:

[0035] Based on the structural data, the software and hardware components, dependencies between components, and deployment topology in the structural data are parsed to obtain structural features including component type, connection relationship, and deployment location.

[0036] The component's operational behavior sequence is analyzed based on the behavioral data to identify behavior triggering patterns, state transition patterns, and resource call patterns, thereby obtaining behavioral characteristics that reflect the execution mode of the implementation scheme.

[0037] Based on the communication protocol, parameter constraints, and interface bandwidth between the interface data parsing components, an interface call matrix is ​​generated to obtain interface characteristics that reflect the software and hardware interaction methods.

[0038] Statistical analysis is performed on the performance data to extract performance characteristics including latency, throughput, resource utilization, and reliability indicators;

[0039] By combining behavioral characteristics, interface characteristics, and performance characteristics, the hardware and software requirements of the implementation instances corresponding to the historical implementation data are obtained;

[0040] Based on the aforementioned hardware and software requirements and implementation structure diagram, feature elements for functional reverse abstraction are generated.

[0041] Based on the aforementioned feature elements, a functional inverse abstraction is performed to obtain the corresponding functional domain model, including:

[0042] Based on the implementation structure diagram in the feature elements, the topological relationships and dependency strengths of the software and hardware components are clustered to identify the subsystem candidates corresponding to the component set, and the structural clustering results reflecting the system decomposition boundary are obtained.

[0043] Based on the software and hardware requirements in the feature elements, software and hardware components with common behavioral links are mapped to functional units, and corresponding coupled and interactive software and hardware components are associated with the same functional unit to obtain a set of functional candidates.

[0044] Based on the structural clustering results and the functional candidate set, a functional domain model is constructed, which includes subsystems, components and the functional relationships between components. The functional domain model includes requirement description, structural description, behavioral description, parameter description and general quality description.

[0045] Generate a structured description corresponding to the functional domain model, including:

[0046] Based on the input-output relationships, behavioral links, and dependencies of the functional units in the functional domain model, construct data flow graphs and control flow graphs between the functional units;

[0047] Based on the mapping relationship between the functional units and the hardware and software components, the behavioral logic of the functional units is converted into a component-level interaction sequence, and the logical calling relationship between components is generated based on the interaction sequence.

[0048] Based on the logical call relationships between components, the components are mapped to the physical nodes that can be supported, generating a physical deployment diagram that includes deployment topology, communication links, and resource binding relationships;

[0049] Based on the requirement description, parameter description, and general quality description in the functional domain model, performance requirements, resource constraints, and quality attributes are mapped to requirement layer constraint items;

[0050] Based on the hierarchical specifications of the MagicGrid framework, data flow diagrams, control flow diagrams, physical deployment diagrams, and requirement layer constraints are modeled in a unified manner to obtain a structured description.

[0051] Compared with the prior art, the beneficial effects of this application are:

[0052] This application constructs business objects, maps historical implementation instances, and performs reverse abstraction of functions, so that the generation of MagicGrid's model no longer relies entirely on human understanding and requirement description, but is derived based on the mature experience of historical projects, thereby improving the efficiency and consistency of model reuse. Attached Figure Description

[0053] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0054] Figure 1 A schematic diagram illustrating the generation principle of the existing MagicGrid framework model provided in this application embodiment;

[0055] Figure 2 An exemplary application scenario diagram provided for an embodiment of this application;

[0056] Figure 3 A schematic diagram of a processor module provided in an embodiment of this application;

[0057] Figure 4 This is a flowchart illustrating a semi-automatic method for generating a MagicGrid framework model based on historical data, provided in an embodiment of this application. Detailed Implementation

[0058] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0059] The term "embodiment" as used herein means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0060] It should be noted that the system mentioned in this article can be understood as a specific implementation device or platform for implementing a semi-automatic generation method of the MagicGrid framework model based on historical data. This device or platform includes, but is not limited to, a combination of hardware and software capable of performing a series of steps such as descriptive information parsing, historical implementation data extraction, functional reverse abstraction, and reverse optimization.

[0061] The proposed semi-automatic generation method for MagicGrid framework models based on historical data is mainly aimed at system engineering scenarios with complex cross-layer constraints, long-term engineering accumulation, and highly diverse project forms, including but not limited to vehicle electronics and vehicle control systems, integrated flight control and mission payload systems, integrated rail transit train control and operation and maintenance systems, and collaborative systems of industrial process control platforms and edge computing nodes.

[0062] Understandably, in such scenarios, enterprises often have accumulated a large amount of historical engineering data covering requirements documents, architecture design specifications, module divisions, interface specifications, simulation models, operation logs, and maintenance events. However, this data is isolated by project and is difficult to integrate back into a model-based systems engineering approach. As a result, when designing a new system, it is still necessary to manually build the MagicGrid model from top to bottom, starting from abstract requirements. This not only consumes a lot of architect experience but also makes it difficult to systematically inherit the successful architecture patterns and failures of historical projects.

[0063] In engineering practice, conventional MBSE forward modeling processes like MagicGrid typically start with the requirements specification of the target business scenario. Architects, based on their personal experience and domain knowledge, deduce functional, logical, and physical views layer by layer, repeatedly adjusting them through multiple rounds of review and trial and error. This model was acceptable in early projects, but as system scale increases, cross-domain coupling strengthens, and software and hardware evolution accelerates, relying solely on manual functional decomposition and architecture selection at the abstract level gradually reveals three main challenges:

[0064] First, a large number of real and effective functional combination patterns and physical deployment patterns have been accumulated in code libraries, configuration libraries and log libraries for a long time and cannot be structurally expressed as a reusable MagicGrid model.

[0065] Secondly, the correspondence between the functional layer, logical layer and physical layer evolves continuously in different projects, and it is difficult to maintain consistency and traceability by relying solely on manual memory and static documents;

[0066] Third, when business scenarios are fine-tuned or constraints change, forward modeling often requires a complete re-engineering process, lacking the ability to quickly refactor based on experience-driven data from historical implementations.

[0067] Furthermore, after obtaining a functional domain model and multi-layered structured description driven by historical data, this application treats system configurations that have appeared in different projects and versions as discrete nodes in the architecture evolution space. It introduces migration steps involving collaborative changes of multiple components as hyperedges to construct an architecture evolution hypergraph, explicitly depicting the historical statistical behavior of various architecture changes in terms of migration cost, migration risk, and downtime. Leveraging the requirements of the target business scenario, functional requirements, performance requirements, reliability requirements, and security requirements are mapped to design constraints and optimization objectives. Instead of simply searching for a statically optimal configuration in the evolution hypergraph, it starts from the currently feasible configuration and follows a multi-stage migration path validated by historical projects. Taking into account the cumulative risks and resource consumption along the path, it reconstructs validated and stable subsystems and component combinations in the configurations along the way into a new target system configuration, and generates matching software and hardware implementation schemes accordingly.

[0068] refer to Figure 1 , Figure 1 A schematic diagram illustrating the generation principle of the existing MagicGrid framework model provided in this application embodiment.

[0069] The MagicGrid framework is a modeling tool for complex systems engineering. Its core idea is to use three key domains:

[0070] Problem domain, solution domain, and implementation domain organize and abstract the system at each level, from requirements to implementation, to achieve systematic modeling from concept to implementation. Each domain undertakes different modeling responsibilities, helping designers analyze, abstract, and design the system from multiple perspectives.

[0071] like Figure 1 As shown, the framework adopts a progressive modeling process from the problem domain to the solution domain, and then to the implementation domain. In this process, engineers first start with business requirements, analyzing the requirements information in the problem domain. This information typically includes the core problems the system must solve, design goals, and constraints. Based on the requirements of the problem domain, engineers generate a solution domain model through step-by-step derivation and abstraction. In this model, functional units, component divisions, and interaction relationships are abstracted into actionable design solutions.

[0072] After abstracting the solution, the actual hardware and software deployment scheme is gradually clarified by modeling the implementation domain. The implementation domain model focuses on the practical feasibility of the design scheme, mapping specific physical components, hardware resources, and operating environments to the system, thereby completing the complete modeling process from the problem domain to the solution domain and then to the implementation domain.

[0073] It should be noted that, Figure 1The black box perspective can be understood as the external or requirement-based view of a system. Within the problem domain, the black box represents the system's input / output interfaces, functional requirements, and external constraints. The black box perspective focuses on the system's functional behavior without delving into internal implementation details. Through this perspective, designers can capture the problems the system must solve, external interaction requirements, and the system's expected output, serving as the starting point for the entire architecture modeling process.

[0074] White-box can be understood as the internal or implementation perspective of a system. In the solution domain, white-box represents the structural decomposition and design scheme of the system. From this perspective, the system's internal working mechanisms, functional module division, and relationships between components are described in detail. The white-box perspective focuses on the system's architecture, how various functional units work together, and how hardware and software resources are allocated, making it a core part of the design process.

[0075] The system can be understood as a bridge between the problem domain and the solution domain, representing the overall functional goals. In the MagicGrid framework, the system typically includes multiple functional units, and the system perspective focuses on the global design and the implementation of business requirements. The system perspective helps architects understand the system-level characteristics required by the target business scenario, such as performance requirements, availability requirements, and security constraints, thereby determining the direction and scope of the overall design.

[0076] A component can be understood as an independent functional unit within a system, typically located in the design phase of the solution domain. Components can be hardware, software, or a combination thereof, and are responsible for performing specific tasks within the system. Components interact and collaborate through interfaces, and each component possesses independent functionality, inputs, outputs, and processing capabilities. Component design must not only consider its functionality but also ensure its compatibility and interoperability with other components to form an effective system solution.

[0077] A device can be understood as the physical device layer that ultimately implements the functionality in a system. In the implementation domain, a device represents the specific physical manifestation of hardware resources or execution modules. The device perspective focuses on how to translate white-box design into actual hardware and software configurations, how to deploy components and manage resources to ensure that the system's functionality can operate stably in a real-world environment.

[0078] refer to Figure 2 , Figure 2 This is an exemplary application scenario diagram provided for an embodiment of this application.

[0079] like Figure 2As shown, through a process of gradual abstraction, information flow, and reverse optimization, the system automatically generates solutions from requirements. The closed-loop system architecture ensures the integrity and consistency of the design. The system architecture design process involves multi-level information interaction, including descriptive information, historical implementation data, and requirement information, specifically encompassing the following four aspects:

[0080] Firstly, in the initial design phase, descriptive information serves as input. This descriptive information typically includes functional requirements of the business scenario, design standards, customer customization needs, and historical project documents. By parsing this descriptive information, the system can identify the requirements, constraints, and technical parameters related to the target business scenario. Then, based on this information, the system extracts relevant design and implementation experience from historical implementation data. This historical implementation data includes structural data, behavioral data, interface data, and performance data used in past projects. This data helps the system understand the success patterns and lessons learned from past solutions.

[0081] Secondly, after abstracting and filtering the descriptive information, historical implementation data is imported into the implementation domain. In the implementation domain, historical data is used to abstract specific devices and hardware resources. This process includes detailed mapping of device characteristics, hardware specifications, performance parameters, etc., ensuring that valuable information extracted from historical data can be implemented into actual hardware and software devices.

[0082] For example, if a specific processing unit or sensor was used in a historical project, the corresponding device type and its working mode can be abstracted based on the performance and reliability data in the historical data. These devices will serve as key components in the system implementation.

[0083] Thirdly, after the specific devices are identified in the implementation domain, these devices and hardware resources need to be further abstracted into the solution domain. The solution domain focuses on the design at the system and component levels. Through abstraction, the system maps devices to systems and components, meaning that the functional units within a device will be decomposed into multiple independent system modules and sub-components.

[0084] For example, in the development of an in-vehicle infotainment system, functional units such as navigation, voice recognition, and entertainment systems may be treated as separate system modules, and each system module may contain multiple sub-components, such as hardware sensors, interface modules, and data processing units. In this way, the solution domain provides a high-level view of the system architecture, making it easier for designers to understand the interaction relationships and dependencies between modules.

[0085] Thirdly, after completing the preliminary design of the solution domain, the next step is the reverse optimization phase. The goal of reverse optimization is to optimize and adjust the existing design to meet the specific constraints and optimization objectives in the requirements information. Through feedback from historical data, reverse optimization can analyze the optimal design path based on the performance of previous systems and select the best implementation path for different requirement constraints.

[0086] Through reverse optimization, the system can find the optimal hardware and software combination and deployment method within the existing design space, based on successful patterns validated in historical projects. This process ensures that the design is not merely theoretical but built upon the optimization results of existing data and experience, guaranteeing its feasibility and efficiency in practical applications.

[0087] Fourthly, after determining the target solution domain and its corresponding hardware and software implementation schemes through reverse optimization, the next step is to match these schemes with the requirements information in the initial problem domain. Through feedback on the requirements information, the system will verify whether the generated target system fully meets the requirements of the business scenario by comparing it with the initially set requirements, performance standards, and security constraints.

[0088] Through reverse optimization and feedback correction of demand information, the system will generate a complete target solution domain, that is, the final system architecture and implementation solution, which not only meets business needs, but also has efficient resource allocation, optimized hardware and software configuration, and reliable system performance.

[0089] It is understood that the third and fourth aspects of this application can be implemented using the same reverse optimization process. Specifically, the third aspect forms a preliminary solution domain architecture by abstracting the device into systems and components. Subsequently, the reverse optimization process in the fourth aspect further optimizes the system design based on the preliminary solution domain, continuously adjusting the solution and optimizing the system architecture based on feedback from requirement information and verified successful patterns in historical data. Ultimately, the joint reverse optimization process of the third and fourth aspects forms a closed loop, thereby ensuring the rationality and consistency of the design solution.

[0090] In some specific embodiments, this application provides a processor for implementing a semi-automatic generation method for a MagicGrid framework model based on historical data, as provided in this application.

[0091] It is understood that the processor can adopt a variety of hardware platforms, such as microprocessors, digital signal processors, FPGAs, embedded systems or general-purpose computers, etc., and this application does not limit them.

[0092] refer to Figure 3 , Figure 3 A schematic diagram of a processor module provided in an embodiment of this application.

[0093] like Figure 3 As shown, the processor includes:

[0094] The data parsing module is used to parse the descriptive information of the target business scenario and identify business activities, operating targets, interaction subjects and resource objects. It constructs a business semantic graph through semantic parsing and generates corresponding business objects.

[0095] The historical data extraction module is used to determine the associated query conditions based on the business object, retrieve the implementation instances that match the associated query conditions from the preset historical project library, and extract historical implementation data including structural data, behavioral data, interface data, performance data and operation log data from them;

[0096] The functional reverse abstraction module is used to extract implementation domain features from the historical implementation data and perform functional reverse abstraction based on the feature elements to generate a corresponding functional domain model, and generate a structured description based on the functional domain model.

[0097] The evolution path optimization module performs reverse optimization on the target business scenario based on the structured description. Under preset design constraints, it constructs multiple target evolution paths through the architecture evolution hypergraph, comprehensively considers migration costs, migration risks, and downtime, determines a unique evolution path, and generates the target system configuration and corresponding software and hardware implementation scheme.

[0098] Next, with reference to the accompanying drawings, we will further describe the semi-automatic generation method for the MagicGrid framework model based on historical data provided in this application. Figure 4 The methods shown specifically include:

[0099] S1: Parse the business object based on the description information of the target business scenario, and obtain the historical implementation data corresponding to the target business scenario based on the business object;

[0100] In this embodiment, the process begins with the descriptive information of the target business scenario. By parsing this information, semantic entities matching business activities, operational objectives, interactive subjects, and resource objects are identified. Specifically, the descriptive information includes functional requirements, technical standards, constraints, and any relevant external environmental data within the target business scenario. Based on this descriptive information, a business semantic graph is constructed through semantic parsing, and key business objects are extracted from it.

[0101] S2: Extract implementation domain features from the historical implementation data to obtain the feature elements of each implementation scheme at the physical implementation level;

[0102] In this embodiment, historical implementation data is imported and feature extraction is performed. This historical implementation data includes structural data, behavioral data, interface data, performance data, and runtime log data from previous projects. At this stage, the system extracts detailed data about devices, components, and their interrelationships from historical projects and performs implementation domain feature extraction. Specifically, this data helps to parse the characteristic elements of each implementation scheme at the physical implementation level, such as component types, dependencies between functional modules, resource configuration, and performance during actual operation.

[0103] S3: Perform functional reverse abstraction based on the feature elements to obtain the corresponding functional domain model, and generate a structured description corresponding to the functional domain model;

[0104] The functional domain model is used to represent the set of functions, functional logic, and functional relationships that each implementation scheme satisfies in the target business scenario;

[0105] In this embodiment, the system performs functional reverse abstraction based on the feature elements obtained from the implementation domain feature extraction stage. By analyzing and refining key characteristics related to physical implementation, the system maps them to the functional domain, generating a functional domain model. This functional domain model describes the set of functions, functional logic, and functional relationships satisfied by each implementation scheme. Specifically, the functional domain model aggregates components related to similar functions, transforms them into functional units with clear functional attributes, and identifies their dependencies and collaboration logic.

[0106] Understandably, functional reverse abstraction can extract functional requirements from the physical characteristics of the implementation domain and use this as a basis to reconstruct the system. This process not only ensures the correct mapping from physical implementation to functional requirements, but also clarifies the correlation between functional units in a structured manner.

[0107] S4: Based on the structured description, reverse optimization is performed. Under the preset design constraints, the target system configuration and the corresponding software and hardware implementation scheme are determined. The target system configuration and the corresponding software and hardware implementation scheme are then encapsulated according to the hierarchical organization method of the MagicGrid framework to generate a MagicGrid framework model to support the target business scenario.

[0108] In this embodiment, the goal of reverse optimization is to select the optimal target system configuration and corresponding hardware and software implementation scheme from multiple possible paths based on given design constraints and requirements information.

[0109] Specifically, the system constructs an architecture evolution hypergraph, treating candidate system configurations as nodes and using hyperedges to represent component migration steps. It optimizes paths by considering factors such as migration costs, risks, and downtime. Through a reverse optimization mechanism, it extracts feasible design paths from historical implementation data and finds the optimal solution within these paths. This evolutionary hypergraph approach not only ensures that the system design meets requirements but also maximizes resource utilization efficiency on the optimal path while minimizing unnecessary risks and costs.

[0110] Before delving into the specific technical details of the steps, the embodiments of this application need to be emphasized again.

[0111] Typical engineering systems often undergo multiple iterations, with not only constantly changing functional requirements but also continuously adjusted hardware and software deployment methods in response to technological advancements, resource costs, and external constraints. Long-term iterations result in a vast amount of implementation data from historical projects, but with inconsistent structures. This data records the system's behavioral patterns, component dependencies, and configuration strategies at different stages, containing a wealth of tacit knowledge. However, this knowledge is often difficult to directly use in subsequent architecture design due to inconsistencies across versions, inconsistent modeling granularity, or a lack of semantic links. Consequently, new rounds of system construction typically still require manual re-decomposition of requirements and reorganization of the architecture at an abstract level.

[0112] The method proposed in this application is not merely a simple aggregation of historical data, nor is it a direct migration of existing architecture to new business scenarios. Instead, it is based on the structural analysis of historical implementation data to identify the implicit cross-domain mapping relationships and functional formation mechanisms. In other words, this embodiment attempts to use historical data to deduce the inherent logic of the system's stable structure in business scenarios, and uses this logic as the basis for constructing the domain models of MagicGrid. In particular, the construction of functional domain models does not rely on preset functional levels or human experience, but rather derives the set of functions and functional relationships that drive the system's operation by analyzing the collaborative behavior, resource consumption patterns, and interface coupling strength of hardware and software components. This bottom-up abstraction approach ensures that the final functional domain models naturally contain the statistical characteristics of the operating mechanisms, and compared to traditional top-down functional decomposition, it better reflects the structural alignment of real systems in complex environments.

[0113] Furthermore, there are often strong upstream and downstream dependencies between the solution domain and the implementation domain, with the solution domain being determined first and the implementation domain being matched subsequently, thus subjecting the solution selection space to artificially imposed constraints. In the modeling logic of this embodiment, the formation of the solution domain is based on the induction of the characteristics of the implementation domain, and then an evolutionary architectural path is searched in the structured description through a reverse optimization mechanism, thereby forming a system configuration that satisfies multiple constraints.

[0114] It is important to emphasize that this application does not simply seek the optimal architecture from historical data. Instead, it analyzes the path characteristics during component migration by building an evolutionary hypergraph between multiple versions and multi-source configurations, including the changing trends in complexity, risk, and resource costs of migration operations. In this way, this embodiment can identify architectural fragments that repeatedly appear in historical evolution and remain stable under various constraints, and use these fragments as the basic elements for constructing the target configuration.

[0115] In one example, the step of parsing the business object based on the description information of the target business scenario includes:

[0116] Semantic parsing is performed on the description information of the target business scenario to identify semantic entities that match business activities, operational targets, interactive subjects, and resource objects, and a business semantic graph is constructed.

[0117] The business semantic graph is extended with semantic relationships and nodes are aggregated. Based on the action chain, dependency chain and constraint chain between entities, corresponding business objects are generated.

[0118] Specifically, for text describing business scenarios, the syntactic structure is first parsed hierarchically. Four core semantic elements—action, executor, recipient, and constraint—are identified through dependency relationships and mapped to candidate semantic entities. Based on this, the candidate entities are semantically categorized using semantic categories from an engineering domain knowledge base. This allows for the automatic filtering out of semantically ambiguous, irrelevant modifiers, and other non-engineering vector content during the parsing process.

[0119] In this embodiment, business activities in engineering scenarios often involve cross-link associations, shared resource access, and parallel execution, relationships that cannot be accurately expressed through a single hierarchical structure. Therefore, by constructing a semantic graph with semantic entities as nodes and effects or dependencies as edges, the temporal logic, resource competition relationships, and system boundaries in the business scenario can be more accurately depicted. Subsequently, the semantic graph is extended with semantic relationships by utilizing synonyms, causal chains, and domain constraint rules stored in the knowledge graph to supplement the node relationships, enabling the graph structure to cover implicit relationships in business semantics that are not explicitly expressed but necessarily exist in engineering logic.

[0120] In yet another example, historical implementation data corresponding to the target business scenario is obtained based on the business object, including:

[0121] Based on the business object, the associated query conditions of the business object are determined, and implementation instances that match the associated query conditions are retrieved from the preset historical project database, wherein the retrieval is achieved by semantic similarity matching based on domain knowledge graph;

[0122] In some optional implementations, the step of retrieving data from a preset historical project database that matches the associated query conditions includes:

[0123] Based on the aforementioned association query conditions, index information of candidate implementation instances is obtained from the historical project database. The index information includes function tags, module tags, interface categories, engineering domain tags, and version identifiers.

[0124] The index information of the candidate implementation instance is semantically vectorized to obtain a semantic feature vector, wherein the semantic vectorization process includes mapping the function label, module label and interface category to a semantic feature vector according to a preset domain knowledge graph.

[0125] The semantic similarity is calculated based on the semantic feature vector and the semantic vector of the associated query conditions, and the semantic similarity is weighted and corrected according to the time sequence of the version identifier.

[0126] Candidate implementation instances with semantic similarity greater than a preset similarity threshold are selected as implementation instances that match the associated query conditions;

[0127] It is understood that the similarity threshold of this application can be determined through a large number of experiments, which will not be elaborated here;

[0128] Furthermore, semantic similarity can be calculated using existing technologies, such as based on Euclidean distance of semantic vectors, and this application does not limit the method.

[0129] Based on the implementation example, historical implementation data, including structural data, behavioral data, interface data, performance data, and runtime log data, is extracted through data parsing.

[0130] Next, we will further elaborate on the technical content of the method of this application regarding the feature elements.

[0131] In one example, the historical implementation data includes structural data, behavioral data, interface data, and performance data.

[0132] In another example, implementation domain features are extracted from the historical implementation data to obtain the feature elements of each implementation scheme at the physical implementation level, including:

[0133] S2.1: Based on the structural data, the software and hardware components, dependencies between components, and deployment topology in the structural data are parsed to obtain structural features including component type, connection relationship, and deployment location;

[0134] Specifically, when parsing the structural information in historical implementation data, it is necessary to abstract the hardware and software components and their connection methods of each version of the system into a computable graph structure. The reason for extracting component types, connection relationships, and deployment locations from the structural data is that these structural characteristics directly determine the system's coupling method, resource dependency paths, and cross-node communication methods, forming the basis for subsequent judgments on whether the system configuration can meet business functions and performance constraints. In different historical projects, the same functionality may be implemented by different component combinations, and component deployment locations may also differ due to resource limitations. Therefore, it is essential to standardize and extract structural information to ensure cross-version and cross-architecture comparability and derivability.

[0135] In this embodiment, the component information in the structural data is first standardized by mapping component names to standard component types in the domain knowledge base, thus eliminating discrepancies caused by different engineering teams and different version naming rules. Then, the connection fields in the topology description are parsed to transform the dependencies between components into directed edges, which are categorized into three types: control dependencies, data dependencies, and resource dependencies. This allows different types of connections to represent different logical meanings in subsequent abstraction. For deployment topology extraction, components are bound to corresponding nodes using node descriptions, and attribute parameters in the deployment relationship, such as computing performance, available bandwidth, and power consumption limits, are recorded synchronously, providing necessary information for subsequently determining component migration costs and deployability.

[0136] S2.2: Analyze the component's running behavior sequence based on the behavioral data, identify behavior triggering patterns, state transition patterns, and resource call patterns, and obtain behavioral characteristics that reflect the execution mode of the implementation scheme;

[0137] Specifically, behavioral data records the triggering conditions, state changes, and resource interaction patterns of hardware and software components during actual operation. This data serves as a crucial basis for determining the functional boundaries, functional carriers, and operational logic of components. By analyzing behavioral sequences, the execution chain of business functions within the system can be inferred, and the formation mechanism of functional units can be identified. Therefore, it is necessary to extract triggering patterns, state transition patterns, and resource call patterns from behavioral data to reflect the dynamic response characteristics of the implementation scheme under different operating conditions.

[0138] In this embodiment, the analysis of behavioral features is performed using a temporal segment reconstruction method:

[0139] First, the event sequences in the runtime logs are time-aligned to create a unified time base for constructing event chains of component behaviors. Then, by analyzing the triggering relationships between events, behavior triggering patterns are identified, such as timed triggering, conditional triggering, chained triggering, and external stimulus triggering. In state transition analysis, component behavior is represented as a state machine. By merging duplicate paths and removing non-critical states, a simplified state transition diagram is obtained, and transition probabilities and triggering condition information are extracted. Resource call pattern identification is based on resource logs. Resource usage is aggregated by component dimension to identify peak usage, periodic usage, and burst usage patterns, ensuring that behavioral characteristics reflect the component's load characteristics and resource dependencies during actual operation.

[0140] S2.3: Based on the communication protocol, parameter constraints, and interface bandwidth between the interface data parsing components, generate an interface call matrix to obtain interface characteristics that reflect the software and hardware interaction methods;

[0141] Specifically, interface data reflects the protocol constraints, parameter formats, bandwidth consumption, and interaction directions of communication between components, serving as a crucial basis for determining the tightness of component relationships and the boundaries of functional divisions. By extracting interface features, the interaction methods between components can be accurately identified, providing communication-level evidence for subsequent functional abstraction. In historical versions, interface specifications often change with architectural modifications; therefore, interface data must be uniformly parsed into a comparable structural representation.

[0142] In this embodiment, interface features are obtained by constructing an interface call matrix. First, the communication protocol is parsed from the interface description file or runtime log, mapping the protocol type to standard protocol categories such as CAN, LIN, Ethernet, SPI, and software bus, and parsing the communicating parties, parameter constraints, data rate, and QoS requirements. Then, all components are arranged into a matrix of rows and columns. By statistically analyzing the call frequency, bandwidth consumption, and parameter complexity of different communication directions, a weighted interface matrix is ​​constructed. The matrix elements simultaneously contain protocol type weights and call metrics, enabling the interface features to quantitatively reflect the degree of coupling between components.

[0143] S2.4: Perform statistical analysis on the performance data to extract performance characteristics including latency, throughput, resource utilization, and reliability indicators;

[0144] Specifically, performance data directly reflects the actual performance of the system under different loads and scenarios, including metrics such as latency, throughput, resource utilization, and reliability. It serves as an important reference for determining whether historical solutions are suitable for current requirements. The extraction of performance characteristics is not only used to describe the current implementation status but also to infer the boundaries of software and hardware requirements and the scope of implementation capabilities.

[0145] S2.5: Combining behavioral characteristics, interface characteristics, and performance characteristics, obtain the software and hardware requirements of the implementation instance corresponding to the historical implementation data;

[0146] Specifically, hardware and software requirements are system operational capability boundaries derived from historical implementation data, reflecting the computing power, storage capacity, bandwidth requirements, and reliability requirements needed for the system to implement a certain set of functions. Deriving these requirements is crucial for accurately determining the correspondence between functions and components in subsequent functional reverse abstraction.

[0147] In this embodiment, by fusing behavioral, interface, and performance characteristics in multiple dimensions, a capability clustering analysis is performed on each component to obtain its functional capabilities. For example, by jointly analyzing resource call patterns and performance peaks, the maximum load a component can handle can be determined; its communication capabilities can be inferred from the interface matrix. These quantitative indicators are compared with the capability labels of similar components in history to form a multi-dimensional vector description of software and hardware requirements.

[0148] S2.6: Based on the hardware and software requirements and implementation structure diagram, generate feature elements for functional reverse abstraction.

[0149] Next, we will further elaborate on the technical content of the structured description method in this application.

[0150] In one example, functional inverse abstraction is performed based on the aforementioned feature elements to obtain the corresponding functional domain model, including:

[0151] S3.1: Based on the implementation structure diagram in the feature elements, cluster the topological relationships and dependency strengths corresponding to the software and hardware components, identify the subsystem candidates corresponding to the component set, and obtain the structural clustering results that reflect the system decomposition boundary;

[0152] S3.2: Based on the software and hardware requirements in the feature elements, map software and hardware components with common behavioral links to functional units, and associate the corresponding coupled and interactive software and hardware components to the same functional unit to obtain a set of functional candidates;

[0153] S3.3: Based on the structural clustering results and the functional candidate set, construct a functional domain model including subsystems, components and the functional relationships corresponding to the components, wherein the functional domain model includes requirement description, structural description, behavioral description, parameter description and general quality description.

[0154] Specifically, to derive the functional domain model from the feature elements of the implementation domain, it is necessary to first analyze the topological relationships and dependency strengths between hardware and software components based on the implementation structure diagram. In this embodiment, when resolving structural dependencies, the division is not simply based on the number of component connections or static dependencies, but rather comprehensively considers connection direction, dependency type, and dependency strength to determine the range of candidate subsystems. Specifically, the dependency strength between components is measured by a multi-dimensional feature vector composed of indicators such as call frequency, interface complexity, communication bandwidth, and the number of behavior triggers. In regions where dependency links form a high density, this embodiment considers them as logically indivisible functional aggregation regions, and uses a hierarchical clustering method to divide these regions into structurally relatively closed sets of components, so that the clustering results can truly reflect the decomposition boundaries formed by the system in engineering practice.

[0155] In this embodiment, to further construct the functional candidate set, it is necessary to map shared behavioral links and components with synergistic effects as functional units. Based on the continuity of behavioral links, the pattern similarity of trigger sequences, and the consistency of resource calls, this embodiment quantifies the behavioral similarity between different components and identifies the set of components undertaking the same functional objectives through a behavioral aggregation algorithm.

[0156] It is worth noting that in engineering systems, different components may be loosely coupled through interfaces or resource sharing, and these loose couplings do not always manifest as obvious triggering or calling patterns.

[0157] For example, when two components appear in the same transaction processing link in the behavior sequence, and their interface data indicates bidirectional communication with clear direction and complex parameters, this embodiment merges them into the same functional unit, so that the function candidate set can more accurately reflect the functional carriers of the system in actual operation. Compared with the common division method based on component type or business experience in the prior art, this behavior link-oriented mapping method combined with interface coupling better reflects the dynamic mechanism of function generation and avoids the ambiguity or omission of functional boundaries caused by human experience.

[0158] Furthermore, this embodiment constructs a functional domain model that includes subsystems, components, and their functional relationships by comprehensively analyzing the structural clustering results and the functional candidate set. To ensure the completeness of the model, this embodiment incorporates five types of information—requirement description, structural description, behavioral description, parameter description, and general quality description—into the construction process of the functional domain model.

[0159] Among them, the requirement description is directly mapped from the target constraints of the business object and is used to define the external boundary of the functional domain model; the structural description uses the structural clustering results to determine the hierarchical relationship between subsystems and components in the functional domain; the behavioral description comes from the behavioral link patterns in the functional candidate set and is used to characterize the execution logic of the function; the parameter description comes from the normalization of performance and resource indicators and is used to define the operating conditions required for function execution; and the general quality description is based on the reliability and stability parameters in historical data and is used to reflect the quality assurance characteristics of the functional domain model in the engineering environment.

[0160] It is worth noting that the construction method used in this embodiment establishes a bidirectional derivation relationship between the implementation domain and the solution domain. That is, the formation of the functional domain model not only depends on the decomposition of requirements, but also on the functional formation mechanism deduced from historical implementation data, so that the model can simultaneously reflect the goals of the problem domain and the facts of the implementation domain.

[0161] In another example, generating a structured description corresponding to the functional domain model includes:

[0162] S3.4: Based on the input-output relationships, behavioral links, and dependencies of the functional units in the functional domain model, construct the data flow diagram and control flow diagram between the functional units;

[0163] S3.5: Based on the mapping relationship between the functional unit and the software and hardware components, the behavioral logic of the functional unit is converted into a component-level interaction sequence, and the logical calling relationship between components is generated based on the interaction sequence;

[0164] S3.6: Based on the logical call relationships between components, map the components to the physical nodes that can be supported, and generate a physical deployment diagram that includes deployment topology, communication links and resource binding relationships;

[0165] S3.7: Based on the requirement description, parameter description, and general quality description in the functional domain model, map performance requirements, resource constraints, and quality attributes to requirement layer constraint items;

[0166] S3.8: Based on the hierarchical specifications of the MagicGrid framework, the data flow diagram, control flow diagram, physical deployment diagram, and requirement layer constraints are modeled in a unified manner to obtain a structured description.

[0167] Specifically, to enable the functional domain model obtained through functional reverse abstraction to be further used for system configuration optimization, the abstract relationships in the functional domain model need to be transformed into a structured description with engineering executability, computability, and verifiability. This embodiment first reconstructs the data and control relationships between functional units at the functional domain level. Since functional units are formed through the cross-derivation of multi-source feature elements, they inherently contain execution links and triggering logic, but this implicit logic is insufficient to directly support cross-domain modeling. Therefore, this embodiment normalizes the input and output events of functional units, mapping event parameters of different versions and granularities to unified semantic event nodes. Then, a data flow graph is constructed based on the trigger sequence of the behavioral links to achieve a formal expression of the data transmission rules during function execution. Subsequently, to characterize the control relationships between functional units, conditional trigger points and state transition boundaries in the behavior are extracted to form a control flow graph reflecting timing control, concurrency control, and abnormal branches, giving the functional domain model a verifiable operational logic structure.

[0168] In this embodiment, by analyzing the mapping relationship between functional units and components, the functional behavior chain is decomposed into component-level event sequences in the time dimension. Since historical implementation data may contain behavior fragments with different temporal granularities, this embodiment employs a behavior fragment splicing and sequence consistency verification mechanism when generating interaction sequences to logically align cross-component behavior chains and verify the call direction and parameter compatibility between components based on interface characteristics. Furthermore, the interaction events between components are abstracted into logical call edges, and a weighted call relationship graph is constructed based on their call frequency, call latency, and parameter load.

[0169] It is worth noting that this process of reverse mapping from functional behavior to component behavior is not a simple split, but a comprehensive restoration of three elements: behavior chain, interface constraints, and component capabilities. This ensures that the generated interaction sequence is consistent with the actual system operation mechanism and avoids the logical deviation caused by the lack of implementation basis in the traditional top-down model.

[0170] Furthermore, components are mapped to physical nodes to generate a deployable physical deployment graph. This mapping process requires consideration not only of the logical call relationships between components but also of the node performance constraints, bandwidth limitations, storage capacity, and security isolation requirements inherent in the historical implementation structure.

[0171] For example, when a component exhibits high bandwidth and low latency call characteristics in the interaction sequence, nodes with high-speed communication buses or the same processor core should be prioritized during node selection to ensure that the performance after deployment does not deviate from the historical feasible state. This embodiment constructs a similarity matrix between node capability vectors and component requirement vectors, employs a heuristic matching algorithm to map components to physical nodes, and automatically generates communication links and resource binding relationships.

[0172] Next, we will further elaborate on the technical aspects of the reverse optimization method in this application.

[0173] Understandably, in order to enable the generated MagicGrid framework model to be truly used in a system evolution process that closely approximates actual engineering practice, this embodiment does not optimize the target system configuration independently, but rather combines structured description with historical engineering data to comprehensively analyze the feasible path of the system from its current state to the target configuration.

[0174] In many typical engineering scenarios, system architecture is not refactored all at once. Instead, it needs to be progressively advanced according to existing dependencies, historical version constraints, and the stability requirements of the hardware and software deployment environment. Therefore, evaluating only the merits of the final configuration often only yields the theoretical optimal solution, but it is difficult to describe the resource conflicts, link reconstruction risks, and operational interruptions that may occur during the actual migration process. Based on this engineering practice phenomenon, this embodiment regards version differences, component migration records, and their accompanying operational performance in historical implementation data as an implicit system evolution trajectory. By deriving the cost and risk characteristics of different migration operations through these trajectories, the reverse optimization process can be searched within a real and feasible evolution path space, rather than remaining in a static configuration space.

[0175] In one example, reverse optimization is performed based on the structured description to determine the target system configuration and corresponding hardware and software implementation schemes under preset design constraints, including:

[0176] S4.1: Based on the requirement information of the target business scenario, the functional requirements, performance requirements, reliability requirements and security requirements of the target business scenario are parsed, and the requirement information is mapped into design constraints and optimization objectives;

[0177] Specifically, before performing reverse optimization, it is necessary to transform the requirement information of the target business scenario from natural language or business document state into a computable and constrained structured form.

[0178] Understandably, different business scenarios have different priorities regarding performance, reliability, and security. If these priorities are not expressed using unified parameters, it will be impossible to establish clear target boundaries during evolution path optimization. Furthermore, requirements often contain implicit relationships, such as the coupling between functional and performance requirements, or the dependency between reliability requirements and fault tolerance strategies. If these implicit relationships are not identified during the constraint mapping phase, the configuration output from subsequent optimization will lack engineering feasibility.

[0179] In this embodiment, requirement information parsing involves semantically decomposing the business description text, converting the target behavior, performance thresholds, security levels, recovery strategies, and other related content into a set of requirement attributes, and then classifying and labeling the requirement items based on a domain knowledge base. Subsequently, by inferring the semantic logical relationships between the requirement items, functional requirements are converted into quantifiable execution link coverage, performance requirements are expressed as maximum latency, throughput, or load occupancy limits, reliability requirements are represented as node fault tolerance levels or redundancy of failed links, and security requirements are mapped to isolation levels or access control conditions, thereby generating multi-dimensional design constraints and optimization objectives.

[0180] S4.2: Based on the structured description and the historical implementation data, construct an architecture evolution hypergraph, wherein the hypergraph nodes of the architecture evolution hypergraph are used to represent candidate system configurations adapted to some of the requirement information, the hyperedges are used to represent migration steps generated by a combination of multiple software and hardware component migration operations, and each hyperedge is weighted by migration cost, migration risk and downtime.

[0181] Specifically, traditional architecture optimization typically only evaluates the static configuration space, failing to reflect the actual evolution cost of a real system from its current configuration to the target configuration. However, the thousands of version differences and migration records in historical implementation data precisely demonstrate how the system gradually adjusts under complex constraints. This embodiment constructs an architecture evolution hypergraph, abstracting component migrations, interface adjustments, and deployment changes in historical projects into composable migration steps, and representing the combination relationships of all migration steps as hyperedges, enabling the optimization process to take place in a realistic, evolvable path space.

[0182] In this embodiment, hypergraph nodes are generated by aggregating historical version configurations. Each node represents a candidate configuration that is feasible in some requirement dimensions and has been validated by engineering. Subsequently, by comparing the structure of version differences, changes such as component migration, interface replacement, and topology reorganization are abstracted into migration units. A multi-dimensional cost description is generated based on the performance fluctuations, number of risk events, and downtime caused by the migration units in historical operation. Multiple migration units form hyperedges according to the combination method of historical migrations, so that each hyperedge records information such as migration order, migration granularity, and the degree of accompanying resource impact.

[0183] S4.3: Based on the candidate system configuration, determine multiple target evolution paths;

[0184] Specifically, after the evolutionary hypergraph is constructed, feasible evolution paths need to be explored based on the current configuration and demand constraints. Since each path contains multiple migration steps with different risk structures, the engineering feasibility of the evolution cannot be guaranteed based on a single objective. Therefore, this embodiment simultaneously evaluates the performance improvement potential, risk accumulation trend, downtime cost, and dependencies between migration steps in the path space, ensuring that the final candidate paths can balance the quality of the target configuration with the stability of the evolution process.

[0185] In one example, based on the candidate system configuration, multiple target evolution paths are determined, including:

[0186] Select a current system configuration from the candidate system configurations, determine the current child node of the current system configuration based on the control flow graph and physical deployment graph in the structured description, and determine the set of candidate child nodes corresponding to the remaining system configurations in the candidate system configurations based on the design constraints, wherein the current child node and candidate child nodes represent the hardware and software components of the system configuration;

[0187] In the architecture evolution hypergraph, starting from the current child node and ending at any candidate child node in the candidate child node set, multiple evolution paths connecting the starting point and the ending point are optimized based on the optimization objective to obtain the target evolution path.

[0188] It is important to note that in the evolutionary hypergraph proposed in this application, although the hypergraph nodes represent the system configuration (i.e., the overall form of a certain version or a candidate architecture), using only the complete configuration as the nodes for graph search during actual path search will result in overly coarse search granularity, making it difficult to describe the local characteristics of migration actions in real-world engineering. The evolution of system architecture is not a one-time overall replacement, but typically involves local migrations around a specific functional carrier or hardware / software component. Therefore, this embodiment introduces the concept of child nodes in reverse optimization, making the path search more closely resemble engineering implementation methods.

[0189] Understandably, a child node is the smallest transferable unit extracted from a complete system configuration. It corresponds to the hardware or software components or sets of components in the system configuration and is used to represent the local structure that may change during the migration process.

[0190] Specifically, after the evolutionary hypergraph is constructed, the candidate system configurations are not simply related by global state transitions, but rather by interconnected local migration steps of multiple hardware and software components. The differences between different configurations often exhibit high localization, asynchronicity, and non-uniformity. In engineering deployment, what truly affects feasibility is not the inherent superiority or inferiority of the configuration itself, but rather whether the gradual evolution path from the current configuration to the target configuration possesses characteristics such as low risk, rollback capability, and compatibility with the current operating load. Therefore, during path search, configurations cannot be treated as indivisible wholes; instead, components within the configuration must be used as the basic observation unit for migration, allowing the path space to reflect the risk propagation mode of local changes. For example, in some highly coupled systems, the migration of one component may trigger a chain of updates, while the migration of another type of component may have no side effects at all. If this difference is ignored, the path obtained at the hypergraph level cannot be used for engineering implementation.

[0191] In this embodiment, to ensure that path search accurately reflects the fine-grained differences between configurations, the hardware and software components responsible for function execution, behavior triggering, resource allocation, and critical link forwarding in the current configuration are first extracted based on the control flow graph and physical deployment graph in the structured description. These components are then designated as the current set of child nodes. The current child nodes characterize the variable migration regions of the current configuration. The control flow graph determines whether the component is a critical execution node, and the deployment graph determines whether migration will cause changes in node load or communication link interruptions; this allows migration risks to be captured at the component level. Simultaneously, based on the component behavior stability, interface compatibility, and substitution of similar components in other configurations recorded in historical implementation data, components with similar or replaceable functions in candidate system configurations are selected, forming a set of candidate child nodes. Thus, the mapping relationship between the current child nodes and candidate child nodes constitutes the start and end conditions of the candidate path space. Subsequently, starting from the current child node and ending with any component in the candidate child node set, multiple path searches are conducted in the evolutionary hypergraph. During the path search process, actions such as component replacement, redeployment, link adjustment, and resource reallocation involved in the migration steps are accumulated according to their historical risk tags, migration duration, and resource fluctuations, thereby obtaining a path metric that reflects the true cost of the evolution process. This search is not a simple shortest path calculation, but rather incorporates the dependency order between migration actions, resource locking relationships, and control link stability into the path evaluation, ensuring that the obtained path is not only theoretically feasible but also highly stable in engineering execution.

[0192] S4.4: By comprehensively considering the overall migration cost, overall migration risk, and overall downtime of multiple target evolution paths, a unique evolution path is determined. The system configurations corresponding to the unique evolution path are combined as the target system configuration. Based on the software and hardware component migration operations corresponding to each migration step in the unique evolution path, a software and hardware implementation scheme corresponding to the target system configuration is generated.

[0193] Specifically, after generating multiple target evolution paths, it is necessary to select one from these candidate paths that can simultaneously meet the requirements of performance improvement, risk control, and migration feasibility. Based on this path, the configurations along the way are synthesized to generate the final target configuration. Since the migration cost distribution, operation sequence, and component combination methods are different in different paths, directly selecting a path based on a single indicator of optimal performance or lowest risk may result in excessively high overall system cost or an extremely uneven migration process.

[0194] In this embodiment, the path selection process utilizes a weighted evaluation model to uniformly map migration costs, risks, and downtime to a comparable scale, and adjusts the weights by incorporating priority information from the requirement constraints, making the path scores more closely reflect the actual requirements of the target business scenario. Subsequently, the path with the highest score is extracted from the scoring results as the unique evolution path, and the structural descriptions of each stage configuration are extracted along the migration steps on this path. The final target system configuration is generated by combining component deployments, interface relationships, and behavioral links.

[0195] In one example, the system configurations corresponding to the unique evolution path are combined to form the target system configuration, including:

[0196] The data flow graphs and control flow graphs in the structured descriptions of each system configuration on the unique evolution path are compared, and the input-output relationships, behavioral links and dependencies between functional units are merged to obtain the target functional layer description.

[0197] Based on the physical deployment diagram of each system configuration in the unique evolution path, the deployment locations of the hardware and software components in the multi-hop migration step are extracted, and the deployment is adjusted according to the new deployment requirements to obtain the target physical deployment diagram.

[0198] Generate the target system configuration based on the target functional layer description and the target physical deployment diagram.

[0199] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A method for semi-automatically generating a MagicGrid framework model based on historical data, characterized in that, The method includes: The business object is obtained by parsing the description information of the target business scenario, and the historical implementation data corresponding to the target business scenario is obtained based on the business object; The historical implementation data is subjected to implementation domain feature extraction to obtain the feature elements of each implementation scheme at the physical implementation level. Based on the aforementioned feature elements, a functional reverse abstraction is performed to obtain the corresponding functional domain model, and a structured description corresponding to the functional domain model is generated. The functional domain model is used to represent the set of functions, functional logic, and functional relationships that each implementation scheme satisfies in the target business scenario. Based on the structured description, reverse optimization is performed. Under preset design constraints, the target system configuration and corresponding software and hardware implementation scheme are determined. The target system configuration and corresponding software and hardware implementation scheme are then encapsulated according to the hierarchical organization method of the MagicGrid framework to generate a MagicGrid framework model to support the target business scenario.

2. The method of claim 1, wherein the MagicGrid framework model is semi-automatically generated based on historical data. Based on the structured description, reverse optimization is performed to determine the target system configuration and corresponding hardware and software implementation schemes under preset design constraints, including: Based on the requirements of the target business scenario, the functional requirements, performance requirements, reliability requirements, and security requirements of the target business scenario are parsed, and the requirements are mapped into design constraints and optimization objectives. Based on the structured description and the historical implementation data, an architecture evolution hypergraph is constructed, wherein the hypergraph nodes of the architecture evolution hypergraph are used to represent candidate system configurations adapted to some of the required information, and the hyperedges are used to represent migration steps generated by a combination of multiple software and hardware component migration operations, and each hyperedge is weighted by migration cost, migration risk and downtime. Based on the candidate system configuration, multiple target evolution paths are determined; By comprehensively considering the migration costs, risks, and downtime of multiple target evolution paths, a unique evolution path is determined. The system configurations corresponding to the unique evolution path are combined to form the target system configuration. Based on the software and hardware component migration operations corresponding to each migration step in the unique evolution path, a software and hardware implementation scheme corresponding to the target system configuration is generated.

3. The method of claim 2, wherein the MagicGrid framework model is semi-automatically generated based on historical data. Based on the candidate system configuration, multiple target evolution paths are determined, including: Select a current system configuration from the candidate system configurations, determine the current child node of the current system configuration based on the control flow graph and physical deployment graph in the structured description, and determine the set of candidate child nodes corresponding to the remaining system configurations in the candidate system configurations based on the design constraints, wherein the current child node and candidate child nodes represent the hardware and software components of the system configuration; In the architecture evolution hypergraph, starting from the current child node and ending at any candidate child node in the candidate child node set, multiple evolution paths connecting the starting point and the ending point are optimized based on the optimization objective to obtain the target evolution path.

4. The method of claim 2, wherein the MagicGrid framework model is semi-automatically generated based on historical data. Combining the system configurations corresponding to the unique evolution path into the target system configuration includes: The data flow graphs and control flow graphs in the structured descriptions of each system configuration on the unique evolution path are compared, and the input-output relationships, behavioral links and dependencies between functional units are merged to obtain the target functional layer description. Based on the physical deployment diagram of each system configuration in the unique evolution path, the deployment locations of the hardware and software components in the multi-hop migration step are extracted, and the deployment is adjusted according to the new deployment requirements to obtain the target physical deployment diagram. Generate the target system configuration based on the target functional layer description and the target physical deployment diagram.

5. The method of claim 1, wherein the MagicGrid framework model is semi-automatically generated based on historical data. The process of parsing the description information of the target business scenario to obtain the business object includes: Semantic parsing is performed on the description information of the target business scenario to identify semantic entities that match business activities, operational targets, interactive subjects, and resource objects, and a business semantic graph is constructed. The semantic relationship of the business semantic graph is expanded and the nodes are aggregated. Based on the action chain, dependency chain and constraint chain between entities, the corresponding business objects are generated.

6. The method of claim 5, wherein the MagicGrid framework model is semi-automatically generated based on historical data. Based on the business object, obtain historical implementation data corresponding to the target business scenario, including: Determine the associated query conditions for the business object, and retrieve the implementation instances that match the associated query conditions from the preset historical project database, wherein the retrieval is achieved through semantic similarity matching based on the domain knowledge graph; Based on the implementation example, historical implementation data, including structural data, behavioral data, interface data, performance data, and runtime log data, is extracted through data parsing.

7. The method of claim 6, wherein the MagicGrid framework model is semi-automatically generated based on historical data. The implementation example of retrieving data from a preset historical project database that matches the associated query conditions includes: Based on the aforementioned association query conditions, index information of candidate implementation instances is obtained from the historical project database. The index information includes function tags, module tags, interface categories, engineering domain tags, and version identifiers. The index information of the candidate implementation instance is semantically vectorized to obtain a semantic feature vector, wherein the semantic vectorization process includes mapping the function label, module label and interface category to a semantic feature vector according to a preset domain knowledge graph. The semantic similarity is calculated based on the semantic feature vector and the semantic vector of the associated query conditions, and the semantic similarity is weighted and corrected according to the time sequence of the version identifier. Candidate implementation instances with semantic similarity greater than a preset similarity threshold are selected as implementation instances that match the associated query conditions.

8. The method of claim 1, wherein the MagicGrid framework model is semi-automatically generated based on historical data. The historical implementation data includes structural data, behavioral data, interface data, and performance data. Implementation domain features are extracted from the historical implementation data to obtain the feature elements of each implementation scheme at the physical implementation level, including: Based on the structural data, the software and hardware components, dependencies between components, and deployment topology in the structural data are parsed to obtain structural features including component type, connection relationship, and deployment location. The component's operational behavior sequence is analyzed based on the behavioral data to identify behavior triggering patterns, state transition patterns, and resource call patterns, thereby obtaining behavioral characteristics that reflect the execution mode of the implementation scheme. Based on the communication protocol, parameter constraints, and interface bandwidth between the interface data parsing components, an interface call matrix is ​​generated to obtain interface characteristics that reflect the software and hardware interaction methods. Statistical analysis is performed on the performance data to extract performance characteristics including latency, throughput, resource utilization, and reliability indicators; By combining behavioral characteristics, interface characteristics, and performance characteristics, the hardware and software requirements of the implementation instances corresponding to the historical implementation data are obtained; Based on the aforementioned hardware and software requirements and implementation structure diagram, feature elements for functional reverse abstraction are generated.

9. The method of claim 8, wherein the MagicGrid framework model is semi-automatically generated based on historical data. Based on the aforementioned feature elements, a functional inverse abstraction is performed to obtain the corresponding functional domain model, including: Based on the implementation structure diagram in the feature elements, the topological relationships and dependency strengths of the software and hardware components are clustered to identify the subsystem candidates corresponding to the component set, and the structural clustering results reflecting the system decomposition boundary are obtained. Based on the software and hardware requirements in the feature elements, software and hardware components with common behavioral links are mapped to functional units, and corresponding coupled and interactive software and hardware components are associated with the same functional unit to obtain a set of functional candidates. Based on the structural clustering results and the functional candidate set, a functional domain model is constructed, which includes subsystems, components and the functional relationships between components. The functional domain model includes requirement description, structural description, behavioral description, parameter description and general quality description.

10. The method of claim 9, wherein the MagicGrid framework model is semi-automatically generated based on historical data. Generate a structured description corresponding to the functional domain model, including: Based on the input-output relationships, behavioral links, and dependencies of the functional units in the functional domain model, construct data flow graphs and control flow graphs between the functional units; Based on the mapping relationship between the functional units and the hardware and software components, the behavioral logic of the functional units is converted into a component-level interaction sequence, and the logical calling relationship between components is generated based on the interaction sequence. Based on the logical call relationships between components, the components are mapped to the physical nodes that can be supported, generating a physical deployment diagram that includes deployment topology, communication links, and resource binding relationships; Based on the requirement description, parameter description, and general quality description in the functional domain model, performance requirements, resource constraints, and quality attributes are mapped to requirement layer constraint items; Based on the hierarchical specifications of the MagicGrid framework, data flow diagrams, control flow diagrams, physical deployment diagrams, and requirement layer constraints are modeled in a unified manner to obtain a structured description.

Images