CAN is a hugely successful fieldbus protocol that’s been around for more than three decades. It’s used today in hundreds of millions of devices including cars, trucks, buses, construction machines, ships, tractors, and spacecraft (there is even a CAN bus orbiting Mars). It has superb features that make it ideal for an embedded system, features that other protocols struggle to match, such as highly robust error handling, atomic broadcast, and short bounded latencies, properties that have supported design-for-correctness approaches.

But CAN needs to meet three new challenges:

• It needs to go faster (today it is so successful that higher bandwidth is obtained by partitioning the system into parallel buses, which is less than ideal)
• It needs to be secure (CAN was designed long before the Internet-of-Things and the idea of connecting a car to the internet was almost inconceivable)
• And most importantly, CAN must be faster and secure while remaining compatible with all existing CAN hardware

CAN-HG addressed these challenges with inspiration from the movie industry..

Complete CAN compatibility

The picture below is of a film ‘cel’ (it’s a 1997 digital re-release of the Star Wars movie Return Of The Jedi).

Studios needed to add digital surround sound to movie film but in a way that the movie would still be showable on all existing film projectors. The image shows the way it was done: adding 2D bar codes between the film sprocket holes so that old projectors ignore the data and new projectors extract the digital sound data.

CAN-HG does the same thing for CAN: it exploits a feature of the CAN protocol to add new high-speed data after a sample point and before the next one. This data is invisible to existing hardware but cCAN-HG hardware can see it.

CAN-HG is also compatible with the existing CAN physical layer: it uses existing CAN transceivers and cabling by automatically re-calibrating at the start of each augmented CAN frame.

More bandwidth over CAN

The invisible data bits added by CAN-HG are at speed of 10Mbit/s. Full CAN-HG augmentation in a ‘carrier frame’ (a standard CAN frame with an 8-byte payload of all zeroes) carries 104 payload bytes (for a CAN speed of 500Kbit/s, twice as much if CAN is at 250Kbit/s):

The image above shows a logic analyzer trace of a CAN frame augmented by CAN-HG. The top signal line is the unaugmented classic CAN frame (an 8-byte carrier frame). The CAN-HG augmentation starts after CAN arbitration is finished, and the protocol decoder shows how the fast bits encode CAN-HG fields:

• 32-bit Header (includes an 8-bit hardware source address)
• 32-bit Timestamp for the transmitter’s clock at start-of-frame
• 32-bit Control field
• 26 x 32-bit Payload words (104 bytes)
• 32-bit CRC

The CAN-HG data has two CRCs, both with a Hamming Distance of 6, and the CAN-HG data is carried inside a classic CAN frame, ensuring CAN-HG is highly robust.

CAN security

CAN-HG provides extra security features in hardware through its header: it is small enough that all CAN frames can be augmented with a CAN-HG header. The Canis Labs Mercury™ CAN-HG security chip sits between the CAN transceiver and the CAN controller does this. The chip on the left is a CAN transceiver, the tiny chip on the right is a Mercury™ chip containing Canis Labs hardware IP:

The CAN-HG header tags a frame with details of where it came from. An Intrusion Detection Prevention System (IDPS) uses this to instantly spot a spoofed frame. The IDPS raises a CAN error to stop the spoof, then broadcasts a short command (in the same format as a CANOpen NMT command) to instruct CAN-HG hardware to disconnect the attacker from CAN.