Note: On 17 – 18 November, our DVN conference will take place in Stuttgart and for the first time, host special sessions on dual use and on “The Road to Type Approval: Mastering End-to-End AI Systems”.
In the runup to the DVN conference, we are presenting Key ADAS/AV players , and sharing their results, perspectives in this field. Now comes the interview of an important hub of industrial leadership and innovation: Zenseact for Volvo. It has already made is jump from a start-up to a successful supplier in China.
Interview with Jonas Ekmark
Leader of Zenseact’s New Technology organization
Interview by Dr Jürgen Dickmann, Senior Advisor, DVN
DVN: To begin with, who is Zenseact, and how does the company fit into Volvo Cars’ overall AD and ADAS strategy? Where does Zenseact’s role begin, and end compared with Volvo itself?
Zenseact: Zenseact develops AD and ADAS software for Volvo Cars. Today we are fully owned by Volvo Cars, but we have been through quite a journey over the last eight or nine years. We started as Zenuity, a joint venture between Volvo Cars and Autoliv. In 2020, that company was split, and Volvo Cars took almost full ownership of the new company Zenseact. A couple of years later, Volvo Cars became our full owner.
DVN: Does that mean Zenseact is fully bound to Volvo Cars in practice, or do you still have the freedom to work for other OEMs? How does this look in day-to-day business
Zenseact : Now, our deliveries are for Volvo Cars. In practice, this also means deliveries to Polestar where Polestar uses platforms supplied by Volvo Cars. Our current central-compute software stack is in the Volvo EX90, Polestar 3 and Volvo ES90, and it is also intended for the new Volvo EX60. Volvo Cars of course still works with other ADAS suppliers in certain areas.
DVN: How is the platform strategy coordinated between Zenseact, Volvo Cars and other ADAS suppliers? Do you have a clear division of responsibilities across Volvo platforms, or is this alignment decided case by case?
Zenseact: It is a strategic question, and I cannot go into every detail. The ambition from our side is to grow the scope of what we deliver and to be able to support Volvo Cars across its platforms, from the smaller vehicles up to the largest ones.
DVN: So, is the ambition for Zenseact to become a full-line AD/ADAS software supplier for Volvo Cars, enabling Volvo to reduce dependence on external partners and gain more control along the value chain?
Zenseact: Yes, that is the direction.
DVN: What is the strategic benefit for Volvo Cars in following this path? We have seen similar vertical-integration approaches in the past, for example with Delphi and General Motors or with Denso, and some of those models were later adjusted. Why is the approach attractive for Volvo today?
Zenseact: Volvo Cars should ultimately answer that from the OEM side, but from my perspective the main advantage is control. If Volvo has a fully owned software partner for a large part of the software-defined vehicle stack, it can align the long-term product strategy, the data collection, the updateability and the supporting services much more tightly. That long-term control is probably the most important benefit.
DVN: That is interesting because in the interview directly before this one, George Massing from Mercedes-Benz explained that Mercedes has recently chosen a very different route: Nvidia for most of the world and Momenta for China in a kind of turnkey setup. For two OEMs with partly similar brand values, these are very different strategic choices. Why do Volvo Cars and Zenseact believe the more integrated route is the right one?
Zenseact That is what makes the field interesting: there is not one obviously correct model. Different OEMs are betting on different concepts. I can only explain why our setup makes sense for us. It is not an easy choice, and it is also not entirely one-size-fits-all.
For example, China will probably require its own solution over time, while the rest of the world may follow another route.
The reason I wanted to show the slide is that it helps explain the logic of our setup.
These numbers give a snapshot of Zenseact today. We have around 750 employees, with many people working in AI. We have collected a large amount of driving data, and we also invest in training infrastructure for neural networks. Historically, the company started in 2017 and is now fully owned by Volvo Cars, with the main office in Gothenburg and additional offices in Munich and Lund. The important point here is that our software, together with Volvo’s middleware and central-compute platform, enables fast data collection from real vehicles. The clips in the middle of the slide are real AEB interventions from the field, and that kind of data is extremely valuable for development. This integration between data collection and software development is one of the strongest reasons for the closest setup with Volvo Cars.
DVN: Does Volvo Cars also have its own base software platform, comparable in strategic role to Mercedes-Benz MB.OS?
Zenseact: Yes. Volvo Cars has its own base software. It was very painful to develop, but the expectation is that the benefits will now become visible.
DVN: If Zenseact and Volvo are successful with this setup, would you then have the capability to act as a full-line player similar to Nvidia or Waymo, covering not only the driving stack but also the full development chain, including data collection, validation and updates?
Zenseact: Technically, yes. We would have the building blocks: the base software interface, the AD/ADAS stack, data collection, validation support and the development chain around it. Whether Volvo Cars uses that capability more broadly is of course a strategic decision for Volvo.
DVN: On one of your slides, Nvidia chips were mentioned. Does that mean the central-compute hardware is already decided around Nvidia, or are alternatives such as Qualcomm or other chip vendors still under consideration for future generations?
Zenseact: In production today we use Nvidia chips. The software stack we are developing is currently focused on Nvidia, including Orin. For future generations, another chip supplier could also be considered, but that is not something I can conclude on here.
DVN Dickmann: Changing chip suppliers sounds like a major effort. From my experience at Mercedes, once the software is tightly optimized around a GPU architecture, including hardware coding, latency, jitter and execution timing, the dependency becomes very strong. How difficult would it be in practice to switch suppliers?
Zenseact: No, it is not easy to change. Once software, hardware, latency, jitter and the full execution environment are optimized together, a chip change becomes a major effort.
At the same time, it can still be worth considering. Bill of material is one obvious driver, and having alternatives also improves negotiation leverage when buying the central-compute module.
Running two paths is always organizationally difficult, but we have managed so far. With EX60 we hope the performance will really shine and that we can also reap the benefits of our Fleet Insight capability, which allows us to collect relevant data from the field.
DVN: Who decides the sensor setup in the joint Volvo-Zenseact context? For example, whether LiDAR is needed, what type of radar is used, and which sensor vendor is selected: is that mainly Volvo’s decision, Zenseact’s decision or a shared process?
Zenseact: The final responsibility sits with Volvo Cars, because Volvo does the procurement. But Volvo makes those decisions with our input. We define the functional requirements the sensor set must meet for the features we need to deliver.
There are also many other factors beyond the function itself: packaging, cleaning, calibration, integration in the vehicle and the relationship with the sensor supplier. Those topics are on Volvo’s side. The slide shows the current sensor setup, including cameras, fisheye cameras, forward and corner radars and, in the maximum configuration, LiDAR. That LiDAR-related functionality has been discontinued for now, but I think it will come back when we move toward unsupervised functions.
DVN: For which automation level is this current sensor setup designed? Is it purely for Level 2, or already scalable toward higher levels?
Zenseact: Technically, this is still Level 2. When the concept was created, however, the sensor setup was designed to be scalable toward unsupervised functionality, meaning Level 3 or Level 4 type use cases depending on the ODD.
DVN: Staying with responsibility: if Volvo decides the sensor setup and supplier selection, how is the safety responsibility divided between Volvo and Zenseact? Who is responsible for building the marketable safety case?
Zenseact: We have to do that together. Zenseact provides software-related safety argumentation and evidence that Volvo needs in order to build the complete safety case. The total argumentation also includes hardware, integration and vehicle-level aspects, so it cannot be done by one side alone.
DVN: With classical algorithm-based systems, the safety argumentation is usually more straightforward. But once supervised and AI-driven software stacks come into play, the question becomes more complex. Are you planning to move toward an end-to-end AI-driven software stack?
Zenseact: This is a very interesting area because different players are taking different routes.
Our current approach is a combination, Fig.2. We use different sensor modalities, and we also use map input. On top of that we have a large end-to-end deep neural network. Inside the network there is also an intermediate output for objects, and around it we apply what we call safety guardrails. These are typically more traditional, rule-based functions. At the end there is an arbitrator. The end-2-end network is intended to deliver performance, comfort and reasoning in complex situations, while the guardrails are simpler, more reliable and more analyzable. That analyzability is important for the safety argumentation.
DVN: I have many follow-up questions but let me stay safe first. In an architecture with an end-to-end AI path and safety guardrails, how do you validate the overall system? Some players are moving toward AI-driven validation as well, which creates the risk of one probabilistic black box validating another. In your responsibility split with Volvo, who owns the argumentation that this does not become an AI ping-pong problem for authorities, for example in Germany?
Zenseact: Volvo Cars presents the evidence to the authorities.
The interaction with authorities goes through Volvo, but Volvo uses material that we prepare. Of course, the actual evidence is much more detailed than this schematic picture. Conceptually, it is a parallel approach. We try to make use of the independence between the neural network and the safety guardrail functions. That independence is a central motivation behind architecture.
DVN: So, on the software side, Zenseact must also provide the reasoning for how to avoid these pitfalls, including how the probability of mistakes is handled in the safety argumentation. Is that correct?
Zenseact: On the software side, that responsibility is clearly with us. We must provide the argumentation, identify the pitfalls and explain how the probability of mistakes is handled.
DVN: The classical motivation for end-to-end systems is that they can use raw sensor data directly and discover features, patterns and edge cases that a traditional hand-engineered system may miss. But in the architecture, you showed, the end-to-end path seems to be constrained by a more classical control or guardrail layer. If the guardrail has less information than the end-to-end network, why does this not reduce the overall system to the capability of the classical system? Where is the benefit of end-to-end in that case?
Zenseact: The plan is that the safety guardrail should be in control only very rarely, clearly less than one percent of the time. It should intervene only when the network creates an obvious problem in terms of collision margins, for example laterally or longitudinally. It should not reduce the overall performance or comfort of the system in normal use. You can compare it with a human driver and an AEB system: the AEB intervenes very rarely, but it is still extremely valuable when it is needed.
DVN: Let me challenge that with an example. Suppose the end-to-end system detects a potential pre-crash scenario, such as lost cargo on the road, because it can interpret raw data better than the classical layer. It might decide that emergency braking or an evasive maneuver is necessary. If the classical guardrail does not detect the same risk, could it block the maneuver?
Zenseact: Not necessarily. The classical part does not need to understand every situation with the same sophistication as the neural network. It can work more like a boundary setter. It allows almost everything that does not create a collision risk. If the large network proposes a maneuver that would clearly lead to a collision according to the guardrail, then the guardrail sets limits. If the maneuver is uncomfortable but still safe, it can still be allowed.
DVN: So, the end-to-end path can still act as the main decision-maker, while the guardrail intervenes only if the proposed maneuver violates defined collision-risk boundaries. Is that the right interpretation?
Zenseact: It is not really a question of the end-to-end system overruling the guardrail in every sense. The key criterion is collision risk. The classical component will not cover all situations with the same richness as the large network, so the two parts have different roles. The arbitration between them is extremely difficult, because the system must decide which source to listen to at every moment.
DVN: Does that mean validation must focus especially on the scenarios where the end-to-end network adds capability beyond the classical guardrail? In other words, if the guardrail is already well understood in certain scenarios, do you concentrate validation effort on the dark area where the AI path is expected to solve cases that the classical system cannot?
Zenseact: The argumentation will be supported to a large extent by field data. That also requires the right triggers, including for functions that can already run in the fleet but are not yet allowed to control the actuators.
We sometimes call that a gray launch: a new function is tested across the fleet, but only in observation mode. It has not driven the vehicle yet.This gives us much broader exposure than we could get with a stored-data or data-center approach alone.
DVN: Is the architecture you showed intended for today’s Level 2 and Level 2+ functions, or is it already the architectural basis for future Level 3 or Level 4 use cases?
Zenseact: In the near term, this architecture is for Level 2. In the longer term, we would call the target unsupervised functionality. I find the Level 3 and Level 4 definitions somewhat insufficient because the ODD is such a decisive factor. The level alone does not tell you enough about the real risk or the real customer offer. So, we distinguish between supervised functionality, which is Level 2, and unsupervised functionality, which is closer to what people typically mean by Level 3 or Level 4.
DVN: When you speak about unsupervised functionality, should that always be understood within a clearly defined ODD, similar to how a customer might understand autonomous driving within specific boundaries?
Zenseact: Yes, but always within a defined ODD. That ODD is what makes functionality understandable and manageable.
DVN: From Zenseact’s perspective, which is the greater challenge: developing scalable and affordable Level 4 functions, or achieving broad approval for end-to-end systems that rely heavily on AI?
Zenseact: Our long-term target is to improve road safety through full automation. The question is how to get there. Scalability matters, of course: the system must be useful, safe, good and affordable, as every OEM requires. Now, we believe the right approach is end-to-end AI complemented by safety guardrails. We are not relying on AI alone. Some players may argue for that, but we are not there. We prefer the parallel approach because independent channels are valuable. The guardrail path provides redundancy, and redundancy also exists at the sensing level. We will use sensors that are useful rather than reducing the set before we know that the system is safe. In our view, redundant sensing modalities make it easier to build a safe system.
Reference to the architecture image. The AI part is the large neural-network path. The parallel path is redundant, but for a good reason. You could argue that the part that establishes the road and the objects on the road have black-box characteristics, but ADAS has always had some of that. Radar and LiDAR are more physical, but their performance is still statistical to some extent. Computer vision has always had black-box aspects as well, even when geometric algorithms are used.
In our setup it is the same company, but different teams.I would not necessarily describe the architecture simply as a mix of neural and rule-based elements. The arbitrator, for example, is rule-based in my view. But the slide is schematic and should be read as such.
DVN: The background to my question is redundancy. Some companies believe that once you move toward what is normally called Level 4, redundancy is also needed at the software level. They may therefore combine their own sw-stack, an Nvidia-stack or another main sw-stack with a second independent supplier. How do you view that idea?
Zenseact: We do not use an external second software stack in that way. But I understand the idea. It is an attempt to create redundancy in as many dimensions as possible, including teams, thinking and implementation. There can be value in that. In our architecture, I would still argue that there is already quite a lot of independence, but I do not reject the principle.
DVN: As a follow-up, how big is the challenge of data collection itself? Is that one of the central bottlenecks in this overall development path?
Zenseact: Yes, data collection is a major challenge for several reasons, but it is also extremely valuable in the long run. We are investing a lot of effort in it. It has been more difficult and has taken more time than we originally expected, but we are getting there. A key part is making data collection affordable: selecting the right data, compressing it intelligently and doing triggering, selection and curation in the vehicle so that only the most useful pieces are sent back to the cloud.
DVN: So, if I summarize your view correctly, the decisive challenge is less the small-scale optimization of the technology and more the creation of a convincing safety case. Would you agree with that?
Zenseact: Yes, I think many people would agree with that, even if PR departments might phrase it differently. Safety is the main factor holding back the broader deployment of unsupervised functionality.
DVN: Which sensor set does Zenseact rely on for the different automation levels from Level 2+ toward Level 4? This question is linked to the discussion in the ADAS and AV ecosystem around high-resolution imaging radar, for example from Arbe Robotics or Mobileye. If radar approaches LiDAR-comparable performance, have you considered using such radar to reduce cost or even substitute LiDAR? After all, the LiDAR sensor itself is not the only cost driver; the surrounding vehicle infrastructure needed to guarantee quality of service can be just as important.
Zenseact: That is an interesting question. We are in fact collecting data with so-called 4D radar.
Right now we are running two vehicles with two different Arbe devices. That is public, so I can talk about it. The question we are trying to answer is exactly whether this technology can replace LiDAR, complement LiDAR or perhaps replace something else. We have not concluded yet; data collection is the key.
It is impressive how far radar has come. When I started at Volvo in the 1990s, we had mechanically scanning radar antennas. Then came electronic scanning, and now we see 48-by-48 radar systems, which is a remarkable step.
The different modes of high-resolution radar are very useful, from super-short-range modes to long-range modes. You can get a wide field of view very quickly, and in long-range mode you also get the range that is valuable for higher-speed use cases.
I understand the idea, and we are right in the middle of investigating it. In the large network, especially in the detection, fusion and tracking part, we can examine where the model places its attention and which sensor modalities it uses in different situations. That is useful, but it will probably not create a simple black-and-white safety argument. It is more nuanced than that. One advantage for us is again the fleet as a source of statistical information. With Fleet Insight we can build much larger datasets from real vehicles. We are not ready to draw a conclusion on high-resolution radar versus LiDAR yet, but large fleet data could be an important enabler.
DVN: With centralized architectures and new redundancy concepts, sensor setups can be rethought. If statistically independent sensor streams can be calculated centrally, it may become possible to remove expensive LiDAR and its required vehicle infrastructure. How does Zenseact position itself in that discussion?
Zenseact: It is a very interesting direction, and we are actively considering it. But we have not made a final decision.
DVN: Will SD or HD maps become unnecessary with end-to-end approaches, or will maps remain relevant? At Tech.AD 2026 and other conferences, some speakers argue that HD maps are no longer needed and that a lower-resolution SD or SD-plus map is sufficient, especially with advanced end-to-end software stacks. Do you agree with that view?
Zenseact: I am a bit bothered by the idea that maps will simply disappear, because it is like saying that self-driving can be solved with vision only. It is easy to make that claim, but the vehicle will always face occlusions. No matter how good the sensors are, you cannot see what you cannot see.
In situations, which are not rare, map information is useful. The geometry of the road, lanes, exits and entries can be valuable. It does not necessarily have to be a full HD map. There may be a middle ground, something like an SD-plus map, where the most important geometry is available. Of course the map can be outdated, so you cannot rely on it as the only ASIL-level source. But if the alternative is no information at all because the road ahead is occluded, the map is still valuable.
Maps are also useful for speed limits. Speed-limit logic differs between countries; sometimes it is linked to road type, sometimes to the last sign, and the rules are not always simple. I therefore believe maps will remain useful, especially if Fleet Insight can help keep them fresher over time.
DVN: Let me return to validation. The current logic in the industry is often to generate mileage that cannot be achieved with a real fleet through simulation, for example with physical AI, generative AI and scenario variation. But this again raises the question of two probabilistic systems interacting during validation. How do you expect Zenseact and Volvo to build a truly marketable safety case for unsupervised functions?
Zenseact: This is the very difficult question. What I can say is that we will not be on the risk-taking side when it comes to application release or ODD expansion. Given Volvo’s heritage, we are expected to be on the safe side. We do not feel pressure to do risky experiments or launch something that is not defensible. That may mean we are somewhat more conservative at the beginning, for example by starting with a smaller ODD, but the focus is a strong and defendable safety case.
The drawback is obvious: the initial customer offering may be smaller.
We are also trying neural-rendering methods. They are very powerful, but they are slow. Building the models and running the simulations is difficult. Object-level simulation still has value because it is much faster. So, we are working with both approaches and evaluating where each one is most useful.
DVN: Final question. Your path toward becoming a full-line player is ambitious in today’s environment. The ADAS and AV ecosystem has become more concentrated around a few very large, well-funded players, and the time pressure is increasing, not least because of the speed of development in China. What convinces you that Zenseact can still achieve this goal?
Zenseact: It is a real concern. Strategically, it is one of the major questions. We have to be very smart about what we build in-house and what we buy.
The software stack itself is something we build in-house. But for tools, simulation, verification and similar areas, we need to decide carefully where internal development is truly strategic.
For example, we recently shifted to buying the CI/CD toolchain, which frees up internal resources.So, the principle is to keep the strategically important parts in-house and buy best-of-breed solutions from the market where that makes more sense. But yes, it is a concern.
DVN: This was an intensive and very interesting insight into a very different view of how to win the race.
Mr. Ekmark, thank you very much for sharing these insights. I hope we can welcome you to our conference in Stuttgart in November.
