Shifting Gears - Will the VW-Rivian Joint Venture Accelerate Realization of Memorable Mobile Experiences?

"If you want to be incrementally better: Be competitive. If you want to be exponentially better: Be cooperative". - Anonymous

Last week, Volkswagen Group and Rivian announced the establishment a Joint Venture with Rivian motors in the development of E/E architecture for EVs including immediate access to Rivian's current technology. Specifics are to be defined contingent on a series of factors including the completion of the results of integration into VW? vehicles, according to the VW Group press release.?

Subsequently, mass and general media have expressed a wide variety of reactions, both positive and negative. But most views miss the point, in my option - what's important is the benefit to the consumer, to the industry, not just the motivation or implications of VW Group and Rivian.

No legacy automaker has yet to launch a multi-brand, multi-model software defined vehicle (SDV). Perhaps in 2025 that will change, but regardless Tesla has been shipping SDVs since 2012 with the model S, (though we can argue what features constitute a "true SDV").?? Why this is the case is not as important as what this may mean to the automotive industry going forward and perhaps it's indictive of a turning point.? The legacy auto industry had been caught up in the "how" of creating the SDV in transformation and SW skills capability development, without agile and iterative evidence to demonstrate the benefit, the purpose; so called "Big Bang" approaches that invest billions in long timelines and lack short iterative cycles to test customer reactions and build capabilities incrementally. As a well-respected CTO stated to me "we spend too much money and too much time on things that don't matter to the customer".? We must instead focus on the intended outcomes and impact that SDVs are intended to enable.??

Each OEM has been investing billions of dollars/euros/yuan in what may be 80% common and 20% differentiated (my own estimate). Further, though OEM "participation" is high, current SDVs are not significantly standardized under standards bodies like Eclipse SDV, COVESA and SOAFEE, though platforms like Android Automotive (AAOS or AOSP) for infotainment are increasingly becoming de-facto standards due to popularity.? While partnerships between OEMs are lacking, there are numerus partnerships between tech companies and OEMs such as AWS, Google, Apple, Apex.ai, etc as well as semiconductor companies such as Qualcomm, Nvidia, NXP, Samsung, Intel, etc.

So why aren't we seeing MORE OEM collaborations in share investments and more standards so that the industry can increase efficiency and focus it's differential investments instead on what benefits consumers, industry and society? Why aren't we seeing more collaboration to commoditize the foundational E/E architecture and operating system of the SDV?

But rather than focus on that question, I'd like to turn attention to the current end customer challenges and opportunities and my wish for the industry. Perhaps this JV is indicative of a first step in that direction:? that of reducing costs in what is not customer facing so that we can instead more efficiently and creatively produce "meaningful and memorable mobility" experiences that are of direct benefit to consumers and society.

The following are a subset of the obstacles to rapid growth and innovation in mobility experiences that I'm hopeful, OEMs and their partners will collectively address across the ecosystem.

Problem 1:? In-vehicle applications are of low value today. Today, many infotainment applications are just cockpit versions of their smartphone equivalent, at best.? At Google IO in May, Google unveiled new entertainment apps on GAS (Google Automotive Services) Max, Peacock and Angry Birds.? Angry Birds was originally released in 2009 and it doesn't really leverage vehicle resources in a powerful way. Is this the best we can do? SDVs offer "dog mode" and "sentry mode" which are richer, but in 5 years we will look back at these as being analogous to the early "snake" smartphone game.

Problem 2: Personal devices & Vehicles are not interoperable.? Other than the primary connected smartphone in a vehicle, devices don't interact with the vehicle in function or share data or experiences.? According to JD Power, more than 50%? Apple users and 40% of Android phone users wirelessly connect to their infotainment systems.? Yet, even in 2024,? wireless connectivity remains one of the top 10 problems!? At the 2024 Google IO, Google Cast for AAOS (Android Automotive OS) was announced, ironically first with Rivian, that will let users cast video content from their phone or tablet to their car while parked.? This is a step in the right direction to improve device-to-car interaction, but there is a long way to go to achieve multi-device interaction that could realize amazing experiences.

Problem 3: Rich features or ease of use, not both.? Increasingly vehicle users are inundated with increased features, changes in the user interaction model (knobs vs. touch, levels and organization of menus, speech recognition vs. gesture etc).? According to AAA, "Drivers using in-vehicle technologies such as voice-based and touch screen features were visually and mentally distracted for more than 40 seconds when completing tasks like programming navigation or sending a text message".? And the number of features and applications will only increase.? So it's important to simplify and standardize the interaction model, and AI offers the opportunity to be a simplification layer and intuitive interaction model to address this, but the solution must go beyond gimmicky "AI assistants" and focus on real user satisfaction.

Problem 4: There is no open app store ecosystem.? OEMs, Apple, Google are all battling for the ownership of the automotive app store. Is this is in the best interest of the consumer?? Will it accelerate innovation?? And if you're an app developer, you're subjected to the harsh constraints of OEMs and tech giants.? The cycle time and effort to get even a simple app through the process for Google GAS or Apple Carplay is painful.? And further, apps tend to be elemental, meaning that they don't combine to create rich 360 degree experiences. Of course it's imperative to ensure safety and security , so certification is imperative, but with test automation and AI, much of this can be automated and the focus should be to enable the app development community.

Problem 5:? Silos: Domains and developer experience.? There is no unified cross-domain app developer experience.? So I can (painfully) create a GAS or Carplay infotainment applications. Separately I can create an ADAS application using a platform like Apex.ai or OpenPilot, or a telematics application using something like Dimo. Each has their own separate development approach and what if I want to create a unified experience?? For example, I want to use ADAS cameras in my infotainment application, or body control functions with infotainment to create immersive haptics and lighting synchronized to the media??? True cross-domain SDV architectures can support these capabilities, but an open and developer friendly platform and experiences from car-to-cloud, cloud-native is essential to open the doors to these experiences.

Problem 6: Is SDV Open Source really open? As mentioned earlier, SDV standards seem not to have not been a priority for SDV for many startups or legacy OEMs.? GM donated uProtocol and other assets to Eclipse SDV, and Microsoft has made a number of donations to Eclipse SDV.? From CoVESA many utilize the VSS (Vehicle Signal Standard) as a schema to reference vehicle signals and data.? SOAFEE holds promise with its blueprints, but is any SDV architecture truly, beyond AAOS APIs, embracing standard APIs and services bumper-to-bumper and from car-to-cloud to accelerate the development, validation and DevOps of sophisticated use cases that go beyond "Angry Birds"?

Call to Action:? SDV as an Abstraction and Development Environment for the Developer Community

The SDV architecture can and should abstract away the underlying hardware (via VHAL and HAL abstraction layers), and also separate the application layer from the underlying SDV stack to facilitate an industry of innovation of mobility experiences.? But doing so differently with each OEM stack will only slow the innovation of mobility experiences.

When I had the pleasure of working on Qualcomm's first smartphone program, Phoenix in 2003, we did not envision the broad range of applications that would ultimately emerge, including Uber, Facebook, Snap, and AR apps like Lego Studio or MeasureKit, etc, etc, etc.? The same will happen with automotive mobility apps metaphorically as the "smartphone on wheels" when we realize that the SDV must be opened up to the creative mind of developers with open interfaces, open app stores and the ability to combine resources between the SDV, the smartphone, the smartcity and the smarthome.? But not when all of these are closed.

So if the VW-Rivian JV can accelerate the systems that don't directly improve the customer experience, then that a big efficiency gain.? Let's also use this as an opportunity to tackle the problems cited above, which are obstacles to innovation of mobility apps to? create memorable and monetizable experiences for consumer and societal benefit.? And to create the snowball / network effect that will ensure.? Unleashing the imagination of developers on the mobility space will yield unimaginable applications and innovations.

Imagine cars that can be summoned by seniors to safely take them to and from their medical appointments.? Imagine convoys of vehicles that can pool together to take fans to and from sporting events and concerts efficiently without congestion, imagine "offices on wheels" where colleagues commute together getting work done while they travel to visit a customer.? Imagine….

Note: This article expresses the opinion of the author and does not explicitly represent that of any employer or client. No confidential information is shared in the content of this article.