Übungsaufgaben zu Schnittstellen und Übertragungsverfahren

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 „Schnittstellen und
Übertragungsverfahren“.

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/schnittstellen-uebertragungsverfahren
- https://oer-informatik.de/rest-grundlagen
- https://oer-informatik.de/mqtt
- https://oer-informatik.de/industrielle-kommunikation
- Stilbeispiel: https://oer-informatik.de/schnittstellen-uebertragungsverfahren-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Schnittstelle
- Push
- Pull
- Polling
- Webhook
- synchron
- asynchron
- Message Broker
- job-orientierte Schnittstelle
- SNMP

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.

Geg.: 12 Räder; Abfrage alle 2 min je Rad; 24 h; 3 Ausleihen je Rad und Tag; 2 Zustandsänderungen je Ausleihe

Ges.: Anzahl der Anfragen n_\text{Pull} (Entwurf 1) und der Meldungen n_\text{Push} (Entwurf 2) je Tag

n_\text{Pull} = \text{Räder} \cdot \frac{\text{Minuten je Tag}}{\text{Intervall}}

n_\text{Pull} = 12 \cdot \frac{24 \cdot 60\ \text{min}}{2\ \text{min}} = 12 \cdot 720 = \underline{\underline{8.640\ \text{Anfragen}}}

n_\text{Push} = \text{Räder} \cdot \text{Ausleihen} \cdot \text{Änderungen je Ausleihe}

n_\text{Push} = 12 \cdot 3 \cdot 2 = \underline{\underline{72\ \text{Meldungen}}}

Bewertung: 1 Punkt Ansatz Polling, 1 Punkt Ergebnis Polling, 1 Punkt Push. Wer nur eine gemeinsame Anfrage für alle Räder annimmt (720 Anfragen), erhält bei richtiger Rechnung ebenfalls volle Punkte.

• Zuordnung (2 Punkte): Entwurf 1 ist Pull (Polling): Das Portal fordert den Zustand selbst an. Entwurf 2 ist Push (Webhook): Der Connect-Server meldet von sich aus, sobald sich etwas ändert.
• Bewertung (1 Punkt): Das Argument ist berechtigt. Ein Webhook-Aufruf, der das Portal nicht erreicht, fehlt dem Portal, und es merkt das nicht von selbst. Polling heilt sich dagegen bei jeder Abfrage selbst.
• Ausgleich (2 Punkte), z. B.: Das Portal ruft beim Start einmal den vollständigen Zustand aller Räder ab (ein einzelner Pull) und verarbeitet danach die Webhooks. Zusätzlich wiederholt der Connect-Server Aufrufe, die nicht mit 2xx bestätigt wurden, für eine begrenzte Zeit. Ein seltener Abgleich (z. B. stündlich) fängt verbliebene Lücken auf.

Je Konfiguration 2 Punkte (1 Punkt Zeitpunkt, 1 Punkt Erläuterung):

• Konfiguration A: um 14:45 Uhr, also 12 Minuten nach der ersten Überschreitung um 14:33 Uhr. Die Störung spielt hier keine Rolle; die Verzögerung entsteht allein durch das Sendeintervall von 15 Minuten. In dieser Zeit lädt der Akku weiter.
• Konfiguration B: gar nicht. Die einzige Alarmmeldung um 14:33 Uhr fällt in die Störung und geht verloren. Weil die Temperatur über 55 °C bleibt, gibt es keine neue Überschreitung und damit keinen weiteren Alarm.

Z. B. eine Kombination aus beiden Verfahren:

• Alarm mit Bestätigung (2 Punkte): Bei Überschreitung von 55 °C sendet der Sensor sofort einen Alarm, den der Connect-Server bestätigen muss. Ohne Bestätigung wiederholt er ihn (z. B. jede Minute), solange die Temperatur zu hoch ist. Zusätzlich bricht die Ladestation das Laden selbst ab, ohne auf den Server zu warten.
• Lebenszeichen (2 Punkte): Der Sensor meldet regelmäßig (z. B. alle 5 Minuten) die aktuelle Temperatur. Bleibt diese Meldung aus, kennzeichnet der Connect-Server den Sensor als gestört und lässt das Laden vorsorglich stoppen bzw. alarmiert die Bereitschaft.

Andere sinnvolle Kombinationen (z. B. Vorwarnung ab 50 °C, Werte erst nach bestätigter Übertragung löschen) sind ebenfalls richtig.

• Laufzeiten (1 Punkt): Meldung 2381: 07:58:44,950 − 07:58:10,204 = 34,746 s. Meldung 2382: 07:58:31,402 − 07:58:31,118 = 0,284 s.
• Erläuterung (2 Punkte): Die Ladestation sendet asynchron, ohne auf eine Bestätigung zu warten. Meldung 2381 war über 34 Sekunden unterwegs (z. B. Funkloch, Wiederholung nach Timeout) und wurde von der später gesendeten Meldung 2382 überholt. Der Server übernimmt einfach die zuletzt eingetroffene Meldung als aktuellen Zustand, ohne die Sequenznummer zu beachten.

• Beurteilung (1 Punkt): Der Vorschlag hilft nicht. Nach dem Eintreffen geordnet, liegt 2381 nach 2382; genau das ist schon jetzt der Fehler.
• Regel (2 Punkte): Der Server speichert je Schloss die höchste bereits verarbeitete Sequenznummer. Er übernimmt eine Meldung nur, wenn ihre Sequenznummer höher ist; ältere Meldungen protokolliert er, ändert den Zustand aber nicht. Meldung 2381 wäre dann verworfen worden, weil 2382 schon verarbeitet war.

Auch ein Zeitstempel, den das Schloss beim Erzeugen setzt (bei synchronisierten Uhren), ist als Regel richtig.

• Problem (1,5 Punkte): Geht nicht die Meldung, sondern nur die Bestätigung verloren, sendet die Ladestation dieselbe Meldung ein zweites Mal – sie kommt doppelt an (Zustellgarantie „mindestens einmal“). Ohne Vorkehrung würde z. B. eine Rückgabe doppelt gezählt oder eine Störung zweimal gemeldet.
• Umgang (1,5 Punkte): Der Server arbeitet idempotent: Er erkennt die Wiederholung an der eindeutigen Kennung (Schloss plus Sequenznummer), bestätigt sie erneut, verarbeitet sie aber kein zweites Mal.

Reihenfolge (2 Punkte): Händlerportal → Warenwirtschaft (ERP) → MES mes01 → OPC-UA-Server der SPS → Rohrbiegemaschine 2

Übergänge (je 1 Punkt), z. B.:

• Händlerportal → ERP: die Bestellung mit Kundennummer des Händlers, Rahmenmaßen, Farbe und Menge;
• ERP → MES: der Fertigungsauftrag mit Auftragsnummer, Maßen und gewünschtem Termin;
• MES → OPC-UA-Server: die Parameter des eingeplanten Arbeitsgangs (z. B. Rohrlängen und Biegewinkel) für die Maschine;
• OPC-UA-Server/SPS → Rohrbiegemaschine: Steuerbefehle an die Antriebe; zurück fließen Ist-Werte wie der aktuelle Biegewinkel.

Geeignet ist die job-orientierte Schnittstelle (1 Punkt). Begründung (2 Punkte): Um 01:30 Uhr ist mes01 in Wartung; ein synchroner Aufruf würde scheitern und müsste von jedem Händlerportal selbst wiederholt werden, während ein Job angenommen wird und nach der Wartung abgearbeitet werden kann (vorausgesetzt, die Annahme der Jobs läuft während der Wartung weiter oder die Übertragung wird auf nach 03:00 Uhr gelegt). Außerdem lassen sich 400 Positionen in einem Job bündeln, statt 400 Aufrufe einzeln auf ihre Antwort warten zu lassen. Dass das Ergebnis erst später kommt, stört nachts nicht.

• Auswahl und Begründung (2 Punkte): synchrone Schnittstelle, weil der Termin noch im laufenden Bestellvorgang gebraucht wird und nur die synchrone Antwort ihn sofort liefert; bei einer einzelnen Bestellung fällt die Wartezeit auf die Antwort kaum ins Gewicht.
• Verhalten im Wartungsfenster (2 Punkte), z. B.: Der Shop erkennt den Fehler (Timeout bzw. 503) und blockiert die Bestellung nicht, sondern zeigt die übliche Lieferzeit von 6–8 Wochen an und vermerkt „Termin folgt per E-Mail“. Die Bestellung kommt in eine eigene Warteschlange und wird nach 03:00 Uhr übertragen (z. B. über die job-orientierte Schnittstelle); der verbindliche Termin wird nachgereicht.

Eine begründete Entscheidung für die job-orientierte Schnittstelle mit sofort angezeigter Standardlieferzeit wird ebenfalls anerkannt, wenn der Konflikt mit Sophies Wunsch benannt wird.

Je Vorfall 1 Punkt Ursache, 2 Punkte Maßnahme, z. B.:

• Vorfall 1: Der erste Aufruf ist im MES angekommen und wurde verarbeitet, nur die Antwort kam nicht rechtzeitig zurück. Der Shop hat nach dem Timeout erneut gesendet, und das MES hat einen zweiten Auftrag angelegt. Maßnahme: Der Shop sendet einen eindeutigen Idempotenzschlüssel mit (z. B. Bestellnummer plus Position). Das MES erkennt eine Wiederholung daran, legt keinen zweiten Auftrag an und liefert die Antwort des ersten Aufrufs.
• Vorfall 2: Die Bestellungen fielen in das Wartungsfenster. Der Shop setzt den Status, ohne die Antwort auszuwerten; 503 bedeutet aber, dass nichts übernommen wurde. Maßnahme: Den Status „übertragen“ erst nach einer Erfolgsantwort (201) setzen; fehlgeschlagene Aufrufe in eine Warteschlange legen und nach 03:00 Uhr automatisch wiederholen, bei dauerhaftem Fehler das Team benachrichtigen.

Das Sequenzdiagramm stellt Vorfall 1 und die Maßnahme gegenüber:

Je Vorteil 2 Punkte, z. B.:

• Entkopplung bei Ausfall: Ist die Warenwirtschaft gerade nicht erreichbar (Wartung, Netzstörung), speichert der Broker die Meldungen und stellt sie später zu. Bei einem synchronen Aufruf müsste das MES selbst puffern und wiederholen.
• Keine Wartezeit im MES: Das MES schickt die Meldung ab und arbeitet sofort weiter; die Fertigung wird nicht durch Antwortzeiten der Warenwirtschaft gebremst.
• Weitere Empfänger ohne Umbau: Auch der Kundenservice, ein Dashboard oder die Versandabteilung können die Meldungen abonnieren, ohne dass das MES geändert werden muss.

Hinweis: Damit die Reihenfolge der Meldungen eines Auftrags erhalten bleibt, sollten sie eine Sequenznummer tragen oder im Broker in einer gemeinsamen, geordneten Warteschlange je Auftrag laufen.

• Regelmäßiges Lesen alle 100 ms: Pull (Polling), weil das MES jeden Wert anfordert (1 Punkt).
• Abonnement: Push bzw. ereignisgesteuert, weil der Server Änderungen von sich aus meldet (1 Punkt). (Technisch holt der OPC-UA-Client die Benachrichtigungen über vorab gestellte Publish-Anfragen ab, ähnlich wie beim Long Polling; fachlich bestimmt aber der Server, wann gemeldet wird.)
• Begründung (1 Punkt): Das Abonnement belastet das Netz weniger, weil nur bei einer Änderung über der Schwelle (0,1°) übertragen wird; steht die Maschine still, entsteht fast kein Verkehr, während beim Polling immer zehn Anfragen pro Sekunde laufen.

• Beurteilung (2 Punkte): reicht nicht. Die regelmäßige Abfrage ist Pull (Polling): Bei einem Abstand von fünf Minuten kann ein Ausfall bis zu fünf Minuten unbemerkt bleiben. Ein Abfrageintervall von unter einer Minute für alle Switches würde Netz und Überwachungsserver unnötig belasten.
• Traps (2 Punkte): Ein Trap ist Push: Der Switch (Agent) meldet ein Ereignis wie „Link down“ sofort von sich aus an das Überwachungsprogramm (Manager, UDP-Port 162). Die Meldung kommt ohne Abfrage innerhalb von Sekunden an.
• Schwäche (1 Punkt): Traps werden per UDP ohne Bestätigung gesendet und können verloren gehen; fällt der Switch ganz aus, sendet er gar nichts mehr. Deshalb kombiniert man Traps mit einer seltener laufenden Abfrage (bzw. nutzt bestätigte Informs ab SNMPv2c) – wie beim Alarm mit Lebenszeichen in Aufgabe 3.1 bb.