Polyprozessorsystem kontra Von-Neumann- und LAN-Konzept:

Verteilte Kontrolle mit enger Kopplung

13.07.1984

HAMBURG - Herkömmliche Rechnerarchitekturen (von Neumann) erfüllen die Forderungen, die heute an Systeme in Industrie und Verwaltung gestellt werden, nur noch unzureichend. Diese Konzepte gehen weitgehend auf die heute nicht mehr gültige Tatsache zurück, "teure" Hardware durch "billige" Software möglichst optimal auszunutzen. Dies führte zu nicht mehr überschaubarer Komplexität der Betriebssysteme, zu Fehlerintoleranz und gewaltigem Systemoverhead auf Kosten der Anwendungskapazität. Auch lassen sich diese Architekturen nicht flexibel an neue Softwarestandards und Kommunikationstechniken anpassen, was immer wieder zu Rucksacklösungen und balkonartigen Erweiterungen führt. Die Stollmann GmbH, Hamburg, entwickelte das Konzept "Mose", das sie im folgenden beschreibt.

Die wichtigsten Forderungen, die neue Systemarchitekturen zu erfüllen haben, lassen sich so beschreiben:

- hohe Verarbeitungsleistung bei geringen Kosten

- stufenlose Erweiterbarkeit bei unveränderter Software

- Fehlertoleranz und hohe Systemverfügbarkeit

- permanente Migration/Integration verschiedener vorhandener und neuer Software-Systeme und Hardware-Elemente

- Vereinfachung der Systemsoftware

- Flexibilität im Einsatz in Netzen verschiedener Ausprägung und Integration von Daten- und Textverarbeitung.

Das Mose-System, das diese Anforderungen erfüllen soll, basiert auf dem Konzept eines Polyprozessorsystems mit verteilter Kontrolle und enger Kopplung.

Mehrere Verarbeitungseinheiten (Modulen) - wobei jedes Modul im Prinzip einen eigenständigen Rechner darstellt mit CPU, Speicher, Bus und eigenen Peripheriegeräten - kommunizieren und kooperieren über ein einheitliches Protokoll, um gemeinsam die Gesamtfunktionen des Systems zu erbringen. Die Kontrolle des Gesamtsystems ist somit verteilt auf die Modulen und nicht zentral (zum Beispiel zentraler System-Supervisor) vorhanden.

Um jedoch auch herkömmliche Strukturen abbilden zu können, gibt es zum Unterschied von LAN-Konzepten einen gemeinsamen Hauptspeicher (global memory), auf den alle Moduln zugreifen können (enge Kopplung).

Durch das Prinzip des "Poly- und Parallel Processing" kann das System bei unveränderter Softwarestruktur sowohl qualitativ (performance) als auch quantitativ (Anzahl Benutzer) fast beliebig erweitert werden.

Während bei konventionellen "Multitasking -System mit zentralem Prozessor der Verwaltungsaufwand für häufige Taskwechsel mit der Anzahl der Benutzer überproportional ansteigt und somit immer weniger Leistung für die eigentliche Verarbeitung übrigbleibt, wird in dem hier beschriebenen System die Verarbeitung und Verwaltung auf mehrere, parallel autonom arbeitende, kooperative Verarbeitungsmodulen "verteilt".

Dadurch wird diese Rechnerarchitektur auch fehlertolerant: Der Ausfall eines Verarbeitungsmoduls führt nicht zum Ausfall des Gesamtsystems. Die Fähigkeit zur selbständigen Rekonfiguration eliminiert die defekten Moduln und verteilt die Aufgaben entsprechend neu. Die auf die Modulen verteilten Betriebssystemfunktionen sind in PROM-Bereichen festgelegt (micro code on a chip), somit gegen ungewollte Veränderungen (Systemfehler, Veränderungen von außen, Fehler beim Laden) geschützt und belegen keine Hauptspeicherbereiche.

Das geht nicht mehr von teuren, daher begrenzten Hardware-Betriebsmitteln aus (eine CPU für alle Systemfunktionen) und einer immer komplexer werdenden Software (virtuelle Betriebssysteme, Multiprogramming, Multitasking), um diese Begrenzung auszugleichen, sondern von mehrfach vorhandenen autonomen Verarbeitungseinheiten, die sich dem standardisierten Kommunikationsprotokoll streng anpassen müssen. Dies führt zu einer Modularisierung der verteilten Betriebssystemfunktionen, der Hardware-unabhängigen Standardisierung aller Systemfunktionen, zu präzise definierbaren und testbaren Schnittstellen.

Auf Basis des standardisierten Kommunikationsprotokolls und der in den Verarbeitungseinheiten festgelegten Systemfunktionen können in verschiedenen Modulen gleichzeitig verschiedene Betriebssysteme beziehungsweise Instruktionssätze abgearbeitet werden. Protokolle und Modulfunktionen bilden zusammen mit einer geräteunabhängigen, logischen Ein-/Ausgabesteuerung und Dateiverarbeitung ein Betriebssystem für Betriebssysteme. Damit können in einem Mose-System verschiedene "Anwenderwelten" wie IBM /370-Assemblerprogramme, CP/M-Basic-Programme, Cobol-Laufzeitsysteme oder Unix über eine gemeinsame Dateibasis abgebildet werden.