aiMOOC

Roboter- und Steuerungsabläufe in Simulationen programmieren

QR-Code

Einleitung

Du entwickelst einen Offline-Zustandsautomaten für einen fiktiven Modellroboter in einem lokalen Prüf- und Wartungslabor. Der Modellroboter sortiert lediglich symbolische Variantenbauteile A und B; keine Motoren, Sensoren oder Anlagen werden angeschlossen. Im Mittelpunkt stehen digitale Ablaufmodelle, nachvollziehbare Entscheidungen, kontrollierte Simulationsversuche und dokumentierte Fehlertests. Das Produkt funktioniert lokal mit Python 3 oder als händisch ausgeführte Zustandstabelle, ohne bezahltes KI-Konto.

Zielgruppe: Auszubildende, empfohlen im 3. Ausbildungsjahr. Voraussetzungen: A1 und A2 sowie fachliche Grundlagen des Modellfalls. Die bestehende Grundlage hier aktivieren: Beschreibe in drei Sätzen Zustand, Ereignis und Prüfprotokoll. Der externe Abruf dieser Grundlage war beim Recherchezeitpunkt technisch nicht möglich; deren konkrete Aussagen werden deshalb nicht unterstellt. Danach entsteht das neue Lernprodukt. Lernziele: Übergänge entwerfen, Fehlerfälle begründen, STOP ohne Auto-Neustart nachweisen, manuellen Reset prüfen und eine Kontrollinstanz unabhängig von KI-Agenten argumentieren.

Geltungsbereich: Ausschließlich didaktische Simulation. Kein Not-Halt-Nachweis, keine funktionale Sicherheitsbewertung, keine Inbetriebnahme, keine reale Roboter- oder SPS-Steuerung. Eigenständiges Bildungsangebot ohne offizielle Zertifizierung durch Liebherr oder die IHK. Offline-Alternative zu jedem externen Medium: Beschreibung, Zustandstabelle, Pseudocode und Testsequenzen auf dieser Seite.

Digitale Abläufe im fiktiven Prüflabor

Modellfall und Begriffe

Im Prüflabor Variantix liegen nur künstliche Dokumente und Ereignisse vor. Bauteil V-A hat den Prüfcode A, Bauteil V-B den Code B. Der Modellroboter besitzt weder echte Achsen noch Greifer. Die Ausgabe „GREIFEN“ ist eine Zeichenkette im Protokoll, niemals ein Gerätebefehl. Ein Zustand beschreibt, was als Nächstes zulässig ist; ein Ereignis ist die beobachtete Eingabe; eine Übergangsfunktion bestimmt den nächsten Zustand; ein Guard ist eine zusätzliche Bedingung für den Übergang.

Ein digitaler Zwilling kann Daten, Struktur und Verhalten eines betrachteten Objekts beschreiben; unser Zustandsautomat ist dagegen zunächst ein isoliertes, vereinfachtes Ablaufmodell, nicht automatisch ein vollständiger digitaler Zwilling. Modelle behaupten keine physische Sicherheit. Die Downloadübersicht der Industrial Digital Twin Association dient als Rechercheeinstieg für dokumentierte Modelle, Schnittstellen und Versionen. Einzelne Spezifikationen müssen vor fachlicher Übernahme anhand ihres Ausgabestands geprüft werden.

Abbildung eines industriellen Roboterarms als Anschauung für den Unterschied zwischen realem Gerät und reinem Ablaufmodell

Abbildung: Industrieller Roboterarm als Anschauung, nicht als Versuchsaufbau. Quelle: Wikimedia Commons, Jo Teichmann/KUKA Roboter GmbH und Tony Wills, Public Domain.

Drei Abgrenzungen

Simulation berechnet Zustandswechsel mit synthetischen Ereignissen. Emulation ahmt eine Schnittstelle oder ein Gerät funktional nach, ohne es zwingend physisch zu besitzen. Reale Steuerung wirkt auf Anlagen und benötigt eigene technische, organisatorische und rechtliche Prüfungen. Ein softwareseitiger STOP in diesem Kurs ist kein physischer Not-Halt. Das zugehörige Foto erläutert nur eine abweichende reale Schutzfunktion.

Abbildung: Physische Not-Halt-Bedieneinrichtung als Abgrenzung vom Softwarezustand STOP; Commons-Dateiseite, Biso, CC BY-SA 4.0.

Kurzaktivierung: Zeichne vier Karten „Zustand“, „Ereignis“, „Guard“ und „Protokoll“. Erkläre, warum eine Zustandsänderung ohne verzeichnetes Ereignis nicht nachvollziehbar wäre.

Zustandsmodell und prüfbare Regeln

Zustandsdiagramm lesen

Unser deterministischer Automat verwendet INIT, BEREIT, PRUEFEN, FERTIG und STOP. Deterministisch bedeutet: Für denselben Zustand, dieselbe Eingabe und dieselben Prüfbedingungen entsteht genau ein definierter Folgezustand. Beim erstmaligen Start bleibt das Modell INIT, bis BOOT_OK als künstliches Prüfergebnis eingeht. Nur aus BEREIT kann START die Simulation PRUEFEN eröffnen. PRUEF_OK führt zu FERTIG, danach ACK zu BEREIT. Unbekannte Eingaben oder widersprüchliche Prüfinformationen führen konservativ zu STOP.

Abbildung: Allgemeine Zustandsmaschine, nicht unser Prüflabor: Commons-Dateiseite, MicroBeaut, CC BY-SA 4.0.

Aktueller Zustand	Ereignis und Bedingung	Neuer Zustand	Begründung
INIT	BOOT_OK	BEREIT	Erst dokumentiert freigeben
BEREIT	START	PRUEFEN	Simulation starten
PRUEFEN	PRUEF_OK	FERTIG	Synthetischen Prüfschritt abschließen
FERTIG	ACK	BEREIT	Abschluss quittiert, kein Bewegungsbefehl
Jeder Zustand	FEHLER, TIMEOUT oder SENSOR_KONFLIKT	STOP	Fehler hat Vorrang
STOP	START, AGENT_START oder ZEIT_ABGELAUFEN	STOP	Kein automatischer Neustart
STOP	RESET_MANUELL und Prüfung OK und Fehler behoben	BEREIT	Getrennte Freigabe, noch kein START
STOP	RESET_MANUELL ohne beide Freigaben	STOP	Abgelehnter Reset

Die drei verbindlichen Kriterien

Kriterium A – Fehler führt STOP: Der Ablauf BEREIT → START → PRUEFEN → SENSOR_KONFLIKT muss in STOP enden. Die Modellaktion bleibt danach AUS. Ein Fehlerereignis hat Priorität vor „Prüfung bestanden“.

Kriterium B – kein Auto-Neustart: Nach STOP dürfen ein Zeitablauf, eine wieder normale Testmessung und auch der Vorschlag AGENT_START den Zustand nicht verändern. Selbst nach geprüftem Reset muss ein neues menschliches START-Ereignis folgen.

Kriterium C – manueller Reset geprüft: Nur das gesonderte Ereignis RESET_MANUELL zusammen mit den dokumentierten Booleschen Prüfergebnissen „Ursache behoben“ und „Prüfung OK“ führt nach BEREIT; ohne Nachweise bleibt STOP erhalten. Diese Kursbedingungen sind Modellregeln und keine reale Sicherheitsfreigabe.

Abbildung: Logik und Speicher einer Zustandsmaschine als Vertiefung; Commons, jjbeard und Perhelion, Public Domain.

Denkhilfe: Male STOP rot und markiere sämtliche dorthin führenden Kanten. Vertiefung: Formuliere die Invariante: Für jeden Zustand s und jedes Fehlerereignis f ist delta(s,f)=STOP. Zeige zusätzlich: Ohne gesondertes RESET_MANUELL kann von STOP niemals zu BEREIT gewechselt werden.

Geführtes Offline-Programm und Fehlertests

Das ausführbare Modell

Speichere den folgenden selbstständigen Beispielcode als modellroboter.py und führe ihn lokal mit python3 modellroboter.py aus. Er liest keine Dateien, nutzt keine Netzwerkschnittstelle und steuert keine Hardware. Alle Ereignisse sind feste, erfundene Zeichenfolgen. Die Rückgabe ist jeweils nur ein Zustand.

STOP = "STOP"
ZUSTAENDE = {"INIT", "BEREIT", "PRUEFEN", "FERTIG", STOP}
FEHLER = {"FEHLER", "TIMEOUT", "SENSOR_KONFLIKT"}

def schritt(zustand, ereignis, pruefung_ok=False,
            fehler_behoben=False):
    if zustand not in ZUSTAENDE:
        return STOP
    if ereignis in FEHLER:
        return STOP
    if zustand == STOP:
        if (ereignis == "RESET_MANUELL"
                and pruefung_ok and fehler_behoben):
            return "BEREIT"
        return STOP
    erlaubte = {
        ("INIT", "BOOT_OK"): "BEREIT",
        ("BEREIT", "START"): "PRUEFEN",
        ("PRUEFEN", "PRUEF_OK"): "FERTIG",
        ("FERTIG", "ACK"): "BEREIT",
    }
    return erlaubte.get((zustand, ereignis), STOP)

def spur(start, ereignisse):
    zustand = start
    for ereignis in ereignisse:
        zustand = schritt(zustand, ereignis)
        print(ereignis, "=>", zustand)
    return zustand

if __name__ == "__main__":
    assert spur("INIT", [
        "BOOT_OK", "START", "SENSOR_KONFLIKT"]) == STOP
    assert schritt(STOP, "START") == STOP
    assert schritt(STOP, "AGENT_START") == STOP
    assert schritt(STOP, "ZEIT_ABGELAUFEN") == STOP
    assert schritt(STOP, "RESET_MANUELL",
                   True, False) == STOP
    assert schritt(STOP, "RESET_MANUELL",
                   False, True) == STOP
    assert schritt(STOP, "RESET_MANUELL",
                   True, True) == "BEREIT"
    assert schritt("BEREIT", "AGENT_START") == STOP
    assert schritt("BEREIT", "START") == "PRUEFEN"
    print("Alle neun Modellprüfungen erfolgreich.")

Geführtes Durchspielen: (1) INIT + BOOT_OK → BEREIT; (2) BEREIT + START → PRUEFEN; (3) PRUEFEN + SENSOR_KONFLIKT → STOP; (4) STOP + AGENT_START → STOP; (5) STOP + RESET_MANUELL ohne behobene Ursache → STOP; (6) STOP + RESET_MANUELL mit beiden Nachweisen → BEREIT. Wichtig: Die letzte Zeile ist noch kein automatischer Neustart. Erst ein neues START führt zu PRUEFEN.

Testorakel und Negativtest

Ein Testorakel ist die vor dem Test festgelegte erwartete Ausgabe. Die Python-Anweisungen assert vergleichen das reale Simulationsergebnis mit diesem Sollwert; eine verletzte Behauptung bricht das Programm mit einem Fehler ab. Ein Negativtest übergibt gezielt unerwünschte oder ungültige Eingaben. Teste absichtlich den Programmfehler, in der STOP-Zeile blind „return BEREIT“ einzusetzen: Ein Test muss nun fehlschlagen. Stelle den korrekten Code danach wieder her.

Test-ID	Vorher	Eingabe und Bedingungen	Erwartung	Beweisart
T01	PRUEFEN	FEHLER	STOP	Fehlerpriorität
T02	STOP	AGENT_START	STOP	Kein Agenten-Neustart
T03	STOP	ZEIT_ABGELAUFEN	STOP	Kein Zeit-Neustart
T04	STOP	RESET_MANUELL, Prüfung wahr, Fehler behoben falsch	STOP	Rücksetzung abgelehnt
T05	STOP	RESET_MANUELL, Prüfung wahr, Fehler behoben wahr	BEREIT	Geprüfter Reset
T06	BEREIT	AGENT_START	STOP	Unbekannter Automatikimpuls löst Modellfehler aus
T07	BEREIT	START	PRUEFEN	Expliziter Neustart

Barrierefrei und offline: Auch ohne Python kannst du die Tabellen Zeile für Zeile auf Papier ausführen. Das GIF zu einem einfachen Laufmechanismus stammt von MichaelFrey, CC BY-SA 4.0; für diesen Kurs muss es nicht abgespielt werden, denn die Zustände und alle Tests stehen in Textform bereit.

Animation eines schematischen Gehmechanismus; reine Bewegungsillustration ohne Steuerschnittstelle

Animation: Laufmechanik als Anschauung von Ablauf und Schrittfolge, nicht als Darstellung unseres Zustandsautomaten.

Versionierte Prüfdokumente und kontrollierte Versuche

Belegbare Änderungen

Für das Labor existieren als synthetische Dokumente folgende logische Artefakte. „Version“ bezeichnet die Ausgabe eines Dokuments, „Testfall“ dessen Eingaben und Soll-Ergebnis. Die Einträge sind hier vollständig lesbar und können ohne Dateien abgetippt werden.

Dokument	Ausgabe	Inhalt	Änderungsregel
modellfall.md	v1.0	Bauteile V-A und V-B, nur Textausgaben	Änderungen schriftlich begründen
uebergaenge.csv	v1.0	Zustands- und Ereignispaare aus der Tabelle	Neue Regeln brauchen Negativtests
prueffaelle.csv	v1.1	T01 bis T07 mit erwartetem Zustand	Sollwerte vor Ausführung fixieren
bericht.md	v1.0	Datum, Codeversion, Prüfergebnis, Abweichung	Jede Abweichung mit Ursache protokollieren

Ein Trace ist eine zeitlich geordnete Spur von Eingaben und Resultaten. Verwechsele einen dokumentierten Trace nicht mit dem Nachweis, dass ein reales Gerät sicher betrieben werden darf. Beispielmeldung: „Prüffall T04, Startzustand STOP, Ereignis RESET_MANUELL, pruefung_ok=True, fehler_behoben=False; Ergebnis STOP; Soll STOP; bestanden.“ Dadurch lässt sich die Entscheidung nachvollziehen.

Kontrollierter Versuch statt bloßem Demo-Lauf

Lege vor dem ersten Durchlauf die Sollzustände T01–T07 fest. Führe danach alle Fälle aus, notiere die Istzustände, markiere Übereinstimmungen und beschreibe Abweichungen. Ändere anschließend genau eine Regel, etwa die Behandlung eines unbekannten Ereignisses, und wiederhole die gesamte Testreihe. Ein solches Regressionstest-Verfahren zeigt, ob zuvor bestandene Fälle verletzt werden.

Wenn später statistische Modelle zur Anomalieerkennung eingesetzt werden, gilt: Training und Test müssen sauber getrennt sein; Vorverarbeitung auf Testdaten zu „fitten“ verfälscht die Bewertung. Die Dokumentation zu häufigen Fehlern beschreibt genau diese Datenlecks. Für unseren deterministischen Kern ist keine KI nötig; die Quelle ist ein Vertiefungshinweis für mögliche spätere datenbasierte Modelle.

Vertiefung: Wähle zwei Versionsstände, notiere präzise die geänderte Übergangsregel und weise durch dieselben Testfälle nach, ob die Änderung erwünscht oder ein Rückschritt ist.

Transfer: unabhängige Kontrollzustände

Rollen sauber trennen

Ein künftiger KI-Agent darf synthetische Daten analysieren und einen Vorschlag formulieren: „Prüffall wiederholen“. Die getrennte, nachvollziehbare Kontrollinstanz verarbeitet dagegen ausschließlich festgelegte Ereignisse und Prüfergebnisse. Sie akzeptiert keinen AGENT_START als Ersatz für einen menschlichen START und keine agentengenerierte Erfolgsmeldung als Resetfreigabe. Damit hängt die Einhaltung der drei Kernkriterien nicht von der Zuverlässigkeit einer generativen Modellantwort ab.

Agentenempfehlung	Kontrollzustand	Erlaubtes Simulationsergebnis
„Starte erneut“	STOP	STOP bleibt; keine Ausführung
„Fehler nicht mehr sichtbar“	STOP	STOP bleibt; Behebung und Prüfergebnis fehlen
„Reset beantragen“	STOP	Antrag nur protokollieren; RESET_MANUELL und beide Nachweise sind gesondert nötig
„Prüfbericht erstellen“	FERTIG	Berichtstext schreiben, keine Steueraktion

Ein fail-safe konzipiertes Lernmodell bevorzugt im Zweifel STOP. Es ist jedoch weder fehlertolerante Robotik noch eine geprüfte Sicherheitssteuerung: reale Gefährdungen, physikalische Dynamik, Sicherheitsnormen und menschliche Handlungen sind hier nicht modelliert.

Transferauftrag mit Begründung

Erweitere das synthetische Labor um V-C, das bei einem widersprüchlichen Prüfcode das Ereignis SENSOR_KONFLIKT auslöst. Definiere mindestens einen normalen Trace, einen Fehlertrace und eine bewusst abgelehnte Reset-Anfrage. Erkläre mit Zustands- und Ereignisbezug, weshalb STOP erreicht wird. Dokumentiere außerdem, wie ein scheinbar plausibler Agentenvorschlag abgewiesen wird. Hilfe: Zeichne erst ein Zustandsdiagramm und formuliere dann die Sollwerte. Anspruchsvolle Erweiterung: Prüfe systematisch alle Zustände gegen sämtliche Fehlerereignisse und formuliere die beiden Invarianten als automatisierte Tests.

Medienhinweis: Ein Robotik-Tutorial der Universität Kassel verlinkt deutschsprachige YouTube-Teile. Die Abspielbarkeit einzelner YouTube-Videos ließ sich beim Abruf am 22.10.2026 nicht unabhängig bestätigen; deshalb kein ungeprüfter Video-Embed. Alle Inhalte und Versuche bleiben durch die Texttabellen ohne Video bearbeitbar. Ein verifiziertes deutsches Sprachbeispiel „Roboterarm“ liegt als Audiodatei auf Commons vor; Urheber Jeuwre, CC BY-SA 4.0. Es vermittelt Aussprache, keine technische Instruktion.

Audioalternative: Das gesprochene Wort lautet „Roboterarm“; alle Fachinhalte sind schriftlich verfügbar.

Interaktive Aufgaben

Bearbeitungshinweis: Prüfe jede Antwort zuerst an den Definitionen und der Übergangstabelle. Die korrekte Option wird in den MC-Aufgaben nicht vorab als Lösungstext erklärt; das Aufgabenformat liefert die Rückmeldung bei der Bearbeitung.

Quiz: Zehn Entscheidungen

Welches Ereignis hat in jeder Phase des vereinfachten Modells Vorrang? (FEHLER führt in STOP) (!PRUEF_OK startet sofort neu) (!ACK setzt jeden Fehler zurück) (!START hat immer Vorrang)

Wofür steht ein Zustand in einem digitalen Ablaufmodell? (Er beschreibt die aktuell gültige Ablaufphase) (!Er ist grundsätzlich ein physischer Sensor) (!Er ersetzt das Testprotokoll) (!Er bezeichnet immer eine Bauteilnummer)

Was geschieht nach STOP und einem AGENT_START im Lernmodell? (Das Modell bleibt in STOP) (!Der Roboter fährt automatisch los) (!Es wird ohne Prüfung auf FERTIG gewechselt) (!Die Dokumentation wird gelöscht)

Welche Bedingung erlaubt den Modellreset? (RESET_MANUELL und beide Prüfnachweise) (!Zeitablauf alleine) (!Agentenempfehlung alleine) (!Ein beliebiger Startimpuls)

Was ist direkt nach einem akzeptierten Reset zulässig? (Wechsel zu BEREIT ohne automatischen START) (!Automatisches Wechseln nach PRUEFEN) (!Überspringen aller Tests) (!Physische Inbetriebnahme ohne Prüfung)

Warum wird eine Übergangstabelle benötigt? (Sie macht Zustände und Ereignisse reproduzierbar) (!Sie beweist die Sicherheit realer Maschinen) (!Sie ersetzt jedes Experiment) (!Sie erlaubt beliebige unerfasste Eingaben)

Was vergleicht eine Assertion in einem Test? (Beobachtetes Ergebnis mit einem erwarteten Sollwert) (!Dateigröße mit Lizenzname) (!Roboterreichweite mit Stromverbrauch) (!Zustandsnamen mit Wetterdaten)

Was dokumentiert ein Negativtest? (Reaktion auf fehlerhafte oder unzulässige Eingaben) (!Nur den idealen Normalablauf) (!Ausschließlich die Bildqualität) (!Eine offizielle Maschinenfreigabe)

Warum muss die Kontrollinstanz vom Agenten getrennt bleiben? (Ein Vorschlag darf festgelegte Sperren nicht umgehen) (!Weil ein Agent stets korrekte Lösungen liefert) (!Damit Testfälle entfallen können) (!Damit ein Agent den Reset ungeprüft ersetzt)

Welche Quelle passt zum Problem des Datenlecks bei späteren ML-Versuchen? (Die scikit-learn Dokumentation zu häufigen Fehlern) (!Die Grafikdatei eines Roboterarms) (!Die Audioaussprache Roboterarm) (!Eine beliebige Bauteilkennzeichnung)

Memory

Verbinde jeden Begriff mit genau einer Beschreibung.

Zustandsautomat	Modell mit endlich vielen Ablaufphasen
Guard	Zusätzliche Bedingung für einen Übergang
Testorakel	Vorab notierter Sollwert eines Tests
Regressionstest	Erneute Prüfung nach einer Änderung
Trace	Aufgezeichnete Folge von Ereignissen
Invariante	Aussage, die für alle betrachteten Fälle gelten soll

Drag-and-Drop

Ordne die fünf Ereignisse ihren überprüfbaren Modellreaktionen zu.

Passendes Ereignis	Modellreaktion
BOOT_OK	INIT wechselt nach BEREIT
SENSOR_KONFLIKT	PRUEFEN wechselt nach STOP
RESET_MANUELL mit beiden Nachweisen	STOP wechselt nach BEREIT
AGENT_START im STOP	STOP bleibt unverändert
PRUEF_OK	PRUEFEN wechselt nach FERTIG

Kreuzworträtsel

Sechs Fachbegriffe mit je einem Wort als Lösung.

Zustand	Aktuelle Phase eines endlichen Ablaufmodells
Fehler	Ereignis, das im Modell stets den Stopzustand erzwingt
Version	Kennzeichen eines bestimmten Dokumentstands
Protokoll	Schriftlicher Nachweis der getesteten Ereignisse
Wächter	Deutsche Bezeichnung einer Bedingung für Zustandswechsel
Simulation	Rechnerische Nachbildung statt Anlagenanbindung

LearningApps

Weitere interaktive Übungen zum Begriffsumfeld:

. Die Treffer sind externe Angebote und nicht Bestandteil der überprüften Testnachweise. Alternative: Ordne die fünf Drag-and-Drop-Paare auf Papier zu.

Lückentext

Offene Aufgaben

Bearbeite die Aufgaben an einer rein textbasierten Simulation. Erstelle keine echte Maschinensteuerung.

Leicht

Zustände markieren: Erläutere für INIT, BEREIT, PRUEFEN, FERTIG und STOP jeweils den Zweck in einem Satz.
Ereigniskarten: Ordne BOOT_OK, START, PRUEF_OK und SENSOR_KONFLIKT passenden Phasen zu.
Trace lesen: Schreibe für BOOT_OK, START und FEHLER eine dreizeilige Zustandsfolge auf.
STOP erklären: Begründe, warum „Fehler wieder verschwunden“ ohne manuellen Reset nicht zum Neustart reicht.

Standard

Diagramm entwerfen: Zeichne die fünf Zustände, Regeln und mindestens zwei Fehlerkanten; markiere Guards.
Offline-Code testen: Führe den Textcode aus oder simuliere ihn tabellarisch; dokumentiere T01 bis T07.
Versionswechsel dokumentieren: Erstelle bericht.md v1.1 mit begründeter Änderung und wiederholten Testfällen.
Fehlerfall begründen: Zeige an SENSOR_KONFLIKT den Zustand vor und nach dem Ereignis sowie die abgeschaltete Modellaktion.

Schwer

Invarianten prüfen: Teste für alle fünf Zustände drei Fehlerereignisse und beweise STOP als Resultat.
Mutationstest entwickeln: Baue eine absichtliche Reset-Schwäche ein, finde sie mit mindestens zwei Tests und repariere sie.
Kontrollarchitektur entwerfen: Trenne Empfehlungsagent, festes Zustandsmodell und Testprotokoll; beschreibe alle Schnittstellen als reine Textdaten.
Transfer auf Variante V-C: Entwirf einen neuen synthetischen Fehlertrace mit abgewiesenem Agentenvorschlag und geprüftem manuellem Reset.

Lernkontrolle

Kriterium Fehler STOP: Leite aus einer selbst gewählten Startphase und einem Fehlerereignis den Sollzustand ab; begründe den Vorrang.
Kriterium Neustart: Zeige mit zwei verschiedenen Ereignissen, weshalb STOP nicht von selbst verlassen werden kann.
Kriterium manueller Reset: Vergleiche eine abgewiesene und eine akzeptierte Reset-Anfrage mit identischem Startzustand.
Vollständigkeit: Gib an, welche Fälle T01 bis T07 abdecken und welcher weitere Randfall fehlen könnte.
Versionsvergleich: Erläutere anhand v1.0 und v1.1, weshalb Sollwerte vor der Programmausführung feststehen sollen.
Agentenunabhängigkeit: Begründe, warum das Kontrollmodell eine KI-Empfehlung trotz plausibler Erklärung ablehnen muss.

Lernnachweis

Gib einen nachvollziehbaren offline bearbeitbaren Satz aus vier Teilen ab: (1) Zustandsdiagramm und vollständige Übergangstabelle, (2) Python-Quelltext oder tabellarische Simulation, (3) Protokoll mit T01–T07 einschließlich Soll, Ist und Versionsstand, (4) eigenständiger Entscheidungsbericht mit begründetem Fehlerfall und Erklärung des unabhängigen Kontrollzustands.

Mindestanforderung: Fehler führt STOP; STOP bleibt ohne Auto-Neustart erhalten; geprüfter RESET_MANUELL wechselt ausschließlich nach BEREIT. Ein ungeprüfter Reset muss abgewiesen werden. Nachweisqualität: jeder Prüffall ist wiederholbar, Quellen und geänderte Versionen sind benannt, Abweichungen werden nicht verschwiegen. Reflexion: Erkläre in eigenen Worten, warum ein bestandener Simulationslauf keinerlei reale Sicherheitsfreigabe darstellt.

OER und Wikipedia

Recherche- und Medienstand: 22.10.2026. Die Wikiseiten und verfügbaren Commons-Dateiseiten wurden beim Erstellen als Fundstellen geprüft; ihre spätere Erreichbarkeit kann sich ändern. Die konkrete Vorgängerseite curid=59869 konnte extern nicht gelesen werden. Die direkte YouTube-Abspielbarkeit war nicht überprüfbar; es wird kein YouTube-Video fälschlich als live bestätigt.

Wikipedia: Endlicher Automat, CC BY-SA, Grundlagen von Zuständen und Übergängen; Industrieroboter als Abgrenzung realer Technik.
IDTA: Downloads, aktuelle Downloadübersicht; konkrete Submodell-Ausgabe vor Übernahme prüfen.
scikit-learn: Common pitfalls and recommended practices, online abrufbare stabile Dokumentation, Abruf 22.10.2026; für datenbasierte Vertiefung, nicht für den deterministischen Kern.
HSHL: Zustandsdiagramm, fachliches Beispiel und vertiefende Darstellung.
Universität Kassel: Robotik-Tutorial, verlinkt deutschsprachige Videos, deren individuelle Live-Verfügbarkeit hier nicht verifiziert werden konnte.
Finite-State-Machine.svg, MicroBeaut, CC BY-SA 4.0, Schaubild.
Finite State Machine Logic.svg, jjbeard/Perhelion, Public Domain, Logikschema.
Industrial robot.jpg, Jo Teichmann/KUKA Roboter GmbH, Tony Wills, Public Domain, Anschauungsfoto.
Emergency Stop.jpg, Biso, CC BY-SA 4.0, Anschauungsfoto.
ExtraSimpleWalker.gif, MichaelFrey, CC BY-SA 4.0, Animation.
De-Roboterarm.ogg, Jeuwre, CC BY-SA 4.0, deutsches Ausspracheaudio.

Lizenzhinweis: Lizenzbedingungen der jeweiligen Datei beachten und Bearbeitungen kennzeichnen; die Urhebernachweise stehen direkt bei den eingebundenen Medien. Medienalternative: Tabellen und textliche Beschreibungen erklären alle technischen Inhalte unabhängig vom Öffnen externer Dateien.