Etwas irritierend ist, dass mehrere unabhängige Systeme versagt haben:
1. Das Landegestell selbst sollte durch Dämpfer schon so abfedern, dass wieder hoch hüpfen verhindert wird.
2. In jedem der drei Landebeine gab eine Bohrschraube, welche sich rein durch die mechanische Energie beim Aufsetzen ins Eis bohren sollten.
3. Ein Triebwerk oben auf Philae sollte den Roboter beim Aufsetzen an den Boden anpressen. Dieses Kaltgas-Triebwerk besteht eigentlich nur aus einem Druckluftbehälter und einem Ventil und soll in anderen Missionen immer zuverlässig gearbeitet haben.
2. Der Roboter sollte mit zwei Harpunen im Boden verankert werden, auch hier hat keine ausgelöst.
1. und 2. waren rein mechanische Systeme.
Grundsätzlich geht es mir gleich, ich bin jetzt auch schon seit 1976 in der Entwicklung von µC-System tätig.
Was sich seit damals grundlegend geändert hat ist, dass heute noch mehr zwischen Soft- und Hardware getrennt wird und die meisten Programmierer keine Ahnung von Hardware und Assembler haben.
OK, das gab es damals schon bei den Grossrechnern, da wurde zwischen System- und Anwendungsprogrammierern unterschieden. Für Anwendungsprogrammierer bestand die unterste Ebene aus dem API des Betriebssystems. Bei kleineren System bestand das API aus BASIC mit ein paar zusätzlichen Befehlen um Terminal, Drucker und Plattenlaufwerk anzusteuern.
Die Systemprogrammierer waren dann hauptsächlich in Assembler unterwegs, mussten Driver für die Hardware schreiben und anpassen und waren damit beschäftigt das System zu optimieren.
Ein anderer Punkt ist, dass die damalige Hardware grundsätzlich etwas weniger zuverlässig war. Schon die Lesefehler-Raten, vor allem von dynamischem RAM, waren wesentlich höher. Mit der Technik aus den 70er Jahren wäre schon rein deshalb ein Speicher mit 1GB nicht realisierbar gewesen, da hätte man im Betrieb etwa jede Sekunde mit einem Lesefehler rechnen müssen.
Auch hatte man die Halbleiterfertigung noch nicht so im Griff wie heute, in den 70er Jahren lag die Strukturgrösse noch um 1µm.
Wir hatten 1976 eine Lieferung von 6502-CPUs aus einer der ersten Produktions-Chargen. Von 100 Geräten funktionierten eigentlich alle. Wenn beim Kunden die Raumtemperatur aber unter 20°C lag, führte die CPU intern den Reset nicht richtig aus. Eine thermische Nachbehandlung der CPUs (Backen der Chips bei etwa 130°C über 10h, die maximale Lagertemperatur lag, laut Datenblatt, bei 175°C) löste dann das Problem. Von den 100 CPUs waren dann 2 defekt und der Rest funktionierte perfekt. Aus Kostengründen wurde ein abgleichbarer RC-Oszillator verwendet und kein Quarz. Nach dem Backen standen dann alle Trimm-Kondensatoren in der selben Stellung (Damals war ein guter Trimm-Kondensator billiger als ein Quarz, heute ist das umgekehrt!).
Später hat uns dann MOS bestätigt, dass die ersten Chargen ungetestet ausgeliefert wurden und das nachbacken empfohlen ...
Auch machte das BIOs des IMP-PCs nach einem Reset eine Menge Selbsttests. Unter anderem gab es auch eine Reihe Tests, welche z.B. die internen Register des 8088 getestet haben, man hat damals immer damit gerechnet, dass auch die CPU selbst einen Fehler haben kann!
MfG Peter(TOO)
- - - Aktualisiert - - -
Heute können doch schon die Kids ihre Legos programmieren, was braucht es da Fachwissen ??
Ein erfahrener Programmierer will doch nur mehr Lohn!
Lesezeichen