There's a lot of approaches for various subsystems. The cameras that you mention are quite-likely some kind of serialized MIPI (e.g., using some generation of F

There's a lot of approaches for various subsystems. The cameras that you mention are quite-likely some kind of serialized MIPI (e.g., using some generation of FPDlink or GMSL to tunnel asymmetrical bidirectional data across a micro-coax cable). An SOC somewhere (often the same one driving the display) will receive the deserialized MIPI streams and do whatever video processing is desired and display the output stream. The display is typically eDP or sometimes HDMI. Old-school hardware that doesn't have large bandwidth requirements will usually use CAN, a multi-drop bus that is capable of up to 1000 kbps but is typically used at 125, 250, or 500 kbps. Its advantage is simple UTP cabling. Its disadvantage is that it's a planned bus - you need to have termination resistors in known locations and you have to plan the addresses of devices in advance. It's kind of brittle and the tiny packet size means folks jump through hoops to send larger blobs of data. This is probably one of the great barriers to being able to buy some random car part from a manufacturer as Joe Q Public and use it. The OEM is used to making lightly-customized firmware for every customer. A typical car is a mix of hub-and-spoke topology and a daisy chain. There will be a handful of CAN buses that go to various devices around the car. You might have a CAN-connected cabin controller that has a bunch of motor control chips for seat adjustments and seat heaters or window heaters and which daisy chains with door controllers and mirror controllers on the cabin bus. There might be another daisy chain in the engine compartment; one device might control the HVAC system and another controls the engine. Usually the hub is some higher-performance device or at minimum a gateway that taps each of the various low-speed buses and is used to provide a firmware flashing and diagnostic gateway. That's increasingly frequently the same computer that runs the infotainment system. So let's say you're at the end of the factory line, you can plug in a thumb drive via USB or drop an Ethernet connection to the car and rapidly upload all the firmware blobs to the infotainment computer and it'll run a program that passes all of them along to the various widgets. 10Base-T1{S,L} might start to displace CAN in some of these widgets so long as MCUs and PHYs are very cheap. 100Base-T1 has already seen some adoption in things like backup cameras that use chips that also implement video compression and streaming. I believe BMW and Mercedes started using standard Ethernet for their diagnostic gateway and then bridged to 100Base-T1 internally between their higher-bandwidth widgets since ~2007. Personally, I'd love it if everything ended up on faster IP networks and no longer needed custom firmware on a per-implementation basis. As of a few months ago, I am no longer in the automotive business.