Datentransfer automatisieren, IT-Lücken schließen

Automatischer Datenaustausch zwischen Anlagensteuerungen und SAP-Systemen

Autoren: Andrea Pankrath und Hanjo Schlüter, veröffentlicht in der http://www.sap-port.de/ 6/2008, S. 9., PDF

„Automatisieren“ heißt derzeit das Schlagwort für Software-Entwickler im Industrieeinsatz. Die letzten IT-Lücken sind zu schließen, um endlich durchgängig von der Produktion über das Lager bis in die letzte Büro-Ecke Daten automatisch austauschen zu können. Der Anbindung an SAP-Systeme kommt dabei eine große Bedeutung zu.

Fertigungsaufträge auszudrucken und per Hand in die Produktion zu tragen, Rückmeldungen ebenso entgegenzunehmen, Füllstände oder Verbrauchszähler abzulesen und Daten einzutippen, Ein- und Auslagerungsprozesse auf Papier zu quittieren – all das ist in vielen Betrieben noch gang und gäbe. Der Bürotrakt ist zwar komplett in die ERP-Software eingebunden – die Tür zum Produktionsnetz aber bleibt verschlossen. Dabei stehen auch dort erfasste Daten standardisiert bereit.

Die Standardschnittstelle OPC

OPC – ursprünglich „OLE for Process Control“ – hat sich seit Veröffentlichung der ersten Spezifikation 1996 längst zur Standard-Softwareschnittstelle in der Automatisierungstechnik entwickelt. Hervorgegangen ist OPC aus dem Bestreben der führenden Anlagenbauer weltweit, ihre Geräte herstellerübergreifend problemlos miteinander kommunizieren zu lassen. Die eigens gegründete OPC Foundation wacht heute über die verschiedenen Spezifikationen, ihr gehören mehr als 450 Unternehmen der Branche an. OPC ermöglicht das Auslesen genauso wie das Zurückschreiben in Anlagensteuerungen (SPS) und anderen Feldgeräten und damit die Überwachung der Produktion in Echtzeit, das Archivieren der Daten und den Umgang mit Alarmen und Meldungen aus den Steuerungen. OPC kann Daten auch für die Anforderungen einer ERP-Software zur Verfügung stellen, zum Beispiel zum Verfolgen von Fertigungsaufträgen, produzierten Chargen oder Materialverbräuchen. Während die früheren Spezifikationen, basierend auf Microsofts DCOM, an Windows-Betriebssysteme gebunden blieben, wird die neue OPC Unified Architecture DCOM- und plattformunabhängig arbeiten.

In der Praxis werden Anlagensteuerungen, Sensoren, Zähler und andere Geräte an einen so genannten OPC-Server angebunden. Die Aufgaben dieses Servers brauchen nicht auf die produktionsinterne Kommunikation beschränkt zu bleiben. Er kann genauso gut als Gateway zur IT-Welt der Büros dienen, das einerseits Daten bereithält, andererseits aber das Produktionsnetz gegen unbefugte Zugriffe absichert. Die Kommunikation erfolgt oft über Ethernet und TCP/IP.

Prozessdaten sichtbar machen

Vielfach nutzen Produktionsleiter die Möglichkeit, über OPC erfassten Daten mit spezieller Software zu visualisieren. Die gängigen Systeme setzen dabei auf Webtechnologie: HTML-Seiten stellen Produktionszustände und erfasste Daten in Echtzeit dar. Die Aufzeichnung der Daten, z. B. in einer SQL-Datenbank, ermöglicht dann, umfangreiche Historien zu erstellen, Verbräuche zu analysieren oder die Maschinenauslastung zu ermitteln (KPI). Kontinuierliche Erfassung von Energie- oder Wasserverbrauch und anschließender Periodenvergleich helfen, Einsparpotenziale zu finden. Alarme und Störzeiten können kategorisiert werden; Gutteile, Ausschuss und Nacharbeit der Produktion sind auszuwerten.

Diese Datenerfassung zu automatisieren, ist derzeit das Bestreben vieler Betriebe. So lässt sich nicht nur viel Arbeitszeit für die Erfassung sparen, auch die Fehlerquote wird geringer – und letztlich sind gerade viele Verbrauchsanalysen nur durch kontinuierliche Messung möglich.

Transfer ins SAP-System

Wenn solche Daten dann bereits elektronisch vorliegen, bietet sich der Transfer in die Bürowelt geradezu an, um damit weiterzuarbeiten oder sie im Controlling zu nutzen. Eine SAP-eigene Lösung bietet die „NetWeaver“-Komponente „Exchange Infrastructure“, mit der über eine grafische Oberfläche OPC-Server angesprochen werden. Ebenfalls am Markt erhältlich sind Hardware-Lösungen, die zwischen SPS und SAP-System geschaltet werden. Wer bereits bestehende Systeme in Produktion und Büro miteinander verbinden will, kann auch eine schmale Router-Software optimal einsetzen. Hierbei werden die Daten mithilfe von BAPIs (Business Application Programming Interfaces), die als Schnittstellen einen SAP-Standard darstellen, an die zugehörigen Businessobjekte im SAP-System weitergeleitet.

Letztlich stehen mit OPC und BAPI zwei standardisierte Schnittstellen zur Verfügung, die einen kontinuierlichen Datenfluss ermöglichen. Ein OPC-Item oder -Datenpunkt liefert ein bestimmtes Datum zu einem bestimmten Zeitpunkt. Dieses Datum wird über OPC-Schnittstelle, Router-Software und BAPI in die entsprechende Eigenschaft des Businessobjekts geschrieben. Dies könnte zum Beispiel die produzierte Stückzahl zu einem Fertigungsauftrag sein. Oder der erfasste Füllstand eines Tanks.

Das Zusammenspiel kann aber auch ausgefeilter sein, wie ein halbautomatisiertes Warenlager zeigt: Eine beladene Palette wird an einem Wiegepunkt automatisch vermessen, die Daten werden von der Steuerung ins SAP-System übertragen. Die entsprechende Funktionalität im SAP-System prüft die Daten, bucht die Mengen und legt aufgrund einer vorgegebenen Logik den Lagerort fest. Wenn der zugehörige Transportauftrag im SAP-System erfolgreich angelegt werden konnte, wird diese Information gemeinsam mit dem Ziellagerort an die Steuerung zurückgegeben, die die Palette zur richtigen Gasse fährt. Im realisierten Beispiel erfolgt der letzte Schritt der Einlagerung dann per Stapler. SAP stellt eine Reihe von Standard-Business-Objekten mit entsprechenden BAPIs bereit. Werden diese genutzt, so ist für die Datenübertragung keine Programmierung nötig. Der Router wird grafisch konfiguriert, nach Bekanntgabe des OPC-Servers und der benötigten Businessobjekte werden die OPC-Items mit den BAPI-Parametern per Drag & Drop verbunden. Trigger lösen die Datenübertragung zyklisch, änderungsbasiert, ereignis- oder skriptgesteuert aus.

Selbstverständlich kann ein Router genauso gut individuell programmierte Funktionsbausteine ansprechen. Programmierung innerhalb des SAP-Systems ist nur dann notwendig, wenn „neue“, also bisher in SAP nicht genutzte Daten, zu verarbeiten oder neue Geschäftslogiken zu implementieren sind.

Fehlerhandling

Egal, ob eine Software- oder Hardware-Lösung den Datenaustausch organisiert – wichtig ist immer, einen Blick aufs Fehlerhandling der möglichen Lösung zu werfen: Was passiert, wenn ein OPC-Datenpunkt nicht erreichbar ist? Wenn der zurückgelieferte Wert ungültig ist? Wenn es einen logischen Fehler gibt – zum Beispiel eine Rückmeldung zu einem nicht existenten Transportauftrag? Zu klären ist vor allem die Frage, welche Fehler außerhalb des SAP-Systems abgefangen werden und welche Konsistenz-Prüfung die BAPIs vornehmen oder vornehmen müssten.

BAPIs und Businessobjekte

Wer auf die beschriebene Art Daten zwischen SAP- und anderen Systemen austauscht, macht sich den objektorientierten Ansatz zu Nutze, dessen Anwendung sich leider nur langsam durchsetzt. Businessobjekte entsprechen bestimmten Objekten in der Geschäftslogik eines Unternehmens. Diese kapseln Daten als Eigenschaften, die sich in den entsprechenden Datensätzen in den SAP-internen Tabellen wieder finden. So kann ein Business-Objekt zum Beispiel ein Fertigungsauftrag sein, der unter anderem eine Fertigungsauftragsnummer zur Identifizierung enthält, sowie eine Reihe von weiteren Eigenschaften wie Materialnummer, Sollmenge mit zugehöriger Mengeneinheit, Gutteile, Fehlteile, Nacharbeitsteile, Produktionsstart- und -endzeitpunkt und dergleichen. Dieser Teil stellt den innersten Kern des Businessobjekts dar. Weiter enthält das Businessobjekt Geschäftsregeln, die in der Integritätsschicht seine betriebswirtschaftliche Logik festlegen. In der Schnittstellenschicht werden externe Struktur und externer Zugriff implementiert. Dazu gehören Attribute, die bestimmte Eigenschaften eines bestimmten Businessobjekts darstellen und zugreifbar machen, sowie BAPIs, mit denen man spezielle Businessobjekte erzeugen, verändern oder einfach auslesen kann. BAPIs beschreiben somit das Verhalten von Businessobjekten.

Businessobjekte gehören zum Konzept der ABAP Objects, der objektorientierten Erweiterung der bisherigen ABAP-Skriptsprache. ABAP Objects setzt viele Konzepte aus dem Bereich der objektorientierten Software-Entwicklung um, zum Beispiel Polymorphie (verschiedene Sichten auf ein Objekt) und Vererbung. Polymorphie bedeutet, dass ein Objekt mehrere Schnittstellen implementieren kann. Dadurch ist es möglich, einem Objekt verschiedene Rollen zuzuteilen, also verschiedene Sichten auf ein Objekt dazustellen. Ein Produktionsgut kann beispielsweise sowohl ein fertiges Produkt – mit entsprechender Schnittstelle – sein oder auch ein Material im weiteren Verbrauchsprozess. Die Schnittstellen präsentieren die verschiedenen Rollen. Diese Unterschiede können selbstverständlich auch in der Kommunikation mit der Produktion flexibel und effizient genutzt werden.

In ABAP Objects können alle bisher vorhandenen Sprachelemente und Modularisierungseinheiten wiederverwendet werden, ebenso können bestehende ABAP-Programme auch Businessobjekte verwenden.

Von Funktionsgruppen zu ABAP Objects

Die Hauptaufgabe von BAPIs besteht darin, RFCs (remote aufrufbare Funktionsbausteine) aufzurufen und mit ihnen Daten auszutauschen. Die Funktionsbausteine sind in Funktionsgruppen zusammengefasst. Der große Vorteil der Businessobjekte ist die Möglichkeit, zur Laufzeit mehrere Instanzen eines Objekts zu erstellen, während von einer Funktionsgruppe jeweils nur eine Instanz erzeugt werden kann.

Da man mit Hilfe von Referenzen den Kontext beziehungsweise die zu verwendenden Businessobjektinstanzen programmiertechnisch selbst bestimmen kann, ist es möglich, mit globalen Daten zu arbeiten. Globale Zähler sind ein Beispiel dafür. Werden dagegen nur Funktionsgruppen verwendet, arbeitet jeder Benutzer mit einer Kopie der benötigten Daten. Die Daten konsistent zu halten, wird dann schwierig.

Der OPC Router der inray Industriesoftware funktioniert in der beschriebenen Weise. Er wird als User – nicht zwangsweise als Dialog User – im SAP-System angemeldet. Das LogOn-Pad ist auf dem entsprechenden Rechner Voraussetzung. Ein Limit in der Anzahl der Datenpunkte und Verbindungen gibt es nicht. (ap)