Platform for running avionics applications, associated method and computer program

Abstract

Platform for running avionics applications, method and associated computer program. The present invention relates to a platform for running avionics applications, comprising a shared memory space (8), a plurality of avionics partitions (15, 16), and an IOTC server (11) for accessing shared resources. The shared memory space (8) is configured to perform all data sharing between a producer partition (11, 15, 16) and a predetermined group of N data-consuming partitions (11, 15, 16) exclusively via a data-sharing structure (17-1, 17-2, 17-3) allocated in this space (8). The data-sharing structure (17-1, 17-2, 17-3) comprises at least two record addresses usable by the data-producing partition (11, 15, 16) for writing two different data. Figure for the abstract: Figure 2

Description

Title of the invention: Platform for the execution of avionics applications, associated method and computer program Field

[0001] The invention relates to the field of computing. The invention relates more particularly to the field of real-time computing and more particularly still to the execution of computer programs within a real-time computerized avionics device which executes independent processes in parallel. Prior art

[0002] In many real-time devices, applications must execute in a deterministic manner. This determinism takes the form of temporal determinism: for its execution, the application is allocated a time range for execution and the execution must be carried out within this allocated time range. This determinism also takes the form of result determinism: during its execution in the time period allocated to it, the application must often produce an execution result. The execution of different applications by the real-time device is subject to scheduling. This scheduling is carried out by a scheduler operating within the real-time device. Its objective is to distribute resources and time between all the applications.

[0003] The situation is complicated when the real-time device must manage the execution, in parallel, of several applications. This is the case, for example, in the field of avionics. In this field, an execution device can, for example, be used to execute, in parallel, applications that can perform the same functions, whether similar or not. These applications can be identical (the same code executed twice) or different (two different codes). These functions, whether different, identical, or similar, may be required to use resources. These are, for example, input / output resources (called I / O resources) or messages. However, in the field of on-board avionics, for example, the increase in the number of functions to be performed by electronic devices is continually increasing.Conversely, key characteristics of these electronic devices are reduced to a minimum for economic and ecological reasons: it is therefore necessary to have more computing power while reducing consumption and SWaP (from the English for "Size, Weight and Power") footprint.

[0004] The electronic devices on which such parallel real-time processing is performed generally consist of one or more processors and shared memory. These include, for example, multi-core processors: in fact, increasing computing power now necessarily involves the use of SoCs (from the English for "System on Chip") which integrate, among other things, several cores allowing the execution of software in parallel, by sharing resources, and in particular, access to remote input / output peripherals (10).

[0005] Thus, a suitable real-time operating system runs on such electronic devices and this operating system schedules the execution of applications, using the scheduler, in partitions. A partition is defined as the allocation of a determined execution time and resources (CPU, memory). Thus, for its execution, each application has a partition allocated to an execution channel (for example a processor or a processor core). The temporal and spatial isolation of the partition is the guarantee of the security of the device. In this context, a given module comprises, for example, two distinct execution channels, each channel executing a partition for a given time.

[0006] The use of multi-core architectures in the avionics field then involves the definition of a software architecture that allows the essential properties for an IMA (Incremental Certification) platform to be preserved, which are: extended robust partitioning (“ERP” from the English “extended robustpartitioning”) and incrementality. These two fundamental properties require:

[0007] - that an application (or a group of controlled applications) has no influence on other applications as long as it(they) remains within the budget (time, memory, etc.) that is allocated;

[0008] - that the times of the services offered remain controlled whatever the conditions execution while remaining compatible with a maximum partition switching drift objective not to be exceeded: this means that to switch from one application to another, a maximum time must not be exceeded.

[0009] However, a problem arises in particular for access to I / O resources. Indeed, certain hardware peripherals dedicated to IO do not support concurrent access. For example, if two partitions are running in parallel (for example by different cores of a processor), certain peripherals do not allow these two partitions to access, at the same time, the same hardware peripheral to obtain the value(s) that they provide. To offer a solution to this access problem, an IO server has been developed (called an "IOTC server"). This server, implemented by a specific partition, centralizes access to resources. The server is therefore placed as an intermediary between the resources (in particular IO) and the partitions that wish to access them (either in reading or writing). Thus, these resources are exclusively accessed by the IOTC server and the IOTC server makes the resulting data available to the partitions that wish to access them.On the other hand, these are then the . software data in question that becomes shared. The consequence is that access, whether reading or writing, to a piece of data may end up in competition between one (or more) consuming partition(s) and the IOTC.

[0010] Such a case is illustrated by [Fig.7] in which the reference 111 designates an IOTC server and the references “115” and “116” designate two partitions wishing to access the data made available by the IOTC server. This IOTC server thus implements a shared memory accessible by each of the partitions 115, 116.

[0011] The problem is then to ensure, in a multi-core context, that at a given moment, a resource-consuming partition (whether it is the IOTC or an avionics partition) can, whatever happens, access the last value available for this resource. The problem is also to ensure that at a given moment, a producer partition (whether it is the IOTC or an application) can, whatever happens, record a value (message, or value intended for another module for example).

[0012] To solve this problem, it would have been possible to require that the partitions provide, in their execution time budgets, a sufficient margin to absorb the possible contentions (interferences) initiated by the other competing partitions. This solution, however, burdens the overall time available for the execution of the partitions and this is neither desirable nor efficient given the constraints listed above. Summary

[0013] The invention aims to resolve these problems of the prior art. More particularly, the invention aims to allow all the producer partitions and the consumer partitions of data to have access to data without it being necessary to increase the overall execution time or to provide access blocking mechanisms.

[0014] To this end, the invention relates to a platform for the execution of avionics applications.

[0015] The platform comprises a multi-core processor, a memory, a management unit and a plurality of shared resources.

[0016] The memory comprises a shared memory space whose access is controlled by the management unit; a plurality of avionics partitions executing a plurality of avionics applications by the multi-core processor; and an IOTC server for accessing the resources shared by the avionics partitions.

[0017] The shared memory space is configured to perform any data sharing between a producer partition and a predetermined group of N data consumer partitions exclusively via a data sharing structure allocated in this space, the or each data producer / consumer partition corresponding to the IOTC server or to one of the avionics partitions.

[0018] The data sharing structure comprises at least two recording addresses usable by the data producing partition for writing two different data.

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

[0020] - the shared memory space comprises a first shared memory area and for each avionics partition, a second shared memory area;

[0021] the first shared memory area being accessible in read-only mode to all avionics partitions and each second shared memory area being accessible in read / write mode to the corresponding avionics partition;

[0022] the management unit being configured to enforce reading / writing in these different zones by the different avionics partitions;

[0023] advantageously, each data sharing structure is distributed between said zones according to its need for writing / reading corresponding data;

[0024] - the data sharing structure further comprises at least one metadata of determining a data recording address to be used by the or each data producing / consuming partition;

[0025] - the data sharing structure has a first type structure when N is strictly greater than 1, the data producing partition corresponding to the IOTC server and each data consuming partition corresponding to one of the avionics partitions;

[0026] the first type structure comprising N+2 recording addresses;

[0027] - among the N+2 recording addresses of the first type structure:

[0028] two addresses are dedicated to the writing by the data-producing partition of a previous data item and a next data item; and

[0029] N other addresses are dedicated to the reading by each of the N data-consuming partitions of said predetermined group, of the previous data;

[0030] - the data sharing structure has a second type structure when N is equal to 1, the data producing partition corresponding to the IOTC server and the data consuming partition corresponding to a single avionics partition;

[0031] - said at least two registration addresses forming a queue of reading / writing of a previous data and a next data;

[0032] - the data sharing structure has a third type structure when N is equal to 1, the producer partition corresponding to a single avionics partition and the consumer partition corresponding to the IOTC server;

[0033] - said at least two registration addresses forming a queue of reading / writing of a previous data and a next data;

[0034] - the shared memory space comprises a second type structure and / or a third type structure for each avionics partition;

[0035] - the shared memory space comprises a first type structure for each group of N avionics partitions sharing the data produced by the IOTC server;

[0036] - the shared memory space comprises a plurality of sharing structures data, each data sharing structure corresponding to a first type structure, a second type structure or a third type structure.

[0037] The invention also relates to a method for executing avionics applications, implemented by the platform as mentioned previously, comprising the step of writing two different data in two recording addresses of said data sharing structure, by the data producing partition.

[0038] The invention finally relates to a computer program comprising software instructions which, when executed by a programmable electronic device, implement the method as defined above. Brief description of the figures

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

[0040] - [Fig.l] [Fig.l] is a schematic view of a platform for the execution of avionics applications according to the invention;

[0041] - [Fig.2] [Fig.2] is a schematic view of a software architecture implemented work by the platform of [Fig.l];

[0042] - [Fig.3][Fig.4][Fig.5] Figures 3 to 5 are schematic views illustrating the func operation of different data structures implemented by the platform of [Fig.l];

[0043] - [Fig.6] [Fig.6] is a schematic view of a shared memory space implemented work by the platform of [Fig.l]; and

[0044] - [Fig.7] [Fig.7] illustrates a solution known in the art. Description of an embodiment

[0045] In relation to [Fig.l], we present the architecture of a platform 1 for the execution of avionics applications allowing concurrent access to data, without increasing the latency time and respecting robust partitioning and allowing incrementability.

[0046] The platform 1 comprises a multi-core processor 2, a memory 3 and shared resources 4. The multi-core processor 2 comprises for example at least two cores, denoted by 2a and 2b in [Fig.l]. The memory 3 comprises a random access memory 6 and a non-volatile memory 7. The non-volatile memory 7 is capable of storing a plurality of applications which are executable by the multi-core processor 2 as will be explained in more detail later. The random access memory 6 comprises a shared memory space 8 which may be a processor cache memory, for example of level L2 or a physical memory of the DDR type. The shared resources 4 include in particular peripherals 10, such as AnIO, DsIO, A429, Fbus, Xtalk, known per se. These shared resources are connected to the multi-core processor 2 via for example a communication interface 9a using a data bus 9b. Furthermore, a management unit 18 is associated with the memory 3.This unit 18 is called MMU (from the English “Memory Management Unit”) and makes it possible to guarantee the correct sharing of memory 3 in compliance with the reading and writing authorizations for each partition at a given address.

[0047] [Fig. 2] illustrates an example of software architecture 10 implemented on the hardware platform 1 of [Fig. 1]. More particularly, in this example of software architecture, at least one application stored in the non-volatile memory 7 implements an IOTC server 11 for accessing the shared resources 4. This IOTC server executes within a kernel 12 of the real-time operating system and constitutes a single access point to the shared resources 4. The kernel 12 forms a partition and can execute on one or more cores of the multi-core processor 2. In this example, at least two other applications stored in the non-volatile memory 7 implement two avionics applications 13, 14 which execute within two avionics partitions 15, 16 respectively.

[0048] With reference to [Fig. 6], the shared memory space 8 comprises a first shared memory area 8-1 and for each avionics partition 15, 16, a second shared memory area 8-2. In [Fig. 6], a single second shared area 8-2 is illustrated in relation to the avionics partition 15. The first shared memory area 8-1 is accessible in read-only mode to all the avionics partitions 15, 16. The second shared memory area 8-2 is accessible in read / write mode to the corresponding avionics partition 15. The management unit 18 makes it possible in particular to enforce reading / writing in these different areas by the different avionics partitions 15, 16.

[0049] The IOTC server 11 and the avionics partitions 15, 16 are able to share data between them using the shared memory space 8. More particularly, the sharing of data between the avionics partitions 15, 16 on the one hand and the IOTC server 11 on the other hand is possible only via the shared memory space 8.

[0050] To do this, the shared memory space 8 comprises at least three data sharing structures 17-1, 17-2 and 17-3. Each data sharing structure 17-1, 17-2 and 17-3 is dedicated to a particular type of sharing between a producer partition and one or more data consumer partitions.

[0051] Subsequently, by “data producing partition” is meant the IOTC server 11 or one of the avionics partitions 15, 16, when it produces data intended respectively for one or more avionics partitions 15, 16 or for the IOTC server 11.

[0052] By “data consuming partition” is meant the IOTC server 11 or one of the avionics partitions 15, 16 when it receives data produced respectively by one of the avionics partitions 15, 16 or by the IOTC server 11.

[0053] Each data sharing structure 17-1, 17-2 and 17-3 is distributed in the shared memory space 8 between the different shared memory areas 8-1, 8-2 according to the needs of the corresponding avionics partition(s), modification or not, of each data or metadata, as will be explained in more detail later.

[0054] Each avionics partition 15, 16 is implemented using, for example, a library for accessing the corresponding data sharing structures. This access library embodies the methods for accessing the data of these structures.

[0055] Each data sharing structure 17-1, 17-2 and 17-3 comprises a plurality of recording addresses of the same data to allow concurrent access to this data by the producing partition and the or each data consuming partition. This number of records is chosen according to the type of the structure, as will be explained in more detail later.

[0056] Furthermore, each data sharing structure 17-1, 17-2 and 17-3 comprises at least one metadata for determining a data recording address to be used. In other words, thanks to the metadata, the producer partition and the or each consumer partition can determine the recording address for writing / reading the corresponding data. First type structure

[0057] In the example described, the data sharing structure 17-1 is a first-type structure, also called a KUS (Kernel to User Sampling) data structure, which is dedicated to the broadcasting by the IOTC server 11 of data to several partitions either in parallel, or sequentially, or both. In other words, for this first-type structure, the IOTC server 11 acts as a data-producing partition and the avionics partitions 15 and 16 act as data-consuming partitions.

[0058] Generally speaking, a first type KUS structure is used when the IOTC server needs to broadcast data to a predetermined group of N avionics partitions where N is an integer greater than or equal to 0. This number may in particular be equal to 0 or 1 for an incremental certification. The structure of The first type allows the IOTC 11 server to write at least two different data (one previous data and one next data) to be transmitted, while allowing the N avionics partitions of the corresponding group to read the previous data. In other words, concurrent access to the data is possible thanks to this data structure. In order for the writing and reading of data to be carried out concurrently, the metadata of the first type structure is used by the IOTC 11 server and the avionics partitions to determine the write memory address (respectively the read memory address) of the current data.To allow concurrent reading and writing, N+2 addresses are used in this data structure (N corresponding to the number of partitions in the corresponding group), so that at any time, the IOTC 11 server can write a subsequent data item to one address while the avionics partitions can read a previous data item to another address. The metadata used thus makes it possible to determine, for each writing or reading need, at which address, among the N+2 available, the reading or writing operation must be performed.

[0059] To maintain robust partitioning, the IOTC server 11 manages this metadata: it is responsible for determining the addresses based on the write or read operations to be performed. The IOTC server 11 reserves, as the writes are performed, an address from among the N+2 available addresses. The presence of an available address is always ensured, due to the number N+2 usable addresses. When an avionics partition wishes to read data, it identifies, within the metadata of the structure, an address available for reading. To prevent corruption of this metadata, before each write, the IOTC server 11 compares the consistency of the metadata made available by the avionics partitions during a previous write and a current write. When an inconsistency is detected, an alert is raised.

[0060] According to a particular example, the metadata associated with the first type structure includes a locking index of each recording address among the N+2 addresses. This index shows whether the corresponding address is currently being read by an avionics partition. The data structure has N+1 locking indices, so by construction, there is always an address available for the next write.

[0061] The first type structure 17-1 is distributed in the shared memory space 8 between the first shared memory area 8-1 (for storing data and metadata) and each second shared memory area 8-2 (for storing metadata) associated with the corresponding avionics partition 15, 16.

[0062] Generally speaking, in the shared memory space there are at least as many structures of the first type as there are groups of N avionic partitions sharing data from the IOTC 11 server. Second type structure

[0063] The data sharing structure 17-2 is a second type structure, also called a KUQ (Kernel to User Queuing) data structure, which is dedicated to the transmission, by the IOTC server 11, of data to a single avionics partition. In the example of [Fig. 2], this is the avionics partition 15. In other words, for this second type structure, the IOTC server 11 acts as a data producing partition and the avionics partition 15 acts as a data consuming partition.

[0064] Generally speaking, a second type KUQ structure allows the IOTC server 11 to write a subsequent data item, while allowing the corresponding avionics partition to read a previous data item. In other words, concurrent access to the data is possible thanks to this data structure. To do this, the second type structure defines a queue (also called FIFO) of depth P, where the number P is an integer greater than or equal to 1, advantageously greater than or equal to 2. Thus, this structure defines P addresses for recording consecutive data to be transmitted.

[0065] In order for the writing and reading of data to be carried out concurrently, the metadata of the data structure is used by the IOTC server 11 and the corresponding avionics partition to determine the write memory address (respectively the read memory address) of the corresponding data. The metadata used thus makes it possible to determine, for each writing or reading requirement, at which address, among the available Ps, the reading or writing operation must be carried out.

[0066] To maintain robust partitioning, the IOTC server 11 manages this metadata: it is responsible for determining the addresses based on the write or read operations to be performed. To do this, when determining the address to be used to perform a data write, it makes a copy of the metadata made available by the corresponding avionics partition and it compares the metadata made available with those that it has retained from the previous write iteration. This comparison makes it possible to verify that the corresponding avionics partition does not perform an erroneous “read”, in the sense that the partition does not indicate that the reading of the data can be performed at a location that is not consistent with that of the previous write iteration.

[0067] According to a particular example, the metadata used by the IOTC server 11 comprises two counters: one incremented on each reading and the other incremented on each writing. The IOTC server 11 duplicates the reading counter in the second shared memory area 8-2 associated with the corresponding avionics partition 15 in order to that this partition 15 can increment it with each reading. When determining the write address, the IOTC server 11 checks the consistency of the duplicated read counter before updating the original read counter.

[0068] The second type structure 17-2 is distributed in the shared memory space 8 between the first shared memory area 8-1 (for the storage of data and metadata) and the second shared memory area 8-2 (for the storage of metadata) associated with the corresponding avionics partition 15.

[0069] Generally speaking, there are at least as many second type structures as there are avionics partitions requiring to receive data from the IOTC server 11 individually. Third type structure

[0070] The data sharing structure 17-3 is a third-type structure, also called UKQ (from the English “User to Kernel Queuing”) data structure, which is dedicated to transmission, by a single avionics partition, to the IOTC server 11. In the example of [Fig.2], this is the avionics partition 16. In other words, for this third-type structure, the IOTC server 11 acts as a data-consuming partition and the avionics partition 16 acts as a data-producing partition.

[0071] Generally speaking, a third-type structure UKQ allows the IOTC server 11 to read a following data item, while allowing the corresponding avionics partition 16 to write the following data item to be transmitted. In other words, concurrent access to the data item is possible thanks to this data structure. To do this, as in the previous case, the third-type structure defines a queue (also called FIFO) of depth P, where the number P is an integer greater than or equal to 1, advantageously greater than or equal to 2. Thus, this structure defines P addresses for recording consecutive data items to be transmitted.

[0072] In order for the writing and reading of data to be carried out concurrently, the metadata of the third type structure UKQ are used by the corresponding avionics partition and by the IOTC server 11 to determine the write memory address (respectively the read memory address) of the corresponding data. The metadata used thus make it possible to determine, for each writing or reading requirement, at which address, among the available Ps, the reading or writing operation must be carried out.

[0073] To maintain robust partitioning, the IOTC server 11 monitors this metadata: it is responsible for determining the read addresses to be performed. To do this, when determining the address to be used to perform a data read, it makes a copy of the metadata made available by the corresponding avionics partition and it compares the metadata made available with those it has retained from the previous reading iteration. This comparison makes it possible to verify that the partition does not perform an erroneous "write", in the sense that the partition does not indicate that the writing of the data could be carried out in a location inconsistent with that of the previous reading iteration.

[0074] According to a particular example, the metadata used by the IOTC server 11 comprises two counters: one incremented on each read and the other incremented on each write. The IOTC server 11 duplicates the write counter in the second shared memory area associated with the corresponding avionics partition 16 so that this partition 16 can increment it on each write. When determining the read address, the IOTC server 11 checks the consistency of the duplicated write counter before updating the original write counter.

[0075] The third type structure 17-3 is distributed in the shared memory space 8 between the first shared memory area 8-1 (for storing metadata) and the second shared memory area (for storing data and metadata) associated with the corresponding avionics partition 16.

[0076] Generally speaking, there are at least as many third-type structures as there are avionics partitions requiring data to be transmitted to the IOTC server 11.

[0077] In certain exemplary embodiments, for a given avionics partition, several data structures of the same type can be implemented. For example, if an avionics partition wishes to transfer, to the IOTC server 11, two different types of data, corresponding to two types of IO that the IOTC server 11 must itself transfer to two IO hardware devices, then two different structures of the third type can then be used. Similarly, for the IOTC server 11 when it must allow the partitions to read several different types of data coming from several IO hardware devices, several different structures of the first or second type can then be used.

[0078] The use of the data structures previously presented to carry out data sharing within the platform 1 is illustrated below. For greater simplicity in the description, the example of [Fig.2] is used to illustrate the methods of managing and accessing the data structures 17-1, 17-2, 17-3.

[0079] In the first situation, illustrated in relation to [Fig. 3], the IOTC server 11 makes available, within the first type structure 17-1 (KUS), for a determined number N of partitions, data coming from an IO peripheral. The IO peripheral generates data at its own generation rate: the generation of the data is not synchronized with the consumption of the data. The IOTC server 11 sequentially retrieves the consecutive data to be transmitted and makes them available to the N partitions 15, 16 which need them. In this situation, competition is possible between the IOTC server 11 and the partitions 15, 16. This mechanism allows on the one hand partitions 15, 16 to always be able to read the most recent data produced by the IOTC server 11 and on the other hand, the IOTC server 11 to always be able to write the next data. These operations must also be carried out without the IOTC server 11 being able to be misled by the partitions as to the address at which the next data must be recorded.

[0080] In the second situation, illustrated in relation to [Fig.4], the IOTC server 11 makes data available, for a (single) partition 15. This is for example data from an IO peripheral (AnIO, DsIO, A429, Fbus, Xtalk) or a message. The IOTC server 11 makes the data available at its own pace: the provision is not synchronized with the consumption of the data. In this situation, competition is possible between the data-producing partition (IOTC server 11) and the data-consuming partition (partition 15). To avoid this situation, when reading the data at the beginning of the queue by partition 15, the IOTC server 11 has the possibility of writing a following data item in the following address of the queue. This next data will be read by partition 15 after the previous data has finished reading.

[0081] In the third situation, illustrated in relation to [Fig.5], the principles applied are the same as for the second situation. The difference is that the IOTC server 11 acts as a data consuming partition and the avionics partition 16 acts as a data producing partition.

[0082] In all situations, regardless of the role assigned to it (producer or consumer), the IOTC server 11 ensures the consistency of the metadata that is present in the corresponding data structures. In this way, robust partitioning is maintained and the IOTC server 11 can protect itself from corruption of the metadata by the partitions and maintain its integrity.

Claims

1.

2.

3. Claims Platform (1) for executing avionics applications, the platform (1) comprising a multi-core processor (2), a memory (6, 7), a management unit (18) and a plurality of shared resources (4), the memory (6, 7) comprising: - a shared memory space (8) whose access is controlled by the management unit (18); - a plurality of avionics partitions (15, 16) executing a plurality of avionics applications (13, 14) by the multi-core processor (2); and - an IOTC server (11) for accessing the shared resources (4) by the avionics partitions (15, 16); the shared memory space (8) being configured to carry out any data sharing between a producer partition (11, 15, 16) and a predetermined group of N data consuming partitions (11, 15, 16) exclusively via a data sharing structure (17-1, 17-2, 17-3) allocated in this space (8), the or each data producer / consumer partition (11, 15, 16) corresponding to the IOTC server (11) or to one of the avionics partitions (15, 16); the data sharing structure (17-1, 17-2, 17-3) comprising at least two recording addresses usable by the data producing partition (11, 15, 16) for writing two different data. Platform (1) according to claim 1, wherein the shared memory space (8) comprises a first shared memory area (8-1) and for each avionics partition (15, 16), a second shared memory area (8-2); the first shared memory area (8-1) being accessible in read-only mode to all the avionics partitions (15, 16) and each second shared memory area (8-2) being accessible in read / write mode to the corresponding avionics partition (15, 16); the management unit (18) being configured to enforce reading / writing in these different zones by the different avionics partitions (15, 16); advantageously, the data sharing structure (17-1, 17-2, 17-3) is distributed between said areas (8-1, 8-2) according to its need for writing / reading corresponding data. Platform (1) according to claim 1 or 2, wherein the structure data sharing (17-1, 17-2, 17-3) further comprises at least one metadata for determining a data recording address to be used by the or each data producer / consumer partition (11, 15, 16).

4. Platform (1) according to any one of the preceding claims, in which the data sharing structure has a first type structure (17-1) when N is strictly greater than 1, the data producing partition corresponding to the IOTC server (11) and each data consuming partition corresponding to one of the avionics partitions (15, 16); the first type structure (17-1) comprising N+2 registration addresses.

5. Platform (1) according to claim 4, in which among the N+2 recording addresses of the first type structure (17-1): - two addresses are dedicated to the writing by the data producing partition (11) of a previous data item and a following data item; and - N other addresses are dedicated to the reading by each of the N data consuming partitions (15, 16) of said predetermined group, of the previous data item.

6. Platform (1) according to any one of the preceding claims, in which the data sharing structure has a second type structure (17-2) when N is equal to 1, the data producing partition corresponding to the IOTC server (11) and the data consuming partition corresponding to a single avionics partition (15); said at least two recording addresses forming a read / write queue for a previous data item and a following data item.

7. Platform (1) according to one of claims 1 to 5, in which the data sharing structure has a third type structure (17-3) when N is equal to 1, the producer partition corresponding to a single avionics partition (14) and the consumer partition corresponding to the IOTC server (11); said at least two recording addresses forming a read / write queue for a previous data item and a following data item.

8. Platform (1) according to claims 6 or 7, in which the shared memory space (8) comprises a second type structure (17-2) or a third type structure (17-3) for each avionics partition (15, 16).

9. Platform (1) according to any one of the preceding claims taken in combination with claim 4, in which the shared memory space (8) comprises a first type structure (17-1) for each group of N avionics partitions (15, 16) sharing the data produced by the IOTC server (11).

10. Platform (1) according to any one of the preceding claims taken in combination with claims 4 and 6 or 7, wherein the shared memory space (8) comprises a plurality of data sharing structures, each data sharing structure corresponding to a first type structure (17-1), a second type structure (17-2) or a third type structure (17-3).

11. Method for executing avionics applications, implemented by the platform (1) according to any one of the preceding claims, comprising the step of writing two different data in two recording addresses of the or each data sharing structure (17-1, 17-2, 17-3), by the data producing partition.

12. A computer program comprising software instructions which, when executed by a programmable electronic device, implement a method according to claim 11.

Images