Patent Application
20200301754
The present invention relates to a method for implementing a partitioning during the execution of software applications on a platform comprising a multicore processor having several separate cores, the implementation method being carried out by an electronic implementing device.
The invention also relates to a non-transitory computer-readable medium including a computer program including software instructions which, when executed by a computer, implement such a method.
The invention also relates to an electronic device for implementing a partitioning during the execution of software applications on a platform comprising a multicore processor having several separate cores.
The invention also relates to an electronic system comprising a memory able to store software applications; a platform able to execute each software application, the platform comprising a multicore processor having several separate cores; and such an electronic device for implementing a partitioning during the execution of software applications on the platform.
The invention relates to the field of the qualification of embedded platforms including one or several multicore processors, in particular in the avionics field according to standard DO297.
Using multicore processors creates substantial difficulty for the qualification of the platforms. Indeed, running several software applications at the same time on one multi-core processor creates risks of contention due to the sharing of common resources (bus, memory) with different cores, the behavior of the multi-core processor not being able to be controlled explicitly and predictively.
The term “contention” refers to any situation in which at least one activity carried out by at least one core of a multicore processor experiences delays in its performance due to the temporal parallelism allowed by said multicore processor.
The origin of the contentions is generally the use of shared resources of the processor or the operating system, also called OS, resulting in waits causing these delays. A contention then causes a delay in the execution of a software application hosted in a core.
A first example of contention is the internal bus (often called “interconnect”) connecting the cores to one another, as well as the cores to the peripherals, which does not always allow independent simultaneous transactions between cores or between the cores and the peripherals, such as certain integrated cache memories or the external memory.
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 at the same time. Simultaneous calls for such shared software modules lead to arbitration and the placement of some requests in standby in order to serialize the software processing operations on the core where the shared software module is installed.
Another example of contention is a temporary interruption of all of the cores on a particular event on one of the cores in order to manage a coherent status among all of the cores.
When the processor is further a processor purchased from a supplier, or a COTS (Commercial Off-The-Shelf) processor, it is generally impossible to access the design details of the internal members of such a multicore processor, and it is therefore very difficult, if not impossible, to guarantee a deterministic behavior of the processor.
According to a first known type of software architecture for a platform with a multi-core processor, also called SMP (Symmetrical Multi-Processing) architecture, a single operating system decides at each moment which software processing is executed on which core.
According to a second known type of software architecture for a platform with a multi-core processor, also called AMP (Asymmetrical Multi-Processing) architecture, each core sequences the execution of a set of software applications, independently from one core to the next, with one operating system per core.
However, such architectures are not intrinsically deterministic enough to obtain the qualification of platforms with multicore processors, in particular in the avionics field according to standard DO297.
The aim of the invention is then to propose a method and a device for implementing a partitioning during the execution of software applications on a platform with multicore processors, which make it possible to control the impact of contention(s) during the execution of said software applications and then to facilitate the qualification of the platform.
To that end, the invention relates to a method for implementing a partitioning during the execution of software applications on a platform comprising a multicore processor having several separate cores, the implementation method being carried out by an electronic implementing device and comprising the following step:
the step of synchronous multicore switching including one or more actions among a first group of actions consisting of:
With the implementation method according to the invention, the cores are synchronized and the running of the software applications is segmented into time clusters, the multicore synchronous switching making it possible to perform a robust partitioning between two successive time clusters, in particular within the meaning of standard DO297.
According to other advantageous aspects of the invention, the implementation method comprises one or more of the following features, considered alone or according to all technically possible combinations:
The invention also relates to a non-transitory computer-readable medium including a computer program including software instructions which, when executed by a computer, carry out an implementation method as defined above.
The invention also relates to an electronic device for implementing a partitioning during the execution of software applications on a platform comprising a multicore processor having several separate cores, the device comprising:
the switching module being configured to perform one or several actions among a first group of actions consisting of:
The invention also relates to an electronic system comprising:
These features and advantages of the invention will appear more clearly upon reading the following description, provided solely as a non-limiting example, and done in reference to the appended drawings, in which:
In
The electronic system 10 further comprises, according to the invention, an electronic device 24 for implementing a partitioning during the running of software applications 14 on the platform 16.
In
The aircraft is preferably an airplane. Alternatively, the aircraft is a helicopter, or a drone piloted remotely by a pilot.
In the example of
Each software application 14 is intended to be executed by the platform 16 and then designed to emit one or several calls to the operating system 20 hosted by the platform 16 and is also configured to use resources 18 of the platform 16.
When the electronic system 10 is an electronic avionics system embedded in the aircraft, each software application 14 is also called avionics function. The software applications 14 for example perform different functions to carry out a flight, and are for example installed on different platforms 16 and use the resources 18 of said platforms 16.
Such functions being critical, for example the braking system or the flight management system, the running of each software application 14 must be separated robustly from the running of the other software applications 14, throughout their entire running duration.
The platform 16 is in particular intended to be embedded in the aircraft. The platform 16 is for example an information processing unit made up of one or several memories associated with one or several processors.
The invention is applicable to different types of software architectures, in particular to a so-called symmetrical multi-processing (SMP) architecture, or to an asymmetrical multiprocessing (AMP) architecture.
An SMP architecture more specifically refers to a software architecture where the operating system 20 decides at each moment which process is run on which processor core.
In the case of the SMP architecture, the platform 16 for example comprises a single operating system 20, and a single partition is active at a given moment in time. For the SMP architecture, the platform 16 then hosts a single operating system 20 for all of the cores.
In the case of the SMP architecture, the installation of software applications 14 is for example done in parallel on several cores.
An AMP architecture more specifically refers to a software architecture where each core sequences a set of software applications independently of the other cores.
In the case of the AMP architecture, the platform 16 for example comprises a plurality of operating systems 20, while hosting an operating system 20 for each core, then making it possible to activate different partitions at a given moment in time.
In the case of the AMP architecture, the installation of software applications 14 is for example done sequentially on a single core independently of the other cores.
The resources 18 of the platform 16 are physical or logic elements capable of being provided to the software application(s) 14.
The resources 18 are for example divided into the following categories:
In the example of
In the example of
The operating system 20 is for example an operating system according to the ARINC 653 standard, or a POSIX operating system, or a hypervisor, or middleware.
One skilled in the art will then understand that the operating system 20 is to be understood broadly, and is more generally a set of at least one system software program, designed to offer services of different types to each application 14.
The electronic implementing device 24 is configured to implement the desired partitioning during the running of the software applications 14 on the platform 16 comprising at least one multicore processor 26.
The electronic implementing device 24 comprises a first switching module 30 configured to switch between the running of a current set of software application(s) 14 on a plurality of cores of the corresponding processor 26 and the running of a subsequent set of software application(s) 14 on the plurality of cores of the corresponding processor 26, in a synchronous manner on said plurality of cores.
As an optional addition, the electronic implementing device 24 comprises a second switching module 32 configured to switch between the running of a first software application and the running of a second software application on a same core, during the running of a given set of software application(s) 14.
As shown in crosshatched form in
In a variant, also shown in
In the example of
In a variant that is not shown, the first switching module 30, and as an optional addition the second switching module 32, are each made in the form of a programmable logic component, such as an FPGA (Field Programmable Gate Array), or in the form of a dedicated integrated circuit, such as an ASIC (Application-Specific Integrated Circuit).
When the implementing device 24 is made in the form of one or several software programs, i.e., in the form of a computer program, it is further able to be stored on a medium, not shown, readable by computer. The computer-readable medium is for example a medium suitable for storing electronic instructions and able to be coupled with a bus of a computer system. As an example, the readable medium is a floppy disk, an optical disc, a CD-ROM, a magnetic-optical disc, 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 including software instructions is then stored on the readable medium.
The first switching module 30 is then configured to perform one or several multicore synchronous switches 40 on multiple cores of a corresponding multicore processor 26.
To perform a multicore synchronous switch 40, the first switching module 30 is configured to perform, synchronously on the plurality of cores of a corresponding multicore processor 26, one or several actions among a first group of actions consisting of: waiting, synchronized over the plurality of cores, for uninterruptible process(es) of the current set of software application(s) to finish running; and purging all memory resource(s) associated with the current set of software application(s).
Memory resources of the plurality of cores refer in general to any memory space of a core, whether it involves a cache, a register or a larger memory space.
Purging a memory resource is the reset of this memory resource.
The first switching module 30 is preferably configured to perform each synchronous multicore switching 40 over all of the cores of the corresponding multicore processor 26. If applicable, the first switching module 30 is configured to perform the aforementioned action(s) of the first group of actions synchronously over all of the cores of the corresponding multicore processor 26.
One skilled in the art will understand that multicore synchronous switching 40 is triggered at a determined moment by the platform 16, typically by configuration, and for all of the affected cores, this triggering being, in light of the aforementioned synchronism, done at the same time for said plurality of cores, and then being simultaneous or quasi-simultaneous. The notion of synchronism depends on the software applications 14; a duration dedicated to the synchronous switching, such as typically several hundreds of microseconds, is for example defined as a duration during which no application activity is performed and the switching activities on the various cores are partially sequential. At the end of switching, the application activity is relaunched simultaneously on all of the cores.
The first switching module 30 is preferably configured to perform all of the actions of the first group of actions, on the plurality of cores of the corresponding multicore processor 26 or preferably on all of the cores of the corresponding multicore processor 26.
In addition, the first switching module 30 is configured to further perform one or several actions among a second group of actions consisting of: resetting input(s)-output(s) associated with the subsequent set of software application(s); saving the context of the current set of software application(s); and restoring the context of the subsequent set of software application(s).
When the first switching module 30 is configured to perform both the actions of the first group of actions and those of the second group of actions, it is preferably configured to perform them in the following order:
and
As an optional addition, the second switching module 32 is, during the running of a given set of software application(s) 14, configured to switch between the running of a first software application and the running of a second software application on a same core. The second switching module 32 is then configured to perform an internal switching 42 to a respective core of the corresponding processor 26.
To perform an internal switching 42 to a respective core, the second switching module 32 is configured to perform one or several actions among the group consisting of: waiting for uninterruptible process(es) of the first software application to finish running; saving the context of the first software application; purging memory resource(s) of the core, including the corresponding private cache(s); and restoring the context of the second software application.
The second switching module 32 is preferably configured to perform all of the actions of the aforementioned group of actions on the respective core of the corresponding multicore processor 26.
The operation of the implementing device 24 according to the invention will now be explained using
During a step 100, the implementing device 24 implements, via its first switching module 32, a synchronous multicore switching 40.
This synchronous multicore switching step 100 includes one or several actions among the first group of actions consisting of: waiting, synchronized over the plurality of cores, for uninterruptible process(es) of the current set of software application(s) to finish running; and purging all memory resource(s) associated with the current set of software application(s).
This step of synchronous multicore switching 100 is performed synchronously over the affected plurality of cores of the corresponding multicore processor 26.
This step of synchronous multicore switching 100 is preferably performed synchronously over all of cores of the corresponding multicore processor 26. The aforementioned action(s) of the first group of actions are then performed synchronously over all of the cores of the corresponding multicore processor 26.
Each synchronous multicore switching step 100 is triggered at a determined moment by the platform 16, typically by configuration, and for all of the affected cores.
Each synchronous multicore switching step 100 preferably includes all of the actions of the first group of actions, the latter then being performed on the plurality of cores of the corresponding multicore processor 26 or preferably on all of the cores of the corresponding multicore processor 26.
In addition, each synchronous multicore switching step 100 further includes one or several actions among the second group of actions consisting of: resetting input(s)-output(s) associated with the subsequent set of software application(s); saving the context of the current set of software application(s); and restoring the context of the subsequent set of software application(s).
As an optional addition, during a next step 110, the implementing device 24 carries out, via its second switching module 32, one or several internal switches 42 to a respective core of the corresponding processor 26.
Each switching step on a same core 110 between the running of a first software application and the running of a second software application on a same core, during the running of a given set of software application(s), includes one or several actions from the group consisting of: waiting for uninterruptible process(es) of the first software application to finish running; saving the context of the first software application; purging memory resource(s) of the core, including the corresponding private cache(s); and restoring the context of the second software application.
Each switching step on a same core 110 preferably includes all of the actions of the aforementioned group of actions on the respective core of the corresponding multicore processor 26.
Thus, the implementing device 24 and the implementing method according to the invention make it possible, via one or several successive synchronous multicore switches 40 and as shown in the example of
This segmentation into time clusters TC with synchronous multicore switches 40 then makes it possible to obtain more robust partitioning, in particular absolute time partitioning, during the running of software applications 14 on the platform 16.
Absolute time partitioning refers to an implementation allowing isolation between time clusters TC irrespective of the core of the corresponding multicore processor 26.
Absolute spatial partitioning refers to an implementation allowing isolation, in terms of resource allocations, in particular of memory resources, between all of the installed partitions irrespective of the core of the corresponding multicore processor 26.
A partition refers to a temporal and spatial area allocated to a software application 14 or to a group of software applications 14 on one or several cores.
In other words, each synchronous multicore switch 40 then makes it possible to provide complete cleaning of the entire multicore context, that is to say, to eliminate any trace of execution related to the previous time cluster for the entire multicore context, that is to say, to eliminate any trace of running related to the previous time cluster for the cores in question, and then to offer absolute partitioning, that is to say, not involving any constraint introducing dependencies between software applications 14.
In
In the example of
In
One skilled in the art will also observe that the multicore processor further makes it possible to offer a partitioning between cores 44, also called inter-core partitioning, shown by the zones filled with dots in
Similarly to the example of
One skilled in the art will understand that the various time clusters TC, as defined above, in particular the determination of the moments at which the successive synchronous multicore switches 40 must be done, are defined during a preliminary design phase or during a mission preparation phase, prior to the implementation of the inventive method.
When the electronic system 10 is an avionics electronic system embedded in the aircraft, this definition of the time clusters TC is further preferably done prior to flight of the aircraft, the implementing method according to the invention preferably being carried out during the flight of the aircraft.
One skilled in the art will also note that it is further possible to install several software applications 14 in separate partitions inside a same time cluster TC using different methods. According to a first method, two partitions are installed in parallel on separate cores, and benefit from partitioning between cores, also called inter-core partitioning. According to a second method, two partitions are installed sequentially on a same core or a set of cores, and in this case benefit from partitioning through one or several internal switches 42, core by core, also called intra-core partitioning. A third method corresponds to a mixture of the first and second methods with inter-core and intra-core partitioning.
Furthermore, the internal switching 42 to a core cannot eliminate all causes of dependency between the preceding and subsequent software applications 14 from a time perspective (contention resulting from a chain between preceding software application, other software application on another core, subsequent software application). This results in the potential presence of jitter on the running time of a software application 14, the jitter depending on the activity of the other software applications 14. There is then ultimately no difference, with respect to the isolation of the software applications 14 within a same time cluster TC, between two applications installed on a same core and separated by an internal switch 42 and two applications installed on two different cores.
As an optional addition and in order to further improve the operating safety of the platform 16, the implementing device 24, or another monitoring device, is configured to monitor the running times within a time cluster TC when several independent software applications 14 are installed. The consequence of exceeding a running time being able to threaten the operating safety, corrective actions, such as resetting the affected software applications 14 or stopping the least critical software applications 14, are provided after this monitoring is triggered. Such corrective actions seek to restore a safer context following such events and to discharge the corresponding multicore processor 26, in order to regain a situation free of exceptional contentions.
One can thus see that the method and the implementing device 24 according to the invention make it possible, due to the partitioning resulting in particular from each synchronous multicore switching 40, to control the impact of contention(s) during the running of software applications 14 and to then facilitate the qualification of the platform 16.
| Number | Date | Country | Kind |
|---|---|---|---|
| 17 01054 | Oct 2017 | FR | national |
This application is a National Stage entry of International Application No. PCT/EP2018/077712, filed on Oct. 11, 2018, which claims priority to French Patent Application No. 17 01054, filed on Oct. 11, 2017. The disclosures of the priority applications are hereby incorporated in their entirety by reference.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2018/077712 | 10/10/2018 | WO | 00 |
