Computergesteuerte Überwachung der Funktionsfähigkeit von Auf/Zu-Ventilen in Produktionsanlagen

Inhaltsverzeichnis

1 Einführung

2 Stand der Technik

3 Verwendete Hard- und Software
3.1 CoDeSys v2.3
3.1.1 Programmiersprachen in CoDeSys
3.1.2 Datentypen in CoDeSys
3.1.3 Struktur eines Projekts in CoDeSys
3.2 Speicherprogrammierbare Steuerung (SPS)
3.2.1 Software-SPS
3.2.2 Hardware-SPS
3.3 Ventilantriebe

4 Methodik
4.1 Ursprüngliche Anlage
4.2 Festlegung von Laufzeiten des Ventils
4.3 Simulation der Phasen des Sicherheitsventils
4.4 Der Hauptventilbaustein
4.5 Baustein für Full-Stroke-Test
4.6 Änderungen an dem Simulationsprogramm
4.7 Visualisierungen

5 Ergebnisse
5.1 Simulierter Ventilantrieb
5.2 Gesteuerte Ventilantriebe

6 Diskussion
6.1 Ausblick

7 Fazit

A Anhang
A.1 Glossar
A.2 Literaturverzeichnis
A.3 Tabellen, Abbildungen und Quelltexte

Mit * gekennzeichnete Begriffe werden im Glossar näher erläutert. Es ist jeweils nur das erste Auftreten eines Begriffes mit einem * markiert. Der Pfeil → verweist auf eine nähere Erläuterung in dem nachfolgend genannten Abschnitt.

1 Einführung

Das Werk Stade der Dow Deutschland Anlagengesellschaft mbH pro- duziert nach eigenen Angaben „jährlich in 16 Produktionsanlagen auf einer Fläche von etwa 550 Hektar rund drei Millionen Tonnen Grund und Spezialitätenchemikalien“[5]. Bei dieser enormen Menge und Di- mension an Anlagen ist eine Automatisierung* der Herstellungsprozesse unbedingt vonnöten. Besonders in Bezug auf das Gefahrenpotenzial der bei der Dow verwendeten Chemikalien ist eine regelmäßige Wartung der Anlagen unabdingbar. Die manuelle Wartung aller Anlagenteile durch Techniker ist bei der Größe des Werks jedoch kaum zu realisieren. Ei- ne automatisierte Wartung hingegen durchzuführen, erscheint vor dem Hintergrund von Effizienz, Zuverlässigkeit und Zeitaufwand als deutlich vorteilhafter.

Über ein Gespräch mit dem schulischen Betreuer der Facharbeit hat der Autor der Arbeit erfahren, dass in modernen Kraftfahrzeugen be- reits automatisierte Wartung angewandt wird. In diesen befinden sich Mikrochips, die Messdaten von Komponenten wie dem Motor empfangen und speichern. Sowie ein schwerwiegender Fehler festgestellt wird, wird der Fahrer sofort etwa durch eine Kontrollleuchte darüber informiert. Sämtliche Messwerte werden gespeichert und beim nächsten Besuch ei- ner Autowerkstatt ausgelesen, sodass Fehler schneller festgestellt werden können.

Zielsetzung Der Autor der Arbeit hat sich im Folgenden primär mit dem pneumatischen Antrieb eines „Auf/Zu-Ventils*“ (s. Abb. 1) und mit dessen Möglichkeiten der automatisierten Wartung befasst und sich zum Ziel gesetzt, mithilfe der Automatisierungssoftware CoDeSys (s. Abb. 2 links) einen Programmablauf zu entwickeln, mit dem er die Funkti- onsfähigkeit von Auf/Zu-Ventilen überprüfen kann, indem er bei deren Betätigung die dabei aufgewendete Laufzeit* misst und mit gegebenen Referenzwerten vergleicht. Anhand dieser soll ermittelt werden können, ob im Ventil ein Defekt vorliegt, da Defekte wie Verschleiß oder Ablage- rungen das Ventil blockieren oder dämpfen. Darüber hinaus soll gemessen werden, wann ein Ventil zuletzt betätigt wurde, da ungenutzte Ventile, wie die Praxis im Dow-Werk Stade zeigte, sich in ihrer Stellung festset- zen. Sobald das Ventil eine gegebene Zeit lang nicht mehr betätigt wurde oder dieses eine längere Zeit zum Auf- oder Zufahren benötigt als erlaubt, soll der Operator* der Anlage über einen Alarm informiert werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Pneumatischer Antrieb eines Auf/Zu-Ventils (Bauteil in der Mitte). [6, S. 18, bearbeitet]

Der Autor der Arbeit hat nun eine automatisierte Wartung eines solchen pneumatischen Antriebs realisiert. Er hat dafür in CoDeSys einen Programmablauf entwickelt, in dem ein Auf/Zu-Ventil als Sicherheits- ventil* innerhalb der Simulation einer kleinen Anlage integriert ist. Das Auf/Zu-Ventil wurde ebenfalls als Simulation verwendet, darüber hin aus wurden zwei Antriebe eines Auf/Zu-Ventils der Firmen Air Torque und Pfeiffer gesteuert. Die Laufzeit des Ventils wird bei jeder Betäti- gung gemessen und mit Referenzwerten verglichen. Sobald ein Messwert den Referenzwert überschreitet, wird ein akustischer und visueller Alarm ausgegeben, sodass der vorliegende Defekt schnellstmöglich behoben wer- den kann. Ein Alarm wird ebenfalls ausgegeben, wenn das Ventil lange Zeit nicht getestet wurde. Wenn ein solcher Alarm ausgelöst wird, führt der Programmablauf einen „Full-Stroke-Test*“ durch, bei dem das Ventil ein Mal komplett zu- und wieder auffährt und die dafür benötigte Zeit gemessen und wie oben genannt ausgewertet wird. Die ständige Betriebs- bereitschaft der Auf/Zu-Ventile ist so stets gewährleistet.

2 Stand der Technik

Über ein Gespräch mit den betrieblichen Betreuern der Facharbeit hat sich der Autor der Arbeit über die derzeitige Wartung von Auf/Zu- Ventilen im Dow-Werk Stade erkundigt. Es stellte sich heraus, dass viele der mehreren Tausend im Dow-Werk Stade verwendeten Ventile bereits über Full-Stroke-Tests gewartet werden. Dies geschieht jedoch nicht im- mer über Full-Stroke-Tests; solche werden häufig dazu verwendet, die Zeit bis zur nächsten vollständigen manuellen Wartung, die aus Stop- pen der Anlage, Ausbau, Überprüfung aller Ventilkomponenten in einer Werkstatt und anschließendem Einbau des Ventils besteht, zu verlängern. Die Wartung der Ventile über Full-Stroke-Tests wird jedoch auf viele ver schiedene und oft ineffiziente Vorgehensweisen durchgeführt. Auch ist die Wartung der Ventile im Werk kaum automatisiert. Es gibt zwar häufig die Möglichkeit, ein Ventil manuell zu fahren und die Fahrzeit zu mes- sen, diese wird aber oftmals nicht weiter verarbeitet. Häufig wird nur das Datum der letzten Betätigung des Ventils zusammen mit der be- nötigten Fahrzeit angezeigt. Der Operator der Anlage muss dann selbst darauf achten, wann das Ventil wieder getestet werden muss, wie lange das Ventil zum Auf- und Zufahren benötigt und wie lange die Betätigung maximal dauern darf.

3 Verwendete Hard- und Software

3.1 CoDeSys v2.3.9.10

Für die Entwicklung des Programmablaufs wurde die Software CoDeSys (s. Abb. 2 links) von der deutschen Softwarefirma „3S-Smart Software Solutions GmbH“ in der von der Dow bereitgestellten Version 2.3.9.10 genutzt. CoDeSys ist ein „hardwareunabhängige[s] IEC 61131-3 Pro- grammiersystem [...] zur Erstellung von Steuerungsanwendungen“[1]. CoDeSys ist eine frei verfügbare Software und lässt sich auf jedem PC mit Windows-Betriebssystem installieren. Da es auf dem IEC 61131-3- Programmiersystem für speicherprogrammierbare Steuerungen* basiert [vgl. 2], lassen sich damit alle Ventilantriebe* steuern, die derzeit auf dem Markt verfügbar sind.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Benutzeroberflächen von CoDeSys (links) und der Software-SPS (rechts).

3.1.1 Programmiersprachen in CoDeSys

CoDeSys unterstützt alle in der Norm IEC-61131 beschriebenen Pro- grammiersprachen. Dies sind unter anderem der Strukturierte Text (ST*, structured text), die Ablaufsprache (SFC*, sequential function chart) und der Funktionsplan (FBD*, function block diagramm) [vgl. 3, S. 22-36].

3.1.2 Datentypen in CoDeSys [vgl. 3, S. 353]

CoDeSys bietet viele verschiedene Datentypen zur Verwendung an. Die gängigsten sind hierbei boolean, die Ganzzahldatentypen byte, word und integer, real zum Darstellen von Dezimalbrüchen, string zum Speichern von Text sowie die Datentypen time und date zur Angabe von Datum und Zeit.

3.1.3 Struktur eines Projekts in CoDeSys

Ein Projekt in CoDeSys besteht aus verschiedenen Bausteinen*, Daten- typen, Visualisierungen, Ressourcen und Bibliotheken. Der „Hauptbau- stein“ mit der Bezeichnung PLC_PRG ist dabei ein Baustein, den die SPS* (→ Abschnitt 3.2) in einer Endlosschleife aufruft. Alle Bausteine müssen von dem PLC_PRG aufgerufen werden, damit sie ausgeführt werden. Über Visualisierungen lassen sich verschiedenste Daten ausge- ben und Bausteine über Variablen steuern. Variablen werden in CoDe- Sys entweder in globalen Variablensammlungen oder lokal in bestimmten Bausteinen deklariert.

3.2 Speicherprogrammierbare Steuerung (SPS)

3.2.1 Software-SPS

Zur Simulation des Auf/Zu-Ventils wurde die CoDeSys-eigene Software- SPS CoDeSys SP PLCWinNT V2.4 (s. Abb. 2 rechts) verwendet. Diese empfängt von CoDeSys über das Netzwerkprotokoll TCP/IP* den kom- pilierten Code des Programms und führt diesen aus. CoDeSys selbst wird beim Ausführen des Projekts lediglich zur Visualisierung genutzt.

3.2.2 Hardware-SPS

Zum Ansteuern der verwendeten Ventilantriebe wurde die Hardware- SPS ecomatmobile BasicController CR0403 des Herstellers „ifm electronic gmbh“ eingesetzt. Diese empfängt wie die Software-SPS den kompilierten Code des Programms von CoDeSys und führt diesen aus. Zur Übertra- gung des Programms wird die SPS über den Feldbus* CANopen und einen USB-Adapter mit dem Computer verbunden. Das Ventil selbst so- wie dessen Sensoren werden mithilfe von Kabeln an die über verknüpfte Adressen* in CoDeSys festgelegten Anschlüsse der SPS angeschlossen. Es erfolgt die Weitergabe des Soll-Zustands des Ventils vom Computer über die SPS an das Ventil, umgekehrt wird die von den Sensoren am Ventil erfasste Stellung über die SPS an den Computer übermittelt.

3.3 Ventilantriebe

Ventilantriebe von Auf/Zu-Ventilen werden mit Druckluft betrieben. Die Druckluft, deren Steuerung über Magnetventile* erfolgt, wird durch die Öffnung 1 in den Ventilantrieb gepresst und drückt dessen Kolben aus einander (s. Abb. 3 oben). Die Luft hinter den Kolben wird dabei über die Öffnung 2 herausgelassen. Die Kolben drehen hierbei mit seinen Zäh- nen an der Welle, die oben an eine Stellungsanzeige und unten an das Ventil angeschlossen ist und dieses steuert. Wird die Druckluftzuführung

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Skizze eines Ventilantriebs. [8, S. 19, bearbeitet]

an der Öffnung 1 gestoppt und die Öffnung 2 geöffnet, sorgen die Federn dafür, dass die Kolben zusammengepresst werden und die eingeschlossene Luft aus der Öffnung 1 strömt (s. Abb. 3 unten). Dies stellt zugleich die Sicherheitsfunktion des Ventilantriebs dar: Wenn der Druck im Inneren des Antriebs abfällt, pressen die Federn die Kolben wieder zusammen und über die Welle schließt sich das angeschlossene Ventil.

4 Methodik

4.1 Ursprüngliche Anlage

Dem Autor der Arbeit wurde von den betrieblichen Betreuern ein Grund- programm übergeben, welches die Simulation eines Wasserbehälters mit Zu- und Abflussventil, Druckausgleichsventil, Pumpe sowie Durchfluss-, Druck- und Füllstandssensoren enthält (s. Abb. 4). Eine Tabelle mit al- len Ein- und Ausgängen der Anlage sowie ausführlichen Erläuterungen hierzu findet sich im Anhang (s. Tab. 1).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Skizze der simulierten Anlage mit Sicherheitsventil.

Die Anlage hat folgende Funktion: Durch Öffnen und Schließen des Re- gelventils* AO(1) wird der Zufluss zum Behälter beeinflusst. Der Stand im Behälter wird in AI(1) sowie in DI(3) und DI(4) gemessen und kon- stant bei 50% gehalten. Sowie der Tankfüllstand höher ist als 10%, soll die Pumpe DO(1) laufen. Dadurch wird Flüssigkeit über das Regelven- til AO(2) im Kreis zurück in den Tank gepumpt. Der Wasserdruck soll konstant bei 7 bar gehalten werden. Die „Nachbaranlage“ entnimmt in unregelmäßigen Abständen und Mengen Flüssigkeit aus der Anlage über das Regelventil AO(3).

Der Tank soll nun durch ein zusätzliches Sicherheitsventil in der Zu- laufleitung des Tanks sicher gegen Überfüllung geschützt werden. Dieses Ventil DO(2) soll schließen, wenn der DI(3) „Stand sehr hoch“ meldet, oder bei einer Tankfüllung von ≥ 90%. Bei dem DO(2) ist zu überprüfen, ob das Ventil sicher schließt und nicht durch Verschmutzungen schwer- gängig oder defekt ist. Ein Indikator für die Funktion des Ventils ist des- sen Laufzeit. Um das Ventil testen zu können, soll ein Full-Stroke-Test programmiert werden, bei dem das Ventil einmal zu- und wieder auffährt, wobei die Laufzeit des Ventils gemessen wird. Überschreitet die Laufzeit eine festgelegte Zeit, so soll eine Alarmmeldung ausgegeben werden. Um eine Unterversorgung der nachgeschalteten Anlagen zu vermeiden, soll bei einem Full-Stroke-Test der Tankfüllstand auf 70% erhöht werden.

4.2 Festlegung von Laufzeiten des Ventils

Die Zeiten tzu sowie tauf , die die Laufzeiten des simulierten Ventils an- geben, werden von der Simulation definiert. Wenn ein intaktes Ventil si- muliert wird, gilt: tzu = 330 ms ± 55 ms und tauf = 1400 ms ± 300 ms. Bei einem defekten Ventil gilt: tzu = 825 ms ± 275 ms und tauf = 2850 ms ± 600 ms. Als maximal erlaubte Referenzwerte werden verwen- det: Tzu = 500 ms und Tauf = 2000 ms. Die Zeit, nach deren Ablauf das Ventil wieder getestet werden muss, beträgt tTest = 30 d.

4.3 Simulation der Phasen des Sicherheitsventils

Der Autor der Arbeit hat die verschiedenen Phasen des Ventils, welche dieses während einer Betätigung durchläuft, in dem SFC-Baustein VAL- VE01_STEP (s. Abb. 13) simuliert. Dies erleichtert die Messung der Betätigungszeit sowie die Visualisierung des Ventils.

Das SFC enthält die Phasen OpenedValve, ClosingValve, ClosedVal- ve, OpeningValve, CheckedValve01 sowie CheckedValve02, die als ST ge- schrieben sind. In allen Phasen werden die Werte von Variablen festge- legt, die eine Animation des Ventilantriebs erlauben. Auch wird festge- legt, ob der Wert Tzu oder der Wert Tauf als aktueller Referenzwert zu verwenden ist.

Phase OpenedValve Beim Starten des Bausteins befindet sich das Ventil in der ersten Phase OpenedValve. Es ist folglich geöffnet. Sobald nun das Ventil geschlossen werden soll (→ Abschnitt 4.6), geht es in die Phase ClosingValve über.

Phasen ClosingValve und ClosedValve Während der Phase Closing- Valve zählt in dem Hauptventilbaustein (→ Abschnitt 4.4) ein Timer aufwärts. Wenn die Sensoren DI(6) und DI(8) nun signalisieren, dass das Ventil vollständig geschlossen ist, geht dieses in die Phase ClosedValve über und der Timer stoppt. Sobald nun das Ventil wieder geöffnet werden soll, geht es in die Phase OpeningValve über.

Phase OpeningValve Hier zählt abermals im Hauptventilbaustein der Timer aufwärts. Wenn das Ventil vollständig geöffnet ist, geht es in die Phase CheckedValve01 über und der Timer stoppt.

Phasen CheckedValve01 und CheckedValve02 Wenn während der Ventilbetätigung kein Fehler festgestellt wurde, wird der Timer aus dem Hauptventilbaustein zurückgesetzt, der die Zeit seit der letzten korrekt ausgeführten Ventilbetätigung ausgibt. Nach 100 ms¹ wird in die Phase CheckedValve02 gewechselt, der die zurücksetzende Variable wieder mit false beschreibt, damit der Timer nicht dauerhaft zurückgesetzt bleibt. Nach einem Durchlauf von CheckedValve02 wird wieder in die Phase OpenedValve gewechselt.

4.4 Der Hauptventilbaustein

Der Hauptventilbaustein mit der Bezeichnung VALVE01_MAIN ist ein Baustein, welcher u. a. die Ausgabe von Alarmen steuert. Es ist als FBD (s. Abb. 20) geschrieben.

Netzwerk 0001 Dieses Netzwerk enthält einen Timer, der eine Zeit hochzählt, sobald dies vom Baustein VALVE01_STEP gefordert wird. Wenn diese Zeit den Referenzwert T (→ Abschnitt 4.2) übersteigt, wird ein Alarm ausgelöst.

Netzwerk 0002 Dieses Netzwerk enthält einen Timer, der die Zeit von 10 der letzten vollständigen und korrekt ausgeführten Betätigung aus hoch- zählt. Sobald der Timer die Zeit erreicht, die ein Ventil maximal arbeiten darf, ohne gewartet zu werden, wird ein Alarm ausgelöst.

Netzwerke 0003 und 0011 Diese Netzwerke rufen die Bausteine VAL- VE01_STEP und VALVE01_FULLSTROKE (→ Abschnitt 4.5) auf, 15 damit sie ausgeführt werden (→ Abschnitt 3.1.3).

Netzwerke 0004-0007 Diese Netzwerke wandeln verschiedene Zeiten in einen Dezimalbruch mit verschiedenen Einheiten um. Das Netzwerk 0004 speichert die vergangene Laufzeit des Ventils in der Einheit Milli- sekunde. Das Netzwerk 0005 speichert die verbleibende Laufzeit in der 20 Einheit Millisekunde. Das Netzwerk 0006 speichert die Zeit nach der letzten Überprüfung des Ventils in der Einheit Tag. Das Netzwerk 0007 speichert die zur nächsten Überprüfung des Ventils noch verbleibende Zeit in der Einheit Tag.

Netzwerke 0008 und 0009 Diese Netzwerke enthalten Flip-Flop*-Blö- 25 cke, die zur Steuerung der Alarmausgabe verwendet werden.

Netzwerk 0010 Dieses Netzwerk lässt eine Variable ständig zwischen zwei Werten springen. Sollte das Ventil defekt sein, bewegt sich hierdurch der Kolben in der Animation (→ Abschnitt 4.7) stockend hin und her.

4.5 Baustein für Full-Stroke-Test

Der Autor der Arbeit hat den Baustein VALVE01_FULLSTROKE ent- wickelt, der einen Full-Stroke-Test des Ventils realisiert. Dieser Baustein wurde als SFC (s. Abb. 21) programmiert.

Das SFC enthält die Phasen Init, Start, Closing, Pause, Opening und Processing, die als ST geschrieben sind.

Phase Init Beim Starten des Bausteins befindet sich der Full-Stroke- Test in der ersten Phase Init. Hier wird der Sollwert für den Füllstand des Tankes auf 50% gesetzt². Sobald der Test über DI(7) gestartet wird, erfolgt der Wechsel in die Phase Start.

Phase Start Es wird der Sollwert für den Füllstand des Tankes auf 70% gesetzt, um eine Unterversorgung der nachgeschalteten Anlagen zu vermeiden. Sowie dies erreicht ist, wird in die Phase Closing gewechselt.

Phase Closing Hier wird das Ventil geschlossen. Die aufgewendete Zeit wird zur Protokollierung auf eine Variable geschrieben. Sowie das Ventil geschlossen ist, erfolgt der Übergang in die Phase Pause.

Phase Pause Der Full-Stroke-Test pausiert hier 1 s lang, damit der Ventilantrieb eine Pufferzeit zwischen Schließen und Öffnen hat, und wechselt dann in die Phase Opening.

Phase Opening Es erfolgt die Öffnung des Ventils. Die dafür aufge- wendete Zeit wird wieder auf eine Variable geschrieben. Sowie das Ventil geöffnet ist, wechselt der Full-Stroke-Test in die Phase Processing.

Phase Processing Abschließend werden die Laufzeiten protokolliert. Dafür wird ein Array* mit 100 Feldern verwendet. Zunächst werden die vorigen Arrayeinträge um ein Element weiter nach unten verschoben. Das älteste Element wird dabei überschrieben. Anschließend wird das erste Element des Arrays mit Datum, Uhrzeit und den beiden Messwerten für die Laufzeit beschrieben. So werden stets die 100 aktuellsten Testergeb- nisse protokolliert. Danach wird in die Phase Init gewechselt.

4.6 Änderungen an dem Simulationsprogramm

Ferner hat der Autor der Arbeit weitere Änderungen an dem Simulations- programm durchgeführt, um das erstellte Sicherheitsventil zu integrieren.

Im Baustein PLC_PRG wurde das Netzwerk 0007 (s. Abb. 27) ange- legt, welches steuert, wann sich das Ventil schließen oder öffnen soll. Es soll schließen, wenn der Füllstand des Tanks größer ist als 90%, der Sensor DI(3) einen sehr hohen Füllstand meldet, der Full-Stroke-Test das Schlie- ßen des Ventils anfordert oder wenn das Ventil über die Visualisierung von Hand geschlossen werden soll. Anschließend wird das Signal noch in der Ausgangsverarbeitung (Netzwerk 0008) invertiert auf eine bestimmte Adresse geschrieben, mit der sich der Ventilantrieb direkt steuern lässt. Zudem wurden Alarmmeldungen erstellt, die erscheinen, wenn das Ven- til eine längere Laufzeit benötigt als erlaubt, drei Tage sowie einen Tag bevor das Ventil getestet werden muss (s. Abb. 8, 10).

4.7 Visualisierungen

Der Autor der Arbeit hat eine Visualisierung des Full-Stroke-Tests er- stellt, um diese steuern und überwachen zu können. Die Visualisierung „FullStroke“ (s. Abb. 5) zeigt Instrumente zur Steuerung des Full-Stroke- Tests. Oben links befinden sich Schaltflächen zum Starten des Tests, zum Zurücksetzen der Alarmmeldungen, zum Quittieren der Alarmmeldungen und zum Umschalten zwischen der Simulation eines intakten und defek- ten Ventils. Rechts daneben sind Anzeigen zur Laufzeit, zur Zeit nach der letzten Wartung und eine Animation des Ventilantriebs. Darunter sind Tabellen der aktuellen Alarme, ein Protokoll der letzten Tests und die Statustexte des Ventils und des Tests zu sehen. Ganz rechts befindet sich eine Tankfüllstandsanzeige.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Visualisierung des Full-Stroke-Tests.

Darüber hinaus hat der Autor der Arbeit eine weitere Visualisierung „Zufluss“ (s. Abb. 6) erstellt, die den Zufluss in den Behälter anzeigt und steuert. Oben links sind sämtliche Ein- und Ausgänge visualisiert. Da- neben befindet sich eine Animation des Ventilantriebs, eine Anzeige der Laufzeit des Ventils und eine Tankfüllstandsanzeige.

[...]

¹ Eine zeitliche Begrenzung ist hier unabdingbar, damit dem Hauptventilbaustein genügend Zeit gegeben wird, den Timer zurückzusetzen.

² Dieser Sollwert wird hier definiert, da er später im Full-Stroke-Test verändert wird und nach dessen Durchlauf wieder zurückgesetzt werden muss.