Übungsaufgaben zur industriellen Kommunikation

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 „Industrielle Kommunikation“.

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

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Automatisierungspyramide
- Echtzeit
- Modbus
- EtherCAT
- OPC UA
- PubSub
- MQTT
- SNMP
- Industrie 4.0

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 Fehler 1 Punkt für das Finden, 1 Punkt für richtige Ebene mit Begründung:

• Nr. 3 gehört auf Ebene 3 (Prozessleitebene): Anlagen bildlich darstellen, beobachten und Alarme bedienen ist die Aufgabe von SCADA bzw. Leitstand; geplant wird dort nichts.
• Nr. 6 gehört auf Ebene 5 (Feldebene): Der Umrichter führt nur aus, was die SPS vorgibt, und stellt den Motor – er ist ein Antrieb bzw. Aktor, keine Steuerung.

Je Funktion 1 Punkt Ebene, 1 Punkt Begründung:

1. Steuerungsebene (SPS des Ofens): Die Reaktion muss innerhalb eines Steuerungszyklus erfolgen und betrifft nur diese eine Anlage. Ein Umweg über Leitstand oder MES würde Zeit kosten und den Ofen von der Verfügbarkeit weiterer Systeme abhängig machen.
2. Betriebsleitebene (MES): Für die Reihenfolge braucht es alle offenen Aufträge mit Farbe und Termin sowie den Belegungsplan der Kabine; geplant wird für Stunden bis einen Tag im Voraus. Die SPS sieht nur den aktuellen Rahmen, das ERP kennt die Kabinenbelegung nicht.
3. Prozessleitebene (Leitstand/SCADA): Anzeigen, Alarmieren und Quittieren durch Menschen ist Bedienen und Beobachten; eine Reaktion im Sekundenbereich genügt.

• Die Aussage ist falsch (1 Punkt): REST über HTTP ist zustandslos, OPC UA dagegen zustandshaltend.
• Richtigstellung (2 Punkte): MES und SPS bauen eine dauerhafte Verbindung mit sicherem Kanal und Sitzung auf. Der Server merkt sich, wer angemeldet ist und mit welchen Rechten, welche Werte das MES abonniert hat (Subscription) und welche Änderungsmeldungen schon zugestellt sind. Ändert sich ein abonnierter Wert, meldet die SPS ihn von sich aus – das MES muss nicht jedes Mal neu fragen.

Je Angabe 1 Punkt (drei Angaben), z. B.:

• Datentyp (z. B. Double) – das MES muss nicht raten, wie die 16 Bit zu deuten sind;
• Einheit (z. B. A) bzw. Wertebereich;
• Zeitstempel der Messung bzw. der Quelle;
• Statuscode (gut, unsicher, schlecht), z. B. bei einem defekten Sensor;
• Name und Stellung im Adressraum (der Strom gehört zum Objekt Schweißzelle S1), Beschreibung, Zugriffsrechte.

Vorteil (1 Punkt): OPC UA beschreibt die Daten semantisch in einem standardisierten Informationsmodell. Das MES kann den Adressraum durchsuchen und versteht die Werte ohne Registertabelle aus dem Handbuch; Maschinen verschiedener Hersteller lassen sich einheitlich anbinden, und Fehler durch falsch gedeutete Register entfallen.

1 Punkt für Client-Server, 1 Punkt für Broker, 1 Punkt für die Änderung durch die fünfte Anwendung. Fazit: Mit Broker wächst die Last der Steuerungen nicht, wenn neue Empfänger hinzukommen, und an den Steuerungen muss nichts umkonfiguriert werden.

• Der Einwand ist berechtigt (1 Punkt): Fällt der Broker aus, erhalten alle vier Anwendungen keine Daten mehr; er ist ein zusätzliches System, das betrieben, aktualisiert und abgesichert werden muss.
• Gegenmaßnahmen (2 Punkte, zwei davon): Broker redundant betreiben (Cluster bzw. zweiter Broker), Zustand überwachen, Zugang nur mit Zertifikat bzw. Anmeldung und Schreibrechte je Topic begrenzen; die Steuerungen selbst laufen weiter, weil ihre Regelung nicht vom Broker abhängt.

Je richtiger Zeile mit passender Begründung 1 Punkt:

Je Zeile 1 Punkt (Kategorie mit stimmiger Begründung; andere gut begründete Einordnungen sind ebenfalls richtig):

• Der Mittelwert sagt nichts darüber, ob jede Übertragung ihre Frist einhält (1 Punkt). Im Büronetz teilen sich die Achsdaten Puffer und Leitungen mit anderem Verkehr; einzelne Pakete können deutlich später ankommen (Jitter).
• Für die Biegelinie ist eine verpasste Frist ein Fehler mit Folgen (harte Echtzeit): Die Achsen laufen auseinander, das Rohr wird bei der Übergabe verbogen oder die Maschinen beschädigt (1 Punkt).
• Nötig ist deshalb ein Netz, das eine Höchstzeit garantiert (Determinismus) und die Achsen synchronisiert – die Aussage ist so nicht haltbar (1 Punkt).

• Prozessdaten: 14 · 12 Byte = 168 Byte; Frame: 168 Byte + 40 Byte = 208 Byte (1 Punkt)
• 208 Byte · 8 bit/Byte = 1.664 bit (1 Punkt)
• Sendedauer: 1.664 bit / (100 · 10⁶ bit/s) = 16,64 · 10⁻⁶ s = 16,64 µs (1 Punkt)

• EtherCAT (2 Punkte): Der Frame wird einmal ausgesendet und von jedem Antrieb nur kurz aufgehalten: 16,64 µs + 14 · 0,6 µs = 16,64 µs + 8,4 µs = 25,04 µs.
• Vollständig empfangen, dann weitersenden (2 Punkte): Der Master sendet den Frame (16,64 µs), danach sendet jeder der 14 Antriebe ihn noch einmal vollständig: 15 · 16,64 µs = 249,6 µs. (Die Verarbeitungszeit in den Geräten käme noch hinzu.)
• Das Weitersenden dauert damit rund zehnmal so lange.

• Mit EtherCAT ist der Datenaustausch nach rund 25 µs erledigt; vom 250-µs-Zyklus bleibt viel Reserve für die Berechnung in der Steuerung (1 Punkt).
• Beim vollständigen Empfangen und Weitersenden wären bereits 249,6 µs für die Übertragung verbraucht – ohne Reserve, ohne Rechenzeit, jede Störung würde den Takt sprengen. Das ist ungeeignet (1 Punkt).
• Prinzip „processing on the fly“ (1 Punkt): Jeder Antrieb liest und schreibt seine Daten, während der Frame ihn durchläuft, statt ihn erst zu speichern. Deshalb wächst die Zykluszeit je zusätzlicher Achse nur um die kurze Durchlaufzeit.

• EtherCAT-Frames tragen einen eigenen Ethertype und haben keinen IP-Kopf; die Antriebe sind also im Normalbetrieb gar nicht per IP ansprechbar, und ein Router kann ihnen nichts zustellen (2 Punkte).
• Vorschlag (1 Punkt), z. B.: Diagnosedaten über die Steuerung (EtherCAT-Master) abrufen, die zusätzlich eine IP-Schnittstelle hat (etwa per OPC UA); oder die EtherCAT-Daten per UDP über IP transportieren lassen – jeweils nur über eine Firewall bzw. VPN und ohne Echtzeitanspruch.

• Spannung: 2318 · 0,1 V = 231,8 V (1 Punkt)
• Strom: 1475 · 0,01 A = 14,75 A (1 Punkt)
• Scheinleistung: 231,8 V · 14,75 A ≈ 3.419 VA ≈ 3,42 kVA (1 Punkt)

Modbus überträgt nur nackte 16-Bit-Zahlen unter einer Adresse; Bedeutung, Einheit und Faktor stehen allein im Handbuch und müssen im EMS von Hand hinterlegt werden (1 Punkt). Ein OPC-UA-Server liefert die Bedeutung mit: Der Knoten hat einen Namen, einen Datentyp, eine Einheit und einen Zeitstempel, die das EMS beim Durchsuchen des Adressraums erfährt (1 Punkt).

• Bits je Abfrage: (8 + 29) Byte · 11 bit = 407 bit (1 Punkt)
• Übertragungsdauer: 407 bit / 19.200 bit/s ≈ 21,2 ms; mit Pause 21,2 ms + 8 ms ≈ 29,2 ms je Zähler (1 Punkt)
• acht Zähler: 8 · 29,2 ms ≈ 234 ms (1 Punkt)
• Bewertung (1 Punkt): Ein Durchlauf dauert weniger als eine Viertelsekunde, sekündliche Werte sind also möglich. Mehr Zähler am selben Bus oder mehr Register je Abfrage würden die Reserve aber schnell aufbrauchen.

• Regel 1 ist zu weit (1 Punkt): Jedes Gerät aus jedem Netz könnte die Zähler lesen und beschreiben, obwohl Modbus keine Anmeldung kennt.
• Regel 2 ist unnötig bzw. falsch herum (1 Punkt): Die Zähler bauen keine Verbindungen zum EMS auf; die Antworten lässt die zustandsbehaftete Firewall ohnehin zurück.
• Regel 3 ist wirkungslos (1 Punkt): Modbus TCP nutzt TCP, nicht UDP.
• Nötig ist nur (2 Punkte): erlauben | TCP | 198.51.100.20 | 192.0.2.32/28 | 502, danach Regel 4 (alles andere verbieten). Unterstützen EMS und Zähler Modbus/TCP Security, entsprechend Port 802.

• Folgen (2 Punkte): Der Zähler rechnet mit falschem Faktor und meldet z. B. ein Vielfaches oder einen Bruchteil des tatsächlichen Verbrauchs. Kostenzuordnung je Rahmen und Lastspitzenmeldungen werden falsch, ohne dass es sofort auffällt; Modbus protokolliert nicht, wer geschrieben hat.
• Maßnahmen (je 1 Punkt, zwei davon): Schreibschutz am Zähler aktivieren (Jumper bzw. Parameter-PIN); in einer Modbus-fähigen Firewall nur lesende Funktionscodes zulassen; Zähler per 802.1X ins eigene OT-VLAN und nur vom EMS erreichbar; Modbus/TCP Security mit Zertifikaten und Rollen; Schreibbefehle im OT-Monitoring melden.