Method and electronic device for managing the execution of software application(s) services on an avionics platform, computer program and associated avionics system

Abstract

Method and electronic device for managing the execution of software application(s) services on an avionics platform, computer program and associated avionics system. This method for managing the execution of software services on an avionics platform comprising resources for the execution of said services is implemented by an electronic device and comprises: - acquisition (110) of contextual data for a group of software services to be executed; the contextual data comprising, for each software service: a maximum quantity of resources used by said service; an operating constraint of said service equal to fault resistance or non-fault resistance; and if the operating constraint of said service is equal to fault resistance, a number of faults to which said service must be resistant;- calculation (120), based on acquired contextual data, of a context for the software service group; - launch (130) of the execution of the software service(s) of the group according to a set of service distribution rules and based on the calculated context. Figure for the abbreviation: Figure 4;

Description

Title of the invention: Method and electronic device for managing the execution of software application(s) services on an avionics platform, computer program and associated avionics system

[0001] The present invention relates to a method for managing the execution of software application services on an avionics platform intended to be carried on board an aircraft, the avionics platform having resources for the execution of said software services, the method being implemented by an electronic management device; as well as a computer program comprising software instructions which, when executed by a computer, implement such a management method.

[0002] The invention also relates to such an electronic device for managing the execution of software application / s services; as well as an avionics system comprising such an avionics platform and such an electronic management device.

[0003] Modern software applications are no longer monolithic and are generally composed of numerous software components, also called software services, working together to ensure the proper functioning of the software application. Each software service is typically encapsulated in a container, which forms an executable file. Software services include, for example, services compatible with the Kubernetes system, which is an open-source software system that automates the deployment, scaling, and management of containerized applications. These containers are called pods in the Kubernetes system.

[0004] The electronic management device, also called an electronic orchestration device or orchestrator, then makes it possible to manage the execution of software services on a computer platform, such as an avionics platform.

[0005] Current orchestrators are generally intended to operate in data centers (from the English "data centers") comprising multiple computer servers with significant resources, where it is possible to add software services on demand, simply by updating the resources required for all the software services.

[0006] However, such orchestrators are not suitable to function properly in an environment where hardware resources are limited, particularly when the platform is intended to be carried on board an aircraft.

[0007] The object of the invention is then to propose a method, and an associated electronic device, for managing the execution of software application(s) services on an avionics platform, allowing better management of the execution of software services with limited resources and thus improving the operation of the platform.

[0008] To this end, the invention relates to a method for managing the execution of software application(s) services on an avionics platform intended to be installed on board an aircraft, the avionics platform comprising resources for the execution of said software services, the method being implemented by an electronic management device and comprising the following steps:

[0009] - acquisition of contextual data for a group of software services to be executed on the avionics platform;

[0010] contextual data including, for each software service: a maximum amount of resources used by said service; an operating constraint of said service equal to fault resistance / s or non-fault resistance / s; and if the operating constraint of said service is equal to fault resistance / s, a number of faults / s to which said service must be resistant;

[0011] - calculation, from the acquired contextual data, of a context for the group of software services;

[0012] - launching the execution of one or more software services of the group following a set of rules for distributing software services on the platform and according to the calculated context.

[0013] With the management method according to the invention, the calculation of the context from the acquired contextual data, which includes, for each software service, a maximum quantity of resources allocated to the service, an indication of whether the service should be resistant to one or more failures, and where applicable the number of failures to which it should be resistant, then the launch of the execution of the software service(s) of the group according to the calculated context and following a set of distribution rules on the software service platform, makes it possible to distribute the platform's resources as best as possible among the software services of the group when these resources are limited.

[0014] In particular, only certain software services are then likely to be executed, ensuring that the sum of the maximum quantities of resources used by the executed services does not exceed the available quantity of resources and / or giving priority to the service(s) that must withstand one or more failures.

[0015] According to other advantageous aspects of the invention, the management process comprises one or more of the following features, taken individually or in all technically possible combinations:

[0016] - during context calculation, a priority level is calculated respectively for each software service, the priority level being higher for a service with an operating constraint equal to fault resistance / s than for a service with an operating constraint equal to no fault resistance / s;

[0017] the priority level depending preferably on the number of failures to which the service must be resistant;

[0018] the priority level for a service that must be resistant to N+l failures being preferably even higher than the priority level for a service that must be resistant to N failures / s, N being an integer greater than or equal to 1;

[0019] - the distribution rule set(s) includes one or more rules from the group consisting of: a first rule according to which the execution of a higher priority level service takes precedence over that of a lower priority level service; a second rule according to which the available quantity of platform resources is greater than or equal to the sum of the maximum quantities of resources used by the running software services; and a third rule according to which the quantity of resources available after N failures is greater than the sum of the maximum quantity of resources used by the service(s) that must be resilient to N failures, N being an integer greater than or equal to 1;

[0020] the set of allocation rule(s) preferably comprising all the rules among the aforementioned group;

[0021] - the context of each software service depends on a flight phase of the aircraft, and

[0022] wherein the process further comprises, at each phase change of flight with implementation of a subsequent flight phase, the calculation of a subsequent context for the subsequent flight phase;

[0023] the software service(s) executed during the subsequent flight phase being a function of the subsequent calculated context; the execution of the software service(s) executed during the current flight phase and no longer to be executed during the subsequent phase being stopped and the execution of the software service(s) to be executed newly during the subsequent phase being started;

[0024] - the priority level of each software service depends on the flight phase of the aircraft, and

[0025] in which subsequent priority levels of software services are calculated for the subsequent flight phase during the calculation of the subsequent context; and the software service(s) executed during the subsequent flight phase are then a function of the subsequent priority levels calculated;

[0026] - the method further includes a step of stopping the execution of the service(s) software(s) with the lowest priority, if the amount of available resources is insufficient to launch the execution of a new software service;

[0027] - the least priority software service(s) are the software service(s) having the lowest priority level(s);

[0028] - the contextual data also includes, for each software service: if the The operating constraint of said service is equal to the non-resistance to fault(s), a rate of availability of said service; and

[0029] software services are less of a priority for their execution the lower their availability rate;

[0030] - the process further comprises, prior to the acquisition step, a step of determination of the software service group to be executed, including receiving a new software service group, verifying the received software service group against a predefined set of verification rule(s), and if the received software service group is deemed correct during this verification, then it forms the software service group to be executed; the software service group being unchanged otherwise.

[0031] The invention also relates to a computer program comprising software instructions which, when executed by a computer, implement a management process, as defined above.

[0032] The invention also relates to an electronic device for managing the execution of software application(s) services on an avionics platform intended to be installed on board an aircraft, the avionics platform having resources for the execution of said software services, the electronic management device comprising:

[0033] - an acquisition module configured to acquire contextual data for a group of software services to run on the avionics platform;

[0034] contextual data including, for each software service: a maximum amount of resources used by said service; an operating constraint of said service equal to fault resistance / s or non-fault resistance / s; and if the operating constraint of said service is equal to fault resistance / s, a number of faults / s to which said service must be resistant;

[0035] - a calculation module configured to calculate, from contextual data acquired, a context for the software services group;

[0036] - a launch module configured to launch the execution of one or more software services of the group following a set of rules for distributing software services on the platform and according to the calculated context.

[0037] The invention also relates to an avionics system intended to be carried on board an aircraft, comprising:

[0038] - an avionics platform comprising resources for the execution of services application software(s); and

[0039] - an electronic device for managing the execution on said platform of software application services, the electronic management device being as defined above.

[0040] These features and advantages of the invention will become clearer upon reading the following description, given solely by way of non-limiting example, and made with reference to the accompanying drawings, in which:

[0041] [Fig-1] [Fig.1] is a schematic view of an aircraft comprising a platform avionics comprising resources for the execution of software application(s) services; an electronic enclosure forming the avionics platform, the enclosure comprising a backplane card and several electronic cards connected to the backplane card;

[0042] [Fig.2] [Fig.2] is a schematic representation of a hardware architecture and electronic circuit board software from the [Fig. 1] box; and

[0043] [Fig.3] [Fig.3] is a schematic representation of an electronic device management of the execution of software application services on the avionics platform of figures 1 and 2;

[0044] [Fig.4] [Fig.4] is a flowchart of a method, according to the invention, for managing the execution of software application services, the process being implemented by the electronic management device of the [Fig.3].

[0045] In the description, as well as in the claims, the terms " / s" or " / x" following the name of an object mean that it designates one or more objects of that name, and these terms are identical to the terms " / s" or "(x)", and may be replaced by them if necessary, without changing the content of the invention. By way of example, the expression "software application(s)" then means "of one or more software applications", the expression "failure resistance" means "resistance to one or more failures", and the expression "service(s)" means "to the service(s)".

[0046] In [Fig.1], an aircraft 10 includes an avionics platform 20, generally forming an on-board data center, in order to offer different types of services on board the aircraft 10.

[0047] The avionics platform 20 is configured for example to provide cockpit services for a crew of the aircraft 10 and / or maintenance services for the ground and / or entertainment services for passengers on board the aircraft 10.

[0048] The avionics platform 20 forms, for example, a multimedia server configured to broadcast, via entertainment terminals not shown, multimedia content to the passengers of the aircraft 10, in particular during the flight (for example, films, TV shows, games or music), and / or information on the progress of the flight (altitude, speed, current position, advancement, etc.). As an optional addition, the multimedia server, formed by the avionics platform 20, is configured to broadcast practical information concerning, for example, the arrival airport, for example via audio and / or video announcements.

[0049] Each entertainment terminal is known in itself and is connected to the multimedia server via a local network, not shown, on board the respective aircraft 10.

[0050] Each entertainment terminal is, for example, fixed or integrated into the passenger's seat itself, or is fixed or integrated into the seat back in front of the passenger's seat. The seats are typically arranged in rows within the aircraft 10.

[0051] The avionics platform 20 comprises at least one electronic communication card 22, a group of electronic computing cards 25, and at least one power supply card 28. The power supply card 25 and the electronic communication card(s) 22 and computing card(s) 25 are interconnected, for example, via a backplane card 30, as shown in [Fig. 1]. The avionics platform 20 is, for example, implemented as an electronic enclosure 32 comprising the backplane card 30, one or more electronic communication cards 22, one or more electronic computing cards 25, and one or more power supply cards 28. Each electronic communication card 22, each electronic computing card 25, and each power supply card 28, respectively, is connected to the backplane card 30 via a respective backplane connector 34, as shown in [Fig. 1].The electronic enclosure 32 also 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 card(s) 28; as well as 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 avionics platform 20 to the local network, as well as to a power supply network, not shown and carried on board the aircraft 10.

[0052] Advantageously, the avionics platform 20 comprises several cards 22, 25, 28 of the same type, namely several electronic communication cards 22, several electronic computing cards 25 and several power supply cards 28.

[0053] A person skilled in the art will understand that having several cards 22, 25, 28 of the same type improves the reliability and availability of the platform 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 then reduce the cost and resource requirement 40 to achieve satisfactory redundancy of cards 22, 25, 28.

[0054] In the example of [Fig. 1], the avionics platform 20 comprises two electronic communication cards 22, six electronic computing cards 25 and one power supply card 28. Alternatively, the avionics platform 20 comprises two electronic communication cards 22, six electronic computing cards 25 and two power supply cards 28, in order to have redundancy for each type of card.

[0055] Each electronic communication card 22 is configured to communicate with one or more pieces of equipment, not shown, external to the platform 20. Each electronic communication card 22 is also called an input / output card, and also noted I / O (from the English Input / Output) in [Fig.1].

[0056] Each electronic computing card 25, also denoted C in [Fig. 1], includes resources 40 and is configured for the execution of software application(s). The resources 40, also called hardware resources, are physical or logical elements specifically designed to be made available to the software application(s).

[0057] Resources 40 are, for example, divided into the following categories visible in [Fig.2]:

[0058] - 40A CPU (Central Processing Unit) type resources;

[0059] - 40B GPU (Graphics Processing Unit) type resources;

[0060] - 40C network communication resources, such as a resource of type Ethernet, denoted ETH in [Fig.2], for communicating with the on-board local network on the one hand, and with an external communication network to the aircraft 10 on the other hand,

[0061] - 40D resources of the RAM type (from English Random Access Memory); and

[0062] - 40E storage memory type resources, i.e., memory type mass (from the English mass memory), such as SSD (from the English Solid State Drive) resources.

[0063] Those skilled in the art will understand that CPU 40A and GPU 40B resources are computing resources, i.e., capable of performing computational operations, with GPU 40B resources being more dedicated to graphics computing and CPU 40A resources to general computing. Those skilled in the art will also understand that these CPU 40A and GPU 40B resources, as well as other resources such as network communication 40C, RAM 40D, and storage memory 40E, are implemented as at least one electronic component that can be integrated onto a printed circuit board, for example, as an integrated circuit, such as an ASIC (Application-Specific Integrated Circuit), or as a programmable logic component, such as an FPGA (Field-Programmable Gate Array). (English: Field Programmable Gate Array), or in the form of a microcontroller, or even in the form of a specific processor, such as a specialized signal processing unit or DSP (Digital Signal Processor). The type of electronic component to preferentially use to implement each type of resource among the aforementioned types of resources is known to those skilled in the art, and is therefore not described in further detail.

[0064] Advantageously, the group of computing electronic cards 25 comprises resources 40 of all types from the aforementioned group. For example, each computing electronic card 25 comprises resources 40 of all types from the aforementioned group. In other words, in this example, each computing electronic card 25 comprises both CPU resources 40A, GPU resources 40B, network communication resources 40C, RAM resources 40D, and storage memory resources 40E.

[0065] The group of electronic computing cards 25 comprises several electronic computing cards 25, each including the same type or types of resources 40.

[0066] Advantageously, the electronic cards of the computing electronic card group 25 are all identical, that is to say, they all include the same resources 40A, 40B, 40C, 40D and 40E. For example, each computing electronic card 25 in particular includes two 40A CPU resources, one 40B GPU resource, two 40C network communication resources, four 40D RAM resources, and two 40E storage memory resources.

[0067] In [Fig.2], each electronic computing card 25 comprises a hardware layer 42, a low-level software layer 44, a middleware layer 46 and a high-level software layer 48, these four layers 42, 44, 46 and 48 being superimposed.

[0068] Advantageously, all the electronic computing cards 25 are materially analogous, or even materially identical, and therefore have the same material layer 42.

[0069] Advantageously, all the computing electronic boards 25 have the same software layers, namely the same low-level layer 44, the same middle-level layer 46, and the same high-level layer 48. In other words, the low-level layer 44 is unique for the group of computing electronic boards 25, while being stored separately on each of the computing electronic boards 25. Similarly, the middle-level layer 46 is unique for the group of computing electronic boards 25, while being stored separately on each of the computing electronic boards 25. The high-level layer 48 is also unique for the group of 25 electronic computing cards, while being stored separately on each of the 25 electronic computing cards.

[0070] Advantageously, these low-level 44, middle-level 46 and high-level 48 layers are further assembled into a single software cluster aggregating all of these software resources

[0071] Each power supply card 28, also denoted P in [Fig. 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 computing cards 25. The electrical energy delivered to the electronic cards 22, 25 is typically direct current electrical energy or DC (Direct Current) energy, and each power supply card 28 then includes an alternating current-direct current converter, or AC-DC converter, when the electrical energy received from the onboard power supply network is alternating current electrical energy, or a direct current-direct current converter, or DC-DC converter, when said electrical energy received is direct current energy.

[0072] The hardware layer 42 of each electronic computing card 25 includes the resources 40, and typically the CPU type resources 40A, the GPU type resources 40B, the network communication type resources 40C, the RAM type resources 40D, and the storage memory type resources 40E.

[0073] The low-level software layer 44 includes a bootloader unit 50, and a low-level service provisioning unit 52 comprising, for example, a kernel, such as a Linux kernel, and one or more software drivers.

[0074] The middle-level software layer 46 includes an orchestrator 60, a computer container manager 62, a file manager 64 and a set 66 of configuration files, the orchestrator 60, also called an orchestration device or management device, being capable of controlling one or more software services 70, also called unitary software services, that is to say, of managing the execution of such software services 70. The computer container manager 62 of each electronic computing card 25 is in particular configured to obtain a list of the computer containers, that is to say, the software resources, present on the respective electronic computing card 25, so that the orchestrator 60 can then control their execution.In addition, the computer container manager 62 of one of the electronic computing cards 25 is designated as the master manager among the managers 62 of the different electronic computing cards 25, each manager 62 of the other electronic computing card(s) 25 then being . slave. The master manager of computer containers 62 is then further configured to obtain, via each slave manager 62, a list of computer containers from each other computing card 25, and then to generate a list of computer containers from all the computing electronic cards 25, that is to say a list of all the software resources forming the software cluster described above.

[0075] The high-level software layer 48 includes said software services 70.

[0076] When the avionics platform 20 forms a cockpit services server, the Software services 70 correspond for example to a non-avionics system service of the type electronic flight bag or EFB (from the English Electronic Flight Bag), remotely accessible by a pilot through a simple web browser, or to a service aggregating meteorological data to propose alternative trajectories less generating condensation trails.

[0077] When the avionics platform 20 forms a maintenance service server, the software services 70 correspond, for example, to an embedded predictive maintenance service, or to "health monitoring" services enabling the detection of critical thresholds in the operation of aircraft systems.

[0078] When the avionics platform 20 forms an entertainment service server, i.e. the multimedia server, the software services 70 correspond for example to the services offered to the passengers of the aircraft 10: video on demand or VOD (from the English Video On Demand), audio on demand or AOD (from the English Audio On Demand), games, flight parameters (altitude, speed, etc.) and its progress (for example using a "moving map"), audio and / or video announcements from the crew, etc.

[0079] According to the invention, the electronic management device 60 comprises a module 80 for acquiring contextual data for a group of software services 70, a module 82 for calculating a context from the acquired contextual data for the group of software services 70 and a module 84 for launching the execution of the software service(s) 70 of the group according to a set of distribution rule(s) and according to the calculated context.

[0080] In addition, the electronic management device 60 includes a module 86 for stopping the execution of the least priority software service(s) 70 and / or a module 88 for determining the group of software services to be executed, prior to acquiring contextual data for said group.

[0081] In the example of [Fig.3] representing the electronic management device 60 in general, the electronic management device 60 includes an information processing unit 90 formed for example of a memory 92 and a processor 94.

[0082] In the example of [Fig. 3], the acquisition module 80, the calculation module 82, and the launch module 84, as well as the optional stop module 86 and the determination module 88, are each implemented as a software program, or a software component, executable by the processor 94. The memory 92 of the management device 60 is then capable of storing acquisition software, calculation software, and launch software, as well as the optional stop software and determination software. The processor 94 is then capable of executing each of the following software programs: acquisition software, calculation software, and launch software, as well as the optional stop software and determination software.

[0083] In an alternative not shown, the acquisition module 80, the calculation module 82 and the launch module 84, as well as optionally the stop module 86 and the determination module 88, are each made in the form of a programmable logic component, such as an FPGA (Field Programmable Gate Array) or in the form of a dedicated integrated circuit, such as an ASIC (Application Specified Integrated Circuit).

[0084] When the electronic control device 60 is implemented in the form of one or more software programs, i.e., in the form of a computer program, it is also capable of being stored on a computer-readable medium (not shown). A computer-readable medium is, for example, a medium capable of storing electronic instructions and being connected to a bus of a computer system. For example, a readable medium is an optical disc, a magneto-optical disc, a ROM, a RAM, any type of non-volatile memory (e.g., EPROM, EEPROM, FLASH, NVRAM), a magnetic card, or an optical card. A computer program comprising software instructions is then stored on the readable medium.

[0085] In the example in [Fig. 2], those skilled in the art will understand that the management device 60, also called the orchestrator 60, uses resources 40 of the computing card 25 on which it is installed for its implementation. In this example, the orchestrator 60 is configured to acquire contextual data for the software service group 70, then to calculate the context from the acquired contextual data for the software service group 70, and finally to launch the execution of the software service(s) 70 of the group according to the allocation rule(s) and based on the calculated context. In addition, the orchestrator 60 is also configured to stop the execution of the lowest priority software service(s) 70 and / or to determine the software service group to be executed, prior to acquiring contextual data for said group.

[0086] The acquisition module 80 is configured to acquire contextual data for a group of software services 70 to run on the avionics platform 20. The acquisition module 80 is configured for example to acquire said contextual data from a first database 96, also called the contextual database.

[0087] The contextual data includes, for example, for each software service 70: a maximum quantity of resources 40 used by said service 70; an operating constraint of said service 70 equal to fault resistance / s or non-fault resistance / s; and if the operating constraint of said service 70 is equal to fault resistance / s, a number of faults / s to which said service 70 must be resistant.

[0088] In addition, the contextual data includes, if the operating constraint of a respective service 70 is equal to non-fault resistance / s, a required availability rate for said service 70. The availability rate of a service is generally expressed as a percentage of the time during which that service is operational.

[0089] In addition, the contextual data includes more general data relating to the state of the electronic computing boards 25, with, for example, for each computing board 25, a faulty state or a partially unusable state where applicable. When a computing board 25 is in a normal operating state, this is not necessarily mentioned in the contextual data, since the respective computing board 25 is then in its nominal state.

[0090] In addition, the contextual data includes data relating to operational conditions specific to aircraft 10, such as an indication of a current flight phase of aircraft 10, and / or the status of each avionics system on board aircraft 10, including, for each avionics system, a fault status where applicable. Again, when the avionics system is in a normal operating state, this is not necessarily mentioned in the contextual data, since the respective avionics system is then in its nominal state.

[0091] The calculation module 82 is configured to calculate, from the acquired contextual data, a context for the software service group 70.

[0092] The context is for example a prioritization of the software services 70 with respect to each other, and the calculation module 82 is then configured to calculate a priority level respectively for each software service 70, based on the acquired contextual data.

[0093] The priority level is, for example, higher for a service 70 with an operating constraint equal to resistance to failure / s than for a service 70 with an operating constraint equal to no resistance to failure / s. In other words, according to this example, the priority level is higher for a service that must withstand one or more failures, that is, having a guarantee of resistance to one or more failures, than for a service that is not expected to withstand one or more failures, i.e., one that does not have a guarantee of resistance to one or more failures.

[0094] In addition to this example, for a software service 70 with an operating constraint equal to fault tolerance / s, the priority level also depends on the number of faults / s to which the service 70 must be resistant. Advantageously, the priority level for a service 70 that must be resistant to N+1 faults is higher than the priority level for a service 70 that must be resistant to N faults / s, where N is an integer greater than or equal to 1.

[0095] In addition, the calculation module 82 is configured to calculate the priority level of each software service 70 according to a flight phase of the aircraft 10, included in the contextual data, and then to calculate the priority level of each software service at each change of flight phase, the priority level being likely to vary from one flight phase to another.

[0096] The flight phases are typically as follows: parking (aircraft 10 is parked), taxiing, takeoff, climb, cruise, descent, landing.

[0097] By way of example, a flight plan loading software service 70 is essential when the aircraft 10 is in the parking phase of flight, so that the aircraft 10 can then perform the flight, and the priority level of this software service 70 is therefore higher in the parking phase than in the other flight phases. Conversely, other software services 70 have a higher priority level for the takeoff, climb, cruise, descent, and landing phases of flight than for the parking phase of flight. For example, entertainment services, also called IFE (In-Flight Entertainment) services, have a high priority level during cruise.

[0098] When the calculation module 82 is configured to calculate the priority level of each software service 70 based on both an aircraft flight phase 10 and a failure rate of N / s, the priority level is calculated first based on the flight phase, and then second based on the failure rate of N / s. According to this configuration, the priority level of each software service 70 is typically calculated first according to different ranges of values ​​(for example, in increments of 100) depending on the flight phase forming the context; then within each range of values, the priority level is refined according to the required failure rate of N / s.

[0099] In addition, when the contextual data also includes, for each software service 70 having an operating constraint equal to non-fault resistance / s, a respective availability rate of said service 70, the calculation module 82 is configured to calculate the priority level of each software service 70 based also on said availability rate.

[0100] According to this addition, the priority level is, for example, higher the higher the availability rate. In other words, the lower the priority for software services 70 is for their execution the lower their availability rate.

[0101] The launch module 84 is configured to launch the execution of one or more software services 70 from the group according to the set of rules for distributing software services 70 on the platform 20 and according to the calculated context.

[0102] The allocation rule set typically comprises one or more rules from the group consisting of:

[0103] - a first rule according to which the execution of a priority level 70 service higher priority takes precedence over that of a lower priority level 70 service;

[0104] - a second rule according to which the available quantity of resources 40 of the platform 20 is greater than or equal to the sum of the maximum quantities of resources 40 used by the software services 70 executed; and

[0105] - a third rule according to which the quantity of resources 40 available after N failure(s) is greater than the sum of the maximum quantity(s) of resources 40 used by the service(s) 70 that must be resistant to N failure(s), N being an integer greater than or equal to 1.

[0106] Advantageously, the distribution rule set includes all the rules from the aforementioned group, that is to say, it includes the first, second and third rules.

[0107] The shutdown module 86 is configured to stop the execution of the lowest priority software service(s) if the available amount of resources 40 is insufficient to start the execution of a new software service 70. The lowest priority software service(s) 70 are those with the lowest priority level(s).

[0108] For the distribution of software services among the resources 40 of the avionics platform 20, in particular among the resources 40 of the different electronic computing boards 25, the launch module 84 is then configured for example to launch the execution of the software services 70 as long as there are sufficient resources available, and preferentially launching the execution of the software services 70 in descending order of priority levels, that is to say, launching first the execution of the highest priority software services 70.

[0109] Then, if there are no more resources 40 available to launch the execution of a new software service 70, then the shutdown module 86 is configured to stop the execution of the lowest priority software service(s) 70, i.e., in ascending order of priority levels, until there are again sufficient resources 40 available for the execution of the new software service(s) 70, i.e., to recover enough resources 40 to be able to execute The new software service(s) 70, while respecting the priority hierarchy between the new software service(s) 70 to be executed and the software service(s) 70 currently running. In other words, the need to launch the execution of a new software service 70 will only cause the execution of a currently running software service 70 to stop if the new software service 70 to be executed has a higher priority level than the currently running software service 70.

[0110] As an optional complement, the determination module 88 is configured to determine the software service group 70 to be executed, in particular to check a new software service group 70 to be executed before the software services 70 of said new group can be launched by the launch module 84.

[0111] According to this optional addendum, the determination module 88 is configured, for example, to receive a new group of software services 70, for instance, from a second database 98, also called the software services database; then to verify the received group of software services 70 against a predefined set of verification rules; and finally to replace the current group of software services 70 with the new received group of software services 70 if it is deemed correct following this verification; the current group of software services 70 being maintained otherwise, that is, if the new received group is deemed incorrect following this verification. The determination module 88 is typically configured to verify the new received group of software services 70 against a set of requirements.The set of requirements includes, for each context and each software service 70, a performance requirement, such as an availability rate higher than a predefined minimum rate (for example 95%) for the context in question.

[0112] The context typically depends on the state of the resources 40 and the operational conditions specific to the aircraft 10. The state of the resources is, for example, evaluated for each resource 40 with a value chosen from among failed, partially unusable, and available. The operational conditions specific to the aircraft 10 are defined, on the one hand, by the flight phase, and on the other hand, by the state of the avionics systems, the state of each avionics system typically having a value chosen from among failed and operational. The context is then, for example, expressed as a triplet including a number of resources 40 that are failed, the flight phase concerned, and an indication of any failure(s) of an avionics system.A context defined in the form of the triplet (0, cruise, hydraulic system failure) then means that the avionics platform 20 is fully operational (no resource 40 is out of service), that the aircraft 10 is in flight phase equal to cruise, and that there is a failure of the hydraulic system.

[0113] The determination module 88 is then advantageously configured to perform the verification of the new group received from software services 70 from the set of requirements and via statistical models, or via Monte Carlo type simulations.

[0114] The operation of the avionics platform 20, and in particular of the electronic management device 60, or orchestrator 60, will now be explained, in particular with the help of [Fig.4] representing an organizational chart of the method, according to the invention, of managing the execution of software services 70, the method being implemented by the management device 60.

[0115] During an optional initial step 100, the management device 60 determines, via its determination module 88, the group of software services 70 to be executed, and in particular checks whether a new group of software services 70 received from the second database 98 is correct and can then replace the current group of software services 70.

[0116] During this determination step 100, the determination module 88 receives the new software service group 70, then verifies it according to the verification rule(s), and replaces it with the current software service group 70 if the new group is correct. Conversely, if the new group is incorrect according to the verification rule(s), then the determination module 88 discards it and retains the current software service group 70.

[0117] A person skilled in the art will understand that the current group of software services 70 is a predefined group of software services 70 assumed to be correct or a group of software services 70 determined previously, that is to say, having been previously checked according to the set of verification rule(s), then having been considered correct and having then replaced a previous group of software services 70.

[0118] During the next step 110, the management device 60 acquires, via its acquisition module 80, the contextual data for the group of software services 70 to be executed on the avionics platform 20, and for example for the group determined during the previous optional determination step 100.

[0119] During a subsequent calculation step 120, the management device 60 calculates, via its calculation module 84, the context for the software service group 70 from the contextual data acquired during the previous acquisition step 110.

[0120] During this calculation step 120, the calculation module 84 typically calculates the priority level for each software service 70, first according to whether the operating constraint for said service 70 is equal to or not fault resistance / s, then according to the number N of faults / s to which said service 70 must be resistant when the operating constraint is equal to fault resistance / s, or according to the rate availability required for said service 70 when the operating constraint equals non-resistance to failure / s.

[0121] In addition, the priority level of each software service 70 depends on the flight phase of the aircraft 10, the calculation module 84 then calculates the priority level for each software service 70 based further on the flight phase of the aircraft 10.

[0122] At the end of the calculation step 120, the management device 60 launches, via its launch module 86 and during a subsequent step 130, the execution on the avionics platform 20 of one or more software services 70 of the group, as represented by the arrows Fl in [Fig.3], this according to the context calculated during the previous calculation step 120 and according to the set of distribution rule(s).

[0123] During this launch step 130, the launch module 86 typically takes into account one or more of the first, second and third distribution rules, and preferably each of the first, second and third distribution rules, to define the software service(s) 70 whose execution is to be launched.

[0124] The launch module 86, for example, launches the execution of the software services 70 of the current group as long as there are sufficient resources available, and orders these execution launches from the highest priority software services 70 to the lowest priority software services 70, that is to say, starting with the software services 70 having the highest priority levels, and ending with those having the lowest priority levels.

[0125] At the end of the launch step 130, if there are no more resources 40 available to launch the execution of a new software service 70, the management device 60 stops, in a subsequent step 140 and via its stop module 86, the execution of one or more software services 70, as represented by the arrows F2 in [Fig.3], advantageously the least priority software service(s) 70, until sufficient resources 40 are freed up to be able to execute the new software service(s) 70 that need to be executed.

[0126] During this shutdown step 140, the shutdown of the execution of software service(s) 70 is preferentially carried out in ascending order of the priority levels of the software services 70 in execution, and by comparing the priority levels of the software services 70 in execution with the priority levels of the new software services 70 to be executed, the execution of a software service 70 in execution being stopped only if the new software service 70 to be executed is of a higher priority level than that of the software service 70 in execution.

[0127] At the end of the shutdown step 140, the management device 60 returns to the determination step 100 if a new group of software services 70 has been received, or to the acquisition step 110 to acquire new contextual data, or to the step calculation 120 to recalculate the context for the software service group 70, for example in case of a change in flight phase.

[0128] As an optional complement, the calculated context of each software service 70 depends on the flight phase of the aircraft 10, and the calculation module 84 then calculates the context for the group of software services 70 at each change of flight phase, from a current flight phase to a subsequent flight phase, and then calculates a subsequent context for the subsequent flight phase.

[0129] According to this optional addition, the software service(s) 70 executed during the subsequent flight phase are then dependent on the calculated subsequent context. The execution of the software service(s) 70 to be newly executed during the subsequent phase is then launched during the next launch step 130. The execution of the software service(s) 70 executed during the current flight phase and no longer to be executed during the subsequent phase is stopped during the next stop step 140.

[0130] The method for managing the execution of software services 70 and the electronic management device 60 according to the invention then make it possible to distribute the limited resources 40 of the avionics platform 20 among the software services 70 in the best possible way, according to the context calculated from the contextual data.

[0131] This contextual data includes, for each software service, a maximum amount of resources allocated to the service, an indication of whether or not the service must be resistant to one or more faults, and where applicable the number of faults to which it must be resistant and / or a required availability rate; and the allocation of these limited resources 40 then favours the software services 70 that must be the most resistant to faults, and failing that, that must offer the highest availability rate.

[0132] Advantageously, the flight phase of the aircraft 10 is taken into account, which makes it possible to define a fault tolerance and / or an availability rate for each software service 70 according to the flight phase, and thus optimize the allocation of resources also according to the flight phase. In doing so, the prioritization of the software services 70 varies from one flight phase to another.

[0133] It is thus understood that the management process and the management device 60 according to the invention make it possible to better manage the execution of the software services 70 with limited resources 40, and thus improve the operation of the avionics platform 20.

Claims

1. Demands Method for managing the execution of software services (70) of software application(s) on an avionics platform (20) intended to be installed on board an aircraft (10), the avionics platform (20) comprising resources (40) for the execution of said software services (70), the method being implemented by an electronic management device (60) and comprising the following steps: - acquisition (110) of contextual data for a group of software services (70) to be executed on the avionics platform (20); the contextual data comprising, for each software service (70): a maximum quantity of resources (40) used by said service (70); an operating constraint of said service (70) equal to fault resistance / s or non-fault resistance / s; and if the operating constraint of said service (70) is equal to fault resistance / s, a number of faults / s to which said service (70) must be resistant; - calculation (120), from the acquired contextual data, of a context for the group of software services (70), a priority level being calculated respectively for each software service (70), the priority level being higher for a service (70) with an operating constraint equal to fault resistance / s than for a service (70) with an operating constraint equal to no fault resistance / s; - launch (130) of the execution of one or more software services (70) of the group according to a set of rules for distributing software services (70) on the platform (20) and according to the calculated context; in which the context of each software service (70) depends on a flight phase of the aircraft (10), and in which the method further includes, at each change of flight phase with implementation of a subsequent flight phase, the calculation (120) of a subsequent context for the subsequent flight phase; the software service(s) (70) executed during the subsequent flight phase being a function of the calculated subsequent context; the execution of the software service(s) (70) executed during the current flight phase and no longer to be executed during the subsequent phase is then stopped and the execution of the software service(s) (70) to be newly executed during the subsequent phase is started.

2. A method according to claim 1, wherein the priority level depends on the number of failures / s to which the service (70) must be resistant; the priority level for a service (70) to be resistant to N +1 failures being preferably even higher than the priority level for a service (70) to be resistant to N failures / s, N being an integer greater than or equal to 1.

3. A method according to claim 1 or 2, wherein the allocation rule set(s) comprises one or more rules from the group consisting of: a first rule according to which the execution of a higher priority level service (70) takes precedence over that of a lower priority level service (70); a second rule according to which the available quantity of resources (40) of the platform (20) is greater than or equal to the sum of the maximum quantities of resources (40) used by the executed software services (70); and a third rule according to which the quantity of resources (40) available after N failures is greater than the sum of the maximum quantity(ies) of resources (40) used by the service(s) (70) that must be resilient to N failures, N being an integer greater than or equal to 1; the allocation rule set(s) preferably comprising all the rules from the aforementioned group.

4. A method according to any one of the preceding claims, wherein the priority level of each software service (70) depends on the flight phase of the aircraft (10), and wherein subsequent priority levels of the software services (70) are calculated for the subsequent flight phase during the calculation of the subsequent context; and the software service(s) (70) executed during the subsequent flight phase are then a function of the subsequent calculated priority levels.

5. A method according to any one of the preceding claims, wherein the method further comprises a step of stopping the execution of the least priority software service(s) (70) s, if the amount of available resources (40) is insufficient to launch the execution of a new software service (70).

6. Method according to claim 5, wherein the least priority software service(s) (70) is / are the software service(s) (70) having the lowest priority level(s).

7. A method according to any one of the preceding claims, wherein the contextual data further includes, for each software service (70): if the operating constraint of said service (70) is equal to non-fault tolerance / s, an availability rate of said service (70); and the software services (70) have less priority for their execution the lower their availability rate.

8. A method according to any one of the preceding claims, wherein the method further comprises, prior to the acquisition step (110), a determination step (100) of the software service group (70) to be executed, comprising receiving a new software service group (70), verifying the received software service group (70) according to a predefined set of verification rule(s), and if the received software service group (70) is deemed correct during this verification, then it forms the software service group (70) to be executed; the software service group (70) being unchanged otherwise.

9. A computer program comprising software instructions which, when executed by a computer, implement a method according to any one of the preceding claims.

10. An electronic device (60) for managing the execution of software application(s) (70) services on an avionics platform (20) intended to be installed on board an aircraft (10), the avionics platform (20) having resources (40) for the execution of said software services (70), the electronic management device (60) comprising: - an acquisition module (80) configured to acquire contextual data for a group of software services (70) to be executed on the avionics platform (20); the contextual data comprising, for each software service (70): a maximum amount of resources (40) used by said service (70); an operating constraint of said service (70) equal to fault tolerance or non-fault tolerance; and if the the operating constraint of said service (70) is equal to fault resistance / s, a number of faults / s to which said service (70) must be resistant; - a calculation module (82) configured to calculate, from the acquired contextual data, a context for the group of software services (70); a priority level being calculated respectively for each software service (70), the priority level being higher for a service (70) with an operating constraint equal to fault resistance / s than for a service (70) with an operating constraint equal to no fault resistance / s; the context of each software service (70) depending on a flight phase of the aircraft (10), and at each change of flight phase with implementation of a subsequent flight phase, a subsequent context is calculated for the subsequent flight phase;- a launch module (84) configured to launch the execution of one or more software services (70) of the group according to a set of rules for distributing software services (70) on the platform (20) and according to the calculated context; the software service(s) (70) executed during the subsequent flight phase being a function of the calculated subsequent context; the execution of the software service(s) (70) executed during the current flight phase and no longer to be executed during the subsequent phase being stopped and the execution of the software service(s) (70) to be newly executed during the subsequent phase being started.

11. Avionics system intended to be carried on board an aircraft (10), comprising: - an avionics platform (20) having resources (40) for the execution of software application(s) (70); and - an electronic device for managing the execution on said platform (20) of the software application(s) (70), characterized in that the electronic management device is according to the preceding claim.

Images