Method and device for monitoring - with contention mitigation - avionics application(s) executed on a platform with multi-core processor, avionics electronic system and associated computer program

Abstract

Method and device for monitoring - with contention mitigation - avionics application(s) executed on a platform with multi-core processor, avionics electronic system and associated computer program This method for monitoring avionics software application(s) executed by an avionics platform, on board an aircraft, comprising a multi-core processor and hosting an operating system, is implemented by an electronic monitoring device and comprising, for each software application being executed, a monitoring phase comprising the following steps: - acquisition of a value of at least one characteristic quantity representative of a use of the platform, each acquired value of characteristic quantity being associated with the respective software application; - comparison of each acquired value with a respective threshold corresponding to the characteristic quantity;- stopping the execution of the respective software application if at least one acquired value is greater than the respective threshold; for each characteristic quantity, the respective threshold is determined for a reference contention application during the execution of said reference contention application and a reference sensitive application during a preliminary phase; the reference contention application being capable of generating an increase in an execution time of the reference sensitive application according to a predefined contention ratio, the contention ratio being equal to the execution time of the reference sensitive application when executed at the same time as the reference contention application divided by an execution time of the reference sensitive application when executed alone by the platform; the preliminary phase preceding the monitoring phase of each software application. Figure for the abstract: None;

Description

Title of the invention: Method and device for monitoring - with contention mitigation - avionics application(s) executed on a platform with multi-core processor, avionics electronic system and associated computer program

[0001] The present invention relates to a method for monitoring avionics software application(s) capable of being executed by an avionics platform, the avionics platform being intended to be carried on board an aircraft, comprising a multi-core processor and hosting an operating system, the method being implemented by an electronic monitoring device.

[0002] The invention also relates to a computer program comprising software instructions which, when executed by a computer, implement such a monitoring method.

[0003] The invention also relates to an avionics electronic system comprising a memory capable of storing at least one avionics software application; a platform capable of executing each avionics software application, the platform hosting an operating system; and such an electronic device for monitoring each avionics software application.

[0004] The invention relates to the field of operational safety of on-board avionics platforms, in particular the monitoring of software applications executed on such on-board avionics platforms.

[0005] In this field of operational safety, the notion of determinism is strong, and the use of multi-core processors brings a significant difficulty for the qualification of platforms. Indeed, the simultaneous execution of several software programs on the same processor is accompanied by risks of contention due to the sharing of common resources (bus, memory), without the behavior of the processor, in particular when it is multi-core, being able to be easily controlled.

[0006] The term "contention" designates any situation in which at least one activity carried out by at least one core of a multi-core processor experiences delays in its execution due to the temporal parallelism permitted by this multi-core processor.

[0007] The origin of contention is generally the use of common resources of the processor or the operating system, also called OS (from the English Operating System) resulting in waits generating these delays. The effect of a contention is then a delay on the execution of a software application hosted on a core.

[0008] A first example of contention is the bus (often called "interconnect") connecting the cores to each other which does not always allow simultaneous transactions. between cores or between cores and peripherals, such as some built-in cache memories or external memory.

[0009] Another example of contention is the use of common software modules of the OS installed on one of the cores and called by all of the cores, potentially simultaneously. Simultaneous calls to such common software modules cause arbitration and queuing of certain requests in order to serialize the software processing on the core where the common software module is installed.

[0010] Another example of contention is a momentary interruption of all cores on a particular event on one of the cores in order to manage a consistent status between all cores.

[0011] When the processor is also a processor purchased from a supplier, or COTS (Commercial Off-The-Shelf) processor, it is generally impossible to have access to the design details of the internal organs of such a multi-core processor, and it is therefore very difficult, if not impossible, to guarantee deterministic behavior of the processor.

[0012] For single-core processors, there are solutions for managing application time allocation overruns. With these solutions, even if there are several detection mechanisms, the platform then systematically kills an application when it exceeds its allocation.

[0013] However, for multi-core processors, with such solutions, the application(s) killed are then those exceeding their allocation, but not necessarily the one(s) causing the slowdown.

[0014] The aim of the invention is then to propose a method and a device for monitoring at least one avionics software application capable of being executed on an avionics platform, which makes it possible to monitor the at least one software application more effectively.

[0015] For this purpose, the invention relates to a method for monitoring avionics software application(s) capable of being executed by an avionics platform, the avionics platform being intended to be carried on board an aircraft, comprising a multi-core processor and hosting an operating system, the method being implemented by an electronic monitoring device and comprising, for each software application being executed, a monitoring phase comprising the following steps:

[0016] - acquisition of a value of at least one representative characteristic quantity of a use of the platform, each acquired value of characteristic quantity being associated with the respective software application;

[0017] - comparison of each acquired value with a respective threshold corresponding to the characteristic size;

[0018] - stopping the execution of the respective software application if at least one value acquired is greater than the respective threshold;

[0019] for each characteristic quantity, the respective threshold is determined for a reference contention application during the execution of said reference contention application and a reference sensitive application during a preliminary phase; the reference contention application being capable of generating an increase in an execution time of the reference sensitive application according to a predefined contention ratio, the contention ratio being equal to the execution time of the reference sensitive application when executed at the same time as the reference contention application divided by an execution time of the reference sensitive application when executed alone by the platform; the preliminary phase preceding the monitoring phase of each software application.

[0020] The monitoring method according to the invention then makes it possible to anticipate contention and to penalize the application(s) which are the cause of the slowdowns experienced by the other application(s).

[0021] In a context where several applications operate in parallel and where each application must operate within a given allotted time in order to ensure its deterministic execution, the monitoring method according to the invention therefore makes it possible, in the event of excessive contention, to act on the applications causing the slowdown to prevent all the applications from crashing entirely.

[0022] If the state-of-the-art solution were applied, any application exceeding its time budget, i.e. its allocation, would then be cut off. In this case, the origin of the problem would potentially not be cut off, because it would potentially not be the contentious application that would be stopped.

[0023] The monitoring method according to the invention then makes it possible to determine which application(s) exceed(s) an acceptable level of aggression by the other applications, this level of aggression corresponding to the predefined contention ratio, and each respective threshold, the exceeding of which triggers the stopping of the monitored application, is determined for the reference contention application which generates an increase in the execution time of the reference sensitive application according to said predefined contention ratio.

[0024] In other words, each respective threshold is determined from the reference contention application which characterizes a maximum admissible contention level, i.e. the predefined contention ratio, with respect to other software application(s) executed in parallel on the platform with the multi-core processor.

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

[0026] - each characteristic quantity and each associated respective threshold are each expressed per unit of time;

[0027] - the platform includes memory resources including a RAM, a first-level cache memory and a second-level cache memory; and each characteristic quantity is a quantity representative of the use of memory resources;

[0028] - each characteristic quantity is chosen from the group consisting of: a occupied bandwidth of a RAM access bus; a number of first-level cache misses; a number of second-level cache misses; a number of third-level cache misses; a number of page changes in DDR mode; and a combination of the above quantities;

[0029] - during the preliminary phase, the reference contention application is an ap plication formed by a contention loop executed several times, the contention loop comprising several write instructions in RAM, with for each instruction a predefined write address jump,

[0030] the number of executions of the contention loop preferably being equal to a size of a line of the second level cache memory divided by a size of the write address jump;

[0031] - during the preliminary phase, the reference sensitive application is an application formed of a sensitive loop executed several times, the sensitive loop comprising several read instructions in RAM, with for each instruction a predefined read address jump,

[0032] the number of executions of the sensitive loop being preferably equal to a size of a line of the second level cache memory divided by a size of the read address jump;

[0033] - during the acquisition step, each characteristic quantity value is acquired separately for each of the cores of the multi-core processor;

[0034] - the acquisition and comparison steps are repeated during each call to the operating system; and

[0035] - the operating system is an operating system operating in a synchronous with periodic system events, and the acquisition and comparison steps are repeated during each system event.

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

[0037] The invention also relates to an electronic device for monitoring avionics software application(s) capable of being executed by an avionics platform, the avionics platform being intended to be carried on board an aircraft, comprising a multi-core processor and hosting an operating system, the monitoring device comprising:

[0038] - an acquisition module configured to acquire, for each software application during execution, a value of at least one characteristic quantity representative of a use of the platform, each acquired value of characteristic quantity being associated with the respective software application;

[0039] - a comparison module configured to compare, for each application lo running software, each value acquired with a respective threshold corresponding to the characteristic quantity;

[0040] - a shutdown module configured to shutdown, for each software application in running, the execution of the respective software application if at least one acquired value is greater than the respective threshold; and

[0041] for each characteristic quantity, the respective threshold is determined for a reference contention application during the execution of said reference contention application and a reference sensitive application during a preliminary phase; the reference contention application being capable of generating an increase in an execution time of the reference sensitive application according to a predefined contention ratio, the contention ratio being equal to the execution time of the reference sensitive application when executed at the same time as the reference contention application divided by an execution time of the reference sensitive application when executed alone by the platform; the preliminary phase preceding the monitoring of each software application.

[0042] The invention also relates to an avionics electronic system comprising:

[0043] - a memory capable of storing at least one avionics software application;

[0044] - a platform capable of executing each avionics software application, the platform hosting an operating system; and

[0045] - an electronic device for monitoring each software application avionics, the electronic monitoring device being as defined above.

[0046] 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:

[0047] [Fig-1] [Fig.l] is a schematic representation of an electronic system avionics according to the invention, comprising a memory capable of storing at least one avionics software application; a platform capable of executing each avionics software application, the platform comprising resources and hosting an operating system; and an electronic device for monitoring each avionics software application;

[0048] [Fig.2] [Fig.2] is a schematic representation illustrating the acquisition of successive values ​​of several characteristic quantities representative of a use of the platform, this for a respective software application, the comparison of the successive values ​​with a respective threshold for each characteristic quantity, and the stopping of the execution of the monitored software application if at least one acquired value is greater than the respective threshold for the corresponding characteristic quantity; and

[0049] [Fig.3] [Fig.3] is a flowchart of a method, according to the invention, of monitoring of avionics software application(s) capable of being executed on the platform, the method being implemented by the monitoring device of [Fig. 1].

[0050] In the remainder of the description, the expressions “substantially equal to” and “of the order of” each define a relationship of equality of plus or minus 20%, preferably of plus or minus 10%, more preferably of plus or minus 5%.

[0051] In [Fig.l], an avionics electronic system 10, intended to be on board an aircraft, comprises a memory 12 capable of storing at least one avionics software application 14; a platform 16 capable of executing each avionics software application 14, the platform 16 comprising resources 17 and hosting an operating system 18.

[0052] The avionics electronic system 10 further comprises, according to the invention, an electronic device 20 for monitoring avionics software application(s) 14.

[0053] The aircraft is preferably an airplane. Alternatively, the aircraft is a helicopter, or a drone piloted remotely by a pilot.

[0054] In the example of [Fig.l], the memory 12 is capable of storing three distinct avionics software applications 14, and the electronic monitoring device 20 is then configured to monitor at least one avionics software application 14, and preferably each of these avionics software applications 14.

[0055] Each avionics software application 14 is intended to be executed by the platform 16 and then designed to issue one or more calls to the operating system 18 hosted by the platform 16 and is also configured to use resources 17 of the platform 16.

[0056] Each avionics software application 14 is also called an avionics function. The avionics software applications 14 perform different functions for the accomplishment of a flight, and are for example installed on different platforms 16 and use the resources 17 of said platforms 16.

[0057] Since such functions are critical, such as for example the braking system or the flight management system, each avionics software application 14 is preferably monitored regularly by the electronic monitoring device 20, for substantially the entire duration of execution of the avionics software application 14 by the platform 16.

[0058] The platform 16 is intended to be carried on board the aircraft. The platform 16 is, for example, an information processing unit formed of at least one multi-core processor adapted to execute the avionics software applications 14 and one or more memories associated with the at least one multi-core processor.

[0059] The resources 17 of the platform 16 are physical or logical elements suitable for being made available to the avionics software application(s) 14. The resources 17 are, for example, divided into the following categories:

[0060] - data processing type resources. Such resources are, for example, the computing power of a processor or the storage capacity of a memory.

[0061] - input and output type resources.

[0062] - resources specific to the avionics network. Such resources are, for example example, communication routers in an ARINC664 network, particularly ARINC664 Part 3 or ARINC664 Part 7.

[0063] - graphic type resources, i.e. resources allowing a display. A screen is an example of such resources.

[0064] - mass memory type resources.

[0065] The operating system 18 is, for example, an operating system compliant with the ARINC 653 standard, or a POSIX operating system, or even a hypervisor, or even middleware.

[0066] Those skilled in the art will then understand that the operating system 18 is understood in the broad sense and is, more generally, a set of at least one basic software program, designed to offer services of different types to each application 14.

[0067] A service is therefore a function of the basic software usable by the application(s) 14 and reachable by a call, also called a call to a service (of the OS) or system call. An example of basic software is an ARINC 653 or POSIX OS which provides such services. In the context of the invention, those skilled in the art will understand that it is the notion of a call to a service which is important, and not the service as such, offered by the basic software.

[0068] The services offered by the operating system 18 are known per se, and are for example services for acquiring input(s) / output(s), managing processes, managing communication protocol(s), etc. The types of service are then the acquisition of input(s) / output(s), managing processes, managing communication protocol(s) and managing a timer, in particular its triggering.

[0069] Those skilled in the art will note that the ARINC 653 and POSIX standards each include, for example, a list of services generally used in the aeronautical field. Those skilled in the art will observe, however, that the invention relates more generally to any basic software adapted to an avionics software application 14, in the to the extent that the service(s) offered by this basic software, as well as the call(s) to the service(s) issued by each avionics software application 14, are identifiable.

[0070] The electronic monitoring device 20 is configured to monitor at least one avionics software application 14, and preferably each avionics software application 14, capable of being executed on the platform 16.

[0071] To carry out this monitoring, the electronic monitoring device 20 comprises a module 22 for acquiring, for each software application 14 currently being executed, also denoted Aj, a value of at least one characteristic quantity Vi representative of a use of the platform 16; a module 24 for comparing, for each software application 14, Aj currently being executed, each acquired value with a respective threshold Si corresponding to the characteristic quantity Vi; and a module 26 for stopping, for each software application 14, Aj monitored, the execution of the respective software application 14, Aj if at least one acquired value is greater than the respective threshold Si.

[0072] For the notation Vi associated with a respective characteristic quantity, also called respective characteristic variable, i is an index belonging to a set I containing all the indices of characteristic quantities, or characteristic variables, taken into account. Those skilled in the art will observe that the index i is likely to be a combined index, such as the index 1&2 in the example of [Fig.2], meaning in this example that the combined characteristic quantity V1&2 corresponding to a combination, such as a linear combination, of characteristic quantities VI, V2 is taken into account. In this example of [Fig.2], the combined characteristic quantity V1&2 is taken into account in addition to the respective characteristic quantities VI, V2.

[0073] Those skilled in the art will further understand that when a combined characteristic quantity is taken into account, then a combined threshold is provided and associated with this combined characteristic quantity, the combined threshold being typically distinct from the respective thresholds associated with the respective characteristic quantities involved in said combined characteristic quantity. In other words, in the example of [Fig.2], the combined characteristic quantity V1&2 is compared to a combined threshold S1&2, typically distinct from the respective thresholds S1, S2, not shown, associated with the respective characteristic quantities V1, V2.

[0074] For the notation Aj associated with a respective monitored avionics software application 14, j is an index belonging to a set J containing all the indices of the monitored avionics software applications 14.

[0075] In the example of [Fig.l], the monitoring device 20 is, for example, distinct from the platform 16, and comprises an information processing unit 30 formed for example by a processor 32 associated with a memory 34.

[0076] As a variant, for which the monitoring device 20 is shown in hatched form. in [Fig.l], the monitoring device 20 is able to be executed directly by the platform 16 and then to use its resources 17. This variant is a preferred embodiment, and the monitoring device 20 is then preferably further hosted within a specific memory partition of the platform 16, this specific partition itself being protected against cyber-attacks, via for example one or more access controls and / or integrity protection. According to this variant where the monitoring device 20 is able to be executed directly by the platform 16, the monitoring device 20 is for example included in the operating system 18.

[0077] In the example of [Fig.l], whether the monitoring device 20 is separate from the platform 16, or hosted and executed by the platform 16, the acquisition module 22, the comparison module 24 and the stop module 26 are each produced in the form of software, or a software brick, executable by a processor, such as the processor 32 when the monitoring device 20 is separate from the platform 16.The memory 34 of the monitoring device 20 is then capable of storing software, for each software application Aj, of a value of at least one characteristic quantity Vi representative of a use of the platform 16; software for comparing, for each software application Aj currently being executed, each acquired value with a respective threshold Si corresponding to the characteristic quantity Vi; and software for stopping, for each software application Aj monitored, the execution of the respective software application Aj if at least one acquired value is greater than the respective threshold Si.

[0078] In a variant not shown, the acquisition module 22, the comparison module 24 and the stop module 26 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).

[0079] When the monitoring device 20 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 adapted to memorize electronic instructions and capable of being coupled to a bus of a computer system. By way of example, the readable medium is a floppy disk or flexible disk, (from the English name Floppy disk), an optical disk, a CD-ROM, 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.

[0080] The acquisition module 22 is configured to acquire, for each application lo software 14, Aj currently running, a value of at least one characteristic quantity Vi representative of the use of the platform 16, each acquired value of characteristic quantity Vi being associated with the respective software application 14, Aj.

[0081] The acquisition module 22 is preferably configured to acquire each characteristic quantity value Vi separately for each of the cores of the multi-core processor.

[0082] Each characteristic quantity Vi is typically a measurable performance element, also called a performance measurement register and noted PMR (from the English Performance Measurement Register).

[0083] The platform 16 comprises, within its memory resources, a random access memory, also called RAM (from the English Random Access Memory); a first level cache memory, also called L1 cache; and a second level cache memory, also called L2 cache; each being connected to the multi-core processor of the platform.

[0084] Each characteristic quantity Vi is advantageously a quantity representative of the use of memory resources, in particular representative of the use of RAM, or of the first level cache memory, or even of the second level cache memory.

[0085] Each characteristic quantity Vi is then for example chosen from the group consisting of: an occupied bandwidth of a RAM access bus; a number of first level cache faults (L1 cache miss); a number of second level cache faults (L2 cache miss); a number of third level cache faults (L3 cache miss); a number of page changes in DDR mode; and a combination of the aforementioned quantities.

[0086] As an advantageous addition, each characteristic quantity Vi and each respective associated threshold Si are each expressed per unit of time. Each characteristic quantity Vi is then, for example, chosen from the group consisting of: an occupied bandwidth of a RAM access bus, expressed per unit of time; a number of first-level cache misses per unit of time (L1 cache miss); a number of second-level cache misses per unit of time (L2 cache miss); a number of third-level cache misses per unit of time (L3 cache miss); a number of page changes in DDR mode per unit of time; and a combination of the aforementioned quantities. Each respective associated threshold Si is then expressed in an analogous manner.

[0087] According to this advantageous addition, the acquisition module 22 is configured to acquire each characteristic quantity value Vi by taking into account an acquisition duration, in order to bring back, i.e. report, each acquired value to a unit of time. In other words, the acquisition module 22 is configured to acquire each value of characteristic quantity Vi during an acquisition duration, also acquiring the value of said acquisition duration, in order to then divide the acquired value of the characteristic quantity Vi by the value of the acquisition duration, to express the characteristic quantity Vi acquired per unit of time.

[0088] The comparison module 24 is configured to compare, for each software application 14, Aj currently running, each acquired value with a respective threshold Si corresponding to the characteristic quantity Vi.

[0089] According to the invention, for each characteristic quantity Vi, the respective threshold Si is determined for a reference contention application, this during the execution of both said reference contention application and a reference sensitive application, this determination being carried out during a preliminary phase 100 preceding the monitoring of each software application 14, Aj.

[0090] The contention measurement is determined by a time measurement between an application executed alone and the same application, using the same usage context, executed in parallel with at least one other application. From there, an application is typically characterized according to two criteria: sensitivity and aggressiveness.

[0091] Sensitivity corresponds to the influence that other applications can have on the measured application. It is proportional to an increase in execution time, and therefore to contention.

[0092] Aggressiveness corresponds to the ability to slow down embedded applications. It is not influenced by other applications in the contention sense of the term, but can move depending on the usage context of each application.

[0093] During the preliminary phase 100, a first application making it possible to characterize the level of contention admissible by the other applications is first determined, the first application also being called a reference sensitive application. A second application, also called a reference contention application, is then determined in order to characterize an admissible level of contention, the level of contention being predefined.

[0094] The contention level is typically expressed in the form of a contention ratio representing an extension of the execution time. The contention ratio is for example of the order of 130%, i.e. of the order of 1.3, representing an extension of the order of 30% compared to a nominal execution time, without contention.

[0095] The reference contention application is then capable of generating an increase in the execution time of the reference sensitive application according to the predefined contention ratio, the contention ratio being equal to the execution time of the reference sensitive application when executed at the same time as the reference sensitive application. reference contention divided by a reference sensitive application execution time when executed alone by platform 16.

[0096] In other words, if the predefined contention ratio is equal to 1.30, then the execution time of the sensitive application used in parallel with the reference contention application is 30% greater than that of this same sensitive application executed in isolation.

[0097] The reference sensitive application aims to be as non-aggressive as possible. The reference sensitive application is, for example, an application formed by a sensitive loop executed several times, the sensitive loop comprising several RAM read instructions, with for each instruction a predefined read address jump.

[0098] The number of executions of the sensitive loop is advantageously equal to a size of a line of the second level cache memory divided by a size of the read address jump. This makes it possible to generate a cache line eviction by alternatively executing the reference sensitive application, such as an L2 cache line eviction.

[0099] As an example, the sensitive loop comprises four read instructions in RAM, such as LO AD type instructions, with for each instruction a predefined read address jump, such as an address jump of 1 word. If the cache line is 16 words, then the sensitive loop is executed sixteen times (16 divided by 1). As known per se, the size of the words depends on the platform 16, in particular the processor, the memories and the data bus. Conventionally, the words are 8-bit, 16-bit, 32-bit or even 64-bit words. Here, the words are for example 32-bit words.

[0100] The reference contention application aims, on the contrary, to manipulate the most aggressive elements possible, but which are sequenced so as to limit the contention to the predefined one. The reference contention application is for example an application formed by a contention loop executed several times, the contention loop comprising several write instructions in RAM, with for each instruction a predefined write address jump.

[0101] The number of executions of the contention loop preferably being equal to a size of a line of the second level cache memory divided by a size of the write address jump. This makes it possible to generate a cache line eviction by executing the reference contention application, such as an L2 cache line eviction.

[0102] For example, the contention loop comprises six RAM write instructions, such as STORE type instructions, with for each instruction a predefined read address jump, such as a 4-word address jump. If the line of cache is 16 words, then the contention loop is executed four times (16 divided by 4). As mentioned earlier, words are for example 32-bit words.

[0103] During the preliminary phase 100, the reference contention application is then characterized to verify the contention level that it generates, in particular that the contention level generated corresponds substantially to the predefined contention ratio.

[0104] During the preliminary phase 100, the reference contention application is according to the invention also used to determine the respective threshold for each characteristic quantity Vi. In other words, the reference contention application makes it possible to determine an admissible limit for each of the characteristic quantities Vi observed, i.e. taken into account, during the subsequent monitoring of avionics software application(s) 14, Aj.

[0105] When advantageously each respective threshold Si is expressed per unit of time, the determination of each respective threshold Si from the reference contention application is then carried out by taking into account an observation duration during which the characteristic quantity Vi is observed for the reference contention application in order to determine the associated respective threshold. Each respective threshold Si is then determined by dividing, by the observation duration, the limit value of the characteristic quantity Vi resulting from this observation, in order to be thus expressed per unit of time.

[0106] Each respective threshold Si is preferably identical from one core to another of the multi-core processor.

[0107] Alternatively, each respective threshold Si is specific to a core of the multi-core processor, and is then potentially distinct from one core to another of the multi-core processor. According to this variant, a predefined contention level is provided separately for each of the cores, and a reference contention application is then also determined separately for each of the cores. In other words, according to this variant, the number of predefined contention levels, and consequently the number of predefined contention ratios, as well as the number of reference contention applications, are then each equal to the number of cores of the multi-core processor.

[0108] According to this variant, in other words, the choice of the predefined contention level, the determination of the reference contention application, and finally the determination of the respective threshold Si for each of the characteristic quantities Vi is then specific to each core of the multi-core processor. This choice and these determinations, specific to each core of the multi-core processor, are then carried out separately for each core of the multi-core processor. This choice and these determinations are typically carried out by applying, for each respective core of the processor multi-core, the previously described method of determining a respective threshold If valid for all cores. The determination method defined above is then implemented for one core after another of the multi-core processor.

[0109] Those skilled in the art will then understand that if one of the monitored avionics software applications 14, Aj exceeds one of these admissible limits during said monitoring, then this means that the application in question generates greater contention than the reference contentionating application, i.e. a contention of a level higher than the predefined contention level, chosen beforehand, and therefore that the application in question must be stopped, or killed (from the English kiiï), so as not to cause too much disruption to the other avionics software applications executed in parallel by the multi-core processor.

[0110] The stop module 26 is then, for each software application 14 currently being executed, configured to stop the execution of the respective software application 14 if at least one acquired value is greater than the respective threshold Si. In other words, the stop module 26 is configured to kill, i.e. definitively interrupt, the execution of the respective software application 14 if at least one acquired value of characteristic quantity is, for said software application 14, greater than the respective threshold Si associated with said characteristic quantity.

[0111] In the example of [Fig.2], illustrating the monitoring of the respective software application Aj, the curve corresponding to the characteristic quantity V1&2, which is moreover a combined characteristic quantity as explained above, crosses at a time instant F the threshold S1&2 associated with said combined characteristic quantity V1&2. Due to this threshold being exceeded, the software application Aj is then stopped, i.e. killed, at the time instant F, as represented by the grayed and hatched area, as well as the crossed-out notation Aj, after the time instant F.

[0112] The operation of the electronic monitoring device 20 according to the invention will now be described with reference to [Fig. 3] representing a flowchart of the method, according to the invention, for monitoring avionics software application(s) 14 executed by the avionics platform 16 comprising the multi-core processor, the method being implemented by the electronic monitoring device 20.

[0113] The monitoring method firstly comprises a preliminary phase 100, described above, followed by a monitoring phase 200. Each characteristic quantity Vi or each threshold Si is preferably defined with respect to time, i.e. expressed per unit of time. The acquisition of each characteristic quantity Vi is then carried out by taking into account an acquisition duration, in order to reduce, i.e. relate, each acquired value to a unit of time. Similarly, the comparison thresholds are determined with respect to the acquisition time, i.e. taking into account an acquisition duration, in order to reduce, i.e. relate, each threshold Si to a unit of time.

[0114] The preliminary phase 100 makes it possible to determine the set of characteristic quantity(ies) Vi, i.e. each characteristic variable Vi for any index i belonging to the set I; as well as the set of threshold(s) Si, each of a corresponding characteristic quantity, i.e. each threshold Si for any index i belonging to the set I, as represented in [Fig.3]. At the end of this preliminary phase 100, each threshold Si is for example defined proportionally to a nominal value of the associated characteristic quantity Vi. In other words, each threshold Si is then equal to said nominal value of the characteristic quantity Vi multiplied by a multiple ai, the multiple ai being a real number strictly greater than 1.

[0115] Then, the monitoring phase 200 is carried out for each of the monitored avionics software applications 14, that is to say for each software application Aj currently running, and for any index j belonging to the set J containing the indices of the monitored avionics software applications 14.

[0116] The monitoring phase 200 comprises an initial acquisition step 210 during which the monitoring device 20 acquires, via its acquisition module 22, the value of at least one characteristic quantity Vi representative of the use of the platform 16. The acquisition module 22 then typically acquires one or more performance measurement register values, also noted PMRi.

[0117] Each characteristic quantity Vi whose value is acquired by the acquisition module 22 is for example the occupied bandwidth of the access bus to the RAM, the number of first level cache faults, the number of second level cache faults, or the number of page changes in DDR mode; or even a combination of these quantities.

[0118] At the end of the acquisition step 210, the monitoring phase 200 comprises a comparison step 220 during which the monitoring device 20 compares, via its comparison module 24, each acquired value of characteristic quantity Vi, preferably reduced to the unit of time, with a respective threshold Si, also preferably reduced to the unit of time, corresponding to said characteristic quantity Vi.

[0119] During the comparison step 220, the comparison module 24 determines in particular whether the acquired value of the characteristic quantity Vi is greater than the respective threshold Si, and if necessary proceeds to the following stopping step 230.

[0120] Otherwise, if the acquired value of the characteristic quantity Vi is less than or equal to the respective threshold Si, then the monitoring device 20 returns to the initial acquisition step 210 to carry out a new acquisition of value(s) of characteristic quantity(ies) Vi.

[0121] If the comparison step 220 results in the detection of at least one crossing of respective threshold If, then the monitoring phase 200 comprises the stopping step 230 following the comparison step 220.

[0122] During the stopping step 230, the monitoring device 20 stops, via its stopping module 26, the execution of the or each respective software application for which at least one acquired value of characteristic quantity Vi is greater than the respective threshold Si corresponding to said characteristic quantity Vi.

[0123] This stopping step 230 therefore makes it possible to stop, that is to say to kill or even to definitively interrupt, the or each software application generating a contention greater than the predefined contention level, characterized by the reference contentionating application having served to determine the set of characteristic quantity(ies) Vi and the set of threshold(s) Si.

[0124] At the end of the stopping step 230, the monitoring device 20 returns to the initial acquisition step 210 to carry out a new acquisition of value(s) of characteristic quantity(ies) Vi for each software application Vj still being executed.

[0125] Those skilled in the art will then understand that, during the monitoring phase 200, the acquisition steps 210, comparison 220, and where appropriate stopping 230, are carried out, preferably in parallel, for each software application Aj.

[0126] The monitoring phase 200 is for example carried out, that is to say implemented, during each call of an application to the operating system 18. In other words, the acquisition 210 and comparison 220 steps are then repeated during each call to the operating system 18.

[0127] In addition or as a variant, the operating system 18 is an operating system operating synchronously with periodic system events, and the monitoring phase 200 is carried out during each system event. In other words, the acquisition 210 and comparison 220 steps are then repeated during each system event.

[0128] It is thus understood that the monitoring device 20 and the monitoring method according to the invention make it possible to monitor more effectively the at least one avionics software application 14.

[0129] In particular, the monitoring device 20 and the monitoring method according to the invention make it possible to anticipate contention and to sanction the application(s) which are the cause of the slowdowns experienced by the other applications, rather than basically sanctioning the avionics software application(s) 14 which exceed their time budget, i.e. their allocation, when they are not necessarily the cause of the contention.

Claims

Claims

1. Method for monitoring avionics software application(s) (14, Aj) capable of being executed by an avionics platform (16), the avionics platform (16) being intended to be on board an aircraft, comprising a multi-core processor and hosting an operating system (18), the method being implemented by an electronic monitoring device (20) and comprising, for each software application (14, Aj) being executed, a monitoring phase (200) comprising the following steps: - acquisition (210) of a value of at least one characteristic quantity (Vi) representative of a use of the platform (16), each acquired value of characteristic quantity (Vi) being associated with the respective software application (14, Aj); - comparison of each acquired value with a respective threshold (Si) corresponding to the characteristic quantity (Vi);- stopping the execution of the respective software application (14, Aj) if at least one acquired value is greater than the respective threshold (Si); characterized in that, for each characteristic quantity (Vi), the respective threshold (Si) is determined for a reference contention application during the execution of said reference contention application and a reference sensitive application during a preliminary phase (100); the reference contention application being capable of generating an increase in an execution time of the reference sensitive application according to a predefined contention ratio, the contention ratio being equal to the execution time of the reference sensitive application when executed at the same time as the reference contention application divided by an execution time of the reference sensitive application when executed alone by the platform (16);the preliminary phase (100) preceding the monitoring phase (200) of each software application (14, Aj).;

2. Method according to claim 1, in which each characteristic quantity (Vi) and each respective threshold (Si) associated are each expressed per unit of time.

3. A method according to claim 1 or 2, wherein the platform (16) comprises memory resources including a random access memory, a first level cache memory and a second level cache memory; and each characteristic quantity (Vi) is a quantity representing indicative of memory resource usage.

4. The method of claim 3, wherein each characteristic quantity (Vi) is selected from the group consisting of: an occupied bandwidth of a RAM access bus; a number of first-level cache misses; a number of second-level cache misses; a number of third-level cache misses; a number of page changes in DDR mode; and a combination of the aforementioned quantities.

5. Method according to claim 3 or 4, in which during the preliminary phase (100), the reference contention application is an application formed of a contention loop executed several times, the contention loop comprising several write instructions in RAM, with for each instruction a predefined write address jump; the number of executions of the contention loop being preferably equal to a size of a line of the second level cache memory divided by a size of the write address jump.

6. Method according to any one of claims 3 to 5, in which during the preliminary phase (100), the reference sensitive application is an application formed of a sensitive loop executed several times, the sensitive loop comprising several read instructions in RAM, with for each instruction a predefined read address jump; the number of executions of the sensitive loop being preferably equal to a size of a line of the second level cache memory divided by a size of the read address jump.

7. Method according to any one of the preceding claims, wherein during the acquisition step (210), each characteristic quantity value (Vi) is acquired separately for each of the cores of the multi-core processor.

8. Method according to any one of the preceding claims, in which the steps of acquisition (210) and comparison (220) are repeated during each call to the operating system (18).

9. A method according to any preceding claim, wherein the operating system (18) is an operating system operating synchronously with periodic system events, and the acquisition (210) and comparison (220) steps are repeated upon each system event.

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 (20) for monitoring avionics software application(s) (14, Aj) capable of being executed by an avionics platform (16), the avionics platform (16) being intended to be on board an aircraft, comprising a multi-core processor and hosting an operating system (18), the monitoring device (20) comprising: - an acquisition module (22) configured to acquire, for each software application (14, Aj) currently being executed, a value of at least one characteristic quantity (Vi) representative of a use of the platform (16), each acquired value of characteristic quantity (Vi) being associated with the respective software application (14, Aj); - a comparison module (24) configured to compare, for each software application (14, Aj) currently being executed, each acquired value with a respective threshold (Si) corresponding to the characteristic quantity (Vi);- a stop module (26) configured to stop, for each software application (14, Aj) currently being executed, the execution of the respective software application (14, Aj) if at least one acquired value is greater than the respective threshold (Si); characterized in that, for each characteristic quantity (Vi), the respective threshold (Si) is determined for a reference contention application during the execution of said reference contention application and a reference sensitive application during a preliminary phase (100);the reference contention application being capable of generating an increase in an execution time of the reference sensitive application according to a predefined contention ratio, the contention ratio being equal to the execution time of the reference sensitive application when executed at the same time as the reference contention application divided by an execution time of the reference sensitive application when executed alone by the platform (16); the preliminary phase (100) preceding the monitoring (200) of each software application (14, Aj).;

12. Avionics electronic system (10) comprising: - a memory (12) capable of storing at least one avionics software application (14, Aj); - a platform (16) capable of executing each avionics software application (14, Aj), the platform (16) hosting an operating system (18); and - an electronic device (20) for monitoring each avionics software application (14, Aj), the electronic monitoring device (20) being according to the preceding claim.

Images