A Layered Communication System and Method for Flight Simulation Based on Cloud-Native Dual-Bus Scheduling

Abstract

This invention relates to the field of flight simulation communication technology, and discloses a flight simulation layered communication system and method based on cloud-native dual-bus scheduling. The layered and decoupled communication architecture includes a component application module, a bus intelligent scheduling module, a data distribution module, and a transmission adaptation module connected sequentially. The component application module is used to interface with various flight simulation components. The bus intelligent scheduling module includes physically isolated control bus units, data bus units, and an intelligent scheduling unit that is communicatively connected to both control bus units and data bus units. This unit is used to identify the type of transmitted data, route data across different buses, and dynamically schedule transmission resources based on the flight simulation scenario. The data distribution module includes a cloud resource adaptation engine and a subscription relationship management unit, used to interface with the cloud platform resource pool to achieve heterogeneous deployment resource matching and communication channel subscription management for various flight simulation components.

Description

Technical Field

[0001] This invention relates to the field of flight simulation communication technology, specifically to a flight simulation hierarchical communication system and method based on cloud-native dual-bus scheduling. Background Technology

[0002] Flight simulation is a core supporting technology for aviation equipment R&D and civil aviation training systems. With the rapid development of the aviation industry, flight simulation systems are rapidly evolving towards high concurrency of multiple flights, full component decoupling, and cloud-native heterogeneous deployment. Core application scenarios such as aviation equipment type approval testing and multi-aircraft collaborative flight training place stringent composite requirements on simulation communication architecture: it not only needs to meet the requirements of millisecond-level low latency and high reliability transmission with a simulation step size of 10ms, but also needs to have the ability to be compatible with containerized / virtualized / bare metal heterogeneous resources, rapidly expand simulation components, and seamlessly port across deployment environments.

[0003] Currently, the industry has conducted numerous studies on flight simulation communication architecture, resulting in a variety of technical solutions, including layered decoupled communication architecture, dedicated simulation bus interface, and general cloud-native network architecture, which to some extent meet the simulation communication needs in specific scenarios.

[0004] However, existing technical solutions fail to resolve the core technical challenge of the incompatibility between cloud-native deployment models and the specific communication characteristics of flight simulation scenarios. Existing solutions are either dedicated simulation communication architectures designed for traditional physical environments, lacking deep cloud-native adaptation, and often employing a single bus to transmit high-priority control commands and large volumes of computational data, lacking targeted intelligent scheduling mechanisms. In multi-flight concurrent scenarios, they are prone to command transmission congestion, inadequate real-time performance, and insufficient scalability, making them incompatible with hybrid cloud platform deployment environments. Alternatively, they are general-purpose cloud-native network architectures designed only for general information transmission scenarios, lacking real-time optimization strategies, dedicated component adaptation logic, and standardized data interaction specifications specific to flight simulation scenarios. These architectures cannot meet the timing synchronization requirements and multi-component collaboration needs of flight simulation, thus preventing the current architectures from simultaneously achieving the flexibility and scalability of cloud-native deployments with the real-time performance and reliability of flight simulation communication. This ultimately hinders the large-scale application of cloud-native technologies in the flight simulation field. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention proposes a cloud-native dual-bus scheduling-based flight simulation hierarchical communication system and method to solve the aforementioned technical problems.

[0006] Firstly, a flight simulation layered communication system based on cloud-native dual-bus scheduling is provided. The communication architecture is based on layered decoupling and includes: a component application module, a bus intelligent scheduling module, a data distribution module, and a transmission adaptation module connected in sequence.

[0007] The component application module is used to interface with various flight simulation components;

[0008] The intelligent bus scheduling module includes a control bus unit and a data bus unit that are physically isolated from each other, as well as an intelligent scheduling unit that is communicatively connected to both the control bus unit and the data bus unit. It is used to realize the identification of the type of transmitted data, the routing of the bus by bus, and the dynamic scheduling of transmission resources based on the flight simulation scenario.

[0009] The data distribution module includes a cloud resource adaptation engine and a subscription relationship management unit, which are used to connect to the cloud platform resource pool to realize heterogeneous deployment resource matching and communication channel subscription management for various flight simulation components;

[0010] The transmission adaptation module is used to adapt to the underlying transmission protocols of different communication scenarios in flight simulation, complete the data transmission between the sending end and the receiving end flight simulation components, and monitor the transmission status in real time.

[0011] Furthermore, the component application module includes a data format standardization conversion unit and an aviation general bus protocol adaptation unit;

[0012] The data format standardization conversion unit is communicatively connected to the aviation general bus protocol adaptation unit, and is used to realize bidirectional conversion between the native data of the flight simulation component and the system standardized transmission data.

[0013] Furthermore, the intelligent scheduling unit includes a load monitoring subunit, a priority sorting subunit, and a bandwidth allocation subunit that are interconnected.

[0014] The load monitoring subunit is communicatively connected to the control bus unit and the data bus unit, the priority sorting subunit is communicatively connected to the control bus unit and the data bus unit, and the bandwidth allocation subunit is communicatively connected to the control bus unit and the data bus unit.

[0015] Furthermore, the cloud resource adaptation engine includes a resource status monitoring subunit, a component requirement profiling subunit, and a resource matching subunit that are interconnected.

[0016] The resource status monitoring subunit is communicatively connected to the cloud platform resource pool, and the component requirement profiling subunit is communicatively connected to the component application module.

[0017] Furthermore, the transmission adaptation module includes a scenario-adaptive transmission switching unit, a shared memory management unit, a Socket communication encapsulation unit, and a transmission status monitoring unit that are interconnected.

[0018] The transmission status monitoring unit is communicatively connected to the bus intelligent scheduling module and the data distribution module, respectively, and is used to realize real-time monitoring and closed-loop feedback of transmission status.

[0019] Furthermore, the data distribution module adopts a three-node deployment architecture of primary node, backup node and hot standby node. Each node is deployed on an independent physical server, and a data synchronization unit and a health check unit are set up between the three nodes.

[0020] The health check unit is connected to the operation ports of the three nodes to monitor the transmission performance and operation status of the three nodes in real time.

[0021] The data synchronization unit is connected to the storage ports of the three nodes to achieve real-time data synchronization among the three nodes.

[0022] Secondly, a flight simulation hierarchical communication method based on cloud-native dual-bus scheduling is provided, based on the flight simulation hierarchical communication system based on cloud-native dual-bus scheduling described in any of the preceding items, including:

[0023] Obtain the access configuration information of the flight simulation component, and complete the standardized registration of the component after adaptation and verification;

[0024] Based on the verified access configuration information, the heterogeneous resources of the cloud platform resource pool are matched to complete the automated deployment of the flight simulation components.

[0025] Based on the deployment location of the flight simulation components, establish communication transmission channels between the components;

[0026] Identify the type of data to be transmitted initiated by the flight simulation component, and route different types of data to independent control buses and data buses respectively to complete the dynamic scheduling of transmission resources;

[0027] Through the communication transmission channel, the scheduled data is transmitted between the sending and receiving flight simulation components and pushed to the target flight simulation component, thus completing the communication interaction between the components.

[0028] Furthermore, the access configuration information of the flight simulation component is obtained, and after adaptation verification, the standardized registration of the component is completed, including:

[0029] Receive access configuration information for flight simulation components through a standardized dynamic link library;

[0030] By loading standardized data structures and aviation bus protocol conversion rules that match the flight simulation components, pre-adapted flight simulation component parameter data is obtained;

[0031] The pre-adapted flight simulation component parameter data is validated to obtain the validated flight simulation component configuration data.

[0032] Assign a unique identifier to each simulation component to complete the standardized registration of the component.

[0033] Furthermore, based on the verified access configuration information, heterogeneous resources in the cloud platform resource pool are matched to complete the automated deployment of flight simulation components, including:

[0034] Collect resource status data of each node in the cloud platform resource pool to obtain a real-time updated resource pool status dataset;

[0035] Multi-dimensional feature extraction is performed on the verified access configuration information to generate a standardized component requirement profile.

[0036] Based on the preset weighted matching rules, the comprehensive matching degree between each candidate resource node and the standardized component requirement profile is calculated, and the target deployment resource data of the component is obtained by sorting and filtering according to the matching degree.

[0037] By adapting to the type of target deployment resources through a standardized resource abstraction interface, the automated deployment of flight simulation components is completed.

[0038] Furthermore, the type of data to be transmitted initiated by the flight simulation component is identified, and different types of data are routed to independent control buses and data buses respectively, completing the dynamic scheduling of transmission resources, including:

[0039] A standardized header is added to the data to be transmitted, and the data type and priority are identified by the identifier bits in the header to obtain an identifiable transmission data packet;

[0040] Real-time load data of the control bus and data bus are collected, and the corresponding scheduling strategy parameters are obtained by combining the preset load level determination rules.

[0041] Based on the type identifier of the tagged transmission data packet, control data is routed to the control bus, and computation data is routed to the data bus. The transmission queue is sorted by combining the priority identifier to obtain the sorted transmission task set.

[0042] Based on the scheduling strategy parameters, dedicated reserved bandwidth is allocated to the control bus, and the remaining available bandwidth is allocated to each transmission task of the data bus according to the adaptive allocation rules, thereby completing the dynamic scheduling of transmission resources.

[0043] The invention employing the above technical solution has the following advantages:

[0044] This invention achieves separate channel transmission and differentiated scheduling of control data and computational data through mutually physically isolated control bus units, data bus units, and supporting intelligent scheduling units. It can effectively avoid bandwidth contention between high-priority control commands and large-volume computational data, alleviate command transmission congestion in multi-component concurrent scenarios, and adapt to the low-latency transmission and timing synchronization requirements of flight simulation scenarios.

[0045] By adopting a layered and decoupled architecture that connects the component application module, bus intelligent scheduling module, data distribution module, and transmission adaptation module in sequence, the decoupled design of each functional module is realized. Each module can be deployed, iterated, and expanded independently, which improves the flexibility and maintainability of the system architecture. Attached Figure Description

[0046] To more clearly illustrate the specific embodiments of the present invention, the accompanying drawings used in the specific embodiments will be briefly described below. In all the drawings, the elements or parts are not necessarily drawn to scale.

[0047] Figure 1 This is an architecture diagram of the flight simulation hierarchical communication system and method based on cloud-native dual-bus scheduling of the present invention;

[0048] Figure 2 This is a diagram of the optimized scheme 1 for a high-availability architecture specific to flight simulation in the cloud-native dual-bus scheduling-based flight simulation hierarchical communication system and method of the present invention.

[0049] Figure 3 This is a diagram of the optimized scheme two of the batch component collaborative scheduling architecture in the cloud-native dual-bus scheduling-based flight simulation hierarchical communication system and method of the present invention;

[0050] Figure 4 This is a flowchart of the flight simulation layered communication method based on cloud-native dual-bus scheduling according to the present invention. Detailed Implementation

[0051] The embodiments of the technical solution of the present invention will now be described in detail with reference to the accompanying drawings. These embodiments are merely illustrative of the technical solution of the present invention and are therefore intended to limit the scope of protection of the present invention.

[0052] This embodiment is implemented based on the following hardware and software environment, and all selections are adapted to the high real-time and high availability requirements of flight simulation scenarios:

[0053] 1. Cloud platform server cluster: It adopts a cluster server that supports Kubernetes orchestration. The CPU of a single node is Intel Xeon Gold 6330, the memory is ≥64GB, and it supports containerization (Docker / K8s), KVM virtualization and bare metal direct connection deployment. The nodes are interconnected through 10 Gigabit Ethernet, and the one-way transmission latency of the link is ≤0.5ms.

[0054] 2. Simulation terminal equipment: compatible with Windows 10, Linux CentOS 7, Kylin V10, Tongxin UOS, and Euler 22.03 operating systems, equipped with a 10 Gigabit Ethernet network card, supports remote access to the cloud platform, and meets the real-time computing requirements of flight simulation components;

[0055] 3. Network equipment: SDN switches supporting OpenFlow protocol are used, with single packet forwarding latency ≤100μs, support VXLAN tunnel encapsulation and traffic priority scheduling, which can ensure that control commands are forwarded first;

[0056] 4. High-availability storage device: A Redis cluster using master-slave replication + sentinel mode is used to store component deployment information, subscription relationship data and bus scheduling status, with data synchronization latency between nodes ≤10ms;

[0057] When the master node of a Redis cluster fails, the sentinel mode automatically switches to the slave node, ensuring that deployment information, subscription relationships, and scheduling status data are not lost and there is no risk of data service interruption.

[0058] 5. Basic Software Environment: The component application module (component application layer) dynamic link library supports C / C++ language calls, data serialization adopts the Protobufv3 protocol, internal module interaction adopts the gRPC protocol, underlying resource adaptation adopts RESTful API, and is compatible with Docker API, Libvirt API, and SSH protocol.

[0059] like Figures 1-4 As shown, the flight simulation layered communication system based on cloud-native dual-bus scheduling of the present invention, based on a layered and decoupled communication architecture, includes: a component application module, a bus intelligent scheduling module, a data distribution module, and a transmission adaptation module connected in sequence.

[0060] The component application module is used to interface with various flight simulation components;

[0061] The bus intelligent scheduling module includes a control bus unit and a data bus unit that are physically isolated from each other, as well as an intelligent scheduling unit that is communicatively connected to both the control bus unit and the data bus unit. It is used to realize the identification of the type of transmitted data, the routing of the bus by bus, and the dynamic scheduling of transmission resources based on flight simulation scenarios.

[0062] The data distribution module includes a cloud resource adaptation engine and a subscription relationship management unit, which are used to connect to the cloud platform resource pool to achieve heterogeneous deployment resource matching and communication channel subscription management for various flight simulation components;

[0063] The transmission adaptation module is used to adapt to the underlying transmission protocols of different communication scenarios in flight simulation, complete the data transmission between the sending end and the receiving end flight simulation components, and monitor the transmission status in real time.

[0064] In this embodiment, the component application module includes a data format standardization conversion unit and an aviation general bus protocol adaptation unit;

[0065] The data format standardization conversion unit communicates with the aviation general bus protocol adaptation unit to realize bidirectional conversion between the native data of the flight simulation component and the system's standardized transmission data.

[0066] Specifically, the interface function definitions, input and output parameter specifications provided by the standardized dynamic link library are completely consistent with the original standalone simulation model. The simulation component only needs to import the dynamic library and its supporting header files and Protobuf definition files. It can complete the integration without modifying the original business logic code, thus achieving seamless migration between the physical environment and the cloud platform.

[0067] Simulation component developers should download the dynamic library and its supporting files (.h) and Protobuf definition files, import the header files into the project, and link the dynamic library (static / dynamic linking is optional).

[0068] The simulation component calls the initialization interface (Init_Bus), passing in the component identifier (formatted as "component type_number", such as "Attitude_001"), communication requirements (real-time level, data type), and priority parameters (levels 1-5, with level 1 being the highest).

[0069] The dynamic library verifies the validity of parameters, calls the flight simulation data format standardization module, loads the corresponding Protobuf structure and aviation protocol conversion rules according to the component data type, and completes the data pre-standardization adaptation; it sends a registration request to the bus intelligent scheduling module (bus intelligent scheduling layer) to obtain a unique component ID (uint32_t type) and completes the access; the whole process does not require modification of the original business code and data processing logic of the component.

[0070] The aviation general bus protocol adapter unit has a built-in aviation industry general bus protocol conversion engine, which natively adapts to the civil aviation ARINC429 protocol, the military aviation GJB289A (1553B) bus protocol, and the GJB5189 fiber channel protocol. It clearly defines the one-to-one mapping relationship between protocol fields and standardized Protobuf structures, and can realize bidirectional seamless conversion between data of different bus protocols and system standardized data.

[0071] The conversion logic is completely encapsulated within the dynamic link library, and the interface definition exposed to the outside world is completely consistent with the original monolithic simulation model. The original simulation components only need to link the dynamic library and do not need to modify any business algorithm code to complete the seamless migration from the physical environment to the cloud platform.

[0072] The data format standardization conversion unit adopts the Protobufv3 protocol as a unified data serialization standard, defines a standardized message structure for core data types across all flight simulation scenarios, and fully covers the transmission requirements of core components such as avionics, flight control, and visual systems. The core definitions include:

[0073] syntax="proto3";

[0074] package fly_simulation;

[0075] / / Core flight attitude data (output from flight control components)

[0076] message FlightAttitudeData{

[0077] uint64timestamp_us=1; / / Microsecond-level timestamp, aligned with the 10ms simulation step size

[0078] floatpitch=2; / / Pitch angle, in degrees

[0079] floatroll=3; / / Roll angle, in degrees

[0080] floatyaw=4; / / Yaw angle, in degrees

[0081] floatpitch_rate=5; / / Pitch rate, unit: degrees / second

[0082] floatroll_rate=6; / / Roll rate, in degrees per second

[0083] floatyaw_rate=7; / / Yaw rate, in degrees / second

[0084] uint32 component_id=8; / / Send the component's unique ID, aligned with the registration system

[0085] uint8 priority=9; / / Data priority, fully matching bus scheduling levels 1-5.

[0086] }

[0087] / / Avionics System ARINC429 Standard Data Frame

[0088] message AvionicsARINC429Frame{

[0089] uint64 timestamp_us=1;

[0090] uint32 label=2; / / ARINC429 standard label number

[0091] uint32 sdi=3; / / Source and destination identifiers

[0092] uint32 data=4; / / 32-bit standard data field

[0093] uint32 ssm=5; / / Symbolic state matrix

[0094] uint32parity=6; / / Parity bit

[0095] uint32component_id=7;

[0096] }

[0097] / / Simulation control commands (fully aligned with the control bus interface)

[0098] message SimulationControlCmd{

[0099] uint64 timestamp_us=1;

[0100] uint32 cmd_type=2; / / Instruction type enumeration: 1=Initialization, 2=Start, 3=Pause, 4=Stop, 5=Reset, 6=Single step

[0101] uint32 target_component_id=3; / / Target component ID

[0102] uint64 target_sim_step=4; / / Target simulation step size, ensuring timing alignment of multiple components

[0103] The core flight attitude data message includes microsecond-level timestamps, pitch angle, roll angle, yaw angle, angular velocity, component ID, and priority fields, aligned with a 10ms simulation step size;

[0104] Avionics system ARINC429 standard data frame message: includes microsecond-level timestamp, ARINC429 standard tag number, source and destination identifier, 32-bit standard data field, symbol status matrix, parity bit, and component ID field;

[0105] Simulation control instruction message: includes microsecond-level timestamp, instruction type enumeration, target component ID, target simulation step size field, and is fully aligned with the control bus interface.

[0106] In this embodiment, the intelligent scheduling unit includes a load monitoring subunit, a priority sorting subunit, and a bandwidth allocation subunit that are interconnected.

[0107] The load monitoring subunit is connected to both the control bus unit and the data bus unit, the priority sorting subunit is connected to both the control bus unit and the data bus unit, and the bandwidth allocation subunit is connected to both the control bus unit and the data bus unit.

[0108] Specifically, the control bus unit and the data bus unit are deployed independently with physical isolation. The control bus unit transmits high-frequency priority control commands such as initialization, start, pause, stop, reset, and single step, thus avoiding bandwidth contention between control commands and computational data at the physical level.

[0109] The control bus unit is equipped with a control interface, the core interfaces of which include:

[0110] The `Init_task`, `Start_task`, `Pause_task`, `Stop_task`, `Reset_task`, and `Step_task` interfaces have input parameters including component ID, instruction type enumeration value, and microsecond-level timestamp. Output parameters include execution result and instruction execution status. The timeout threshold is 1ms. The data bus unit has a supporting data interface, with core interfaces including:

[0111] The WriteDE, ReadDE, and GetAddressByName interfaces accept component ID, address, data buffer, and data length as input parameters, and output parameters include execution result and number of bytes transmitted. The timeout threshold is 5ms.

[0112] Table 1 Data Bus Core Interfaces

[0113]

[0114] Table 2 Control Bus Core Interfaces

[0115]

[0116] The load monitoring subunit adopts a monitoring mechanism with a fixed-length sliding window of 100ms (covering 10 complete simulation steps) and a step interval of 20ms. The sliding window is implemented using a lock-free circular buffer in C language to avoid timing jitter caused by multi-threaded scheduling, and the CPU utilization rate is <0.1%. It collects three core indicators in real time: bandwidth utilization of the dual bus, transmission queue backlog length, and data packet timeout rate, and adopts a three-level load judgment threshold system to match differentiated scheduling strategies.

[0117] A matching data type accurate identification mechanism is provided, which uses a fixed-length packet header identifier to achieve 100% accurate differentiation between calculated data and control commands, avoiding data and command transmission errors and scheduling failures due to overload.

[0118] The simulation component calls the corresponding interfaces (WriteDE for transmitting computational data, Start_task and other control interfaces for transmitting control commands) through the dynamic library. Internally, each interface adds a 4-byte fixed-length standardized header to all data / commands to be transmitted, enabling accurate identification and verification of data types. The complete header definition is as follows:

[0119] Table 3

[0120]

[0121] The packet header is followed by a microsecond-level timestamp, the data packet body, and a CRC32 checksum, forming a complete transmission frame. After the interface completes the packet header encapsulation, it submits the data packet to the bus intelligent scheduling layer.

[0122] The load monitoring submodule collects the dual-bus load in real time through a 100ms sliding window, adopts a three-level load judgment threshold system, and clarifies the triggering conditions for the scheduling strategy, as follows:

[0123] Normal load: Control bus queue length < 10 lines and bandwidth utilization < 50%, data bus bandwidth utilization < 60% and queue length < 50 lines, bandwidth is allocated according to default weight;

[0124] Warning load: Control bus queue length is 10-20 lines and bandwidth utilization is 50%-70%, data bus bandwidth utilization is 60%-85% and queue length is 50-100 lines, suspend non-critical data transmission at levels 4-5 of the data bus;

[0125] Overload: If the control bus queue length is greater than 20 and the bandwidth utilization is greater than 70%, and the data bus bandwidth utilization is greater than 85% and the queue length is greater than 100, immediately interrupt all non-real-time data transmission on the data bus, prioritize the transmission of control commands with full bandwidth, and trigger elastic expansion of the cloud platform.

[0126] Three-level load assessment and scheduling strategy closed-loop binding rules:

[0127] The load level determination result directly triggers the corresponding scheduling strategy, and the execution of the scheduling strategy is fed back to the load monitoring subunit in real time, forming a closed loop.

[0128] In early warning / overload scenarios, the scheduling strategy takes precedence over regular queue sorting and takes effect immediately.

[0129] Once the load returns to normal levels, the default bandwidth allocation and data transmission permissions will be automatically restored.

[0130] The priority sorting subunit adopts a two-tiered inter-node migration rule: "static priority baseline inter-node migration + dynamic preemptive scheduling of inter-node migration." This rule is fully compatible with the inter-node migration priority levels 1-5 (inter-node migration level 1 being the highest) set during component registration.

[0131] All commands on the control bus are fixed at the highest priority of inter-node migration level 1, supporting preemptive transmission. When the control bus receives a new command, it can immediately terminate the fragmented transmission of non-critical data at inter-node migration levels 3-5 that is currently being transmitted on the data bus, and prioritize the transmission of control commands. It is forbidden to interrupt the transmission of high-priority calculated data at inter-node migration levels 1-2.

[0132] Data bus transmission tasks are sorted in a non-preemptive manner according to the static priority of the components, and tasks with the same priority are sorted in ascending order of load rate within the sliding window.

[0133] The sorting strategy defaults to refreshing the inter-node migration every 20ms, which perfectly matches the timing requirement of the 10ms inter-node migration simulation step size. In the event of an early warning of inter-node migration / inter-node migration overload scenario, the scheduling strategy can immediately refresh the queue sorting when triggered to ensure that high-priority transmission tasks are executed first.

[0134] The bandwidth allocation subunit adopts a "fixed reservation + dynamic adaptive" allocation mechanism. First, 30% of the physical link bandwidth is reserved for the control bus, and the remaining 70% of the bandwidth is adaptively allocated by the data bus according to priority and real-time load. The core calculation formula is as follows:

[0135]

[0136] In the formula: Allocate bandwidth to the highest priority component of the data bus; The weights of the i-th priority component are (16 for level 1, 8 for level 2, 4 for level 3, 2 for level 4, and 1 for level 5). This represents the sum of the weights of all currently online data transmission components. The remaining available bandwidth after deducting the reserved bandwidth for the control bus from the total physical link bandwidth; The bandwidth load rate of the i-th priority component of the data bus within the current sliding window (0 ≤ ≤1);

[0137] Meanwhile, engineering boundary constraints are set: when the real-time bandwidth usage of the control bus exceeds the reserved value, the idle bandwidth of the data bus can be temporarily occupied, with a maximum occupation of no more than 50% of the total bandwidth; the data bus must not occupy the reserved bandwidth of the control bus under any circumstances; a minimum bandwidth guarantee is set for each priority component of the data bus, and the bandwidth allocated to a single component is not less than 1% of the total bandwidth of the physical link, so as to avoid the transmission starvation phenomenon of low priority components.

[0138] In this embodiment, the cloud resource adaptation engine includes a resource status monitoring subunit, a component requirement profiling subunit, and a resource matching subunit that are interconnected.

[0139] The resource status monitoring subunit communicates with the cloud platform resource pool, and the component requirement profiling subunit communicates with the component application module.

[0140] Specifically, the resource status monitoring subunit collects real-time status data of CPU, memory, and network bandwidth of each node in the cloud platform resource pool at a period of 20ms through a standardized resource abstraction interface, and obtains a real-time updated resource pool status dataset. The resource abstraction interface adopts a gRPC+RESTful dual-protocol adaptation design. The interaction between internal modules adopts the gRPC protocol (Protobuf serialization), and the underlying resources are connected to the RESTful API. The underlying layer encapsulates Docker API, Libvirt API, and SSH protocol to realize unified calls for three types of resources: containers, KVM virtualization, and bare metal. The core interfaces include Get ResourceStatus, Create Component Deployment, Delete Component Deployment, and Update Component Resource.

[0141] Core interfaces and calling methods:

[0142] GetResourceStatus: A GET call with input parameters being resource type enumeration values ​​and output parameters being the real-time status of node CPU / memory / bandwidth, used to query the status of cloud platform resource pools;

[0143] CreateComponentDeployment: A POST call with input parameters being the component requirement profile structure and the component deployment package path, and output parameters being the deployment result and the component instance ID. It is used for automated deployment of container / VM / bare metal resources.

[0144] DeleteComponentDeployment: The DELETE call takes the component instance ID as input and the operation result as output, and is used for resource release and scaling.

[0145] UpdateComponentResource: The PUT call takes the component instance ID and resource adjustment parameters as input parameters and outputs the adjustment result as output parameter, and is used for dynamic resource adaptation.

[0146] Adaptability: The interface encapsulates Docker API, Libvirt API, and SSH protocol at the underlying level, enabling unified access to three types of resources: containers, KVM virtualization, and bare metal. The upper layer does not need to worry about the differences in underlying resources.

[0147] The component requirement profiling subunit adopts a four-dimensional standardized profiling system specific to flight simulation scenarios, which is fully compatible with the 1-5 priority system during component registration. It extracts multi-dimensional features from component access configuration information to generate a standardized component requirement profiling, with the four dimensions including:

[0148] Real-time dimensions: component real-time level, end-to-end transmission delay limit, transmission jitter tolerance, simulation step size matching requirements;

[0149] Computing resource dimensions: minimum CPU core count requirements, CPU architecture compatibility requirements, minimum memory capacity requirements, and NUMA node affinity requirements;

[0150] Network resource dimensions: minimum inbound / outbound bandwidth requirements, maximum cross-node transmission latency, and packet loss rate tolerance;

[0151] Deployment characteristics: resource type preference, high availability level requirements, and data persistence requirements.

[0152] The following is a standardized profile example for typical components of flight simulation:

[0153] Flight control attitude calculation component: Real-time performance level 1, CPU ≥ 8 cores, memory ≥ 16GB, bandwidth ≥ 100Mbps, end-to-end latency ≤ 1ms, bare metal deployment preferred;

[0154] Avionics system simulation components: Real-time performance level 2, CPU ≥ 6 cores, memory ≥ 12GB, bandwidth ≥ 50Mbps, end-to-end latency ≤ 2ms, KVM virtualization deployment preferred;

[0155] Visual rendering component: Real-time performance level 3, CPU ≥ 4 cores, memory ≥ 8GB, bandwidth ≥ 200Mbps, end-to-end latency ≤ 10ms, containerized deployment preferred;

[0156] Data playback / recording component: Real-time performance level 5, CPU ≥ 2 cores, memory ≥ 4GB, bandwidth ≥ 10Mbps, end-to-end latency ≤ 50ms, container deployment.

[0157] The resource matching subunit adopts a "real-time priority" weighted scoring matching algorithm specific to flight simulation. It optimizes weight allocation to address the shortcomings of general cloud architectures that are "cost-intensive and lack real-time performance". The core calculation formula is as follows:

[0158]

[0159] In the formula: The comprehensive matching score is the j-th candidate resource node. The higher the score, the better the matching degree. For real-time matching weighting, a fixed 70% is used. The resource specifications are assigned a weight, fixed at 20%. The deployment cost is adjusted to a weighted average, fixed at 10%. Score the real-time matching degree between components and nodes (0-100 points). Score for resource specification matching degree (0-100 points) Score for cost fit (0-100 points).

[0160] Simultaneously, matching rule constraints are set: for real-time level 1-2 components, matching is only filtered in bare metal / KVM resource nodes; for real-time level 3-5 components, matching is preferentially filtered in container resource nodes; when high-priority components have no available resources, resource reclamation and migration of low-priority components can be triggered to ensure the resource supply of core simulation components.

[0161] Resource recycling and migration execution logic:

[0162] Triggering conditions: When a high-priority component of level 1-2 has no matching bare metal / KVM resources available, it will be triggered immediately; when multiple level 1-2 components apply for resources at the same time, they will be arbitrated and sorted according to the component registration priority and the coreness of the simulation task.

[0163] Temporary resource guarantee: During the migration process, container resource nodes are temporarily allocated to start basic services for the 1-2 level components to be deployed. After the bare metal / KVM resources are released, the migration is smooth and the simulation task is not interrupted throughout the process.

[0164] Execution sequence: First, lock the target low-priority component, suspend its new task scheduling, and then migrate the low-priority component to the container resource node through incremental synchronization + dual write and dual read mode. After the migration is completed and the data consistency is verified, release the original bare metal / KVM resources.

[0165] Time constraints: The maximum migration time for a single component is ≤10s. The simulation task of high-priority components is not interrupted throughout the entire process, and the simulation data is kept continuous during the migration of low-priority components.

[0166] Deployment rule constraints: Level 1 and 2 components may be temporarily deployed to container resource nodes only when there is absolutely no available space on bare metal / KVM resources, which will trigger resource reclamation and migration. After the resources are released, they will be migrated back immediately. Level 1 core components are prohibited from being deployed on container resource nodes for a long period of time.

[0167] The fallback rule is: if resources are still insufficient, non-real-time components will be suspended in order of priority from low to high, with priority given to suspending level 5 data playback / recording components, followed by suspending level 4 non-core components, to fully guarantee the resource supply of level 1-2 core components.

[0168] The subscription relationship management unit is used to record the publish / subscribe relationship between components. Based on the component deployment location and data type, it allocates a dedicated communication transmission channel and supports channel reuse for data packets of the same priority and type, reducing channel establishment overhead.

[0169] Establishing a complete closed-loop process for communication transmission channels:

[0170] The data distribution module queries the deployment location information (node ​​IP, resource type, container ID) in the Redis cluster through the component ID, and at the same time verifies the validity of the data packet header, and removes invalid data packets with incorrect flag bits or failed length verification.

[0171] Based on the data type identifier in the packet header and the component deployment location, the communication scenario is determined: communication within the same node is marked as "local communication", and communication across nodes is marked as "cross-node communication".

[0172] Local communication establishes a shared memory transmission channel (dedicated memory block + semaphore synchronization); cross-node communication establishes a dedicated VXLAN tunnel communication channel based on the SDN switch; channel information is bound to data packet priority; control command channel enables the highest priority forwarding queue of the SDN switch; channel information is stored in the Redis cluster.

[0173] The subscription relationship management module records component subscription relationships and supports channel reuse of data packets with the same priority and type, reducing channel establishment overhead.

[0174] In this embodiment, the transmission adaptation module includes a scenario-adaptive transmission switching unit, a shared memory management unit, a Socket communication encapsulation unit, and a transmission status monitoring unit that are interconnected.

[0175] The transmission status monitoring unit is communicatively connected to the bus intelligent scheduling module and the data distribution module, respectively, to realize real-time monitoring and closed-loop feedback of transmission status.

[0176] Specifically, the scenario-adaptive transmission switching unit automatically matches the optimal transmission method and protocol based on the communication scenario and data priority, balancing low latency and high reliability. The switching judgment rules are as follows:

[0177] Table 4 Switching Judgment Rules

[0178]

[0179] The shared memory management unit allocates dedicated memory blocks for local communication scenarios, achieving read-write synchronization through semaphores to avoid TCP / IP protocol stack overhead and solve the problem of excessive local communication latency. The Socket communication encapsulation unit encapsulates the underlying calling logic of the TCP / UDP protocol, with built-in timeout retransmission mechanism, packet header validity verification, and fault fallback handling rules. The control command timeout threshold is ≤1ms, with a maximum of 3 retransmissions; the data calculation timeout threshold is ≤5ms, with a maximum of 2 retransmissions. If retransmission fails, fault information is reported to the bus intelligent scheduling layer and the sending component, triggering channel switching. When the receiving end detects invalid data packets with incorrect packet header flags, failed CRC32 verification, or failed length verification, it directly discards the packets and sends a retransmission request to the sending end, while recording the abnormal data in the scheduling log.

[0180] The transmission status monitoring unit monitors indicators such as transmission success rate, round-trip delay, and packet loss rate every 10ms, and provides real-time feedback to the bus intelligent scheduling module and data distribution module, providing a basis for decision-making for dynamic scheduling and resource adjustment. When the packet loss rate is detected to be greater than 0.1%, the FEC redundancy is automatically increased. When the transmission delay is detected to be excessive, the transmission mode is triggered to switch, forming a complete closed-loop feedback mechanism.

[0181] In this embodiment, the data distribution module adopts a three-node deployment architecture of primary node, backup node and hot standby node. Each node is deployed on an independent physical server, and a data synchronization unit and a health check unit are set up between the three nodes.

[0182] The health check unit communicates with the operation ports of the three nodes to monitor the transmission performance and operating status of the three nodes in real time.

[0183] The data synchronization unit communicates with the storage ports of the three nodes to achieve real-time data synchronization among the three nodes.

[0184] Specifically, the three nodes adopt an operating mode of "master node processing business, standby node in standby, and hot standby node synchronizing data in real time". The master and standby nodes are deployed on different physical servers with completely identical hardware configurations. The health detection unit initiates heartbeat detection at a frequency of 50ms / time, with a heartbeat packet interval of 20ms. The monitoring indicators include CPU utilization, memory load, transmission latency, and simulation step size adaptability. The data synchronization unit is based on Redis master-slave replication + simulation data incremental synchronization mechanism to achieve real-time synchronization of component deployment information, subscription relationship data, and scheduling status data among the three nodes, with a synchronization latency of ≤5ms.

[0185] When the health monitoring unit detects that the master node fails to respond to heartbeat packets twice consecutively or the transmission delay is greater than 1ms, it immediately determines that the master node has failed and triggers a failover. The hot standby node immediately takes over all services of the master node, and the standby node is automatically promoted or demoted to a hot standby node. At the same time, the cloud platform is triggered to start a new standby node. The switching process does not affect the continuity of the simulation step size and the collaborative state of the components. After the master node recovers, it reverses the data through incremental synchronization + simulation state alignment mechanism to confirm that the data is consistent and switches back to the master node.

[0186] Fault switching boundary constraints: The entire switching process strictly follows the priority rules for new node task takeover, prioritizing the stable operation of Level 1 core control instructions and simulation components, and not exceeding the timing requirement of 10ms simulation step size.

[0187] In other implementations, a flight simulation hierarchical communication method based on cloud-native dual-bus scheduling is provided. The flight simulation hierarchical communication system based on cloud-native dual-bus scheduling, based on any of the preceding embodiments, includes:

[0188] Step S01: Obtain the access configuration information of the flight simulation component, and complete the standardized registration of the component after adaptation verification;

[0189] Specifically, the access configuration information of the flight simulation component is received through a standardized dynamic link library;

[0190] By loading standardized data structures and aviation bus protocol conversion rules that match the flight simulation components, pre-adapted flight simulation component parameter data is obtained;

[0191] The pre-adapted flight simulation component parameter data is validated to obtain the validated flight simulation component configuration data.

[0192] Assign a unique identifier to each simulation component to complete the standardized registration of the component.

[0193] Step S02: Based on the verified access configuration information, match the heterogeneous resources of the cloud platform resource pool to complete the automated deployment of the flight simulation component;

[0194] Specifically, resource status data of each node in the cloud platform resource pool is collected to obtain a real-time updated resource pool status dataset.

[0195] Multi-dimensional feature extraction is performed on the verified access configuration information to generate a standardized component requirement profile.

[0196] Based on the preset weighted matching rules, the comprehensive matching degree between each candidate resource node and the standardized component requirement profile is calculated, and the components are sorted and filtered according to the matching degree to obtain the target deployment resource data of the components.

[0197] By adapting to the type of target deployment resources through a standardized resource abstraction interface, the automated deployment of flight simulation components is completed: container resources start containers and mount dynamic libraries through the Docker API, VM resources configure network and storage through the Libvirt API, and bare metal resources push component files and runtime environment through the SSH protocol; after deployment, component instance information, deployment location, and resource matching results are written to the Redis cluster.

[0198] Step S03: Based on the deployment location of the flight simulation components, establish a communication transmission channel between the components;

[0199] Step S04: Identify the type of data to be transmitted initiated by the flight simulation component, and route different types of data to independent control buses and data buses respectively to complete the dynamic scheduling of transmission resources.

[0200] Specifically, a 4-byte fixed-length standardized header is added to the data to be transmitted. The data type and priority are identified through the flag bits in the header, resulting in a tagged transmission data packet. The complete header definition includes: a 1-bit data type flag (0 = calculated data, routed to the data bus; 1 = control command, routed to the control bus), a 7-bit priority flag (corresponding to priority levels 1-5), and a 24-bit data length check bit. The header is followed by a microsecond-level timestamp, the data packet body, and a CRC32 checksum, forming a complete transmission frame.

[0201] Real-time load data from the control bus and data bus is collected, and the corresponding scheduling strategy parameters are obtained by combining the preset load level determination rules.

[0202] Based on the type identifier of the transmitted data packet with the identifier, control data is routed to the control bus, and computation data is routed to the data bus. Combined with the priority identifier, the transmission queue is sorted to obtain the sorted transmission task set.

[0203] Based on the scheduling strategy parameters, dedicated reserved bandwidth is allocated to the control bus, and the remaining available bandwidth is allocated to each transmission task of the data bus according to the adaptive allocation rules, thereby completing the dynamic scheduling of transmission resources.

[0204] Step S05: Through the communication transmission channel, the scheduled data is transmitted between the sending end and the receiving end flight simulation components, and pushed to the target flight simulation component to complete the communication interaction between the components.

[0205] Specifically, the transmission adaptation module (transmission layer) obtains channel information, data packet priority identifiers, and deployment location information, and through the scenario-adaptive transmission switching engine, automatically determines and switches the transmission mode.

[0206] In local communication scenarios, the shared memory management module is called to allocate dedicated memory blocks according to the above rules. After writing data / instructions, the receiver is notified through a semaphore. The transmission status monitoring module monitors the write success rate and access latency at a period of 10ms.

[0207] In cross-node communication scenarios, the Socket encapsulation module is called to select the corresponding protocol for transmission according to the above rules. The SDN switch maps the control commands to the highest priority forwarding queue according to the packet priority identifier. Transmission security is ensured through VXLAN tunnel. The transmission status monitoring module monitors the packet loss rate and round-trip delay in real time. When the packet loss rate is >0.1%, the FEC redundancy is automatically increased.

[0208] A retransmission mechanism is triggered when transmission timeout occurs. The timeout threshold for control commands is ≤1ms, and the maximum number of retransmissions is 3. The timeout threshold for calculation data is ≤5ms, and the maximum number of retransmissions is 2. If retransmission fails, fault information is reported to the bus intelligent scheduling layer and the transmitting component, triggering channel switching.

[0209] Complete closed-loop process of data processing at the receiving end:

[0210] The receiving end transmission adaptation module reads the data and performs triple verification of CRC32, length, and timestamp. After the verification is successful, it forwards the data to the bus intelligent scheduling module.

[0211] The bus intelligent scheduling module parses data / instructions, restores them to the original data format through the data format standardization module, and pushes them to the receiving component.

[0212] After the receiving component completes the data / instruction processing, it returns the processing result (0 = processing completed) to the sending end, completing the closed loop of the entire communication interaction process.

[0213] In this embodiment, the access configuration information of the flight simulation component is obtained, and the standardized registration of the component is completed after adaptation verification, including:

[0214] Receive access configuration information for flight simulation components through a standardized dynamic link library;

[0215] By loading standardized data structures and aviation bus protocol conversion rules that match the flight simulation components, pre-adapted flight simulation component parameter data is obtained;

[0216] The pre-adapted flight simulation component parameter data is validated to obtain the validated flight simulation component configuration data.

[0217] Assign a unique identifier to each simulation component to complete the standardized registration of the component.

[0218] Specifically, the simulation component developers download the standardized dynamic link library and its accompanying header files and Protobuf definition files, import the header files into the project and link the dynamic library, the simulation component calls the initialization interface Init_Bus, and passes in the component identifier, communication requirements, real-time level and priority parameters, and the dynamic link library receives the access configuration information of the flight simulation component;

[0219] Load the standardized Protobuf data structure and aviation bus protocol conversion rules that match the flight simulation components, perform pre-adaptation processing on the component access configuration information, and obtain the pre-adapted flight simulation component parameter data;

[0220] The pre-adapted flight simulation component parameter data is validated for legality. The validation includes the compliance of parameter format, the legality of priority range, and the compatibility of protocol adaptation, resulting in the flight simulation component configuration data that passes the validation.

[0221] Assign a unique uint32_t type identity to each valid flight simulation component, send a registration request to the bus intelligent scheduling module, and write the component registration information to the Redis high-availability storage cluster to complete the standardized registration of the component.

[0222] In this embodiment, based on the verified access configuration information, heterogeneous resources in the cloud platform resource pool are matched to complete the automated deployment of the flight simulation component, including:

[0223] Collect resource status data from each node in the cloud platform resource pool to obtain a real-time updated resource pool status dataset;

[0224] Multi-dimensional feature extraction is performed on the verified access configuration information to generate a standardized component requirement profile.

[0225] Based on the preset weighted matching rules, the comprehensive matching degree between each candidate resource node and the standardized component requirement profile is calculated, and the components are sorted and filtered according to the matching degree to obtain the target deployment resource data of the components.

[0226] By adapting to the type of target deployment resources through a standardized resource abstraction interface, the automated deployment of flight simulation components is completed.

[0227] Specifically, the resource status monitoring subunit of the cloud resource adaptation engine collects resource status data of each node in the cloud platform resource pool through the GetResourceStatus interface of the resource abstraction interface. The data refresh cycle is 20ms, and a real-time updated resource pool status dataset is obtained.

[0228] The component requirement profiling subunit extracts multi-dimensional features from the verified access configuration information, generating standardized component requirement profiles from four dimensions: real-time performance, computing resources, network resources, and deployment characteristics.

[0229] The resource matching subunit calculates the comprehensive matching degree between each candidate resource node and the standardized component requirement profile based on the preset "real-time priority" weighted matching rule, sorts and filters them according to the matching degree from high to low, and obtains the target deployment resource data of the component by combining the real-time level constraints.

[0230] The CreateComponentDeployment interface, a standardized resource abstraction interface, adapts to the type of target deployment resources. For container resources, it starts containers and mounts dynamic link libraries via Docker API; for VM resources, it configures network and storage via Libvirt API; and for bare metal resources, it pushes component files and runtime environment via SSH protocol to complete the automated deployment of flight simulation components. After deployment, the component instance information and deployment location are written to the Redis cluster.

[0231] This step is accompanied by dedicated resource elastic scaling logic for 8 concurrent flights, implemented based on Kubernetes' native HPA+VPA capabilities. The specific rules are as follows:

[0232] Component-level vertical scaling up / down trigger conditions: Vertical scaling up is triggered when the CPU utilization of a single simulation component is continuously ≥75% or the memory utilization is continuously ≥80% for a duration of ≥3 simulation steps (30ms); Vertical scaling down is triggered when the CPU utilization is continuously ≤30% or the memory utilization is continuously ≤40% for a duration of ≥30s.

[0233] Node-level horizontal scaling up / down trigger conditions: Horizontal scaling up is triggered when the average CPU utilization of compute nodes in the cluster is ≥80% or the average bus bandwidth utilization is ≥85% or ≥2 new simulation frames are added for a duration of ≥10s; horizontal scaling down is triggered when the average CPU utilization of the cluster is ≤40% or the bandwidth utilization is ≤40% for a duration of ≥60s.

[0234] Expansion and matching rules: For every 2 new complete simulation tasks, 1 new standard configuration computing node will be added by default. A single node can carry a maximum of 3 simulation tasks. After the new node starts up, it will take priority to undertake low-priority non-core components of level 3-5. Only after it has been running stably for 100ms without performance jitter can it undertake high-priority components.

[0235] Priority rules for vertical and horizontal expansion / scaling timing:

[0236] Single component overload scenario: Vertical scaling is triggered first. After vertical scaling is completed, if the component load still exceeds the limit by ≥3 simulation steps (30ms), horizontal scaling is triggered immediately.

[0237] In scenarios where the overall cluster load exceeds the limit: horizontal scaling is triggered directly without waiting for the vertical scaling results of individual components. Simultaneously, vertical scaling requests for non-core components are suspended to prioritize the stability of the overall cluster resources.

[0238] Timing constraints: The execution cycle of a single vertical expansion adjustment is ≤100ms, and the start-up and readiness cycle of a horizontal expansion node is ≤30s, to ensure timely resource supply in a scenario with 8 concurrent sorties;

[0239] Expansion ratio matching rules: When horizontal expansion is triggered, the number of nodes added at one time = ceil(current cluster load rate / 80%) - the current number of nodes. The maximum number of nodes added at one time shall not exceed 3 to avoid excessive allocation of resources.

[0240] After a new node starts up, it first goes through a node readiness verification mechanism: if there is no jitter in CPU / memory / network latency within 100ms and the clock synchronization error of the cluster master node is <100μs, and all basic services are ready, it is marked as a node that can take on tasks.

[0241] Once a new node is ready, it should prioritize taking on low-priority non-core components of level 3-5. Only after it has been running stably for 30 seconds without any abnormalities can it take on second-highest priority components of level 2.

[0242] Level 1 highest priority core components (flight control and avionics main modules) can only be migrated between nodes that have been running stably for more than 5 minutes. Direct deployment to newly started nodes is prohibited to prevent control commands from being squeezed out and transmission delays from exceeding the standard.

[0243] Before scaling down, the target node is locked and new tasks are prevented from being scheduled to that node. Component migration is performed through incremental synchronization + dual write and dual read mode: first, the basic data and simulation status of the component are fully synchronized, and then the incremental data in the simulation process is continuously synchronized incrementally. During the synchronization process, the source node and the target node are dual write and dual read to ensure data consistency.

[0244] The maximum time for full data migration of a single component is ≤10s, and the maximum total time for full component migration of a single node is ≤30s. If the time threshold is exceeded, the current scaling down will be terminated and a new target node will be selected.

[0245] The source node component will only be terminated and the node destroyed once the target node has fully taken over the component task, the data interaction is normal within 3 consecutive simulation steps (30ms), and there is no delay exceeding the limit. The simulation task will not be interrupted throughout the process.

[0246] The data distribution layer senses resource changes in real time and automatically updates subscription relationships and transmission channels. The bus intelligent scheduling layer dynamically adjusts bandwidth allocation to ensure that the 8 concurrent simulation tasks are uninterrupted and the simulation step size timing is stable.

[0247] Elastic expansion and contraction boundary constraints:

[0248] When horizontal scaling is triggered, the number of nodes added at one time = ceil(current cluster load rate / 80%) - the current number of nodes. The maximum number of nodes added at one time shall not exceed 3 to avoid excessive resource allocation.

[0249] In a scenario with 8 flights operating at full load concurrently, the minimum number of nodes in the cluster should not be less than 4 to ensure redundant resources and high availability.

[0250] In this embodiment, the type of data to be transmitted initiated by the flight simulation component is identified, and different types of data are routed to independent control buses and data buses respectively, thereby completing the dynamic scheduling of transmission resources, including:

[0251] A standardized header is added to the data to be transmitted, and the data type and priority are identified by the identifier bits in the header to obtain an identifiable transmission data packet;

[0252] Real-time load data from the control bus and data bus is collected, and the corresponding scheduling strategy parameters are obtained by combining the preset load level determination rules.

[0253] Based on the type identifier of the transmitted data packet with the identifier, control data is routed to the control bus, and computation data is routed to the data bus. Combined with the priority identifier, the transmission queue is sorted to obtain the sorted transmission task set.

[0254] Based on the scheduling strategy parameters, dedicated reserved bandwidth is allocated to the control bus, and the remaining available bandwidth is allocated to each transmission task of the data bus according to the adaptive allocation rules, thereby completing the dynamic scheduling of transmission resources.

[0255] Specifically, the data distribution module queries the deployment location information in the Redis cluster through the component ID, including node IP, resource type, and container ID, and verifies the validity of the packet header of the data packet to be transmitted, and removes invalid data packets;

[0256] The communication scenario is determined based on the component deployment location; communication within the same node is marked as local communication, and communication across nodes is marked as cross-node communication.

[0257] In local communication scenarios, a shared memory transmission channel is established, and a dedicated memory block + semaphore synchronization mechanism is configured. In cross-node communication scenarios, a dedicated VXLAN tunnel communication channel is established based on an SDN switch. Channel information is bound to data packet priority, and the control command channel enables the highest priority forwarding queue of the SDN switch.

[0258] The subscription relationship management unit records the subscription relationships between components, supports channel reuse of data packets with the same priority and type, and reduces channel establishment overhead.

[0259] In some embodiments, a 4-byte fixed-length standardized header is added to the data to be transmitted. The header structure includes a 1-bit data type identifier (0 = calculated data, 1 = control command), a 7-bit priority identifier, and a 24-bit data length check bit. The data type and priority are identified by the identifier in the header. The header is followed by a microsecond-level timestamp, the data packet body, and a CRC32 checksum to form a complete transmission frame, resulting in an identifiable transmission data packet.

[0260] The load monitoring subunit collects real-time load data from the control bus and data bus through a 100ms sliding window, and matches the corresponding scheduling strategy parameters with the preset three-level load level judgment rules.

[0261] Based on the type identifier of the transmitted data packet with the identifier, control data is routed to the control bus, and computation data is routed to the data bus. The priority identifier in the packet header is used to sort the transmission queue. The control bus instructions are fixed at level 1, the highest preemptive priority, and the data bus tasks are sorted according to static priority to obtain the sorted transmission task set.

[0262] Based on the scheduling strategy parameters, 30% of the dedicated reserved bandwidth is allocated to the control bus. The remaining available bandwidth is allocated to each transmission task of the data bus according to the preset adaptive allocation formula. At the same time, the boundary constraint rules are executed to complete the dynamic scheduling of transmission resources.

[0263] In some implementations, the transmission adaptation module obtains channel information, data packet priority identifiers, and deployment location information, and matches the optimal transmission method and protocol through a scenario-adaptive transmission switching engine.

[0264] In local communication scenarios, the shared memory management module is called to allocate a dedicated memory block, and after writing data, the receiver is notified via a semaphore; in cross-node communication scenarios, the Socket communication encapsulation module is called to transmit data according to the corresponding protocol, and the SDN switch performs priority forwarding based on the priority identifier.

[0265] The transmission status monitoring unit monitors the transmission status in real time, triggers a retransmission mechanism when a timeout occurs, and reports fault information to the bus intelligent scheduling module when a transmission abnormality occurs, triggering channel switching.

[0266] The receiving end transmission adaptation module (receiving end transmission layer) reads the data and completes CRC32, length, and timestamp verification. After the verification is successful, it is forwarded to the receiving end component application module, restored to the component's native data format, and pushed to the target flight simulation component. The component returns the processing result, completing the communication interaction between components.

[0267] Based on the main solution, a dedicated high-availability mechanism is designed to address the uninterrupted nature of flight simulation missions, distinguishing it from general redundancy solutions:

[0268] Preferred Option 1:

[0269] The data distribution layer adopts a three-node deployment of "primary-backup-hot standby" (primary node + backup node + hot standby node). The primary and backup nodes are deployed on different physical servers, and the hot standby node synchronizes the primary node data in real time, forming triple redundancy.

[0270] Deploy a dedicated health check module for flight simulation, and add "simulation step size adaptability" (transmission delay ≤ 5ms) and "component coordination status" to the monitoring indicators. Initiate heartbeat detection every 50ms (heartbeat packet interval 20ms).

[0271] Failover logic: When the master node fails (failure to receive heartbeat packets twice consecutively or transmission delay > 1ms), the hot standby node immediately takes over the task, the standby node is upgraded to a hot standby node, and the cloud platform is triggered to start a new standby node. The switching process does not affect the continuity of the simulation step size.

[0272] After the master node recovers, the data is synchronized in reverse through the "incremental synchronization + simulation state alignment" mechanism to ensure that the collaborative state of the components is consistent before switching back to the master node to avoid simulation data deviation.

[0273] The remaining hardware, software components, and workflows are consistent with the main solution.

[0274] During the fault switching process, the priority rules for new node task takeover defined in the main scheme are strictly followed, prioritizing the stable operation of Level 1 core control instructions and simulation components, and ensuring that the timing requirement of 10ms simulation step size is not exceeded throughout the switching process.

[0275] Optimization Plan Two:

[0276] Based on the main solution, and to address the needs of collaborative simulation involving multiple sorties and components, the batch scheduling mechanism has been optimized, differing from the general batch interface:

[0277] The data bus adds a "component group batch read / write interface (GroupBatchReadDE, GroupBatchWriteDE)" to support batch data transmission by component group (such as "a certain flight sensor component group"), and has a built-in data synchronization mechanism within the group;

[0278] The control bus adds a new "Cooperative Batch Scheduling Interface (CoopBatchStartTask, CooopBatchPauseTask)" to support sending synchronous control commands to multiple component groups and ensures coordinated response of multiple components through "command timestamp alignment".

[0279] The data distribution layer has added a "component group management module", which supports dividing component groups by flight and function type, batch maintaining subscription relationships and transmission channels, and adapting to component group collaboration in a scenario with 8 concurrent flights.

[0280] The remaining hardware, software components, and workflows are consistent with the main solution.

[0281] During the batch transmission of components, the dual-bus intelligent scheduling mechanism and packet header identification rules of the main scheme are reused to ensure the highest priority transmission and low-latency response of batch control commands, with a collaborative response time difference of ≤300μs.

[0282] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention, and they should all be covered within the scope of the claims and specification of the present invention.

Claims

1. A flight simulation hierarchical communication system based on cloud-native dual-bus scheduling, characterized in that, The communication architecture is based on layered decoupling and includes: a component application module, a bus intelligent scheduling module, a data distribution module, and a transmission adaptation module connected in sequence. The component application module is used to interface with various flight simulation components; The intelligent bus scheduling module includes a control bus unit and a data bus unit that are physically isolated from each other, as well as an intelligent scheduling unit that is communicatively connected to both the control bus unit and the data bus unit. It is used to realize the identification of the type of transmitted data, the routing of the bus by bus, and the dynamic scheduling of transmission resources based on the flight simulation scenario. The intelligent scheduling unit includes a load monitoring subunit, a priority sorting subunit, and a bandwidth allocation subunit that are interconnected. The load monitoring subunit is communicatively connected to the control bus unit and the data bus unit, the priority sorting subunit is communicatively connected to the control bus unit and the data bus unit, and the bandwidth allocation subunit is communicatively connected to the control bus unit and the data bus unit. The bandwidth allocation subunit adopts a fixed reservation + dynamic adaptive allocation mechanism. First, 30% of the physical link bandwidth is reserved for the control bus, and the remaining 70% of the bandwidth is adaptively allocated by the data bus according to priority and real-time load. The core calculation formula is as follows: In the formula: For the data bus Bandwidth allocation for priority components; For the first The weights of priority components are as follows: Level 1: 16, Level 2: 8, Level 3: 4, Level 4: 2, and Level 5:

1. This represents the sum of the weights of all currently online data transmission components. The remaining available bandwidth after deducting the reserved bandwidth for the control bus from the total physical link bandwidth; For the data bus The priority component's bandwidth load rate within the current sliding window, where 0 ≤ ≤1; The data distribution module includes a cloud resource adaptation engine and a subscription relationship management unit, which are used to connect to the cloud platform resource pool to realize heterogeneous deployment resource matching and communication channel subscription management for various flight simulation components; The cloud resource adaptation engine includes a resource status monitoring subunit, a component requirement profiling subunit, and a resource matching subunit that are interconnected. The resource status monitoring subunit is communicatively connected to the cloud platform resource pool, and the component requirement profiling subunit is communicatively connected to the component application module. The resource matching subunit adopts a real-time priority weighted scoring matching algorithm specific to flight simulation. The core calculation formula is as follows: In the formula: The comprehensive matching score is the j-th candidate resource node. The higher the score, the better the matching degree. For real-time matching weighting, a fixed 70% is used. The resource specifications are assigned a weight, fixed at 20%. The deployment cost is adjusted to a weighted average, fixed at 10%. The score is assigned to the real-time matching degree between components and nodes, ranging from 0 to 100. Score the resource specification matching degree, from 0 to 100. Score for cost fit, 0-100 points; The transmission adaptation module is used to adapt to the underlying transmission protocols of different communication scenarios in flight simulation, complete the data transmission between the sending end and the receiving end flight simulation components, and monitor the transmission status in real time. The transmission adaptation module includes a scenario-adaptive transmission switching unit, a shared memory management unit, a Socket communication encapsulation unit, and a transmission status monitoring unit that are interconnected. The transmission status monitoring unit is communicatively connected to the bus intelligent scheduling module and the data distribution module, respectively, and is used to realize real-time monitoring and closed-loop feedback of transmission status.

2. The flight simulation hierarchical communication system based on cloud-native dual-bus scheduling according to claim 1, characterized in that, The component application module includes a data format standardization conversion unit and an aviation general bus protocol adaptation unit. The data format standardization conversion unit is communicatively connected to the aviation general bus protocol adaptation unit, and is used to realize bidirectional conversion between the native data of the flight simulation component and the system standardized transmission data.

3. The flight simulation hierarchical communication system based on cloud-native dual-bus scheduling according to claim 1, characterized in that, The data distribution module adopts a three-node deployment architecture of primary node, backup node and hot standby node. Each node is deployed on an independent physical server, and a data synchronization unit and a health check unit are set up between the three nodes. The health check unit is connected to the operation ports of the three nodes to monitor the transmission performance and operation status of the three nodes in real time. The data synchronization unit is connected to the storage ports of the three nodes to achieve real-time data synchronization among the three nodes.

4. A flight simulation hierarchical communication method based on cloud-native dual-bus scheduling, characterized in that, The flight simulation hierarchical communication system based on cloud-native dual-bus scheduling according to any one of claims 1 to 3 includes: Obtain the access configuration information of the flight simulation component, and complete the standardized registration of the component after adaptation and verification; Based on the verified access configuration information, the heterogeneous resources of the cloud platform resource pool are matched to complete the automated deployment of the flight simulation components. Based on the deployment location of the flight simulation components, establish communication transmission channels between the components; Identify the type of data to be transmitted initiated by the flight simulation component, and route different types of data to independent control buses and data buses respectively to complete the dynamic scheduling of transmission resources; Through the communication transmission channel, the scheduled data is transmitted between the sending and receiving flight simulation components and pushed to the target flight simulation component, thus completing the communication interaction between the components.

5. The flight simulation layered communication method based on cloud-native dual-bus scheduling according to claim 4, characterized in that, Obtain the access configuration information of the flight simulation component, and complete the standardized registration of the component after adaptation verification, including: Receive access configuration information for flight simulation components through a standardized dynamic link library; By loading standardized data structures and aviation bus protocol conversion rules that match the flight simulation components, pre-adapted flight simulation component parameter data is obtained; The pre-adapted flight simulation component parameter data is validated to obtain the validated flight simulation component configuration data. Assign a unique identifier to each simulation component to complete the standardized registration of the component.

6. The flight simulation hierarchical communication method based on cloud-native dual-bus scheduling according to claim 4, characterized in that, Based on the verified access configuration information, the system matches heterogeneous resources from the cloud platform resource pool to complete the automated deployment of flight simulation components, including: Collect resource status data of each node in the cloud platform resource pool to obtain a real-time updated resource pool status dataset; Multi-dimensional feature extraction is performed on the verified access configuration information to generate a standardized component requirement profile. Based on the preset weighted matching rules, the comprehensive matching degree between each candidate resource node and the standardized component requirement profile is calculated, and the target deployment resource data of the component is obtained by sorting and filtering according to the matching degree. By adapting to the type of target deployment resources through a standardized resource abstraction interface, the automated deployment of flight simulation components is completed.

7. The flight simulation layered communication method based on cloud-native dual-bus scheduling according to claim 4, characterized in that, Identify the type of data to be transmitted initiated by the flight simulation component, and route different types of data to independent control buses and data buses respectively, thereby completing the dynamic scheduling of transmission resources, including: A standardized header is added to the data to be transmitted, and the data type and priority are identified by the identifier bits in the header to obtain an identifiable transmission data packet; Real-time load data of the control bus and data bus are collected, and the corresponding scheduling strategy parameters are obtained by combining the preset load level determination rules. Based on the type identifier of the transmitted data packet with the identifier, control data is routed to the control bus, and computation data is routed to the data bus. The transmission queue is sorted by combining the priority identifier to obtain the sorted transmission task set. Dedicated reserved bandwidth is allocated to the control bus according to the scheduling policy parameters, and the remaining available bandwidth is allocated to each transmission task of the data bus according to the adaptive allocation rules to complete the dynamic scheduling of transmission resources.

Images