Functional partitions with dedicated snapshot storage in integrated modular avionics

Abstract

The invention relates to a computing system (1) with a plurality of avionics computers (5) for an aircraft (3), wherein the computing system (1) assigns volatile partitions to the avionics computers (5), which partitions are started in response to a respective trigger signal and terminated by their respective generation of a current 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 at least for a predetermined time.

Description

The invention relates to a computing system for executing software applications in an aircraft, and to a method for executing software applications in 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 are executed on avionic computers of the IMA platform for isolation 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.If such a conventional partition is executed on an avionic computer of a computing system designed as an IMA platform, which enters a faulty state, or if a partition is provided for an avionic computer that is already defective at the start, the functionality to be provided by this partition is initially eliminated. In order to ensure the functionality nevertheless, the following possibilities conventionally exist: replicas of partitions can be executed simultaneously on different avionic computers. However, this has the disadvantage that the computational power required for this, the power consumption and the weight of the computing system with the avionic computers increases linearly with the number of replicas. Furthermore, synchronization of the internal states of the replicas is only possible with difficulty, since the semantics of the respective state of the individual partitions of an orchestration unit is not known. Another possibility is to migrate an essential partition to another avionic computer, a target avionic computer, in the event of a defect in an avionic computer. For this purpose, not only must the program code for the partition to be executed be present on each potential target avionic computer, because of the need for predefined time slots and communication channels, these must be known for each possible migration at the design time. The internal state of such a migrated partition generally cannot be restored because it cannot be guaranteed that a byte-like copy on another avionic computer will have the same semantics even if both avionic computers are structurally the same.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 / Bre 18a. pdf The 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 has 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 in response to a respective trigger signal and are ended by their respective generation by the computing system, in particular an orchestration unit, of a current return value of a return variable which is the same for each execution of a plurality of sequential executions and predefined for them in each case, such that a respective one of the volatile partitions is restarted at a plurality of times over a contiguous runtime of the computing system and is ended again after their calculated return value has been output, wherein the computing system has a respective memory for a volatile partition assigned to the respective memory, which can be written and / or read out 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 predefined time.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 partition state variable is not definable in advance, since it is generally unpredictable what value the partition state variable will have upon the onset of pause, rather there is a generally unpredictable snapshot whose random access memory state is partially or completely lost. Such a conventional partition can generally only be ended (as opposed to being paused) during runtime (for example during flight operation of the aircraft) if, for example, a fault is detected and a 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 predefined category of a return variable, the required memory requirement for this is very readily predictable, in contrast to the method carried out in the prior art, since each termination of the repeatedly executed partition is a new, current calculation of a return value of the predefined return variable.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, preferably at least insofar as its execution 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 module 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 value of a partition state variable can thus be more easily transmitted to another orchestration unit in a preferably applied orchestration unit.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, in particular, that the program flow is oriented to pipelines, i.e. that a return value of one volatile partition can be the call parameters of another volatile partition, so that a 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). Also, a budget for utilizing a CPU may be defined by resource allocation by the volatile partition.In the event of a fault, the use of volatile partitions allows a volatile partition concerned to be migrated to another avionic computer, it being possible for its most recent return value of the return size and / or its most recent value of the defined partition state size, i.e. as a persistent state, to be retained.The return size may be a value or value tuple of a variable that is / is obtained in terms of a final result of the execution of a partition. The partition state variable is in particular a current state of a random access memory of an avionics computer, on which a respective memory area is assigned to a respective partition and is reserved for the latter at least temporarily.For the purpose of handover capability and snap-location formation of the relevant values, a memory separate from the random access memory is provided, or a dedicated memory area in the random access memory, briefly called "memory", to store the most recent return value of the return size and / or the most recent value of the defined partition state size and optionally further past corresponding values. The random access memory is part of the Von Neumann architecture and serves as a processor for volatile data storage. The memory for temporarily storing said values is at least logically separated therefrom, and is available from the system in atomic transactions.This has the advantage that the contents of the memory are always consistent, since interrupted writes cannot leave the memory in an undefined state as an incomplete transaction. Transactions may be performed, for example, at the end of each successfully executed volatile partition, or else if the volatile partition explicitly requests a transaction by an internal function call. In the case of a non-successfully executed volatile partition, the most recent correct partition state variable may be used in the sense of a snapshot that does not adversely affect the next execution.Since volatile partitions are known to be ready to execute and / or write, a value of their partition state size can be safely copied, migrated, and interpreted in the sense of a snapshot. An additional advantage is that a volatile partition can be reset to a previous partition state size.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 obtained from a functional unit of the aircraft.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.In this case, it may also occur that a partition requires specific input values. Several ways of entering the input value can be considered. If the required input value was generated some time before by another volatile partition, it is assumed that each volatile partition receives information about a time limit at the design time, for which time duration its return values are valid. It may also be that the required input value must be generated by another volatile partition. For this purpose, there is the possibility that the orchestration unit must execute all dependencies before the volatile partition which is actually required in time, so that all necessary input values are present at the required time. This also applies to the dependencies of the dependencies. For this purpose, the orchestration unit would then have to calculate how much earlier all necessary volatile partitions must be executed, and this depending on the maximum execution times of the respective partitions.Advantageously, output values of volatile partitions are given a time limit which specifies how long the respective return value is allowed to be used, so that this volatile partition does not have to be executed if its value is still within the limit. This limitation should be set at design time. It is also possible that the volatile partition itself determines the time limit for each execution.According to a further advantageous embodiment, each of the avionic computers has its own orchestration unit, which is each designed to manage at least one memory. Preferably, moreover, each of the avionic computers has its own memory, so that an orchestration unit preferably manages exactly one memory. Nevertheless, one or more partitions may be executed on each of the avionics computers. Advantageously, a plurality of memories is then provided, one memory for each partition.According to a further advantageous embodiment, the computing system is designed, when a fault is detected by one of the avionic computers when it executes a first volatile partition, to use a return value and / or value of the partition state variable, which is determined before the fault is detected and stored in the associated memory, for continuation of the functionality of the first volatile partition in a second partition with the functionality of the first volatile partition on another avionic computer.According to a further advantageous embodiment, the computing system is designed to transmit the return values and / or values of the partition state variable of the memories for all volatile partitions of an avionics computer continuously to at least one other avionics computer.As a result, in the event of a defect in an avionic computer, a most up-to-date state of a volatile partition on another avionic computer can be continued.According to a further advantageous embodiment, the respective other avionics computer is designed to store the return values and / or values of the partition state variable received from the sending avionics computer even for a predefined time.According to another advantageous embodiment, the computing system is configured to, upon detection of an error in execution of a volatile partition, reset that volatile partition to its most recently stored return value and / or its most recently value of its partition state size.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 that volatile partition which has generated the content of the memory.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, if there is a lack of integrity, to reset the associated volatile partition completely or to reset it to a previously stored return variable and / or a previously stored value of the partition state variable.A further aspect of the invention relates to a method for executing software applications in an aircraft, wherein a computing system having 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 on a respective trigger signal and are ended by their respective generation of a current return value of a return variable which is the same for each execution of a plurality of sequential executions and is predefined for them in each case, such that a respective one of the volatile partitions is restarted at a plurality of times over a continuous runtime of the computing system and is ended again after output of 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 store the 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 predefined time.Advantages and preferred refinements of the proposed method result from an analog and analogous transfer 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 : An aircraft having a computing system for executing software applications in the aircraft according to an exemplary embodiment of the invention. FIG. 2 : The computing system of FIG. 1 schematically.FIG. 1 shows a computing system 1 for executing software applications in an aircraft 3. The computing system 1 therefore forms a platform according to the concept of integrated modular avionics. The computing system 1 executes volatile partitions on a plurality of avionic computers 5. 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. 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 the respective volatile partition and serves to keep at least one return value of the return variable and / or one value of a defined partition state variable of the volatile partition assigned to the memory stored at least for a predefined time. Further properties are explained with the aid of FIG. 2.FIG. 2 shows the computing system 1 of FIG. 1 in schematic more detail. The computing system 1 has two avionic computers 5, each of which executes a volatile partition that uses less than 40% of the available CPU resources of a respective avionic computer 5 with its respective deadline. Both avionics computers 5 have more than 60% idle time. All partitions are expected to be able to meet their deadlines in 99% of the number of executions, the remaining one percent of which has no critical impact on flight safety. In addition to this respective volatile partition per avionic computer 5, a respective additional health monitoring partition can optionally be provided, which continuously consumes less than 10% of the available CPU resources of a respective avionic computer 5. After each execution of a volatile partition, it receives the memory content of both memories of the avionic computers 5 provided as snapshot in order to check the respective memory contents for errors and / or plausibility. However, this exemplary tight deadline is expected to cause the deadlines to be exceeded at irregular intervals. In these cases, the affected volatile partition is scheduled, re-executed, and when re-executed, its most recent value of its partition state size is used in the sense of snapshot to continue re-execution with the most recent value of the partition state size. The additional health monitoring partition checks the respective value of the partition state size of a respective partition after each execution of the partition. Should the respective value not be plausible or even damaged, the health monitoring partition can reset the partition state variable to the preceding value or completely delete it in particularly critical situations. During the runtime of the computing system 1, both avionic computers 5 periodically share values of their partition state variables with one another. If one of the two avionic computers 5 fails, the respective other avionic computer 5, which still remains as more functional, can carry out the volatile partitions of the failed avionic computer 5 with it. In this case, the most recent value of the partition state size of the partition executed on the failed avionic computer 5 is used for the new partition executed on the remaining avionic computer 5 having the same functionality as that of the partition which was previously executed on the now failed avionic computer 5.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) has a plurality of avionic computers (5) and is designed to assign computing tasks to be executed to the avionic 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 ended by their respective generation of a current return value of a return variable which is the same for each execution of a plurality of sequential executions and predefined for them respectively, such that a respective one of the volatile partitions is restarted at a plurality of times over a contiguous runtime of the computing system (1) and is ended again after their calculated return value has been output, wherein the computing system (1) has a respective memory for a volatile partition assigned to the respective memory, which can be written and / or read out 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 predefined time.The computing system according to claim 1, wherein each of the avionic computers (5) has its own orchestration unit, each of which is designed to manage at least one memory.The computing system according to any one of the preceding claims, wherein the computing system (1) is configured to, upon detection of a fault of one of the avionics computers (5) upon its execution of a first volatile partition, use a return value and / or value of the partition state variable determined before the detection of the fault 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).The computing system according to any one of the preceding claims, wherein the computing system (1) is configured to continuously transmit the return values and / or values of the partition state size of the memories for all volatile partitions of an avionic computer (5) to at least one other avionic computer (5).The computing system according to claim 4, wherein the respective other avionic computer (5) is configured to store the return values and / or values of the partition state variable received from the transmitting avionic computer (5) even for a predetermined time.The computing system according to any of the preceding claims, wherein the computing system (1) is configured to, upon detection of an error in execution of a volatile partition, reset that volatile partition to its most recently stored return value and / or its most recently value of its partition state size.The computing system according to any of the preceding claims, wherein the computing system (1) comprises a dedicated monitoring partition configured to analyze, by means of a content of a memory, the state of that volatile partition that generated the content of the memory.The computing system of claim 7, wherein the monitoring partition is configured to check the state and / or content of the memory for integrity and, if there is a lack of integrity, reset the associated volatile partition completely or reset it to a previously stored return size and / or a previously stored value of the partition state size.Method for executing software applications in an aircraft (3), wherein a computing system (1) having a plurality of avionic computers (5) is used and computing tasks to be executed are assigned to the avionic computers (5) in the form of volatile partitions, wherein the volatile partitions are each characterized in that they are started on a respective trigger signal and are ended by their respective generation of a current return value of a return size which is the same for each execution of a plurality of sequential executions and is predefined for them in each case, such that a respective one of the volatile partitions is restarted at a plurality of times over a contiguous run time of the computing system (1) and is ended again after output of 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 store the 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 predefined time.

Images