LLM-Powered Requirements Generation and Virtual Testing for Automotive Software Development

capgemini · Automotive · year n/a · source Agentic: yes · promotional bias: high · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Automotive software requirements and virtual testing

Capgemini wanted to bring cloud-style iteration speed to automotive software development while preserving requirement consistency, testability, and regulated safety/security quality expectations.

Constraints:

• Automotive development has longer timelines than web or cloud development.
• Integration with ECUs and vehicle devices often happens late and can take months or years.
• Late misunderstandings make remediation expensive and quality suboptimal.
• Automotive development remains regulated and still requires safety and security certification.
• Developers need virtual environments before scarce hardware racks are available.

Architecture

Capgemini's Amplifier accelerator uses AWS Bedrock LLMs and engineered prompts to extract information from whiteboard photos, generate consistent requirements, test them for ambiguity, and create user stories. Those requirements feed architecture, Jira tickets, automated tests, and AWS-based virtual ECU environments so teams can test ideas earlier, scale scenarios to virtual fleets, and reserve physical hardware testing for the validation activities that still require it.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  Whiteboard["Whiteboard capture input"] --> Amplifier["Amplifier LLM pipeline"]
  Amplifier --> Requirements["Requirements and stories"]
  Requirements --> Tests["Automated test generator"]
  Requirements --> VirtualECU["Virtual ECU environment"]
  Tests --> VirtualECU
  VirtualECU --> Fleet["Cloud fleet simulator"]

Components

Data flow

An ideation session produces whiteboard sketches and notes. Amplifier ingests photos, extracts information with Bedrock-hosted LLMs, produces requirements, checks ambiguity, generates user stories and tests, and connects those artifacts to virtualized ECU environments and cloud automation for individual development and fleet-scale testing.

Why this architecture

The architecture joins LLM requirements generation with virtual ECU infrastructure because the biggest automotive pain is not only writing requirements faster; it is discovering integration problems earlier and testing them before physical racks, hardware benches, and vehicle fleets are available.

Models used: AWS Bedrock LLMs · pre-trained AI models · LoRA-modified AI models

Scale

• The demo generated over 30 requirements in about 15 minutes.
  “it takes about 15 minutes to get through this whole process with over 30 requirements”transcript, stated
• The presentation contrasts one- or two-day cloud development with much longer automotive cycles.
  “it really takes only like a day or two to get from an idea down to something deployed in the in the actual environment and Automotive development has slightly longer development times”transcript, stated
• Automotive integration can take months and sometimes years before testing against vehicle ECUs.
  “until you can really test it against uh the devices the ECU in the vehicle it takes months sometimes even years”transcript, stated
• The virtual infrastructure is described as scaling to a fleet test of a thousand vehicles.
  “now I want to test that with a fleet of a thousand Vehicles”transcript, stated
• The presenter also gives a 10,000-vehicle deployment-risk example.
  “you don't want to find out as soon as you publish that change to 10,000 vehicles on the street and your backend crashes”transcript, stated

Alternatives considered (roads not taken)

Photograph whiteboards and manually carry ideas forward

Rejected because: Ideas from workshops can fade after someone collects flip charts and photos.

Late hardware-rack integration

Rejected because: Waiting for racks and physical resources delays feedback and makes same-day iteration impossible.

Write thick architecture documents and hope for proper implementation

Rejected because: The team wanted short iterations, prototypes, product-owner feedback, and architecture evolution from working examples.

Replace all V-model and hardware testing

Rejected because: Safety, regulated development, timing tests, and safety certifications still require parts of the classical process and hardware validation.

Patterns

prompt-chaining (requirements)

Amplifier chains extraction from images, requirement creation, ambiguity testing, and user-story generation.

tool-use-orchestration (architecture)

The system connects Bedrock models, vector databases, AWS Engineering Workbench, virtual ECU Builder, code pipelines, and cloud scripts into one development flow.

rag-retrieval (knowledge-grounding)

The architecture mentions vector databases alongside Bedrock and modified AI models, implying retrieval support for generated automotive artifacts.

eval-driven-development (testing)

Generated requirements feed automated tests early in the lifecycle so teams can validate behavior before late hardware integration.

Tradeoffs

Generate requirements from ideation artifacts

Chose LLM extraction from whiteboard photos over manual workshop capture and later requirements writing.

Rationale: The accelerator turns ephemeral workshop output into structured requirements and user stories much faster.

Use virtual ECU environments

Chose AWS-based virtualization for developer testing over waiting for physical racks and vehicle devices.

Rationale: Virtualization lets developers test integrations locally and earlier instead of waiting for scarce hardware resources.

Scale fleet validation in cloud

Chose cloud automation over virtualized vehicle fleets over discovering backend scaling problems after field deployment.

Rationale: The team can test security or backend changes against virtual fleets before pushing changes to many real vehicles.

Gotchas (what bit them)

Late ECU integration makes misunderstandings expensive.

Root cause: Teams may discover requirement or integration problems only months or years into automotive development.

Resolution: Use virtual ECUs and cloud environments to test feature behavior earlier.

Generated speed cannot remove regulated validation needs.

Root cause: Automotive development still has safety, security, timing, and certification requirements.

Resolution: Use LLM and virtualization to shift integration earlier while preserving hardware tests where required.

Requirement phrasing can create consistency problems.

Root cause: Different wording can describe the same functional intent across teams and artifacts.

Resolution: Use generative text understanding to detect semantic similarity and support iterative development.

Evaluation

The presentation describes requirement ambiguity checks, generated automated tests, virtual ECU integration tests, fleet-scale cloud tests, and remaining hardware/timing/safety certification checks; it does not publish quantitative accuracy or defect-reduction metrics.

Metrics: about 15 minutes for over 30 demo requirements · fleet test example of a thousand virtual vehicles · 10,000-vehicle deployment risk scenario

Outcomes

• The demo produced over 30 requirements in about 15 minutes.
• Generated requirements feed user stories, Jira tickets, test cases, and test automation.
• Virtual ECU environments let developers test complete app behavior before physical hardware integration.
• Cloud automation supports fleet-scale virtual testing scenarios.

The transcript reports a 15-minute demo for over 30 requirements, months-to-years late integration pain, and fleet-scale testing examples at 1,000 and 10,000 vehicles.