By 
As vehicles become increasingly software-defined, the next generation of automotive interfaces may extend far beyond traditional dashboards and head-up displays. High-resolution headlights capable of projecting navigation guidance, safety warnings and contextual information directly onto the road could transform how vehicles communicate with drivers, pedestrians and their surroundings.
In an exclusive interview with Car App News, Florian Gruss from e.solutions GmbH explores how digital projection lighting could evolve into a new automotive human-machine interface (HMI), complementing traditional screens and augmented reality head-up displays. He also discusses the role of real-time vehicle data, cloud connectivity, cybersecurity and the potential emergence of third-party applications within exterior projection systems.
Interview with Florian Gruss – e.solutions GmbH
Your high-resolution headlight technology effectively turns the road into a display, projecting guidance, warnings and other information directly into the driver’s environment. How do you see digital projection lighting evolving from a lighting feature into a new automotive interface?
Projection lighting is moving from a passive safety feature to an active contextual communication layer between vehicle, driver and surroundings toward becoming a certified, software-defined HMI channel sitting alongside (not replacing) screens and HUDs, governed as much by safety engineering as by design.
AR in vehicles has traditionally been associated with head-up displays and screens. What new use cases become possible when augmented reality can also be projected directly onto the road and surrounding environment through the vehicle’s lighting system?
HUD-based AR (what eso has proven in series production) is fundamentally a driver-private, windshield-bound interface. Road/environment projection via headlights extends AR into a shared, public, spatially-literal interface. The new use cases it unlocks are less about replacing HUD features and more about:
-
Externalizing AR to pedestrians/other road users (trust, safety signaling)
-
Removing the eyebox/windshield dependency, making AR visible from any viewing angle
-
Collapsing the symbolic-to-literal gap — guidance appears exactly where it applies, not as a perspective-corrected icon
-
Extending AR’s spatial footprint beyond the windshield’s limited field of view
The most forward-looking automotive HMI strategies (per current industry direction, consistent with eso positioning both products as parallel embedded software stacks) treat HUD-AR and projection-AR not as competing systems, but as complementary layers of one coherent AR architecture — HUD for the driver’s immediate cognitive field, projected light for the physical world everyone else occupies.
Digital projection becomes much more powerful when it can react to real-time information. How can vehicle sensors, navigation and live cloud services work together to dynamically determine what should be projected, where and when?
Onboard multi sensor fusion (camera/radar/lidar) combined with ego-motion and motion-prediction provides the fast, low-latency layer that detects hazards and keeps projected content precisely locked to real-world positions as the vehicle moves. Navigation and HD-map data add route context, pre-staging guidance content (turn arrows, lane markers) at the right time and distance before a maneuver, while live cloud/V2X services extend awareness beyond the vehicle’s own sensor range by supplying early warnings on hazards, traffic and weather.
Together these layers form a priority cascade while onboard perception always overrides for immediate safety content, navigation determines timing and cloud data enriches and adjusts what, where and when something is projected.
Once cloud data can influence information projected into the driver’s physical environment, cybersecurity becomes critical. How do you ensure that a projected warning, navigation instruction or AR element is authentic and cannot be manipulated or injected by an unauthorized source?
Authenticity of projected content is ensured by layering: signed origin data (keys never exposed, per Locksmith’s zero-leakage model), encrypted/integrity-checked transport (AEAD, TLS with TrustZone-protected keys), strict network segmentation, privilege-separated on-vehicle processing (so a compromised ingestion component can’t directly command the renderer), TEE-based signature verification before content is trusted and continuous vulnerability scanning while all governed under ISO/SAE 21434 and UNECE R155.
Critically, cloud-sourced triggers should never be projected on trust alone. They should always be corroborated against the vehicle’s own real-time sensor fusion world model before being rendered, so a spoofed or injected cloud message can be overridden or flagged rather than blindly displayed to the driver or pedestrians.
Your Locksmith technology is designed so that plaintext master keys remain within a controlled security boundary, while bulk encryption takes place locally. How could this architecture be applied to create a trusted and encrypted data path between cloud services, the vehicle and, ultimately, real-time AR or digital-light projection?
Locksmith’s envelope-encryption model translates directly: cloud services wrap AR, navigation and hazard content locally using a DEK issued by a sovereign KMS, while the master key itself never leaves the secure boundary. The encrypted payload and the wrapped key travel together over segmented, TLS-protected channels. On the vehicle side, the DEK is unwrapped inside a TrustZone/QTEE-protected boundary, and only after AEAD integrity verification does plaintext content reach the privilege-separated rendering pipeline that drives AR-HUD or projection lighting.
Conventional designs force a trade-off here: isolating the master key fully means routing every operation through a slow secure element, while fast bulk encryption usually requires exposing keys to higher-privilege contexts. Locksmith breaks this by keeping the master key sealed inside the KMS while short-lived DEKs do the fast work outside, delivering sovereign key custody and real-time rendering throughput at the same time.
Looking five years ahead, how far could digital projection evolve beyond today’s safety and navigation applications? Could we eventually see third-party apps and services interacting with exterior AR projection? If so, what technical, security and safety requirements would need to be addressed?
In five years, digital projection plausibly evolves from a pure safety/navigation tool into a tiered platform: OEM-only safety content stays locked down exactly as today, a certified partner tier (navigation, municipal, charging/parking) emerges using an extension of the signed, envelope-encrypted, TEE-verified pipeline already described and a sandboxed cosmetic/entertainment tier opens up for lower-stakes third-party content under strict contextual constraints (stationary, geofenced).
The technology to secure this (PKI, envelope encryption, TEE verification, privilege separation) is largely an extension of what e.solution’s cybersecurity and Locksmith stacks already provide. The gating factor over the next five years is far more likely to be regulatory certification, human-factors safety validation and liability frameworks than cryptographic or rendering capability.
Comments