Virtuel FAT vs. fysisk FAT: Hvad skal I teste hvor?

En fabriksaccept er den formelle kørsel, hvor køberen verificerer, at maskinen opfylder aftalte specifikationer, før den afskibes. Tests dækker sikkerhed, cyklusadfærd, HMI-betjening, dokumentation og ofte konkrete performance-mål.

Resultaterne fodrer acceptprotokollen: bestået, betinget bestået, eller dumpet med omarbejde. Vidnenavne, punch-lister og afskibningshold knytter sig som regel til denne kørsel, ikke til en tidligere digital prøve.

På kundespecificeret maskineri er FAT-ugen også det tidspunkt, hvor software, mekanik og kunden møder det samme objekt for første gang. Hvis logikfejl stadig er åbne, forsvinder gulvtiden i debug i stedet for accept.

Derfor splitter teams arbejdet: bevis sekvenser og HMI-flow tidligere mod en tvilling, og brug fysisk FAT til det, kun stål, sensorer og forsyninger kan vise.

Virtuel FAT anvender samme acceptmindset på en digital tvilling koblet til rigtig styresoftware. Testcases køres mod simuleret I/O og repræsentativ motion i stedet for den fulde fysiske linje. Stakeholders kan deltage remote, logge fejl med reproduktionstrin og køre suiter igen efter PLC-drops uden at optage byggehallen.

Disciplinen spejler fysisk FAT: navngivne cases, forventede resultater, observatører og dokumenterede udfald. Forskellen er, at gulvet er simuleret. Alarmer kan injiceres sikkert; kanttilstande, der er farlige eller spildende på hardware (fastsiddende produkt, svigtende vakuum, gentagne e-stop-cyklusser), kan gentages, indtil recovery-stien er korrekt.

Kobl virtuelle FAT-cases til krav-ID'er fra den funktionelle spec, når det er muligt. Sporbarhed gør det tydeligt, hvilke kontraktklausuler der er øvet digitalt, og hvilke der stadig kræver et vidne på stål.

Kunden behøver ikke at se hele simulationsplatformen. Det afgørende er, at det er tydeligt, hvilke scenarier der er kørt, hvad der bestod, hvad der fejlede, og hvad der bevidst er udskudt til fysisk FAT. Den gennemsigtighed gør virtuel FAT til en del af acceptforløbet i stedet for en teknisk demo.

Navngivning betyder noget i projektkommunikation. Nogle teams kalder sessionerne digital FAT, simuleret accept eller pre-FAT: vælg ét begreb i kvalitetsplanen, så interessenter ved, om underskrifter er i scope. Uklar navngivning er vejen til, at virtuelle kørsler bliver forvekslet med kontraktlukning.

Outputtet er evidens: skærmoptagelser, testlogs og issuelister, der former den fysiske FAT-dagsorden. Kontrakten definerer stadig, hvad der tæller som formel accept; virtuel FAT er forberedelse og risikoreduktion, ikke erstatning for underskrifter på den afskibede maskine, medmindre det er eksplicit aftalt. Se, hvordan det kan struktureres, i vores case om digital idriftsættelsestestplan.

Begge sigter mod at bevise, at maskinen matcher hensigten; de adskiller sig i miljø, evidenstype og hvilke fejlklasser der kommer først. Virtuel FAT er stærk på logik, sekvenser og operatørflow. Fysisk FAT forbliver autoritativ for mekanisk pasform, rigtige sensorer, støj, vibration og installerede forsyninger.

Fysisk FAT bærer også kontraktvægt: vidnenavne, punch-lister bundet til afskibning og ofte økonomiske triggere. Virtuel FAT lander sjældent i underskriftsfelter, medmindre legal og kvalitet skriver det ind. Behandl virtuelle resultater som input til den formelle pakke, ikke som automatiske erstatninger.

Et andet skel er gentagelighed. Virtuelle suiter kan køre natten over efter en patch; fysiske gentagelser kræver ofte folk, materiale og gulvtid. Den asymmetri er grunden til, at teams lægger softwaretunge cases digitalt forrest: de får flere iterationer pr. kalenderdag.

Risikoejerskab adskiller sig også. Fund fra virtuel FAT er typisk rettelser hos maskinbyggeren, før kunden rejser. Fund ved fysisk FAT kan udløse kontraktmidler, afskibningshold eller fælles root-cause med højere stakes.

Når begge gates planlægges sammen, betyder rækkefølgen noget: kør virtuel FAT tidligt nok til, at rettelser lander i den PLC-build, kunden ser på stål, ikke i en sidste-øjebliks-patch i den fysiske uge.

Brug sammenligningen nedenfor, når I splitter ansvar mellem engineering, kvalitet og kundeteamet. Virtuel FAT og fysisk FAT dækker forskellige fejlklasser; tabellen er splittet, ikke en rangering af, hvilken gate der tæller mest.

Kør virtuelt først: modeskift, sikkerhedsinterlocks, alarm- og kvitteringsstier, receptbehandling, HMI-navigation, datalogging-triggere og kommunikations-handshakes med MES eller upstream, når stubs findes. De fejl er dyre at debugge med kundeobservatører i rummet.

Tag negative tests med: forkert SKU valgt, vagt åbnet midt i cyklus, communication timeout til upstream, og recovery efter e-stop. Virtuelle miljøer gør dem gentagelige uden scrap eller sikkerhedseksponering.

Reservér fysisk FAT til det, modellen ikke kan gengive troværdigt: faktisk cyklustid under last, pneumatik og vakuum, vision-tuning, EMI, vagtinteraktioner og materialevariation. Markér hullerne eksplicit i testplanen, så virtuelle pass-resultater ikke overfortolkes.

Split testplanen i kolonner: virtuel-egnet, kun fysisk, og hybrid. Hybrid-cases kan verificere motion-profiler virtuelt for kollisionsrisiko og så bekrefte throughput på stål. Kvalitetsreviewere kan signere hver kolonne uden at blande standarder.

Operatørtræning hører i den virtuelle kolonne, når procedure (lockout-trin, kvitteringsrækkefølge, data entry) betyder mere end linjehastighed. Kør operatører gennem fejlscenarier på tvillingen, før de rører det rigtige HMI under pres.

Dokumentér tvillingens begrænsninger ved hver virtuel case: forenklet friktion, ideelle sensorer, antaget upstream-tilgængelighed. Reviewere kan så acceptere virtuelt pass med åbne øjne og planlægge fysisk bekræftelse kun dér, hvor antagelsen betyder noget.

En nyttig regel: sidder fejlmoden i software eller procedure, start virtuelt. Afhænger den af fysik eller installation, hold den fysisk. Motion-profiler og stram timing har ofte brug for begge, med hardware-in-the-loop på de cases, hvor scan cycle og feldbus betyder noget.

Behandl det som et formelt møde. Send testplan og build-revision ud i forvejen. Fordel roller: operatør på HMI, ingeniør på PLC, facilitator der fanger resultater, og kundeobservatører med en defineret stemme på pass/fail. Start med sikkerhed og mode-tjek før cyklusdemoer. Planlæg mindst én intern gennemkørsel, før kunden inviteres. Første gang simulationen starter, bør ikke være foran kunden.

Åbn med en erklæring om tvillingens troværdighed: hvad er modelleret nøjagtigt, hvad er stubbet, og hvilke cases er ude af scope. To minutter her forhindrer timeslange debatter, når en test fejler, fordi fysikken var forenklet.

En halvdagssession virker til en afgrænset celle med ti til femten kritiske cases, der allerede er scriptet. En heldagssession passer til bredere dækning, flere recepter eller remote teams på tværs af tidszoner. Læg pauser ind til akutte rettelser og gentagelser: fordelen ved virtuelt er hurtig iteration, når en fix lander.

Brug en synlig statustavle: cases bestået, dumpet, blokeret, udskudt til fysisk. Blokerede cases betyder typisk manglende modeltroværdighed eller ufærdig HMI; notér grunden, så de, der ejer fysisk FAT, ved, hvad der kommer.

Til remote observatører: del ét kamera på HMI og ét på tvillingeskærmen; lag betyder mindre end synkron fortælling om, hvad der blev klikket, og hvad PLC'en gjorde. Optag sessionen, selv hvis alle er live; tidszonehuller viser sig senere.

Efter sessionen: udgiv en status inden for én arbejdsdag: pass/fail-oversigt, åbne fejl og en eksplicit liste over cases udskudt til fysisk FAT. Hastighed her bygger troværdighed hurtigere end perfekt grafik.

Luk med handlinger: åbne fejl, ejere, frister og hvilke cases der skal gentages på hardware. Vedhæft optagelser eller logs til FAT-pakken, så fysisk FAT åbner med delt kontekst i stedet for at genopdage de samme issues.

Gevinsten viser sig som kortere fysisk FAT-omarbejde og færre nødrejser. Teams, der øver accept digitalt, går ofte ind i byggehallen med en prioriteret punch-liste i stedet for åben debug. Hvor stor effekten er, afhænger af maskinkompleksitet og om testlisten faktisk vedligeholdes.

Oversæt casen til linjer, finance allerede kender: færre standby-dage, færre fly, mindre overtid på byggeteamet og lavere risiko for forsinkelsesbod. På komplekst kundespecificeret udstyr kan én undgået FAT-forlængelse overstige modelleringsbudgettet.

Kundetillid før afskibning, en glattere handover til service og operatører, der allerede har set fejlflow, betyder stadig noget, når regnearket er konservativt. Det viser sig senere som færre supportkald i den første produktionsmåned.

Sammenlign med jeres sidste projekts FAT-burndown, hvis I har én. Timer brugt på logik versus mekanik fortæller, om virtuel FAT fortjener en linje i næste tilbud.

Spring den over, når maskinen er trivial, accepten er lokal og uformel, eller styrekoden er frosset fra en identisk tidligere build. Modellering koster mere, end den giver, hvis ingen vil vedligeholde cases eller møde op til sessioner.

Estimér ud fra jeres egne tal: daglig FAT-omkostning, rejse, omarbejdstimer og forsinkelsesbod. Vores ROI-beregner strukturerer den samtale. Publicerede brancheeksempler er pejlemærker, ikke en garanti for jeres linje.

Genbesøg estimatet efter første virtuelle FAT-cyklus. Fejltal og omarbejdstimer fra projekt ét er det stærkeste input til at citere simulation på projekt to.