Can Injection: keyless car theft

Re:Can Injection: keyless car theft by the__alchemist on Wednesday April 05, 2023 @01:45PM (#35457850)

I appreciate the detailed insight! Great point on something subtle re individual bulbs that is non-ideal. I'm learning CAN now, mainly for use in drones. I have got 2 STM32 FDCAN periphs talking to each other; the basics seem easy, but the protocols that go on top of it seem complicated! I suppose this is due to managing a decentralized network. Ie, at first CAN seemed like to offer a bus that simplifies wiring and offers resistance to noise, but the more subtle and interesting point seems to be a common API where hardware access is handled by individual nodes, and communication is through this API layer on top of the hardware. Ie, if you control the whole network, it can seem like the first case, but the interesting things happen, eg as you describe, arise when the nodes are by different manufacturers and are swappable.

Ie, with CAN, each node only needs to do reg reads/writes/datasheet-spelunking for a narrow part; the other nodes just need to know the API that sits on top of the hardware.

[ Parent | on HN ]

Re:Can Injection: keyless car theft by jeffreygoesto on Wednesday April 05, 2023 @05:10PM (#35460428)

You are talking about dbc files, defining the binary layout per message on the bus? That is typically in the hands of the OEMs, not ECU vendors.

See for example https://github.com/commaai/opendbc

Quite old and for Wundows, but a lot of code showing how to use a lot of CAN interface boxes is at https://github.com/rbei-etas/busmaster/tree/master/Sources/B...

[ Parent | on HN ]

Re:Can Injection: keyless car theft by sgtnoodle on Thursday April 06, 2023 @04:04AM (#35465617)

CAN only really works out well in a complex system if you have full control over the addressing scheme. Addressing and prioritization are one in the same. Unintuitively, prioritization isn't about the importance of a message so much as it is about the message's urgency. A pretty common approach is to use "rate monotonic" prioritization. The basic idea is that higher rate messages have higher priority (lower address) than lower rate messages.

There's rules of thumb about never overloading a CAN bus beyond, say, 50% utilization. That's because systems with poor prioritization management tend to start falling over around there. With a well thought out scheme, it's possible to push a CAN bus fairly close to 100% utilization. I built several safety critical systems that pushed 80% utilization on average. At that level, you really need to rely on redundancy rather than simple robustness, though. A CAN bus running at 80% falls over very hard when you have a flaky physical connection somewhere.

[ Parent | on HN ]