Concepts and solutions

Multiple OEMs now offer portals to help developers build applications using vehicle APIs. The portals can include vehicle status information such as location, charging status or errors. Some offer the ability to send data and commands to vehicles, enabling use cases such as drive experience personalization, customized patterns for locking and unlocking, anti-kinetosis, charging pattern optimization or sleep detection.   

These developer portals are key enablers for SDV ecosystem growth, providing the foundation for third-party applications that integrate seamlessly with vehicle systems. They support innovative use cases ranging from fleet management and smart home integration to personalized vehicle experiences and connected services. The portals also create opportunities for developers to build applications that use vehicle data and control capabilities while maintaining security and safety standards.

The developer experience and functionality vary significantly across OEM portals, reflecting the early stage of this technology's evolution. Some portals offer comprehensive APIs with extensive documentation and testing tools, while others provide more limited access with basic functionality. This variation suggests the industry is still defining best practices for vehicle API design and developer engagement.

The growing availability of vehicle APIs through developer portals will accelerate innovation in the automotive ecosystem by enabling a broader range of developers to contribute to vehicle functionality. This approach will also help OEMs differentiate their vehicles through unique applications and services while maintaining control over critical vehicle systems. As the automotive industry evolves, developer portals will become essential for building vibrant software ecosystems around vehicles.

The adoption of virtual ECUs (vECUs) for development continues to advance, enabling earlier integration and collaboration. OEMs are increasingly integrating multiple vECUs early in the software development lifecycle. Architectures now also interconnect supplier-owned vECU environments, allowing independent software deployment, faster iteration and earlier error detection when fixes are less costly.

However, OEMs’ expectations for vECUs must take into account that, while some cases achieve binary compatibility with hardware, the significant investment required to create exact replicas of complex ECUs often yields diminishing returns. The highest value lies in using vECUs to uncover integration issues early, analyze system behavior and run parallel simulations of vehicle instances with different software variants to accelerate validation cycles.

While vECU technology shows clear improvement and enables valuable workflows, a fully synchronized, hardware-identical virtual network — particularly concerning CPU clock speed synchronization for complex multi-vECU testing — remains a challenge. Focusing on high-value use cases, rather than exhaustive replication, offers the most pragmatic way to maximize vECU benefits.

Multi-tenant compute is a computing architecture where multiple, independent applications, services or virtual machines share the same physical hardware resources while maintaining strict isolation and security boundaries. In automotive contexts, this means running vehicle systems — such as infotainment, Advanced Driver Assistance Systems (ADAS), telematics and third-party applications — on shared computing platforms rather than dedicated hardware for each function.

The need for multi-tenant compute has emerged from the industry's shift toward new vehicle architectures. Traditional distributed ECU architectures are being replaced by zonal and central computing architectures that consolidate multiple functions onto shared platforms. This requires sophisticated resource management and isolation mechanisms to ensure safety-critical systems, infotainment applications and third-party services can coexist securely on the same hardware.

Multi-tenant operating systems like seL4 and L4Re provide the foundation for this architecture, offering formal verification of security properties and microkernel-based isolation. These systems enable OEMs to run applications from different suppliers, third-party services and internal systems on the same hardware with guaranteed security boundaries. They also provide resource management for efficient allocation of computing resources based on real-time demands.

A vehicle abstraction layer (VAL) provides a higher-level interface to access a vehicle’s functionality without having detailed knowledge about the underlying implementation, sensors and actors. 

Unlike the traditional approach of pre-planned, signal-based communication between components, a VAL abstracts a vehicle’s capabilities, separating hardware-bound software from features software. This allows more flexibility for additional features provided by application updates, supports the porting of features to different vehicle models, and is essential for external solution providers such as ADAS and AD, infotainment systems or connected mobility services.

Many OEMs include the VAL concept in their internal architecture, but there are also more public examples that include this concept, such as Android Automotive, Veecle.io and the Vehicle Information Service Specification (VISS).

While there are clear benefits to a VAL concept, it also comes with challenges, including difficulty supporting different service requirements. Some applications using the VAL need a response or execution done in real time, while others don’t, and implementing this mixed criticality is complex. 

Another challenge we observe in VAL design is ‘leaky’ abstractions, where API layers are implicitly coupled to hardware. This results in brittle architectures, sometimes with multiple layers of APIs, so even simple feature additions require widespread ‘shotgun surgery’ instead of isolated changes.