Functional partitions in integrated modular avionics

Abstract

The invention relates to a computing system (1) for executing software applications in an aircraft (3), wherein the computing system (1) is designed to use volatile partitions for at least temporal resource allocation of one or more computing processes to physical resources available in the computing system (1), wherein a respective one of the volatile partitions is started by a trigger signal and is terminated upon its generation of a current return value of a return variable that is the same for each execution of a plurality of sequential executions, so that over a contiguous runtime of the computing system (1), a respective one of the volatile partitions is restarted at a plurality of times and is terminated again after its calculated return value has been output.

Description

The invention relates to a computing system for executing software applications in an aircraft, and to a method for executing applications on an integrated modular avionics of an aircraft.The following statements are not necessarily from a particular prior art document, but are well known in the art and will be apparent from consideration of those skilled in the art:A simple, but generally inefficient, avionic architecture is the use of multiple LRUs (LRU is an abbreviation for "line-replaceable unit"). In this case, a dedicated processing unit is provided for each application in a dedicated LRU, which processing unit has, for example, a dedicated power supply, a dedicated CPU (abbreviation for "Central Processing Unit") and a network interface (a so-called I / O interface). While such an architecture may easily partition (in the wording of DO-178-C) and redundantly execute applications of avionics (e.g., an automatic landing system, a hydraulic control system, an autopilot for cruise flight, a flight management system, a sensor signal provision, a display control, etc.), and may easily allow physical replacement of a single LRU, such an architecture is generally inefficient and requires provision of more physical resources than is essential, e.g., unnecessary many separate power supply modules.In order to eliminate this inefficiency and to increase the flexibility with respect to the applications to be implemented when executed on the avionics, the concept of integrated modular avionics (abbreviated "IMA") has therefore been pursued for several decades. In this case, a plurality of aircraft applications are accommodated on the same platform, that is to say physical resources are shared by a plurality of applications. The platform comprises a physical solution (hardware) and software necessary for operating the hardware, typically comprising an operating system, state monitoring, drivers, a board support package and service programs. The physical solution is realized, for example, by a so-called "integrated rack" or "cartridge", which offers an integrated physical platform and has a unit of shared physical resources instead of individual LRUs.The platform provides system services to such high-level applications that are implemented for the direct realization of the aircraft functions, manages application interfaces, manages the common resources and provides isolation from one another within the scope of partitioning the respective applications. For this purpose, the applications are typically provided with a documented API (abbreviation for "application program interface"), i.e. a software interface, in order to be able to carry out a defined communication between a first program (of the application) and a second program (in particular an operating system of the platform).Typically, so-called partitions are used as isolation primitives which are completely encapsulated from one another both in time and with regard to their resource allocation (for example, in terms of storage technology). The integrated modular avionics aims to allow application developers to focus on the application layer while a platform developer has to ensure platform availability, integrity, and security functions. Unlike the application developer, it is up to the platform developer to provide a configuration that meets the requirements set forth above, so that the application developer only carries responsibility for the application, thereby using only the API to the IMA platform.The execution paradigm for IMA platforms established in the prior art provides that partitions for isolation are executed on computers of the IMA platform in predefined time slots. These partitions are continuously executed from a semantic point of view, are paused at the end of their time window in the frozen state and are continued to the start of their next time window.Such isolation of the partitions can only be broken through predetermined communication channels. However, the problem of these communication channels is that continuous execution of the partitions frequently requires new messages to be waited for, the partitions (or individual processes within a partition) blocking. In this case, system resources (i.e. in particular CPU cycles) are used repeatedly inefficiently. This also applies to other platforms that do not fall under the IMA architecture, such as fly-by-wire systems.The following publication describes how appropriate hardware and software mechanisms are used in partitioning to restore severe fault containment in integrated avionics architectures. In this case, requirements for partitioning, the mechanisms for realizing them, and the problems in ensuring partitioning are investigated. Since there are some concerns about computer security in partitioning, security models are reviewed and compared to the concerns about partitioning: Rubby, J.: Partitioning in Avionics Architectures: Requirements, Mechanisms, and Assistance, NASA / CR-1999-209347, 1999, Langley Research Center, Document ID 19990052867, https: / / ntrs.nasa.gov / citations / 19990052867.The following publication also describes a review of a state of the art of time and space partitioning (TSP) research for spacecraft avionics: Bredereke, J.: A Survey of Time and Space Partitioning for Space Avionics. In: "DASIA 2018 Data Systems In Aerospace". (Oxford, UK, 29th-31st May 2018). Session A10: TSP including Multicore & PU. Eurospace, 2018; City University of Applied Sciences Bremen. https: / / homepages.on.hs-bremen.de / -jbredereke / downloads / Bre18a.pdf object of the invention is to provide an improved avionics platform.The invention results from the features of the independent claims. Advantageous refinements and refinements are the subject matter of the dependent claims.A first aspect of the invention relates to a computing system for executing software applications in an aircraft, wherein the computing system is designed to use volatile partitions for at least temporal resource allocation of one or more computing processes to physical resources available in the computing system, wherein a respective one of the volatile partitions is started by a trigger signal and, upon generation of a current return value, a return size which is the same for each execution of a plurality of sequential executions is ended, such that, over a contiguous runtime of the computing system, a respective one of the volatile partitions is restarted at a plurality of times and is ended again after output of its calculated return value.As explained at the beginning, it is customary in the prior art, when a time limit defined by the platform configuration is reached, to freeze and pause the process or processes executed in the partition until a new time budget is available, and to continue the paused partition. A single partition is therefore semantically executed continuously over the entire runtime, i.e. executed with interruptions over the entire runtime. After a respective interruption, a partition must therefore be continued exactly in the state in which it was terminated after the expiration of the time budget. However, a memory state is not definable in advance, since it is generally unpredictable which memory state the partition will have when the pause begins, rather a generally unpredictable snapshot is present, with some or all of its memory state being lost. A partition may generally be ended (as opposed to being paused) during runtime (e.g., during flight operation of the aircraft) only when, for example, a fault is detected and restart of the partition is attempted.In contrast, with the present computing system and the method performed thereby, a partition is not nominally executed repeatedly in a suspended manner over the entire runtime, but rather is repeatedly started anew and ended completely again in a genuine manner from the outset. The termination is triggered by the executed partition having come to a result which is expressed in the output of a return value. Since the return value corresponds to a predetermined category of a return size, in contrast to the method implemented as described above in the prior art, the memory required for this is very well predictable, since each termination of the repeatedly implemented partition is a new current calculation of a return value of the predetermined return size.The return variable can be defined in a data type, for example a numerical scalar, or an array, a string, a specifically defined data type, for example from numerical values and / or from strings or another set of different data types, wherein not every variable of the return variable has to be occupied with an actual value in each embodiment. It is decisive that the return variable defines a maximum set of return values in the sense of a result of an algorithm executed in the respective volatile partition; the partition comes to completion in this case like a function and delivers the return value in the sense of a return value. The return value is the respectively currently determined value or value set of the return variable.The computing system preferably forms a platform according to the concept of integrated modular avionics.The termination of the respective volatile partition is triggered by the receipt of this return value of a respective volatile partition itself, at least if it is below a predefined maximum time budget. The time budget and the availability of the physical resources must be designed according to an expected computing time. In addition to the predictable memory size when ending the respective volatile partition, a further advantage is achieved: the respective volatile partition can be more easily transferred to another avionics computer of the integrated modular avionics, in particular in the event of a fault, since a respective return value is a well-defined result of the execution of a volatile partition. In addition, a state in the initially applied orchestration unit (in particular a hypervisor) can thus be more easily transferred to another orchestration unit (in particular a hypervisor). This can be done, for example, by means of managed memory.For orchestration, i.e. superimposed organization, of the execution of partitions, an orchestration unit (a hypervisor) is typically used. If a fault case is detected, the execution of a volatile partition under an orchestration unit of an avionic computer of the computing system can be assumed to be another orchestration unit of another avionic computer.A volatile partition has the properties of a conventional partition being encapsulated and isolated from each other in order to ensure the safety of execution and high reliability in the execution of applications. On the other hand, a volatile partition simulates a functional execution paradigm and is characterized by corresponding call parameters and output parameters.The execution life cycle of a volatile partition thus only reaches until the task is fulfilled or a predefined maximum execution time is reached, in order not to exceed a predefined time budget (since otherwise, under certain circumstances, further partitions would likewise not have a sufficient time budget available).The functional execution paradigm of the volatile partitions provides that the program flow is pipelined, i.e., a return value of one volatile partition may be the call parameters of another volatile partition, such that dependent sequential execution of the volatile partitions is performed. The term pipeline is analogous to a physical pipeline in which material is successively moved through a predefined transport path. In particular, the return value of a volatile partition can be the call parameters of the same partition, which is however executed sequentially at a new point in time subsequently, or of another volatile partition.Preferably, the respective volatile partition defines not only a temporal resource allocation but also a physical resource allocation, i.e. for example a memory space reservation in a volatile memory (RAM). A budget for using a CPU of a respective avionics computer can also be defined by the resource allocation by the volatile partition.According to one advantageous embodiment, the computing system has a multiplicity of avionics computers, wherein the computing system is designed to determine an assignment of a respective execution of a respective partition to a respective one of the avionics computers by means of a predefined configuration logic, wherein the configuration logic is designed to determine the assignment as input variable using information about a respective availability of a respective avionics computer.In this case, the physical resources are divided into individual avionic computers. The predetermined configuration logic is to assign the execution of the partitions to the physical resources so as to determine which partition is executing on which the avionic computer. In addition, the execution time, i.e. the start time, of a respective partition can be determined by means of the configuration logic.The configuration logic may be implemented as a configuration function. The configuration logic is in particular a deterministic function which delivers the same result with the same input variable, and is therefore configured deterministically. System information that contains at least the information as to which of the avionic computers is functional (i.e. without detected errors) at a respective point in time acts as the input variable.According to a further advantageous embodiment, the computing system is designed to make a sub-selection of partitions to be executed regularly by means of the configuration logic and on the basis of the respective availability of a respective avionic computer, and to execute only the partitions from the sub-selection on their partitions assigned in each case according to the assignment.Preferably, each of the avionics computers is provided with its own orchestration unit, which can use the predefined configuration logic in order to determine on its own which of the partitions originally and regularly provided for execution are still to be executed depending on the number of avionics computers still available without errors after a fault case. This makes a sub-selection of the partitions to be executed originally and regularly, and only the partitions from the sub-selection made are still executed on avionic computers selected according to the configuration logic. One strategy by which the configuration logic can be designed is that as many partitions as possible are executed with functionalities with respectively high safety criticality.The deterministic nature of the configuration function allows the avionics computers to independently make the proper decision as to which of the partitions they must execute at what time to run the computing system with the highest possible security for the aircraft. The correctness of the selection can be guaranteed by a consensus algorithm (for example by a byzinic fault tolerance algorithm) or by the configuration logic itself.In the case of one or more faulty avionic computers or under the influence of an attack, all the still remaining functional avionic computers can decide which partitions they must execute. In the event of a fault in one or more of the avionic computers, the functionality of the overall system can thereby still be maintained. There is also advantageously the possibility of certification, since the configuration logic is already defined in its deterministic design, in particular, at the design time and remains invariant. This enables verification before startup.Conventionally defined partitions in the prior art are statically allocated to a respective avionics computer according to a configuration defined at design time. In the case of a defective avionic computer, the functionality previously provided can only be provided by a replica partition on another avionic computer. A disadvantage of this is that, in the event of failure of all avionic computers with replicas of a partition, the functionality of this partition can no longer be provided at all. In contrast, the above-mentioned configuration logic provides a determination, in particular by a system-specific configuration function, which describes on which avionic computer a respective partition is to be executed as long as the nominal case predominates and which adaptation is carried out if one or more defective avionic computers are present. Execution of essential partitions can thus be guaranteed in a proven manner. In addition, non-replicated partitions also gain fail-safe if those of the avionics computers on which they are running fail. Namely, a partition having a low security criticality may be stopped in favor of a partition having a higher security criticality when the avionics computer executing the partition having a higher security criticality is defective.According to a further advantageous embodiment, the configuration logic comprises an algorithm for solving a backpack problem. A backpack problem is an optimization problem known in mathematics and informatives, and is also called a "snapbag problem". Abstracts is to solve the problem of finding from a set of elements to which a respective cost value and a respective quality value is assigned a combination such that the sum of the quality values is maximized without exceeding a predetermined limit value with the sum of the cost values of the selected elements. In this case, the metapher of the backpack corresponds to the predefined limit value.If the configuration logic is designed as a solution to such a backpack problem, the (time) capacities of the orchestration units of the computing system with its avionics computers correspond to a respective backpack and thus to a respective predefined limit value. The elements as explained above correspond to the partitions. Cost values of the partitions are time costs, quality values are priorities which indicate how important the execution of the respective partition is for the most reliable possible execution of the computing system with regard to the flight of the aircraft with this computing system. To solve the backpack problem, a simple greedy algorithm can be applied, which is designed to always take the highest priority partitions as far as possible. This is an example of a deterministic algorithm that always yields the same result for the same inputs.If one of the partitions has dependencies, for example if its execution is dependent on the result of the execution of another partition, these dependencies must also be taken into account in the transmission to the "backpack". This means that the dependencies must be packed in a backpack if they are not yet in a backpack.If an orchestration unit should fail, the (time) capacity of the backpack of the orchestration unit is set to zero. This yields an algorithm (the configuration logic) which can be executed on all orchestration units of an overall system and outputs the same configuration.The only input that is necessary is the information which of the orchestration units are currently available without detected fault cases. After executing the algorithm, each orchestration unit still executed may implement its backpack (its configuration logic) on its own.According to an advantageous embodiment, the computing system is configured to execute concurrent execution of a plurality of processes within at least one of the volatile partitions.Concurrent execution concerns parallelism of execution of elementary or higher-order tasks. A prerequisite for the concurrent execution of a plurality of processes within at least one volatile partition is the support by the orchestration unit, which is responsible for the management of the volatile partition. Advantageously, physical resources of the computing system can thus be better utilized under certain circumstances and a more rapid execution of the computing results per application can be achieved.According to another advantageous embodiment, the computing system is configured to, upon detection of a failure to execute a volatile partition, start a new replacing volatile partition that fails, wherein a call parameter of the new volatile partition is the most recent return value of the replaced partition.The new volatile partition is preferably re-executed, i.e. migrated, to an avionics computer of the integrated modular avionics that is redundant to the faulty avionics computer. In this case, in particular, a transfer takes place from the orchestration unit of the faulty avionic computer to the orchestration unit of the redundant avionic computer in order to continue there with a new consecutive execution of the volatile partitions.According to a further advantageous embodiment, the computing system is designed to end the execution of this volatile partition when a time duration of an execution of a volatile partition exceeds a predefined maximum permissible execution duration.The maximum permitted execution duration corresponds to a predefined time budget, which is provided in order to release the physical resources again in time in order to make corresponding resources available for further partitions.According to a further advantageous embodiment, the trigger signal for starting a volatile partition is present when a return value from a previous execution of the volatile partition is available, or when a command signal is obtained from a functional unit of the aircraft.The command signal of a functional unit can be, for example, the occurrence of a new, current sensor signal of a sensor unit. Other sources may be, for example, a LAN network adapter, SPI, or a CAN bus, which may provide corresponding call parameters for a volatile partition. For example, after obtaining a new sensor value of a discretely measuring sensor of the aircraft over time, a calculation may be necessary, which is to be executed in the sense of an application on the CPU of an IMA. The receipt of the new sensor value is thus the trigger signal in the sense of the command signal of the sensor in the role of the functional unit, after which the volatile partition is started and a corresponding application is executed in the volatile partition.If a return value is made available by a preceding execution of a volatile partition, which return value is used by a subsequently executed volatile partition as a call parameter and input value analogous to a software function, this corresponds to the paradigm of pipelining described above.According to a further advantageous embodiment, the computing system is designed to preset the trigger signal in a time-dependent manner, so that the start of a respective volatile partition takes place by time triggering.This achieves in particular a repeated periodic execution of a volatile partition.According to a further advantageous embodiment, the computing system is designed to start the execution of a new volatile partition only after a predefined pause time has elapsed between two consecutive executions of a volatile partition.This in turn advantageously ensures that the volatile partitions are not executed too frequently, and thus physical resources are not unnecessarily occupied. A particular advantage of this in turn is that time guarantees can nevertheless be decided in asynchronous operation.According to a further advantageous embodiment, the computing system is designed to hold a determined return value of a volatile partition only for a predefined maximum validity period as a result of the predefined return variable.If the return size is required, the now old value can no longer be used and the volatile partition has to be executed again; in such a case, a new volatile partition is preferably executed for calculating a current return value when the maximum validity period is exceeded.According to another advantageous embodiment, the computing system comprises a multi-core CPU and a respective volatile partition defines an assignment to a respective core of the multi-core CPU.While, typically in a single core processor, a respective volatile partition allows the full processor to be populated during its allocated execution time, i.e., time budget, a volatile partition may define the use of a particular one or more cores of a multi-core processor. Thus, multiple volatile partitions can also be executed simultaneously on disjunctly allocated cores.A further aspect of the invention relates to an aircraft having a computing system as described above and below.A further aspect of the invention relates to a method for executing applications on an integrated modular avionics of an aircraft, characterized in that volatile partitions are used for at least temporal resource allocation of one or more computing processes to physical resources available in the integrated modular avionics, wherein a respective one of the volatile partitions is started by a trigger signal and, upon generation of a current return value, a return variable which is the same for each execution of a plurality of sequential executions is ended, such that, over a contiguous runtime of the computing system, a respective one of the volatile partitions is restarted at a plurality of times and, after output of its calculated return value, is ended again without being frozen and paused between the executions of the partitions.Advantages and preferred refinements of the proposed aircraft or of the proposed method result from an analogous and analogous transmission of the statements made above in connection with the proposed computing system.Further advantages, features and details are evident from the following description, in which--possibly with reference to the drawing--at least one exemplary embodiment is described in detail. Identical, similar and / or functionally identical parts are provided with the same reference numerals.The following are shown: FIG. 1 : shows a civil aircraft with a computing system for executing software applications in the aircraft according to an exemplary embodiment of the invention. FIG. 2 : A military aircraft with a computing system for executing software applications in the aircraft according to a further exemplary embodiment of the invention. FIG. 3 : A computing system with twelve avionic computers and a configuration logic.FIG. 1 shows a computing system 1 for executing software applications in a civil passenger aircraft 3. The computing system 1 therefore forms a platform according to the concept of integrated modular avionics. The computing system 1 holds an orchestrator, also called a hypervisor, implemented. This has the highest authority among all programs in the computing system 1, and organizes volatile partitions. The volatile partitions comprise a temporal resource allocation and a resource allocation to hardware resources in order to be able to execute safety-critical applications on the computing system 1 in a time-critical manner. The volatile partitions, in contrast to conventional partitions, are distinguished in that respective ones of the volatile partitions are started by a trigger signal and, upon their generation of a current return value, a return variable which is the same for each execution of a multiplicity of sequential executions is ended. This occurs at a very large number of times, for example multiple times in each second of the runtime of the computing system 1. a respective volatile partition is therefore continuously started and ended again after its return value has been output. It therefore corresponds to the paradigm of a function that is called and that is passed an input value, so that it can output an output value after calculations have been performed. Over a contiguous runtime of the computing system 1, i.e. from a start of the computing system 1 even before the aircraft 3 is started to the shutdown of the aircraft 3 after the landing of the aircraft 3, a volatile partition is not repeatedly paused continuously, but rather is actually ended and restarted.FIG. 2 shows a military aircraft 3 with a computing system 1, which is likewise based on the IMA architecture. A plurality of applications are executed on the computing system 1 during flight of the aircraft 3, including a terrain avoidance and warning system (TAWS). This application requires information about the aircraft 3 to perform its task and returns current warnings at the end of its execution. This application is executed in repeatedly executed volatile partitions. After a predefined period of time after each generation of a return value, this partition is restarted and ended again with the receipt of the return value. A further, second, volatile partition is provided to receive data from a so-called "remote data concentrator" and to process it in order to process sensor data. This further volatile partition is also executed correspondingly repeatedly. A third volatile partition is provided to provide direct control over a cockpit display screen and to perform appropriate computations for the graphical elements displayed there. The second volatile partition is executed at regular time intervals by a timer and started in a correspondingly time-controlled manner. After their successful execution, their return values can be used by other volatile partitions. After all the required call parameters for the first volatile partition have thus been accumulated, the first volatile partition is executed, i.e. the second volatile partition with its generated return value serves as a trigger for starting the first volatile partition. Its return value is in turn used by the third volatile partition in order to correspondingly control the display in the cockpit of the aircraft 3, in particular to output a possible warning state.FIG. 3 shows a computing system 1 which has twelve individual avionic computers 5, each of which in turn executes its own orchestration unit. Furthermore, a configuration logic L is provided, which assigns partitions to be executed to one of the avionic computers 5. In this example, the partitions to be executed in this computing system 1 have been configured in a system modelling program and an associated configuration logic L for the respective orchestration units has been generated. Due to the deterministic nature of the configuration logic L, all the avionic computers 5 get the same result for the partitions which are to be executed on all avionic computers 5. All the avionics computers 5 implement this result separately and the computing system 1 is fully operable. If, by way of example, one of the avionic computers 5 fails, which is indicated in FIG. 3 by a truncated rectangular shape, this is recognized by the remaining avionic computers 5, in particular their orchestration units. Such a detection can take place by detecting missing pings, which, however, in the functional case the avionics computers 5 transmit to one another at regular time intervals. The information is thus known which of the avionic computers 5 is still functional. This information is an input variable of the configuration logic L, which is evaluated accordingly. All remaining functional avionic computers 5 again receive the same result and implement it on their own. By overprovisioning the available avionic computers, all partitions can therefore continue to be executed despite the failure of an avionic computer 5. If a further avionic computer 5 fails, which is indicated in FIG. 3 by a rectangular shape with dashed lines, the configuration logic L is again reevaluated and it is thus determined which partitions of which remaining avionic computers 5 are still to be executed. If two defective avionic computers 5 are a case in which there is not enough computing time in the computing system 1 to execute all partitions as regularly scheduled, then those partitions which have the lowest safety criticality are no longer executed with the possible utilization of all remaining avionic computers 5 and their physical resources.Although the invention has been illustrated and explained in more detail by preferred exemplary embodiments, the invention is not restricted by the disclosed examples and other variations can be derived therefrom by the person skilled in the art without departing from the scope of protection of the invention. It is therefore clear that a large number of possible variations exist. It is also clear that embodiments mentioned by way of example represent only examples which are not to be understood in any way as limiting, for example, the scope of protection, the possible applications or the configuration of the invention. Rather, the preceding description and the description of the figures enable the person skilled in the art to implement the exemplary embodiments in concrete terms, wherein the person skilled in the art, knowing the disclosed inventive concept, can make various changes, for example with regard to the function or the arrangement of individual elements mentioned in an exemplary embodiment, without departing from the scope of protection defined by the claims and their legal equivalents, such as further explanations in the description.

Claims

A computing system (1) for executing software applications in an aircraft (3), wherein the computing system (1) is configured to use volatile partitions for at least temporal resource allocation of one or more computing processes to physical resources available in the computing system (1), wherein a respective one of the volatile partitions is started by a trigger signal and is ended upon its generation of a current return value of a predefined return size which is the same for each execution of a plurality of sequential executions, such that over a contiguous runtime of the computing system (1) a respective one of the volatile partitions is restarted at a plurality of times and is ended again after its calculated return value has been output.The computing system (1) according to claim 1, wherein the computing system has a plurality of avionics computers (5), and wherein the computing system is designed to determine an assignment of a respective execution of a respective volatile partition to a respective one of the avionics computers (5) by means of a predefined configuration logic (L), wherein the configuration logic (L) is designed to determine the assignment as an input variable using information about a respective availability of a respective avionics computer (5).The computing system (1) according to claim 2, wherein the computing system (1) is configured to, by means of the configuration logic (L) and on the basis of the respective availability of a respective avionics computer (5), make a sub-selection of volatile partitions to be executed regularly, and to execute only the volatile partitions from the sub-selection on their respectively assigned avionics computers (5).The computing system (1) according to any one of claims 2 to 3, wherein the configuration logic (L) comprises an algorithm for solving a backpack problem.The computing system (1) of any preceding claim, wherein the computing system (1) is configured to, upon detection of a failure in execution of a volatile partition, start a new volatile partition replacing the faulty volatile partition, wherein a call parameter of the new volatile partition is the latest return value of the faulty partition prior to detection of its failure.The computing system (1) according to any one of the preceding claims, wherein the trigger signal for starting a volatile partition is present when a return value from a previous execution of the volatile partition is available or when a command signal is obtained from a functional unit of the aircraft (3).The computing system (1) according to one of the preceding claims, wherein the computing system (1) is designed to preset the trigger signal in a time-dependent manner, such that the start of a respective volatile partition takes place by time triggering.The computing system (1) according to any one of the preceding claims, wherein the computing system (1) is configured to start the execution of a new volatile partition only after a predetermined pause time has elapsed between two consecutive executions of a volatile partition.The computing system (1) according to any of the preceding claims, wherein the computing system (1) is configured to hold a determined return value of a volatile partition only for a predetermined maximum validity period as a result of the predetermined return size.Method for executing applications on an integrated modular avionics of an aircraft (3), characterized in that volatile partitions are used for at least temporal resource allocation of one or more computing processes to physical resources available in the integrated modular avionics, wherein a respective one of the volatile partitions is started by a trigger signal and, upon generation of a current return value, a return variable which is the same for each execution of a plurality of sequential executions is ended, such that, over a contiguous runtime of the computing system (1), a respective one of the volatile partitions is restarted at a plurality of times and, after output of its calculated return value, is ended again without being frozen or paused between the executions of the volatile partitions.

Images