By on January 11, 2017

SYNC 3 AppLink now automatically discovers smartphone apps including Spotify, Pandora, Stitcher, and displays their unique graphics and branding, Image: Ford

Ford, Mazda, Toyota, Subaru, PSA (Peugeot, etc.), and Suzuki are now part of an automotive alliance concerning your dashboard. The SmartDeviceLink Consortium, as they’re styling it, is apparently all about muscling around Google and Apple’s forays into the automobile, and is based on Ford’s existing “AppLink” software project, which has been around for several years.

I’ve written about smart dashboards before for TTAC. Particularly, in 2013 after Apple’s original announcement, I was amazed automakers were willing to cede so much control over the precious dashboard real estate. I later noted people are likely to be more loyal to their phones than cars and to make buying decisions around what cars support their phones “properly,” especially because Apple and Google fundamentally know a lot more about you and can do a much better job of knowing what you want to listen to and where you want to go.

But what exactly is the SmartDeviceLink Consortium all about? You might think it sounds like it’s a rejection of your smartphone driving the screen in your car, as with Android Auto and Apple CarPlay. Curious as to what was really going on, I then dug into the giant pile of software and specifications they’ve posted on Github. What’s really going on here isn’t as much in opposition to what Google and Apple are up to as it’s an attempt to standardize it and refactor it.

Consider the following diagram:

SmartDeviceLink technology overview diagram, Image: SDL Consortium

HMI, on the left, is the big touchscreen in your dashboard. SmartDeviceLink (SDL) is a computer somewhere behind that screen running many different software components, which then interacts with your device, pictured on the right.

Hey, can you zoom into that SDL diagram? Sure, happy to oblige:

SDL Components View diagram, Image: SDL Consortium

What I hope is plainly visible to any TTAC reader, whether or not they’ve ever written a line of code, is that there’s a whole lot of stuff going on here, replicating many of the features and services already present inside your phone.

So how is all of this different from what Apple and Google are doing?

Primarily, Apple and Google’s designs are all about keeping it simple. The car provides access to the screen and maybe a few other handy things like wheel telemetry or a compass, and then the phone does all the rest of the work, saying “here are a bunch of pixels, draw them.” Dumb car, smart phone. Apple and Google’s designs are conceptually similar to a long-established class of remote desktop software applications (think: Microsoft Remote Desktop Services, Citrix, VNC, and other such things).

What’s the ostensible benefit of SDL having all of this functionality refactored into the car rather than resident solely in the phone? Let me give an example and zoom in on one proposal (dated August 2016, written by a Ford employee) for handling “turn by turn mobile managers”:

The idea is to provide an API in the mobile libraries to app developers to navigate to a desired destination. On the other side suppliers of navigation SDKs can develop against APIs and create a [turn by turn] proxy to accept requests to navigate to a destination. Furthermore these navigation SDKs can provide notifications for instructions, a maneuver icon and a map view to be shown inside the lock screen. In between SDL can receive the information from the navigation SDKs and send them to the HMI of the head unit. Implementing the HMI related work inside the mobile libraries would unify the behavior of different navigation SDKs and make it very easy for app developers to integrate a navigation feature into their apps.

In a nutshell, SDL is all about having the car collaborate with the phone rather than being a dumb display terminal for it. This gives the automaker an opportunity to customize how things work, to add their own layers, to mix-and-match native and remote applications, and so forth. Sounds great, right?

Computer security and keeping it simple. A legendary computer scientist, Sir Tony Hoare, once said: “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.” Apple and Google’s approaches are all about keeping the car side relatively simple with the heavy lifting happening inside the phone. Conversely, SDL is trying to do more of the work inside the car itself. Not only does this imply many more problems with software bugs, integration issues, and long-term maintenance, it’s also going to be a nightmare for computer security.

Yes, computer security. In the modern era, when cheap Chinese webcams have been used to mount massive denial of service attacks, it’s legitimate to consider how our cars should be resistant to external exploitation.

Consider the last time you rented a car; you had no idea where it’s been. The prior driver’s poor taste in music or incomprehensible seating position is only the start of your problems when we’re talking about the car’s computers. Would you connect your phone with that car?

The magic of having a standardized connection between your phone and the car, if it’s done right, is that you have a narrow interface between the evil, sharp, dangerous world of smartphones and the safe, fluffy, every-component-is-a-special-snowflake world of the automotive CAN bus, wherein any component can issue nasty commands to any other; see for example this lovely security analysis of J1939 communications used in big trucks and other heavy equipment. The car-side support for Android Auto and Apple CarPlay can be small and carefully engineered. It can shield the car from evil phone behaviors. At the same time, the car/phone communication protocol can be sufficiently full-featured to pass along screen touches, wheel telemetry, and other goodies to make your smartphone nav work better than it could do alone. Likewise, the security-sensitive software on the phone can and will be updated all the time. Software in the car, at least for most cars, is rarely updated.

Computer security is a process. No software is ever perfect out of the gate, and carmakers don’t generally have the processes or mindset to deal with this. After all, it took GM five years to fix the security vulnerabilities reported to them by a joint UCSD / U. Washington team. (Check out our TTAC coverage from 2011.)

In short, everything about SDL seems to fly against Hoare’s keep it simple maxim. Inside the car, SDL places a full-blown web browser supporting the HMI. SDL includes a giant pile of C++ implementing the SDL Core. And how aggressive will the automakers be at rolling out monthly security patches for decade-old cars? How well do you trust them to debug and test their internal software against all the external phone apps that will be communicating with it now and in the future?

In computer security lingo, SDL has a massive attack surface. In military lingo, SDL is a target-rich environment. Keep it simple! It’s the only way.

Dan Wallach is a Professor in the Department of Computer Science and a Rice Scholar at the Baker Institute for Public Policy at Rice University in Houston, Texas. His research concerns computer systems security, he harangues Rice CS sophomores to “write beautiful code,” and he’s really bothered the new Honda Civic Hatchback doesn’t let you get a manual transmission and Android Auto at the same time.

Get the latest TTAC e-Newsletter!

Recommended

20 Comments on “SmartDeviceLink Introduces ‘Target-Rich Environment’ for Car Hackers...”


  • avatar
    sirwired

    The reasoning behind automakers wanting to push Android Auto / CarPlay to the side is obvious. If every entertainment system looks alike (because Android/Apple is running the thing), that’s now not a point of differentiation between automakers. It’s perfectly natural for automakers to want to make themselves distinct from the competition and sideline companies they view as nothing more than outside suppliers that aren’t beholden to them.

    The problem? They suck at it. With very few exceptions, what Google and Apple have put together is superior to what the automakers have devised for themselves, and the automakers have the disadvantage that they don’t have the massive infrastructure available to leverage the capabilities of the “mothership” in some distant data center.

    Google and Apple can respond intelligently and accurately to all sorts of voice commands because they can farm your request out to a distant server farm and leverage immense amounts of computing power and knowledge about you to compute the answer.

    In addition, they have all sorts of UI engineers that have some faint clue how to do their jobs, which apparently is not a job requirement designing OEM infotainment GUIs.

    Speaking for myself (the proud owner of a ’17 CR-V), AA/CarPlay was on my list of “must-have” features for whatever car I purchased.

  • avatar
    psarhjinian

    Dear christ, this looks like an attempt to make the same mistakes as we made when we allowed cars to just slurp phones via BT OBEX (and get, quite literally, everything utterly wrong), combined with the mistakes we made when we thought that RPC & DCOM were just fantastic.

    Great article, by the way.

  • avatar
    5280thinair

    For an analogy, look at the the mobile phone market back when the carriers controlled what software you could put on your phone (pre iPhone). The carriers had little interest in updating the capabilities of the software because they made their money selling the devices. Want newer/better software? You’ll have to buy a new phone.

    If manufacturers push more of the capabilities into the cars hardware and built-in software, and rely less on the phones, then they can push that same paradigm: gaining new features means buying new hardware (in this case, a new car). I suspect that’s the real incentive here.

    • 0 avatar
      28-Cars-Later

      “Want newer/better software? You’ll have to buy a new phone.”

      This is still true.

      “If manufacturers push more of the capabilities into the cars hardware and built-in software, and rely less on the phones, then they can push that same paradigm”

      This was already happening to an extent (i.e. feature X misses the product launch and you have to buy it again two years in to get it). We’ve already discussed the concept of a permanent leasing society and planned obsolesce, it benefits you very little and industry very much.

      • 0 avatar
        5280thinair

        “This is still true.”

        Not nearly as much as it used to be. Buy a Pixel phone from Google, or an iPhone from Apple, and you’re typically able to install the next 2-3 major OS upgrades and get the majority of the new features without paying more money*. Contrast that to the pre-iPhone days when getting any new capabilities pretty much required a new phone.

        I agree other features are already like this with cars. I suspect the mfgs want that to happen with infotainment systems as well rather than let Google/Apple get you upgrades for free or by buying a newer device from them where no money goes to the car maker.

        *Yes some new features are tied to the hardware, but typically those are in the minority. And yes, with a lot of cheaper Android phones the carrier never makes OS updates available; you need to do your homework to determine which carriers/phones will get updates.

      • 0 avatar

        “Want newer/better software? You’ll have to buy a new phone.”

        Sure, but a new phone is a few hundred bucks, and many people upgrade every two years. A new car is a whole lot more money and you upgrade much less frequently.

        So far, only Tesla seems to be serious about adding new features to older cars. Sure, they’re not retrofitting AutoPilot hardware into the cars made beforehand, but all of the software upgrades that run on older cars are released for them.

        Note that it’s not just about “features”. It’s also about bug-fixes, security-related and otherwise. It helps immensely that every Tesla connects home regularly to download updates.

    • 0 avatar
      S2k Chris

      “For an analogy, look at the the mobile phone market back when the carriers controlled what software you could put on your phone (pre iPhone). The carriers had little interest in updating the capabilities of the software because they made their money selling the devices. Want newer/better software? You’ll have to buy a new phone.”

      Exactly right. That was the REAL breakthrough of the iPhone, it was a device maker getting to dictate terms to a carrier. I was at Motorola when the iPhone first was launched, and honestly, for a year or two we were excited because it was a seismic tilt in the power balance between carrier and device maker that we assumed would also benefit us. Note that when Moto came out with the OG Droid, it also was famed for being naked unskinned Android, instead of coming with all the VZW/ATT bloatware. But, Moto being Moto, we got our lunch eaten anyways, and I left years ago.

    • 0 avatar
      epsilonkore

      You have to keep in mind that cars should stay on the road an average of 8 years (I think I read that somewhere) and the software should remain relevant during that time. Static hardware/software isn’t the way to go.
      I have had Apples CarPlay in my 2013 FR-S (Via Pioneers NEX headunit) since CarPlay 1 and my iPhone 5. Every iOS update bugs were squashed, features added, and performance improved. Every new iPhone (on iPhone 7+ now) resulted in even better CarPlay performance. Now my screen is instant in response (vs pretty fast on my iPhone 5 and 6) and the App library keeps expanding (I have over 30 CarPlay apps available, though only 10 are regularly used). Apples Maps went from crap compared to Pioneers built in, to vastly superior within 3 years.
      Comparing my parents 2013 Edge (complete with the latest Sync Firmware updates) that is still useful, but sluggish in comparison to my 2013 Pioneer head unit with CarPlay is night and day. Expensive map updates hurt the argument as well.
      Add to that Siri, now reaching into my home with HomeKit… I can turn on my climate control, unlock my locks, and turn on the lights from the dash of my car or from my voice. Sync and its voice recognition, is stuck where it was (despite updates), with zero outside connectivity.
      Leave the software to Apple/Google/Amazon (Ford and Hyundai using Alexa is a GOOD idea… though I wish it was powered by a regularly upgraded phone instead of a static in dash system).
      Just give us big screens to project to, and API’s that allow Siri/OK Google/Alexa to control the cars climate/locks/lights/NAV (but not safety systems, brakes, steering… yet…) and let the cloud be leveraged to keep everything super fast in a way that static hardware can’t keep up with.

  • avatar
    S2k Chris

    Didn’t see it addressed here, but I’ve heard/read that a lot of the fight is actually about who owns the mineable data resulting from usage. If Apple/Google use the car as a display, all of the data stays on the Apple/Googled device for viewing/mining/use by A/G. If the work is done in the car, then all of the sudden the car makers own this data and can do what they will with it.

    Right Wrong Indifferent?

    • 0 avatar
      5280thinair

      I hadn’t thought about that, but it’s likely correct.

    • 0 avatar
      JMII

      I would guess this is a driving (no pun intended) factor behind it. Remember its ALL about the data! The current business model (that everyone learned from the Google) is: this service is free, in exchange for free we record/track everything you do, since you do lots of stuff we then have lots to sell to others thus ensure this service stays free, plus these others can sell you more stuff allow the loop to go on forever.

      Honestly car OEMs have proven to be terrible at doing this kind of thing (OS, GUI, NAV, etc). So the CarPlay model seems 1,000 times better. So what is the smart OEM to do? I suggest they work on model specific apps and provide hooks into those via the car level connection. For example a “My Honda” app tells me when to change my oil, what my tires pressures are, current and past gas mileage, etc. Then using the phone’s push notification system interact with the customer that way. Instead it appears they are just going to make an over complicated mess that will never work and become abandon-ware as soon as the next model is released.

    • 0 avatar

      I’ll probably need to write a whole new essay on this point, but here are the broad outlines of the issue. The name of the game is, of course, how to make money out of adding a car into the mix of information that’s already floating around in your phone.

      Here’s a simple example: how about radio advertisements customized to you? Just based on what you’re driving and where you are, an advertiser can infer an awful lot about who you are. If all the audio is streaming from your phone, then the carmaker gets nothing. Even without the customization, I’ll bet Pandora pays some kind of royalty to have their Pandora button built into your car.

      In the Apple/Google universe, Pandora does the integration work exactly twice (once for iOS and once for Android), and every automaker does the work twice (again, once for iOS and once for Android), and then poof, Pandora works in every car rolling down the road. No need to strike a royalty agreement with each automaker. No fuss, no worries. That’s something that Pandora would almost certainly prefer, although it does put Apple and Google in a central position to mediate what’s going on. If those two companies say “no GPS for you!” then Pandora can’t do location-specific advertising. If they hide the make/model of the car, then Pandora can’t use that to infer other things about you.

  • avatar
    schmitt trigger

    “And how aggressive will the automakers be at rolling out monthly security patches for decade-old cars? How well do you trust them to debug and test their internal software against all the external phone apps that will be communicating with it now and in the future?”

    Those. Sentences.
    Made my skin crawl.

    • 0 avatar

      Crawling skin is a regular hazard of working on computer security. You get used to it.

      • 0 avatar
        zamoti

        I for one, don’t believe that we should just accept this progression that’s being thrust upon us by a group of people that presume to know better than everyone else. As noted earlier, there is a ton of data to mine from cars, but it doesn’t serve the end user in any meaingful way. Sure we get cute apps that give us navigation and music, but what about something actually useful? In most modern cars, the infotainment system (aka, radio) is integrated into and has access to a variety of critical systems that reside on the CAN bus. WHY?!?! Why on earth does the radio need to talk to the ABS/traction control systems, or the ECU or any other non-infotainment (excepting HVAC maybe)? For many years we’ve had cars with complicated drive systems, transmisions, active suspension and they’ve had their own SEPARATE interfaces, that is a button or knob on the console somewhere. Now we need to shove all of this into a bright pretty toy for what reason? What problem is being solved with this? Worst of all, even with all of this information being fed to the dash computer, we STILL rely on a stupid check engine light! No clue as to what is wrong, some cars have some info, but usually nothing with any amount of detail. If there were a real benefit to the user, the carputer would provide a detailed narrative of what an issue is and even offer to send that data to a service center for advice. We could have remote diagnosis cost tracking (dollars per mile) but we don’t. Instead we’re all worried that our stupid phone won’t play music or share an address book in just the right way.
        I believe that there should be a full and hard separation of CAN bus systems from the infotainment system. Given that there has been no move toward benefit to the user and a LOT of risk for remote exploitation and unwanted surveillance, I don’t see any reason why they should communicate at all.
        Furthermore, there should be a common interface for these in-dash systems that will allow users to have them removed and/or updated and (God forbid) even changed for a different unit as the user sees fit.
        Instead of just being used to having our collective skin crawl, it seems that the media at large should be on point to call out these issues and question the WHY of what is happening instead of just asking useless questions like “will it connect to my old iPhone?”

        • 0 avatar

          Why not use completely separate buses? Two reasons:

          1) Money. It’s all about the money. The more you integrate things, the lower your costs.

          2) Features. Let’s say everybody decides to follow Tesla’s lead, and do everything on a giant touchscreen. That means HVAC controls, audio, phone, external networking, never mind various car controls like suspension settings, acceleration limits, and more. If you want all those features, that means your computer is going to be issuing CANbus requests to all the appropriate devices.

          Even in cars where you’ve got separate physical buttons for HVAC, stereo, etc., they’re probably still going with integrated electronics, since it saves money.

  • avatar
    WildcatMatt

    Here’s another angle: I’m staring at that section marked “Transport Adapters” and thinking about your car deciding it won’t use the hotspot on your phone for ‘net access and you have to add your car to your data plan (for only $50 more per month!!11). The auto industry wins ’cause it now has wifi access to your data AND the cellular industry wins ’cause it now adds millions of additional lines.


Back to TopLeave a Reply

You must be logged in to post a comment.

Recent Comments

  • SoCalMikester: toyota got in early and mastered the game. when i think hybrid, i automatically think prius. but yes,...
  • SoCalMikester: looks like you only mentioned the 2 “gayest” areas, for some reason. the whole LA and OC...
  • Dave M.: Texas is ditching the safety inspection but keeping the emissions check in the major cities.
  • scott25: Also the one in Wichita is exactly what I’m looking for. Just slightly unfeasible at this point.
  • scott25: I sometimes browse Craigslist for them in US (it’s really inconvenient to use compared to Kijiji since...

New Car Research

Get a Free Dealer Quote

Staff