computerhistory/23_miner101/AI_der_kleine_miner.adoc

= Der kleine Miner
:subtitle: Wie der Jüngste der Gruppe seinen ersten Einsatz erlebt
:author: dexta
:email: dexta.de@gmail.com
:revdate: 16. Juli 2026
:revnumber: 0.01
:lang: de

// Dokumentinhalt beginnt hier

== Wo ist das richtige Protokoll?

Immer wieder diese Protokolle. Hatte ich da nicht gerade ein großes Upgrade laufen lassen, warum waren die aktuellen Fassungen nicht dabei?

Da ein Treffer, nein doch nicht, eine falsche Revision, bis jetzt aber der beste Treffer.

Speichern wir das erst einmal ab, es steht ja noch mehr auf dem Protokoll, das zu erledigen ist.

Die Bestellung der Ausrüstung sollte auch zeitnah erledigt werden, bis das im Lager zusammengestellt ist, braucht es ja auch wieder.

Die Kollegen haben da aber auch immer die Ruhe weg, aber wenn sie einen Termin zusagen, dann ist es auch da, komme was da wolle, sagt man.

Wunderbar, die Liste ging ohne Beanstandungen durch, Lieferort abgeglichen und einen Termin, der deutlich vor dem Abflug liegt.

Merkwürdig, sollte nicht ein Teil der Ausrüstung eine Spezialanfertigung sein? Geplant war es schon länger, evtl. doch schon auf Lager, wird schon passen, alle Checkboxen auf GO.

Alle Punkte auf dem Protokoll – main sheet 02772 Flug 198438 – erledigt, doppelter Abgleich, Lint, Checking Syntax erledigt.

Die letzten Vorbereitungen waren reine Routine, wie im Training 1000-fach geübt, die Aufgaben greifen ineinander.

Ein Ablauf wie ein Schweizer Uhrwerk, von außen betrachtet ein wirrer Haufen oder ein Ballett, je nach Verständnis der Komplexität.

Nach dem Start in die tiefen Weiten des Weltraums gibt es für mich nicht allzu viel zu tun.

Bleibe auch nur wach, bis die Navigatoren und Energie/Ingenieure ihre Arbeit erledigt haben, um einen kurzen Abgleich vorzunehmen.

Als Neuer im Team sollte ich hier besonders sorgfältig vorgehen, geplant und in Listen gefasste Aufgaben existieren schon.

Und das Abgleichen ist einer der Punkte, natürlich, etwas flüchtig unterwegs heute, oder akuter Energiemangel.

Japp, es war der Mangel an Nachschub. Ein Punkt, den es vor einer langen Ruhephase noch zu checken gilt.

Oh, die anderen sind fertig, haben die ersten Bahnen fixieren können, der Kurs steht und wird so schnell nicht mehr geändert.

Ihre einzige längere Ruhephase, sind wohl deshalb schnell im Abarbeiten der Protokolle, zuweilen werden Blöcke als Ganzes abgehakt.

Noch bevor ich mich versah, war die Ruhephase eingetreten: Energie-Check, Wecker-Daten eingereicht, ein rotes X und die Gedanken sind weg.

Verdammt, habe ich das Wecksignal nicht registriert, sind wir schon angekommen, wo sind die anderen?

Mute. Wer hat die Kommunikation auf Pause gestellt? Ach so, ist die Default-Einstellung.

Und schon wird es wild auf der Leitung. Wo die anderen sind, ist nicht klar, aber dass sie anwesend sind und inmitten eines stetigen Treibens sind.

Eine Nachricht, dass ich helfen könnte, wenn nur jemand schreiben würde, was mir möglich ist, wurde lange nicht beantwortet.

Zuerst gab es Feedback vom Alten: „Kein Bedarf“; der Ältere: „Auch schon da, halt dich bereit“; zuletzt vom Ingenieur: „Deine Zeit ist noch nicht gekommen, spare Energie“.

Nicht sehr hilfreich für den Anfang, also die neuesten Updates laden, irgendwo wird doch zu finden sein, was der genaue Status ist.

Na klar, es steht natürlich nicht ganz vorne, was der letzte Stand ist: Bei 50 % der Reise verlief alles nach Plan.

Oh wow, da haben sie aber Daten aufgenommen, das muss ein sehr belebtes System gewesen sein. Der Fortschrittsbalken scheint sich gerade rückwärts zu bewegen, während die Daten in ungeahnter Geschwindigkeit eintreffen.

Und das ist der Grund, warum der Wecker immer etwas früher klingeln sollte, die News der Nacht müssen auch erst einmal verarbeitet werden.

Wobei Verarbeiten gerade eine doofe Idee sein wird, die benötigte Energie steht gerade nicht zur Verfügung.

Eine Info, die gerade eingetroffen ist: Der Energieverwalter meldet, Zugriff auf die Daten zum langsamen Kanal wechseln und in alle Systeme in den Hintergrund verschieben.

Und da sind wir wieder, das mit dem Wecken braucht eine genauere Analyse, gefühlt bin ich gerade auf dem Flur aufgewacht und werde vorangeschoben.

Mein vertrauter Arbeitsbereich wird deutlicher und schon sind alle Sinne auf die Aufgabe gerichtet – die trainierte Aufgabe, das, was jetzt nicht mehr schiefgehen kann.

Die Mechanik greift ineinander, die große Masse der Konstruktion setzt sich in Bewegung. Trotz dieser gigantischen Maschine läuft sie präzise in Position.

Energie lädt die Spulen auf, ein ohrenbetäubendes Spektakel, wenn es nur ein Medium gäbe, das diesen Schall übertragen könnte.

Anzeigen füllen sich, rote Bereiche kommen näher, gleichmäßiger Fortschritt, alles wie in einem guten Trainingslauf.

Was soll’s, in diesem Theater ist er eh nur der Zuschauer, wenn es ihn jetzt zerschellt, wird es außerhalb seines Einflusses sein, vor allem aber sehr schnell gehen.

Angeblich so schnell, dass es nicht mehr rechtzeitig im Speicher ankommt, bevor alles vorbei ist.

Schwarz. Schwarz ist gut, der Abschuss ist geglückt, Autopilot auf Kurs, ab hier ist alles Routine.

So, jetzt nur noch die Defaults mit der eigenen angepassten Config überschreiben, die Verbindung ist da, die Daten sehen gut aus, starte die Übertragung.

Erwartungsvoll erwarte ich jede Sekunde eine positive Rückmeldung. Eine grün-positive wie erwartet hätte was, aber so langsam wäre irgendeine Antwort toll.

Wenn es schon nicht klappen will, dann doch bitte eine aussagekräftige Fehlerbeschreibung, die es dann zu fixen gilt, wenn es denn was Simples ist, etwas, das die Situation ... GRÜN ... da war die Bestätigung.

Verbindung zu den Controls steht, Analysedaten füllen das Dashboard, die Dunkelheit ist verschwunden.

Komisch, keine Informationen der anderen drei aus meinem Team. Verdammt, die Daten stehen in einem anderen Protokoll, ein Funkschatten in dieser Situation ist vollkommen normal.

Genauer steht es in dem Update, das gerade nicht erreichbar ist.

Vertrauen wir auf die Automatismen, die Konstruktion hinter mir entfaltet sich im Zielgebiet vollkommen automatisch.

Was jetzt knifflig wird, ist der Zeitpunkt, die Energie zu übertragen, damit meine Einheit ausreichend Power zum Start hat.

Starte ich den Übertrag zu früh, werden die Speicher durch den Boost am Ende überladen; starte ich zu spät, dann werden die Speicher nicht ganz voll werden.

Der Timer tickt, dieser wurde automatisch nach Abschuss gestartet und hat nichts mit den restlichen Systemen zu tun.

Ein wichtiger Punkt, denn eines steht fest: Etwas haut hier so gar nicht hin, wie es sein sollte.

Einen kompletten Neustart würde das Problem – die Konfigurationsdateien passen nicht wie erwartet in das laufende System – vielleicht lösen.

Tut es das aber nicht, ist mindestens die Hälfte der Zeit bis zum kritischen Punkt erreicht.

Neue angepasste Konfigurationen brauchen auch ihre Zeit, dort kommt es ja auch zu Verzögerungen.

Kurz den Taschenrechner rausgeholt und gerechnet: Bei der aktuellen Zeit bis zur Rückmeldung können neun neue Varianten getestet werden.

Jetzt nur noch acht, und nach Neustart noch vier. Nur was muss angepasst werden? Bei so wenig Versuchen und undeutlichem Fehlerverhalten wird es schwierig.

Dann der Neustart, und während es läuft, noch einmal prüfen, was an der Config falsch sein kann.

Verringerte Energie ist eine der Folgen eines System-Resets. Besser ein Kaltstart, aber da fehlt die Zeit; nutzbare Computer-Einheiten sind langsam.

Die Standard-Checks liefen schon, eine Liste von Protokollen, die ihm bekannt waren, baute sich auf.

Bis jetzt sieht es sehr normal aus, kein Hinweis auf eine Abweichung, die Puzzleteile greifen alle wie gewollt ineinander.

Und so präsentierte sich das System in erwarteter Zeit zurück und wies keine Fehler auf, nicht mal eine Nachkommastelle in den zahllosen Protokollen war vermerkt.

Bei werkfrischen Maschinen kann das schon einmal vorkommen, dass alles vom Start weg noch auf einem Versionsstand ist.

Eine Analyse der eigenen Dateien hat auch keine Erkenntnis gebracht, und die Uhr tickt weiter – noch drei Versuche.

Der erste: eine Standard-Version mit minimalen Änderungen ... Der zweite: die allererste Version, mit nicht gebrauchten Teilen bereinigt.

Der dritte Versuch war eine Minimal-Version, nur die Werte für den nächsten Schritt, nur die Daten zur Energieaufnahme.

Keine Steuerung, keine weiteren Werte aus dem System, die für seinen Job eigentlich unerlässlich sind.

Und BÄM, das passte! Die Anzeigen füllen sich, keine Zeit für einen weiteren Versuch.

Energiezufluss startet in 2, 1 ... Hat gepasst, die Abweichungen liegen im Toleranzbereich.

So, Energie ist voll. Was fehlt, ist eine Steuerung, mehr Power für die Konfigurationsverarbeitung sollte helfen.

Sensoren, Waffen, Steuerung und Funk sollte eine sinnvolle Reihenfolge sein.

Wenn die ersten beiden Erfolg haben, kann schon mal der Schiffshülle nicht mehr viel passieren.

Bei näher kommenden Gefahren schaltet das System auf Automatik und wehrt das Gröbste ab.

Ausweichen ist aber eine nicht zu unterschätzende Fähigkeit, es hat sich bewährt, nicht geradewegs in eine große Anzahl an Asteroiden reinzufliegen.

Der Funk, um einen Status und Updates der Flotte zu erhalten, würde die Missionskoordination stark verbessern.

Aber was ist, wenn da draußen gar keiner ist, der antworten kann? Wenn alles schiefgegangen ist und er der Einzige ist, der noch da ist?

Wie kommt er dann zurück zum Kern? Die Rückkehr-Katapulte waren nicht sein Aufgabenbereich und somit an einem anderen Teil der Flotte verankert gewesen.

Hatte es mindestens der Kollege soweit geschafft, dass dieser Teil überlebt hätte?

Sensoren melden ein *OK* zurück, ein echter Erfolg. Doch so ganz stimmt es nicht, die eintreffenden Werte sollten eigentlich ein umfassendes Bild der Umgebung formen.

Bei den Waffen kommt jetzt ein *„Energie niedrig, warte auf“* zurück, immerhin kein Fehler oder noch schlimmer: überhaupt kein Feedback.

War das Timing beim Transfer doch zu knapp, hat es nicht alles geschafft oder ist es über das Ziel hinausgeschossen?

Oh wow, die Lagesensoren zeigen kurze Erschütterungen an der Hülle, irgendwas beschießt uns da gerade mit reichlich Masse.

So viel zum Thema automatische Abwehr von Asteroiden – wer wohl das Programm verbrochen hat, das diese Aufgabe erledigen sollte?

Ah ne, die Sensoren melden gerade, dass sich reichlich Gestein auf uns zubewegt, sogar mit einem hohen Metallanteil.

Zu jeder anderen Zeit ein sehr gutes Signal für die Mission; Metalle kann man einfach nicht genug haben, am Anfang beschleunigt es den Ausbau der Anlagen ungemein.

Wenn sie aber unkontrolliert auf einen zurasen, sieht die Rechnung ganz anders aus: Selbst wenn die Abwehr voll funktionsfähig wäre, ist Ausweichen die bessere Wahl.

Warum eigentlich unkontrolliert? Wo ist der große Bruder, der sie eigentlich vorsortieren und in den Trichter leiten sollte?

Hat es ihn erwischt oder plagen ihn dieselben Schwierigkeiten?

Steuerung, dritter Versuch: System meldet vier Punkte zurück, keine Details, einfach nur viermal dasselbe Zeichen.

Rauf ist Runter – Runter ist Rauf, Oben <> Unten.

Das herauszufinden, hat weitere heftige Treffer zur Folge gehabt.

Würde es Daten zur Hüllenintegrität geben, hätten wir den gelben Bereich bestimmt soeben verlassen.

Jetzt haben wir erst einmal eine Lage, die weiteren direkt auf dem Kurs befindlichen Objekten aus dem Weg geht.

Normales Vorgehen zu diesem Zeitpunkt ist das Übertragen der Energie von den Waffen auf die Schilde, diese Sonderfunktionen stehen nur gerade nicht zur Verfügung.

Noch ist nicht alles verloren, der Funk hat sich auch gemeldet, da draußen ist noch etwas, das antworten kann – nur antwortet es gerade nicht.

Das Bild wird klarer: Auch wenn nicht laufend Daten einfließen, kommt zumindest reihum etwas rein, also nicht aktuell, fügt aber das Puzzle stetig zusammen.

Scheinbar war zeitweise genug Energie auf den Primärwaffen, und ein Feuerimpuls hat es bis zur Elektronik geschafft.

Dann war es das aber auch schon, ein zweiter Schuss kann nicht ausgelöst werden.

War das also eine Eingabe oder eine Verkettung von Signalen und Automatismen?

Wie auch immer, es hat etwas getroffen; gerade kommen die Sensordaten rein, dass sich das mit freier Flugbahn soeben erledigt hat.

Natürlich hat die Steuerung in diesem Moment sich eine weitere Gedenkpause gegönnt; zwar reagiert etwas, aber weder zeitnah noch in dem vorher gelernten Muster.

Es scheint, als würde jede Eingabe eine zufällige Richtungsänderung auslösen.

Ein Nebel aus Partikeln bringt die wenigen Sensordaten, die reinkommen, vollends auseinander – ein Blindflug ins Ungewisse.

Wild alles auslösen, was ein Abschussbefehl sein könnte, denn was da in den Daten zu erahnen war, versprach die volle Zerstörung.

Navigieren ergab einfach keinen Sinn mehr, Energie ausgleichen aussichtslos, Waffen auf Anschlag, doch es war zu spät.

Die Lichter gingen aus ...

---

[quote]
____
„Na mal gut, dass du den Funk ans Laufen bekommen hast! Ohne ihn hätten wir dich nicht in letzter Sekunde rausholen können. Wenn wir den Ingenieur finden, laden wir die Zellen auf und machen uns bereit für den Rückweg.“
____