Functional partitions in integrated modular avionics

Abstract

The invention relates to a computing system (1) for executing software applications in aircraft (3), said computing system (1) being designed to use volatile partitions for an at least temporal resource allocation of one or more computing processes to physical resources available in the computing system (1). Each of the volatile partitions is started by a trigger signal and is ended in response to the generation, by means of the partition, of a current return value for a return variable which is the same for each execution of a plurality of sequential executions such that each of the volatile partitions is restarted at a plurality of points in time over a continuous runtime of the computing system (1) and is ended again after the calculated return value of the partition has been output.

Description

[0001] Functional partitions in integrated modular avionics

[0002] The invention relates to a computing system for executing software applications in an aircraft, as well as a method for executing applications on an integrated modular avionics system of an aircraft.

[0003] The following statements do not necessarily arise from a specific prior art document, but are generally known specialist knowledge in the technical field and are the result of expert considerations:

[0004] A simple, but generally inefficient, avionics architecture is the use of multiple LRUs (LRII stands for "line-replaceable unit"). Each application is provided with a separate processing unit in a separate LRII, which includes, for example, its own power supply, its own CPU (Central Processing Unit), and a network interface (a so-called I / O interface). While such an architecture can accommodate avionics applications (e.g., an automatic landing system, a hydraulic control system, a cruise autopilot, a flight management system, a sensor signal supply, a display control system, etc.),) can be easily partitioned (in the wording of DO-178-C) and implemented redundantly, and a physical replacement of a single LRU is easily possible, in general such an architecture is inefficient and requires the provision of more physical resources than absolutely necessary, for example an unnecessary number of separate power supply modules.

[0005] To address this inefficiency and increase flexibility regarding the applications to be implemented on the avionics, the concept of integrated modular avionics (abbreviated "IMA") has been pursued for several decades. This involves accommodating multiple aircraft applications on the same platform, meaning that physical resources are shared between multiple applications. The platform comprises a physical solution (hardware) and the software required to operate the hardware, typically including an operating system, condition monitoring, drivers, a board support package, and utilities. The physical solution is implemented, for example, in a so-called "integrated rack" or "cabinet," which provides 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, which are implemented to directly implement aircraft functions, manages application interfaces, manages shared resources, and ensures isolation within the framework of partitioning the respective applications from each other. For this purpose, the applications are typically provided with a documented API (short for "application program interface"), i.e., a software interface to enable defined communication between a first program (the application) and a second program (in particular, an operating system of the platform).

[0006] Typically, so-called partitions are used as isolation primitives, which are completely encapsulated from each other both in terms of time and resource allocation (e.g., memory). Integrated modular avionics allows application developers to focus on the application layer, while a platform developer ensures platform availability, integrity, and security features. Unlike the application developer, the platform developer is responsible for providing a configuration that meets the above requirements, so the application developer is solely responsible for the application and uses only the API to the IMA platform.

[0007] The state-of-the-art execution paradigm for IMA platforms involves executing partitions for isolation purposes in predefined time slots on IMA platform computers. From a semantic perspective, these partitions are executed continuously, paused in a frozen state at the end of their time slot, and resumed at the start of their next time slot.

[0008] Such partition isolation can only be breached through predefined communication channels. The problem with these communication channels, however, is that the continuous execution of the partitions often requires waiting for new messages, causing the partitions (or individual processes within a partition) to block. This repeatedly results in inefficient use of system resources (i.e., particularly CPU cycles). This also applies to other platforms that do not fall under the IMA architecture, such as fly-by-wire systems. The object of the invention is to provide an improved avionics platform.

[0009] The invention is based on the features of the independent claims. Advantageous developments and refinements are the subject of the dependent claims.

[0010] 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 is terminated upon its generation of a current return value of a return size that is the same for each execution of a plurality of sequential executions, so 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 terminated again after its calculated return value has been output.

[0011] As explained at the beginning, it is common practice according to the state of the art to freeze and pause the process or processes running in the partition when a time limit defined by the platform configuration is reached until a new time budget is available, and to continue the paused partition. A single partition is therefore semantically executed continuously over its entire runtime, i.e., it is executed with interruptions over its entire runtime. After each interruption, a partition must therefore be continued in exactly the state in which it ended after the time budget expired. However, a memory state cannot be defined in advance because it is generally unpredictable what memory state the partition will have when the pause begins. Rather, a generally unpredictable snapshot exists, with its memory state being partially or completely lost.A partition can generally only be terminated (as opposed to paused) during runtime (for example, during aircraft flight) if, for example, an error is detected and a restart of the partition is attempted.

[0012] In contrast, with the present computing system and the method implemented thereby, a partition is not nominally paused multiple times throughout its entire runtime, but rather is intentionally restarted multiple times and then completely terminated. Termination is triggered when the executed partition has reached a result, which is expressed in the output of a return value. Since the return value corresponds to a predefined category of a return variable, the memory required for this is very predictable, in contrast to the method implemented in the prior art as described above, since each termination of the repeatedly executed partition involves a new, current calculation of a return value of the predefined return variable.

[0013] The return variable can be defined in a data type, such as a numeric scalar, or be an array, a string, a specially defined data type, e.g., consisting of numeric values ​​and / or strings, or another set of different data types. Not every variable in the return variable needs to be assigned an actual value in every execution. The crucial point is 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 terminates like a function and delivers the return value in the sense of a return value. The return value is the currently determined value or set of values ​​of the return variable.

[0014] Preferably, the computing system forms a platform based on the concept of integrated modular avionics.

[0015] The termination of the respective volatile partition is triggered by the receipt of this return value from the respective volatile partition itself, at least if it is below a specified maximum time budget. The time budget and the availability of physical resources must be designed according to the expected computing time. In addition to the predictable memory size when terminating the respective volatile partition, another advantage is achieved: The respective volatile partition can be more easily transferred to another avionics computer of the integrated modular avionics, especially in the event of a failure, since the respective return value is a well-defined result of the execution of a volatile partition. Furthermore, a state in the initially applied orchestration unit (in particular, a hypervisor) can be more easily transferred to another orchestration unit (in particular, a hypervisor).This can be done, for example, using managed memory.

[0016] For orchestration, i.e., for the overarching organization, of the execution of partitions, an orchestration unit (a hypervisor) is typically used. If a failure is detected, the execution of a volatile partition under one orchestration unit of an avionics computer in the computing system can be subordinated to another orchestration unit of a different avionics computer.

[0017] While a volatile partition has the properties of a conventional partition, being encapsulated and isolated from each other to ensure execution security and high reliability during application execution, a volatile partition is modeled after a functional execution paradigm and is characterized by corresponding call and output parameters.

[0018] The execution life cycle of a volatile partition therefore only extends until the task is completed or a specified maximum execution time is reached in order not to exceed a specified time budget (otherwise, other partitions might also not have sufficient time budget available).

[0019] The functional execution paradigm of volatile partitions stipulates that program flow is pipeline-oriented, meaning that a return value from one volatile partition can be the call parameter of another volatile partition, resulting in dependent sequential execution of the volatile partitions. The term pipeline is an analogy to a physical pipeline, in which material is moved sequentially through a predefined transport path.

[0020] In particular, the return value of a volatile partition can be the call parameter of the same partition executed sequentially at a new point in time, or of another volatile partition.

[0021] Preferably, the respective volatile partition defines not only a temporal resource allocation, but also a physical resource allocation, e.g., a memory space reservation in a volatile memory (RAM). A budget for the utilization of a CPU of a respective avionics computer can also be defined by the resource allocation by the volatile partition.

[0022] According to an advantageous embodiment, the computing system has a plurality 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 predetermined configuration logic, wherein the configuration logic is set up to determine the assignment using information about a respective availability of a respective avionics computer as an input variable.

[0023] In this case, the physical resources are divided into individual avionics computers. The predefined configuration logic is used to assign the execution of the partitions to the physical resources in such a way that it is determined which partition is executed on which avionics computer. Furthermore, the execution time, i.e., the start time, of each partition can be determined using the configuration logic.

[0024] The configuration logic can be implemented as a configuration function. The configuration logic is, in particular, a deterministic function that delivers the same result given the same input; it is therefore deterministic. The input is system information, which at a minimum contains information about which avionics computer is functional (i.e., without detected errors) at a given time.

[0025] According to a further advantageous embodiment, the computing system is designed to make a subselection of partitions to be regularly executed by means of the configuration logic and on the basis of the respective availability of a respective avionics computer, and to execute only the partitions from the subselection on their respective partitions assigned according to the assignment.

[0026] Preferably, a separate orchestration unit is provided for each of the avionics computers. This unit can use the specified configuration logic to determine which of the partitions originally and regularly intended for execution are still to be executed, depending on the number of avionics computers still available without errors after a failure. This results in a subselection of the partitions originally and regularly intended for execution, and only the partitions from the selected subselection are still executed on the avionics computers selected according to the configuration logic. One strategy for implementing the configuration logic is to execute as many partitions as possible with functionalities that are each highly safety-critical.

[0027] The determinism of the configuration function allows the avionics computers to independently make the correct decision about which of the partitions should be executed at what time in order to operate the computing system with the highest possible reliability for the aircraft. The correctness of the selection can be guaranteed by a consensus algorithm (e.g., a Byzantine fault tolerance algorithm) or by the configuration logic itself.

[0028] In the event of one or more faulty avionic computers or under the influence of an attack, all remaining functional avionic computers can decide which partitions they must execute. This allows the functionality of the entire system to be maintained in the event of a failure of one or more of the avionic computers. Certification is also advantageous, as the configuration logic, in its deterministic design, is defined at design time and remains invariant. This enables verification before commissioning.

[0029] Partitions conventionally defined in the state of the art are statically assigned to a respective avionics computer according to a configuration defined at design time. In the event of a defective avionics computer, the previously provided functionality can only be guaranteed by a replica partition on another avionics computer. The disadvantage of this is that if all avionics computers with replicas of a partition fail, the functionality of this partition can no longer be provided at all. In contrast, the above-mentioned configuration logic provides determinism, in particular through a system-specific configuration function that describes on which avionics computer a respective partition should be executed as long as the nominal case prevails and which adaptations are made if one or more defective avionics computers are present. The execution of essential partitions can thus be provably guaranteed.Furthermore, non-replicated partitions also achieve resilience if the avionics computers on which they run fail. A partition with a low safety criticality can be stopped in favor of a partition with a higher safety criticality if the avionics computer running the higher safety criticality partition fails.

[0030] According to a further advantageous embodiment, the configuration logic comprises an algorithm for solving a knapsack problem. A knapsack problem is an optimization problem known in mathematics and computer science and is also called a "knapsack problem." In abstract terms, it involves solving the problem of finding, from a set of elements assigned a respective cost value and a respective quality value, a combination such that the sum of the quality values ​​is maximized without exceeding a predetermined limit with the sum of the cost values ​​of the selected elements. The knapsack metaphor corresponds to the predetermined limit.

[0031] If the configuration logic is designed as a solution to such a knapsack problem, the (time) capacities of the orchestration units of the computing system with its avionics computers correspond to a respective knapsack and thus to a respective predefined limit. The elements, as explained above, correspond to the partitions. Cost values ​​of the partitions represent time costs, and quality values ​​are priorities that indicate how important the execution of the respective partition is for the safest possible execution of the computing system with regard to the flight of the aircraft with this computing system. To solve the knapsack problem, a simple greedy algorithm can be applied, which is designed to always select the partitions with the highest priority. This is an example of a deterministic algorithm that always delivers the same result for the same inputs.

[0032] If one of the partitions has dependencies, for example, if its execution depends on the result of the execution of another partition, these dependencies must also be taken into account when transferring to the "backpack." This means that the dependencies must be packed into a backpack if they are not already in one.

[0033] If an orchestration unit fails, the (time) capacity of the orchestration unit's backpack is set to zero. This results in an algorithm (the configuration logic) that can be executed on all orchestration units of an entire system and outputs the same configuration to all of them. The only input required is the information about which of the orchestration units are currently available without a detected error. After the algorithm has been executed, each orchestration unit still running can implement its backpack (its configuration logic) independently.

[0034] According to an advantageous embodiment, the computing system is designed to execute a multiplicity of processes concurrently within at least one of the volatile partitions. Concurrent execution refers to the parallel execution of elementary or higher-level tasks. A prerequisite for the concurrent execution of a multiplicity of processes within at least one volatile partition is support from the orchestration unit responsible for managing the volatile partition. This advantageously allows for better utilization of the computing system's physical resources and faster execution of the computational results for each application.

[0035] According to a further advantageous embodiment, the computing system is designed to start a new volatile partition replacing the faulty one upon detection of an error during the execution of a volatile partition, wherein a call parameter of the new volatile partition is the most recent return value of the replaced partition.

[0036] The new volatile partition is preferably re-executed, i.e., migrated, on an avionics computer of the integrated modular avionics system that is redundant to the faulty avionics computer. In particular, a handover takes place from the orchestration unit of the faulty avionics computer to the orchestration unit of the redundant avionics computer, where a new consecutive execution of the volatile partitions can be continued.

[0037] According to a further advantageous embodiment, the computing system is designed to terminate the execution of this volatile partition if the duration of an execution of a volatile partition exceeds a predetermined maximum permissible execution duration.

[0038] The maximum permissible execution time corresponds to a predetermined time budget, which is provided in order to release the physical resources in time to make appropriate resources available for further partitions.

[0039] 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 received from a functional unit of the aircraft. The command signal from a functional unit can, for example, be the occurrence of a new, current sensor signal from a sensor unit. Other sources can be, for example, a LAN network adapter, SPI, or a CAN bus, which can provide corresponding call parameters for a volatile partition. For example, after receiving a new sensor value from a temporally discrete sensor of the aircraft, a calculation may be necessary that is to be executed in the sense of an application on the CPU of an IMA.Receiving 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.

[0040] If a previous execution of a volatile partition provides a return value that is used by a subsequently executed volatile partition as a call parameter and input value analogous to a software function, this corresponds to the pipelining paradigm described above.

[0041] According to a further advantageous embodiment, the computing system is designed to specify the trigger signal in a time-dependent manner, so that the start of a respective volatile partition occurs by time triggering.

[0042] This is particularly useful for achieving repeated periodic execution of a volatile partition.

[0043] According to a further advantageous embodiment, the computing system is designed 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.

[0044] This, in turn, ensures that the volatile partitions are not executed too frequently, thus avoiding unnecessary physical resource consumption. A particular advantage of this is that time guarantees can still be provided in asynchronous operation.

[0045] According to a further advantageous embodiment, the computing system is designed to retain a determined return value of a volatile partition only for a predetermined maximum validity period as a result of the predetermined return size. When the return size is needed, the old value can no longer be used, and the volatile partition must be executed again. Preferably, in such a case, when the maximum validity period is exceeded, a new volatile partition is executed to calculate a current return value.

[0046] According to a further advantageous embodiment, the computing system comprises a multi-core CPU and a respective volatile partition defines an allocation to a respective core of the multi-core CPU.

[0047] While in a single-core processor, a volatile partition typically allows the entire processor to be used during its allocated execution time, i.e., its time budget, a volatile partition can define the use of one or more cores of a multi-core processor. Thus, multiple volatile partitions can also be executed simultaneously on disjointly allocated cores.

[0048] A further aspect of the invention relates to an aircraft having a computing system as described above and below.

[0049] A further aspect of the invention relates to a method for executing applications on an integrated modular avionics system 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 system, 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 size that is the same for each execution of a plurality of sequential executions, so 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 terminated again after outputting its calculated return value, without being frozen and paused between the executions of the partitions.

[0050] Advantages and preferred developments of the proposed aircraft or the proposed method arise from an analogous and analogous application of the statements made above in connection with the proposed computing system. Further advantages, features, and details emerge from the following description, in which at least one exemplary embodiment is described in detail—where appropriate with reference to the drawings. Identical, similar, and / or functionally equivalent parts are provided with the same reference numerals.

[0051] They show:

[0052] Fig. 1: A civil aircraft with a computing system for executing software applications in the aircraft according to an embodiment of the invention.

[0053] Fig. 2: A military aircraft with a computing system for executing software applications in the aircraft according to another embodiment of the invention.

[0054] Fig. 3: A computing system with twelve avionics computers and a configuration logic.

[0055] Fig. 1 shows a computing system 1 for executing software applications in a civil passenger aircraft 3. Computing system 1 incorporates an integrated rack containing line replaceable modules (abbreviated "LRM"). Computing system 1 therefore forms a platform based on the concept of integrated modular avionics. Computing system 1 implements an orchestrator, also called a hypervisor. This orchestrator has the highest authority among all programs in 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 enable the time-critical execution of safety-critical applications on computing system 1.The volatile partitions, in contrast to conventional partitions, are characterized by the fact that each of the volatile partitions is started by a trigger signal and terminated upon generation of a current return value of a return size that is the same for each execution of a large number of sequential executions. This occurs at a very large number of times, for example, several times per second of the runtime of the computing system 1 . A respective volatile partition is therefore continuously started and terminated again after issuing its return value. It therefore corresponds to the paradigm of a function that is called and to which an input value is passed so that it can output an output value after the calculations have been performed. Over a continuous runtime of the computing system 1 , i.e.From the start of the computing system 1 before the takeoff of the aircraft 3 until the shutdown of the aircraft 3 after the landing of the aircraft 3, a volatile partition is not constantly paused, but actually terminated and restarted.

[0056] Fig. 2 shows a military aircraft 3 with a computing system 1, which is also based on the IMA architecture. Several applications are executed on the computing system 1 during the 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 following each generation of a return value, this partition is restarted and terminated upon receipt of the return value. A second volatile partition is provided to receive and process data from a so-called "Remote Data Concentrator" to process sensor data. This additional volatile partition is also executed repeatedly.A third volatile partition is provided to exercise direct control over a screen in the cockpit and to perform corresponding calculations for the graphic elements displayed there. The second volatile partition is executed at regular intervals by a timer and started accordingly. After its successful execution, its return values ​​can be used by other volatile partitions. After all necessary call parameters for the first volatile partition have 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 to control the display in the cockpit of aircraft 3 accordingly, in particular to output a possible warning status.

[0057] Fig. 3 shows a computing system 1 having twelve individual avionics computers 5, each of which executes its own orchestration unit. Furthermore, a configuration logic L is provided, which assigns partitions to be executed to one of the avionics computers 5. In this example, the partitions to be executed in this computing system 1 have been configured in a system modeling program, and an associated configuration logic L for the respective orchestration units has been generated. Due to the determinism of the configuration logic L, all avionics computers 5 receive the same result for the partitions to be executed on all avionics computers 5. All avionics computers 5 implement this result independently, and the computing system 1 is fully functional. If, for example, one of the avionics computers 5 fails, which is the case in Fig.3 by a crossed-out rectangle, this is recognized by the remaining avionics computers 5, in particular their orchestration units. Such recognition can occur by detecting missing pings, which, however, the avionics computers 5 transmit to each other at regular intervals if they are functioning. Thus, the information as to which of the avionics computers 5 are still functioning is known. This information is an input variable of the configuration logic L, which is evaluated accordingly. All remaining functioning avionics computers 5 in turn receive the same result and implement it. By overprovisioning the available avionics computers, all partitions can continue to be executed despite the failure of one avionics computer 5. If another avionics computer 5 fails, which is shown in Fig.3 is indicated by a dashed-crossed rectangular shape, the configuration logic L is re-evaluated, and it is thus determined which partitions of which remaining avionics computers 5 are still to be executed. If two defective avionics computers 5 are a case in which there is not enough computing time in the computing system 1 to execute all partitions as regularly planned, those partitions with the lowest safety criticality are no longer executed, while utilizing all remaining avionics computers 5 and their physical resources as best as possible.

[0058] Although the invention has been illustrated and explained in detail by preferred embodiments, the invention is not limited by the disclosed examples, and other variations may be derived therefrom by those skilled in the art without departing from the scope of the invention. It is therefore clear that a multitude of variations exist. It is also clear that the embodiments mentioned by way of example are truly only examples and should not be construed as limiting the scope, possible applications, or configuration of the invention in any way.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, whereby the person skilled in the art, with knowledge of 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

Patent claims 1. 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 predefined return size 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.

2. 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 predetermined configuration logic (L), wherein the configuration logic (L) is set up to determine the assignment using information about a respective availability of a respective avionics computer (5) as an input variable.

3. Computing system (1) according to claim 2, wherein the computing system (1) is designed to make a subselection of volatile partitions to be regularly executed by means of the configuration logic (L) and on the basis of the respective availability of a respective avionics computer (5), and to execute only the volatile partitions from the subselection on their respective avionics computers (5) assigned according to the assignment.

4. Computing system (1) according to one of claims 2 to 3, wherein the configuration logic (L) comprises an algorithm for solving a knapsack problem.

5. Computing system (1) according to one of the preceding claims, wherein the computing system (1 ) is designed to start a new volatile partition replacing the faulty volatile partition upon detection of an error during the execution of a volatile partition, wherein a call parameter of the new volatile partition is the most recent return value of the faulty partition before its error was detected.

6. Computing system (1) according to 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 received from a functional unit of the aircraft (3).

7. Computing system (1) according to one of the preceding claims, wherein the computing system (1) is designed to specify the trigger signal in a time-dependent manner, so that the start of a respective volatile partition takes place by time triggering.

8. Computing system (1) according to one of the preceding claims, wherein the computing system (1) is designed 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.

9. Computing system (1) according to one of the preceding claims, wherein the computing system (1) is designed to retain a determined return value of a volatile partition only for a predetermined maximum validity period as a result of the predetermined return size.

10. Method for executing applications on an integrated modular avionics system 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 system, 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 after output of its calculated return value without being frozen or paused between the executions of the volatile partitions.

Images