Beim Aufbau der Kommunikation zwischen dem SAP-System eines Unternehmens und seiner Produktionsnetzwerke gibt es stets auch Randbedingungen zu beachten: Welche Software- Umgebungen und welches Knowhow sind vorhanden? Häufig gibt es konzernweite Vorgaben, die eine bestimmte Technik vorschreiben – selbst wenn diese für ein konkretes Projekt nicht die perfekte Lösung ist. Produktionsseitig ist die OPC-Schnittstelle häufig gesetzt, vor allem wenn die entsprechende Infrastruktur mit OPC-Servern und Prozessdatenerfassung bereits vorhanden ist. SAP-seitig stehen dagegen mehr Möglichkeiten zur Disposition – die Schnittstellen BAPI und IDoc oder spezielle SAP-Komponenten.

Die SAP-eigene Kommunikationstechnik, basierend auf der Programmiersprache ABAP (Advanced Business Application Programming), stellt die Schnittstellen BAPI (Business Application Programming Interface) und IDoc (Intermediate Document) bereit, die andere Anwendungen für die Kommunikation mit SAP nutzen können. Daneben gibt es so genannte Konnektoren zur Anbindung von Anwendungen, die kein ABAP „verstehen.“ Dazu zählen beispielsweise Konnektoren für Java oder .NET.

Im OPC-Router können die Datenpunkte des OPC-Servers grafisch den BAPI- Parametern zugeordnet werden.

© Inray Industriesoftware

Die Konnektoren haben einen Nachteil: Bereits während der Entwicklung muss definiert sein, auf welche SAP-Funktionen die Fremdanwendung zugreift. Bei diesem Ansatz bedeutet jede nachträgliche Änderung zusätzlichen Programmieraufwand. Während die Konnektoren Fremdanwendungen den Zugriff auf SAP gestatten, kann das SAP-System auch selbst auf andere Anwendungen zugreifen und via OPC auch mit Steuerungen kommunizieren. Solche Komponenten sind beispielsweise „MII“ (Manufacturing Intelligence und Integration) als Middleware für SAP R/3 oder „NetWeaver Process Integration“ (PI).

Allerdings sprechen die Kosten für Lizenzen und eine eventuelle Programmierung gegen eine reine SAP-Lösung. Dies trifft gerade dann zu, wenn keine SAP-Experten im Unternehmen angestellt sind oder die Produktion bereits über eine Prozessdaten-Aufzeichnung verfügt, deren Inhalte sich einfach ins SAP-System transferieren lassen. Diesen Ansatz nutzt die Firma inray Industriesoftware, die über OPC und die Standardschnittstellen BAPI und IDoc die Kommunikation der Automatisierungstechnik mit SAP-Systemen aufbaut. Zur Anwendung kommen Standard- Lösungen, die teilweise direkt vom Automatisierungsfachmann oder in Verbindung mit der IT-Abteilung projektiert werden können.

So funktioniert BAPI

BAPI ist eine standardisierte Schnittstelle zur Kommunikation zwischen verschiedenen SAP-Systemen (ab Release R/3 3.1) untereinander oder mit Fremdanwendungen. SAP stellt dazu bereits Standard- BAPIs zur Verfügung. Bei Bedarf lassen sich ebenso individuelle Schnittstellen implementieren und ansprechen. Ein BAPI ist immer Bestandteil eines Business- Objekts, das alle Informationen eines Prozesses (zum Beispiel Auftragsnummer und weitere fertigungsrelevante Daten) und deren zugehörigen Operationen (die BAPIs) kapselt. Standard-Business-Objekte wie Fertigungsauftrag, Rückmeldungen und Steuerrezepte enthalten bereits die grundlegenden BAPIs zum Lesen und Schreiben von Daten.

Um BAPIs anzusprechen, nutzt die Firma inray einen OPC-Router, der als Windows-Dienst beliebige OPC-Server und Datenbanken untereinander sowie mit dem SAP-System verbindet – unabhängig von der SAP-Version, sofern diese BAPI unterstützt. Dazu sind dem Router lediglich die OPC-Server und Datenbanken bekannt zu geben und das SAP-Logon-Pad einzurichten. Über eine grafische Oberfläche verbindet der Projekteur dann die OPC-Items mit den Eigenschaften der entsprechenden Business- Objekte und mit den zugehörigen BAPI-Parametern per Drag & Drop. Anschließend ist nur noch die Bedingung zu konfigurieren, die den Datentransfer auslöst. Dieser Trigger kann beispielsweise zeit-, ereignis- oder skriptgesteuert sein. Kommen SAP-seitig ausschließlich Standard-BAPIs zum Einsatz, ist keinerlei Programmierung notwendig. Bei dieser Kommunikationsart liefern die SAP-Funktionen Meldungen an das aufrufende System zurück.

Über das IDoc-Modul des FAS lässt sich die gleiche Übertragungssicherheit erreichen (oben) wie mit OPC-Router in Verbindung mit BAPI.

© Inray Industriesoftware

Der Vorteil dieser Architektur ist die Möglichkeit, das Fehlermonitoring und -handling zu verteilen: Der OPC-Router bietet dazu umfangreiche Logging-Funktionen, die Fehler in der Datenübertragung dokumentieren. Quittiert das SAP-System beispielsweise einen Datentransfer mit einer Fehlermeldung, gibt der OPC-Router diese Meldung direkt an die Steuerung zurück, die dann entsprechende Maßnahmen einleiten kann. Automatisierer und IT-Abteilung können darüber flexibel festlegen, dass jede Fehlerart nur dort aufläuft, wo diese am besten behoben werden kann: im SAP-System oder in der Anlagensteuerung. Jede in die Steuerung zurückgeschriebene Meldung kann auch in der Produktion visualisiert und in der Prozessdatenbank erfasst werden. Von dort lassen sich bei Bedarf die zuständigen Mitarbeiter per Mail, SMS oder Fax benachrichtigen. Bei einer Lösung ausschließlich mit SAP-Komponenten bleibt das Monitoring auf die SAP-Administration beschränkt. Zwar lassen sich SAP-Terminals auch in der Produktion einrichten, um auftretende Fehler vor Ort zu bearbeiten, doch wird für jedes Terminal eine entsprechende Lizenz benötigt. Im Gegensatz dazu kommt die Lösung auf Basis des OPC-Routers mit einer SAP-Lizenz aus, zumal die Anzahl der Datenpunkte und Verbindungen nicht limitiert ist.

Die Funktionsweise von IDoc

Grundsätzlich anders funktioniert die Anbindung über IDocs. Ein Intermediate- Document ist ein speziell formatiertes Textfile, das an das SAP-System gesendet wird beziehungsweise von SAP an andere Anwendungen. Eine direkte Antwort erfolgt im Gegensatz zur BAPI-Kommunikation nicht (asynchrone Kommunikation). Ein Vergleich zeigt den Unterschied: Ähneln BAPIs einem Telefonanruf, sind IDocs Briefe, die zwar im Briefkasten landen, aber ohne Gewähr, ob und wann der Empfänger sie liest. Das Message-Queueing gewährleistet lediglich die Anlieferung des IDocs in SAP. Das SAP-System interpretiert die IDocs und verbucht die Daten. Treten dabei Fehler auf, erkennt das zunächst nur die IT-Abteilung anhand des Ampel-Status (Rot-Gelb-Grün) des IDoc-Eingangs. Die IT-Adminstratoren können die Daten zwar sehen und bearbeiten, eine fachliche Beurteilung können sie jedoch nicht vornehmen. Das Fehlerhandling bleibt bei diesem Ansatz zunächst auf die IT-Abteilung begrenzt. Zudem gibt es keine automatische Rückmeldung an die Maschinensteuerung. Darüber hinaus ist der Personalaufwand für manuelles Monitoring des IDoc-Eingangs hoch.

Kommunikation mit Pausen

Die auf IDoc basierende Kommunikation realisiert inray über den Factory-Application- Server (FAS), ein Entwicklungs- Framework mit Standard-Modulen für Leitsysteme, mit dem aber auch spezielle Lösungen auf MES/SCADA-Ebene realisierbar sind. Der FAS stellt dazu die Kommunikation zwischen OPC-Server und Prozess-Datenbanken bereit. Das IDoc- Modul generiert anhand einer programmierten Logik die IDocs und reiht diese in die Warteschlange einer zusätzlich benötigten nachrichtenorientierten Kommunikationsschicht (beispielsweise IBMWebsphere- MQ) ein. Diese Middleware garantiert die Zustellung der IDocs an das SAP-System. Damit ist die IDoc-Kommunikation gleichermaßen zuverlässig und dezentral zu realisieren wie mit BAPI. Vom SAP-System gesendete IDocs wertet der FAS aus und puffert die Informationen in einer Datenbank, bis ihre Inhalte von der Steuerung oder dem Bediener abgerufen werden. Eine Konfigurationsoberfläche, mit der Anwender die IDocs selbst definieren können, befindet sich in der Entwicklung und wird in den grafischen FAS-Designer integriert.

Auswirkungen in der Praxis

Die unterschiedliche Wirkung einer Kommunikation mit BAPI oder IDoc zeigt das Beispiel einer Produktionslinie: An deren Ende steht eine Verpackungslinie, die fortlaufend Paletten mit fertigen Produkten bereitstellt, die eingelagert werden müssen. Dazu benötigt die Steuerung für jede Palette einen Transportauftrag (Einlagerauftrag), den sie über die Meldung „Fertigungsauftrag abgeschlossen“ beim SAP-System anfordert. Welche Kommunikationsart dafür gewählt werden sollte, bestimmt unter anderem der Automatisierungsgrad (voll- oder halbautomatisch).

Beim vollautomatischen Einlagerungsprozess sollte die Kommunikation zwischen Steuerung und SAP-System über den OPC-Router und BAPI erfolgen: Das SAP-System generiert hier umgehend für jede Palette eine Rückmeldung mit Einlagerauftrag und Lagerort. Die Steuerung lagert die Palette vollautomatisch ein und meldet danach die Ausführung zurück. Bei einer halbautomatischen Einlagerung werden die Paletten zunächst am Ende der Verpackungslinie gesammelt und sukzessive manuell per Gabelstapler oder Hubwagen eingelagert. In diesem Szenario könnte eine Kommunikation über IDocs in Frage kommen, da die Steuerung der Verpackungslinie nicht auf eine Antwort (Einlagerauftrag) aus dem SAP-System angewiesen ist.

Die Maschine meldet den Abschluss des Fertigungsauftrags an den FAS, der das entsprechende IDoc generiert. Nach erfolgter Buchung kann der entsprechende Einlagerauftrag aus dem SAP-System ebenfalls per IDoc im FAS so lange zwischengespeichert werden, bis die zugehörige Palette eingelagert wird. Meldet SAP einen Fehler (Auftrag bereits abgeschlossen oder Überproduktion) gibt es bei der BAPI-Lösung ein Zeitproblem, da kein konkreter Einlagerauftrag vorliegt: Trotzdem muss die Palette zügig abtransportiert werden, um einen Rückstau der Paletten oder einen Produktionsstillstand zu vermeiden.

Und das Fehlerhandling?

Der OPC-Router kann bei solchen Rückmeldungen eine Nachricht (Alarm-Bit) an die Steuerung senden und die umgehende Ausschleusung der Palette anstoßen. Parallel dazu lässt sich die Störung in der Prozessvisualisierung anzeigen und bei Bedarf per Mail, Fax oder SMS an die zuständigen Mitarbeiter melden. Nach der Fehlerbehebung sollte das System die Fehlermeldung automatisch quittieren.

Die Fehlerbehandlung bei IDoc ist unkritischer, da die Reaktionszeit keine Bedeutung hat. Das IDoc kommt im SAP-System zwar an, wird aber nicht verbucht. Die Ampel des IDoc ist jetzt rot und der Mitarbeiter in der IT-Abteilung beginnt mit der Suche nach der Fehlerursache – wahrscheinlich ohne den Fehler in der Produktion fachlich beurteilen zu können. Der Vorteil dieses Verfahrens liegt darin, dass die Steuerung ihre Meldungen an SAP überträgt und sich nicht weiter darum kümmern muss. Der Nachteil: Die Palette muss so lange vor Ort verbleiben, bis der Fehler behoben wurde. Das können unter Umständen mehrere Stunden oder gar Tage sein.

Autor: Hanjo Schlüter ist Technischer Redakteur bei inray Industriesoftware in Schenefeld.