 Hey, everyone. Thank you for joining the session today. We're going to be talking about what it means to bridge your automotive telematic solution with the cloud. What that means is what's presented here will give you the building blocks you need to design your next generation telematic system that's secure, scalable, and highly available. So my name is Richard Alburger, and I'm excited to be your speaker for this session today. I've had a few different roles at Amazon, but I have been doing embedded development and IoT evangelism for building solutions on top of AWS for the last several years. Now today, I'm really excited to demonstrate some of the work we've been doing in a meta AWS project while pairing that with some of the AWS cloud services. So when I work on the are the possible here, I work with a lot of different types of hardware, which is pretty exciting. It could be the Renaissance R car. I have some props, so like this guy right here, which is the starter kit or the TI Jacinto J7. I have one lying around here. It's a little bit bigger or the Qualcomm 8155P board, which is here. I wanted to show you the 828, but I can't find it right now. So also, oh, one more thing. When you have the Renaissance R card with the Kingfisher board, this is what it looks like. So we'll be using that a little bit later. So I also work with some peripherals, like some trivial GPS peripherals, like this guy right here, which you'll see a lot of later. And also there's on a little bit more expensive or high end is the Parker Lord GNSS sensor, which provides like really precise data. But in any case, I can use these in a wide variety of situations that pair with things that I'm developing in the AWS cloud. But today I'm focusing on automotive. So why don't we go ahead and get started with that? So we're first going to kick off with the why today. Why do we care about pairing telemedics in the cloud? What are we trying to achieve here? After some time with that, by talking through a story I'll share, we'll go a bit deeper and understand both the edge and the cloud components. Those are the components that will need to be successful with the pairing between the edge and the cloud. Now, once we have that understood, we can bubble this up one level higher and we can visualize how the cloud and edge components work together end to end. And at the end, we'll top that off with a demonstration that shows the Renaissance R car working with the AWS cloud. So look, telemedics is nothing new. Things like data loggers have been around for some time now and many benefits have been realized by that. So why do we need to stretch it to the cloud? When we get into it, you'll see it's not a stretch, but it's certainly not trivial to achieve. So whether you're running a delivery service or a car rental agency or maybe a trucking fleet, you're concerned with telemedics. Where are your assets, meaning like where are your vehicles? How are they tracking? Are they throwing diagnostic trouble codes? Is the driver on schedule? So let's break that down a bit. Previous to connected telemedics, you relied on data loggers to record telematic information. You were able to review that information when the asset came back to home base. It could be when the refrigerant trunk got parked at the distribution center for the night. That seemed pretty good, but of course there's more opportunity for advancement and optimization for sure. Or wide area communications are advancing and they're getting faster and smarter as well. Cloud technologies are becoming more pervasive and the resources you can use are more on demand and at least for AWS and you pay for only what you use. So now we can truly create that single pane of glass. That's what we want to achieve when we're managing large amounts of fleets. The one where to have that pane of glass where you can see everything in your fleet operations from one central location, not only because you're using cloud or using 5G, but because you embrace global infrastructures that are scalable and elastic. So what we can do now is, so I wonder what can we do then? Can we just snap our fingers and we suddenly have this global fleet management that's driven by connected vehicle telematics? Yeah, sorry, that's not going to happen. But what we can do is create a set of mechanisms, right? We can create a set of mechanisms that will enable you to marry these telematics with the cloud on your own terms. So now that we have an understanding of the why, we're going to move on with the what. What we need to make these cool new technical advances happen without recreating everything. And delaying our projects. We don't want to have to be able to create all these little minuscule details from scratch. So let's first start at the edge side where we can talk about how the static gets generated and propagated up to the cloud, right? Because the data is coming from the physical assets that we're measuring. So as you're aware, there's no central brain that controls everything in the vehicle. There's many subsystems in the vehicle that work together. And really, that's a good thing because it gives us flexibility and makes it so there's no single point of failure. Also, we want to make real consideration on the pitfalls of each of these subsystems not having hardened connectivity with one another. And that's really the reason why things like Canbus continues to be really, really popular. Ethernet has been growing in popularity due to the types of data that we're pushing around. But in any case, the telematics unit is usually responsible for communications between the vehicle and the outside world, specifically for fleet management. And GPS data is usually needed for that. So if the GPS peripheral is part of the TCU, that's fine, but if it's not, it needs to get that information via the Canbus, right? So we have to have the mechanisms in place to achieve that. So why don't we do this? Why don't we take the magnifying glass to a basic telematic subsystem? And a couple of things here really, really stand out. It's the upstream and downstream communications that you see here. The upstream communications is how the telematics subsystem is going to talk to the cloud. The downstream communications is how the device is going to talk with other subsystems in the vehicle. For telematics going to the cloud, the flow is from the left to the right. We're going to pick up the data from multiple sources, the Canbus, the Ethernet IP, and also local peripherals. The first step is the logger. The data will be coming in at a fast rate and we need the mechanisms in place to buffer the data. Then we need a series of readers that are more fine-tuned to pick up the data it needs to relay to the cloud. And also we'll need the local persistence mechanism, right? In place in case of intermittent connectivity failure to the cloud. Then there will be an engine to route that data to the cloud, right? Because we need to take that data, put it up to the cloud. We need to have the mechanics in place in order to achieve that. Then, so that really brings me to my next point. I mean, if we're taking this data at a super fast rate, how fast really should we be sending that data? We really need to think about that. So there's a lot of variables that require evaluation when you get to this point. You need to, because they require evaluation when you decide exactly what you want to propagate to the cloud. But nothing constrains you what you send more than the communication module that you actually choose early in your design. There are a few different parameters that go into making the choice. First, what is the range that you need, right? How much does it cost and is the technology available where you need to operate? For example, if you're maintaining a fleet of scooters that operate in municipality and you're operating under NB IoT or you're looking at operating under NB IoT and you don't have the need for sending high bandwidth data, that might be a good choice for you, right? NB IoT solutions usually cost lower on the power side as well. So that could persuade you to take the top swim lane, swim lane there. On the other hand, perhaps you want to develop a new system that sends telematics that also has the ability of transmitting video. Now why would we want to do this? Perhaps we want to develop a system that is constantly taking video on a ring buffer or something like that. And when some event occurs, like someone backs into your vehicle in a parking lot, you can take the snapshot of video and send it over the wire. Well, is that classic telematics? Probably not, but we can bond these together for convenience if we want to. But the payload is fatter, right? We would likely transmit it to a different system than where the general telematics go to, right? Just because it's of a larger payload frame. So this is really telling us that the upstream communications module is going to set all these design boundaries down the road. It's not something that you can really have the luxury of choosing late in your design. So this presentation, well, it would be far from complete if I didn't mention the telematics profile in automotive grade Linux, right? The slide looks similar to the one a few back, but automotive grade Linux provides helper APIs for common tasks that you commonly see in telematics subsystems. These are really proving useful in helping us accelerate telematics system development. We've been seeing this in AGL over the last year or so. The first is the simplified bindings to the Canvas and this high level service provides a nice wrapper for Canvas messages being transmitted on the wire between all the subsystems we were talking about earlier. The next is the simplified bindings for network configuration. It pains me to say this, but gateway commissioning can still be a painful experience for us. So one of the aspects of commissioning is network configuration and this API wrapper for the con man bindings really helps alleviate some of that pain. Now you would think that would be natural to have a GPS binding in the telematics profile, right? Well, it's really not that simple. The GPS data can come from either the telematics peripheral itself, especially if it's an aftermarket gateway, or from another subsystem like the navigation subsystem, for example. So we would need to implement that on our own. Coincidentally, that's exactly what we did for the demo you'll see later on in this talk. So I'm going to switch gears just a tiny bit and talk about some cloud specific software that's provided for the edge that helps things move forward. So there's software named AWS IoT Greengrass. It's software that extends cloud computing capability down to the edge. It allows you to develop serverless business logic using modern programming languages like Python and Java and C. And if you're into node programming, then you can use that too. These Lambda functions can be deployed to Greengrass without disrupting the firmware in the vehicle. This means that we don't actually have to do a firmware update to upgrade the software. This is actually a huge leap forward in agility for OEMs and has the potential to change the way these applications are developed on the edge. So OEMs are creating new electrical architectures in their vehicles that leverage micro brokers that connect multiple components and sensors to a fit for purpose computing system in the vehicle. They're doing this using open source MQTT. We'd like to take a bit of the work off their shoulders by providing us fully supported software components like Greengrass and Friartos. And Greengrass can also wrap messages from one component to another and doesn't require cloud connectivity, which means it can operate in a disconnected state. And it's perfect for things like a vehicle, like if you're going between two cellular towers. So as of our re-event conference a couple of years ago, which is actually going on right now as we speak, we announced Greengrass machine learning inference, right? So that means that you can train machine learning models up in the cloud and push them down to Greengrass on the edge. And then you can actually do machine learning inference or other operations down there after you deploy it. So that really extends the value of what we're doing up in the cloud down to the edge. So why am I talking about this in the context of telematics? Well, now that we know about this cloud-connectable software that we can run on automotive-grade Linux, where does it fit into what we've been talking about? How does it, where does it run? Well, like we learned, Greengrass, it combines several components, right? Into a single package that's delivered by the AWS cloud and you can naturally get that as part of your image and run it in your TCU. But let's see where it fits here. Actually, it actually covers quite a bit, but really it's from a component perspective and I'll give you more clarity about that. Going from left to right here, we'll see how this gets covered from the bindings perspective and also peripheral interfaces. Greengrass would interact with those. You would implement Lambda functions to integrate with these APIs. It's the same for the custom implementation down there for the GPS and so forth. But why does it only cover half? Well, part of that either comes from the system as part of the drivers or helper libraries or the telematics profile, which is not Greengrass and the other part are the Lambda functions that would integrate with them. For the logger, there are many choices ranging from the Greengrass stream manager to using several RAM-based databases like Redis to persist data at intervals as necessary. The stream manager feature in Greengrass gives some easy mechanisms to move data in a high bandwidth way through the system. So like I mentioned a bit previously, we don't want to send all the data up at once, right? We want to create these readers using Lambdas to work against the data source and you can do them in those languages that I mentioned previously. But once you've obtained your sample, you're either doing sampling or aggregation, then you can send along what we call a Greengrass subscription to the router, which is the MQTT broker and then you can propagate that to the AWS cloud, all right? So, awesome, let's get into the cloudy stuff. Okay, well, that was quite a bit about the edge side of things. I hope that it was understandable what I was trying to get across. Now we want to take a look at the cloud side. We're going to do this from a kind of abstract perspective. So we can focus on the mechanisms rather than the literal cloud services. Then we can talk about specific cloud services after going through these concepts. Okay, so when you're sitting there, right? Why, because you're all wanting to do telematics. When you're sitting there thinking of those amazing visions, right? Of global fleet management dashboards. The mechanism that underscores or underpins these behaviors in the dashboard is the telematics and DTCs or diagnostic trouble codes. Those real-time feeds, right? That's what makes all those UIs happen. But we can't have apps take those data flows directly, right? We need to get it to some kind of index storage in a consumable form. So let's, again, let's go from left to right. Let's walk how those messages flow. Like we learned in the edge section, it will mostly be conversing over MQTT, right? So it's going, this means that we're going to have some kind of IoT service ingest, something that has a managed MQTT broker up in the cloud. This broker should be, of course, highly secure, scalable, resilient, because you're going to have thousands of vehicles sending it data. Usually these managed services provide a way to route messages, right? Using very simple configuration between itself and the other services, just to reduce the amount of complexity in the configuration. Usually then we want to perform some compute on that or data cleansing or alerting at that level. The new fingled way to handle this is with what we call serverless. You can think of it as secured chunks of code floating in the cloud that you can invoke to get work done in a distributed way. Now, depending on the type of message, we may want to implement a restful routing pattern to other serverless chunks of code so they can do their own specialized compute. But at some point though, you'll want that data to reach a repository, a repository that can quickly index that data for visualization or rendering or even automation purposes, right? So simply when apps want to view the data, they'll look at that repository. Here, we're using ElastiCache because it's open source and you can use other appropriate data stores as well. You don't have to use ElastiCache here, right? So there's another swim lane here that we should take a look at. Let's take a look at this for TeleMax. Remember what I said before, the cloud is for doing things of scale so when we're doing anomaly detection in the cloud, we would likely be inferring outcomes across the whole fleet rather than a particular vehicle, right? So we're focused on a single vehicle and the inference model isn't too heavy. We can maybe do that at the edge, but usually we'll want to deal with a significant amount of data with on-demand compute and that translates to cloud. Also, so there are other scenarios as well and I'll get to that in a little bit, but just think of needing to do this at mass scale. But let's, again, let's go step by step. After the message makes it to the MQT broker, maybe we want to look for strange variations in oil temperature or other readings that could signal a chance for imminent equipment failure, right? There are algorithms that can take the data that are in like windows of time in the stream and compute on them, and which can give you the statistical result for that particular window, that sliding window. That could surface an anomaly within system function, right? Once that anomaly is found, we would want to bucket that into an aggregation. Now, to be honest, I'm a little bit mixed about this part of the diagram. It starts to get a little bit philosophical. How much of this data do I really want to collect? Especially like what we saw in the previous slide, if I'm already capturing it in the real-time feed. In any case, we do need to eventually flag those anomalies and get them persisted into an index storage so we can do something with it later. And later, we can use these as flags. For example, if an anomaly is found with a particular vehicle, we may want to flag that for a mechanic. So why would we care about that? Why can't we just tell staff about the engine warning light that's gone on like the driver comes in, parks the vehicle, says the engine lights gone on? Well, really, again, this comes down to optimization. If we can get a mechanic scheduled in advance of the vehicle arriving at the distribution center, we can optimize how fast we can get the vehicle on the road again. If the vehicle was brought in and no mechanics were available until the next day, then that vehicle would just sit. So we have an opportunity to optimize that when you have cloud-connected telematics. Next, let's talk about archiving. Telematics archiving is really your raw data lake. Everyone's heard a lot about data lakes, I'm sure. That initial pool, that's what it is, it's your raw data that you can tune and prune for machine learning and analytics and long-term auditing. This pipe provides a fast and robust and cost-effective means of getting that data you need into the lake. Remember, that's a raw data unadulterated, right? You're not doing any changes to that data, you can do that in later stages. Of course, you can tune how much you're transmitting and persisting. You also have the opportunity to do some cleansing after it's been put to rest. Let's deal with this step-by-step, okay? One moment. Let's deal with this step-by-step. We would have the data come into the IoT ingest point, right, using MQTT once again. I don't need to go into that detail, I've already said that a few times. But remember, when this data's coming through, it's doing it file, well, I called it a file, it's an object, it's a chunk of data that we want to persist into our data lake, right? Now, you're looking at this diagram and saying, well, why do I need the streaming thing? Why can't I just take the data and put it into object storage directly? Well, the deal is, is that when you're taking data and you're putting it directly to object storage, many times that it can be considered inefficient because you're doing a data storage transaction for every single file, right? Because those object data storages are usually very highly resilient, right? So transactional stuff is a high priority. So don't get me wrong, it's still very fast, but we can do it better. The streaming service can be used in pairing with the object storage. So what a streaming service usually can do is take a whole bunch of objects and then batch persisted to object storage at larger intervals. So you're reducing the number of transactions and increasing the throughput to the object storage system. So just throw it to a stream, let the stream manage it in bulk and put it to the object storage system which optimizes your archiving procedure. And really, that's one of the reasons why the cloud really scales this because you're able to do really, really cool operations like that. Now the last component that, major component that I want to talk about in a cloud is, that's the actionable dashboards. We've done a lot with the data already, but now we need to do something interesting with that data. And at least in some cases, interesting things happen hopefully when humans are involved, right? So that means human interfaces and, but really that's not the whole story here because we have some non-human things that we need to do as well. So let's cover off the non-human part first. The non-human part has to do with APIs that provide not only the data interfaces for applications, but the mechanisms for reporting like daily operational reports. We could say this belongs in the fleet management UI maybe, but really reporting could be a long process. And if we can avoid it, we wouldn't want to have a human perform the dual task of sitting there, hitting the run report button, and then just waiting, right? So we can batch that stuff. But now we're going to get into the exciting parts, the human interfaces. The fleet management UI is that beautiful single pane of glass that gives insights to your fleet. You should be able to locate vehicles in real time, look at the vehicle properties, see what trip it's on and all those other kind of cool things. In the demo later, actually you'll see that it's a fair, you'll see that kind of shininess and of something called the connectivity management solution that we do here at AWS and I'll be able to share that with you. But it's like a bunch of JavaScript react coding, right? Really fancy shiny stuff. But there's other UIs too that are just as important because they get a lot of great things done. For example, you may have a web UI that integrates for managing parts for your fleet. You could have mobile apps that integrate into the system for your mechanics like what we talked about earlier. So those are just as important as part of your overall operations. But anyway, this is where, we did all that work with the data so the humans could get to the data to make some really interesting decisions, all right? So next what I want to talk about is bringing this all together. I talked about those, excuse me, those two lower low level parts, right? The edge and the cloud. Now what we wanna do is bring those together. We bend through that journey of the why, the edge, the cloud details, and we're going to walk this through, again, one more time end to end just so we have a high degree of certainty that we're sure that we know what we're thinking about this. I just wanna bring all those details back to the surface for you. Also, before jumping into the demo, we'll do a walkthrough of the event pipeline because this might be interesting to you if you want to notify workers in how your operations are going and any important events that may be happening in your fleet. So why don't we go ahead and get started with that? So let's go through this step by step, going again from the left to the right, right? From the hardware to the cloud. So we're gonna go through it step by step. Remember, we're gonna go, and when we're doing this, right? We're going to pair these mechanisms with actual AWS services, right? Because now we're going to start looking at concrete implementation, how we can use these cloud services. So down here at the edge, the Telemax data is collected from the CAN bus or peripherals and it can be decoded or deserialized at the edge and then published over MQTT, right? So that's a first step. Or it could be published raw and transformed in the cloud. You could make that decision too. The way that the connectivity management solution works, which is this framework that I'll be showing you in the demo is we use JSON over MQTT, but I think something like BSON might be good too. We just haven't really dove into that yet. We recommend using the MQTT protocol since it's lightweight and supports those PubSub mechanisms, right? That's what we've been talking about. Now, in the case where you, maybe you have a device where you want to use HTTP instead. Well, yeah, sure. The AWS cloud, AWS IoT supports HTTPS and also WebSockets. But in the case that we're talking about today, I don't want to pollute or make that more cloudy. So let's just focus on what we've been talking about so far, which is IoT Greengrass running on the TCU and that's going to end up saving us a lot of implementation time for those details. So now the TCU is pushing Telematics to cloud, right? Telematics to cloud, right? And IoT Core, that's what the service is called, uses rules engine, which is, and in that is an IoT rule, to route things to different back ends. So remember the first stage we went through, which was, well, it was actually a later stage, the archive telemetry, right? So let's go through archive telemetry. That data would be coming full blast in from many angles as a number of vehicles in your fleet. So we need to have a wide pipe. That's handled by a service named Kinesis Data Firehose, which is super scalable, streaming solution. It takes raw data, it's archived into an S3 data lake for regulatory or analytics or anything you'd like to do with that raw data, data lake data, okay? So next we have the anomaly detection, which has performed in near real time. This was the second part that we talked about. And you can use the algorithm, so this is really a cool thing. We're using streaming, but what we can actually do is run analytics on the data as it's streaming, right? So the pattern that we typically talk to customers about is using a random cut forest algorithm with Kinesis analytics. Yeah, we can produce, we can just do that right on the fly on the streaming data. And that gives you the wide scale that you really need. That can be further tuned. And then before we're hitting the DynamoDB database, which is the NoSQL database, and then going to Amazon Elasticsearch. So next is the telemetry and the DTCs and the driver score computations, right? That nowadays the trip data and driver score, that's a pretty standard metric that you want to be able to compute and display and report on. And you can do it through that particular event pipeline. So that can be processed through Lambda and persisted to a DynamoDB table. All this information is in a raw and aggregated form in a stored in Elasticsearch for consumption through APIs or UIs. Now, of course, your workload may need to evolve some of these components that we're talking about based on your use case. The CMS doesn't force you to use any specific components. It's an excellent starting point based on the customer engagements that we've had. However, the way some fleets operate could lead to using alternate AWS services. So of course, you have to always go through a design evaluation phase on exactly what you're using. For example, if you don't need the data immediately, in some cases, it might be okay to implement batch processes, right? Now, after all that, then users can view the data. And there's a good starting point in the CMS that I'll show you in a little bit, which you'll be able to see in the demo coming up. So next, I'm gonna show you something that we haven't really talked about yet, which is event data, right? Because it's not one of those core pipelines that we were talking about. But this is something that I like talking to people that could be derived, talking to people about that could be derived from Telematics data and could be useful in your case. So for event processing, right? There's a workflow built that you can leverage within the Connectivity Management Solution using AWS Lambda and the Simplification Service, which is just a messaging service in the AWS Cloud. This event processor, this is an event processing pipeline, can receive events from event sources like IoT Core and DynamoDB Streams. The subscriber on the right-hand side over there defines the filters for the events, okay? So those are your SNS subscriptions and generate alerts based on those settings. That's a really, really great way to cheaply and quickly integrate events into the Connectivity Management Solution. Of course, like anything else at AWS, there are approaches to achieving this outcome that has its own trade-offs, right? So like I said, this pipeline is easy to manage. However, if you like to do larger-scale event orchestration, you might want to be or implement something maybe a little bit more savvy, like using IoT events, which is in the IoT suite of services. And you would just evaluate to see if those set of features would actually fit your particular use case. That's kind of the cool thing about the cloud. There's usually an array of things to choose from to fit your case. And that would help you build a really cool state machine that could help you manage your fleet. But right now we're going to keep it simple. There's a few different services that can work the event pipeline right here. You'll learn more about that over time, right? Okay, cool. So now what we're going to do next is run through a demo of this end-to-end solution. Actually, I don't know exactly how we're doing on time. I think we might be doing okay. Or a little bit on time. So let me just get through this. The demo is just going to take about four minutes and it's recorded, okay? And there's a lot of moving pieces on the edge of the cloud, so let's jump right into it. It's a video, it's on YouTube, so you can watch it later if you want to. So I'm really excited to demonstrate this to you. So what we're going to be using is the RamSus R-Car in the AWS cloud to build your next generation, right? Automotive Gateway Solution. That's the thing that I've been talking about here. And we're using for a very basic prototype and to move on to the software integration side. And then finally to how the R-Car delivers data to the AWS cloud. So it's the, let me see how far away we are. Okay, so I'm using the H3, the RamSus R-Car H3 starter kit, right? And I just, sorry, I just lost control on my screen for a second there. What I wanted to say is that I'm just going to go back a little bit if I can. I think the video is really playing. So I'll just say that I was using the MTK3339 GPS module on the video with the USB Wi-Fi dongle. And to get this all running, I had to do three basic steps. I needed to integrate the software stack to the R-Car image. The R-Car naturally runs AGL Automotive Grade Linux. So what we'll want to do is produce the AGL demo along with IoT Greengrass. To do that, we'll build it using Meta AWS, which is the big layer that we have up on GitHub. And then once the build completes and it's flashed to the device or is running on the microSD, we need to provision the device, right? When we do this in production, we'll probably want to use an automotive grade TPF, right? But right now we're going to commission and provision manually. I can create the credentials on the command line and also create and deploy IoT Greengrass group on the command line. So now what we can do is reboot the device and the device connects automatically to the AWS cloud. I'm doing some Wi-Fi configuration here. We have our GPS connected, but right now nothing is reading the data, okay? So what we can do is write some code for the GPS using AWS Lambda. We can deploy that code from the cloud to the device. And this is the deployment process here in using Greengrass, so I'm starting the deployment. And once Lambda function has been deployed, IoT Greengrass can start reading the GPS data and reading that to the cloud. Now, of course, you might not want to send the GPS raw data to the cloud. So Lambda function will massage that data first. And send only the most essential data that you need to reduce costs. So what we can do then is view the telemet data in the fleet manager user interface, which I'm logging into right now. After logging in, you can drill down to the specific vehicles. And in this case, it's the R car that has the GPS sitting on my desk. So you're seeing kind of where I live. And what I'm doing right now is changing the heading of the GPS device. The data is going through the pipeline we talked about. So you have the GPS data for later analysis, right? So for more information about integrating the R car, you can browse the meta AWS project and the meta AWS demos walkthrough for the Renaissance R car, right? And so those are the links there that you can go and check out. So that's it, that went a little bit speedy. And I think I lost my pointer one second. Okay. I'm just gonna have to manually do my pointer throughout. Okay, so throughout the session, you witnessed the use of a lot of resources, right? That are brought together to make all this technology possible. On the device side, we use automotive grade Linux to build in AWS IoT green grass using the meta AWS project. We also have a walkthrough for the Renaissance R car H3 on meta AWS demos. Right now, the repo isn't live, but we should, it should be live in the next couple of weeks. It's the usual procedure here at AWS. If you're interested in that, just follow me on LinkedIn or GitHub and you'll be able to know when it becomes available. Because I'll announce it there. Last, but not least, if you're interested in the connected mobility solution that I talked about, you can reach out to this on the last URL here. And that will get you to the right people if you'd like to do that. But if you do that, don't mention, I mean, don't forget to mention that you sought during the session. All right. And with that, I would like to say thanks again for taking the time of watching this presentation. I know there's a lot of great presentations going on. Thank you so much. And please feel free to reach out to me on LinkedIn. If we have time for questions, please don't be shy and ask away. For example, if you're interested in what the code looks like or how it's getting GPS data information, I can show you that and how it's configured in AWS. We'll see how much time we have left. And that's it, thank you. I'm not, oh, I have some messages. I have to figure out how to use this thing one second. I think what we can do is, if what I can do is stop the session. And then if you have any questions, you can reach out to me at the two track automotive Linux summit channel. And we can go and you can ask me for questions there, I'll be there for a while. Okay, so thank you so much. Have a great conference, bye.