(upbeat music)
- Hi, my name is Kurt Niebuhr.
I am a principal PM on the Azure HPC team,
I spend a lot of my time working with automotive customers,
specifically on the autonomous workloads,
and have been asked today to talk about some
of the cool stuff we're doing in this space.
First, people always ask,
"Azure, why are you even in this space?
You know, you're not making any autonomous vehicles."
And actually, because we're not making autonomous vehicles,
that's exactly why we're in this space.
We see autonomous driving as
the ultimate AI problem,
But more than that,
autonomous driving represents a shift
from a mechanical engineering-centric workflow
to a software-centric workflow,
and we, Microsoft, see ourselves as a software company
and a software platform that is very much focused
on enabling our customers' partners
to do this digital transformation,
and that's exactly why we're in this space.
In other words, we are very much focused
on using our platform to help customers basically make
some of the coolest things on planet Earth,
inclusive of autonomous vehicles,
and that's why we're in this space.
But having said that, autonomous driving is
a tough problem to deal with.
You're basically trying to solve
the largest AI problem that mankind has
tried to tackle to date.
You have a bunch of sensors packed on a car
that have to perceive the world around it.
They have to follow policy like following,
with a car, a certain distance in front of them,
not hit people, process all this data, and
make decisions in near real time.
So training that autonomy stack basically requires
our customers to be able
to do three things very well at scale.
First is they have to be able to scale
their CI/CD pipeline-Azure DevOps.
Second, they have to be able to scale their AI training,
which is basically what we call MLOps.
And third, and this is definitely where
our partner ecosystem plays a key role,
is you have to be able to scale your validation pipelines,
and last but not least, you have to be able to integrate
your DevOps, your MLOps, and your validation pipelines.
So basically the swim lanes of all the different engineers
all collaborate in a very meaningful way to
bring these products to market faster.
So the autonomous driving end-to-end workflow
is a very complex workflow.
We call it the "data loop," where you basically start
with test vehicles. You'd probably see them driving
all over the streets,
see a signal like the Lidar on top with a big camera,
kind of drive it around.
So it starts with those test vehicles.
We pull all the data out of those test vehicles,
then we have a series of very large compute jobs.
And then at the end,
you need to send out the updated software and algorithms
back out to the vehicle for more tests.
So because you start with a vehicle,
it goes back to the vehicle.
We call it the "test loop."
So we basically look to support that end-to-end workflow.
So today I would like to discuss
where we think we're very differentiated
in some of the compute-intensive aspects of this.
I would like to say, though,
we are also extremely strong in some of the other aspects,
for example, DevOps,
and then some of our storage solutions in this space.
But seeing how I'm on the HPC team,
I'm going to talk about
some of the cool stuff we do in the compute space.
So, first, I think one challenge
we're very much focused on nailing
is what we call "resimulation" or "recompute."
Resimulation and recompute is probably one
of the more challenging jobs to figure out how to do,
because very often customers use either a very specific
or custom application or an application
that is supplied by
the in-vehicle SoC (system-on-a-chip) company.
So like something from Nvidia or Mobileye or Qualcomm,
and they basically have to recreate and assess
what happened in the test vehicle.
So you basically have to take all this data out of the car,
and it's this really large embarrassingly parallel test,
where you basically score the performance
of the test vehicle during the test drive.
The reason you want to do that,
and you want to be able to do that really accurately,
is because you have to figure out
what software or what AI algorithms need to be updated.
However, it's key to point out
that you're not really doing anything new
or adding any new capabilities
to the car as a part of this job.
You're simply saying, "Okay,
did that test drive go well?"
And because of this,
the low value added of this job per se,
there's huge demand to run this
in a super cost-performant way.
So we've spent now several years inside Microsoft,
working on basically skew design,
optimizing our applications,
be it CycleCloud or Batch,
to run these jobs in a very cost-performant way
and get very linear scaling,
so you can get past this job,
and then get the results to the software developers,
to the data scientists.
So you can do this,
open what we call the data loop,
and execute even faster.
So resimulation and recompute continues
to be an area where we'll invest going forward.
Another area that's really, really huge is simulation.
So simulation within the world of autonomous vehicles
is a little different than a traditional simulation
because you have
new scenarios that need to be validated.
So we basically break it
into two major buckets specific to autonomous driving.
One is the validation of the sensors,
in other words, perception.
In other words, the Lidars with the cameras
and all the radars that are on the car,
did they actually see the world
the way they're supposed to see them?
Did they see them accurately? Maybe did sunlight
or did something else mess with it?
And did it affect the performance
of the vehicle? That's one type
of sensor simulation you see.
Another one is scenarios, or post-perception,
which is basically policy.
Like, is the car following at a proper distance
from the car in front of it?
Did it navigate the traffic circle well?
When it executed some sort
of a maneuver like an overtake,
did it keep distance? Did it keep
between the lanes when it got there?
All those types of policy-driven things
that you, when you drive yourself,
you never think about.
But if you're going to have a robot do it,
you really have to validate
all these capabilities.
And then, of course, third is engineering,
or engineering simulation, or even performance simulation,
which is basically traditional HPC.
But if you think about it,
autonomous vehicles, you're going to have to do
all the same types of simulation you've done to date,
be it your crash test,
your wind tunnel-like CFD jobs.
But there's also a lot of other jobs,
especially multi-physics jobs.
There's NVH (noise, vibration, harshness).
Other types of jobs, when a computer
or a robot is driving for you,
people are going to basically want to do infotainment.
So we expect that there's going to be huge,
massive new types of simulations
for the purpose of occupancy.
The occupants in the vehicle,
what they will want to experience
as they ride around in these autonomous vehicles.
So simulation, we expect to continue
to be an exploding opportunity for us on Azure
because let's face it,
the amount of simulation that has to be done,
it's just crazy huge,
and so it's an exciting opportunity for us.
And last one, the third one that I want to talk about
in our limited time today
is some of the unique requirements
when it comes to large-scale compute
that we have to accommodate for,
and I would call that "HIL rig integration."
HIL rigs (hardware-in-the-loop)
is a very specific type of testing
that is done on very specialized
and custom rigs,
in what's called "HIL farms" inside automotive companies.
And it is very clear to note that these,
for functional safety and certification,
some of these ISO- or compliance-mandated
workloads, it must run on this type
of specialized equipment.
You can't run it on a regular VM.
Which puts it on us, Microsoft, to figure out a way,
how to integrate the hybrid way
with these specialized compute systems,
between our VMs and the cloud.
And there's multiple ways we can do that.
One is just simply on-premises,
in-cloud orchestration of this hybrid-type approach.
Another one is in partnership with
companies like Equinix, where we put in a co-lo
and then integrate between the two,
and basically obviate the need
for all those egress costs.
Going forward in the future,
in close partnership
with a sister team of mine in Azure,
the Azure Dedicated team,
we're also even looking at ways of bringing
this specialized hardware into Azure,
much like we do today with our programming
with Cray supercomputers.
In closing, I would like to just remind everyone,
this is very much a partner-driven type of engagement,
although we, in Azure and Microsoft,
we do have first-party services that are critical
to our success
in this space. For example,
Azure DevOps or MLOps, the entire
third pipeline,
the validation pipeline, is completely partner-driven,
and we have many, many amazing partners
and reference customers in this space
who we are deeply partnered with,
because it's very much a domain that requires
a lot of expertise that we, Microsoft, don't have,
but we do bring the ability
to help these partners scale their business
and scale specifically their capabilities.
And that, really, at the end of the day,
really lights up the scenario for a lot of our customers.
So once again, Microsoft,
we are very committed to this space.
We believe we're really contributing a lot
to the innovation here,
and would definitely like to
continue to work with customers and partners
to really
make this digital transformation happen.
Thank you.
(upbeat music)