5 IoT challenges for connected car dev

Growth in adoption of connected cars has exploded as of late, and is showing no signs of slowing down, especially the vehicle-to-infrastructure and vehicle-to-retail segments. As adoption grows exponentially, the challenges in how we develop these apps emerge as well.

One of the biggest challenges to consider will be connectivity, and how we connect and network the millions of connected cars on the road. How can we ensure that data gets from Point A to Point B reliably? How can we ensure that data transfer is secure? And how do we deal with power, battery, and bandwidth constraints?

1. Signaling

At the core of a connected car solution is bidirectional data streaming between connected cars, servers, and client applications. Connected car revolves around keeping low-powered, low-cost sockets open to send and receive data. This data can include navigation, traffic, tracking, vehicle health and state (Presence); pretty much anything you want to do with connected car.

Signaling is easy in the lab, but challenging in the wild. There are an infinite amount of speed bumps (pun intended) for connected cars, from tunnels to bad network connectivity, so reliable connectivity is paramount. Data needs to be cached, replicated, and most importantly sent in realtime between connected cars, servers, and clients.

2. Security

Then there’s security, and we all know the importance of that when it comes to connected car (and the Internet of Things in general). Data encryption (AES and SSL), authentication, and data channel access control are the major IoT data security components.

In looking at data channel access control, having fine-grain publish and subscribe permissions down to individual channel or user is a powerful tool for IoT security. It enables developers to create, restrict, and close open channels between client apps, connected car, and servers. With connected car, IoT developers can build point-to-point applications, where data streams bidirectionally between devices. Having the ability to grant and revoke access to user connection is just another security layer on top of AES and SSL encryption.

3. Power and Battery Consumption

How will we balance the maintaining of open sockets and ensuring high performance while minimizing power and battery consumption? As with other mobile applications, for the connected car, power and battery consumption considerations are essential.

M2M publish/subscribe messaging protocols like MQTT are built for just this, to ensure delivery in bandwidth, high latency, and unreliable environments. MQTT specializes in messaging for always-on, low-powered devices, a perfect fit for connected car developers.

4. Presence

Connected devices are expensive, so we need a way to keep tabs on our connected cars, whether it be for fleet and freight management, taxi dispatch, or geolocation. ‘Presence’ functionality is a way to monitor individual or groups of IoT devices in realtime, and has found adoption across the connected car space. Developers can build custom vehicle states, and monitor those in realtime as they go online/offline, change state, etc.

Take fleet management for example. When delivery trucks are out on route, their capacity status is reflected in realtime with a presence system. For taxi and dispatch, the dispatch system knows when a taxi is available or when its currently full. And with geolocation, location data is updated by the millisecond, which can also be applied to taxi dispatch and freight management.

5. Bandwidth Consumption

Just like power and battery, bandwidth consumption is the fifth connected car challenge we face today. For bidirectional communication, we need open socket connections, but we can’t have them using massive loads of bandwidth. Leveraging M2M messaging protocols like the aforementioned MQTT lets us do just that.

Building the connected car on a data messaging system with low overhead, we can keep socket connections open with limited bandwidth consumption. Rather than hitting the servers once multiple times per second, keeping an open socket allows data to stream bidirectionally without requiring requests to the server.

Solution Kit for Connected Cars

The PubNub Connected Car Solution Kit makes it easy to reliably send and receive data streams from your connected car, facilitating dispatch, fleet management applications and personalized auto management apps. PubNub provides the realtime data stream infrastructure that can bring connected car projects from prototype to production without scalability issues.

The future of embedded automotive technology

Rob Valiton, senior VP and general manager, Automotive, Aerospace and Memory Business Units, Atmel Corporation, recently participated in an EE Catalog panel discussion about the future of embedded automotive technology.

According to Valiton, there is a wide variety of of technology that will continue to find its way into in-vehicle infotainment (IVI) systems – with capacitive touchscreens projected to be one of the fastest-growing spaces.

“The current dominant touchscreen technology in automotive is resistive. However, resistive technology does not allow consumers to interact with their car the way they interact with their smartphone, tablet and Ultrabook. The superior user interface, including common gesture recognition utilizing pinch/zoom and swiping motions is enabled by the adoption of capacitive technology,” he explained.

“Some newer features such as hover and proximity may also have the potential to create a less-distracted user environment than what exists today. Hover and proximity can be used in combination to ensure that the drivers’ eyes stay on the road for as long as possible and changing basic setting does not require several menu changes.”

In addition, Valiton noted that there are a number of standards which should be (further) unified to accelerate the IVI experience between on-board systems and connectable consumer products, with standards ranging from security and software considerations, to technology such as Bluetooth and Wi-Fi.

“Standards identified by technology standards bodies, such as the Bluetooth SIG or Wi-Fi Alliance, are required in order to unify the IVI experience on-board, specifically in relation to consumer products. These are required to ensure a smooth and seamless connection, as well as a positive experience for the end user,” he said.

“Firmware specifications are identified within a car to ensure connectivity is established flawlessly. [Plus], continued development of standards such as those being developed by the Connected Car Consortium will ensure that drivers can continue to control their devices using existing in-vehicle equipment. Of course, software considerations are also important. Since the infotainment lifecycle of an automobile is typically much longer than in the home, future cars must consider software standards along with the ability to upgrade.”

Valiton also pointed out that there are a number of technologies required to connect a car to the roadway and municipal infrastructure, along with vehicle-to-vehicle communications.

“[Such technology] requires a microcontroller (MCU), numerous sensors, a connectivity solution which can range from Wi-Fi such as 802.11p, GPS and 3G or 4G networks and security. The combination allows cars to connect to roadway and municipal infrastructures such as Fastrak, toll payment or Onstar security systems—all of which are connected to terrestrial and/or wireless connectivity,” he said.

“Clearly, security in automobiles is very important. Remember, we are all used to having virus protection readily available on our PCs, but are unlikely to think that much about how secure our software is in the modern automobile. Until now, the software has been part of a closed system and not subject to hacking. With the new V2V and V2X systems, we will need technology to ensure secure firmware updates and prevent hackers from communicating with unsuspecting drivers and their vehicles.”

Last, but certainly not least, Valiton commented on the future of self-driving cars, citing a recent ORC International survey that claimed only 18 percent of consumers would consider buying a self-driving car.

“Despite this survey, we believe consumers do not have a full understanding of self-driving cars. There are a number of technologies today that are baby steps towards a self-driving car (think automatic braking),” he explained. “One example is the safe park, where the vehicle parks itself. Another example is autopilot, a system used to guide a vehicle without assistance from a person, developed in 1912. Autopilots are used in aircraft, boats (known as self-steering gear), spacecraft, missiles and other vehicles.”

Similarly, an aircraft autopilot still requires human intervention—a pilot and a co-pilot—to ensure that if anything is amiss, they can be sure to steer the plane to safety.

“With self-driving cars, drivers will have the option to set the car in drive and not worry about a long trip or traffic. Similar to cruise control, the self-driving car can be turned off or if there is an emergency, the driver can still have full control of the car,” he added.

The car-to-x system warns of road works, congestion, obstacles and dangerous weather (courtesy Daimler).

“However, with strict automotive standards currently in place, to make this idea a reality, hardware and software must work closely together to achieve a safe and reliable self-driving car and one that is not hackable. Embedded technologies such as microcontrollers, sensors and touch solutions, encryption and even technologies such as 3D scanning are already in place to enable an autonomous vehicle. We are ready for self-driving cars; the real question is whether both manufacturers and drivers are ready to embrace it.”

Interested in learning more about Atmel’s comprehensive automotive lineup? You can check out our full automotive portfolio here.