Wie wurde angesichts kleiner Rechenressourcen die Navigation implementiert? (Keine Beispiele alter Führungssoftware)

Bei vielen der frühen Sonden, bis in die Nähe von Apollo, gab es keine echten Computer auf Raumsonden. Alle Berechnungen wurden auf der Erde durchgeführt und die Bordelektronik war als Sequenzer bekannt, für Pioneer 10 hatte sie 222 mögliche Befehle, von denen 5 vorbereitet werden konnten. Frühe Venus-Sonden sendeten Daten, indem sie verschiedene Sensoren mechanisch schalteten, um einen CW-Sender der Reihe nach zu modulieren und alles auf der Erde auseinander zu sortieren.

Dies galt auch für einen Großteil des Apollo-Startprozesses, bei dem die Hardware in der Startplattform keine echte Software ausführte, sondern eine Sequenz (ab hier ) von „warte, aktiviere dies, warte, messe das und wenn außerhalb der Grenzen, halte sonst weiter“. .

Zusammen mit dem AGC-Code-Link von Ludo können Sie sich den Abort-Controller als ein kleineres Beispiel dafür ansehen, wie die Dinge gemacht wurden (feste Schleife bekannter Schritte und Timings).

Selbst heute ist es sehr selten, Code an ein Raumschiff zu senden, der nicht auf eine Folge sehr spezifischer Anweisungen hinausläuft, die der Reihe nach ausgeführt werden müssen. Curiosity verfügt über einige autonome Navigations- und Fotoaufnahmefähigkeiten, aber im Allgemeinen ist Verzweigungscode dazu da, Fallback/Fail-Safe auszulösen, „Ups Stop, Problem mit der Antennenausrichtung zu lösen und zu Hause anzurufen, um Anweisungen zu erhalten“, anstatt KI oder Lerncode.

Im Allgemeinen wurde der Code so erstellt, dass er genauso funktioniert, wie Menschen heute für Mikrocontroller programmieren:

Keine Art von Benutzeroberfläche im Code (Apollo DSKY war größtenteils Hardware)

Verwenden von Annäherung oder ganzzahliger Mathematik über Gleitkomma (viele Dinge sind möglich, wo pi = 3 ist) oder Vorberechnen von Konstanten auf der Erde und Hochladen bei Bedarf (z. B. Schwerkraft oder Motorleistung)

Kundenspezifisches Design von unterstützender Hardware wie Sterntrackern, die mit Konstanten von der Erde vorgeladen werden und vorformatiert und gebunden für den nächsten Verarbeitungsschritt geprüft werden. Bounds prüfen tatsächlich nur einmal, woher die Daten stammen, und stellen sicher, dass kein nachfolgender Schritt sie überlaufen kann.

Entwerfen Sie Algorithmen, die eher in Registern als in Speicherorten arbeiten (was eine schreckliche Quelle darstellt, da Sie keine Variablen haben), aber bedeutet, dass Sie vermeiden können, dass viele Werte in den und aus dem Speicher verschoben werden.

Vermeiden Sie allgemeine Probleme für das Spezifische, für Raumfahrzeuge ging es nur um Navigation, Meldung von Sensor-/Instrumentenzuständen und Ausrichtung. All dies könnte sorgfältig ausgearbeiteten Code haben, der über einen bestimmten Bereich von Eingaben gut funktioniert ( obwohl siehe ).

Vertrauen Sie Ihren Daten (im Sinne der Sicherheit) ( obwohl die Natur Sie immer noch erwischen kann )

(ursprünglich beantwortet zu "Beispiele alter Leitsoftware")

Das erste, was mir in den Sinn kommt, ist das Github-Repository des Apollo 11 Guidance Computer (AGC) . Das Repository enthält sowohl Command Module- als auch Lunar Module-Software, aber beachten Sie, dass es von Hardcopies transkribiert wurde und daher möglicherweise (noch) nicht vollständig ist. Einen Simulator der AGC finden Sie auf der Virtual AGC-Website (dort gibt es auch eine Menge anderer Referenzen).

Ich bin Softwareentwickler und mit all den heute verfügbaren Ressourcen kann ich mir nicht vorstellen, wo man mit einem solchen Unterfangen überhaupt anfangen könnte.

Bis heute gibt es viele computerbasierte Systeme, die mit solchen Einschränkungen leben müssen. Es gibt viele eingebettete Systeme, bei denen 2^16 (65536) Bytes Speicher ein Luxus bleiben. Schließlich macht es auf Maschinen, die 16-Bit-Speicheradressen verwenden (von denen es noch viele gibt und die bis heute noch hergestellt werden), keinen Sinn, mehr als 65636 Byte Speicher zu haben. Und so wie es kein Problem mit einem Computer mit 64-Bit-Adressen gibt, der weniger als 18+ Exabyte Speicher hat, gibt es kein Problem mit einem Computer, der 16-Bit-Adressen mit weniger als 2^16 Byte Speicher hat.

Es gibt viele Möglichkeiten, mit einem solchen Unterfangen zu beginnen. Die wichtigste Regel lautet, auf die Verwendung eines Betriebssystems zu verzichten. Viele (die meisten?) eingebetteten Systeme sind nackte Maschinen . Es gibt kein Betriebssystem und es läuft immer nur ein Programm. Ihr Mikrowellenherd verfügt über einen Computer, der als eingebettetes System arbeitet und über kein Betriebssystem verfügt. Wenn Ihr Auto in den letzten 25+ Jahren hergestellt wurde, laufen viele eingebettete Systeme darin. Wenn Ihr Auto auch nur annähernd modern ist, verfügt es über mehrere Dutzend Mikrocontroller, die zusammen mehrere Millionen Codezeilen ausführen.

Viele der Mikrocontroller in einem modernen Auto unterliegen nicht der Adressbegrenzung von 64 KB (2^16 oder 65536). Früher war dies eine sehr verbreitete Grenze, die die Größe des Speichers von Natur aus begrenzte. Aber es schränkte die Speicherung nicht ein. Das Problem, dass die Festplattengröße die Adressbeschränkungen überschreitet, wurde in den 1950er und 1960er Jahren gelöst. Eine gängige Lösung war die Verwendung von Speicherüberlagerungen . Diese Technik, die ich froherweise (meistens) vergessen habe, ist bis heute in der Programmierung eingebetteter Systeme üblich.

Eine weitere weit verbreitete Technik war und ist es , die eingebettete Maschine einer Harvard - Architektur folgen zu lassen , im Gegensatz zu einer von - Neumann - Architektur . Es gibt keine Unterscheidung zwischen Code und Daten in einer Von-Neumann-Maschine. Code und Daten sind in einer Maschine mit Harvard-Architektur sehr unterschiedliche Dinge, möglicherweise mit unterschiedlichen Wortgrößen. Ihr Laptop oder Desktop-Rechner ist höchstwahrscheinlich, zumindest oberflächlich betrachtet, ein von-Neumann-Architektur-Rechner. Tief unter der Haube sieht es eher aus wie eine Harvard-Maschine mit separaten Caches für Code und Daten.

Die Art und Weise, wie es in der ICBM-Welt implementiert wurde, bestand darin, dass sechs Kollegen um einen Tisch herum saßen und gleichzeitig die mathematischen Routinen und die Gesamtarchitektur, die detaillierte Codierung der Programmkomponenten und die Computerhardware entwarfen. Fünf Zeilen Code pro Tag galten als gute Tagesarbeit. Die meiste Zeit wurde damit verbracht, darüber zu streiten, ob man etwas mit Hardware oder Software machen sollte. Integrierte Schaltungen waren so weit fortgeschritten, dass Vier-Bit-Register verfügbar waren. Sie wurden für die beiden Register der CPU verwendet.

In dem System, an dem ich gearbeitet habe, gab es keinen adressierbaren Speicher. Nur eine Scheibe mit einem Haufen fester Köpfe. Der Code wurde auf die Festplatte getaktet. Es gab einen oberen und einen unteren Bus und zwei Register mit einer Wortlänge, aber es war ein großes Wort.

Am Ende gab es vier Programme, die per Remote Data Change ausgetauscht werden konnten. Nur eines war für den Flug, die anderen waren Bodenprogramme.

Die Hardware erledigte die meiste Arbeit, Dinge wie 3 x 3-Matrix-Mathematik wurden mit ein paar Mikrocode-Anweisungen erledigt, die dazu führten, dass eine neue Matrix eine alte an derselben Stelle auf der Festplatte ersetzte.

Die CPU hatte oft Bereiche, die während dieser längeren Anweisungen nicht verwendet wurden, sodass sie kleine Additionen/Subtraktionen/Multiplikationen/Divisionen in der Mitte einschleichen konnten. Diese Anweisungen schalteten nur kleine Teile der CPU um, und es waren VIELE Anweisungen verfügbar. Man musste nur dafür sorgen, dass alles an der richtigen Stelle auf der Diskette war, damit es verfügbar war, wenn man ein bisschen Freizeit hatte. Sie hatten fünf verschiedene Anweisungen zum Dividieren zweier Zahlen, die sich nur in der Route und dem Timing des Prozesses innerhalb der CPU unterschieden, um Kollisionen mit anderen laufenden Berechnungen zu vermeiden. Viele der Buchhaltungsfunktionen wurden auf diese Weise erledigt.

Der wirklich lustige Teil war, dass Sie eine lange Anweisung beginnen konnten, bevor Sie alle Zahlen hatten, um sie abzuschließen. Während es am vorderen Ende schleifte, konnten Sie eine Additionsoperation initiieren und sie in einem Register belassen, damit die lange Anweisung sie später finden konnte. Möglicherweise können Sie es sogar auf die Festplatte schreiben. Es war eine wahre Freude, diese zu verfolgen und zu debuggen.

Der Navigationscomputer musste drei Ausgangssignale ansteuern, um die Rakete zu steuern. Es wusste nichts über Inszenierung oder sonst etwas. Es hatte eine Tabelle, die besagte, dass es Beschleunigungsmesserzählungen von x, y, z zum Zeitpunkt t sehen sollte (akkumulierte Impulse gleich Geschwindigkeit der Beschleunigungsmesserachse). Es verglich die tatsächlichen Zählungen mit der vorprogrammierten Tabelle und berechnete neue Steuersignale.

Die Quintessenz ist, dass die Programmierer ein ziemlich begrenztes Ziel hatten und eine vollständige Karte der CPU in ihrem Kopf hatten und die gesamte CPU-Operation in ihrem Kopf verfolgen konnten, während die Programmkomponenten ausgeführt wurden.

Ich war nicht in der Designphase, wurde aber von einem der Jungs, die am Tisch saßen, in die CPU und den Microcode eingewiesen.

Schauen Sie sich die FORTH-Sprache an. Es macht keinen Unterschied zwischen Benutzercode und dem Code im (winzigen) OS-Kernel. Es wurde in der Firmware früher Satelliten verwendet. Eine gute Beschreibung ist hier: https://en.wikipedia.org/wiki/Forth_(programming_language)

Vielleicht möchten Sie dieses Buch lesen: https://www.goodreads.com/book/show/7754526-the-apollo-guidance-computer

Die erste Hälfte ist eine detaillierte Beschreibung der Hardwarearchitektur des Apollo Guidance Computers und der darauf ablaufenden Software. Es gibt einige faszinierende Diskussionen über die Einschränkungen der Hardware und darüber, was die Designer getan haben, um diese Einschränkungen zu überwinden.