Finding the Right Development Tool and Platform for a Vehicle HMI

Many automotive Original Equipment Manufacturers (OEMs) and Tier 1 suppliers are developing their own platforms and implementations of embedded Human-Machine Interface (HMI), Connectivity, and In-Vehicle Infotainment systems. For this challenge, there is a wide range of basic operating systems and user interface development tools available. Each of them has its pros and cons, as well as the supported functionality available for integration. These in-house developments are aimed at process optimization to achieve the company's key goals, ultimately leading to increased product margins.

The main directions for the development of these types of systems cover three major goals for the vehicle as a product:

• Advanced Infotainment is one of the most popular in the passenger vehicle segment and includes a range of entertainment features available in the car, as well as navigation and voice recognition systems. The latter two are the most resource-consuming processes on head unit devices and raise the increasing level of requirements for hardware implementations and peripheral devices. For example, almost all OEMs in the passenger segment are targeting to have natural language support in a voice assistant, which requires a stable internet connection and a high-quality noise cancellation system.

• Robust Vehicle Interaction includes all types of interaction with the internal components of a vehicle and the requirements for this interaction. This direction is key in terms of each OEM's branding since it aggregates all types of physical and digital interfaces for interacting with drivers and passengers. Consequently, from the head unit functionality point of view, Tesla Model Y, New Ford Mustang, and Byton have completely different configurations of screens and controls. Moreover, we must not forget that in the case of digital dashboards, we have to take into account the requirements of ISO 26262. Additionally, the active development of ADAS and Autonomous Driving functionality is leading to a significant complication in the visualization of screen content through the integration of 3D rendering.

• The goal of the smart ECO system is quite flexible, but its main aim is to increase the margin of the final product through integration with external services. On the one hand, this includes basic user profiles that are already in place on smartphones, and on the other, integration with external business services or data providers. This direction is particularly important for commercial vehicle OEMs or vehicles that focus heavily on car sharing or taxi markets, as it allows them to accumulate a wide range of commercial services without incurring additional costs.

  
  

  Each of these goals includes a large number of functions that have pushed forward the development and innovations in the industry in recent years.

Here are examples of the functionality that slips into areas:

Each OEM and Tier 1 supplier takes into account business goals and forms the requirements for the main head unit architecture on top of it. The standard vehicle life cycle is typically 3-5 years, so solutions with separate modules for each of these goals are moving aside, giving way to solutions with a single control module for all these goals. The major driver of this change is the optimization of the vehicle BOM cost, which puts forward more complex technical requirements for such solutions.

The most critical of them:

1. Most parts of OEMs have already abandoned the analog dashboard and replaced it with a digital one. This brings requirements to achieve ISO 26262 with a minimum ASIL B level and has all safety-related mechanisms aboard.
2. The built-in Human Machine Interface and In-Vehicle Infotainment are subject to very stringent requirements in terms of speed and stability. For example, the most challenging requirement for boot-up time is 2 seconds to display the Rear view camera according to NHTSA https://www.ecfr.gov/current/title-49/subtitle-B/chapter-V/part-571/subpart-B/section-571.111 (although there is a possibility of increasing this time up to 4 or 5 seconds due to earlier switching on driver approaching recognizing).
3. Different from mobile systems, Vehicle Human Machine Interfaces (HMI) and In-Vehicle Infotainment systems are focused on multi-display solutions (take, for example, the latest models of Volkswagen, Mercedes-Benz, Ford, JRL, etc.). This introduces additional requirements for the functionality and performance of these systems.

All described separation is common and works in different vehicle engineering approaches, but OEMs are actively transferring all HMI-related activities in-house. This raises a difficult choice between different available on-market platforms and user interface frameworks for development. To make the right choice, it is necessary to base the requirements on the major goals of the OEM on possible technical implementations. This process is actually the first step towards transferring development or choosing a solution foundation.

But before going deeper, it would be good to introduce an abstraction of such solutions architecture:

By moving away from separate devices responsible for each goal, we are developing solutions based on hypervisors of the first, second, or hardware-dependent types. Much has been written about them; we won't pay much attention to this. The only thing we are interested in is that the resource-sharing method on the hypervisor level should have minimal impact on the trusted (safety) operating system and should reach ASIL B level as a standalone solution or in a system with a display.

The first crossroads that influence the company's goals is the selected platform and operating systems used to implement business logic and user interface in the safety and infotainment domains.

Most of this segment of the automotive market is occupied by solutions:

Here, it needs to be clarified that all the solutions that you may see on the road have gone through a customization process done by the OEM or Tier1 suppliers, but the base as a rule is taken from one of the above bases operating systems. It is also true that there are small pieces of completely different solutions. For example, I have worked with Windows CE-based implementation; honestly, the amount of effort put into this development and quality leaves them out of this article. Of course, with unlimited resources and time, it is possible to implement the functions described above on any of these platforms, but in practice, it is always necessary to proceed from vehicle timelines and budgets.

Let's try to estimate the efforts for the implementation of the entire scope of work on each of the platforms:

Depending on the technical aspects of operating systems, some of the functionality may not be realizable at all or require unreasonably high costs. For example, Linux-based operating systems will not be able to implement safety and time-critical functionality, and RTOS-based systems will not be able to support ecosystems or complex multimedia functionality. The question of license costs for these operating systems needs to be discussed outside of this article and should be a topic for commercial negotiations.

All of the described platforms in the dedicated configurations can cover the company's business goals, but the actual visualization in each case could be completely different and depends primarily on the frameworks used. The same operating system used in Ford and Kia/Hyundai vehicles has a fundamentally different visualization.

For developing an in-house solution for the Human Machine interface and In-Vehicle Infotainment systems, choosing the right framework is the second critical crossroads. In my experience, there have been two cases when an OEM or Tier1 has chosen the wrong framework at the beginning, spent huge amounts of effort on implementation, and in the end realized that it would not work at all.

Currently, there is a wide range of such frameworks available on the market, as well as solutions provided by Tier1 vendors (Harman, Continental, Bosch, LGE and Luxoft). Tier1 solutions are mostly based on some of the common frameworks with added functionality. The common frameworks include: Kanzi (Rightware), Altia, Qt + Qt3DStudio, EB GUIDE, Android Automotive (Native – standart Android Automotive Framework), Android Automotive (Unity/Unreal Engine – combination of Android Automotive Framework and injections of Unity/Unreal Engine frames for 3D visualisation). Each of the listed tools has its pros and cons, grown from the historically established functionality and adapted market segments.

As can be seen from the visualization, the frameworks available on the market could cover needs at the development level and allow for certain needs from the business goals of the company to be met with different levels of effort. The lower value for criteria indicates more effort and costs that must be expended by the company to build a solution on top of a selected framework. Each of the discussed frameworks supports the main operating systems listed above, but not all types of CPUs are used in embedded systems. Porting to an unsupported CPU can cost several million dollars.

If summarize the results for operating systems and frameworks, then the following picture will be:

Based on the platform and framework limitations, a group of real-time operating systems with user interface modeling solutions, such as Kanzi (Rightware) and Altia can be identified. These combinations cover the needs of the trusted domain, but are quite consuming when it comes to implementing an Infotainment domain. This is mostly due to the development cycle of modeling tools and the limitations raised by safety domains.

EB GUIDE Qt + Qt3DStudio allow to build solutions across all operating systems, but in both cases significant will be spent on optimization.

No matter what configuration Android is in, it remains Android. It takes up a significant part of Infotainment solutions now, but the possibility of realizing Safety solutions based on it looks very problematic. The same issue is present with all Linux-based operating systems.

Unfortunately some Frameworks suppliers are legally restricted to share information misaligned with their vision and they are not included in the review, so each company has to make a such evaluation with these tools themself

Final Thoughts:

I hope this analysis will help someone speed up the decision-making process for development and allow them to avoid any hidden pitfalls that are not always visible from the marketing prospectus and open documentation.

References:

Kanzi Studio - https://rightware.com/product/kanzi-studio/

Qt 3D Studio - https://doc.qt.io/qt3dstudio/qt3dstudio-index.html

EB GUIDE Studio - https://www.elektrobit.com/products/ux/

Altia - https://altia.com/design/

QNX - https://blackberry.qnx.com/en

FreeRTOS - https://www.freertos.org/

Automotive Grade Linux - https://www.automotivelinux.org/

COVESA - https://www.covesa.global/