Kann die Nachrichtenübermittlung für ein CPU-Redundanz- und Lastausgleichskonstrukt verwendet werden?

8

Ist es in eingebetteten Bare-Metal- oder Minimal-RTOS-Systemen mit mehreren Prozessoren möglich, auf jedem Prozessor ein identisches Programm auszuführen, das Message Passing Interface (MPI) verwendet, um bei Prozessorausfall einen Lastausgleich und auch Redundanz bereitzustellen? B. eine Zustandsmaschine, die ändert, welche Aktionen andere CPUs basierend auf übergebenen Nachrichten ausführen, z. B. einen anderen Prozessor auffordert, einen Teil der Systemschleife für den Lastausgleich zu übernehmen oder periodisch lebendige Nachrichten zu senden, und sich merkt, wofür jede CPU verantwortlich ist CPU-Redundanz.

In diesem Beispieldiagramm können die tatsächlichen Teile der vollständigen Systemschleife, die "offen" sind, unterschiedliche Systeme sein. Es könnte keine Kooperation geben, nur die Möglichkeit, Teile der vollständigen Systemschleife, die auf jeder CPU ausgeführt wird, in einer Art sehr primitiven asymmetrischen Multiprozessors zu öffnen und / oder zu schließen. "Prozessmigration" zu einer anderen CPU würde durch eine Anforderung an eine andere CPU ausgelöst, den Teil der Systemschleife zu öffnen, nach dem die anfordernde CPU ihren Teil schließt, oder durch eine fehlende Antwort von einer anderen CPU, wenn sie abgefragt wird, wenn sie für einige Zeit am Leben ist .

Geben Sie hier die Bildbeschreibung ein

Es wurde als Lösung für potenzielle Prozessorausfälle und als Lösung für den Lastausgleich vorgeschlagen, da wir ein eingebettetes Betriebssystem nicht portieren können, um wirklich symmetrische oder asymmetrische Mehrfachverarbeitung auf der benutzerdefinierten Karte durchzuführen, und es scheint theoretisch möglich zu sein, aber ein unglaublich schlechtes Design Idee. Außerdem konnte ich keine Entwurfsmuster oder Algorithmen für die Verwendung der Nachrichtenübermittlung auf diese Weise finden.

Einige Hintergrundinformationen, die für die Softwareentwicklungsentscheidungen wichtig sind: Als CubeSat-Projekt für Studenten (nicht benotet oder für eine Klasse) haben wir ein kleines Softwareentwicklungsteam mit hauptsächlich jungen Studenten, die nur wenig oder gar keine Kenntnisse über das Design von Betriebssystemen haben. Aus verschiedenen Gründen können wir keine der vielen realen Lösungen durchführen, über die ich gelesen habe. Dies klingt zwar so, als ob es möglich wäre, dass es zu viel Komplexität für das Team mit sich bringt, und selbst wenn dies möglich ist, führt dies zu einem schrecklichen Design, das zu einem Problem führt, das den CubeSat in einen umlaufenden Stein verwandelt.

Ich bin mir nicht einmal sicher, ob wir die Nachrichtenübermittlung auf eine Weise implementieren können, die für die Raumfahrt zuverlässig genug ist. Ich konnte noch nicht einmal produktionsbereite Kommunikationsprotokolle finden, mit denen Nachrichten auf einem Bus mit einem winzigen Betriebssystem oder nackt übertragen werden können Metall wie wir es brauchen. Ich bin aber auch gespannt, ob diese vorgeschlagene Lösung für Prozessmigration, CPU-Redundanz und Lastausgleich für ein sicherheitskritisches System überhaupt realisierbar ist. Es scheint, als könnte dies zu einem Zustand führen, in dem zwei CPUs denselben "Prozess" oder Teil der Programmschleife ausführen, wenn einer aufwacht, der schwer zu erkennen wäre.

8bit.wappen
quelle
Einige Fragen: (1) Wie werden Daten weitergegeben? Gibt es einen Netzwerk- oder Interprozessor-Datenübertragungsbus? Im Gegensatz zu Allzweckprozessoren (Desktop / Server) ist es unwahrscheinlich, dass alle Prozessoren gleichzeitig auf dieselben Speicherbänke zugreifen können. (2) Wie gehe ich mit Geräten (Sensoren und Aktoren) um, die fest mit einem einzelnen Prozessor verbunden sind?
Rwong
1
Daten müssten mit UART oder I2C übergeben werden, wenn wir Shared Memory verwenden würden, könnten wir genauso gut SMP ausführen, aber Dinge, die ich über die Implementierung dieser (vorzugsweise über SPI) wie Speicherbarrieren gelesen habe, werden in unserem Kurs für Undergrad-Betriebssysteme nicht einmal behandelt, geschweige denn Implementierung von Mutex, Semaphor usw. Das Elektro- und Computertechnik-Team hat mir versichert, dass jede CPU an jedes Peripheriegerät angeschlossen ist, aber das Board-Design ist bei weitem nicht vollständig.
8bit.wappen
Ich sehe nicht ein, wie Sie gleichzeitig CPU-Redundanz und Lastausgleich erreichen können. Wenn Sie unterschiedliche Aufgaben auf jede CPU verteilen, gibt es keine Redundanz (wenn die CPU ausfällt, reagiert sie möglicherweise nicht mehr, aber höchstwahrscheinlich wird sie nur zufällig ausgeführt, normalerweise aufgrund von Strahlungseffekten, reagiert aber weiterhin). Aus Redundanzgründen sollten alle Aufgaben auf allen Prozessoren ausgeführt werden. Wenn der Lastausgleich wichtiger ist als Redundanz, dann scheint Ihr Schema einfach genug zu sein. Ich würde einfach jeden Teil als eine andere Aufgabe implementieren, anstatt Zweige einer einzelnen Aufgabe (vorausgesetzt, Ihr RTOS ist Multitasking).
André Sassi
@ AndréSassi: AFAICT Sie beginnen mit Redundanz und einem gewissen Lastausgleich. Wenn bei einigen CPUs etwas schief geht, migrieren Sie die Aufgaben auf andere CPUs, was zu einer höheren Auslastung pro CPU und möglicherweise sogar zu einem geringeren Durchsatz bei geringerer CPU führt. Prioritätsaufgaben oder höhere unkritische Fehlerrate. Dies ist immer noch besser als vollständig zu scheitern.
9000
Was ist der Vorteil dieses Systems, anstatt alle Aufgaben auf allen Prozessoren auszuführen?
user253751

Antworten:

1

Ausgezeichnete Fragen, weil ich Mitte der 90er Jahre tatsächlich einiges davon herausgearbeitet habe. Raumfahrzeuge sind teuer und es ist schwierig, Software im Orbit zu modifizieren. Ich dachte über eine Variante dieses Problems nach, als ich darüber nachdachte, wie Softwareressourcen von Raumfahrzeugen aufgrund sich ändernder Missionsanforderungen neu zugewiesen werden könnten. Soweit wir es im Labor (VxWorks) aufgenommen haben:

  1. Schätzen Sie die Aufgabenlast für jeden Prozessor gemäß den Anforderungen.
  2. Schätzen Sie die Aufgabenlast für den Teilauftragssatz. Dies ist die neue Konfiguration, die gewünscht wird, basierend auf der Bereitstellung der erforderlichen Aufgaben pro Prozessor, die erforderlich sind, um die wichtigsten Missionsanforderungen zu erfüllen. Grundsätzlich, ohne was man nicht leben kann.
  3. Für jeden Prozessor haben wir jetzt ein primäres Missions-Tasking-Modell und Varianten davon, die auf anderen Verarbeitungszuständen basieren, zu denen wir möglicherweise so schnell wie möglich wechseln müssen. Dies ist eine einfache geplante Anpassung. Nichts Besonderes, nur verschiedene Sätze von Tasking-Modellen, die einige Reize ein- und ausschneiden. Der Lastausgleich in meinen Experimenten war im Wesentlichen vorgeplant. Für diese Operation haben wir die grundlegende RMA-Planung verwendet. Grundsätzlich ist dies ein großer Kontextwechsel auf systemweiter Tasking-Modellebene.

On Station Programmaktualisierungen unter einem RTOS. Schließen Sie im Grunde einen neuen Task-Set an, schließen Sie das Warteschlangennetzwerk an und starten Sie den Datenfluss erneut.
In dieser einfachen Implementierung haben wir einige Aufgaben angehalten oder entfernt und andere ausgeführt. Wir haben es in der sogenannten "Herztransplantation" etwas weiter gebracht. Dies war für On-Station-Software-Updates. Wir könnten die Warteschlangennetzwerke innerhalb des Tasking-Modells trennen und umleiten. Trennen Sie die Aufgabe grundsätzlich und beseitigen Sie sie, falls gewünscht, beenden Sie die Warteschlangen und verbinden Sie die neue Aufgabe (Herz) und die Arterien (Warteschlangennetzwerk) erneut. Wir haben diese Spielzeit 1995/96 gemacht. Ich wollte nicht nur die Möglichkeit haben, Funktionen hinzuzufügen, sondern diese auch nicht zu entfernen, da der Speicher eine sehr begrenzte Ressource ist. Ich weiß nicht viel über MPI, ich habe es nie benutzt. Ist es deterministisch? Mit der Informationstheorie brauchen Sie nicht viel, um ein Keep-Alive-Signal zu senden. Verwenden Sie minimale Bits. Die gängigsten Informationen wie "Keep Alive" benötigen nur ein Bit. richtig oder falsch. Ereignisse, die mit einer viel geringeren Wahrscheinlichkeit auftreten, benötigen mehr Bits zur Darstellung. Beseitigen Sie jeglichen Software-Overhead, den Sie können. Folgen Sie dem KISS-Prinzip (Keep It Simple..Stupid!).

Jetzt irgendein Strahlenschutz. Studentenprojekt bedeutet wahrscheinlich CMOS fliegen. Ich würde zumindest CRC-Checks in den Speicher stellen und einen Watchdog ausführen, um Fehler zu erkennen, wie z. B. Aufhängestrahlung seltsame Dinge für die Elektronik bewirkt. Einzelereignis-Störungseffekte können mithilfe von CRC im Speicher verringert werden. Das Einrasten erfordert einen Power-Reset.

Ich würde vorschlagen, etwas wie FreeRTOS auszuprobieren und zu sehen, welche Funktionen Sie Ihrem Willen anpassen können. Der Weltraum ist eine sehr herausfordernde Umgebung. Habe Spaß.

Vimyixen
quelle