From CES: Solving SDV Complexity With QNX + Vector’s New Alloy Kore Platform
Annotations will appear as you listen
0:00
67:16
Car
Ford Model T
The Ford Model T was one of the first cars that many people could afford. It was made by Ford and was produced a long time ago, from 1908 to 1927, changing how cars were made and sold.
Car
Mercedes-Benz Sclass
The Mercedes-Benz S-Class is a very fancy car that is known for being super comfortable and packed with the latest technology. It's often seen as one of the best luxury cars out there, and many people admire it for its smooth ride and high-end features.
Term
ECU
An ECU is a small computer in a car that helps control different parts of the car, like the engine and the seats. Many cars have several of these computers to manage all their features.
Term
Android Auto
Android Auto is a way to use your Android phone in your car. It helps you access apps and maps on your car's screen safely while you drive.
Term
CarPlay
CarPlay is a feature that lets you connect your iPhone to your car. It makes it easier to use your phone's apps and maps on your car's screen while driving safely.
Term
ADAS
ADAS means systems in cars that help drivers stay safe and make driving easier. Examples include features that help you stay in your lane or automatically brake if you get too close to something.
Term
OEM
OEM means the original company that made the parts for your car. For example, if your car has a part made by Ford, Ford is the OEM for that part.
Term
LiDAR sensors
LiDAR sensors are special devices that help cars see their surroundings by using lasers. They create a detailed map of what's around the car, which is important for self-driving technology.
Term
GPUs
GPUs are powerful computer parts that help process lots of information quickly. In cars, they help with things like self-driving features and analyzing data from sensors.
Term
vertical integration
Vertical integration is when a company makes more of its own parts instead of buying them from other companies, which can save money and improve quality.
Company
Rivian
Rivian is another car company that makes electric vehicles, especially trucks and SUVs designed for outdoor adventures.
Term
silicon
Silicon is a material used to make computer chips, which are important for the electronics in cars, especially electric ones.
Term
level four autonomy
Level four autonomy means the car can drive itself in certain situations without needing you to take control. You can relax and let the car do all the work when it's in those areas.
Term
AI
AI stands for artificial intelligence, which is a technology that helps cars think and make decisions on their own. It allows them to learn from their surroundings and improve how they drive.
Term
level three autonomy
Level three autonomy means the car can drive itself most of the time, but you still need to be ready to take over if something goes wrong. It's like having a really smart co-pilot.
Car
Cadillac Escalade
The Cadillac Escalade IQ is a new luxury SUV that will let you drive without using your hands in some situations. It's a part of the Escalade family, which is famous for being big and comfortable.
Term
FSD
FSD means Full Self-Driving, which is a Tesla feature that lets the car drive itself in some situations. It can change lanes and go through intersections without you having to do anything.
Term
Super Cruise
Super Cruise is a feature from GM that lets you drive without using your hands on the wheel on some highways. It uses special technology to keep the car safe while doing this.
Term
Blue Cruise
Blue Cruise is Ford's feature that lets you drive without using your hands on some highways. It checks to make sure you're paying attention while you do this.
Term
Hyundai Drive Assist
Hyundai Drive Assist is a feature that helps you drive by steering and controlling speed for you in certain situations, like on highways.
Car
Tesla Model
The Tesla Model Y is a fully electric SUV that has a lot of space inside and comes with high-tech features. It's known for being environmentally friendly and having a long driving range on a single charge.
Term
version 14
Version 14 is the latest update for Tesla cars that makes them work better and adds new features. Tesla regularly updates its cars to improve how they drive and what they can do.
Term
augmented reality
Augmented reality is a technology that adds digital images or information to what you see in real life. In cars, it can show things like directions right on the windshield, making it easier for drivers to see where they need to go without looking away from the road.
Brand
Audi
Audi is a car brand from Germany that makes luxury cars. They are known for using advanced technology in their vehicles, making them comfortable and high-performing.
Term
internal combustion
Internal combustion engines are the engines that most cars use, where fuel is burned inside the engine to make it run.
Term
hybrid
A hybrid car uses both a regular engine and an electric motor to help it run better and save fuel.
Term
EREV
An EREV is a car that mostly runs on electricity but has a gas engine that helps it go further when the electric battery runs out.
Car
Porsche 911
The Porsche 911 is a famous sports car that many people love for its speed and handling. It's known for its unique shape and powerful performance.
Car
Bmw M
The BMW M Coupe (E36) is a sporty car that is designed for people who love to drive fast and enjoy a thrilling experience. It has a unique look and is known for being fun to drive, which makes it popular among car fans.
Car
Cadillac Ctsvs
LIVE
We have to make sure that we're taking advantage of the collective knowledge of the industry to
make sure that we're solving these types of integration problems as well.
We want to make sure that there aren't any guesses.
Safety can't be guesses.
Security can't be guesses.
Welcome to The Inevitable, a podcast by MotorTrend.
Hi there!
Welcome to The Inevitable.
This is MotorTrend's podcast, our podcast about the future of the car, the future of mobility,
where we're going, how we're going to get there.
This week is a little different because Ed and I are here in our Culver City studio,
but what you're about to watch took place in Las Vegas not long ago.
Yep, and I have a special announcement.
The Inevitable podcast is brought to you by QNX, whose high performance foundational
software powers over 275 million vehicles on the road today.
QNX delivers safe, secure, reliable, and scalable solutions, enabling automakers to unlock transformative
applications and drive new revenue streams and launch innovative business models all without
compromising safety or security.
The Inevitable podcast is also brought to you by Vector, a competent partner in embedded
software.
For over 35 years, Vector has been helping the industry simplify complexity and accelerate
the transition to software-defined vehicles.
And both of our guests happen to be from QNX and Vector Informatic.
We have Justin Moon, vice president, core product engineering from QNX, and Dr. Mark
Weber, vice president, product management, embedded software and systems from Vector.
And this is a very interesting conversation.
To be frank, Johnny and I had to do some extra prep because we thought, you know,
this stuff is super technical.
We're on the show floor at CES.
We're actually in QNX's booth.
And, you know, it's a very tough topic for two car guys who mostly test and evaluate
consumer vehicles.
Right.
Car go fast.
Yes, good.
Car go fast.
Look at this guy.
We like car.
Turns out, actually, a very interesting and very fast-moving podcast because both
Justin and Mark were great guests.
They're very good on camera.
Very good on camera.
And they also, you'll be able to tell immediately they've worked for a long
time with each other.
So they're basically finishing each other's senses.
So it's a very interesting, very technically techie and technical focused podcast if you're
into the future of software-defined vehicles.
So let's get right to it live and direct from QNX's booth at CES.
All right.
So Justin Moon and Mark Webber.
Thank you for coming on to the inevitable.
I'll ring my bell here at CES.
First of all, could I just ask you to introduce yourself?
Remember, this is both a video and audio podcast.
So why don't I start with Mark Webber?
Introduce yourself.
Yes, sure.
So I'm Mark.
I am from Germany with Vector since approximately 15 years.
Started there as an software development engineer and moved over to product management,
which I'm now responsible for.
So like heading the product management for embedded software and tools at Vector.
Very good.
All right.
Product management, embedded software and systems at Vector Informatic.
Exactly.
Very impressive title.
He's the guy to know.
He's the guy to know.
You are the guy to know.
And you are the guy to know.
Justin, please.
Well, I'm Justin Moon.
I've been with QNX for about 25 years.
Oh, wow.
Yeah, yeah.
I'm a long timer, held a lot of different roles from hardcore engineering to strategy
management.
I'm currently running our core product engineering organization and I have the absolute pleasure
to work with partners like Vector, more specifically people like Mark.
Like Wes.
On some of the more strategic developments that we're doing, like Alucor that was launched
today.
Okay.
All right.
We'll get into that in a little bit.
We'll stay with you, Justin.
Can you, for those, now this podcast is, it's for the automotive enthusiasts, it's
for the laymen, but apparently we also have some very techie people because I got
stopped on the way in by somebody who's like, hey, great job with the park.
I was like, I was very flattered.
I don't get, Johnny gets called out a lot more than I do, but it's quite an interesting
thing when somebody knows.
That's just a looks thing.
But for those who, I'm going to ask you to break down, like just briefly what your
day to day looks like.
So like what do you actually do, Justin, at QNX?
I can't just say overhead.
That's not good enough.
No, no.
So if you could explain it sort of like, what should day look like?
Sure.
Yeah, no problem.
So when we think about QNX, we have a core set of products that's our operating system
or hypervisor, our safety security pedigree, all of the tooling that goes around that.
My organization is responsible for all of that software lifecycle for all of those
products.
The product portfolio is quite large.
My day to day is literally working with my lead engineers, my directors, my senior
directors on product and strategy paths, portfolio management, making sure that we
are making the right decisions and right bets when it comes to technologies and
paths forward.
I am an engineer, so I do participate in architectural discussions, and I try to
stay in the techie side of it as much as I can, but at the same time, I work
a lot with our larger customers and our partners.
Mark and I have been working together directly for the last two years, but
indirectly for a decade.
Oh, wow.
Yeah, yeah.
So, I mean, my days are full, but it's all about, you know, that technology
management, the portfolio management, you know, bridging the product and strategy
with the engineering organizations, our customers and our partners.
Okay.
Same question to you, Mark.
What's your day-to-day look like?
I couldn't have explained it better than just you.
Okay.
All right.
Same, similar?
It's pretty much similar.
Although the top top titles are quite different, but I think from a role
description or what we are doing from a day-to-day business, it's more or less the
same.
So, if I would have to phrase it in one sentence, we are translating the
customer wishes and architectural concepts to be realized by our
development departments.
Okay.
And is that, I know, because you're, you know, you're based, sorry, I'm
pointing, Justin's in Ottawa, and Mark, you're in Stuttgart, right?
Yes, exactly.
So, are your days, they're not nine to five, right?
You must do calls at all different times.
What's nine to five?
Exactly.
Okay.
So, because you have clients in Asia, you have clients in Europe for
Justin, and you're obviously dealing with the U.S. quite a bit.
Although I have to say that, luckily, we have the subsidiaries or our subsidiaries,
they are taking care on the first level with our customers.
And I'm in favor of then going to Asia, going to the U.S. to have face-to-face
meetings because just having a call in the morning or having a call in
the evening doesn't the deal.
So, in a supportive manner, yeah, you can do so.
And if you want to get into discussions and into whiteboard sessions,
you have to be on site.
Okay.
As a technologist, it's difficult for me to say that, you know, the face-to-face
is better.
There's plenty of technology for telepresence and all of those types of
things, but I'm a firm believer in a real handshake at the end of the
day.
Yeah.
You know, being able to be face-to-face with people, being
able to break bread with people, that's how relationships are formed,
right?
It's not necessarily over a screen.
Screens are great from a work tool perspective.
But I mean, we, I see Mark more than I see a lot of people.
We are, you know, an ocean apart, sir.
Right.
Right, right, right.
Okay.
Now, we're five minutes in, and I know there's some listeners who are
still like, I still don't know what these guys do.
Uh-oh.
True.
Yeah.
And some hosts, too.
Yes.
So, I'm going to go back to Mark and say, if you were to explain
this to your five-year-old, is there something you can point to in the
car that you would say, this?
This is why daddy works so hard.
This is why daddy works hard.
This is what daddy works on.
Everything from A to B. So, not like pressing a button.
This is nothing we are doing.
But if our software doesn't work, the car is just not working.
It breaks down.
So, like, we did a survey back, I don't know, 20 years, and I think if all of
our software would crash and would not work, 80% of the cars would just stop
working.
80% of the cars in the world.
Yes.
Yeah.
Okay.
Like, software-equipped cars.
I mean, there are cars, of course.
All right.
Model T.
Sure.
It's been decades now.
Exactly.
It's been a long, yeah.
As soon as networking comes into the picture.
So, like, if you only have an engine-controlled unit back then, in the
old days, that's maybe nothing we have been in touch with.
But as soon as ECUs started talking to each other, networking, then that's
our home turf, and then we started in there.
So yeah, like, providing the underwear for the car, so make it work.
Providing the underwear for the car.
I like that.
Maybe something that I understand.
That I understand.
Like, I remember, this was probably going back a decade or so, at one point
there was like, you know, I think it was like, you know, the Mercedes S-Class
has over 100 ECUs.
There's an ECU for the seat.
There's an ECU for the whatever.
You guys enabled those to, like, work via partnership with
Bach.
You being vector.
You being vector.
Yes.
Especially making the ECUs understand and talk to each other.
Yes.
Maybe there's some task to make an ECU alone work.
Like an ECU does the job.
But it's another task to make it work in a set of ECUs, in an environment,
in a system of systems, basically.
The specification of the messages and what the structure of all of those
things look like.
Exactly.
So, in other words, like, unlock activates a lot of ECUs in a car.
Yeah.
System of systems instead of a system alone.
In a sense of not building an ECU, but building a car, building an EE
architecture and then having, I mean, our philosophy, and I think that is also
something shared with QNX and Justin is like, we want to be the
simplifier of the automotive engineering or the EE automotive engineering
industry.
So, not providing the functional solution in a sense of that's
perceivable by the end customer, but make it as easy as possible for
tiers, for OEMs to get the system up and running and make it work
safely, securely, and in a performant manner.
If you think about collectively what companies like Vector and QNX do
today, it's about forming the building blocks for each one of
these ECUs to actually function appropriately.
So, with Vector on the calm side of things, with diagnostics,
with logging, with all of the things that every ECU needs in
order to interact with each other properly, we provide that low
level operating environment for people to build those automotive
services on.
So, maybe not the brake controllers and the very small ECUs out
there, but as we transition into more centralization, let's say,
in terms of how compute happens in a vehicle, that's where we
truly shine from an operating environment perspective and it
isn't necessarily just an operating system, it's also
about virtualization, it's about complexity management,
really is what Mark said.
At the end of the day, he said simplification, but really
what the industry needs is complexity management.
These systems are absolutely complex and if you look at the
problem space that the automotive industry is, it isn't
necessarily just software, it's safe software, it's secure
software, it's automated software in a lot of situations.
So, having those foundations or those fundamentals, being
able to rely on those things, knowing that they're going to
just be there and they're just going to work, so you
don't necessarily have to worry about those types of
things and innovate at a, I don't want to say at a
higher level, but I want to see at a much more strategic
level.
Like, in other words, these fundamental problems are solved,
like you're not going to get hacked, it's not going to
turn off when it shouldn't turn off, go do your thing.
And I mean, it's a big part of, you know, I'm going to jump
back into partnerships and all of those types of things,
but it's a big part of why we came together.
We saw an industry need for that complexity
management moving up, we're not moving up the stack,
it's a horizontal platform approach, but to really
bring the complexity down, you actually have to bring
the number of layers of software down.
I mean, in order to reduce complexity, reduce numbers
of lines of code, make things easier, right?
So the idea was, working collectively, we make
an operating environment at base principles that have
diagnostics and communications and logging and
all of those types of things that are, you know,
very much base and foundational implementations
of the technology, as opposed to layering that
and then putting middleware on top of that
and putting an application framework on top of that,
really bringing everything down to first principles.
And again, it's not about just integration
with our technology, it's a true re-imagination
of how we actually do these implementations.
It's not like we're just slapping a bunch of stuff
together and saying, oh, here's a new thing.
That's totally not what Alloy Core is, Alloy Core
flat out is a re-imagining of how we work together
not just from a technology perspective,
from a commercial perspective, from a legal perspective,
it's really solving those complexity problems.
It's not just software.
Okay, so you said the F-word, which is foundational,
like, which is what I was gonna do,
because you actually, you arrived at it too,
which is, yes, a different F-word, which is, you know,
but it's-
Oh, before we started, yeah, yeah, yeah, yeah.
No, no, but all this is great,
because that was my understanding of what QNICS does.
It's foundational software upon which your clients,
your partners can build up the user experience,
whatever they want to do, right on top of it.
So at the expense of making you repeat
some of what you just said,
let's shift the conversation to where we're at today,
we're at the second floor of your awesome booth here
in Coral, the new colorway for QNICS as of last year.
What's the big news, Alloy Core,
that you guys are announcing?
What's-
You wanna give a recap of what this is?
Yeah, yeah.
It's a combination of different individual building blocks
we had in the past, and as Justin said,
we encountered the same issues or challenges
project by project for the past 10 years.
And then the idea was born in a sense,
we don't wanna solve the problems
on a project by project by project basis,
but come together in a more act as a single company sense
to provide a solution,
which blurs the boundary of the building blocks.
Or in other words, having just one foundational layer
which is optimized to a maximum,
so to squeeze out the last bits of performance,
not optimizing to five, 10 percentage,
but really go into higher two digit,
even three digit numbers of optimizations.
So like we have been optimizing ourselves
for the last five years, but we came to an end.
So like every individual company optimized
and optimized and optimized,
but we didn't make big steps forward.
It was too small.
And by coming together, alloy core as a new product,
the new joint product,
it blurs the boundary of optimizing building blocks.
So to have a single foundational layer
optimized to our customer needs,
not in a sense of the functions or the things on top,
which is really customer perceivable,
but relieving them from the pain of integration,
safety certification and everything,
which is, sorry, again,
the underwear, which needs to be done,
but our customers should focus on doing
what really matters for your customers.
So like an OEM should focus on what matters
for the car drivers.
We are focusing on what matters for the OEMs
and for the T-1s.
I think a lot of SOPs,
they spend an awful lot of time
on the integration of those foundational components.
So the idea here was we are going to define,
very tightly define what a foundational component looks like.
We don't want to increase a vertical stack.
We don't want to say we want to replace your middleware,
we want to replace this, we want to replace that.
We want to be able to inter-operate
with a middleware selection.
We want that ultimate flexibility.
Customers want to be flexible
in their technology decisions.
Really with alloy core,
it is very foundational and fundamental things.
It's the OS, it's a hypervisor.
It's diagnostics and communications.
It's-
What's a hypervisor?
It's the second time you said that.
Sure, yeah, no problem.
A hypervisor is a virtualization solution.
It allows you to run multiple operating systems
on one piece of hardware.
Okay, okay, okay.
So from a desktop perspective,
VMware is a high level type two hypervisor,
but our operating system,
our hypervisor is built on top of our operating system
and it allows you to build a cockpit.
So you want to have a safe cluster,
but you want to have Android infotainment
and I want one piece of hardware.
You virtualize Android and the hypervisor.
You get that entire Android experience
and then you have the safe cluster still.
So yeah, it allows carplay and Android auto or whatever.
Yeah, yeah, yeah.
I think one point to add is like with being foundational,
there is no need of having different solutions
for different domains.
Like in the past, you have silos at the OEMs
like one department taking care of infotainment
another department taking care of ADAS
another department taking care of chassis.
And by not having a foundational layer,
every department came up with a different fragmented
architecture, a different solution
for the foundational software layer.
And this was a common problem across OEMs.
A common problem.
Okay, so this was a problem you were solving
again and again and again.
It's not, I would say it's a little different.
So like it could work.
Like if all the departments are strong enough
and have strong partners,
they can come up with an architecture
which works for them.
But if you have a more holistic view
from an OEM level perspective,
you are doing three times, four times the same job.
You're integrating an operating system
with a communication stack with diagnostics.
And by the foundational software platform
or called LA Core,
there is at least the possibility to wipe that out
and say, hey, we have one, we are doing the job once,
but we still have the flexibility and freedom
to support the domain specific things
like deterministic communication for ADAS,
like high fancy AI acceleration
and audio video processing for IVI
and all these kind of things.
So we are not stepping on the feet of others,
but just saying you should not,
an OEM or a tier one should not take care
about the same job over and over and over again
for the same tasks so there's a solution necessary.
It basically sounds like you're moving
the starting point much higher.
You're saying don't start here
and all these different teams within the domains
replicate the same work.
Let's just get all that out of the way
and you start right here.
What we need to do as an industry is again,
it's the simplification and the management
of complexity moving forward.
We want to make sure that the really tough challenges
that the OEMs are solving in each SOP,
that's where they focus.
I mean, to correct me if I'm wrong
and I'll use the word distraction,
this type of thing from an OEM in an SOP
is kind of a distraction.
It's nobody's buying a car
because it's the foundational components in an ECU.
Right, right, right.
Well, in some markets I hear,
I hear in China people are very into the chips.
In China they market the car based on
the number of LiDAR sensors, LiDAR sensors,
and how many GPUs it has.
More power no one cares, but oh.
You got the new NVIDIA, whoa.
Exactly.
Okay, well that's great.
So that's a really good, I think,
understanding the foundational software piece
that you guys provide helps us ground this conversation
because we want to talk about,
I think a lot of what you're alluding to,
which is, you know, when we started working
with Blackbrake Unix on our software-defined vehicle awards,
which are happening tonight.
Can't wait.
Yes, we're looking forward to it, a big year.
You know, I think SEV was new to motor trend.
It wasn't new to the industry,
but it was certainly in the last four years,
things have really grown.
It was something that was never discussed in our world.
We didn't, that term was just never,
no one ever used it around us.
It's funny, because we had to decide
whether it was the right term.
Is it software-defined car?
Is it ACEs?
Is it case?
Is it a bunch of these other terms?
And it was really only because a couple of OEMs,
like Hyundai and GM actually had set up divisions
within the organization that use the term STV.
I was like, okay, this sounds like the one
everyone's going to land on.
Anyway, it's long story short.
We're now four years on in this relationship
with Blackbrake Unix, and things have happened.
There's been some, I think, a bigger picture.
We've been tracking some of the big OEMs,
having some issues and rolling out operating systems.
There've been a lot of product delays.
Some of them, it seems to be a lot of German car companies
for some reason that have had this issue.
A car?
But we want to talk a little bit.
We're not going to try to rub anybody's nose in it,
but just to understand what's going on,
I get it, because a lot of this stuff
is flying 30 feet over my head.
When you talk about the complexity that's going on,
but can we talk about, when we talk about
there have been some missteps within STVs,
what would be the first one that comes to your mind, Mark?
Like what's a big one that you've seen
as somebody who's active in this space?
I would say,
believing that I need to do everything on my own.
Like when STV came up, there were some companies saying,
okay, to be in charge of or to have the control over my STV,
I need to do everything in-house.
And not just controlling it, but I need to own it.
I need to implement code and develop everything from scratch.
To my perspective, this is not what STV is about.
STV is about the exact opposite thing.
So like building a stable platform,
you can sustain over multiple years
and just getting updates and updates and updates
without losing your power of innovation
or something like that.
So like, and by focusing on that,
so like if you want to have that kind of platform,
you need to build,
you don't need to build a platform on your own,
but you can rely, for example, on partners
which are doing that.
So as I said before, an OEM should not focusing
to my perspective to build and develop
and implement everything on its own,
but doing it together with partners.
And it does not mean I don't have control over it.
So an OEM can have control, should have control
and an OEM should exactly understand what platform does,
but it does not mean I need to implement everything
from scratch because there's learnings over the past 20,
30, 40 years on software and cars.
Why to stumble over the same pitfalls
the industry has already solved.
So like really having a continuous way forward
from where we are now to an STV.
So an STV is not wiping out everything which is there,
but it's a movement, it's a journey.
It's not a one-shot thing,
it's really a journey towards a software platform development.
I think you alluded to it,
but I'll push the point a little bit further earlier.
You were talking about individual companies
and kind of trying to push that envelope
as an individual company.
We've talked about this a number of times.
I think we've already hit the endpoint
of what any individual company can do.
Really where the next phase of STV is in the partnerships,
it's in how we actually work together
to solve real industry challenges.
So again, we come back to,
STV is a journey, it's a movement,
it's all of those types of things,
but we also can't lose sight of the fact that
there's also non-technical pieces
that need to be resolved as part of
making something like an STV.
What's a non-technical piece?
Commercial engagements,
legal indemnification liability,
all of those types of things.
It's the safety side of things,
the secure side of things.
What happens if there's a recall?
All of those types of things,
like how do those types of things work?
So complexity in STV isn't just technology.
It's in supply chain management.
I mean, there has to be innovation there.
You have to start looking at what does it mean
to manage technology,
not necessarily just parts
and stuff like that moving forward.
It's a different mindset.
That was the key point,
or this is one thing I wanted to add.
It starts with the organization.
So if an OEM is organized like described before,
in the sense of I have a silo for domain A, B, C,
it's very hard to reach an STV to my perspective,
because in that sense,
in an STV, the software platform
and the software development
to some extent decoupled from what your hardware does,
and the hardware means the vehicle.
So looking, I am sorry now for the comparison,
but looking at the phone and at the mobile phone.
Sure, no, no, good, good, yeah.
You have Android, you have iOS,
and basically the software platform
is developed independently of the hardware below.
So you can wipe out the hardware, replace it by another one.
You have still the same software ecosystem,
and you don't want to have five software ecosystems,
but you want to have one.
And therefore, I think it starts,
if you take STV serious,
you need to have a software platform team
in your organization,
which has the power of developing the platform
independently of car releases,
of model releases, of SOPs.
As soon as you bound your SOP
to your software development,
there's something not STV is to my perspective.
Say that again, say that last line again,
that was interesting.
So like, when you bind...
Or if your software development
is bound to releases and SOPs of vehicles.
Start of production, yeah.
Yeah, it's start of productions, exactly.
Then this is, to my perspective,
not the philosophy of an STV.
What would be the correct philosophy for us?
Going with software and start of production.
To my perspective, the right philosophy would be
I have an independent software platform development
with an individual release cycle.
Of course, if a release cycle matches
and a start of production of a vehicle,
great, if not, that's not a problem.
So like, you can update the software platform
on every car, which is out there.
Older cars, newer cars, doesn't matter.
So like, developing the hardware shell,
the complete vehicle, this is one thing.
And developing the ecosystem,
the software ecosystem is another thing.
So this goes back to your phone analogy,
which is perfect, which is, you know,
I've got whatever version of Instagram
it's been updated, I don't even know.
And I'm on iPhone 16, about to get a 17.
I've had 16 iPhones and it doesn't matter.
It all just works.
Hardware gets better independently of the software.
Don't time together.
But it's funny because your clients at the highest level,
all the OEMs, a lot of them are legacy,
most of them are legacy car manufacturers
and they live and breathe by the hardware drop, right?
Like I'm about to go check out the new S-Class debut
in Stuttgart later in January.
And I think they're releasing several all new systems.
You're suggesting is upending that,
which is keep iterating, launch awesome,
super polished software all the time
and then the cars will flow in and have this natively.
But the manufacturers love to make a big deal about,
this is the new flagship sedan from Mercedes-Benz.
There are steps in that path though.
Mark's vision is the utopia, right?
It's the software definition that it defines everything.
It defines the flow, it defines everything.
But at the same time, those five, six new systems,
all of those types of things can absolutely benefit
from a similar mindset.
The idea is foundational software and a platform
that scales across all five, six new systems
so that the innovation and the complexity
is in the stuff that actually matters to Mercedes
for instance.
Or I mean, in software development terms,
you have a mainline development, you have a trunk
and somebody just takes a specific commit
or a specific status, branch it
and then that's version A for the vehicle
being launched in January.
The mainline development isn't stopped by that.
It's not influenced by that, it's just there
and the individual projects, the individual models grab it
and then it's already in the maintenance phase,
let's say.
The trunk, the software development is leading
and it's not necessarily bound to,
hey, there's another carline coming up
so I have to stop and redevelop things.
No, the carline is adopting and taking what's being there.
I think the phone analogy is great
when you're talking just about software
but we also have to consider what this is.
It's not a phone, right?
This is something that's rather large.
I knew that you were bringing people.
Right, much more dangerous too.
Little dangerous, yeah.
So the idea of that software flow
and just picking and choosing is great
but there's a safety thing that we have to consider as well
and there's a ton of complexity in that
and again, that's why having multiple companies
coming together makes a lot of sense
because we're creating those safety artifacts
for those integrations to say it's already done.
Just focus here.
Could you give us some examples of that?
Yeah, sure.
If you take a look at,
I'll use a specific example of something
that we had to deal with in the past.
It's a little bit in the weeds
but we put out a safety manual.
Here's how you use our product in a safe manner.
Vector puts out something.
Here's our safety manual.
Here's how you use our thing in a safe manner
and then we have conflicting requirements.
And that happens, it happened once I think.
It was an exception thing.
But it's a good example because this is something
which differentiates the automotive industry
from the mobile phone industry.
We have to make sure that we're taking advantage
of the collective knowledge of the industry
to make sure that we're solving these types
of integration problems as well.
We want to make sure that there aren't any guesses.
Safety can't be guesses.
Security can't be guesses.
Safety from a life perspective,
security possibly from a revenue perspective.
The whole idea is making sure
that we're protecting businesses, people,
all of those types of things.
So having those tight relationships
and being able to have our safety organizations
come together and say, no, no,
this is how this is going to work moving forward
so that we put one set of argumentation together
to say, and this is how this whole thing works now.
Don't worry about all of these things,
just follow these steps, use these APIs, innovate.
And I think that's to put it maybe in one sentence.
We want to work or we want our customers
to work like in the smartphone industry,
but still having safety, security,
and everything covered, which is the add-on,
which is not there out of the box.
So this is the differentiating factor.
So adopting modern software development practices
work like the smartphone industry
without losing the other properties
we definitely need in the automotive environment.
I want to go back to something you said at the outside,
which was the main issue seems to be
a lot of these companies trying to do the SDV themselves,
like do the whole thing.
Is that tension from this idea of vertical integration?
A lot of these car manufacturers,
maybe they want to follow somebody like Tesla,
Johnny and I just went to Rivian's Autonomy and AI Day
and they talked about how they're going to start doing
their own silicon.
Or can the two, these two ideas coexist, right?
Maybe it's also a little bit our fault, I have to say.
So the automotive industry in the past,
like in the traditional supplier model,
the turnaround times were far too long.
So like if there's something at the OEM discovered,
an issue, an additional feature,
no OEM or customer needed to write a spec,
pass the spec, spec is analyzed,
if it's implemented, it's going back.
It was implemented wrong, surprise, surprise.
So another circle.
So like, I think this is a lot of the reason
why OEMs are pushing for vertical integration.
But this, to my perspective, does not exclude
the partnership model or the cooperation model,
because if you find other ways of cooperating,
not in a classical OEM supplier model,
but more in the partnership model
like the two companies of us do,
then this is absolutely possible
and we are in favor of doing so, of course,
in that kind of partnership scheme.
So having the properties of agile development
and fast circles without having the need of doing,
having the need for doing it on your own.
So like this is not, coming back to your question,
sorry for that, it's not excluding each other.
So like the two philosophies can coexist
and can maybe even outperform the individuals.
At the end of the day, the most important thing
is time to serious production, right?
The car needs to roll off of an assembly line at some point.
So what's the easiest method?
What is the easiest path?
It's not necessarily doing everything yourself.
It may feel like that is the quickest path.
The OEMs do spend an awful lot of time
in serious programs doing supplier management.
Where, this doesn't happen with us ever,
but I'll use it as an example.
You've heard about it in the initial, yeah.
Mark'll point at me, I'll point at Mark,
and then somebody has to, we pointed somebody else,
and then the OEM has to do that management
and really mitigate those risks.
Back in the days, I'm sorry to say that,
but it was like this.
In the first projects, it was exactly like this.
So like an OEM, an orchestrator taking care
of supplier A, B, C, D, passing tons of specs,
and that scheme broke up, I would say.
And that's why, again, it's not necessarily SDV
and partnering and all those things,
it's not just about the technology,
it's about solving real industry challenges.
One of those industry challenges for time to series
is the management of the suppliers.
If we can take that off of the mind
from an OEM's perspective, they can focus other places,
they can move quicker in other places,
all of those types of things.
So, me as an engineer, I keep harping
on the non-technical stuff, but you can't understate
how important those less technical things are.
Yeah, it's kind of like the age-old argument
to like math and liberal arts, right?
Like the engineers love, hey math, man,
you run a formula, you get one answer, and that's it.
But all this legal stuff, it's gotta go,
someone's gotta read it, somebody's gotta mark it up,
send it back, nope, overruled, come back,
and it's just like one path, very clear,
you can plan around it, all this other stuff, HR, legal.
And including compliance, which is something
I wanted to talk a little bit about.
So, you know, we did a little prep work on this.
I've learned a lot about ISO 26262.
I understand there's a cybersecurity framework,
ISO SAE 21434, that works with that one,
but you guys threw me a curve ball
with the Cyber Resilience Act,
which apparently is coming to play in 2027.
So it's something everybody is sort of
what frantically working on right now.
And this is an EU.
Can you explain what this, two questions,
what is the Cyber Resilience Act,
and then how is it not already covered by ISO 26262
and 21434, and then how do you guys play,
like how do you handle this?
So in trying to be as simple as possible,
you have to be able to react on cybersecurity issues.
With everything you need for that.
So like you need to detect cybersecurity issues
and the more you need to be able to react on
and provide updates.
So like you need to manage your cybersecurity system,
your cybersecurity relevant system.
And the ISO 21434 is kind of the process descriptions.
So like there are recommendations in there
and there are kind of, you need to assess your system.
Where are your threats?
So like in a safety you have a hazard and risk analysis,
there's something similar for a threat analysis
in the cybersecurity space.
And yeah, you have to comply to that
in order to get the type approval in the EU.
So let me reframe.
So ISO 262 is functional safety.
It's all the stuff in the car, breaking, the lighting.
So again, 26262 isn't a prescriptive standard.
This is what your processes should look like.
Here are the outcomes you need.
If you want to claim that you meet this criteria.
Yes.
I mean, you go to an assessor to get that external,
but you don't have to.
And then 21434 is similar, but for cybersecurity.
Yeah, so it's a cybersecurity management standard,
let's say, it's how you manage
and what do those processes look like.
And then you get those processes assessed by an assessor
to get your CSMS, or your ML levels.
If you're a car manufacturer that you've thought about
all the different cybersecurity threats
and access points in this now, right?
And there's one, I want to freak everybody out, right?
Like if you have a new car and you got a USB port in it.
Right.
That's an access point into your car.
Did somebody at that car manufacturer think about that
and plan around it?
That's what this standard would be.
So Mark mentioned it.
So the industry is very much used
to the hazard and risk analysis
or the HERA from a safety perspective.
It's done vehicle down.
TERA, the threat analysis.
It's something that is now part of 21434.
It does, the vehicle does have
to have a vehicle level TERA as well.
And that those requirements will flow from vehicle
to vehicle network, to groups of ECUs, to ECU.
So somebody actually has, and we as software providers
or technology providers have to be able
to provide our assets into those analyses
and into those to say, once you get to this level,
don't worry, I got this.
Here are my requirements.
Here are what we, this is what we do.
Here are all of my claims.
This is my safety case.
This is my security case.
Here's how you use this box of tech
in an appropriate manner.
Here's the certification and the artifacts
to go along with it.
Here's how you feed into that much larger
threat analysis.
To name a concrete example,
like on a vehicle level, you're in the first place
treating it, or you could treat it as a black box
and have all the interfaces exposed to the outside world.
USB interfaces, Wi-Fi, Bluetooth, whatever's in there.
And then it's broken down.
And at the end, what the both of us are taking care of.
For example, how to store secrets securely.
So how to store keys, how to encrypt messages,
how to secure your diagnostic support that nobody...
Your face ID, like a lot of these cars now
are scanning your face every second
while you're driving, right, like all that stuff.
Exactly, or your cloud data, everything.
The music you listen to.
Again, providing the infrastructure of making it secure.
So we can, with our system,
we cannot make the vehicle secure,
but we can provide the infrastructure for an OEM,
for a customer to store the keys, to encrypt stuff,
to prove integrity of messages and these kind of...
It's slotting our technologies, collectively,
and our artifacts into that much larger vision
from a safety error.
And then CRA, the Cyber Resilience Act,
that's essentially law in the EU
that manufacturers who wanna sell in the EU have to meet.
Yeah, okay.
And that comes down to timing.
It's the react part of everything that here.
So the resilience act is necessary.
You have to follow the resilience act
to get a type approval
and it more or less says, similar to safety,
in order to get type approval,
you have to be state of the art
for cybersecurity management.
And the ISO 21-434 is considered to be state of the art.
So like the legislative part,
it's the resilience act
and the guidance for the industry is the ISO.
So in other words,
if the OEM's using the services and software
you guys provide,
they're already in compliance with the act.
Well, they're in compliance with our technology.
So then they have to feed into there.
The card you're giving them is in compliance.
That's our technology's in compliance,
but our technology doesn't build the whole.
Right, they still have work to do,
but you don't have to worry
that they're getting software
that won't comply with the resilience act.
But you're global players,
you support manufacturers in Europe, in the US, in Asia.
So then how do you handle CRA?
It's not a US standard,
but the parts you provide,
ideally we'll-
To Mark's point,
the CRA is the legislative part of it in the EU.
What I can provide as a technology provider
is state of the art cybersecurity for my software,
which is 21-434.
So I mean, we are ML3 certified, for instance,
from our cybersecurity management system
and all of those types of things.
So we can stand behind our customers claim.
Okay, all right.
So it's not a hurdle per se because you're already-
It's, I'm not gonna say everything is solved.
There's always challenges, right?
So-
And then there's things coming up.
We are talking about intrusion detection systems.
We are talking about stochastics in the communication,
so anomaly detection in the communication.
So like starting, security started back in the days,
I would say with diagnostics.
You're right.
And secure access to diagnostic services for a car.
So like not make your brakes bleed
on the highway, for example.
But there's more and more state of the art
known from cloud computing,
known from the office or IT industry.
It's moving over to the in-vehicle parts as well
because more or less the in-vehicle-E architecture
is like a network on its own
and you can really compare it also
from the security measures to what you have
in the IT industry.
And the performance is creeping up in the hardware
that goes into a vehicle today, right?
So you can do a lot more.
I'm gonna ask you that.
Like just fundamentally like,
how much more complex can vehicles get?
Like when you're looking forward 20 years,
like how much more are they gonna do
than they're able to do now?
That's a great question.
I hope from a complexity management,
not more, but hopefully even less.
There's a chance that it might become less complex.
I think from a functionality perspective,
getting more complex, or it gets richer,
more functionality being added,
but this must not lead to more complexity in engineering
because otherwise the industry is not able to handle it.
Oh, okay, wow.
Yeah, so again, at the end of the day,
what we need to do is make sure
that we can provide a level for the innovators
in the industry to innovate
without really creeping up the complexity
of the systems themselves.
So we need to make sure that everything is feature rich.
I mean, cars can do a lot of things today, right?
I mean, use your imagination 20 years
so now they can do a lot more things.
Well, that's a good point, yeah, but like, you know,
again, back to this Rivian day, we went to, you know,
okay, by 2028, you'll have like level four autonomy,
eyes off, you know, point to point driving around,
plus you'll have full AI, like I'm not really comfortable
in my seat, adjusted so I'm comfortable,
you know what would make me comfortable, yeah.
So you can do all that, like what else?
What else, I mean, you must have be talking to OEMs
that are like, hey, we want flying,
you know what I'm coming for.
Let's let them think about it
because I wanted to close on a similar question,
but to the point you just raised,
General Motors late last year,
announced that they're going to have hands off,
eyes off, essentially level three autonomy
in the Cadillac Escalade IQ,
it's our current motor turn SUV of the year,
by 2028.
Several other manufacturers
are also seem to be soft circling, 2028.
Keon Hyundai said 2028, Rivian said basically 2028
for level four.
Is that, from where you guys sit?
First of all, do you believe it?
Is this believable?
Is it, are you guys like, yeah, that's going to be,
it's going to be great, safe, we see the future
and 2028 is when, and when we say hands,
because you know, the car manufacturers
and the marketing speak, they don't want to say level three
because the consumers don't know what level three is.
Hands off, eyes off means, like currently when I drive,
if I'm FSD or if I'm super cruising,
they're on supercruise, blue cruise,
Hyundai Drive Assist, I can take my hands off the wheel
on certain mapped roads, highways, mostly.
But it stares at your eyes.
And it's looking at you.
FSC's the same way, but you can do it on city streets,
but there's a little camera watching you
and the minute you look at your phone
for more than like 10 seconds,
it starts telling you, get your, pay attention.
In a hands off, eyes off world,
theoretically you could be watching a movie,
pull up your phone, you could plan on Instagram,
close your eyes, take a nap.
2028, that's two years away.
Is that, is this, you guys see this as reality?
I do not have a crystal ball.
It's not a question that I'm going to answer.
Okay.
Okay.
Good, good.
Mark?
I may be more the optimistic guy.
So I think it's, it's, it's realistic.
From a tech perspective, absolutely.
The text there.
Oh.
The text there.
So the holdup is legal?
The holdup is.
I think so.
And the operational design domain.
Operational design.
Okay.
The question I asked one of the GM guys
who left the company shortly after this question,
I'm not sure it was my question.
It was Bear Satnok.
I asked him whether GM system is going to allow
drivers to go over the speed limit.
And he's like, no.
He basically said no.
But I was like, that's insane.
Because if you go on to the, I'd FSD'd here
at 80 miles an hour.
That was breaking the law.
I don't know how Tesla does it, but you know, I think.
I found spicy mode on the Rivian.
They're, they're, they're spicy, spicy.
These are the questions.
It lets you set the cruise over.
Right.
These are the questions I think.
I, I understand your.
So I, the reason why I'm hesitant to answer
a question like that is I fall back on the,
my safety pedigree.
Right.
And it's very difficult for me to,
to say that that's going to happen.
We've also heard, we've also heard that that was going
to happen in 2015.
In 2020.
That's super fair point.
That's a good one.
I remember, I remember it was like 15,
16, I went to some BMW thing and it was,
they had a lot of engineers there and they're
talking about autonomy.
Cause it was real hot with Wall Street,
autonomy, autonomy.
And they were just basically like like not,
not anytime soon, but that was over a decade ago now.
And it seems to be soon.
You are seeing there, there are two German
manufacturers that have systems out there today.
Well, Mercedes is at level three on sale since
the end of 23 in, in California, Nevada and,
in Germany, I believe.
And I might have changed.
I haven't really been following, but yeah.
But yeah.
And I think there's a big difference
between 10 years back and now.
Yeah.
Absolutely.
10 years back, there was more or less no
ADAS at all.
And then there was, hey, we are going for level
three, level four, level five.
Without, without, without those,
the intermediate steps of ADAS.
And we are again, like for STV,
also in the ADAS environment,
to my perspective, we are on a journey.
And journey started from level two,
to level two plus, to level two plus plus,
the three systems are out there now.
And maybe there is not a level three,
level four system in an affordable manner
because that's the next factor.
You can see Waymo.
You can see the others.
You can see the Amazon.
Yeah.
Sooks.
Sooks, you can hail right now for the show.
And they are working,
and they are working incredibly well,
but from a commercial perspective,
to put that in a private car, different story.
So like, I believe we will see more
and more level three systems.
And we are involved in some developments going on,
but they have a clear ODD in the sense of,
hey, you're entering the highway,
then you're engaging the system.
And as soon as you are about to leave the highway,
take over again.
I think these type of systems
are really coming up by,
I don't have a crystal ball either,
but 28, 29, 30.
We're just going off, like again,
Rivian last two weeks ago, whatever it was.
Three weeks ago.
Three weeks ago said, okay,
we're going to have eyes off,
which I interpret as level three.
We're going to have eyes off point to point,
some other words.
Once you buy the car with LiDAR,
it'll just go, it'll follow the maps
and it'll work on any highway that has painted lines.
It's not freeways.
You can go travel around back roads
as long as there's a painted line
and something can see the painted line
in the camera or whatever.
And they said that's at the end of 26.
And they showed the car,
they had the physical car sitting there.
They said, these are the chips we just produced
and they're in this compute box
and this is in the vehicle.
You might've moved a lot of their dates up a little bit.
No, I remember they said,
Do you work for them?
They're going to freak out.
No, we were just there three weeks ago.
No, I'd pay them actually.
It'll be paid off soon.
But you know what I mean?
So that's just, I was like, okay.
And they said then like the,
what do they call it?
They called it L4 personal.
So in other words, I'm going to sit on my couch
and doom scroll, go pick the kids up from school.
That's coming with another generation of chips.
Can I ask you guys a question?
Yeah.
Oh, of course.
So do you think the general market
is ready for something like that?
Yes.
The general market.
What do you mean by general market?
Everybody specified.
Like do you mean, do you mean level three
or level four?
Three.
Safe.
Hands off, eyes off.
Everyone's texting constantly.
Yeah.
They're more than ready.
Yes.
With reservations, like I showed,
we have a,
Motortran has a Tesla Model Y with FSD.
I've been kind of raving about it with the staff
because version 14 is way better than V12, V13.
I did show my parents.
They're 80.
And I, they were like, what?
Like, and then, you know, that hurdle of,
I don't have to do anything.
I'm like, no, watch this.
And, but watching them get used to it very quickly,
I think is that was sort of the key point where I'm like,
I think when this thing becomes more broadly available,
I think you'll see adoption.
Now, having, I've done over a thousand FSD miles
and when I'm not in a car that does that,
I'm a terrible driver.
So that's where, that's where I think.
That's an interesting side point to this is,
at what point do we forget how to drive?
Exactly.
And I think that's going to accelerate the demise
of driving.
That's another episode.
And I think another point is you have to experience it.
Yes.
So I was skeptical as well, I have to say.
Since I've driven one or a few in back in California,
the first ride is scary.
The second ride is maybe okay.
And you get used to it so fast.
Absolutely.
Yeah, absolutely.
Well, we've got, LA's become, you know, Waymo Central.
Like there's, I think there's,
I think the total Waymo fleet deployed is 2,500.
I think 1,500 are in Los Angeles.
They're everywhere.
Seems like they're everywhere.
And I've been taking them and it's like,
I didn't think about it.
I just get in and it's great and just works.
I did the same in Phoenix.
Yeah.
The most interesting thing I had heard recently, again,
and we keep going back to this Rivian A autonomy day,
but we talked to James Philbin.
He leads their ADAS and autonomy and AI team.
And he was at Waymo and Google is and I'm sure
you know him.
You know, he posited that the arrival of full autonomy
is not going to lead to what everybody thinks,
which is we're all going to own robotaxies
and they drive us to work.
And when they don't park at work,
they're going to make us money.
And I was, I was like, what?
Cause every, all the McKinsey guys,
all the consultants are like,
this is going to be a huge unlock,
no more parking structures, no more parking lots.
It's going to go out and deliver stuff
while you're working.
Exactly.
And I was, he was so, and he was,
I don't want to say negative in a hard way.
He was just like, no, no one's going to do that.
He's like, let me ask you,
do you want to go have to go back and clean up your car after?
Think about what you've done in taxis over your life.
A dozen strangers have been in it.
Like, are you going to want to have to manage that?
Or what's the insurance going to look like?
And I hadn't thought about the opposite side
of this utopia of autonomy,
which is that, yeah,
maybe you don't want people in your car.
Like, you guys, I don't.
I don't even want my wife,
I don't want my wife in my car, you know?
Just trash on everywhere.
So yeah, no, definitely not.
Well, we're running out of time here.
And I do want to talk a little bit about that
because we, this is a great segue
because you brought it up earlier.
So we're talking about the future.
We've talked about the regulatory issues in STVs.
We talked about how the products you guys are making,
alloy core in particular,
are helping manufacturers get there faster.
What is there going to be, right?
We've sort of rift a little bit on autonomy.
One thing I saw very recently is augmented reality
is now coming into the cars in kind of a big way.
Audi has a really great system.
They're putting directions, the arrows,
the fixed upside on the side.
BMW and Mercedes are doing it, yeah.
They're doing it, but I think Audi's is really cool
because they're also sending the directions
into the headrest speaker just for the driver.
It's like it's in your brain, you know?
It's very, it's very cool.
I would still turn that off, but yes.
So digital cockpit, it obviously is a big domain
that is being developed.
AI, and we didn't even talk about AI assistance
and how those are coming online.
This is a refreshingly AI free conversation,
I will say.
I appreciate it.
Up to now, huh?
Well, yeah, so let's take it, what do you guys see?
What's on the road map?
What's on the product road map
for some of these big companies?
Stuff that the listeners, the people viewing
should pay attention to, do you see?
I mean, if we look shorter term,
a lot of people are looking at solving
a lot of the time to series, time to market challenges.
So it's safe, secure, faster.
So what does that look like?
And it comes down to platform design.
How do we leverage that horizontally?
And then how do we scale that internally?
Not we, we as an industry,
not we as QNICS and Vector, but we as an industry.
I'm gonna stay away from specific features
only because I don't have that crystal ball
and I don't want to out anyone in particular.
But again, it's about fundamentally understanding
the real industry challenges that exist today.
And it isn't just features.
It's how we work together as an industry moving forward.
And I think that's going to be one of the biggest things
that needs to be solved in order for
all of the crazy things that you saw at the AI days
and everything that everybody's talking about,
how AI is going to do everything for us.
And all of those things.
Well, they were touting, Rivian said we're no longer
SDV, we're AI.
In video, so that's it.
Everybody, that's the new thing.
Yeah, and I was like,
there's SDX and then there's a...
Well, let me ask you specifically
about the speeding this thing up.
Is how much of that is driven by the term China speed?
Right, is that...
That's come up a lot over the last 18 months to two years.
Are they setting the standard for time to market,
for products and features, would you say?
They are accelerating pace, absolutely.
Okay, and is it all good though?
I mean, I think some of the things
falling off the wagon.
There's a market acceptance in updating software,
in certain markets, so.
And there is the, yeah, maybe just rephrasing what you said,
they are, the market there is much more open to,
let's try it out.
So like they are not expecting,
they're ready to go 100% tested, safe, validated product.
They're just saying,
hey, that's an awesome technology,
I want to have it, if it's not working,
let's get an update.
So there's not a hesitance of adopting new things,
I think that's what's differentiating.
In the US, I was sort of like Tesla early adopters,
we're fine with, oh yeah, I'm just beta,
it's beta, cool.
And they were kind of tech enthusiast,
but like most consumers, I just spent a lot of money,
I don't want beta, I want alpha, you know, finished.
I mean, especially in Europe or in Germany,
I mean, privacy, data production.
There's a lot of things and this is not
in their heads at all.
So they are not making their minds.
So this is also what, to my perspective,
accelerates the development.
And another point is mostly,
we are at the turning point right now,
but up to now the Chinese OEMs mostly started
on green fields, they didn't take care
about let you see too much.
And I think that's also a game changer.
If you have big plans and big process,
everything established like the big American
or European OEMs compared to,
hey, I'm starting everything from scratch.
Of course it's easy, sorry,
easy to build something from scratch.
It's like building a new house.
You have an architect, you can put your cables,
your plumbing, everything like you want to have it.
If you are going to remodel or renovate your house,
you have to take care about certain things.
And if they start taking care about that,
the question is, will they do so or not?
And not just that there's pure startup from zero,
but they also are typically one powertrain,
one or two types of powertrains.
And the OEMs here have to worry about
internal combustion, hybrid, now EREV and EV,
and how to sell it.
I mean, I was with Gile yesterday driving a bunch of stuff
and like the Pure EV, hybrid, mild hybrid, EREV,
and they had a two liter turbo.
It was like they had nine different cars.
But I'm a strong believer in simplification
and in getting rid of variants.
I think the classical, maybe European,
specifically automotive industry and OEMs,
they overshoot in terms of what you can configure
and how you can assemble.
Oh yeah, sure, millions, millions, yeah.
And to get rid of that part of the complexity,
I think that's necessary.
And I think to my perspective,
maybe that's a personal opinion,
it doesn't harm too much.
So if I'm going to buy a new car,
I'm kind of really eager to get a setup
and configuration fast.
And I don't want to click in the configurator
about one day to get the last option.
And if I click to that option,
then I have to select five other ones.
So I'm getting rid of that kind of philosophy.
Depends on the market.
I think depends on the market,
or the segment of the market.
Because there are certain cars, like a 911,
that's the joy is like,
it's like yellow deviated stitching, you know, yes.
Oh, I thought you were talking about performance modes.
Because we had this argument
where CTS-Vs and BMW M cars have too many performance modes.
Not enough, yeah.
You got to play with the rat tuner.
No, no, no.
To play with the rat tuner.
Yeah, yeah, yeah.
Not enough.
So, okay.
Well, let me not,
let me give Mark a chance to just answer that question.
Is there any particular feature or category
or domain that you're particularly interested
that's coming in the near term?
To me, it's really like
what the software defined vehicle ends up with.
So what's the next step in terms of software defined vehicle?
I fully acknowledge there is the infotainment stuff going on,
there's the ADAS stuff going on,
but sorry, Justin, for again,
bringing the smartphone on the table.
But wouldn't it be nice if I just buy a new car,
park it next to my old one,
it's transferring all my properties
and every app I have downloaded
and I get the same experience just in a new shell.
So like-
Yes, that'd be great.
This is something I would understand
from an STD perspective.
Oh, wow, yeah, that would be cool.
Utopia.
Yeah.
Well-
That's the thing, if we're protecting where to journey,
it can lead us to-
Yeah, yeah, yeah, okay.
Just so I can anger Johnny,
but also check the box.
I do want to touch lightly on AI.
Are you guys using it?
Of course.
Are you, is there,
obviously you probably use it for work and for play.
Is there, I like to give the viewers,
the listeners, something actionable.
Is there a particular app
or GPT or LLM
and or tool within
that you would recommend people play with?
Like I, for instance, I asked this
of a South by Southwest last year
and somebody said to go use a Google notebook
and you'll take your, turn your notes into a podcast,
which I was like, that's wild.
Is there anything in particular?
Are you guys using it to write emails?
Is there-
Engineers typically use it.
So I mean, I'll answer it in Justin's work voice
and then I'll answer it in Justin's personal voice.
Justin's work voice, we're leveraging AI
from a software development,
life cycle, acceleration type of thing.
We're not using it to write code.
Not vibe coding.
Of course not.
Again, I built safe and security software.
But what we do use it for is what we call
that 20% lift that takes 80% of a developer's time.
Right, right, right.
Code reviews, that's documentation reviews,
that's all of the circular conversations
around what a requirement should look like.
Leverage a large language model or direct to the AI
or a Gentik or whatever you want to call it
to do the first pass of a code review.
Like we have internally, we have our own system
that leverages multiple models
and we have some extremely intelligent people
that are stitching a lot of these things together
that I could pop a merger quest up into Git
and say go off and do my code review
before I give it to humans.
And it will come back with everything
that's ever happened on a similar piece of code
saying maybe you should look at this
because Sally said this about a code that looks similar
to this and Bobby said something like this.
So just taking history and 45 plus years of software
and applying it to that one merger quest
or that one documentation review
so that you take advantage of the history
that existed previous instead of having
those circular conversations and arguments around
well, this should be a comma.
Like just stuff that just takes up far too much time
from a developer perspective.
Personally, I use a number of different applications
from an AI perspective, but I use it primarily
for things like diagnosis for my vehicles
and stuff like that.
So I use it literally as an assistant
not to write emails and all of those types of things
but that's a weird noise.
What does this sound like to you?
Perplexity or which one are you?
I've used perplexity, yeah.
But stuff like that, I mean it's more,
I'm using it in my personal life to play more than.
Got it, right, right, right.
But at least in work, it truly is an accelerator
from a development and a developer perspective
but it's not in the write my code for me.
Not test this for me.
At the end of the day, we want to be able to use AI
to do what it's good at, it's recognizing patterns.
It's crunching large data sets very, very quickly
to find anomalies, to find similarities
and all those types of things.
That's what we internally will be using it for.
Now, we're an operating system company,
we're an operating environment company
and when we start talking about in-vehicle,
what we want to be able to do
is provide a highly-performant environment
for people to leverage AI models through accelerators,
creating those safety paths
so that you could potentially use an AI accelerator
in the future in a vehicle and safe handers
and all of those types of things.
Okay, same question to Mark.
Okay.
Like, our developers are, in the past,
they wrote 20% of their time code
and 80% of their time was documentation and whatever.
I think it's pretty common in the industry,
that's that 2080 is...
I want to flip it.
All right.
It's not, we did the mistake by ourselves
and then say, hey, let's start with code assistance
but you're optimizing 20%,
your leverage is much higher
if you're optimizing...
Absolutely, that's interesting.
Sure.
...actual coding
and then what Justin said,
code reviews and all these kind of things
plus workflow assistance.
So like how to optimize internal processes.
This is also another area
where we are applying AI for.
Okay, and personally, any fun things?
Personally, as an assistant, so not writing emails
but getting summaries of emails.
So like if you get lengthy emails
before reading everything,
let's summarize it.
You know, now I'm going to bury random stuff
in an email to Mark just to see what happens.
Or just like using it as an assistance
also in product management.
It's really like, okay, how does the market look like?
Where are the competitors?
What kind of solutions do you see?
What kind of solutions do you imagine?
So it's not the ground truth
but it's a valuable input.
You can broaden your scope,
you can broaden your mind.
So like that's where I'm personally using it.
Oh man, he said ground truth.
Now I don't want to see a bunch of ground truth questions
but no, we'll leave it at that.
We're out of time, but this was...
That was fun.
Thanks guys.
Great conversation.
Inspiring talk.
Thank you very much.
Thank you so much for your time.
Have a great CES.
Thanks.
You too.
It's only going to get crazier from here.
I'm looking forward to tonight.
Yes.
Motor Trend, SDV Awards tonight.
Thank you.
We can see all about our SDV Awards
on MotorTrend.com.
But thank you for watching.
Thank you for listening.
Thank you to Justin Moon,
Vice President, Core Product Engineering, QNX
and Mark Weber, VP of Product Management
and embedded software and systems at Vector Informatic.
It was awesome to chat with you guys.
Thanks guys.
We really appreciate it.
Thank you guys.
Thank you.
Thank you.
About this episode
A deep dive into the complexities of software-defined vehicles (SDVs) featuring insights from Justin Moon of QNX and Mark Weber of Vector. The discussion covers the importance of foundational software in automotive technology, the challenges of integration, and the need for collaboration among OEMs and suppliers. They introduce Alloy Core, a new platform aimed at simplifying automotive engineering and enhancing safety and security. The episode also touches on the future of autonomy, regulatory challenges, and the role of AI in streamlining development processes.
Original notes
Live from CES, MotorTrend’s The InEVitable sits down with Justin Moon (VP, Core Product Engineering, QNX) and Dr. Marc Weber (VP, Product Management, Embedded Software & Systems, Vector) to unpack what it really takes to build software-defined vehicles—without drowning in integration complexity.
They explain why “doing it all in-house” can slow OEMs down, how Alloy Kore aims to reduce duplicated effort across vehicle domains, and why safety and cybersecurity can’t be guesses—especially as regulations like the EU’s Cyber Resilience Act come into focus. Plus: a plain-English breakdown of hypervisors/virtualization, SDV org structure pitfalls, and what the path to faster, safer series production could look like.
The InEVitable
MotorTrend
0:00
67:16