SDV Guide
digital.auto
  • Welcome
  • SDV101
    • Part A: Essentials
      • Smart Phone? No: Habitat on Wheels!
      • Basics: What is a Software-defined Vehicle
      • MHP: Expert Opinion
      • Challenges: What sets automotive software development apart?
      • SDV Domains and Two-Speed Delivery
    • Part B: Lessons Learned
      • Learnings from the Internet Folks
        • Innovation Management
        • Cloud Native Principles
          • DevOps and Continuous Delivery
          • Loose Coupling
            • Microservices & APIs
            • Containerization
            • Building Robust and Resilient Systems
      • Learnings from the Smart Phone Folks
    • Part C: Building Blocks
      • Foundation: E/E Architecture
        • Today`s E/E Architectures
        • Evolving Trends in E/E Architectur
        • Case Study: Rivian
      • Standards for Software-Defined Vehicles and E/E Architectures
      • Building Blocks of an SDV
        • Service-Oriented Architecture
          • The SOA Framework for SDVs
          • Container Runtimes
          • Vehicle APIs
          • Example: Real-World Application of SDV Concepts
          • Ensuring Functional Safety
          • Event Chains in Vehicle SOAs
          • Vehicle SOA Tech Stack
        • Over-the-Air Updates: The Backbone of Software-Defined Vehicles
        • Vehicle App Store: The Holy Grail of Software-Defined Vehicles
      • Summary: Building Blocks for Software-Defined Vehicles
    • Part D: Implementation Strategies
      • #DigitalFirst
      • Hardware vs Software Engineering
        • The Traditional V-Model in Automotive Development
        • Agile V-Model, anybody?
        • Key: Loosely Coupled, Automated Development Pipelines
        • The SDV Software Factory
      • Implementing the Shift Left
        • Simulation and Digital Prototyping
          • Early Validation: Cloud-based SDV Prototyping
          • Detailed Validation: SDVs and Simulation
        • Towards the Virtual Vehicle
          • Case Study: Multi-Supplier Collaboration on Virtual Platform
          • Long-Term Vision
        • Physical test system
        • De-Coupled, Multi-Speed System Evolution
        • Continuous Homologation
        • Summary and Outlook
      • Enterprise Topics
        • Variant Management
        • Engineering Intelligence
        • Enterprise Organization, Processes, and Architecture
        • Incumbent OEMs vs EV Start-ups
  • SDV201
  • ./pulse
    • SDV Culture
    • Lean Sourcing
      • LeanRM
        • Why so many Requirements?
      • SCM for SDVs
    • SDV Systems Engineering
      • LeanSE
      • SDVxMBSE
    • Digital First
    • Loose Coupling
      • API-first
      • Freeze Points
    • Automation and Engineering Intelligence
    • Continuous Homologation
    • Build / Measure / Learn
  • Glossary
Powered by GitBook

SDV Guide

  • Legal Notice
  • Disclaimer
  • Privacy Policy

(c) 2025 Dirk Slama

On this page
  • Build: Pre-SOP vs Post-SOP Phases
  • Measure: The Role of Customer Journey Analysis
  • Learn: Leveraging AI for Smarter Insights and Features
  • Mapping Build / Measure / Learn to the ./pulse Framework
  • Conclusion
  1. ./pulse

Build / Measure / Learn

The Build / Measure / Learn (B/M/L) cycle in the ./pulse framework is a foundational approach to iterative development and continuous improvement. It adapts principles from agile and Lean development to the complexities of modern automotive systems, enabling rapid innovation while ensuring system reliability and regulatory compliance. By emphasizing data-driven feedback loops, the B/M/L cycle helps align vehicle development with customer needs and technological advancements across the entire lifecycle, from pre-SOP prototypes to post-SOP real-world vehicles.

Build: Pre-SOP vs Post-SOP Phases

The Build phase in the B/M/L cycle differs significantly before and after the vehicle's Start of Production (SOP):

  • Pre-SOP (Prototyping Phase): In the pre-SOP phase, prototypes and virtual models are used to experiment with new features and systems. These builds allow teams to:

    • Validate concepts and designs in controlled environments (e.g., simulations, labs, and limited physical prototypes).

    • Test integrations between mechanical, E/E, and software layers to identify early-stage issues.

    • Freeze critical elements such as hardware and embedded software APIs while maintaining flexibility in fast-moving digital systems. Prototypes provide the initial learning ground, where engineers refine features based on simulated scenarios and lab-scale testing.

  • Post-SOP (Learning from Real Vehicles): After SOP, learning shifts to real vehicles on the road, providing access to vast amounts of real-world data from diverse use cases and environments.

    • User Behavior Insights: Analyze how customers interact with various vehicle features, such as adaptive cruise control, infotainment, or energy-saving modes.

    • Problem Identification: Detect issues such as feature usage inconsistencies, safety anomalies, or performance bottlenecks based on telemetry data from connected vehicles.

    • Fleet Data Aggregation: Use aggregated data to identify trends across the fleet, supporting feature optimization and predictive maintenance.

The transition from pre-SOP to post-SOP learning ensures that every iteration—whether a software update or a new model variant—improves upon the previous one, guided by real-world insights.

Measure: The Role of Customer Journey Analysis

Understanding how customers interact with their vehicles is vital to delivering features that truly enhance user satisfaction. Customer Journey Analysis (CJA) applies best practices from the digital world to the automotive industry, enabling a deeper understanding of user behavior.

  • Mapping Customer Journeys: CJA involves mapping how customers interact with the vehicle across different touchpoints—such as entering the car, configuring driver preferences, or using connected services. This mapping helps identify friction points and opportunities for improvement.

  • Data Collection and Analysis: By leveraging APIs, vehicles can collect anonymized telemetry data on feature usage, such as:

    • How often customers use a specific mode (e.g., sport mode or eco mode).

    • Interaction frequency with voice assistants or infotainment systems.

    • Behavioral patterns, such as typical charging times for EVs or preferred navigation settings.

  • Insights for Feature Refinement: CJA insights help prioritize features based on actual customer needs, reduce redundant functionalities, and improve user interfaces to align with real-world preferences.

Learn: Leveraging AI for Smarter Insights and Features

Artificial Intelligence (AI) plays a transformative role in the Learn phase, with two primary dimensions:

  1. AI to Improve Learning:

    • Enhanced Data Analysis: AI-powered tools can analyze massive datasets from connected vehicles to uncover patterns, identify anomalies, and predict future behavior.

    • Advanced Customer Journey Analysis: AI can dynamically segment users based on their behavior, offering insights into how different demographics interact with vehicle features.

    • Predictive Insights: Machine learning models can predict maintenance needs, feature failures, or even emerging customer preferences, enabling proactive adjustments.

  2. AI Deployed on the Vehicle:

    • Onboard Learning: AI systems embedded in vehicles, such as personalized driver settings, adaptive infotainment, or autonomous driving algorithms, continuously learn from real-world scenarios.

    • OTA Updates for AI Models: Post-SOP, onboard AI models can be updated over-the-air (OTA) to improve performance, integrate new features, or address edge cases not covered during pre-SOP testing.

    • Example Use Case: An AI-powered parking assistant might learn from user feedback to optimize parking space detection in complex urban environments. Over time, these improvements are deployed fleet-wide, enhancing the feature for all users.

AI, in both dimensions, ensures that vehicles are not static products but dynamic systems that evolve based on real-world use and feedback.

Mapping Build / Measure / Learn to the ./pulse Framework

The B/M/L cycle integrates seamlessly with the other elements of the ./pulse framework to ensure iterative development and alignment across domains:

  • LeanRM: Requirements evolve dynamically based on insights from the "Learn" phase, ensuring that feature development aligns with real-world usage and customer needs.

  • LeanSE (Systems Engineering): Systems-level design considerations feed into the "Build" phase, ensuring that dependencies between mechanical, E/E, and software systems are accounted for.

  • Freeze Points: Critical design decisions made in the "Build" phase are stabilized through freeze points, ensuring downstream stability while enabling continued iteration in digital systems.

  • API-First: APIs enable seamless data collection for the "Measure" phase and ensure modularity for faster updates in the "Build" phase.

  • CI/CD/CT Automation and Engineering Intelligence: Automation accelerates the "Build" and "Measure" phases, while Engineering Intelligence provides actionable insights for the "Learn" phase.

  • Continuous Homologation (CoHo): Compliance checks integrated into the "Measure" phase ensure that iterative updates meet regulatory requirements.

Conclusion

The Build / Measure / Learn cycle in the ./pulse framework transforms automotive development into an iterative, data-driven process. By differentiating pre-SOP prototyping from post-SOP real-world learning, incorporating Customer Journey Analysis, and leveraging AI to enhance both learning and feature evolution, the B/M/L cycle ensures continuous improvement across all domains. Integrated with the other elements of the framework, it empowers OEMs to deliver software-defined vehicles that are innovative, user-focused, and compliant with evolving industry standards.

PreviousContinuous HomologationNextGlossary

Last updated 4 months ago