Eclipse CANought Is Bridging the CAN Bus and Telematics Gap

The Controller Area Network (CAN bus) has been a key component of in-vehicle hardware for the better part of two decades, enabling different electronic control units (ECUs) within the vehicle to communicate with one another. 

While this has remained a constant, vehicle architectures have evolved and software is playing  an increasingly important role. As such, there are now numerous telematics applications that enable features such as edge analytics for prognostics and ECU software updates.

However, there is no standard/secure Application Programming Interface (API) for these telematics applications to access in-vehicle ECUs. This was an issue we ran into at Cummins starting back in 2012 when we first started working with aftermarket Telematics Service Providers to create connectivity services for our engines. We needed a way to get data from our engines to the cloud, but each telematics integration required fully custom software. We ended up partnering with 35 different providers, which resulted in 35 independent development efforts, and no reusable software. This was neither scalable nor sustainable, which is why we decided to launch the Eclipse CANought project. 

CANought Provides an Open Standard for CAN Communications

The project started as proprietary software used internally at Cummins. We developed it with the intent of it becoming open source, but we needed to make sure we had something production-ready, and we did that by launching it to series production earlier this year. That launch was also the first step towards creating the open source project to get the ball rolling for broader industry adoption. 

The CANought architecture has three fundamental subcomponents: the CAN Client, the CAN Translator Server, and the CAN Access Manager (Figure 1). 

Figure 1: Eclipse CANought architecture 

The interoperability between these three components is key to understanding how CANought can provide value in this space. 

Architecture Structure Streamlines CAN Access and Security 

The first thing to understand is that in a typical CAN architecture, once an application has access to CAN, it has access to every ECU, and can use every CAN protocol. There’s no method within CAN for restricting these because every component is fully trusted. But that is both inefficient (because each application must have its own protocol library) and potentially risky (if any specific applications don’t behave as expected). In a typical commercial vehicle, there are telematics applications from different vendors, with each only being responsible for a specific component or ECU on the vehicle. There is the potential for one of these applications to not behave as expected, by using too much CAN bandwidth, by using the wrong communications protocols, or by communicating with the wrong ECUs. 

The Translator Server, CAN Client, and Access Manager work together to tackle these problems. Rather than having the protocols be embedded withing each application, which makes very inefficient use of limited computing power, they instead live in the CAN Translator Server. The server gates access to the main CAN interface, ensuring only the applications that need a particular protocol can access it. Because of where the server sits in the architecture, the main CAN interface to the vehicle can be changed without impeding the function of the CAN clients: the server sits in-between them and takes care of translating the clients’ request to match the device’s specific CAN configuration.  

CAN access and security is perhaps the most critical aspect of CANought. Normally, CAN bus access would allow any telematics application to access any ECU. But the CAN Access Manager gates, audits, and observes that access to ensure that each application can access only the pre-approved ECU(s). 

The net effect of this is a lightweight mechanism for facilitating CAN bus and ECU communication. It creates an interoperable environment where different protocols and components from different vendors can all interact in a seamless and secure manner. 

It’s also worth noting that CANought is written in C++, and it mainly uses Docker for containerisation and an MQTT broker to communicate with and between CAN clients and the CAN server. While C++ has historically been recommended for embedded software development     , Rust is seeing some significant adoption, so we may integrate that in the future as well. 

Project in Incubation But Work Is Ongoing

The CANought project is currently in incubation at the Eclipse Foundation, and work is ongoing to complete development of the core architecture. 

For the first two components of CANought, namely the CAN Client and CAN Translator Server, work is proceeding apace, and the plan is to release a 1.0 functional version in the near future. This is because we already have a production version at Cummins. 

Work on the CAN Translator Server, meanwhile, is focused on creating an open source version that has the ability to agnostically integrate with different CAN protocol libraries. Because the server must use copyrighted libraries such as SAE J1939 that cannot be open sourced, we’re figuring how to build the server so these libraries can be incorporated in a modular way.   

Technology Interoperable With Other Eclipse Projects

One of the exciting things about CANought is that it’s being built to interoperate with other Eclipse projects to make it even more useful and easy to adopt. 

One notable example is the Eclipse Kanto project, which is an IoT framework for running applications. It essentially provides the other piece of the puzzle for the problem we’re trying to solve, because it really has two parts. One part is the standardisation of CAN interfaces for running applications in-vehicle, which is what CANought is tackling. But the other is the need for portable applications that can run across any piece of hardware, which Kanto handles. It’s worth noting that CANought and Kanto have no dependency on one another, and either can be used with other frameworks or architectures. But they really highlight how open source projects can effectively stack on one another to provide broad industry solutions.      

Another example is the uProtocol project. Rather than trying to develop for MQTT and Eclipse Zenoh and all the other potential transports enterprises may use, we’re looking to abstract that away. The uProtocol communication protocol is fully agnostic to deployment, OS, and device, and maps its APIs to existing software frameworks. So, the idea is that uProtocol can sit between CANought and the transport layer and essentially future-proof our communications without requiring us to build specific supports for each different transport that exists now or may exist in the future. 

Maturing the Open Source SDV Ecosystem Alongside the Industry

Much has already been written about how the growing role of software has changed the automotive industry. What’s interesting to note is that as the software development environment has matured, there’s been this growing need to bring the two divides of the actual CAN buses themselves, and the higher level technologies that have been built on top of them. 

The open source ecosystem itself is paralleling this maturation. When the Eclipse SDV Working Group was founded about 2 years ago, it was in many ways a kind of collection of many different Lego bricks, but it wasn’t clear how they were supposed to interconnect. The big gap for us was that all our powertrains use legacy ECUs that connect via CAN bus. All other software projects, as interesting and useful as they may be, are useless to us if we can’t bridge that gap. 

Vehicles today are extremely configurable. Tier 1 suppliers must work together with OEMs to make sure everything works. And for the SDV world, we must make sure our software has that same level of modularity and interoperability. Modularity and interoperability are the focus of the CANought project, especially with the UN R155 and R156 regulatory frameworks coming into play, which regulate cybersecurity and software updates. The hope is that CANought will be able to standardise and secure CAN access for software orchestration, both during regular operations and for updates. 

Once the project is out of incubation it’ll be open to more input from the community, which we encourage. In the meantime, we are asking anyone who is interested in the project to take a look at the API specification for the CAN Translator Server and give us feedback on there and any suggestions on capabilities that would be helpful to you. It works well for our use cases, of course, but we want to make sure it also works well for everyone’s use cases. 

Our general target is for the CAN Client and CAN Translator Server to be production-ready by mid-2025. The CAN Manager, however, is completely new code, and we are not yet to an alpha-level release at this point. But the other two components will be functional without it.