AWS re:Invent 2021 - Building connected auto solutions with AWS IoT

Aug 16, 2023

AWS re:Invent 2021 - Building connected auto solutions with AWS IoT

Join this session to learn about connected auto and mobility best practices that were discovered through hundreds of engagements and thousands of activations. Find out how to customize different microservices, from the edge to the cloud, to build innovative and differentiated solutions for use cases from in-vehicle personalization to safety monitoring, behavioral analytics, anomaly detection, diagnostics, and more.

Learn more about re:Invent 2021 at https://bit.ly/3IvOLtK

Subscribe:
More AWS videos http://bit.ly/2O3zS75
More AWS events videos http://bit.ly/316g9t4

ABOUT AWS
Amazon Web Services (AWS) hosts events, both online and in-person, bringing the cloud computing community together to connect, collaborate, and learn from AWS experts.

AWS is the world’s most comprehensive and broadly adopted cloud platform, offering over 200 fully featured services from data centers globally. Millions of customers—including the fastest-growing startups, largest enterprises, and leading government agencies—are using AWS to lower costs, become more agile, and innovate faster.

#AWS #AmazonWebServices #CloudComputing

Content

0.29 -> Good afternoon and welcome to the session today.

3.9 -> Did everybody watch the keynote this morning?

6.36 -> Adam's keynote?

7.85 -> Good.

8.683 -> And how's your day going?

10.85 -> Hopefully all good.

12.13 -> Great.

12.963 -> Well, we're very thankful that you're here.

14.73 -> Very excited for everyone to be here

17.17 -> and spend this next hour with us.

19.73 -> So we're gonna be talking about how

23.557 -> AWS IoT helps our customers

25.35 -> build connected auto solutions,

27.406 -> easily and quickly with AWS IoT.

30.83 -> My name is Ritu Kama, I lead

32.76 -> the worldwide IoT go-to-market strategy here at AWS,

36.11 -> and I'm transitioning into my new role

38.26 -> as a principal PM on SageMaker foundation team.

42.22 -> You'll also be hearing in today's session

45.14 -> from Michael Garcia and Henrik Stromberg.

47.36 -> They'll do the intro when they come on the stage.

50.66 -> So, let's get into the agenda for today.

54.03 -> To begin with, we'll be talking about

56.34 -> what do we mean by connected auto?

58.88 -> What does that mean?

60.58 -> And then we'll talk about what tools and technologies

64.06 -> AWS has to enable connected auto solutions

67.03 -> for our customers.

68.33 -> I'm sure you all caught the announcement of IoT FleetWise.

72.59 -> We'll talk a little bit about that too as well.

74.7 -> And then we'll hear from Henrik,

77.59 -> our customer from WirelessCar.

79.7 -> He's going to talk about their journey

82.46 -> with AWS IoT to enable connected auto solutions

85.55 -> for their customers.

86.56 -> And then we'll hopefully have some time set aside

88.73 -> for Q&A at the end.

91.397 -> Okay, so let's jump into it.

94.38 -> We can all relate to this.

96.01 -> Cars used to be all about mechanical systems,

98.6 -> about electrical systems.

100.3 -> And frankly, auto companies became very good at

103.22 -> building cars over the course of time.

105.65 -> But then when we think about cars today,

107.768 -> they're not as much about mechanical and electrical system

111.06 -> as it is about digital and the data

112.97 -> that these cars are collecting.

114.818 -> And customers expect digital solutions

118.34 -> from their cars today.

119.36 -> So, by collecting all of this data

121.89 -> it creates a lot more possibility.

123.43 -> And that's what we're here to talk about.

126.36 -> And this is all driven by consumer demand.

130.15 -> We can see this, that the customers are evolving

132.93 -> and they're requiring and actually,

135.25 -> expecting more and more of this from the auto manufacturers.

138.76 -> And the auto industry is rising up to the challenge

141.33 -> by delivering new solutions to their consumers.

144.47 -> We know that the consumer demand

146.61 -> for connected automotive or connected cars

149.07 -> has gone up significantly.

151.17 -> The connected vehicles shipments

152.86 -> will go from 52 million cars to 78 million cars

157.26 -> in the next three years.

158.49 -> And all these cars are being designed today.

161.24 -> So the technology that's going into the cars

163.35 -> are being designed and put into the solutions today.

167.7 -> Technologies like cloud, obviously,

170.33 -> 5G, edge computing, computer vision, AI,

174.01 -> and machine learning is fueling all of this transformation

176.63 -> in the automotive industry.

178.46 -> And this industry is undergoing a transformation,

181.27 -> unlike anything it has faced in the past.

183.71 -> And so we're all sort of experiencing this

187.502 -> as we're both technologists,

190.34 -> as well as consumers in this market.

193.25 -> There's also a shift in consumer mindset.

195.91 -> Consumers want experiences.

198.5 -> They want personalized interactions.

202.339 -> They have expectations that their digital lives

204.86 -> follow them wherever they go.

206.85 -> And so for the auto industry,

208.38 -> this convergence of all of these factors

211.22 -> is unlike anything that they've experienced in the past.

215.53 -> So when we talk about connected car,

217.38 -> what does it actually mean, right?

219.19 -> You may think to yourself like,

220.75 -> well, there's lots of different things

222.22 -> when it comes to the technology of

224.37 -> creating connected car or connected auto solutions.

227.99 -> We do need to think about software solutions,

230.3 -> software systems in the car.

231.94 -> That's collecting real-time data

234.07 -> from the sensors, from the cameras,

235.62 -> from lighter and other sensors

237.84 -> and other detectors in the car

239.08 -> to make real-time decisions.

241.23 -> There's also a need to bring all of that data

243.44 -> that's been collected in the car, into the cloud.

247.377 -> And as you heard Adam say this morning,

249.43 -> there's terabytes and terabytes of data

251.25 -> being produced in the car every hour.

253.41 -> So how do you bring all of that data to the cloud

255.82 -> and how do you make those decisions?

258.01 -> There's also need to make some

259.29 -> of the decisions within then the car

260.6 -> because of the latency requirements.

262.07 -> So we'll talk a little bit about

263.87 -> architectures that support that.

267.16 -> There's also need to bring the data

268.96 -> for some back to some sort of a backend platform

272.22 -> securely, first of all.

273.96 -> Where all of this data can enable services

276.13 -> that are going to be needed both by the auto manufacturers

278.91 -> and the auto OEMs, as well as the consumers.

281.73 -> And then you need a system

282.98 -> to perform real-time health checks on the car's operation,

286.84 -> provide feedback loop on how the car is doing

289.94 -> about various critical components in the car.

292.83 -> And then finally, if you deploy a fleet of connected cars,

296.49 -> there's a whole other set of use cases

299.38 -> and solutions that are needed to be able

301.73 -> to perform fleet management, over the air updates

305.49 -> and ensure that there is a central system

307.41 -> to do lifecycle management of the car.

309.27 -> So there's a lot of different things

310.744 -> and a lot of different components of the architecture

313.27 -> that need to come together to support

315.18 -> a connected car solution.

318.53 -> But the possibility by collecting

320.9 -> all of this data is endless.

323.917 -> There's so many dimensions of how different types

328.22 -> of solutions can be produced and provided.

331.388 -> There are used cases as we've all experienced

334.63 -> in the entertainment industry.

336.81 -> There are use cases from productivity standpoint,

339.92 -> and there are use cases from digital e-commerce

342.68 -> and just, you know,

343.53 -> business to business type of use cases

345.33 -> within the auto industry.

347.72 -> When we talk about connected automotive,

349.37 -> it means different things to different people.

352.27 -> For OEMs, it is host of new services

354.84 -> to reduce things like warranty costs,

358.64 -> replacement costs for parts and things like that.

362.21 -> There's use cases for managed service providers

365.67 -> to be able to deploy new and innovative experiences

368.71 -> and services to drive productivity

371.21 -> and improve customer experiences.

372.79 -> And there's also use cases in commercial fleet.

375.71 -> So there's lots and lots of different use cases,

378.48 -> but the underlying critical component is the data, right?

381.15 -> Data is the key enabler,

382.6 -> how that data is fueling innovation for the customers,

386.53 -> how that data is fueling innovation for the ecosystem

389.6 -> and how that data is fueling innovation

391.5 -> for internal insights for the car or the auto OEMs.

396.27 -> And this creates tremendous business opportunity

399.05 -> in the market across the board.

401.88 -> But it's not very easy to do.

404.62 -> What makes us hard, but first of all,

406.79 -> communication is expensive.

409.02 -> You can't really send or upload

410.99 -> all of the data to the cloud.

413.25 -> Also, instrumenting the physical world takes time.

416.13 -> So, how do we decide what data is important to collect

420.18 -> and where those decisions need to get made?

423.3 -> There's also security and privacy concerns.

425.65 -> So when we're collecting all of this data

427.45 -> at millisecond speed and bringing

429.44 -> all of that data into the cloud,

430.9 -> how do we bring that securely,

434.4 -> what sort of protocols we need to be supporting,

436.96 -> and then deciding what computation to do on the edge,

441.36 -> what computation to do in the cloud

442.81 -> and how to do that securely both in the cloud

444.63 -> and then within the car or at the edge.

448.55 -> And then the next level of challenges

450.64 -> come with organizational challenges.

454.03 -> This is really hard for a lot of companies to do.

456.8 -> Managing huge volumes of data is a whole new ball game.

461.28 -> So how do you collect all of that data?

464.82 -> How do you build solutions on top of that data?

467.38 -> And more importantly, how your team's performance

470.02 -> is measured on the basis of data.

472.15 -> Is this a new world,

473.22 -> but also very scary one too, for many organizations.

476.84 -> And then many organizations are also not set up

479.5 -> to harness the returns from all of the insights

481.89 -> and enabling this new paradigm for the consumer.

485.03 -> So there's lots of different challenges,

487.947 -> but surely, definitely,

490.71 -> the auto industry is moving in this direction.

494.41 -> So with that, I'm going to turn us over to Michael

497.03 -> to talk about what AWS solutions exist for automotive.

504.13 -> Thank you, Ritu.

506.92 -> Hi, everyone.

507.78 -> My name is Michael Garcia.

509.43 -> I'm a Principal Product Solution Architect at Amazon.

512.4 -> I've been working at AWS for nine years.

515.73 -> Most of my background is working in launching

518.36 -> the IoT services that exist today.

520.93 -> And now I'm focused on BlackBerry IVY.

524.02 -> So in this section, we're going to talk about

526.81 -> the technological impact that exists

529.03 -> when you develop a digital product,

531.04 -> 'cause as Rita mentioned,

532.69 -> that's what the vehicles are becoming.

535.39 -> And then we'll also talk about the software architecture

538.756 -> they have to put in place to make possible

542.13 -> that vision of software-defined vehicle.

545.5 -> So one of the thing that is different

547.31 -> that we have seen in the IoT world,

549.49 -> when you develop a digital product

551.54 -> is that you have three teams

553.53 -> that really have to work hand-in-hand

556.65 -> and organizationally, those three teams

558.86 -> may be in different silo.

560.64 -> But you really want to make sure

562.13 -> that there's connective tissues

563.89 -> between them and incentives for them to work together.

567.14 -> The first one is the hardware team.

569.69 -> So the people developing the hardware competence

572.3 -> for the vehicle and the car itself.

574.9 -> The second one is the software team, IT teams.

578.02 -> So you've seen that a lot of automakers

580.85 -> have started to hire a lot of software talents

585.19 -> to make sure that they can build software in the vehicle,

587.87 -> but also the cloud vehicle connected backend

591.55 -> that the vehicle is connected to.

593.44 -> And the third team, is the product team owning

597.15 -> like the delivering of the feature for customers.

599.96 -> And here customers are pretty broad terms.

602.99 -> It could be consumers if we're talking about retail cars,

606.36 -> but it could also be companies

608.17 -> if we're talking about fleet use cases, for example.

611.85 -> And so the value when you develop a digital product,

615.77 -> the value goes beyond just having a digital product

619.26 -> and services delivered by the digital products.

623.03 -> For example, now with the digital product,

625.01 -> you can collect a lot of telemetric data

627.4 -> coming from the vehicle.

628.95 -> And that's very useful in the rest of the company

631.51 -> for the engineering teams that are producing,

635.47 -> working on the battery management system, for example,

638.96 -> understand better how the components of the vehicle,

641.85 -> the hardware competence are behaving,

643.88 -> what is the performance of those?

646.68 -> And another example, is in the supply chain.

649.8 -> Now with a digital product,

651.5 -> you can track and trace where the product is.

655.4 -> So for example, you can track and trace a vehicle

659.19 -> once it's out of the manufacturing line

661.68 -> and it makes its way to be delivered

663.25 -> to a dealership for example.

665.09 -> So that means better visibility

667.11 -> over the fulfillment of orders

669.26 -> and the ability to optimize those in the future.

672.91 -> Another example in manufacturing,

674.58 -> is that with a software products,

676.67 -> you can extend the quality control checks

680.53 -> that are already in place, in place in factories today,

684.17 -> with the software you can test,

686.11 -> you know, some of the hardware,

687.17 -> but also the other software features

689.93 -> that are in the vehicle.

691.557 -> And by doing so, you can prevent

694.25 -> the operation of lemon cars.

698.42 -> And last but not least, sales and marketing,

701.42 -> you might have seen that more and more people

704.21 -> are ordering, buying cars online,

706.5 -> and then they're delivered to their driveway.

708.94 -> So there's an opportunity there

710.44 -> to specialize the software at delivery.

714.02 -> For example, loading the profile of the buyer,

716.91 -> to greet them with a personalized message,

720.22 -> but also buying the software

722.54 -> and customizing that software package for the vehicle.

727.61 -> So now we're gonna zoom in a little bit onto the hardware

731.21 -> and just to level set here with the audience,

733.23 -> we're gonna talk about the hardware in the vehicle.

736.47 -> So most of you might be familiar already

738.94 -> with traditional vehicle architectures here,

741.96 -> where there's a lot of ECUs in the vehicle that are siloed,

745.675 -> and you might know that the industry

747.97 -> has already worked its way

749.38 -> towards consolidation of ECU by domain.

752.71 -> So powertrain, body, chassis

755.38 -> and have added connectivity.

757.76 -> So, it could be in the limited capacity today,

761.07 -> but in the future, everyone is geared towards

764.93 -> high compute platform in the vehicle,

768.42 -> and a lot of connectivity options.

770.48 -> You've seen Adam talking this morning about 5G.

774.52 -> There's also satellite connectivity

777.05 -> that might exist if you're going into remote places

780.73 -> and you need to manage all of that.

782.83 -> As you can see, it's a journey

784.82 -> that spans years even decade.

788.38 -> So when you have this trio,

790.44 -> remember of those three teams,

792.48 -> the hardware, the software, and the products,

796.05 -> one thing to take into account

797.51 -> is that the refresh cycle are different.

800.24 -> For example, for the hardware,

801.77 -> you're looking at a refresh of every two or three years,

805.41 -> and very similarly, to the smartphone

807.94 -> you have in your pocket,

808.9 -> you buy the hardware, which is the phone.

810.95 -> And then you change it, you know,

812.22 -> after one year, two year, three years or more,

814.54 -> but the software that is in your phone

817.05 -> is updated at a much quicker pace.

820.25 -> And so, knowing that,

823.21 -> we can design really a software architecture

826.52 -> to make sure that it can take advantage

829.17 -> of the hardware that is available,

831.3 -> but remain flexible as well,

834.17 -> to be able to evolve at the base

836.55 -> of the hardware in the future.

839.63 -> So now I'm going to talk about

841.87 -> what would be the software architecture

843.95 -> for software-defined vehicle,

846.86 -> putting those principle to use.

850.4 -> The first thing is that you will have

852.61 -> the hardware of the vehicle at the bottom.

855.91 -> And then the first layer is the signal abstraction layers.

860.14 -> So the ability basically, to turn any sensor

863.23 -> and actuator into the vehicle, into an API,

866.25 -> to consume data from the vehicle signals

870.57 -> also be able to write to the activators

874.16 -> and normalizing, you know,

875.43 -> some of the data to expose it to compute.

879.3 -> And so, we also have a compute obstruction module,

882.64 -> which mission is going to be to run the compute workload.

886.57 -> And in vehicles, there's many different level

888.95 -> of safety that are involved.

890.87 -> So the implementation of the computer

894.5 -> might take different form

896.23 -> to conform with the different safety.

899.3 -> So for example, it can be native processes

901.73 -> all the way up to the use of containers.

904.77 -> And as you might know, running containers,

907.66 -> you can do that multiple ways.

909.79 -> You have, if you take the example

912 -> of what's available on the cloud with Fargate,

914.26 -> it's very serverless.

915.3 -> You don't see any of the underlying hardware,

918.27 -> but you could also run different orchestrator,

921 -> Kubernetes, lucky guess.

923.13 -> And so this module will, you know,

925.31 -> make it easy to deploy workload to the vehicle.

929.49 -> Next step, is machine learning.

931.4 -> There are a couple of optimization that have to be done,

935.08 -> making sure that if the vehicle has GPU,

938.02 -> you can make use of those.

940.31 -> Compile new machine learning models.

942.03 -> So it's accelerated, but also pooling resources.

946.1 -> So instantiating one machine learning model

948.52 -> that can be used by multiple workloads to save on resources.

953.01 -> And there's also optimization to the tool chain here

956.26 -> and for developers to help.

957.98 -> For example, gather the feedback on the prediction

960.79 -> that you've made and send that to the cloud,

963.7 -> to measure the drift of your model and have retraining.

968.14 -> Looking further ahead into the future,

970.17 -> it's in that module that you could handle things

972.16 -> like federated learnings, for example.

976.29 -> Then you have operations.

977.49 -> This one is pretty traditional in software architecture,

981.87 -> making sure you can get the log of the systems,

983.84 -> but also metrics on the performance

985.98 -> on how the components are doing and enable debugging.

990.77 -> Personal assistance to have a layer

993.17 -> of abstraction integrating with

995.44 -> multiple personal assistant in the markets,

997.81 -> such as Amazon Alexa.

1000.77 -> Vehicle connectivity, again,

1002.31 -> to handle all the different types of connectivities.

1005.12 -> So, this will go from Bluetooth, wifi.

1008.89 -> If you're in the home to 5G in urban environments,

1012.41 -> satellite in remote environment.

1014.8 -> How do you make sure that you give

1016.71 -> the best connectivity option to a workload?

1020.05 -> What are the latency requirement of that workload

1023.3 -> that modules will end on that arbitration

1026.48 -> also will enable you to control your costs?

1030.14 -> Because maybe, you know,

1031.3 -> if you have wifi accessible,

1032.93 -> it's gonna be cheaper to use that

1034.063 -> than the 5G that is also accessible

1037.4 -> and make it seamless for the application.

1040.02 -> Security integration, where the hardware security modules

1043.36 -> to hold the private keys of certificate

1045.86 -> to provision the identity of the vehicle.

1048.78 -> And also of course, security is job zero at AWS.

1052.36 -> So that goes across the board.

1057.57 -> And then we have the data communications,

1059.47 -> which is the gateway to the cloud

1062.58 -> and to the connected backend.

1064.35 -> So this is where we have telemetry,

1066.73 -> exchange of information, also common and control,

1070.26 -> and Henrik has few example of what

1073.15 -> common and control would look like.

1075.97 -> And then the next three counterparts

1078.01 -> mainly, of what exists in the vehicle.

1081.08 -> And then analytics, analytics is really important.

1084.22 -> That's where you will have your databases

1086.418 -> data warehouse, lake house, data lake, as well,

1090.76 -> and make use of the data for the rest of the company,

1093.99 -> but also sharing that data

1096.21 -> to other parties outside of the company.

1099.09 -> So you can look at things like monetization of the data.

1102.79 -> Pipeline will encompass building

1105.97 -> the different type of software that exists in the vehicle.

1108.62 -> And there's gonna be a lot of

1109.61 -> different types here to handle,

1112.66 -> but also keeping track with a graph database.

1115.96 -> For example, the software components

1118.74 -> that are deployed to this specific vehicle.

1121.28 -> Which version are there of those different components.

1125.9 -> Tools will be extremely important.

1127.44 -> That's where it all comes together.

1129.26 -> So for example, if I'm a data scientist,

1131.93 -> I want to create a new machine learning model.

1134.41 -> I can access a unified data catalog off the vehicle.

1138.86 -> And then I see that maybe the parameters

1141.91 -> that I want is not available in the data lake

1144.96 -> because it exists,

1146.13 -> but it's not being collected at the moment.

1148.58 -> While tooling, the right tooling can empower me

1150.92 -> just to make that request.

1152.56 -> And then software can be deployed

1154.27 -> through the pipeline to the vehicle.

1156.09 -> So that then the data communication

1157.8 -> and the computer abstraction now is recording,

1160.54 -> getting that data from the vehicle,

1162.26 -> sending it to the cloud.

1163.29 -> and then I see it appear in my data lake.

1167.84 -> And finally integrations of,

1169.63 -> we mentioned with the web mobile application,

1172.99 -> but also manufacturing with ERP system

1176.03 -> or the rest of the supply chain.

1178.6 -> And again, security all the way.

1181 -> So in this session, as you see,

1182.69 -> the scope is very broad for software-defined vehicle

1185.65 -> and it's very deep as well.

1187 -> So we're very aware of that.

1189.43 -> This session is really focused more on the IoT services.

1193.27 -> So we'll talk more about the data communications

1196.73 -> and Henrik in a few minutes,

1198.61 -> will give you very good overview

1203.18 -> of using AWS IoT Core

1205.8 -> and going into more details there.

1209.52 -> So zooming onto the vehicle here,

1212.84 -> you can see on the left side,

1214.71 -> the use of Ivy.

1216.53 -> So IVY's products that is co-developed

1219.53 -> by AWS and BlackBerry.

1222.36 -> And for the purpose of this session,

1224.12 -> you can see it as a way to get access to vehicle signals,

1228.84 -> process them, with or without machine learning,

1232.17 -> and then create an insight out of that.

1234.4 -> The result of the processing, basically.

1236.86 -> There's gonna be a chalk talk dedicated to Ivy tomorrow,

1240.03 -> AUT307 If you are curious and wants to learn more

1244.24 -> and otherwise I invite you also to go online

1246.69 -> to learn more about it.

1248.76 -> So, now let's say that we have useful information

1251.9 -> and that has to make its way out to the cloud.

1255.04 -> There's a few different routes.

1256.61 -> The first one, is just integrating

1258.9 -> with a telemetry solution that might already exist.

1263 -> As you've seen it on the hardware diagram.

1266.05 -> It's a journey that will take years.

1268.03 -> The software architecture is the same thing

1271.03 -> and OEMs automakers are different places.

1274.71 -> So some already have already some of those modules.

1278.23 -> So that's why it's an integration here

1280.73 -> with something that already exists.

1282.81 -> Could be also using the AWS SDK.

1285.45 -> They're open source.

1286.96 -> And they're already includes some of the mechanism

1290.03 -> that you would have otherwise to code yourself.

1292.81 -> Like we try logic with exponential backoff,

1295.82 -> they're updated as well by the AWS teams.

1298.65 -> So really it's there to give you

1300.61 -> a leg up in the development,

1302.52 -> but their use is optional.

1305.802 -> And then the option that was launched today

1309.72 -> is AWS IoT FleetWise.

1312.68 -> So again, a way to capture vehicle signals

1316.38 -> from the vehicle and upload that to the cloud.

1320.11 -> And so on the cloud side now,

1321.4 -> you have a different couple of option

1323.31 -> to handle your data communications.

1324.89 -> The first one is kind of do it yourself.

1327.37 -> You know, on top of EC2, you could create your own broker.

1331.35 -> Of course, in this approach,

1332.55 -> you have to manage the high availability,

1335.46 -> high scalability, yourself,

1338 -> the security and the updates.

1340.3 -> So it's a lot of work, operationally.

1343.52 -> You could deploy a open source broker

1346 -> that exists out there on top of EC2.

1348.46 -> You could also look at other services

1350.45 -> that we have that are bit more managed.

1353.67 -> You would still have to handle

1355.23 -> the scalability still in that configuration.

1358.65 -> So for those who wants to go fast

1361.41 -> or wants to have a service that handles for you,

1364.89 -> the scalability, the availability, the security,

1367.92 -> then AWS IoT Core is the right choice there

1371.6 -> and supports multiple transport protocol.

1375.01 -> What is usually used in those architecture,

1377.15 -> MQTT, HTTP and WebSockets.

1381.24 -> In addition now, if you wanna go further

1383.33 -> into the management,

1384.163 -> AWS IoT FleetWise will enable you

1387.04 -> to extract data from the vehicle

1390.18 -> by configuration of the agents.

1393.31 -> So it's adding value there.

1399.2 -> And then just to mention a couple of other services,

1402.65 -> if you have to handle different types of data

1405.2 -> that turn between control,

1408.19 -> if you have to handle sound or video,

1411.86 -> for example, video you might want to

1413.75 -> take a look at Amazon Kinesis video streams to do that.

1418.19 -> And the last piece is the integration.

1420.78 -> Again, there to integrate with a web mobile application

1425.79 -> and the rest of the backend as well.

1430.7 -> And so now want to do a little bit of a zoom on IVY

1435.4 -> and AWS IoT FleetWise and take a use case

1438.98 -> to do so to show you how they could work together.

1444.08 -> So here in our vehicle, we have

1445.92 -> the AWS IoT FleetWise agents already deployed.

1449.67 -> It can collect sensor data,

1451.67 -> then send that to the cloud.

1454.35 -> One thing could imagine in combining IVY

1457.23 -> and AWS IoT FleetWise is that

1459.74 -> if you wanted to do scene detection, for example.

1462.34 -> So let's say you're interested in detecting

1464.73 -> when there is a stop sign on the road

1467.64 -> because you're building a map.

1469.51 -> So you could have IVY doing all the computer vision

1472.8 -> on the frames of the camera here

1474.81 -> to make that detection and then send that insights

1478.42 -> to AWS IoT FleetWise so it can make its way to the cloud.

1482.08 -> So that's one way they're complimentary.

1484.72 -> That's not all,

1485.6 -> you could also use IVY as a trigger

1490.04 -> to tell AWS IoT FleetWise now start

1493 -> the collection of data because there's something

1495.24 -> that I've detected on the road, for example.

1498.69 -> And the last one is,

1500.42 -> using one of the FleetWise capabilities.

1502.81 -> It's just to sample the data coming from vehicles.

1506.23 -> If you have a fleet of vehicles,

1508.17 -> let's say they're all, you know,

1509.7 -> in the same location on the highway,

1512.57 -> maybe you don't want to have all those messages

1515.49 -> going to the cloud.

1516.323 -> You can use FleetWise to kind of sample only,

1519.67 -> you know, few cars giving you that information

1521.78 -> if they're in the same location, for example.

1525.04 -> The rest of the architecture here

1527.06 -> is just really to handle that use case.

1530.58 -> So nothing very specific here.

1532.91 -> You have the use of machine learning, operation,

1536.29 -> it could be other services here.

1537.87 -> It's just an example.

1539.28 -> And then some OTA capabilities

1541.27 -> that can be done a different way as well.

1545.01 -> And so what you see here is that

1546.84 -> we're releasing more and more,

1548.117 -> and you might have heard that from Adam this morning,

1550.67 -> more and more services

1551.65 -> that are tailored to industry vertical.

1554.77 -> And so IVY and AWS IoT FleetWise,

1557.44 -> they're really example of that.

1560.15 -> As you see, you know, we're trying to help

1562.26 -> into that map of software-defined vehicle.

1565.31 -> You've seen that there's a lot of modules there,

1567.18 -> so you can expect from us, you know,

1569.43 -> further help in the years to come

1571.55 -> and also additional services that are,

1573.85 -> will be tailored to the automotive industry.

1578.07 -> And with that, I'm gonna hand it off to Henrik.

1581.89 -> Thank you.

1586.59 -> All right, thank you, Michael.

1588.53 -> My name is Henrik Stromberg.

1589.88 -> I come from a company called WirelessCar.

1593.82 -> Where WirelessCar is making backend solutions

1597.22 -> for connected vehicles.

1598.78 -> And we're based in Gothenburg in Sweden,

1601.54 -> with 100% automotive focus.

1604.22 -> Although the connected vehicles is pretty new.

1606.16 -> We've been doing this since 1999, so we have almost,

1610.72 -> or more than 8 million connected vehicles in our systems.

1614.91 -> And we're located worldwide in more than 85 markets.

1620.94 -> So, we have a lot of customers.

1623.13 -> We have Volvo cars, Mercedes-Benz, Subaru,

1628.17 -> Jaguar, Land Rover, and so on,

1630.12 -> but I'm here to tell you to talk about

1632.13 -> what we do with Volkswagen Group.

1634.13 -> And that's the customer I've been working with

1636.04 -> for a couple of years now.

1637.53 -> And I'm gonna look into a little bit

1640.03 -> what we're doing with them.

1642.35 -> So Volkswagen Group, that's a huge company.

1646.3 -> They have 662,000 employees

1650.2 -> and 2020, was a bit of a downturn

1652.383 -> for the automotive industry,

1654.21 -> but they still produced 9.2 million vehicles.

1657.92 -> And they're not only produce Volkswagen vehicles,

1660.05 -> they have brands like Audi, Skoda, Seat,

1664.193 -> Lamborghini, Bugatti, Bentley, and a few others.

1668.02 -> So it's really, really big.

1670.44 -> It's based in Volksburg in Germany, of course.

1674.17 -> And then but they have 118 production sites worldwide.

1678.21 -> So, really, really, really big.

1683.02 -> So what are we doing with Volkswagen WirelessCar?

1685.87 -> Well, the business goals and the challenges

1687.81 -> that we have is that we were asked to provide

1690.77 -> a backend solution for the connected vehicles

1693.04 -> or connected services for the vehicles

1695.23 -> that are based on their latest platform.

1697.8 -> And their latest platform is the electrical platform.

1700.49 -> They're going almost all in on electrical vehicles.

1703.52 -> It's called MEB.

1706.12 -> I don't know if you know,

1706.953 -> but they have vehicles such as the ID3, ID4.

1710.09 -> (Henrik coughs)

1711.03 -> Excuse me.

1712.02 -> Audi has the Q4 E-tron,

1714.75 -> Skoda has the Enyaq,

1716.43 -> and there are many, many more models to come also,

1719.35 -> in the coming years.

1720.29 -> And there's more already.

1724.53 -> When you're developing a backend or a connected solution

1728.32 -> for the vehicles security,

1729.82 -> like Michael mentioned is of the utmost

1732.12 -> or Ritu sorry, utmost important.

1735.2 -> Security in the vehicle.

1736.91 -> Secured in the communication to the cloud.

1739.55 -> Security in the cloud.

1741.28 -> Data protection, that's really, really important.

1744.41 -> And also a breach of security in a vehicle

1747.63 -> could potentially be far more serious than other areas.

1752.16 -> Like, if the volume of the radio turns up to max,

1755.03 -> that could be really, really dangerous,

1756.48 -> if it's done suddenly.

1759.61 -> Also another challenge or something you have to consider

1762.01 -> is the variability.

1762.97 -> And when I say variability,

1764.41 -> I mean variability in number of vehicles over the years.

1768.15 -> There's many, many millions of vehicles

1770.42 -> that are gonna go on this platform.

1772.84 -> Variability in the number of services

1776.01 -> and the scope that these services will actually have

1779.53 -> during the lifetime of the vehicle.

1781.54 -> Variability over the day in traffic patterns.

1786.67 -> So that's something that your architecture

1788.63 -> and your way of working needs to be able to handle.

1791.94 -> And lastly, also requirements.

1794.39 -> Developing a car, it takes three, four years

1797.85 -> to develop a new car and you develop the software

1800.28 -> alongside the hardware and the wheels

1802.23 -> and the steering wheel and the roof and all that.

1805.98 -> But the requirements in the beginning of such a cycle

1808.05 -> is going to be different than what you end up in the end.

1810.99 -> So you need to be able to handle this changing requirements

1813.44 -> along that way, kind of in an agile way.

1815.41 -> Even though developing a car is pretty much

1818.44 -> a waterfall in other aspect.

1821.03 -> So that's something that we need to handle when we do this.

1824.64 -> So you mentioned a little bit about

1828.21 -> what connected services are.

1829.98 -> I'll give you some examples of what we have.

1833.25 -> The ones that are end-user visible.

1835.08 -> We have about 50 different services

1837.633 -> in this backend for Volkswagen,

1839.3 -> but these are the ones or some of them ones

1842.25 -> that you can see as an end user.

1843.45 -> EV services, electrical vehicles services,

1846.45 -> these are some screenshots for the app.

1848.17 -> You can view the range of the car,

1849.98 -> the state of charge,

1851.42 -> the temperature in the car.

1852.71 -> So basically, a remote view of your vehicle.

1857.06 -> You can control the vehicle a little bit.

1858.88 -> If you wanna start the charging

1860.64 -> at a different point in time

1862.07 -> than when you actually plug in the cable,

1864.29 -> you can do that by controlling it.

1865.97 -> Setting it on a schedule,

1867.61 -> or my personal favorite,

1869.39 -> now when it gets cold outside,

1872.06 -> well, not here in Vegas,

1873.07 -> but in Sweden where I'm from,

1874.62 -> we're having a foot of snow actually right now.

1877.8 -> Preheat the car.

1878.9 -> When you get out in the morning,

1879.81 -> going to work, it's nice and cozy.

1881.98 -> That's a really killer thing.

1886.4 -> But other things like your status of your vehicle.

1889.23 -> Check if it's locked,

1890.09 -> did I lock it when you left it.

1893.3 -> Find it, if you forgot where it's parked.

1895.71 -> But also get dashboard information

1899.48 -> about warning lights in the dashboard.

1901.33 -> You get that to your app.

1903.22 -> Or things like roadside assistance.

1905.04 -> If you have a breakdown and you call the call center

1907.72 -> and they get data about your vehicle.

1909.33 -> What's wrong, where it is,

1910.96 -> and they can do the appropriate things that need to be done.

1913.79 -> So that's just some of them,

1915.17 -> but there's plenty of plenty more, of course.

1918.86 -> So how do we do this?

1920.7 -> Of course we use AWS.

1924.09 -> Like I mentioned, we have about 50-ish

1926.47 -> different types of services.

1927.81 -> So we have divided those into a microservices architecture.

1932.68 -> What's really important for us,

1933.93 -> is you should try to keep these services separated.

1938.23 -> Working in a service isolation manner.

1940.68 -> We want to have as little dependencies

1943.11 -> and as little impact between these services in runtime.

1947.23 -> Because if there's a failure in one,

1949.15 -> we don't want the other service to be impacted.

1953.56 -> We're using a lot of asynchronous and event-driven patterns,

1956.91 -> to be able to handle

1958.07 -> the variability in traffic load really.

1961.02 -> We'll see an example of that later on.

1964.53 -> The picture to you right here, is a typical service setup.

1968.78 -> It's not entirely like this for all the services,

1971.27 -> but it's a blueprint really.

1973.77 -> We're going pretty much all serverless.

1976.75 -> And the core here in the communication

1978.93 -> with the vehicle is the IoT Core.

1982.24 -> Most of the communication is done over MQTT

1985.91 -> and we're having hundreds of thousands of cars already.

1988.95 -> We've been live for a little more than a year,

1992.04 -> but for seeing of course, millions of cars being connected.

1994.78 -> And these cars are connected 24/7, pretty much.

1999.02 -> They're communicating over MQTT, as I said.

2002.87 -> Protobuf as the payload.

2004.904 -> Protobuf is binary format, which is very small,

2008.04 -> makes the messages small,

2009.45 -> but it's also extensible into the future.

2011.92 -> You can add things to that protocol

2014.97 -> without impacting the vehicle, software in the vehicle.

2017.91 -> And that is really important because over time,

2020.23 -> your services are gonna evolve

2022.88 -> during these 10 and 15 years.

2024.33 -> And you wanna maintain as few versions of the software

2028.23 -> in the backend or a few versions of the payload format

2031.73 -> for easier life cycle management, really.

2035.56 -> Once the messages get into the backend,

2037.45 -> we, the main business engine is run by AWS Lambdas,

2043.56 -> using integrations like SQS, SNS, Kinesis,

2047.87 -> persistence in dynamos.

2049.8 -> And then these services can expose that data

2051.92 -> to apps or backends for apps,

2054.72 -> where we have the API gateways, mostly,

2057.93 -> over standard protocols,

2059.09 -> like HTTP with JSON payload.

2062.43 -> So this is a very typical blueprint,

2066.04 -> the services that we have.

2067.55 -> And it's built for scale, really.

2070.66 -> Scale and variability.

2073.47 -> So I'm gonna go through a couple of flows

2076.56 -> that we have on a pretty high level,

2078.16 -> but still, that is necessary

2081.15 -> in order to achieve all this.

2084.28 -> First of all, we need to be able to register a car,

2088.49 -> add a thing, add a car,

2090.54 -> and that is done by cars

2092.26 -> sending certificate signing request to CSR,

2095.08 -> to the backend saying,

2096.4 -> hey, I wanna be part of this ecosystem.

2098.82 -> And we validate that CSR and sign it

2102.23 -> to create a certificate.

2104.29 -> As a result of that, that certificate

2106.05 -> goes on to the IoT Core to create a thing.

2108.48 -> So this certificate identifies this car, individually.

2113.04 -> We create alongside with this,

2114.83 -> what we call an external ID.

2116.78 -> And an external ID is also being part of the policy

2119.97 -> that sets up the MQTT topics

2123.55 -> so that we have topic structures

2125.26 -> for both published and subscribed messages.

2128.05 -> And this means that each vehicle has its own set of topics

2131.6 -> so that they can communicate with vehicles, individually.

2135.46 -> And this is really important, of course.

2138.5 -> Once that is done, the certificate

2139.99 -> is returned to the vehicle.

2141.22 -> And then the vehicle can use that

2142.72 -> to connect to the IoT Core,

2144.25 -> which then enables it to basically,

2146.5 -> receive and publish messages and information to the backend.

2152.55 -> So once that is done, we want

2155.55 -> to send the state of charge for the vehicle.

2158.04 -> I'm loading my car.

2159.46 -> I wanna see my app.

2160.61 -> What's the state of charge.

2162.42 -> The vehicle is connected to the IoT Core,

2164.38 -> sending an MGTT message to the backend.

2167.7 -> What we have them first is kind of not as simple Lambda,

2171.52 -> but it's a routing engine taking that message,

2174.5 -> looking at it and looking at

2176.29 -> who's the target service for this message.

2179.11 -> And then as I mentioned,

2180.48 -> the services are divided, individually.

2183.81 -> And typically, that message is forwarded to an SQS,

2187.44 -> which has picked up on a Lambda in the target service,

2190.666 -> which then does whatever it's supposed to do,

2192.93 -> store it, notify some subscribers or whatever.

2199.39 -> Pretty straight forward.

2201.67 -> Go in the other way around though,

2203.83 -> producing service to the right.

2205.57 -> I wanna send something.

2208.13 -> We wanna keep the producing service unaware

2210.36 -> of the communication protocols

2211.85 -> that we need to do with the vehicles,

2214.04 -> if that is to change.

2215.87 -> So it's sending its request to an API gateway,

2218.9 -> to this routing function that we have,

2221.29 -> which looks at the message and then figures out

2223.63 -> which topic am I gonna send it to.

2225.63 -> Also figuring out which vehicle mapping it

2227.59 -> to the external ID, as I mentioned earlier.

2229.65 -> Ending up on the IoT core,

2231.48 -> which then is responsible for forwarding

2233.69 -> that to the vehicle.

2236.08 -> So, yeah, very typical flow.

2242.21 -> During this journey, when we developed this,

2244.95 -> we also learned a couple of things.

2247.33 -> A couple of lessons learned here.

2250.95 -> I don't know if you remember, just two slides back

2253.67 -> the uplink flow here from the vehicle to the backend,

2257.69 -> We used to have it like this in SQS

2260.41 -> consuming message or getting the messages

2262.45 -> off of the IoT Core

2264.51 -> and then invoking a Lambda from there

2266.5 -> in order to be able to batch process messages.

2269.26 -> Then you can take 10 at a time,

2270.81 -> be a bit more efficient, save some money.

2274.33 -> However, the world is not really ideal.

2280.81 -> Usually, when you have this setup,

2282.52 -> there should constant stream of messages from the vehicles.

2285.64 -> So the backend is scaled appropriately

2287.54 -> to handle these messages,

2289.16 -> but even mobile network operators,

2291.32 -> MNOs, they have outages.

2293.75 -> So when we got an outage,

2295.83 -> the stream of messages, they stop coming

2298.43 -> and of course the backend adapts to that, scales down.

2302.571 -> But then what happens when the vehicles

2304.34 -> then regained that connection,

2305.73 -> they have pile up a lot of messages

2308.19 -> and they're all flushed hundreds of thousands of vehicles

2311.33 -> sending many messages at once

2313.24 -> to the IoT Core, no problem.

2316.8 -> Then we ran into a challenge about

2319.27 -> scalability or speed of scalability,

2321.27 -> really elasticity when the Lambda

2323.66 -> was going off of the SQS.

2326.64 -> And when you couple that

2328.18 -> with some vehicle behavior resending messages,

2330.81 -> when it didn't get response quickly enough,

2333.51 -> then what happened was that the SQS was just getting

2336.83 -> more and more and more and more messages.

2339.45 -> And they were not really consumed

2341.07 -> quickly enough for that case.

2343.21 -> So we changed the architecture and to this,

2346.14 -> we removed that SQS and had the Lambda being invoked

2348.82 -> directly from IoT Core, which scales quicker.

2352.5 -> Little bit less efficient from a cost perspective,

2356.34 -> but it handles it does what it's supposed to do.

2360.19 -> And we know that, that architecture

2361.75 -> will probably have to change going forward,

2363.37 -> maybe looking into Kinesis.

2364.76 -> And so I'm looking, I was really thrilled this morning

2367.87 -> when I heard this serverless Kinesis thing,

2369.96 -> that there was a good thing.

2376.29 -> Going forward, this one is something

2379.09 -> that is really good for us

2381.36 -> really to reduce runtime dependencies.

2385.32 -> And what I mean with that is be kind,

2388.5 -> really be nice when you're running serverless

2390.98 -> or in the cloud,

2392.35 -> you basically, have all the resources

2395.03 -> that you need whenever you need it.

2396.87 -> And if you have a dependency or using a downstream service,

2400.11 -> you can really just overload them really, really easily.

2404.35 -> So you need to be nice.

2405.71 -> And a couple of ways of doing that

2407.9 -> is to keep local copies of the mostly used data.

2411.49 -> If you don't really need

2412.83 -> to go somewhere else to get something,

2415.21 -> keep a local copy.

2416.49 -> And maybe even caches of some things.

2420.75 -> And one thing was almost a funny story, now in hindsight.

2425.28 -> Before we went live during development,

2426.89 -> we were running some game-based load tests jointly

2429.46 -> for all the services in the backend.

2434.12 -> Represented here by S1, S2 and S3, different services.

2437.43 -> They were getting a lot of requests in the load test.

2440.52 -> So what happens then is that the Lambda starts scaling up

2443.541 -> in vocations, all of these Lambdas they need a token

2447.86 -> from the identity provider.

2449.69 -> So they all went there.

2451.09 -> And when you scale up all these,

2452.91 -> they were just drowning that IDP.

2454.93 -> So the IDPs was overloaded, stopped responding.

2459.62 -> These Lambdas were sitting there waiting for the response,

2463.14 -> requests were still coming in,

2464.5 -> more concurrency of the Lambdas were starting up,

2468.49 -> so it ended up we brought down the IDP,

2470.97 -> we exhausted all the resources in the account.

2473.886 -> Basically, the whole thing came to a stop.

2476.79 -> So, okay, what we'll learn was

2479.43 -> keep a local copy of the mostly used data.

2482.16 -> Download that token and keep it for that service, locally.

2486.93 -> Even if you have serverless,

2488.64 -> which is supposed to be stateless.

2490.23 -> So you pick it up from a local database

2491.84 -> instead of going to the IDP.

2493.75 -> And then instead of getting thousands of requests

2496.32 -> to the IDP, they got like 30, 40, so a lot easier.

2500.49 -> So this is one way of reducing those dependencies

2503 -> I was talking about earlier.

2505.75 -> And of course, fail fast.

2507.24 -> Everybody says that if you know that your service

2510.37 -> or the something that you're contacting usually

2512.72 -> responds in 200 milliseconds,

2514.97 -> don't stick around for 30 seconds.

2516.73 -> It's not gonna be worth it.

2518.63 -> So, that has really served as well

2522.1 -> in trying to reduce those runtime dependencies.

2528.81 -> Third lesson, not too late,

2532.13 -> but this is something that is also promoted by AWS,

2534.91 -> when it comes to how you organize your accounts.

2538.54 -> Have service accounts.

2539.97 -> Like I mentioned, we have about 50 services

2543.37 -> and in the beginning, or if you don't split them

2546.87 -> into different accounts,

2548.06 -> you're gonna have all these services

2550.08 -> competing for the resources in the accounts.

2552.55 -> When you run serverless,

2553.6 -> you have limits on the account level,

2555.2 -> which is really a good thing

2556.38 -> because otherwise you could get broke really quickly.

2560.26 -> But all these services are not used equally.

2562.44 -> So if you have here two different services,

2564.24 -> you have the orange service,

2565.073 -> you have the purple service.

2566.71 -> And the orange service, if it's used a lot,

2568.96 -> it could really exhaust the resources

2571.82 -> in the account from the purple service,

2573.58 -> basically, becoming a noisy neighbor.

2576.51 -> And that's what you want to avoid.

2577.94 -> You wanna guarantee that you have the resources

2579.83 -> that you want when you need it,

2582.306 -> but you still don't want to impact other services.

2584.97 -> So by doing that, by putting those services

2587.26 -> into different service account is really, really good.

2594.87 -> Now, looking ahead a little bit

2599.41 -> with the journey we have done,

2601.94 -> but also start off by looking back.

2604.48 -> I must say, I think that serverless

2606.937 -> has served us really well.

2608.68 -> We have been able to focus on the business logic

2612.3 -> to add user value,

2614.8 -> instead of focusing on managing databases

2617.29 -> or queues or load balancing or fail overs,

2622.02 -> that's all taken care of.

2623.26 -> So from that perspective,

2624.48 -> I think it works really, really well.

2629.11 -> Going forward though, in this industry,

2632.42 -> I would say a lot it's about scalability and scaling.

2636.52 -> There's new services, new vehicles,

2639.65 -> increased demand for traffic and data.

2642.27 -> So your backend really needs to scale.

2646.61 -> And yeah, coupling that also with cost management,

2651.9 -> just scaling you see,

2653.14 -> well, not easy, but it's,

2655.42 -> you got to do it efficiently or cost efficiently.

2659.08 -> And that means that the architecture

2660.58 -> might have to change along the way

2662.41 -> because some architecture or one architecture

2665.67 -> might may be cheaper today.

2667.27 -> But as the scaling grows, as it takes more traffic,

2669.59 -> you may need to transition into another one,

2672.46 -> to keep the optimal cost level.

2675.22 -> So that's something that's constantly overlooked

2678.21 -> when doing these backend solutions.

2681.8 -> And the third one really, service efficiency.

2684.26 -> And I'm not talking about

2685.18 -> the code of the services that you have,

2687.8 -> but really how they actually work with other services.

2692.63 -> Do I need to make that extra request over here?

2695.47 -> Can I scale down a little bit in order to be able to scale

2700.06 -> the way you want or handle the traffic

2702.21 -> from the vehicles that you want?

2704.01 -> Like I said, data transfer is expensive.

2706.37 -> You wanna keep it to a minimum,

2707.92 -> but not less than you actually want or need.

2711.12 -> So that balance the efficiency services

2713.65 -> efficiency in that balance.

2717.96 -> All right, thank you.

2720.532 -> (audience applauds)

2728.07 -> So thank you for the time today.

2731.3 -> We do have some time for some questions.

2732.83 -> So, you folks have questions.

2734.7 -> We can take them now.

2739.969 -> [Audience Member 1] I have a question about cost.

2742.24 -> Where do you see the cost landing?

2744.12 -> Like with the car manufacturers, the fleet, the consumer?

2748.165 -> (indistinct)

2755.967 -> So, I can repeat the question.

2756.833 -> I think the question is about the costs.

2758.92 -> Like, where does the cost land.

2760.74 -> Does the cost land with the consumer, with the fleet,

2763.26 -> with the car manufacturer and so on?

2766.2 -> And Henrik, do you have an opinion on that?

2768.12 -> I think it's going to vary a bit,

2770.1 -> depending on what kind of services that you actually offer.

2773.92 -> Some are definitely gonna be taken

2775.81 -> by the car manufacturer

2777.38 -> because they are the ones who are interested in that data.

2780.87 -> Whereas other services is something

2783.3 -> that you sell to your end user

2785.68 -> and then you can incur that cost to them.

2788.33 -> So I think it's going to be a variance of here.

2792.691 -> [Audience Member 1] Thank you.

2794.962 -> There's a question in the back.

2796.756 -> [Audience member 2] (indistinct)

2847.26 -> Do you wanna repeat the question first?

2849.44 -> Yeah, so I think your question was around connectivity.

2853.44 -> And so, if there's an accident that happens

2858.1 -> or like an event like that,

2859.5 -> how can you leverage different connectivity options

2863.56 -> and also how do you make sure the data

2866.06 -> is not lost if you're keeping sending it?

2868.91 -> Is that?

2871.831 -> Yeah, you're absolutely right.

2873.36 -> I think when we talked about it,

2875.38 -> it was like sending data continuously,

2878.27 -> but you can, the first answer is that

2881.72 -> you could also have some of that data keep being local.

2887.51 -> If you don't need to send it straight away.

2890.19 -> That's why we have compute elements on the vehicle,

2893.68 -> like IVY, for example.

2894.77 -> So you could detect a collision

2897.46 -> and then you could keep a buffer locally.

2899.56 -> That just like writes over.

2901.61 -> And then if you detect like the right,

2903.08 -> even you could tell the buffer,

2904.58 -> okay, no not that one, like, that's the snapshot

2906.61 -> that we'll keep there.

2908.31 -> Now, if you also want to send that

2911.32 -> to the cloud with that collision,

2914.74 -> then you can do that through different connectivity options.

2917.59 -> I think you also mentioned like different SIM cards

2920.28 -> and things like that.

2921.113 -> So absolutely like you would look at what's available,

2924.09 -> again, with the latency requirements that you have for that.

2928.44 -> And I think it would be very important

2930.55 -> depending on the use case to really size well,

2933 -> like the snapshot that you would take

2934.51 -> for like a collision, for example.

2936.27 -> Like what's important to you

2938.26 -> and then you can also make sure that yeah,

2939.86 -> you have different connectivity option to do that.

2943.048 -> [Audience Member 2] (indistinct)

2983.32 -> Yeah, absolutely.

2984.47 -> And so just to repeat for the other people in other rooms,

2989.5 -> that cannot hear you.

2990.51 -> You would have also like different SIM cards there

2995.19 -> and like you mentioned, luxury cars also,

2998.4 -> they're usually they're more capable.

3000.25 -> So you can also augment like the availability

3003.21 -> of the connectivity options with all the cards.

3010.084 -> There's a question here.

3012.739 -> [Audience Member 3] The diagram of the car (indistinct)

3031.164 -> So if the car is sending frequent messages,

3034.07 -> could it maybe just check to see

3037.51 -> if there is anything waiting in a message box.

3043.66 -> Queue?

3044.515 -> [Audience Member 3] (indistinct)

3063.907 -> Did I get your question right?

3067.21 -> If it would be more having a buffer in the car of messages,

3070.58 -> is that what you said?

3072.283 -> [Audience Member 3] So here,

3074.62 -> all the messages are coming in frequently

3076.38 -> but when we're sending back messages also frequently?

3080.503 -> Does it happen at the same scale?

3085.077 -> So the question was if the uplink

3088.22 -> from the vehicle and downlink messages

3090.03 -> are as frequent.

3091.53 -> No, I would say that the car,

3092.82 -> usually my experience is that the car,

3094.41 -> usually sends more messages than it receives.

3097.088 -> [Audience Member 3] So maybe (indistinct).

3103.87 -> I would say they're different things.

3106.71 -> There's not really a request and response in general.

3111.43 -> So the vehicles kind of handoff information,

3114.15 -> which you wanna process and maybe forward

3115.92 -> to other interested parties.

3118.17 -> And then as a result of that,

3119.5 -> there may be things happening.

3120.73 -> And then there's a message going back,

3122.56 -> but not far from always.

3124.62 -> So, yes.

3128.741 -> [Audience Member 4] So beyond the access control

3130.72 -> from a security perspective,

3132.526 -> we implement other security protocol.

3138.237 -> At which level of the security protocols?

3141.26 -> [Audience Member 5] So you illustrate this particular,

3144.41 -> (indistinct) in order to provide access control.

3148.803 -> Right.

3149.636 -> [Audience Member 5] But there is a confidentiality

3151.578 -> of information.

3153.678 -> There's a probability of service.

3155.618 -> There are other security attributes

3158.19 -> And the question is,

3159.414 -> are this somehow implemented (indistinct).

3162.717 -> So the question was,

3164.2 -> if there are other security attributes

3165.75 -> in just the authentication with the certificates.

3168.344 -> Yeah, of course, there's also payload encryption

3171.28 -> within that.

3173.43 -> And then everything is encrypted in the backend.

3176.44 -> There's access control from a privacy perspective,

3180.39 -> which is really, really, really important in this industry

3183.74 -> because there can be really some really sensitive data

3186.25 -> like GPS positions that can be used in a not so nice way.

3191.04 -> So you really have to protect that data,

3193.63 -> both in the vehicle and in the backend.

3196.81 -> They're actually, I mean, it's quite common

3201.28 -> that you actually separate the different ECUs

3202.907 -> you were talking about,

3204.39 -> not knowing what the other ECUs are actually doing.

3207.53 -> So having an in-vehicle encryption of data,

3210.14 -> because you need to pass through a gateway or something,

3212.69 -> just to make sure if that ECU is compromised,

3215.98 -> you don't leak that data.

3217.7 -> So, there are a number of levels, definitely.

3221.87 -> And then I would add that even on the service side, right,

3224.14 -> there has to be security implemented

3225.87 -> in all of those services.

3226.99 -> So what access to the data each of those services have,

3231.01 -> and then there's also like if you have a fleet of cars

3234.4 -> in different countries and things like that,

3236.24 -> like what data you have access to

3237.87 -> or what data you don't have access to.

3240.07 -> So then, you know, security in the vehicle,

3242.79 -> security during the communication of that data

3245.32 -> then in the cloud,

3246.153 -> and then as the services are being invoked,

3248.39 -> what access to the database services have,

3250.98 -> I think security has to be implemented at all those levels.

3255.44 -> And then just add a little bit,

3258.56 -> the question about privacy and GDPR

3261.15 -> is that is taken really, really seriously.

3264.708 -> Yeah.

3267.085 -> Other questions?

3270.016 -> There's a question here.

3271.308 -> [Audience Member 6] Yeah, so you're trying

3274.42 -> to generate one set of topics (indistinct)

3279.67 -> It's quite interesting (indistinct).

3286.244 -> When you get to things like 8 million vehicles,

3288.837 -> do you find topic management (indistinct).

3293.64 -> Not yet, I mean, these topics are just a structure,

3300 -> which is one hard coded part,

3302.13 -> sorry question was,

3303.44 -> if there's difficulties in managing all the topics

3307.302 -> that we see.

3309.98 -> Not yet, the IoT core is able to handle these topics

3315.77 -> quite well I would say.

3317.16 -> I think they're more logical in that architecture, not sure,

3322.39 -> but what we're doing, we're having

3323.63 -> a certain set of topics structure in the beginning,

3325.997 -> and then you can add on for the specific services.

3329.58 -> So, no not really.

3337.96 -> Anything else?

3343.7 -> There's one more question here.

3345.611 -> [Audience Member 7] (indistinct)

3353.76 -> Yeah, it is.

3356.57 -> And well, basically there's a limit

3358.8 -> to the number of topics a subscription you can have

3362.42 -> per subscription or connected to it.

3365.51 -> So, but if you can do it,

3369.03 -> if it's okay for the client,

3371.35 -> you can do a wildcard subscription.

3373.17 -> So even if you have 200 topics per client,

3376.43 -> if you do wildcard subscription, it counts as one,

3379.66 -> which is quite handy.

3387.04 -> Great.

3388.08 -> Thank you everyone for your time.

3389.9 -> Hopefully you found the session useful

3392.17 -> and you could see how IoT Core, BlackBerry IVY

3396.5 -> and IoT FleetWise as well as other AWS services

3400.19 -> help to pull the connected automotive solution together.

3403.65 -> We're gonna stick around for a few minutes,

3405.24 -> if you have any more questions.

3406.35 -> Please don't forget to fill out the survey for the session.

3409.87 -> And again, thank you for the time today.

3412.35 -> Thank you, everybody. Thank you.

3414.027 -> (audience applauds)

Source: https://www.youtube.com/watch?v=wlzrpvSGQfM