[go: up one dir, main page]

DE102024104737B3 - Funktionale Partitionen in integrierter modularer Avionik - Google Patents

Funktionale Partitionen in integrierter modularer Avionik Download PDF

Info

Publication number
DE102024104737B3
DE102024104737B3 DE102024104737.2A DE102024104737A DE102024104737B3 DE 102024104737 B3 DE102024104737 B3 DE 102024104737B3 DE 102024104737 A DE102024104737 A DE 102024104737A DE 102024104737 B3 DE102024104737 B3 DE 102024104737B3
Authority
DE
Germany
Prior art keywords
computing system
volatile
partition
partitions
avionics
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE102024104737.2A
Other languages
English (en)
Inventor
Sven Friedrich
Wanja Zaeske
Umut Durak
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Deutsches Zentrum fuer Luft und Raumfahrt eV
Original Assignee
Deutsches Zentrum fuer Luft und Raumfahrt eV
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Deutsches Zentrum fuer Luft und Raumfahrt eV filed Critical Deutsches Zentrum fuer Luft und Raumfahrt eV
Priority to DE102024104737.2A priority Critical patent/DE102024104737B3/de
Priority to PCT/EP2025/054315 priority patent/WO2025176653A1/de
Application granted granted Critical
Publication of DE102024104737B3 publication Critical patent/DE102024104737B3/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061Partitioning or combining of resources
    • G06F9/5077Logical partitioning of resources; Management or configuration of virtualized resources
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/45575Starting, stopping, suspending or resuming virtual machine instances

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Hardware Redundancy (AREA)

Abstract

Die Erfindung betrifft ein Rechensystem (1) zur Ausführung von Software-Anwendungen in einem Flugzeug (3), wobei das Rechensystem (1) dazu ausgeführt ist, zur zumindest zeitlichen Ressourcenzuteilung von einem oder mehreren Rechen-Prozessen zu im Rechensystem (1) verfügbaren physischen Ressourcen flüchtige Partitionen zu verwenden, wobei eine jeweilige der flüchtigen Partitionen durch ein Auslösesignal gestartet wird und auf ihre Erzeugung eines aktuellen Rückgabewerts einer, für jede Ausführung einer Vielzahl von sequenziellen Ausführungen gleichen, Rückgabegröße beendet wird, so dass über eine zusammenhängende Laufzeit des Rechensystems (1) hin eine jeweilige der flüchtigen Partitionen zu einer Vielzahl von Zeitpunkten neu gestartet wird und nach Ausgabe ihres berechneten Rückgabewerts wieder beendet wird.

Description

  • Die Erfindung betrifft ein Rechensystem zur Ausführung von Software-Anwendungen in einem Flugzeug, sowie ein Verfahren zum Ausführen von Anwendungen auf einer integrierten modularen Avionik eines Flugzeugs.
  • Die folgenden Aussagen ergeben sich nicht notwendigerweise aus einem bestimmten Dokument aus dem Stand der Technik, sondern sind allgemein bekanntes Fachwissen im technischen Gebiet und ergeben sich durch fachmännische Überlegungen:
    • Eine einfache, jedoch im Allgemeinen ineffiziente, Avionik-Architektur stellt die Verwendung mehrerer LRUs dar (LRU ist eine Abkürzung für „line-replaceable unit“). Dabei wird für jede Anwendung in einer eigenen LRU eine eigene Recheneinheit bereitgestellt, die beispielsweise eine eigene Energieversorgung, eine eigene CPU (Abkürzung für „Central Processing Unit“) und eine Netzwerk-Schnittstelle (ein sogenanntes I/O-Interface) aufweist. Während sich mit einer solchen Architektur Anwendungen der Avionik (beispielsweise ein automatisches Landessystem, ein Steuersystem für die Hydraulik, ein Autopilot für den Reiseflug, ein Flug-Management-System, eine Sensorsignalbereitstellung, eine Displaysteuerung, etc.) leicht partitionieren (im Wortlaut der DO-178-C) und redundant ausführen lassen, sowie ein physischer Austausch einer einzelnen LRU unschwer ermöglicht wird, ist im Allgemeinen eine solche Architektur ineffizient und benötigt die Bereitstellung mehr physischer Ressourcen als unbedingt notwendig, beispielsweise unnötige viele separate Energieversorgungsmodule.
  • Zur Behebung dieser Ineffizienz und zur Erhöhung der Flexibilität bezüglich der zu implementierenden Anwendungen in der Ausführung auf der Avionik wird daher seit einigen Jahrzehnten das Konzept der integrierten modularen Avionik (abgekürzt „IMA“) verfolgt. Hierbei werden mehrere Flugzeug-Anwendungen auf derselben Plattform untergebracht, das heißt physische Ressourcen von mehreren Anwendungen geteilt genutzt. Die Plattform umfasst eine physische Lösung (Hardware) sowie eine zum Betrieb der Hardware notwendige Software, typischerweise aufweisend ein Betriebssystem, eine Zustandsüberwachung, Treiber, ein Board-Support-Paket und Dienstprogramme. Die physische Lösung wird beispielsweise durch ein sogenanntes „Integrated Rack“ oder „Cabinet“ realisiert, welche eine integrierte physische Plattform bietet, und anstelle von einzelnen LRUs eine Einheit gemeinsam genutzter physischer Ressourcen aufweist.
  • Die Plattform stellt solchen High-Level-Anwendungen, welche zur direkten Realisierung der Flugzeug-Funktionen implementiert werden, Systemdienste zur Verfügung, verwaltet Anwendungsschnittstellen, verwaltet die gemeinsamen Ressourcen und sorgt für die Isolierung im Rahmen der Partitionierung der jeweiligen Anwendungen voneinander. Hierfür wird den Anwendungen typischerweise eine dokumentierte API (Abkürzung für „application program interface“) zur Verfügung gestellt, d. h. eine Software-Schnittstelle, um zwischen einem ersten Programm (der Anwendung) und einem zweiten Programm (insbesondere einem Betriebssystem der Plattform) eine definierte Kommunikation ausführen zu können.
  • Typischerweise werden sogenannte Partitionen als Isolationsprimitiv genutzt, welche sowohl zeitlich als auch hinsichtlich ihrer Ressourcenzuteilung (beispielsweise speichertechnisch) vollständig voneinander gekapselt sind. Die integrierte modulare Avionik zielt darauf ab, dass sich die Anwendungsentwickler auf die Anwendungsschicht konzentrieren können, während ein Plattformentwickler die Plattformverfügbarkeit, Integrität und Sicherheitsfunktionen sicherzustellen hat. Im Gegensatz zum Anwendungsentwickler obliegt es dem Plattformentwickler, eine Konfiguration bereitzustellen, die den oben genannten Anforderungen entspricht, sodass der Anwendungsentwickler lediglich Verantwortung für die Anwendung trägt, und dabei lediglich die API zur IMA-Plattform nutzt.
  • Das im Stand der Technik etablierte Ausführungsparadigma für IMA-Plattformen sieht vor, dass Partitionen zur Isolation in vordefinierten Zeitfenstern auf Computern der IMA-Plattform ausgeführt werden. Diese Partitionen werden dabei von einem semantischen Standpunkt aus betrachtet kontinuierlich ausgeführt, am Ende ihres Zeitfensters im eingefrorenen Zustand pausiert und zum Start ihres nächsten Zeitfensters fortgeführt.
  • Eine solche Isolation der Partitionen kann nur durch vorher festgelegte Kommunikationskanäle durchbrochen werden. Das Problem dieser Kommunikationskanäle ist jedoch, dass durch die kontinuierliche Ausführung der Partitionen häufig auf neue Nachrichten gewartet werden muss, wobei die Partitionen (oder einzelne Prozesse innerhalb einer Partition) blockieren. Hierbei werden wiederholt Systemressourcen (d. h. insbesondere CPU Zyklen) ineffizient genutzt. Dies gilt auch für andere Plattformen, die nicht unter die IMA-Architektur fallen, wie Fly-By-Wire Systeme.
  • Die folgende Veröffentlichung beschreibt, wie bei einer Partitionierung geeignete Hardware- und Softwaremechanismen verwendet werden, um eine starke Fehlereindämmung in integrierten Avionik-Architekturen wiederherzustellen. Dabei werden Anforderungen an die Partitionierung, die Mechanismen für ihre Realisierung und die Probleme bei der Gewährleistung der Partitionierung untersucht. Da bei der Partitionierung einige Bedenken hinsichtlich der Computersicherheit bestehen, werden Sicherheitsmodelle überprüft und mit den Bedenken der Partitionierung verglichen: Rushby, J.: Partitioning in Avionics Architectures: Requirements, Mechanisms, and Assurance, NASA/CR-1999-209347, 1999, Langley Research Center, Document ID 19990052867, https://ntrs.nasa.gov/citations/19990052867.
  • Die folgende Veröffentlichung beschreibt außerdem eine Umschau zu einem Stand der Forschung zur Zeit- und Raumpartitionierung (TSP) für Raumfahrzeug-Avionik: Bredereke, J.: A Survey of Time and Space Partitioning for Space Avionics. In: „DASIA 2018 Data Systems In Aerospace". (Oxford, UK, 29th-31st May 2018). Session A10: TSP including Multicore & PU. Eurospace, 2018; City University of Applied Sciences Bremen. https://homepages.on.hs-bremen.de/-jbredereke/downloads/Bre18a.pdf Aufgabe der Erfindung ist es, eine verbesserte Avionik Plattform bereitzustellen.
  • Die Erfindung ergibt sich aus den Merkmalen der unabhängigen Ansprüche. Vorteilhafte Weiterbildungen und Ausgestaltungen sind Gegenstand der abhängigen Ansprüche.
  • Ein erster Aspekt der Erfindung betrifft ein Rechensystem zur Ausführung von Software-Anwendungen in einem Flugzeug, wobei das Rechensystem dazu ausgeführt ist, zur zumindest zeitlichen Ressourcenzuteilung von einem oder mehreren Rechen-Prozessen zu im Rechensystem verfügbaren physischen Ressourcen flüchtige Partitionen zu verwenden, wobei eine jeweilige der flüchtigen Partitionen durch ein Auslösesignal gestartet wird und auf ihre Erzeugung eines aktuellen Rückgabewerts einer, für jede Ausführung einer Vielzahl von sequenziellen Ausführungen gleichen, Rückgabegröße beendet wird, so dass über eine zusammenhängende Laufzeit des Rechensystems hin eine jeweilige der flüchtigen Partitionen zu einer Vielzahl von Zeitpunkten neu gestartet wird und nach Ausgabe ihres berechneten Rückgabewerts wieder beendet wird.
  • Wie eingangs erläutert ist es nach dem Stand der Technik üblich, beim Erreichen einer durch die Plattformkonfiguration definierten zeitlichen Grenze den in der Partition ausgeführten Prozess oder die ausgeführten Prozesse einzufrieren und zu pausieren, bis ein neues Zeitbudget zur Verfügung steht, und die pausierte Partition weiterzuführen. Es wird demnach eine einzige Partition über die gesamte Laufzeit semantisch kontinuierlich ausgeführt, d. h. über die gesamte Laufzeit mit Unterbrechungen ausgeführt. Nach einer jeweiligen Unterbrechung muss damit eine Partition exakt in dem Zustand fortgeführt werden, in dem sie nach Ablauf des Zeitbudgets beendet wurde. Dabei ist ein Speicherzustand jedoch im Voraus nicht definierbar, da im Allgemeinen nicht vorhersagbar ist, welchen Speicherzustand die Partition beim Einsetzen der Pausierung aufweisen wird, vielmehr liegt ein im Allgemeinen nicht vorhersagbarer Snapshot vor, wobei ihr Speicherzustand teilweise oder ganz verloren geht. Eine Partition kann während der Laufzeit (beispielsweise während eines Flugbetriebs des Flugzeugs) im Allgemeinen nur dann beendet werden (im Gegensatz zum pausiert werden), wenn beispielsweise ein Fehler festgestellt wird, und ein Neustart der Partition versucht wird.
  • Im Gegensatz dazu wird mit dem vorliegenden Rechensystem und dem dadurch ausgeübten Verfahren nicht nominal eine Partition über die gesamte Laufzeit vielfach pausiert ausgeführt, sondern von Vornherein intendiert vielfach echt neu gestartet und wieder vollständig beendet. Die Beendigung wird dadurch ausgelöst, dass die ausgeführte Partition zu einem Ergebnis gekommen ist, welches sich in der Ausgabe eines Rückgabewerts äußert. Da der Rückgabewert einer vorgegebenen Kategorie von einer Rückgabegröße entspricht, ist im Gegensatz zum im Stand der Technik wie oben beschriebenen ausgeführten Verfahren der benötigte Speicher dafür sehr wohl vorhersagbar, da es sich mit jeder Beendigung der wiederholt ausgeführten Partition um eine neue aktuelle Berechnung eines Rückgabewerts der vorgegebenen Rückgabegröße handelt.
  • Die Rückgabegröße kann dabei in einem Datentyp definiert sein, beispielsweise einem numerischen Skalar, oder ein Array sein, ein String, ein speziell definierter Datentyp bspw. aus numerischen Werten und/oder aus Strings oder eine andere Menge von verschiedenen Datentypen sein, wobei nicht jede Variable der Rückgabegröße in jeder Ausführung mit einem tatsächlichen Wert besetzt sein muss. Entscheidend ist, dass die Rückgabegröße eine maximale Menge von Rückgabewerten im Sinne eines Ergebnisses eines in der jeweiligen flüchtigen Partition ausgeführten Algorithmus definiert; die Partition kommt dabei wie eine Funktion zum Abschluss und liefert den Rückgabewert im Sinne eines Return-Wertes. Der Rückgabewert ist der jeweils aktuell ermittelte Wert oder Wertemenge der Rückgabegröße.
  • Bevorzugt bildet das Rechensystem eine Plattform nach dem Konzept der integrierten modularen Avionik aus.
  • Die Beendigung der jeweiligen flüchtigen Partition wird dabei durch den Erhalt dieses Rückgabewertes einer jeweiligen flüchtigen Partition selbst ausgelöst, zumindest sofern sie unterhalb eines vorgegebenen maximalen Zeitbudgets liegt. Das Zeitbudget und die Verfügbarkeit der physischen Ressourcen ist entsprechend einer erwarteten Rechenzeit auszulegen. Neben der vorhersagbaren Speichergröße beim Beendigen der jeweiligen flüchtigen Partition wird ein weiterer Vorteil erreicht: Die jeweilige flüchtige Partition kann insbesondere im Fehlerfall leichter auf einen anderen Avionik-Computer der integrierten modularen Avionik übertragen werden, da ein jeweiliger Rückgabewert ein wohldefiniertes Ergebnis der Ausführung einer flüchtigen Partition ist. Außerdem kann somit leichter ein Zustand in der zunächst angewendeten Orchestrierungseinheit (insbesondere ein Hypervisor) auf eine andere Orchestrierungseinheit (insbesondere ein Hypervisor) übertragen werden. Dies kann beispielsweise mittels managed memory erfolgen.
  • Zur Orchestrierung, d. h. zur überlagerten Organisation, der Ausführung von Partitionen wird typischerweise eine Orchestrierungseinheit (ein Hypervisor) verwendet. Wird ein Fehlerfall festgestellt, kann die Ausführung einer flüchtigen Partition unter einer Orchestrierungseinheit eines Avionik-Computers des Rechensystems einer anderen Orchestrierungseinheit eines anderen Avionik-Computers unterstellt werden.
  • Eine flüchtige Partition weist zwar die Eigenschaften einer konventionellen Partition auf, untereinander gekapselt und isoliert voneinander zu sein, um die Sicherheit der Ausführung und eine hohe Zuverlässigkeit bei der Ausführung von Anwendungen sicherstellen zu können. Andererseits ist eine flüchtige Partition einem funktionalen Ausführungsparadigma nachgebildet, und wird durch entsprechende Aufrufparameter und Ausgabeparameter charakterisiert.
  • Der Ausführungslebenszyklus einer flüchtigen Partition reicht damit nur bis zur Erfüllung der Aufgabe oder Erreichung einer vorgegebenen maximalen Ausführungszeit, um ein vorgegebenes Zeitbudget nicht zu überschreiten (da sonst andernfalls unter Umständen weitere Partitionen ebenfalls kein ausreichendes Zeitbudget zur Verfügung hätten).
  • Das funktionale Ausführungsparadigma der flüchtigen Partitionen sieht vor, dass sich der Programmfluss an Pipelines orientiert, d. h., dass ein Rückgabewert einer flüchtigen Partition der Aufrufparameter einer anderen flüchtigen Partition sein kann, sodass eine abhängige sequenzielle Ausführung der flüchtigen Partitionen durchgeführt wird. Der Begriff der Pipeline ist eine Analogiebildung zu einer physischen Pipeline, bei der nacheinander Material durch einen vordefinierten Transportweg bewegt wird. Insbesondere kann der Rückgabewert einer flüchtigen Partition der Aufrufparameter der gleichen, jedoch sequentiell zu einem neuen Zeitpunkt anschließend ausgeführten Partition, oder aber einer anderen flüchtigen Partition sein.
  • Bevorzugt definiert die jeweilige flüchtige Partition nicht nur eine zeitliche Ressourcenzuteilung, sondern auch eine physische Ressourcenzuteilung, d. h. beispielsweise eine Speicherplatzreservierung in einem flüchtigen Speicher (RAM). Auch kann ein Budget zur Nutzung einer CPU eines jeweiligen Avionik-Computers von der Ressourcenzuteilung durch die flüchtige Partition definiert werden.
  • Gemäß einer vorteilhaften Ausführungsform weist das Rechensystem eine Vielzahl von Avionik-Computern auf, wobei das Rechensystem dazu ausgeführt ist, mittels einer vorgegebenen Konfigurations-Logik eine Zuordnung einer jeweiligen Ausführung einer jeweiligen Partition zu einem jeweiligen der Avionik-Computer zu bestimmen, wobei die Konfigurations-Logik dazu eingerichtet ist, mit einer Information über eine jeweilige Verfügbarkeit eines jeweiligen Avionik-Computers als Eingangsgröße die Zuordnung zu ermitteln.
  • In diesem Fall sind die physischen Ressourcen unterteilt in einzelne Avionik-Computer. Die vorgegebene Konfigurations-Logik dient dazu, die Ausführung der Partitionen den physischen Ressourcen so zuzuweisen, dass bestimmt ist, welche Partition auf welchem der Avionik-Computer ausgeführt wird. Zudem kann der Ausführungszeitpunkt, d. h. der Startzeitpunkt, einer jeweiligen Partition mittels der Konfigurations-Logik bestimmt werden.
  • Die Konfigurations-Logik kann als Konfigurationsfunktion implementiert werden. Die Konfigurations-Logik ist insbesondere eine Determinismusfunktion, die unter gleicher Eingangsgröße das gleiche Ergebnis liefert, sie ist daher deterministisch eingerichtet. Als Eingangsgröße fungieren Systeminformationen, die mindestens die Information enthalten, welcher der Avionik-Computer zu einem jeweiligen Zeitpunkt funktionsfähig (d. h. ohne erkannten Fehler) ist.
  • Gemäß einer weiteren vorteilhaften Ausführungsform ist das Rechensystem dazu ausgeführt, mittels der Konfigurations-Logik und auf Basis der jeweiligen Verfügbarkeit eines jeweiligen Avionik-Computers eine Unterauswahl von regulär auszuführenden Partitionen zu treffen, und nur die Partitionen aus der Unterauswahl auf ihren jeweils gemäß Zuordnung zugewiesen Partitionen auszuführen.
  • Bevorzugt wird für jeden der Avionik-Computer eine eigene Orchestrierungseinheit vorgesehen, die die vorgegebene Konfigurations-Logik nutzen kann um für sich zu bestimmen, welche der ursprünglich und regulär zur Ausführung vorgesehenen Partitionen abhängig von der Zahl der nach einem Fehlerfall noch fehlerfrei zur Verfügung stehenden Avionik-Computer noch auszuführen sind. Dadurch wird eine Unterauswahl der ursprünglich und regulär auszuführenden Partitionen getroffen, und nur die Partitionen aus der getroffenen Unterauswahl auf gemäß der Konfigurations-Logik ausgewählten Avionik-Computern noch ausgeführt. Eine Strategie, nach der die Konfigurations-Logik ausgebildet sein kann, ist, dass möglichst viele Partitionen mit Funktionalitäten mit jeweils hoher Sicherheitskritikalität ausgeführt werden.
  • Durch den Determinismus der Konfigurations-Funktion kann diese den Avionik-Computern unabhängig voneinander ermöglichen, die richtige Entscheidung zu treffen, welche der Partitionen von Ihnen zu welchem Zeitpunkt ausgeführt werden muss, um das Rechensystem mit möglichst hoher Sicherheit für das Flugzeug mit dem Rechensystem zu betreiben. Die Richtigkeit der Auswahl kann durch einen Konsensusalgorithmus (zum Beispiel durch einen byzantinischen Fehlertoleranz Algorithmus) oder über die Konfigurations-Logik selbst garantiert werden.
  • Im Falle von einem oder mehreren fehlerbehafteten Avionik-Computern oder unter dem Einfluss eines Angriffs können alle weiterhin verbleibenden funktionsfähigen Avionik-Computer entscheiden, welche Partitionen sie ausführen müssen. Hierdurch kann im Fehlerfall eines oder mehrerer der Avionik-Computer die Funktionalität des Gesamtsystems weiterhin aufrechterhalten werden. Es besteht weiterhin vorteilhaft die Möglichkeit der Zertifizierung, da die Konfigurations-Logik in ihrer deterministischen Auslegung insbesondere bereits zur Designzeit festgelegt wird und invariant verbleibt. Dies ermöglicht eine Verifikation vor Inbetriebnahme.
  • Konventionell im Stand der Technik definierte Partitionen werden gemäß einer Konfiguration, welche zur Designzeit definiert wird, einem jeweiligen Avionik-Computer statisch zugeteilt. Im Falle eines defekten Avionik-Computers kann die vorher erbrachte Funktionalität nur durch eine Replika- Partition auf einem anderen Avionik-Computer gewährleistet werden. Nachteilig hieran ist, dass beim Ausfall aller Avionik-Computer mit Replika einer Partition die Funktionalität dieser Partition überhaupt nicht mehr erbracht werden kann. Im Gegensatz dazu stellt die oben erwähnte Konfigurations-Logik einen Determinismus bereit, insbesondere durch eine systemspezifische Konfigurations-Funktion, welcher beschreibt, auf welchem Avionik-Computer eine jeweilige Partition ausgeführt werden soll, solange der Nominalfall vorherrscht und welche Anpassung vorgenommen wird, wenn ein oder mehrere defekte Avionik-Computer vorliegen. Die Ausführung essenzieller Partitionen kann somit beweisbar garantiert werden. Außerdem erlangen auch nicht-replizierte Partitionen Ausfallsicherheit, wenn diejenigen der Avionik-Computer ausfallen, auf denen sie laufen. Eine Partition mit einer niedrigen Sicherheitskritikalität kann nämlich zugunsten einer Partition einer höheren Sicherheitskritikalität gestoppt werden, wenn derjenige Avionik-Computer, der die Partition mit höherer Sicherheitskritikalität ausführt, defekt ist.
  • Gemäß einer weiteren vorteilhaften Ausführungsform umfasst die Konfigurations-Logik einen Algorithmus zur Lösung eines Rucksack-Problems. Ein Rucksack-Problem ist ein in der Mathematik und Informatik bekanntes Optimierungsproblem, und wird auch „knapsack problem“ genannt. Abstrahiert geht es darum, das Problem zu lösen, aus einer Menge von Elementen, denen ein jeweiliger Kostenwert und ein jeweiliger Gütewert zugeordnet ist, eine derartige Kombination zu finden, dass die Summe der Gütewerte maximiert wird ohne einen vorgegebenen Grenzwert mit der Summe der Kostenwerte der ausgewählten Elemente zu überschreiten. Hierbei entspricht die Metapher des Rucksacks dem vorgegebenen Grenzwert.
  • Wird die Konfigurations-Logik als Lösung für ein solches Rucksack-Problem ausgelegt, so entspricht einem jeweiligen Rucksack und damit einem jeweiligen vorgegebenen Grenzwert die (Zeit-) Kapazitäten der Orchestrierungseinheiten des Rechensystems mit seinen Avionik-Computern. Die Elemente wie oben erläutert, entsprechen den Partitionen. Kostenwerte der Partitionen sind Zeitkosten, Gütewerte sind Prioritäten, die angeben, wie wichtig die Ausführung der jeweiligen Partition für eine möglichst sichere Ausführung des Rechensystems mit Hinblick auf den Flug des Flugzeugs mit diesem Rechensystem ist. Zur Lösung des Rucksack-Problems kann ein einfacher Greedy-Algorithmus angewendet werden, der dazu ausgelegt ist, möglichst immer die Partitionen mit der höchsten Priorität zu nehmen. Dies ist ein Beispiel für einen deterministischen Algorithmus, der immer dasselbe Ergebnis für gleiche Eingaben liefert.
  • Weist eine der Partitionen Abhängigkeiten auf, wenn zum Beispiel ihre Ausführung vom Ergebnis der Ausführung einer anderen Partition abhängig ist, müssen diese Abhängigkeiten auch in der Übertragung auf den „Rucksack“ berücksichtigt werden. Das bedeutet, dass die Abhängigkeiten in einen Rucksack gepackt werden müssen, wenn sie noch nicht in einem solchen liegen.
  • Wenn eine Orchestrierungseinheit ausfallen sollte, wird die (Zeit-)Kapazität des Rucksacks der Orchestrierungseinheit auf Null gesetzt. Hierdurch erhält man einen Algorithmus (die Konfigurations-Logik), der auf allen Orchestrierungseinheiten eines Gesamtsystems ausgeführt werden kann und allen dieselbe Konfiguration ausgibt.
  • Die einzige Eingabe, die notwendig ist, ist die Information, welche der Orchestrierungseinheiten aktuell ohne erkannten Fehlerfall verfügbar sind. Nach der Ausführung des Algorithmus kann jede noch ausgeführte Orchestrierungseinheit ihren Rucksack (ihre Konfigurations-Logik) für sich umsetzen.
  • Gemäß einer vorteilhaften Ausführungsform ist das Rechensystem dazu ausgeführt, eine nebenläufige Ausführung einer Vielzahl von Prozessen binnen zumindest einer der flüchtigen Partitionen auszuführen.
  • Die nebenläufige Ausführung betrifft eine Parallelität der Ausführung von elementaren oder höherwertigen Aufgaben. Voraussetzung zur nebenläufigen Ausführung einer Vielzahl von Prozessen innerhalb zumindest einer flüchtigen Partition ist die Unterstützung durch die Orchestrierungseinheit, welche für das Management der flüchtigen Partition zuständig ist. Vorteilhaft können so physische Ressourcen des Rechensystems unter Umständen besser ausgenutzt werden und eine schnellere Durchführung der Rechenergebnisse je Anwendung erreicht werden.
  • Gemäß einer weiteren vorteilhaften Ausführungsform ist das Rechensystem dazu ausgeführt, bei Feststellung eines Fehlers bei der Ausführung einer flüchtigen Partition eine neue, die fehlerhafte ersetzende, flüchtige Partition zu starten, wobei ein Aufrufparameter der neuen flüchtigen Partition der jüngste Rückgabewert der ersetzten Partition ist.
  • Die neue flüchtige Partition wird dabei bevorzugt auf einem, zum fehlerhaften Avionik-Computer redundanten, Avionik-Computer der integrierten modularen Avionik neu ausgeführt, d. h. auf diesen migriert. Dabei findet insbesondere eine Übergabe von der Orchestrierungseinheit des fehlerhaften Avionik-Computers auf die Orchestrierungseinheit des redundanten Avionik-Computers statt, um dort mit einer neuen konsekutiven Ausführung der flüchtigen Partitionen fortzufahren.
  • Gemäß einer weiteren vorteilhaften Ausführungsform ist das Rechensystem dazu ausgeführt, bei Überschreiten einer Zeitdauer einer Ausführung einer flüchtigen Partition über eine vorgegebene höchstzulässige Ausführungsdauer die Ausführung dieser flüchtigen Partition zu beenden.
  • Die höchstzulässige Ausführungsdauer entspricht einem vorgegebenen Zeitbudget, welches vorgesehen wird, um die physischen Ressourcen zeitlich rechtzeitig wieder freizugeben, um für weitere Partitionen entsprechende Ressourcen zur Verfügung zu stellen.
  • Gemäß einer weiteren vorteilhaften Ausführungsform liegt das Auslösesignal zum Start einer flüchtigen Partition dann vor, wenn ein Rückgabewert aus einer vorhergehenden Ausführung der flüchtigen Partition verfügbar ist, oder wenn ein Kommandosignal von einer Funktionseinheit des Flugzeugs erhalten wird.
  • Das Kommandosignal einer Funktionseinheit kann beispielsweise das Auftreten eines neuen, aktuellen Sensorsignals einer Sensoreinheit sein. Andere Quellen können beispielsweise ein LAN Netzwerkadapter, SPI, oder ein CAN Bus sein, welche entsprechende Aufrufparameter für eine flüchtige Partition bereitstellen können. Beispielsweise kann nach dem Erhalt eines neuen Sensorwerts eines zeitlich diskret messenden Sensors des Flugzeugs eine Berechnung notwendig sein, die im Sinne einer Anwendung auf der CPU einer IMA auszuführen ist. Der Erhalt des neuen Sensorwerts ist somit das Auslösesignal im Sinne des Kommandosignals des Sensors in der Rolle der Funktionseinheit, wonach die flüchtige Partition gestartet wird und eine entsprechende Anwendung in der flüchtigen Partition ausgeführt wird.
  • Wird von einer vorhergehenden Ausführung einer flüchtigen Partition ein Rückgabewert zur Verfügung gestellt, der von einer anschließend ausgeführten flüchtigen Partition als Aufrufparameter und Eingabewert analog einer Software-Funktion verwendet wird, entspricht dies dem oben beschriebenen Paradigma des Pipelining.
  • Gemäß einer weiteren vorteilhaften Ausführungsform ist das Rechensystem dazu ausgeführt, das Auslösesignal zeitabhängig vorzugeben, so dass der Start einer jeweiligen flüchtigen Partition durch Zeitauslösung erfolgt.
  • Hiermit wird insbesondere eine wiederholte periodische Ausführung einer flüchtigen Partition erreicht.
  • Gemäß einer weiteren vorteilhaften Ausführungsform ist das Rechensystem dazu ausgeführt, die Ausführung einer neuen flüchtigen Partition erst nach Ablauf einer vorgegebenen Pausenzeit zwischen zwei konsekutiven Ausführungen einer flüchtigen Partition zu starten.
  • Damit wiederum wird vorteilhaft erreicht, dass die flüchtigen Partitionen nicht zu häufig ausgeführt werden, und somit nicht unnötig physische Ressourcen belegt werden. Ein besonderer Vorteil hiervon wiederum ist, dass in einem asynchronen Betrieb dennoch Zeitgarantien ausgesprochen werden können.
  • Gemäß einer weiteren vorteilhaften Ausführungsform ist das Rechensystem dazu ausgeführt, einen ermittelten Rückgabewert einer flüchtigen Partition nur für eine vorgegebene maximale Validitätsdauer als Ergebnis der vorgegebenen Rückgabegröße zu halten.
  • Wenn die Rückgabegröße benötigt wird, kann der nun alte Wert nicht mehr genutzt werden und die flüchtige Partition muss erneut ausgeführt werden; bevorzugt wird in einem solchen Fall beim Überschreiten der maximalen Validitätsdauer eine neue flüchtige Partition zur Berechnung eines aktuellen Rückgabewerts ausgeführt.
  • Gemäß einer weiteren vorteilhaften Ausführungsform umfasst das Rechensystem eine Mehrkern-CPU und eine jeweilige flüchtige Partition definiert eine Zuteilung zu einem jeweiligen Kern der Mehrkern-CPU.
  • Während typischerweise bei einem Einkern- Prozessor eine jeweilige flüchtige Partition die Belegung des vollständigen Prozessors während ihrer zugewiesenen Ausführungszeit, d. h. ihres Zeitbudgets, erlaubt, kann eine flüchtige Partition die Verwendung von einem bestimmten oder mehreren Kernen eines Mehrkern-Prozessors definieren. Somit können auch mehrere flüchtige Partitionen zeitgleich, auf disjunkt zugeteilten Kernen, ausgeführt werden.
  • Ein weiterer Aspekt der Erfindung betrifft ein Flugzeug mit einem Rechensystem wie oben und im Folgenden beschrieben.
  • Ein weiterer Aspekt der Erfindung betrifft ein Verfahren zum Ausführen von Anwendungen auf einer integrierten modularen Avionik eines Flugzeugs, dadurch gekennzeichnet, dass zur zumindest zeitlichen Ressourcenzuteilung von einem oder mehreren Rechen-Prozessen zu in der integrierten modularen Avionik verfügbaren physischen Ressourcen flüchtige Partitionen verwendet werden, wobei eine jeweilige der flüchtigen Partitionen durch ein Auslösesignal gestartet wird und auf ihre Erzeugung eines aktuellen Rückgabewerts einer, für jede Ausführung einer Vielzahl von sequenziellen Ausführungen gleichen, Rückgabegröße beendet wird, so dass über eine zusammenhängende Laufzeit des Rechensystems hin eine jeweilige der flüchtigen Partitionen zu einer Vielzahl von Zeitpunkten neu gestartet wird und nach Ausgabe ihres berechneten Rückgabewerts wieder beendet wird, ohne zwischen den Ausführungen der Partitionen eingefroren und pausiert zu werden.
  • Vorteile und bevorzugte Weiterbildungen des vorgeschlagenen Flugzeugs bzw. des vorgeschlagenen Verfahrens ergeben sich durch eine analoge und sinngemäße Übertragung der im Zusammenhang mit dem vorgeschlagenen Rechensystem vorstehend gemachten Ausführungen.
  • Weitere Vorteile, Merkmale und Einzelheiten ergeben sich aus der nachfolgenden Beschreibung, in der - gegebenenfalls unter Bezug auf die Zeichnung - zumindest ein Ausführungsbeispiel im Einzelnen beschrieben ist. Gleiche, ähnliche und/oder funktionsgleiche Teile sind mit gleichen Bezugszeichen versehen.
  • Es zeigen:
    • 1: Ein ziviles Flugzeug mit einem Rechensystem zur Ausführung von Software-Anwendungen in dem Flugzeug gemäß einem Ausführungsbeispiel der Erfindung.
    • 2: Ein militärisches Flugzeug mit einem Rechensystem zur Ausführung von Software-Anwendungen in dem Flugzeug gemäß einem weiteren Ausführungsbeispiel der Erfindung.
    • 3: Ein Rechensystem mit zwölf Avionik-Computern und einer Konfigurations-Logik.
  • 1 zeigt ein Rechensystem 1 zur Ausführung von Software-Anwendungen in einem zivilen Passagier-Flugzeug 3. Im Rechensystem 1 ist ein Integrated Rack vorgesehen, welches Line Replaceable Modules (abgekürzt „LRM“) aufweist. Das Rechensystem 1 bildet daher eine Plattform nach dem Konzept der integrierten modularen Avionik aus. Das Rechensystem 1 hält einen Orchestrator, auch genannt Hypervisor, implementiert. Dieser weist die höchste Autorität unter allen Programmen im Rechensystem 1 auf, und organisiert flüchtige Partitionen. Die flüchtigen Partitionen umfassen eine zeitliche Ressourcenzuteilung und eine Ressourcenzuteilung zu Hardware-Ressourcen, um sicherheitskritische Anwendungen auf dem Rechensystem 1 zeitkritisch ausführen zu können. Die flüchtigen Partitionen im Gegensatz zu konventionellen Partitionen zeichnen sich dadurch aus, dass jeweilige der flüchtigen Partitionen durch ein Auslösesignal gestartet werden und auf ihre Erzeugung eines aktuellen Rückgabewerts einer, für jede Ausführung einer Vielzahl von sequenziellen Ausführungen gleichen, Rückgabegröße beendet werden. Dies geschieht zu einer sehr großen Vielzahl von Zeitpunkten, beispielsweise mehrfach in jeder Sekunde der Laufzeit des Rechensystems 1. Eine jeweilige flüchtige Partition wird daher laufend gestartet und nach Ausgabe ihres Rückgabewerts wieder beendet. Sie entspricht daher dem Paradigma einer Funktion, welche aufgerufen wird, und der ein Eingabewert übergeben wird, sodass diese nach ausgeführten Berechnungen einen Ausgabewert ausgeben kann. Über eine zusammenhängende Laufzeit des Rechensystems 1, d. h. von einem Start des Rechensystems 1 noch vor dem Start des Flugzeugs 3 bis zum Abschalten des Flugzeugs 3 nach der Landung des Flugzeugs 3 wird nicht eine flüchtige Partition ständig wiederholt pausiert, sondern tatsächlich beendet und wieder neu gestartet.
  • 2 zeigt ein militärisches Flugzeug 3 mit einem Rechensystem 1, welches ebenfalls auf der IMA Architektur basiert. Auf dem Rechensystem 1 werden während des Flugs des Flugzeugs 3 mehrere Anwendungen ausgeführt, darunter ein Terrain Avoidance and Warning System (TAWS). Diese Anwendung benötigt Informationen über das Flugzeug 3, um seine Aufgabe zu erfüllen und gibt aktuelle Warnungen am Ende seiner Ausführungen zurück. Diese Anwendung wird in wiederholt ausgeführten flüchtigen Partitionen ausgeführt. Nach einem vordefinierten Zeitraum nach jeder Erzeugung eines Rückgabewerts wird diese Partition erneut gestartet, und mit dem Erhalt des Rückgabewerts wieder beendet. Eine weitere, zweite, flüchtige Partition wird vorgesehen, um Daten aus einem sogenannten „Remote Data Concentrator“ zu empfangen und zu verarbeiten, um Sensordaten zu prozessieren. Auch diese weitere flüchtige Partition wird entsprechend wiederholt ausgeführt. Eine dritte flüchtige Partition wird vorgesehen, um direkte Kontrolle über einen Bildschirm im Cockpit auszuüben, und um entsprechende Berechnungen für die dort angezeigten grafischen Elemente vorzunehmen. Die zweite flüchtige Partition wird in regelmäßigen zeitlichen Abständen durch einen Timer ausgeführt und entsprechend zeitgesteuert gestartet. Nach deren erfolgreicher Ausführungen können ihre Rückgabewerte von anderen flüchtigen Partitionen genutzt werden. Nachdem so alle notwendigen Aufrufparameter für die erste flüchtige Partition akkumuliert wurden, wird die erste flüchtige Partition ausgeführt, d. h. dass die zweite flüchtige Partition mit ihrem erzeugten Rückgabewert als Auslöser zum Start der ersten flüchtigen Partition dient. Deren Rückgabewert wiederum wird von der dritten flüchtigen Partition genutzt, um die Anzeige im Cockpit des Flugzeugs 3 entsprechend anzusteuern, insbesondere einen möglichen Warnungszustand auszugeben.
  • 3 zeigt ein Rechensystem 1, welches zwölf einzelne Avionik-Computer 5 aufweist, wovon jeder wiederum eine eigene Orchestrierungseinheit ausführt. Des weiteren ist eine Konfigurations-Logik L vorgesehen, welche auszuführende Partitionen jeweils einem der Avionik-Computer 5 zuweist. In diesem Beispiel sind die Partitionen, die in diesem Rechensystem 1 ausgeführt werden sollen, in einem System-Modellierungsprogramm konfiguriert worden und eine zugehörige Konfigurations-Logik L für die jeweiligen Orchestrierungseinheiten wurde generiert. Durch den Determinismus der Konfigurations-Logik L bekommen alle Avionik-Computer 5 dasselbe Ergebnis für die Partitionen, die auf allen Avionik-Computern 5 ausgeführt werden sollen. Alle Avionik-Computer 5 setzen dieses Ergebnis für sich um und das Rechensystem 1 ist voll funktionsfähig. Fällt beispielhaft einer der Avionik-Computer 5 aus, was in der 3 durch eine ausgekreutzte Rechtecksform angedeutet ist, wird dieser von den verbleibenden Avionik-Computern 5, insbesondere deren Orchestrierungseinheitens erkannt. Eine solche Erkennung kann stattfinden, indem ausbleibende Pings detektiert werden, welche sich jedoch im funktionsfähigen Fall die Avionik-Computer 5 in regelmäßigen Zeitabständen einander übermitteln. Es ist somit die Information bekannt, welche der Avionik-Computer 5 noch funktionsfähig sind. Diese Information ist eine Eingangsgröße der Konfigurations-Logik L, die entsprechend ausgewertet wird. Alle verbleibenden funktionsfähigen Avionik-Computer 5 erhalten wiederum dasselbe Ergebnis und setzen dieses für sich um. Durch Überprovisionierung der verfügbaren Avionik-Computer können somit trotz des Ausfalls eines Avionik-Computers 5 weiterhin alle Partitionen ausgeführt werden. Fällt ein weiterer Avionik-Computer 5 aus, was in der 3 durch eine gestrichelt-ausgekreutzte Rechtecksform angedeutet ist, wird wiederum die Konfiguration-Logik L neu evaluiert und es wird damit bestimmt, welche Partitionen von welchen verbleibenden Avionik-Computern 5 noch auszuführen sind. Sind zwei defekte Avionik-Computer 5 ein Fall, bei dem nicht genügend Rechenzeit im Rechensystem 1 vorliegt, um alle Partitionen wie regulär geplant auszuführen, so werden solche Partitionen nicht mehr ausgeführt, die die niedrigste Sicherheitskritikalität aufweisen unter möglichster Ausnutzung aller verbleibenden Avionik-Computer 5 und deren physischen Ressourcen.
  • Obwohl die Erfindung im Detail durch bevorzugte Ausführungsbeispiele näher illustriert und erläutert wurde, ist die Erfindung nicht durch die offenbarten Beispiele eingeschränkt und andere Variationen können vom Fachmann hieraus abgeleitet werden, ohne den Schutzumfang der Erfindung zu verlassen. Es ist daher klar, dass eine Vielzahl von Variationsmöglichkeiten existiert. Es ist ebenfalls klar, dass beispielhaft genannte Ausführungsformen wirklich nur Beispiele darstellen, die nicht in irgendeiner Weise als Begrenzung etwa des Schutzbereichs, der Anwendungsmöglichkeiten oder der Konfiguration der Erfindung aufzufassen sind. Vielmehr versetzen die vorhergehende Beschreibung und die Figurenbeschreibung den Fachmann in die Lage, die beispielhaften Ausführungsformen konkret umzusetzen, wobei der Fachmann in Kenntnis des offenbarten Erfindungsgedankens vielfältige Änderungen, beispielsweise hinsichtlich der Funktion oder der Anordnung einzelner, in einer beispielhaften Ausführungsform genannter Elemente, vornehmen kann, ohne den Schutzbereich zu verlassen, der durch die Ansprüche und deren rechtliche Entsprechungen, wie etwa weitergehende Erläuterungen in der Beschreibung, definiert wird.

Claims (10)

  1. Rechensystem (1) zur Ausführung von Software-Anwendungen in einem Flugzeug (3), wobei das Rechensystem (1) dazu ausgeführt ist, zur zumindest zeitlichen Ressourcenzuteilung von einem oder mehreren Rechen-Prozessen zu im Rechensystem (1) verfügbaren physischen Ressourcen flüchtige Partitionen zu verwenden, wobei eine jeweilige der flüchtigen Partitionen durch ein Auslösesignal gestartet wird und auf ihre Erzeugung eines aktuellen Rückgabewerts einer, für jede Ausführung einer Vielzahl von sequenziellen Ausführungen gleichen, vordefinierten Rückgabegröße beendet wird, so dass über eine zusammenhängende Laufzeit des Rechensystems (1) hin eine jeweilige der flüchtigen Partitionen zu einer Vielzahl von Zeitpunkten neu gestartet wird und nach Ausgabe ihres berechneten Rückgabewerts wieder beendet wird.
  2. Rechensystem (1) nach Anspruch 1, wobei das Rechensystem eine Vielzahl von Avionik-Computern (5) aufweist, und wobei das Rechensystem dazu ausgeführt ist, mittels einer vorgegebenen Konfigurations-Logik (L) eine Zuordnung einer jeweiligen Ausführung einer jeweiligen flüchtigen Partition zu einem jeweiligen der Avionik-Computer (5) zu bestimmen, wobei die Konfigurations-Logik (L) dazu eingerichtet ist, mit einer Information über eine jeweilige Verfügbarkeit eines jeweiligen Avionik-Computers (5) als Eingangsgröße die Zuordnung zu ermitteln.
  3. Rechensystem (1) nach Anspruch 2, wobei das Rechensystem (1) dazu ausgeführt ist, mittels der Konfigurations-Logik (L) und auf Basis der jeweiligen Verfügbarkeit eines jeweiligen Avionik-Computers (5) eine Unterauswahl von regulär auszuführenden flüchtigen Partitionen zu treffen, und nur die flüchtigen Partitionen aus der Unterauswahl auf ihren jeweils gemäß Zuordnung zugewiesen Avionik-Computern (5) auszuführen.
  4. Rechensystem (1) nach einem der Ansprüche 2 bis 3, wobei die Konfigurations-Logik (L) einen Algorithmus zur Lösung eines Rucksack-Problems umfasst.
  5. Rechensystem (1) nach einem der vorhergehenden Ansprüche, wobei das Rechensystem (1) dazu ausgeführt ist, bei Feststellung eines Fehlers bei der Ausführung einer flüchtigen Partition eine neue, die fehlerhafte flüchtige Partition ersetzende, flüchtige Partition zu starten, wobei ein Aufrufparameter der neuen flüchtigen Partition der jüngste Rückgabewert der fehlerhaften Partition vor Feststellung ihres Fehlers ist.
  6. Rechensystem (1) nach einem der vorhergehenden Ansprüche, wobei das Auslösesignal zum Start einer flüchtigen Partition dann vorliegt, wenn ein Rückgabewert aus einer vorhergehenden Ausführung der flüchtigen Partition verfügbar ist, oder wenn ein Kommandosignal von einer Funktionseinheit des Flugzeugs (3) erhalten wird.
  7. Rechensystem (1) nach einem der vorhergehenden Ansprüche, wobei das Rechensystem (1) dazu ausgeführt ist, das Auslösesignal zeitabhängig vorzugeben, so dass der Start einer jeweiligen flüchtigen Partition durch Zeitauslösung erfolgt.
  8. Rechensystem (1) nach einem der vorhergehenden Ansprüche, wobei das Rechensystem (1) dazu ausgeführt ist, die Ausführung einer neuen flüchtigen Partition erst nach Ablauf einer vorgegebenen Pausenzeit zwischen zwei konsekutiven Ausführungen einer flüchtigen Partition zu starten.
  9. Rechensystem (1) nach einem der vorhergehenden Ansprüche, wobei das Rechensystem (1) dazu ausgeführt ist, einen ermittelten Rückgabewert einer flüchtigen Partition nur für eine vorgegebene maximale Validitätsdauer als Ergebnis der vorgegebenen Rückgabegröße zu halten.
  10. Verfahren zum Ausführen von Anwendungen auf einer integrierten modularen Avionik eines Flugzeugs (3), dadurch gekennzeichnet, dass zur zumindest zeitlichen Ressourcenzuteilung von einem oder mehreren Rechen-Prozessen zu in der integrierten modularen Avionik verfügbaren physischen Ressourcen flüchtige Partitionen verwendet werden, wobei eine jeweilige der flüchtigen Partitionen durch ein Auslösesignal gestartet wird und auf ihre Erzeugung eines aktuellen Rückgabewerts einer, für jede Ausführung einer Vielzahl von sequenziellen Ausführungen gleichen, Rückgabegröße beendet wird, so dass über eine zusammenhängende Laufzeit des Rechensystems (1) hin eine jeweilige der flüchtigen Partitionen zu einer Vielzahl von Zeitpunkten neu gestartet wird und nach Ausgabe ihres berechneten Rückgabewerts wieder beendet wird, ohne zwischen den Ausführungen der flüchtigen Partitionen eingefroren oder pausiert zu werden.
DE102024104737.2A 2024-02-20 2024-02-20 Funktionale Partitionen in integrierter modularer Avionik Active DE102024104737B3 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE102024104737.2A DE102024104737B3 (de) 2024-02-20 2024-02-20 Funktionale Partitionen in integrierter modularer Avionik
PCT/EP2025/054315 WO2025176653A1 (de) 2024-02-20 2025-02-18 Funktionale partitionen in integrierter modularer avionik

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102024104737.2A DE102024104737B3 (de) 2024-02-20 2024-02-20 Funktionale Partitionen in integrierter modularer Avionik

Publications (1)

Publication Number Publication Date
DE102024104737B3 true DE102024104737B3 (de) 2025-07-10

Family

ID=94734235

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102024104737.2A Active DE102024104737B3 (de) 2024-02-20 2024-02-20 Funktionale Partitionen in integrierter modularer Avionik

Country Status (2)

Country Link
DE (1) DE102024104737B3 (de)
WO (1) WO2025176653A1 (de)

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
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<https://homepages.on.hs-bremen.de/~jbredereke/downloads/Bre18a.pdf>
Rushby, J.: Partitioning in Avionics Architectures: Requirements, Mechanisms, and Assurance, NASA/CR-1999-209347, NASA Center for AeroSpace Information (CASI) 7121 Standard Drive, Hanover, MD 21076-1320J, June 1999<https://ntrs.nasa.gov/citations/19990052867>

Also Published As

Publication number Publication date
WO2025176653A1 (de) 2025-08-28

Similar Documents

Publication Publication Date Title
EP0048767B1 (de) Prioritätsstufengesteuerte Unterbrechungseinrichtung
DE112012000797B4 (de) Mehrfach-Modellierungsparadigma für eine Vorhersageanalytik
DE102013214756B4 (de) Verfahren zum verwalten einer task-ausführung in einem mehrkernprozessor
EP2506098B1 (de) Anordnung und Verfahren für den Betrieb einer industriellen Automatisierungsanordnung mit einer Mehrzahl programmierbarer Automatisierungskomponenten und einer Mehrzahl Automatisierungsprogramme
DE102011086530A1 (de) Mikroprozessorsystem mit fehlertoleranter Architektur
DE112011101019T5 (de) Verarbeitung von Befehlen mit mehreren Prioritäten zwischen Back-End-Prozessoren
DE112012004728T5 (de) Verfahren, Programm und System zur Simulationsausführung
EP2513796B1 (de) Verfahren zum betreiben einer recheneinheit
DE102017128711A1 (de) Mehrkernprozessor und Verfahren zur dynamischen Einstellung einer Versorgungsspannung und einer Taktfrequenz
DE102020205720A1 (de) Computerimplementiertes Verfahren und Vorrichtung zur Planung von Ressourcen
DE102020214951A1 (de) Verfahren zum dynamischen Zuweisen von Speicherbandbreite
DE102007051803A1 (de) Verfahren und Vorrichtung zur Datenverarbeitung
DE102009025572A1 (de) Eine Methode zur Entwicklung von garantiert korrekten Echtzeitsystemen
EP2732347A1 (de) Verfahren und system zur dynamischen verteilung von programmfunktionen in verteilten steuerungssystemen
DE102024104737B3 (de) Funktionale Partitionen in integrierter modularer Avionik
DE112012004468B4 (de) Anwendungs-Level-Spekulative-Verarbeitung
DE102021209627A1 (de) System und Verfahren zum Ausführen von funktional gleichen Applikationen
EP2615511A1 (de) Verfahren zur synchronen Ausführung von Programmen in einem redundanten Automatisierungssystem
DE102024104736B3 (de) Funktionale Partitionen mit dediziertem Snapshot-Speicher in integrierter modularer Avionik
WO2012051972A2 (de) Verfahren, zur effizienten nutzung eines zwei- oder mehrkernprozessors durch ein betriebssystem
WO2014019722A1 (de) Vorrichtung und verfahren zur realisierung eines steuersystems mit hoher verfügbarkeit und/oder integrität
DE102019219260A1 (de) Verfahren zum Betreiben einer Recheneinheit
DE102018123563B4 (de) Verfahren zur Zwischenkernkommunikation in einem Mehrkernprozessor
DE102013217616B4 (de) Verwalten von Ressourcen innerhalb einer Datenverarbeitungsumgebung
DE102015104872A1 (de) Datenverarbeitungssystem für eine grafische Schnittstelle und grafische Schnittstelle, die ein solches Datenverarbeitungssystem aufweist

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication
R018 Grant decision by examination section/examining division