Sådan laver du en digital idriftsættelsestestplan

Tvillingen så flot ud i demo. Så spurgte kunden, hvad der faktisk var verificeret, og svaret blev et Excel-ark, tre ingeniørers hukommelse og en liste over alarmer, der "plejer at gå væk af sig selv." En digital idriftsættelsestestplan findes for at undgå det øjeblik.

Det er det dokumenterede grundlag for, hvad I tester i virtuel idriftsættelse, hvordan I ved, at et scenarie er bestået, og hvad der stadig er åbent. Hvert scenarie har et nummer, en trigger, forventet adfærd, acceptkriterier, en ejer og en status. Det er mere end rækker i et regneark: det er det fælles sprog mellem automationsingeniør, mekanik, projektledelse og kvalitet.

Planen kobler tre ting: PLC-koden (eller soft-PLC), den digitale model og de mennesker, der skal blive enige om resultatet. Uden den kobling ender virtuelle kørsler som ad hoc-demoer, hvor automationsingeniøren ved, hvad der virker, men ingen andre kan spore det til accept.

Begrebet overlapper med fabriksaccept-protokollen, men opgaven er en anden. Testplanen er arbejdsbogen under udvikling. FAT-protokollen er ofte kundevendt dokumentation knyttet til formel accept. Mange punkter i FAT-protokollen starter som virtuelle testscenarier, der allerede er kørt og logget uger tidligere.

En stærk plan kan læses af nogen, der ikke har skrevet PLC'en. Triggers, trin, forventede resultater og beviskrav skal stå på projektsprog, ikke kun som interne tag-navne. Når en ny kollega overtager, eller kunden deltager i en forhåndsgennemgang, skal scenariet kunne køres uden mundtlig overlevering.

De fleste teams har allerede en model og adgang til PLC-simulation. Problemet starter, når ingen har aftalt, hvad der skal bevises. Demo-turen viser normal drift fint, men nødstop midt i cyklus, formatomstilling og tom buffer fordi forrige station stopper bliver aldrig beskrevet som konkrete testscenarier.

Uden faste scenarienavne og numre afhænger kvaliteten af, hvem der er til stede den dag. En erfaren automationsingeniør husker de kritiske interlocks; en ny kollega tester happy path. Ved fysisk fabriksaccept finder kunden huller, I troede var dækket, fordi "vi har jo kørt simulation."

Åbne punkter fragmenterer sig på tværs af mail, Teams og mødenoter. Ingen kan svare på, hvilken PLC-version der beviste scenarie VC-04, om fejlen er lukket, eller om kunden skal se det igen ved den fysiske maskine. Uden ét register bliver virtuel test aldrig en del af kvalitetssystemet.

Mekanik og automationsingeniører arbejder ofte ud fra forskellige mentale checklister. Mekanik tænker clearance, bevægelse og operatør adgang; automationsingeniøren tænker tilstandsmaskine og alarmtekst. En testplan tvinger begge perspektiver ind i samme struktur.

Hvert scenarie bør beskrive mindst fem ting: hvordan det startes (trigger), hvem der gør hvad (roller), hvad der skal observeres (forventet adfærd), hvornår det er bestået (kriterier), og hvordan det dokumenteres (bevis). Tilføj en sjette linje om tvillingens begrænsning, når modellen forenkler sensorer, timing eller materiale.

Triggers skal være konkrete. "Test nødstop" er ikke nok: angiv cyklusfasen, stationen og om operatøren skal handle på HMI. "Start auto med opskrift A efter fuld reset" er en trigger, I kan køre igen næste måned.

Acceptkriterier skal kunne observeres. "Sekvensen virker" er ikke et kriterie. "Al bevægelse stopper inden for defineret tid; HMI viser sikkerhedsstop; genstart følger den dokumenterede reset-sekvens" kan en intern reviewer eller kundeobserver teste.

Giv hvert scenarie en navngiven ejer: automationsingeniør, sikkerhed, mekanik eller projektleder. Ejerskab handler om, hvem der lukker åbne punkter, ikke kun hvem der trykkede start i simulationen.

Versionér testlisten sammen med PLC-projektet. Når logikken ændrer sig, opdater scenarier eller markér dem som forældede. Kør ikke grønne resultater fra en gammel PLC-version ind i ny FAT-dokumentation uden at matche versionsnummer.

I vores case: digital testplan før opstart viser vi, hvordan et maskinlinje-team satte struktur på testlisten, acceptkrav og åbne punkter omkring en Unity-baseret tvilling med Siemens- og Beckhoff-PLC.

Start med det, der gør ondt, hvis det fejler sent: sikkerhedsinterlocks og nødstop-gendannelse, skift mellem manuel, auto og service, format- eller opskriftomstilling, start og stop under delvis belastning, og signaludveksling med udstyr før og efter jeres maskine, når det er i scope.

Brug jeres egen historik. Hvilke fem til ti problemer dukkede op ved de sidste tre fabriksaccept-forløb? Hvis svaret handler om logik, HMI eller sekvens, hører det sandsynligvis hjemme i den virtuelle kolonne først.

På mindre projekter med få sekvenser og et lille team er fem velbeskrevne scenarier ofte nok. Én side med navn, hvordan testen startes, og hvornår den er bestået slår et tomt regneark, og I kan altid udvide listen, når strukturen viser sin værdi.

Prioritér negative test: forkert opskrift valgt, dør åbnet midt i cyklus, sensorudfald, MES-timeout, blokering på transportør. Virtuelle miljøer gør det muligt at gentage fejl uden skrot, støj eller sikkerhedsrisiko på gulvet.

Operatørflow er ofte undertestet. Korrekt PLC-logik med forvirrende alarmtekst eller reset-rækkefølge giver stadig fejl i drift. Inkludér scenarier, hvor operatøren skal bekræfte, eskalere eller vælge mellem tilladte HMI-handlinger under pres.

Et nyttigt skel mellem virtuel og fysisk scope finder I i vores guide om virtuel vs. fysisk FAT. Markér hvert nyt scenarie som kun virtuelt, kun fysisk eller begge dele, før I udvider testlisten ud over de første ti scenarier.

Skriv kriterier, I kan flytte fra virtuelle kørsler til fysisk fabriksaccept uden omskrivning. Byg dem på observerbar adfærd, ikke implementeringsdetaljer. "Ventil Q12 aktiveres" er internt. "Produkt frigives fra station 2 inden for aftalt cyklustid under opskrift A" er et kriterie kunden kan forholde sig til, når X står i specifikationen.

Skil must-pass fra nice-to-have. Must-pass scenarier blokerer næste milepæl, hvis de fejler. Nice-to-have kan udskydes til SAT eller en senere softwarerelease, men skal stadig logges, så de ikke forsvinder.

For sikkerhed: reference jeres risikovurdering og PLd- eller SIL-krav, hvor det er relevant. Virtuel bestået beviser ofte interlock-logik; fysisk fabriksaccept bekræfter afstande, dørkontakter og målte stopptider. Skriv i planen, hvad virtuel grøn dækker, og hvad der stadig skal bekræftes på den fysiske maskine med kunden til stede.

Brug ens skala for alvorlighed på åbne punkter: kritisk, major, minor. Uden skala ender enhver fejl som "vi tager den senere."

Når kunden deltager i virtuel forhåndsgennemgang, gennemgå acceptkriterierne for de scenarier, I viser. Det reducerer diskussioner ved fysisk fabriksaccept om, hvad "bestået" betød i simulationen.

Start med fast agenda: hvilke scenarier køres (fx VC-01 til VC-05), hvilken PLC-version er i scope, og hvilke åbne punkter fra sidst skal lukkes eller genåbnes. Uden agenda bliver mødet en fri demonstration.

Roller betyder noget. En mødeleder holder tempo; automationsingeniøren kører logik og simulation; HMI-ansvarlig observerer operatørflow; projektlederen dokumenterer beslutninger og scope. Mekanik deltager, når bevægelse, clearance eller omstilling er central. Sikkerhed vurderer interlock- og reset-scenarier.

Kør scenarier i prioriteret rækkefølge. Log afvigelser med scenarienummer, faktisk adfærd, forventet adfærd, alvorlighed og ejer. Tag skærmbilleder eller korte optagelser, når reproduktion er uklar.

Afslut med synlig status: grøn, gul eller rød pr. kritisk scenarie, og hvad der skal ske før næste session. Del protokollen samme dag. Virtuel review uden protokol tæller ikke i kundens acceptfortælling.

Planlæg mindst én intern gennemkørsel, før kunden inviteres. Første gang simulationen starter bør ikke være foran kunden.

Det stærkeste afkast fra en digital testplan er genbrug. Scenarier, der bestod virtuelt, bliver tjekliste ved fysisk fabriksaccept. Scenarier, der fejlede virtuelt og blev rettet, bør køres igen efter hver større ændring i PLC-programmet.

Markér tre kolonner i testlisten: kun virtuelt, kun fysisk, begge dele. Det forhindrer, at virtuelle bestået-resultater overfortolkes, og at I glemmer test, der kun kan køres på den rigtige maskine.

Operatørtræning kan bruge de samme scenarier i et langsommere tempo: alarm, reset, omstilling, eskalering. Når træningsmodulet deler ID'er med testplanen, ved I, hvilke flows operatøren har øvet, før maskinen står hos kunden.

Service arver værdien senere. Fejlrapporter fra site kan kobles tilbage til et scenarie: "VC-07 fejlede igen, da bufferen løb tør."

Når I skal begrunde indsatsen over for projektsponsorer, kan ROI-beregneren for virtuel idriftsættelse modellere udvikling, fabriksaccept og SAT separat med jeres egne antagelser.

Opdater planen efter fabriksaccept. Fysiske fund, der ikke var modelleret, bliver nye scenarier eller noter om tvillingens begrænsninger.