Virtuelle FAT vs. physische FAT: Was ist der Unterschied?

Ein Fabrikabnahmetest ist der formale Lauf, in dem der Käufer prüft, dass eine Maschine vor dem Versand die vereinbarten Spezifikationen erfüllt. Tests decken Safety, Taktverhalten, HMI-Bedienung, Dokumentation und oft konkrete Leistungskennzahlen ab.

Ergebnisse speisen das Abnahmeprotokoll: bestanden, bedingt bestanden oder nicht bestanden mit Nacharbeit. Zeugennamen, Punch-Listen und Versandstops hängen in der Regel an diesem Lauf, nicht an einer früheren digitalen Probe.

Bei Sondermaschinen ist die FAT-Woche auch der Moment, in dem Software, Mechanik und Kunde zum ersten Mal dasselbe Objekt treffen. Sind Logikfehler noch offen, verschwindet die Hallenzeit in Debug statt in Abnahme.

Deshalb teilen Teams die Arbeit: Sequenzen und HMI-Abläufe früher gegen einen Zwilling nachweisen, dann die physische FAT für das nutzen, was nur Stahl, Sensorik und Medien zeigen können.

Virtuelle FAT wendet dasselbe Abnahmemindset auf einen digitalen Zwilling an, der an echte Steuerungssoftware gekoppelt ist. Testfälle laufen gegen simulierte I/O und repräsentative Bewegung statt gegen die volle physische Linie. Beteiligte können remote dabei sein, Befunde mit Reproduktionsschritten loggen und Suiten nach SPS-Drops erneut fahren, ohne die Montagehalle zu belegen.

Die Disziplin spiegelt die physische FAT: benannte Fälle, erwartete Ergebnisse, Beobachter und dokumentierte Ausgänge. Der Unterschied ist die simulierte Halle. Alarme lassen sich sicher injizieren; Randzustände, die an Hardware gefährlich oder verschwenderisch sind (verklemmtes Produkt, ausgefallenes Vakuum, wiederholte E-Stop-Zyklen), können wiederholt werden, bis der Wiederanlauf stimmt.

Knüpfen Sie virtuelle FAT-Fälle möglichst an Anforderungs-IDs aus der Funktionsspezifikation. Rückverfolgbarkeit macht sichtbar, welche Vertragsklauseln digital geübt wurden und welche noch einen Zeugen am Stahl brauchen.

Der Kunde muss nicht die gesamte Simulationsplattform sehen. Entscheidend ist, dass klar ist, welche Szenarien gelaufen sind, was bestanden hat, was fehlgeschlagen ist und was bewusst auf die physische FAT verschoben wurde. Diese Transparenz macht die virtuelle FAT zu einem Teil des Abnahmeprozesses statt zu einer technischen Demo.

Namen zählen in der Projektkommunikation. Manche Teams nennen die Sitzungen digitale FAT, simulierte Abnahme oder Pre-FAT: wählen Sie einen Begriff im Qualitätsplan, damit Beteiligte wissen, ob Unterschriften zum Umfang gehören. Unklare Namen sind der Weg, virtuelle Läufe mit vertraglichem Abschluss zu verwechseln.

Der Output ist Evidenz: Bildschirmaufnahmen, Testlogs und Issuelisten, die die physische FAT-Agenda formen. Verträge definieren weiterhin, was als formale Abnahme gilt; virtuelle FAT ist Vorbereitung und Risikoreduktion, kein Ersatz für Unterschriften an der versendeten Maschine, sofern nicht ausdrücklich vereinbart.

Beide sollen nachweisen, dass die Maschine der Absicht entspricht; sie unterscheiden sich in Umgebung, Evidenztyp und darin, welche Fehlerklassen zuerst auftauchen. Virtuelle FAT ist stark bei Logik, Sequenzen und Bedienabläufen. Physische FAT bleibt maßgebend für mechanischen Sitz, echte Sensoren, Lärm, Vibration und installierte Medien.

Physische FAT trägt auch Vertragslast: Zeugennamen, Punch-Listen am Versand und oft finanzielle Trigger. Virtuelle FAT landet selten in Unterschriftsfeldern, außer Legal und Qualität schreiben sie hinein. Behandeln Sie virtuelle Ergebnisse als Input für das formale Paket, nicht als automatischen Ersatz.

Ein weiterer Schnitt ist Wiederholbarkeit. Virtuelle Suiten können nach einem Patch über Nacht laufen; physische Wiederholungen brauchen oft Personal, Material und Hallenzeit. Diese Asymmetrie ist der Grund, softwarelastige Fälle digital vorzuziehen: mehr Iterationen pro Kalendertag.

Risikoeigentum unterscheidet sich ebenfalls. Funde aus virtueller FAT sind meist Korrekturen auf Seiten des Maschinenbauers, bevor der Kunde reist. Funde in der physischen FAT können vertragliche Mittel, Versandstops oder gemeinsame Root-Cause mit höheren Einsätzen auslösen.

Wenn beide Gates gemeinsam geplant sind, zählt die Reihenfolge: fahren Sie virtuelle FAT früh genug, damit Fixes in dem SPS-Build landen, den der Kunde am Stahl sieht, nicht in einem Last-Minute-Patch in der physischen Woche.

Nutzen Sie den Vergleich unten, wenn Sie Verantwortlichkeiten zwischen Engineering, Qualität und Kundenteam teilen. Virtuelle FAT und physische FAT decken unterschiedliche Fehlerklassen ab; die Tabelle ist die Teilung, keine Rangfolge, welches Gate mehr zählt.

Zuerst virtuell: Moduswechsel, Sicherheitsverriegelungen, Alarm- und Quittierungspfade, Rezeptbehandlung, HMI-Navigation, Datalogging-Trigger und Kommunikations-Handshakes mit MES oder Upstream, wenn Stubs existieren. Diese Fehler sind teuer zu debuggen, wenn Kundenbeobachter im Raum sitzen.

Negative Tests dazu: falsche SKU gewählt, Schutztür mitten im Takt geöffnet, Communication-Timeout zum Upstream, Wiederanlauf nach E-Stop. Virtuelle Umgebungen machen sie wiederholbar ohne Ausschuss oder Safety-Exposure.

Reservieren Sie die physische FAT für das, was das Modell nicht treu abbilden kann: echte Taktzeit unter Last, Pneumatik und Vakuum, Vision-Tuning, EMI, Schutzzäune und Materialstreuung. Markieren Sie Lücken ausdrücklich im Testplan, damit virtuelle Pass-Ergebnisse nicht überinterpretiert werden.

Teilen Sie den Testplan in Spalten: virtuell geeignet, nur physisch, hybrid. Hybridfälle können Bewegungsprofile virtuell auf Kollisionsrisiko prüfen und den Durchsatz dann am Stahl bestätigen. Qualitätsreviewer können jede Spalte zeichnen, ohne Standards zu mischen.

Bedienerschulung gehört in die virtuelle Spalte, wenn das Verfahren (Lockout-Schritte, Quittierungsreihenfolge, Dateneingabe) mehr zählt als die Liniengeschwindigkeit. Fahren Sie Bediener durch Störszenarien am Zwilling, bevor sie das echte HMI unter Druck berühren.

Dokumentieren Sie Zwilling-Grenzen neben jedem virtuellen Fall: vereinfachte Reibung, ideale Sensoren, angenommene Upstream-Verfügbarkeit. Reviewer können virtuelles Pass dann mit offenen Augen akzeptieren und physische Bestätigung nur dort planen, wo die Annahme zählt.

Eine brauchbare Regel: sitzt der Fehlermodus in Software oder Verfahren, starten Sie virtuell. Hängt er an Physik oder Installation, bleibt er physisch. Bewegungsprofile und enges Timing brauchen oft beides, mit Hardware-in-the-Loop dort, wo Scan-Cycle und Feldbus zählen.

Behandeln Sie sie wie ein formales Meeting. Verteilen Sie Testplan und Build-Stand im Voraus. Rollen vergeben: Bediener am HMI, Ingenieur an der SPS, Facilitator für Ergebnisse, Kundenbeobachter mit definierter Stimme zu Pass/Fail. Beginnen Sie mit Safety- und Moduschecks vor Taktdemos. Planen Sie mindestens einen internen Probelauf, bevor der Kunde eingeladen wird. Die Simulation sollte nicht zum ersten Mal vor dem Kunden starten.

Öffnen Sie mit einer Aussage zur Modelltreue: was genau modelliert ist, was als Stub nachgebildet ist, welche Fälle außerhalb des Umfangs liegen. Zwei Minuten hier verhindern stundenlange Debatten, wenn ein Test scheitert, weil Physik vereinfacht war.

Eine halbe Tagessitzung trägt eine abgegrenzte Zelle mit zehn bis fünfzehn bereits geskripteten kritischen Fällen. Ein ganzer Tag passt zu breiterer Abdeckung, mehreren Rezepten oder Remote-Teams über Zeitzonen. Legen Sie Pausen für Hotfixes und Wiederholungen ein: der Vorteil des Virtuellen ist schnelle Iteration, wenn ein Fix landet.

Nutzen Sie eine sichtbare Statusliste: Fälle bestanden, nicht bestanden, blockiert, auf physisch verschoben. Blockierte Fälle bedeuten meist fehlende Modelltreue oder unfertiges HMI; notieren Sie den Grund, damit die Verantwortlichen der physischen FAT wissen, was kommt.

Für Remote-Beobachter: eine Kamera auf das HMI, eine auf den Zwilling-Bildschirm; Lag zählt weniger als synchrones Erzählen, was geklickt wurde und was die SPS tat. Zeichnen Sie die Sitzung auf, auch wenn alle live dabei sind; Zeitzonenlücken tauchen später auf.

Nach der Sitzung: innerhalb eines Arbeitstags ein Kurzbericht: Pass/Fail-Zusammenfassung, offene Befunde und eine explizite Liste der auf physische FAT verschobenen Fälle. Geschwindigkeit hier baut Glaubwürdigkeit schneller als perfekte Grafik.

Schließen Sie mit Maßnahmen: offene Befunde, Verantwortliche, Zieldaten und welche Fälle an Hardware wiederholt werden müssen. Hängen Sie Aufzeichnungen oder Logs an das FAT-Paket, damit die physische FAT mit geteiltem Kontext öffnet statt dieselben Issues neu zu entdecken.

Der Nutzen zeigt sich als kürzere physische FAT-Nacharbeit und weniger Notreisen. Teams, die Abnahme digital proben, betreten die Halle oft mit einer priorisierten Punch-Liste statt offenem Debug. Wie groß der Effekt ist, hängt von Maschinenkomplexität und davon ab, ob die Testliste tatsächlich gepflegt wird.

Übersetzen Sie den Fall in Positionen, die Finance schon kennt: weniger Standby-Tage, weniger Flüge, weniger Überstunden am Montageteam und geringeres Risiko von Verspätungsstrafen. Bei komplexen Sondermaschinen kann eine vermiedene FAT-Verlängerung das Modellbudget übersteigen.

Kundenvertrauen vor dem Versand, eine glattere Übergabe an den Service und Bediener, die Störabläufe schon gesehen haben, zählen weiter, wenn die Kalkulation konservativ bleibt. Das zeigt sich später als weniger Supportanrufe im ersten Produktionsmonat.

Vergleichen Sie mit dem FAT-Burndown des letzten Projekts, wenn Sie einen haben. Stunden an Logik versus Mechanik sagen, ob virtuelle FAT in das nächste Angebot gehört.

Lassen Sie sie weg, wenn die Maschine trivial ist, die Abnahme lokal und informell, oder der Steuerungsstand aus einem identischen Vorgängerbau eingefroren ist. Modellierung kostet mehr, als sie bringt, wenn niemand Fälle pflegt oder an Sitzungen teilnimmt.

Schätzen Sie aus Ihren eigenen Zahlen: tägliche FAT-Kosten, Reise, Nacharbeitsstunden und Verspätungsstrafen. Unser ROI-Rechner strukturiert das Gespräch. Veröffentlichte Branchenfälle sind Benchmarks, keine Garantie für Ihre Linie.

Prüfen Sie die Schätzung nach dem ersten virtuellen FAT-Zyklus. Fehlerzahlen und Nacharbeitsstunden aus Projekt eins sind der stärkste Input, um Simulation in Projekt zwei zu zitieren.