Der Einsatz von lokalen Netzen im Bereich der kommerziellen Datenverarbeitung schafft ein neues Problem, dem bislang noch wenig Aufmerksamkeit gewidmet wurde: Kann bei einer zentralen EDV-Anlage prinzipiell von einer einheitlichen Zeitbasis ausgegangen werden, so ist die Synchronisation der verschiedenen lokalen Zeiten in einem Rechnernetz noch weitestgehend ungelöst.
Die meisten Programmsysteme wie Textverarbeitung, Buchhaltung oder Auftragsbearbeitung, die in einem verteilten System auf gemeinsame Ressourcen (Speicher, Drucker etc.) zugreifen, sind im Normalfall auf eine gemeinsame Zeitbasis nicht angewiesen, doch spätestens mit der Vernetzung im Fertigungs- und Automatisierungsbereich sind praktische Lösungen zu diesem bislang akademischen Problem gesucht.
Aus der Forderung nach einer gemeinsamen Zeitbasis in einem lokalen Netz ergeben sich mehrere - teils nur mit beträchtlichem Aufwand lösbare - Schwierigkeiten. Werden unterschiedliche Hardwarekomponenten an ein gemeinsames Netz (zum Beispiel Ethernet, Token-Bus) angebunden, so kann im Normalfall nicht davon ausgegangen werden, daß eine zentrale Uhr existiert. Zwar wäre ein solcher zentraler Zeitgeber, beispielsweise auf der Basis einer Funkuhr, die sicherlich beste Lösung, doch die Kosten für die Sende- und Empfangseinrichtungen sowie die Abschirmung gegenüber den sehr starken elektromagnetischen Einflüssen in der Nähe der Rechenanlagen sind sehr hoch und in der Praxis kaum durchzusetzen. Zudem ist die Flexibilität des Gesamtverbundes bei Erweiterungen oder Ersetzungen von Netzkomponenten sehr eingeschränkt. Beispielsweise wird die Kostenersparnis im Fertigungs- und Produktionsbereich, die durch den Einsatz von vernetzten Mikrorechnern erreicht wird, durch teure Spezialhardware für die Zeitsynchronisation wieder aufgehoben Bereits in der Planungsphase von Produktionsanlagen sollte deshalb eindeutig analysiert werden, inwieweit zeitkritische Anforderungen auftreten und diese über ein lokales Kommunikationssystem abgearbeitet werden beziehungsweise entsprechende Gegenreaktionen erfolgen müssen.
100 Millisekunden als Zeitraster im Rahmen von MAP definiert
Zumeist genügt im Bereich der Automatisierung jedoch eine Genauigkeit in der Größenordnung von 100 Millisekunden, die sich mit den bereits bekannten und teilweise auch realisierten softwaremäßigen Synchronisationstechniken erreichen läßt. Dieses Zeitraster wurde auch von General Motors (GM) sowie weiteren einflußreichen Herstellern von Automatisierungsanlagen im Rahmen der Definition der MAP-Protokolle als ausreichend angesehen. Mit diesen Kommunikationsprotokollen im Fertigungs- und Produktionsbereich wurde mittlerweile ein bislang konkurrenzloser Industriestandard geschaffen. Im Herbst 1985 sollen auf der Autofact '85 in Detroit die Geräte mehrerer großer Hersteller zusammengeschlossen werden und die Leistungsfähigkeit des MAP-Konzeptes unter Beweis stellen.
Folgende Bedingungen sind demnach bei der Einführung eines lokalen Netzwerks zu prüfen:
a) Sind die Kosten für eine Zentraluhr tragbar?
b) Existieren zeitkritische Anforderungen, die Reaktionszeiten von weniger als 100 Millisekunden erfordern?
Sind beide Fragen zu verneinen kann auf die einzelnen lokalen Rechneruhren zurückgegriffen werden, die mit Hilfe von geeigneten Synchronisationsmechanismen zu überprüfen und eventuell zu korrigieren sind.
Wird bei der Zeitsynchronisation in einem lokalen Netz von den einzelnen verteilten Rechneruhren ausgegangen, dürfen allerdings folgende Probleme nicht außer acht gelassen werden:
- Die Zeitraster der einzelnen lokalen Uhren sind unterschiedlich genau. So wird beispielsweise bei den Unix-Systemen von einer Mindestgenauigkeit von 20 Millisekunden ausgegangen, viele Unix-Installationen erreichen jedoch bessere Werte. In einem lokalen Netzwerk müssen sich jedoch sämtliche angeschlossenen Systeme nach dem "zeitschwächsten" Rechner richten, ansonsten wird eine höhere Genauigkeit vorgetäuscht.
- Die Zeiten der einzelnen lokalen Uhren laufen auseinander. Die Erfahrungen, die mit der Zeitsynchronisation im lokalen "Revue"-Netz (Rechner-Verbund Universität Erlangen) erzielt wurden, zeigen, daß ein Großteil der Rechnerhersteller sich sehr wenig Gedanken über die Qualität der verwendeten Quarze macht. So wurde bei einigen Rechnern ein Auseinanderdriften von bis zu zwei Minuten am Tag gemessen. Diese Werte werden heutzutage selbst bei den billigsten Quarz-Armbanduhren übertroffen und können auch in den Rechnern durch die Verwendung qualitativ hochwertigerer Quarze verbessert werden.
-Durch die Synchronisation der einzelnen lokalen Rechneruhren auf eine gemeinsame Netzzeit hin wird zum einen Rechnerkapazität benötigt und andererseits das Kommunikationssystem benutzt, wodurch weitere Ungenauigkeiten auftreten. So können die Synchronisationsprozesse durch folgende (unvollständig aufgezählte) Mechanismen negativ beeinflußt werden:
- Störung durch andere Benutzer bei Systemen ohne echte Prioritäten (Zum Beispiel Unix-Rechner),
- Prozeßwechsel auf Betriebssystemebene,
- Störung durch Interrupts oder Alarme,
- Behinderungen oder Kollisionen auf dem Kommunikationsmedium.
Insbesonders bei dem heute am weitesten verbreiteten Ethernet können aufgrund des Zugriffsverfahrens (...)MA/CD ("Carrier Sense Mutiple Access with Collision Detection") vom Prinzip her unbegrenzte Antwortzeiten auftreten. Bei sehr starker Last beispielsweise, wenn mehrere Stationen Dateien übertragen ("File-Transfer") Programme von Automatisierungsgeräten angefordert werden ("Downline Load") oder Grauwertbilder im Rahmen der Mustererkennung analysiert werden müssen, ist eine Netzkapazität in der Größenordnung des Ethernets (10 MB) nicht mehr ausreichend. Dies ist durch das Zugriffsverfahren des Ethernets zu erklären, denn zu einem bestimmten Zeitpunkt kann jeweils nur eine einzige Station senden. Der Sendevorgang wird von allen anderen Stationen bemerkt, die nach Beendigung der aktuellen Übertragung auf das Netz zugreifen, wobei es dann zu den erwähnten Kollisionen kommen kann.
Kollisionen auf dem Ethernet werden zwar erkannt und die sendewilligen Stationen können nach einer, von der jeweiligen Realisierung des Zugriffsverfahrens abhängigen Zeitdauer wieder auf das Kommunikationsmedium zugreifen, doch auch dann kann es wiederum zu den gerade beschriebenen Verzögerungen beziehungweise Behinderungen kommen.
Durch derartige Interferenzen wird auch die Synchronisation im lokalen Netz beeinflußt. Kommunikationssysteme auf der Basis des Token-Rings oder des Token-Bus - auf letzterem basiert das Kommunikationskonzept der MAP-Gruppe - garantieren jedoch ein besseres Antwortzeit-Verhalten. Flexible Fertigungszellen (FFZ), die wie in Abbildung 1 über ein gemeinsames Kommunikationssystem mit Leit- und Prozeßrechnern verbunden sind können somit auf der Basis einer gemeinsamer Zeitachse besser aufeinander abgestimmt werden. Der Materialfluß zwischen zwei Zellen kann so auf der Basis einer gemeinsamen Netzzeit genauer kalkuliert werden.
Dadurch wird nicht zuletzt auch eine höhere Produktionsgeschwindigkeit möglich, da mit zusätzlicher Unterstützung von mechanischen oder elektronischen Sensoren Rechneraktionen im voraus besser geplant und vorbereitet werden können, wie
- Programme nachladen oder entsprechende Software-Parameter setzen,
- Durchlauf-Alternativen beim vollständigen Ausfall einer Fertigungszelle berechnen sowie die einzelnen flexiblen Fertigungszellen; entsprechend zu informieren und untereinander abzustimmen
- den Materialfluß bei kurzfristiger Überlastung einer Station oder nach manuellen Eingriff durch das Bedienpersonal flexibel zu dirigieren
Ausgehend vom Synchronisationsmechanismus Tempo, der an der University of Berkeley (Kalifornien) entwickelt wurde, wurden innerhalb des Erlanger Revue-Netzes (Abbildung 2) mehrere unterschiedliche Unix-Rechner auf eine gemeinsame Netzzeit hin ausgerichtet. Mittlerweile wird auf der Basis des Synchronisationsdienstes "Resy" (Rechnersynchronisation) eine Netzgenauigkeit auf dem Ethernet von zirka 50 Millisekunden erreicht. Dieser Wert ist zwar im Gegensatz zu einer Zentral-EDV-Anlage gesehen sehr ungenau, in einem heterogenen Computernetz wurden solche Werte bislang aber noch kaum erreicht.
Master-Prozeß fragt "Zeitdämon" ab
Auf jedem der in der Zeitsynchronisation eingeschlossenen Rechner ist permanent ein sogenannter "Zeitdämon" installiert, der von einem Master-Prozeß abgefragt und zu Korrekturen veranlaßt wird. Prinzipiell wird auf der Basis der einzelnen lokalen Rechneruhren eine gemeinsame Netzzeit errechnet, wobei allerdings fehlerhafte Werte, die unter ein definiertes Raster fallen, in diese Berechnung nicht eingehen.
Resy benötigt auf dem steuernden Rechner ("Master") einen Anteil von 0,5 Prozent der gesamten Rechenleistung. Auf allen anderen Netzkomponenten ("Slaves") schwankt die benötigte Leistung, je nach Qualität der lokalen Uhr und den Störungen durch die aufgeführten Interferenzen, zwischen 0,05 und 0,1 Prozent. Die einzelnen lokalen Rechneruhren werden in einem Zyklus von drei Minuten zwanzigmal hintereinander abgefragt ("polling"). Fehlerhafte Ergebnisse, "Ausreißer", werden dadurch erkannt und eliminiert.
Lokale Zeit wird zur gemeinsamen Netzzeit korrigiert
Für die Qualität des in Erlangen implementierten Synchronisationsmechanismus spricht die Tatsache, daß im Durchschnitt nur jede zweite Stunde die Zeit eines am Ethernet angeschlossenen Rechners korrigiert werden muß. Fällt der Rechner aus, der die momentane Synchronisation steuert, wird dies nach einer gewissen Zeitdauer erkannt und der Master-Prozeß auf einem beliebigen anderen aktiven Rechner gestartet. Ein großer Vorteil der Synchronisation im lokalen Revue-Netz ist es, daß mißbräuchliches oder versehentlich falsches Setzen der einzelnen lokalen Uhren sofort erkannt und die lokale Zeit zur gemeinsamen Netzzeit hin korrigiert wird.
Es hat sich aufgrund der Erfahrung gezeigt, je mehr Rechner an einem lokalen Netz angeschlossen sind und auf der Basis von Resy synchronisiert werden, desto unwahrscheinlicher und auch unmöglicher ist es, daß die einzelnen Zeiten manipuliert werden können. Dies hat insbesondere für die Datensicherung und für das sogenannte "Makefile"-Konzept unter Unix Bedeutung.
Allerdings muß auch auf die Gefahren eines fehlerhaften Algorithmus oder einer mit Fehlern versehenen Realisierung hingewiesen werden da dadurch das gesamte Zeitgefüge im gesamten Netz durcheinandergebracht wird und man sich dadurch leicht dem Unmut der betroffenen Benutzer aussetzt.
Im Rahmen eines "Projektes für flexibel automatisierte Produktionssysteme" (PAP), in dem die Universität Erlangen-Nürnberg zusammen mit einem Partner aus der Industrie eine Modellfabrik beispielhaft realisieren und untersuchen will, wird das Synchronisationskonzept "Resy" im Fertigungsbereich eingesetzt. Hierbei sollen Concurrent-CP/M-Systeme zusammen mit Xenix-Rechnern, die beide als flexible Fertigungszellen fungieren, an ein gemeinsames Netz angeschlossen und synchronisiert werden.
Dipl.-Inf. Walter Gora ist wissenschaftlicher Mitarbeiter am Lehrstuhl für Rechnerarchitektur und Verkehrstheorie (Prof. Herzog) der Universität Erlangen-Nürnberg. Der Autor des Artikels beschäftigt sich mit dem Netzwerkmanagement im Fertigungs- und Automatisierungsbereich auf der Basis des GM-MAP-Konzeptes.