Schaltpläne mit KI erstellen und prüfen: Vom Auftrag zum Fehlerfall

Der Auftrag ist der Anfang der Klärung

In Teil 1 lautet der Ausgangspunkt sinngemäß: Ein Pumpenmotor mit 4 kW soll an 400 V im Direktanlauf betrieben werden. Die KI arbeitet mit diesen Angaben, schlägt Werte und Komponenten vor und bekommt Rückmeldung. Erst danach wird der Schaltplan dargestellt.

Für einen Entwicklungsverantwortlichen liegt hier eine konkrete Prüffrage: Kann ich erkennen, was die KI aus meinem Auftrag übernommen hat und was sie selbst ergänzt? Eine stillschweigende Annahme kann im weiteren Ablauf wie eine bestätigte Vorgabe aussehen. Deshalb würde ich die Herkunft der Angaben bereits im Entwurf festhalten.

Motorabgang und Wendeschütz sind zwei verschiedene Beispiele

Teil 1 zeigt den Pumpenmotor und seine Schaltzustände. Teil 2 beginnt mit einem Förderband, ebenfalls mit 4 kW und 400 V, nun mit Vorwärts- und Rückwärtslauf. Das Förderband ist eine neue Aufgabe. Es wird nicht derselbe Pumpenschaltplan weitergeführt.

Zum Ende von Teil 2 wird zusätzlich ein Lüfter mit 22 kW und Stern-Dreieck-Anlauf als weiterer Auftrag eingeführt. Der Artikel konzentriert sich auf den Motorabgang und die Wendeschütz-Demonstration. Alle genannten Leistungs- und Spannungswerte beschreiben die Beispiele; sie sind keine Auslegungsempfehlung für eine Anlage.

Warum der Fehlerfall mehr erklärt als der Normalbetrieb

Ein normaler Funktionsablauf beantwortet nur einen Teil der Fragen. In der zweiten Folge werden auch konkurrierende Schaltbefehle und veränderte Verriegelungsbedingungen im Modell untersucht. Die Reaktionen werden sichtbar; bei fehlenden Verriegelungen meldet das Modell einen Kurzschluss.

Das ist ein simulierter Fehlerfall. Im Video wird kein Kurzschluss an einer realen Anlage ausgelöst. Die Darstellung dient dem Verständnis der modellierten Schaltung. Sie ist keine Anleitung, eine Verriegelung an einer Maschine außer Kraft zu setzen.

Für die Bewertung würde ich zu jedem Test die Ausgangslage, die erwartete Reaktion und das beobachtete Ergebnis dokumentieren. Erst dann lässt sich besprechen, ob die Prüfung zur gestellten Aufgabe passt. Die Anzahl grüner Meldungen allein reicht mir dafür nicht.

Ein Prüfergebnis braucht einen benannten Umfang

In Teil 1 werden acht interne Prüfungen angezeigt. Daraus lässt sich keine vollständige Normenprüfung ableiten. Entscheidend bleibt, welche Eigenschaften das System überhaupt prüft und welche Daten ihm dafür vorliegen.

Auch die EPLAN-Dokumentation beschreibt Projektprüfungen im Zusammenhang mit einem ausgewählten Prüfschema und dem gewählten Projektumfang. Diese allgemeine Grundlage hilft bei der Einordnung: Das Ergebnis einer Softwareprüfung hängt von ihrer Konfiguration und ihrem Gegenstand ab. EPLAN: Checking Projects.

Für einen Versuch im Unternehmen würde ich daher vorab festlegen, welche Ergebnisse erwartet werden: ein nachvollziehbarer Entwurf, eine Liste offener Annahmen und dokumentierte Modellprüfungen. Die zuständigen Elektrofachleute bewerten anschließend Schaltung, Komponenten, Schutzkonzept und erforderliche Nachweise für den konkreten Einsatz.

So lässt sich ein erster Versuch auswerten

Starten würde ich mit einer bereits bekannten, überschaubaren Aufgabe und einem dokumentierten Referenzstand. Das Team vergleicht die KI-Ausgabe mit dem eigenen fachlichen Vorgehen. Welche Rückfragen sind hilfreich? Wo fehlen Angaben? Welche Korrekturen werden notwendig?

Entwurfszeit und Prüfaufwand sollten getrennt erfasst werden. Zusätzlich würde ich festhalten, ob Annahmen erkennbar sind und ob sich ein Befund bis zur betroffenen Stelle zurückverfolgen lässt. Das liefert eine Grundlage für die Entscheidung, ob ein weiterer Versuch sinnvoll ist. Die beiden Filme belegen bisher keine Zeitersparnis im Kundeneinsatz.

Häufige Fragen