Today we announce the launch of the first generation of the Qt Automotive Suite.
The idea for the Qt Automotive Suite was born when The Qt Company, Pelagicore and KDAB sat down and shared their experiences of projects using Qt for In-vehicle Infotainment (IVI). With cumulative experience from over 20 automotive projects it was noted how Qt is really well suited to the needs of building IVIs and Instrument Clusters, that there were already millions of vehicles on the road with Qt inside, and that there were a lot of ongoing projects. There was though a feeling that things could be even better, that there were still a few things holding back the industry, contributing to the sense that shipped IVI systems could be built faster, cheaper and with a higher quality.
One observation was that additional infrastructure components and tooling were being created. While it is great to see software being built on top of Qt, from an industry perspective it is inefficient with duplication of work, little reuse across projects and engineering resources being used to maintain them rather than focusing on differentiating features. So we’ve added some of these components to the Qt Automotive Suite and will continue to add more over time.
Another observation was that industry practices had been slow to change from when IVI was simply a radio with a two-line display. Then, writing a specification and outsourcing the implementation worked well. Now there are multiple screens in the car that represent the digital UX and allow the user to physically interact with the brand. This digital UX needs to be perfectly integrated with the entire interior design making it almost impossible to perfect a consistent user experience first time in the design house: some refinement is inevitable when the HMI is tested in-vehicle and unanticipated usability problems are found. We are seeing changes in the industry with OEMs taking control of not just the HMI design but also its development. The tools we are adding will make it faster to try out UI changes and to deploy to the target. More iterations mean a more refined UX and a better experience for the end customer.
Automotive Suite Architecture
What is the Automotive Suite? A picture is better than a thousand words so here’s what it looks like with the parts outlined in red specific to the Automotive Suite.
All the added pieces were carefully selected with the goal to make it faster to build better in-vehicle experiences. Let’s now describe some of the components in the diagram above and why we added them.
Qt for Device Creation
The Qt Automotive Suite inherits all the good parts of Qt for Device Creation. This include the QML language for building modern user interfaces, Wayland support with the Qt Wayland Compositor, Qt WebEngine based on Chromium, remote deploy and debugging directly to your target board and a comprehensive class library including multimedia and networking to make writing application logic faster and more fun.
The Application Manager and Compositor
IVI systems are getting more complex and building a complex UI with a single application is becoming unwieldy and fragile. The Application Manager and Compositor bring a modern multi-process architecture to Linux in the car. Separating the HMI into different functional units allows independent teams to develop and test both separately and simultaneously, reducing project risk and shortening development time. 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.
The Qt Wayland Compositor, which debuts as a technical preview in Qt 5.7, is integrated with the Application Manager which can be used to take care of a virtual keyboard and notifications as well as compositing the displays from multiple applications. How these different displays are composited is completely up to the HMI design team, with the QML language being used to define the layout and behavior of output from each application.
The Application Manager handles the complete lifecycle of an application. It validates the installation package and can handle API access permissions. If the Application Manager determines that the system is running low on resources, for example memory, it can shut down idle applications.
Application launch time is fast due to pre-forking a process to run the application.
We advocate splitting the HMI into applications. There might be one for media playback, another for phone call handling and another for display vehicle status. These have to talk to the middleware so we’ve build a set of cross-platform Qt APIs called QtIVI to abstract these from the underlying middleware.
QtIVI – Automotive APIs
The QtIVI APIs introduces a level of standardization within the Qt ecosystem for how to access automotive-specific APIs. The goal is to promote reuse: 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.
The QtIVI APIs follow a pattern to provide common, but extendable, Qt interfaces integrating to the various platform middleware components used by the various OEMs. This means that the same function is exposed through the same interface, even if the implementation is completely different. The core functionality can also include a channel to the Application Manager to check to see whether the application calling a particular component has permission to use the API.
As and where it makes sense, we will provide backends for GENIVI, QNX and AGL. In the future there will also be backends that work with the desktop device emulator, described next.
One thing we’ve found in automotive programs is that there are never enough hardware units to go around and they are never available early enough in the development cycle. Qt for Device Creation includes an emulator for testing your application on the desktop so we will be extending it to support all the QtIVI APIs. This will allow the inputs to be simulated or even scripted to do what you want so the whole system can be tested on the bench. Not only will this be great for developers, it will also be great for QA, allowing input values to be scripted and even out-of-range value to be tested.
QML Live – Update the UI on a Live System
Getting the UI correct is typically an iterative cycle. Do a design, implement it and see how it looks. The faster a design can be tested, the more iterations and the better the end result. Usually, testing a new UI design involves a compile, link and flashing of the device. With QML Live a change to a QML file can be seen running on a live system as soon as the Save button is hit. This makes tuning color schemes, fonts, and animations on target display just so much more productive.
Deploy to Target & Debugging from Qt Creator
Qt for Device Creation is our product for embedded systems. A key feature is being able to build and download an app to the target device and optionally launch a debugger all with one click from within the Qt Creator IDE. The Automotive Suite includes this functionality which removes the lengthy device flashing stage which makes developers much more productive.
Profiling & Diagnostics
Qt Creator already provides remote debugging tools. It also provides profilers to see how long your QML code is taking to execute which is critical for ensuring smooth 60fps operation and instant start-up. The Qt Automotive Suite deeply integrates an additional tool called GammaRay into 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.
Each automotive program and platform is different and great tools that increase productivity need to be extensible and tailored to a specific context. For that reason GammaRay also provides building blocks for the creation of visualization and diagnosis of proprietary frameworks, specialized hardware or protocols, custom controls or third party components. So if there is a specific aspect of the system you routinely need to look at in depth, GammaRay can be extended to do that in a way that integrates seamlessly with the existing development tools.
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 for discussions on engineering and product direction.
The Qt Automotive Suite v1.0 is timed for release towards the end of June, shortly after the availability of Qt 5.7. It will support any Linux and work just fine and for anyone wanting to quickly try it out we have pre-built yocto stacks for the Boundary Devices Sabre-Lite i.MX6 board and for customers of the NVIDIA DriveCX. For QNX, the tooling works with both QNX 6.6 and QNX Car 2 in combination with the native Application Manager and Compositor.
The goal of the Qt Automotive Suite is to make building of IVIs faster with a combination of software components, automotive APIs and tooling. It will be available under both commercial and Open Source licenses. This is just the start and we will be adding functionality and improving the tooling with each release. If you want to talk to someone about this fabulous new toolkit, please fill in the form https://www.qt.io/contact-qtauto.