5 noteworthy challenges of automotive software development

HMI and connected applications

Before we dive into the most noteworthy challenges of automotive development, you must understand that modern automotive applications generally fall into two categories. One is the main interactive display on the vehicle called the human machine interface (HMI). The second major category is the connected application that runs on a mobile device to facilitate interactions with the HMI unit.

The HMI is responsible for functions such as GPS, media controls, phone interface and other accessory functions within a vehicle. This can also include components such as backup camera views, blind spot warning systems and other hardware designed to assist the driver. The HMI unit typically integrates with an onboard messaging bus that both receives and transmits messages to the rest of the vehicle.

Connected applications form a link between mobile devices and the car's HMI, whether that is via a wireless connection like Bluetooth or by directly plugging into a vehicle's USB port. These applications live within the mobile device, rather than the vehicle itself, but still maintain a significant relationship with associated HMI applications.

Challenge 1. When HMIs and connected applications collide

While developers typically don't think of mobile devices as real-time, embedded devices, it's possible for a phone to overwhelm the HMI unit with messages while operating on a network. For instance, such an overload can occur when the HMI unit needs to send a safety alert by dialing 911 through the connected mobile device while also signaling the vehicle's location via GPS.

SAE International has developed J2945, a set of standards for communication between personal devices and automobiles. In practice, teams use a framework from the manufacturer, design the application responsibly and test heavily for unusual conditions. The go-to approach to deliver connected applications is to have users download them via a verified app store, such as the Apple Store or Google Play, and to then integrate the device with the HMI via USB or Bluetooth.

There are limitations to what kind of applications developers can deliver via the HMI, however. While it may seem tempting to let the onboard computer screen in a car play video for passengers, you won't find any official in-vehicle application for a video service in any app store. This is due to concerns around driver responsibility, as there are few ways to ensure drivers won't abuse such a function while driving alone.

Listening to music while you drive is considered responsible. Watching a movie is not. Yet streaming services and text messages run on phones, which can connect to the HMI while a car is in motion, and a GPS can reasonably detect someone is in a car. It's possible the person sending the text is not the driver but someone in the backseat, however, and most HMI systems offer APIs to determine if the vehicle is moving and lock the screen.

Challenge 2. The unique world of automotive applications

To build an in-vehicle application, developers often used open source technology from the SmartDeviceLink Consortium, an open source community designed to provide resources for connected in-vehicle applications written for Android, iOS or other HMI-compatible platforms. Some examples of specific languages and frameworks for these types of applications include Java for both Android and HMI-related components and Cocoa for iOS applications.

Developers should remember that individual automakers will maintain their own application design standards and development tools, making it important to know things like what specific frameworks they'll need to support or the unique requirements they'll need to satisfy as early as possible in the process. In addition, software capable of sensitive actions like unlocking doors or starting engines often falls under its own class of security controls and regulatory requirements that developers will need to comply with.

The Car Connectivity Consortium, another organization dedicated to defining standards for in-vehicle connectivity applications, defines additional rules regarding how to connect a vehicle identification number (VIN) to an owner, thereby creating a digital key that grants a phone or other mobile device permission to wirelessly control vehicle operations.

Challenge 3. Build and deployment considerations

It's important for developers to remember that test versions of automotive software likely won't be directly deployable to an app store. It's possible to build packages that sideload directly onto mobile devices, but that can be difficult -- and potentially dangerous -- to do alone. Most companies tend to provide a continuous integration server that creates a build for every change marked with a certain tag.

Several beta testing tools, such as TestFlight and Applivery, let select users download and custom build software. With this in place, the concern moves to the process of promoting the application post-deployment, including whatever delay the individual app store in question imposes before a release. Another consideration is that major releases of software tend to cause stores to remove all existing user reviews -- something those working on existing applications will need to stay mindful of.

Challenge 4. The need for high observability

Most connected applications bring the company's product into the vehicle. As a result, they tend to use APIs, which require an internet connection. Cell phones lose connectivity as vehicles move, and parking lots can limit coverage. Errors also creep into the transmission of the API. These errors can occur within an API gateway, at the composition level, in a source API, in the network or somewhere between the network and the vehicle.

An automotive application system with proper observability should be able to link a VIN to all the specific API calls it made through a navigable list of search queries. Operations staff, testers, programmers and customer service can then see exactly what went wrong and when. If you combine error reporting with queries on the number of which types of error, you have powerful tools for improvement. Without comprehensive observability, all you have is an error report.

Although observability tools can help a company with diagnostics, they do have their downsides. Observability tools can be expensive to implement and, in the worst cases, cause network traffic spikes and congestion. They aren't the type of tool you can flip on all at once in a complex environment. Consider a staged rollout, and performance test them.

Challenge 5. The risk of delaying release cycles

End-to-end tests on actual vehicles tend to be slow and expensive, which can often tempt developers to simply avoid new releases as much as possible. However, as more time elapses between releases, the more likely it is that software will pile on bugs that will ultimately need to be addressed anyway -- often in the form of a large, overwhelming test cycle.

One way developers can try to avoid this problem is to get as close to the real vehicle as they can. For instance, if leasing the current model year of the actual vehicle isn't an option, see if it's possible to run a real HIM on your desktop. Along the way, consider the different model years and devices this application will support, and try having members of the team use different configurations when building the software.