Was ist ISA-95? Fünf Ebenen, IEC 62264 und die Automatisierungspyramide

Die Pyramide ordnet einen Betrieb von unten nach oben. Jede Ebene hat eine eigene Aufgabe, einen eigenen Zeittakt und typische Systeme. Ihre Ebenen tragen Namen; eine verbindliche Nummerierung gibt es nicht.

Ein Prozessleitsystem (DCS) passt in keine einzelne Zeile: In der Automatisierungspyramide spannt ein Prozessleitsystem über Steuerungs- und Prozessleitebene. ISA führt es in seiner Beschreibung als Ganzes unter Level 2. Mehr dazu in Was ist ein Prozessleitsystem (DCS)?

Die Ebenen trennt dabei vor allem ihr Zeittakt, weniger die Software. Eine Steuerung antwortet in Millisekunden, weil ein Antrieb sonst gegen einen Anschlag fährt. Ein ERP plant in Wochen, weil eine Materialdisposition Lieferzeiten abwarten muss. Zwischen beiden liegen rund neun Größenordnungen. Jede Anbindung zwischen Fertigung und Unternehmens-IT muss diesen Unterschied überbrücken. Das Problem entsteht dort, wo das ERP eine Steuerung direkt abfragt, ohne Puffer und ohne Quittung dazwischen.

Planungshorizont ist nicht Datenalter

Die Angabe in der letzten Zeile beschreibt den Planungshorizont. Sie wurde lange auch als Datenalter gelesen: Was im ERP steht, darf Tage alt sein, weil ohnehin erst zum Monatsende abgerechnet wird. Das ist überholt. Viele Betriebe, mit denen wir arbeiten, verlangen einen Blick in die laufende Fertigung, mindestens auf Auftragsebene: welcher Auftrag gerade auf welcher Anlage läuft und wann er fertig wird. Lagerbuchungen sollen stehen, wenn die Palette steht, und nicht erst über Nacht laufen.

Der Grund liegt in der Logistik. In unseren Projekten wird Fertigung zunehmend just in time geplant und immer weniger gegen ein lokales Lager. Wo ein Puffer im Regal steht, verzeiht er einen Tag Verzug in den Daten. Wo er fehlt, wird aus einer veralteten Bestandszahl eine Fehlmenge in der nächsten Schicht. Damit ändert sich nicht der Zeittakt der Planung, sondern die geforderte Aktualität der Daten. Laufende Aufträge im ERP setzen voraus, dass die Fertigung dort angezapft wird, wo sie stattfindet.

Die Automatisierungspyramide ist ein didaktisches Bild aus dem deutschsprachigen Raum. Sie erklärt anschaulich, wie ein Betrieb geschichtet ist, und ist so verbreitet, weil sie leicht zu vermitteln ist. Eine Norm ist sie nicht. Eine verbindliche Definition ihrer Ebenen gibt es ebenso wenig: In der Literatur finden sich Darstellungen mit vier, fünf und sechs Ebenen, und keine davon ist falscher als die andere.

ISA-95 ist eine Norm der International Society of Automation, international geführt als IEC 62264. Teil 1 trägt den Titel Enterprise-control system integration – Part 1: Models and terminology. Sie legt Modelle und Begriffe fest, damit ein MES-Hersteller, ein ERP-Hersteller und ein Systemintegrator dieselbe Sache gleich benennen. Was ein Arbeitsgang ist, muss dann nicht in jedem Projekt neu geklärt werden.

Ihre funktionale Hierarchie hat die Ebenen Level 0 bis Level 4. Die Norm definiert sie über Funktionen; welche Systeme dort typischerweise stehen, beschreibt ISA auf seiner Standardseite:

Oben stimmen beide überein. Unten ist die Pyramide um eine Ebene verschoben und teilt ISAs Level 2 in zwei. Wo SCADA steht, ist deshalb eine Frage der Quelle: ISA führt es in seiner Beschreibung unter Level 3, verbreitete Darstellungen nach dem Purdue-Modell unter Level 2. Das HMI kommt bei ISA nicht vor. Die Anlagenhierarchie, die zweite Fünferteilung der Norm, zeigt die Pyramide gar nicht.

Die Pyramide zeigt, wo etwas steht. Die Norm legt fest, wie darüber gesprochen wird.

Man kann das eine auf das andere abbilden, wie in der Tabelle oben. Austauschbar sind sie nicht, und eine Ebenenzahl ist nur zusammen mit ihrem Modell eindeutig.

Ja. ISA-95 ist die Nummer, unter der die International Society of Automation (ISA) die Norm herausgibt; IEC 62264 ist die Nummer, unter der die IEC sie führt. Gemeint ist dasselbe Regelwerk. In Ausschreibungen und Lastenheften begegnen Ihnen beide Schreibweisen, gelegentlich im selben Absatz. Auch ANSI/ISA-95 und die Kurzformen S95 oder SP95 bezeichnen dasselbe Regelwerk.

In der Zählung der ISA hat ISA-95 acht Teile. Teil 2 legt die Objekte und Attribute für den Austausch zwischen Level 4 und Level 3 fest, Teil 3 die Aktivitätsmodelle der Betriebsführung auf Level 3 und Teil 4 die Objekte und Attribute, die zwischen diesen Aktivitäten ausgetauscht werden. Die Teile 6 bis 8 regeln Dienste für den Nachrichtenaustausch, Aliasnamen und Austauschprofile.

Für ein Integrationsprojekt ist vor allem Teil 5 interessant, Business-to-Manufacturing Transactions: Er beschreibt die Transaktionen zwischen Anwendungen auf Level 4 und Level 3, also welche Nachricht zwischen Unternehmens-IT und Betriebsführung überhaupt vorgesehen ist. Für den Austausch dieser Nachrichten gibt es B2MML, eine offene XML-Umsetzung der ISA-95-Modelle, herausgegeben von der MESA International. Die OPC Foundation nennt B2MML die De-facto-Standardschnittstelle für die Inhalte, die ISA-95 festlegt.

Eine Nachbarnorm der ISA ist ISA-88, die Norm für die Chargensteuerung, also für Rezepte und den Ablauf einer Charge. Sie beantwortet eine andere Frage als ISA-95; wie beide zusammenspielen, beschreibt die ISA in einem eigenen technischen Bericht.

ISA-95 enthält zwei verschiedene Fünferteilungen. Beide haben fünf Stufen, beide heißen umgangssprachlich „die Ebenen“. Werden sie verwechselt, reden die Beteiligten eines Projekts aneinander vorbei, ohne es zu bemerken.

Die eine ist die funktionale Hierarchie, Level 0 bis 4, die in der Tabelle oben der Pyramide gegenübersteht; unten zählen beide verschieden. Sie ordnet Systeme nach ihrer Aufgabe.

Die andere ist die Anlagenhierarchie. Sie ordnet Orte und Dinge:

ISA-95 gilt für Stückgutfertigung, Prozessindustrie und Logistik. Linie und Maschine sind deshalb Beispiele aus der Stückgutfertigung, keine Definition der beiden unteren Stufen.

Diese zweite Teilung ist die praktisch wichtigere, sobald Daten strukturiert werden. Ein Namensraum für Produktionsdaten baut typischerweise auf ihr auf, nicht auf den Levels 0 bis 4. Eine Temperatur gehört zu einer Maschine, die zu einer Linie gehört, die in einem Bereich eines Werks steht. Dass der Sensor in ISA-95 auf Level 1 sitzt und das auswertende System auf Level 3, spielt für die Benennung keine Rolle.

Level 3 heißt in ISA-95 Manufacturing Operations Management (MOM); in der Pyramide entspricht ihm die Betriebsleitebene. Typisch ist hier ein MES, ein Manufacturing Execution System; nach ISAs Beschreibung steht hier auch SCADA. Das ISA-95-Objektmodell der OPC Foundation (OPC 10030) nennt zusätzlich Batch-Systeme und Historians. Auf Level 3 werden Aufträge in Arbeitsgänge zerlegt, Chargen verfolgt, Qualitätsdaten erfasst, Personal und Material zugeordnet und Rückmeldungen an die Planung gegeben.

Um Level 3 wird in Projekten gestritten, weil die Ebene von zwei Seiten beansprucht wird. Ein ERP-Hersteller sieht Auftragsfeinplanung als seine Aufgabe, ein MES-Hersteller ebenso, und beide haben gute Argumente. Wo die Grenze verläuft, ist eine organisatorische Frage und keine technische: Sie hängt daran, wer im Unternehmen den Fertigungsplan verantwortet. ISA-95 gibt dafür die Begriffe, die Antwort gibt es nicht vor.

Muss Level 3 ein MES sein?

Nein. Die Norm beschreibt Aufgaben, kein Produkt: Aufträge zerlegen, Chargen verfolgen, zurückmelden. Welches System das erledigt, legt sie nicht fest. Üblich sind drei Wege, die sich nicht ausschließen: ein vollständiges MES; nur die benötigten Funktionen, selbst gebaut, etwa auf einer No-Code-Plattform wie manubes; oder kein eigenes System auf Level 3. Dann übernimmt ein Datenvermittler den Datenweg: Er holt die Werte aus der Fertigung, übersetzt sie und übergibt sie dem ERP. Wann welcher Weg passt, behandelt Was ist ein MES?

Ist Level 3 nicht als eigenes System besetzt, muss das ERP seine Daten woanders holen. Naheliegend ist dann die Prozessleitebene: Dort liegen die Werte, und dort werden sie ohnehin schon erfasst.

Die Ebenen sind dann nützlich, wenn klar ist, welche Frage auf welcher beantwortet wird. Diese drei Systeme lassen sich leicht verwechseln:

Die drei unterscheiden sich vor allem im Bezug, weniger in der Datenmenge. Das SCADA zeigt, dass Ofen 3 auf 180 Grad läuft. Das MES ordnet diese 180 Grad der Charge 4711 zu. Das ERP führt Charge 4711 unter einem Auftrag über 5.000 Stück, der am Freitag fällig ist. Jede Ebene hängt einen Bezug an, den die darunter nicht führt.

In der Praxis überlappen sich die drei, und viele Systeme haben Funktionen der Nachbarebene dazubekommen. Die Zuordnung bleibt trotzdem nützlich: Sie legt fest, welches System bei einem Widerspruch zwischen zwei Zahlen gilt.

Ausführlich je Begriff: Was ist SCADA? · Was ist ein MES?

Als Erklärmodell ja. Als Beschreibung tatsächlicher Datenwege immer seltener.

Das lässt sich an Anwenderberichten zeigen. Bei einem Hersteller von Wachstechnologie hatte der Integrator ZewaTec laut Anwenderbericht (opc-router.de, Juli 2023) zunächst zwei Siemens-Systeme und ein Yokogawa-Leitsystem über einen Verbund mehrerer Teillösungen an SAP angebunden und dafür rund 20.000 Zeilen Code geschrieben. Die vielen Lizenzen für Standardsoftware machten den Verbund teuer, und der Datentransfer stockte, sobald eine der Lösungen nicht mehr lief. Grafisch konfigurierte Verbindungen im OPC Router lösten schließlich über 90 Prozent der Programmierung ab.

Ein Etikettenhersteller hat laut Anwenderbericht eine direkte Strecke zwischen SPS und SAP aufgebaut: Das ERP sendet Rezeptur und Produktionsgeschwindigkeit an die Maschinen, und die Maschinen melden Fehlstellen mit der Rollennummer zurück. Der Bericht nennt rund 15.000 Datentelegramme pro Tag bei Verbuchungszeiten unter 15 Millisekunden, ohne zu sagen, wann gemessen wurde; die Firmenzahlen auf derselben Seite stammen aus dem Geschäftsjahr 2017. Ein Folienhersteller vernetzte laut Anwenderbericht 50 Maschinen an drei Standorten von der Steuerungs- und Sensorebene bis ins SAP; in Betrieb gingen die Systeme Anfang 2019.

In unseren Projekten reicht der übliche Fall weniger tief: Das ERP spricht häufig mit der Prozessleitebene, also mit HMI und SCADA, und teilweise direkt mit der Steuerung. Die Beispiele oben reichen bis auf die Steuerung hinunter, das erste zusätzlich auf ein Leitsystem. Die tiefe Variante kommt vor, ist aber nicht die Regel.

Beide Wege überspringen Ebenen, die das Modell vorsieht. Die Pyramide ist deshalb nicht falsch: Sie beschreibt die Zuständigkeiten weiterhin richtig, nur nicht mehr den Weg, den die Daten nehmen.

Warum die Ebenen als Datenweg nicht mehr tragen

Solange jede Ebene die nächste bedient, ist jede Verbindung ein eigenes Projekt mit eigener Abstimmung, eigener Wartung und eigenem Ansprechpartner. Kommen auf der Fertigungsseite zehn Maschinentypen und auf der IT-Seite fünf Systeme zusammen, sind das fünfzig mögliche Punkt-zu-Punkt-Verbindungen, und jede davon kann brechen, wenn auf einer der beiden Seiten eine Version wechselt.

Dazu kommt ein Verlust, der schwerer wiegt als der Aufwand: Kontext geht auf dem Weg nach oben verloren. Was an der Steuerung noch „Temperatur an Extruder 3, Auftrag 4711, Charge B“ war, kommt im ERP als Zahlenreihe an. Welche Formen das annimmt, steht im übernächsten Abschnitt.

Und der Weg ist einbahnig gedacht. Daten steigen nach oben, Befehle steigen nach unten. Ein Betrieb, der aus dem ERP heraus eine Rezeptur an eine Maschine schickt und im selben Takt die Rückmeldung erwartet, passt in dieses Bild nicht mehr hinein.

Nein, er verschiebt ihre Rolle. In einem Unified Namespace veröffentlichen alle Systeme ihre Daten in einen gemeinsamen Namensraum, statt sie von Ebene zu Ebene weiterzureichen. Geordnet ist dieser Namensraum typischerweise nach der Anlagenhierarchie aus ISA-95, etwa Unternehmen, Werk, Bereich, Linie, Maschine; die Levels 0 bis 4 tauchen darin nicht auf. Steuerung bleibt Steuerung, MES bleibt MES, nur die Rolle als Datenkurier entfällt. Wie Daten in einen solchen Namensraum hinein- und wieder herauskommen, zeigt Unified Namespace anbinden.

Ein ERP ruft auf und wartet, eine Steuerung antwortet im Zyklus. Beide arbeiten mit verschiedenen Zeitmaßen, und ein Datensatz ist auf beiden Seiten etwas anderes. Die Fehler, die daraus an der Grenze entstehen, lassen sich nicht wegkonfigurieren, aber behandeln, und ein Teil davon bleibt immer beim Betrieb.

Die Zeitschere: oben abgebrochen, unten weitergelaufen

Ein ERP ruft eine Funktion auf, die in der Fertigung etwas auslöst, und wartet auf das Ergebnis. Läuft seine Zeitgrenze ab, bevor unten alles fertig ist, endet der Aufruf, der Ablauf in der Fertigung aber nicht. Er läuft weiter und schreibt sein Ergebnis an eine Stelle, die niemand mehr liest.

Die Ursache: Jede Ebene hat ihre eigene Uhr und ihre eigene Abbruchgrenze, und über die Grenze hinweg gibt es keine Transaktionsklammer. Ein Timeout oben sagt, wie lange ein Aufrufer wartet. Es ist keine Anweisung nach unten, etwas zu unterlassen. Zur Gegenstelle gelangt keine Meldung über den Zeitablauf.

Woran man es merkt: Ein Auftrag, den das ERP als fehlgeschlagen führt und der an der Anlage trotzdem gefahren wurde. Doppelte Chargen, weil jemand nach der Fehlermeldung von Hand nachgestartet hat. Rückmeldungen, die zu keinem Vorgang passen.

Was beim Betrieb liegt: Den Ausgang auswerten. Eine Middleware kann ihn melden, aber ohne ein Programm, das den Rückgabewert abfragt, bleibt die Meldung folgenlos. Dazu die Grundfrage, ob überhaupt synchron aufgerufen wird: eine Architekturentscheidung, keine Einstellung nebenbei. Und die Zeitgrenze selbst. Im voreingestellten Hosting-Prozess des OPC Router greift zusätzlich eine feste Grenze von 60 Sekunden für die interne Übergabe. Liegt die eigene darunter, sieht SAP eine normale Rückkehr mit unbelegten Exportparametern, also gerade keinen Fehler. Nach unten gilt dasselbe spiegelbildlich: Bleibt die Quittung an die Steuerung aus, muss das SPS-Programm das bemerken und erneut senden.

Im OPC Router: Er kann den Ausgang an beide Seiten zurückmelden, über einen Rückgabewert statt über einen Abbruch. Ankommen kann der Rückgabewert nur, wo noch jemand wartet, und auswerten muss ihn die Gegenseite selbst. Am SAP-RFC-Trigger gibt er nach jedem Transfer den Parameter „TRANSFER_OK“ zurück und unterscheidet damit Erfolg, Abbruch und Fehler; zum Fehlerfall steht im Handbuch dabei, dass die Anfrage später erneut zu senden ist und nicht als abgeschlossen gelten darf. Die Schere entsteht nicht, wenn SAP nicht wartet: Schickt SAP ein IDoc, quittiert der OPC Router den Empfang sofort, und über diesen Aufruf geht kein Ergebnis zurück. Ist am IDoc-Trigger die IDoc-Quittierung eingeschaltet, schreibt der OPC Router das Transferergebnis anschließend als Statussatz dieses IDocs nach SAP zurück, zum Beispiel Status 12 bei Erfolg und 11 bei Fehler. Nach unten gibt es für zusammengehörende Werte einen Handshake über den Bit- oder Message-Trigger: Die Steuerung schreibt die Werte und setzt zuletzt den Trigger, der OPC Router wartet einen zusätzlichen Lesezyklus ab, liest und quittiert über einen Antwort-Datenpunkt, bei fehlerhaftem Transfer über ein Fehlerbit, sofern beides am Trigger eingestellt ist. Ob die Werte zusammenpassen, hängt daran, dass die Steuerung den Trigger wirklich als letztes Signal schreibt. Das Handbuch empfiehlt, den Bit-Trigger immer mit Antwortbit zu betreiben: Ändert sich der Trigger innerhalb eines Lesezyklus zweimal, bleibt der zweite Transfer aus und mit ihm die Antwort; auf dieses Ausbleiben muss die Steuerung reagieren. Für den Message-Trigger empfiehlt das Handbuch, den Triggerwert aufzuzeichnen; daran lässt sich nachverfolgen, ob Datensätze nicht oder doppelt übertragen wurden.

Was er nicht tut: den Ablauf unten abbrechen, wenn oben die Zeit abläuft. Der Flow läuft weiter. Für diesen Fall ist der asynchrone Weg über das IDoc gedacht.

Die Gültigkeit eines Werts überlebt die Ebenengrenze nicht

Sobald ein Wert über OPC gelesen wird, trägt er eine zweite Angabe mit sich: seine Qualität. Sie sagt, ob es ein echter aktueller Messwert ist, der letzte bekannte Wert einer abgerissenen Verbindung, ein Wert außerhalb der Sensorgenauigkeit oder ein von Hand erzwungener Wert.

Wandert derselbe Wert in eine Datenbankspalte, ein JSON-Feld oder ein ERP-Feld, gibt es für diese zweite Angabe von Haus aus keinen Platz, solange niemand ihn anlegt. Oben steht eine Zahl, die aussieht wie jede andere.

Die Ursache: OPC überträgt Wert und Status als Paar, die Zielsysteme der oberen Ebenen kennen von sich aus nur den Wert. An der Grenze bleibt deshalb nur die Wahl zwischen zwei Verlusten. Entweder der Status fällt weg, dann steht ein erzwungener oder veralteter Wert oben als gewöhnliche Messung. Oder es wird gefiltert, dann verschwinden die betroffenen Werte still, und in der Ebene darüber erscheint keine Störung, sondern eine Lücke, die sich von „nichts passiert“ nicht unterscheiden lässt. Ein Filter kann durchlassen oder verwerfen, den Grund gibt er nicht weiter.

Woran man es merkt: Eine Kennzahl, die über Tage exakt gleich bleibt, obwohl die Anlage läuft. Ein defekter Sensor, dessen letzter Wert weiter in den Monatsbericht läuft. Die Gegenprobe ist einfach: Derselbe Datenpunkt zeigt im Leitsystem eine Störungsfarbe und im Dashboard eine unauffällige Zahl.

Was beim Betrieb liegt: Oben Platz schaffen. Eine zusätzliche Spalte in der Tabelle, ein Feld im JSON, ein Z-Feld im ERP. Dazu eine fachliche Festlegung, die keine Einstellung ist: Zählt ein Wert, den ein Sensor außerhalb seiner Genauigkeit geliefert hat, als Messung oder als Lücke? Und die Auswertung muss die neue Angabe lesen. Ein Bericht, der die Qualitätsspalte ignoriert, zeigt erzwungene und veraltete Werte weiter als gewöhnliche Messung.

Im OPC Router: Hier ist die Qualität ein eigener Wert neben dem Messwert. Sie lässt sich als Text (Quality-String) oder als Zahl (Quality-ID) ausgeben und wie jeder andere Wert verknüpfen, also auch in eine eigene Datenbankspalte schreiben; eingestellt wird das am Trigger über „Metadaten ausgeben“. Die Unterscheidungen von oben tragen benannte Werte: „goodLocalOverride“ für einen erzwungenen, „badLastKnownValue“ für einen eingefrorenen Wert. Zwei Optionen zielen auf die beiden Symptome: „Triggern bei Quality-Änderung“ überträgt auch dann, wenn sich nur die Qualität ändert und der Wert gleich bleibt, und der Data-Change-Missing-Trigger löst aus, wenn sich ein Datenpunkt innerhalb eines Prüfzeitraums nicht ändert. Damit wird aus der stillen Lücke ein Ereignis.

Filtern kann der OPC Router ebenfalls. Im OPC-Plug-in legt „Erlaubte Qualities von Werten“ fest, welche Zustände überhaupt verarbeitet werden. Was die Einstellung ausschließt, wird ignoriert. Deshalb gehört die Überwachung auf ausbleibende Werte dazu, und ihr Prüfzeitraum ist eine fachliche Größe: Ein Füllstand, der sich eine Stunde nicht ändert, ist normal. Eine Drehzahl nicht.

Ein Zeitstempel, der oben gesetzt wird, misst den Transportweg

Wird der Zeitstempel eines Produktionswerts erst dort vergeben, wo der Wert ankommt, statt dort, wo er entsteht, fällt das nicht auf, solange nichts stockt.

Sobald irgendetwas puffert, bündelt oder nachliefert, rückt eine ganze Reihe von Werten auf nahezu denselben Zeitpunkt zusammen. Im Grenzfall so dicht, dass Datensätze einander überschreiben.

Die Ursache: Jede Ebenengrenze hat eine eigene Laufzeit, und die ist nicht konstant. Verschärft wird es von den Mechanismen, die die Lücke schließen sollen: Eine Nachlieferung läuft parallel zum Livebetrieb und damit nicht in der ursprünglichen Reihenfolge. Wo nur die Ankunftszeit festgehalten wird, ist die Reihenfolge, in der die Dinge im Werk passiert sind, danach nicht mehr rekonstruierbar.

Die Abhilfe kostet wenig, muss aber vorher entschieden werden: Jeder Datensatz führt seinen eigenen Zeitstempel mit, vergeben dort, wo der Wert entsteht. Wird das nachträglich eingebaut, fehlt es für die Historie davor.

Was beim Betrieb liegt: Eine Entstehungszeit mitführen kann nur eine Quelle, die eine hat. Entweder der OPC-Server führt sie selbst, oder die Steuerung schreibt sie in einen eigenen Datenpunkt, zusammen mit den übrigen Werten eines Datensatzes. Erfinden kann eine Middleware sie nicht. Am Ziel braucht die Zeit eine Spalte, und die Auswertung muss sie benutzen: Eine Tabelle, deren einzige Zeitangabe der Einfügezeitpunkt ist, misst weiter den Transportweg. Wird nach einer Unterbrechung nachgeliefert, ist auch festzulegen, wohin nicht: Eine Visualisierung, die nur den aktuellen Stand zeigt, bekäme sonst veraltete Werte geschrieben.

Im OPC Router: Ob der Zeitstempel die Entstehung oder die Ankunft misst, ist hier eine Auswahl. Beim Lesen übernimmt er den Value-Timestamp vom Quell-Server, beim Schreiben lässt er sich vorgeben, ausdrücklich für den Fall, dass der Wert aus einer Historie stammt. Beim Schreiben in eine Zeitreihendatenbank steht die Zeitstempelquelle zur Wahl: die Zeit des Empfängers, die Zeit des Routers oder ein selbst mitgegebener Zeitstempel. Das Handbuch rät von der Empfängerzeit ab, sobald gebündelt geschrieben wird, und nennt dafür denselben Schaden wie oben: Werte, die die Datenbank in derselben Nanosekunde verarbeitet, werden zusammengefasst.

Was er nicht tut, steht im Handbuch. Eine Nachlieferung läuft parallel zum Livebetrieb; nachgereichte und aktuelle Werte werden ausdrücklich nicht zwingend in ihrer ursprünglichen Reihenfolge übertragen. Die Reihenfolge der Übertragung stellt der Router damit nicht wieder her. Rekonstruierbar wird sie über den mitgeführten Zeitstempel, nicht über die Ankunft. Und nachgeliefert wird nur, wo Store and Forward eingeschaltet ist und das Transferobjekt es unterstützt. Unterstützt wird es in der Regel an allen Transferobjekten am Ende eines Flows, also auch an den SAP-Transferobjekten; ob ein bestimmtes es unterstützt, zeigt nach dem Einschalten das Store-and-Forward-Symbol. Am SAP-IDoc-Transferobjekt kommt die IDoc-Queue hinzu: Nicht versendbare IDocs werden dort zwischengespeichert. Unabhängig vom Ziel gibt es den Transferstatus-Trigger: Kommen die Datensätze aus einer Datenbanktabelle, markiert er jeden nach dem Transfer als transferiert oder fehlgeschlagen, und fehlgeschlagene lassen sich über einen Zähler wiederholen. Weitere Versuche gibt es auch ohne Store and Forward: Ein Try/Catch-Transferobjekt führt den umschlossenen Teil des Flows bis zu viermal erneut aus, auch was davon schon erfolgreich war. Das Handbuch rät deshalb, die Wiederholung nur für Abläufe einzuschalten, die mehrfach laufen dürfen.

Steuerungen sprechen Feldprotokolle und legen Werte in Registern ab, ERP-Systeme arbeiten mit Geschäftsobjekten und Belegen. Eine Middleware übersetzt zwischen beiden und entkoppelt sie zugleich: Wird auf einer Seite etwas ausgetauscht, bleibt die andere unberührt. Aus den fünfzig Punkt-zu-Punkt-Verbindungen von oben werden zehn plus fünf.

Ein Beispiel aus den internationalen Anwendungsfällen auf opc-router.de: Bei einem italienischen Hersteller von Polyethylenrohren wurde der OPC Router eingesetzt, um SAP S/4HANA mit einem MES zu verbinden, über SAP IDoc, SAP RFC und MS SQL Server. Konfiguriert sind laut Übersicht mehrere Transaktionen in beide Richtungen, von Artikelstammdaten und Produktionsaufträgen bis zur Rückmeldung von produzierten Stücken, Materialverbrauch und Ausschuss in Kilogramm. Das ist die Schnittstelle zwischen Level 4 und Level 3, wie ISA-95 sie beschreibt.

Ein zweiter Fall aus derselben Übersicht: Ein Dämmstoffhersteller in Japan hat den OPC Router eingesetzt, um den Historian seines Leitsystems durch eine Zeitreihendatenbank zu ersetzen; übertragen werden dabei alle paar Sekunden über 10.000 Datenpunkte.

Wie eine solche Strecke konkret aussieht, zeigt die SAP-Anbindung in der industriellen Produktion. Dort ist auch beschrieben, wo sich eine Middleware von einer herstellereigenen Anbindungskomponente unterscheidet. Was ein Aufbau kostet, steht unter Lizenzen und Kosten.

Mehr zu den Grundlagen: Was ist Middleware? · Was ist IT/OT-Integration?