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) includes 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 running avionics applications, associated method and computer program. Domain

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

[0002] In many real-time systems, applications must execute deterministically. This determinism notably takes the form of temporal determinism: for its execution, the application is allocated a specific time window, and execution must be carried out within this allocated time window. This determinism also takes the form of outcome determinism: during its execution within its allocated time period, the application must often produce an execution result. The execution of different applications by the real-time system is subject to scheduling. This scheduling is performed by a scheduler operating within the real-time system. Its purpose is to distribute resources and time among all applications.

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

[0004] The electronic devices on which such parallel real-time processing is performed generally consist of one or more processors and shared memory. This includes, for example, multi-core processors: indeed, increasing computing power now necessarily involves the use of SoCs (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 devices (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, into partitions. A partition is defined as the allocation of a specific execution time and resources (CPU, memory). Therefore, 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 guarantees the device's security. In this context, a given module includes, for example, two distinct execution channels, each channel executing a partition for a given time.

[0006] The use of multi-core architectures in avionics thus requires the definition of a software architecture that preserves the essential properties for an IMA (Incremental Certification) platform, namely: extended robust partitioning (ERP) 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 they remain within the allocated budget (of time, memory, etc.);

[0008] - that the times of the services offered remain controlled regardless of the conditions execution while remaining compatible with a maximum drift target for partition switching ("partition switching") 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, particularly with regard to access to I / O resources. Indeed, some hardware devices dedicated to I / O do not support concurrent access. For example, if two partitions are running in parallel (for example, on different cores of a processor), some devices do not allow these two partitions to access the same hardware device simultaneously to obtain the value(s) it provides. To provide a solution to this access problem, an I / O server has been developed (called an "IOTC server"). This server, implemented by a specific partition, centralizes access to resources. The server is therefore positioned as an intermediary between the resources (especially I / O) and the partitions that wish to access them (either for reading or writing). Thus, these resources are accessed exclusively by the IOTC server, and the IOTC server makes the resulting data available to the partitions that wish to access it.On the other hand, these are then the . The software data in question becomes shared. The consequence is that access, whether reading or writing, to data may be subject to competition between one (or more) consuming partition(s) and the IOTC.

[0010] Such a case is illustrated by [Fig. 7] in which reference 111 designates an IOTC server and 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 then becomes ensuring, in a multi-core context, that at any given time, a resource-consuming partition (whether it be the IOTC or an avionics partition) can, under all circumstances, access the last available value for that resource. The problem also becomes ensuring that at any given time, a producer partition (whether it be the IOTC or an application) can, under all circumstances, save a value (a message, or a value intended for another module, for example).

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

[0013] The invention aims to solve these problems of the prior art. More particularly, the invention aims to allow all data-producing and data-consuming partitions to have access to data without the need to increase the overall execution time or to provide access blocking mechanisms.

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

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

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

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

[0018] The data sharing structure includes at least two record 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 features, taken individually 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 read / write access in these different areas by the different avionics partitions;

[0023] Advantageously, each data sharing structure is distributed among said zones according to its need to write / read corresponding data;

[0024] - the data sharing structure further includes at least one metadata of determination of a data record address to be used by the data-producing / consuming partition(s);

[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 registration addresses;

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

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

[0029] N other addresses are dedicated to reading by each of the N data-consuming partitions of said predetermined group, 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 a previous and a next piece of data;

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

[0033] - said at least two registration addresses forming a queue of reading / writing a previous and a next piece of 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 running avionics applications, implemented by the platform as previously mentioned, comprising the step of writing two different data into two record 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 process as defined above. Brief description of the figures

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

[0040] - [Fig. 1] [Fig. 1] is a schematic view of a platform for execution 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 the [Fig.l];

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

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

[0044] - [Fig.7] [Fig.7] illustrates a solution known in art. Description of a method of implementation

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

[0046] The platform 1 comprises a multi-core processor 2, 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. 1]. Memory 3 comprises random access memory 6 and non-volatile memory 7. The non-volatile memory 7 is capable of storing a plurality of applications that can be executed by the multi-core processor 2, as will be explained in more detail later. The random access memory 6 includes a shared memory space 8, which can be a processor cache, for example, at level L2, or physical memory of the DDR type. The shared resources 4 include peripherals 10, such as AnIO, DsIO, A429, Fbus, and Xtalk, which are known in themselves. 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 ensures the correct sharing of memory 3 in accordance with the read and write permissions for each partition at a given address.

[0047] Figure 2 illustrates an example of a software architecture 10 implemented on the hardware platform 1 of Figure 1. More specifically, in this example of a software architecture, at least one application stored in non-volatile memory 7 implements an IOTC server 11 for accessing shared resources 4. This IOTC server runs 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 run on one or more cores of the multi-core processor 2. In this example, at least two other applications stored in non-volatile memory 7 implement two avionics applications 13, 14 which run 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], only one second shared area 8-2 is shown in relation to the avionics partition 15. The first shared memory area 8-1 is read-only accessible to all avionics partitions 15, 16. The second shared memory area 8-2 is read / write accessible to the corresponding avionics partition 15. The management unit 18 ensures, in particular, that read / write access is maintained in these different areas by the various avionics partitions 15, 16.

[0049] The IOTC server 11 and the avionics partitions 15, 16 are capable of sharing data between them using the shared memory space 8. More specifically, data sharing 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 achieve 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 producing partition and one or more data-consuming partitions.

[0051] Hereafter, "data-producing partition" means 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), whether or not each data or metadata is modified, 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 materializes the processes for accessing the data of these structures.

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

[0056] Furthermore, each data sharing structure 17-1, 17-2, and 17-3 includes at least one metadata element for determining a data record address to be used. In other words, thanks to the metadata, the producing partition and each consuming partition(s) can determine the record address for writing / reading the corresponding data. Type 1 structure

[0057] In the described example, 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 dissemination by the IOTC server 11 of data to several partitions, either in parallel, 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, 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 can, in particular, be equal to 0 or 1 for incremental certification. The structure of The first type allows the IOTC 11 server to write at least two different data items (a previous and a next item) for transmission, while simultaneously allowing the N avionics partitions in the corresponding group to read the previous item. In other words, concurrent data access is possible thanks to this data structure. For data writing and reading to be performed 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 item.To allow concurrent reading and writing, N+2 addresses are used in this data structure (N corresponding to the number of partitions in the relevant group), so that at any given time, the IOTC 11 server can write the next piece of data to one address while the avionics partitions can read the previous piece of data from another address. The metadata used thus makes it possible to determine, for each read or write operation, at which address, among the N+2 available, the read or write operation should be performed.

[0059] To maintain robust partitioning, the IOTC 11 server manages this metadata: it ensures that addresses are determined based on the write or read operations to be performed. As write operations are performed, the IOTC 11 server reserves one address from among the N+2 available addresses. The presence of an available address is always guaranteed, due to the number of usable N+2 addresses. When an avionics partition wants to read data, it identifies an available read address within the structure's metadata. To prevent corruption of this metadata, before each write operation, the IOTC 11 server compares the consistency of the metadata made available by the avionics partitions during a previous write operation with the current write operation. 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 lock index for each record address among the N+2 addresses. This index shows whether the corresponding address is being read by an avionics partition. The data structure has N+1 lock indices, so by construction, there is always an address available for the next write operation.

[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] In general, in the shared memory space there are at least as many first-type structures as there are groups of N avionics partitions sharing data from the IOTC 11 server. Type II 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 in [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] In general, a KUQ second-type structure allows the IOTC 11 server to write subsequent data while simultaneously allowing the corresponding avionics partition to read previous data. In other words, concurrent data access is possible thanks to this data structure. To achieve this, the second-type structure defines a queue (also called a FIFO) of depth P, where P is an integer greater than or equal to 1, advantageously greater than or equal to 2. Thus, this structure defines P consecutive data record addresses to be transmitted.

[0065] To enable concurrent data writing and reading, the metadata of the data structure is used by the IOTC 11 server 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 write or read operation, at which address, among the available P, the read or write operation should be performed.

[0066] To maintain robust partitioning, the IOTC 11 server manages this metadata: it ensures that addresses are determined based on the write or read operations to be performed. To do this, when determining the address to use for writing data, it makes a copy of the metadata made available by the corresponding avionics partition and compares this metadata with the metadata it has retained from the previous write iteration. This comparison verifies that the corresponding avionics partition is not performing an erroneous "read," in the sense that the partition is not indicating that the data can be read from a location inconsistent with that of the previous write iteration.

[0067] According to a particular example, the metadata used by the IOTC 11 server includes two counters: one incremented with each read and the other incremented with each write. The IOTC 11 server duplicates the read 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 read. When determining the write address, the IOTC 11 server checks the consistency of the duplicate 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 storing data and metadata) and the second shared memory area 8-2 (for storing 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 individual receipt of data from the IOTC 11 server. Third type structure

[0070] The data sharing structure 17-3 is a third type structure, also called a UKQ data structure (from the English "User to Kernel Queuing"), which is dedicated to transmission, via 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] In general, a UKQ third-type structure allows the IOTC server 11 to read the next piece of data, while simultaneously allowing the corresponding avionics partition 16 to write the next piece of data to be transmitted. In other words, concurrent access to the data is possible thanks to this data structure. To achieve this, as in the previous case, the third-type structure defines a queue (also called a 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 consecutive data record addresses to be transmitted.

[0072] To enable concurrent data writing and reading, the metadata of the UKQ third-type structure is used by the corresponding avionics partition and by the IOTC 11 server 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 write or read operation, at which address, among the available P, the read or write operation should be performed.

[0073] To maintain robust partitioning, the IOTC 11 server monitors this metadata: it is responsible for determining the read addresses to be performed. To do this, when determining the address to use for reading data, it makes a copy of the metadata made available by the corresponding avionics partition and compares the available metadata with those it has retained from the previous read 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 data can be written to a location inconsistent with that of the previous read iteration.

[0074] In a particular example, the metadata used by the IOTC 11 server includes two counters: one incremented on each read and the other incremented on each write. The IOTC 11 server 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 11 server 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 metadata storage) and the second shared memory area (for data and metadata storage) associated with the corresponding avionics partition 16.

[0076] In general, there are at least as many third-type structures as there are avionics partitions requiring data transmission to the IOTC 11 server.

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

[0078] The use of the previously presented data structures to perform data sharing within platform 1 is then illustrated. For simplicity in the description, the example of [Fig.2] is used to illustrate the management and access processes for 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 predetermined number N of partitions, data from an I / O device. The I / O device generates data at its own generation rate: data generation is not synchronized with data consumption. The IOTC server 11 sequentially retrieves the consecutive data to be transmitted and makes it available to the N partitions 15, 16 that need it. In this situation, competition is possible between the IOTC server 11 and the partitions 15, 16. This This mechanism allows partitions 15 and 16 to always be able to read the most recent data produced by the IOTC 11 server, and also allows the IOTC 11 server to always be able to write the next piece of data. Furthermore, these operations must be performed without the partitions confusing the IOTC 11 server regarding the address at which the next piece of data should be saved.

[0080] In the second situation, illustrated in relation to [Fig. 4], the IOTC server 11 makes data available for a single partition 15. This could be, for example, data from an I / O device (AnIO, DsIO, A429, Fbus, Xtalk) or a message. The IOTC server 11 makes the data available at its own rate: the data making is not synchronized with the data consumption. In this situation, there is potential conflict between the data-producing partition (IOTC server 11) and the data-consuming partition (partition 15). To avoid this, when reading the data from the beginning of the queue by partition 15, the IOTC server 11 has the option of writing the next piece of data to the next address in the queue. This next piece of 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 its assigned role (producer or consumer), the IOTC 11 server ensures the consistency of the metadata present in the corresponding data structures. In this way, robust partitioning is maintained, and the IOTC 11 server can protect itself from metadata corruption by partitions and preserve its integrity.

Claims

1.

2.

3. Demands Platform (1) for running 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) running a plurality of avionics applications (13, 14) by the multi-core processor (2); and - an IOTC server (11) for accessing resources shared (4) by the avionics partitions (15, 16); the shared memory space (8) being 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 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 record 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 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 read / write in these different areas by the different avionics partitions (15, 16); Advantageously, the data sharing structure (17-1, 17-2, 17-3) is distributed between the said zones (8-1, 8-2) according to its need to write / read corresponding data. Platform (1) according to claim 1 or 2, wherein the structure data sharing (17-1, 17-2, 17-3) further includes at least one metadata for determining a data record address to be used by the data producer / consumer partition(s) (11, 15, 16).

4. Platform (1) according to any one of the preceding claims, wherein the data sharing structure has a first-type structure (17-1) where 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, wherein among the N+2 record addresses of the first type structure (17-1): - two addresses are dedicated to writing by the data-producing partition (11) a previous data and a next data; and - N other addresses are dedicated to reading by each of the N data-consuming partitions (15, 16) of said predetermined group, the previous data.

6. Platform (1) according to any one of the preceding claims, wherein the data sharing structure has a second type structure (17-2) when N equals 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 registration addresses forming a read / write queue of previous and next data.

7. Platform (1) according to any one of claims 1 to 5, wherein the data sharing structure has a third type structure (17-3) when N equals 1, the producing partition corresponding to a single avionics partition (14) and the consuming partition corresponding to the IOTC server (11); said at least two registration addresses forming a read / write queue of previous and next data.

8. Platform (1) according to claims 6 or 7, wherein 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, wherein 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. A method for running avionics applications, implemented by the platform (1) according to any one of the preceding claims, comprising the step of writing two different data into two record 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 process according to claim 11.

Images