Derzeit koexistieren verschiedene Ansätze zur Kopplung von Warenwirtschaftssystemen (ERP) mit der Fertigung. Diese Lösungen basieren zum Großteil auf proprietären Protokollen. Dies gilt gleichermaßen für die Kommunikation zwischen Produktionsausführung und Produktionsleitebene (MES: Manufacturing Execution Systems) wie auch für den Datenaustausch mit der Betriebsleitebene (ERP). Die Kommunikation mit SAP-Systemen erfolgt klassisch dokumentenbasiert mittels IDocs (Intermediate Documents) und Funktionsbaustein-Aufrufen per RFCs (Remote Function Calls) oder BAPI - Business Application Programming Interface - (siehe auch Computer&AUTOMATION 2008, H. 9, S. 54ff.).

Mit der Verbreitung und Akzeptanz von Webservice- basierten Kommunikationsmechanismen findet diese Technik vermehrt auch als Transportprotokoll Verwendung. SAP-Systeme können mittels standardisierter Webservice-Schnittstellen (Enterprise Services) angesprochen werden, beispielsweise zum Erfassen von Qualitätsdaten. Erste Ansätze zur Verwendung von Webservice-basierter Kommunikation sind ebenso im Bereich der Betriebs- und Maschinendatenerfassung (BDE/ MDE) zu erkennen.

Systemarchitektur zur vertikalen Integration via OPC Unified Architecture auf Basis von AP Plant Connectivity und MII.

© SAP, MPDV

Bei den bereits verwendeten Formaten setzt sich der Trend zur Standardisierung fort. So unterstützt SAP im Rahmen des Produkts SAP MII (Manufacturing Integration and Intelligence) eine herstellerübergreifende Kommunikation zwischen ERP und MES auf Basis des internationalen ISA-95-Schnittstellenstandards und dessen XML-Implementierung B2MML. Obwohl auch andere ERP-Anbieter die ISA- 95-Spezifikation unterstützen, ist die Marktdurchdringung des Standards noch gering. Neben den zahlreichen proprietären Schnittstellen zu Steuerungen hat sich in vielen Industrien vor allem die OPC-Technologie (OPC: OLE for Process Control) etabliert. Dennoch existieren parallel dazu branchenspezifische Standards wie SECS/GEM in der Halbleiterindustrie und Euromap 63 im Bereich Spritzgusstechnik. Einige SPS-Hersteller können über Zusatzmodule ihre Steuerungen direkt mit einer Datenbank oder einem ERP-System verbinden.

Mit dem DPWS (Device Profile for Webservices) propagiert Microsoft Webservices für die Gerätekommunikation. Windows Vista, Windows Embedded und Windows CE unterstützen diesen Standard. Automatisierungsanbieter wie die Firma Beckhoff integrieren bereits DPWS-Stacks in ihre Steuerungen. Der Vorteil von Webservices liegt vor allem in der einheitlichen Kommunikation über alle Hierarchie-Ebenen. Als Nachteile gelten die Performance (vor allem die Latenzzeit beim Verbindungsaufbau) und die Bandbreite bei XML-basierten Nachrichten. Zudem gibt es keine Organisation, die für die Normierung der DPWS-Profile zuständig ist und deren korrekte Implementierung in Produkten zertifiziert. Ein weiterer Schwachpunkt: DPWS beschreibt derzeit nur die Kommunikation, ein standardisiertes Datenmodell fehlt.

OPC Unified Architecture

Die OPC-Foundation setzte sich zum Ziel, auf Basis der COM/DCOM-Technologie (Distributed Common Object Modell) von Microsoft einen einheitlichen Zugriff auf Echtzeit-Daten unter Windows-Betriebssystemen zu erarbeiten. Im August 1996 wurde mit OPC-DA (Data Access) die erste Schnittstellenbeschreibung veröffentlicht. Bis zum Jahr 2004 wurden insgesamt elf Spezifikationen für unterschiedliche Aufgaben definiert. Im praktischen Einsatz wurden jedoch schnell Schwächen deutlich: COM/DCOM schließt die Nutzung von OPC über Internet aufgrund von Firewall-Unverträglichkeiten aus und lässt nur einen Einsatz auf Windows-Plattformen zu. Der Versuch, dies mit den OPC-XML-Webservices zu beheben, überzeugte in der praktischen Umsetzung allerdings nicht - der Nachrichtenaustausch war um den Faktor 10 langsamer.

 Hauptmanko der OPC-Spezifikationen ist jedoch das fehlende einheitliche Datenmodell: Jeder Spezifikationsteil definiert ein eigenes Datenmodell unabhängig und weitgehend inkompatibel zu den anderen. Diese Schwächen beseitigt die 2004 aufgesetzte OPC Unified Architecture (OPC UA) mit einem einheitlichen Datenmodell und einem performanten binären Übertragungsprotokoll. Darüber hinaus hat OPC UA das Potenzial, als Schnittstellen-Komponente direkt in Steuerungen integriert zu werden. Dadurch können die Windows-basierten Gateway-PCs für den OPC-Server entfallen und die Lebenszykluskosten (weniger Software-Updates sind notwendig) sinken.

Architekturvergleich: OPC versus OPC Unified Architecture

© SAP, MPDV

Die Kern-Elemente der OPC UA wurden bereits 2006 vorgestellt (siehe auch Computer& AUTOMATION 2006, H. 10, S. 54ff.) und Anfang 2009 zur endgültigen Abstimmung als IEC-Norm (IEC 62541) angenommen. Lediglich das Ereignis- Modell für „OPC UA Alarms" sowie „OPC UA Discovery" (definiert, wie verteilte OPC-UA-Server für Clients sichtbar gemacht werden) sind bislang noch als Konzepte verfügbar. Neben dem bereits in ersten Produkten eingesetzten C/C++- und .NET-Stack, ist seit März 2009 ein Java-basierender Stack als Beta-Version verfügbar.

Beispielsweise ermöglicht der Automatisierungsspezialist Beckhoff bei seiner Embedded SPS den Zugriff auf Laufzeitdaten über einen eingebetteten OPC-UA-Server. Auch die Scada-Software der Firma Iconics unterstützt OPC UA. Deren 3D-Visualisierung GraphworX64 kann Echtzeit-Daten über einen OPC-UA-Client einlesen. Seit Anfang 2009 steht mit dem Produkt SAP PCo (Plant Connectivity) die OPC Unified Architecture im Rahmen von SAP MII zur Verfügung. Das PCo-Modul übernimmt die hardwarenahe Anbindung und stellt einen OPC-UA-Client bereit, mit dem sich prozessnahe Parameter abrufen und mittels MII in ein ERP-System übertragen lassen. Momentan wird das ereignisbasierte Publisher/Subscriber-Modell unterstützt: Ändert sich der Wert eines „abonnierten" OPC-Tag, erhält die PCo- Software eine Nachricht mit dem aktualisierten Wert.

Eine universelle Schnittstelle

Im Future Factory Lab von SAP Research in Dresden werden innovative Konzepte und Technologien, wie die OPC Unified Architecture, praxisnah erprobt.

© SAP, MPDV

Obwohl die klassische OPC-Technologie in der Produktion weit verbreitet ist, beschränkt sich deren Nutzung auf die Integration von MES, Scada und Steuerungstechnik untereinander. Das Potenzial von OPC UA geht deutlich über diese Anwendungsszenarien hinaus. Die Vision ist ein einheitliches Kommunikationsprotokoll für die vertikale Integration bis in kleinste Steuerungen. Derzeit werden die meisten OPC-Server auf Basis von PC-Hardware und einem Windows-Betriebssystem realisiert. Der Server stellt die Daten und Funktionen der SPS über Tags zum Lesen und Schreiben zur Verfügung. MES- oder Scada-Systeme agieren als führende Systeme, das heißt, sie initiieren die Datenkommunikation.

Dagegen sieht ein alternativer Ansatz die SPS als führendes System. Die Firma Beckhoff hat dazu die Funktionen eines OPC-UA-Client als Funktionsbaustein direkt in ihrer Steuerung implementiert. Dieser OPC-UA-Client kann Daten selbstständig an den OPC-Server übermitteln, der mit den Leitsystemen verbunden ist. Da die SPS bedarfs- und ereignisorientiert agieren kann, ist die Datenqualität sowie Effizienz der Kommunikation potenziell deutlich besser als bei pollingbasierten, traditionellen Integrationslösungen. Die Steuerung könnte sich je nach Bedarf zum Beispiel Produktionsaufträge oder andere Daten aus MES und ERP abrufen oder erledigte Aufgaben quittieren.

Rollentausch: Das ERP als OPC-Server

Ein ERP-System kann betriebswirtschaftliche Daten wie Aufträge, Arbeitspläne, Materialien über OPC UA zum Abruf verfügbar machen. Möglich wird dies, indem das ERP als OPC-UA-Server fungiert und HMI/Scada-Systeme diese Daten abrufen und verarbeiten. Vorstellbar ist eine Implementierung mittels Wrapper, der intern bereits existierende Technologien wie BAPI oder Webservices nutzt. Am SAP Research Center Dresden wurde diese Problemstellung bereits thematisiert und prototypisch umgesetzt.

In dessen Test- und Demonstrationsumgebung, dem SAP Research Future Factory Lab, werden im Rahmen der Future- Factory-Initiative unter anderem OPCUA- basierte Integrations-Szenarien im Kontext aktueller Hard- und Software validiert. Die Initiative ist ein gemeinsames Projekt von SAP Research sowie industriellen und akademischen Partnerorganisationen. Ziel ist, die Forschung und Entwicklung im Bereich der Fertigung, Montage und Prozessindustrien zu fördern und daraus innovative Lösungen abzuleiten sowie deren Praxis-Tauglichkeit in einer realitätsnahen Umgebung zu prüfen. Die Future Factory Initiative bildet außerdem einen organisatorischen Rahmen zur Kommunikation zwischen Experten im Bereich der Produktion.

Autoren:
Christian Hengstler ist Entwickler am SAP Research Center Dresden.

Dr. Jochen Rode ist Programm-Manager am SAP Research Center Dresden.