Source-linked AI summary
AI-Based End-to-End Automotive Design and Software Development for SDVs
Nenad Petrovic, Alois Knoll
TL;DR
Manual metamodel development and regulation-based scenario derivation are effortful, and regulatory requirements are distributed across complex documents. The paper combines LLMs with MDE and task-specific methods to generate and validate automotive artifacts; its reported approach accelerates activities by at least one order of magnitude over traditional processes.
Problem
Method
Results
At least one order of magnitude faster than traditional development processes; locally deployed LLMs achieved around 80% usable results, while commercial models such as GPT achieved around 90% or higher.
Source: §10 · p. 14Takeaways & Limitations
Regulation-faithful scenarios with explicit provenance can serve as inputs to downstream simulation scenario generation.
Source: §5 · p. 6Complex spatial-temporal reasoning and trajectory synchronization remain major challenges for LLM-based simulation scenario generation.
Source: §6 · p. 8
Abstract
from arXiv · showhide
This paper explores the potential of Artificial Intelligence (AI) to enable end-to-end automotive design and software development for Software-Defined Vehicles (SDVs). Based on our contributions within the Central Car Server (CeCaS) and follow-up EU-funded projects, we present an AI-driven toolchain integrating Large Language Models (LLMs) with Model-Driven Engineering (MDE) to automate the transformation of natural-language requirements into system architectures, executable software, and validation artifacts. The approach emphasizes traceability, consistency, and compliance with safety-critical automotive development requirements. Validation is performed on a centralized vehicle computing platform supporting adaptive cruise control and emergency braking, tested in Hardware-in-the-Loop (HiL) and Software-in-the-Loop (SiL) environments. We discuss current capabilities, practical limitations, and future directions toward increasingly automated, reliable, and quality-assured automotive software development with minimal human intervention.
1. Introduction
The toolchain uses MDE-based intermediate artifacts as verification checkpoints in a path from natural-language requirements toward automotive design and code. For implicit architecture extraction, LLMs and VLMs derive configuration and behavior models from engineering artifacts, which can be inspected, refined, and validated.
1. Introduction
- MDE-based intermediate artifacts serve as verification checkpoints in a toolchain aimed at a highly automated, verifiable, regulation-compliant design-to-code process.The paper presents this as an opportunity and an area with remaining challenges.Source: §1 · p. 2
2. Implicit Architecture Extraction
- Metamodels define domain concepts, attributes, and relationships, but manually developing and adapting them requires substantial effort as SDV architectures grow more complex.The proposed GenAI-assisted approach aims to reduce this effort.Source: §2 · p. 2
- LLMs and VLMs process textual specifications and engineering diagrams into configuration models, then derive behavior models that can be refined through user feedback.The behavior models describe activities, event sequences, interactions, and dependencies.Source: §2 · p. 2
- PlantUML provides an inspectable intermediate representation for generated models, which support later model-to-model transformations and automated design validation.For local models that struggle to produce syntactically correct Ecore, a deterministic PlantUML-to-Ecore transformation can ensure formal correctness.Source: §2 · pp. 2–3
3. Model Instance Generation
The instance-generation workflow separates semantic generation from model-file construction: an LLM produces an intermediate representation, and a compiler creates conformant XMI. This raises validity substantially compared with direct raw-XMI generation.
3. Model Instance Generation
- The workflow addresses the labor of manually building instance models and formal constraints by separating intermediate-model generation from deterministic model construction.The paper also describes a complementary workflow in which a fine-tuned LLM synthesizes OCL constraints from natural-language specifications.Source: §3 · p. 3
- A few-shot-prompted LLM generates a flat JSON Conceptual Instance Model (CIM), which a PyEcore-based compiler converts into a conformant XMI instance model.The compiler reports mismatched or undefined elements for expert review.Source: §3 · p. 3
- 100% validity for every tested LLM was achieved through CIM and compiler routing, versus 0–20% valid raw-XMI cases even after manual repair.GPT-4o additionally reached about 99% grammatical accuracy and 93% semantic accuracy on generated elements.Source: §3 · pp. 3–4
4. Model Checking
The OCL workflow targets formal requirements that a metamodel alone cannot capture, using a locally deployable fine-tuned LLM and retrieval of relevant metamodel fragments.
4. Model Checking
- OCL constraints express requirements that a metamodel alone cannot capture, such as requiring each software node to have at least one input and output.Manually building these constraints requires modeling-technology expertise.Source: §4 · p. 4
- The workflow fine-tunes a locally deployable Llama 3 8B model with LoRA on 52 metamodels and 369 natural-language-to-OCL pairs.The dataset was collected from open-source EMF projects and cross-checked with Eclipse OCL.Source: §4 · p. 4
- At inference, retrieval selects metamodel fragments relevant to the requirement before the fine-tuned LLM generates OCL constraints.The workflow addresses confidentiality concerns associated with commercial LLMs in safety-critical industrial use.Source: §4 · p. 4
5. RAG-Based Regulation-Compliant Test Scenario Generation
RegulaRAG assembles regulation evidence with clause and cross-reference structure before generating traceable test scenarios. On the evaluated UN Regulation No. 152 dataset, it outperformed the next-best RAG system while using substantially fewer tokens than graph-centric baselines.
5. RAG-Based Regulation-Compliant Test Scenario Generation
- Manual derivation of regulation-compliant scenarios is time-consuming and error-prone because requirements and test parameters are dispersed across hierarchical clauses, annexes, tables, and cross-references.Long-context processing is costly and can suffer from the “lost in the middle” effect; isolated-chunk RAG can miss linked definitions, conditions, and tolerances [8].Source: §5 · pp. 4–5
- Prior compliance systems produce verdicts or assessment text, while driving-scenario methods target diversity and criticality rather than completeness and traceability to a specific standard.Structure-aware retrieval approaches also do not model normative cross-references between provisions,.Source: §5 · p. 5
- RegulaRAG achieved the highest average score among six RAG systems, outperforming the next-best by 43% while using an order of magnitude fewer tokens per query than graph-centric baselines.It remained robust when distractor regulations were added to the corpus.Source: §5 · p. 5
- RegulaRAG preserves clause hierarchy, reconstructs fragmented tables, and models explicit cross-references as a graph before assembling linked evidence for scenario generation.The LLM generates preconditions, test parameters with tolerances, and expected post-conditions from evidence so each value is attributable to its governing clause or table.Source: §5 · p. 5
- RegulaRAG has expanded beyond a single-regulation case study to normative, contractual, and financial documents, with refined retrieval, table handling, and evidence-based abstention.Its regulation-faithful scenarios with explicit provenance feed the downstream simulation scenario generation process.Source: §5 · p. 6
6. Simulation Scenario Generation
The section describes an LLM-based pipeline that turns natural-language requirements into executable CARLA scenarios and evaluates generation across vehicle definitions, simulation preconditions, and postconditions. Results show reliable direct mapping and validation, while complex trajectory synchronization remains difficult.
6. Simulation Scenario Generation
- The approach combines GPT-4o with JSON schemas, CARLA blueprints, and Python scripts to automate scenario configuration and evaluation from freeform requirements.The requirements were collected in a “living document” with project partners.Source: §6 · p. 7
- The pipeline maps vehicle and sensor requirements to JSON, generates simulation preconditions, and translates expected outcomes into telemetry-based validation rules.Complex spatial-temporal constraints use generated Python for coordinate offsets, road-graph queries, trajectory synchronization, and converting TTC into physical distance.Source: §6 · p. 7
- CoT reached 0.99 Avg TPR and 0.80 Pass@1 for Vehicle Definition; postconditions reached 1.0 Avg TPR and 1.0 Pass@1.Postcondition generation was the most reliable stage.Source: §6 · p. 8
- For car-to-car pre-conditions, CoT raised Avg TPR from 0.78 to 0.95 and achieved 1.0 Pass@5, while pedestrian scenarios had 0.0 Pass@1, Pass@5, and Pass@10.Python code-generation success for car-to-pedestrian scenarios reached 0.70.Source: §6 · p. 8
- The results indicate that direct requirement-to-configuration mapping and simulation-result validation are reliably automated, but spatial-temporal reasoning and trajectory synchronization remain major challenges.Structured schemas, CARLA-specific information, external tools, and generated Python form the practical hybrid approach described.Source: §6 · p. 8
7. Code Generation
The code-generation workflow turns requirements and design decisions into an event-chain description that supports both formal model validation and software generation. In an AEB case study, generated components and model-generated integration code were deployed in ROS2 with CARLA to trigger emergency braking.
7. Code Generation
- A general-purpose LLM converts requirements, specifications, and design decisions into one JSON event-chain description, which branches into formal-model and functional-code generation paths.The model path reuses the CIM/compiler method and supports early OCL validation; the code path generates components not already available in the software base.Source: §7 · p. 8
- A code-specific LLM generates middleware-independent Python classes, while Acceleo deterministically generates middleware-specific integration code from the validated instance model.The integration code can create one ROS2 node per component, including signal subscriptions, publishers, and calls to the generated class.Source: §7 · p. 9
- The EMF event-chain metamodel links software nodes and data, recording execution frequency, neighboring nodes, and middleware wiring details such as topic, message type, field, and QoS.These elements underpin both model-based validation and code generation.Source: §7 · p. 9
- In the AEB case study, LLM-generated TTC_Calculation and BrakingDecision components, combined with model-generated integration code, triggered emergency braking before a stationary obstacle in ROS2 and CARLA.The instance chain includes ObjectDetection, TTC_Calculation, BrakingDecision, and VehicleControl, connected by data such as range, speed, TTC, braking force, and brake command.Source: §7 · p. 9, Figure 7 · p. 9
8. Functional Safety Analysis
The functional-safety workflow transforms requirements, code, and behavioral diagrams into structured models checked against formal safety rules. Across three representative ADAS scenarios, LLM reasoning combined with deterministic MDE validation detected and corrected behavioral inconsistencies, with GPT-5 achieving up to 100% successful validation and correction.
8. Functional Safety Analysis
- The workflow transforms textual requirements, source code, and behavioral diagrams into structured models, using GenAI for extraction and correction and deterministic MDE validation for traceable outcomes.It targets early-stage functional safety analysis and aims to reduce risks from hallucinated LLM outputs.Source: §8 · p. 10, Figure 8 · p. 11
- PlantUML activity diagrams are transformed into JSON event-chain models and checked against LLM-generated rules for event ordering, time budgets, and role responsibilities.The “before” relation can express event ordering or a maximum execution time; numerical time budgets are in milliseconds.Source: §8 · p. 10
- Three ADAS scenarios cover incorrect event ordering, missing sensing dependencies, and inappropriate actuator activation; detected violations and relevant information are returned to the LLM for correction and revalidation.Validated implementations can subsequently be evaluated in SDV simulation environments such as CARLA or digital.auto.Source: §8 · p. 11
- GPT-5 achieved up to 100% successful validation and correction; locally deployable models achieved 80–90% correct outcomes across 10 runs without fine-tuning.Gemma-4 also provided shorter inference times.Source: §8 · p. 11
8. RAG-Based Signal Mapping and Hallucination Reduction
The signal-mapping approach uses retrieval-augmented generation to narrow large VSS and CAN-FD catalogs before LLM mapping. Evaluation reports high mapping accuracy and limited unsupported signal generation, while performance varies with signal-space size and mapping complexity.
8. RAG-Based Signal Mapping and Hallucination Reduction
- A two-stage retrieval process uses all-MiniLM-L6-v2 embeddings to find semantically similar candidates, then ms-marco-MiniLM-L-6-v2 to rerank them before LLM signal mapping.The compact set of trusted signals is used to map relevant events to VSS or CAN-FD signals.Source: §8 · pp. 11–12
- GPT-5 achieved 100% accuracy for VSS mapping with 20 signals and approximately 90% with 50; for CAN-FD mapping it achieved 90% with 20 and 80% with 50.Qwen3.5 reached around 90% accuracy for VSS mapping and showed a larger decrease for the more complex 50-signal CAN-FD case.Source: §8 · p. 12
- RAG grounding combined with formal validation limits unsupported signal generation while maintaining high mapping accuracy.The approach retrieves signals relevant to the analyzed vehicle behavior or safety scenario rather than providing thousands of catalog entries to the LLM.Source: §8 · pp. 11–12
- Validated signal mappings can bind abstract safety events and test steps to concrete vehicle signals for template-based test generation.The reported workflow also supports on-premise processing of confidential vehicle architectures and software assets with locally deployable open-weight models.Source: §8 · p. 12
9. Automated Approach to Model Interoperability
The approach uses LLMs to transform models and merge metamodels across heterogeneous tools while preserving formal conformance. Its workflow combines semantic generation with automated validation and iterative refinement.
9. Automated Approach to Model Interoperability
- The workflow supports both model-instance transformation and metamodel merging, addressing interoperability across heterogeneous modeling languages and tools while maintaining consistency, semantics, and traceability.Source: §9 · pp. 12–13
- 100% semantic accuracy was achieved across the considered model-mapping and metamodel-merging scenarios.Source: §9 · p. 13
- Ecore/XMI targets reached 100% syntactic correctness, while SysML v2 correctness ranged from 40% to 80% by model and scenario.Source: §9 · p. 13
- A Python orchestrator routes artifacts into structured prompts for a locally deployed LLM, then validates generated transformations and iteratively feeds errors or warnings back for refinement.Validation checks syntax, containment, references, multiplicities, and type consistency; metamodel merging follows the same principle.Source: §9 · p. 13
- Gemma averaged 5.1 s per workflow, compared with 46.5 s for Qwen.Source: §9 · p. 13
9. Experiment Execution Environment
An n8n-based workflow integrates locally deployable AI models with formal MDE frameworks and executes generated models in CARLA. Validated scenarios can then move to a ZoneECU-based physical testbench.
9. Experiment Execution Environment
- The n8n orchestration integrates locally deployable LLMs/VLMs with EMF, Ecore, and OCL in a multiagent system.Source: §9 · p. 13, Figure 11 · p. 14
- Inference runs through an OpenAI API-compatible local server equipped with three NVIDIA H200 NVL GPUs, each with 141 GB.Source: §9 · p. 13
- Generated configurations and behavior models are evaluated in CARLA, and validated scenarios can transfer to a ZoneECU-based Volkswagen ID. Buzz testbench.Deployment and communication use CARIAD middleware with CommAPI and the FLAME protocol.Source: §9 · pp. 13–14
10. Conclusion
The evaluated GenAI-enabled approach accelerates automotive software engineering and improves the reliability and verifiability of generated artifacts. Local models provide a viable basis for privacy-sensitive development, while commercial models currently show higher overall reliability.
10. Conclusion
- At least one order of magnitude acceleration over traditional development was reported, with requirements checking taking seconds and artifact generation minutes rather than hours or days.Source: §10 · p. 14
- Combining GenAI with MDE, task decomposition, RAG, fine-tuning, and task-specific strategies significantly improves generated-artifact reliability and verifiability.Source: §10 · p. 14
- Local LLMs achieved around 80% usable results across evaluated use cases, while commercial models such as GPT achieved around 90% or higher.The paper describes local models as a viable basis for privacy-sensitive automotive development and commercial models as currently more reliable overall.Source: §10 · p. 14