Efficient, open source and cloud-native orchestration and platform reference solution for SDVs

This talk presents insights into the development of Software Defined Vehicle (SDV) platforms, focusing on the need for cloud-native approaches to enhance flexibility, safety, and determinism in automotive software. The speakers, Chari and Abi, discuss how traditional software architectures can be improved by leveraging orchestration layers, particularly Kubernetes, to enable smoother updates and resource management. They introduce two dimensions of orchestration: spatial and temporal, which are essential for managing workloads effectively in automotive systems. Demos illustrate how these orchestration techniques are applied for real-time performance monitoring and resource reassignment in mixed-criticality environments. The contributions to open-source projects like Eclipse Prep and Tani, geared towards enhancing cloud-native functionalities in vehicles, are also highlighted, emphasizing the importance of community collaboration in the automotive industry's evolution towards AI-driven solutions.

Thank you. The today the Abby and I introduce the some of the uh the our thought and our ideas for making the SDV software platforms. So the there are the so long and boring the the tax in there even though that the I will the explain and I will introduce the very simply if it's possible and then I will show the some of the demos for for

the understanding. Okay. Okay. the I will introduce myself first. The my name is Chari the that port was taken in last year the in the English SD in Korea event. So looks good. I'm the principal the research engineer and and also the in the the CTO division the I'm a the project leader of the SDV software platform and I have the another hat the for the opensource

community so the I have I I'm the project leader of the Eclipse prep project and Eclipse team project so and the Abi the could you >> hello everybody my name is Abi Shakan from As Julie is addressing, I go by Abby. I lead partner and ecosystem development for IMA mostly for the Red Hat in vehicle OS. I take care of partnerships with OEMs, silicon vendors, tier ones

and ISVS. And I think Chulie will run through the first half of the slide before I kick in. Take us away. Okay. The Yeah, that's it. the the in this page the I'd like to talk about the the what is the SD requirements and how how do we the how can we solve that issues and the the and what why I did the explained that we need

to prepare something like the cloud native approaches for the SDV software platforms so and then I will show the some of the demos yeah let's The first slide the in the past before the the usually we made some some of the software the architecture and the software modules like the Lego bricks that means that it's very the it's very it can be the meet something the safety

requirements and determinisms or the other functionalities is possible but in the case we it's not easy to update after the vehicle is released because it's very tightly the coupled and very static structured but the to get something the curable and adaptable and flexibility in that case we need to care about the the something like the after diagrams in that case that that the each modules the still

the coupled But it's a little bit the loosely coupled and also in the case we can the smoothly move and smoothly change the structures. But in that case we need to we have to the handle and we have to prepare something like the the some of the another modules or the or the another the methodologies for making some safety and determinism or the the vehicle requirements. Okay.

So how to make this? So in that case the I'd like to talk about something like the the orchestration layer. So in the cloud industry the we usually use the kubernetes the in the the if we use the kubernetes when we use the kubernetes the software engineer just focusing on their own software the business logics they are not focusing on the operation and how to the the

control the something the server the resources about that they are only focusing on their the service logics. So in the case that we I I'd like to talk about the functions in the case we we can leverage it that the legacy architecture for example the adaptive autos also and we can separate operations for the make of configuration and man make the manifest and then the orchestration layer

cover to the automat the automatically the operation for the applications. So in that case the to get some the safety me safety the requirement or the to get some the the determinisms it's the frameworks and API can cover that part it's similar with the legacy architecture but with the operation this separate in that case the orchestration layer to maintain and to the to shield and to monitor

that the the required the state and then we can have the flexibility for the SDV platform. So that's why the I mention the cloud native orchestration approaches it's needed for the SDV platforms. Okay. So the we we usually talk about the orchestration things. We usually think about the the the Kubernetes but for the vehicle systems we need to care about the the other parts of the the

the safety safety related or the determinism or the realtime things also. So that's why the we suggested two types of two dimension of the orchestration. one is special and the other is the temporal So in the special orchestration in that case the specialation the is in charge of the where the workload should be learn and the which environment and which requirement is needed for the workload learning.

So this is deployment to the SOS one and to the SOS 2 or the cloud also and resource allocation for the application CPU, memory, networks for all the other these resources also and the temporal orchestration in that case the temporal orchestration should control the about the when something like the execution time or the determinism even the even if the the the workload learning in the different the

issues. So like this the application one and application two are the consecutive workers in the case the how to control the the consecutive work the execution time even if the workers the pipelines are learning on the different theu and the last one is dependencies from and application three so that's why the We they contributed the prep projects and the team projects. Thanksfully the the assign the the

in the last week and two weeks ago we the compound we got comp confir confirmation about the tempan projects. So the the the probably the the the pro publicly yes sorry publically the contributed and publically the the opened so the there are two opensource projects one is pity pity is focusing on the spatial orchestration the based on the multi-issue systems and also tani also the focusing on

the temporal orchestration based on the across the systems with the PPD and tempanic case in that case we can the improve we can improve the the forback scenarios or the fail safe or the fail operation scenarios to for the each applications. So okay the boring part is gone. Okay. So you can you can the watch the video some some of the video. So that is the special

orchestration use case. There are two the main use case. One is the cloud offloading and another is the automatic the resource assignment. So left side left display is HPC and right display is is showing the the cloud monitoring the the status. So there are two the SOC and and one more the cloud side. So in this demo we used the SO2 and the cloud side. So you

can check this too and also the this the CPU uses the the indicates two part one is the safety functionality and the another is the the C functionality. So in this demo we leverage it we used the the leed invic OS. So we leveraged the the container ecosystem based on the le invic OS. Okay. Let's see. Okay, let's check the aas workers are running in here and

the new function where the deployed here. So in that case disturbation are occurred and then the apply the property in that case we can the something like the le assignment for the computing resources and also some of the the non-safety application can move can offload over the on the cloud side. Okay. Next thing is the temporal orchestration. The use case temporal orchestration is focusing on the the

target FPS maintenance. The usually the in legacy system that we have some of the monitoring features for the the application functionality or the application the performance things. But in the case that we need to make something the source code or the making some the the not the unified the interface but the with the team panic case in that case we can cover some the even even if

that is the customized factors for example the fops in that case it's it can cover by the team projects so so the target FPS the monitoring and automatic the resource assignment with the prep and the company. Okay, let's This one is the procession display and this one is CPU core. This one is perception algorithms running on the four cores and these graphs are the the latencies for

the FPS. So this is something like a metric data. Okay, let's see the in this demo the in our the demo the we defined the forpect scenarios for the if deadline mis count the over the 15 in the case we defined that is failure and CPU core reassignment for the fair operations. So in in this demo the prep can cover the special resource the reassignment and team

can cover the temporal deterministic scheduling and report for that. Okay you can check the this the count it could be the added and the blocked. So you can check. So see that the price action algorithms something the something wrong in here and the miscount the over the 15 in that case the pink one from here to here. Yeah, it works actually the the we try to the

deadline miscount just one the under the one or the two in the case very very short and very quick. So we can't catch that situation. So that's why we we set up the 15 for the this demo. Yeah. the additional use case for the Eclipse SDV blueprints. The as you see in the two months ago the in the Eclipse SDV community in Bone actually the at the

time the I watched as I know the this demo is the Eclipse SV E2E demo blueprint. So we thought oh it's it's great it's we can we we can leverage that demo with the our the Eclipse prep project. So in this demo in this demo do we the what point we put some our additional features on based on this. Okay, let's see. So from here to here

we made two of the the issues. One is the master and another is guest. the the base project has just won the as I know just one the Raspberry Pi but the in this case we made something like the multi-node system multi ECU systems the with the lead the auto SD and then we we connected the Arduino devices like this the like this like this and the

joystick and the the some of the LED is are the similarly the same as the the base project. And then the we put the additional the air the additional the devices for example the the rotary and the merger to make sound and the low qu low frequency burgers. So in this demo the we would like to the we would like to leverage the existing functionality the it's

not the unchange it not change it the LED brinks left and right the based on the joystick the left and right side and the the leverage that and we add additional features the prepity on le the central and rotary the input reconfigure the version the device at runtime. That means that the when someone change the rotary the control the lottery and push the button in that case

the that systems has the different another scenarios. So, so that scenarios part we the we assumed we did representative the BGER sound the something like the high frequency BERS and the low frequency BERS. So and joystick push it triggers BGER sound. Okay. This is system architecture. There are the serial cooks bridges. Actually the the base project already have this the project this the architecture and also we

add add our the prep master and prep agent. Actually the our prep the master and agent are connected by the gRPC and also prep can the listen and the prep can the the the the listen some the vehicle services or the vehicle status by the by the the the IP or the DDS or the gRPC. But in this case we leverage just this the URL the command

line. But the after this demo after this event we will change this part to the to to the the VSSs the VSSs or the DDS or the semi text. Okay. And the prep agent control the this part the cook serial bridges. Pasha bridges they connect with the Arduino Bger and Arduino merger the this one is low frequency and this one is high frequency. the basically the we

the even though the prep master end here and prep agent in if someone want to change their scenario in that case the scenario file the deploy in here and then prep master understand the status and the prep master the request to prepare agent and prepare agent the control the status. the another type of the the system So the the we used the the x86 the mini PC

two mini pieces and the Arduino devices three5 and the LED and joystick and rotary and ka sera data broker and ka bridge also and the master and agent. it's legacy features. It's the sounds big. Yeah. Change the scenarios. Change from the passive to active. It's the active. So in that case, it works well. and we can change the scenarios from the the lower and the the the

high high frequencies. So in that case we assume we assume that the the the when the the OEM or the when the automotive company want to make their the vehicle systems in the case they can have something like their portfolio or they are the the something like the road map for the models. For example, there are the the several models or the several trims for the vehicle

vehicles. So so in that case the we we can replace the for the premium or the for the affordable. So so the the the the v the hardware because hardware are changed. So do we need to the make and we need to put the the human resources and integration cost for the making some the the pol the the So even though the function is same the makeger

make sound making sound is is just function and the push the button is just functions function are the same but the operation the little bit change it from here and here but the in the legosy architecture we need to the push the the the a lot of the human resources a lot of the codes and a lot of the integration time for making the same policy. But

with the Eclipse property projects in that case we can the cover something like the separated the separation from the the vehicles and the user space. So so after that the the we can make something like the the the different scenarios or the different the use case even if the vehicle is listed. the that demo actually this demo this demo the source code already the opened and contributed

in this repository. So you can the follow up the our the our contributed source code and you can make some the same demo demonstration based on this source code. Okay. I think it's very faster than I expected, but yeah, I get more time. Yeah. Thank you, Julie. So, as you saw, what we built was an open and everything what you saw over there, you can see it.

You can build on it and test it. But I'm here to address the fundamental why. Why is open-source important? And the journey from softwaredefined vehicle to a AI definfed vehicle is undeniably a journey. And the engine for both is open source. As you see, look at the numbers on the slide. The top 500 supercomputers on the world runs on Linux. 90% of public cloud workloads for AI

is on Linux. 80% of developers use Linux for AI development. The open source community is growing bigger as well. There's around 395 million repositories on GitHub. That is 19% greater than last year. 60% of top 10 opensource projects are AI focused and over 1 billion contributions. And 82% of organizations state opensource is critical to their AI future. So it's clear open source is what's driving innovation today.

What's exciting for us is not only cloud and AI. Look at the right side of the slide where the automotive communities which is growing quite fast as well. And this is what I want to talk about next. At the top you see CentOS automotive special interest group. This group manages the automotive stream distribution. Think of this as the open-source base for Red Hat in vehicle OS. What

we sell as a product. Second is the Eclipse softwaredefined vehicle group. Um along with ESCO they're building a base for STVs. There are also others and other communities over here. Kisa, Elisa, Sophie, Autoare all of them focus on different areas connectivity standards and others as well. We are happy to go into deeper uh conversations in all of it. But what the key takeaway here should be Red

Hat is active in all these communities. We are working on all of it and contributing to it. But why does this all matter to you? Look at the left side of the slide. All the automotive ecosystem players, OEMs, tier ones, integrators and uh ISVS, they're all working in open Things like base Linux, middleware and virtualization layer is common to every OEM. Not everybody has to build this

alone and from the scratch. Look at the right side of the slide. If OEM A B C use the same base layer, they save a lot of time, energy and effort where they focus on the non-ifferiating or sorry the differentiating aspects of building the features and the apps which actually add value and they can think about what customers really want. And that's where the differentiating aspects from

one brand to the other comes into using the same base layer. You can start now. You don't have to wait. Development teams today wait for the board for the chip before they actually start development. Look at the left SL uh left side of the slide. The phase one you can start in the cloud with the same base Linux a middleware and an app you can do early

testing basic validation with very low cost so you don't have to wait phase two this is where the virtual ECU is kicking you again the same middleware but you add more apps so it's easy to update and maintain and scale And finally phase three, this is where the actual testing on the hardware kicks in where you do real world testing. So from phase one to three, you

can start from the base layer today. You don't have to wait until the hardware is available. And finally you can go into field testing certifications and productions. But let me connect the dots together here. So as we saw open source communities are building. Opensource is the key for innovation. So that's the reason why we have built Red Hat invehicle operating system. This is not a Linux which

is something which you try to fit into the car. From the day one, we have optimized and tailored this for automotive. What does this offer? These are the key features. We offered safety certified Linux up to ASEL ASELB ISO 262 62 certified. So you already get a safety certified Linux where you can start building on top. We offer mixicality support. You can run different workloads on the

same chip. Real time we provide preempti by default. We also provide fastport capabilities and on the right side we provide all the packages which is part of our flagship product which is Red Hat Enterprise Linux and automotive specific packages. We support x86 and harm hardware architecture. We support diverse use cases, infotainment, ADAS, telematics, gateways up to ACL. And we also support modern software development practices, containers, DevOps,

build, test, deploy cycles. let me add all of this together. The journey today is definitely from softwaredefined vehicles to AI definfined vehicles. As mentioned in my earlier slides, we provide the safety certified Linux cloudnative development, security resources and a partner ecosystem of hardware vendors, tier ones and ISVS, so you're not locked in. We also provide long-term uh support and a platform for AI edge use cases. we

are happy to work with you to a pro proof of concept of sorts. Let's talk. Thank you Julie. Thank you Avishek. Um, I'm sure you have questions now. We have enough time for enough questions. So, raise your hand. Yeah, there's Do we have a mic? Yeah, there. Thanks. >> Hey, Julie. As an icebreaker, um, you showed the rearrangement of the tasks in this one demo. >> Yeah.

Um the >> basically the safety tasks moved a little bit to make room for the blue ones. Actually >> this one. >> Yeah, exactly. This one in the animation the safety tasks moved to the next four cores on the right side. Why haven't you moved the blue ones and left the safety task sitting safe and sound there? Any deeper meaning in that or >> Oh, the actual

the Okay, the good question. the the you you you you catched up actually the at the time the we the I focused on the how to make some the mix critical the domain for the safety and the non-safety application they work together in the same issue or the same domain. So you mentioned why don't the blue one move to or the the the throw the away the

for the safety domain the actually the with the in the system level we thought the system level the blue one also safety functions the red one also safety functions so in the case it's something like the compared the situations so we dot the red red one the pink one we prepared the when the the problem is occur in that case the pink one can move to the

other the locations or the deployment for the the but the blue one there is no the the specific scenarios or policies so that's why the pink one something like the escape >> okay thanks That explains it. >> Thank you. >> In the second. Any anyone else? Any other questions to Julie and uh Abishek? >> Anyone? >> Maybe I have a question then. So um we heard about

rivals, we heard about pulpiri, we had we heard some other keywords in there. So is there something where we bring all like there's the elephant in the room is obviously escore, right? So is there initiatives bringing this all together somehow? Can you comment on that? So I mean when you talk about I mention where we are actually more focused on but if you're talking about the non-ifferiating

stack that's mostly on the escore side I mean we have heard mostly this talks in Sophie as well but I would say escore is the most relevant one here. So you guys are in talks with Escore and I I I I I know for a fact you are but um can you tell me a little bit more about how this is going? I mean I think our

goal over there is to uh position ourselves as the base layer base Linux layer. Um and as far as I know at least things are going pretty well. uh but I don't think we have reached where we want to reach and it's obviously it's also because of escort right and it's a new community where things are being understood there's a lot of different players where they're trying

to uh bring their own stuff on. So from Red Hat what we see is communities take time but it's really important for automotive to have that non- differentiating layer given where automotive is today. >> Okay. Thanks. Um anyone else have a comment or question? Yeah over there. >> Y hello Manda from Denzo. Uh one question for you guys. Thank you for your presentation. Uh so I want

to know since you mentioned about uh Sophie and Escore, I want to know what are the current developments in the containerization area in respect to Eclipseore or how is it going if you have some idea. So the the your question is did the did Sophie and ask for the what's difference or the what's the the similar the uh so I want to know specific about containerization which

is kind of a maybe a block inside Eclipseore. So are you guys involved in such way in in a way to contribute in this area >> and if you are then are you how can you uh tell some more about it? >> I mean for Red Hat in vehicle OS at least containers is part of our safety story. We use containers for mixed criticality between QM and

safety workloads. The same safety architecture is what we try to position into escore as well. But where we stand in terms of containers being used in the context of >> I don't know >> I have to be honest over there >> the the in our side the property and the tempen project side actually the the we are the governing body members in the sophie so the basically

sophie the the vision of the sophie makes something like the they the leverage the cloud native approaches is for the the vehicle systems. So the first the when they the occur and the when they making some the there the consortium. So we we are we joined that the the consumer also and the the we at that time we developed something like the cloud native approaches and the

the how to make some the mixed critical and the container ecosystem. how to the leverage the vehicle systems first. But the the in this time the we they've definitely a little bit change it our the approaches the base because the container ecosystem and container the the container ecosystem or the cloud native approaches is good but it's not uh enough the the the the performance or the safety

mechanisms or the the determinisms for the vehicle systems. So that's why did we make some the team pan and prep and something like other the modules in in house. So so and and further more we leverage it how to this integrate with the ascore the for the the more specific and more focused on the vehicle system first and then the how to the leverage the cloud native

the something like the flavor. Yeah. Yeah. >> Any other questions? Just there. >> Yeah. Thanks for your presentation. Uh could you go to OEM journ uh the slide OM Sha? It's one of the last slots second last. This one next. >> Yeah, this one. >> Um, so from in point two it says simulate real world. Uh, does this mean only software simulation? Because you could also go

from two to three directly going to hardware in the loop testing. Uh, so I mean if you already have the hardware, yeah, it might be possible. But if you want to try new hardware then there are also different simulation steps you could do >> right those are on virtual ECUs on phase two what I'm talking about but yes essentially you can skip that step as well I

don't know if that's the point what you would what you're trying to >> no my point is uh how what would be the approach for completely new hardware if you want to implement the pulpy on new hardware how would you test it >> I mean uh I think we go through the same steps at the end, right? Because it's much more faster instead of waiting for the

new board. >> Okay? But if you directly go to the tape of your hardware, then it's very costly without prior verification in simulation. >> Right? That's where the virtual simulation comes into play. >> Okay. And for the virtual, what exactly do you use there? >> What do you mean? >> Now, you can do system C simulation of your hardware. You can also do RTL simulation or post

layout even >> What simulation? Sorry. >> Uh register transfer level RTL >> This then very hardware specific >> So this is mostly coming from the software side, >> right? So not exactly on the hardware level. >> H okay. >> But we don't go into that depth. But if necessary, yes, I think we can make that happen as well. But we are looking mostly from the software angle.

Okay. Any other over there? All right. Thank you. I think it's question to Shul here as well. Um or both of you. So considering this software hardware combination that you just showed, we saw the Arduino, we saw the the normal PC setup, what is the next step in it? Are you planning to bring it to automotive hardware into a vehicle integrating this? Any plans on >> That's

a great question. I mean I mean it's great seeing this software stacks, right? and and the demonstrator from Christian in in having the lowlevel entry in order to start developing in order to use the the the elements from the community being done but uh going into into vehicle hardware going into the nitty-gritty details for having whatever kind of board support packages needed in order to do so

would love to see it and I'm just curious if you're planning to go there >> for me I think that's the ential goal for all of these reference tags. I don't think anybody likes to just do science projects. At some point we need to transition and execute but exactly what is in the road map for the next I don't think we have nailed down those details yet.

So you have like still three minutes so put in your questions now. Is there anything you Yeah. want to know? Uh thank you for the great presentation. Uh I heard a few times you use the word blueprint. Uh maybe it's time you shared it with the whole community and make it into a proposal, make it official. So the actually the the as the eclipse prepare project the

we already something they have a plan to make some the the blueprint proposes the leverage the our the several demonstration the use case. let's see we will do that. Okay, maybe one quick question from me. So we've heard Revis has like ASEL bravo certification and so what about Pulp Piri where we are on this ASEL category list there. >> Okay, thank you. Thank you for questions. Yeah,

actually the property is the our the open source project. So and firstly when we make some eclipse prep projects or the actually the picol projects at that time we thought we need to prepare the mixed critical orchestrations for the systems because there are a lot of the various various the applications are running together in the one vehicle systems. So in that the prop the purpose and in

that perspective the we are the pro progressing the for the ACB grade the prep project and also the we are finding out something the how to the control something like the HLD applications by the the the our picor project. So, so firstly the I can announce okay I can explain the prep projects will be the B level and uh the picoros uh I'm not sure hey thank

you okay then again a warm applause to Julie and Abby You check.