Aircraft auxiliary display system design method based on software service

Abstract

The application relates to the field of aircraft auxiliary display information systems, and discloses an aircraft auxiliary display system design method based on software service, which comprises the following steps: performing dynamic resource scheduling; obtaining the hardware resource occupation of each software service unit and the functional application software through a self-maintenance service of the system; and dynamically adjusting and distributing the central processing unit (CPU) resource, the memory resource and the storage resource of each software service unit and the functional application software according to the hardware resource occupation and the division level of the data, and adjusting and distributing the interface bandwidth resource of the hardware adaptation layer. The method can provide clear technical guidance for the research and development, testing and deployment of the aircraft, improve the research and development efficiency, and ensure the rationality and practicability of the system design.

Description

Technical Field

[0001] This invention relates to the field of aircraft auxiliary display information systems, and more particularly to a design method for an aircraft auxiliary display system based on software services. Background Technology

[0002] As modern aviation equipment develops towards intelligence, integration, and complexity, the high demands of missions and the complexity of operation place increasingly higher requirements on the safety, digitalization, efficiency, and cost of aircraft crews. The aircraft auxiliary display information system (AIS), as one of the core airborne digital devices, interconnects with various onboard systems and primarily undertakes functions such as electronic flight bag, video surveillance, health management, and intelligent assistants. It enables paperless cockpit operations and mission collaboration, serving as a crucial support for ensuring safe flight and convenient maintenance of aircraft.

[0003] With the rapid development of electronic and intelligent technologies, user demands for the functionalities of aircraft auxiliary display information systems are constantly evolving and upgrading, leading to frequent updates and optimizations of the system software business layer. However, airborne equipment is constrained by aircraft design standards, hardware installation space, and reliability requirements, resulting in a much slower iteration speed for the hardware platform compared to the software business layer. Traditional system architectures (such as modular, component-based, and plug-in architectures) struggle to resolve this contradiction. Modular architecture primarily addresses system order, component-based architecture focuses on functional reuse, and plug-in architecture addresses simple functional changes; none of these can achieve collaborative work and independent evolution of software services. When software business layer requirements iterate, the entire system often needs to be restructured, increasing development costs and potentially affecting system stability and reliability.

[0004] Service-oriented architecture (SOA) differs fundamentally from modular, component-based, and plug-in architectures. Its core advantage lies in solving the problems of collaboration and independent evolution of software services. It enables independent deployment, upgrades, and maintenance of each service unit without relying on overall system reconstruction. This effectively adapts to the current limitations of airborne hardware platform iteration and meets the continuous evolutionary needs of aircraft during service and in the future, including digital missions, decision support, manned / unmanned collaboration, and intelligent cockpits. Currently, existing aircraft auxiliary display information systems do not adopt a mature software service-oriented architecture design, failing to fully leverage the advantages of SOA and struggling to adapt to the ever-increasing functional iteration requirements. Therefore, developing a design methodology for aircraft auxiliary display information systems based on software service-oriented architecture has become an urgent need in the field of aircraft information systems technology. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention provides a design method for an aircraft auxiliary display information system based on a software service architecture, comprising the following steps:

[0006] Step S1, construct a layered software service architecture: the layered software service architecture is divided from top to bottom into a user interface interaction layer, a software service layer, a data interaction layer and a hardware adaptation layer;

[0007] Step S2, Construct the FACE software architecture based on the operating system: The FACE software architecture is divided into a framework layer, a service layer and an application layer; an operating system adaptation and task scheduling module is configured in the framework layer, and a software service registration center and an interface gateway are configured in the service layer;

[0008] Step S3: Configure independent software service units in the software service layer: Configure three software service units in the software service layer: display control service, health management service and system self-maintenance service. Each software service unit is deployed in a containerized manner.

[0009] Step S4, Configure functional application software invocation in the application layer: Deploy functional application software in the application layer, and the functional application software invokes the software service unit in the software service layer through the interface gateway in the service layer;

[0010] Step S5, perform hierarchical data interaction: perform data transmission between each of the software service units and between the software service layer and the hardware adaptation layer through the data interaction layer, and divide the transmitted data into first-level flight critical data, second-level monitoring data and third-level maintenance data;

[0011] Step S6, perform dynamic resource scheduling: obtain the hardware resource usage of each software service unit and the functional application software through the system self-maintenance service, and dynamically adjust the CPU resources, memory resources, and storage resources allocated to each software service unit and the functional application software, as well as the interface bandwidth resources allocated to the hardware adaptation layer, according to the hardware resource usage and the data classification level.

[0012] As a technical solution of the present invention, in steps S1 and S5:

[0013] The interface interaction layer receives multimodal operation commands and displays information;

[0014] The data interaction layer uses a RESTful interface for data transmission, and encrypts the data using an encryption algorithm and verifies the integrity of the data using a data verification mechanism during the data transmission process.

[0015] The hardware adaptation layer connects to airborne hardware devices, including Phytium processors and Jingjia Micro display drivers. The hardware adaptation layer provides PCIe interfaces, Ethernet interfaces, and HDMI interfaces.

[0016] As a technical solution of the present invention, in step S3, the operation steps of each software service unit include:

[0017] The display control service controls the display layout, content updates, and parameter adjustments of the interface interaction layer.

[0018] The health management service monitors the working status of the auxiliary display information system and the airborne hardware equipment, and generates an alarm prompt and pushes the fault information to the functional application software when a fault is detected.

[0019] The system self-maintenance service performs load balancing scheduling, automatic fault recovery, version updates, and operation log recording for each of the software service units.

[0020] As a technical solution of the present invention, in steps S2 and S4:

[0021] The operating system is the Galaxy Kylin Desktop Operating System;

[0022] The framework layer is also configured with memory management, security control, and operation log auditing modules;

[0023] The functional application software includes at least one of the following: electronic manual application, electronic aeronautical chart application, video surveillance application, health management application, and intelligent assistant application;

[0024] The method further includes: the newly added software service unit completes system access by initiating a registration request to the software service registration center.

[0025] As a technical solution of the present invention, step S6, the step of dynamically adjusting the storage resources, includes:

[0026] The storage resources are divided into a system storage area, a data cache area, and a log storage area.

[0027] The data cache area is preferentially allocated for storing the primary flight critical data.

[0028] As a technical solution of the present invention, step S6, the step of dynamically adjusting the central processing unit (CPU) resources and the memory resources, includes:

[0029] When the system self-maintenance service detects that any of the software service units or functional application software is overloaded, it prioritizes allocating CPU and memory resources to the display control service and the health management service, and reduces the proportion of resources allocated to non-core functional application software.

[0030] As a technical solution of the present invention, in step S6, the proportion of initial hardware resource allocation for the system self-maintenance service is configured as follows:

[0031] The initial allocation of central processing unit (CPU) resources is as follows: display control service accounts for 40%, health management service accounts for 25%, system self-maintenance service accounts for 15%, and functional application software accounts for 20%.

[0032] The initial allocation of memory resources is as follows: display control service accounts for 30%, health management service accounts for 20%, system self-maintenance service accounts for 15%, data cache area accounts for 20%, and functional application software accounts for 15%.

[0033] The initial allocation of interface bandwidth resources is as follows: 40% for PCIE interfaces that transmit avionics bus data, 35% for Ethernet interfaces that transmit maintenance data, and 25% for HDMI interfaces that transmit video image data.

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

[0035] This invention adopts a software service architecture design, strictly adhering to four major principles: single responsibility, high cohesion and low coupling, airborne scenario adaptability, and independent evolution. It clearly divides software services into three independent units: display and control services, health management services, and system self-maintenance services. Containerized deployment allows each service to be independently upgraded, iterated, and switched over for fault redundancy without requiring the reconstruction of the entire system. This effectively adapts to the current situation of limited iteration of airborne hardware platforms, while simultaneously addressing the issues of insufficient reliability and cumbersome maintenance in existing service-oriented architectures in airborne scenarios. It meets the continuous evolution requirements during the aircraft's service life, reduces system iteration and development costs, and is distinct from existing ordinary software service architecture designs.

[0036] The software service architecture of this invention supports service registration and discovery mechanisms. New functions can be implemented by adding new software service units without modifying the existing architecture. Each function application is independently encapsulated, and the upgrade and iteration of a single application does not affect other components, greatly reducing the difficulty and cost of system maintenance. It improves user experience and ease of operation, which is different from the existing design with single functions and simple interaction methods.

[0037] This invention builds a FACE software architecture based on the domestically developed Kylin desktop operating system, improving the system's localization level. It adheres to the FACE technical standard, deeply integrates domestic hardware adaptation logic, and achieves bidirectional adaptation between the system software and domestic operating systems and domestic airborne hardware. Data interaction employs an encrypted transmission protocol to prevent data leakage and tampering, ensuring airborne information security. It enhances the system's autonomy, controllability, and security. The hardware adaptation layer provides standardized interfaces to support compatible integration with different models of airborne hardware, improving the system's versatility.

[0038] This invention establishes a standardized design methodology by clearly defining software service divisions, data interaction methods, and functional APP design schemes. This methodology provides clear technical guidance for the research, development, testing, and deployment of aircraft, improves research and development efficiency, and ensures the rationality and practicality of system design. Attached Figure Description

[0039] Figure 1 This is a schematic diagram of the layered system architecture based on software service in this invention.

[0040] Figure 2 Schematic diagram of the airborne FACE software logic framework Detailed Implementation

[0041] The terms first, second, third, fourth, etc. (if present) in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms include or have, and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0042] Existing auxiliary display information systems utilize imported operating systems and employ traditional, highly coupled application software architectures, resulting in unavoidable technical defects in actual operation. This invention aims to address the shortcomings of existing application software development technologies by providing a design method for aircraft auxiliary display information systems based on a software service-oriented architecture. This method solves the problems of existing aircraft auxiliary display information systems, such as difficulties in iterating the software business layer, inability to adapt to hardware platform-limited scenarios, insufficient independent controllability, and difficulty in meeting the continuous evolution and high safety requirements during aircraft service. It enables independent evolution and collaborative work of software services, enhances the system's domestic adaptability and security performance, supports system design and development, improves the system's scalability, maintainability, and reliability, and fills the gap in the integration and adaptation of service-oriented and domestically developed technologies in airborne auxiliary display information systems.

[0043] The present invention adopts the following technical solution:

[0044] Process 1: Design the software service architecture of the auxiliary display information system

[0045] The software service architecture adopts a layered design pattern, which is divided into the interface interaction layer, software service layer, data interaction layer and hardware adaptation layer from top to bottom. Each layer is deployed independently, with clear responsibilities and collaborative work. The core goal is to achieve independent evolution and efficient collaboration of software services.

[0046] The user interface layer serves as the entry point for interaction between the user and the system, receiving multimodal user commands such as parameter settings, function switching, touch operations, and displaying various information output by the system (flight information, video feeds, fault prompts). It supports multi-window display, touch operation, and shortcut key operation, adapting to aircraft cockpit display terminals and immersive operation scenarios to ensure user convenience and intuitiveness. The software service layer is the core business layer of the system, comprising three independent software service units: display control service, health management service, and system self-maintenance service. Each software service unit corresponds to one or a type of core business function. It adopts containerized deployment, supporting independent deployment, upgrades, iterations, and fault redundancy switching. A failure of a single software service unit does not affect the normal operation of the entire system, adapting to the high safety requirements of airborne systems. The data interaction layer enables data transmission between software service units and between the software service layer and the hardware adaptation layer, using standardized RESTful APIs. The system employs an ul (conforming to a representational state transition design) interface and encrypted transmission protocol, combined with a data verification mechanism, to ensure the real-time performance, accuracy, security, and integrity of data transmission. It also defines a unified data format to enable data interoperability between different software service units. The hardware adaptation layer facilitates communication between the system and residing domestic airborne hardware devices, providing standardized interfaces such as PCIe, Ethernet, and HDMI. This supports compatible integration and seamless migration of different models of domestic airborne hardware, reducing the impact of hardware platform iterations on system software and enhancing system autonomy and controllability. Hardware resource allocation adopts a priority-oriented + dynamic scheduling approach, clearly defining resource allocation standards for core software service units and functional apps. The system's self-maintenance service monitors the hardware resource usage of each software service unit and functional app in real time, dynamically adjusting CPU, memory, storage, and interface bandwidth allocation to avoid resource waste or insufficient core service resources, adapting to scenarios with limited airborne hardware resources.

[0047] Process 2: Determine the FACE software architecture based on the domestic Kylin desktop operating system

[0048] Considering the requirements for safety, compatibility, independent controllability, and domestic production of airborne systems, this invention determines that the auxiliary display information system is based on the domestic Kylin desktop operating system Galaxy Kylin V10 version to build the FACE software architecture, so as to realize the bidirectional adaptation of system software with domestic operating systems and domestic airborne hardware, thereby improving the system's domestic production level, safety, reliability, and independent controllability.

[0049] The FACE software architecture is divided into a framework layer, a service layer, and an application layer from top to bottom: The framework layer provides basic system support services and domestic security audit functions, including operating system adaptation, memory management, task scheduling, security control, and operation log auditing, providing a stable and secure operating environment for upper-layer services and applications; The service layer integrates a software service registry, interface gateway, and service management module to realize the registration, discovery, invocation, scheduling, and exception control of software services, supporting seamless integration between the application layer and the software service layer; The application layer deploys various functional applications (APPs), such as electronic manuals, electronic navigation charts, video surveillance, health management, and intelligent assistants. Each APP calls the software service unit through the service layer's interface to realize corresponding business functions, while also supporting direct adaptation of APPs to domestic airborne hardware, further enhancing the system's autonomy and controllability.

[0050] Process 3: Determine the division of software services and the methods for data interaction and allocation.

[0051] Based on the display control process of the auxiliary display information system (data acquisition → data processing → information display → interactive control), and combined with the core business functions of the system, the software service-oriented architecture's division method, data interaction rules, and data allocation strategy are identified and determined to ensure its rationality and practicality. The division of software services strictly adheres to four core principles, aligning with the needs of airborne scenarios:

[0052] 1. Single Responsibility Principle: Each software service unit undertakes only one core business function, with clear boundaries of responsibility to avoid functional overlap and redundancy. For example, the display control service is only responsible for interface display-related business, while the health management service is responsible for monitoring and managing the status of various systems on the aircraft. This ensures that each software service function is focused, easy to operate and maintain, and meets the high reliability and easy maintenance requirements of airborne systems.

[0053] 2. High cohesion and low coupling principle: The functional modules within a single software service unit are closely related and work together to achieve efficient integration of core functions; the software service units only interact with each other through standardized interfaces, without involving internal function calls, reducing mutual dependence and ensuring that the failure or upgrade of a single software service does not affect the normal operation of other software service units and the entire system.

[0054] 3. Airborne Scenario Adaptation Principles: Considering the characteristics of airborne equipment with limited hardware resources, high security, high reliability, and long-term service, the division of software services prioritizes key functions, simplifies non-core function redundancy, and ensures that core software services (display control services, health management services) consume the least amount of resources and achieve optimal functionality, adapting to the current situation of limited iteration and scarce resources of airborne hardware platforms.

[0055] 4. Independent Evolution Principle: Each software service unit is independently packaged and containerized for deployment, possessing independent deployment, upgrade, and iteration capabilities. It does not rely on other software service units or the entire system reconstruction. Based on the functional iteration needs during the aircraft's service life, a specific software service can be individually optimized and upgraded, reducing system iteration costs and adapting to the long-term service and continuous functional evolution requirements of airborne systems. It also meets the requirements for porting to future aircraft, aligning with the continuous evolution needs of digital missions, decision support, manned / unmanned collaboration, and intelligent cockpits.

[0056] Based on the above four classification principles, software service-oriented architecture is specifically divided into three core software service-oriented units. These units have clear responsibilities and work collaboratively: Display control service, responsible for controlling the interface display layout, updating display content, and adjusting display parameters; receiving and processing various information; and synchronously feeding it back to the interface interaction layer for accurate display. Health management service, responsible for monitoring the operational status of the entire system and each software service-oriented unit, as well as the working status of onboard hardware devices; real-time troubleshooting of operational anomalies; timely triggering of alarms when a fault is detected; and synchronously pushing fault information to the health management APP to support fault diagnosis. System self-maintenance service, responsible for load balancing scheduling, automatic fault recovery, version updates, and operational log recording of the software service-oriented architecture; and managing the dynamic allocation of hardware resources to achieve autonomous system operation and maintenance, reduce manual intervention, improve system stability and reliability, and adapt to the needs of unattended airborne operation and long-term service.

[0057] Data interaction adopts standardized interfaces, and various software services communicate with each other through these interfaces. During the interaction process, a combination of encryption algorithms and data verification mechanisms is used to encrypt and verify the integrity of transmitted data, preventing data leakage, tampering, and loss. Automatic reconnection is also supported in case of abnormal data transmission. Data allocation is divided into three levels based on information display priority: Level 1 is critical flight data; Level 2 is monitoring data; and Level 3 is maintenance data. Data is displayed on demand according to user needs, and data transmission bandwidth is dynamically adjusted according to system load to improve system resource utilization and operational efficiency. Hardware resource allocation is deeply linked to data priority and software service priority. Storage resources are divided into system storage area, data cache area, and log storage area. The data cache area prioritizes storing critical flight data to ensure fast data retrieval. Interface bandwidth allocation dynamically adjusts the bandwidth ratio of each interface according to data priority.

[0058] Step 4: Determine the design scheme of the functional APP

[0059] Based on the preset functions of the auxiliary display information system (electronic manual, electronic aeronautical chart, video surveillance, health management, intelligent assistant, etc.), the design schemes of each functional APP are sorted out and determined. Each functional APP adopts an independent encapsulation design, and achieves functional collaboration by calling software service interfaces, supporting independent upgrades and iterations.

[0060] Furthermore, the software-as-a-service (SaaS) system architecture supports service registration and discovery mechanisms. New SaaS units can be registered through the service registry without modifying the existing system architecture, enabling flexible expansion of system functions. Each functional application (APP) supports modular updates and version-linked adaptation. Upgrading and iterating a single functional APP does not affect the normal operation of other APPs and SaaS units, reducing system maintenance costs. Moreover, the functional APP interface supports custom layouts to adapt to different aircraft cockpit display terminals, improving system versatility. Hardware resource allocation is managed in real time by the system's self-maintenance service. When a software service or functional APP experiences resource overload, the system's self-maintenance service automatically adjusts resource allocation, prioritizing resource supply for core services (display control service, health management service). When overall system resources are strained, the system automatically reduces resource usage of non-core functions to ensure the stable operation of core system functions.

[0061] II. Working Principle

[0062] In practical application, the workflow of the design method of this invention is as follows: First, the FACE software architecture is built based on the Galaxy Kylin V10 operating system, completing the layered deployment of the software service architecture. The interface interaction layer, software service layer, data interaction layer, and hardware adaptation layer are deployed and initialized sequentially. Simultaneously, the system self-maintenance service completes the initial hardware resource allocation, allocating CPU, memory, storage, and interface bandwidth resources to each software service and functional APP according to preset standards. Second, data transmitted from various onboard hardware devices and other systems is collected through the PCIE bus, Ethernet, and other interfaces of the hardware adaptation layer. After coordination and processing, data of different priorities are transmitted to each software service according to the data allocation strategy and hardware resource allocation rules. The display control service displays the corresponding data on the control interface interaction layer according to the data priority and user operation instructions. The system displays relevant information (auxiliary displays, electronic manuals, electronic charts, video surveillance, intelligent assistants, etc.) while using a preset proportion of hardware resources to ensure smooth display. Users operate various functional applications (APPs) through the interface interaction layer, and the APPs call the corresponding software service units through the service layer interface. The health management service displays the operating status of each airborne system, supports status monitoring, configuration management, fault record query, and maintenance command issuance. The system self-maintenance service monitors the resource usage of each component in real time and dynamically adjusts resource allocation. When it is necessary to upgrade the system functions, the corresponding software service units or functional applications can be updated independently without reconstructing the entire system. At the same time, the system self-maintenance service synchronously adjusts the hardware resource allocation of the upgraded components, realizing the independent evolution and collaborative work of software services, supporting the design, development, and subsequent maintenance of the system.

[0063] The technical solution of the present invention will be further described in detail below with reference to specific embodiments. These embodiments are only used to explain the present invention and do not constitute a limitation on the scope of protection of the invention.

[0064] This embodiment takes an airborne auxiliary display system of a certain type of aircraft as the application scenario, and adopts a software service architecture to build a complete auxiliary display information system.

[0065] Process 1: Design the software service-oriented system architecture (see...) Figure 1The system adopts a layered design and is developed using the Qt framework. It supports standard or non-standard resolution displays, is compatible with aircraft cockpit LCD display terminals, and supports touch operation and shortcut key operation. The software service layer is divided into three independent software service units: display control service, health management service, and system self-maintenance service. It is developed using a software service-based framework and supports independent service deployment and upgrades. The data interaction layer uses a RESTful interface. The hardware adaptation layer provides standardized hardware interfaces such as PCIe bus, Ethernet, and HDMI, supporting cross-connection and adaptation with airborne cameras, aircraft avionics buses, and onboard health management systems. Hardware resource allocation adopts a dynamic scheduling mode, specifically as follows: CPU resources are allocated as follows: display control service 40%, health management service 25%, system self-maintenance service 15%, and functional application APP 20%; memory resources are allocated as follows: display control service 30%, health management service 20%, system self-maintenance service 15%, data cache 20%, and functional application APP 15%; interface bandwidth is allocated as follows: PCIe bus interface 40%, Ethernet interface 35%, and HDMI interface 25%, which is monitored and dynamically adjusted in real time by the system self-maintenance service.

[0066] Step 2: Determine the FACE software architecture, see Figure 2 Built on the domestically developed Kylin desktop operating system Galaxy Kylin V10, the framework layer uses domestically developed basic software components to provide memory management, task scheduling, and security control functions; the service layer integrates software service registration and interface gateway to realize the registration, discovery, and invocation management of software services; the application layer deploys auxiliary display, electronic manual, electronic aeronautical chart, video monitoring, maintenance display, intelligent assistant and other APPs, which are developed using Qt Quick and support multi-window display.

[0067] Process 3: Software Service Division and Data Interaction and Allocation: Following the four principles of single responsibility, high cohesion and low coupling, airborne scenario adaptability, and independent evolution, software services are divided into three core units: display control service, health management service, and system self-maintenance service. The display control service is responsible for controlling the interface layout and updating display content related to business applications; the health management service is responsible for troubleshooting aircraft maintenance displays and triggering alarms; and the system self-maintenance service is responsible for system self-checks, resource scheduling, fault recovery, and version updates. Data allocation is divided into three levels: Level 1 is information data such as auxiliary displays for flight assistance, electronic manuals, and electronic aeronautical charts, which are displayed with priority; Level 2 is video surveillance data, which is displayed normally; and Level 3 is aircraft health management (PHM) maintenance data, which is displayed as needed.

[0068] Process 4: Functional Application App Design: Based on the division of display control services, health management services, and system self-maintenance services, the business app design includes: Electronic Manual App and Electronic Chart App displaying manual content, alarm associations, emergency handling suggestions, flight plans, navigation information, airport terminal information, etc., supporting real-time updates and historical queries of flight data; Video Surveillance App receiving signals from 16 airborne cameras, supporting real-time display, video storage, and abnormal alarms; Health Management App displaying the operating status of various airborne systems, supporting status monitoring, configuration management, fault record queries, and maintenance command issuance; and Smart Assistant App providing time zone conversion, unit conversion, and intelligent reminders.

[0069] The working process of this embodiment is as follows: After system deployment, data from airborne hardware and onboard systems is collected through interfaces such as the PCIe bus and Ethernet in the hardware adaptation layer. Users can operate assisted displays, electronic manuals, electronic charts, video surveillance, intelligent maintenance, and health management apps via touch operation. The apps call the corresponding display control services and health management service units through service layer interfaces to achieve functional interaction. The system's self-maintenance service monitors the resource usage of various software services in real time and dynamically adjusts the allocation of resources such as CPU and memory. For example, when it is necessary to upgrade the health management function, only the health management service and the relevant software service interfaces need to be updated, without modifying the entire system, thus achieving independent evolution.

[0070] 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 of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A design method for an aircraft auxiliary display information system based on a software service architecture, characterized in that, Includes the following steps: Step S1, construct a layered software service architecture: the layered software service architecture is divided from top to bottom into a user interface interaction layer, a software service layer, a data interaction layer and a hardware adaptation layer; Step S2, Construct the FACE software architecture based on the operating system: The FACE software architecture is divided into a framework layer, a service layer and an application layer; an operating system adaptation and task scheduling module is configured in the framework layer, and a software service registration center and an interface gateway are configured in the service layer; Step S3: Configure independent software service units in the software service layer: Configure three software service units in the software service layer: display control service, health management service and system self-maintenance service. Each software service unit is deployed in a containerized manner. Step S4, Configure functional application software invocation in the application layer: Deploy functional application software in the application layer, and the functional application software invokes the software service unit in the software service layer through the interface gateway in the service layer; Step S5, perform hierarchical data interaction: perform data transmission between each of the software service units and between the software service layer and the hardware adaptation layer through the data interaction layer, and divide the transmitted data into first-level flight critical data, second-level monitoring data and third-level maintenance data; Step S6, perform dynamic resource scheduling: obtain the hardware resource usage of each software service unit and the functional application software through the system self-maintenance service, and dynamically adjust the CPU resources, memory resources, and storage resources allocated to each software service unit and the functional application software, as well as the interface bandwidth resources allocated to the hardware adaptation layer, according to the hardware resource usage and the data classification level.

2. The design method for an aircraft auxiliary display information system based on a software service architecture according to claim 1, characterized in that, In steps S1 and S5: The interface interaction layer receives multimodal operation commands and displays information; The data interaction layer uses a RESTful interface for data transmission, and encrypts the data using an encryption algorithm and verifies the integrity of the data using a data verification mechanism during the data transmission process. The hardware adaptation layer connects to airborne hardware devices, including Phytium processors and Jingjia Micro display drivers. The hardware adaptation layer provides PCIe interfaces, Ethernet interfaces, and HDMI interfaces.

3. The design method for an aircraft auxiliary display information system based on a software service architecture according to claim 1, characterized in that, In step S3, the operation steps of each software service unit include: The display control service controls the display layout, content updates, and parameter adjustments of the interface interaction layer. The health management service monitors the working status of the auxiliary display information system and the airborne hardware equipment, and generates an alarm prompt and pushes the fault information to the functional application software when a fault is detected. The system self-maintenance service performs load balancing scheduling, automatic fault recovery, version updates, and operation log recording for each of the software service units.

4. The design method for an aircraft auxiliary display information system based on a software service architecture according to claim 1, characterized in that, In steps S2 and S4: The operating system is the Galaxy Kylin Desktop Operating System; The framework layer is also configured with memory management, security control, and operation log auditing modules; The functional application software includes at least one of the following: electronic manual application, electronic aeronautical chart application, video surveillance application, health management application, and intelligent assistant application; The method further includes: the newly added software service unit completes system access by initiating a registration request to the software service registration center.

5. The design method for an aircraft auxiliary display information system based on a software service architecture according to claim 1, characterized in that, In step S6, the step of dynamically adjusting the storage resources includes: The storage resources are divided into a system storage area, a data cache area, and a log storage area. The data cache area is preferentially allocated for storing the Level 1 flight critical data.

6. The design method for an aircraft auxiliary display information system based on a software service architecture according to claim 1, characterized in that, In step S6, the step of dynamically adjusting the central processing unit (CPU) resources and the memory resources includes: When the system self-maintenance service detects that any of the software service units or functional application software is overloaded, it prioritizes allocating CPU and memory resources to the display control service and the health management service, and reduces the proportion of resources allocated to non-core functional application software.

7. The design method for an aircraft auxiliary display information system based on a software service architecture according to claim 1, characterized in that, In step S6, the initial hardware resource allocation ratio for the system self-maintenance service is configured as follows: The initial allocation of central processing unit (CPU) resources is as follows: display control service accounts for 40%, health management service accounts for 25%, system self-maintenance service accounts for 15%, and functional application software accounts for 20%. The initial allocation of memory resources is as follows: display control service accounts for 30%, health management service accounts for 20%, system self-maintenance service accounts for 15%, data cache area accounts for 20%, and functional application software accounts for 15%. The initial allocation of interface bandwidth resources is as follows: 40% for PCIE interfaces that transmit avionics bus data, 35% for Ethernet interfaces that transmit maintenance data, and 25% for HDMI interfaces that transmit video image data.

Images