Wer schon einmal sowohl in einem Schaltschrank als auch in einem SAP-System gearbeitet hat, weiß: Diese beiden Welten wurden nicht dafür gebaut, miteinander zu reden. Eine SPS denkt in Millisekunden, Sensorzuständen und sicheren Bewegungen. SAP denkt in Lageraufträgen, Bestandskonsistenz und Belegflüssen. In den meisten Werken wird der Raum dazwischen bis heute von Menschen überbrückt: Jemand liest ein Display ab, geht zum Terminal und tippt etwas ein. Das funktioniert. Aber es ist langsam, und genau dort passieren die Fehler.

In den vergangenen Monaten haben wir ein vollautomatisches Hochregallager an SAP Extended Warehouse Management angebunden. Wird in SAP eine Lageraufgabe angelegt, nimmt ein Regalbediengerät wenige Sekunden später die Palette physisch auf und lagert sie in den zugewiesenen Platz ein. Die Quittierung fließt von selbst zurück ins System. Kein Scanner, kein Abtippen. In diesem Beitrag beschreiben wir, wie der Aufbau funktioniert und was wir dabei gelernt haben.

 

Warum das schwieriger ist, als es klingt

Das technische Problem ist nicht exotisch. Treiber, Protokolle und Middleware gibt es für all das. Die eigentliche Schwierigkeit liegt darin, dass beide Seiten völlig unterschiedliche Annahmen über Zeit und Verlässlichkeit treffen. Auf der Automatisierungsseite arbeitet ein Siemens S7 ihr Programm in einem Zyklus von wenigen Millisekunden ab. Wird eine Lichtschranke unterbrochen, muss das Regalbediengerät sofort stoppen, nicht erst nach einem Datenbank-Commit. Auf der Unternehmensseite denkt SAP EWM in Transaktionen: Eine Warenbewegung hat entweder stattgefunden und ist gebucht, oder sie hat nicht stattgefunden. Beides direkt zu verdrahten wäre selbst dann keine gute Idee, wenn es technisch ginge. Man braucht eine Schicht dazwischen, die übersetzt. Und zwar eine, die man auch nachts um zwei noch debuggen kann, wenn etwas klemmt.

 

Der Aufbau, den wir realisiert haben

Unsere Architektur besteht aus vier Ebenen und entspricht dem, was man auch in einem automatisierten Lager im Produktivmaßstab vorfindet: Ganz unten sitzt eine Siemens S7-1200, die das Regalbediengerät steuert und sämtliche Sensoren einliest. Bewegungsabläufe, Verriegelungen und Fehlerbehandlung liegen hier, weil nur diese Ebene schnell genug dafür ist.

Ihre Daten stellt die SPS über einen OPC-UA-Server bereit, der direkt auf der CPU läuft. Wir haben uns für OPC UA entschieden, weil es herstellerneutral ist und die Daten semantisch beschreibt statt als rohe Speicheradressen. In der Praxis heißt das: Die SAP-Seite abonniert ein Tag namens „PositionErreicht“, statt Byte 42 irgendeines Datenbausteins zu pollen. 

In der Mitte übernimmt SAP Plant Connectivity (PCo) die Übersetzung. PCo verbindet sich per OPC UA mit der Steuerung und per RFC mit SAP. Schickt das Materialflusssystem im EWM ein Telegramm, etwa „Handling Unit auf Platz 2/3 einlagern“, macht PCo daraus Schreibzugriffe auf die Tags der Steuerung. Meldet das Gerät den Abschluss, reicht PCo die Quittierung zurück, und SAP bucht die Bewegung. Ganz oben läuft SAP EWM mit MFS und übernimmt die Geschäftslogik: welcher Lagerplatz verwendet wird, welche Aufgabe Vorrang hat, wie die Bestandssituation aussieht und was zu tun ist, wenn die Anlage ein Problem meldet. Das Ergebnis ist ein geschlossener Kreislauf zwischen physischem Lager und führendem System. Der Bestand in SAP ist nicht das, was jemand am Schichtende gebucht hat. Er ist das, was tatsächlich im Regal steht. Jetzt gerade.

 

Was wir unterwegs gelernt haben

Ein paar Erkenntnisse, die in keinem Architekturdiagramm stehen: Die Telegrammschnittstelle zwischen MFS und SPS ist der Vertrag des gesamten Projekts. Befehle, Quittierungen, Statusworte, Fehlercodes. Früh zusammensetzen, mit beiden Seiten am Tisch definieren und schriftlich festhalten. Jede Stunde, die wir hier investiert haben, hat uns später ein Vielfaches erspart. Fehlercodes verdienen genauso viel Aufmerksamkeit wie der Gutfall. Das Gerät auf Kommando fahren zu lassen, ist ehrlich gesagt der einfache Teil. Ein robuster Betrieb steht und fällt damit, dass die SPS an SAP meldet, warum etwas fehlgeschlagen ist, und zwar in einer Form, auf die SAP reagieren kann. Ein belegter Lagerplatz und ein Antriebsfehler müssen völlig unterschiedliche Reaktionen auslösen. Ebene für Ebene in Betrieb nehmen. OPC-UA-Verbindung, Registrierung des PCo-Agenten am SAP-Gateway, Telegrammverarbeitung im MFS: Jeder dieser Schritte lässt sich einzeln testen. Wer so vorgeht, verwandelt eine einschüchternde Integration in eine Abfolge kleiner, unspektakulärer Schritte. Unspektakulär ist hier genau richtig. Und schließlich: Ein solches Projekt liegt exakt zwischen Automatisierungstechnik und SAP-Beratung. Keine Seite kann es allein stemmen. Beide Disziplinen in einem Team zu haben, idealerweise in einem Raum, hat mehr bewirkt als jede einzelne Werkzeugentscheidung.

 

Wohin das führt

Sobald die Brücke zwischen Shopfloor und ERP steht, wird möglich, was getrennte Systeme schlicht nicht können. Ein- und Auslagerungen, die direkt aus Kundenaufträgen angestoßen werden. Störungen, die den richtigen Ansprechpartner erreichen, während die Palette noch auf dem Gerät steht. Bewegungs- und Zeitdaten, die in die Instandhaltungsplanung einfließen, statt in einer Logdatei zu verschwinden, die niemand liest. Unser Demonstrator ist kompakt, aber das Muster ist dasselbe, das auch große Distributionszentren antreibt. Wenn Sie darüber nachdenken, Ihren eigenen Shopfloor an SAP anzubinden, und die gesamte Kette einmal live sehen möchten, von der Lageraufgabe bis zum fahrenden Regalbediengerät: Kommen Sie vorbei. Wir zeigen es Ihnen gern.