⚡ electrical engineering

Using Large Language Models for Black-Box Testing of FMU-Based Simulations

Dit artikel stelt een mens-in-de-lus-benadering voor die gebruikmaakt van grote taalmodellen om automatisch gestructureerde testscenario's en asserties te genereren voor black-box-testen van Functionele Mock-up Units (FMU's), met als doel de handmatige inspanning te verminderen en de interpreteerbaarheid van resultaten in dynamische simulatiemodellen te verbeteren.

Oorspronkelijke auteurs: Abdullah Mughees, Gaadha Sudheerbabu, Tanwir Ahmad, Dragos Truscan, Mikael Manngård, Kristian Klemets

Gepubliceerd 2026-04-29

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Abdullah Mughees, Gaadha Sudheerbabu, Tanwir Ahmad, Dragos Truscan, Mikael Manngård, Kristian Klemets

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een gloednieuwe, high-tech motor voor een schip hebt, maar deze zit opgesloten in een zwarte doos. Je kunt de tandwielen, de bedrading of de code erin niet zien. Je hebt alleen een handleiding die zegt: "Deze doos neemt water en brandstof op, en spitst hitte en beweging uit." Jouw taak is om ervoor te zorgen dat deze zwarte doos perfect werkt zonder deze ooit open te maken. Dit is de uitdaging van het testen van FMU's (Functionele Mock-up Units), standaard digitale modellen die ingenieurs gebruiken om complexe systemen te simuleren.

Het artikel stelt een slimme manier voor om dit op te lossen met behulp van AI (Grote Taalmodellen) als "creatieve assistent", maar met een zeer belangrijke regel: een menselijk expert moet altijd aan het stuur zitten.

Hier is hoe hun "Human-in-the-Loop"-aanpak werkt, opgesplitst in eenvoudige stappen:

1. De Opstelling: De Handleiding Lezen

Eerst leest de AI de "handleiding" (de technische specificaties en data-bestanden) van de zwarte doos. Het fungeert als een bibliothecaris die een lijst trekt van wat erin gaat (ingangen zoals temperatuur of druk) en wat eruit komt (uitgangen zoals olietemperatuur of klepstand).

De Analogie: Denk hierbij aan de AI die de ingrediëntenlijst op een cakemixdoos leest om te begrijpen wat het kan doen, zonder het geheime recept erin te kennen.

2. Het Brainstormen: Het Schrijven van "Wat Als"-Verhalen

Vervolgens wordt de AI gevraagd om verschillende testscenario's te bedenken. Het schrijft deze in een eenvoudig verhaalformaat genaamd "Gegeven-Wanneer-Dan".

Gegeven: De motor draait normaal.
Wanneer: Plotseling raakt het schip een storm (een verandering in de ingang).
Dan: De motor moet koel blijven en niet oververhitten (het verwachte resultaat).
De Analogie: De AI is als een creatieve schrijver die plotideeën voor een film presenteert. Het suggereert: "Wat als de held bang wordt? Wat als het regent?" Het genereert veel verschillende "wat als"-verhalen om te zien hoe het systeem reageert.

3. De Realiteitscheck: De Menselijke Expert

Dit is het meest kritieke deel. De "verhalen" van de AI zijn slechts ideeën. Een menselijk expert (een domeinspecialist die weet hoe echte motoren werken) beoordeelt ze.

De Analogie: Stel je voor dat de AI een junior kok is die wilde recepten suggereert. De Hoofdkok (de mens) proeft het idee en zegt: "Nee, we doen geen chocolade in de soep," of "Ja, dat kruidenmengsel klinkt perfect." De mens filtert de gekke ideeën eruit en houdt de realistische over.
Waarom dit belangrijk is: Het artikel vond dat als je de AI de vrije loop laat zonder dat een mens controleert, het ongeveer 50% onbruikbare of verkeerde tests creëert. Met de menselijke controle stijgt de nauwkeurigheid naar bijna 100%.

4. De Uitvoering: De Simulatie Draaien

Zodra de mens de testideeën heeft goedgekeurd, zet de AI ze om in precieze instructies (cijfers, timing en specifieke waarden). Het voert vervolgens de simulatie duizenden keren uit, voert deze ingangen in de zwarte doos en observeert de uitgangen.

De Analogie: De AI is nu de regisseur die de lichten en het geluid precies instelt zoals de Regisseur (de mens) heeft goedgekeurd, en de voorstelling laat lopen om te zien of de acteurs (het systeem) correct optreden.

5. Het Oordeel: Is het Geslaagd?

Het systeem controleert of de resultaten overeenkomen met het "Dan"-gedeelte van het verhaal. Bleef de temperatuur binnen de limieten? Bewoog de klep op de juiste manier?

De Analogie: Het is als een scheidsrechter die fluit. Als de motor oververhit raakt wanneer dat niet zou mogen, is de test mislukt. Als het zich perfect gedraagt, is de test geslaagd.

De Geheime Ingrediënten: Twee Verschillende "Persoonlijkheden" voor de AI

De auteurs merkten op dat de AI voor dit werk twee verschillende stemmingen nodig heeft:

Creatieve Stemming (Hoge Willekeur): Bij het brainstormen van ideeën zeggen ze de AI dat het wild en divers moet zijn, zodat het niet blijft hangen in hetzelfde testidee keer op keer.
Strenge Stemming (Lage Willekeur): Bij het omzetten van die ideeën in echte cijfers en het uitvoeren van de tests, zeggen ze de AI dat het precies en saai moet zijn, zodat de wiskunde exact is.

De Resultaten

Ze testten dit op een Smeermiddelkoelsysteem (een systeem dat voorkomt dat de motorolie van een schip te heet wordt).

Ze vergeleken hun door AI ondersteunde tests met tests die volledig door mensen waren gemaakt.
De Bevinding: De door AI gegenereerde tests waren net zo goed in het vinden van "bugs" of potentiële storingen als de door mensen gemaakte.
De Haken en Ogen: De AI is snel en kan veel ideeën genereren, maar het moet de mens hebben om de onzin eruit te filteren. Zonder de mens maakt de AI fouten. Met de mens wordt het een krachtig hulpmiddel dat tijd en moeite bespaart.

Kortom: Dit artikel toont aan dat je AI kunt gebruiken om ingenieurs te helpen complexe, onzichtbare computermodellen te testen, maar alleen als je de AI behandelt als een behulpzame stagiair die een senior manager nodig heeft om zijn werk te controleren. Je vervangt de expert niet; je geeft hen een supersnelle assistent.

1. Probleemstelling

Moderne engineeringssystemen vertrouwen sterk op modelgebaseerd ontwerp met behulp van Functional Mock-up Units (FMU's) voor simulatie en co-simulatie. FMU's kapselen modelbinaries en beschrijvingen in, maar verbergen interne vergelijkingen en solver-details, waardoor traditionele witte-doos-testen onuitvoerbaar zijn. Bijgevolg moet verificatie vertrouwen op zwarte-doos-testen, wat het definiëren van complexe testscenario's vereist op basis uitsluitend van functionele specificaties en interface-beschrijvingen.

Uitdaging: Het handmatig definiëren van diverse testscenario's, invoer-tijdreeksen en verwachte output-gedragingen (orakels) voor dynamische systemen is arbeidsintensief, foutgevoelig en moeilijk schaalbaar.
Kloof: Bestaande geautomatiseerde testmethoden vereisen vaak toegang tot interne modelstructuren (bijv. Simulink-internals) of missen mechanismen om menselijk leesbare, domeinspecifieke testdoelen te genereren voor zwarte-doos FMU's.

2. Methodologie

De auteurs stellen een Human-in-the-Loop (HITL)-kader voor dat Large Language Models (LLM's) benut om de generatie van zwarte-doos testscenario's te automatiseren. De aanpak volgt een hiërarchie van drie abstractieniveaus: Intentie (Doelen) $\rightarrow$ Sjablonen (Plannen) $\rightarrow Uitvoerbare Tijdreeksen (Scenario's).**

A. Overzicht van de Werkwijze

Invoer: Een FMI-compliant FMU (specifiek modelDescription.xml) en documenten met functionele specificaties.
LLM-extractie: De LLM extrahert I/O-beperkingen (variabelenamen, eenheden, bereiken) uit de metadata.
Scenario-generatie (Iteratieve Fasen):
- Fase 1: Doelgeneratie: De LLM genereert hoogwaardige testdoelen in Given-When-Then (GWT)-formaat (Gherkin-syntaxis). Deze doelen beschrijven kwalitatieve precondities, verstoringen en verwachte gedrags-trends (bijv. "monotone toename", "stabiliseert naar setpoint").
- Fase 2: Plangeneratie: Goedgekeurde doelen worden omgezet in concrete Scenario-plannen. De LLM definieert specifieke invoerpatronen (constant, stap, helling), groottes, timing en formele assertie-orakels (bijv. bounded, crosses_above, settles_to) met numerieke drempelwaarden afgeleid van beperkingen.
- Fase 3: Scenario-instantiatie: Plannen worden omgezet in uitvoerbare tijdreeksen met behulp van Latin Hypercube Sampling (LHS) met een vaste willekeurige seed om deterministische generatie en duplicaatverwijdering te waarborgen.
Human-in-the-Loop: Een domeinexpert beoordeelt doelen en plannen in elke fase om haalbaarheid, veiligheid en domeinlogica te valideren voordat uitvoering plaatsvindt.
Uitvoering & Evaluatie: De FMU wordt gesimuleerd met de gegenereerde invoer. Asserties worden geëvalueerd tegen opgenomen outputs om doorval/verval-verdicten te produceren.

B. Belangrijke Technische Mechanismen

Prompt Engineering: Het systeem gebruikt schema-first prompting met strikte JSON-schema's, few-shot voorbeelden en roldefinities om gestructureerde, machineleesbare outputs te waarborgen.
Temperatuurcontrole: Er wordt een gesplitste-temperatuurstategie toegepast:
- Hoge Temperatuur (0,7) voor Doelgeneratie om diversiteit en creativiteit te maximaliseren.
- Lage Temperatuur (0,2) voor Plangeneratie om determinisme en precisie in numerieke waarden te waarborgen.
Orakeldefinitie: In plaats van exacte numerieke waarden te voorspellen (wat moeilijk is voor dynamische systemen), genereert de LLM generieke orakels die trends beschrijven (bijv. "output stabiliseert binnen tolerantie $t$ naar doel").
Duplicaatverwijdering: Er wordt een hash-mechanisme gebruikt om dubbele doelen, plannen en scenario's over runs heen te detecteren en te verwijderen om efficiëntie te optimaliseren.

3. Belangrijkste Bijdragen

HITL-kader voor FMU's: Een innovatieve workflow die LLM's integreert met domeinexpert-review, specifiek voor zwarte-doos testen van ingekapselde simulatiemodellen.
Gestructureerde Scenario-generatie: Een methode om ongestructureerde FMU-metadata om te zetten in gestructureerde GWT-doelen en uitvoerbare tijdreeksplannen met behulp van prompt engineering en schema-beperkingen.
Mutatiegebaseerde Toereikendheidsevaluatie: De auteurs introduceren een aangepaste mutatieanalyse-methode om de kwaliteit van gegenereerde scenario's te evalueren. Omdat interne code niet beschikbaar is, muteren ze de output-tijdreeks van de FMU (bijv. Mirror, Random Uniform, Crossover, Polynoom-mutaties) om "mutanten" te creëren en meten ze hoeveel ervan worden "gedood" (gedetecteerd als fouten) door de gegenereerde testset.
Praktische Implementatie: Een complete toolchain die de generatie, uitvoering en logging van testscenario's demonstreert voor een Lube Oil Cooling (LOC)-systeem.

4. Resultaten

De aanpak werd geëvalueerd op een FMU van een Lube Oil Cooling (LOC)-systeem.

Nauwkeurigheid: Zonder menselijke review hadden de door de LLM gegenereerde scenario's een gemiddelde nauwkeurigheid van 47% door hallucinaties en onrealistische beperkingen. Met domeinexpert-validatie steeg de nauwkeurigheid tot bijna 100%.
Vermogen tot Foutdetectie:
- Mutatiescore: De door de LLM gegenereerde scenario's behaalden een mutatiescore van 0,67 (47 van de 70 mutanten gedood).
- Vergelijking: Dit is vergelijkbaar met handmatig gemaakte scenario's, die een score van 0,685 behaalden (48 mutanten gedood).
- Conclusie: De door LLM ondersteunde aanpak genereert scenario's met een equivalent vermogen tot foutdetectie als handmatige testen.
Efficiëntie: Het end-to-end generatieproces (beperkingen, doelen, plannen) voor een batch van 8–10 scenario's duurde minder dan één minuut per run.
Dekking: De aanpak genereerde aanvullende, diverse scenario's die verder gingen dan wat een menselijke expert handmatig had gemaakt, waarbij verschillende gedragsvariaties werden gedekt.

5. Betekenis en Toekomstig Werk

Betekenis: Dit werk toont aan dat LLM's effectief de kloof kunnen overbruggen tussen hoogwaardige functionele specificaties en laagwaardige uitvoerbare testgevallen voor zwarte-doos simulatiemodellen. Het vermindert handmatige inspanning aanzienlijk terwijl het hoge testkwaliteit behoudt door menselijk toezicht.
Beperkingen:
- Niet-determinisme: LLM-outputs kunnen variëren tussen runs, zelfs met vaste seeds, wat robuuste duplicaatverwijdering vereist.
- Hallucinaties: Het model kan nog steeds onrealistische parameterbereiken genereren, wat menselijke review noodzakelijk maakt.
- Orakelvertrouwen: De geldigheid van kwalitatieve orakels hangt af van het begrip van de LLM van systeemdynamica; onjuiste drempelwaarden kunnen leiden tot vals-positieven/vals-negatieven.
Toekomstige Richtingen: Uitbreiden van de aanpak naar co-simulatie (multi-FMU-opstellingen) en implementeren van een active learning-loop waarbij de LLM zichzelf opnieuw prompt op basis van simulatiefouten om toekomstige testgevallen te verfijnen.

Kortom, het artikel presenteert een robuuste, praktische methodologie voor het automatiseren van het testen van complexe engineering-simulaties, en bewijst dat LLM's, wanneer ze worden geleid door strikte prompting en menselijke expertise, kunnen dienen als krachtige assistenten bij de verificatie en validatie van zwarte-doos systemen.