Avionic electronic computer with a hypervisor for managing virtual machines, and aircraft comprising such a computer
The hypervisor-managed virtual machines in avionics computers enable secure and efficient resource reallocation, prioritizing critical applications and reducing cybersecurity risks by segregating them within separate virtual environments.
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- THALES SA
- Filing Date
- 2025-12-15
- Publication Date
- 2026-06-25
AI Technical Summary
Existing avionics electronic computers lack the ability to efficiently and securely reallocate resources to ensure critical software applications are not affected by resource shortages, leading to suboptimal performance and potential cybersecurity risks.
The implementation of a hypervisor that manages multiple virtual machines across computing boards, allowing resource distribution and reallocation between orchestrators, ensuring critical applications are prioritized and segregated within separate virtual environments.
This approach ensures secure and efficient resource allocation, guaranteeing sufficient resources for critical applications while maintaining flexibility and reducing cybersecurity risks.
Smart Images

Figure EP2025087075_25062026_PF_FP_ABST
Abstract
Description
[0001] An avionics electronic computer with a virtual machine management hypervisor, and an aircraft comprising such a computer.
[0002] The present invention relates to an avionics electronic computer intended to be installed on board an aircraft, the computer comprising a group of electronic computing board(s), the group of electronic computing board(s) comprising:
[0003] - computing resources and storage resources;
[0004] - a set of microservices configured to run independently of each other, with at least some of the resources;
[0005] - a set of software application(s) configured to call one or more of the microservices;
[0006] - a set of orchestrator(s) configured to implement the set of microservices by allocating at least a portion of the resources.
[0007] We know of an avionics electronic computer for executing software application services.
[0008] Resource conflicts can arise within this computer. An orchestrator is configured to manage these conflicts during the execution of software microservices. The orchestrator's tools include Quality of Service (QoS) mechanisms, resource reallocation, microservice prioritization, and resource preemption. This computer allows for the flexible deployment and hosting of microservices.
[0009] However, this calculator does not allow for simplified and secure reconfiguration of finite resources. Indeed, if the orchestrator lacks the necessary resources to handle the load, all microservices will fall behind. The hosted application(s) will then perform less well, and the most critical software application(s) may be affected.
[0010] The aim of the invention is therefore to provide a calculator that allows more resources to be allocated to certain applications or groups of applications by reallocating available resources in a secure and more efficient way.
[0011] To this end, the invention relates to an electronic computer of the aforementioned type in which the orchestrator set includes several orchestrators, and the group of electronic computing card(s) comprises at least two virtual machines and a virtual machine management hypervisor, the hypervisor being common to the group of electronic computing card(s) and configured to distribute at least a part of the resources between the virtual machines, each virtual machine being configured to host one of the orchestrators and make its resources available to the latter.
[0012] The calculator according to the invention then makes it possible to offer an execution of each application independently within each orchestrator, with several orchestrators distributed across several distinct virtual machines.
[0013] The computer according to the invention also allows for a sufficient level of segregation between different domains, through the implementation of multiple virtual machines and the management hypervisor, typically with at least one virtual machine per domain, while retaining the original flexibility of deployment and hosting of microservices.
[0014] Advantageously, the software application(s) whose microservices are implemented by the priority orchestrators are guaranteed sufficient resources. Furthermore, the microservices are hosted concurrently. A single microservice called by multiple applications is updated only once. This concurrent hosting allows the computer to retain its original deployment and hosting flexibility.
[0015] According to other advantageous aspects of the invention, the electronic calculator comprises one or more of the following features, taken individually or in all technically possible combinations:
[0016] - the group of computing electronic cards comprises several computing electronic cards, and in which at least two of the virtual machines are contained in separate computing electronic cards;
[0017] - at least two of the virtual machines are contained in the same electronic computing card;
[0018] - each orchestrator in the orchestrator group(s) is of the Kubernetes® type;
[0019] - the hypervisor is configured to create and / or delete virtual machines;
[0020] - the hypervisor is configured to create and / or delete virtual machines during the execution of software application(s);
[0021] - orchestrators are ranked by priority, and the hypervisor is configured to reallocate resources from a lower priority orchestrator to a higher priority orchestrator;
[0022] - The hypervisor is configured to reallocate resources from a lower-priority orchestrator to a higher-priority orchestrator by creating at least one virtual machine; and
[0023] - at least one resource allocation scenario between the lower-priority orchestrator and the higher-priority orchestrator is predefined before the aircraft takes off. The invention also relates to an aircraft comprising a computer as defined above.
[0024] The invention will become clearer upon reading the following description, given solely by way of non-limiting example, and made with reference to the drawings in which:
[0025] - Figure 1 is a schematic view of an aircraft comprising an avionics electronic computer with resources for executing software microservices called by a set of software application(s), the aircraft comprising an electronic box forming the avionics computer, the box comprising a backplane card and several electronic cards connected to the backplane card;
[0026] - Figure 2 is a schematic representation of the software architecture of some electronic boards in the enclosure shown in Figure 1; and
[0027] - Figure 3 is a schematic representation of an example of the temporal evolution of the architecture of Figure 2.
[0028] In Figure 1, an aircraft 10 includes an avionics electronic computer 20, generally forming an on-board data center, in order to offer different types of services on board the aircraft 10.
[0029] Aircraft 10 is, for example, an airplane, specifically a commercial aircraft such as a long-haul jet. Aircraft 10 is capable of carrying passengers, including several dozen or even several hundred passengers. Alternatively, aircraft 10 could be a helicopter, or even a drone remotely piloted by a pilot.
[0030] Computer 20 is, for example, configured to provide cockpit services for an aircraft crew 10 and / or ground maintenance services and / or entertainment services for passengers on board aircraft 10.
[0031] The computer 20 forms, for example, a multimedia server configured to run one or more software applications. Each application is configured to perform various functions, including streaming content via entertainment terminals (not shown). This content includes, for example, multimedia content delivered to passengers of the aircraft 10, particularly during the flight (e.g., movies, TV programs, games, or music), and / or information about the flight progress (altitude, speed, current position, progress, etc.). One application, for example, is configured to broadcast practical information about the arrival airport via audio and / or video announcements. Each entertainment terminal is known in itself and is connected to the multimedia server via a local area network (not shown) onboard the respective aircraft 10.Each entertainment terminal is fixed or integrated into the passenger's seat itself, or is fixed or integrated into the seatback in front of the passenger's seat. The seats are typically arranged in rows within the aircraft.
[0032] The computer 20 includes at least one electronic communication card 22, a group of electronic calculation card(s) 25, at least one power supply card 28. The power supply card 25 and the electronic communication card 22 and calculation card 25 are interconnected with each other by means of a backplane card 30 via a respective backplane connector 34, as shown in Figure 1.
[0033] The electronic enclosure 32 further includes a protective housing 36 inside which are housed the backplane card 30 and the plurality of electronic communication cards 22 and computing cards 25 and power supply cards 28. The electronic enclosure 32 also includes external connectors 38 arranged around the periphery of the housing 36. The external connectors 38 are intended in particular to allow the connection of the computer 20 to the local network, as well as to a power supply network, not shown and carried on board the aircraft 10.
[0034] Advantageously, the computer 20 includes several cards 22, 25, 28 of the same type, namely several electronic communication cards 22, several electronic calculation cards 25 and several power supply cards 28.
[0035] Those skilled in the art will understand that having several cards 22, 25, 28 of the same type improves the reliability and availability of the computer 20, as cards of the same type are redundant. Furthermore, having a large number of cards 22, 25, 28, particularly electronic computing cards 25, reduces the "granularity" of each card 22, 25, 28 within the electronic enclosure 32, and decreases the cost and resource requirements 40 for achieving adequate redundancy of cards 22, 25, 28.
[0036] In the example in Figure 1, the computer 20 includes two electronic communication cards 22, six electronic calculation cards 25 and one power supply card 28. Alternatively, the computer 20 includes two electronic communication cards 22, six electronic calculation cards 25 and two power supply cards 28, in order to have redundancy for each type of card.
[0037] Each electronic communication card 22 is configured to communicate with one or more external devices, not shown, to the computer 20. Each electronic communication card 22 is also called an input / output card, and also denoted I / O (from the English Input / Output) in Figure 1. Each power supply card 28, also denoted P in Figure 1, is configured to convert electrical energy received, via one or more respective external connectors 38, from the aircraft's onboard power supply network 10 into another electrical energy delivered to the electronic communication cards 22 and the computing card 25.
[0038] Figure 2 shows six electronic computing boards 25, namely a first 25A, a second 25B, a third 25C, a fourth 25D, a fifth 25E, and a sixth 25F. The electronic computing board is designated by the general reference 25, or by the letter C in Figure 1, when referring to any electronic computing board in general, and not to one of the six aforementioned electronic computing boards 25A to 25F in particular.
[0039] The electronic computing board group 25 contains 40 resources and is configured to run one or more software applications. The software application(s) include microservices. The software application(s) are, for example, composed of these microservices. Each microservice is an autonomous unit specialized in a specific task. The microservices collaborate with each other via interfaces to form a modular functional architecture. For example, one microservice might be tasked with recording the time, another with transforming this recording into a passenger-readable format, and a third with routing the processed information to a specific entertainment terminal.
[0040] Resources 40, also called hardware resources, are computing resources or storage resources specifically designed to be made available to one or more of the software microservices.
[0041] Each electronic computing card 25 includes a hypervisor 45, also noted HV in Figures 2 and 3. The hypervisor 45 is advantageously common to the group of electronic computing card(s) 25. In other words, the hypervisor 45 is advantageously identical from one electronic computing card 25 to another.
[0042] Each computing card 25 also includes one or more virtual machines 50, also denoted VM in Figures 2 and 3. Each virtual machine 50 is software simulating a complete computing environment, capable of running an operating system and application(s), as if it were a real computing card. In other words, a virtual machine 50 forms a virtual computing card operating within a respective computing card 25.
[0043] Each virtual machine 50 is configured to host at least one orchestrator 55, 56, in place of its operating system. Each orchestrator 55, 56 is configured to implement software microservices, intended to be called by the software application(s). In the example in Figures 2 and 3, at least one computing card 25, and preferably several computing cards 25, includes several orchestrators 55, 56, namely a first orchestrator 55, also denoted K1, and a second orchestrator 56, also denoted K2.
[0044] In this example, two computing boards 25A and 25B each contain several virtual machines 50 and two orchestrators 55 and 56, preferably different. Also in this example, four computing boards 25C, 25D, 25E, and 25F each contain a single virtual machine 50 that hosts the same orchestrator 56.
[0045] The hypervisor 45 is then configured to distribute the resources 40 between the different virtual machines 50.
[0046] Preferably, the hypervisor 45 is configured to restart the computing electronics card 25 on which it performs the resource reallocation operations 40, without affecting the operation of the other computing electronics cards 25 continuing to run microservices within the virtual machines 50.
[0047] Alternatively, a respective communication card 22 includes the hypervisor 45 and communicates with the electronic computing cards 25.
[0048] Furthermore, hypervisor 45 is configured to retrieve resource consumption information from microservices via an interface provided by one of the orchestrators 55 and 56. Hypervisor 45 can thus determine when either orchestrator 55 or 56 requires more resources. Advantageously, the interface is an API (Application Programming Interface).
[0049] Each orchestrator 55, 56 is a system for deploying and managing containerized applications within a cluster of computing resources. The orchestrators 55, 56 are deployed across multiple virtual machines 50.
[0050] Each orchestrator 55, 56 creates a level of abstraction from the application perspective and manages the allocation of resources 40 on the virtual machines 50 on which it is deployed. Advantageously, each orchestrator 55, 56 is of the Kubernetes® type. Each orchestrator 55, 56 runs the microservices of one or more applications using the resources 40 of one or more virtual machines 50, and therefore of one or more computing cards 25. The microservices and applications hosted by one of the orchestrators 55, 56 do not have to manage the allocation of resources 40.
[0051] The tools available to each orchestrator 55, 56 are quality of service or QoS mechanisms, resource reallocation 40, micro-service prioritization and resource preemption 40. Each orchestrator 55, 56 is configured to access only the resources of the virtual machine group 50 that hosts it.
[0052] For example, the first orchestrator 55 is configured to implement the microservices of the application(s) under an AISD domain and the second orchestrator 56 is configured to implement the microservices of the application(s) under a PIESD domain.
[0053] The AISD (Airline Information Services Domain), i.e., the airline's information services domain, provides information, particularly operational information, to the passenger cabin and the cockpit. It includes services such as passenger management, ground communications, and maintenance systems. The AISD domain thus comprises systems that help manage and operate the aircraft without directly affecting flight control.
[0054] The PIESD (Passenger Information and Entertainment Services Domain) is dedicated to entertainment and network services for passengers on board the aircraft. The PIESD domain includes in-flight entertainment systems such as video, audio or games, these systems being generally called IFE (In-Flight Entertainment) systems, access to the Internet and intranet, as well as communication services such as voice over IP generally called Vol P (Voice over Internet Protocol), short messages generally called SMS (Short Message Service) and emails.
[0055] AISD software applications include, for example, maintenance and maintenance reporting and data generation applications, communication applications with the airline's infrastructure networks, or AOC (Airline Operational Communication), or applications dedicated to flight crew such as messaging or documentation applications.
[0056] Software applications in the PIESD domain include, for example, in-flight entertainment, or IFE (In Flight Entertainment), or food and beverage ordering services (catering).
[0057] Figure 3 illustrates an example of hardware and software architecture evolution for an architecture identical to that of the example in Figure 2, for a given use case, such as the takeoff of aircraft 10. In this example, the first orchestrator 55, also noted K1, has priority over the second orchestrator 56, also noted K2. At takeoff, the hardware and software architecture is that of a first state E1 equivalent to that shown in Figure 2. In this state, the first and second computing boards 25A and 25B include the hypervisor 45 and two virtual machines 50, each hosting either the first orchestrator 55 or the second orchestrator 56. In this state, the other computing boards, namely the third, fourth, fifth and sixth computing boards 25C, 25D, 25E and 25F, include the hypervisor 45 and a single virtual machine 50 hosting the second orchestrator 56.For the purposes of this example, the virtual machine 50 of the third computing electronic card 25C containing only the second orchestrator 56 is referred to as the pre-existing virtual machine 50P.
[0058] During the flight, the hypervisor 45 is configured to determine if the first orchestrator 55 does not have sufficient resources 40 to run all the microservices called by its software application(s). The hypervisor 45 is then configured to select the computing board 25 containing the pre-existing virtual machine 50P, namely the third computing board 25C in the example in Figure 3, which hosts the second orchestrator 56, and to delete the pre-existing virtual machine 50P. The hypervisor 45 is also configured to create, on the selected computing board 25, two new virtual machines 50N1 and 50N2, each hosting the first 55 or second 56 orchestrator respectively, using the resources 40 freed up by the deleted pre-existing virtual machine 50P. This configuration corresponds to a second state E2, shown in Figure 3.
[0059] Furthermore, if the resource shortage 40 recurs, the hypervisor 45 is configured to allocate more resources by repeating the aforementioned operation on the other computing boards, namely the fourth, fifth, and sixth computing boards 25D, 25E, and 25F. This allows for a successive transition to other states: a third state E3, then a fourth state E4, and finally a fifth state E5, as shown in Figure 3. The creation of the new virtual machine 50N2 hosting the second orchestrator 56 is optional. Indeed, the resources can be entirely reallocated to the new virtual machine 50N1 hosting the first orchestrator 55.
[0060] Furthermore, if the hypervisor 45 determines that the second orchestrator 56 does not have sufficient resources 40, it is configured to prohibit a rollback and the creation of pre-existing virtual machines 50P hosting the second orchestrator 56 from the resources 40 previously allocated to the first orchestrator 55. A reset of the avionics computer 20, according to arrow R in Figure 3, is possible only if the aircraft 10 has returned to the ground.
[0061] Alternatively, the hypervisor 45 is configured to restrict the amount of resources 40 allocated to the virtual machines 50, rather than deleting one or more of the virtual machines 50. As described above, the hypervisor 45 is configured to detect a lack of resources 40 associated with the first orchestrator 55 and select a corresponding compute card, such as the third compute card 25C. The hypervisor 45 is then configured not to delete the virtual machine 50P hosting the second orchestrator 56, referred to as the pre-existing virtual machine. However, the hypervisor 45 is configured to create a new virtual machine 50N1 hosting the first orchestrator 55 and to reduce the amount of resources allocated to the pre-existing virtual machine 50P.
[0062] According to this variant, the second state E2 is identical to that shown in Figure 3, except that the new virtual machine 50N2 hosting the second orchestrator 56 is identical to the pre-existing virtual machine 50P with restricted access to the resources 40 of the selected computing electronic card 25C.
[0063] Preferably, the resources 40 required to run the application(s) of the priority orchestrator 55 are overestimated, i.e. estimated with an additional margin of operation, and the configuration corresponding to the worst use case scenario is different from that in which all the resources 40 are allocated to a single orchestrator 55.
[0064] Advantageously, different resource allocation scenarios 40 are planned prior to the flight, and the different resource allocation configurations 40 between the virtual machines 50 hosting the orchestrators 55 and 56, such as the configurations corresponding to states E1 to E5, are predefined for each computing electronic card 25.
[0065] In the case of multiple orchestrators 55, 56 ranked by priority, the hypervisor 45 is configured to reallocate resources 40 from one of the virtual machines 50 hosting any of the lower-priority orchestrators 56 to a virtual machine 50 hosting a higher-priority orchestrator 55. For three orchestrators, the hypervisor 45 is configured to reallocate resources 40 from the virtual machines 50 hosting the second orchestrator 56 and / or the third orchestrator (not shown) to the virtual machines 50 of the first orchestrator 55. The hypervisor 45 is preferentially configured to reallocate resources 40 from the virtual machines 50 hosting the third orchestrator to the virtual machines 50 of the second orchestrator 56.
[0066] In a multimedia server formed by a computer 20 according to the invention, each software application operates on the basis of microservices. The tasks performed by each microservice range, for example, from recording the time or temperature in a database to streaming a video feed. However, in such a computer 20, some software applications have priority over others. For example, software applications enabling the pilot to communicate with passengers have priority over those enabling the streaming of multimedia entertainment content.
[0067] When a first microservice requested by a higher priority application is activated, the orchestrator 55 or 56 releases the resources 40 of a second, lower priority microservice that was being processed, to execute the computation requested by the first microservice.
[0068] With a state-of-the-art computer, releasing resources 40 sometimes requires a significant number of memory accesses to save the request state. These operations are sometimes computationally expensive and can delay the execution of the first microservice. Sometimes, there are more than three or four microservices seeking to access the same resources 40 simultaneously. Each microservice has its request data stored before any calculations are performed. Since the resources 40 available on the computer 20 are finite, it is not possible to allocate additional resources 40. Using an orchestrator 55, 56 allows prioritizing certain applications over others and ensuring the execution of the most important microservices. However, since the applications share the physical and software resources 40 of the computer 20, it is not possible to guarantee that this is done in a cybersecurity-secure manner.Indeed, the execution of a less critical application could modify the data stored for the execution of a more critical application. Calculator 20 cannot be considered robust from a cybersecurity perspective.
[0069] To avoid this scenario, applications with different priorities are run in separate environments. The virtual machines 50 behave like dissociated electronic computing boards 25 with resources 40 that are physically separated. When a criterion, such as the number of resources 40 used by applications in a higher-priority environment, exceeds a predefined threshold, the computer 20 according to the invention increases the number of resources 40 allocated to that environment by reducing those allocated to a lower-priority environment. The decision to redefine the resources allocated to each environment is made by the hypervisor 45, which is advantageously run in a separate environment for the mathematical proof reasons described above.
[0070] Thus, this flexible architecture allows resources 40 to be allocated for the worst-case computing usage scenario 20. That said, the use of computing and storage resources 40 by third-party services is not necessarily restricted. The microservices of the most critical applications are run by segregated virtual machines 50. This ensures that these applications run within a defined timeframe by prioritizing their microservices at the hardware level. Furthermore, less critical applications can utilize more resources 40 outside of the worst-case usage scenario.
Claims
DEMANDS 1. Avionics electronic computer (20) intended to be installed on board an aircraft (10), the computer (20) comprising a group of electronic computing board(s) (25), the group of electronic computing board(s) (25) comprising: - computing resources and storage resources (40); - a set of microservices configured to run independently of each other, with at least some of the resources (40); - a set of software application(s) configured to call one or more of the microservices; - a set of orchestrator(s) (55, 56) configured to implement the microservices package by allocating at least part of the resources (40); characterized in that the set of orchestrator(s) (55, 56) includes several orchestrators (55, 56), and in that the group of computing electronic card(s) (25) comprises at least two virtual machines (50) and a virtual machine management hypervisor (45), the hypervisor (45) being common to the group of computing electronic card(s) (25) and configured to distribute at least part of the resources (40) between the virtual machines (50), each virtual machine (50) being configured to host one of the orchestrators (55, 56) and make its resources (40) available to the latter (55, 56).
2. Computer (20) according to claim 1, wherein the group of computing electronic card(s) (25) comprises several computing electronic cards (25), and wherein at least two of the virtual machines (50) are contained in separate computing electronic cards (25).
3. Computer (20) according to claim 1 or 2, in which at least two of the virtual machines (50) are contained in the same electronic computing card (25).
4. Calculator (20) according to any one of the preceding claims, wherein each orchestrator (55, 56) of the orchestrator group(s) (55, 56) is of the Kubernetes® type.
5. A calculator (20) according to any one of the preceding claims, wherein the hypervisor (45) is configured to create and / or delete virtual machines 6. Calculator (20) according to claim 5, wherein the hypervisor (45) is configured to create and / or delete virtual machines (50) during the execution of software application(s).
7. Calculator (20) according to any one of the preceding claims, wherein the orchestrators (55, 56) are ranked in order of priority and wherein the hypervisor (45) is configured to reallocate the resources (40) of a lower priority orchestrator (56) to a higher priority orchestrator (55).
8. Calculator (20) according to claim 7, wherein the hypervisor (45) is configured to reallocate resources (40) from a lower priority orchestrator (56) to a higher priority orchestrator (55) by creating at least one virtual machine (50).
9. Computer (20) according to claim 7 or 8, wherein at least one resource allocation scenario between the lower priority orchestrator (56) and the higher priority orchestrator (55) is predefined before takeoff of the aircraft (10).
10. Aircraft (10) characterized in that it comprises a computer (20) according to any one of the preceding claims.