When my customers develop embedded systems, they face similar challenges:
- Challenge 1: iPhone-Like HMI
- Challenge 2: Internet-Connected
- Challenge 3: Running Everywhere
- Challenge 4: Fast Time-To-Market
Using examples from different industries, I’ll first elaborate on the challenges and then on how Qt can help us to solve these challenges. These challenges are typical for nearly every industry nowadays: automotive, agricultural, medical, manufacturing, home-appliance, home-automation – to name just a few.
Challenge 1: iPhone-Like HMI
Challenge Explained
Requirement specifications for HMIs have become pretty short these days: “My HMI shall look, feel and behave like an iPhone”. But – what does it mean for an HMI to be iPhone-like? I think that Larry Constantine’s five rules to characterise good usability give the best definition of “iPhone-like” (Note: I summarised Constantine’s rules 1, 2 and 3 into my rule 1):
- Rule 1: HMI adapts easily to different experience levels (beginner, intermediate, expert).
- Rule 2: HMI is suited for the context, in which it is used.
- Rule 3: HMI makes real work easier, faster, more fun, or makes new things possible.
My simple washing machine has a strictly mechanical HMI: a rotary button, a few push buttons, no display. I have three types of laundry: the stinky stuff (underwear, towels, etc.), the normal stuff (shirts, good pants, etc.) and the special stuff (some woollen sweaters). For each type, I have to set the buttons again and again. There is no way to define a programme for each type. So, my simple washing machine fails Rule 1, as it is no good for intermediate or expert use.
A good example for Rule 2 are the different ways of user input for an in-vehicle infotainment system. Entering a destination is pretty tedious with a rotary knob, but pretty simple with touch. In contrast, changing the settings of the climate control is simpler and especially less distracting with the rotary knob than with touch. With touch input, the driver must look at the screen. With a rotary knob, the driver can do the change without looking. The simplest way of all is speech control, which fits the context of driving a car best.
Getting Rule 3 right is what made the iPhone such a success. Browsing through photos in cover flow with a simple flick of our finger is obviously easy, fast and fun. Everyone grasps the idea intuitively and gets grumpy when they have to browse photos in the old way. Another example for Rule 3 is navigation. By simply adding a GPS antenna to a smartphone, it became possible to use the smartphone as a sat nav – and save some money on buying a separate sat nav.
These three rules are a good guideline to tell apart a good and a bad HMI. They also give a pretty clear idea what customers mean when they want an “iPhone-like user experience”.
Solution with Qt
Of course, the first step towards an iPhone-like user experience is a really good user interaction design. For the next step, the implementation of this design, we need a technology that makes it easy and quick to turn a great design into a great HMI of our embedded system. Enter QML!
QML is a lightweight declarative language built on top Qt. It is very easy to learn and leads to very compact code. In the early days of QML, I was tasked by a premium TV maker to rewrite a prototype of their TV GUI in QML. They needed 20 days and 18K lines of code to write the original prototype. The QML version took me only 5 days and 1.5K lines of code. And bonus, the QML version ran much faster and smoother on their TV hardware.
QML enables a pair of a UI designer and an application developer to develop a GUI very quickly in a very agile way. The design gets implemented almost instantly and tried out immediately on the target hardware. The pair can even ask some users to try out a feature. Based on the users’ feedback, the GUI is changed – often on the spot. Knowing early what works and seeing alternatives is very valuable to customers. QMLs support for an agile approach (very much in the sense of eXtreme Programming) makes it easy to satisfy the three golden rules of good usability.
QtCreator – a first-class IDE for developing software with QML, Qt and C++ – includes a UI designer (tool) for QML. So, it supports the work of both the UI designer (person) and the application developer very well. If this is not enough, QtCreator can be customised to special needs, as it is open-source and is implemented using a plugin architecture.
Here are a few examples of systems using QML for their GUIs: Blackberry 10 smartphones, in-vehicle infotainment (IVI) system of QNX’s concept car for CES 2014, IVI systems of three car OEMs (soon to be on the roads), Freebox set-top box (STB) by French telco Free, millions STBs and TVs, Loewe’s SoundVision system, in-flight entertainment systems of 50+ airlines, home appliances of several top-10 OEMs and many more systems. If you are still not convinced about the simplicity and power of QML, read KDAB’s post “Qt 5 under the hood”. It is a fantastic testimony by QNX how easy and fast it was to develop the in-vehicle infotainment system of QNX’s concept car for CES 2014. It says it all!
Challenge 2: Internet-Connected
Challenge Explained
If we hook up our home appliances to the Internet, new things become possible (Rule 3 from above). The oven can send an alert to our smartphone when the bread is ready. So, we can watch TV in another room without the bread getting burned. When our washing machine is defect, it can prepare a diagnostics report, which we can send to the technical support of the manufacturer. The technical support could even log into our washing machine to find out what’s wrong. Or, we can control our wireless speakers from our induction hob such that we can listen to Internet radio stations or our own music. There seem to be nearly limitless possibilities once a device is connected to the Internet.
Solution with Qt
Qt supports the application layer protocols like HTTP, TLS/SSL, FTP and DNS right out of the box – even through proxy servers. This is easily enough to use web services over RESTful APIs. If we need other application layer protocols, say, like SIP, RPC or POP3, we can implement them using Qt’s TCP and UDP socket classes. We can also use these socket classes to implement proprietary protocols. More often than not, we’ll find out that someone else has implemented a communication stack with Qt already. There are stacks for SIP, VoIP, SOAP and many others. So, Qt has all that’s needed to connect our embedded systems to the Internet.
Challenge 3: Running Everywhere
Challenge Explained
Users can nowadays control their home appliances from their smartphones, tablets and PCs – in addition to controlling them directly from, say, a touch screen. Hence, similar HMI software must run on different smartphone and tablet OSs (iOS, Android, Windows Phone, etc.), on different desktop OSs (Windows 7/8, Mac OS X, Linux), and on the OS of the embedded system (Linux, QNX, vxWorks, etc.). On top of that, the OS must run on different processor architectures (ARM, Intel, SH4, MIPS, etc.) – with different means of graphics acceleration (OpenGL, OpenVG, DirectFB, none).
Of course, we do not want to develop the same HMI software for each mobile, desktop and embedded OS over and over again. That would multiply our development efforts. Hence, we want to reuse as much code as possible. And, we do not want to care on which OS and processor architecture our system will run in the end.
Solution with Qt
There are two technologies that run everywhere: Web (HTML, JavaScript, CSS, etc.) and Qt. Especially on resource-restricted systems like embedded systems and smartphones, Web is not a serious contender. It is far too resource hungry with respect to memory, speed and power. Consequently, the user experience is not at all iPhone-like. Yes, that is exactly the reason why the HTML5 apps of Facebook and Google Maps were replaced by native apps on iOS and why the Palm Pre failed so miserably.
This leaves Qt as the last man standing when it comes to technologies running everywhere with near-native performance. Qt runs on all desktop operating systems (Windows XP/7/8, Mac OS X, Linux), on all relevant mobile operating systems (iOS, Android, Blackberry, Windows Phone) and on most embedded operating systems (Linux Embedded, Windows Embedded, QNX, vxWorks, Nucleos, Integrity). And, it runs at near-native performance. Qt makes a much better trade-off between being cross-platform and running at native performance than Web.
Once developed, we can run our system on every relevant mobile, desktop and embedded operating system. This is in stark contrast with developing the system for every operating systems natively and separately – using different technologies on these systems. Qt will save us a lot of development and allows us to bring our products to the market faster.
Challenge 4: Fast Time-To-Market
Challenge Explained
Volkswagen has nine brands including VW, Audi, Seat, Skoda and Porsche. Every brand has many different models (Up, Polo, Golf, Passat, Tiguan, Caddy, etc.) for different categories (supermini, compact, family, premium, SUV, etc.). Volkswagen sells its cars in nearly every country of the world (150+ countries), which requires localisations to the special regulations and user requirements of these wishes.
That is a lot of complexity, Volkswagen and other car makers have to cope with. And, they have to release their cars to market in ever shorter cycles. When it comes to hardware like the car body, engine, power train, seats or dashboard, they have figured it out pretty well. They use the same parts in cars of different brands addressing similar market segments. In short, car makers use a platform concept.
When it comes to software like in-vehicle infotainment (IVI) systems, car makers have failed miserably. Different brands use different suppliers to build their IVI systems. Even worse, car makers use different suppliers for the same brand. Every time car makers changes their supplier, they change to a completely different IVI system. The situation is not much better with makers of home appliance or agricultural machines. What a waste of time and money!
Solution with Qt
What all these OEMs need, is a proper software platform! The platform must enable the OEMs to adapt their GUIs easily to the look, feel and behaviour of different brands, models, categories and countries. It must also enable them to run their system on different hardware platforms and operating systems. Essentially, the platform must enable the OEM to become independent of the supplier and change suppliers easily.
The platform provides APIs for functional areas like vehicle data, multimedia, radio, connectivity, navigation, window management, configuration management and diagnostics. These APIs constitute a software application layer, which makes the GUI of the IVI system independent of the actual software used for these areas. For example, the GUI doesn’t have to worry about, whether multimedia functionality is implemented with the GStreamer or Cinemo multimedia stack. On different hardware platforms, the multimedia API can even be implemented by different stacks.
Qt is ideally suited for this kind of abstraction, because it provides many of these APIs already like APIs for multimedia, connectivity and window management. Furthermore, Qt is all about cross-platform APIs that abstract away the actual implementations. If some APIs are missing in Qt, we can easily extend Qt. For our car OEM, we would provide a base SDK (software development kit), which serves as the base platform for all of its cars. There may be special SDKs, built on top of the base SDK, for different car categories or models.
These SDKs make it easy for the application developers to implement the HMI of the IVI system. These developers can work on their PCs and then try out their work on the actual hardware – right from the beginning of the project. Thanks to the SDKs, they don’t have to know on which platform they are running their software. Of course, the SDK also provides a library of standard widgets specific to the brand and the model.
This leaves us with the problem that the GUI of the IVI system must adapt easily to different brands, car models, car categories, countries, screen sizes and screen resolutions. Dealing with all these variants is where QML shines. As long as the layout of the GUI stays pretty much the same, we can handle this with themes (simple changes like colours, images, fonts, sounds, etc.). If the layout changes drastically, we must resort to skins, where we must rewrite parts of the GUI. In both cases, Qt’s file selectors will be of great help to manage all the different variants of the GUI.
Initially, the effort to build such a platform is higher than building just an IVI system. But the costs will quickly amortise – at the latest when the OEM changes a supplier or uses different suppliers for different brands. Personally, I know of three car OEMs that are building such platforms with Qt to be faster to the market. Unfortunately, they don’t want to be name at the moment.