Kommunikation mit IDA aus einem Guss

Heinrich Munz ist Geschäftsführer LP-Elektronik und bei der Kuka Roboter GmbH, Augsburg, für die Steuerungstechnik verantwortlich

Die Situation in der Automatisierung erinnert an die Verhältnisse bei den Personal Computern vor 15 Jahren. Damals gab es viele unterschiedliche Rechner, Betriebssysteme und Netzwerke mit einer Vielzahl inkompatibler Applikationen. Technologiebrüche waren vorprogrammiert. Heute haben sich bei den PC Windows als Betriebssystem, Ethernet als Netzwerk, TCP/IP als Netzwerkprotokoll sowie die Übertragungsprotokolle HTTP/HTML des Internets als Standard bei diversen Bedientechniken durchgesetzt. Diese Standards müssen auch die Basis für die Automation werden, denn die Industrie will es sich auf Dauer nicht leisten, ausschließlich für sie entwickelte und damit teure Speziallösungen einzusetzen.

Besorgt beobachten deshalb die Anwender die immer größeren Entwicklungsaufwendungen und die sich trotzdem nicht reduzierenden Inbetriebnahme- und Fehlerlokalisierungszeiten von Anlagen in der industriellen Automatisierung. Der Grund: Die Gerätehersteller sind gezwungen, alle möglichen „Kommunikationsstandards” in Form von diversen Feldbussen zu unterstützen. Dazu kommen die unterschiedlichsten Steuerungstechnologien wie beispielsweise SPS, CNC, Roboter- oder diverse Speziallösungen, die mit einer Vielzahl von Sprachen zu programmieren sind. Während sich an dieser Applikations-Situation nur schwerlich etwas ändern lässt, existiert im Kommunikationsbereich unnötigerweise eine Vielzahl unterschiedlichster Technologien (Netzwerke, Feldbusse, E/A-Geräte), die wiederum Brüche darstellen und daher einen freien Datenfluss verhindern.

Die Industrie kann es sich nicht leisten, ausschließlich für sie entwickelte Spezialtechnologien und -produkte einzusetzen. Aus diesem Grund wurde bereits 1996 die weltweit erste, vollständig auf einem Windows-PC basierende Steuerung für Industrieroboter vorgestellt. Diese war damals schon im Grundumfang mit Ethernet und TCP/IP ausgerüstet.

Heute ist eine durchgängige und reibungslose Kommunikation über alle Automatisierungsebenen hinweg gefordert, so dass alle Geräte einheitlich erreicht werden können. Aus diesem Grunde müssen sich alle Hersteller von Automatisierungskomponenten auf einen gemeinsamen Kommunikationsstandard einigen. Dabei genügt es nicht nur, sich auf ein einheitliches Kommunikationsmedium zu einigen. Vielmehr müssen alle Schichten im Kommunikationsstapel und darüber hinaus noch weitere Komponenten identisch sein.

Für die unterste Schicht bietet sich der Ethernet-Standard an. Dieser muss jedoch zunächst für die speziellen Anforderungen der Industrieumgebung tauglich gemacht werden. Da es aus heutiger Sicht sowohl technisch als auch kommerziell oft nicht sinnvoll ist, Ethernet bis zum einzelnen Sensor, Aktor oder Motor hinzuführen, kann ab einer gewissen Stufe ein Übergang von Ethernet auf herkömmliche Feldbusse stattfinden.

Das Problem der großen Komplexität von heutigen zentralen Automatisierungsprogrammen wird durch die Verteilung auf dezentrale Knoten gelöst. Zusammen mit der entsprechenden Software fungiert das Ethernet nicht mehr nur als „dummer” Verteiler von Informationen eines zentralen Steuerungsmasters hin zu „dummen” E/A-Slaves wie bei den Feldbussen. Vielmehr stellt es neben den anderen Diensten die zur Dezentralisierung notwendige Verteilung von Informationen in Echtzeit sicher. Somit kann diese neue Technologie nicht als weiterer Feldbus oder dessen Ersatz bezeichnet werden, sondern stellt einen völlig anderen Ansatz dar.

Um eine einheitliche und standardisierte Mensch-Maschinen-Schnittstelle zu realisieren, sollte jedes Gerät einen integrierten Internet-Server besitzen. Auf den dadurch möglichen Web-Seiten sind alle relevanten Informationen für den Umgang des menschlichen Bedieners mit dem Gerät hinterlegt. Dies hat den Vorteil, dass der Gerätehersteller das Aussehen und die Bedieneroberfläche seines Produktes immer selbst bestimmt, egal, wo die Informationen später angezeigt werden. Überdies ist kein spezifisches Programm zur Präsentation der Informationen notwendig. Diese Aufgabe erfüllt der Webbrowser, der auf einem beliebigen Ausgabegerät laufen kann. Um die Web-Seiten einfach an unterschiedliche Ausgabeformate anpassen zu können, empfiehlt es sich, XML und XSL als Seitenbeschreibungssprache zu verwenden.

Zusätzlich muss jedes Gerät eine einheitliche minimale Diagnosefunktionalität (konfigurierbare Datenvorverabeitung, historisches Speichern und Alarmierung) und Diagnoseschnittstellen aufweisen. Dadurch kann sowohl von einem menschlichen Bediener als auch von anderen Computern einheitlich abgefragt werden.

Ausgefallene oder gestörte Komponenten müssen sich einfach und ohne weiteres Zutun des Bedieners auswechseln lassen. Dadurch ist sichergestellt, dass der Ausbildungsaufwand der Bediener niedrig und die Laufzeit der Anlage möglichst hoch gehalten werden können. Hierfür notwendig sind sowohl eine einheitliche Backup/Restore-Strategie als auch gemeinsame Netzwerk-Management-Dienste und ein Plug-and-Play-Mechanismus für alle Geräte.

Für die Erfüllung der genannten Anforderungen sind unterschiedliche Software-Dienste erforderlich, die in allen Geräten identisch realisiert werden müssen. Hierzu bedarf es einer herstellerübergreifenden Standardisierung, die die Kommunikationskompatibilität der Geräte sicherstellen soll. Dieser Standard muss alle Schichten im Kommunikationsstapel und darüber hinaus noch weitere Komponenten abdecken.

Die unteren Ebenen werden durch das Medium Ethernet mit den Protokollen TCP/IP (UDP/IP für Echtzeit) abgedeckt. Für die höheren Schichten, insbesondere Schicht 7, können einige bereits bestehende Protokolle aus der IT-Welt verwendet werden. Dies könnten beispielsweise HTTP für den Webzugriff oder FTP für File Transfer sein. Für Aufgaben, bei denen es aus der IT-Welt keine passenden Protokolle gibt, müssen neue Schicht-7-Protokolle wie etwa das verteilte Steuern in Echtzeit definiert werden. Wegen der Komplexität der Aufgabenstellung reicht es jedoch nicht aus, nur die Ebene 7 zu spezifizieren. Es bedarf auch einer zusätzlichen Verwaltungssoftware, die die objektorientierte Verteilung der Informationen an alle interessierten Teilnehmer vornimmt. Schließlich muss noch ein wohldefiniertes Application Programming Interface (API) hinzukommen. Auf der Hannover Messe schlug deshalb die Geburtsstunde von IDA – Interface for Distribution Automation – , mit der die Kuka GmbH, Augsburg, Jetter AG, Ludwigsburg, Sick AG, Waldkirch, und Phoenix Contact, Blomberg, eine offene Ethernet-basierte Kommunikationsschicht für verteilte Intelligenz schaffen wollen.

Solche Maßnahmen sind notwendig, damit nicht jeder Hersteller die gesamte Kommunikationssoftware parallel entwickeln muss, sondern sich ausschließlich auf seine Applikation konzentrieren kann. Unter der Voraussetzung, dass die oben angeführte Verteilungssoftware jedem Gerätehersteller zur Verfügung steht, liegt der eigentliche Schwerpunkt der Standardisierung auf diesem API und nicht auf der Ebene-7-Schnittstelle.

Diese Zusammenhänge lassen sich passend am Beispiel von OLE for Process Control (OPC) erläutern. Das OPC-API ist in einer Spezifikation festgelegt und ermöglicht es den Programmierern, Applikationen in Form von OPC Servern oder Clients zu entwickeln. Das TCP/IP-orientierte OPC basiert auf der Verwaltungs- und Verteilungssoftware DCOM von Microsoft und ist durch die Verwendung von TCP statt UDP nicht echtzeitfähig.

Aber auch mit der Realisierung eines einheitlichen API und der dazugehörigen Verwaltungssoftware ist noch nicht alles festgelegt. Damit funktional gleiche Geräte von unterschiedlichen Herstellern mit möglichst wenig Aufwand gegeneinander ausgetauscht werden können, bedarf es so genannter Geräteprofile, die die Minimaleigenschaften jeder Geräteklasse beschreiben. Als Sprache für diese Profile bietet sich die Extensible Markup Language (XML) an. XML hat die Vorteile, dass es sowohl von Menschen als auch von Maschinen direkt bearbeitet werden kann. Zusätzlich lassen sich sogenannte XML-Schemata erstellen.

Auf diese Weise lässt sich aus einem Profil für Automatisierungsgeräte beispielsweise ein Profil für Steuerungen ableiten, das wiederum die Vorlage für spezifische Steuerungen wie SPS, RC, CNC bildet. Ganz zum Schluss der Reihe kann zusammen mit dem Gerät auf der Homepage ein herstellerspezifisches Profil ausgeliefert werden, durch das Zusatzfunktionen beschrieben sind, die über den Standard hinausgehen.

Die Standards für den Datenaustausch sind in erster Linie

– das Hypertext Protocol und

– die Hypertext Markup Language des Internet, mit denen sich alle Informationen im Browser darstellen lassen. Dazu kommt noch

– die sogenannte Extensible Markup Language (XML) für den plattformneutralen Datenaustausch. XML ist wesentlich mächtiger als die Hypertext Markup Language (HTML). Als Seitenbeschreibungssprache regelt HTML nur das äußere Erscheinungsbild eines Dokumentes, ist aber gegenüber dessen Inhalt blind. Mit dem aus der SGML (Standard Generalized Markup Language) hervorgegangenen XML sind jedoch auch dokumentenübergreifende, inhaltliche Festlegungen möglich. Für solche Inhalte ist entsprechend bestimmter Anwendungsszenarien jeweils eine Syntax in Form einer „Document Type Definition“ (DTD) festzulegen, um dann gezielte Abfragen nach den definierten inhaltlichen Kriterien durchzuführen. Auch könnte eine Applikation selbstständig aus Web-Seiten-Parameter für eine Steuerung oder Profile eines Automatisierungsgerätes herauslesen und diese verarbeiten.