 Good day, everyone. My name is Shrikant Hacharian. I'm the CTO of Excel 4 and today's topic, of course is software defined vehicle. It's almost become a cliche at this point. And the standardization efforts undertaken by both Red Hat and Excel 4 in the form of ESync and other associated standards that are encompassing the whole sphere of software defined vehicle. And of course, the common theme is the OpenShift hybrid platform of Red Hat, which allows you to connect to any cloud provider with ease. With that said, let me come to my introduction. So a quick one. So Excel 4 has been driving standardization both for cloud to the vehicle and from inside the vehicle as well. So this was the standardization that started to standardize data and OTA, which is very key if SDV has to become a real what I call fountain of monetization for the car industry. So we are just a quick introduction. We have five offices worldwide. We have global adoption for the E-Sync standardization across OEMs. And of course, we have a considerable amount of what I call established vehicles on the road. Now just a quick note on what E-Sync really means. The E-Sync is a bi-directional standardized pipeline. And it's a client, server client and agent approach. It's not new to the what I call industrialized world. And the beauty of this distributed architecture is allow you to scale. You don't have another scaling comes in the form of it doesn't matter how many devices are connected in network, the client discovers them and brings them into the network. This allows scalability. Secondly, the server to client connectivity is not going to change from platform to platform. And so in that context, you create you only change the aspects of the system that need to change from when you move from say one car platform to the next. It addresses all major OESs. So that's not a problem. It is basically transparent to the connectivity scheme. So any network can be connected. It has global requirements. And of course, it has full logs and records for compliance. So that's very important because that's one of the important things for certification today. Now what's inside the what I call the client agent architecture, the agent is a software abstraction, a software abstraction that allows you to present a device in a very standardized interface that connects to a message broker. So whenever a new device comes in, it presents its credentials, the credentials are verified, and if it's the right one, it becomes registered. This is what is known as a discovery mechanism. In this way, what happens is the agents get discovered as the system powers up. So the system does not have a predefined memory as to how many devices are in the network at any given time. What it does is as the power comes on, the various registrations get matched, tallied, and the network gets discovered. There are two reasons why this becomes a very important thing. One is, first of all, any new element that gets introduced as a rogue element can be discovered immediately. And if some devices are non-operational, it gets flagged immediately. And if the same setup is put on a car that has 20 ECUs, or a car 40 ECUs or 100 ECUs, the discovery allows the system to stay standard across platforms. Now, the standardization effort is not an easy effort at any point, but it has gathered momentum. It has gathered momentum in terms of customers, OEMs, and even semiconductor companies. And that has really been a driving force, because finally, standardization has to come from within the organization. It cannot be imposed. Standardizations have to be something that you learn from mistakes. But standardization cannot be what I call an insular. It has to go across standard, because there's so many other bodies that are also doing stuff. This whole SDV is such a big swath that you cannot attempt to solve it with one organization. So you have to collaborate. And in this regard, you have the CoVisa. CoVisa is building this what I call the standardized vehicle catalog in the cloud. And so the SYNC Alliance went into analyze an agreement in 2021, created the certification, or I call organization between the CVII, the connected vehicle initiative, as well as the vehicle catalog that they are trying to build. So these are all the activities, joint technical sessions, and demonstrate proof of concepts. There's another standard organization that is evolving called the AutoWire Foundation that presents what I call creating an open source for the autonomous driving pipeline. So now we have worked with them for over six months to bring in concepts that can allow this kind of what I call containerized updates into their autonomous vehicles. And this is again an important what I call development. So standardization cannot be insular. It has to grow beyond its own boundaries, and it has to collaborate because the whole area of the vehicle development is not a preserve of one single organization or company. Now, in this standardized pipeline, you have the OTA, which is the ODF update, but that is not what I call all in all, you have to bring data out of the vehicle in order to have this learning loop. So we talk about autonomous driving vehicles. How do they become better? You have to have a learning loop. And for that, that is the idiotic data management aspect. So you always have to figure out how things can grow from a structure that is what I call the infrastructure. And the infrastructure is this standardized pipeline. And then it exposes very standardized interfaces through APIs that are well defined in the standard definition that's available in the E-Sync Alliance to the E-Sync Alliance members. It's a 500 page spec that outlines every aspect of how to make the server available, how to create the client, how create the agent, and also to create what I call substantially the next aspects of evolution, which is the data and then the analytics. So by creating these, what I call common interfaces that are look like, what I call microservices, you can bring in these services into the E-Sync pipeline. And so deep data, how to extract the full resolution, having rolling buffers, all this become part of the construct that create the edX pipeline that connects to the E-Sync OTS scheme. Now what happens with the data aggregation platform? You have to have both the cloud aspect and the in-vehicle aspect. So much data is getting collected inside the vehicle to transfer all the data into the cloud is, I would say, not a, I wouldn't call it feasible, it is feasible, but it's not practical. So you have to have cleans the data, cleansing the data inside the vehicle is extremely important before you transfer that cleans data back into the cloud because that's what is relevant, relevant data that is in and around an event, relevant data that extracts certain features out of what's happening. That to me is essential to the platform approach itself. So you have the E-Sync pipeline, then you have the E-Sync OTS and application, and now you have the edX as an application. Now you have the complete learning loop for the vehicle, and these are all coming out of standardization processes. Now, so we have implemented a version of the edX, and these are all the things that we have managed to get out of it. So telematics data for the vehicle that is generally available and everybody knows how to do it, then talk about different, what I call device statuses inside the vehicle. You're talking about what I call dashboards that tell us a little more detail about power and drivetrain, battery management systems, and high resolution data and demand. Now these are all configurable. So you can send the configuration information from the cloud and the appropriate data shows up from the device through the client into the cloud. Now coming to the whole aspect of a software-defined vehicle. Now a software-defined vehicle can mean several things to the people who work on it. Here is our definition of what a software-defined vehicle is. The key things are you have to have a standardized hardware that rolls out of a platform because you are trying to put software that is configured to create the car. So what is that? It needs to have a domain master architecture, you have to have zonal controllers, and these are what I call a confluence of high compute centralized units to what I call regional zonal computing units. So now once the hardware is standardized, you can now deploy the software to create the feature or the vehicle. So in that regard, now you can put model, you can create sub-models, you can create options, packages, personalizations, but it all emanates from a standard having a standard hardware platform on the table. So now a lot of things are happening, features on demand, feature purchases, subscriptions, rentals, refreshers, upgrades have become part of a personalization process. We are all in this age of having cell phones getting updated, new cell phones coming along. We are all used to it. Now we are trying to bring the same into the car and you don't have to sell it anymore because this is something that we have got used to it. Similarly, now that you have pushed features on what you do in terms of getting data out of the vehicle. So what all the things that you can create to monetize the vehicle data? Now that's important that you need to get standardized data out of the vehicle in order to even monetize it. So you have to go beyond test vehicles. So in olden days you had to run vehicles and test tracks to get data before a vehicle is launched, but today you cannot, you don't have that, you don't need to have that because you have hundreds and thousands of vehicles running on everyday use cases and you're going to collect data out of them. While you may need still the the race tracks or the test tracks are going to be relevant, but the reality is that by connecting the vehicles, all of them, you are getting hundreds and thousands of vehicle data all at once giving you a better understanding as to how the vehicle is performing in different use cases. So you can bring in predictive analytics, predict life cycles, remedials, event correlations, even assess us to the stature of the road. Challenge in a software defined vehicle and the complexity of its connections. This is the challenge. We talk a lot about standardization, talk about the ways you can monetize data, but fundamentally are grounded in our own legacy that we are managing and that's somehow we are unable to get out of it. Why? This is the challenge we have in the modern what I call landscape of OEMs. You have OEMs on one end, you have tier ones on the other end, they all make ECUs, but they each make a different version of the device to reflect the needs of their OEMs. Look at how much cost that entails, how much energy that is, and this is what we all want to do is to standardize. If we get ECUs to present a standardized interface and they are tested, validated, and say they are ESync ready or whatever standardize ready, then even the OEMs don't have to wonder how they want to integrate that vehicle, that device ECU into their structure. In order to simplify, you have to standardize. In order to reduce cost, you got to standardize. In order to monetize, you got to standardize and this is the challenge for all of us. Interoperability is part of the spec and the compliance, conforms, conformations. There are minimal requirements, of course, and they are APIs. We have also what I call, we understand that OEMs have had their own what I call investments, so this standard allows you to how to gracefully merge the two. So that you can use the scalability and ease of deployment to try to merge with existing infrastructure. Market engagement adoption, so we have leading partnerships, of course, Red Hat being one of the key ones. The alliance is bringing in a lot of value and of course we have managed to create a common interface to the cloud platforms. Use cases. This is a use case of an autonomous driving truck platform that is using eSync today. It got it running in literally three months into their beta. Now, this concept of trying to get things into production is always a headache for automotive OEMs, but the standardized modular structure of eSync allows you to get going into your production quickly. There's a new upcoming member in the alliance that is really creating a platform that we thought would be the prototype of a software divine vehicle. What are they doing? They are creating a super board that presents the drive train, the battery, the steering, all these available as a platform and you can put the skin on top and create your own vehicle. That would have been a great concept to start with, but this is reality today and so that's your power for you. It's a multimodal EV platform. Now, a little bit about open shift integration. Everything is a collaboration and an effort to figure out how these things can work together and what we have done in this whole process of two years of working with Red Hat is figuring out ways that the various modules can talk to each other and become part of a connectivity environment. The open shift to us has been a great experience and right now, I'd like to hand over my talk to my colleague, Otwin, who can expound on what all he's been doing with eSync and the open shift and the environment that he has created. Thank you, Shrikant. Can you hear me, by the way? Sound is working? Great. I would need to share my screen. Do I have to leave now to let you share the screen? No, you can do it yourself. It should work now. Try this and you should see my screen. Yes, we can. So you see my screen, right? Yep. Okay, great. First, let me briefly introduce myself. My name is Otwin Schneider. I'm working in the hybrid platforms, open shift business unit at Red Hat. Today, I want to show you a little demo and also talk a little bit about what we have done with eSync together. In this context of the demo, you heard already with human driving perception platform with Bobby Carr, but first of all, thank you, Shrikant, for covering this topic and explaining the over-the-air architecture and so on. I would start with a question now from a retic perspective, how can we help with this over-the-air update topic? How can we help with our technologies? I would say basically it is like this eSync kind of standardize the way or over-the-air updates, so that's not every render kind of invent a deal again and again. What we do from the red hat side, we kind of standardize the platform. We not only have Kubernetes, we have a lot more services added on top of it. We have platform services, application services, data, developer services, and there's a bunch of other services as well like multi-cluster management, security, all the things you need for two things. You can run it in a complete eSync over-the-air infrastructure at scale in a cloud agnostic fashion. As also mentioned in the upstream talk we heard, it is like cloud agnostic. We have operators. They can replace the managed services you have and you can kind of run your eSync over-the-air infrastructure in any cloud, if it's AWS, Azure, wherever in your own data center, so you have kind of really a consistent environment to run these services really at scale. Some of the things, for example the eSync the architecture consists of several components, so there is a server component actually where you kind of manage your software packages, you create updating campaigns and so on. The server infrastructure needs several middleware components as well. We can also provide on top of OpenShift with some of our application services portfolio, for example with API management, with messaging platforms, database caching, so all these services we can use them to actually support the actual eSync infrastructure. What you could do is you can really operate an over-the-air infrastructure on top of OpenShift. This is one thing. The other thing you can use the OpenShift container platform to really build your automotive cloud for all the other types of workloads in this scenario, as already heard today. We have machine learning AI, so OpenShift is really for any type of workload. You can do your machine learning AI stream data processing, batch processing. It supports microservice architecture, event-based architecture and so on. These are also very relevant in this context. Let me come to the demo part. As already heard, we've created a demo which is called BobbyCar. Basically, what it is, it is kind of an opinionated design, a red-app recommendation, you could say, for a cloud native IoT architecture built with red-app products. There are a lot of reference architectures out there supporting these different types of workloads. This is kind of a way we would recommend you could do it with OpenShift and a bunch of the middleware portfolio we have. The high-level architecture, just to give you the context of this demo, just walk over the high-level architectures. Basically, it is a vehicle simulation. We have, on the left side, the actual BobbyCars, which are vehicle simulators implemented in cloud native Java and Quarkus. By the way, everything you see here is running in OpenShift. Then we have several regional cloud environments and a central cloud environment. There is the connectivity from the simulated vehicles to the central cloud environment with MQTT, with an HTTP Kafka bridge and so on. Basically, all the data coming from the cars, all the telemetry data, they are coming to the MQTT. Then we have several integration components, cloud native integration components. Basically, everything that comes in goes into Kafka. From there, we distribute the data or do different types of processing. One thing is, of course, real-time data processing with Kafka Streams or Apache Spark, the different technologies you could use there. Then we have distributed caching as well to store the current state of every car in the system, where we have business entities and configurations stored in there. There is a real-time dashboard to see where are the cars driving, what is happening there. Then we mirror the data. We do also some data cleansing, so to say, and mirror all the relevant data for machine learning from the regional cloud environments to central cloud environments. You see there on the right side, there is a central Kafka cluster running and attached to this cluster. For example, our machine learning infrastructure, which could be from a Red Hat perspective based on OpenData Hub. There you do your machine learning and bring the trained models back up into the car. This is basically the high-level architecture of the demo. Now, what we've done in the last few months is also integrate a use case with eSync with standard over-the-air updates for this specific demo. What we have is we've deployed eSync service in this regional cloud environments. The eSync client is the in-vehicle gateway, communicating with the service side, so whenever there is an update for a specific type of car and so on, the client will fetch the data, the actual payload and will distribute it internally to the specific ECU and will do the update. In this scenario here, the vehicle simulations, they're not highly sophisticated, so we don't simulate like ECUs or things like this. This is just more the use case we've implemented here is kind of a location-based configuration change, so we have our vehicles, they're driving around and we have configured different zones. That could be, for example, environmental zones or it could be a zone in a specific area where we want to react on certain conditions like there is kind of the road conditions are different and we want to apply a different configuration to the car for a specific location, so this is kind of the use case and so we have the simulated car, so they're driving, sending telemetry data to the cloud backend of ramqtt, mqstreams, so this is kind of a simplified view you see here, then there's also a zone change detection service running, so whenever a car enters a zone or leaves a zone there will be a zone change event emitted and then we use openshift serverless which is also one of the services openshift offers and we use the serverless function to kind of communicate with eSync server to check, okay, is this an update zone, is this car kind of valid for an update and then we assign kind of the vehicle identification number to a specific update campaign, so we're interacting with the API server of the eSync and this one will then trigger the assigned eSync client, the actual over the update download, so the client will download the update package and will distribute it to the car and will be applied here, so this is kind of the context and just a demo we've implemented here and I would now jump into the demo part in openshift, but I have to apologize today, so something really bad happened, actually I completely destroyed my openshift cluster, so I don't have an over the update infrastructure, eSync, whatever, so I've used a new openshift cluster and I only can show you unfortunately only a few parts of it, so basically just the bobby car components and the cars, but I wasn't able to kind of reproduce the complete over the eSync parts of this demo, so I'm really sorry for this, this is one of the worst days in years for me, but yeah honestly it's okay, so what you see here, we are here in an open shift environment 4.10 and there is a project called bobby car, I switch into this project and also jump into the developer perspective and then you should see some circles and bubbles popping up and you see all the containers running here, so basically what you see here is the complete regional IoT cloud environment with a caching system with Kafka running here, MQTT broker, several integration components, so everything is deployed in here and you'll find all the code also in github, so you can also if you want to try that in your open shift environment, so everything is running here and now let's zoom in, you see here is a car simulator, this is the actual bobby car or a vehicle, so there's one container currently running and this one is simulating 20 cars and there is also a dashboard component, which is kind of the actual visual side of it, so we have a dashboard and there's basically very simple, there's just a map and we see the 20 cars now, so we should see a map and we should also see some markers moving around and the red circles you see here, these are the specific update zones, so there is for example in Frankfurt, we have a zone then here is a zone in this intersection here in front of the airport and so on, so we can have different zones and configure them, so one thing we can do, we could for example create new zones and move them around and configure them for specific types of updates, for example, we could do some real time query of the data, if we move like this gray search area and we want to know okay now kind of a little bit of stream analytics, what is the average speed, carbon dioxide, emission and so on of the cars driving here, we could do things like this and also so the thing is now, if a car enters a specific zone, so we are not that happy because the cars are driving somewhere else around, but if they enter a zone, this will trigger the serverless function in the background and this will assign the car to the, over the update server and will trigger the actual download, so we could normally, if it would work, we could go to the car detail, select one specific car, yeah we can also switch the cockpit view, if there is speed view data available, we see okay the car is currently driving here and we see the data here and there is kind of a heads up display where we see okay what type of car, what is the vehicle number and so on and we see this car is driving in a default zone and as soon as there is a zone change event we you see also this one is popping up here, by the way you see also some of the data here was the current speed and so on and then we could also vary the current engine config and this is kind of the behavior where we took like a configuration from a real world car and this is the actual payload where we have a different engine behavior for specific zones, so that would be this JSON would come through the ESync over the update normally, so basically but you get the idea how this works and how we use it in this specific scenario and integrate it also with a lot of the the technologies from our side and yeah basically that's it from my side and yeah so Ortwin don't worry live demos always fail at some point, I know proves the elasticity of our adaptable speakers and thank you very much for that