Übungsaufgaben zur SPS-Programmierung in ST

Kopiere den Text in ein KI-Sprachmodell Deiner Wahl und passe Kompetenzstufe, Anzahl, Bearbeitungszeit und Szenario bei Bedarf an. Wie die Aufgaben aufgebaut sind, beschreibt der Artikel Wie sind die Aufgaben aufgebaut?. Prüfe die Ergebnisse mit dem Lehrartikel: KI-Sprachmodelle machen Fehler.

Erstelle neue Übungsaufgaben zum Thema „SPS-Programmierung in ST“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/sps-programmierung-st
- https://oer-informatik.de/sps-grundlagen
- https://oer-informatik.de/ablaufsteuerung-grafcet
- https://oer-informatik.de/steuerungssicherheit
- Stilbeispiel: https://oer-informatik.de/sps-programmierung-st-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Strukturierter Text
- Funktionsbaustein
- Instanz
- CASE-Anweisung
- Laufzeitüberwachung
- Simulation
- Interface
- Vererbung
- KI-Assistent
- virtuelle SPS

Kompetenzstufe: Profilkompetenz (alternativ: Basiskompetenz, Kernkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

Je Teilaufgabe 1 Punkt (Zuordnung mit Begründung):

• (1) Umrechnung: Funktion (FUNCTION FC_Feuchte : REAL). Das Ergebnis hängt nur vom Rohwert ab; der Baustein braucht kein Gedächtnis und liefert einen Rückgabewert.

• (2) Schieber: Funktionsbaustein (FUNCTION_BLOCK FB_Schieber). Er muss sich die Störung und die abgelaufene Laufzeit merken (Instanz von TON); jeder der drei Schieber bekommt eine eigene Instanz mit eigenen Daten.

• (3) Zusammenführung: Programm (PROGRAM PRG_Bewaesserung). Es wird von der zyklischen Task aufgerufen, liest Betriebsart und Regen und ruft die drei Instanzen und die Funktion auf.

Geg.: Hub s = 360\ \mathrm{mm}, Geschwindigkeit v = 9\ \mathrm{mm/s}, Zuschlag z = 25\ \% = 0{,}25

Ges.: Überwachungszeit t_\mathrm{\ddot{U}} als TIME-Literal

\begin{aligned} &\text{(I)} && t_\mathrm{F} = \frac{s}{v} \\ &\text{(II)} && t_\mathrm{\ddot{U}} = t_\mathrm{F} \cdot (1 + z) \end{aligned}

I in II (Fahrzeit 1 Punkt, Überwachungszeit 1 Punkt):

t_\mathrm{\ddot{U}} = \frac{s}{v} \cdot (1 + z) = \frac{360\ \mathrm{mm}}{9\ \mathrm{mm/s}} \cdot 1{,}25 = 40{,}0\ \mathrm{s} \cdot 1{,}25 = \underline{\underline{50{,}0\ \mathrm{s}}}

Als TIME-Literal (1 Punkt): T#50S. Die reguläre Fahrzeit beträgt 40 s; erst wenn ein Motor 10 s länger läuft, ohne dass der Endschalter meldet, gilt der Schieber als blockiert.

Beispiellösung (Bewertung: Deklaration mit Eingängen, Ausgängen und statischer TON-Instanz 3 Punkte, Aufruf der Zeit in jedem Zyklus mit Motorlauf als Eingang 2 Punkte, Störspeicher mit Vorrang und Quittierbedingung 2 Punkte, Motorausgänge mit Endlagen und Störung 2 Punkte, Vorrang „schließen“ und gegenseitiger Ausschluss 1 Punkt):

FUNCTION_BLOCK FB_Schieber
// Ansteuerung eines Absperrschiebers mit Endlagen und Laufzeitüberwachung
// Version 1.0
VAR_INPUT
    xOeffnen    : BOOL;            // Befehl öffnen
    xSchliessen : BOOL;            // Befehl schließen (Vorrang)
    xEndAuf     : BOOL;            // Endschalter offen, 1 = erreicht
    xEndZu      : BOOL;            // Endschalter zu, 1 = erreicht
    xQuitt      : BOOL;            // Störung quittieren
    tLaufzeit   : TIME := T#50S;   // Überwachungszeit aus b)
END_VAR
VAR_OUTPUT
    xMotorAuf   : BOOL;            // Schütz "auf"
    xMotorZu    : BOOL;            // Schütz "zu"
    xStoerung   : BOOL;            // Laufzeitstörung gespeichert
END_VAR
VAR
    tonLaufzeit : TON;             // eigene Zeit je Instanz
END_VAR

    // Zeit läuft, solange ein Motor angesteuert ist (Wert aus dem letzten Zyklus)
    tonLaufzeit(IN := xMotorAuf OR xMotorZu, PT := tLaufzeit);

    IF tonLaufzeit.Q THEN
        xStoerung := TRUE;                                   // Vorrang: Störung
    ELSIF xQuitt AND NOT xOeffnen AND NOT xSchliessen THEN
        xStoerung := FALSE;                                  // Quittieren ohne Befehl
    END_IF;

    xMotorZu  := xSchliessen AND NOT xEndZu AND NOT xStoerung;
    xMotorAuf := xOeffnen AND NOT xSchliessen AND NOT xEndAuf AND NOT xStoerung;
END_FUNCTION_BLOCK

Weil xMotorAuf den Term NOT xSchliessen enthält, können beide Ausgänge nie gleichzeitig 1 sein. Die Verriegelung der Schütze über Hilfsöffner bleibt in der Hardware trotzdem bestehen. Andere Lösungen (z. B. mit IF-Zweigen statt Zuweisungen oder mit einer Umschaltpause beim Richtungswechsel) sind gleichwertig, wenn alle Anforderungen erfüllt sind und tonLaufzeit in jedem Zyklus aufgerufen wird.

Beispiellösung (Bewertung: Feld von Instanzen und Schleife 1 Punkt, Zweipunktverhalten mit Hysterese 1 Punkt, CASE mit Hand, Automatik und ELSE-Zweig 2 Punkte, Vorrang Regen 1 Punkt, Aufruf der Instanzen und Zuweisung der Ausgänge 1 Punkt):

PROGRAM PRG_Bewaesserung
VAR
    aSchieber   : ARRAY[1..3] OF FB_Schieber;   // drei Instanzen
    rFeuchte  : REAL;                        // Bodenfeuchte in %
    xAutoAuf  : BOOL;                        // Automatik verlangt "offen"
    xOeff     : BOOL;                        // Befehl für den aktuellen Schieber
    xSchl     : BOOL;
    i         : INT;
END_VAR

    rFeuchte := FC_Feuchte(iRoh := iAI_Feuchte);

    // Zweipunktverhalten: dazwischen bleibt xAutoAuf unverändert
    IF rFeuchte < 30.0 THEN
        xAutoAuf := TRUE;
    ELSIF rFeuchte >= 45.0 THEN
        xAutoAuf := FALSE;
    END_IF;

    FOR i := 1 TO 3 DO
        CASE iBetriebsart OF
            0:  // Hand
                xOeff := axTastAuf[i];
                xSchl := axTastZu[i];
            1:  // Automatik
                xOeff := xAutoAuf;
                xSchl := NOT xAutoAuf;
        ELSE    // ungültige Betriebsart: schließen
                xOeff := FALSE;
                xSchl := TRUE;
        END_CASE;

        IF xRegen THEN          // Vorrang in jeder Betriebsart
            xOeff := FALSE;
            xSchl := TRUE;
        END_IF;

        aSchieber[i](xOeffnen := xOeff, xSchliessen := xSchl,
                   xEndAuf := axEndAuf[i], xEndZu := axEndZu[i],
                   xQuitt := xQuittTaster);
        axMotorAuf[i] := aSchieber[i].xMotorAuf;
        axMotorZu[i]  := aSchieber[i].xMotorZu;
    END_FOR;
END_PROGRAM

Der Befehl „schließen“ darf in der Automatik dauernd anliegen, weil der Baustein den Motor an der Endlage „zu“ abschaltet. Jede Instanz wird in jedem Zyklus genau einmal aufgerufen.

• FUP-Netzwerk (2 Punkte): ein UND-Baustein mit vier Eingängen: xOeffnen direkt, xSchliessen, xEndAuf und xStoerung jeweils negiert (Negationskreis am Eingang). Der Ausgang geht auf die Zuweisung xMotorAuf.

• Vorteil FUP (1 Punkt): Der Signalfluss ist grafisch sichtbar; bei der Fehlersuche sieht die Instandhaltung online sofort, welcher Eingang die Freigabe verhindert.

• Vorteil ST (1 Punkt): Der ganze Baustein mit Störspeicher, Zeit und beiden Richtungen steht kompakt auf wenigen Zeilen, lässt sich kommentieren, als Text vergleichen und mit einer Schleife für alle Schieber wiederverwenden.

Je Testfall 1 Punkt, weitere Angaben 2 Punkte:

Weitere Angaben (je 1 Punkt, zwei genügen): beobachtetes Ergebnis und Bewertung (i. O./n. i. O.) je Testfall, Datum und Name, Programm- bzw. Bausteinversion, verwendete Simulationsumgebung. Die Erwartungswerte wurden vorab mit einer Nachbildung des Bausteins geprüft (Störung nach 50,0 s, vorher nicht).

• Einsatz (2 Punkte): I_Ruehrwerk legt die Methoden Starten, Stoppen und Quittieren als Vertrag fest; FB_Ruehrwerk setzt das Interface um (IMPLEMENTS I_Ruehrwerk). Die Tauchmotor-Rührwerke sind zwei Instanzen von FB_Ruehrwerk. Für das Paddelrührwerk entsteht FB_RuehrwerkReversierbar EXTENDS FB_Ruehrwerk, der Überwachung, Störspeicher und Methoden erbt und nur die Rückwärtsrichtung ergänzt.

• Nutzen (je Argument 1 Punkt): Der geprüfte Basisbaustein wird nicht kopiert und nicht geändert, eine Korrektur wirkt in allen abgeleiteten Bausteinen. Programme, die nur das Interface kennen (z. B. „alle Rührwerke stoppen“ in einer Schleife über ARRAY OF I_Ruehrwerk), funktionieren mit jedem neuen Rührwerkstyp unverändert. Auch genannt werden kann: einheitliche Bedienung und Visualisierung aller Rührwerke, getrennte Tests von Basis- und Zusatzfunktion.

Beispiellösung in der Schreibweise der Norm (Bewertung: Interface mit drei Methoden 1 Punkt, EXTENDS mit neuem Ausgang und geschützter Variable 1 Punkt, StartenRueck mit Verriegelung und Rückgabewert 2 Punkte, Stoppen mit OVERRIDE und Aufruf der Basismethode 1 Punkt, Rumpf mit Ansteuerung des Rückwärts-Schützes und Aufruf des Basisrumpfs 1 Punkt):

INTERFACE I_Ruehrwerk
    METHOD Starten : BOOL
    END_METHOD
    METHOD Stoppen
    END_METHOD
    METHOD Quittieren
    END_METHOD
END_INTERFACE

FUNCTION_BLOCK FB_RuehrwerkReversierbar EXTENDS FB_Ruehrwerk
VAR_OUTPUT
    xMotorRueck  : BOOL;          // Schütz rückwärts
END_VAR
VAR PROTECTED
    xBefehlRueck : BOOL;          // gespeicherter Rückwärtsbefehl
END_VAR

    SUPER^();                     // Rumpf des Basisbausteins (Überwachung, xMotor)
    xMotorRueck := xBefehlRueck AND NOT xBefehl AND NOT xStoerung;

    METHOD PUBLIC StartenRueck : BOOL
        IF NOT xStoerung AND NOT xBefehl THEN   // Verriegelung gegen vorwärts
            xBefehlRueck := TRUE;
        END_IF;
        StartenRueck := xBefehlRueck;
    END_METHOD

    METHOD PUBLIC OVERRIDE Stoppen
        xBefehlRueck := FALSE;
        SUPER^.Stoppen();         // vorwärts wie im Basisbaustein beenden
    END_METHOD
END_FUNCTION_BLOCK

SUPER^ ist die Schreibweise verbreiteter Entwicklungsumgebungen (z. B. CODESYS) für den Zugriff auf den Basisbaustein. Damit auch Starten (vorwärts) gegen einen laufenden Rückwärtsbetrieb verriegelt ist, kann es ebenfalls überschrieben werden (zusätzliche Bedingung NOT xBefehlRueck); die Überwachung der Rückmeldung muss beide Richtungen erfassen. Beides wird bei der vollständigen Lösung erwartet, hier aber nicht bepunktet.

Je Fehler 1 Punkt, je passender Korrektur 1 Punkt:

1. Falscher Vorrang: xStart steht im ersten Zweig und gewinnt. Bei gedrücktem Ein-Taster läuft der Motor, obwohl der Aus-Taster betätigt oder der Motorschutz ausgelöst ist (setzdominant). Korrektur: Abschaltbedingung zuerst prüfen (IF NOT xAus OR NOT xMotorschutz OR xStoerung THEN xMotor := FALSE; ELSIF xStart THEN xMotor := TRUE; END_IF;).

2. Zeitglied nur bedingt aufgerufen: tonUeberwach wird nur im IF-Zweig und immer mit IN := TRUE aufgerufen. Kommt die Rückmeldung, wird die Zeit nie zurückgesetzt; beim nächsten Fehlerfall ist sie schon abgelaufen oder wird falsch weitergezählt. Korrektur: in jedem Zyklus aufrufen, tonUeberwach(IN := xMotor AND NOT xRueckmeld, PT := T#3S); (besser xMotor XOR xRueckmeld, dann wird auch ein verschweißter Kontakt erkannt).

3. Störung ohne Wirkung und ohne Rücksetzen: xStoerung schaltet den Motor nicht ab und wird nie zurückgesetzt. Korrektur: xStoerung in die Abschaltbedingung aufnehmen (siehe 1.) und einen Quittiereingang ergänzen, der die Störung nur ohne Startbefehl zurücksetzt.

4. Warteschleife auf einen Eingang: Die WHILE-Schleife wartet innerhalb eines Zyklus auf xRueckmeld. Das Prozessabbild ändert sich während des Zyklus nicht; die Schleife endet nie, und die Zykluszeitüberwachung stoppt die CPU. Korrektur: Schleife ersatzlos streichen; das Warten übernimmt das Zeitglied, das in jedem Zyklus neu abgefragt wird.

Vor dem Einsatz wird der korrigierte Baustein mit eigenen, aus den Anforderungen abgeleiteten Testfällen in der Simulation getestet; die KI-Ausgabe ersetzt diese Prüfung nicht.

Beispielhafte Beurteilung (je Chance und Grenze 1 Punkt, Sicherheitsfunktionen 1 Punkt, begründete Empfehlung 1 Punkt):

• Chancen: Die Hardware ist austauschbar und kann zentral gesichert und aktualisiert werden; die Bausteinbibliothek läuft in derselben Laufzeitumgebung wie beim Test in der Simulation; Betriebsdaten (Rührzeiten, Störungen, Gasertrag) lassen sich ohne zusätzliche Kopplung auswerten; mehrere Anlagenteile können auf einem Rechner laufen.

• Grenzen: Die Echtzeit hängt von Rechner, Virtualisierung und Netzwerk ab; Ein- und Ausgänge im Fermenterbereich laufen über einen Feldbus, dessen Ausfall die ganze Anlage betrifft; der Industrie-PC muss gepatcht und gegen Angriffe geschützt werden, was IT-Wissen beim Betreiber verlangt; im landwirtschaftlichen Betrieb ist Personal für die Störungsbehebung oft nicht sofort verfügbar.

• Sicherheitsfunktionen: Gaswarnanlage, Überdrucksicherung und NOT-HALT müssen unabhängig von der Prozesssteuerung wirken und bleiben auf zertifizierter Sicherheitstechnik (Sicherheitsschaltgerät, Sicherheits-SPS bzw. zugelassene virtuelle Sicherheitssteuerung) sowie auf mechanischen Sicherungen. Sie gehören nicht in die Bausteinbibliothek der Prozesssteuerung.

• Empfehlung (Beispiel): Die Prozesssteuerung der Rührwerke kann als virtuelle SPS laufen, wenn eine Ersatzhardware und eine geprüfte Sicherung bereitstehen, der Feldbus redundant bzw. überwacht ist und Zuständigkeiten für IT-Sicherheit geklärt sind. Die Sicherheitsfunktionen bleiben getrennt. Auch eine begründete Ablehnung (z. B. wegen fehlender IT-Betreuung) ist richtig.