Video summary

Can AI Replace Your ASPICE Processes?

Main summary

Key takeaways

Business

Business-focused summary (AI vs. ASPICE across the V-model)

1) Webinar purpose and context

  • Topic: Whether AI can replace or significantly automate ASPICE processes across the V-model (requirements → architecture/detail design → code/test → verification).
  • Framing: AI can help with drafting, checks, summaries, and tooling acceleration, but humans remain responsible for correctness, ASPICE compliance, and final decisions.
  • Early caution: Even “AI-generated” content can fail on basics (e.g., an AI text generator forgetting to replace placeholders like a surname), reinforcing the need for human verification.

2) AI use cases along the V-model (what can be automated vs. what can’t)

Requirements generation and support

AI can assist with generating requirements at multiple levels:

  • System requirements from stakeholder expectations
  • Software requirements from system requirements
  • Hardware requirements from system requirements

It can also help by:

  • Configuring AI with organization-specific templates/patterns to improve:
    • Traceability (mapping generated items back to sources)
    • Verifiability (using structured requirement formats)
    • Reducing “generic” outputs

Key process insight (risk):

  • AI needs rich inputs; otherwise it may hallucinate or violate safety/regulatory constraints.
  • Inconsistent or unverifiable requirements can lead to downgrades at base practice level (not necessarily “ASPICE broken,” but audit/review issues are more likely).

Concrete input checklist AI reportedly demanded (for automotive-valid requirements):

  • System architecture overview (boundaries, major components, interfaces)
  • Use cases / user scenarios (e.g., driver/vehicle actions)
  • Environmental and functional constraints (regs/standards)
  • Performance/KPIs at system level:
    • Latency
    • Reliability
    • Availability
    • Accuracy
  • ASIL level inputs
  • OEM-specific glossary/terminology
  • Templates and requirements patterns
  • Assumptions/constraints/known legacy constraints
  • Traceability info from level to level

Requirements consistency and traceability checks

AI can help verify:

  • Coverage: software requirements cover all system requirements
  • Internal consistency: detect contradictions within one document
  • “Smell detection”: flag likely issues for human review
  • Coverage dashboards: identify gaps visually

Positioning: Speakers emphasize AI can’t (today) “one-button” produce fully valid, consistent requirements without structured input and human validation.

Architecture support

AI can assist with:

  • Suggesting architectural elements and interfaces from requirements (advisor/suggestion use)
  • Proposing component decompositions using patterns/blueprints
  • Checking weak points, such as:
    • Cybersecurity vulnerabilities
    • Interface bottlenecks
  • Validating against known/proven patterns (e.g., Visitor/Factory patterns)

Limits:

  • The speaker notes they are not overly optimistic about AI fully generating architecture end-to-end.

High-value early-stage capability:

  • Text-to-diagrams generating:
    • architecture diagrams
    • sequence diagrams
    • block diagrams
    • data flow diagrams
    • state diagrams (again, as suggestions to iterate with humans)

Detail design and reverse engineering

AI can help in rare scenarios:

  • With existing source code, AI can perform reverse engineering to produce more detailed design

ASPICE relationship nuance:

  • ASPICE requires both design artifacts and code consistency; it does not enforce a strict order that makes reverse engineering impossible—consistency is what matters.

Source code generation (most skepticism)

AI-generated code was discussed as:

  • A “favorite” use case for some, but speakers are skeptical about practical replacement.

Reported failure modes:

  • Code “glitches” after prompt iterations
  • AI removes required functionality
  • Refactoring leads to missing helpers or deleted components
  • Context/buffer limits cause broken output

Mitigations mentioned:

  • AI guided by coding guidelines (e.g., MISRA expectations were explicitly mentioned)
  • Integration with traceability requirements

Even then: speakers note general-purpose models “start glitching quite fast” without specialized setup.

Source code checking and verification support (more promising)

AI is more practical today for:

  • Static code check alignment to coding guidelines
  • Traceability checks, including:
    • Detail design ↔ source code consistency
    • Software requirements ↔ source code/unit allocation
  • Test generation support, such as:
    • Generating test cases from software requirements
    • Assisting with test automation
  • Log analysis, including:
    • Summarizing large test execution logs
    • Detecting inconsistencies
    • Reporting coverage issues

Concrete experience re: automated test generation:

  • Evaluated a tool generating “manual/discrete test steps” from requirements:
    • Without tuning/context: 2,500 test cases from ~45 arbitrary requirements
    • After tuning: ~150 meaningful test cases (more reasonable scale)
  • Conclusion: automation is feasible but requires heavy tuning for project context.

Unit test generation experiment outcomes:

  • One internal approach claimed ~30% KPI improvement via AI-generated unit tests (faster development), but humans must still review correctness.
  • Speakers’ estimate: for smaller projects, the setup/training/context teaching costs may outweigh benefits.

3) Non-engineering processes (management/operations) where AI is already operational

  • Change/problem/change-tracking support

    • AI can identify dependencies and duplicates and generate trend reports for:
      • Sub-9 problem resolution management
      • Sub-10 change request management

  • Managerial productivity tools (examples described as already built/used)

    • Automated backlog generation tool (Jira integration):
      • Takes system requirements
      • Breaks into user stories and tasks
      • Uses naming conventions and story/task templates
      • Can create items in Jira
    • Effort estimation / capacity prediction (theoretical / not fully tried):
      • Uses historical Jira task data to suggest milestones
    • Automatic project status summaries:
      • Aggregates from Jira/Confluence/commits/test reports
      • Produces structured status reports (currently via scripts; future AI enhancement expected)
    • Problem resolution automation:
      • Duplicate defect detection by linking similar/duplicate tickets to speed triage
    • Process documentation generation (e.g., CMP—Configuration Management Plan):
      • Drafts documentation using corporate templates and provided context
      • A “next webinar” was mentioned to review compliance

4) Adoption data from an internal DXC-style survey (operational insight)

Survey summary (≈ 240 responses):

  • Geography: Ukraine, Germany, Bulgaria, Egypt, Poland, Italy, others
  • Automotive experience:
    • 67% have >8 years automotive experience
  • Daily AI usage:
    • Project managers: 22%
    • Scrum masters: 20%
    • Developers: 28%
    • Test engineers: 17%
  • A few times per week:
    • Project managers: 26%
    • Scrum masters: 37%
    • Developers: 25%
    • Test engineers: 29%
  • Overall:
    • Approximately 50–60% use AI regularly
    • 40% never or rarely

Top AI use cases in automotive projects (from survey):

  • Managers/scrum masters:
    • drafting/editing text (docs/emails)
    • information search/research (e.g., Copilot/ChatGPT)
    • summarizing/organizing info
    • data analysis/visualization
  • Developers/test engineers:
    • research/info search
    • code suggestions/completion
    • summarizing/organizing info
    • test generation/automation

Notable discussion point: “Nobody use it for architecture for requirements” (likely due to contractual/data constraints).

5) Practical governance: NDAs, GDPR, and “trusted models”

Direct guidance:

  • Do not paste customer/project requirements into public ChatGPT (explicit NDA violation risk).
  • Prefer:
    • Local AI on company-controlled infrastructure, or
    • a cloud setup where the company has control and governance

Hardware/performance tradeoff:

  • Local “high context” models can be slow and may require high-spec compute (example claim: ~€50–60k for a single machine running a large model efficiently; speaker considered it impractical if savings are small).

Vendor model trust:

  • Prefer trusted suppliers (e.g., Google/Microsoft mentioned).
  • Speakers advised against untrusted “China-based” model providers where leakage guarantees are unclear.

Additional recommendation:

  • Consult your organization’s AI governance project team
  • Experiment in sandbox / disconnected environment if unsure

Frameworks / processes / playbooks explicitly referenced

  • ASPICE V-model (core framing)
  • Traceability & consistency (recurring assessment theme)
  • ASIL levels (automotive safety context)
  • Coverage dashboards (traceability/coverage reporting concept)
  • MISRA guidelines (coding guidance when attempting code generation)
  • Sub-9 problem resolution management and Sub-10 change request management (change management mapping)

(No explicit OKRs/SWOT/Lean Startup mentioned in this excerpt.)

Key takeaways (business/operations oriented)

  • AI is best used as an assistant for:
    • requirements checks (consistency/coverage)
    • architecture drafting/suggestion (especially diagrams)
    • code verification checks and test-case support
    • management productivity (backlogs, status summaries, duplicate defects)
  • Replacing full ASPICE work (especially requirements → architecture → detail design → unit/code with end-to-end correctness) is not realistic with current tooling, per the speakers’ view.
  • Biggest practical barriers:
    • context completeness (missing inputs → hallucinations)
    • traceability requirements across artifacts
    • code/test correctness and prompt/context brittleness
    • legal/compliance constraints (NDA/GDPR, data handling)

Presenters / sources mentioned

  • Olga (DXC / automotive professional; certified Scrum Master & configuration manager; contributed to ASPICE assessments; mentioned role achieving ASPICE level 2)
  • Oena Liza (automotive software professional; engineering/leadership/product/project management background)
  • Ronald “Ron” Melster (principal ASPICE assessor; VDA 6.3 auditor; author of three ASPICE books; previously led a development division to SPICE capability level 3)

Referenced organizations/companies: Borch, Carmarmac, Nepansaki, Audi, Porsche (as part of Ron’s experience), plus mention of startups/tools and model providers (e.g., Gemini, Copilot, ChatGPT).

Original video