Das unter der Schirmherrschaft von General Motors entwickelte Manufacturing Automation Protocol, kurz MAP, läßt derzeit noch viele Wünsche offen. Walter Gora* skizziert die beiden Hauptprobleme von MAP: die Inkompatibilität zwischen den einzelnen Versionen sowie die in Forschungsinstituten nachgewiesene Unzuverlässigkeit der Protokolle.
Erfahrungen mit MAP-Protokollen sowie insgesamt mit der Problematik einer computerintegrierten Fabrikation werden seit Anfang 1985 im Rahmen des PAP-(Projekt für flexibel automatisierte Produktionssysteme) Projekts an der Universität Erlangen-Nürnberg gewonnen. Die Ziele dieses gemeinsamen Projektes mehrerer Lehrstühle der Fertigungstechnik und der Informatik sind der von Staat und Industrie geförderte Pilotaufbau einer rechnergeführten Fabrik sowie die Untersuchung beziehungsweise Erforschung von fertigungs- und informationstechnischen Problemstellungen in diesem Bereich.
Während die MAP-Protokolle auf dem Token-Bus aufsetzen, wird im Rahmen des PAP-Projektes das Ethernet eingesetzt, für das bei Projektbeginn bereits Anschlüsse an die verschiedenen Rechnerkomponenten verfügbar waren. Ferner gewährleistet das Ethernet als Backbone-Netz (Hintergrundnetz) im niedrigen Lastbereich bessere Antworteigenschaften als andere lokale Netze.
Durch das dem MAP-Konzept zugrundeliegende ISO/OSI-Schichtenmodell, welches die Kommunikation dem Anwender durch die Vergabe fester Schnittstellen verdecken soll, ist es allerdings auch möglich, neben dem in MAP bevorzugten Token-Bus andere physikalische Übertragungsmöglichkeiten (Ethernet, Token Ring, V.24 oder IEC-Bus) als Alternative zu verwenden und trotzdem "MAP-kompatibel" in der Anwendungsebene zu sein. Im Rahmen des PAP-Projektes an der Universität Erlangen-Nürnberg wurde diese Möglichkeit ausgenutzt, um auch Geräte, die nicht normkonform sind, in die rechnergeführte Fertigung mit zu integrieren. Auf dieser Basis konnten bereits mehrere Verfahrensketten vom Entwurf auf der CAD-Station bis hin zur Übermittlung von Programmen in die entsprechenden Steuerungen realisiert werden.
So kann beispielsweise eine Tastatur an einer CAD-Workstation entworfen werden, anschließend lassen sich auf der Basis der eingegebenen Informationen automatisch entsprechende Roboterprogramme generieren und diese an einen zentralen Datenbankserver weiterleiten. Während der Fertigung entscheidet nun der Fertigungsleitrechner, welcher Auftrag zu bearbeiten ist, und übermittelt die entsprechenden Auftragskenndaten an einen Zellenrechner. Dieser fordert das entsprechende Roboterprogramm auf der Basis der MAP-Protokolle von der zentralen Datenbank an und lädt dieses anschließend in die Robotersteuerungen.
In bezug auf die MAP-Protokolle der Ebenen 5 bis 7, die im Rahmen des PAP-Projektes implementiert wurden, hat sich gezeigt, daß zwar ein erster Schritt in Richtung "Computer Integrated Manufacturing" mit diesen international einheitlichen Protokollen und Schnittstellen getan werden kann, jedoch ist noch grundlegende weitere Forschungs- und Normierungsarbeit notwendig.
Zeitkritische Aktionen nicht abgedeckt
Da die fertigungstechnischen MAP-Protokolle als Anwendungsprotokolle durch sämtliche Kommunikationsschichten geschleust werden müssen, können zeitkritische Aktionen, wie sie beispielsweise zur Prozeßkontrolle notwendig sind, kaum erfüllt werden. Hierzu wurden mittlerweile verschiedene Realzeit-Architekturen definiert (Mini-MAP, EPA-MAP), welche die meisten Schichten des ISO/OSI-Referenzmodells unbesetzt lassen.
Zwar wird dadurch einerseits die Verarbeitung unter Echtzeitbedingungen ermöglicht, jedoch wird andererseits Abschied von der Idee einer einheitlichen Kommunikationsarchitektur genommen. Die "Sprachlosigkeit" zwischen verschiedenen Komponenten zu lösen, war allerdings eines der Hauptziele der MAP-Bemühungen, die insofern realistischer gesehen werden müssen.
Eine weitere Schwäche der aktuellen MAP-Spezifikation ist die fehlende Möglichkeit, Prioritäten vergeben zu können. Zwar ist auf dem Token-Bus prinzipiell eine prioritätsgesteuerte Übertragung möglich und auch die ISO-Protokolle sehen Vorrangdaten vor (Expedited Data), doch wird dies momentan von den MAP-Protokollen nicht unterstützt. Alarme und wichtige Ereignisse können damit nicht vorrangig übertragen werden, sondern werden eventuell durch nicht-zeitkritische Datenübertragungen (Statistikinformationen etc.) blockiert. Bezüglich der Prioritätsvergabe kann demnach auch ein Ethernet, wie beispielsweise im Erlanger Pappprojekt, ohne Bedenken eingesetzt werden.
Engpässe werden darüber hinaus bei der Umsetzung in reale Produktionsanlagen durch die verschiedenen MAP-Spezifikationen (MAP 2.1: März '85, MAP 2.2: August '86, MAP 3.0: Mitte '87) verursacht, wobei die einzelnen Versionen teilweise inkompatibel miteinander sind. So können beispielsweise zwischen den in der Version 2.2 definierten Echtzeit-Architekturen und der "echten" MAP-Architektur der Version 2.1 keine Daten ausgetauscht werden. Weiterhin ist zwischen den MAP-Architekturen der Version 2.1 und 3.0 kein Datenaustausch möglich, da in MAP 3.0 die Ebene 6 ("presentation layer") durch ein entsprechendes ISO-Protokoll besetzt wird, während diese Kommunikationsschicht in der Version 2.1 leer war.
Nachdem 1985 die MAP-Spezifikation 2.1 als relativ endgültige Fassung für die Kommunikation in der Fertigung propagiert worden war, wird dies auch momentan von der in diesem Jahr erwarteten Spezifikation 3.0 erwartet. Allerdings ist abzuwarten, inwieweit diese Ankündigungen auch in der Realität Bestand haben. Zwar können Inkompatibilitäten zwischen weiteren zukünftigen MAP-Spezifikationen durch entsprechende Umsetzungsprogramme beseitigt werden, doch diese Anpassungsarbeiten bereits vom Konzept her zu vermeiden, war das eigentliche Ziel des MAP-Projektes.
Grundlegende Forschungsarbeiten dienen in Erlangen der Überprüfung der Praxisbezogenheit von in MAP definierten fertigungstechnischen Anwendungsprotokollen gemäß EIA RS 511. Diese Funktionen beziehungsweise Kommandos ermöglichen die international einheitliche Ansteuerung von Automatisierungskomponenten wie speicherprogrammierbaren Steuerungen, Robotern oder NC-Steuerungen. Wichtige Anwendungsbereiche, die in jeder automatisierten Fabrikation vorkommen, wie beispielsweise die Steuerung des Transportsystems oder die Einbindung des Lagers, sind momentan jedoch noch nicht in dieser Norm mit enthalten und müssen über Privatlösungen realisiert werden.
Reinfall in Montagewerk von General Motors
Als Negativbeispiel für die mangelnde Praxisbezogenheit der MAP-Anwendungsfunktionen kann das neue, 600 Millionen US-Dollar teure Montagewerk von General Motors in Hamtrack aufgeführt werden. Hier versuchen nach einer Meldung des "Wall Street Journals" von Anfang Mai 1986 die Ingenieure und Programmierer seit mittlerweile über einem Jahr vergeblich, die Produktion anlaufen zu lassen.
General Motors hatte dieses Prestigeobjekt als "Passage in die Zukunft" beschrieben - dagegen sieht die Realität düster aus. Statt Autos zu lackieren, sprühen sich die Roboter gegenseitig an. Das vollautomatische Transportsystem, das mit enormen Kosten und "High-Tech" von Grund auf neu konzipiert und eingerichtet wurde, steht wie die gesamte Fabrikation ebenfalls still.
Weitere Probleme bei der Realisierung der MAP-Protokolle im Rahmen des PAP-Projektes an der Universität Erlangen-Nürnberg ergaben sich mit der MAP-Spezifikation selbst, die zumeist informell, daß heißt in Prosa und ohne die Verwendung formaler Spezifikationstechniken, verfaßt ist. Hieraus resultieren Verständnisprobleme für den Implementierer, der auf seine eigene Interpretation in einer sehr komplexen Sachwelt angewiesen ist und diese nur unzureichend abstimmen kann, sei es durch Erfahrungsaustausch mit anderen Entwicklern oder durch erläuternde Literatur.
Gerade Kommunikationssysteme sind allerdings darauf angewiesen, von einer eindeutigen Basis auszugehen, um überhaupt eine sinnvolle und praxisrelevante Kommunikation zu ermöglichen. Weiterhin weisen die ISO-Protokolle erhebliche Fehler auf, die bei einer vollautomatisierten Fabrikation zu "unerklärlichen" Leistungseinbußen oder auch zu Totalverklemmungen führen können. Bereits für das ISO-Session-Protokoll, welches nur eine Schicht gemäß dem ISO/OSI-Referenzmodell realisiert, wurden in Forschungsinstituten mehr als 25 Fehler entdeckt.
Ferner ist ein kontinuierliches Testen der Protokolle auf Normkonformität bereits bei der Entwicklung notwendig, so daß Fehler beziehungsweise Implementierungs-Schwierigkeiten bereits in einem frühen Stadium entdeckt und behoben werden können. Hierzu wurde an der Universität Erlangen das NBS-Testbed des National Bureau of Standards portiert und weiterentwickelt.
Leistungsverhalten noch ungeklärt
Völlig ungeklärt ist noch das dynamische Leistungsverhalten der einzelnen Kommunikationsschichten. Beim Verbindungsaufbau können auf jeder Ebene zahlreiche Parameter individuell ausgehandelt werden. Diese Parameter, beispielsweise Größe eines Paketes und gewisse Gütemerkmale, bestimmen wesentlich die Leistung des Kommunikationssystems. Bei einer schlechten Abstimmung in einem großen Netzwerk kann es hierbei zu erheblichen Leistungseinbußen kommen, so daß Antwortzeiten im Sekundenbereich auftreten können oder letztendlich die Kommunikation sogar zusammenbricht.
Die nicht nur in Erlangen gewonnenen bisherigen Erfahrungen zeigen zudem auf, daß weniger das lokale Netz als solches (Token Bus, Token Ring, Ethernet) bestimmend für die Leistung der Kommunikation im Rahmen der Fabrikautomatisierung ist, sondern vielmehr die Art der Protokolle und deren Realisierung.
*Dipl.-Inform. Walter Gora ist wissenschaftlicher Mitarbeiter am Lehrstuhl Informatik 7 dem Universität Erlangen-Nürnberg und beschäftigt sich im Rahmen des PAP-Projektes mit den MAP-Protokollen und Netzwerkmanagement-Fragestellungen.