After being founded just a year ago, the Software Defined Vehicle (SDV) Working Group is on the cusp of releasing its first two "blueprints," a versioned set of artifacts, packages, or images from participating SDV projects. Excitingly, these should be coming out just as the projects they’re based on are coming out of incubation. So, we’ll see the first projects to come out of the group released alongside examples of their use.
We first tried out the ideas behind these blueprints at the hackathon in Berlin in November, to great success. Now we’re looking to package together the outputs from that hackathon into our blueprints.
Truck Fleet Management
The truck fleet management blueprint is focused on capitalizing on all the data that a fleet of trucks generates. Fleet managers want to be able to capture and make use of where vehicles are, how fast they’re going, and other details. There are also a variety of apps and services running on a fleet of vehicles that must be tracked and managed.
Several projects in the SDV Working Group are well suited to address these needs:
- Eclipse Chariott performs the middleware role and acts as a common registry for the other applications and in-vehicle services that want to talk to each other
- Eclipse Kuksa provides simple APIs to adapt various vehicle interfaces into a common interface that provides a basis for adding techstacks to the vehicle architecture
- Eclipse Leda is purpose-built to provide functional integration of other SDV projects by enabling a Linux-based image/distribution by using system image “recipes”
- Eclipse Velocitas provides the toolchain to build in-vehicle applications that uses the vehicle data for remote management and observation
Fleet management software isn’t new. But the idea here is that rather than a company having to spend hundreds of thousands of dollars on mission-critical software that it can’t see the guts of, it can get a plug-and-play, fully open solution. Users can see all the moving parts and can participate in the future development of the software to ensure it meets their future needs as well.
Autonomous Racers
ROS is widely used in autonomous vehicle development and research, including full-scale autonomous race cars that can reach speeds of up to 300 km/h in the Indy Autonomous Challenge. To teach students how to build autonomous vehicle systems, F1Tenth.org has developed 1/10 scale versions of these cars, which serve as educational material for university and K-12 courses on robotics and self-driving vehicles, as well as the fundamentals of autonomous systems and ROS.
The application of Eclipse SDV blueprints to orchestrate and manage the F1Tenth stacks that power the miniature vehicles racing around a track is another interesting use case for an Eclipse SDV blueprint. As in other software distributions, Eclipse Chariott and Leda perform similar functions. Additionally, Eclipse Muto is a compelling choice for orchestrating ROS software as it provides a robust framework and runtime platform for model-driven ROS software stacks, enabling users to actively monitor and manipulate the ROS graph. This functionality mirrors the approach taken by the fleet management blueprint, demonstrating the versatility and adaptability of Eclipse SDV blueprints.
We’re also looking at potentially integrating functionality from Eclipse Kuksa and Eclipse Velocitas, but for the moment that’s a work in progress. The blueprint also incorporates Eclipse Muto, a natural choice for an ROS framework, as it provides a framework and runtime platform for model-driven ROS software stacks. It also allows users to monitor and manipulate an ROS graph even while it’s actively running.
And, similar to the fleet management blueprint, the idea is that end users get something they can download and use right away.
Take Them, Use Them, Come Back With Changes
Obviously, one of the key points of working in open source is that progress is iterative and there’s rarely, if ever, only one, pre-defined standard. Naturally, with these blueprints, the goal isn’t to define how everyone will tackle these problems, but to get something usable out there, see how people make use of it, and to get feedback on it.
For the automotive industry, which has historically only collaborated in closed-source, proprietary environments, this is an exciting step forward. To encourage more collaboration, however industry players want to engage with it, we’ll be creating a separate collaboration space for these blueprints. So, if you’re using one, you’ll have an easy way to engage with the project and see how others are using it or share how you’ve found it useful.
You can check the SDV blueprint space to have a look for yourself.