The Evolution: From Carburetors to Clouds

A lot has happened in the 30 years that have elapsed since General Motors introduced GM OnStar to provide connected vehicle services (telematics at the time) to drivers and passengers, in order to improve accident safety, and location-based features. Let’s take a stroll down “Connected Car Memory Lane” and see how things evolved.

Chapter 1: The Breakdown Lane (1970-1985) — Why cars needed to talk

The journey toward connected vehicles began not with grand visions of autonomous driving or entertainment systems, but with a far more fundamental problem: cars were breaking down, and nobody knew why until it was too late. Diagnosis was an art form practiced by mechanics who relied on experience, intuition, and often sheer guesswork. A mysterious engine knock could mean anything from bad gasoline to imminent catastrophic failure. By the time most problems were diagnosed, the damage was done — and expensive.

The catalyst for change came from two converging crises: mechanical complexity and environmental regulation. By 1975, the average car had over 15,000 individual parts, any one of which could fail without warning. Warranty claims were eating into profits. Meanwhile, the Clean Air Act and California’s increasingly strict emissions standards demanded precise control of engine parameters that mechanical systems simply couldn’t deliver.

The solution emerged in the form of On-Board Diagnostics (OBD-I), first mandated by California in 1988 but developed throughout the early 1980s. This wasn’t about adding fancy features — it was about survival. OBD-I required vehicles to monitor their own critical systems and alert drivers when something was wrong. That simple “Check Engine” light represented a profound shift: for the first time, cars could tell you they were sick before they died on the highway. It was, in effect, a nervous system for the vehicle.

The early implementations were chaotic. Each manufacturer developed their own diagnostic protocols, connectors, and trouble codes. A Ford mechanic couldn’t read a GM computer without entirely different equipment — like needing a different stethoscope for every patient. But the foundation was laid: cars were beginning to communicate, even if they all spoke different languages.

By 1985, electronic engine control wasn’t optional — it was mandatory for meeting emissions standards. The 8-bit processors managing fuel injection and ignition timing were crude by today’s standards, but they established the principle that would define the next four decades of automotive development: software could solve problems that hardware alone could not.

Chapter 2: The Digital Foundation (1986-1995) — Learning to speak

In 1994, the California Air Resources Board mandated OBD-II for all 1996 model year vehicles — a universal standard that would revolutionize automotive diagnostics.

The requirements were specific and comprehensive: a standardized 16-pin connector located within three feet of the steering wheel, universal diagnostic trouble codes (starting with P for powertrain, B for body, C for chassis, U for network), real-time data streaming at standardized rates, and freeze-frame data capturing the exact conditions when a fault occurred. After decades of babble, the industry finally had a common language: any scan tool could talk to any car.

But OBD-II represented something more profound than standardization — it was effectively the automotive industry’s first universal API. The diagnostic port wasn’t just for reading trouble codes anymore; it provided real-time access to hundreds of data parameters: speed, RPM, coolant temperature, fuel trim, oxygen sensor readings, and more.

Meanwhile, another revolution was brewing in automotive networking. As vehicles added electronic features — anti-lock brakes, traction control, airbags, power seats — the wiring was becoming impossibly complex. The 1990 BMW 7 Series contained nearly 2 miles of copper wiring weighing 110 pounds. Robert Bosch GmbH’s solution, the Controller Area Network (CAN) bus, allowed multiple systems to share a single communication network. Messages were broadcast to all components, but only relevant recipients would act. It was elegant, robust, and transformative.

By 1995, the pieces were in place for the connected car revolution: standardized diagnostics through OBD-II, efficient internal networking via CAN bus, and rapidly improving cellular networks. The automotive industry had built the nervous system — now it needed a brain.

Chapter 3: The OnStar Revolution (1996-2005) — The first true connection

In October 1996, General Motors did something that until then seemed like technology out of a science fiction novel: they embedded cellular hardware and a GPS receiver directly into the Cadillac DeVille. Not as an add-on through the diagnostic port, not as an accessory that could be installed later, but as an integral part of the vehicle’s architecture. OnStar was born — the first true connected car system with its own dedicated telematics control unit.

This was a radical departure from everything that had come before. While other manufacturers were debuting features like an in-dash CD player or passenger airbag, GM was installing what amounted to a $1,500 computer and communication system in every OnStar-equipped vehicle, with its own cellular modem, GPS receiver, and processor, separate and independent of the vehicle’s diagnostic systems.

The genius of OnStar’s embedded approach became clear during its first real-world saves. When a crash triggered airbag deployment, automatic crash notification immediately contacted the response center with exact GPS coordinates — even when the vehicle was invisible from the road and the driver was unable to call for help.

By 2000, OnStar had saved over 100 lives through automatic crash response. The system was handling thousands of emergency calls monthly, remotely unlocking doors for forgetful owners, and recovering stolen vehicles. The embedded architecture meant OnStar could do things no diagnostic-port-based system could: disable a stolen vehicle’s ignition, honk the horn to help owners find their car in a parking lot, or run remote diagnostics without any action from the driver.

The business model was revolutionary too. For a modest monthly subscription, OnStar transformed the car from a one-time purchase into a platform for ongoing services, with renewal rates unheard of in the automotive industry. By 2005, OnStar had millions of subscribers generating over $1 billion annually.

Chapter 4: The Sync experiment and its limitations (2007-2012)

Launched in 2007, Ford Sync was clever in its simplicity. Instead of building in a cellular modem, it used Bluetooth to connect to drivers’ phones. Instead of proprietary navigation, it could use smartphone apps. The system could read text messages aloud, make voice-controlled calls, and play music from USB devices. It was “bring your own device” before that became a corporate IT strategy.

Initially, the strategy worked. Sync was far cheaper to implement than an embedded system — roughly $300 per vehicle versus $1,500. Ford sold over 1 million Sync-equipped vehicles in the first year. Infotainment satisfaction scores jumped, and younger buyers in particular loved the smartphone integration.

But cracks soon appeared. Without an embedded modem, Sync couldn’t do automatic crash notification — it relied on a paired phone that might be damaged, out of battery, or out of range. Remote services like door unlock were impossible. Vehicle diagnostics required the owner to actively run an application. When drivers forgot their phones or batteries died, Sync became a glorified radio.

The killing blow came from an unexpected direction: software updates. Embedded systems could update themselves remotely. Sync required customers to download updates to a USB drive and install them manually — a process so cumbersome that only a small fraction of owners ever did it. As smartphone technology rapidly evolved, Sync fell further behind.

By 2011, Ford announced Sync would add an embedded modem in future versions. The experiment in phone-dependent connectivity was over. The lesson: “connected car” means the car needs to be connected, not just the driver.

Chapter 5: The dongle revolution — hacking the diagnostic port (2008-2015)

The OBD-II port, designed for emissions testing and diagnostic tools, provided power and access to vehicle data. What if you could plug in a device that added cellular connectivity, turning any car into a connected vehicle? It would mean using infrastructure meant for one purpose to achieve something entirely different.

The first successful OBD-II dongle was Automatic, launched on Kickstarter in 2012. For $99, it promised to make any car “smart” — tracking fuel economy, logging trips, detecting crashes, and even calling for help in emergencies. Within two years, Automatic had 100,000 users.

The dongle ecosystem exploded. Zubie offered fleet tracking for small businesses. Mojio added Wi-Fi hotspot capability. Verizon launched Hum, Progressive introduced Snapshot for usage-based insurance, and dozens of startups created their own variations. By 2015, over 10 million OBD-II dongles were in use globally.

But dongles had limitations that embedded systems didn’t. They could be unplugged — problematic for stolen vehicle recovery or teen driver monitoring. They could read data but not control vehicle functions. Power management was tricky; some dongles drained batteries if vehicles sat unused. And they occupied the only OBD-II port, blocking mechanics from running diagnostics.

More concerning was security. The OBD-II port was never designed for continuous connection to the internet. Researchers demonstrated that compromised dongles could potentially send malicious commands to vehicle systems. Regulators and insurers took notice. The very universality that made OBD-II dongles attractive also made them risky.

The dongle era proved that consumers wanted connected car features and would pay for them, and that aftermarket solutions could move faster than traditional automotive development cycles. But it also showed the limitations of retrofit connectivity.

Chapter 6: The Tesla disruption — rewriting the rules (2012-present)

While traditional automakers debated embedded versus tethered connectivity, and startups hacked the OBD-II port, Tesla reimagined the entire concept of what a car could be. Tesla did not just add connectivity to vehicles — they built vehicles around connectivity.

On September 19, 2014, Tesla owners worldwide experienced something unprecedented. They woke to find their cars had literally improved overnight. Not through any physical modification, but through an over-the-air software update that reduced 0-60 times by a full second. No dealer visit. No hardware changes. Just bits and bytes transmitted through Tesla’s embedded LTE connection while owners slept.

Unlike a traditional luxury car which might have 50-70 electronic control units from different suppliers, each running proprietary software, the Model S had essentially one central computer controlling everything from door locks to motor control. Where a Mercedes S-Class had 2.5 miles of wiring, the Model S had less than half that.

But the real revolution was philosophical. Traditional automakers saw software as something that supported the car. Tesla saw the car as something that supported the software. The 17-inch touchscreen was not just an interface — it was the interface, controlling virtually every vehicle function. Physical buttons were eliminated ruthlessly, and the car’s operating system was based on Linux.

Every Tesla was permanently connected via embedded cellular modems — not as an option, but as a fundamental architecture requirement. The vehicles uploaded vast amounts of diagnostic and driving data daily. This was not just telemetry; it was a continuous feedback loop. An unusual pattern observed in one market could be analyzed, fixed, and deployed to every car globally within weeks.

The OTA capabilities transformed Tesla’s business model. Instead of yearly model updates that required new purchases, Tesla could add features to existing vehicles — for a price. Acceleration Boost, Full Self-Driving Capability, even heated rear seats could be activated remotely. The car became a platform for in-app purchases.

Traditional automakers scrambled to respond. Volkswagen created a separate software company with thousands of engineers. Ford recruited Tesla leadership. GM announced Ultifi, their own software platform. But they faced a fundamental challenge: their existing vehicles were not designed for comprehensive OTA updates. Adding connectivity to a traditional distributed ECU architecture was like trying to turn a library into Wikipedia — technically possible, but missing the design philosophy that made it work.

Chapter 7: Where we are now

The connected car is no longer a project. It is the platform. Most new models ship with embedded modems, continuous telemetry, and a plan for software income over the life of the vehicle. The strategy shift shows up in architecture. Carmakers are moving from a forest of isolated control units to domain controllers, then to zonal controllers tied to a central computer that coordinates experience, safety, and performance. The motivation is simple. You cannot update fifty suppliers’ boxes every other week. You can update one brain. The result is a vehicle that behaves like an edge device on a cloud. It can learn, heal, and sell services without a visit to the service bay. Analysts call this the software-defined vehicle. The differentiator is code, and the electrical and electronic backbone exists to enable it.

Conclusion: Technology marches on

Modern vehicle driving and passenger experiences would not exist without the backbone of technologies that have evolved to provide connected vehicle services. The next wave of technology will include capabilities being tested right now like “data-casting,” which uses broadcast technology to send data to moving vehicles instead of expensive wireless. Real-time continuous map updates, emergency alerts, and richer infotainment content are just a few of the services that can be provided in this way. And as vehicle architectures improve, your car really will become more like an edge device, able to heal itself, enable new features, and request service automatically, improving the ownership experience as well. Onward!