The customization crossroads: Mobileye DXP as a novel approach

Over the past decade, as we have embarked on the gradual transition from driver assist towards autonomous driving, there have been several crossroads along the way where the conventional industry approach has overlooked an inconvenient reality and thus limited the potential for safer and ubiquitous autonomous vehicles – the shared goal in the industry. The path of least resistance often leads to a choice of what seems doable now, but isn’t practical or scalable later.

We saw this when it was understood that AVs needed HD maps on a level that regular navigation maps could not support, and the common approach was to use dedicated lidar-equipped vehicles to manually map an area for AV driving. This was slow, costly, geographically limited, and generated maps that were quickly out of date. This was when we came up with the idea of REM crowdsourced mapping using cameras already onboard ADAS-equipped vehicles travelling on their typical routes.

We also saw this when the industry came to a consensus that cameras, radars, and lidars were all necessary for redundant sensing for AVs, but overlooked how equipping vehicles with that many sensors would make them highly expensive, dramatically limiting profitable business models. This is why we are investing in developing imaging radar with lidar-like output, to reduce the number of lidars included and thereby significantly lowering the hardware costs per vehicle. We even see today that our then-radical early 2000s decision to design our own chip and tightly couple hardware with software is proving central to cost-effective high-performance delivery, while others are only now considering this route.

The industry is now at another crossroads, where we must not overlook an important reality, even if it is inconvenient or hard to overcome, and it has to do with the inherent tension between, on one hand, automakers' desire to customize their offerings and, on the other hand, the time-to-market and performance risks involved in full development of automated driving systems from scratch.

The differentiability-scalability-risk tradeoff

For automated driving to become commonplace, automakers will want to customize their driving experience for their particular consumers' expectations. How to do this optimally must take into consideration three key factors: the ability for the automaker to differentiate among other brands, the ability for the supplier to scale to many automakers, and a need to minimize the risk of not executing to the desired performance, cost, and timeline. Given the numerous announcements about ambitious projects in recent years that never came, or have yet to come, to fruition, this execution risk cannot be overlooked.  

  

Where to draw the line between sense, plan, and act?

The foundation of all robotics is sense-plan-act: perceive the environment, make a plan, and execute the plan. If differentiability is desired, the automaker must control some part of this stack, but the hard question is where to draw the line between what the supplier controls and what the automaker controls, with all three aspects of the tradeoff in mind. If the supplier provides part of the perception and the automaker develops the rest, differentiation is obtained, but the risk to the automaker is very high; development is difficult, time-consuming, and costly. Integrating everything into one complete and robust system is extremely hard.

On the other hand, if the supplier provides all of the driving policy and the automaker handles only the actions taken by the vehicle, either not enough differentiation is achieved on the part of the automaker, or the supplier needs to handle all of the automaker’s driving experience requirements, which is a challenge to scalability.  

So then the answer seems easy – draw the line between perception and planning. Get all your sensing from the supplier, and the automaker can build their own driving policy and actuation stack.

While tantalizing, this too is highly problematic, and where a key reality of AV development gets overlooked: perception is never perfect, and a driving policy must be robust enough to anticipate those imperfections, requiring an intimate integration of perception and planning. Many attempts have been made with this approach and are at various stages of failure, due to what we call the "underestimation plague" – a tendency to vastly underestimate how hard driving policy really is.

Driving policy must deal with predictions, intentions, uncertainties, and risks of decision-making errors and is therefore highly complex. This approach is therefore also not scalable for the automaker, as driving policy is intimately integrated with perception and must be continually adapted and revalidated as perception changes. 

Separating the universal from the unique

Given the above, the better path to enable differentiation while also minimizing execution risk and enabling scalability is to draw the line in the middle of the policy stack, with the goal of keeping the perception and sensing integrated, while offering space to the automaker to define behavioral elements of the vehicle.

In order to do this, we must define which aspects are universal and should be the same for all systems, and which aspects are unique – where differentiation can and should be possible. Perception is clearly universal, and the way the vehicle performs actions is clearly unique. Driving policy, however, is partially universal and partially unique. On the one hand, it must be tailored to sensing, and on the other hand, it is responsible for the look and feel of the driving experience. The art is to find the right granularity of abstractions that will enable us to make the separation between the universal content (which we want to standardize) and the unique content (which we want to customize around).

Mobileye DXP: When, what, and how

Mobileye Driving Experience Platform, or DXP, is a programming language that separates between the universal and the unique, by organizing the decision-making according to when, what, and how. The "when" and "what" are universal, and the "how" is unique. For example, "when" approaching a stop sign, the vehicle must brake to stop (the "what"). But "how" each vehicle model brakes is unique – later and stronger, or earlier and milder, for example. Or, when approaching a roundabout, the vehicle must decide whether to yield or to proceed in front of another vehicle. Assuming both are safe, what should the vehicle do? This is the “how” category, and different automakers will want to tune their systems differently.

How it works inside DXP

Within a given scenario – the "what" and "when" – the automaker defines packages or families of "how" – a variety of implementations of how to brake to stop for example. The automaker constructs packages of “how instances” out of the platform’s “how families". The platform provides online and offline tools for creating these packages. The platform also offers reference designs for required packages, in order to reduce execution risk, such that the automaker doesn't need to implement all packages from day one, but can focus on where it specifically wants to provide differentiation.

Automakers then create code that selects the appropriate package during online driving, based on application parameters like locality, road type, regulation, driving mode, and weather conditions. This solves the differentiability-scalability-risk tradeoff by offering differentiability without breaking the intimate integration between sensing and policy, by using the right abstractions, and, accordingly, reducing execution risk, because the platform will be based on a working product out of the box, and all efforts can focus on differentiation. Automakers can also make post-production tweaks to the driving experience in response to consumer feedback.

The backbone of this platform is based on redundancy in perception engines, and driving policy using Responsibility-Sensitive Safety combined with analytical calculations and intentions (you can learn more about that in this video).

We see great potential in DXP, and in the short time since we unveiled it at CES, several automakers have expressed interest in learning more. The tangible benefits of automated driving systems should help an automaker further define its brand. DXP offers a better roadmap to that future.