 Good day everyone. My name is Srikanth Acharya. I'm the chairperson of the eSync Alliance. Today's topic, eSync Alliance and CoVisa collaborate to standardize automotive data from the cloud to the edge device. Our presentation today will describe the eSync Alliance efforts to standardizing a bi-directional pipeline, which includes OTA updates and data aggregation from the server to the edge device. Involves three areas. One is specifying the architecture and behavior of the server client agent model, a PI definition for server to client and client to agents, and specifying the data gathering parameters and formats for agents. CoVisa, on the other hand, is building a standardized vehicle catalog database to distinguish and access data from diverse sources in the vehicle, specifying a data structure for each edge ECU or vehicle domain. Today's presentation describes the collaboration between these two activities, specifying the exchange of data between the catalog and the pipeline through layer zone. Today's agenda. So we'll start with the introduction to CoVisa, followed by an introduction to eSync Alliance. Then we will describe the layer zone that is happening with a use case, and then our conclusions and looking forward. Let me describe to you the origins of CoVisa. It started as Genevieve in 2009 with a focus on in-vehicle infotainment, transitioned into vehicle data and cloud connectivity, launched a common vehicle interface initiative in collaboration with W3C, and then this year changed its name to CoVisa. And CoVisa, of course, stands for Connected Vehicle Systems Alliance. It'll continue to make the efforts that span CVII and that collaborative effort. The scope is in vehicle, on edge, and in the cloud. Activities support automotive and adjacent industries, example insurance, which has a great deal of interest in automotive data. And also technology and business model discussions that define future of mobility. So what is a common vehicle interface initiative? Just historically it started in 2020, between Genevieve, which is the old name, and W3C to unify the trends and interests and ongoing efforts. What does it outline? Creating a foundation for vehicle data-driven architectures, define and share common data definitions and service APIs. And finally, standardization that allow you to reduce the fragmentation complexity and increase efficiency in how data can be exchanged. So CVII is really about harmonizing across industry organizations and consortia. Now, just to give a perspective as to how expanded the initiative has become over the years, and how CoVisa and E-Sync Alliance play a part in some of those initiatives. Now, it starts with the CVII initiative. There is a breakdown into the tracks. From there, it ends up into many activities and projects. And we form a small portion of the activities and they're outlined. So there are two kinds into two aspects. One is the catalog and also the signal specification. Now, a little about vehicle signal specification. So the background is what it's a four and a half, four to five years of research. The current version is version 2.2 and fully open license. And what does it do? Define model for vehicle data definition. And then there are seven data types developed and published tools support extensibility and innovation. So what is the current status? The current status is VSS extensible using layers. There is an ontology map that has been built, supports connecting data applications, refine and remove data duplication. And some of this initiatives found itself in production vehicles and also as a protocol specification at W3C. So you can see it's starting to harmonize, making itself prevalent in the standards. Now, the whole idea is to find a common data model. Even if you don't, if you're dealing with what I call legacy data sets and of course new ones will always follow that. So if you can see the legacy data sets have come into three different forms. Formats that are defined under JSON. Formats that just carry a header descriptor with data followed. And then of course something like a Microsoft defined DTDL format. So these are all different kinds of things that exist in legacy today. But in the going forward portion, which is on the right-hand side, they are trying to use the data catalog and the common data model. So going forward, the path is very clear, but there is also a path to bring conformance to data that exists today in different formats. Now to give a flavor as to what we are talking about. So this is a vehicle data structure that is outlined in the standard catalog. It's quite extensive. It defines one for each ECU and you can find something that you're all can relate. And let me take one example like this for an electric vehicle, you'll have a definition such as this powertrain, power source. We will try to take this as an example and try to expand it into the next slide. Here we are talking about a vehicle signal specification syntax, every spec file. So in this we are defining the electric motor, in which we are giving you a couple of instances of a data attribute and a sensor. And these define two parameters when it's the electric vehicle powertrain, power source, max regenerative power and the motor coolant temperature. So that we have defined what the basics of what VSS data catalog, the data structure, now we go on to define what is the ESync data pipeline. We are trying to solve an industry challenge. What is the challenge? The challenge is existence of over a dozen way to update issues. Now, some are OEM related. So OEMs and cells can define their own updating mechanism which are unique to that platform. You have tier ones that have their own ways of updating. I mean Bosch has one, continental has one, and there can be several others who have their own method for updates. As if that's not enough, you have the OS themselves have a prescribed way of getting updated. You have Android, you have Linux, you have QNX, and then all these operating systems seem to define their own methods for updating. Now let me add another level of complexity. So each of these tier ones have to adjust or modulate and change the software to reflect the OTA mechanism of a given OEM. So let's take powertrain, it's gone to six different OEMs. So I have to maintain six different versions of the software for the same part. Now, suppose if I have 800 different parts that have a similar problem, it just increases the skew of software that I have to manage and you can see it reflects an increased cost and ultimately the consumer pays for that cost. So what is the solution for all of this? The solution is to standardize. And how? And standardization is through creating a common specification for vehicle updates, for ECU updates. But if that is possible, then I can bring any ECU to an OEM and OEM could say if this confirms to the single-lions agent spec, I know how to, it is updated. Doesn't matter whether it's a powertrain or a brake controller, infotainment system, I know how to update it. If OTA-ready systems can be brought that can work in harmonious with each other, in harmony with each other, then it substantially reduces the cost. And it says spec that is well understood, defined. And that's how we start to begin reducing the complexity, increasing efficiency, all the words that we have talked about in the previous slides. Now, as you can see, these are the representative members of the ECU single-lions, and you can see there's a large focus by the tier ones themselves to come and standardize their update mechanisms. But this is not just these tier ones, there is OEM, there are semiconductor companies, they're also part of the alliance who are doing their work in the background. Let's talk a little bit about the e-sync bidirectional data pipeline. So you can clearly see that there is a cloud, there is the vehicle which has a client, and then there is the agent. And you have the server client APIs. Both do updates as well as data gathering. These server client agents are scalable to any number of edge devices because of the way they have been architected. E-sync itself is agnostic to the cloud infrastructure or the device operating system or the payload or data format. And in the last two years, it has been in production with six OEMs worldwide, and these OEMs are Europe, China, Japan. So it's not like it's confined to one region, it's quite a world-wide acceptance. Let's look at what we are trying to focus in e-sync alliance, and the e-sync is alliance we are trying to provide compliance. Compliance means interoperability, which means how we can work to make all devices talk to each other and in a very prescribed manner. And this conforms to the architecture, the minimal feature spec, and the APIs. Now these APIs define how the compliance can be driven for servers, agents, and clients. And they can come from different sources. What we have recognized in the alliance is that you want to democratize the process, which means you don't have to get it from one single source, the whole end-to-end system. So you can get it from different suppliers, so long as they are compliant products. Similarly, the alliance also focused on existing infrastructure. OEMs have existing infrastructure. So how do you take an existing infrastructure and without them having to spend and re-engineer stuff, clearly bring it in what I call a staged manner so that they can actually start to benefit from the standardization efforts. So there is a prescription how to bring existing infrastructure. Let me give you a few examples of the APIs. Now we have taken some selection and these are from vehicle database to OTA campaigns to operations of the end devices. They are REST APIs, you can see. And there are more that are being drawn today between the alliance to figure out how the data aggregation will take place. Now let's look at the ESYNC alliance view of the ecosystem. Now the ecosystem has, now this is classically how all OTA architectures reflect and so they should have a campaign, way of organizing a campaign, organizing policies, encryption, delta updates, compression, assembling components, and also when things fail to provide rollbacks. So let me expand these a little bit, let me organize. The cybersecurity and vehicle regulations are extremely important. There are several standards bodies, many are government funded. And here there are a few names we can put as representations of them. The UNEC WP-2010 is quite prevalent and visible. Of course there is the, in the USA and HTSA, then you have the INST, the NIST and then ITU, X3-1373. There are cloud providers. Of course there are three big names in the US. And then there are several big names in China too, like Baidu and Kensant. There are other efforts that have been about hybrid cloud as well. You have these applications that providers that provide fleet analytics, fleet software, fleet data, and there are several such companies. You have these third party companies like Akamai that are providing Syrian services. In the advent of 5G, there is MEC, tested registries. Then inside vehicle, there is a gateway, there is a domain architecture, and there is a zonal architecture with a new upcoming way of architecting vehicles. Then finally, it's partnerships, standardization projects, liaison activities, between OEMs, tier ones, consortia. This actually comprises how we see the ecosystem around us. Now how do you get started? So you have to find some kernel that can allow companies to extract value through the process. So the lines has created an eSync SDK. And what does it have? It provides a functional server account. It provides a downloadable eSync software, available Linux, provides a source code of a template agent that you can create and modify for your specific devices, and provides extensive documentation for OTA update process, how to write agents and policies. How does it start? So we have outlined a series of steps, steps one to nine. Step one is SDK, sharing file sharing server that customer draws, and that has documentation as a file. Then that can expand into creating your test environment with the agent, with the download and the connection to the server. And of course, then the process of actually authentication from the server to your device, checking the new updates, downloading new updates, informing the server about the progress of the installation, and then when the installation is complete, provide a success metrics back to the server. Now that we have defined what is eSync Alliance and its activities. Let me bring focus to the eSync Alliance and its Liaison activities with CoVisa. And I'll also describe a use case. Liaisons happen because there's a lot of background work that has continued to happen even before a Liaison happens. So in this effort, eSync Alliance and CoVisa have been working a lot in informal gatherings at CES, at Detroit. And as a result, we have brought in a level of understanding and cohesion in our thought processes that led to creating a Liaison to provide greater focus and formality. And so the initial focus is the CVI initiative and the eSync's data gathering. The goal is to develop APIs for the automotive industry standard, common data model, common service catalog. And so there is a focus, and what's the focus is this having this regular cadence of joint technical discussions, eventually creating a demonstrator and proof of concept projects. Opportunity for a joint demonstrator and POC. So what CoVisa provides is a focus on the vehicle signal spec, standardizing in vehicle data formats. Of course, they are described in YAML and this gives you data types, variable and so on. And in the case of the eSync Alliance, you have the opportunity, data opportunity. And in this case, we have taken a special use case for the OTA data metrics, update metrics between the server and the client, the client and the agent, agent to the device. And so you're building it right from ground up back to the server. So we wanted to take a real world example. And what we all are concerned about, for example, you're very concerned about the performance of your whole update system. So obviously one of the measures that you will take is how to measure time of a date to the edge and it's traveled back to the server. You can set up an experimentation in an environment to measure and validate such metrics. So there are many factors in OTA performance. Now the server itself, you could say, hey, what's the sign on time, what's the upload time for your packages, how do you create campaigns, generate delta files, deploy across geographies. There's a lot of parameters that you could track for server performance. And then there is the client. The client will, for example, it's how to indicates to the server at the start so that we could say what is your startup time for a client. How much time it takes to download updates, manage service interruptions, verify updates, check policies. And if there is a issue of rollback, you could even do a metric on a rollback. What about the agent? So agents typically have, may have secure module, hardware security module. So it'll take some time to decode that. So what is the decode time there? What is the policy enactment time? How much time it takes to reconstruct deltas update? How much time for updates? How do you mitigate failures and rollback? And all these are metrics that are real world and very much relevant to any OEM. So what we're trying to do is a confluence as to how to bring the data, data gathering architecture that's described in the E-Single Alliance. And how do you harmonize with what VSS catalog and VSS signal specification is all about. So how do you bring it all together? So you take the E-Single Server Client agent model and then you take the agent construct and create the VSS library and embed there. So that when you bring the data out of the agent, it's already conforming to some format standardization that VSS wants. Now if we can generate data that already confirms to such formats, imagine that you don't need a translation at the edge, at the top, sorry, at the cloud edge, where you have to transfer data to the VSS catalog. So a laser activity allows you to think of ways of simplifying the process and create harmony. Now to outline an example. So we have the vehicle infrastructure, vehicle infrastructure metrics and this could be authentication and connection times type of networks because the speed may impact if it's a 4G or 5G or a Wi-Fi because each one has a certain what I call bandwidth. What is the type of cloud payload size, download times and retries. And what are the vehicle metrics? So SHA is our secure hash verification time, encryption, decryption times, in-vehicle network speeds, CAN is a slow network, LIN is even slower, FlexWay is a faster network, most and so on. And of course Ethernet is the fastest. So we can define payload size, policy check times, transfer times, military construction and these are all what we have set up as a metric for our own evaluation. And this is what we are going to evaluate. Now, we have created, now several slides before we created the VSpec which was using the electric motor as an example. And now we are creating a VSpec file for the agent to bring out data in conformance to what the VSS catalog wants. And here we are giving the type instead of an attribute type here is a branch. And we are describing details of different OTA metrics. Now, what are all these OTA metrics? So this can be further explained in the next slide. So these organization of the metrics and there is, for example, vehicle children and general has OTA metrics and OTA metrics has further children which can be brought into V2X metrics, client, agent and external metrics. Now I can go further down by expanding the OTA metrics to the V2X metrics. And so I have a whole list of signals that the VTS metrics creates. Now I can go further down and expand one more thing. In this case, I am expanding the client metrics and the client children would be client SHA verification, client SHA verification error, time, transfer time, transfer retries, all this becomes, so you can actually keep breaking this down in a tree form and you can go and add all this information and that's what we are trying to put together as part of our project. Now, having described how what Covisa is currently doing, what E-Sync Alliance is doing and how our liaison activities are coming together, we want to figure out what has been accomplished and what we want to look to the future of standardization. So it's clear there are several standards that are emerging for connected vehicles and including connected devices. So we need to create harmony so that we are not reinventing the wheel time and time again. The liaison allows us to create a way for transfer of data that can go from the base from the device itself to something that the applications can use. And then of course we are going to collaborate on building this vehicle catalog to be more diverse as we had talked about. So we'll create use cases, we'll create a simulator library of devices and so on so forth. Now, how do you look into the future? There will be several other areas in which the Alliance is looking to collaborate and one such area is this autonomous driving software, which is being driven by Autoware Foundation and open source development community. So you have two ways to look at it. One is upcoming bodies to which you need to liaison, but we also have to see what existing standards already exist. And is there a way to confirm to what they have already prescribed because there are devices using those standards and the classic is Autosar. And so where we are, where things are starting to evolve, we start to do liaison where things have been defined, you try to figure out a way to make them all work because you have Android devices, you have Ethernet based devices, Autos based devices, and then you have a bunch of Autosar based devices. And all of this are in the car and we all have to address them. So now this brings to me the conclusion of my presentation. And thank you. And I'm looking forward to answering your questions.