Autonomous truck designers rethink their CAN interface needs

Environmentally and from a health and safety perspective, long haul trucking has an arms-length list of disadvantages, and yet it represents the way that over 75% of total inland freight in Europe is moved. Radical change is coming though. Leading the change are a mix of industry incumbents and start-ups that are reinventing truck architectures, charging infrastructure and freight management platforms. Unsurprisingly, they are replacing the diesel engine with full or partial electrification. More surprising is the driver’s transformation into ‘operator’, controlling the truck remotely, or indeed, some manufacturer’s progress to full autonomy. Enabling these changes are a combination of fundamentally new technologies and familiar ones, including CAN. 

Speaking to a member of the platform team for one, not-to-be-named autonomous and electric truck manufacturer, it’s clear that the fundamental electrical architecture remains very similar to traditional trucks, albeit with more network buses and a lot more data. ‘Under the hood’ has evolved into a more distributed electrical layout for all electric vehicles, but with an average of six CAN networks on the truck, primarily for chassis control (or the ‘skateboard’ as it is increasingly referred to), plus eight Ethernet-only networks, the changes stop there. There is an advantage in keeping it simple, the engineer explains, and CAN’s reliability, ubiquity, electrical robustness and resistance to EMI, means that it remains the obvious choice for many key vehicle systems.

When building from the outset for no driver, a safety culture is paramount. As a result, one question that this autonomous truck manufacturer posed was how to collect CAN data while categorically not affecting the vehicle control systems, or increasing the risk of a security breach? A positive feature of CAN is that it can be configured quickly and easily using a standard CAN interface, which can both transmit and receive CAN messages. However, in certain situations, CAN interfaces should be used in silent mode to ‘listen only’ (or receive only). The Kvaser USBcan range provides software-controlled silent mode, but the manufacturer in question chose the new Kvaser USBcan Pro 4xCAN Silent, which implements silent-mode through hardware and thus, cannot transmit on bus. The device is mounted within the main computer housing of all prototype vehicles and logs CAN data continuously. 

The hyper-complexity of the myriad sensors, software and data on which autonomous vehicles rely is often cited. What is often less considered, for start-ups at least, is their unique opportunity to reduce complexity by analysing what they need and what they do not. In relation to CAN data collection, this translates to a requirement for simpler listen-only interfaces that cannot be used by a potential attacker to affect the safety-critical CAN busses from the logging application, but also to more standard requirements, such as Linux support and backwards compatibility. For the resource constrained, backwards compatibility ensures that simple migration to other CAN hardware is assured in the long-term. 

For the autonomous and electric heavy-duty sector, the end-goal is a revolution in the way that goods and people are moved. As part of this, rethinking how CAN tools are used within the development process is an extremely worthwhile endeavour.