⚡ electrical engineering

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

This paper proposes a human-in-the-loop approach that leverages Large Language Models to automatically generate structured test scenarios and assertions for black-box testing of Functional Mock-up Units (FMUs), aiming to reduce manual effort and enhance result interpretability in dynamic simulation models.

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

Published 2026-04-29

📖 5 min read🧠 Deep dive

CC BY 4.0

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

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you have a brand-new, high-tech engine for a ship, but it's locked inside a black box. You can't see the gears, the wires, or the code inside. You only have a manual that says, "This box takes in water and fuel, and it spits out heat and motion." Your job is to make sure this black box works perfectly without ever opening it. This is the challenge of testing FMUs (Functional Mock-up Units), which are standard digital models used by engineers to simulate complex systems.

The paper proposes a clever way to solve this using AI (Large Language Models) as a "creative assistant," but with a very important rule: a human expert must always be in the driver's seat.

Here is how their "Human-in-the-Loop" approach works, broken down into simple steps:

1. The Setup: Reading the Manual

First, the AI reads the "manual" (the technical specifications and data files) of the black box. It acts like a librarian, pulling out a list of what goes in (inputs like temperature or pressure) and what comes out (outputs like oil temperature or valve position).

The Analogy: Think of this as the AI reading the ingredients list on a cake mix box to understand what it can do, without knowing the secret recipe inside.

2. The Brainstorming: Writing the "What If" Stories

Next, the AI is asked to imagine different test scenarios. It writes these in a simple story format called "Given-When-Then."

Given: The engine is running normally.
When: Suddenly, the ship hits a storm (a change in input).
Then: The engine should stay cool and not overheat (the expected result).
The Analogy: The AI is like a creative writer pitching plot ideas for a movie. It suggests, "What if the hero gets scared? What if it rains?" It generates many different "what if" stories to see how the system reacts.

3. The Reality Check: The Human Expert

This is the most critical part. The AI's "stories" are just ideas. A human expert (a domain specialist who knows how real engines work) reviews them.

The Analogy: Imagine the AI is a junior chef suggesting wild recipes. The Head Chef (the human) tastes the idea and says, "No, we don't put chocolate in the soup," or "Yes, that spice mix sounds perfect." The human filters out the crazy ideas and keeps the realistic ones.
Why this matters: The paper found that if you let the AI run wild without a human checking, it creates about 50% useless or wrong tests. With the human checking, the accuracy jumps to nearly 100%.

4. The Execution: Running the Simulation

Once the human approves the test ideas, the AI turns them into precise instructions (numbers, timing, and specific values). It then runs the simulation thousands of times, feeding the black box these inputs and watching the outputs.

The Analogy: The AI is now the stage manager, setting up the lights and sound exactly as the Director (the human) approved, and running the play to see if the actors (the system) perform correctly.

5. The Verdict: Did it Pass?

The system checks if the results match the "Then" part of the story. Did the temperature stay within limits? Did the valve move the right way?

The Analogy: It's like a referee blowing a whistle. If the engine overheats when it shouldn't, the test fails. If it behaves perfectly, the test passes.

The Secret Sauce: Two Different "Personalities" for the AI

The authors noticed that the AI needs to be in two different moods for this to work:

Creative Mood (High Randomness): When brainstorming ideas, they tell the AI to be wild and diverse so it doesn't get stuck thinking of the same test over and over.
Strict Mood (Low Randomness): When turning those ideas into actual numbers and running the tests, they tell the AI to be precise and boring, ensuring the math is exact.

The Results

They tested this on a Lube Oil Cooling System (a system that keeps a ship's engine oil from getting too hot).

They compared their AI-assisted tests against tests created entirely by humans.
The Finding: The AI-generated tests were just as good at finding "bugs" or potential failures as the human-made ones.
The Catch: The AI is fast and can generate many ideas, but it needs the human to filter out the nonsense. Without the human, the AI makes mistakes. With the human, it becomes a powerful tool that saves time and effort.

In short: This paper shows that you can use AI to help engineers test complex, invisible computer models, but only if you treat the AI as a helpful intern who needs a senior manager to double-check its work. You don't replace the expert; you give them a super-fast assistant.

1. Problem Statement

Modern engineering systems rely heavily on model-based design using Functional Mock-up Units (FMUs) for simulation and co-simulation. FMUs encapsulate model binaries and descriptions but hide internal equations and solver details, making traditional white-box testing infeasible. Consequently, verification must rely on black-box testing, which requires defining complex test scenarios based solely on functional specifications and interface descriptions.

Challenge: Manually defining diverse test scenarios, input time-series, and expected output behaviors (oracles) for dynamic systems is labor-intensive, error-prone, and difficult to scale.
Gap: Existing automated testing methods often require access to internal model structures (e.g., Simulink internals) or lack mechanisms to generate human-readable, domain-specific test goals for black-box FMUs.

2. Methodology

The authors propose a Human-in-the-Loop (HITL) framework that leverages Large Language Models (LLMs) to automate the generation of black-box test scenarios. The approach follows a three-level abstraction hierarchy: Intent (Goals) $\rightarrow$ Templates (Plans) $\rightarrow$ Executable Time-Series (Scenarios).

A. Workflow Overview

Input: An FMI-compliant FMU (specifically modelDescription.xml) and functional specification documents.
LLM Extraction: The LLM extracts I/O constraints (variable names, units, ranges) from the metadata.
Scenario Generation (Iterative Phases):
- Phase 1: Goal Generation: The LLM generates high-level test goals in Given-When-Then (GWT) format (Gherkin syntax). These goals describe qualitative preconditions, disturbances, and expected behavioral trends (e.g., "monotonic increase," "settles to setpoint").
- Phase 2: Plan Generation: Approved goals are converted into concrete Scenario Plans. The LLM defines specific input patterns (constant, step, ramp), magnitudes, timing, and formal assertion oracles (e.g., bounded, crosses_above, settles_to) with numerical thresholds derived from constraints.
- Phase 3: Scenario Instantiation: Plans are converted into executable time-series using Latin Hypercube Sampling (LHS) with a fixed random seed to ensure deterministic generation and deduplication.
Human-in-the-Loop: A domain expert reviews goals and plans at each stage to validate feasibility, safety, and domain logic before execution.
Execution & Evaluation: The FMU is simulated using the generated inputs. Assertions are evaluated against recorded outputs to produce pass/fail verdicts.

B. Key Technical Mechanisms

Prompt Engineering: The system uses schema-first prompting with strict JSON schemas, few-shot exemplars, and role definitions to ensure structured, machine-readable outputs.
Temperature Control: A split-temperature strategy is employed:
- High Temperature (0.7) for Goal Generation to maximize diversity and creativity.
- Low Temperature (0.2) for Plan Generation to ensure determinism and precision in numerical values.
Oracle Definition: Instead of predicting exact numerical values (which is difficult for dynamic systems), the LLM generates generic oracles describing trends (e.g., "output settles to target within tolerance $t$ ").
Deduplication: A hashing mechanism is used to detect and remove duplicate goals, plans, and scenarios across runs to optimize efficiency.

3. Key Contributions

HITL Framework for FMUs: A novel workflow integrating LLMs with domain expert review specifically for black-box testing of encapsulated simulation models.
Structured Scenario Generation: A method to translate unstructured FMU metadata into structured GWT goals and executable time-series plans using prompt engineering and schema constraints.
Mutation-Based Adequacy Evaluation: The authors introduce a custom mutation analysis method to evaluate the quality of generated scenarios. Since internal code is unavailable, they mutate the output time-series of the FMU (e.g., Mirror, Random Uniform, Crossover, Polynomial mutations) to create "mutants" and measure how many are "killed" (detected as failures) by the generated test suite.
Practical Implementation: A complete toolchain demonstrating the generation, execution, and logging of test scenarios for a Lube Oil Cooling (LOC) system.

4. Results

The approach was evaluated on a Lube Oil Cooling (LOC) system FMU.

Accuracy: Without human review, the LLM-generated scenarios had an average accuracy of 47% due to hallucinations and unrealistic constraints. With domain expert validation, accuracy rose to nearly 100%.
Fault Detection Capability:
- Mutation Score: The LLM-generated scenarios achieved a mutation score of 0.67 (killing 47 out of 70 mutants).
- Comparison: This is comparable to manually created scenarios, which achieved a score of 0.685 (killing 48 mutants).
- Conclusion: The LLM-assisted approach generates scenarios with equivalent fault-detection capability to manual testing.
Efficiency: The end-to-end generation process (constraints, goals, plans) for a batch of 8–10 scenarios took under one minute per run.
Coverage: The approach generated additional, diverse scenarios beyond what a human expert manually created, covering different behavioral variations.

5. Significance and Future Work

Significance: This work demonstrates that LLMs can effectively bridge the gap between high-level functional specifications and low-level executable test cases for black-box simulation models. It significantly reduces manual effort while maintaining high test quality through human oversight.
Limitations:
- Non-determinism: LLM outputs can vary between runs even with fixed seeds, requiring robust deduplication.
- Hallucinations: The model may still generate unrealistic parameter ranges, necessitating human review.
- Oracle Trust: The validity of qualitative oracles depends on the LLM's understanding of system dynamics; incorrect thresholds can lead to false positives/negatives.
Future Directions: Extending the approach to co-simulation (multi-FMU setups) and implementing an active learning loop where the LLM re-prompts itself based on simulation failures to refine future test cases.

In summary, the paper presents a robust, practical methodology for automating the testing of complex engineering simulations, proving that LLMs, when guided by strict prompting and human expertise, can serve as powerful assistants in the verification and validation of black-box systems.