Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

24.08.1984 - 

IBM PC und kompatible Mikros als Endgerät, Arbeitsplatzsystem, Externer Rechner, Gateway, Netzsimulator:

Fünf Einsatzformen des Mikros in Bildschirmtext-Anwendungen

Die ursprüngliche Diskussion des Btx-Dienstes war geprägt von der Vorstellung seiner Nutzung durch den Heimfernseher. Mittlerweile ist klar, daß der Btx-Dienst seine Nützlichkeit erst voll entfalten kann, wenn er mittels eines hinreichend leistungsstarken lokalen Rechners genutzt wird. Diese den Btx-Dienst integrierende lokale Intelligenz kann heute durch Mikros in kostengünstiger Weise zur Verfügung gestellt werden - es ist absehbar, daß sie allgegenwärtige Nutzer des Btx-Dienstes werden. Daher stellt sich die Frage nach den unterschiedlichen Formen dieser Integration von Mikrocomputer und Btx-Dienst. Der Artikel behandelt diese Frage, indem er einige wichtige Szenarien erläutert und ihre Problematik beziehungsweise praktische Nutzung darlegt. Ausgegangen wird dabei von der bei weitem wichtigsten Klasse von Mikros, nämlich der Klasse der "IBM-PC-Kompatiblen". Analoge Aussagen gelten natürlich für die anderen Mikros vergleichbarer Leistungsfähigkeit.

Die Strukturen "Mikro-basierter Btx-Applikationssysteme", sehen recht einheitlich aus, so daß die Implementierung solcher Btx-Applikationen durch gezielt entwickelte Hilfsmittel erheblich vereinfacht werden kann.

Um Mißverständnisse zu vermeiden, sei aber klargestellt, daß wir in diesem Artikel den Mikro in einer Ausstattung betrachten wollen, wie sie für Arbeitsplatzsysteme in den nächsten Jahren wohl üblich sein wird, (1-3). In aller Kürze heißt das, daß er über einen 16-Bit-Prozessor verfügt, sein Arbeitsspeicher mindestens 256 KBytes groß ist und er einen schnellen Hintergrundspeicher (zum Beispiel Winchester-Platte) von mindestens 10 MBytes hat. Die Hardwarekosten eines solchen Systems werden kurzfristig auf etwa 10 000 Mark sinken, die (durch seinen Btx-Einsatz bedingten) Softwarekosten werden - je nach Softwareausstattung - zwischen 1000 und 20 000 Mark variieren. Dieser Kostenrahmen ist in (1-4) weiter aufgeschlüsselt. Die heute marktüblichen Hardwarekosten liegen etwa 30 bis 50 Prozent höher als in diesen Rahmenvorstellungen angegeben, die gegenwärtig häufig noch angestrebten Softwarekosten liegen sogar teilweise um den Faktor 10 bis 30 höher. Es ist aber zu erwarten, daß der in (4) vorgegebene Kostenrahmen allgemein verbindlich wird.

Nachfolgend werden die fünf wichtigsten Einsatzformen des Mikros in Btx-Applikationen diskutiert.

Einsatzform 1: Privates Endgerät

Die Anordnung der bei dieser Einsatzform des Mikros benötigten Geräte ist aus der nachfolgenden Skizze ersichtlich.

Das "rudimentäre Btx-System" ist eines der heute marktüblichen Btx-Geräte. Damit ist das Kostenproblem dieser Anordnung bereits klar: Sie erfordert mehrere tausend Mark für das rudimentäre Btx-System, die in dem beschriebenen Kostenrahmen nicht vorgesehen sind. Wir wollen die Vor- und Nachteile dieser Mikro-Einsatzform in darlegen.

Zunächst einmal erinnern wir uns daran, welche Protokolle auf den Leitungen links und rechts des rudimentären Btx-Systems im wesentlichen abgewickelt werden. Zwischen Btx-Netz und System benutzt man eine Telefonleitung für die Übertragung mit 1200/75 beziehungsweise 1200/1200 Bit pro Sekunde, sichert diese Übertragung aber gegen Bit-Fehler (durch CRC-Generierung und Vergleich, (5)) ab - daher der Kurzname Tel+ in der Skizze. Zwischen dem rudimentären Btx-System und den Mikro arbeitet man meistens mit der bekannten V.24 und verzichtet (da diese Leitung im allgemeinen ja sehr kurz ist) auf jede Fehlersicherung, gestattet dafür aber bei einigen Systemen eine wesentlich schnellere Übertragung (zum Beispiel bis 9,6 KBit/Sek.). Auf beiden Leitungen entsprechen die Informationen selbst (abgesehen von einigen zusätzlichen Steuerinformationen) dem Cept-alpha-Mosaik-Repertoire und sind auch so codiert (6).

Vorteil dieser Anordnung: Man vermeidet das Problem, für den Mikro als Btx-Endgerät beim FTZ eine Zulassung erwerben zu müssen. Er müßte nämlich erstens das oben genannte Leitungssicherungsprotokoll auf der Schnittstelle zum Btx-Netz realisieren können, er müßte zweitens über eine Farb-Karte mit 32 Farben und einen Farb-Monitor verfügen, die drittens über eine hinreichend hohe Auflösung verfügen, und mit denen viertens mehrere Formen des Blinkens ermöglicht werden. Mittels der üblichen Farb-Karten für Mikros kann man das Blinken nicht vernünftig realisieren, außerdem arbeiten sie meist nur mit 16 Farben. Geeignete preiswerte Karten sollen jedoch in Kürze verfügbar sein. Die weiteren Vorteile/Nachteile dieser Form des Mikro-Einsatzes kann man am besten diskutieren, wenn man zwei Fälle unterscheidet.

1. Fall:

Mikro ohne Cept-Dekoder

Dies ist die einfachste Form des Mikro-Einsatzes überhaupt. In diesem Fall benötigt man auf dem Rechner nur ein "PC-Integrations"-Programmpaket, wie es etwa in (4) umrissen ist. Der entscheidende Nachteil dieser Einsatzform besteht darin, daß man zur Bilderzeugung ganz auf den Cept-Dekoder des rudimentären Btx-Systems angewiesen ist, diese Systeme aber durchweg äußerst leistungsschwach sind. Professionelles Arbeiten beim Erstellen von Btx-Seiten kostet zuviel Zeit. Überdies ist man in diesem Fall weitestgehend auf den Bildeditor des rudimentären Btx-Systems angewiesen, der wiederum in keiner Weise dem Stand der Technik bei Editiersystemen entspricht. Besitzt man jedoch bereits ein solches Btx-System, so ist diese Form der Hinzunahme des Mikros mit den geringsten Softwarekosten verbunden.

2. Fall:

Mikro mit Cept-Dekoder

Auf dem Kleinrechner können damit sehr viel komfortablere und schnellere Seiten- beziehungsweise DRCS-Editore angesiedelt werden, als sie auf dem rudimentären Btx-System möglich sind (4). Dieser Vorteil kommt vor allem dann zum Tragen, wenn der Mikro auch noch über Farb-Karte und -Monitor verfügt, weil man dann arbeitsmäßig das langsame rudimentäre Btx-System ganz vermeiden kann (man benutzt es dann nur noch aus legalistischen Gründen, wenn man mit dem Postnetz direkt arbeitet). Dieser Vorteil führt aber auch dann noch zu einer größenordnungsmäßigen Verbesserung der Produktivität beim Erstellen von Btx-Seiten, wenn man diese Farbausstattung des Bildschirms nicht hat und zur Anzeige der Bildinformation deshalb das rudimentäre Btx-System benutzen muß.

Einsatzform 2:

Arbeitsplatzsystem

Gegenüber der vorherigen unterscheidet sich diese Einsatzform vor allem durch mehr Einfachheit: Das rudimentäre Btx-System ist weggelassen.

Der Vorteil besteht nicht nur in der Kostenersparnis für das rudimentäre Btx-System. Entscheidender Vorteil ist hier vielmehr in der Beseitigung der Umstände zu sehen, die die Einschaltung des rudimentären Btx-Systems in die Kommunikation zwischen Mikro-Arbeitsplatz und Btx-Netz unweigerlich bedeutet. Man kann nun auf dem Kleinkomputer große Datenbanken von Btx-Seiten anlegen und pflegen und sie bei Bedarf im "Bulkupdate"-Transfer über die Telefonleitung in die Btx-Datenbank der Post übertragen. Dieses lokale Aufbauen einer Btx-Seiten-Datenbank mit einem "Offline-DB-Editor", (4), geschieht sehr viel bequemer, sicherer und effizienter als dies mit dem "Online"-Editor der Post möglich ist. Während dieses lokale Arbeiten natürlich auch bei Einsatzform 1 möglich ist, erweist sich der Bulkupdate-Transfer durch ein rudimentäres Btx-System hindurch derzeit als Schwierigkeit.

Selbstverständlich braucht man auf dem Mikro nur hardwaremäßig Farb-Karte und -Monitor und softwaremäßig die Btx-Integrationskomponente und einen Cept-Decoder und einen Seiten-/DRCS-Editor. Außerdem muß der Mikro nun offensichtlich auch das Bitfehler-Sicherungsprotokoll auf der Anschlußleitung zum Btx-Netz realisieren können; dies ist mit den heute bei Mikros üblichen E/A-Schnittstellen lediglich ein Softwareproblem. Ob man den obengenannten lokalen Btx-Datenbank-Editor und die zugehörigen Möglichkeiten des Bulkupdate auf einem Mikro benötigt, hängt in erster Linie von der Größe des Btx-Seitenbestandes ab, der mit diesem Mikro bearbeitet werden soll: Bei 20 Seiten scheint er bereits höchst wünschenswert zu sein, bei 50 Seiten noch ohne ein solches Hilfsmittel zu arbeiten wäre unprofessionell.

Diese Einsatzform des Mikros ist nur mit einer geeigneten FTZ-Zulassung möglich. Die Post unterscheidet hier zwei unterschiedliche Zulassungsarten für einen Mikro: als Abrufgerät und als Bulkupdate-Gerät.

Software-Decoder

Die Zulassungsanforderungen an ein Abrufgerät und ihre Problematik haben wir bereits bei Einsatzform 1 erläutert. Die einzige Möglichkeit, diese Problematik zu lösen, besteht derzeit darin, die Mupid-Karte zu benutzen. In Kürze soll es jedoch eine ganze Reihe anderer Karten geben, die dieses Problem ebenfalls lösen - dabei ist für mindestens eine Karte geplant, sie unter 1000 Mark Einzelhandelspreis zu vertreiben. Hat man eine solche Btx-Farb-Karte in einem 16-Bit-Mikro, wie wir ihn hier zugrunde gelegt haben, so stellt sich natürlich die Frage nach der Realisierung des Cept-alpha-Geometrie-Modus in einem ganz anderen Licht: Ein entsprechender Dekoder ist dann softwaremäßig realisierbar. Ein leistungsstarker Alpha-Geometrie-Editor ist zwar sehr viel schwieriger zu realisieren als ein alpha-Mosaik-Editor, aber auch hierfür reicht die Leistungsfähigkeit eines Mikros noch aus. In (4) ist ein solcher Alpha-Geometrie-Editor skizziert, der dem heutigen Stand der Technik im Computer-Graphics-Bereich entspricht.

Rechtsproblematik

Damit ein Mikro als "Bulkupdate"-Endgerät zugelassen werden kann, muß er - außer dem Fehlersicherungsprotokoll - auch noch das Bulkupdate-Protokoll beherrschen; an die sogenannte RGB-Schnittstelle (= Rot/Grün/Blau-Schnittstelle, sie impliziert Farbfähigkeit, Auflösung, Blinken, wie oben beschrieben) werden hierbei keinerlei Anforderungen gestellt. Es ist also vorstellbar, daß es Bulkupdate-Mikros geben wird, deren RGB-Schnittstelle nicht zulassungsfähig ist. Ein Btx-Teilnehmer, der in erster Linie Informationsangebote erstellt und dazu einen Bulkupdate-Mikro benutzt, könnte einen solchen Rechner also auch zum gelegentlichen Btx-Seitenabruf benutzen - obwohl das Gerät dafür nicht zugelassen ist. Eine ähnliche Rechtsproblematik kennt man aus dem Straßenverkehr: Auch hier wird gelegentlich in geschlossenen Ortschaften mit Privatfahrzeugen schneller als 50 km/h gefahren - obwohl dies nicht erlaubt ist.

Einsatzform 3:

Externer Rechner

Wenn der Mikro als Externer Rechner eingesetzt wird, ergibt sich die Situation, die die nachfolgende Skizze zeigt.

Selbstverständlich muß der Mikro dann unter einem Multitasking-Betriebssystem laufen und X.25-fähig sein - dies sind zwei einschneidende Voraussetzungen. Erstere erfüllen zum Beispiel Unix-ähnliche Betriebssysteme (etwa QNX, (4)), letztere erfordert spezielle Hardware, derzeit zum Beispiel in Form der Teles X + T-Karte gegeben, (4). Darüber hinaus muß der Mikro noch das EHKP4, das EHKP6 und das Btx-Anwendungsprotokoll realisieren können. Die Realisierung aller Protokollschichten bedarf der Abnahme durch das FTZ. Alle diese Voraussetzungen sind mittlerweile erfüllt (4).

Die Möglichkeit des Einsatzes des Mikros als Externer Rechner verändert das Verständnis des Btx-Dienstes der Post auf grundlegende Weise: Die so bedingte wesentliche Kostensenkung für den Anschluß eines Externen Rechners (4) und die erhöhte Flexibilität beim Aufbau von Btx-Applikationen läßt Btx auch für Geschäftsbereiche, die ihm bisher skeptisch gegenüberstanden, zum geeigneten Hilfsmittel werden.

Betrachten wir noch kurz die Frage nach der Leistungsfähigkeit des Mikros als Externer Rechner. Erfahrungen mit der Teles X+T-Karte/-Software haben gezeigt, daß der Mikro den 9.6-Kbit/Sek.-Datex-P-Anschluß mit voller Geschwindigkeit bedienen kann. Extrapoliert man (davon ausgehend) auf die Belastung des Mikros durch die Realisierung der EHKP4/EHKP6 und des Btx-Anwendungsprotokolls, geht man von einfachen Btx-Datenbankzugriffen aus und nimmt man ein vernünftiges Verhalten der Informationsabrufer an, so kommt man zu der Schätzung, daß bei fünf bis zehn Abfragesitzungen gleichzeitig (das heißt, Sitzungen zwischen einem Mikro und fünf bis zehn Informationsabrufern) nennenswerte Wartezeiten in der Regel nicht auftreten. Jedenfalls dürfte die dadurch bedingte Protokollabwicklung (insbesondere für den Datentransfer auf der Datex-P-Leitung) den Prozessor des Mikros nicht auslasten - eine Gegebenheit, die für Großrechner in dieser Rolle keineswegs selbstverständlich ist. Einige Überlegungen, die diese Abschätzungen (des Aufwandes, der durch die Externe-Rechner-Protokolle oberhalb von Datex-P bedingt wird) begründen, findet man bei der nachfolgenden Beschreibung der Einsatzform 4.

Selbstverständlich dagegen ist, daß die begrenzte Leistungsfähigkeit der Organisation eines Mikros es nicht gestattet, nebenläufig zu dieser Protokollabwicklung auch noch CPU-Arbeitsspeicherplatz oder Hochvolumen-E/A-intensive Anwendungsprogramme auszuführen - für Anwendungen dieser Art braucht man leistungsstärkere Anlagen als Mikros. Die nächste Einsatzform stellt auf diese Gegebenheit ab.

Einsatzform 4:

Gateway zum ER

Die Verteilung der insgesamt zu erbringenden Funktionalitäten auf Mikros als Gateway beziehungsweise auf dem eigentlichen Externen Rechner ersieht man aus der nachfolgenden Skizze.

Zunächst einmal ist klar, daß der Mikro zum Btx-Netz hin sich genauso verhalten muß wie in Einsatzform 3, das heißt, er muß die X.25-Protokolle, EHKP4, EHKP6 und das Btx-Anwendungsprotokoll realisieren. Die Aussagen, die wir bei Einsatzform 3 bezüglich FTZ-Zulassung und bezüglich der Auslastung des Mikros (durch diese Protokollabwicklungen) gemacht haben, gelten also auch für den Einsatz als Gateway.

Nicht zwingend vorgeschrieben ist dagegen, welche Protokoll zwischen dem Gateway und dem eigentlichen Externen Rechner abgewickelt wird. Hier wollen wir davon ausgehen, daß eine Anwendung auf dem eigentlichen Externen Rechner vollständig implementiert ist und von seinen lokalen Terminals aus problemlos genutzt werden kann, und daß es deshalb der naheliegende und sehr vernünftige Wunsch ist, diese Anwendung von Btx-Terminals aus ebenfalls nutzen zu können - ohne dafür die Implementierung der Anwendung ändern zu müssen. Wenn diesem Wunsch entsprechen werden soll, muß sich der Mikro dem Externen Rechner gegenüber genauso wie ein oder mehrere seiner lokalen Terminals verhalten. Das heißt, der Mikro muß im wesentlichen das Btx-Anwendungsprotokoll (und seine Inhalte) auf das Protokoll eines lokalen Terminals (und seine Inhalte) abbilden und umgekehrt, (4). Diese Abbildung läßt sich in vielen Fallen so implementieren, daß ihre Realisierung die CPU des Mikro kaum belastet - auf jeden Fall ist dieser Aufwand, verglichen mit dem Aufwand für die Protokollabwicklung zum Btx-Netz hin - sehr klein und kann von vornherein gut abgeschätzt werden.

Geht man davon aus, daß ein Btx-Informationsabruf-Terminal seinen 1200-Bit/Sek.-Anschluß über eine Sitzungsdauer gemittelt - höchstens zu 50 Prozent ausnutzt, andererseits der Mikro-Gateway aber seinen 9.6-KBit/Sek.-Anschluß permanent mit Daten versorgen kann, so sieht man, daß ein solcher Mikro bis zu 16 Abrufer-Sitzungen gleichzeitig ohne ernsthafte Verzögerung bedienen kann.

Einsatzform 5:

Netzsimulator

Unabhängig davon, ob man einen Mikro in Einsatzform 3 oder 4 zur Realisierung eines Externen Rechner benutzt, ergibt sich das Problem, daß man das Dienstleistungsangebot des Externen Rechners - so wie es sich einem Btx-Informations-Abrufer darstellt - überprüfen möchte. Man kann diese Überprüfung natürlich immer vornehmen, indem man vom Btx-Abruf-Terminal über das Btx-Netz an den Externen Rechner geht. Diese Form des Testens der Dienstleistung des Externen Rechners hat aber mehrere Nachteile - unter anderem entstehen dabei Postgebühren. Man kann deshalb einen Mikro als Netzsimulator einsetzen, wie es die beiden nachfolgenden Skizzen (die erste/zweite für die Einsatzform 3 beziehungsweise 4) veranschaulichen.

FTZ-Zulassungsprobleme für den Mikro als Btx-Netzsimulator gibt es hier nicht: Es handelt sich ja um eine rein private Testmaßnahme, weil der Netzsimulator an keinem Postnetz angeschlossen ist.

Die Protokolle, die der Netzsimulator zum Externen Rechner (beziehungsweise seinem Gateway) hin realisieren muß, sind natürlich die gleichen wie die des Externen Rechners beziehungsweise seines Gateways (also wiederum die X.25-Protokolle, EHKP4, EHKP6 und das Btx-Anwendungsprotokoll), jedoch muß der Simulator nun die Netzseite dieser Protokolle übernehmen (4). Die Protokolle, die der Netzsimulator zum Btx-Abruf-Terminal hin realisieren muß, sind das Leitungssicherungsprotokoll und das Abrufer-Protokoll - wobei er wiederum die Netzseite übernehmen muß (4).

Die vorangehende Diskussion von fünf Einsatzformen von Mikros (IBM-PC-kompatibel) in Btx-Applikationen darf nicht als erschöpfend betrachtet werden. Die Häufigkeit dieser Einsatzformen scheint jedoch gegenüber allen bisher absehbaren anderen Formen dieses Einsatzes in Btx-Anwendungen ganz klar zu dominieren.

Auch sind diese fünf Einsatzformen keineswegs alternativ zueinander zu verstehen. Offensichtlich kann man mittels eines einzigen Mikros mehrere solcher Einsatzformen praktizieren - falls erforderlich auch gleichzeitig.

Ziel dieses Artikels war, darauf hinzuweisen, daß die Leistungsfähigkeit moderner Mikros die Btx-Technologie für wohl alle verteilten Anwendungen kommerziell attraktiv gemacht hat, und daß dies in der Hauptsache auf einige wenige und gut beherrschte Einsatzformen zurückzuführen ist.

Literatur

(1) S. Schindler: "Der PC als offener multifunktionaler Büroarbeitsplatz", Online '84, Februar '84, Berlin.

(2) S. Schindler: "Aufbau eines flexiblen Satz- und Kommunikationssystems unter besonderer Berücksichtigung kleiner Druckereien", Eröffnungsreferat der Imprinta '84, Februar '84, Düsseldorf.

(3) S. Schindler: "Entwicklungstendenzen der Büroautomation", GI-Tagung Datenverarbeitung in der Hochschulverwaltung, April '85, Kiel.

(4) TELES-SYS - Eine Übersicht, erhältlich über den Autor.

(5) Functional Specification for Btx-Terminals DBP, Dezember '83.

(6) The TCD 6. 1, CEPT, September '83.

*Telematic Services GmbH, Informationstechnologien, 1000 Berlin, Am Sandwerder 36, Telefon 0 30/8 03 66 15 oder 0 30/31 47 31 60