Werkzeuge mit Werkzeugen machen, die Werkzeuge machen, die wieder Werkzeuge machen, die wieder Werkzeuge machen …

Computer Vintage
oder:
Wenn Produktions- und Entwicklungsketten zu komplex werden, dann könnten sie ja auch mal (zer-)reißen

Die Gedanken zu diesem Artikel entstanden im Rahmen einer kurzen Diskussion, inwieweit unsere entwickelte Gesellschaft technologisch wieder in das prä-elektrische Zeitalter zurückfallen könnte. Mein Gesprächspartner meinte, das wäre unmöglich. Dieser feste Glaube hat mich zum Nachdenken gebracht.

Anfang der 70iger Jahre studierte ich an der TUM Mathematik mit Nebenfach Informatik und war schon bald bei Siemens als Werkstudent tätig. Weil es da tolle Rechner (Computer) gab und man als Student für damalige Verhältnisse gut verdient hat.

Ich war damals in den Baracken der „Koppstrasse“ tätig. Getestet haben wir im „Feurich-Bau“ – im Zentralgelände der Siemens AG an der Hofmann-Straße. Das Leben in den Baracken war toll, es war eine richtige F&E-Atmosphäre, so wie man es sich heute bei einem guten Start-up vorstellt.

Mein erstes Projekt habe ich hier in IF-Blog beschrieben. Es ging damals um das Berechnen von möglichst großen Mersenne-Primzahlen. Das war eine Aufgabe eher für einen Einzelkämpfer.

Dann wurde ich immer mehr Teil der Teams und fast berauscht von denn Herausforderungen unserer Aufgabe. Wir arbeiteten gemeinsam mit weiteren Kollegen an der Entwicklung der PALOG-A- und PALOG-B-Systeme.

PALOG stand für „PrüfAutomat für LOGik. Die Aufgabe eines PALOG-A-Gerätes war der Funktionstest von in kleinen Serien gebauten „Maxi-Flachbaugruppen“, die in Groß-Rechnern unterschiedliche Funktionen realisierten. Die Funktionalität und die Richtigkeit der zu realisierenden Logik waren schon getestet.

Es ging „nur noch“ um das Prüfen, ob die Serien-Produktion fehlerfrei erfolgt war und die gefertigten Komponenten zuverlässig die gewünschten Ergebnisse lieferten. Die erweiterte Funktion des PALOG-B erläutere ich im weiteren Teil des Textes.

So eine Maxi-Flachbaugruppe war ein großes Brett (Board), ziemlich breit und tief aber von geringer Höhe. Die auf den Bildern abgebildeten Boards stammen aus späterer Zeit und waren viel kleiner.

Eine Maxi-Flachbaugruppe hatte auf einer Seite eine Steckleiste mit 128 Stiften, die in die Rückwand des Großrechners eingesteckt wurden. Dieser speiste das Board mit digitalen Mustern entsprechend der Anzahl der Stifte, bekam vom Board ein Ergebnis zurück und verarbeitete dieses weiter. (Vielleicht täusche ich mich und es waren nur 64 Stifte, aber ich erinnere mich deutlich an 128.)

Das Board war auf der Oberfläche voll mit Elektronik-Bauteilen, die ein paar Füße oder mehrere Füßchen hatten. Diese wurden in die vorbereiteten Löcher des Brettes gesteckt. Das ganze wurde dann von unten entsprechend verlötet, bei Serienproduktion in einem Lötbad.

Die Bauelemente auf dem Board waren zum Teil von Siemens selber entwickelt und produziert. Einiges musste zugekauft werden. Ich habe da besondere Chips von Motorola in Erinnerung, die im Einkauf auch mal um die 1.000 DM kosteten.

Wenn ich mich hier nicht korrekt ausdrücke habe, dann bitte ich dies zu entschuldigen. Ich habe nie Hardware gemacht, sondern mich schon damals ausschließlich auf die Entwicklung der Software beschränkt.

Der Prozess der Bestückung und Verlötung war alles andere als trivial.  So war es durchaus möglich – und kam auch häufig vor – dass diese Maxi-Flachbaugruppen nach der Fertigung keine oder falsche Ergebnisse lieferten. Manchmal kam es auch vor, dass die zu gelieferten Einzelteile defekt waren.

Aber wie findet man das raus? Wie testet man so eine Maxi-Flachbaugruppe?

Unsere Methode war einfach. In das zu prüfende Objekt wurden Bitmuster gesendet und dann geprüft, ob die Antwort die richtige (erwartete) ist. Einen solchen Test kann man aus Effizienzgründen natürlich nicht mit allen möglichen Eingabe-Mustern durchführen. Die Aufgabe unserer Software war es, relevante Muster zu generieren, mit denen man in möglichst wenigen Testschritten beweisen konnte, dass die Logik der Maxi-Flachbaugruppe richtig funktioniert.

Dazu wurde diese in den PALOG-A Automaten eingespannt und dort mit den ihrer Funktionalität entsprechenden Binär-Mustern über die 128 Stifte beschickt. Die Antworten wurden mit den Soll-Ergebnissen verglichen. Wenn IST und SOLL bei allen Testmustern übereingestimmt hatte, war validiert, dass die Maxi-Flachbaugruppe einwandfrei funktioniert.

Die Suchen und Finden der relevanten Testmuster war alles andere als einfach und wurde ziemlich „mathematisch“ aus der jeweiligen Funktionalität heraus entwickelt. Die Programmierung erfolgte „cross“ auf BS1000 und dann bald auch auf BS2000.

Die Muster selber und die richtigen Antworten wurden auf Prozessrechnern der Serie 300 generiert. Die hatten übrigens einen 6-Bit-Assembler mit zwei Akkumulatoren und dem schönen Namen PROSA. Die „Dreihunderter“ galten als ungeheuer schnelle Rechner.

Das Spitzenmodell war die 306. Aber auch diese in der damaligen Zeit absolut schnellste Maschine von Siemens brauchte gut und gerne auch mal eine Woche oder mehr für die Berechnung der benötigten Muster.

Ein Rechner lief damals selten eine Woche ohne Ausfall. Meistens stürzte er in so einem langen Zeitraum schon ein paar mal ab. Deswegen hatte die Software neben der algorithmischen Herausforderung noch weitere wie die Wiederaufsetzbarkeit des Programms bei einem Systemabsturz. Dies war damals alles andere als eine Selbstverständlichkeit.

Soweit so gut. Immerhin konnten wir mit PALOG-A zuverlässig validieren, ob eine Maxi-Flachbaugruppe fehlerfrei war oder nicht. Allerdings gab es ziemlich häufig mangelhafte Produkte. Was macht man mit diesen? Allein aufgrund der teuren eingesetzten Bauelemente wollte man die natürlich nicht vernichten oder zurück bauen, denn damit wäre auch nicht viel gewonnen worden. Man wollte also möglichst alle wenn irgendwie möglich reparieren.

Wenn ich einen Fehler in einer komplizierten Logik einer Flachbaugruppe beheben will, muss ich aber zuerst einmal herausfinden, wo er sich auf dem Board befindet. In unserem Fall geht das natürlich nicht durch logisches Überlegen oder „Code Reading“ wie bei einem Programm. Auch einen eingebauten Debugger hatter wir nicht. Die Frage ist ja, welches Bauteil falsch sein könnte, welche Lötstelle nicht funktioniert oder ähnliches …

Da kam unser System PALOG-B ins Spiel. Wenn eine Maxiflachbaugruppe von PALOG-A als fehlerhaft erkannt wurde kam sie ins PALOG-B-System. Dort wurde sie einer (von uns so genannten) PFAD-Methode unterworfen und mit ganz anderen Testmustern bearbeitet. Diese ermöglichten an Hand der zurück kommenden Daten den Fehler auf dem Board einzukreisen. So war es möglich durch mehrfaches Einkreisen die möglichen Fehler zu beheben. Dann wurde das Board wieder mit PALOG-A getestet, und wenn es dann funktioniert hat wurde gejubelt.

Warum das Vorgehen „PFAD-Methode“ hieß, kann man sich gut vorstellen. Man sich nur überlegen, dass verschiedene Eingabemuster verschiedene „Pfade“ auf der Flachbaugruppe durchlaufen. Und wenn man fest stellen kann, welche der vielen möglichen verschiedenen Pfade nicht funktioniert, ist man dem Fehler schon deutlich näher.

Ich habe versucht, das alles möglichst einfach und gut verständlich zu beschreiben. In Wirklichkeit war das Ganze aber sehr kompliziert und wurde von einem über sehr viele Jahre erarbeiteten und weitergegebenen Know-How getragen.

Unsere Software war nur ein kleiner Teil der für die effiziente Entwicklung und Produktion von IT-Systemen notwendigen Design- und Konstruktionssoftware. Da ging es bei Siemens damals mit großen Fortschritten weiter. Ein paar Jahre später hatte die Siemens AG eine umfassende Workbench aus vielen SW-Systemen für die Entwicklung ihrer Chips, die wahrscheinlich allen Konkurrenz-Systemen deutlich überlegen war.

Leider habe ich Abkürzung dafür vergessen, weiß aber noch, dass diese Anwendung als die komplizierteste SW-Lösung der Welt galt und die meisten „Lines of Code“ aller bekannten Programmsysteme gehabt haben soll.

Und dann ging es abwärts mit dem Bereich Datenverarbeitung und all das Know-How verschwand.

😉 Aber was interessiert den Juden und auch uns „die Freud von gestern“?
Vorbei ist vorbei!

Ich kann mir vorstellen, dass das Know-How und die Werkzeugkette, die gebraucht werden um einen Intel-Prozessor oder einen IBM Power zu entwickeln und zu produzieren mittlerweile eine ungleich höhere Herausforderung darstellt als damals die doch noch überschaubaren Flachbaugruppen.

Und es könnte sein, dass nicht nur so ein High-Tech-Prozessor sondern auch der „einfache“ elektrische Motor oder Stromgenerator heute ohne einer ähnlich komplexen „Maschinerie“ so ganz einfach nicht mehr hergestellt werden können. Und wenn die zerbricht – warum auch immer – was dann?

Damit habe ich den Kreis geschlossen und komme zur Eröffnung meines Artikels. Genau wegen der Durchdringung solcher Werkzeug- und Produktionsketten in allen Technologien und Sparten – ob Chemie, Energie, Landwirtschaft, Mechanik, Pharmazie, Physik … könnte ich mir gut vorstellen, dass unser System kippen kann und wir dann wieder bei NULL anfangen müssen. Und das das dann sehr schwierig sein könnte.

RMD

P.S.
Ich schreibe die technischen Erinnerungen aus dem Kopf heraus und völlig ohne Unterlagen auf. Leider ist Wikipedia bei solchen spannenden Themen der Informatik gar nicht so recht hilfreich. Ich finde es schade, dass in Wikipedia ausgerechnet die Technik, die Wikipedia erst ermöglicht hat, kaum und meistens sehr ungenügend  beschrieben ist.

Insofern bitte ich zu entschuldigen, wenn ich die eine oder andere Abkürzung falsch in Erinnerung habe oder ähnliche Fehler mache. Ich konnte nirgends nachschauen und so meinen Erinnerungen auf die Sprünge helfen. Umso mehr bin ich für Korrekturen und Hinweise zur von mir berichteten Technik dankbar.