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 services of software application(s) on an avionics platform, associated computer program and avionics system

[0001] The present invention relates to a method for managing the execution of software services of software application(s) on an avionics platform intended to be carried 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; 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 services of software application(s); as well as an avionics system comprising such an avionics platform and such an electronic management device.

[0003] Current software applications are no longer monolithic, and are generally composed of many software components, also called software services, working together to enable the software application to function properly. Each software service is generally encapsulated in a container forming an executable file. Software services are, for example, services compatible with the Kubernetes system, which is an open-source software system for automating the deployment, scaling, and management of containerized applications, these containers being called pods in the Kubernetes system.

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

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

[0006] However, such orchestrators are not suitable for operating correctly in an environment where hardware resources are limited, particularly when the platform is intended to be mounted on an aircraft.

[0007] The aim of the invention is then to propose a method, and an associated electronic device, for managing the execution of software services of software application(s) on an avionics platform, making it possible to better manage the execution of software services with limited resources and thus to improve the operation of the platform.

[0008] To this end, the invention relates to a method for managing the execution of software services of software application(s) on an avionics platform intended to be carried 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] 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 resistance to failure / s or non-resistance to failure / s; and if the operating constraint of said service is equal to resistance to failure / s, a number of failure / 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, these comprising, for each software service, a maximum quantity of resources allocated to the service, an indication according to which the service must or must not be resistant to one or more failures, and where appropriate the number of failures to which it must be resistant, then the launch of the execution of software service(s) of the group according to the calculated context and according to a set of distribution rule(s) on the software services platform, makes it possible to best distribute the resources of the platform between the software services of the group when these resources are limited.

[0014] In particular, only certain software services are then likely to be executed while 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 by giving priority to the service(s) that must withstand one or more failures.

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

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

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

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

[0019] - the set of distribution rules includes one or more rules among the group consisting of: a first rule according to which the execution of a higher priority level service takes priority 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 executed software services; and a third rule according to which the quantity of resources available after N failure / s is greater than the sum of the maximum quantity / s of resources used by the service / s which must be resistant to N failure / s, N being an integer greater than or equal to 1;

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

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

[0022] wherein the method further comprises, at each change of flight phase 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 calculated subsequent 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 then stopped and the execution of the software service(s) to be executed again during the subsequent phase being launched;

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

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

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

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

[0028] - the contextual data also includes, for each software service: if the operating constraint of said service is equal to non-resistance to failure / s, an availability rate of said service; and

[0029] the software services are all the less of a priority for their execution as their availability rate is low;

[0030] - the method further comprises, before the acquisition step, a step of determining mination of the group of software services to be executed, comprising receiving a new group of software services, verifying the received group of software services according to a predefined set of verification rule(s), and if the received group of software services is considered correct during this verification, then it forms the group of software services to be executed; the group of software services being unchanged otherwise.

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

[0032] The invention also relates to an electronic device for managing the execution of software services of software application(s) on an avionics platform intended to be carried on board an aircraft, the avionics platform comprising 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 be executed on the avionics platform;

[0034] 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 resistance to failure / s or non-resistance to failure / s; and if the operating constraint of said service is equal to resistance to failure / s, a number of failure / s to which said service must be resistant;

[0035] - a calculation module configured to calculate, from the 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(s) software services, the electronic management device being as defined above.

[0040] These characteristics and advantages of the invention will appear more clearly on reading the description which follows, given solely by way of non-limiting example, and made with reference to the appended drawings, in which:

[0041] [Fig-1] [Fig.l] is a schematic view of an aircraft comprising a platform avionics comprising resources for the execution of software application(s) software services; an electronic box forming the avionics platform, the box 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 card software of the box of [Fig.l]; and

[0043] [Fig.3] [Fig.3] is a schematic representation of an electronic device of managing the execution of software application(s) software 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 the software application(s) software services, the method being implemented by the electronic management device of [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 this designates one or more objects of this name, and these terms are identical to the terms " / s" or "(x)", and may be replaced by them if necessary, without this changing the content of the invention. For example, the expression "software application / s" then means "of one or more software applications", the expression "resistance to failure / s" means "resistance to one or more failures", and the expression "to the service / s" means "to the service or services".

[0046] In [Fig.l], an aircraft 10 comprises an avionics platform 20, generally forming an on-board data server (from the English on-board data center), in order to offer different types of services on board the aircraft 10.

[0047] The avionics platform 20 is for example configured to offer 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, progress, 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 per se, 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 seat itself, or is fixed or integrated into the back of the seat located in front of the passenger 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 card(s) 25, at least one power supply card 28, the power supply cards 25 and electronic communication cards 22 and computing cards 25 being interconnected with each other, for example via a backplane card 30, as shown in [Fig.l]. The avionics platform 20 is for example produced in the form of an electronic box 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, respectively each power supply card 28, is connected to the backplane card 30 via a respective backplane connector 34, as shown in [Fig.l].The electronic box 32 further comprises a protective casing 36 inside which are housed the backplane card 30 and the plurality of electronic communication cards 22 and calculation cards 25 and power supply card(s) 28; as well as external connectors 38 arranged on the periphery of the box 36. The external connectors 38 are in particular intended to allow the connection of the avionics platform 20 to the local network, as well as to a power supply network, not shown and 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 calculation cards 25 and several electrical power supply cards 28.

[0053] Those skilled in the art will then understand that having several cards 22, 25, 28 of the same type makes it possible to improve the reliability and availability of the platform 20, the cards of the same type being redundant with each other. Furthermore, having a high number of cards 22, 25, 28, in particular electronic computing cards 25, makes it possible to reduce the “granularity” of each card 22, 25, 28 within the electronic box 32, and thus to reduce the cost and the need in terms of resources 40 to carry out satisfactory redundancy of the cards 22, 25, 28.

[0054] In the example of [Fig.l], the avionics platform 20 comprises two electronic communication cards 22, six electronic calculation cards 25 and one power supply card 28. Alternatively, the avionics platform 20 comprises 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.

[0055] Each electronic communication card 22 is configured to communicate with one or more devices, 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.l].

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

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

[0058] - 40A resources of the CPU type (from the English Central Processing Unit);

[0059] - 40B resources of GPU type (from the English Graphics Processing Unit);

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

[0061] - resources 40D of the random access memory type, that is to say of the RAM type (from the English Random Access Memory); and

[0062] - 40E resources of storage memory type, i.e. of storage 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 the CPU 40A and GPU 40B type resources are computational resources, i.e. capable of performing computation operations, the GPU 40B type resources being more dedicated to graphical computation and those of the CPU 40A type to general computation. The person skilled in the art will also understand that these resources of the CPU 40A type and of the GPU 40B type, as well as the other resources of the network communication 40C type, of the RAM 40D type and of the storage memory 40E type, are produced in the form of at least one electronic component that can be integrated on a printed circuit board, and for example in the form of an integrated circuit, such as an ASIC (Application Specific Integrated Circuit), or in the form of a programmable logic component, such as an FPGA (Field Programmable Gate Array), or in the form of a microcontroller, or even in the form of a specific processor, such as a processor specialized in signal processing or DSP (from the English Digital Signal Processor). The type of electronic component to be used preferably to produce each type of resource among the aforementioned types of resources is known to those skilled in the art, and is therefore not described in more detail.

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

[0065] The group of electronic calculation card(s) 25 comprises several electronic calculation cards 25, each including the same type(s) of resource(s) 40.

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

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

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

[0069] Advantageously, all the electronic calculation cards 25 have the same software layers, that is to say respectively 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 electronic calculation cards 25, while being stored separately on each of the electronic calculation cards 25. Similarly, the middle-level layer 46 is unique for the group of electronic calculation cards 25, while being stored separately on each of the electronic calculation cards 25. The high-level layer 48 is also unique for the group of electronic calculation cards 25, while being stored separately on each of the electronic calculation cards 25.

[0070] Advantageously again, these low level 44, middle level 46 and high level layers level 48 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.l], is configured to convert electrical energy received, via one or more respective external connectors 38, from the onboard electrical power supply network on board the aircraft 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 electrical energy or DC energy (from the English Direct Currenf), and each power supply card 28 then comprises an alternating-direct converter, or AC-DC converter (AC from the English Alternative Current), when the electrical energy received from the onboard electrical power supply network is alternating electrical energy, or a direct-direct converter, or DC-DC converter, when said received electrical energy is direct energy.

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

[0073] The low-level software layer 44 comprises a unit 50 for loading a bootloader program, and a unit 52 for providing low-level services comprising, for example, a kernel, such as a Linux kernel, and one or more software drivers.

[0074] The mid-level software layer 46 comprises 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 able to control one or more software services 70, also called unitary software services, i.e. to manage 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, i.e. software resources, present on the respective electronic computing card 25, so that the orchestrator 60 can then control their execution.Furthermore, the computer container manager 62 of one of the electronic computing cards 25 is designated as a 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 a slave. The master computer container manager 62 is then further configured to obtain, via each slave manager 62, a list of the computer containers of each other computing card 25, then to generate a list of the containers. computing resources of all electronic cards calculation 25, that is to say a list of all the software resources forming the software cluster described previously.

[0075] The high-level software layer 48 comprises 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 electronic flight bag or EFB type, remotely accessible by a pilot through a simple web browser, or to a service aggregating meteorological data to propose alternative trajectories that generate less condensation trails.

[0077] When the avionics platform 20 forms a maintenance services server, the software services 70 correspond for example to an on-board predictive maintenance service, or to “health monitoring” services making it possible to detect critical thresholds in the operation of the aircraft systems.

[0078] When the avionics platform 20 forms an entertainment services 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, parameters of the flight (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 and for the group of software services 70 and a module 84 for launching the execution of software service(s) 70 of the group according to a set of distribution rule(s) and as a function of the calculated context.

[0080] In addition, the electronic management device 60 comprises a module 86 for stopping the execution of the lowest priority software service(s) 70 and / or a module 88 for determining the group of software services to be executed, prior to the acquisition of 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 comprises 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 optionally the stop module 86 and the determination module 88, are each produced in the form of software, or a software brick, executable by the processor 94. The memory 92 of the device management 60 is then able to store acquisition software, calculation software, and launch software, as well as optionally additionally stopping software and determination software. The processor 94 is then able to execute each of the software among the acquisition software, the calculation software and the launch software, as well as optionally additionally stopping software and determination software.

[0083] In a variant not shown, the acquisition module 80, the calculation module 82 and the launch module 84, as well as, as an optional addition, the stop module 86 and the determination module 88, are each produced 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 Specific Integrated Circuit).

[0084] When the electronic management device 60 is produced in the form of one or more software programs, that is to say in the form of a computer program, it is also capable of being recorded on a medium, not shown, readable by a computer. The computer-readable medium is, for example, a medium capable of storing electronic instructions and of being coupled to a bus of a computer system. By way of example, the readable medium is an optical disk, a magneto-optical disk, a ROM memory, a RAM memory, any type of non-volatile memory (for example 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 of [Fig.2], those skilled in the art will understand that the management device 60, also called orchestrator 60, uses for its implementation resources 40 of the electronic computing card 25 on which it is installed. In this example, the orchestrator 60 is then configured to acquire the contextual data for the group of software services 70, then to calculate the context from the acquired contextual data and for the group of software services 70, and finally to launch the execution of software service(s) 70 of the group according to the set of distribution rules and according to 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 group of software services to be executed, prior to the acquisition of contextual data for said group.

[0086] The acquisition module 80 is configured to acquire contextual data for a group of software services 70 to be executed on the avionics platform 20. The acquisition module 80 is for example configured to acquire said contextual data from a first database 96, also called a 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 failure resistance / s or non-failure resistance / s; and if the operating constraint of said service 70 is equal to failure resistance / s, a number of failure / 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-failure 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 this service is operational.

[0089] In addition, the contextual data includes more global data relating to a state of the electronic computing cards 25, with for example, for each computing card 25, a faulty state or a partially unusable state where appropriate. When a computing card 25 is in a normal operating state, this is not necessarily mentioned in the contextual data, given that the respective computing card 25 is then in its nominal state.

[0090] In addition, the contextual data comprises data relating to operational conditions specific to the aircraft 10, such as an indication of a current flight phase of the aircraft 10, and / or such as a state of each avionics system on board the aircraft 10, including, for each avionics system, a fault state where applicable. Here again, when the avionics system is in a normal operating state, this is not necessarily mentioned in the contextual data, given that 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 relative to each other, and the calculation module 82 is then configured to calculate a priority level respectively for each software service 70, this from the acquired contextual data.

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

[0094] In addition to this example, for a software service 70 with operating constraint equal to fault resistance / s, the priority level also depends on the number of failures / s to which the service 70 must be resistant. Advantageously, the priority level for a service 70 which must be resistant to N+1 failures is higher than the priority level for a service 70 which must be resistant to N failures / s, N being 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 as a function of a flight phase of the aircraft 10, included in the contextual data, and to then 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 (the aircraft 10 is parked), taxiing, takeoff, climb, cruise, descent, landing.

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

[0098] When the calculation module 82 is configured to calculate the priority level of each software service 70 as a function of both a flight phase of the aircraft 10 and a resistance to N failures / s, the priority level is calculated primarily as a function of the flight phase, then secondarily as a function of the resistance to N failures / s. According to this addition, the priority level of each software service 70 is typically calculated first according to different ranges of values ​​(for example from 100 to 100) depending on the flight phase forming the context; then within each range of values, the priority level is refined according to the required resistance to N failures / s.

[0099] In addition, when the contextual data also includes, for each software service 70 having an operating constraint equal to non-failure 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 as a function of said availability rate.

[0100] According to this supplement, the priority level is for example higher the higher the availability rate. In other words, the software services 70 have lower priority 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 of 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 set of distribution rules typically comprises one or more rules from the group consisting of:

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

[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 which must be resistant to N failure / s, N being an integer greater than or equal to 1.

[0106] Advantageously, the set of distribution rule(s) includes all the rules from the aforementioned group, i.e. includes the first, second and third rules.

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

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

[0109] Then, if there is no longer any resource 40 available to launch the execution of a new software service 70, then the stop module 86 is configured to stop the execution of the software service(s) 70 with the lowest priority, 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 sufficient resources 40 to be able to execute the new software service(s) 70, while respecting the hierarchy of priority levels between the new software services 70 to be executed and the software services 70 currently being executed. In other words, the need to launch the execution of a new software service 70 results in the stopping of the execution of a software service 70 currently being executed. execution only if the new software service 70 to be executed is of higher priority than the currently running software service 70.

[0110] As an optional addition, the determination module 88 is configured to determine the group of software services 70 to be executed, in particular to check for a new group of software services 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 addition, the determination module 88 is for example configured to receive a new group of software services 70, for example from a second database 98, also called a software service database; then to verify the received group of software services 70 according to a predefined set of verification rule(s), and finally to replace the current group of software services 70 with the new received group of software services 70 if it is considered correct following this verification; the current group of software services 70 being maintained otherwise, that is to say if the new received group is considered incorrect following this verification. The determination module 88 is typically configured to verify the new received group of software services 70 from a set of requirements.The set of requirements includes, for each context and each software service 70, an operating requirement, such as an availability rate greater than a predefined minimum rate (for example 95%) for the context considered.

[0112] The context typically depends on the state of the resources 40 and 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 in the form of a triplet including a number of resource / s 40 failed, the flight phase concerned, and an indication of possible avionics system failure(s).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 failed), that the aircraft 10 is in the 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 carry out the verification of the new received group of software services 70 from all the requirements and via statistical models, or even via Monte-Carlo type simulations.

[0114] The operation of the avionics platform 20, and in particular of the electronic device management electronics 60, or orchestrator 60, will now be explained, in particular with the aid of [Fig.4] representing a flowchart of the method, according to the invention, for 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 then receives the new group of software services 70, then verifies it according to the set of verification rule(s), and substitutes it for the current group of software services 70 if the new group is correct. Conversely, if the new group is incorrect with respect to the set of verification rule(s), then the determination module 88 discards it and retains the current group of software services 70.

[0117] Those 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, i.e. having been previously verified 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 following 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, firstly depending on whether the operating constraint for said service 70 is equal or not to failure resistance / s, then depending on the number N of failure / s to which said service 70 must be resistant when the operating constraint is equal to failure resistance / s, or depending on the availability rate required for said service 70 when the operating constraint is equal to non-failure resistance / 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 as a function furthermore of the flight phase of the aircraft 10.

[0122] At the end of the calculation step 120, the management device 60 launches, via its module launch 86 and during a following 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 depending on 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 launches, for example, the execution of the software services 70 of the current group as long as there are sufficient resources available, and by ordering these execution launches from the software services 70 with the highest priority to the software services 70 with the lowest priority, that is to say by starting with the software services 70 having the highest priority levels, then finishing with those having the lowest priority levels.

[0125] At the end of the launch step 130, if there is no longer any resource 40 available to launch the execution of a new software service 70, the management device 60 stops, during a following 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 software service(s) 70 with the lowest priority, until sufficient resources 40 are freed to be able to execute the new software service(s) 70 that must be executed.

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

[0127] At the end of the stopping step 140, the management device 60 returns to the determining step 100 whether a new group of software services 70 has been received, or to the acquisition step 110 to acquire new contextual data, or to the calculation step 120 to calculate the context again for the group of software services 70, for example in the event of a change of flight phase.

[0128] As an optional addition, 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 a function of the calculated subsequent context. The execution of the software service(s) 70 to be executed again 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 best distribute the limited resources 40 of the avionics platform 20 between the software services 70, this depending on the context calculated from the contextual data.

[0131] This contextual data includes in particular, for each software service, a maximum quantity of resources allocated to the service, an indication according to which the service must or must not be resistant to one or more failures, and where applicable the number of failures / s to which it must be resistant and / or a required availability rate; and the distribution of these limited resources 40 then favors the software services 70 which must be the most resistant to failures, and failing that which 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 resistance to failure / s and / or an availability rate for each software service 70 as a function of the flight phase, and then to optimize the distribution of resources also as a function of 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 method 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 to improve the operation of the avionics platform 20.

Claims

1.

2.

3. Claims Method for managing the execution of software services (70) of software application(s) on an avionics platform (20) intended to be carried 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 resistance to failure / s or non-resistance to failure / s; and if the operating constraint of said service (70) is equal to resistance to failure / s, a number of failure / 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); - launching (130) the execution of one or more software services (70) of the group according to a set of rule(s) for distributing the software services (70) on the platform (20) and according to the calculated context. Method according to claim 1, in which, during the calculation (120) of the context, a priority level is calculated respectively for each software service (70), the priority level being higher for a service (70) with operating constraint equal to failure resistance / s than for a service (70) with operating constraint equal to non-failure resistance / s; the priority level preferably depending on the number of failures / s to which the service (70) must be resistant; the priority level for a service (70) which must be resistant to N+1 failures being preferably still higher than the priority level for a service (70) which must be resistant to N failure / s, N being an integer greater than or equal to 1. The method of claim 2, wherein the set of dispatching rules comprises one or more rules from the group consisting of: a first rule according to which the execution of a service (70) of higher priority level is prioritized over that of a service (70) of lower priority level; a second rule according to in 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 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) which must be resistant to N failure / s, N being an integer greater than or equal to 1; the set of distribution rule / s preferably comprising all the rules from the aforementioned group.

4. Method according to any one of the preceding claims, in which the context of each software service (70) depends on a flight phase of the aircraft (10), and in which the method further comprises, 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 being then stopped and the execution of the software service(s) (70) to be executed again during the subsequent phase being launched.

5. A method according to claims 2 and 4, 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 when calculating the subsequent context; and the software service(s) (70) executed during the subsequent flight phase are then a function of the calculated subsequent priority levels.

6. Method according to any one of the preceding claims, in which the method further comprises a step of stopping (140) the execution of the software service(s) (70) with the lowest priority, if the quantity of resources (40) available is insufficient for launching the execution of a new software service (70).

7. A method according to claims 2 and 6, wherein the software service(s) (70) with the lowest priority are the software service(s) (70) having the lowest priority level(s).

8. Method according to any one of the preceding claims, in which the contextual data further comprises, for each software service (70): if the operating constraint of said service (70) is equal to non-failure resistance / s, an availability rate of said service (70); and the software services (70) are given less priority for their execution as their availability rate is low.

9. A method according to any preceding claim, wherein the method further comprises, before the acquisition step (110), a step of determining (100) the group of software services (70) to be executed, comprising receiving a new group of software services (70), verifying the received group of software services (70) according to a predefined set of verification rule(s), and if the received group of software services (70) is considered correct during this verification, then it forms the group of software services (70) to be executed; the group of software services (70) being unchanged otherwise.

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

11. Electronic device (60) for managing the execution of software services (70) of software application(s) on an avionics platform (20) intended to be carried on board an aircraft (10), the avionics platform (20) comprising 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 quantity of resources (40) used by said service (70); an operating constraint of said service (70) equal to resistance to failure / s or non-resistance to failure / s; and if the operating constraint of said service (70) is equal to resistance to failure / s, a number of failure / 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 launch module (84) configured to launch the execution of a; or more software services (70) of the group following a set of rule(s) for distributing the software services (70) on the platform (20) and according to the calculated context.

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

Images