aiMOOC

IGH-Baugruppenprüfung in Biberach – Prüffolgen für verschiedene Baugruppen konfigurieren

QR-Code

Einleitung

Du lernst, wiederverwendbare Prüfschritte für unterschiedliche elektrische und mechatronische Lehrbaugruppen zu entwerfen. Im Mittelpunkt steht die Frage: Welche Prüfungen dürfen gemeinsam genutzt werden und ab wann braucht eine Baugruppe einen eigenen Prüfschritt? Dazu beschreibst du Voraussetzungen, Sollverhalten, Abbruchregeln und Nachweise so, dass andere Fachkräfte die Prüfung nachvollziehen und wiederholen können.

Der berufliche Bezug ist die veröffentlichte Praxisbeschreibung von IGH Automation: Das Unternehmen berichtet, dass im Werk Biberach Prüfsoftware für Turmdrehkran-Baugruppen vom Prüfstand für Elektrobaugruppen bis zu Komponentenprüfständen eingesetzt wird. Genannt werden digital konfigurierte und dokumentierte Prüffolgen sowie die Simulation eines umgebenden Systems. Die öffentlich verfügbare Beschreibung nennt jedoch keine konkreten Softwareversionen, Herstellerparameter oder freigegebenen Arbeitsanweisungen. Deshalb arbeitest du hier mit ausdrücklich synthetischen Lehrbaugruppen und Beispielwerten, nicht mit einer originalen IGH-Konfiguration.

Zielgruppe sind Auszubildende im dritten Ausbildungsjahr in Fachinformatik, Elektronik für Geräte und Systeme sowie Mechatronik. Die Aufgaben verbinden Anforderungsanalyse, Testautomatisierung, elektrische Messung, Steuerungslogik, Datenqualität und nachvollziehbare Dokumentation.

Von der Anforderung zur Prüffolge

Was ist eine Prüffolge?

Eine Prüffolge ist eine festgelegte Reihenfolge von Prüfschritten mit Eingangsbedingungen, Aktionen, erwarteten Ergebnissen und Regeln für die Auswertung. Sie übersetzt eine Anforderung in überprüfbare Aussagen. Ein Testfall beantwortet mindestens fünf Fragen: Was wird geprüft? Unter welchen Voraussetzungen? Welche Reaktion wird ausgelöst oder gemessen? Was gilt als bestanden? Welche Daten werden gespeichert?

Eine gute Prüffolge trennt Vorbereitung, Durchführung, Bewertung und Abschluss. Sie ist reproduzierbar: Bei gleichen freigegebenen Voraussetzungen soll sie auf vergleichbare Weise ausgeführt werden. Sie ist rückverfolgbar: Jede Prüfung verweist auf eine Anforderung, Baugruppenvariante und Version der Prüfspezifikation. Sie ist fehlertolerant im Sinne klarer Fehlerbehandlung, nicht im Sinne des Ignorierens von Abweichungen.

Beispiel einer generischen Prüfschritttabelle

Feld	Zweck	Synthetisches Beispiel
Kennung	Eindeutige Referenz	T-010
Voraussetzung	Sichere Startbedingung	Lehrbaugruppe erkannt; Prüfadapter laut Übungsblatt ausgewählt
Aktion	Geplante Anregung oder Abfrage	Freigegebenes digitales Eingangssignal im Simulationsmodus setzen
Sollwert / Sollzustand	Erwartete Reaktion	Statusbit wechselt innerhalb des Lehrmodells auf „bereit“
Abbruchregel	Unzulässigen Zustand verhindern	Adapterkennung passt nicht: Test nicht starten
Ergebnis	Bewerteter Zustand	Bestanden / Nicht bestanden / Nicht ausführbar
Nachweis	Spätere Analyse ermöglichen	Zeitstempel, Testfall-ID, Variante, Softwarestand und Messwert

Die Tabelle ist ein Lehrmodell. „Statusbit“, Zeitgrenze und jede beispielhafte Prüfbedingung müssen in einer realen Anlage durch freigegebene Spezifikationen ersetzt werden. Erfinde keine elektrischen Grenzwerte, Pinbelegungen, Prüfspannungen oder Sicherheitsfreigaben.

Begriffe sicher unterscheiden

Prüfanforderung beschreibt, was nachgewiesen werden muss. Testfall beschreibt einen konkreten Fall mit Vorbedingungen, Aktion und erwartetem Ergebnis. Prüfschritt ist ein einzelner Schritt innerhalb einer Prüffolge. Prüfsequenz ordnet die Schritte und legt Übergänge fest. Prüfadapter stellt eine definierte Verbindung zwischen Prüfling und Prüfstand her. Restsystemsimulation bildet fehlende Komponenten oder Systembedingungen ab, damit eine nicht vollständig montierte Baugruppe unter definierten Lehrbedingungen geprüft werden kann. Quality Gate ist eine dokumentierte Entscheidungsschwelle, die den weiteren Prozess nur bei erfüllten Kriterien zulässt.

Gemeinsamkeiten und Unterschiede von Baugruppen erkennen

Lehrmodell mit zwei Varianten

Für die Übungen werden zwei synthetische Baugruppen verwendet. Variante A ist eine Bedieneinheit mit drei Tastern und zwei Statusanzeigen. Variante B ist ein Sensormodul mit einem simulierten Analogeingang, einer Statusanzeige und einer digitalen Diagnosemeldung. Diese Beschreibungen sind frei erfundene Lehrmodelle, keine Produktdaten eines Herstellers.

Gemeinsame Prüfbausteine können beispielsweise Identitätsabgleich, Sichtkontrolle anhand einer Checkliste, Prüfung der Protokollfelder, Versionsprüfung und Bewertung eines eindeutig definierten Fehlerzustands sein. Ein gemeinsamer Baustein ist nur sinnvoll, wenn seine Voraussetzungen und sein erwartetes Verhalten für beide Varianten tatsächlich gelten. Die gleiche Bezeichnung oder ein ähnlicher Steckverbinder genügt nicht als Nachweis.

Prüfaspekt	Variante A: Bedieneinheit	Variante B: Sensormodul	Entscheidung
Identität / Variantenkennung	vorhanden	vorhanden	gemeinsamer Baustein möglich, wenn Datenmodell gleich ist
Protokollvollständigkeit	Test-ID, Ergebnis, Zeitstempel	Test-ID, Ergebnis, Zeitstempel	gemeinsam, gleiche Bedeutung und Pflichtfelder
Tasterreaktion	drei diskrete Signale	nicht vorhanden	getrennte Prüfung
Analoge Messwertauswertung	nicht vorhanden	simulierter Eingang	getrennte Prüfung mit eigenem Sollbereich aus dem Lehrblatt
Statusanzeige	zwei Anzeigen	eine Anzeige	nur gemeinsame Teilprüfung, wenn gleiche Spezifikation nachgewiesen
Diagnosemeldung	modellabhängig	definierte Lehrmeldung	getrennte Prüfung bei unterschiedlicher Semantik

Entscheidungsregel für Wiederverwendung

Prüfe vor dem Teilen eines Bausteins: Sind Zweck, Ein- und Ausgaben, Vorbedingungen, Abbruchverhalten und Ergebnisbedeutung gleich? Sind die erforderlichen Signale vorhanden? Sind die Prüfmittel und die Berechtigungen dafür geeignet? Ist die Variante eindeutig identifiziert? Lassen sich Ergebnisse ohne Informationsverlust auswerten? Wenn eine Antwort offen ist, darf der Baustein nicht einfach als gemeinsamer Funktionstest freigegeben werden. Teile stattdessen den Baustein in einen sicheren gemeinsamen Teil und variantenspezifische Unterprüfungen.

Selbst erstelltes Entscheidungsschema

Schritt	Prüffrage	Konsequenz
1	Ist die Baugruppenvariante eindeutig identifiziert?	Nein: Start blockieren und Diagnose ausgeben
2	Sind Vorbedingungen, Schnittstellen und Ergebnissemantik gleich?	Nein: getrennte Prüfschritte definieren
3	Ist die gemeinsame Prüfung für beide Varianten belegt?	Nein: erst Spezifikation klären
4	Ist ein Fehlerzustand eindeutig und sicher behandelt?	Nein: Abbruch- und Fehlerpfad überarbeiten
5	Werden Variante, Version, Ergebnisse und Abweichungen protokolliert?	Nein: Nachweisfähigkeit herstellen

Prüfschritte konfigurieren und versionieren

Vom Testbaustein zum wiederverwendbaren Modul

Ein Testbaustein sollte genau beschreiben, was er benötigt und was er liefert. Definiere Eingaben, erwartete Ausgaben, Fehlercodes, Zeitverhalten soweit spezifiziert, Vorbedingungen und Nachbedingungen. Halte die Prüflogik möglichst frei von fest eingebauten Variantennamen. Variantenabhängige Eigenschaften gehören in eine geprüfte Konfiguration, nicht in unübersichtliche Sonderfälle im Programmcode.

Ein mögliches Konfigurationsmodell für das Lehrprojekt enthält die Felder: Varianten-ID, Konfigurationsversion, aktivierte Testbausteine, benötigte Signale, Sollkriterien, erlaubte Abbruchgründe und Dokumentationsschema. Konfigurationsdaten müssen validiert werden, bevor die Prüfung startet. Eine unbekannte Variante, ein fehlendes Pflichtfeld oder eine nicht passende Version führt im Lehrmodell zu „nicht ausführbar“ statt zu einem scheinbar bestandenen Test.

Baustein-ID	Geltungsbereich im Lehrmodell	Voraussetzung	Ergebnis
GEN-ID-01	A und B	gültige Kennung und freigegebene Testkonfiguration	Identität gültig / ungültig
GEN-LOG-02	A und B	Protokollschema vorhanden	Pflichtfelder vollständig / unvollständig
A-BTN-10	nur A	Tastereingänge laut Simulationsplan verfügbar	Reaktion je Taster dokumentiert
B-ANA-20	nur B	Simulationssignal und Lehrbereich definiert	Abweichung zum Lehr-Soll bewertet
B-DIAG-30	nur B	Diagnosezustand im Testmodell erzeugbar	Diagnosemeldung entspricht Spezifikation

Die IDs sind erfundene Übungskennungen. Sie sind weder IGH-Softwarebefehle noch betriebliche Prüfpläne.

Prüfreihenfolge und Abhängigkeiten

Die Reihenfolge ist fachlich begründet. Zuerst werden Identität, Konfigurationsintegrität und notwendige Vorbedingungen kontrolliert. Danach folgen Prüfungen, die keine gefährliche oder ungültige Ausgangssituation erzeugen. Erst dann kommen funktionsbezogene Tests, für die alle Voraussetzungen erfüllt sind. Am Ende stehen Ergebnisbewertung, Protokollprüfung und ein klarer Abschlusszustand. Wenn ein früher Prüfschritt scheitert, werden abhängige Tests übersprungen oder kontrolliert abgebrochen; sie dürfen nicht so protokolliert werden, als hätten sie stattgefunden.

Sequenzphase	Zweck	Übergang
Startkontrolle	Identität, Konfiguration, Adapterzuordnung im Lehrmodell prüfen	nur bei gültiger Ausgangslage fortfahren
Gemeinsame Basisprüfungen	Pflichtfelder und vereinbarte Schnittstellen prüfen	Fehlerstatus stoppt abhängige Funktionstests
Variantenauswahl	nur passende Testbausteine aktivieren	unbekannte Variante = nicht ausführbar
Funktionstest	variantenspezifisches Verhalten bewerten	Ergebnis pro Testfall speichern
Abschluss und Bericht	Vollständigkeit und Status prüfen	Quality-Gate-Entscheidung dokumentieren

Versionsmanagement und Änderungsauswirkung

Jede Änderung eines Prüfschritts kann bestehende Ergebnisse beeinflussen. Deshalb erhalten Testdefinition, Konfiguration und relevante Ausführungssoftware jeweils identifizierbare Versionsstände. Ein Review prüft, ob eine Änderung nur Texte oder auch Testlogik, Signale, Sollkriterien, Abhängigkeiten oder Ergebnissemantik verändert. Nach einer fachlichen Änderung werden betroffene Testfälle erneut ausgeführt; Umfang und Freigabe werden im betrieblichen Verfahren festgelegt.

Ein häufiger Fehler besteht darin, einen Test für Variante A zu ändern und nicht zu erkennen, dass die Änderung auch Variante B betrifft. Weitere typische Fehler sind doppelte Test-IDs, ungültige Standardwerte, nicht geprüfte Konfigurationskombinationen, zu breite Fehlerbehandlung und das Überschreiben älterer Protokolle. Gegenmaßnahmen sind Code- und Konfigurationsreview, Versionsverwaltung, automatisierte Schemaprüfungen und ein nachvollziehbarer Änderungsverlauf.

Ergebnisse bewerten, Fehler behandeln und Qualität nachweisen

Soll-Ist-Vergleich und Statusmodell

Ein Prüfergebnis entsteht aus dem Vergleich eines beobachteten Ist-Zustands mit dem vorher festgelegten Sollzustand. Ein Test gilt nicht deshalb als bestanden, weil kein Fehler angezeigt wird. Es muss nachgewiesen sein, dass der Test tatsächlich ausgeführt wurde und seine Bedingungen erfüllt waren. Für das Lehrmodell werden vier Status verwendet: Bestanden, Nicht bestanden, Nicht ausführbar und Abgebrochen. Diese Status werden nicht gleichgesetzt.

„Nicht bestanden“ bedeutet, dass ein ausgeführter Test eine Abweichung festgestellt hat. „Nicht ausführbar“ bedeutet, dass Vorbedingungen fehlten oder die Konfiguration ungültig war. „Abgebrochen“ bedeutet, dass die Ausführung nicht regelgerecht beendet werden konnte. Nur nach den zuvor dokumentierten Kriterien ist ein Gesamtergebnis „freigegeben“ möglich.

Fehlerdaten und nachvollziehbare Diagnose

Ein guter Fehlerdatensatz enthält mindestens Baugruppenkennung, Variante, Konfigurations- und Softwareversion, Testfall-ID, Zeitstempel, Ergebnisstatus, Soll-/Ist-Beschreibung und Referenz auf den Fehlerfall. Zusätzliche Signale oder Messwerte werden nur erfasst, wenn sie für die Aufgabe erforderlich und zulässig sind. Personenbezogene Daten gehören nicht in die Lehrdaten. Ein Fehlercode muss eine klare Bedeutung besitzen und über Versionen stabil oder nachvollziehbar migrierbar sein.

Die Veröffentlichung von IGH Automation beschreibt digitale Datenerfassung und die Ablage in einer digitalen Produktakte sowie die Nutzung wiederholbarer Prüffolgen. Das ist ein allgemeiner Industriebezug; Details der hier gezeigten Datensätze sind Lehrentwürfe und stellen keine Aussage über die interne Datenstruktur eines bestimmten Herstellers dar.

Medien zur Vertiefung

Abbildung 1: Prüfgeräte-Rack mit Oszilloskop, Digitalmultimeter und Bedienfeld. Datei: F18NARack.JPG; Urheber: George5530; eigene Arbeit; gemeinfrei laut Dateiseite auf Wikimedia Commons.

Abbildung 2: Elektronische Bauteile auf einer Leiterplatte. Datei: Electronic components in Printed Circuit Board.jpg; Urheber: Soumyapatra13; eigene Arbeit; Lizenz CC BY-SA 4.0, Namensnennung und Weitergabe unter gleichen Bedingungen beachten.

Eigene Ablaufgrafik als Textschema

Eingang	Verarbeitung	Entscheidung / Ausgabe
Baugruppen-ID + Konfigurationsversion	Schema- und Variantenprüfung	unbekannt oder unvollständig → nicht ausführbar
Gültige Konfiguration	gemeinsame Basisprüfungen	Abweichung → Fehlerstatus, abhängige Tests stoppen
Variante A	Taster- und Anzeigeprüfungen im Lehrmodell	Ergebnisse je Testfall speichern
Variante B	Analogsignal- und Diagnoseprüfung im Lehrmodell	Ergebnisse je Testfall speichern
alle abgeschlossenen Tests	Status- und Protokollprüfung	Gesamtbewertung nach definiertem Quality Gate

Interaktive Aufgaben

Quiz: Wissen testen

Warum muss eine Baugruppenvariante vor der Prüffolge eindeutig identifiziert werden? (Weil nur passende und freigegebene Prüfschritte ausgewählt werden können) (!Damit die Prüfung immer schneller läuft) (!Damit Sollwerte aus anderen Varianten übernommen werden) (!Damit ein unvollständiges Protokoll akzeptiert werden kann)

Welche Aussage beschreibt einen gemeinsamen Testbaustein korrekt? (Er ist nur gemeinsam nutzbar, wenn Voraussetzungen und Ergebnisbedeutung für beide Varianten belegt gleich sind) (!Er kann gemeinsame Bezeichnungen besitzen, auch wenn die Signale verschieden sind) (!Er wird einmal erstellt und danach nie wieder überprüft) (!Er darf fehlende Signale automatisch als bestanden werten)

Welche Information gehört in einen nachvollziehbaren Ergebnisdatensatz? (Testfallkennung und verwendete Konfigurationsversion) (!Nur der Name der Person am Prüfstand) (!Ausschließlich ein Gesamturteil ohne Einzelresultate) (!Nur die Uhrzeit des letzten Systemstarts)

Was bedeutet im Lehrmodell der Status „Nicht ausführbar“? (Eine notwendige Voraussetzung oder Konfiguration fehlt) (!Ein vollständig ausgeführter Test hat eine Abweichung nachgewiesen) (!Alle Testkriterien wurden erfüllt) (!Der Test wurde erfolgreich wiederholt)

Welche Prüfung ist im beschriebenen Lehrmodell nur für Variante A vorgesehen? (Die Reaktion der drei simulierten Tastereingänge) (!Die Vollständigkeit der gemeinsamen Protokollfelder) (!Die Prüfung einer vorhandenen Variantenkennung) (!Die Prüfung, ob ein Ergebnisstatus gespeichert wurde)

Wozu dient die Restsystemsimulation grundsätzlich? (Sie bildet definierte Bedingungen fehlender Systemkomponenten ab, damit eine einzelne Baugruppe geprüft werden kann) (!Sie ersetzt alle Sicherheitsvorschriften am realen Prüfstand) (!Sie macht eine eindeutige Baugruppenkennung überflüssig) (!Sie garantiert die Fehlerfreiheit des vollständigen Produkts)

Was ist bei einer Änderung der gemeinsamen Protokollstruktur besonders wichtig? (Die Auswirkungen auf beide Varianten und vorhandene Auswertungen zu prüfen) (!Nur die Bildschirmfarbe anzupassen) (!Die alte Version ohne Nachweis zu überschreiben) (!Alle Variantentests automatisch als bestanden zu markieren)

Welche Reihenfolge ist für das Lehrmodell am sinnvollsten? (Identität und Vorbedingungen prüfen, dann passende Funktionsprüfungen ausführen und Ergebnisse bewerten) (!Funktionsprüfungen starten und danach erst die Variante bestimmen) (!Protokoll löschen, dann Prüfschritte ohne Voraussetzungen ausführen) (!Nur den Gesamtstatus ausgeben und Einzeltests weglassen)

Was sollte bei einer nicht passenden Adapterkennung geschehen? (Die Prüfung kontrolliert nicht starten und den Grund dokumentieren) (!Die Adapterkennung ignorieren und die Prüfung fortsetzen) (!Die Konfiguration durch eine zufällige Variante ersetzen) (!Das Ergebnis ohne Testausführung als bestanden speichern)

Welche Aussage zu automatisierten Tests ist fachlich angemessen? (Sie liefern Nachweise für definierte Testfälle, beweisen aber nicht die Abwesenheit sämtlicher Fehler) (!Ein bestandener Test beweist, dass alle möglichen Fehler ausgeschlossen sind) (!Automatisierung macht Anforderungen und Reviews überflüssig) (!Ein digitaler Bericht ersetzt immer jede betriebliche Freigabe)

Memory-Spiel

Prüfanfordung	Festlegung eines erwarteten Zustands, der nachgewiesen werden soll
Vorbedingung	Voraussetzung, die vor dem Start erfüllt sein muss
Soll-Ist-Vergleich	Gegenüberstellung des beobachteten und des geforderten Ergebnisses
Variantenkennung	Merkmal zur eindeutigen Auswahl der Baugruppenvariante
Rückverfolgbarkeit	Möglichkeit, Ergebnis und verwendete Versionen einer Prüfung zuzuordnen
Restsystemsimulation	Modellierung definierter Bedingungen von noch nicht eingebauten Komponenten

Drag-and-drop: Begriff und Erklärung zuordnen

Ordne im Lernspiel die Suchbegriffe den passenden Erklärungen zu. Verwende jeden Begriff genau einmal.

Suchbegriff	Erklärung
Testfall	Konkrete Vorbedingungen, Aktion und erwartetes Ergebnis für einen Prüffall
Prüfsequenz	Geordnete Abfolge zusammenhängender Prüfschritte
Quality Gate	Dokumentierte Entscheidungsschwelle für den weiteren Prozess
Fehlercode	Einheitliche Kennung für eine klassifizierte Abweichung
Versionsstand	Eindeutige Bezeichnung einer kontrollierten Fassung

Kreuzworträtsel: Fachbegriffe

Variante	Wie heißt die eindeutig zu bestimmende Ausführung einer Baugruppe?
Adapter	Wie heißt die definierte Verbindung zwischen Prüfling und Prüfstand?
Sequenz	Welcher Begriff bezeichnet eine geordnete Folge von Prüfschritten?
Protokoll	In welchem Nachweis werden Ausführung und Ergebnis festgehalten?
Diagnose	Wie heißt die systematische Untersuchung einer erkannten Abweichung?
Sensor	Welches Bauteil erfasst eine physikalische Größe und liefert ein Signal?

LearningApps

Nutze die Lernaktivität als ergänzende Übung zum Zuordnen von Testbegriffen und Prüfentscheidungen. Die verlinkte LearningApps-Suche öffnet die thematische Suche; sie ist keine Behauptung, dass eine bestimmte fertige App eigens für diesen Kurs existiert.

Lückentext

Bevor eine Prüffolge startet, muss die

eindeutig geprüft werden. Eine gemeinsame Prüfung ist nur zulässig, wenn Vorbedingungen und Ergebnisbedeutung für alle betroffenen Varianten nachgewiesen

sind. Ein einzelner konkreter Prüffall wird mit Vorbedingungen, Aktion und erwartetem Ergebnis als

beschrieben. Kann ein Test wegen einer ungültigen Konfiguration nicht beginnen, lautet der Status im Lehrmodell

. Nach jeder Ausführung werden Ergebnis und verwendete Konfigurationsversion nachvollziehbar

. Variantenspezifische Eigenschaften gehören in getrennte oder kontrolliert ausgewählte

.

Offene Aufgaben

Bearbeite die Aufgaben anhand der synthetischen Lehrmodelle aus diesem Kurs. Lösungen sind Musterlösungen zur fachlichen Orientierung; im Betrieb gelten ausschließlich freigegebene Spezifikationen, Unterweisungen und Arbeitsanweisungen.

Leicht

Prüfanforderungen erkennen: Erstelle für die Lehr-Bedieneinheit eine Anforderung und formuliere ein beobachtbares Sollverhalten. Musterlösung: „Bei Betätigung von Taster 1 wechselt das zugeordnete simulierte Eingangssignal gemäß Lehrplan von 0 auf 1“; die konkrete Zeitgrenze bleibt offen, bis sie spezifiziert ist.
Gemeinsame und getrennte Prüfungen: Markiere aus der Vergleichstabelle je zwei gemeinsame und variantenspezifische Prüfungen. Musterlösung: Variantenkennung und Protokollvollständigkeit können gemeinsam sein; Tasterreaktion und Analogsignal-Auswertung sind getrennt.
Prüfprotokoll entwerfen: Erstelle eine Tabelle mit Testfall-ID, Variante, Konfigurationsversion, Soll, Ist, Status und Bemerkung. Musterlösung: Jeder Datensatz verweist auf genau einen Testfall und speichert auch nicht ausgeführte Tests mit dem korrekten Status.
Prüfablauf visualisieren: Zeichne einen Ablauf vom Startcheck bis zur Abschlussbewertung. Musterlösung: Identität → Vorbedingungen → gemeinsamer Basischeck → Variantenauswahl → Funktionstest → Bericht; bei ungültiger Kennung führt ein Fehlerpfad zum kontrollierten Stopp.

Standard

Prüfbaustein spezifizieren: Schreibe eine Spezifikation für den gemeinsamen Baustein zur Protokollvollständigkeit. Musterlösung: Vorbedingung ist ein verfügbares Lehrprotokollschema; geprüft werden die vereinbarten Pflichtfelder; fehlende Felder ergeben „Nicht bestanden“; ein fehlendes Schema ergibt „Nicht ausführbar“.
Variantenauswahl modellieren: Entwickle Pseudocode, der A und B auswählt und unbekannte IDs zurückweist. Musterlösung: Wenn ID=A, A-Bausteine aktivieren; sonst wenn ID=B, B-Bausteine aktivieren; andernfalls abbrechen, Fehlergrund speichern und keine Funktionsprüfung starten.
Fehlerfall untersuchen: Analysiere einen Datensatz, in dem ein Funktionstest ohne gültige Variantenkennung ausgeführt wurde. Musterlösung: Der Ablauf verletzt die Startbedingung; betroffene Ergebnisse sind nicht belastbar, die Konfiguration ist zu sperren und Ursachenanalyse samt Korrektur und Wiederholungsumfang zu dokumentieren.
Änderungsreview durchführen: Prüfe eine geänderte gemeinsame Ergebnisstruktur auf Auswirkungen. Musterlösung: Beide Varianten, die Berichtsverarbeitung, Pflichtfelder, Rückwärtskompatibilität und automatisierte Auswertungen müssen im Review bewertet werden; betroffene Regressionstests werden festgelegt.

Schwer

Testabdeckung bewerten: Entwirf eine Abdeckungsmatrix für gemeinsame und variantenspezifische Prüfschritte und begründe Lücken. Musterlösung: Zeilen bilden Anforderungen, Spalten die Testfälle; jede Anforderung benötigt eine nachvollziehbare Zuordnung oder eine begründete Nichtanwendbarkeit.
Fehlerpfad und Abbruchlogik entwickeln: Formuliere Regeln für fehlende Konfiguration, unpassende Variante und unerwartete Testunterbrechung. Musterlösung: Jeder Fall hat eine eigene Ursache und einen passenden Status; kein nicht ausgeführter Test wird als bestanden protokolliert.
Konfiguration versionieren: Entwickle einen Ablauf für eine sichere Änderung an Variante B. Musterlösung: Änderungsvorschlag, Review, neue Versionskennung, Prüfung der Konfigurationsvalidierung, Regressionstest, Freigabe und nachvollziehbare Ablage.
Modellfall präsentieren: Stelle dein Prüfkonzept als fünfminütige technische Präsentation mit Tabelle und Ablaufgrafik vor. Musterlösung: Die Präsentation erklärt Anforderungen, wiederverwendbare Bausteine, Trennkriterien, Fehlerbehandlung, Protokollierung und ausdrücklich die Grenzen des Lehrmodells.

Lernkontrolle

Entscheidung zur Baustein-Wiederverwendung: Vergleiche zwei Varianten mit teilweise unterschiedlichen Signalen und begründe, welche Prüfungen gemeinsam bleiben dürfen. Bewertet werden die Betrachtung von Vorbedingungen, Signalverfügbarkeit, Sollsemantik und Fehlerpfaden.
Fehleranalyse nach fehlerhaftem Start: Ein Prüflauf beginnt trotz unbekannter Varianten-ID. Rekonstruiere die mögliche Ursache, bewerte die Aussagekraft der Ergebnisse und schlage sichere Korrekturmaßnahmen vor.
Abhängigkeiten und Reihenfolge: Begründe, warum Identitäts- und Konfigurationschecks vor Funktionsprüfungen liegen und welche Tests bei einem Fehler übersprungen werden müssen.
Protokolldaten bewerten: Prüfe einen synthetischen Bericht darauf, ob Test-ID, Variante, Versionsstand, Soll, Ist und Status eine spätere Ursachenanalyse ermöglichen. Benenne fehlende Felder.
Änderungsauswirkung abschätzen: Erkläre, wie eine Änderung im gemeinsamen Testbaustein Variante A und B sowie die Berichtsauswertung beeinflussen kann.
Spezifikation und Nachweis trennen: Erläutere, warum ein erfolgreicher Test nur den geprüften Umfang belegt und keine umfassende Fehlerfreiheit garantiert.
Sicherer Transfer in den Betrieb: Beschreibe, welche Punkte vor einer Übernahme eines Lehrentwurfs in eine reale Prüfumgebung durch qualifizierte Verantwortliche geklärt und freigegeben werden müssen.

Vollständiger berufstypischer Modellfall mit Lösung

Ausgangslage (synthetischer Lehrfall): Ein Lernteam soll für die fiktive Bedieneinheit A und das fiktive Sensormodul B wiederverwendbare Prüfschritte konfigurieren. Beide Varianten sollen ein gemeinsames Protokollformat verwenden. A besitzt drei simulierte digitale Eingänge und zwei simulierte Statusanzeigen. B besitzt einen simulierten Analogeingang, eine Statusanzeige und eine diagnostische Lehrmeldung. Es existieren keine realen Spannungs-, Strom-, Pin- oder Zeitparameter. Alle Zahlen und IDs in diesem Modell sind lediglich didaktische Beispiele.

Auftrag: Beschreibe gemeinsame Bausteine, variantenspezifische Prüfungen, Startbedingungen, Fehlerpfade, Ergebnisdaten und Freigabekriterien. Lege außerdem fest, wie eine Konfigurationsänderung geprüft wird.

Musterlösung Schritt 1 – Anforderungen: Beide Varianten benötigen eine gültige Variantenkennung, eine zulässige Konfigurationsversion und ein vollständiges gemeinsames Protokoll. Für A wird die Reaktion der drei simulierten Tastereingänge geprüft. Für B wird ein vorgegebenes simuliertes Eingangssignal mit dem im Lehrblatt definierten Sollzustand verglichen; die Diagnosemeldung wird gegen ihre Lehrspezifikation geprüft.

Musterlösung Schritt 2 – Modularisierung: Die gemeinsamen Module sind GEN-ID-01 zur Identitäts- und Konfigurationskontrolle und GEN-LOG-02 zur Prüfung der Pflichtfelder im Protokoll. A-BTN-10 wird nur für A aufgerufen. B-ANA-20 und B-DIAG-30 werden nur für B aufgerufen. Der Variantenrouter aktiviert nie beide variantenspezifischen Pfade allein aufgrund eines ähnlichen Steckers oder einer unvollständigen Kennung.

Musterlösung Schritt 3 – Reihenfolge: Zuerst validiert der Ablauf Kennung und Konfiguration. Danach kontrolliert er die gemeinsamen Protokollvoraussetzungen. Anschließend wählt er den Variantenpfad. Nur wenn die Startchecks bestanden sind, beginnt der jeweilige Funktionstest. Abschluss und Bericht prüfen, ob alle vorgesehenen Tests einen zulässigen Status haben und die Daten vollständig sind.

Musterlösung Schritt 4 – Fehlerbehandlung: Eine unbekannte Kennung führt zu „Nicht ausführbar“ und verhindert die Funktionsprüfung. Ein im ausgeführten Test festgestellter Soll-Ist-Unterschied führt zu „Nicht bestanden“. Eine unerwartete Unterbrechung wird als „Abgebrochen“ protokolliert. Kein Fehler wird durch einen Defaultwert oder das Überspringen eines Pflichtfelds als bestanden gewertet.

Musterlösung Schritt 5 – Dokumentation und Änderung: Der Bericht enthält Baugruppen-ID, Variante, Konfigurationsversion, Testfall-IDs, Ausführungsstatus, Zeitstempel, Soll-/Ist-Beschreibung und Fehlerreferenz. Wird B um eine weitere Diagnosemeldung ergänzt, erhält die Konfiguration eine neue Version. Review und Regressionstests prüfen mindestens den B-Diagnosepfad, den gemeinsamen Protokollbaustein und die Berichtsauswertung für beide Varianten.

Musterlösung Schritt 6 – Freigabeentscheidung: Das Quality Gate ist nur erfüllt, wenn die Variante eindeutig, die Konfiguration gültig, alle erforderlichen Tests ausführbar und die definierten Kriterien erfüllt sowie die Nachweise vollständig sind. „Nicht ausführbar“, „Abgebrochen“ oder „Nicht bestanden“ werden nicht in „Bestanden“ umgewandelt. Über eine reale Produktionsfreigabe entscheidet ausschließlich das zuständige betriebliche Verfahren.

Bewertungsraster (100 Punkte):

Kriterium	Punkte	Voll erfüllt
Anforderungen und Prüfumfang klar abgegrenzt	15	gemeinsamer und getrennter Umfang korrekt erkannt
Wiederverwendbare Bausteine sinnvoll spezifiziert	20	Eingaben, Voraussetzungen, Sollzustand und Ausgabe beschrieben
Variantenrouter und Prüfreihenfolge logisch	15	ungültige oder unbekannte Variante stoppt kontrolliert
Fehlerstatus und Abbruchpfade korrekt	15	Status werden nicht verwechselt; abhängige Tests werden behandelt
Protokollierung und Rückverfolgbarkeit	15	relevante IDs, Versionen und Resultate sind enthalten
Änderungs- und Regressionstestplan	10	Auswirkungen auf beide Varianten werden bewertet
Grenzen des Lehrmodells und betriebliche Freigabe	10	keine Herstellerparameter erfunden; reale Arbeit nur nach Unterweisung und Freigabe

Orientierung: 90–100 Punkte = sehr sicher begründet; 75–89 = gut und weitgehend vollständig; 60–74 = grundlegende Lösung mit Lücken; unter 60 = zentrale Prüfvoraussetzungen, Fehlerpfade oder Nachweise überarbeiten. Diese Skala ist eine didaktische Bewertung, keine offizielle Prüfungsordnung.

Lernnachweis

Als Lernnachweis gibst du eine kleine, nachvollziehbare Prüfkonfiguration für die beiden Lehrvarianten ab. Sie enthält eine Anforderungsübersicht, eine Tabelle der gemeinsamen und getrennten Testbausteine, Ablaufdiagramm oder Pseudocode, Start- und Abbruchregeln, einen Beispieldatensatz mit synthetischen Werten sowie ein Änderungsreview. Weise zu jeder Anforderung mindestens einen Testfall oder eine begründete Nichtanwendbarkeit zu.

Ein guter Nachweis zeigt, dass du falsche Wiederverwendung erkennst, fehlerhafte Startbedingungen kontrolliert behandelst, eindeutige Status nutzt und Ergebnisse rückverfolgbar dokumentierst. Benenne auch offene Fragen: Welche Spezifikation fehlt? Wer muss die Konfiguration fachlich prüfen? Welche Tests wären vor betrieblicher Verwendung nötig?

OER und Wikipedia

Primärquelle zum Maschinenbezug: IGH Automation – Turmdrehkrane. Die Seite berichtet über den Einsatz von Prüfsoftware im Werk Biberach seit 2003 und beschreibt Prüfstände für Elektrobaugruppen sowie Komponentenprüfstände. Die Webbeschreibung nennt kein Publikationsdatum und belegt weder die hier genutzten Lehr-IDs noch konkrete IGH-Softwareversionen.

Fachliche Vertiefung: IGH Automation – Softwaremodule erläutert unter anderem Prüfsequenzen, digitale Dokumentation, Fehlermanagement und Reports. IGH Automation – Baugruppenprüfung beschreibt die Prüfung von Hauptbaugruppen und die Simulation eines umgebenden Restsystems in einem anderen Anwendungsbeispiel.

Weitere offene Ressourcen zur Orientierung: Softwarequalität, Modultest und die Wikimedia-Commons-Dateiseite zur gemeinfreien Abbildung. Bei der zweiten Leiterplattenabbildung gilt CC BY-SA 4.0 gemäß ihrer Dateiseite; Quelle und Lizenz sind bei Weiterverwendung anzugeben. Videos werden nur ergänzt, wenn eine konkrete URL, der Inhalt und die Nutzungsbedingungen tatsächlich verifiziert sind; eine passende, belastbar verifizierte Videodatei lag für diesen Entwurf nicht vor.

Verknüpfte Lernbereiche

Die Aufgabe verbindet Elektrotechnik, Mechatronik, Softwareentwicklung, Testmanagement, technische Dokumentation und Qualitätsmanagement. Die fachliche Tiefe und die Reihenfolge sind redaktionelle Lernempfehlungen für das dritte Ausbildungsjahr; Betrieb und Berufsschule stimmen sie mit dem jeweiligen Ausbildungsplan ab.

Baugruppenprüfung und Prüffolgen

Passende interne Themen: Softwaretest, Softwarequalität, Modultest, Mechatronik, Elektronik, Testautomatisierung und Qualitätsmanagement.