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.
> 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.
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.
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.
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...
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.
In the factory, you fit the bulbs in a certain order every time, and the computer knows that order.
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…”
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.
That sounds like a good thing to me.
(I'm not sure though - it might be some headlight controller fails non incandescent bulbs)
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.