Mobileye Global Inc. (MBLY) Earnings Call Transcript & Summary

Good afternoon, and welcome, everyone. I'm Dan Galves. As I said yesterday, yesterday was the 10th iteration of our CEO, Amnon's annual CES presentation. This is the first time we've done a bit of a big deeper session at CES, and there's really no one better to take care of that for us, then Professor Shai Shalev-Shwartz, our Chief Technology Officer. Shai's not only a key architect of everything about Mobileye, but he's also a person that really can put very complex issues into simple terms, which I really appreciate. Before we begin, please note that today's discussion contains forward-looking statements based on the business environment as we currently see it. Such statements involve risks and uncertainties. Please refer to the accompanying presentation, which includes additional information on the specific risk factors that could cause actual results to differ materially. Without further ado, I'd like to welcome Shai to the stage.

Thank you, Dan. So I'm going to talk about a new platform developed at Mobileye called Driving Experience Platform or DXP for short, about the architecture, why we decided to put this platform in its particular shape, abstractions that we are using in the APIs. So the outline of the talk will be as follows. I will start with asking the question, why at all should we care about the platform? And what exactly is a development platform. Then we will deep dive a little bit about previous platforms, how we think is the right way to build this platform I will talk about the differentiability, scalability and risk trade-off in building such platforms. Then we will introduce the platform. And at the end, we will wrap up with some backbone of our solution that lies beneath the platform. So if we think about platforms, they are everywhere. When we use an operating system like Windows, iOS or Android or Linux, it is a development platform. programming languages or development platforms. There are task-specific developer packages like Spark for working on the cloud. And they are high-level interfaces like ChatGPT that most of you know, weeks for designing websites, et cetera. So why someone should use a platform? The simple idea is that you don't want to reinvent the wheel. So if you want to write an iOS up, you want to focus on the content and the specifics of your application and not reinvent iOS, the operating system itself. So for the user, it saves time and resources. And for the supplier, it enables scale. So in order to explain how should we build the platform, let's talk about autonomous driving and how it builds. Usually, in robotics, we are talking about the Sense Plan Act methodology. Sense or perception is understanding the surrounding, what's around us. It is where the cars around us as well as mapping whereas the lanes who has priority, et cetera. Planning is a decision-making process. We call it driving policy. What would happen if type of reasoning. So if I'm going to yield to someone, is it going to be okay or not, if I'm going to not slow down, is it going to be okay or not. And at the end, after we decided what we want to do, we need to actually do it, and this is the act part or the control, executing the plan, moving the steering wheel, hitting the throttle, et cetera. Now when we talk about a platform, there are 3 considerations to make. The first one is differentiability. The user of the platform should be able to differentiate its product from other products. So when we are talking with our customers, OEMs, they want to control the experience of the system. They don't want to take a turnkey solution and just take a black box that behaves the same on all car platforms. This is differentiability. The second issue is scalability, more for the development of the platform, in this case, Mobileye. We want that the resources that we invest for every customer grows sublinearly with a number of customers. So we don't want to have a dedicated group for every OEM. Otherwise, we won't be able to scale. But another factor which is very, very important as well, is a risk factor. We want that people that are using the platform will reach a real product and not just playing with the platform and not succeeding in reaching a real product by using the platform. So based on these considerations, let's think where we put the line between the platform and the user. And let's look again at the perception plan a sense plan and methodology. One approach, which has been taken by some suppliers of autonomous driving platforms is splitting between platform and user somewhere in between or in the middle of perception, say, giving some APIs for training newer networks. So low-level perception will be supplied by the supplier of the platform. And the user need to work and build the entire perception plan and the driving policy and the control. The problem with this approach is high risk. We get full differentiability with this approach, but the risk of succeeding is high. Another option on the other part of the spectrum is having the supplier of the platform deal with perception and planning and leaves only the control part to the OEM. The problem with this approach is that there is no differentiability or no scale. So either the OEM gets a package and cannot differentiated solution from others or the OEM will come to Mobileye and will ask for this change and that change and very, very quickly, we will need a big team for every customer. So maybe the best place to put the line between the platform and the user is between the perception task and the driving policy task. And this idea was actually coming from customers. Many customers told us, give us just a perception layer, we will do the rest. And the idea is that we will do the perception, they will own the driving policy. And by owning the driving policy, they will own the entire look and feel of the car. So is it a good approach? In order to answer it, we must accept that driving policy is also a very complex thing. And the problem with this approach is high risk. And I call it the underestimation play. So if we go back to 2016, there were headlines all around that self-driving is really almost here. And many projects started with a huge optimism that in a few years that they can come and bring autonomous driving to the market. But self-driving is difficult. And maybe the reason for the difficulty is that self-driving combine both the complexity of advanced AI systems with the extremely high precision required for system that required high level of safety. Okay. But this was back in 2016. Today, we have deep learning -- we had deep learning also in 2016, but today, we have better deep learning, okay? So maybe deep learning to the rescue. So it turns out that even the most modern deep learning systems like graph neural networks, transformers, BEV formers and all the new cool kid in the town, still make unintuitive errors are still bad at edge cases, still struggle with planning. And there is no single evidence of a modern AI system that reaches the accuracy of 99.99 enough after the dot, which is the level of accuracy we need from safety-critical systems such as autonomous driving. And maybe the reason is all of these approaches are statistical approaches, they are built on statistics. And the problem with statistics is that the tail is very, very difficult. So the problem with putting the line between perception and planning is that we still have high risk because driving policy is also hard. And I will explain later that you need to deal with predictions, intentions, uncertainties, risks of decision-making errors, efficiency of planning, all of this is really hard. And it is also not scalable. Why? Because perception is never perfect, especially when we are talking about consumer level autonomy where we must have compromises on the price of the system. So driving policy must have intimate integration with a perception layer. If the perception has changed, driving policy must be adopted. And then putting the line between supplier of the platform and user of the platform in a place that require delicate integration is not a good idea. It's a recipe for problems. Okay. So if this is so hard, what are we going to do? So let's go back and ask ourselves how to design a good self-driving platform. We want to enable differentiation while minimizing the risk and enabling scalability. These are the 3 things that we wanted before. And the idea is to hide universal content because there is nothing to differentiate in universal content and focus on the unique content. And now the main art is to find the right granularity of obstruction that enable to do this separation between Universal and unique content. Okay. So let's look again at this picture and look below the graph of universal versus unique. On the left-hand side, we have things that are clearly universal, like the perception stack. The perception stack is universal. Everybody wants to know where are the cars, where the pedestrians, where the lanes. There is nothing here which is specific to some OEMs. On the right-hand side, there are things that are clearly unique. The control is unique to the car platform. The HMI is unique to the car platform. The question is -- and this is an elephant in the room, what do is driving policy. On one hand, driving policy is difficult and we want consolidation of efforts. But on the other hand, driving policy is the main responsibility for the look and feel of the driving behavior of the car. So we need to be more delicate and split the right split between Universal and unique. So for Universal, let's see what is for sure Universal. Facts are for sure universal, okay? So where are the road users, hazards, traffic lights, all of this, there is nothing to differentiate. Uncertainties, it's also very important. Usually, it is in the driving policy part, but it's also universal. So you need to know not only what you know, but also what you don't know. If you have lack of visibility, you need to know it. If you have occlusions, if you have air bars on your estimators, another thing which is universal is semi effects. What are semi-effects? Semi-facts are things like predicting the future, predicting what are the intentions of other road users. For example, there is a car which is standing. Is it a parked car double parking or is it a car that is standing in a traffic jam. The behavior will be very different between these 2 options, but the kinematic state of the car is exactly the same. It is standstill, okay? Likewise, is a car intent to park, to perform a cut-in to perform a U-turn. All of these uncertainties are universal. You want the best understanding of the intentions of other road users no matter how you want to differentiate the product. Likewise, we invested a lot in optimization engines. You want everything to be very, very optimized in order to run efficiently on the car. So efficient data structures and optimization engines are also universal part. On the other side, on the right-hand side, the unique part is what to do with all of this information on the kinematic state of other cars and the uncertainties. Decisions like discrete driving decision, do you want to perform now a lane change or not? Here you can do something which differentiates between different platforms. One OEM will want more lane changes, more sporty type of driving. Another OEM will want something more calm, it depends on the customers, overtake or stay behind and other discrete driving decisions. Likewise, continues from longitudinal planning, how exactly you want to accelerate faster, milder, how we want to break in advance or at the last minute. All of these are things that enable differentiation, lateral planning and, of course, controlling the HMI. So this is the right split between universal and unique, and we need to put the difference between the universal part of the platform and the unique part of the platform is the right place. So now that we understand it, we need to ask ourselves how we do it. And the triplet answered is when, what how, okay? So when and what are universal and how is unique. Let's take an example. When we approach a stop sign. What we need to do, we need to break, to reach full stop. This is universal. Every OEM will want to break to full stop at a stop sign. There is no differentiator. Where is the differentiation in the how, what is the exact breaking profile on how we want to stop, do we want to stop later and stronger? Or do we want to stop in advanced and milder. Likewise, when we approach around about, we need to yield or take away to other cars in the roundabout. That's for sure. Now assuming it is safe to take both of these decisions, should we yield or should we take away. This is how, and it depends on yield logic that can be owned by the OEM and one OEM will be more assertive. We will want to be a behavior which is more assertive. Another one will want to be more mild, okay? So here is a bipartite graph. On the left-hand side, we see when, on the right-hand side, we see what? And these are several examples of when and what from the platform. Now as you can see, all of this is universal. When you approach a speed bump, you want to slow down, okay? This is universal. There is no differentiation. The only question is how much, how fast, how exactly here you should -- in the how you need to differentiate. But in the when and what, this is universal. So how it works. We take some scenario, what and what we want to do in this scenario, break to stop. And then we enable the OEM to define packages or families of how several implementation of how to break the stop. And from this, we can derive specific instances. So I will briefly explain how is the experience of working with DXP. There are 2 steps. The first step, which is done in advance, is that the users, the OEM construct packages of instances, how instances out of the platform's families of what the platform enabled to do. So the platform provides off-line and online tools for creating these packages and see how they work in simulator or in online injection, recording tools, and then the OEM can find these packages at ECARX. Very importantly, in order to minimize risk, the platform provides reference design to all of the required packages. So the user doesn't need to implement from day 1, all of these packages. We can focus on the specific instances that he wants to change. So we start with something working from day 1 and then can focus on, one, what are the most important things to differentiate. And depending on the time until SOP can choose more or less to optimize. Then the user creates code that during online drive select the packages based on application parameters like locality, road types, regulation, driving modes, weather condition, et cetera. This approach solves a differentiability, scalability risk trade-off. Of course, we get differentiability. The user of the platform have full control on the unique content of the driving experience. We get scalability because this obstruction doesn't put the line in places where integration is a big risk. It puts a line in places where the integration is seamless. And in addition, we provide reference design, so the user can also look at our reference design and find out if it's doing something wrong. Also, in terms of risk from day 1, the user gets a reference design, something that works out of the box from day 1 of the project of the implementation of the project. So there is no risk of not converging in time to production. The only risk is whether we succeeded to do all the differentiation that we wanted or maybe only a subset of the differentiation that we wanted. But project will succeed for sure. This is just examples of code, just to show you that it's not just PowerPoint, it's really working in the car. I will not go over the cut, but just to let you know that you take some what, like break to stop and you define the scenarios, the when that apply to this work. For example, for break to stop, you have traffic light red light, you have traffic like right on red, yield with blinking red, et cetera, stop sign, end of path because we are going to hit rotate and many other cases, bottleneck with on coming, very narrow street where we want to stop because there is oncoming car. All of these are instances of breaking to stop. And this is an example, very simplistic code of what will happen in online. In online, the customer needs to write the code that chooses the appropriate package of how to break the stop at that moment, and it can depend on country code it can depend on road type. It can depend on resel condition and HMI items like driving mode. Now will show you a short movie showing 2 completely different behaviors of the car, that both of them were constructed by DXP. So just by writing this DXP cord on the same backbone of the platform, we can achieve really different behavior of the car. On the left-hand side, you will see a more aggressive style of driving. And on the right-hand side, you will see -- or maybe the other way around, you will see a more milestone. Let's see if you will manage to see the difference between the sites because I don't remember Okay. So which side is more aggressive? You got it. Okay. So the last part of the talk, I will touch a little bit about the engine behind the platform. So what are the ingredients that enable us to build the perception in the driving policy layer? How to build a capable driving system. So the first thing we said it back in 2017 in scientific paper, we must separate driving policy from perception as opposed to an end-to-end system. And there are many good reasons for that, and Amnon talked about it yesterday in more detail. So the perception for the perception, the basic methodology that we are using is redundancy. So we build a modular design, and gradually, we add more and more redundant player. Therefore, supervision system already can drive everywhere, but maybe not accuracy enough for eye off system. And gradually, we are adding more layers to enable full stack. On the other side, driving policy, here the idea is the RSS model, the responsibility sensitive safety model, which I will talk about it a bit and intentions versus predictions. So let's start with the perception stack. The idea is redundancy. And here are 4 exes of redundancy. One redundancy is in the sensor set, camera versus radar versus LiDAR. Another excess is the composable versus end-to-end approaches and those Amnon talked about it yesterday. Another layer is appearance versus geometry approaches. So our appearance is what we see in terms of the semantic meaning of what we see in an image. So we see something when we say we know to name it. Its name is a car. And because this is a car, we know what to do with it. Geometric approach means that we don't know what it is. We just know that it's above the road surface. So we shouldn't hit anything which is not flat on the road, okay? So this is another type of thinking. And every type of thinking has its own advantages and disadvantages and this redundancy approach enable us to enjoy the benefits of all words. And at the end, learning versus model-based approaches. So very, very quickly, I'm going to show you for the problem of vehicle detection many points on this 4 axes of redundancy. So here is camera, learning, the composable appearance-based and then camera learning end-to-end appearance based. And then camera model-based, geometry based and then camera learning-based geometry based. And camera learning end-to-end appearance based and LiDAR model composable geometry and learn, blah, blah, blah, yes, you got the picture. So we are not building a single system. We build plenty of systems. And then we utilize the benefits, the advantages of all of these systems because there is no single system which rules them all. Every system has its own benefits and failures. And by building all of them, we can smartly choose between the different approaches. The last part is why driving policy is difficult. So in driving policy unlike a sensing part, there is no ground cruise. There is no single right answer, whether I need to yield or can I take the right of way. In addition, actions that are performed now have long-term effect on the future. So we might have butterfly effects. Everything is working in closed loop, so we are also affecting the environment by our own actions. And we must handle uncertainties about the futures. We must reason about what others might do and what is not reasonable that others will do and act accordingly. It's this approach -- this driving policy problem and these problems also lead to computational challenges because we must plan for sufficiently long time. Otherwise, we might find ourselves in a situation where things looked fine before, but then now they are looking very, very bad. So for example, this car here is driving 10 meters per second. If we look only 2 seconds into the future, then we see that everything is clear because the other cards that is standstill is 20 meters away. So in 2 seconds, we see nothing, no problem. It's great to continue and do the maneuver right. But of course, it's a horrible idea to do it because we will find ourselves hitting the other car. So we must plan for a sufficiently long time. But then because of the butterfly effect, we have we need to reason about an evolving future. So what is Mobileye's approach to this driving policy challenges? The idea is RSS plus analytical calculations plus intentions, okay? So quickly going over the main ideas. RSS is an assume guarantee type of methodology. This is something that is used in safety systems like aviation. The idea is that you want to assume the worst case under a well-defined set of reasonable assumptions. And then under these reasonable assumptions, every bed thing that might happen will happen, okay? So we need to plan for the worst case. And then how can we do this? Because there are infinite possible futures Here's come the analytic calculations. It is impossible to do it in a numeric way. So what we are doing is that we are coupling all the future into the present using analytical calculations. This idea of coupling the future into the present is very similar to dynamic programming methods, which are popular in driving policy and planning problems, okay? But unlike driving like dynamic programming method, which requires predictions of other agents. For our method, we are not using prediction, but we are using intentions of what others might do. And this results in more human-like behavior. Think as an example of a pedestrian standing on the side of the road, okay? Predictions mean that I know exactly if it is going to -- across the road, they know exactly the trajectory of how exactly it's going to cross the road at what speed and exactly the care that is going to do. Intentions on the other hand, ask a single question, does it intend to cross or not? If we intend to cross, I need to take the worst case of trajectories that you might do and be ready for it. If it's not going to cross, then final can continue. So it's a much simpler requirement from the AI that needs to do the postulation or the prediction of what the intentions of the road user. And we use all the modern AI tools as well as model-based tools in order to construct these predictions. Okay. So just to sum up the comparison of mobilized approach for driving policy to other approaches. So in the columns, you see Mobileye approach, you see another popular approach, which is called Monte Carlo Research. Which came to a great popularity in the works on using AI for solving games like Chess, like Go. There is a dynamic programming on macro decision processes or linear podiatric regulator. And end-to-end learning that now also are very, very populated, just give the AI best all the information and let it rule out what to do. So when we judge -- when we are judging these methods, we need to look at several considerations. Transparency, do we understand what the system is doing. Controllability, can we change the behavior of the system, which, of course, is very, very important for OEMs in order to own the product. Performance is it efficient approach? Or does it require a massive amount of computation. -- sorry, this is efficiency. Performance is how good the system is working and can we guarantee that it always works. And the only approach that has a V in all of these is mobilized approach, and this is why we chose this approach. So to wrap up, Mobileye, DXP, this platform makes a separation between universal content and unique content. We as when, what, how obstruction. It solves the expressivity scalability risk trade-off. It enables both expressivity, enabling the OEMs to differentiate, enable Mobileye to scale up and leads to a product that will work to projects that will succeed. The many grants of the platform's backbone are the redundancy as a key component for perception and driving policy using RSS plus analytical calculation plus intentions. Thank you very much.