Was ist eine SPS? Aufbau, Programmierung und Anbindung an IT-Systeme

Programmable Logic Controller, kurz PLC. Beide Begriffe meinen dasselbe Gerät. Die deutsche Abkürzung SPS steht für speicherprogrammierbare Steuerung, im Gegensatz zur früheren verbindungsprogrammierten Steuerung, bei der die Logik in der Verdrahtung lag.

Der Unterschied ist für die Suche relevant: In Deutschland wird SPS rund 14.800 Mal im Monat gesucht, PLC 5.400 Mal; in den USA kommt PLC auf rund 40.500 Suchen (Google-Suchvolumen im Monatsmittel, erhoben im September 2026). Beim Lesen internationaler Dokumentation hilft es, beide Begriffe zu kennen.

Eine Warnung zur Abkürzung

SPS ist in Deutschland auch eine Messe. Die SPS – Smart Production Solutions ist eine internationale Fachmesse für Automatisierung in Nürnberg und läuft jeden November. Eine Suche nach „SPS“ kann also auch der Messe gelten. Die Suchzahl oben unterscheidet das nicht.

Drei Bauformen sind üblich, und die Wahl hat Folgen für die Anbindung.

Für die Anbindung zählt weniger die Bauform als das, was an Kommunikationsmodulen steckt. Eine modulare SPS aus den Neunzigern kann über eine nachgerüstete Kommunikationsbaugruppe durchaus Ethernet sprechen und damit moderner angebunden sein als eine zehn Jahre jüngere Kompakt-SPS, der schlicht der Steckplatz fehlt. Bei der Bewertung eines Maschinenparks lohnt deshalb zuerst der Blick in die Baugruppenträger und erst danach der auf das Typenschild. Das gilt besonders dort, wo über die Jahre erweitert statt ersetzt wurde.

Die Norm IEC 61131-3 beschreibt in ihrer aktuellen Ausgabe (IEC 61131-3:2025) drei Programmiersprachen: Kontaktplan (KOP), der wie ein Stromlaufplan aussieht, Funktionsbausteinsprache (FBS) mit grafischen Blöcken, und Strukturierter Text (ST), der einer Hochsprache ähnelt. Die Ablaufsprache (AS) gliedert ein Programm in Schritte und Übergänge. Die frühere Anweisungsliste (AWL) gehört nicht mehr zur Norm, läuft in vielen Bestandsanlagen aber weiter.

Für die Anbindung ist weniger die Sprache wichtig als die Adressierung. Bei Siemens hat sie sich mit der S7-1200 und S7-1500 grundlegend geändert, dazu unten mehr.

In der Automatisierungspyramide sitzt die SPS auf der Steuerungsebene. Unter ihr liegt die Feldebene mit Sensoren und Aktoren, über ihr die Prozessleitebene mit HMI und SCADA. ISA-95 zählt anders und stellt Steuerungen auf Level 2, über Level 1 mit Sensoren, Aktoren und Ventilen.

Diese Ordnung beschreibt Zuständigkeiten, nicht mehr die Datenwege. Ein ERP kann mit der Prozessleitebene sprechen und auch direkt mit der Steuerung, wenn der Auftragsstand von jetzt gebraucht wird und nicht der von gestern Nacht.

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

Welcher Weg offensteht, hängt an der Generation der Steuerung, am Modell und an der Kommunikationsschnittstelle, die verbaut und freigeschaltet ist. Am deutlichsten zeigt sich das bei Siemens, weil dort mit der S7-1200 und S7-1500 die Adressierung gewechselt hat. Die Tabelle zeigt deshalb die Siemens-Generationen. Ob Steuerungen anderer Hersteller OPC UA haben, integriert oder über ein Zusatzmodul, und welcher Treiber sie anspricht, zeigt die Übersicht weiter unten unter „Der Übersetzer: vom SPS-Protokoll zu OPC UA“.

Warum die S7-1500 einen eigenen OPC UA Server hat

Der Grund liegt in der Adressierung, und er erklärt den Generationswechsel.

Bei der S7-300 und S7-400 lagen Variablen auf festen Speicherplätzen in Datenbausteinen und Merkern. Ein externes System konnte diese Adressen direkt lesen, weil sie sich nicht verschoben. Darauf baut das RFC1006-Verfahren auf.

Mit der S7-1200 und S7-1500 kam die symbolische Adressierung. Programmierer müssen ihre Variablen nicht mehr auf feste Speicherplätze legen, und in optimierten Datenbausteinen liegen sie auch gar nicht mehr an einer vorhersagbaren Stelle. Das ist für die Programmierung ein Fortschritt und für den externen Zugriff ein Bruch: Die Adresse, die man lesen wollte, gibt es so nicht mehr.

Der interne OPC UA Server löst das, indem er die symbolischen Namen nach außen anbietet. Man liest nicht mehr „Datenbaustein 12, Wort 4“, sondern Linie3.Ofen.Temperatur. Eine Programmänderung unterbricht die Anbindung damit nicht mehr unbemerkt.

Zwei Dinge sind dabei zu prüfen: Der OPC UA Server der Steuerung braucht eine Runtime-Lizenz, und er muss in der Gerätekonfiguration aktiviert werden. Ohne vorherige Prüfung fällt beides erst im laufenden Projekt auf.

Ein OPC Server vor den Steuerungen liefert statt des internen Servers eine einheitliche symbolische Sicht auf alle Steuerungen, für die er einen Treiber hat, auch auf ältere. Bei Steuerungen mit festen Adressen wie der S7-300 und S7-400 kommen die Namen dabei nicht aus der Steuerung, sie werden im OPC Server angelegt. Für diesen Fall gibt es die Treibersammlungen: Siemens-Anbindung per OPC Server.

Auch die S7-1200 und S7-1500 lassen sich über das klassische S7-Protokoll ansprechen, ein OPC Server führt sie dafür in seinem Siemens-Ethernet-Treiber. Dabei gilt dasselbe wie bei der S7-300: Gelesen werden feste Adressen. Optimierte Datenbausteine sind so nicht erreichbar, die Werte müssen in einem nicht optimierten Baustein liegen. Außerdem muss laut Siemens in den Eigenschaften der CPU unter Schutz & Security der Zugriff über PUT/GET-Kommunikation durch entfernte Partner erlaubt sein, sonst weist die Steuerung Lese- und Schreibzugriffe ab. Der Kepware-Treiber Siemens TCP/IP Ethernet verlangt laut Handbuch zusätzlich die Schutzstufe „Full access (no protection)“, weil er kein Passwort unterstützt.

Der Übersetzer: vom SPS-Protokoll zu OPC UA

Jede Steuerung spricht das Protokoll ihres Herstellers, etwa das S7-Protokoll, Modbus oder EtherNet/IP. Ein OPC Server übersetzt es nach OPC UA: Nach unten spricht er mit jeder Steuerung in deren Protokoll, nach oben bietet er alle Werte in einer einheitlichen OPC-UA-Sicht an. Dahinter kann der OPC Router als OPC UA Client weiterarbeiten und die Werte an ERP, MES oder Datenbank übergeben.

Herstellerunabhängig leistet das der Kepware Server (bis Version 6.18 KEPServerEX) mit über 150 Treibern für mehr als 300 Protokolle. Als Container-Variante für Linux gibt es Kepware Edge, das sich standardisiert ausrollen und zentral verwalten lässt.

Ob die Übersetzung nötig ist, hängt an der Steuerung. Manche bringen einen OPC-UA-Server mit, andere bekommen ihn über ein Zusatzmodul, bei den übrigen übersetzt ein OPC Server. Die Tabelle zeigt das für die Steuerungsfamilien der vier großen Hersteller: Siemens, Rockwell Automation, Mitsubishi Electric und Schneider Electric teilen sich laut Interact Analysis (Bericht von 2019) fast drei Viertel des weltweiten SPS-Markts (74,3 %). Dazu kommen Modbus in seinen Varianten und Steuerungen mit CODESYS-Laufzeit, am Beispiel WAGO. Die Angaben stammen aus Datenblättern und Handbüchern der Hersteller.

„Integriert“ heißt: Der Server läuft in der Steuerung selbst, bei einer modularen SPS in der CPU. Läuft er auf einem eigenen Modul neben der CPU, steht in der Tabelle „über Zusatzmodul“. „Nicht genannt“ heißt: Die herangezogenen Unterlagen des Herstellers führen keinen OPC-UA-Server beziehungsweise keinen Treiber auf. Steht in der Spalte Voraussetzung keine Lizenz, ist damit nicht gesagt, dass keine nötig ist. Modbus ist ein Protokoll und keine Steuerung: Die Spezifikationen der Modbus Organization bilden nichts nach OPC UA ab, ob ein Gerät zusätzlich einen OPC-UA-Server hat, hängt am Gerät.

Das Handbuch des Treibers Siemens S7 Plus Ethernet (Version 1.052 von 2026) führt als unterstützte Firmware für die S7-1200 Stände bis 4.6 und für die S7-1500 bis 3.0.x. Spätere Firmware wie V4.7 bei der S7-1200 oder V3.1 bis V4.1 bei der S7-1500 steht dort nicht.

„Integriert“ heißt nicht unbegrenzt: Für die S7-1200 mit Firmware V4.5 bis V4.7 und für die S7-1200 G2 nennt Siemens höchstens 10 Sessions und 1.000 überwachte Elemente, die 1.000 in den Datenblättern als empfohlenes Maximum.

Mehr dazu: Grenzen integrierter OPC-UA-Server

Was, wenn die Steuerung älter ist als die Anforderung?

Dann hilft die Übersetzerschicht aus dem vorigen Abschnitt, und sie hat einen zweiten Nutzen: Wird eine Steuerung getauscht, ändert sich diese Schicht, das ERP dahinter bleibt unberührt. Einen Fall mit dem Wechsel von S5 auf S7 beschreibt unten der Abschnitt „Wie sieht das in echten Anlagen aus?“.

Die Protokolle zerfallen in zwei Gruppen.

Feldprotokolle verbinden die Steuerung mit ihren Geräten, etwa PROFINET, PROFIBUS, EtherCAT, Modbus. Sie sind auf kurze Wege und feste Zykluszeiten ausgelegt.

Anbindungsprotokolle verbinden die Steuerung mit der IT, zum Beispiel OPC UA und MQTT, herstellereigene wie das S7-Protokoll über RFC1006, das auch neuere Siemens-Steuerungen noch sprechen, und teils auch direkte Datenbankzugriffe. OPC UA und MQTT sind auf Struktur und Sicherheit ausgelegt, weniger auf kurze Zykluszeiten.

Wo Steuerung und IT-System kein gemeinsames Protokoll sprechen, sitzt dazwischen ein Übersetzer, beschrieben oben unter „Der Übersetzer: vom SPS-Protokoll zu OPC UA“.

Mehr dazu: Was ist OPC UA? · Was ist MQTT? · Was ist Modbus?

Eine SPS arbeitet ihren Zyklus ab und beantwortet Anfragen von außen im Rahmen des Anteils, den die Kommunikation bekommt. Zwischen den einzelnen Telegrammen einer Leseanforderung läuft ihr Zyklus weiter. Daraus folgt vor allem, dass mehrere gelesene Werte nicht zwingend aus demselben Zyklus stammen, auch bei fehlerfreier Einrichtung. Dazu kommen Planungsfragen: wie die Schnittstelle geschnitten ist und wie oft welcher Wert gelesen wird.

Einzelne Werte kommen ohne Zusammenhang an

Zwischen SPS und lesendem System gibt es keine Transaktionsklammer. Eine Leseanforderung über mehrere Werte wird in ein oder mehrere TCP-Telegramme zerlegt. Die Steuerung beantwortet sie aus ihrem jeweils aktuellen Speicherzustand. Zwischen zwei Telegrammen läuft ihr Zyklus weiter, unter Umständen mehrfach.

Die Folge: Die Werte stammen möglicherweise nicht alle aus demselben SPS-Zyklus. Die Auftragsnummer kann aus Zyklus 4711 kommen und die zugehörige Stückzahl aus 4713. Bei den klassischen Zugriffswegen wie RFC1006 verhindert nichts im Protokoll das, und nichts zeigt es an. Der Datensatz sieht vollständig aus und ist in sich falsch.

Zehn Werte zu lesen ist deshalb nicht dasselbe wie einen Datensatz zu lesen.

Der Fehler tritt nur auf, wenn sich ein Wert zwischen zwei Telegrammen ändert, also nicht bei jeder Leseanforderung.

Was hilft. Die Abhilfe hat zwei Hälften, und die erste liegt in der Steuerung. Die SPS kopiert die zusammengehörenden Werte an einer definierten Stelle ihres Zyklus in einen eigenen Datenbereich, eine Art Momentaufnahme. Erst danach meldet sie, dass gelesen werden darf. Das steht im SPS-Programm, und kein Werkzeug auf der IT-Seite kann es ersetzen: Nur im Programm der Steuerung ist festgelegt, an welcher Stelle des Zyklus die Werte zusammenpassen.

Die zweite Hälfte liegt auf der IT-Seite: Der OPC Router liest den Datenbereich erst nach dieser Meldung und quittiert nach erfolgreichem Transfer, beschrieben unten unter „Wie holt man konsistente Daten aus einer SPS?“.

Der Aufwand verteilt sich damit auf beide Seiten. In der Steuerung sind es unter anderem ein Datenbereich, der bis zur Quittung unverändert bleibt, das Setzen des Triggers und beim Bit-Trigger sein Zurücksetzen nach der Antwort, dazu ein Timeout, das bei ausbleibender Antwort erneut sendet und nach mehreren Fehlversuchen einen Fehler meldet. Im OPC Router ist es Konfiguration statt Programmierung.

Schlecht geschnittene Schnittstellen erzeugen Netzlast ohne Gegenwert

Nicht jedes Protokoll zwischen SPS und OPC Server kennt Benachrichtigungen. Wo ein Abonnement fehlt, bleibt nur das Abfragen: Der Server fragt in festen Abständen nach, auch dann, wenn sich seit der letzten Abfrage nichts geändert hat.

Das ist verkraftbar, solange die Schnittstelle zusammenhängend entworfen ist. Liegen die benötigten Werte in einem durchgehenden Datenbereich, holt eine Anfrage sie alle auf einmal.

Liegen sie verstreut, wird aus einer Abfrage ein Dutzend. Jede einzelne kostet ein Telegramm, eine Antwort und einen Anteil der Kommunikationszeit der Steuerung. Das Ergebnis sind lange Netzwerkzyklen für wenige Werte.

Der Schnitt der Schnittstelle ist damit eine Leistungsfrage. Der Datenbereich wird am besten mit dem Programmierer der Steuerung gemeinsam festgelegt, bevor die erste Verbindung konfiguriert wird. Nachträglich zu ändern ist teuer, weil beide Seiten angefasst werden müssen.

Am meisten bringt der Schnitt: Zusammenhängende Bereiche statt verstreuter Einzeladressen senken die Zahl der Anfragen. Das ist Arbeit in der Steuerung.

Dazu kommt das Verfahren: Wo das Protokoll ein Abonnement kennt, wie OPC UA es tut, meldet die Steuerung Änderungen selbst, statt gefragt zu werden. Die S7-1200 und S7-1500 können das über ihren internen OPC UA Server. Für ältere Steuerungen bleibt das Abfragen. Ein vorgelagerter OPC Server verlegt es nur an eine einzige Stelle, dazu der nächste Absatz.

Schließlich die Bündelung über einen vorgelagerten Datenvermittler, beschrieben unten unter „Die SPS steuert. Kommunikation bekommt ihren Anteil“. Sie senkt die Last an der Steuerung auch dann, wenn das Protokoll darunter kein Abonnement kennt und weiter abgefragt werden muss, denn Werte, die die Verbraucher beim Datenvermittler abonniert haben, fragt nur noch er ab.

Die SPS steuert. Kommunikation bekommt ihren Anteil

Die Hauptaufgabe einer SPS ist die Maschine. Ihr Echtzeitanspruch gilt dem Zyklus: Eingänge lesen, Programm rechnen, Ausgänge setzen, und das verlässlich innerhalb einer festen Zeit. Die Kommunikation bekommt davon einen begrenzten Anteil.

Wie groß dieser Anteil ist, legt die Steuerung fest. Je nach Hersteller und Modell ist er einstellbar, oder ein eigener Prozessor übernimmt die Kommunikation. Bei Siemens-Steuerungen der Reihe S7-1500 etwa ist der Anteil ein Parameter der CPU, und Organisationsbausteine mit höherer Priorität unterbrechen laut Siemens die Kommunikation. Was die Kommunikation von ihrem Anteil nicht braucht, steht dem Anwenderprogramm zur Verfügung. Wird der Anteil voll genutzt, dauert der zyklische Programmteil länger, bei einem Anteil von 50 Prozent bis zum Doppelten. Welcher Wert voreingestellt ist, hängt laut Siemens von Typ und Version der CPU ab. Ein kleinerer Anteil senkt diese Verlängerung. Siemens empfiehlt im Funktionshandbuch „Zyklus- und Reaktionszeiten“ (Ausgabe 11/2024), die Kommunikationslast bei der maximalen Zykluszeit mit einzuplanen.

Die Abfragedichte ist damit eine Planungsgröße, und sie wird auf beiden Seiten eingestellt: in der Steuerung über den Kommunikationsanteil und die Zykluszeit, auf der Seite der Anbindung darüber, wie oft und auf welche Weise gelesen wird. Daraus folgt die Reihenfolge: Erst wird festgelegt, welche Werte in welchem Takt gebraucht werden, dann wird die Anbindung dazu entworfen.

Die Last sinkt, wenn weniger Stellen fragen und wenn seltener gefragt wird, wo der Wert es erlaubt. Wenn eine Datenbank, ein Dashboard und ein MES dieselben Werte brauchen, muss die Steuerung sie nicht dreimal liefern. Ein vorgelagerter Datenvermittler, etwa ein OPC Server oder eine Middleware, liest abonnierte Werte einmal und bedient die drei Verbraucher aus derselben Abfrage. Einzelne Lese- und Schreibaufträge eines Verbrauchers können dagegen bis zur Steuerung durchgehen: Der Kepware-Treiber Siemens S7 Plus Ethernet etwa fragt abonnierte Werte laut Handbuch auf Wunsch nicht schneller ab als eingestellt, einzelne Lese- und Schreibaufträge bearbeitet er unabhängig von dieser Einstellung so schnell wie möglich. Aufseiten der Anlage bleibt eine Entscheidung, die keine Software abnimmt: wie oft welcher Wert wirklich gebraucht wird. Ein Temperaturwert, der sich alle zwei Minuten ändert, muss nicht im Sekundentakt gelesen werden.

Gegen Werte aus verschiedenen SPS-Zyklen hilft ein Handshake: Die Steuerung meldet, dass ein Datensatz vollständig ist, und bekommt eine Quittung. Für mehrere zusammengehörende Werte sieht der OPC Router zwei Trigger vor: den Bit-Trigger für einzelne Vorgänge und den Message-Trigger für Folgen von Datensätzen, in denen eine Lücke auffallen soll. Bei beiden wartet der OPC Router nach dem Auslösen einen weiteren Lesezyklus ab, bevor er den Datensatz liest, damit die SPS alle Werte schreiben konnte.

Der Bit-Trigger ist ein Datenpunkt, den die SPS setzt, wenn die Werte vollständig geschrieben sind. Erst dann liest der OPC Router. Das Handbuch schreibt vor, den Bit-Trigger immer mit Antwortbit zu verwenden, und begründet das so: Ändert sich der Trigger-Datenpunkt in der SPS innerhalb eines Lesezyklus zweimal, bemerkt der OPC Router die zweite Änderung nicht. Der zugehörige Transfer unterbleibt und damit auch das Antwortbit. Wartet die SPS mit einem Timeout auf die Antwort, erkennt sie den Ausfall und kann den Vorgang erneut anstoßen.

Der Message-Trigger ist laut Handbuch die sicherere der beiden Varianten, weil er mit einem Zähler arbeitet statt mit einem Bit. Diesen Zähler, die Telegrammnummer, erhöht die SPS um 1, wenn ein neuer Datensatz bereitsteht, und der OPC Router kann über einen eigenen Datenpunkt antworten. Wird der Zählerstand mit aufgezeichnet, lässt sich später nachverfolgen, ob Datensätze nicht oder doppelt übertragen wurden, zum Beispiel wenn der Zähler von 5 auf 7 springt oder derselbe Zählerstand zweimal aufgezeichnet ist. Das dient der Rückverfolgung und der Diagnose. Eine Lücke vermeiden muss die SPS: Sie schreibt den nächsten Satz erst nach der Antwort und sendet erneut, wenn die Antwort innerhalb eines Timeouts ausbleibt.

Die Reihenfolge in der SPS ist dabei immer dieselbe: Erst alle zusammengehörenden Werte schreiben, dann den Trigger setzen. Der weitere Lesezyklus des OPC Router ersetzt das nicht: Steht der Trigger vorher, kann wieder ein Zwischenstand gelesen werden.

Das ist ein typischer Fall für den Message-Trigger.

Die Steuerung schreibt die zusammengehörenden Werte in die dafür vorgesehenen Datenpunkte, etwa Materialnummer, Auftragsnummer, produzierte Menge, verbrauchte Menge und Zeitstempel. Erst danach erhöht sie den Message-Zähler. Der OPC Router erkennt den neuen Zählerstand, liest den vollständigen Satz und übergibt ihn an das ERP. Danach meldet er der SPS über den Antwort-Datenpunkt, dass die Rückmeldung übergeben wurde.

Ein Haftmaterial-Hersteller koppelte laut Anwenderbericht (undatiert, die Firmenzahlen darin stammen von 2017) 14 Maschinen über den OPC Router mit SAP, bei rund 15.000 Datentelegrammen pro Tag und Verbuchungszeiten unter 15 Millisekunden. SAP sendete Rezepturen und Geschwindigkeiten an die Maschinen, die Maschinen meldeten Fehlstellen zurück. Die Strecke zu SAP lief laut Bericht per RFC mit Handshake.

Der Rückkanal, also Aufträge in die SPS zu schreiben, ist technisch dasselbe wie lesen, organisatorisch aber etwas anderes: Wer darf schreiben, was passiert bei einem Konflikt, und was tut die Anlage, wenn die Verbindung abbricht. Diese Fragen gehören in die Inbetriebnahme.

Ein Motorgerätehersteller prüfte laut Anwenderbericht von 2019 am Ende einer Montagelinie in bis zu neun Prüfzellen parallel, mit Prüfabläufen von bis zu fünf Minuten. Im Werk waren Steuerungen der Simatic-Reihe, Sinumerik-CNC, Simotion und Roboter im Einsatz. Der Bericht nennt 16 Installationen in Deutschland, dazu die Werke in den USA und China, je Montagelinie ein OPC Router mit eigenem lokalem Datenbankserver. Hier wurde eine Anbindung einmal entworfen und als Muster vervielfältigt.

Ein Fahrradhersteller band laut Anwenderbericht (undatiert) die S5-Steuerung seiner Elektrohängebahn zunächst über eine IBH-Schnittstelle an den OPC Router an und stellte etwa ein Jahr später auf eine S7-Steuerung um. Die Umstellung nahm er zum Anlass, die Datentransfers neu zu strukturieren.

Ein Automobilzulieferer fertigte laut Anwenderbericht (undatiert) Bodenverkleidungen just in time und just in sequence, mit zahlreichen Varianten und vollständiger Rückverfolgbarkeit. Dort waren alle SPS der Stationen über einen OPC Server angebunden, und der OPC Router übernahm die Kommunikation mit SAP.

Eine Container-Terminal-Gruppe band laut Anwenderbericht (undatiert) Umschlaggeräte und Anlagen an, also bewegliche Großgeräte statt stehender Maschinen.

Ein Verpackungshersteller band laut Anwenderbericht von 2020 auf kepware-opcserver.de rund 500 Maschinen verschiedener Hersteller in elf Werken an, darunter Spritzgussmaschinen, mit Kepware Servern in den Werken und zentral dem OPC Router.

Weitere Beispiele, nach Branchen geordnet, sammelt die Seite Internationale OPC Router Use Cases auf opc-router.de (Stand der Seite: Juli 2026).

Anhaltspunkte für die Strecke vom OPC Server zum Zielsystem geben die Benchmarks aus dem Handbuch des OPC Router:

Gemessen wurde mit einer älteren Version des OPC Router gegen simulierte OPC-Server, nicht gegen Steuerungen, und die Ziele waren MQTT und InfluxDB. Die Zahlen markieren die Grenze des jeweiligen Testaufbaus: Bei 21.200 Datenpunkten pro Sekunde kamen bereits nicht mehr alle Werte an, bei 28.500 war der OPC-Server der begrenzende Faktor. Was eine konkrete Anlage trägt, hängt unter anderem an der Steuerung, am Netz und daran, wie viele Werte wirklich gebraucht werden. Last entsteht dabei auch aus einem zu kurzen Leseintervall auf Werten, die sich selten ändern.