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.

19.04.1985

Neues Informationssystem für Transportwesen bringt mehrere Hardwarekonzepte unter einen Hut:LOG startet Probelauf bei Speditionen

GREVEN-Unmittelbar vor seiner Pilotphase steht das vom Bundesministerium für Technologie mitfinanzierte Informations und Komrmunikationssystem LOG für die Speditlonsbranche. Den Aussagen der ersten LOG-Anwender von der Internationalen Spedition Feige, Greven, zufolge ermöglicht die neue Anlage unter anderem einen flexiblen Anschluß an verschiedene Hardwaretypen.

Mit der steigenden Datenaustauschmenge wächst auch die wirtschaftliche Diskrepanz zwischen dem hohen technischen Niveau der internen EDV-Anwendungen und der vergleichsweise unrationellen Art, wie der Datenaustausch vorherrschend durchgeführt wird. Bis auf Ausnahmen findet man folgende Situationen vor: Der Anwender A erzeugt auf seiner EDV-Anlage eine Nachricht, zum Beispiel einen Lieferschein. Diese Nachricht wird sodann auf Papier gedruckt und dem Partner B per Post zugestellt. Partner B muß diese Nachricht zur weiteren Verarbeitung auf seiner EDV neu erfassen, prüfen und so weiter.

Dieser Weg ist kostspielig, zeitraubend, fehlerbehaftet und vor allem unnötig. Seit Jahren sind technische Möglichkeiten für den Datenaustausch mittels der Datenfernübertragung (DFÜ) vorhanden. Sie fanden bis heute keinen wesentlichen Verbreitungsgrad, weil die DFÜ besondere Probleme technischer und organisatorischer Art aufwirft.

Eine stärkere Verbreitung erfuhr die DFÜ daher in der Regel nur unter besonderen Bedingungen, wie zum Beispiel:

Innerhalb eines Großunternehmens, das eine homogene Hardware benutzt und eine herstellerseits angebotene Kommunikationslösung einsetzen kann, die allerdings hardwaregebunden ist.

Im Rahmen von Punkt-zu-Punkt-Verbindungen großer Organisationen, die erforderlichen Ressourcen für die Überwindung der Probleme mit der Datenkommunikation heterogener Systeme haben.

Bei Großunternehmern, die Kraft ihrer Wirtschaftsmacht ihre Geschäftspartner zur Nutzung von Hardware des gleichen Typs anhalten, den Weg zu der schon angesprochenen hardwaregebundenen Lösung freimachen.

Unter dem letzten Fall haben gerade die Spediteure besonders zu leiden. Als vorwiegend kleine bis mittelständische Firmen, werden die Spediteure durch ihre Großkunden wirtschaftlich dominiert. In ihrem legitimen Wusch nach größerer Rationalisierung "empfehlen" die Großversender beziehungsweise -empfänger den Spediteure durch ihre Hardwaretyp zum Datenaustausch zu installieren. In kritischen Fällen passiert es zuweilen, daß der Spediteur dadurch in den Besitz mehrerer Typen von Kommunikationshardware kommt, sehr zum Nachteil seiner eigenen Wirtschaftlichkeit.

System muß offen sein

Zu einer der wichtigsten Anforderungen an ein brauchbares Datenfernübertragungskonzept gehört seine Offenheit. So muß es für möglichst viele Betriebe, unabhängig von der jeweiligen Firmengröße, der installierten Hardware und dem vorhandenen EDV-Wissen, zugänglich sein. Zum Zweiten sollte es sich um ein leistungsfähiges und preiswertes System handeln, das dem DFU-Bedarf eines Großunternehmens gerecht wird und zugleich in der Einstiegskonfiguration auch für das kleinste Unternehmen wirtschaftlich ist. Außerdem empfiehlt es sich, für einen minimalen Anschlußaufwand zu sorgen.

Die vorliegende Lösung nun konzentriert sich vorläufig auf den Datenaustausch per Filetransfer. Sie kann - wie weiter unten gezeigt wird - auch zu einem echten Dialog ausgebaut werden, falls es erforderlich werden sollte.

Zum besseren Verständnis der Konzeption ist es sinnvoll, zunächst die gängigsten Ansätze der DFÜ zu prüfen. Folgende Basisumgebungen sind dabei typisch:

1. Datenaustausch innerhalb homogener Hardware.

2. Datenaustausch innerhalb heterogener Hardware auf der Host-Ebene.

3. Datenaustausch innerhalb heterogener Hardware mit einem Kommunikationsverrechner .

Punkt eins ist auf folgendem Hintergrund zu sehen: Große Hardwarehersteller bieten Kommunikationskonzepte an, mit denen auch Datenaustausch durchgeführt werden kann. Als Beispiele gelten SNA von IBM und Transdata von Siemens. Funktionell decken diese Konzepte

den Umfang des ISO/OSI-Schichten-Modells ab, wenn auch insbesondere

bei SNA in einer anderen Struktur. Durch diese Konzepte wird der Datenaustausch mit hoher Leistung und guter Übertragungsqualität gewährleistet. Eine allgemeine Kommunikation ist nicht gegeben, weil eine starke Abhängigkeit von der Hardware und Software besteht. Aus diesem Grunde fällt dieser Lösungsansatz für LOG aus.

Im Falle heterogener Hardware setzt eine leistungsfähige und abgesicherte Host-zu-Host-Kommunikation theoretisch voraus, daß sich alle Hardwarehersteller auf ein DFÜ-Konzept einigen. Als Grundlage eines solchen Konzeptes könnte das ISO/OSI-Modell dienen. Die Wirklichkeit ist von diesem Ideal weit entfernt und kurzfristig wohl nicht realisierbar.

In der Praxis läuft daher die Datenkommunikation in heterogener Hardwareumgebung auf Insellösungen hinaus, in denen der dominante Hardwareschwerpunkt den übrigen Kommunikationspartnern sein Konzept vorschreibt.

Aus Kostengründen beschränkt sich die Anpassung der Partner auf das Notwendigste. Gewöhnlich werden die untersten Protokollebenen des dominierenden Hardwareherstellers (Leitungs- und Sicherungsschicht) emuliert und mit einem sehr einfachen Protokoll zum Filetransfer auf der Transport-, Sitzungs- und Anwendungsebene ergänzt. Die Folge dieser "Sparverbindung" ist eine niedrige DFÜ-Qualität oder eine niedrige DFÜ-Leistung. Ein recht verbreiteter Repräsentant dieser Richtung ist das BSC-Protokoll für 3780 RJE (IBM) und seine Emulationen bei den übrigen Herstellern.

Für LOG würde der Einsatz dieser Lösung folgendes bedeuten:

- Konzentration auf ein relativ einfaches und dadurch unsicheres Protokoll (zum Beispiel BSC).

- Entwicklung der Verarbeitungssoftware und der Formatumsetzung für alle gängigen Hardwareanlagen sowie mehrfache Pflege dieser Software für diese heterogene Umgebung.

Gegen diese Lösung sprechen sowohl die zu erwartende niedrige Qualität der DFÜ als auch die hohe Investition, verbunden mit der Realisierung und der Wartung der Software.

Im Hinblick auf den Einsatz eines Kommunikationsvorrechners (FEP = Front-end-Processor ) ergeben sich folgende Prinzipien:

Dekomposition des gesamten Netzes in einen lokalen Teil und einen externen Teil.

Wirtschaftliche Realisierung des lokalen Filetransfers zwischen dem Host und dem FEP. Dafür bieten sich die BSC-Protokolle an.

Anschluß an ein externes Netz zur Durchführung des externen File-Transfers mit möglichst hoher DFÜ-Absicherung. Als Standardschnittstelle wird das Interface X.25 herangezogen.

Die generellen Vorteile dieser Lösung lassen sich wie folgt strukturieren:

Offenes externes System nach einer internationalen Norm (X.25) und mit abgesichertem Protokoll.

Flexibler Anschluß an viele Hardwaretypen nach gängigsten Protokollen und über Inhouse-Standleitung.

Reduzierung des DFÜ-Risikos auf das lokale Netz, das voll unter Kontrolle des Anwenders steht.

Das externe Protokoll und die gesamte Software ist auf dem FEP standesgemäß realisiert. Seine Implementierung beim Anwender beschränkt sich auf die Aufstellung der FEP-Hardware.

Die SW steht durch die BMFT-Förderung dem Anwender nahezu kostenlos zur Verfügung.

Konsequente Realisierung des 7-Schichten-Modells in allen Schichten, für die es internationale Normen gibt.

Einsatz von internationalen Syntax-Regeln (GTDI) sowie die Möglichkeit, mit einem universellen Formatumsetzer aller unter den Kommunikationspartnern abgestimmte Dokumentenformate zu verarbeiten.

Verwendung von Datex-P als dem zur Zeit einzigen offenen internationalen Datenübertragungsnetz (gegenwärtig in über 40 Industrieländern verfügbar).

Realisierung der gesamten Software unter UNIX und in C (maximale Portierbarkeit des gesamten Systems).

Pilotanwendung auf Fortune-System

Die Log-Lösung - "LOG" steht übrigens für logistische Optimierung von Gütertransportketten - lehnt sich streng an das 7-Schichten-Modell an. Ihre Realisierung läßt sich daher am besten nach der Struktur dieses Modells darstellen.

Die Entwicklungshardware und die Pilotausführung des FEP basiert auf der Fortune 32:16. Als FEP ist sie neben dem Hauptprozessor M68000 mit je einem Z80A-Prozessor zur Abwicklung der Protokolle für den lokalen und den externen Anschluß ausgerüstet. Die Datenübertragung ist mit bis zu 19 200 Bit pro Sekunde sowohl extern als auch lokal möglich. Für die externe Verbindung (X.25) sind allerdings nur 9600 Bit pro Sekunde nutzbar, weil die DBP den 19 200 Bit pro Sekunde-Dienst nicht anbietet.

Für den lokalen Anschluß stehen gegenwärtig BSC mit 3780 oder 3270 zur Verfügung.

Die Schichten eins und zwei werden auf dem Z80A realisiert, die oberen Schichten übernimmt simultan der Hauptprozessor. Die Ebenen sechs und sieben werden weiter unten in Verbindung mit der externen Kommunikation behandelt.

Der externe Anschluß zu Datex-P geht über die international gültige X.25-Schnittstelle nach der CCITT-Empfehlung. Sie wird in den ersten drei Schichten des ISO/OSI-Modells auf dem Z80A als ladbare Software realisiert. Die FTZ-Zulassungsnummer für den Betrieb in Datex-P ist seit 1983 vorhanden.

Bis zu 16 logische Kanäle können für die simultane virtuelle Verbindung mit mehreren DFÜ-Partnern je Datex-P-Hauptanschluß mit dem obengenannten FEP betrieben werden.

Logum setzt Formate um

Die Schichten vier und fünf des Modells sind nach dem Teletex-Transportprotokoll T70 (S70) und nach dem Teletex-Sitzungs- und Dokumentationsprotokoll T62 (S62) ausgeführt Beide sind ebenfalls von CCITT empfohlen. Für den Anwender ist es wichtig, daß die LOG-DFÜ nach der Übertragung jedes Dokuments (Lieferschein, Spedionsauftrag, Rechtung) prüft, ob die Übertragung erfolgreich war. Im negativen Fall werden Maßnahmen zur Behebung des Übertragungsfehlers ergriffen. Die bis zum Auftreten des DFÜ-Fehlers übertragenen Dokumente müssen nicht nochmals übertragen werden. Dadurch steigt die Sicherheit, Komfortabilität und Wirtschaftlichkeit der DFÜ gegenüber den gängigen File-Transfer-Lösungen wesentlich.

Das Kernstück der Schichten 6./7 von LOG ist ein universeller Formatumsetzer (Logum) der auf dem FEP realisiert und damit für jeden Anwender sofort einsetzbar ist. Der Formatumsetzer kann auf dem FEP jedem Kommunikationsprozeß vor- oder nachgeschaltet werden.

Logum ist durch folgende Leistungsmerkmale charakterisiert:

Umsetzung individueller feste Formate des Senders in andere feste Formate des Empfängers oder in GTDI-Formate nach der ISO-Empfehlung und umgekehrt.

Übertragung beliebiger Texte (Teletex-Funktion) .

Möglichkeit der transparenten Übertragung (zum Beispiel Source-Code).

Bis 50 Satzarten für Eingabe- und Ausgabedokumente.

Alphanumerische, numerische und gepackte Feldformate.

Komprimierung der Nachrichten auf relevante Inhalte.

Logum setzt die Daten während der DFÜ um, so daß sie auf dem FEP nur in einem Format (ohne Redundanz durch Zwischenspeicherung) gehalten werden. Logum kann wahlweise bei der Übertragung Host < - > FEP und/oder Anwender <-> Anwender wirksam werden. Die Daten (Dokumente) können ferner empfängerabhängig umformatiert werden.

Multiplex-Fahigkeit der LOG-Lösung

Der Sender zum Beispiel ein Automobilhersteller) will seine Lieferabrufe an die Lieferanten A, B und C senden.

Der Sender arbeitet mit individuellen Formaten C mit VDA-Format (VDA: Verband Deutscher Automobilhersteller) A arbeitet mit SEDAS-Format und B (zum Beispiel ein ausländischer Lieferant) mit GTDI (Guideline Transportation Data Interchange).

Der Sender überträgt die Lieferabrufe vom Host auf seinen FEP und schaltet zugleich beim Empfang auf dem FEP auf VDA-Format um. Während des Sendens wird der Lieferant identifiziert und die VDA-Formate

- zu C unverändert weitergeleitet,

- zu A in Sedas-Format umgesetzt,

- zu B in GTDI-Format umgesetzt.

Eine zweite Möglichkeit könnte folgendermaßen aussehen:

- Sender sendet alles im VDA-Format,

- A und B empfangen im VDA-Format und setzen bei sich in Sedas beziehungsweise GTDI-Format um.

Dabei ist es unerheblich, ob die Umsetzung beim Empfänger (Lieferant} während des Empfangens über Datex-P erfolgt oder während der Übertragung von deren FEP zum Host.

Gegenüber den üblichen File-Transfer-Programmen kann im Rahmen der LOG-Lösung jeder Teilnehmer mit beliebigen Formaten auf seinem Host arbeiten. Die einzige Bedingung ist die Abstimmung über die Inhalte und die Längen der Datenfelder.

- Die Lösung ist extrem preisgünstig. Die Host-Anlage benötigt einen minimalen Anpassungsaufwand und wird zusätzlich von dem Umsatzprogramm entlastet.

- Die Multiplex-Fähigkeit der LOG-Lösung (gegeben durch den gleichzeitigen Betrieb von mehreren virtuellen Wählverbindungen über einen Datex-P-Hauptanschluß) setzt die Anzahl der notwendigen Rufwiederholungen herunter. Außerdem wird der Benutzer von wiederholten Verbindungsanforderungen entlastet, durch die Zwischenspeicherung auf dem FEP der zu übertragenden Daten und die automatische zeitversetzte Rufwiederholung - solange bei dem gewünschten Empfänger (Senke) kein logischer Kanal frei ist.

- Das Übertragungsprotokoll im externen Teil des Netzes ist voll abgesichert. Im Unterbrechungsfall muß die DFÜ nicht komplett wiederholt werden, sondern wird auf dem letzten Konsistenzpunkt (hinter dem letzten erfolgreich übertragenen Dokument) automatisch wieder aufgesetzt.

- Die Pflege mehrerer Umsetzervarianten in Abhängigkeit von der Teilnehmerhardware entfällt, weil die Umsetzersoftware auf den untereinander kompatiblen FEP-s läuft.

Die Schicht 7 von LOG beinhaltet im Prinzip einen Kommunikationsmanager für Steuerungsvorgänge der DFÜ und vertikale Anwendungen, die für unterschiedliche Branchen und Aufgabenstellungen spezifisch sind (zum Beispiel die Transportabwicklung).

Hier soll lediglich auf die Funktion des Kommunikationsmanagers eingegangen werden. Im wesentlichen sind es:

die automatische oder manuelle Durchführung des Verbindungsaufbaus, der Überwachung und des Abbaus einer DFÜ-Verbindung. Dies gilt sowohl für den lokalen als auch für den externen File-Transfer,

Organisation der Freigabe der zu sendenden Daten,

Prüfung der Berechtigung für den Zugang der empfangenen Daten aus dem Netz,

Maßnahmen für Störfälle,

Protokollierung des DFÜ-Ablaufes.

Als organisatorisch wertvoll kann sich die Möglichkeit erweisen, daß der FEP direkt in der Fachabteilung installiert werden kann. Die zu sendenden Daten können durch die Fachabteilung (Versand und Einkauf ) vor dem Senden freigegeben werden, umgekehrt können die empfangenen Daten von der Fachabteilung vor der Weitergabe an den Host geprüft werden.

Durch die Trennung des FEP vom Host und die Berechtigungsprüfung in der Netz-DFÜ ist gewährleistet daß kein Zugriff auf die Host-Dateien von draußen erfolgen kann.

Dr. Frantisek Bumba, selbständiger Unternehmensberater aus Ratingen, ist technischer Leiter des LOG-Projektes.

Dr. frantisek Bumba, selbstständiger Unternehensberater aus Ratingen, ist technischer Leiter des LOG-Projektes