Good morning Good afternoon my name is

Bernard Dion

CTO of systems at Ansys and I will

present

you now Ansys automomy in practice so

in

a previous talk by Sandeep Sovani you have seen

what

is Ansys autonomy about and what market we

are and

this product this solution is about enabling

companies to efficiently

develop autonomous vehicles and components

that are safe by design

and safe by validation so I'd like to show

you

to give you an idea in practice of what this

means and the starting point will be a white

paper

that is called safety first automated driving

created by number

of automotive companies and suppliers and it

has two fundamental

parts in it safe by design which we will

address

by MBSE model based system engineering

good practices and tools

and on the other hand by establishing safe by

validation

and relying on extensive simulation and

road driving a combination

of situation and road driving with of course

much more

simulation then road driving in a well targeted

manner

This solution relies on assembling different

disciplines together so in

the middle you see system safety and then for

autonomous

systems sensors are important which is on

the left

on the right we see that we have to develop

controls and AI and on top and bottom there

is

a notion of system simulation and virtual

reality experience that

is needed for all of these parts we do have

products that we are assembling in the Ansys

autonomy solution so

you see MEDINIfor safety SPEOS and

HFSS for sensors

SCADE for embedded software and twin builder

and VRXPERIENCE

for system simulation on top of

that we are

going to rely on the V cycle template that

you

see here and going through various steps

starting at the

top with ODD and feature definition and going

in the first

round of definition of a functional

architecture that is done

altogether with number of analysis for

functional safety and so

that if one there is a model's iteration

that

has been constructed we go into the

construction of the

physical architecture that is made by

allocating components of the

functional architecture onto the final system

and once the system

has been described we go into the building of

the

components so here we see a software part

where we

will provide tools and sensor part where

again will provide

tools including simulation and in order to

achieve validation and

then we go into the ascending part of the V

where we will proceed with various levels of

verification including

model in the loop software in the loop

hardware in

the loop and finally we're going to system

validation and

building a safety case where there is all the

evidence

that you can trust that the system is safe

this

is not the end of the story because typically

a

company wants to build on project to project

and to

reuse things that have been done in project to

reuse components

and so it continues into the next cycle

hoping that

a lot of it can be reused in what had

been done in the previous project so this is

the

typical setting that we propose in terms

of MBSE

workflow for ADAS/AD starting from the

beginning you

know the ODD the feature definition and then

there is

building a system model that you see in the

middle

here this is a MEDINI tool that is providing

around

system model all the elements to proceed to

do the

safety analysis functional safety

cybersecurity to do the

usual things like fault analysis HAZOP as well as

FMEA

to produce additional requirements from the

initial ones because of these

analysis that have been performed so we'll

take in this

presentation a very small example which will

be emergency breaking

and let's assume that this is the initial

architecture so

we see the radar sensor on the left and then

AEB core function and depending on time to

collision

there may be the decision to apply emergency

breaking which

goes onto the brake system output now looking

at it

in more details

We may have a discussion about specification

for example on

the left

What we see here when we start to model

scenarios

is that maybe we're going to hit this green

car

but maybe not because in fact

provided that the driver if there is driver

follows the

road then it's not going to be a problem so

that is a sign that something is missing in

the

requirements analysis and initial

architecture and this will lead to

you know thinking about it and thinking about

it can

be greatly help school causal analysis that

is FTA analysis

where you see here that if we are looking at

unjustified breaking

Then one of the goals may be that the object

reported as intersecting with ego lane

although it is not which is the case in what

we had seen previously and this will lead

this will

lead to modify architecture where we do you

know corridor

we have corridor delimiters and we will

we will

worry about the lanes

All depends if this is fully automated or not

but

in any case it should be handled and

depending on the Lane information then

you will

make a decision which will be to trigger the

emergency

braking so this is an iteration of the

architecture

that is solving one of the problems that we

have

identified in the initial requirements now

let's move on with

the simulation part so this is a high level

description

of what we provide in terms of simulation So

what

we see is that it starts from ODD

definition

He should have scenarios and variation of

parameters creation of

test plan execution of the closed loop where

we

have a model of the environment the scenario

and we'll

be testing the AD function here that is

coming from

outside and then looking at the result of the

expected

results on there so that's one part there are

other

parts that we see here so first of all on

the left there is drive data and how do we

use it well we will perform analytics

and from

this drive analytics maybe we will discover

that on the road

we see situations that are not described in

the scenario

so in that case there is need to think about

the scenarios again and maybe to add

simulation scenarios and

then to include them in the test plan another

problem

that there is with simulation or question not

a problem

is about toolchain validation can we trust

the simulation

are the results sufficiently close to the

reality in the

way that they are helpful and in order to

think

about this to have a decision about this we

also

have this module toolchain validation that is

starting from

drive data and on this drive data we use it

to reconstruct the scenario and we compare

the result on

the role that we have together with the drive

data

to the result of the same scenario in

simulation to

see if they are as close as we need to

the reality

Last but not least this comes with data

lineage

we need to manage the data forever and keep

track

of everything that has been done and

dependencies the tracing

between all the elements of what has been

performed in

these simulation activities so to go in a

little bit

more details first point modeling realistic

world so you see

here that we create a world then that can

come

from HD map information and other type of

information to

build a world

Then we need to build the sensor simulation

so to

give you an example here to show that the

level

of fidelity of the simulation can get very

high when

needed here we have the example of the camera

sensor

that is inserted inside headlamp and what is

studied here

simulated is the effect of rain droplets on

the headlamp

and we see that it becomes fairly

difficult to

do perception during the day and during the

night and

what we see is that we add a hydrophobic film

on the headlamp then the perception becomes

much easier so

as needed the simulation environment allow us

to do into more

physics based more realistic modeling of the

sensors

One last point here in in creating the

simulation is

about driving scenarios and so what I'm

showing here is

something that is in the making because

it's

related to a standard that is being

constructing at ASAM

which is OpenSCENARIO 2.0

where you see a high

level language to create driving scenarios we

will have it

when the standard becomes available in little

bit of

time

Now let's turn to the software part so

again

we'll take our example and look at software

requirements and

how they are implemented and then simulated

So what we

have here is a software component that relies

on input

which is an occupancy grid where we see

occupied areas

and probability that this is an

object And

then we have a software requirement that says

that upon

detecting collisions threat we will produce

emergency breaking depending on

occupancy probability time to collision and

ego vehicle speed and

so in order to implement the software what we

propose

is the model based software notation and tool

that you

see here where in the very high level and

graphical

way you express the algorithms so here I will

not

go into the details but it is about going

through

iterations of these array cells and detecting

the objects and

understanding if breaking should be applied

so very high level

graphical notation that comes with a

certified code generator so

you never have to worry about the software

code itself

you only worry about the design and

understanding the design

is correct and meets the requirements

themselves and so once

this is done

You can go in simulation and so here we have

coupled the generated code so that we execute

the model

simulation

together with destination of the driving

scenario and we see

that here the car is going to break because

of

the pedestrian and then resume its course

Now one last topic I want to address is that

assessing you know the level of confidence

you can have

in in the application of emergency breaking

relies on coverage

of a large number of things first of all you

should cover all of the requirements the

scenarios and they

have to be tested second of all you must

ensure that

you cover all the situations that you are

going to

see in driving if not you have to add

scenarios

as we said and there is one last example I

wanted to illustrate here is that you have to

cover

through simulation all of the software

elements that there is

and here we see a tool which is a model

coverage tool for the software part and what

this is

telling us is that this condition has never

been set

to true in the overall executions of all the

simulations that we have performed and this

means that something

is missing and in fact the fact is that the

case that is missing is that when the two

vehicles

are going in the same directions and so this

is

an indication that there is a need either to

fix

the requirements or the model or to add test

cases

in order to be able to meet all the

expectations

in terms of coverage that was just an example

of

what kind of coverage but there is many

different kinds

of coverage that have to be that have to be

achieved so this is the end of the

presentation and

I will now turn it to a few questions thank

you