A heterogeneous middleware migration system and method for automatic driving software

Abstract

This invention discloses a heterogeneous middleware migration system and method for autonomous driving software. The method first scans ROS2 interface definition files and extracts interface metadata to form standardized input. Then, it uses a Skill-based rule base combined with adapter plugins to complete standard scene interface mapping. For boundary scenes, it uses LLM to generate adaptation code and feeds it back into the rule base. Subsequently, it verifies semantic equivalence before and after migration through multi-dimensional behavior recording and playback. Incremental migration and batch scheduling are performed based on the module dependency graph, automatically generating a bidirectional bridging layer to ensure transparent interoperability between modules. Finally, it generates the target middleware adaptation code to complete the migration. The system consists of an input layer, a rule layer, an AI-assisted layer, a semantic verification layer, a migration engine layer, and an output layer working together. It supports multiple types of target middleware, achieving zero-downtime progressive migration and effectively solving problems such as low efficiency and lack of verification in manual migration.

Description

Technical Field

[0001] This invention relates to middleware communication technology for autonomous driving, and more particularly to a heterogeneous middleware migration system and method for autonomous driving software. Background Technology

[0002] With the rapid development of autonomous driving technology, the selection of the underlying communication middleware for autonomous driving software systems is crucial to system performance, functional safety, and maintainability. ROS2 (Robot Operating System 2), with its rich toolchain and active open-source community, has become the mainstream framework for autonomous driving software prototyping and functional verification. Its underlying layer uses DDS (Data Distribution Service) as the communication middleware, providing flexible QoS policies, standardized interface definitions (IDL), and cross-platform compatibility.

[0003] However, during the product deployment phase, enterprises typically need to migrate their ROS2 software to specialized autonomous driving middleware with functional safety certifications, higher real-time performance guarantees, or better resource utilization. Currently, mainstream autonomous driving middleware on the market includes: AUTOSAR Adaptive Platform (service-oriented architecture, using the SOME / IP protocol), CyberRT (using shared memory + serialization), Apex.OS (a real-time ROS2-compatible solution compliant with functional safety standards), and dedicated middleware developed by various OEMs (such as AutoCore.OS). These middlewares differ significantly from ROS2 in core dimensions such as communication paradigms, interface definition languages, QoS policy systems, data type serialization formats, and node lifecycle management, posing significant challenges to software migration.

[0004] Current solutions rely on engineers manually analyzing ROS2 interface definitions file by file and writing adaptation code based on the target middleware documentation. A full migration of a medium-sized autonomous driving software project typically requires several months of manpower and is highly susceptible to semantic errors due to misunderstandings. Different middlewares exhibit numerous fine-grained differences in QoS policies, data type mappings, and asynchronous behaviors, making it difficult to fully cover them using simple regular expression replacements or script tools. Incomplete rule coverage and difficulties in handling boundary cases become migration bottlenecks, and existing tools lack effective boundary case handling mechanisms. Existing tools lack systematic verification of behavioral equivalence before and after migration. Potential semantic errors are only discovered during integration testing or runtime, resulting in extremely high repair costs. Autonomous driving software modules are highly coupled; a full, one-time migration means the entire system cannot function properly during the migration period. Current solutions lack engineering mechanisms to support incremental, gradual migration. Enterprises may target multiple middlewares simultaneously; existing tools cannot reuse migration rules, requiring the redevelopment of migration tools for each new target, severely wasting R&D resources. Summary of the Invention

[0005] To address the shortcomings of existing technologies, the present invention aims to provide a heterogeneous middleware migration system and method for autonomous driving software.

[0006] To achieve the objectives of this invention, the technical solution adopted is as follows: A method for migrating heterogeneous middleware for autonomous driving software includes the following steps: (1) Scan the interface definition files in the ROS2 source code, extract the interface metadata through the syntax parser, and form standardized input; (2) Encapsulate the migration rules into Skill units that can be loaded independently and managed in layers, and combine them with the adapter plugins corresponding to the target middleware to complete the interface mapping of standard scenarios; (3) When the Skill-based rule base cannot cover boundary migration scenarios, start the LLM to generate adaptation code. After automatic verification and manual review, the effective solution is fed back to the rule base. (4) Verify the consistency of behavior before and after migration from the dimensions of message semantics, service semantics, parameter behavior, and temporal behavior through multi-dimensional behavior recording-playback equivalence verification; (5) Incremental migration and batch scheduling are performed based on the module dependency graph, and a bidirectional bridging layer is automatically generated to achieve transparent communication between migrated and unmigrated modules; (6) Generate code assets that are compatible with the target middleware and complete the entire migration and delivery process.

[0007] Further, in step (1), the interface definition file includes .msg, .srv, .action, and .idl files; The interface metadata includes field names and data types, QoS policies, service request / response structures, Action triple structures, node parameters, and dynamic change event specifications.

[0008] Furthermore, in step (2), the Skill unit encapsulates the standard structure: Skill metadata; mapping logic; test case set; applicable constraints; Skill units are categorized by functional semantics into: Communication Layer Skill, Service Invocation Layer Skill, Parameter Reading Layer Skill, State Management Layer Skill, QoS Policy Layer Skill, and Data Type Layer Skill.

[0009] Furthermore, in step (2), the adapter plugin supports target middleware such as AUTOSAR Adaptive Platform, CyberRT, Apex.OS, and AutoCore.OS. To add a new target middleware, you only need to develop the corresponding plugin and register it in the rule base.

[0010] Further, in step (3), the execution steps include: context intelligent construction, the system automatically aggregates the complete interface metadata definition of the interface to be migrated, the relevant interface specification document fragments of the target middleware, the existing mapping cases with similar semantics in the rule base, historical failure cases and repair records; then generates standardized prompt words, including role settings, constraints, and output format specifications; LLM generates candidate migration code and performs multiple rounds of automatic verification and retries, and transfers it to manual review after exceeding the limit; for LLM generated code that passes manual review, the system automatically extracts its general mapping pattern, encapsulates it into a new Skill unit and registers it in the rule base.

[0011] Furthermore, in step (4), the execution steps include: recording message streams, service calls, parameter behaviors, and lifecycle event data on the ROS2 side, injecting the same input sequence on the target middleware side and comparing it dimension by dimension, and generating a structured difference report and repair suggestions when the verification fails.

[0012] Furthermore, in step (5), the execution steps include: constructing a directed graph of inter-node dependencies, planning migration batches according to the principles of prioritizing independent modules, prioritizing underlying interfaces, and prioritizing low-risk modules; automatically performing semantic verification after each batch of migration, and supporting automatic rollback in case of failure.

[0013] Furthermore, in step (5), the system automatically generates a bidirectional bridging layer between ROS2 and the target middleware to realize transparent message forwarding between migrated and unmigrated modules, supports zero-downtime incremental migration, and takes the bridging layer offline after the full migration is completed.

[0014] A heterogeneous middleware migration system for autonomous driving software includes an input layer, a rule layer, an AI-assisted layer, a semantic verification layer, a migration engine layer, and an output layer. The input layer scans the interface definition files in the ROS2 source code, extracts interface metadata through a syntax parser, and forms standardized input. The rules layer encapsulates migration rules into Skill units that can be loaded independently and managed hierarchically, and combines them with the corresponding adapter plugins of the target middleware to complete the interface mapping for standard scenarios; The AI-assisted layer, when the Skill-based rule base cannot cover boundary migration scenarios, starts LLM to generate adaptation code. After automatic verification and manual review, the effective solution is fed back to the rule base. The semantic verification layer verifies the consistency of behavior before and after migration from the dimensions of message semantics, service semantics, parameter behavior, and temporal behavior through multi-dimensional behavior recording-playback equivalence verification. The migration engine layer performs incremental migration and batch scheduling based on the module dependency graph, and automatically generates a bidirectional bridge layer to achieve transparent communication between migrated and non-migrated modules. The output layer generates code assets adapted to the target middleware, completing the entire migration and delivery process.

[0015] The beneficial effects of this invention are as follows: Compared with existing technologies, the Skill-based rule base of this invention covers common migration scenarios, and LLM assists in handling boundary situations. Engineers do not need to deeply understand the underlying implementation of each target middleware, reducing the manpower cost of migration. The multi-dimensional behavior recording-playback comparison mechanism systematically verifies the correctness of migration from four dimensions: message semantics, service semantics, parameter behavior, and temporal behavior. It advances the discovery of semantic errors from integration testing / runtime to the migration verification stage, reducing repair costs. The incremental migration engine supports step-by-step migration by module and interface layer, and sets up a bridging layer to ensure interface interoperability during hybrid operation, achieving zero-downtime migration and allowing enterprises to complete system migration without interrupting business operations. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of a heterogeneous middleware migration method for autonomous driving software as described in this invention. Figure 2 This is a comparison diagram of the interfaces between ROS2 and the target middleware. Detailed Implementation

[0017] The technical solution of the present invention will be further described below with reference to the accompanying drawings and embodiments. The following embodiments are only used to more clearly illustrate the technical solution of the present invention, and should not be used to limit the scope of protection of this application.

[0018] like Figure 1As shown, the present invention provides a heterogeneous middleware migration method for autonomous driving software, comprising the following steps: (1) Input layer: The system scans the original software environment and the interface definition files (.msg / .srv / .action / .idl) in the ROS2 source code. It extracts the interface metadata through the syntax parser to provide standardized input for subsequent processing. The interface definition files in the ROS2 source code include four types of standard files that define the communication specifications between nodes: .msg files, used to define the data structure for topic communication, including basic types, custom types, or nested types; .srv files, used to define the data structure for service requests and responses; .action files, used to define the triple structure of actions, namely goal, result, and feedback; and .idl files, or Interface Definition Language files, which are a more general middleware interface definition format.

[0019] The system extracts interface metadata from these files using a syntax parser, serving as standardized input for subsequent migration processing. Interface metadata includes: field names and data types (basic types / custom types / nested types), QoS policies (reliability policies, history depth, deadlines, Liveliness policies), service request / response structures, Action's Goal / Result / Feedback triple structure, node parameters, and dynamic change event specifications.

[0020] (2) Rule layer: The migration rules are encapsulated into standardized, independently loadable Skill units and managed hierarchically according to the functional hierarchy of the target middleware; After the input layer completes the standardized extraction of the original interface metadata, the system needs a set of mature migration rules to transform these interface metadata into a format that the target middleware can recognize. Each migration rule is encapsulated as an independent Skill unit, and the Skill unit is a rule unit, realizing cross-middleware functional semantic docking.

[0021] The standard structure of a Skill unit encapsulation includes: Skill metadata (applicable interface layer, list of supported target middleware, version number, confidence score); mapping logic (deterministic transformation functions for input interface specifications and output interface specifications); test case set (input / output pairs covering normal and boundary scenarios); and applicable constraints (preconditions and exception descriptions for triggering the Skill). Skill units are independent of each other, and users can combine and load specific levels of Skill units as needed to achieve precise migration.

[0022] Based on the interface metadata extracted in step 1, the system divides the interface into six skill layers according to functional semantics: communication layer skill, service call layer skill, parameter reading layer skill, state management layer skill, QoS policy layer skill, and data type layer skill. Each skill layer can be loaded independently, allowing users to precisely combine them according to actual migration needs without requiring full application deployment.

[0023] The communication layer skill maps topics (publish / subscribe interfaces) and converts between Pub / Sub communication paradigms, based on the Topics defined in the interface metadata (including field names, data types, and QoS policies). The service invocation layer skill maps service requests / responses and Action long-task interfaces, based on the Service / Action structure defined in the interface metadata (including request / response / feedback triples). The parameter reading layer skill maps ROS2 parameter servers and target middleware configuration services, including a dynamic parameter change notification mechanism, based on node parameter specifications defined in the interface metadata (including parameter names, default values, and dynamic change events). The state management layer skill maps ROS2 node lifecycle 4-state machines and target middleware lifecycle models, based on lifecycle event specifications defined in the interface metadata (including state transition sequences and transition times). The QoS policy layer skill maps QoS policy configurations (reliability policies, historical depth, deadlines, and Liveliness policies) in ROS2 to... The conversion of QoS policies to target middleware transmission policies; the data type layer Skill, based on the data type definitions (basic types / custom types / nested types) in the interface metadata, implements the serialization format adaptation of the ROS2 message type system to the target middleware data type.

[0024] Each target middleware corresponds to a set of adapter plugins. These adapter plugins implement a unified interface specification and support flexible expansion to include new target middleware. Currently supported adapters include AUTOSAR Adaptive Platform Adapter, CyberRT Adapter, Apex.OS Adapter, and AutoCore.OS Adapter. When adding a new target middleware, only the corresponding adapter plugin needs to be developed and registered in the rule base; no modification to the core migration engine is required, enabling open expansion.

[0025] (3) AI Assist Layer: When the Skill-based rule base cannot cover a certain migration requirement (such as boundary cases involving custom complex data types, special QoS combinations, target middleware private extension features, etc.), the system starts LLM to assist in boundary scenario processing; Although the rule layer covers most standard scenarios, the fixed rules may fail when faced with boundary situations such as custom complex data types or private extended features. In such cases, the system will automatically trigger the AI-assisted layer for intelligent compensation.

[0026] The specific steps include: Contextual intelligent construction: The system automatically aggregates the complete interface metadata definition (including nested structure and comments) of the interface to be migrated, relevant interface specification document fragments of the target middleware, existing semantically similar mapping cases in the rule base (retrieved by vector similarity), and historical failure cases and repair records (used to guide LLM to avoid known pitfalls and provide sufficient background for LLM).

[0027] Generate standardized prompts; the system generates standardized prompts including: role settings; constraints (interface signatures must match, data semantics must be equivalent, and no new external dependencies may be introduced); output format specifications (code blocks, mapping reasons, applicable constraint descriptions, and test cases) to ensure the parsability of the output code.

[0028] Candidate migration code is generated and subjected to multiple rounds of automatic verification and retries. Automatic static analysis is performed on the candidate migration code generated by the LLM, using interface metadata to verify its syntax correctness, interface signature consistency, and data type matching. If the check fails, error messages are fed back to the LLM for retries. If limits are exceeded, the code is transferred to manual review. The results of the manual review are recorded as training data for subsequent prompt word optimization.

[0029] Skills are dynamically fed back; for LLM-generated code that has passed manual review, the system automatically extracts its common mapping patterns, encapsulates them into new Skill units, and registers them in the rule base. The rule base is continuously optimized and expanded, the frequency of LLM intervention decreases, and the overall system migration automation rate increases over time.

[0030] (4) Semantic verification layer: Perform semantic equivalence verification independent of the target middleware. Automatically determine the semantic equivalence of system behavior before and after migration through behavior recording-playback comparison technology; The generated code needs to ensure logical consistency before and after the migration, therefore a semantic verification layer is required to perform strict behavioral equivalence checks on the generated solution.

[0031] The specific steps include: Multidimensional data recording (ROS2 side): Based on the interface definitions in the interface metadata extracted in step 1, the original system is run in the ROS2 environment, and behavioral data in four dimensions is automatically recorded: Message flow: Recording is performed for the Topic (including field structure) defined in the interface metadata; Service call: Recording is performed for the Service / Action (including request / response structure) defined in the interface metadata; Parameter behavior: Recording is performed for the parameter specifications (including parameter name, default value, and dynamic change events) defined in the interface metadata; Lifecycle events: Recording is performed for the lifecycle event specifications defined in the interface metadata.

[0032] Equivalence replay comparison (target middleware side): Based on the field definitions and structural specifications in the interface metadata extracted in step 1, the same input sequence is injected into the migrated target middleware system, and the output is collected. A systematic comparison is performed in four dimensions: Message semantics is compared field by field based on the field definitions (field name, data type, nested structure) in the interface metadata; Service semantics is verified based on the Service / Action structure definition in the interface metadata to verify the consistency of response content, the equivalence of timeout policies, and the correctness of error code mapping; Parameter behavior is verified based on the parameter specifications in the interface metadata to verify the consistency of read and write results and the equivalence of change notification triggering conditions; Timing behavior is verified based on the QoS policy configuration in the interface metadata to verify the end-to-end message delay distribution, publication frequency deviation, and QoS constraint satisfaction rate.

[0033] The system provides guidance on difference analysis and remediation. When verification fails, the system generates a structured difference report, which includes the difference type (value difference / time series difference / behavioral difference / missing message), impact assessment, and remediation suggestions, guiding engineers to quickly locate and fix migration issues.

[0034] (5) Migration Engine Layer: An incremental migration engine based on the module dependency graph supports progressive migration according to interface level and module boundary to ensure business continuity during migration; After ensuring the semantic correctness of individual interface and module migrations, the migration engine layer performs engineered batch scheduling. To ensure business continuity, the system adopts a gradual migration strategy.

[0035] The specific steps include: The system constructs a module dependency graph and performs risk assessment. It parses the Topic / Service dependencies between nodes in the ROS2 software, constructs a directed dependency graph (DAG), labels it layer by layer according to the functional interface hierarchy, and calculates the migration risk score for each module.

[0036] The migration batches are planned, and the migration tasks are divided into multiple batches based on the topology order and risk assessment results. The principles of prioritizing independent modules, prioritizing underlying interfaces, and prioritizing low-risk modules are followed to minimize the coupling risk between batches.

[0037] The system automatically generates a bidirectional bridging layer between ROS2 and the target middleware, enabling transparent message forwarding between migrated modules (running on the target middleware) and unmigrated modules (still running on ROS2). The bridging layer dynamically updates the routing configuration based on the migration progress of each batch, achieving zero-downtime incremental migration.

[0038] Verification is performed batch by batch. After each batch migration is completed, semantic equivalence verification is automatically triggered. If it passes, the current batch is deployed and the next batch continues; if it fails, it is automatically rolled back. After the full migration is completed, the bridging layer is taken offline, and the system runs fully on the target middleware.

[0039] (6) Output layer; output code assets that are fully adapted to the target environment to ensure that the migrated system can run completely and stably on the new heterogeneous middleware platform; the system supports the migration and adaptation of ROS2 to a variety of mainstream autonomous driving middlewares, and each Adapter plugin implements a complete mapping from the ROS2 interface to the corresponding target middleware interface; like Figure 2 As shown, the source middleware ROS 2 comprises five core interface elements: Action (long-running tasks), Topic (publish / subscribe), Service (synchronous request / response), Parameter (parameter service), and Lifecycle (lifecycle management). QoS policies are configuration attributes for Topics and Services, and are not independent interface elements.

[0040] Using ROS2 as the source middleware, an Adapter plugin is used to achieve mapping and compatibility with target middleware (AUTOSAR AP, CyberRT, Apex.OS, and AutoCore.OS) at six interface layers. AUTOSAR AP primarily processes Actions through composite mapping, mapping Topics to Events, Services to Methods, and Parameters to Fields. In CyberRT, Topics correspond to Channels, and Services correspond to Services, while also supporting global parameter service mapping. Apex.OS provides highly compatible Topic and Service mappings, emphasizing deterministic latency and real-time constraints. In AutoCore.OS, Topics are mapped to its high-performance shared memory communication, Services are mapped to asynchronous RPC, and hierarchical parameter management is supported.

[0041] like Figure 1As shown, the present invention provides a heterogeneous middleware migration system for autonomous driving software, comprising an input layer, a rule layer, an AI-assisted layer, a semantic verification layer, a migration engine layer, and an output layer; each layer works together to complete an automated, low-risk, and verifiable migration from ROS2 to heterogeneous autonomous driving middleware.

[0042] The input layer scans the ROS2 source code, extracting metadata from interface files such as .msg, .srv, .action, and .idl using a syntax parser to form standardized input. The rules layer, centered on a Skill-based rule base, encapsulates migration logic into independently loadable, hierarchically managed Skill units. Through adapter plugins, it connects to target middleware to achieve accurate mapping of standard scenarios. The AI-assisted layer handles boundary scenarios not covered by the rule base, such as custom complex types, special QoS, and private extensions, using LLM (Local Management Model). The system intelligently generates adaptation code, which, after automatic verification and manual review, feeds back effective solutions into the rule base. The semantic verification layer employs multi-dimensional behavior recording and playback equivalence verification to verify the consistency of behavior before and after migration from four dimensions: message semantics, service semantics, parameter behavior, and temporal behavior, thus identifying and locating semantic errors in advance. The migration engine layer, based on the module dependency graph, implements incremental migration and batch scheduling, automatically generating a bidirectional bridging layer to ensure transparent interoperability between migrated and unmigrated modules, supporting zero-downtime incremental migration. The output layer ultimately generates adaptation code that can be directly deployed on the target middleware, completing the entire migration delivery process and ensuring stable system operation on the target platform.

[0043] The applicant of this invention has provided a detailed description of the embodiments of the invention in conjunction with the accompanying drawings. However, those skilled in the art should understand that the above embodiments are merely preferred embodiments of the invention. The detailed description is only intended to help readers better understand the spirit of the invention and is not intended to limit the scope of protection of the invention. On the contrary, any improvements or modifications made based on the inventive spirit of the invention should fall within the scope of protection of the invention.

Claims

1. A method for migrating heterogeneous middleware for autonomous driving software, characterized in that, Includes the following steps: (1) Scan the interface definition files in the ROS2 source code, extract the interface metadata through the syntax parser, and form standardized input; (2) Encapsulate the migration rules into Skill units that can be loaded independently and managed in layers, and combine them with the adapter plugins corresponding to the target middleware to complete the interface mapping of standard scenarios; (3) When the Skill-based rule base cannot cover boundary migration scenarios, start the LLM to generate adaptation code. After automatic verification and manual review, the effective solution is fed back to the rule base. (4) Verify the consistency of behavior before and after migration from the dimensions of message semantics, service semantics, parameter behavior, and temporal behavior through multi-dimensional behavior recording-playback equivalence verification; (5) Incremental migration and batch scheduling are performed based on the module dependency graph, and a bidirectional bridging layer is automatically generated to achieve transparent communication between migrated and unmigrated modules; (6) Generate code assets that are compatible with the target middleware and complete the entire migration and delivery process.

2. The heterogeneous middleware migration method for autonomous driving software according to claim 1, characterized in that, In step (1), the interface definition files include .msg, .srv, .action, and .idl files; The interface metadata includes field names and data types, QoS policies, service request / response structures, Action triple structures, node parameters, and dynamic change event specifications.

3. The heterogeneous middleware migration method for autonomous driving software according to claim 1, characterized in that, In step (2), the Skill unit encapsulates the standard structure: Skill metadata; mapping logic; Test case set; Applicable constraints; Skill units are categorized by functional semantics into: Communication Layer Skill, Service Invocation Layer Skill, Parameter Reading Layer Skill, State Management Layer Skill, QoS Policy Layer Skill, and Data Type Layer Skill.

4. The heterogeneous middleware migration method for autonomous driving software according to claim 1, characterized in that, In step (2), the adapter plugin supports target middleware such as AUTOSAR Adaptive Platform, CyberRT, Apex.OS, and AutoCore.OS. To add a new target middleware, you only need to develop the corresponding plugin and register it in the rule base.

5. The heterogeneous middleware migration method for autonomous driving software according to claim 1, characterized in that, In step (3), the execution steps include: intelligent context construction, the system automatically aggregates the complete interface metadata definition of the interface to be migrated, the relevant interface specification document fragments of the target middleware, the existing mapping cases with similar semantics in the rule base, historical failure cases and repair records; then generates standardized prompt words, including role settings, constraints, and output format specifications; LLM generates candidate migration code and performs multiple rounds of automatic verification and retries, and transfers it to manual review after exceeding the limit; for LLM generated code that passes manual review, the system automatically extracts its general mapping pattern, encapsulates it into a new Skill unit and registers it in the rule base.

6. The heterogeneous middleware migration method for autonomous driving software according to claim 1, characterized in that, In step (4), the execution steps include: recording message streams, service calls, parameter behaviors, and lifecycle event data on the ROS2 side, injecting the same input sequence on the target middleware side and comparing it dimension by dimension, and generating a structured difference report and repair suggestions when the verification fails.

7. The heterogeneous middleware migration method for autonomous driving software according to claim 1, characterized in that, In step (5), the execution steps include: constructing a directed graph of inter-node dependencies, planning migration batches according to the principles of prioritizing independent modules, prioritizing underlying interfaces, and prioritizing low-risk modules; automatically performing semantic verification after each batch of migration, and supporting automatic rollback in case of failure.

8. The heterogeneous middleware migration method for autonomous driving software according to claim 1, characterized in that, In step (5), the system automatically generates a bidirectional bridging layer between ROS2 and the target middleware, enabling transparent message forwarding between migrated and unmigrated modules, supporting zero-downtime incremental migration, and taking the bridging layer offline after the full migration is completed.

9. A heterogeneous middleware migration system for autonomous driving software, characterized in that, It includes an input layer, a rule layer, an AI-assisted layer, a semantic verification layer, a transfer engine layer, and an output layer; The input layer scans the interface definition files in the ROS2 source code, extracts interface metadata through a syntax parser, and forms standardized input. The rules layer encapsulates migration rules into Skill units that can be loaded independently and managed hierarchically, and combines them with the corresponding adapter plugins of the target middleware to complete the interface mapping for standard scenarios; The AI-assisted layer, when the Skill-based rule base cannot cover boundary migration scenarios, starts LLM to generate adaptation code. After automatic verification and manual review, the effective solution is fed back to the rule base. The semantic verification layer verifies the consistency of behavior before and after migration from the dimensions of message semantics, service semantics, parameter behavior, and temporal behavior through multi-dimensional behavior recording-playback equivalence verification. The migration engine layer performs incremental migration and batch scheduling based on the module dependency graph, and automatically generates a bidirectional bridge layer to achieve transparent communication between migrated and non-migrated modules. The output layer generates code assets adapted to the target middleware, completing the entire migration and delivery process.

Images