DE102021002354A1

DE102021002354A1 - Ressourcenbasiertes Konzept zur Betriebsplanung verteilter Raumfahrtsysteme

Info

Publication number: DE102021002354A1
Application number: DE102021002354.4A
Authority: DE
Inventors: Kai Leidig; Jonas Burgdorf; Steffen Gaißer; Ulrich Mohr; Susann Pätschke; Robin Schweigert; Sebastian Wenzel; Sabine Klinkner
Original assignee: Universitaet Stuttgart
Current assignee: SAT:IO GMBH, DE
Priority date: 2021-04-28
Filing date: 2021-04-28
Publication date: 2022-11-10

Abstract

Satelliten haben in der heutigen Zeit weitläufige Einsatzgebiete. Diese reichen von wissenschaftlichen Missionen wie der Erforschung des weltweiten Klimas, über klassische Kommunikationssatelliten für die Fernsehübertragung bis hin zu verbraucherorientierten Systemen wie die globale Verfügbarkeit von Satelliten. Durch diese sehr breiten Anwendungbereiche steigt die Zahl der sich im Orbit befindlichen Satelliten stetig an. Da der Bau, Start und Betrieb dieser Satelliten allerdings weiterhin sehr teuer ist und durch die sehr stark steigende Zahl an Satelliten im Orbit auch das Problem des Weltraummülls immer dringlicher wird, müssen Satelliten im Orbit best möglich genutzt werden. Hierfür bedarf es einer effizienten und effektiven Missionsplanung am Boden. Diese Missionsplanung hat die Aufgabe, verfügbare Ressourcen sowohl am Boden als auch im Orbit best möglich auszunutzen. Ressourcen am Boden beinhalten Dinge wie verfügbare Antennen, verfügbare Downlinkkapazitäten und verfügbare Datenauswertungen. Im Orbit hingegen müssen Ressourcen wie die verfügbare Zeit, der verfügbare Speicher, die Position im Orbit und die zur Verfügung stehende elektrische Leistung verwaltet werden. Diese Verwaltung geschieht momentan meist zumindest teilweise von Hand durch Operatoren. Das macht diesen Prozess stark zeitaufwändig und anfällig für Menschliche Fehler. Des Weiteren sollte für eine optimale Ausnutzung der verfügbaren Ressourcen dynamisch auf Änderungen sowohl am Boden als auch im Orbit reagiert werden können. Dies beinhaltet zum Beispiel den Ausfall einzelner Bodenstationen, durch welchen Überflüge neu geplant werden müssen oder die Änderung der Missionsplans. Spontan auf solche Umstände ist meist nur schwer bis garnicht möglich, wenn die Planung von Menschen durchgeführt wird, da hier genug Zeit vorhanden sein muss, um die erhaltenen Daten zu analysieren, den Plan entsprechend anzupassen und anschließend zu verifizieren, bevor die neue Planung ausgeführt werden kann. Wenn die Ressourcenplanung allerdings vollständig von Computern übernommen wird, kann können Pläne sehr schnell und dynamisch erstellt und angepasst werden. Hierfür muss allerdings das gesamte zu steuernde System und dessen Ressourcen dem Computer bekannt sein, damit dieser im Stande ist, die best mögliche Ressourcenverteilung zu erstellen und zu pflegen.Der hier vorgeschlagene Aufbau eines solchen Ressourcenmanagement setzt an dieser Stelle an. Die vorgestellte Komponente ist Teil eines größeren Systems zu Steuerung mehrere Missionen. Der Grundgedanke der vorgestellten Missionsplanung und des Ressourcenmanagements ist, dass das Bodensegment und das Segment im Orbit zusammengenommen einen zu regelnden Regelkreis bilden. Diese Regelung muss auf beiden Seiten die begrenzten Ressourcen beachten und damit einen möglichst optimalen Zeitplan für alle Systeme gemeinsam finden. Dieser Zeitplan soll hierbei nicht statisch erstellt werden, das System kann dynamisch auf Änderungen an allen Stellen reagieren. In einem ersten Schritt in diesem Regelkreis gilt es, die aktuellen Statusinformationen aller Systeme zu sammeln. Dies geschieht über verschiedene MCS, deren Zweck es ist, zwischen dem Mission Planning Tool (MPT) und den verschiedenen, zu steuernden Systemen zu übersetzen. Dabei werden die Statusinformationen bei den einzelnen Systemen abgeholt und in ein für das MPT lesbares Format übersetzt. Diese Daten werden dann in einem nächsten Schritt analysiert und dienen dann als Grundlage für die weitere Regelung. Diese Analyse beinhaltet systemspezifische Daten und dient dazu, den aktuellen Status des Systems zu beschreiben. Dies beinhaltet zum Beispiel Daten zu dem aktuellen Orbit eines Satelliten anhand welcher dann Überflüge über verschiedenen Bodenstationen geplant werden können. Diese Analysen werden in dem hier beschriebenen System von sogenannten Agent durchgeführt. Diese Agenten sind Softwarekomponenten, welche anhand von den ihnen zur Verfügung gestellten Daten Entscheidungen treffen und verschiedene Aktionen ausführen können. Diese dann auszuführenden Aktionen werden in dem hier definierten System als Activities beschrieben. Sie enthalten alle nötigen Informationen um die getroffene Entscheidung bei den betroffenen Systemen ausführen zu können. Um eine Activity weiterzuverarbeiten bestehen zwei Möglichkeiten. Wenn weitere Entscheidungen getroffen werden müssen, kann eine Activity an einen Agenten weitergegeben werden, welcher diese weiter bearbeitet. Wenn allerdings direkt verschiedene Systeme angesteuert werden sollen, wird die Activity an ein Mission Control System (MCS) weitergegeben, welches dann wiederum die Anweisungen in ein Format übersetzt, welches von dem entsprechenden System verstanden wird. Zusätzlich zu solch automatisch erstellten Activities können diese auch von Menschen an das System übergeben werden. Dies dient als Schnittstelle nach außen, wenn Operatoren die Missionsplanung direkt beeinflussen müssen. Die weitere Verarbeitung dieser Activities läuft dann aber weiterhin vollautomatisch in dem System ab.Die Übergabe einer Activity an ein MCS schließt dann den Regelkreis wieder. Die erstellte Planung wird wieder an das zu steuernde System übergeben und neue Statusinformationen können angefragt oder zur Verfügung gestellt werden.

Description

2 Stand der Technik
2.1 Allgemeine Problemstellung
Laut der European Cooperation for Space Standardization (ECSS) ist ein Space System definiert als ein verteiltes System, welches in zwei Teile unterteilt wird, das Raumsegment und das Bodensegment. Hierbei muss jedes Segment nicht aus einer einzelnen Komponente bestehen, das Raumsegment kann zum Beispiel mehrere Satelliten enthalten und das Bodensegment mehrere Komponenten und Bodenstationen. Ein Teil dieser Komponenten am Boden ist das sogenannte Betriebssystem, welches die Steuerung und Verwaltung des gesamten Systems übernimmt. Das Raumsegment hingegen dient der Durchführung der definierten Mission. Das gesamte Space System bildet hierbei einen Regelkreis, da das Bodensegment auf Daten des Raumsegments reagieren muss und anhand derer neue Abläufe für das Raumsegment generiert.
2.2 Technische Problemstellung
Durch die physikalische Trennung des Raum- und Bodensegmentes entstehen Einschränkungen, die bei dem Entwurf eines Betriebssystems beachtet werden müssen. So sind die meisten Ressourcen in einem solchen System stark eingeschränkt. Energie auf dem Satelliten ist nur begrenzt verfügbar, die Rechenleistung ist meist gering und der Speicher klein. Am Boden hingegen sind Operatoren nur zu bestimmten Zeit verfügbar, um Entscheidungen zu Treffen, und eine Antenne kann meist nur einen Satelliten gleichzeitig empfangen. Hinzu kommt, dass die meisten Satelliten, mit Ausnahme des geostationären Orbits, nur zeitweise von einer Bodenstation aus sichtbar sind. In niedrigeren Orbits beläuft sich diese Zeit auf meist ungefähr zehn Minuten pro Überflug und ungefähr sechs Überflüge pro Tag. Außerhalb dieser Zeiten muss der Satellit vollständig autonom arbeiten und alle nötigen Befehle müssen bereits im Vorhinein gesendet worden sein. Eine Vorausplanung am Boden ist daher nötig. Außerdem schränken diese seltenen Kontaktzeiten mit dem Raumsegment die Reaktionsfähigkeit des Bodens ein. Eine neue Planung kann immer nur während einem Überflug übertragen werden, bis zum nächsten Überflug kann dann nichts mehr geändert werden. Dies setzt allerdings auch voraus, dass bei kritischen Ereignissen, welche während einem Überflug festgestellt werden, die Missionsplanung sehr schnell reagieren muss, sodass mögliche Gegenmaßnahmen noch während dem aktuellen Überflug durchgeführt werden können.
Des Weiteren müssen bei machen Aktivitäten mehrere System kooperieren. So muss bei einem Überflug eine Antenne am Boden reserviert werden und die Ausrichtung der Antenne muss auf den Satelliten gerichtet und nachgeführt werden. Gleichzeitig muss der Satellit sich im Orbit zur richtigen Zeit mit seiner Antenne auf die Bodenstation ausrichten und das Sender von Daten beginnen. Um ein solches Szenario planen zu können, ist eine genaue Kenntnis über den aktuellen bzw. erwarteten Zustand aller System erforderlich. Außerdem müssen die Zeitpläne aller Systeme synchron gehalten werden.
2.3 Aktuelle Lösungen
Auch aktuelle Systeme sind bereits im Stande die Planung eines Satelliten großteils autonom zu erstellen [6, 1, 8]. Hierfür werden Aktivitäten erstellt und geplant und Konflikte zwischen verschiedenen Aufgaben erkannt und meist durch im Vorhinein definierte Modelle aufgelöst. Allerdings sind hierfür weiterhin Eingaben von Operatoren nötig [4].
2.4 Schwachstellen Aktueller Lösungen
Aktuelle Betriebssysteme sind meist stark monolithisch aufgebaut. Dies bedeutet, dass alle nötigen Aufgaben von der Planung bis hin zur Ausführung eines Zeitplans von einer einzelnen Software durchgeführt werden. Dadurch sind solche Systeme meist sehr statisch an einzelne Missionen angepasst und können daher nur diese einzelne Systeme steuern. Das Hinzufügen neuer System, sowohl am Boden als auch im Orbit, ist nur eingeschränkt oder garnicht möglich.
Zusätzlich sind die durch aktuelle Systeme erstellen Pläne meist statisch angelegt. Dies bedeutet, dass im Vorhinein geplant wird, dieser Plan dann an den Satelliten geschickt wird und nach der Ausführung überprüft wird, ob der volle Plan ausgeführt werden konnte. Hierbei wird nicht dynamisch auf Änderungen an den Systemen reagiert. Solche dynamischen Änderungen können zum Beispiel Ausfälle von Bodenstationen oder Änderungen am Wetter und den damit verbundenen Bobachtungsbedingungen sein. In aktuellen Systemen muss in solchen Fällen meist manuell eingegriffen werden und der Plan auf die neuen Bedingungen angepasst werden. Wenn während einem Überflug eine Änderung festgestellt wird, fehlt hier meist die Zeit zu reagieren, da das System den aktuellen Plan nicht autonom anpassen kann.
Des Weiteren bilden aktuelle Operationssysteme meist nicht den globalen Status aller angeschlossenen Systeme ab. Diese Information ist allerdings nötig, wenn der Betrieb weitgehend autonom durchgeführt werden soll. Mit Hilfe dieser Daten können damit die Ressourcen aller angeschlossener System verwaltet werden und Operationspläne dynamisch erstellt und angepasst werden.
3 Das Multi-Mission Operations System
Das vorgeschlagene Planungsverfahren ist Teil eines größeren Systems für den Multi-Missions-Satellitenbetrieb (MMOS). Eine globale Architektur ist in der dargestellt.
Eines der wichtigsten Designprinzipien des MMOS ist die Implementierung eines sauberen Prozesses zur Steuerung von Raumfahrzeugen, der einen automatischen Betrieb ermöglicht. [5] definiert Automatisierung als einen Steuerungsprozess, der aus vier aufeinander folgenden Schritten besteht:

1. Information Acquisition (Informationsbeschaffung)
2. Information Analysis (Informationsanalyse)
3. Decision & Action Selection (Entscheidung & Aktionsauswahl)
4. Action Implementation (Umsetzung der Aktion)

3.1 Informationsbeschaffung
Zweck des Missionskontrollsystems (engl. Mission Control System, kurz MCS) auf der linken Seite der Architekturdarstellung ist es, eine rudimentäre Verbindung mit dem betriebenen System (dem Satelliten) auf der Grundlage von Telemetrie (TM) und Telekommandos (TC) herzustellen. Die Telemetrie vom Satelliten (oder jedem anderen betriebenen System) wird in ein Telemetrie-Archiv geleitet, das vom Telemetrie- & Nutzlast-Datensystem bereitgestellt wird. Das Telemetriearchiv bietet eine persistente Speicherung der gesamten Telemetrie aller mit dem MMOS betriebenen Systeme und damit eine Datenbasis für den Steuerungsprozess.
3.2 Informationsanalyse
Bestimmte Steuerungsprozesse oder das Erreichen von Betriebszielen erfordern eine Analyse der empfangenen Informationen. Ein erster Schritt der Analyse erfolgt bereits, wenn ein Systemparameter (manchmal auch als Engineering-Parameter bezeichnet) aus einem Telemetrie-Paket im Archiv extrahiert wird.
Ein Beispiel für eine umfassendere Analyse ist die Flugdynamik (engl. flight dynamics). Zweck dieses Systems ist die Erzeugung von Orbitinformationen. Ein Orbit ist eine Ellipse im dreidimensionalen Raum. Eine solche Ellipse kann mit Hilfe von sechs geometrischen Parametern beschrieben werden. Der Orbit eines Satelliten kann z. B. anhand aus Positionsdatenpunkten bestimmt werden, die das Flight Dynamics Tool aus dem Telemetriearchiv bezieht. Anhand dieser Positionsdatenpunkte kann das Flugdynamik-Tool die Satellitenbahn bestimmen und die Satellitenposition vorausberechnen.
Dies ist jedoch nur ein Beispiel. Je nach Anwendung sind auch andere Auswertungen denkbar. Ein Platzhalter für die Umsetzung solcher ist das Automationssystem mit missionsspezifischen Software-Agenten, die implementiert und auf die individuellen Missionsbedürfnisse zugeschnitten werden können.
3.3 Entscheidung & Aktionsauswahl
Nachdem die Daten analysiert wurden, muss eine Entscheidung getroffen werden, was als nächstes zu tun ist. Das Ergebnis der Entscheidungsfindung ist immer eine Aktivität. Aktivitäten können auf zwei Arten generiert werden, entweder von einem menschlichen Bediener, der mit analysierten Daten oder Satellitentelemetrie versorgt wird, oder von einem Software Agent.
Dem Beispiel aus dem vorherigen Abschnitt folgend, werden Bahninformationen für die Planung von Satellitenübergängen berücksichtigt. Ein Überflug wird als eine koordinierte Aktivität verstanden, an der zwei Systeme beteiligt sind: ein Satellit und eine Antenne (bzw. eine Bodenstation), bei der beide Parteien eine physikalische Datenverbindung herstellen. Die Entscheidung, wann ein Überflug geplant werden soll, kann von einem Agenten getroffen werden.
3.4 Umsetzung der Aktion
Aktivitäten, die (entweder von einem menschlichen Bediener oder einem Agenten) definiert wurden, müssen in den Systemzeitplan (engl. schedule) eingefügt und schließlich von dem betriebenen System ausgeführt werden.
Zweck des Missionsplanungssystems ist es, individuelle Zeitpläne für jedes betriebene System (z.B. Satellit, Konstellation, Bodenstation) bereitzustellen und zu pflegen. Dies umfasst eine Vorabprüfung gegen die von dem System bereitstellbaren Ressourcen, die Konfliktauflösung, die Überprüfung eines erfolgreichen Uploads, die Überprüfung der Ausführung und schließlich das Schließen der Aktivität.
Telekommandos, welche an den Satelliten gesendet werden, werden direkt aus den Zeitplänen generiert, welche von den Mission Planning Tools gepflegt werden. Die Software, die für die Zusammenstellung und das Versenden der Telekommandos zuständig ist, ist das MCS. An dieser Stelle schließt sich der Regelkreis.
4 Beschreibung der Erfindung
4.1 Die Aktivität (engl. Activity)
Eine Aktivität wird als ein Prozess betrachtet, der entweder von einem einzelnen System oder von mehreren zusammenarbeitenden Systemen ausgeführt wird. Sie beschreibt eine abgeschlossene Aufgabe, die das ausführende System von einem definierten Anfangszustand in einen anderen definierten Endzustand überführt.
Wenn der Zustand des betriebenen Systems (ein Satellit oder eine Bodenstation) am Boden abgebildet wird, ermöglicht dieses Konzept eine kontinuierliche Verfolgung und Planung dieses Zustands, obwohl das MMOS aufgrund der physikalischen Einschränkungen im Satellitenbetriebs nicht in ständigem physischen Kontakt mit dem betriebenen System steht.
Schreibweise
Da sich in der Computer-, Software- und Satellitentechnik der englische Sprachgebrauch eingebürgert hat, werden in sämtlichen Abbildungen und an Stellen an denen keine gebräuchliche Deutsche Vokabel zur Verfügung steht die englischen Bezeichnungen verwendet, so wie sie auch in der Software verwendet werden. Übersetzung werden angegeben.
4.1.1 Attribute
Die Aktivität als Objekt weist eine Reihe von Attributen auf, wie in dargestellt.
Jede Aktivität hat einen Namen und eine Beschreibung, die es einem menschlichen Bediener ermöglichen, den Zusammenhang und den Zweck der Aktivität zu verstehen. Mittels einer ID kann jede Aktivität innerhalb des Betriebssystems eindeutig identifiziert werden.
Der Zustand (engl. state) der Aktivität ist ein zweidimensionales Objekt, das zum einen anzeigt, inwieweit die Aktivität bereits bearbeitet wurde (sowohl vom betriebenen System, als auch am Boden), und ob die Ausführung der Aktivität gerade aktiv ist. Das Konzept des states wird im Abschnitt 4.1.2 ausführlich vorgestellt.
Die Priorität ist ein Mittel zur Lösung von Konflikten zwischen Aktivitäten (Abschnitt 4.1.7). Im Falle eines Konflikts werden Aktivitäten mit niedrigerer Priorität zu Gunsten von Aktivitäten mit höherer Priorität pausiert.
Jede Aktivität hat einen Initiator und einen Executor. Der Initiator ist die Entität, die die Aktivität erstellt hat. Dies kann ein registrierter menschlicher Bediener oder ein Software-Agent sein. Der Executor ist die Entität, welche die Aktivität ausführt. Jede Entität innerhalb des MMOS kann durch eine logische Adresse eindeutig identifiziert werden. Entitäten können MMOS-Softwarekomponenten, menschliche Bediener oder die betriebenen Systeme sein. Die betriebenen Systeme als Entitäten werden innerhalb des MMOS durch ihre MPTs repräsentiert. Die ausführende Entität ist also gleichbedeutend mit dem jeweiligen MPT.
Die Kommunikation mit einem Satelliten beruht immer noch auf der Übertragung von Befehlen (engl. commands). Folglich kann jede Aktivität eine Folge von Commands aufweisen, die in der richtigen Reihenfolge ausgeführt werden müssen, um eine Aufgabe zu erfüllen. Die erfolgreiche Ausführung einer Aufgabe erfordert in der Regel die Verfügbarkeit bestimmter Systemressourcen. Ein Ressourcenbedarf (engl. resource demand) gibt an, in welchem Maße eine Ressource während der Ausführung verbraucht wird. Im Abschnitt 4.1.6 wird das Konzept der Ressourcen im Detail vorgestellt. Während einer Aktivität kann eine beliebige Anzahl von Ressourcen verbraucht werden.
Jede Aktivität kann eine Eltern-Aktivität und eine beliebige Anzahl von Kindern haben. Eltern (engl. parent) und Kinder (engl. children) sind Verweise auf andere Aktivitäten. Sie werden mit Hilfe ihrer eindeutigen ID adressiert. Das Verschachteln von Aktivitäten auf diese Weise wird im Abschnitt 4.1.3 näher erläutert.
4.1.2 Zustand
Der Zustand (engl. state) einer Aktivität ist ein zweidimensionales Objekt ( ).
Die stage Variable (Stufe/Stadium) gibt an, zu welchem Grad eine Aktivität ausgeführt wurde, entweder vom betriebenen System oder am Boden. Eine Aktivität beginnt im Zustand requested (angefordert). Wenn eine angeforderte Aktivität in den Zeitplan (engl. schedule) passt, wird sie als scheduled on ground (geplant am Boden) betrachtet. In dem Moment, in dem eine Aktivität zum Satelliten hochgeladen wird, tritt sie in den Zustand in transmission (in Übertragung) ein. Wenn die Aktivität vom betriebenen System nicht unmittelbar ausgeführt wird, wird sie als scheduled on board (soz. in Warteschlange) betrachtet, was bedeutet, dass die Befehle in die Liste der noch auszuführenden Befehle der on-board Software eingetragen wurde. In dem Moment, in dem die Zeit der Ausführung (engl. execution time) erreicht ist, tritt die Aktivität in das Stadium in process (in Ausführung) ein, was bedeutet, dass die Befehle in der Warteschlange von der on-board Software ausgeführt werden. Nachdem alle Befehle abgearbeitet wurden, wird die Aktivität als executed (ausgeführt) angesehen. Wenn die Ausführung erfolgreich war, wird die Aktivität als verified (verifiziert) markiert und schließlich geschlossen (engl. closed).
Die Status Variable gibt an, ob die Aktivität gerade bearbeitet wird oder nicht. Drei verschiedene Status sind möglich:

• In Progress (in Arbeit/in Bearbeitung)
• Suspended (pausiert)
• Failed (fehlgeschlagen)
• Closed (geschlossen)

Das Ändern der Stufe wie oben beschrieben ist nur möglich, wenn die Aktivität in Bearbeitung (engl. in progress) ist. Wenn die Ausführung einer Aktivität aus irgendeinem Grund unterbrochen/pausiert (engl. suspended) werden muss, ist ein weiterer Fortschritt nur möglich, nachdem die Aktivität wieder aufgenommen wurde. Der Begriff Wiederaufnahme (engl. resume) bezieht sich auf den Prozess der Verschiebung des Aktivitätsstatus von suspended zurück zu in progress.
Laufende und auch pausierte Aktivitäten können fehlschlagen. Das Setzen einer Aktivität in den Status failed (fehlgeschlagen) geht immer mit einer Erhöhung der Stufe einher. Dadurch wird angezeigt, dass der entsprechende Stufenübergang fehlgeschlagen ist. Wenn z. B. eine Aktivität fehlschlägt, während sie sich in der Ausführung durch das betriebene System befindet (in process), wird durch die gleichzeitige Änderung der Stufe angezeigt, dass die Ausführung (execution) nicht erfolgreich war.
Alle 19 (neunzehn) möglichen Zustände einer Aktivität sind in dargestellt.
4.1.3 Verschachtelung
Verschachtelung (engl. nesting) ist eine weitere Eigenschaft des Aktivitätenkonzepts: Der Begriff soll sich auf die Tatsache beziehen, dass ein Activity-Objekt mehrere Kinder (engl. children) haben kann, wie auch die Aktivität selbst das Kind einer Eltern-Aktivität (engl. parent) sein kann ( ). Auf diese Weise kann eine bestimmte Aufgabe (engl. task) in Unteraufgaben (engl. subtasks) zerlegt werden (Abbildung ref-fig:nestedActivitiesStructure).
Sowohl die Eltern-Aktivität als auch die Kinder sind kein direktes Attribut (engl. member variable) des Activity-Objektes, sondern werden über ihre ID referenziert ( . Auf diese Weise können alle Kinder eines Elternteils angesprochen und identifiziert werden, ebenso wie die Kinder dieser Kinder usw.
Zustand verschachtelter Aktivitäten
Der Zustand (engl. state) einer übergeordneten Aktivität (Abschnitt 4.1.2) hängt vom Zustand ihrer Kinder ab. Mit Hilfe des beschriebenen Referenzierungsansatzes können rekursive Aufrufe implementiert werden, die die Ermittlung aller Kindszustände ermöglichen, anhand derer der Elternzustand ermittelt werden kann.
Bis die Eltern-Aktivität die Stufe (engl. stage) in procress (in Bearbeitung) (n = 5) eingetreten hat, ist ihre Stufe gleich der höchsten Stufe die von einem ihrer Kinder erreicht wurde. $n_{parent} = max {n_{child, 1}, n_{child},_{2}_{,} \dots} wenn n_{parent} < 5$
Zum Beispiel wird die Stufe scheduled on Board (in Warteschlange) angenommen, wenn dies die Stufe von mindestens einem Kind ist und sich alle anderen Kinder in der gleichen oder niedrigeren Bearbeitungsstufen befinden.
Ab der Stufe scheduled on Board, ist die übergeordnete Stufe immer gleich der minimalen Kind-Stufe. $n_{parent} = min {n_{child, 1}, n_{child},_{2}, \dots} wenn n_{parent} \geq 5$
Soll heißen, die übergeordnete Aufgabe gilt nur dann als executed (ausgeführt), wenn alle untergeordneten Kinder ebenfalls ausgeführt wurden, ebenso wie die übergeordnete Aufgabe nur dann als verified (verifiziert) gilt, wenn das auch auf alle Kinder zutrifft.
Der Rückfall in einer niedrigere Stufe ist nicht möglich.
Der Status der Eltern-Aktivität m wird wie folgt gesetzt:

• Der Eltern-Status ist in progress (in Bearbeitung), wenn mindestens ein Kind ebenfalls in Bearbeitung ist und kein Kind fehlgeschlagen ist.
• Der Eltern-Status ist suspended (pausiert), wenn auch alle Kinder pausiert wurden.
• Der Eltern-Status ist failed (fehlgeschlagen), wenn mindestens ein Kind ebenfalls fehlgeschlagen ist.
• Der Eltern-Status ist closed (geschlossen), wenn alle Kinder geschlossen wurden.

4.1.4 Executor
Wie oben erwähnt, bezieht sich der Executor auf die Entität, welche die Aktivität ausführt. Der eigentliche Executor einer Aktivität ist eines der betriebenen Systeme. Auf dem Boden bzw. innerhalb des MMOS werden diese betriebenen Systeme durch die MPTs repräsentiert ( ). Die logische Adresse des Attributs executor ( ) verweist also auf eben jenes MPT.
Eine wesentliche Eigenschaft des Konzepts ist, dass es keine Einschränkung macht hinsichtlich des ausführenden Systems, also des Executors.
Im Abschnitt 4.1.3 wurde auf die Möglichkeit der Verschachtelung von Aktivitäten hingewiesen. Indem jeder untergeordneten Aktivität unterschiedliche Executors zugewiesen werden, kann eine Aufgabe auf mehrere Systeme verteilt und koordiniert werden.
Auf diese Weise kann die Interaktion mehrerer Systeme geplant werden. Anwendungsfälle, in denen dies zum Tragen kommt, sind z. B. die Planung von Bodenstationsüberflügen (egnl. passes) (Abschnitt 3.3 und 4.1.8) oder die Planung von Aktivitäten, an denen mehrere Satelliten beteiligt sind, was z. B. bei Konstellationsmission der Fall ist.
4.1.5 Sequenz
Ausschließlich Aktivitäten, die nicht weiter in Teilaufgaben (child activities) zerlegt werden, können Befehlssequenzen (engl. command sequences) enthalten. Diese Befehle (engl. command) werden vom betriebenen System ausgeführt. Die Attribute eines command Objektes sind in aufgeführt.
Wie eine Aktivität (Abschnitt 4.1.1) kann ein Befehl beschrieben und durch einen Namen, sowie eine ID eindeutig identifiziert werden.
Darüber hinaus besitzt ein Befehl eine Ausführungszeit (engl. execution time) und eine Übertragungszeit (engl. release time). Die Ausführungszeit bezieht sich auf den Zeitpunkt, zu dem der Befehl vom bedienten System ausgeführt wird, während die Übertragungszeit sich auf den Zeitpunkt bezieht, zu dem der Befehl an das betriebene System gesendet wird. Darüber hinaus kann jeder Befehl eine beliebige Anzahl von Parametern aufweisen, welche die Ausführung im Detail spezifizieren.
4.1.6 Ressourcenverbrauch
Eine der Kerneigenschaften einer Aktivität, wie sie im Abschnitt 4.1 erwähnt wurde, war, dass sie ein Mittel ist, um das System aktiv von einem definierten Anfangszustand in einen definierten Endzustand zu überführen, und dass sie außerdem ein Mittel ist, um diesen Zustand zu prognostizieren. Das Attribut, das all dies ermöglicht, ist der Ressourcenbedarf (engl. resource demand).
Die diesem Konzept zugrundeliegende Annahme ist, dass der Systemzustand äquivalent zu den Zuständen aller Systemressourcen ist. Der Zustand einer Ressource wird als Niveau (engl. level) bezeichnet. Der durch eine Aktivität angegebene Ressourcenbedarf ist ein Mittel zur Simulation dieses Niveaus über der Zeit.
Bezüglich existierender Konzepte zur Ressourcenmodellierung wird auf [7, 3] verwiesen.
Eine Aktivität kann ihren Ressourcenbedarf auf zwei verschiedene Weisen ausdrücken: absolut und relativ.
Absoluter Bedarf
Aktivitäten, die einen absoluten Bedarf (engl. absolute demand) angeben, erfordern, dass sich eine Ressource zu einer gegebenen Zeit in einem bestimmten Zustand befindet. veranschaulicht, wie eine solche Bedingung ausgedrückt werden kann. Es sind mehrere Optionen möglich. Es kann verlangt werden, dass eine Ressource in einem bestimmten Zustand ist oder nicht ist. Wenn ein genauer Wert nicht angegeben werden kann oder ein genauer. Wert nicht erforderlich ist, kann der erforderliche Zustand durch die Definition von Ober- und Untergrenzen eingegrenzt werden.
Relativer Bedarf
Im Gegensatz zu einem absoluten Bedarf gibt ein relativer Bedarf (engl. relative demand)den Verbrauch einer Ressource an, wobei ein positiver Verbrauch zu einem sinkenden Niveau und ein negativer Verbrauch zu einem Anstieg führt. Das Verbrauchen einer endlichen Menge zu einem Zeitpunkt wird als Entnahme (engl. withdrawal) bezeichnet, während Rückgabe (engl. return) das Gegenteil bedeutet. In wird zu t₀ eine endliche Menge d₀ entnommen. Anschließend beginnt der Verbrauch über einen Zeitraum der Dauer T. Am Ende des Verbrauchs wird eine Menge d₁ zurückgegeben.
Das Niveau wird wie folgt modelliert: $R_{0} = R_{- 1} - d_{0}$
$R (t) = R_{0} - d (t)$
$= R_{- 1} - d_{0} - d (t)$
$= R_{- 1} - d_{0} - \int_{t_{0}}^{t_{1}} c (t) d t$
$= R_{- 1} - d_{0} - c (t - t_{0}) wenn c = const .$
$R_{1} = R (t_{1}) - d_{1}$
4.1.7 Lösung von Konflikten
Ein Nebeneffekt der Propagierung des Systemzustands durch Ressourcenbedarfe ist, dass dadurch Konflikte zwischen Aktivitäten aufgelöst werden können. So können bspw. Aktivitäten, die entgegengesetzte Systemzustände fordern, nicht gleichzeitig geplant werden.
Eine Eigenschaft von relativen Bedarfen ist, dass diese kumuliert werden können. Ein solcher Fall ist in dargestellt. Zu t₀ beginnt Aktivität I die Ressource konstant zu verbrauchen. Ab t₁ wird die selbe Ressource auch von Aktivität II verbraucht, was zu einem steileren Abfall des Niveaus führt. Ein Konflikt entsteht, wenn die Bedarfe beider Aktivitäten zu einem übermäßigen Verbrauch der Ressource führen, was der Fall ist, wenn entweder die obere oder untere Grenze eines Ressourcen-Niveaus überschritten wird.
In einem solchen Fall muss eine der Aktivitäten ausgesetzt (engl. suspended) werden. Ein Mittel zur Auflösung eines solchen Konflikts ist die Priorität ( ). Wenn beide Aktivitäten die gleiche. Priorität haben, greifen andere Auflösungsmechanismen.
4.1.8 Abgeleitete Aktivitäten
Abgeleitete Aktivitäten (engl. derived activities) bezeichnen solche Aktivitäten, die im Betriebsprozess eine übergeordnete Rolle spielen und daher gesondert behandelt werden müssen.
Link Activities
Sog. link activities (Datenverbindungsaktivitäten) sind verschachtelte Aktivitäten (Abschnitt 4.1.3), mit denen die Zusammenarbeit von zwei oder mehr Systemen geplant wird, mit dem Ziel, eine Datenverbindung zwischen diesen herzustellen.
Link activities sind dadurch gekennzeichnet, dass beide Parteien zu Beginn Teilaufgaben ausführen, um die Verbindung herzustellen (z. B. Aktivierung der Sender und Empfänger). Am Ende der Kommunikation führen beide Parteien die entsprechenden Teilaufgaben aus, um die Verbindung wieder zu deaktivieren (z. B. Abschalten der Sender und Empfänger).
Ein Beispiel für eine link activities zwischen einem Satelliten und einer Bodenstation ist in den und dargestellt.
Maneuver Activities
Manöver sind Aktivitäten zur Änderung des Satellitenorbits. Zusätzlich zum Ressourcenbedarf einer gewöhnlichen Aktivität geben Manöver-Aktivitäten (engl. maneuver activity) eine Umlaufbahn (Orbit) an. Aus technischer Sicht funktioniert die Implementierung einer solchen Orbit-Forderung genau wie ein Ressourcenbedarf. Der Unterschied besteht darin, dass nicht nur ein Zustand gefordert wird, sondern dass die sechs Parameter zur Beschreibung einer Satellitenbahn - auch bekannt als Kepler Elemente (oder Äquivalente davon) - angegeben werden.
Eine Manöver-Aktivität gibt den Orbits vor und nach der Aktivität an. Manöver-Aktivitäten sind also nicht ausschließlich ein Mittel zur Änderung des Systemzustandes, sondern ein Mittel um ein Raumfahrzeug von einem definierten Startorbit in einen anderen definierten Zielorbit zu überführen.
Durch den Vergleich des aktuellen Orbits mit den geplanten Orbits kann so zum einen festgestellt werden ob das geplante Maneuver zielführend ist, was einer Konfliktauflösung gleich kommt, und zum anderen die erfolgreiche Ausführung des Manövers überprüft werden.
4.2 Das Missionsplanungs-Tool (engl. Mission Planning Tool)
Jede Instanz eins Missionsplanungs-Tools (kurz MPT) innerhalb des MMOS ist für ein betriebenes System (z. B. einen Satelliten, oder eine Bodenstation) zuständig. Sie verwaltet den Zeitplan der Mission (engl. schedule) für dieses System sowie die Ressourcen, die das System für den Betrieb bereitstellt.
Der schedule besteht aus einer Liste von Aktivitäten (Abschnitt 4.1), die vom betriebenen System auszuführen sind. Zweck des MPT ist es, diese Aktivitäten zu planen, d.h. Konflikte zwischen ihnen zu erkennen und aufzulösen und Befehle (engl. Commands) für das Versenden freizugeben. Außerdem setzt und überwacht das MPT die Zustände (engl. states) der Aktivitäten und verwaltet die Randbedingungen (Ressourcen), die für die Ausführung einer Aktivität erforderlich sind.
Der Mechanismus zur Planung von Aktivitäten, .zur Lösung von Konflikten und zur Verifikation der Ausführung von Aktivitäten stützt sich auf das Ressourcenmodell (Abschnitt 4.1.6). Das Ausführen einer Befehlssequenz bedeutet den Verbrauch einer Ressource des betriebenen Systems. Ressourcen werden in Budgets verwaltet, die angeben, von wem und in welchem Umfang eine Ressource verbraucht wird. In dem Moment, in dem eine Aktivität eingeplant wird, wird ihr Ressourcenbedarf im Budget modelliert. Wenn das Budget vollständig verbraucht ist, kann keine weitere Aktivität mit derselben Ressource eingeplant werden, bis die Ressource zurückgegeben oder vom System wieder bereitgestellt werden kann. Der Vergleich des modellierten Budgets mit dem tatsächlichen Zustand der Ressource (gewonnen aus der Satellitentelemetrie) ist ein Mechanismus zur Überprüfung der Ausführung einer Aktivität.
Informationen über Aktivitäten werden dauerhaft gespeichert und können von einem zentralen Archiv über das Activity & Schedule Interface abgefragt werden. Jede Komponente, die diese Schnittstelle implementiert, kann Informationen über Aktivitäten in das Archiv schreiben und auslesen.
4.2.1 Übersicht über die MPT Architektur
zeigt eine Übersicht über die MPT-Architektur und ihre Komponenten. Der Funktionsumfang der einzelnen Komponenten wird in den folgenden Unterabschnitten kurz vorgestellt.
4.2.2 Configuration Layer
Die Konfigurationsschicht (engl. configuration layer) ist der Überwachung, Steuerung und Konfiguration dieser Komponente gewidmet. Sie ist nicht Gegenstand der vorliegenden Erfindung.
4.2.3 Scheduling Layer
Zweck der Planungsschicht (engl. scheduling layer) ist die Überwachung und Einstellung des Zustands der Aktivitäten im schedule. Gemäß der Aktivitätsdefinition kann sich eine Aktivität in 19 definierten Zuständen befinden ( ). Die Planungsschicht muss für jeden dieser Zustände dedizierte Dienste implementieren.
Die Hauptaufgabe eines jeden Dienstes besteht darin, Aktivitäten zu überwachen, die sich in einem bestimmten Zustand befinden, und dann die Randbedingungen zu prüfen, um den Zustand der Aktivität zu ändern ( ). Je nach Zustand der Aktivität variieren die Randbedingungen, die vor dem Ändern der Aktivität zu prüfen sind. Die folgenden Punkte können Gegenstand einer Prüfung sein.

• Attribute der Aktivität selbst (Ressourcenbedarf, Zeitstempel, etc.)
• Zustände (states) der Kind-Aktivitäten
• Zustände der Befehle in der Sequenz
• Zustand (Ressourcen Niveaus) des betriebenen Systems

Da die zu prüfenden Randbedingungen in jedem Zustand unterschiedlich sind, müssen in jedem Service unterschiedliche Zustandsautomaten implementiert werden. Der Zustand einer Aktivität ist dann Grundlage für die Aktionen, die von der operativen Schicht (Abschnitt 4.2.4) durchgeführt werden.
Ein weiterer Zweck der Dienste in der Planungsschicht ist die Auflösung von Konflikten, falls solche erkannt werden.
4.2.4 Operative Layer
Basierend auf dem von der Planungsschicht eingestellten activity state führt die operative Schicht verschiedene Aktionen aus, die wiederum neue Randbedingungen für die Planungsschicht erzeugen ( ).
Die verschiedenen Funktionen, die in der operativen Schicht implementiert sind, hängen vom Zustand der Aktivitäten ab. Außerdem löst nicht jeder activity state eine Aktion innerhalb der operativen Schicht aus.
Bislang sind 4+1 verschiedene Funktionen innerhalb der operativen Schicht vorgesehen:

• Command Management (Befehlsverwaltung)
• Release Management (Versandverwaltung)
• Resource Management (Ressourcenverwaltung)
• Orbit Management (Orbitverwaltung)
• (optional) On-Board Schedule Management

Command Management
Der einzige Zweck der Befehlsverwaltung (engl. command management) ist die Versandfreigabe (unlock for release) von Befehlen, die zu Aktivitäten gehören, welche sich im Zustand 3 (in transmission) befinden. Auf diese Weise markierte Befehle werden dann vom MCS an das betriebene System übertragen.
Wird die Aktivität durch einen Dienst in der Planungsschicht in einen anderen Zustand versetzt (z. B. pausiert), wird die Versandfreigabe wieder zurück gezogen. Daraufhin werden die entsprechenden Befehle nicht mehr an das betriebene System übertragen.
Release Management
Zweck des Versandverwaltung (engl. release management) ist die Ermittlung von release times (Übertragungszeitpunkt). Die Ermittlung der release time soll für alle Aktivitäten erfolgen, die sich im Zustand 2 (scheduled on ground) und 11 (transmission suspend-ed) befinden. Für die Ermittlung der Freigabezeit sind mehrere Randbedingungen zu berücksichtigen:

1. Wann sind uplink passes gelpant? (Bodenstationsüberflüge mit Möglichkeit zur Kommandierung)
2. Wann soll die Aktivität ausgeführt werden?
3. Wie lange dauern die uplink passes? ( )
4. Wie groß ist die on-board queue? (Menge an Befehlen, die an Bord gespeichert werden können)
5. Wie groß ist die Bandbreite?
6. Wie groß sind die Telekommando-Pakete?
7. Wie viele Daten sollen übertragen werden?
8. Wie groß ist der Daten-Overhead? (Menge an Daten die.zusätzlich übertragen werden müssen)

In einer ersten Version dieser Funktion soll eine Standardregel zur Bestimmung der release time implementiert werden. Zukünftige Versionen sollen so konfigurierbar sein, dass ein Bediener diese Regeln entsprechend den Missionspräferenzen anpassen kann. Weiterhin ist ein Priorisierungsschema denkbar. Auch Optimierungsschemata sollen in einer zukünftigen Version möglich sein. Solche Schemata könnten die Verweildauer von Befehlen an Bord, die Auslastung der Datenverbindung o.ä. optimieren.
Resource Management
Die Aufgabe der Ressourcenverwaltung (engl. recourse management) ist zweigeteilt:

1. Durch die Erfassung der geplanten Aktivitäten und des durch diese festgelegten Ressourcenbedarfs soll die Ressourcenverwaltung das Niveau der Ressourcen in die Zukunft propagieren.
2. Die Ressourcenverwaltung muss außerdem in der Lage sein, Ressourcenprüfungen durchzuführen. Wenn Aktivitäten geplant werden, stellen die entsprechenden Services in der Planungsschicht Anfragen, ob diese Aktivitäten in Konflikt zueinander stehen. Ein Konflikt liegt vor, wenn zwei oder mehr Aktivitäten dieselbe Ressource überbeanspruchen (Abschnitt 4.1.6). Ist dies der Fall, informiert die Ressourcenverwaltung den anfragenden Service über die Ursache des Konflikts bzw. über die kollidierenden Aktivitäten.

Die Propagierung des zukünftigen Ressourcenniveaus R(t) basiert auf einer Anfangsbedingung R(t) und mehreren Randbedingungen ( ). Die Anfangsbedingung ist der letzte bekannte Zustand der jeweiligen Ressource, der aus der Telemetrie gewonnen wird. Die Randbedingungen sind die verschiedenen Bedarfe, die durch die geplanten Aktivitäten vorgegeben werden. Basierend auf dem in Abschnitt 4.1.6 beschriebenen Ressourcenmodell kann das Ressourcenmanagement den zukünftigen Zustand einer Ressource prognostizieren.
Orbit Management
Die Orbitverwaltung (engl. orbit management) funktioniert genau wie die Ressourcenverwaltung, mit dem Unterschied, dass sie nur die Manöver-Aktivitäten und die darin enthaltenen Orbitparameter erfasst (Abschnitt 4.1.8).
Die Orbitprognose, ähnlich dem Ansatz in , wird jedoch nicht vom MPT sondern vom Flugdynamik-Tool durchgeführt ( ). Die Anfangsbedingung ist der aktuell prognostizierte Satellitenorbit, und die Randbedingungen sind die Parameter der entsprechenden Manöver Aktivitäten. Daraus lässt sich die zukünftige Flugbahn R(t) vorausberechnen. Auf diese Weise kann das MPT die vorgesehene Flugbahn des Satelliten im Weltraum mit der tatsächlichen Flugbahn vergleichen und Rückschlüsse über den Erfolg einer Manöver Aktivität ziehen.
4.2.5 Interface Layer
Zweck der Schnittstellenschicht (engl. interface layer) und der darunter liegenden Kommunikationsschicht (engl. communication layer) ist es, über eine sog. Middleware eine funktionale Verbindung zu den anderen MMOS-Komponenten herzustellen. Die Schnittstellenschicht stellt diejenigen Schnittstellen zur Verfügung, die von Planungsschicht und operativer Schicht benötigt werden, um auf Daten zuzugreifen, die von anderen Komponenten innerhalb des Systems bereitgestellt werden.
Die Schnittstellenschicht ist nicht Gegenstand der vorliegenden Erfindung.
Bezüglich eines alternativen Konzeptes für eine Scheduling Software wird auf [2] verwiesen.
Literatur

[1] Seung-woo Baek u. a. „Development of a scheduling algorithm and GUI for autonomous satellite missions“. In: Acta Astronautica 68.7-8 (2011), S. 1396-1402.
[2] Jens Eickhoff, Harald Eisenmann und Oliver Kienzler. „TINA - Knowlegebased Mission Planning for Future Spacecrafts and their Autonomous Operation“. In: WIT Transactions on Information and Communication Technologies 19 (1997). DOI: 10.2495/AI970421.
[3] GSOC. Planning Modelling Language. Hrsg. von German Space Operations Center. German Areoscpace Center. Juli 2010. URL: https : / / www . dlr. de / rb / en / Portaldata / 38 / Resources / dokumente / GSOC _dokumente / RB - MIB / GSOC_ Modelling_Language.pdf.
[4] KS Klemich u. a. The Flying Laptop University Satellite Mission: Ground Infrastructure and Operations after one Year in Orbit. Deutsche Gesellschaft für Luft-und Raumfahrt-Lilienthal-Oberth eV, 2018.
[5] Luca Save und Beatrice Feuerberg. „Designing Human-Automation Interaction. A new level of Automation Taxonomy“ . In: Human Factors: a view from an integrative perspective. Hrsg. von Dick de Waard. 2012.
[6] P Soma u. a. „Multi-satellite scheduling using genetic algorithms“. In: Space OPS 2004 Conference. 2004, S. 515.
[7] Thomas Uhlig, Florian Sellmaier und Michael Schmidhuber. Spacecraft Operations. Hrsg. von German Space Operations Center (GSOC). Hrsg. von German Aerospace Center (DLR). Vienna, Austria: Springer, 2015. ISBN: 978-3-7091-1802-3. DOI: 10. 1007/978-3-7091-1803-0.
[8] Zhu Waiming u. a. „A two-phase genetic annealing method for integrated Earth observation satellite scheduling problems“. In: Soft Computing 23.1 (2019), S. 181-196.

Claims

Eine Aktivität dient der Planung von Vorgängen/Aufgaben/Unteraufgaben auf Systemebene. Über ein Ressourcenmodell und einen spezifizierten Ressourcenbedarf ermöglicht es die Aktivität ein System gezielt von einem Anfangszustand in einen Endzustand zu überführen und diese Transition zu planen und vorherzusagen. Die Zustandsvariablen des Systems sind gleich den Ressourcen des Systems. Somit ergibt sich der Systemzustand ans der Gesamtheit aller Ressourcenzustände zu einem bestimmten Zeitpunkt. (Abschnitte 4.1 und 4.1.6)
Eine Aktivität bietet die Eigenschaft der Verschachtelung, also andere Aktivitäten zu referenzieren. Es kann eine Eltern-Aktivität und mehrere Kinder-Aktivitäten angegeben werden. Auf diese Weise lässt sich eine Aufgabe rekursiv in verschiedene Unteraufgaben gliedern. (Abschnitt 4.1.3)
Die Tatsache, dass sich Aktivitäten verschachteln lassen und darüber hinaus einen beliebigen Executer (ausführendes System) aufweisen können, ermöglicht es, eine Aufgabe auf mehrere Systeme zu verteilen, und auf diese Weise Interaktion über Systemgrenzen hinweg und zwischen Systemen zu planen und zu koordinieren. (Abschnitte 4.1.3 und 4.1.4)
Der Ressourcenverbrauch einer Aktivität ist ein Mittel zur Auflösung von Konflikten. Ein Konflikt entsteht sobald eine oder mehrere Aktivitäten einen Ressourcenbedarf aufweisen, der vom betriebenen System zum geplanten Zeitpunkt nicht bereitgestellt werden kann. Das System kann sich entweder in einem anderen als dem geforderten Zustand befinden (absoluter Bedarf) oder das System kann eine Ressource nicht in der geforderten Menge bereitstellen (relativer Bedarf) (Abschnitt 4.1.6). Ein absoluter Bedarf wird über die die Angabe von Bedingungen an das geforderten Niveau der Ressource zum Ausdruck gebracht ( ), während ein relativer Bedarf Angaben zum Verbrauch einer Ressource über der Zeit macht ( ).
Das Missionsplanungs-Tool (MPT) stellt die Implementierung einer Architektur zur Verwaltung der beschriebenen Aktivitäten dar ( ). Eine MPT Instanz ermöglicht es alle Aktivitäten eines ausführenden Systems zu verwalten. Dazu zählt das Überwachen und das Verwalten aller möglichen Zustände (states) der Aktivitäten ( ), das Erkennen und das Lösen von Konflikten basierend auf dem Ressourcenmodell (Abschnitt 4.1.6), die Propagation des Systemzustands in die Zukunft auf Basis des angegebenen Ressourcenverbrauchs, das Ermitteln von Übertragungszeitpunkten von Befehlen ( ), die Steuerung der Freigabe von Befehlen für die Übertragung zum betriebenen System, sowie die Verifizierung der Ausführung von Aktivitäten auf Basis der Aktivitätszustände, der empfangenen Telemetrie und des geplanten Ressourcenverbrauchs. (Abschnitt 4.2)
Die Ausführung von Manöver Aktivitäten (Abschnitt 4.1.8) kann ebenfalls mittels MPT geplant und überwacht werden. In Ergänzung zu einer herkömmlichen Aktivität geben Manöver Aktivitäten Informationen über einen Start- und einen Zielorbit an. Durch den Vergleich dieser Orbit Informationen mit dem tatsächlichen Orbit kann das MPT die Ausführung eines Manövers verifizieren. In Ergänzung zum bestehenden Konzept entsteht ein Konflikt bei einer Manöver Aktivität dadurch, dass entweder Start- oder Zielorbit nicht erreicht werden können. (Abschnitt 4.2)