And yet the obvious thing is for someone to be making and selling a "can bulb" - a tiny 4 pin bulb with 12V, GND, CAN-H/L pins. And all bulbs (led or not) on a car would be that. It would turn on/off commanded by the canbus and report status info back.
Yet car manufacturers don't do this. CAN transceivers are still too expensive to build into every bulb. Instead, a single CAN transceiver and microcontroller will control a whole set of nearby bulbs (eg. brake, indicator, reversing lights). That then makes it vehicle specific, so you don't get the economies of scale of just making a single model of can-bulb which fits lots of places in many cars from many manufacturers.
> And yet the obvious thing is for someone to be making and selling a "can bulb" - a tiny 4 pin bulb with 12V, GND, CAN-H/L pins.
No, that's not obvious at all.
Separating the control board and the bulb is obvious. You wouldn't want to replace your entire control circuit every time you need to replace a bulb, would you? You don't want to have to reprogram your ECU to know which bulb serial number corresponds to your front headlight because all of your bulbs are the same.
Moreover, this is impossible because there isn't a single bulb model that goes into a car. High beams, low beams, blinkers, and interior lights are all different. They also differ from model to model depending on the requirements.
> That then makes it vehicle specific, so you don't get the economies of scale of just making a single model of can-bulb which fits lots of places in many cars from many manufacturers.
Car companies make millions or tens of millions of cars per year.
When you're making 10s of millions of something every year (or 2X that for parts that come in pairs, like headlights), you already have economies of scale.
Automotive equipment manufacturers will also share components between car companies, and further upstream you have companies that make chips for auto makers who share chips across the companies.
Automotive manufacturing is a great example of economies of scale. It's not correct to say that auto manufacturers aren't leveraging economies of scale while producing 10s of millions of common parts per year.
Plenty of vehicles only have production runs of ~10,000. At those scales, you really don't get economies of scale. In fact, there were only 25 car models that sold more than 100,000 units in 2021.
Plenty of particular brands of vehicles have smaller production runs. But "vehicle" to the manufacturer doesn't mean "brand". It means "set of pieces and parts that can be the same or nearly so across many brands". For example, a "Cadillac" to you is a different "vehicle" from a "Chevrolet"; but to GM, the vast majority of the pieces and parts and manufacturing processes are shared. So the economy of scale to GM when building "Cadillacs" is huge even if to you it looks like "Cadillac" has a small production run.
Exactly, and this is one of the reasons modules need programming, because it comes “virgin” with only a bootloader and the features are loaded according to the VIN.
I’m guessing you’ve never worked in customer support. The failure modes of mistakes would be nasty. Even smart people swap bulbs around when diagnosing faults.
Simplicity (good usability) is most always crushingly hard to achieve, doubly so for hardware.
Calling things “simple” is often a sign of shallow thinking in my experience - something a customer or manager might naively say but an engineer cannot (because they have to deal with all of the real requirements).
For example, the engineers that build cars can’t say “you simply push a button to start a car” - as an engineer the complexity behind that simple operation is very very deep.
> For the customer-replacement case, you simply tell the customer to replace just one bulb at a time
Just imagining the customer support for this is gonna give me nightmares.
“Sir, you need to make sure your vehicle’s ignition is turned to accessory mode. Then wait for the light to blink twice, that’s the vehicle’s confirmation that it correctly identified the new light. If it blinks three times, it can’t confirm the light’s location, so you should try removing it and re-inserting it. If it blinks four times, that means you didn’t replace the bulbs in the correct order so you need to initiate a manual reset procedure by going to the driver’s seat and…”
CAN frames only have space for 8 bytes of payload, unless you upgrade to CAN-FD at a significant complexity cost. For the sake of a light bulb, you could make it work by being sufficiently clever. You could even use all 8 bytes for serial number, and then use existence of the message itself to turn on the bulb. Have it turn off after 100ms of timeout.
It's really not a sustainable approach to try to address nodes on a CAN bus by serial number, though. CAN is content addressed rather than receiver addressed. Due to the way arbitration works on the bus, it's invalid for two nodes to transmit to the same CAN identifier. The arbitration mechanism breaks down and results in error frames, at which point the CAN bus is in a degraded state.
That would preclude a CAN enabled bulb from being able to send telemetry back, at least until the bulb was provisioned an identifier. That could be done by an ECU sending a frame with the bulb's serial number and assigned identifier. You still need a zero-conf discovery protocol, though, and so you're back to transmitting before provisioning. You could work around all that, but it's a lot of work.
Stepping back a bit, running a car's CAN bus over a light bulb socket is going to cause some practical reliability problems. Compared to a wire harness going into an ECU, a user serviceable bulb socket is going to be much more prone to intermittent connections from vibration, as well as oxidation and wear. Intermittent connections on CAN_H/CAN_L tend to cause a ton of frame errors, and significantly degrade the overall bus performance often to the point of system failure. When a node encounters enough error frames, it is compelled by the standard to go into a BUS-OFF state where it isolates itself from the bus. Because it's a bus and all the nodes share the same two wires, it's pretty much impossible to diagnose where an intermittent connection is without trial and error.
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.
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.
Yet car manufacturers don't do this. CAN transceivers are still too expensive to build into every bulb. Instead, a single CAN transceiver and microcontroller will control a whole set of nearby bulbs (eg. brake, indicator, reversing lights). That then makes it vehicle specific, so you don't get the economies of scale of just making a single model of can-bulb which fits lots of places in many cars from many manufacturers.