Alle Unternehmensbereiche tauschen heute elektronisch Informationen aus. "Doch die verschiedenen IT-Verfahren", bemängelt Tom Jell, Senior Berater im Münchner Best Practice Center der Siemens Business Services (SBS), "sind überhaupt nicht oder handgestrickt mehr schlecht als recht miteinander verbunden." Betrachtet man die produktbezogenen Informationen, dann ist von Integration keine Spur. Vor allem Marketing und Vertrieb, von immer kürzeren Innovationszyklen überrollt, bemängeln, dass sie keinen Durchgriff auf die Daten aus Entwicklung, Konstruktion und Fertigung haben.
Kommunikation bislang nur halbautomatischZwar habe das Produktdaten-Management mehr Transparenz im Lebenszyklus eines Produktes geschaffen, resümiert Mario Jeckle vom Daimler-Chrysler Research and Technology Center. Aber "viele Medienbrüche verhindern noch immer die Sicht auf den Ist-Zustand der Fertigung". Heute kommunizieren die einzelnen Prozessbeteiligten halbautomatisch miteinander. Eine unweigerliche Folge dieser mangelnden Integration sind redundante und inkonsistente Daten, die sich nur unter großem Zeit- und Kostenaufwand vereinheitlichen lassen.
Größtes Hindernis für die vertikale Integration ist das Manko an Standard-Schnittstellen, um Maschinensteuerungen und Planungsebene miteinander zu verbinden. Die Unternehmensabläufe lassen sich dadurch nicht transparent genug für alle Prozessbeteiligten abbilden. Die gegenseitige Beschaffung von Informationen aus Entwicklung, Konstruktion, Fertigung, Vertrieb und Planung ist mühsam, die Reaktionszeiten sind zu lang. Immer kürzere Produktzyklen, schnellere Lieferzeiten, weltweit verteilte Entwicklungs- und Produktionsprozesse und wechselnde Unternehmensverbünde lassen sich ohne durchgängige Kommunikation nicht erfolgreich bewältigen.
Aus technischer Sicht stehen der Integration der Steuerungs- und Planungsebenen ihre verschiedenen Konzepte zur Informationsverarbeitung im Weg. "Maschinensteuerungen arbeiten ereignisbasiert unter Echtzeitbedingungen und sind nicht standardisiert. Der Produktionsplaner hat es dagegen mit standardisierten, transaktionsbasierten Systemen zu tun, die keine Echtzeitfähigkeit zeigen", so Xcc-Spezialist Christian Popp. Um diese beiden Konzepte zusammenzubringen, müssten entsprechende Abbildungen und Schnittstellen geschaffen werden. "Momentan kommen vor allem APIs etwa von Baan oder SAP zum Einsatz. Die sind jedoch nicht standardisiert, so dass wir wieder proprietäre Systeme erhalten."
Inzwischen tragen die Bemühungen um zukunftsgerichtete Standards in der Industrieautomatisierung jedoch erste Früchte. Das zeigt sich zum Beispiel an der zunehmenden Verbreitung der Netzwerktechnologie Ethernet und des Übertragungsprotokolls TCP/IP auch für industrielle Anwendungen. Die institutionellen Vertreter der verbreiteten Bus-Systeme in der Fertigung, darunter die Profibus-Nutzerorganisation PNO oder die "CAN in Automation" sind entschlossen, die Produktionsgeräte und -prozesse in der Automatisierung dem Ethernet zugänglich zu machen - und damit nicht zuletzt auch den vielversprechenden Nutzungsmöglichkeiten des Internet. Seit Ende letzten Jahres widmet sich auch die "Industrial Automation Open Networking Alliance" (Iaona) der Förderung von Ethernet als globalem Standard in der Industrieautomation.
Ist die von einigen Tagungsteilnehmern bemängelte größere Störungsanfälligkeit gegenüber der üblichen Feldbus-Technik erst beseitigt, bietet Ethernet der Fertigung den Anschluss an Firmen-Netzwerke, ermöglicht den Einsatz preiswerter PC-Systeme zur Steuerung und eröffnet den Zugang zum Web.
Auch softwareseitig zeichnet sich - analog zur Entwicklung bei Hardware und Netzwerken - ein unbestrittener Trend in Richtung PC-Standards ab. Speziell im Windows-Umfeld hat sich zur Spezifizierung von Schnittstellen ein De-facto-Standard mit OLE for Process Control (OPC) durchgesetzt, basierend auf COM beziehungsweise DCOM. Ebenfalls auf COM- und Active-X-Technik gründet Microsofts Distributed Internet Applications Arcitecture (DNA).
Dem Anwender bringt OPC eine Reihe von Vorteilen. Als Standard-Schnittstelle macht der Softwarebus den Einsatz spezieller Treiber überflüssig. Dadurch hat man letztlich freie Wahl bei den Software- und Hardwarekomponenten. Vor allem jedoch wird die Konfiguration des Datenaustauschs zwischen einzelnen Anwendungen und zur Hardware wesentlich vereinfacht. Jeder OPC-Server kann mehrere Client-Anwendungen gleichzeitig bedienen. Der Server-Zugriff ist dabei prinzipiell auch über Intra- oder Internet möglich. Durch die Nutzung von DCOM ist für den Industriestandard auch Netzwerkfähigkeit garantiert. Client-Anwendungen nutzen dann Datenquellen unabhängig davon, ob sich der OPC-Server auf dem lokalen Rechner befindet oder remote im Netz.
Teja Ulrich, Berater bei ARC Advisory Group, zur Verbreitung der Technik: "Der OPC-Standard hat die Microsoft-Plattform zur DNA for Manufacturing erweitert und genießt in der Automatisierungstechnik zur Zeit breite Unterstützung." Viele Manufacturing-Execution-Systeme (MES) setzen auf die COM-Architektur. Da sich die Technik bislang hauptsächlich auf der Ebene der Fertigungsleitsysteme durchgesetzt hat, versucht Microsoft nun mit COM+ weiter in die Unternehmensplanungsebene vorzudringen. COM+ soll DNA die fehlenden Dienste für verteilte Unternehmensanwendungen bringen. Für eine Beurteilung ist es aber nach erst zweimonatiger Marktpräsenz noch zu früh.
Ein weiterer Ansatz ist Embedded Corba und das Corba-Komponentenmodell CCM. Auf Java beziehungsweise Corba setzt eine Reihe bedeutender Hersteller, bieten sie doch unter anderem Vorteile durch ihre Nähe zu Internet-Techniken. Auf Geräteebene stehen sich Microsofts Universal Plug & Play, Jini von Sun oder Chai von Hewlett-Packard gegenüber.
OO-Spezialist Angelo Schneider erläutert am Beispiel eines Projekts aus der Stahlbranche Einsatz und Nutzen von JavaEnterprise-Technologien (kurz: J2EE) in Industrieunternehmen. Schneider: "J2EE bietet definierte Schnittstellen, die komplett auf Java basieren und für Projektteams viele Aspekte einer Software-Architektur transparent und handhabbar machen." Dazu zählen beispielsweise
-die Portabilität über Rechnerarchitekturen hinweg (Mainframe, Midrange, Server, PCs),
-die Anbindung von Altsystemen und Transaktionsmonitoren (MoM, JMS, CICS),
-die Datenbankanbindung und Verteilung (Corba, IIOP, RMI),
-die Integration in Intranet und Internet und
-die Unterstützung durch verschiedene Hersteller wie Sun, IBM, BEA, Oracle und andere.
Breite Zustimmung fand in diesem Zusammenhang die Aussage eines Teilnehmers, im reinen Microsoft-Umfeld sei man mit DNA besser bedient. Setze ein Unternehmen jedoch Mainframes, Workstations und PCs verschiedener Hersteller ein, werde die Java-Corba-Plattform interessanter.
Nach Auffassung der Experten vollzieht sich der Wandel zur vertikal integrierten Unternehmensstruktur mit größter Wahrscheinlichkeit auf der Basis von Internet-Protokollen und verteilten objektorientierten Architekturen. Die entscheidende Rolle beim Datenaustausch spielt auch im Automatisierungsbereich die Datenbeschreibungssprache XML (Extensible Markup Language). "Wenn wir erfasste Daten weiterverarbeiten sollen, ist XML überall die geeignete Basis," so Jell. Nach seiner Einschätzung wird XML ähnlich wie bereits Java in breitem Umfang Einzug in die Automatisierungstechnik halten. Die meisten der hier genannten Architekturkonzepte stützen sich denn auch auf XML.
Ohne Kommunikationsstandards hilft jedoch auch XML in der Fertigung nur begrenzt weiter. Man kann jetzt zwar Daten von A nach B fließen lassen, und die Information von A kann intern jeweils anders aussehen als die in B. Im Fertigungsprozess sollen die verschiedenen Systeme aber auch interagieren können. Das Produktionsplanungssystem sollte dem Steuerungssystem zum Beispiel mitteilen können: "Produktion anhalten" oder "Wechsle an der Stelle den Zulieferer". Um das zu realisieren, müssen sich jedoch erst alle Hersteller von Automatisierungskomponenten auf einen gemeinsamen Kommunikationsstandard einigen.
Hier kommen Protokolle wie Soap (Simple Object Access Protocol) oder XML/RPC (Remote Procedure Calls) ins Spiel. Durch ihre Unabhängigkeit von bestimmten Betriebssystemen, Programmiersprachen oder Objektmodellen versprechen sie nicht nur eine größere Offenheit. Über das Standard-Internet-Protokoll HTTP lässt sich etwa mit Soap auch die Interaktion zwischen Applikationen definieren. Wenn es die entsprechende Akzeptanz am Markt erreicht, ist das Protokoll geeignet, heterogene Kommunikationswelten zu vereinheitlichen.
Ist die Automatisierungsebene über solche Architekturen und Standards Schritt für Schritt mit der Planungsebene zusammengewachsen, verfügt das Management über aufbereitete Maschinen- und Prozessdaten. Es könnte dann sehr viel schneller als heute klären, warum etwa bestimmte Produktionsstandorte kostengünstiger oder qualitativ besser arbeiten. Zur vollständigen Lösung der Probleme dieser Integration steht nach Aussagen der Techniker im Prinzip nur noch die Einigung auf einen Standard aus. Das Auditorium in der Veranstaltung äußerte dazu jedoch seine Vorbehalte gegenüber allzu euphorischen Versprechungen. Bei der durchgängigen Integration aller Prozesse bis hin zu Partnern und Lieferanten sind die organisatorischen Randbedingungen gar nicht groß genug einzuschätzen. Besonders rechtliche Fragestellungen hinsichtlich der Datenzugriffe und der Sichtbarkeit interner Informationen sehen die Referenten als Problembereiche.
*Sonja Hübner ist freie Journalistin in Stuttgart.
Abb: Microsofts De-facto-Standard OLE for Process Control (OPC) erweitert die Distributed Internet Applications Architecture (DNA) des Herstellers für industrielle Zwecke. Quelle: ARC