Peter LeVasseur Shares His Insights on the Future of Automotive Software and Fostering Adoption of Open Source Projects
We had the pleasure of speaking with Peter (Pete) LeVasseur, an experienced professional in the automotive and embedded systems space. With over a decade of experience in automated driving, ADAS, and systems software, Pete brings valuable insights into the evolving landscape of automotive software. As a committer to the Eclipse uProtocol project and a leader in the Rust Safety-Critical Consortium, Pete is deeply involved in advancing safe and reliable software solutions for the automotive industry. In this interview, we’ll delve into his views on key developments in automotive software, the role of Rust as a programming language in the automotive sector, effective ways to onboard new contributors, and fostering collaboration between open source projects.
You’ve worked in the embedded and automotive space for over a decade. Generally speaking, what is the most significant development in automotive software you have observed during that time?
Peter: I’ve seen two trends which seem opposed, but aren’t: in-sourcing of software and more openness and collaboration. Generally speaking, I’ve seen legacy automotive OEMs move toward wanting to be more in control of their software stack and less wanting to just buy “boxes” which they plug into their vehicle network. This shake-up is due to new OEMs like Tesla and Rivian that are in full control, so are able to release software fixes and updates with a turn-around time measured in hours and days, not weeks and months.
On the other hand, there’s an increased willingness to participate in foundations, consortiums and both contribute to and use open source software. The idea of being in control of software can take many forms. It can mean taking an open source package, developing software with it, contributing, or even forking internally to meet some needs.
You are a committer to Eclipse uProtocol. What has been your area of focus within the project?
Peter: We took an approach in Eclipse uProtocol of leveraging Rust for those critical, infrastructural services which must not fail. I focus on this segment of the project, developing the protocol-bridging library uStreamer and the SOME/IP Transport in Rust. I am also one of the reviewers of our Zenoh Transport Rust implementation contributed by ZettaScale Technology.
Rust strikes a nice balance between safety, practicality, and general purpose usability that has earned it a spot as a viable candidate for use in embedded.
To Rust aficionados, this might be obvious, but not being a Rust programmer, I need to ask this naive question: What makes Rust such a good choice for embedded technologies compared to C/C++, leading to many projects being rewritten in Rust?
Peter: Rust strikes a nice balance between safety, practicality, and general purpose usability that has earned it a spot as a viable candidate for use in embedded. There’s a fairly well-known article by Microsoft which shows that roughly 70% of CVEs are due to memory corruption bugs. Those sorts of memory safety issues are not possible using safe Rust, as the compiler performs static analysis using the concepts of ownership and borrowing.
Practically speaking, though, if we’re working in embedded there’s a fair chance that we will need to interoperate with an existing C or C++ library or need even lower level access to registers and memory. The unsafe keyword in Rust lets us do those things, so long as we as engineers have upheld the same sorts of memory safety guarantees that the compiler would normally check for. It’s typical to then write a safe layer above any unsafe usage so that we can go back to the rest of our software having that correctness enforced.
Rust is also a very useful general purpose language for other domains such as backend web development and writing systems software. This cross-domain appeal leads to a larger base of folks that may have used Rust in another domain which are able to take a lot of their knowledge and experience with them when they cross over into the embedded domain. Another great language for safety-critical and embedded applications, Ada, suffers a bit here due to its niche application and less broad appeal.
Finally, I think it helps to have perspective. JF Bastien of Woven by Toyota, who’s an active contributor to the C++ standard, helped sober us up at the kickoff meeting of the Rust Safety-Critical Consortium (paraphrased): “Honestly, I don't care about Rust in and of itself. I want the ability in automotive to use the best tool for the job. Rust looks like it might be that tool. We have some work to do here to improve things for its use in the safety-critical domain.”
You recently blogged about writing a Zenoh plugin for the uProtocol uStreamer, and it seems that working with the project and its team has been a very positive experience for you, as you wrote: “The documentation is excellent, the code is very clean and easy to understand, and it’s open source, so it’s extensible and forkable.” Would you say that good documentation, clean code, forkability, and extensibility are the main factors driving the adoption of open-source projects, or are there additional elements that project teams should consider to encourage more adoption?
The Rust community has succeeded in large part due to its active community building efforts and feels very welcoming.
Peter: Right! So Eclipse Zenoh actually just hit its 1.0.0. I saw Zenoh (the dragon in their comics) get a birthday cake and everything.
I think those are all very important to help folks get up to speed and use an open source project quickly. I’d add a few more: community, marketing, and adoption.
Rust is an open source project that has great success in community building. I spoke with Florian Gilcher of Ferrous Systems this weekend about why the Rust project was successful. He was a part of the community team in the Rust project for some time and helped mentor them. It really helps to have a welcoming and engaging community in multiple places to help meet folks where they are at and provide support. The Rust community has succeeded in large part due to its active community building efforts and feels very welcoming.
I felt the impact of marketing first hand in Eclipse uProtocol’s efforts to have greater appeal and adoption by automotive OEMs. After GM went through a restructuring and most who worked on Eclipse uProtocol lost their jobs, this was a large blow to the speed at which we could deliver new features. I began a group on LinkedIn for Eclipse uProtocol and began posting regularly about both my individual activities and those that involved the project. We’ve since seen an uptick in the attendance to our meeting and had people reach out who are interested in contributing to the project.
Adoption is also an important factor both for longevity of the project and for securing funding. GM’s future use of Eclipse uProtocol being unclear, we’ve gone into a mode of trying to market it as a real solution automotive OEMs face. I attended GOSIM in Beijing last week to give a talk about Eclipse uProtocol’s usefulness as a service mesh to connect applications across. Steven Hartley, Kai Huddala, and Daniel Krippner will be giving talks about Eclipse uProtocol at OCX this week as well [editor’s note: OCX took place October 22-24, 2024]. We need to see adoption by an automotive OEM so that funding and contributions continue on strong.
Open source software has it in the name: open. It’s a great signal to both other open source projects and industry that a project is able to collaborate effectively.
Eclipse uProtocol has benefitted greatly from collaboration among several major companies. In your opinion, how important is collaboration not only among key players in the automotive industry but also with open-source projects like Eclipse Zenoh and Eclipse uProtocol?
Peter: Open source software has it in the name: open. It’s a great signal to both other open source projects and industry that a project is able to collaborate effectively.
I think both Zenoh and uProtocol benefitted from this collaboration. Eclipse uProtocol benefits from the deep knowledge of protocols held by the many folks working on Eclipse Zenoh which helps guide decisions during development. Eclipse Zenoh benefitted from some help in prioritising their deliverables ahead of their 1.0.0 release for what Eclipse uProtocol needed. The marketing aspect certainly helped both as well, as when I see an interesting Zenoh post on social media I’m more likely to comment or repost with my thoughts of working together.
Pete LeVasseur has worked in the automotive industry for over a decade, working in automated driving and ADAS as well as in systems software and middleware. He has seen the challenges with writing safe software for a safety-critical domain and hopes to improve this story. Pete is chair of the Coding Guidelines Subcommittee of the Rust Safety-Critical Consortium. He is a member of the Eclipse Software Defined Vehicle Work Group and Rust Special Interest Group. Pete is a maintainer of the Eclipse SDV project Eclipse uProtocol, centered around the goal of an open source framework for in-vehicle communications down to mechatronics devices and out to the cloud and mobile devices.
