Apps on the Road: How to Make Them Work on a Car Integrated Computer

Whether you are a media company, a smartphone maker, a car manufacturer, an insurance company or even an app developer, you are most probably aware of the potential modern vehicles can offer for your apps and services. But how can we establish the actual communication between a vehicle and a phone? How to keep driver distraction to a minimum? How to ensure that the chosen solution will remain viable throughout the lifespan of the vehicle?

Free drivers’ hands from the smartphone

The decision-making strategy would consist of, firstly, the location of the application. It could be stored in the head unit, in the smartphone or in the cloud. Secondly, it is the issue of how to control driver distraction – which HMI should be used, which apps should be allowed? The third question would be about integration methods.

At the present moment, options include at least SYNC AppLink, Android Auto, Apple CarPlay, proprietary SDKs, etc. The wide selection of different technologies and options results from the fact that the concept is new and emerging. Companies are now promoting solutions that are relevant to their strategies, business goals and other facts which stimulate them to force one option over the other. The good thing is that some of the technologies may live in peace on board of a car all at the same time, but the risk here is that it could generate some confusion for consumers, which is absolutely not in line with the idea of avoiding distractions.

It’s also natural to assume that, at some stage, there will be just two or three winning mainstream integration technologies, since the rest will remain as potentially specialized and niche technologies. New solutions should obviously be planned considering the modular architecture, enabling easy migration from one integration technology towards the other, at the lowest possible costs and with minimal influence on user experience.

Safety first

When vendors undertake the task of bringing an app on board of a car, their primary concern is how to make the interaction of the driver and the app a super safe deal. Let’s consider the hypothetical situation, when drive at 80 km/h. We move almost 23 meters each second, and keeping our attention focused on the phone for just three seconds means that for 69 meters we are not paying attention to driving and are prone to potential hazards.

The study conducted by the National Highway Traffic Safety Administration (NHTSA) and the Virginia Tech Transportation Institute (VTTI) shows that 80% of crashes and 65% of near-crash situations involve some kind of driver distraction which takes place within three seconds before the accident on most occasions.

Hence, just because something can be brought into a vehicle doesn’t mean that is should be done so. Only appropriate content is allowed.

You should’ve gone for the head unit

The obvious solution is to create a proprietary operating system for the head unit. But then the car manufacturer needs to develop new applications in-house, and adapt the existing ones into its own system. In many cases, it’s not directly in the interest of the car manufacturer to either write an app or adapt the existing one.

The distribution mechanism is also a potential problem. The mobile industry has managed to establish vital ecosystems gathered around each leading mobile OS, as the final step in the evolution of app distribution. No such ecosystem currently exists in the world of the car industry, and considering that even market leaders are having a problem when creating one, the development of a new ecosystem might be of serious concern to some of the leading car manufacturers. Another issue that could prevent the creation of independent operating systems is that software must be connected to hardware that should be capable of running the newest applications for the next few years. Don’t forget the different pace of R&D in the automotive and consumer electronics industries.

Adapt your app

Many customers would like to bring their smartphone applications to the car – to the dashboard screen, to the car speakers – and make use of the functionality that has been custom-made and tailored for a specific interior. Keeping applications embedded in the smartphone and integrating them into the vehicle creates many opportunities, provided they are well-designed and built by software vendors that are aware of the specific requirements of the car context.

The crucial element of a successful application is a well-designed HMI and overall user experience – keeping the right balance of the car’s constraints and experience gathered directly from modern mobile platforms.

The possibility of two-way control between the smartphone and the vehicle is also an interesting factor. We shouldn’t just control the phone using the car’s HMI. We must also be able to change car settings like turning on the engine or air conditioning directly from the screen of our smartphone. Scenarios like remote engine activation on a cold winter morning can become nothing out of the ordinary.

AppLink

Let’s consider Ford connectivity technologies, such as AppLink, which exists as an effort to keep the driver’s hands on the wheel and their eyes on the road.

AppLink is a suite of APIs that provide the ability for mobile developers to extend the command and control of a mobile application to the in-vehicle HMI. AppLink transfers the normal functionality processed by touching a mobile device screen into the familiar vehicle controls such as voice commands, steering wheel and radio buttons, and capacitive touch screens.

When an application connects to the Ford vehicle, the application must lock out the device screen in an effort to further deter in-hand interaction.

Certain categories of mobile apps simply will not be allowed to interact with a Ford vehicle, since the primary concern is safe driving, as mentioned above. Additionally, certain content and functionality within approved apps will not be allowed to extend in-vehicle.

What do developers say?

Specific requirements are applied primarily at the level of the UI and refer to safe interaction while driving. The app menu should be as simple as possible, with large buttons which are easy to use. Certain actions like login or settings are mostly available when the phone is disconnected from the multimedia system which is further underlined by notifications like “Please park your car”. Advertising may be absolutely forbidden for the sake of safety to avoid driver distraction during the ride.

Some multimedia systems may provide their own UI and interaction protocol, so mobile app development proceeds within their limits.

Technical difficulties during adaptation are mostly observed during the app adaptation as such, especially when we deal with user flow and a specific head unit. This is explained by the fact that head units often have a limited set of UI tools, their locations and interaction. Hence, we have to create an app observing such limitations while keeping as many functional features of the app as possible and taking into account clarity and ease of use.

As for the type of apps, the integration process hardly depends on it. It will look the same in any case:

- We determine limitations and possibilities of the head unit for the app in question.

- We find out which functions of the app will be implemented or not.

- We map out the structure/design of the app for the head unit taking into account the first two steps.

- We implement the support of the head unit.

The app type mostly influences the functionalities that can be transferred to the head unit, with due consideration of the said possibilities and limitations.

The main requirement has been mentioned several times – safe driving. In other words, the interaction of the driver with the app in the head unit should not distract him/her from driving.

The rest flows logically from this requirement. There are normally restrictions related to display of video or data input. Some clients want to have the option of showing notifications for drivers informing them of unsafe actions on the road.

In addition, if the head unit allows creating a completely customized UI, there are requirements for button sizes, fonts, colors used. But this is more about design rather than functionalities.

Round up

No doubt that all vehicles in the future will be connected. This small revolution has already begun. Its first steps are soft, but it will soon be a regular topic on many conference agendas – not only those specific for Telematics and in-vehicle information and entertainment systems. The future is in integrated, synchronized systems providing personalized user interfaces across all everyday life devices, for example, computers, tablets, smartphones and cars. Synchronized data is kept in the cloud and app UI should be customized for each device.

It looks like it’s already time to invest in development and the deployment of actual applications and services. Some barriers, like driver distractions, market fragmentations, a broad ecosystem of players, and emerging integration technologies that are still in the development phase, are obvious, but if we look at any other sphere (for instance, healthcare) we can list similar obstacles. The future is connected, and the car is part of that connected world.

The Qulix team is aware of the extreme diversity in the car market and has expertise in all integration scenarios. Manufacturers of car stereos (Kenwood, JVC, Sony, Pioneer) may have their own SDKs, which require a personalized approach to software development, testing and integration. Our experience in using diversified products and tools and knowledge of weak spots is a major advantage for our clients.

If you are thinking about taking your app on board of vehicles and looking for the best option to bring your solution safely and successfully to life, fell free to contact us via request@qulix.com or visit our website.