A look at car connectivity and its latest generally aware ecosystem shift.
Hello everyone, we’re well into the swing of 2023 at this point. As of now I’m in school as well as working with my town’s digital literacy program in order to help raise technology awareness. This is doing my part to help bridge the digital divide. This service covers the entire state and deals in not only in technology but in general media literacy as well. It’s an important service and one I’m proud to offer as I seek new opportunities to embolden the community around us I continue to champion. If you’re interested in such a program be sure to check out the website [https://digital.literacyrochester.org/].
Our community is starting to host a lot more attendance based events similar to this one. Tomorrow I’ll be headed to the local Microsoft building in order to attend an Azure conference [https://www.meetup.com/rochester-azure-users-group/events/290175467]. I hope to bring forward my decades of experience to this event as we explore IoT through the Azure’s take on OpenAI services. Having this opportunity to visit after gaining so much insight and knowledge through the Microsoft Learn platform over the past 2 years is an incredibly empowering and validating feeling. If you’re attending the event, feel free to say hello and I hope to see you there.
The topic of this month’s blog will cover a high level view of car connectivity technologies. We’ll look at some recent and interesting developments associated with underlying car technology as well as a short technical history of two key components. If you’ve never gotten a chance to explore the technologies associated with automobiles, I get where you’re coming from. Prior to this I had the notion that auto tech was strictly a trade managed area, save for the occasional highly automated aircraft or combine harvester. I was pleasantly surprised to hear the involvement companies like google are bringing to the table in the downshift on their focus towards autonomous driving.
Indeed, there is a group associated with new developments in underlying auto technology known as the Car Connectivity Consortium [https://carconnectivity.org/]. This group is more than a lobbying group, as they focus on forwarding open technology standards for automobiles. However, the motive behind the group is to push more technology into the car: Technology designed to help people interact, connect and work more efficiently. The agenda behind this to the cynic means pushing the underlying systems they make into new territory, which is exactly what google has been doing with their android auto ecosystem since 2017. More on that later.
A typical sedan has standards for feature sets, and those standards are often set by certain companies. GM, General Motors, sets standards for their automobiles in the Chrysler, Chevy and GM vehicle lines. Purpose built vehicles all contain features that are determined by the auto maker itself. From chassis to steering, engine and onboard control systems for things like diagnostics and infotainment. The latter 2 caught my interest during this research period, and I’m sure I’m not the only person so fascinated by both the readouts of cars, but how the flashiest computers on the newest spec vehicles connect to understand it all.
If you browse the app store, you might come across something known as an ODB scanner. I was surprised at how popular some of these scanners are, given they are nearly #2 on both the paid iOS app store and google play. ODB is short for OnBoard Diagnostics, and this type of communication has been around since the mid 60’s(!) on most consumer vehicles [https://ww2.arb.ca.gov/resources/documents/obd-ii-regulations-and-rulemaking]. Currently we’re working with revision 2 of the ODB standard made in the mid 90’s. These communicate with other computers through the use of a diagnostics port and a serial-esque communication port. This port displays readouts that are 1:1 what’s seen on your car’s dashboard. Internal temperature sensors, warning lights, and even car specific diagnostic codes can be output through ODB communications. Like with automakers, there are also vendor specific versions of this, but generally there’s a universally accepted standard for grabbing this information. Even with modern Electric Vehicles, ODB2 ports continue to exist and allow mechanics and if the app store is correct, most hobbyist to read information from their systems.
One area I’d like to highlight here pertains to use case. A mechanic is going to need to see areas of a vehicle in a standardized way, most likely in a different way than a phone owning car hobbyist would. Do OEM mechanics have access to specialized tools different than a regular licensed and certified mechanic shop? Do these tools have a reliability standard they need to meet? How much is too much when looking for consumer based OBD2 reading tools? And what’s up with all these $2 devices claiming to work for OBD2 readouts? To answer this, I’ve compared where people may find these typers of devices, how they display the data they capture, and what considerations might be needed. This is a generic look at a handful of ways one might capture data from an OBD2 scanner and, pun intended, your mileage may vary.
OBD2 to ethernet/serial — This is intended to plug into a computer. Computers dating decades back could support this standard with some type of software to pair with. Modern machines can also use this with the right adapters and software combination. Devices here can cost $2 to $20 not counting additional cables.
https://m.media-amazon.com/images/I/51il8BugNsL._AC_SL1130_.jpg
OBD2 to LCD handheld computer. — Often microcontroller-centric LCD computer devices are paired with these OBD scanners. These vary in appearance and functionality, most are useful for reading onboard diagnostics from a device. These are commonplace in auto specialty and hardware stores such as Harbor Freight and AutoZone. Typically low end devices cost anywhere from $20 and range up to $300.
https://m.media-amazon.com/images/I/61ZmgqNhtbL._AC_SL1200_.jpg
OBD2 to wifi/bluetooth — These devices use a wifi or bluetooth chip to connect to a phone or computer which do much of the work. The convenience of taking out a small adapter and using your phone to display information is almost too convenient, as data can update much the same way a dashboard could. Many apps and even flashier hardware in this area also mimic the look of the dashboard, meaning a user could get the idea to replace their own displays with a phone or OBD2 computer. What suffers with these devices is real time data. While the readouts are accurate, they are most likely to receive interference, delays, security issues or interruptions that render the data less than accurate. Some of the cheapest devices might not work at all due to poor manufacturing practices or a lack of communication protocols. This makes the aforementioned possibility less desirable, but still possible. The basic adapter to phone devices range from $2 to $50, and a general ‘you get what you pay for’ is the sentiment from most consumers in this space.
https://m.media-amazon.com/images/I/61qBOSxu6mL._AC_SL1500_.jpg
OBD2 to proprietary communication protocol (can be wired or wireless) — this would be an ‘other’ category for both hardware and software based communications meant to capture readouts. At one point, many auto insurers used a device that plugged into an OBD2 reader. These devices phoned home after being either shipped back or connected to another device in order to give customers an insurance policy discount [https://www.progressive.com/auto/discounts/snapshot/snapshot-faq/]. (Or in contrast show them the truth that they in fact be the worst driver in the county.)
Another example is a high end OBD2 reader like the BlueDriver. While it looks like a typical wifi/bluetooth adapter, it actually uses a proprietary protocol. It also asks for 4 times the price of these adapters. [https://m.media-amazon.com/images/I/71RQ96Zb9eL._AC_SL1500_.jpg]
It’s appropriate to mention here how this type of connection is what is often required on the horror stories you may hear about American infrastructure. As ODB2 is an open standard, one might imagine it cross compatible, unlike specific OEM communication protocols set forth by automakers. Even so, one can’t help but wonder how many of these are the result of lacking digital literacy as opposed to the often scapegoated bit-rot and technical debt [https://www.ocregister.com/2022/09/20/how-clever-mechanics-keep-50-year-old-bart-trains-running-windows-98-ebay-and-scraps/]. This blog also doesn’t even scratch the surface of things like the CAN/BUS capabilities. There are fantastic talks about these at places like DEFCON, where you’ll find a whole village of experienced individuals looking into these systems for fun and profit. (I recommend this one for that specific topic: https://youtu.be/YSApvBDIVCM)
OEM manufacturers have a vested interest in controlling this sort of standard and not letting consumers get ahead of their involvement in the market, which is why these programs are found on bug bounty platforms quite often. At the same time, they need to create a feature set more advanced than the home user could potentially make on their own with inexpensive hardware as both a brand statement and a technology many rely on as much if not more than a phone. GM as mentioned before has an interest in android auto and its competitor Apple CarPlay in order to bridge the gap between phone and auto technologies that consumers want to use. Getting real time call, map and music information is desirable for a lot of people buying new cars. The front end operating system people see when they boot their car is called the infotainment system, and I would argue that next to the current electric truck boon, this is the most exciting area to be involved with in auto technology. More specifically, the operating system used under the… dashboard.
You might be familiar with the fact that Tesla’s fleet of cars run on Linux; people have known and even celebrated this fact for years. However, most cars in the mid 2010’s run UNIX as well. QNX is the operating system powering most infotainment systems. As a real time operating system (RTOS) its role differs from typical computers found in office spaces[]. It’s specialized for running apps configured from a central make and feature set. In a very condensed and less than accurate simplification, when an auto maker installs their tailored version of QNX onto its cars, it checks a box that says that certain features can run on a hardware level and are always running when the system starts up. The system itself must get updates through the car manufacturer, and adding apps to the car isn’t possible by anyone without the ability to build a new version of the operating system from scratch. That has not stopped people from swapping out the infotainment system completely, or reverse engineering it, but for the bulk of the 2010’s QNX was the system most car infotainment systems ran on. The apps for android auto and Apple CarPlay themselves ran through QNX. This system became more integral to the automobile experience now to the point that google has partnered with several auto makers including GM to bolster its android auto ecosystem into a full on OS. Android itself has spun off into Android Automotive OS (AAOS)[https://developers.google.com/cars/design/automotive-os].
AAOS succeeds android auto and QNS. The responsibility for integrating AAOS Apps still falls to the auto maker itself. The Apple CarPlay app itself now runs through android, irony aside this is similar to how Airplay works with Samsung’s Tizen OS for its TV’s. The ecosystem being android means it’s more open in a manner that was previously restricted by QNX. Whats more, android’s deeper integration means that smartphone features can be brought into cars. Remote car keys, that is lock and unlock, starting and stopping your car with an app, can be built into integration to make the experience one free of a physical car key. Alternatively, google wallet allows for NFC car keys, although the only supported manufacturer of this system is BMW [https://www.cnet.com/roadshow/news/android-digital-car-key-sharing-announced/]. The biggest concern here is Key Fob cloning or unintended key sharing. To bring it around, creating key fobs from scratch could already be done with or without the use of an OBD reader [https://www.youtube.com/watch?v=Hvgo517JEv8]. How auto makers will handle security within AAOS will certainly be a tall order.
Thanks for reading, Stay Safe.
