It is not surprising that the general public is unaware of the user invisible computers running their vehicles. It is a testament to the skill of the automotive engineering community that computer controls were adopted with the care and testing which enabled them to remain hidden in the background. On Board Diagnostics were included within these controls due to the magnanimous donation of thousands of hours to industry committees who hammered out the standards. Access to the “big data” is just the starting point. Many iterations of testing and development are needed to weed out the “false positive” alarms that shake our confidence in the “code”. We evolved from OBD 1 through OBD 1.5 to the OBD II standard that came into effect in 1996. The upgrade to the standardization of OBD II was the result of emission requirements but the industry implementation included useful features such as common connection hardware, standardized diagnostic trouble codes, and access to the computers.
Vehicle computer controls are very sophisticated these days. Artificial intelligence in the form of mapping is used to keep up with the vehicle processes in real time and adjust the response to accomplish better outcomes like lower emissions, better fuel economy, traction control, straight line stopping and smoother ride.

New values are continuously stored in a digital map which is used to avoid computing from scratch when the same conditions occur in the future.
The embedded On Board Diagnostics are able to spot failures which are above even my talent and vision. More important than that is that they continuously track simple failures
like disconnected wires. My college roomate electrical engineer, stated that there are no electrical failures. There are only mechanical failures. Electricity will flow if you give it a path. On Board Diagnostics is like having a mechanic who rides with you every mile of the way watching for even the simple failures. Nothing is more frustrating than having an intermittent problem that clears up every time you schedule an appointment with the mechanic.
As an automotive engineer and trained auto mechanic, I championed the display of the diagnostic trouble codes in addition to the “idiot light” on the dash panel. Now that I have seen this IoT application evolve, I realize that simply displaying the diagnostic trouble code number (some cars use the odometer display to do this currently) is of marginal usefulness compared to simultaneously providing the technical data and links like YouTube instructional video related to the indicated code. Applications such as my www.mileagetrakker.com grow in the marketplace because most car users also need lots of actionable related information, like the nearby location of appropriate repair shops.
The IoT has emerged into the marketplace in true “overnight success” fashion. Volkswagen brought out the first on board computer with scanning capability in 1968. The car repair industry was disrupted and gas stations with repair bays were replaced by convenience stores. In the 1940’s and 50’s tape driven digital servo motor controls were added to drive the motions of milling machines. CNC machining centers (and their intranet linked CAD and cutter path generation and management software) now dominate, displacing most Bridgeport milling machines. (And the Bridgeport company itself) In 1968 Bedford Associates brought out the first PLC (now Modicon) for GM. As a result, historic relay industrial controls have been replaced by PLC computer systems with their embedded intranet links.

Will we ever see the first disruptive Internet of Things success? Now that I have seen the security agencies complain that encryption is blocking interception of ISIS phone conversations, my prediction is that it will arrive as an extension of the Intranet of Things. Most IoT applications, like home security, require that any intranet extension onto the web includes the emerging communication encryption.