Functional partitions with a dedicated snapshot storage unit in integrated modular avionics

Abstract

The invention relates to a computing system (1) having a plurality of avionics computers (5) for aircraft (3). The computing system (1) assigns volatile partitions to the avionics computers (5), each partition being started in response to a respective trigger signal and being ended by the generation, by means of the respective partition, of a current return value, and the computing system (1) has a respective storage unit for a volatile partition associated with the respective storage unit, which can be written and / or read by the respective volatile partition and which is used to keep at least one return value for the return variable and / or a value for a defined partition state variable of the volatile partition associated with the storage unit stored at least for a specified duration.

Description

[0001] Functional partitions with dedicated snapshot storage 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 software applications in 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 involves 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.), it is also possible to implement a separate LRU.) 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.

[0006] 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).

[0007] 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.

[0008] The state-of-the-art execution paradigm for IMA platforms involves executing partitions for isolation purposes in predefined time slots on avionics computers of the IMA platform. 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.

[0009] 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., especially CPU cycles). This also applies to other platforms that do not fall under the IMA architecture, such as fly-by-wire systems.

[0010] If such a conventional partition is executed on an avionics computer of a computing system implemented as an IMA platform that enters a faulty state, or if a partition is intended for an avionics computer that is already defective upon startup, the functionality provided by this partition is initially lost. To ensure functionality despite this, the following conventional options exist: Replicas of partitions can be executed simultaneously on different avionics computers. However, this has the disadvantage that the necessary computing power, power consumption, and the weight of the computing system with the avionics computers increase linearly with the number of replicas. Furthermore, synchronization of the internal states of the replicas is difficult because the semantics of the respective state of the individual partitions of an orchestration unit are unknown.Another possibility is to migrate an essential partition to another avionics computer, a target avionics computer, in the event of a failure of one avionics computer. This requires not only the program code for the partition to be executed on each potential target avionics computer, but the need for predefined time windows and communication channels means that these must be known at design time for each possible migration. The internal state of such a migrated partition cannot generally be restored, since there is no guarantee that a byte-equivalent copy on another avionics computer will have the same semantics, even if both avionics computers are identical.

[0011] The object of the invention is to provide an improved avionics platform.

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

[0013] A first aspect of the invention relates to a computing system for executing software applications in an aircraft, wherein the computing system comprises a plurality of avionics computers and is designed to assign computing tasks to be executed to the avionics computers in the form of volatile partitions, wherein the volatile partitions are each characterized in that they are started upon a respective trigger signal and are terminated by the computing system, in particular an orchestration unit, by their respective generation of a current return value of a return variable that is identical for each execution of a plurality of sequential executions and is respectively predefined for them, 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.wherein the computing system has a respective memory for a volatile partition assigned to the respective memory, which can be written to and / or read from the respective volatile partition and serves to keep at least one return value of the return variable and / or a value of a defined partition state variable of the volatile partition assigned to the memory stored for at least a predetermined time.

[0014] As explained above, it is common practice, when a time limit defined by the platform configuration is reached, to freeze and pause the process(es) running in the partition until a new time budget is available, and then to continue the paused partition. Thus, a single partition is semantically executed continuously throughout its entire runtime, i.e., with interruptions. After each interruption, a partition must be continued in exactly the same state in which it ended after the time budget expired.However, a partition state variable cannot be defined in advance, as it is generally unpredictable what value the partition state variable will have when the pause occurs. Rather, a generally unpredictable snapshot exists, whose random access memory state is partially or completely lost. Such a conventional partition can generally only be terminated (as opposed to paused) during runtime (e.g., during flight of the aircraft) if, for example, an error is detected and a restart of the partition is attempted.

[0015] 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 and completely terminated multiple times. Termination is triggered when the executed partition has reached a result, which is expressed by the output of a return value. Since the return value corresponds to a predefined category of a return variable, the required memory is very predictable, in contrast to the method implemented in the prior art, since each termination of the repeatedly executed partition involves a new, current calculation of a return value of the predefined return variable.

[0016] 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.

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

[0018] The termination of the respective volatile partition is triggered by the receipt of this return value from the respective volatile partition itself, preferably at least if its execution 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 module 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 value of a partition state variable in a preferred orchestration unit can be more easily transferred to another orchestration unit.

[0019] 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. On the other hand, a volatile partition is modeled after a functional execution paradigm and is characterized by corresponding call parameters and output parameters. The execution lifecycle of a volatile partition thus 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 lack sufficient time budget).

[0020] The functional execution paradigm of volatile partitions specifically 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 analogous to a physical pipeline, in which material is moved sequentially through a predefined transport path. In particular, the return value of a volatile partition can be the call parameter of the same partition, but executed sequentially at a new point in time, or of a different 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 volatile memory (RAM). A CPU usage budget can also be defined by the resource allocation by the volatile partition.

[0022] In case of failure, the use of volatile partitions allows an affected volatile partition to be migrated to another avionics computer, preserving its most recent return value of the return variable and / or its most recent value of the defined partition state variable, i.e., as persistent state.

[0023] The return variable can be a value or value tuple of a variable that is obtained as a final result of the execution of a partition. The partition state variable is, in particular, the current state of a random access memory of an avionics computer, in which a respective memory area is assigned to a respective partition and is reserved for it at least temporarily.

[0024] For the purpose of transferring and snapshotting the relevant values, a separate memory space from the random access memory, or a dedicated memory area within the random access memory (referred to as "memory" for short), is provided to store the most recent return value of the return variable and / or the most recent value of the defined partition state variable, and optionally, corresponding values ​​from further back. The random access memory is part of the von Neumann architecture and serves a processor for volatile data storage. The memory for temporarily storing said values ​​is at least logically separate from it and is available in an atomic transactional manner.

[0025] This has the advantage that the memory contents are always consistent, since interrupted writes, each incomplete transaction, cannot leave the memory in an undefined state. Transactions can be executed, for example, at the end of each successfully executed volatile partition, or when the volatile partition explicitly requests a transaction through an internal function call. In the case of an unsuccessful volatile partition, the most recent correct partition state can be used as a snapshot, which does not negatively impact the next execution.

[0026] Because volatile partitions know whether they have finished their execution and / or writing operations, a value of their partition state can be safely copied, migrated, and interpreted as a snapshot. An additional advantage is that a volatile partition can be reset to a previous partition state.

[0027] According to an 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.

[0028] 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.

[0029] In this case, it may also happen that a partition requires specific input values. Several options can be considered for how this partition obtains the input value. If the required input value was generated some time previously by another volatile partition, it is assumed that each volatile partition receives information at design time about a time limit for which its return values ​​are valid. It may also be the case that the required input value must be generated by another volatile partition. For this to happen, the orchestration unit may have to execute all dependencies before the volatile partition actually required in time, so that all necessary input values ​​are available at the required time. This also applies to the dependencies of the dependencies.To do this, the orchestration unit would then have to calculate how much earlier all necessary volatile partitions must be executed, depending on the maximum execution times of the respective partitions.

[0030] It is advantageous to assign a time limit to the output values ​​of volatile partitions, which specifies how long the respective return value may be used, so that the volatile partition does not have to be executed if its value is still within the limit. This limit should be set at design time. It is also possible for the volatile partition itself to determine the time limit for each execution.

[0031] According to a further advantageous embodiment, each of the avionics computers has its own orchestration unit, each of which is designed to manage at least one memory. Preferably, each of the avionics computers also has its own memory, so that an orchestration unit preferably manages exactly one memory. Nevertheless, one or more partitions can be executed on each of the avionics computers. Advantageously, a plurality of memories is then provided, one memory for each partition.

[0032] According to a further advantageous embodiment, the computing system is designed to use, upon detection of an error in one of the avionics computers during its execution of a first volatile partition, a return value and / or value of the partition state variable determined before the error was detected and stored in the associated memory to continue the functionality of the first volatile partition in a second partition with the functionality of the first volatile partition on another avionics computer.

[0033] According to a further advantageous embodiment, the computing system is designed to continuously transmit the return values ​​and / or values ​​of the partition state variable of the memories for all volatile partitions of an avionics computer to at least one other avionics computer.

[0034] This allows, in the event of a defect in one avionics computer, the most up-to-date status of a volatile partition to be continued on another avionics computer. According to a further advantageous embodiment, the other avionics computer is designed to store the return values ​​and / or values ​​of the partition state variable received from the sending avionics computer itself for a predetermined period of time.

[0035] According to a further advantageous embodiment, the computing system is designed to reset, upon detection of an error during the execution of a volatile partition, this volatile partition to its most recent stored return value and / or its most recent value of its partition state variable.

[0036] According to a further advantageous embodiment, the computing system has a dedicated monitoring partition which is designed to analyze, by means of a content of a memory, the state of the volatile partition which generated the content of the memory.

[0037] According to a further advantageous embodiment, the monitoring partition is designed to check the state and / or the content of the memory for integrity and, in the event of a lack of integrity, to completely reset the associated volatile partition or to reset it to a previously stored return variable and / or a previously stored value of the partition state variable.

[0038] A further aspect of the invention relates to a method for executing software applications in an aircraft, wherein a computing system with a plurality of avionics computers is used and computing tasks to be executed are assigned to the avionics computers in the form of volatile partitions, wherein the volatile partitions are each characterized in that they are started upon a respective trigger signal and are terminated by their respective generation of a current return value of a return variable that is the same for each execution of a plurality of sequential executions and is respectively predefined for them, so that over a continuous runtime of the computing system, a respective one of the volatile partitions is restarted at a plurality of times and terminated again after outputting its calculated return value, wherein respective memories are used in the computing system,which are each assigned to a volatile partition and which can be written to and / or read from the respective volatile partition and which store at least one return value of the return variable and / or a value of a defined partition state variable of the volatile partition assigned to the memory, at least for a predetermined time.

[0039] Advantages and preferred developments of the proposed method result from an analogous and analogous transfer of the statements made above in connection with the proposed computing system.

[0040] Further advantages, features, and details will become apparent from the following description, which – where appropriate with reference to the drawings – describes at least one embodiment in detail. Identical, similar, and / or functionally equivalent parts are provided with the same reference numerals.

[0041] They show:

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

[0043] Fig. 2: The computing system of Fig. 1 schematically.

[0044] Fig. 1 shows a computing system 1 for executing software applications in an aircraft 3. The computing system 1 includes an integrated rack containing Line Replaceable Modules (abbreviated "LRM"). The computing system 1 therefore forms a platform based on the concept of integrated modular avionics. The computing system 1 executes volatile partitions on several avionics computers 5. Unlike conventional partitions, the volatile partitions are characterized in 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 plurality of sequential executions. This occurs at a very large number of times, for example, multiple times per second of the computing system 1's runtime. 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 which is called and to which an input value is passed so that it can output an output value after performing calculations. Over a continuous runtime of the computing system 1, i.e. from a 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 is actually terminated and restarted again. The computing system 1 also has a respective memory for a volatile partition assigned to the respective memory, which can be written to and / or read from by the respective volatile partition and serves to keep at least one return value of the return variable and / or a value of a defined partition state variable of the volatile partition assigned to the memory stored at least for a predetermined time.Further properties are explained with the help of Fig. 2.

[0045] Fig. 2 shows the computing system 1 of Fig. 1 in more detail. The computing system 1 has two avionics computers 5, each of which runs a volatile partition which, with its respective deadline, consumes less than 40% of the available CPU resources of a respective avionics computer 5. Both avionics computers 5 have more than 60% idle time. All partitions are expected to be able to meet their deadlines 99% of the time, of which the remaining one percent is not critical for flight safety. In addition to this respective volatile partition for each avionics computer 5, an additional health monitoring partition can optionally be provided which consistently consumes less than 10% of the available CPU resources of a respective avionics computer 5.After each execution of a volatile partition, it receives the memory contents of both memories of the avionics computers 5, designated as a snapshot, in order to check the respective memory contents for errors and / or plausibility. Due to this exemplary tight deadline, however, the deadline is expected to be exceeded at irregular intervals. In these cases, the affected volatile partition is terminated, re-executed, and upon re-execution, its most recent value of its partition state variable, as defined by the snapshot, is used to continue the re-execution with the most recent value of the partition state variable. The additional health monitoring partition checks the respective value of the partition state variable of each partition after each execution.If the respective value is implausible or even corrupted, the health monitoring partition can reset the partition state variable to its previous value or, in particularly critical situations, delete it completely. During the runtime of computing system 1, both avionics computers 5 regularly share values ​​of their partition state variables with each other. If one of the two avionics computers 5 fails, the other avionics computer 5, which remains functional, can execute the volatile partitions of the failed avionics computer 5. In doing so, the most recent possible value of the partition state variable of the partition executed on the failed avionics computer 5 is used for the new partition executed on the remaining avionics computer 5, with the same functionality as the partition previously executed on the now failed avionics computer 5.

[0046] 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 exemplary embodiments 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) comprises a plurality of avionics computers (5) and is designed to assign computing tasks to be executed to the avionics computers (5) in the form of volatile partitions, wherein the volatile partitions are each characterized in that they are started upon a respective trigger signal and are terminated by their respective generation of a current return value of a return variable that is identical for each execution of a plurality of sequential executions and is respectively predefined for them, so that over a continuous 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 outputting its calculated return value, wherein the computing system (1) has a respective memory for a volatile partition assigned to the respective memory,which can be written to and / or read from the respective volatile partition and serves to keep at least one return value of the return variable and / or a value of a defined partition state variable of the volatile partition assigned to the memory stored for at least a predetermined time.

2. Computing system according to claim 1, wherein each of the avionics computers (5) has its own orchestration unit, each of which is designed to manage at least one memory.

3. Computing system according to one of the preceding claims, wherein the computing system (1) is designed to use, upon detection of an error in one of the avionics computers (5) during its execution of a first volatile partition, a return value and / or value of the partition state variable determined before the error was detected and stored in the associated memory to continue the functionality of the first volatile partition in a second partition with the functionality of the first volatile partition on another avionics computer (5).

4. Computing system according to one of the preceding claims, wherein the computing system (1) is designed to process the return values ​​and / or To continuously transmit values ​​of the partition state variable of the memory for all volatile partitions of an avionics computer (5) to at least one other avionics computer (5).

5. Computing system according to claim 4, wherein the respective other avionics computer (5) is designed to store the return values ​​and / or values ​​of the partition state variable itself received from the transmitting avionics computer (5) for a predetermined time.

6. Computing system according to one of the preceding claims, wherein the computing system (1) is designed to reset, upon detection of an error during the execution of a volatile partition, this volatile partition to its most recent stored return value and / or its most recent value of its partition state variable.

7. Computing system according to one of the preceding claims, wherein the computing system (1) has a dedicated monitoring partition which is designed to analyze, by means of a content of a memory, the state of the volatile partition which generated the content of the memory.

8. Computing system according to claim 7, wherein the monitoring partition is designed to check the state and / or the contents of the memory for integrity and, in the event of a lack of integrity, to completely reset the associated volatile partition or to reset it to a previously stored return variable and / or a previously stored value of the partition state variable.

9. Method for executing software applications in an aircraft (3), wherein a computing system (1) with a plurality of avionics computers (5) is used and computing tasks to be executed are assigned to the avionics computers (5) in the form of volatile partitions, wherein the volatile partitions are each characterized in that they are started upon a respective trigger signal and are terminated by their respective generation of a current return value of a return variable that is the same for each execution of a plurality of sequential executions and is respectively predefined for them, so that over a continuous runtime of the computing system (1), a respective one of the volatile partitions is newly is started and is terminated again after outputting its calculated return value, wherein respective memories are used in the computing system (1), which are each assigned to a volatile partition and which can be written to and / or read from the respective volatile partition and which store at least one return value of the return variable and / or a value of a defined partition state variable of the volatile partition assigned to the memory, at least for a predetermined time.

Images