From CES: Solving SDV Complexity With QNX + Vector’s New Alloy Kore Platform

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.

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.

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.

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.

From CES: Solving SDV Complexity With QNX + Vector’s New Alloy Kore Platform

About this episode

Ford Model T

Mercedes-Benz Sclass

ECU

Android Auto

CarPlay

ADAS

OEM

LiDAR sensors

GPUs

vertical integration

Rivian

silicon

level four autonomy

AI

level three autonomy

Cadillac Escalade

FSD

Super Cruise

Blue Cruise

Hyundai Drive Assist

Tesla Model

version 14

augmented reality

Audi

internal combustion

hybrid

EREV

Porsche 911

Bmw M

Cadillac Ctsvs

Request an Explanation

Want to learn more?

Help improve this episode

More from The InEVitable