Just wanted to add many comments on Can and obdII:
In the United States the obdII port is required beginning in model year 1996. The obdII port and the CAN is analogous to rj45 and cat5, 5e, 6, etc.
Should note, the can bus is anything but bog standard.
However, in 2008 the United States required that all vehicles provide an iso15765 interface as the basis of the on board diagnostics. Iirc, 15765 is a subset of Can that's for cars and not forklifts. Can is controller area network.
There are a large variety of protocols talked across Can, far too many to list as you have noted. There are schemes which are serial, parralel addressed and not, and even analog signaling cohabitating this generic breakout port.
Where it differs between cars is the capabilities of the DLC, if the vehicles isn't equipped with a sensor suite, there will be no correspondent ecu subsystem to query, but for the most part you can send control messages to anything you want on a DoT approved vehicle, unless it is locked away behind a specific gateway and the car manufacturer is still hiding the method to control access to the device.
None of this applies to infotainment devices or comfort features.
Consumers should rue the day we return to the age of mystery subsystems requiring special protocols.
The reason I say this (and I suspect but, can't remember the 2008 iso 15765 mandate rationale) is that you probably want your mechanic to be able to fix your car, right?
Anybody who might be interested in the wild and fun world of automotive Com protocols such as this I can recommend to you this good and recent resource from 2020: https://www.csselectronics.com/screen/page/simple-intro-to-c...
Looked at it like a fixed phy layer with some parts of the messaging fixed as well, although now that you brought it up, I remember adding J1939 support too.
Ugh, it was, in my opinion, a bit-hacked mess :) I can really appreciate when things that despite being messy and hackish, solve real, actual problems, and for that, I thank thee, CAN-bus :).
Of course a hardware air-gap is inconvenient when you are trying to ship subpar hardware and software on a shoestring budget, so the industry invented smart CAN "switches" and it's possible to escalate the access the diagnostic port provides, or tunnel from the infotainment network to the safety one. In newer cars, you can also possibly substitute CAN in this post with Ethernet.
It is not, however, required that said CAN bus is used for anything other than for passing emission tests. Easiest way to implement that feature is by exposing main CAN bus on that port, but you don’t have to.
I don't think the port is the surprising part, it's the ability to articulate brakes and steering wheel!
To be clear, I don't have a car or a driver's licence, I was just surprised that this standardization was a thing at all. Seems like a stark contrast to all the walled gardens in every other technology-related industry these days.
TL;DR: Apart from really basic data and physical connector, everything else is (ever more increasing) walled garden. With new VWs and Fiats requiring online connection for even most basic operations - so even if you know the protocol, you have to unlock it online (See VW SFD and Fiat SGW)
I think the obd connector on tesla doesn't do anything
It's common to extract diagnostics about the car from this port. For example, when buying a used car this is highly recommended. Buy a cheap adapter that you plug in, connect to it over BT from a phone, and read out error codes. Perhaps the owner has temporarily put out an error to mask it during your inspection?