►
From YouTube: Driving the Software Defined Vehicle with eSync Shrikant Acharya Excelfore Ortwin Schneider Red Hat
Description
Driving the Software Defined Vehicle with eSync and Openshift
Shrikant Acharya (Excelfore/eSync Alliance)
Ortwin Schneider (Red Hat)
OpenShift Commons Gathering on Automotive
April 6th 2022
full agenda here: https://commons.openshift.org/gatherings/OpenShift_Commons_Gathering_on_Automotive.html
A
A
Now,
just
a
quick
note
on
what
esync
really
means:
the
esync
is
a
bidirectional
standardized
pipeline
and
it's
a
client,
server,
client
and
agent
approach.
This
is
not
new
to
the
what
I
call
industrial
interest
rise
world
and
the
the
beauty
of
this
distributed
architecture
is
allow
you
to
scale,
you
don't
have
another.
The
scaling
comes
in
the
form
of
it
doesn't
matter
how
many
devices
are
connected
in
network
the
client
discovers
them
and
brings
them
into
the
network.
A
A
A
So
that's
very
important
because
that's
one
of
the
important
things
for
certification
today
now,
what's
inside
the
the
what
I
call
the
client
agent
architecture,
the
agent
is
a
software
abstraction,
a
software
abstraction
that
allows
you
to
present
a
device
in
a
very
standardized
interface
that
connects
to
a
message
broker.
So
whenever
a
new
device
comes
in,
it
presents
its
credentials,
the
credentials
are
verified
and
if
it's
the
right
one
it
becomes
registered.
A
A
What
it
does
is,
as
the
power
comes
on,
the
various
registrations
get
matched
tallied
and
the
nascar
network
gets
discovered.
There
are
two
reasons
why
this
is
becomes
a
very
important
thing.
One
is
first
of
all
any
new
element
that
gets
introduced
as
a
rogue
element
can
can
be
discovered
immediately
and
if
some
devices
are
non-operational
gets
flagged
immediately
so
and
if
there
are,
if
the
same
setup
is
put
on
a
car
that
has
20
issues
required
for
ecu's
or
if
100
is
used.
The
discovery
allows
the
system
to
stay
standard
across
platforms.
A
Now
the
standardization
of
an
effort
is
not
an
easy
effort
at
any
point,
but
it
has
gathered
momentum.
It
has
gathered
momentum
in
terms
of
customers,
oems
and
even
semiconductor
companies,
and
that
has
really
been
a
driving
force
because
finally,
standardization
has
to
come
from
within
the
organization
it
cannot
be
imposed.
Standardizations
have
to
be
something
that
you
learn
from
mistakes,
but
standardization
cannot
be
what
I
call
insular.
A
It
has
to
go
across
standard
because
there's
so
many
other
bodies
that
are
also
doing
stuff.
This
whole
sdv
is
such
a
big
swath
that
you
cannot
attempt
to
solve
it
with
one
organization,
so
you
have
to
collaborate,
and
in
this
regard
you
have
the
kovisa
kovisa
is
building
this.
What
I
call
the
standardized
vehicle
catalog
in
the
cloud,
and
so
the
sink
alliance
went
into
analyzing
agreement
in
2021
created
the
the
specification
oracle
organization
between
the
cvi,
the
connected
vehicle
initiative,
as
well
as
the
vehicle
catalog
that
they
are
trying
to
build.
A
A
Now,
in
this
standardized
pipeline,
you
have
the
ota,
which
is
the
or
the
air
update,
but
that
is
not
what
I
call
all
in
all.
You
have
to
bring
data
out
of
the
vehicle
in
order
to
have
this
learning
loop.
So
we
talk
about
anonymous
driving
vehicles.
How
do
they
become
better?
You
have
to
have
a
learning
loop,
and
for
that
that
is
the
idiotics
management
aspect,
so
you
always
have
to
figure
out
how
things
can
grow
from
a
structure.
A
Now
what
happens
with
the
data
aggregation
platform?
You
have
to
have
both
the
cloud
aspect
and
the
the
in
vehicle
aspect.
So
much
data
is
getting
collected
inside
the
vehicle
to
transfer
all
the
data
into
the
cloud
is,
I
would
say,
not
a,
I
wouldn't
call
it
feasible,
it
is
feasible,
but
it's
not
practical,
so
you
have
to
have
cleans
the
data
cleaning.
A
The
data
inside
the
vehicle
is
extremely
important
before
you
transfer
that
cleans
data
back
into
the
cloud,
because
that's
what
is
relevant
relevant
data
that
is
in
and
around
an
event
relevant
data
that
extracts
certain
features
out
of
what's
happening.
That
to
me
is
essential
to
the
platform
approach
itself.
So
you
have
the
e-sync
pipeline,
then
you
have
the
using
ota
as
an
application,
and
now
you
have
the
edatix
as
an
application.
Now
you
have
the
complete
learning
loop
for
the
vehicle,
and
these
are
all
coming
out
of
standardization
processes.
A
Now
so
we
have
implemented
a
version
of
the
erratics,
and
these
are
all
the
things
that
we
have
managed
to
get
out
of
it.
So
telematics
data
for
the
vehicle
that
is
generally
available,
and
everybody
knows
how
to
do.
It
then
talk
about
different
what
I
call
device
statuses
inside
the
vehicle
you're
talking
about
what
I
call
dashboards,
that
tell
us
a
little
more
detail
about
power
and
drivetrain
battery
management
systems
and
high
resolution
data
and
demand.
A
Now
these
are
all
configurable,
so
you
can
send
the
configuration
information
from
the
cloud
and
the
appropriate
data
shows
up
from
from
the
device
it
through
the
client
into
the
cloud
now
coming
to
the
whole
aspect
of
the
software
defined
vehicle.
The
software
defined
vehicle
is,
can
mean
several
things
to
the
the
people
who
work
on
it.
Here
is
our
definition
of
what
a
software
defined
vehicle
is.
A
The
key
things
are
you
have
to
have
a
stand,
standardized
hardware
that
rolls
out
of
the
platform,
because
you
are
trying
to
put
software
that
is
configured
to
create
the
car.
So
what
is
that
it
needs
to
have
a
domain
master
architecture?
You
have
to
have
zonal
controllers,
and
these
are
what
I
call
a
confluence
of
high
compute,
centralized
units
to
what
I
call
regional,
zonal,
compute
units.
So
now,
once
the
hardware
is
standardized,
you
can
now
deploy
the
software
to
create
the
feature
or
the
vehicle.
A
So
in
that
regard,
now
you
can
put
model.
You
can
create
sub
models.
You
can
create
options,
packages
personalizations,
but
it
all
emanates
from
a
standard
having
a
standard
hardware
platform
on
the
table.
So
now
a
lot
of
things
are
happening.
Features
on
demand
feature
purchases
subscriptions
rentals
refreshes
upgrades
have
become
part
of
a
personality,
personalization
process.
We
are
all
in
this
age
of
having
cell
phones
getting
updated.
New
cell
phones
coming
along.
A
A
Similarly,
now
that
you
have
pushed
features
on
what
do
you
do
in
terms
of
getting
data
out
of
the
vehicle?
So
what
all
the
things
that
you
can
create
to
monetize
their
vehicle
data?
Now
that's
important
that
you
need
to
get
standardized
data
out
of
the
vehicle
in
order
to
even
monetize
it,
so
you
have
to
go
beyond
test
vehicles.
So
in
olden
days
you
had
to
run
vehicles
on
test
tracks
to
get
data
before
a
vehicle
is
launched,
but
today
you
cannot.
A
While
you
may
still,
the
the
racetracks
or
the
test
tracks
are
going
to
be
relevant,
but
the
reality
is
that
by
connecting
the
vehicles,
all
of
them,
you
are
getting
hundreds
of
thousands
of
vehicle
data
all
at
once,
giving
you
a
better
understanding
as
to
how
the
vehicle
is
performing
in
different
use
cases.
So
you
can
bring
in
predictive
analytics,
reduce
life
cycles.
Remedials
event
correlations
even
essence
as
to
the
stature
of
the
road.
A
Challenge
in
a
software-defined
vehicle
and
the
complexity
of
its
connections,
this
is
the
challenge.
We
talk
a
lot
about
standardization,
talk
about
the
ways
you
can
monetize
data,
but
are
fundamentally
grounded
in
our
own
legacy
that
we
are
managing
and
that's
somehow
we
are
unable
to
get
out
of
it.
Why?
This
is
the
challenge
we
have
in
the
modern.
A
What
I
call
landscape
of
oems.
You
have
oems
on
one
end,
you
have
tier
ones
on
the
other
one
they
all
make
ecu's,
but
they
each
make
a
different
version
of
the
device
to
reflect
the
needs
of
the
oems.
Look
at
how
much
cost
that
entails
how
much
energy
that
is-
and
this
is
what
we
all
want
to
do
is
to
standardize
is.
A
A
A
What
I
call
investments,
so
this
standard
allows
you
to
how
to
gracefully
merge
the
two
so
that
you
can
use
the
the
scalability
and
and
ease
of
deployment
to
trying
to
merge
with
existing
infrastructure
market
engagement
adoption.
So
we
have
leading
partnerships,
of
course,
red
hat
being
one
of
the
key
ones.
The
alliance
is
building
building
bringing
in
a
lot
of
value
and
of
course,
we
have
managed
to
create
a
common
interface
to
the
cloud
platforms.
A
Use
cases
this
is
a
use
case
of
a
autonomous
driving
truck
platform
that
is
using
e-sync
today.
It
got
it
running
in
literally
three
months
into
their
beta.
Now.
This
concept
of
trying
to
get
things
into
production
is
always
a
headache
for
automotive
williams,
but
the
standardized
modular
structure
of
heatsink
allows
you
to
get
going
into
your
production
quickly.
A
The
there's
a
new
upcoming
member
in
the
alliance
that
is
really
creating
a
platform
that
we
thought
would
be
the
prototype
of
a
software-defined
vehicle.
What
are
they
doing?
They
are
creating
a
super
board
that
presents
the
drivetrain
the
battery
the
steering
all
these
available
as
a
platform,
and
you
can
put
the
skin
on
top
and
create
your
own
vehicle.
A
B
So
you
see
my
screen
right:
yep,
okay,
great
so
yeah.
First,
let
me
briefly
introduce
myself
so
my
name
is
audrey
schneider,
I'm
working
in
the
hybrid
platforms,
openshift
business
unit
at
red
hat
and
yeah.
Today.
I
want
to
show
you
a
little
demo
and
also
talk
a
little
bit
about
what
we
have
done
with
e3
together
in
this
context
of
the
demo.
B
You
heard
alright
already
with
the
human
driving
perception
platform
with
bobby
carr,
but
first
of
all
thank
you
srikant
for
for
covering
this
topic
and
is
explaining
kind
of
the
the
over
there
architecture
and
so
on,
and
now
I
would
start
with
a
question.
Okay,
now,
from
a
retired
perspective,
how
can
we
help
with
with
this
over
the
update
topic?
So
how
can
we
help
with
our
technologies?
And
I
would
say
basically
it
is
like
this
eastern
kind
of
standardized
the
the
way
or
over
the
air
updates.
B
So
that's
not
that
not
every
vendor
kind
of
invent
the
wheel
again
and
again,
and
what
we
do
from
the
red
hat
side.
We
kind
of
standardize
the
platform,
so
we
not
only
have
kubernetes.
We
have
a
lot
a
lot
more
services
added
on
top
of
it
so
like
we
have
platform
services,
application
services,
data,
developer
services
and
there's
a
bunch
of
other
services
as
well
like
multi-cluster
management
security,
all
the
things
you
need
for
two
things,
so
you
can
run
it
and
complete
esync
over
there
infrastructure
at
scale
in
a
cloud
agnostic
fashion.
B
So,
as
also
mentioned
in
the
upstream
talk,
we
heard
it
is
like
cloud
agnostic.
We
have
operators,
they
can
replace
the
managed
services
you
have
and
you
can
kind
of
run
your
esync
over
the
air
infrastructure
in
any
cloud
if
it's
aws
azure,
wherever
in
your
own
data
center.
So
you
have
kind
of
really
inconsistent
environment
to
run
these
services
really
at
scale
and
some
of
the
things,
for
example,
the
e-sync
consists
of
the
architecture,
consists
of
several
components.
So
there
is
a
server
component.
B
Actually,
where
you
kind
of
manage
your
software
packages,
you
create
updating
campaigns
and
so
on,
and
the
the
server
infrastructure
needs
several
middleware
components
as
well,
and
we
can
also
provide
on
top
of
openshift
with
some
of
our
application
services
portfolio,
for
example,
with
api
management
with
messaging
platforms
database.
Caching.
So
all
these
services
we
can
use
them
to
actually
support
the
actual
eastern
infrastructure.
B
So
what
we,
what
you
could
do
is
you
can
really
operate
and
over
over-the-air
infrastructure
with
with
on
top
of
openshift.
This
is
one
thing
and
the
other
thing
you
can
use
the
openshift
container
platform
to
really
build
your
automotive
cloud
for
all
the
other
types
of
workloads
in
the
scenario
as
all
already
here
today.
So
we
have
machine
learning
ai,
so
openshift
is
really
for
any
type
of
workload
right.
So
you
can
do
your
machine
learning,
ai
stream
data
processing
batch
processing.
It
is
it
supports
microservice
architecture,
event-based
architecture
and
so
on.
B
These
are
also
very
relevant
in
this
context.
So,
but
let
me
come
to
the
demo
part.
So,
as
already
heard,
we've
created
a
demo
which
is
called
bobby
car.
Basically,
what
it
is,
it
is
kind
of
an
opinionated
design,
a
retired
recommendation.
You
could
say
for
a
cloud
cloud
native
iot
architecture
built
with
red
hat
products.
B
So
there
are
a
lot
of
kind
of
reference
architectures
out
there
supporting
these
different
type
of
workloads,
and
this
is
kind
of
a
way
we
we
would
recommend
you
could
do
it
with
openshift
and
a
bunch
of
the
the
middleware
portfolio
we
have
so
the
high-level
architecture.
Just
to
give
you
the
context
of
this
demo,
just
walk
over
the
high-level
architectures.
So
basically
it
is
a
vehicle
simulation.
So
we
have
on
the
left
side
the
actual
bobby
cars
which
are
vehicle
simulators
implemented
in
cloud
native
java
and
qualcos.
B
By
the
way
everything
you
see
here
is
running
an
open
shift.
So
and
then
we
have
several
regional
cloud
environments
and
the
central
cloud
environment,
and
so
there
is
the
connectivity
from
the
simulated
vehicles
to
the
central
cloud
environment,
with
mqtt,
with
an
http
kafka
bridge
and
so
on.
So
basically
all
the
data
coming
from
the
cars,
all
the
telemetry
data
they're
coming
to
the
mqtt,
and
then
we
have
several
integration
components.
B
Cloud
native
integration,
components
and
basically
everything
that
comes
in
goes
into
kafka
and
from
there
we
distribute
the
data
or
do
different
types
of
processing.
So
one
thing
is,
of
course,
real-time
data
processing
with
kafka,
streams
for
or
apache
sparks
or
the
different
technologies
you
could
use
there.
B
Then
we
have
distributed
caching
as
well
to
kind
of
store
the
current
state
of
every
car
in
in
the
system
where
we
have
business
entities
and
configurations
stored
in
there.
There
is
a
real-time
dashboard
to
see.
Okay,
where
are
the
cars
driving
what
is
happening
there,
and
then
we
mirror
the
data.
We
do
also
some
data
cleansing
so
to
say
and
mirror
all
the
relevant
data
for
machine
learning
from
the
regional
cloud
environments
to
central
cloud
environments-
and
you
see
there
on
the
right
side.
B
There
is
a
central
kafka
cluster
running
and
attached
to
this
cluster
there's,
for
example,
our
machine
learning
infrastructure,
which
could
be
from
a
red
hat
perspective
based
on
open
data
hub
and
there
you
do
your
machine
learning
and
bring
the
trained
models
back
up
into
the
into
the
car.
So
this
is
basically
the
high
level
architecture
of
of
the
demo,
and
now
what
we've
done
in
in
the
last
few
months
is
also
an
integrated
use
case
with
eastern
with
standard
over-the-air
updates
for
this
specific
demo.
B
So
what
we
have
is
we've
deployed,
e-string
servers
in
this
virtual
cloud
environments
and
the
eastern
client
is
kind
of
the
in-vehicle
gateway
communicating
with
the
server
side.
So
whenever
there
is
an
update
for
a
specific
type
of
car
and
so
on,
the
client
will
fetch
the
data,
the
actual
payload
and
will
distribute
it
internally
to
the
specific
ecu
and
we'll
do
the
update.
But
in
this
scenario
here
the
the
vehicle
simulations
they're
not
highly
sophisticated,
so
we
don't
simulate
like
issues
things
like
this.
This
is
just
more.
B
B
So
whenever
their
a
car
enters
a
zone
or
leaves
the
zone,
there
will
be
a
zone,
change
event
emitted,
and
then
we
use
openshift
serverless,
which
is
also
one
of
the
services
openshift
offers,
and
we
use
the
serverless
function
to
kind
of
communicate
with
e-string
server
to
check.
Okay
is
this:
is
this
an
update
zone?
Is
this
car
kind
of
valid
for
an
update
and
then
we
assign
kind
of
the
vehicle
identification
number
to
a
specific
update
campaign,
so
we
interacting
with
the
api
server
of
the
esync
and
this
wall.
B
This
one
will
then
trigger
the
assigned
eastern
client,
the
the
actual
over-the-air
update
download.
So
the
client
will
download
the
update
package
and
will
distribute
it
to
the
car
and
will
be
applied
here.
So
this
is
kind
of
the
context
and
just
the
demo
we've
we've
implemented
here
and
I
would
now
jump
into
the
demo
part
and
open
shift,
but
I
have
to
I
have
to
apologize
today.
So
something
really
bad
happened.
B
Actually,
I
completely
destroyed
my
openshift
cluster,
so
I
don't
have
an
over
the
update
infrastructure
easing
whatever
so
I've
I've
used
the
new
openshift
cluster
and
I
only
can
show
you,
unfortunately,
only
a
few
parts
of
it,
so
basically
just
the
bobby
car
components
and
and
the
cars,
but
I
wasn't
able
to
kind
of
reproduce
to
complete
over
the
eastern
parts
of
this
demo.
So
I'm
really
sorry
for
this.
This
is
one
of
the
worst
days
in
in
years.
For
me,
but
yeah
honestly,
it's
it's
the
case.
B
B
So
basically,
what
you
see
here
is
is
the
complete
regional,
iot
cloud
cloud
environment
with
the
caching
system,
with
kafka
running
here:
mqtt
broker
several
integration
components,
and
so
so
everything
is
deployed
in
here
and
you
you'll
find
all
the
code
also
in
github.
So
you
can
also,
if
you
want
to
try
that
in
your
openshift
environment,
so
everything
is
running
here
and
now,
let's
zoom
in
you
see
here
is
a
car
simulator.
This
is
the
actual
bobby
car
our
vehicle.
B
So
there's
one
container
currently
running
and
this
one
is
simulating
20
cars
and
there
is
also
dashboard
component,
which
is
kind
of
the
actual
visual
side
of
it.
So
we
have
a
dashboard
and
there's
basically
very
simple,
there's
just
a
map
and
we
see
the
20
cars
now.
So
we
should
see
a
map
and
we
should
also
see
some
markers
moving
around
and
the
red
circles
you
see
here.
These
are
the
specific
update
zones
so
there's,
for
example,
in
frankfurt.
We
have
a
zone.
B
B
For
example,
we
could
do
some
real-time
query
of
the
data
if
we
move
like
this
gray
search
area-
and
we
want
to
know
okay
now
kind
of
a
little
bit
of
stream
analytics
what
is
the
average
speed,
carbon
dioxide
emission
and
so
on
of
the
cars
driving
here
we
could
do
things
like
this
and
also
so.
The
the
thing
is
now
if
a
car
enters
a
specific
zone.
B
So
we
are
not
that
happy,
because
the
cars
are
driving
somewhere
else
around,
but
if
they
enter
a
zone,
this
will
trigger
the
serverless
function
in
in
the
background,
and
this
will
assign
the
car
to
the
over
the
update
server
and
will
trigger
the
actual
download.
So
we
could
normally,
if
it
would
work,
we
could
go
to
the
car
detail,
select
one
specific
car
yeah.
We
can
also
switch
the
cockpit
view
if
there
is
preview
data
available.