Open roads ahead: Collaborating on a SDV reference implementation for commercial vehicles

This talk provides an in-depth overview of the commercial vehicle industry, specifically focusing on the challenges faced by companies like Cummins and Allison Transmission in integrating open-source solutions. The speaker emphasizes the need for application portability and software updates in a landscape of high variation in vehicle configurations and tight profit margins. He discusses the formation of a commercial vehicle blueprints group aimed at addressing common use cases and problems through standardization and collaboration. The speaker highlights a prototype demonstration that illustrates the use of Eclipse Symphfony for fleet orchestration and managing communication across various ECUs. He underscores the importance of evolving their technology stack to adapt to industry standards while ensuring security for in-vehicle communications.

[music] All right. Thank you all. Good afternoon and uh yes and thanks thanks for the introduction as well. So uh we're going to start off and give you a little information about the commercial vehicle industry, how it's different because we realize there's a lot of automotive passenger car focus here. Uh but also we're going to talk about what we're doing to specifically try to solve problems. So

I think you know the context when when we first joined open source you know when when Eclipse STB was formed it was like what can open source do for us? What can we what what packages can we go download and it's going to put it on our our compute device and all of our problems are solved. Well we've you know we've we've gotten more experienced over the

past few years and it's more like what do we need to have solved by open source and then how do we use open source to solve that. So I'll start talking through Um, so first of all, an overview of the commercial vehicle industry and our companies because you may not have heard of them. So, Cummins is an uh mostly a diesel engine provider in larger commercial vehicles.

So, think from 7 L up to we have engines as large as 95 L. And Allison Transmission is one of the largest suppliers of transmissions as well, especially in in North America, but also globally. Uh we serve multiple market segments. So we have we're in a lot of different types of vehicles with a lot of different types of fleet owners. So that could be onro on highway

truck. It could be commercial buses and it could also be mining or even power generation types. We serve hundreds of OEMs. Most of them very small, some of them very large, some of them, you know, larger than our company, some of them much smaller. But because we have such a huge number of of uh customers of OEMs with which we work, we have to figure out how

to make our software more portable and more compatible without having to rewrite it every time we do a software integration. Our customer and our market segment's very different. Uh our customers operate at extremely low margins. So you think you know 2 3% profit margin is what they have to work with. So when we're talking about we have this great new software or great new feature that's going

to require this new hardware investment and we've probably already lost the interest of our customers because the cost of the vehicle goes up. It's a big investment that we have to recoup quickly. So we're in the commercial vehicle space a little more slower in our progression and more deliberate. We have to have a very strong business case of ROI before we move software into production. And that's

why we really want to have some scale from open source and make sure we have the capabilities there so that we get that cost benefit when we take it to market. Um and finally, you know, we have much higher variation. A fleet may order many different configurations of vehicles from from even multiple suppliers to to tailor to the exact use cases to get the profit margins thereafter.

So we have more variation uh and you you can have multiple brands of engine in the same vehicle chassis, multiple brands of transmissions available as well. So with that setup, what are we trying to uh accomplish with open-source software and STV? Well, the first is we need application portability for both a tier one provider like us who's going to write an application that runs on OEM hardware

and for the OEMs themselves who have multiple global platforms where they need to deploy applications. We really want to write it once and be able to run it in a semi-h hardware agnostic fashion. The second is we need to keep our software up to date. This this is software on our ECUs. It's software in the Telmatics or high performance compute and it it can be other applications

as well. And finally, you know, we think CAN is going to be around for a very long time. And especially, you know, us being powertrain providers, we want to make sure the CAN is accessible, but also it has to be secured because we're talking about communications across domain. We're going from a connectivity domain with cloud connectivity into this very functional ASL level uh of ECU. So we

we're we're working on how do we standardize that and through open collaboration uh through SOVD and others how do we add even more security than it has today to make sure we can achieve this. So uh you know I I talked about how do we uh go from what what can open source do for us to what do we need open source to do and how do

we make that happen. We have formed a commercial vehicle blueprints group and uh unlike a lot of other groups within Eclipse STV. What we're focusing on is use cases. What are the problems we have that we think are infrastructure and interchangeable type of problems and how do we define those use cases? And then how do we talk about blueprints that could start to address that? And then

finally, how do we turn this into a working prototype so we know that that it actually is solving the problems we want and so that others can replicate that architecture and use it. So we do meet uh every other Thursday at 4:00 p.m. Central European time and um we're we're starting to get even like each meeting has more and more participation. We've had two in-person meetings as

well. So, we do have a list uh a pretty good list actually of use cases that we want to solve and we've gone through prioritizing that. We're starting with some easier ones where we have blueprints there. And what we're going to do uh today is is do a demonstration of one of these use cases and showing not just how we came up with the blueprint but also

how we're using the different open source packages getting them to work together and showing and demonstrating that it is functional. So, what are these use cases? The first one is edge applications. How do we put it in an OCI container? What are the interfaces that we use? And then how do we use that to do something like uh an ECU software update on an embedded ECU. The

next is a powertrain feature integration service. So Allison Transmissions has their proprietary T uh uh u ECU that's on their transmission. Cumins, we have our own proprietary ECU and communication way in ours. But what if you want to do something like uh switching between a performance mode and an economy mode? There's no standard way to do this. There's no service that defines that. So we have prototyped

a service that allows uh any other service in the vehicle to to control this uh mode and do the switching without knowing that it's a a a Cumins ECU or an Allison ECU there. So we are trying to move these proprietary functions out of the ECUs and put it into a more standardized and serviceoriented architecture. And we do have our first draft of that and we think

you know is this the right technology solution? We're not positive but we're getting feedback. We're we're showing what works and then we'll explore other other ways to expand it into other parts of the vehicle. Uh and then I'll talk about one more uh specific here and this is embedded controls portability. How would we move you know maybe uh something out of an embedded ECU and move it

into the high performance compute and how do we define the services that work around that? This is a more complex one. We talked about this that this morning. this this we don't have an easy solution yet but I think this is going to take a lot of collaboration over the next year to talk through uh you know different hardware architectures that would exist for this software architecture

to function on top of so this will be the the function and the focus of this commercial vehicle blueprints group going forward uh so I've presented on this before um we've been working on an architecture like this for quite some time this is on the telematics device or on the high performance compute device. So, um, four years ago, uh, Cummins, we launched our own Telmatics device that

is based mostly on an open-source stack. But, of course, four years ago, there weren't very many Eclipse SDV projects for us to use. So over the over the years, we've evolved that architecture to use more open- source projects and to figure out how to use more standard APIs to accomplish what we were doing before in our own I would say proprietary architecture based on open source. And

you can see here uh some very familiar u project names. This is based on Eclipse Symphony and it is the orchestrator or the state manager. we have in Kyios as well which actually uh controls the the workloads and can start and stop the containers and then our proprietary software that's what's inside these two containers here for labeled as Allison and Cumins what we're doing is taking our

proprietary functions putting it in an OCI container and then putting into this framework so basically the the quick summary is Symfony can control our uh our containerized applications and then the application can make changes to our ECU such as performing a software update. And we've created a service that uh defines what where we are in the update process and when that update can take place safely and

if it's successfully succeeded. And uh we are heavily dependent now on open sd uh cumins had contributed a project called cannot which was can abstraction and uds abstraction. But since then, open SOVD has gr gained a lot of uh prominence and capability. So we've shifted away from what our our initial solution and moved to where the industry is going. And I think that's really the focus of

what this blueprint project is going to be is to find these industry solutions that serve the broader need and try to adopt those as best we can. So uh I am now going to hand it over to Pria. She's from Allison Transmission and uh I'm really happy that she agreed to present with me today because as we started talking and I found out what they're doing with

their internal fleet of vehicles, they're using even more of the open- source stack than than we've been using at Cumins. Even though we've been involved with for quite some time, they're moving faster. So really impressed with how you're taking so many open source components uh testing them in your engineering environment and then taking into a production-like situation. Thank you, Carlton. [clears throat] So, I would like to

give a little bit of context first on uh where I come from and why what I'm doing here. So, I work for Allison Transmission. Um Allison is a global leader providing safety and mission critical propulsion solutions for over 250 customers across 15 countries. We have 15,000 employees now positioned across the globe. Uh we headquartered in Indianapolis and we extend our operations to uh in Belgium, Hungary, Netherlands,

UK, India, China and Brazil. Um Allison's mission is to improve the way world works and we do that through our unwavering commitment to our customers. And to give you a flavor of how we show up in our customers environment is um the this oopsies this customer here in Sweden uh is um you know owning a refuge application and they are dependent highly on our start stop feature

for their um efficient duty cycle. And the customer next to that is the uh in the entertainment industry they rely on our on a clean smooth and safe rides for their customers. And the customer here in South America Allison enabled them to be the very first fully automatic um transmissionpowered school buses. And when we speak of customer requirements, we cannot skip the emissions. So for packar and

commercial vehicle uh trucking industry, we enable them to meet their uh carb compliance for MX uh 13 engine. And how do we um you know cater to these bespoke customer requirements through carefully segmented product lines from 1,00 2,000 series all the way to 9,000 series. Um higher the number of course greater the horsepower and torque characteristics as you can imagine. And uh we also have specialized fracking

um uh transmission applications in fracking and defense and electrified propulsion as I said. And now comes to what I'm doing here. So Allison meets our customers requirements uh which is 100% uptime and optimized uh total cost of ownership. And how do we do that? through remote data acquisition, through careful analysis of the data that we acquire and fixing the quality issues before it shows up in the

customer's environment and my team enables that entire um opportunity for Allison. So I lead the connected tools team. There's about 10 engineers across the globe uh ranging from cloud embedded test um domains and some of the technologies we use are TypeScript, C, React, Django, Unicon, um C++, Python, uh and now recently Rust uh as well. Now some of the products to give you an idea is of

course like I said uh remote data acquisition overtheair programming of the transmission control module and data analytics which is powered by data bricks and powerbi as well as uh you know we provide the opportunity for the engineers to program and configure the parameters that they want to acquire remotely from the test field or even the customer field sometimes and we cannot do this on our own. Um

I would definitely want to acknowledge our uh partner Vantage Power who has been fundament uh foundational um in you know supporting the the um software that we support today and Oasis is our hardware uh vendor and uh we work with Geotab. They provide us the diagnostic trouble code from a lot of customers um um field trucks and then we provide uh action plan for the customers in

case of a diagnostic trouble code. Last but not the least, Eclipse and Coisa are uh the open source consortiums that uh have helped us uh make some advance advancements in the uh telematic space. Now coming to the topic. I know Carlton already went through this so we have probably heard this a million times in the last two days. Um the demo that I'm going to be doing

in a couple of minutes now uh takes all these different technologies and then forms a complete pipeline. Um I have a architecture diagram in the next slide that I can show you but basically it starts with Symfony which is a fleet level software orchestration. Its invehicle counterpart is Ankaios which does you know invehicle workload orchestrations. Kuka is an abstraction of the uh raw CAN vehicle signals from

the um service layer applications. Kovisa supports VSSS which is a common data um signal language um and across the industry partners and then U protocol supports uh communication standards that is agnostic to the transport uh layer. It supports um routing uh through IPCs, Ethernet, CAN gateways and C cloud proxies. Um it is specifically designed for invehicle distributed vehicle systems and uh use service of course is the

um service APIs that are compatible across tier ones. It's a standard um and I as I'm showing here um Eclipse and Kyios as you all know supports multiple runtime engines. So we have implemented uh the podman and containerd runtime. So we have a couple of applications that runs on podman and containerd and how they can communicate with each other. Um and then the U protocol of course

like I so this is the architecture this is the symfony um which is offtheshelf from the um open source project that we have uh we have deployed it as an Azure Kubernetes service. it uh we have a front- end uh portal uh through which I will be uh showing you a demo where I will be deploying some containers. I will give instructions to read a a signal

from the CAN. I will give instructions to write a signal over the CAN and I'll also uh on the on the edge box which is the telematics unit we call it edgebox at Allison. So we have um Ankyio's orchestrator which basically is either in launch mode or orchestrate mode. In launch it is just a pass through. It doesn't really do anything. So the CPU uh usage and

latency is at its maximum. Um and in orchestrate mode it shuts down a few containers based on our simulated health condition. So we have an app um all these are container apps by the way. So we have a health container app that essentially says that simulates a bad health based on that then kaios would shut down all the containers and I'll show you the CPU impact uh

usage impact as well. I think I covered everything. This is the bench setup. These are our telematics unit edge boxes as we call them. And these are the transmission control modules and they are all connected over CAN. And the demo that I will be doing is remotely connecting to this bench setup there. Now we'll get to the demo. This is the port uh UI that I talked

about. Um so I will be first installing uh base level um applications. So this is cooks data broker as you can see and then the CAN provider which is part of the data broker uh framework and then Ustreamer which uh helps us to communicate between Zenova and MQTT which is a feature of U and Ustreamer is just a configuration library that allows us to do that and

then the TCU health monitor like I said it simulates bad good health and then And the TCM read container um uh basically gets when it gets an instruction it goes and reads uh data from the CAN signal uh canvas sorry. So I have two edge boxes just to demonstrate the symfony fleet orchestration. Assume these two edge boxes are on two different vehicles but they are on my

bench but assume they're on two different vehicles. Just deploying it. So I'm waiting for all the applications to be running. And this is a prototype which was developed in four months time using all these different open source projects um with uh two embedded developers and two cloud developers. So if it fails, that's probably the reason [cough] So while that loads up um what I will be demonstrating

is how simple it is to add a signal that you want to read or write uh over canvas. Traditionally you would need to program the you know the CAN libraries and um also the underlying format and adding the PGN and all that stuff but today we are with the help of uh Kovisa's VSSs uh project we are able to just update a JSON file. So this is

a limited JSON file. Um there are some signals here not all and then this is a full uh JSON file and all we do is from the portal deploy it and uh and then we are able to read and write signal. So I'm going to go ahead with the uh with the one that's working. So all of these are running. As you can see one container here

is in containerd runtime. The rest of them are in podman. I'm going to deploy the limited uh JSON uh with the limited VSSs mapping to the CAN signals. So when I deploy the JSON file all the containers will get restarted. Um that's the way we have implemented it. So we have a CAND DBC downloader application that downloads the JSON file and then applies that so that the

next time the containers come up it recognizes the new JSON file and the associated signals. What I'm looking for is the CAN DBC downloader to be succeeded at the end of uh the loop that it goes through. There you go. Succeeded and succeeded. So here I will demonstrate how we cannot read some signals because I'm using the limited JSON file just to prove the point basically. Um,

powertrain, that's that's who we are, transmissions, and then I'll go with these sensors and I'm requesting to read them. Supposed to say it cannot. So that's what it says. Cannot read any of them because they are not in that JSON file. Now I go and update the new JSON file. So this is uh has all the signals. This will go through another loop of starting all the

containers again. So we don't need to uh you know kind of update the firmware. We just deploy that particular JSON file and the containers would understand that again. I'm waiting for the last one to go succeeded. And as you can see, all this can is remotely connecting to my bench, which means we can pretty much update the values. We can write and read from the CAN signal

remotely with the telematic unit and the transmission control module being in a test vehicle in uh Arizona probably. There you go. Succeeded. now I'll read the same signals with the new uh DBC file uh JSON file and I'm able to read the values. Now I will demonstrate the UDS right. Uh we do not have the authentication and uh you know the cyber related requirement supported as of

today. We still looking into open SOVD as Carlton mentioned for it but I can demonstrate a parameter that does not require additional security. Now I'm looking to see the right uh TCM write container to be running which it So now I'm going to write uh a signal using uds command again using data broker and VSSS tree model. writing to a parameter called boot level on two separate

uh ECUs sorry two separate vehicles. So now this says that this 1785 ending device is bad health. So this is a demonstration of symfony orchestrator uh fleet level orchestration where for whatever reason it stops uh it pauses its operation on one uh vehicle and moves on to the other vehicle. That's what it's saying. Now it comes back for the same IMEI says it's good. Do you want

to continue? Yes. Yeah. The second something is wrong with that second ECU. So I'm reading it and it's working on one of the ECUs. The second one is not working from the beginning. So me try it once. Okay. So that demonstrated symfony fleet level orchestration. The final one is the um ankyios orchestrator whether it's in launch mode or uh orchestrate mode. So I'm deploying uh sorry before

I do that I want to capture. So as you can see it's around 57% 5747 7.8 nconds. Now we'll see uh deploying orchestrate mode what happens supposed to be lower. So this all this is in launch mode and then we are entering the orchestrate So when we enter the orchestrate mode, the CPU usage is higher because the orchestrator is performing some actions and it's stopping some containers

and so on. But once it settles down, you'll see the difference. So what I'm waiting for here is for the symfony agent, the downloader, the health um and the Ustreamer. Those should be running. Rest of them should get stopped in orchestrate mode. Okay, so the downloader Ustreamer Symphfony agent and the health monitor So it does go down to 32% CPU and yeah 36% CPU and 7.8 8

nconds it'll drop down but essentially this is to show that u the ankyios orchestrator needs some work still uh to make it more powerful but we do see that the CPU usage there is a 10% drop and then the latency kind of fluctuates up and down that brings me to the end of this presentation and the demonstration any questions I can take at this point >> so

so first of all I want to I want to point out I've been to, you know, every Eclipse SDV event since Eclipse SDV was formed. I've seen a lot of demos. I've seen recordings of demos. I've seen ones run locally on a laptop, occasionally connect to the cloud. I have never seen a demo that connects to actual physical hardware and then that hardware connects over CAN to

an ECU and writes parameters. So I think this this is a first very ambitious and quite an accomplishment especially in four months worth of work which I think is a testament to the open source software its maturity and its and its developer friendliness. So round of applause for >> Thank you. [applause] >> So any questions we can answer for you? using VSSs. >> We're presenting Kvisa. Yeah.

Uh so what is your experience with VSSs? Uh is it off the shelf you're using it? Did you need it uh modifications, >> extensions and uh yeah and will you contribute back to Kavisa? >> Yes, absolutely. I mean like I said the UDS protocol is not totally supported with the VSSs. uh there are some UDS overlays that got added which I think it's probably because we started

asking those questions in that forum but uh definitely uh we are looking into uh improving that as well as the anio orchestrator so as we stabilize this as you can see I mean one of the issues didn't respond as expected so we need to stabilize this first and then we can contribute to the open source projects >> and and the message catalog itself the message catalog itself

you found something missing. So >> yeah, I mean I think it's more for the passenger vehicles and so you know we didn't see some signals that we were looking for and um and but you know but we know how to add them. It's pretty simple. So yeah >> useful in general please contribute yeah them back in this spec. >> Yeah. Yeah. It's very helpful. Yes. And I

would add to that, you know, I think VSSs is fantastic for reading signals and sharing them and especially, you know, sending to the cloud for processing or sending them to a fleet to know what's going on with their vehicle. I I think where there's a shortcoming with VSSs, and it's it's not a shortcoming, I think it's just just the limitations of how systems work is around the

cyber security. So, Priya demonstrated a UDS right to an ECU, but there was no authentication around that, and VSSs wasn't really designed to solve that use case. So as we get I think you know closer to production we're going to be looking at at other ways to do UDS rights. So that would probably be open SOVD and we would you know require a secure session be established

and then we would have a signed application that can only communicate with open SOVD in that one ECU to actually do the do the firmware right. So um you know it the way it worked here we wish we we had you know we could trust everything and and everybody and it was this easy to do but cyber security I think as we productionize things is going to

make it a little more difficult for writing through VSSs. Yeah, from your requirements uh on use cases uh do you have any performance um indications or requirements is it just uh real times uh you need or is it uh offline data you're collecting or is there anything special? >> Yeah, I think for now we're starting with easier use cases that that have no functional safety requirement or

timing requirements at all. So these would be more diagnostic and monitoring types of functions and if they completely fail and shut down no issues. Uh as I mentioned we're starting to look at some more advanced use cases to where we may be moving functions from ECUs into other domains. Time time criticality is going to be very important there. Um I I can't say you know what what

technologies we'll use and what those requirements are but it the problems we're solving now are not are not as complex and difficult as the ones we'll be addressing in the future. So that will certainly come into play and I think will will really uh narrow down the technologies we'll have available that that meet the uh the time requirements and and functional safety requirements. >> Yeah. And you

know another thing is um in terms of cloud-tocloud um you know communication when it comes to OEMs and tier 1's again we have their uh very uh custom bespoke implementation and we want to make sure that OEM doesn't have to reimplement or tier one doesn't have to reimplement so we need to establish standards there as well and of course R156 we all know it's there uh but

we don't know the amount of work in involved and the amount of preparation involved. So there needs to be some standardization around those as well. Those would be the requirements. >> Yeah, that that's right. you were just mentioning that some IP may be there and IP uh IP connections instead and actually actually that is a simplified diagram. Um typically between the the the SOVD implementation it would

be over some IP to a gateway and then the gateway converts some IP into CAN signals. So we we simplified it but you're exactly right like there it it is more complex than we were showing and there's more capability than we were showing as well. Any other questions? >> One question from my side, Carlton. So you are both members of the Eclipse Foundation of the STV working

group and you are working with quite a lot of open-source projects, right? Eclipse Symphfony, which one of that I also quite know a little bit about it, Cooks, all the others. How have you been finding the collaboration with so many different projects to come up with a solution? What can we do better as a community? I mean in the open-source um you know industry it to get

the experts time uh is is always a challenge but in our experience in the last four months we have been like whether it's Kai or whether it's Pete or whether it's somebody else they have always been helpful and you know helping us overcome the roadblocks here and there so that is a challenge I would say and the more and more contributors join the community the easier it

gets. >> Question from anyone on the audience. >> So Carlton Prius, thank you so much for the great presentation. Thank you. Thank