Die stetig wachsende Dezentralisierung von Rechnerkapazität einerseits und der Einsatz heterogener Rechnersysteme andererseits führt mehr und mehr zu der Forderung nach freizügiger Kommunikation zwischen den verschiedensten Systemen.

Die Realisierung dieses Wunsches nach "Offenen Rechnernetzen" jedoch wird immer noch durch die inkompatiblen Schnittstellen von Dialog- und Batch-Terminals der verschiedenen Hersteller erschwert. Die Standardisierung von Kommunikationsprotokollen und Schnittstellen wird kurzfristig keine Lösung bringen. Eine Mehrzahl unterschiedlicher Terminal-Hardware an einem Arbeitsort für den Zugriff auf die verschiedensten Zielanlagen ist die logische Konsequenz. Eleganter und kostengünstiger laßt sich dieses Problem durch Emulation der jeweiligen herstellerspezifischen Endgerätetypen, also durch softwaremäßige Nachbildung ihrer Charakteristiken auf einem frei programmierbaren Kleinsystem losen. Die "Danet Beratung und Softwareentwicklung Deutsche Datel-Gesellschaft für Datenfernverarbeitung m.b.H." - kurz Danet - hat in der Vergangenheit eine Vielzahl solcher Emulatoren für verschiedene Hersteller entwickelt. Die in diesen Projekten gewonnenen Erfahrungen, sowohl generell auf dem Gebiet Rechnernetz-Architektur als auch speziell bezüglich Emulationssoftware, haben zwangsläufig zu einem generalisierten Emulationskonzept - dem "Hyperemulator" - geführt. Er soll im folgenden dargestellt werden.

Im Zuge der raschen Entwicklung der Computer- als auch der Telekommunikationstechnik haben sich eine Reihe herstellerspezifischer Rechnernetzarchitekturen (SNA, Transdata, CNA, Decnet etc.) und -Komponenten entwickelt, die mit der Weiterentwicklung und Vermarktung zunehmend Inkompatibilitäten aufweisen. Dabei sind sowohl horizontale Inkompatibilitäten, das heißt innerhalb vergleichbarer Funktionsebenen, als auch vertikale Strukturunterschiede zwischen verschiedenen Kommunikationsdiensten und -Schnittstellen festzustellen.

Heutige Rechnernetzmodelle werden durch die Ebenendarstellung beschrieben, in der die Funktionsebenen innerhalb eines Kommunikationssystems in horizontalen Ebenen aufgetrennt werden.

Abbildung 1 zeigt eine vergleichende Darstellung verschiedener herstellerspezifischer Rechnernetz-Architekturen, wobei das 7-Schichtenmodell von ISO zugrunde gelegt ist.

Bei der Realisierung von Rechnernetzkomponenten treten wiederkehrend die gleichen Probleme auf. Bestimmte Softwarepakete sind infolge von Marktforderungen zu verschiedenen Zeitpunkten kurzfristig auf unterschiedlichen Anlagen zu realisieren. Dabei ist in den meisten Fällen eine Übertragung der Software nur mit großem Aufwand möglich, da die Implementation aus Zeitgründen meist kompakt und systemspezifisch erfolgte. Speicher- und Durchsatzbegrenzungen erschweren zusätzlich die Übertragung auf insbesondere kleinere Terminalsysteme.

Diese Umstände verstärken den Trend zu steigenden Software-Kosten. Insellösungen mit ihrer meist monolithischen Struktur haben letzten Endes den Zwang zur Neucodierung des gleichen Problems in einer neuen Umgebung zur Folge. Die aufgrund dieser Tatsache schnell wachsenden Softwarekosten führen zwangsläufig zu der Forderung nach einem generellen Konzept für Datenfernverarbeitungssoftware, das die Mehrfachnutzung einmal entwickelter Problemlösungen erlaubt.

Die Erarbeitung des Implementations-Konzeptes muß zur Absicherung gegen vorschnelles Veralten einige wichtige Randbedingungen berücksichtigen, die im folgenden kurz skizziert werden.

Analyse des Bedarfs

Vor dem Entwurf der generellen Software-Struktur ist für das gesamte Zielsystemspektrum eine Erhebung bezüglich der voraussichtlich benötigten Funktionsebenen eines Rechnernetzes durchzuführen. Dabei sind die verschiedenen Funktionsebenen gemäß Abbildung 1 zu berücksichtigen.

Datenübertragungsprozeduren

Auf der Ebene "Data Link Control" spielen Installationsbasis und vermutliche Lebensdauer bestehender Datenübertragungsprozeduren (IBM/ BSC, Siemens/MSV) und der noch zu erwartende Marktanteil ebenso eine Rolle wie die marktbezogene Akzeptanz bitorientierter Prozeduren wie HDLC und SDLC. Die Ebene "Data Link Control" ist wegen ihrer starken Hardwarenähe besonders sorgfältig zu analysieren.

Gerätefunktionen

Ein charakteristisches Leistungsmerkmal marktgängiger Terminals und Bürocomputer ist die Emulation von Endgeräten weitverbreiteter Großrechner wie IBM 3270 oder Siemens Transdata 160. Die Einbettung dieser Teilsysteme in ein Gesamtkonzept leidet in der Realität meistens an der monolithischen und rein gerätebezogenen Lösung des gegebenen Problems. Ein übergreifendes Konzept jedoch kann diese Schwache vermeiden.

Funktionalität

Das Aufgabenspektrum einer Geräteemulation ist ausschließlich von der gesetzten Problematik her in möglichst klar voneinander trennbare Funktionen (zum Beispiel OPEN, CLOSE, RECEIVE, SEND) zu unterteilen.

Portabilität

Schnittstellen und Struktur sind maschinenunabhängig zu gestalten. Das gilt auch für die Programmiersprachen (beispielsweise Pascal) und Dokumentation, soweit dies möglich ist.

Modularität

Entsprechend der Funktionalität sind Programmodule mit möglichst allgemeinen Schnittstellen zu definieren .

Anwendungstransparenz

Allgemein benötigte Funktionen/ Moduln dürfen keine anwendungsspezifischen Elemente enthalten; solche sind als "Extrafunktionen/-moduln" hinzuzufügen.

Automatisierungsgrad

Die Software sollte sich über vorher zu setzende Parameter weitgehend eigenständig organisieren. Dies gilt sowohl für die Zusammenstellung benötigter Moduln bei der Generierung als auch für die Anpassung an bestimmte Umgebungsbedingungen (Codes Fehlersicherung) zur Laufzeit.

Entwicklungsaufwand

Der Aufwand für das Gesamtsystem ist zuminimieren. Dies ist vor allem durch Einmal-Codierung und Mehrfach-Benutzung der einzelnen Software-Komponenten zu erreichen, indem ein "Hyper-Emulator" entwickelt wird.

In Tabelle 1 ist beispielhaft der Aufwand durchgeführter Projekte für je eine 3270- und eine 8160-Emulation aus zwei verschiedenen Rechnern nach der "Insel"-Methode zusammengestellt. Den Aufwand für eine Hyperemulator-Methode zeigt Tabelle 2. Anhand dieses Beispiels ist deutlich die Kosteneinsparung beim Hyperemulator zu erkennen. Mit Hilfe der Hyperemulator-Lösung lassen sich die Entwicklungskosten um 50 Prozent senken. Das Beispiel läßt sich auf alle Komponenten der Netzebenen-Software ausdehnen (HDLC/ SDLC, SNA/Transdata).

Konsequenzen

Ausgehend von den geschilderten Entwurfsvoraussetzungen und Kostenvorteilen lassen sich einige Forderungen an die Entwicklung eines Hyperemulators stellen.

Festlegung von Hard- und Softwareanteil

Bei Entwurf eines neuen Produktes ist die Verteilung der Funktionen auf Hardware und Software entscheidend. Die Entwicklung sollte von der Software her erfolgen: Erst aufgrund der Software-Anforderungen und möglichst nach entsprechenden Simulationen ist der Hardware-Entwurf vorzunehmen ("Software-First-Design").

- Die Hardware ist so zu konzipieren, daß sie spätere aufwendige Realisierung bestimmter Funktionen in Software (zum Beispiel CRC-Generierung) unnötig macht (Hardware-Überdimensionierung).

Definition allgemeiner Schnittstellen

Für die gesamte Software des Hyperemulators sind möglichst transparente Schnittstellen vorzusehen:

- Externe Schnittstellen für die Ansprache durch Applikationen oder Zugriff auf Geräte. Die Berücksichtigung spezieller Hardwareeigenschaften kann dabei in speziellen "Interface"- Moduln erfolgen.

- Interne Schnittstellen für die Kommunikation zwischen den Softwarekomponenten. Zwecks freizügiger Kombinierbarkeit dieser Moduln sind diese Schnittstellen ebenfalls frei von Anwendungseigenschaften zu gestalten.

Zerlegung komplexer Prozesse

Die Struktur des Hyperemulators erfolgt mit Hilfe des ISO-Schichtenmodells. Bei der Anpassung umfassender Prozesse in eine gegebenenfalls zerlegt werden. Abbildung 2 zeigt dieses Vorgehen am Beispiel eines 3270-Emulators. Die Emulator-Struktur wird auf die Ebenen gemäß ISO-Schichtenmodell zurückgeführt, das heißt

- LINE CONTROL - BSC-KERN (SEND/RECEIVE)

- NETWORK - POLL/SELECT

- TRANSPORT - STATUS/SENSE

- SESSION - KOMMANDS

- PRESENTATION - ORDERS

- APPLICATION - zum Beispiel LOG-ON-Prozedur.

Dabei ist gegebenenfalls zusätzliche Software ("Interface"-Moduln) zur Anpassung an die Standardschnittstellen erforderlich.

Nicht vertretene Ebenen werden durch eine Art Software-"Gateway" dargestellt.

Die Schwierigkeiten bei der Zerlegung besteht in der eindeutigen Zuordnung von Elementen eines gegebenen Protokollsystems zu den einzelnen Ebenen des ISO-Modells. Historisch gewachsene Prozeduren wie BSC vermischen Funktionen mehrerer Ebenen in einer Weise, die eine spätere Entkopplung implementationstechnisch außerordentlich erschwert. Wegen der voraussichtlichen Langlebigkeit dieser historischen Protokollsysteme erscheint jedoch der Aufwand als gerechtfertigt.

Mehrfach benutzbare Software bedarf besonders einer systematischen Erstellungsphase, um spätere Portabilitätsprobleme zu vermeiden. Eine systemunabhängige Darstellung mittels Zustandsdiagrammen, HlPO-Technik und "Pseudo Procedural Languages" (Pascal) ist dabei Grundvoraussetzung. Die Übersetzung in den jeweiligen Zielcode (Assembler) darf dem Codierer zwecks Fehlereinschränkung nur noch minimalen Freiraum belassen.

Weiterhin sind umfangreiche Testverfahren zum Austesten einzelner Moduln und des Gesamtsystems im Offline-Betrieb erforderlich.

Der wachsende Rationalisierungsdruck und die schnell steigende Installationszahl von Rechensystemen führt mehr und mehr zur Forderung nach Verbundsystemen. Die Normung kann diesem Zeitdruck jedoch nicht gerecht werden. Die Emulation von Endgeräten wird daher in Zukunft zunehmend an Bedeutung gewinnen. Der damit verbundene Aufwand ist nur durch eine langfristige Planung und die Entwicklung entsprechender Softwarekonzepte in vertretbaren Grenzen zu halten. Die Hersteller sollten daher kurzfristige Marktanforderungen gegen die Vorteile einer langfristigen Konzeption abwägen.

Frank Raudszus

Jahrgang 1943, Dipl.-Ing. der Nachrichtentechnik (TH-Darmstadt). Entwicklung Systemsoftware für Kommunikationsrechner und Rechnernetze bei der GMD/Darmstadt. Projektleiter für die Netzanschlußtechnik im GMD-Rechnerverbundnetz. 1977/78 tätig als Systemberater bei Control Data, Frankfurt mit Schwerpunkten: Rechnernetzprojektierung mit Cyber 170/NOS; Entwurfsarbeiten am Cyber-Netzkonzept (NAM). Seit 1978 Berater bei Danet für Systemsoftware und Marktforschung im MDT-Bereich. Heute verantwortlich für die Leitung des Arbeitsgebietes "Kleinrechner-Software" in der Danet-Geschäftsstelle Darmstadt.