Mikroprozessor-Technologie vereint mit Software-Know-how ist ein Mädchen für alles: Kommunikationsprozessor, Konzentrator Multiplexer, Protokoll-Konverter und Messagesystem zugleich. Diagnose und Statistikauswertungen inbegriffen. Für eine ganze Anzahl von Computeranwendungen - vom Mikro bis zu Jumbos - ist das eine wirtschaftliche Lösung, Datex-P-fähig zu werden.

Es scheint, als wenn die CCITT-Empfehlung X.25, also der Vorschlag, Daten als einheitliche Pakete verpackt mit Absender- und Empfängerangaben an festgelegten Paketstellen über die Leitung zu schicken, weltweit gefruchtet hat. Namen wie Tymnet, Telenet, Uninet, Datapac, RPDT, IPSS, Transpac, CTNE, Euronet, DN-1 und natürlich Datex-P im eigenen Land: Alles Bezeichnungen für Paketnetze unter Ausnutzung dieser Technologie lassen erkennen, daß die X.25-Empfehlung den Turmbau zu Babel, also die Vielsprachigkeit auf dem Protokollsektor, gestoppt oder zumindest verlangsamt hat.

Wer nicht Datex-P-fähig ist, kann es werden. Aber wie?

Viele Wege führen ins Paketvermittlungsnetz. Eine große Anzahl der Computerhersteller weiß bereits, wie man X.25-Pakete schnürt. Eine kleinere Anzahl kann es sogar schon in der Praxis. Darüber hinaus beteiligt sich die Deutsche Bundespost gebührenpflichtig mit dem PAD-Dienst (Package Assembly Disassembly) an der Aufgabe, Datenendgeräte Datex-P-fähig zu machen und außerdem den Zugang aus anderen Übertragungsnetzen ins Datex-P zu ermöglichen. Das allerdings mit gewissen Einschränkungen:

In manchen Fällen kann nur auf einer Seite der Datenübertragung die PAD-Funktion genutzt werden, die andere muß Datex-P können. Einschränkungen gibt es bei der PAD-Nutzung auch bei der Geschwindigkeit sowie bei dem Versuch, mehrere asynchrone zeichenorientierte Geräte, auch Start-Stop-Betrieb genannt, kostengünstig ins Netz zu adaptieren. Genau an dieser Stelle offeriert die oben angekündigte Kommunikationsprozessor-Technologie glänzende Aussichten.

Die Notwendigkeit, vorhandene, meist gemietete öffentliche Leistungskapazitäten weitgehendst auszunutzen, führte zur Entwicklung synchroner Übertragungsverfahren, bei denen beide Übertragungsenden während der Übertragung ständig synchronisiert sind. Im Klartext: Jeder weiß genau, wann welches Bit ansteht. Synchronisiert wird nur noch von Zeit zu Zeit (zum Beispiel Blockfang).

Asynchrone Geräte, oftmals auch "dumm" geschimpft, rahmen jedes Byte, also jedes Zeichen, zur Synchronisierung mit Start- und Stopbits ein. Bei acht Datenbits, einem Start- und zwei Stopbits zum Beispiel also mehr als 30 Prozent Ballast auf dem Weg zur optimalen Leitungsausnutzung. Ein weiterer Grund für den Siegeszug synchroner Verfahren war sicher die Möglichkeit der Übertragungssicherung. Während synchrone Übertragung ganze Blöcke mit mathematisch ermittelten Block-Check-Charaktern absichert, beim Empfänger überprüft und im Fehlerfalle diesen Block erneut überträgt, gewährleisten asynchrone Verfahren im Normalfall nur die Richtigkeit der übertragenen Zeichen durch Hinzufügen eines Paritätsbits. Ganze Zeichen oder Zeichenfolgen könnten also unbemerkt verschwinden. Kein guter Gedanke.

Wo also "dumme" asynchrone Netzkomponenten und wo teurere "intelligente" synchrone? Die Antwort gibt der gesunde technische Menschenverstand. Auf der lokalen Seite, also dort, wo zu jedem Gerät (zum Beispiel Bildschirmterminal) eine im doppelten Sinne eigene Leitung führt, spielt die Auslastung keine große Rolle. Start- und Stopbits stören dort kaum. Außerdem befindet sich auf diesem direkten Weg keine allzu komplexe Technologie in Form von Modulatoren/Demodulatoren (Modems), Knoten, Vermittlungsrechnern etc., der Übertragungsinhalte zum Opfer fallen können. Der Grund also, warum solche lokalen asynchronen Datenübertragungssysteme seit vielen Jahren zuverlässig arbeiten. Diese Erkenntnis weitergedacht und praktisch angewandt nahm nachstehende Entwicklung:

Protokoll-Konverter, Multiplexer, X.25- Kommunikationsprozessor

Die erste und zweite Stufe dieser Entwicklung arbeitet seit Jahren zufriedenstellend. Protokoll-Konverter wandeln einen asynchronen Port in ein synchrones Protokoll (BSC, SDLC, HDLC, X.25). Da ein schneller Prozessor sich mit einem Port langweilt, bekam er gleich mehrere asynchrone Ports an den Eingang und war ab sofort Protokoll-Konverter-Multiplexer. Meist verwenden diese Geräte auf der synchronen, also der Übertragungsseite schon eine Art X.25-Protokoll und verpacken damit die Nachrichten der asynchronen Seite zu Paketdaten. Am anderen Ende der DÜ-Leitung wird alles schön wieder ausgepackt und der Inhalt der Pakete an die richtigen Abnehmer weitergereicht. Warum, das war die nächste Überlegung, der technischen Entwickler, nicht gleich ein astreines X.25-Protokoll auf der Übertragungsseite "installieren" (zum Beispiel um das Paketnetz national oder international als Transportweg zu verwenden)?

Bis zu 64 asynchrone Datenendgeräte, wie zum Beispiel Bildschirmterminals, Drucker oder manch anderes, vereinigt ein Kommunikationsprozessor zu einem X.25-Datenstrom. Die Kosteneinsparung gegenüber synchronen Geräten ist erheblich. In puncto Ergonomie, also Anpassung an den Menschen, scheuen asynchrone Produkte keinen Vergleich mit ihren teureren synchronen Artgenossen. Umfangreiche Praxistests zeigen, daß alle vom Prozessor zu bewältigenden Aufgaben zur vollsten Zufriedenheit erledigt werden. Das alles kann er als lokale oder remote Steuereinheit abwickeln:

- Volle CCITT-X.25-Funktion inklusive der Stufen eins, zwei, drei und X.25-X.3 und X.29-Unterstützung

- Automatischer Verbindungsauf- und -abbau in Paketnetzen

- Selbsttätige Geschwindigkeitsanpassung und Flußsteuerung auf der asynchronen Seite (bis zu 64 Eingängen)

- Unproblematische Anpassung an asynchrone Terminals oder sonstige Einheiten mittels Software

- Datenkompression und -dekompression zur Kostenersparnis (Volumengebühr im Datex-P-Netz)

Statistische Funktionen, Eigendiagnose und Messagesystem inbegriffen

Sozusagen als Extraleistung übernehmen Spitzenentwicklungen auf diesem Gebiet zusätzliche für den Anwender wertvolle Aufgaben. Statistische Auswertungen können von jeder Stelle des Netzwerkes abgerufen oder in variablen Zeitabständen ausgegeben werden (Drucker oder Datenaufzeichnung). Loop-Back-Tests ermöglichen den Test aller angeschlossenen Netzwerkkomponenten, auch auf Distanz. Den krönenden Abschluß bilden Port-Contention-Möglichkeiten. Mit deren Hilfe können Nachrichten von jedem angeschlossenen Endgerät innerhalb des Netzwerkes zu jedem anderen Endgerät gelangen, auch an der lokalen Seite, also ohne Einschaltung eines Host-Rechners. Auf Wunsch also eine Art LAN (Local Area Network) als willkommener Nebeneffekt.

Die Hersteller und Vertreiber asynchroner Komponenten werden diese Entwicklung sicher begrüßen. Und dem Anwender selbst hilft es schließlich, Kosten zu sparen. Abzuwarten bleibt die Reaktion derer, die lieber ihre synchrone Peripherie einschließlich Kommunikationsrechner an den Mann bringen.

Paul Hofmann, Wetronic-Automation München.