We are excited to announce the Qt Automotive Suite 2.0, a great leap forward towards a unified HMI toolchain and framework for digital cockpit, available end of February 2018.
A few years back, we saw several challenges in the industry. One was that with increasing number of screens being present in the car, creating and maintaining a consistent digital UX across multiple displays with strong brand differentiation is unquestionably difficult. Why? Because a perfectly integrated digital UX for the digital cockpit does not end with the UI/UX design, it is only the beginning. When an OEM sends out the design specification, the supplier typically utilizes different software tools and technologies for developing the instrument cluster and center stack (aka. IVI or Infotainment) respectively. Somewhere down the line, there will be unavoidable HMI refinement needed to ensure the digital UX on different screens cooperate in a cohesive way.
Another challenge was that there was little reusability from one project to another, from one customer to another. The re-usability issue was particularly prominent on the center stack development. There was a lot of duplication of work when creating a new center stack HMI and it was just inefficient. Low re-usability made it difficult for the industry to rapidly innovate and differentiate on the HMI, and the development cycle was long and costly.
The third challenge we saw was that the center stack HMI has been traditionally monolithic, meaning all features (e.g. HVAC control, media player, radios) are packed into a single software instance. This approach not only created risks of introducing bugs, but more importantly, each feature may interfere with each other. If one feature crashes, the whole center stack needs to restart. This creates a lot of headache for developing and maintaining the HMI development – it is difficult to split the features into smaller sub projects for parallel development, and a pain to maintain a monolithic code base. Of course, if one feature needs update, the whole center stack needs to be rebuilt and reinstalled.
We solved these challenges, working with our strategic partners Luxoft and KDAB, announcing our first release of the Qt Automotive Suite 1.0 in 2016. We created the market’s first unified HMI toolchain and framework for digital cockpit development.
Today, we are happy to report that Qt Automotive Suite has been well received and are being adopted by some of the major OEMs in the world. An increasing number of customers are switching from the traditional specification writing and outsourcing, to owning the HMI design and development. We are glad to see the market is transitioning toward this direction that matches well with our vision, and the Qt Automotive Suite proves to be the right solution. Above all, we are seeing millions of cars shipped with Qt Automotive Suite in the coming years.
So, what is in Qt Automotive Suite 2.0?
Let’s look at the diagram.
Figure 1: Qt Automotive Suite 2.0
Qt Automotive Suite 2.0 builds out a vision to provide easy-to-use tools that free designers and software engineers to rapidly create superior digital cockpits. Before we jump in to the key features, here is one digital cockpit reference that is built with Qt Automotive Suite.
Qt for Device Creation
As customers are adopting Qt Automotive Suite for production development, the feature set and stability must be carefully balanced. Now the Qt Automotive Suite 2.0 sits on top of Qt 5.9, bringing major performance improvement and feature set while receiving Long Term Support (LTS).
Qt 3D Studio
We believe a truly unified HMI toolchain and framework should also ship with advanced UI authoring tool for the designers. With 3D becoming a more significant part of the HMI we saw the need for a design tool that facilitates rapid 3D UI/UX concepting and design. For that, we now included the Qt 3D Studio into the suite.
Qt Safe Renderer
Functional safety is a critical path that our customers must cross. Qt Automotive Suite 2.0 includes the Qt Safe Renderer, ensuring the rendering of safety critical telltales is reliable and certifiable by ISO 26262 part 6 ASIL-B specification.
Qt Application Manager
Qt Application Manager brings a modern multi-process GUI architecture to the IVI. By separating the HMI into different functional units (for example, HVAC could be one unit while Navigation could be another), Qt Application Manager enables independent teams to develop and test both separately and simultaneously, thereby reducing project risk and shortening development time. In addition, splitting the UI into smaller applications also makes it easier to do system updates; smaller pieces of code are touched, and the OTA updates are smaller.
Qt Application Manager is a headless, core component. Despite the application management tasks, Qt Application Manager powers the Reference UI which implements a system UI compositor and the home screen along with a selection of apps.
In Qt Automotive Suite 2.0, the user can now make a custom application executable based on Qt Application Manager internal libraries. This greatly improves flexibility and makes integration in customer specific system setups easier. The new and extended system monitoring APIs has been extended and now also allow monitoring of resources consumed by separate applications. During the startup, the new logs allow tracing and profiling of apps in much larger details. Another improvement to mention is further polishing of the single-process mode, which allows running QML-runtime application on single process setups in the same way as on multi-process ones.
There are lots of other improvements under the hood, be sure to check out the latest documentation.
Qt Application Manager Plugin for Qt Creator
Since Qt Application Manager controls the application life cycle, direct launching from Qt Creator is now possible. A special plugin is provided now which wraps the command line tools provided in Qt Application Manager and integrates all essential steps into Qt Creator IDE. In Qt Automotive Suite 2.0, the plug-in uses the Generic Linux device type as a base. In the future it will directly use Boot2Qt device types to unify the device setup.
To tackle reusability, QtIVI brings a level of standardization within the Qt ecosystem for how to access and extend automotive-specific APIs. The applications developed in one generation of program can be reused on the next, even if the underlying platform is different. This is particularly important as OEMs are increasingly taking control of the car HMI development. Reducing duplication of work means significant cost saving and more focus on branded UX differentiation. Qt Automotive Suite 2.0 will integrate well with industry’s leading initiatives such as GENIVI and AGL, further increasing the re-usability on the platform level for the entire industry.
At its core, Qt IVI is built around a pattern based on the separation of API facing the application developer, so-called Feature, and the code implementing it, the Backend. There can be multiple backends per feature and the Core module provides support for finding the corresponding backend in an easy-to-use way.
Common use cases driving this separation are:
- Early development, where the UI can rely on a feature with a very basic backend implementation.
- Testing / simulation, where the backends can be tested separately from the app and the app can be tested using a specialized testing backend.
- Targets with different hardware configurations, where certain parts of the system are represented by simulated backends while others use a real hardware integration.
- Dynamically appearing services, when services are available sometimes, but not always, meaning that backends come and go over time.
The module provides an extendable set of reference APIs for automotive features. It can be used to develop automotive applications and to provide automotive features to Qt-based applications in a structured manner.
We added a way to describe interfaces using an IDL (interface definition language) and then generate Qt/QML API code based on this definition. We use QFace IDL and its libraries, which provide a generic auto-generation framework. In addition to the generic integration of a QFace-based auto-generation into QtIVI Core, we migrated the Climate and Vehicle Settings APIs to be based on IDL.
From the interface definition, the tooling generates the QML and C++ APIs, code that allows properties (i.e. values) to be inspected and overridden by other tools such as GammaRay and Squish, and the code for a simulator that will allow a developer to observe and control vehicle data values in the absence of a real vehicle to test on. This is useful not only for debugging but also for automated testing.
Figure 2: Qt IVI auto generator architecture
The grey boxes are the only parts what the customer needs to implement. The visible part (to the end user) is the application that uses the vehicle data. The non-visible part is the communication with the vehicle data service which is typically an independent process that communicates via an IPC.
The Qt Automotive Suite deeply integrates GammaRay into the QtCreator which allows for runtime introspection, visualization and manipulation of internal structures such as scene graphs and state machines. This can provide an insight into the running system to diagnose those hard problems and understand where memory is being used.
In Automotive Suite 2.0, our partner KDAB has added new texture inspection capabilities, improved Qt Quick layout diagnostics, support for QML binding analysis, and many other improvements. In addition, GammaRay’s performance has been improved to reduce the analysis impact on the target application and increases the responsiveness of the remote views. Make sure you have a read on GammaRay.
Figure 3: GammaRay can identify resource waste and even suggest remedy
Reference UI: Neptune
Since the initial release of Qt Automotive Suite, Qt Quick Controls 2.0 were released providing significant improvements in performance and more flexible styling. The Neptune reference UI has been upgraded to use Qt Quick Controls 2.0. The UI initialization supports staged loading for better performance. There is a new Notification framework with a Notification Center, Application Expose allowing to stop apps. Check out the documentation.
After 2.0, we will provide a new UX design and implementation developed by our partner Luxoft. Some of you might have seen it already at the CES or at the Embedded World shows this year.
Figure 4: New Neptune UI
The future System UI highlights Qt’s unique windows compositing capabilities. Take a look at the Phone, Maps, Player app widgets, they are run as separate apps and composited together on one screen managed by the System UI that acts as Application Launcher and HVAC control.
Qt Automotive Suite 2.0 is now more mature, and one aspect is that we now have much better documentation for all the existing and new tools, components, and APIs.
Let us reiterate this. Many times, parts of the system functionality will be delivered by second and third parties. Or third parties may want to develop apps specifically for your platform. The Qt Automotive Suite makes it easy to build a redistributable SDK that contains your specific HMI assets and added middleware together with the Qt tooling to allow 3rd parties to build and test their apps with minimal intervention.
Open Development Model
The Qt Automotive Suite will be developed in the same open manner as Qt itself. The code is available at http://code.qt.io/cgit/ and there is an automotive specific mailing list (http://lists.qt-project.org/mailman/listinfo/automotive) for discussions on engineering and product direction.
With Qt Automotive Suite 2.0, we now provide a truly end-to-end solution for the digital cockpit HMI development, bringing designers and developers to work under the Qt ecosystem, maximizing consistent digital UX for all screens while equipped with Functional Safety. With reduced design-development roundtrip and underlying cost, OEMs can now focus more on HMI innovation and brand differentiation, which is a win for the whole industry and consumers like you and us.