Kan AI bygge, teste og fejlfinde maskinsoftwaren selv?

Maskinsoftware bliver normalt udviklet i flere adskilte trin. En automationsingeniør læser kravene, skriver PLC-koden, konfigurerer motion, bygger projektet og tester dele af løsningen. Senere møder softwaren mekanikken. Først dér bliver nogle af antagelserne bag programmet udfordret af den faktiske maskine.

AI gør det muligt at forbinde flere af de trin. Hos neexo kan vi i dag give en engineering-agent adgang til langt mere end en kildekodefil. Den kan arbejde med eksisterende maskinsoftware, virksomhedens arkitektur og biblioteker, PackML, motion, HMI, I/O, teknisk dokumentation og information om den maskine, softwaren skal styre. Den kan bygge projektet, arbejde videre efter compilerfejl, køre mod en virtuel maskine, analysere traces og bruge resultatet i næste iteration.

En almindelig kodeassistent kan forklare en funktionsblok, foreslå Structured Text eller hjælpe med en compilerfejl. Det er nyttigt, men maskinen findes ikke i kode alene. En sekvens kan være korrekt programmeret og stadig være forkert for mekanikken. En motion-profil kan være korrekt konfigureret og samtidig efterlade for lidt tid til næste proces. Et signal kan være korrekt håndteret i PLC'en, mens eldiagrammet viser en anden intention. En sekvens til fejlgenopretning kan fungere i den normale test og fejle, når den efterfølgende station står stille.

Når agenten også har adgang til mekaniske og elektriske oplysninger, kan den koble softwaren til det system, den skal styre. Det giver et loop, hvor informationen flyder begge veje: krav og tekniske data, implementering, build, virtuel test, målinger og traces, analyse, ændring og ny test. Efter fysisk opstart kan data fra den rigtige maskine føres ind i samme proces.

Ja, hvis agenten får en tydelig softwarearkitektur og de nødvendige værktøjer. PLC-software hos en maskinbygger er sjældent et blankt stykke papir. Der findes allerede principper for struktur, navngivning, maskinmoduler, driftstilstande, alarmer, diagnostik, HMI og motion. Mange virksomheder har også biblioteker eller tidligere projekter, der viser, hvordan en god løsning skal se ud.

Det giver agenten et langt bedre udgangspunkt end en generel prompt om at skrive PLC-kode. Opgaven kan eksempelvis være at implementere en ny transferstation efter virksomhedens eksisterende maskinstandard.

Agenten kan arbejde med stationens tilstande og overgange, PackML-integration, adfærd i automatisk og manuel drift, spærringer, alarmer og status mod HMI. Hvis stationen indeholder servoakser, kan samme opgave omfatte aktivering, referencetagning, positionering, grænser og fejltilstande og de bevægelsesfunktioner, projektets arkitektur bruger.

Den kan også koble stationen ind i den omkringliggende maskine. Hvornår må den foregående station aflevere et produkt? Hvornår er den efterfølgende station klar? Hvad sker der, hvis et produkt mangler? Hvordan kommer modulet tilbage i en kendt tilstand efter et stop?

Det kræver gode standarder. En ustruktureret kodebase bliver ikke automatisk til god maskinsoftware, fordi en AI får adgang til den. Genanvendelig arkitektur, klare grænseflader og ensartede principper bliver tværtimod mere værdifulde, når både mennesker og agenter skal arbejde i samme projekt.

Det første feedback-loop er simpelt. Agenten ændrer projektet og bygger det. Hvis build fejler, får den compilerens fejlmeddelelser tilbage. Den finder årsagen, foretager en ændring og bygger igen.

Et PLC-projekt, der kan kompileres, fortæller ikke, om maskinen opfører sig korrekt. Derfor kan agenten kobles videre til et digitalt testmiljø, hvor den faktiske maskinlogik arbejder mod en model med den relevante mekanik, sensorer, aktuatorer, produktflow og motion.

Tag en transferstation som illustrativt eksempel. Stationen modtager et produkt, positionerer det og afleverer det videre. Normal sekvens er kun begyndelsen på testen. Agenten kan også afprøve, hvad der sker, når den efterfølgende station ikke bliver klar, en sensor skifter senere end forventet, et produkt mangler, en bevægelse bliver afbrudt, eller maskinen stoppes midt i en overgang. Efter hver ændring kan de relevante scenarier køres igen.

En automationsingeniør behøver dermed ikke vælge mellem at bruge tiden på implementeringen eller på en lang række gentagne regressionstests. Agenten kan udføre meget af det gentagne arbejde, mens ingeniøren bestemmer arkitektur, testintention og de grænser, løsningen skal holde sig indenfor. Test bliver en kontinuerlig del af udviklingen i stedet for en aktivitet, der først får fuld opmærksomhed tæt på FAT.

De fleste tests starter med en kendt forventning. Vi ved, at en sensor kan fejle, så vi tester sensorfejl. Vi ved, at den efterfølgende station kan stoppe, så vi tester et stop. Vi kender en tidligere fejl i fejlgenopretningen, så den bliver til en regressionstest. Det efterlader de problemer, ingen havde tænkt på.

Når agenten kan læse traces og maskindata, kan den undersøge en kørsel for afvigelser i stedet for kun at kontrollere, om den består de fastlagte testkriterier. En test kan godt bestå, samtidig med at noget interessant har ændret sig.

En akse bruger længere tid på acceleration. Momentet ligger anderledes end i referencekørslen. En programtilstand er aktiv lidt længere. En sekvens venter oftere på en bestemt signaludveksling. Fejlgenopretningen tager en anden vej gennem programmet end tidligere. Ingen af de observationer er automatisk en fejl. De er spor, som agenten kan undersøge.

Den kan gå tilbage til softwareændringen, sammenligne med tidligere traces, se på bevægelsesparametre og undersøge, om ændringen hænger sammen med andre dele af maskinen. Testplanen er stadig nødvendig, men den suppleres med en agent, der kan lede efter adfærd, vi ikke havde skrevet ind i testplanen på forhånd.

En af de største begrænsninger ved en ren kodeagent er, at den naturligt leder efter forklaringen i softwaren. Virkelige maskinproblemer respekterer ikke den grænse.

Hvis en akse kommer for sent frem, kan sekvensen være forkert. Det kan også skyldes bevægelsesprofilen, en ændret mekanisk belastning eller et signal, der kommer senere end forventet. Hvis agenten har adgang til hele konteksten, kan den skelne bedre mellem mulighederne.

Forestil dig, at en trace viser, at en bevægelse nu tager længere tid end i tidligere tests. Agenten kan kontrollere, om starttidspunktet fra PLC'en har ændret sig. Hvis det ikke har, kan den sammenligne hastigheds- og momentkurverne. Den kan derefter holde målingen op mod den mekaniske konfiguration og de relevante ændringer i projektet.

AI kan ikke diagnosticere enhver fysisk fejl alene. Men den kan samle information, som normalt ligger fordelt mellem automation, mekanik, el og idriftsættelse, og bruge den i samme undersøgelse.

Før fysisk opstart kan agenten arbejde mod simulationen. Efter opstart kan den samme logik suppleres med traces og målinger fra den rigtige maskine. Forskellen mellem forventet og observeret adfærd bliver et nyt input til engineering-processen. Simulationen kan dermed fungere som reference for, hvordan maskinen forventes at opføre sig, ikke kun som et miljø til test før FAT.

Agenten behøver ikke stoppe og spørge en bruger efter hver compilerfejl eller hver mislykkede regressionstest. En stor del af loopet kan køre autonomt: implementering, build, test, trace, analyse, ændring og regressionstest.

Der bør stadig være tydelige grænser omkring handlinger, der påvirker den fysiske maskine eller ændrer væsentlige tekniske forudsætninger. En agent kan godt komme frem til, at en bevægelsesprofil bør ændres. Det er noget andet end automatisk at sende den nye profil til en produktionsmaskine og bevæge aksen.

Den praktiske arkitektur handler derfor om at flytte godkendelsespunkterne. Mennesket behøver ikke godkende hver lille operation. Kontrolpunkter giver mere mening omkring sikkerhedsrelateret adfærd, overførsel til fysisk udstyr, nye bevægelsesgrænser og andre ændringer med en reel fysisk konsekvens.

For den tekniske leder bliver et vigtigt spørgsmål derfor: Hvilke handlinger må agenten udføre og verificere selv, og hvilke ændringer kræver ingeniørfaglig vurdering eller fysisk godkendelse? Det spørgsmål er mere nyttigt end en generel diskussion om, hvorvidt man stoler på AI.

Teknisk dokumentation har et tilbagevendende problem: Den bliver ofte skrevet efter arbejdet. På det tidspunkt kan koden fortælle, hvad løsningen gør. Den fortæller sjældent hele historien om, hvorfor løsningen endte sådan.

Hvorfor ligger denne spærring her? Hvorfor blev denne bevægelsesprofil valgt? Hvilken test førte til ændringen? Hvilke alternativer blev prøvet? Hvad viste tracen?

Når agenten har været en del af engineering-loopet, findes meget af den information allerede. Den har set kravet, implementeringen, build-resultaterne, testscenarierne, traces, ændringerne og de efterfølgende regressionstests. Den kan derfor dokumentere beslutningen på baggrund af den proces, der faktisk fandt sted.

Dokumentationen kan knytte kode og parametre til deres tekniske begrundelse. Den kan forklare, hvilken situation en ændring skulle løse, hvilken evidens der blev brugt, og hvilke tests der efterfølgende blev kørt. Service kan se baggrunden for løsningen, en ny ingeniør kan forstå, hvorfor et stykke kode ser ud, som det gør, og næste maskinprojekt kan genbruge både implementeringen og erfaringerne fra testen.

Når implementering bliver billigere, bliver kvaliteten af krav, arkitektur, begrænsninger og testintention vigtigere. Agenten skal vide, hvad god software er i netop jeres virksomhed. Den skal have en maskinarkitektur at arbejde indenfor og kende forskellen på en ufarlig softwareændring og en ændring, der kræver fysisk validering.

AI kan overtage mere af det gentagne arbejde mellem de beslutninger. Det kan være at oprette softwaremoduler, rette buildfejl, køre regressionstests, sammenligne traces, kontrollere grænseflader og holde dokumentationen ajour. Resultatet bør ikke måles alene på, hvor mange programmeringstimer der forsvinder. Et mere interessant mål er, hvor meget mere teknisk arbejde projektet får udført.

Start ikke med hele maskinen. Vælg et afgrænset maskinmodul med en rigtig PLC-funktion, klare grænseflader og mulighed for at teste adfærden digitalt. Det kan være en transfer, en processtation eller et bevægelsesmodul. Giv agenten adgang til den eksisterende standard og de værktøjer, den faktisk skal bruge. Lad den implementere en afgrænset ændring, bygge projektet og køre et kendt sæt tests.

Derefter kan loopet udvides med mere regressionstest, traces, mekanisk og elektrisk kontekst og til sidst feedback fra den fysiske maskine. En engineering-agent bør måles på, om den kan levere en ændring, der bygger, opfører sig korrekt, består de relevante tests og efterlader et forståeligt spor af, hvorfor løsningen ser ud, som den gør.