 Hi everyone. Thanks for coming. Good morning. I hope the keynote sessions were exciting and engaging. I'm Megan Knight. I work for Amazon Web Services as the Senior Program Manager for Open Source IoT Automotive. And today we are going to chat about vehicle to cloud services with Automotive Grade Linux. So just a quick overview of what we're going to get into today. First we're just going to start off with really what is vehicle to cloud. It's a term that has been around for a few years now, but I don't necessarily think that everyone has a clear understanding or the same understanding of what it is, but there's many different ways that you can interpret it. So we're going to start there and then move into the role of V2C in modern vehicles and then spend some time talking about the AGL vehicle to cloud expert group and the body of work that we're doing there and how to get involved if you're interested in participating. So there are 400 million connected vehicles predicted to be on the road by 2025. That is a lot of cars and each one of those cars, I'm not great with the math, but per car per day is going to generate 25 gigabytes of data. So across those 400 million vehicles, that's quite a lot of data. Where is it going to go? And what are we going to do with it? These are some questions. Data standards are pretty imperative to efficiently reduce integration costs and complexity and being able to actually focus on the business value. So not collecting data for collecting data's sake and actually delivering value to both the OEMs and consumers, people purchasing the actual vehicles themselves. So what is vehicle to cloud? What we're talking about here is the seamless communication between vehicles and cloud providers, cloud-based platforms. So it's a two-way exchange, both from the car to the cloud and then back down from the cloud to the vehicle itself. And as vehicles become increasingly connected and software-oriented, the role of cloud in the vehicular environment continues to grow in its importance. So what can we do with that? How do we keep innovating with this concept and delivering that value? Let's take a look at some use cases. I'm a pretty visual person, so these tend to help me in understanding complex concepts. So collision avoidance, some of the new cars that are coming out will warn you. There's a car near you, don't swerve, and they'll actually take over the steering wheel and push you back into your lane. It's a weird sensation to get used to at first, but it's actually pretty amazing. And a lot of that is happening because of the cloud connectivity in those two vehicles. They're talking to each other and saying, hey, there's a car over there. Watch out. And then maintenance reminders, right? Real-time data from the vehicles can be analyzed in the cloud to predict potential issues, and it can also be helpful for scheduling things like oil changes, interpreting how hard of a breaker you are, and perhaps suggesting that you have maintenance that's required or scheduling something in the future for you, connecting directly to a dealership and being able to make that appointment for you. And then this one's one of my favorites, optimized route planning. So for gas vehicle users, this makes sense using real-time traffic data to be able to help you pick a fuel-optimized route. But this one is special to me because my dad and I used to take a lot of road trips as a kid, and we drove through a lot of middle America where the weather can change very quickly. And there's not a whole lot of options for driving. But now with the use of the cloud, they can overlay weather patterns with real-time driving and be able to provide you alerts of inclement weather that's up ahead. And we did have to pull over a time or two for tornadoes to go by just like this. So I would have loved a vehicle that could warn me and maybe say, hey, stop for some pancakes for an hour and let this weather pass. So I particularly like this example. So what's the big deal with cloud connectivity? Why is everyone seemingly talking about this now? Are we just collecting data to collect data? And what value does this actually bring to the OEM and the consumer? So there's three key components that I like to break down here. First, being safety. As we talked about in the last example, right? Enhancing features through real-time data exchange. It needs to be real-time to be able to avoid those things like collisions or being able to help take over with hard breaks. It also is helpful for efficiency. As we talked about with the optimized route planning and the predictive maintenance, right? Saving time and helping you with those reminders. We have a lot to keep up with these days. And I know car maintenance usually falls to the bottom of my bucket until it becomes an actual issue. So it would be very nice to have my car actually be able to help me with this. And for convenience, right? Remote start. Remote capabilities like having your environment already cooled or heated to your preferred temperature that's set in an app that's connected to the cloud. So no matter what vehicle you get in, you can have those settings auto-applied, right? This is particularly nice if you, say, live somewhere really cold or really hot. And it's nice to have that car safely warming up while being locked from the exterior. With all this data, though, you can imagine that there are quite a few challenges in collecting all of it, right? So data fragmentation and being the first one, right? A lot of folks are using their own formats. A lot of OEMs are having to manage this process themselves. They're having to create this process themselves, right? And so it does make it harder to generate fleet-based insights across different models of vehicles within even one OEM. And then as I mentioned, it's just a lot of data, right? So these vast amounts of data that are coming in, especially from advanced sensors like cameras, right? Actual images. For example, things like if you get in an accident and they can revisit the image of the point in which the car actually hit the object, right? Insurance loves this now. There was no, I didn't do it, when there's a picture of how this happened, right? But it increases the storage cost because there's just a lot more to store. So we need to be very particular in what we're actually storing and is it delivering value, right? And then data delays. Sometimes data comes in too late for people to actually mitigate fleet-wide problems, right? So if you're getting data three to six months after it was sent to the cloud, is that really going to deliver real-time value? Maybe not, right? So how do we combat the data delay? In our particular instance, we're really going to focus on this data fragmentation, okay? How do we get standard formats running between the vehicle and the cloud? So this is what brings us to the expert group. So the vehicle-to-cloud expert group's been around since 2021, 2020, and it's gone through a few evolutions, but all essentially trying to solve the same problem in a variety of ways, right? So if you attended either of the AGL automotive grade learning member meetings earlier this year, there were talks on this particular body of work at both of those conferences. We decided to take a pause after the June AMM and really evaluate the project, right? Is this delivering the value that we think it should be delivering? And is this the most collaborative way that we could be doing it, right? And so when we did that, we realized that no, it actually was not, and that there are things going on in the industry that we can leverage with a much more open and transparent mindset to help fuel innovation in a way that is directly supportive of consumers, eliminating that data fragmentation and also delivering value to OEMs because they're directly involved by providing feedback. So with that, we did decide to rescope, and as I mentioned, we are collaborating now with a couple other open source projects. So let's talk about those. So some of you may be familiar by now with Covisa's VSS, the Vehicle Signal Specification. Scott Murray here actually gave a talk on this earlier this year about the exciting things that that VSS is doing and why it's so important for the industry. I do encourage you to go check that out. It's on the AGL YouTube. But essentially, VSS is an industry-relevant data standard, okay, and it's developed as part of the Connected Vehicle Interface Initiative, which is a collaboration between Covisa and W3C. So they have a couple key objectives that really aligned with what it is we were trying to do, and that's why we realized it's best to collaborate and support this initiative, one being defining the definition of how to define any vehicle signals, right? We need to get on the same page of how to do that, and being able to structure them in a manner that we can all agree on, right? So this is this VSS model rules, okay, and it's how you formulate future vehicle signals and current signals, right? So it's a syntax. And then the second part is the definition of a proposed VSS standard catalog. So this is a catalog of vehicle-related signals that people can reference, right? Hey, I'm looking for this particular signal. I'm going to go to the catalog, and I'm going to look it up, and it's going to follow a syntax that I'm already familiar with because they all do, right? So just a standardization all around. Very nice. So as I mentioned before, the current state is really OEMs creating their own specifications and how they deal with certificates, vehicle identity, messaging, protocols, all semi-specific to a particular automaker, right? And within that, it can create organizational silos. So even between departments within the same auto manufacturer, they can have data fragmentation and incompatibility with how they share data between teams, right? So this creates complex interoperability challenges across the fleet. And it also, as you can imagine, with complexity increases time and money, which we're all trying to save in both. So to reduce costs and enable scale and realize new features, right? Using VSS is going to be able to help us do that. So by creating those open standards that we can all agree upon, right, and are all working from, it allows much more interoperability both between teams within automakers and also industry-wide. So think about like a rental car provider that has a variety of different vehicles in their fleet, right? Being able to access the data across any make and model of a vehicle is quite powerful for people running and managing these fleets, right? And not being limited by, oh, I have to do this for one automaker and this for another automaker and manually compile all this data. And with that, right, there's a mutual understanding of the definition and of the data. So there's no misconception of what it is that this sensor is actually recording what signals actually being sent and how that data can be used. And with that, again, it's going to reduce your costs and it's going to increase scalability because everybody's on the same page about what they're doing. So with this, with our specific project that we're working on right now, we have a few expected outcomes that we're driving towards by Embedded World here, Embedded World 2024. So we want to produce a provider agnostic reference platform, the ConnectorVet, for exchanging data between vehicles and cloud providers with a very basic initial set of signals. It's about 10 signals. The list of signals is available on our Confluence page. I'll share a link to that on the last slide on the Get Involved slide. And the idea is to start with this basic set because we want to understand is this delivering the value that we hope it does, right? Essentially, our hope is that we're creating that 80% that OEMs should be able to pick up and put directly into their own software so that they can make the last 20% flexible, right, tailor that to their needs. Or maybe they have a specific signal that's for that one car that hasn't quite made it to CoVisa and VSS yet, right? So with that, we hope to demonstrate this via a demo at Embedded World 2024. And we are going to use the AWS cloud to be able to do this. But the idea is that any cloud provider should, again, be able to pick this up and tweak it to connect directly to their cloud. So, yeah, hopefully something that any cloud provider and any OEM is able to use. So the idea, again, is to collect the data from the vehicle, right? And using that connector, we're going to transfer that to the cloud where it's going to be transformed and visualized to create insights that then can be used for business decision making, right? So just three quick, simple steps. I'm sure it'll look just like this. And additionally, this is only one part, right? This is kind of one way of the two-way equation we were talking about earlier. So allowing deployment and management of vehicle software remotely is also a consideration, right? Feeding that data back from the cloud and into the vehicle. So for those that want to look a little bit deeper, here's the initial draft of the architectural diagram for this particular demonstration. And again, the scope is to have an easy to replicate example where we're going to tap into that CoVisa.val data. And based on the configuration, we're going to transmit those specified signals we talked about earlier, that initial basic set of signals over the internet to an MQTT broker in which the scenario would be operating IoT Core. And from there, the IoT rule is going to parse and inject those signals into a time series database. And we're going to be using Grafana to visualize that. And I have an example of what that's going to look like on the next slide. So this is just an example dashboard. So the graph at the top is actually showing kind of a heart rate, a heartbeat event, right? It's taking that data in real time. So for example, if you have a heartbreak event, you'll be able to see that the steady state, the heartbreak, right? And then the continued steady state after that. And the really nice part about this is you can click on anything in that particular chart, and it will give you more information. So for example, if it's related to the vehicle imagery that we were talking about earlier, right? So you have a heartbreak event, and you want to see what happened, what were the surroundings of the vehicle that might have caused this heartbreak event. You can click on that particular point, and down below, it will generate an image and show you the exact point in time in which that heartbreak event happened in a picture of how that happened, right? So there's a lot that can be done by actually visualizing the data and feeding that back into those insights that we're talking to make to make real business decisions. Instead of just collecting data for data sake, for it to live in a data lake, to say that you have the data to do what with we don't know. So how do we get involved? Where are we currently in the project? So we would love to have more people join the vehicle to Cloud Expert Group. If this is something that calls to you, whether you're any part of the industry, right? We really would welcome more feedback and more involvement, both from a feedback of this particular demo, but also feedback on the signals that we're using, right? I mean, we're hoping that this joint collaboration with Coveysa and VSS will lead to more people voicing direct feedback to Coveysa and VSS to hopefully generate more signals that are more relevant and can hopefully increase standardization across industry, right? And that's kind of that open source collaboration value that we have. And so our next call is scheduled for December 11th. It's coming up so I think next week. We'd love to see everyone there call details are on the AGL Wiki. And then as I mentioned before, we really want your feedback. This demo is meant to be a starting point. It is not meant to be a one and done all-in solution, right? As VSS matures, right? We imagine that some things might shift and change. But the power of VSS is also that it is OEM feedback directed, right? So several OEMs got together and decided to start this initiative. So we want to continue to further that, right? Involve more automakers and more people in this value chain to be able to hopefully drive more signals and more standardization. And then as I mentioned earlier in the presentation, we have all of the details high level all the way down to the task breakdown and who's doing what, who's on first, all of that good jazz. It's in the confluence. So I would encourage you to go check that out. And you're welcome to leave feedback both on the confluence and we'll respond. So that's all I have for us today. Thank you so much for your time. Do we have any questions? Yes, I can. Is it working? Yes, it seems so. You were talking about real time. And real time is obviously sometimes a few microseconds and sometimes still one minute. It can also be real time. What are the time constraints you are setting in the current specification or in the current plans? Means posting up a data from vehicle to cloud and back to another vehicle within one minute or within two or within 10. What is, are you thinking about at the moment? I mean, that's a great question. I don't have a particular time constraint that we're modeling right now. They switched the verbiage from near real time to real time because we're getting closer and closer to that. We all know it's not going to be instant, right? And that all depends on connectivity as well. But I think that will continue to see it progress from that maybe one or two seconds down further and further and further the more concise we get and improve remote connectivity. So I hear you. I'm not sure. What I can say is we just did a demonstrator at AWS Free Invent last week where we showed this, right? We showed a hard break event and the data being transmitted to the cloud. It was instant. It was 100% instantaneous. Now this is on a hard wired internet connection, right? Very stable, not out in maybe a very remote location. And that's not necessarily the cloud talking back to the car, right? So in this instance, I can confirm it is nearly instant. But as far as communication from the cloud, say another vehicle in a collision, right? I'm not quite sure where that's at. That's not necessarily our direct use case for this particular demonstration. Good question. Thanks. Thank you. Sorry, I came in a bit late. So I saw the one way data transfer from the vehicle to the cloud. Have you thought of some other way like the binary upgrades from the cloud to the vehicle over the airplane? Yep. Yep. So we did talk about that a bit. It is a it's a component of this concept. It's just not necessarily something that we're particularly targeting with this this demo. But yes, over the air updates are important, right? We want to make sure that all the software that we're working on is actually going to be able to get updated, especially if there's security issues or concerns, right? In a quick and safe manner. So it is definitely a part of this concept. It's just not the mini focus of the expert group at this time. Thanks. Okay. Oh, one more. Thank you. So I have a question about the safety features that are connected to cloud. I know we didn't specifically talk too much about this, but here I kind of have a concern or like, and I would like to understand the trade off of doing it at the edge versus in the cloud, because I can imagine that when you do it in the cloud, I mean, it comes with a lot of concerns like what do you have if I don't have a connection doesn't mean that my car loses some of my safety features. And it's more of a question like how do you approach this? And where do you put the line? Whether some stuff you calculate at the edge versus in the cloud and generally how to handle this? Yeah, that's a wonderful question. I unfortunately don't have enough depth to be able to respond, but I have someone I would love to connect you with. Richard Elberger, who actually was started the V2C expert group and was actively involved. He works heavily between the edge and the cloud. And I think he would be able to provide a lot of guidance in this particular topic, especially with safety critical function. Okay, thank you. Yeah, you're welcome. Thanks, everybody. Have a good day.