Burkhard on Qt Embedded Systems: No. 3

Welcome to Episode 3 of my newsletter on Qt Embedded Systems. I lead this episode with my thoughts about a better pricing model for Qt. What price would you be willing to pay for Qt and why? I am keen on learning your answers. You can simply respond to this email or the posts on LinkedIn and Twitter. Now enjoy reading about relocating Qt, technical debt, vertical integration of hardware and software, and more.

My Blog Posts

Less Love for FOSS Qt Users. Tightening the thumbscrews on LGPL Qt users seems to become a bit of a habit for The Qt Company. It started with moving from LGPLv2.1 to LGPLv3 with Qt 5.6. New Qt modules like Qt for Automation are not available under LGPLv3. The Application Manager has been discontinued for LGPLv3. The offline installer and the LTS versions are only available commercially from Qt 5.14. This is all perfectly legal with respect to the SLA between The KDE Free Qt Foundation and The Qt Company, although The Qt Company is testing the limits of this SLA.
The agenda is fairly obvious: Each turn of the thumbscrews means a little bit more effort for LGPL Qt users. In my post, I give you the concrete numbers for a typical Qt embedded project with three developers and 1000 units per year. Over five years, the costs for Qt Commercial are roughly 100,000€ and for Qt LGPLv3 25,000€. Now ask the Qt sales people why you should pay four times more for Qt Commercial and what your return on investment is. And - enjoy the answers ;)
The main problem is that The Qt Company offers only one pricing option for Qt. It's take it or leave it. I think that there should be three pricing options for Qt: 600€, 1,950€ and 4,950€ look pretty attractive to me. The different options would include different support levels, royalties and modules. The 600€ option is the no-frills option: no support, some royalties, one or two modules more than Qt LGPLv3 (e.g., Qt Virtual Keyboard, Qt MQTT) and the offline installer. The 1,950€ option has everything from the first option plus some support and some bigger modules like Qt Designer, Qt for Automation or Qt for Device Creation. The 4,950€ option is the current commercial Qt license for embedded systems.
These three pricing options cover 80-90% of the low-value and medium value projects. For the remaining 10-20% high-value projects, The Qt Company could offer productised services at a fixed price corresponding to the value they bring to this concrete project.

Benefits of a Relocatable Qt. By making Qt relocatable, The Qt Company makes building your own offline installer very easy. The installer relocates Qt from the build location to the installation location. The decision to make the offline installer commercial only (see the previous item Less Love For FOSS Qt Users) is nearly nullified. 
Bob builds Qt on a fast compute server running on Linux x86_64. He passes the Qt libraries to the development team. The developers use Linux x86_64 as well and install Qt in a different location than Bob. When the developers want to try their application on an embedded device running Linux x86_64 on an AMD Ryzen SoC, they install Qt in yet another location.
I describe in detail how to build Qt with Docker, how to relocate Qt twice and how to set the run-time link path in the CMake file correctly for the target embedded system. I am planning two follow-up posts. In the first post, I'll explain how to use CPack to package an application and the Qt libraries. In the second post, I'll show you how to build an offline installer. So, stay tuned.

News

Introducing WPEQt, a WPE API for Qt5. The library Qt5WebEngineCore has a formidable size of 106 MB. This is far too big for most embedded systems. As the startup time of an application is dominated by the size of the executable and the libraries, loading a 106 MB library easily adds a couple of seconds. If your system has 1 GB of RAM and runs multiple applications, you will soon have to add another GB of RAM. And don't even think of using the library on a system with less than 256 MB of RAM.
Ten years ago, the library QtWebKit was considered to be huge with 12-15 MB. Today, the WebKit port for embedded systems or WPE for short could be the white knight. WPE is specially optimised for less powerful embedded devices. It comes with a Qt integration called WPEQt. WPEQt provides the typical QML web components. It only runs with Qt's wayland-egl plugin on Linux systems. It has its own Yocto layer meta-webkit and works with the last three Yocto releases rocko, sumo and thud. I haven't had the time to try out WPEQt, but hope to do soon. WPEQt seems like a good alternative to Qt5WebEngineCore.

Learn More About iMX8 based product development and testing at ConExpo 2020 by CrossControl. CrossControl build high-quality display computers or terminals for agricultural, construction and heavy-duty machines. They are the manufacturers of the ISOBUS terminals, which you find in nearly every tractor and harvester. Their high-end models are currently powered by quad-core i.MX6 SoCs. The linked article shows that CrossControl are testing the much more powerful i.MX8 SoCs. I reckon that CrossControl will have i.MX8-based terminal prototypes ready for the 2020 harvest and they will have the product ready for the next Agritechnica 2021. I expect other terminal manufacturers to have a similar timeline.

Tesla teardown finds electronics 6 years ahead of Toyota and VW by Hideyoshi Kume. Tesla builds one very powerful integrated control unit called Hardware 3 in-house instead of sourcing many ECUs from external suppliers. Hardware 3 powers the self-driving capabilities and the infotainment system of the Tesla cars. This vertical integration of the software and hardware of many ECUs gives Tesla full control over the core functionality of its cars. Tesla turns the integration of multiple ECUs over a network into the integration of multiple processes on a single super ECU. It turns a hardware problem into a software problem. Tesla can easily update the software of Hardware 3 over the air. Tesla follows the playbook used by Apple to create the most successful product in history, the iPhone.
Manufacturers of agricultural and construction machines could benefit from Tesla's idea of a single super ECU. Harvesters, for example, contain many ECUs: up to four display computers; telematics gateways; ECUs for front implements, field navigation, drive train, engine and cameras; assistance systems for guiding tractors, for turning around, for detecting the maturity of crops and for weighing the harvested crops. Manufacturers like to put a hardware box for each ECU into their harvesters.
Like Tesla, these manufacturers could integrate many of the ECUs into a single super ECU powered by an NVIDIA Jetson, an NXP i.MX8 or an AMD Ryzen. Assistance systems fuse the information from multiple sources to come up with meaningful support. This becomes much easier, as all this information is in one place: on the super ECU. Manufacturers have full control over the software on the super ECU - no interfaces to multiple ECUs and multiple suppliers any more.
In the post What’s Wrong with Multiple Display Computers in Driver Cabins, I suggest to integrate two terminals, a telematics unit and an Ethernet switch into a single ECU with two displays. This little integration reduces the costs by 15-25%. Integrating more ECUs will reduce the costs even more and it will make things possible that were not possible or too costly before.

Volkswagen ID.3 reportedly suffering software problems. The fully electric ID.3 is VW's first car built on vw.OS. VW are facing massive software problems. They didn't even get the over-the-air (OTA) update working in time for the first batch of 10,000 cars. So, VW must update these 10,000 cars manually! Most likely, they'll have to update the second batch of 10,000 cars manually as well. 
VW's struggles show how important it is to have a bullet-proof OTA update working on the very first release. The OTA update enables you to deliver better software incrementally. This is what Tesla got right.

Reading

Questions to Ask: Software Architecture, Design, And Coding by Matthew Eshleman. Matthew compiled a list of questions that a development team should evaluate regularly over the lifetime of an embedded software project. He divided the questions in three sections: Architecture and System, Design and Coding. Here are some questions from my favourite section Architecture and System.

• Will this product be a one-off design or create the foundation for a family of related products?

• What other users might have an interest in the software and product requirements? Factory/Manufacturing? Calibration? Configuration? Serial Numbers? [...] Technical support? Internal QA? [...]

• How should the architecture support protecting [sensitive data]?

• Does the product require real-time responsiveness? Are those requirements enumerated and justified?

• Will the product operate 24x7?

• What open-source software will be included and how will the software architecture ensure license requirements are respected?

Is High Quality Software Worth the Cost? by Martin Fowler. In a recent project, I noticed that my actual efforts were roughly three times higher than my estimates - for most stories. The code was very hard to understand. Any change caused the code to break at unrelated places. I found new issues faster than I could solve them. The development team had accrued considerable technical debt or cruft in the code base for more than two years. It had traded lower code quality for higher implementation speed. At least, that's what they thought. 
The reality is that they had to delay their first release by at least half a year and had to pay for an expensive consultant to help them. Improving the code quality will take considerabe time and money over the next months. If the team had ensured high code quality right from the beginning, they would have saved almost all of the extra costs. Software development is one of the rare cases, where higher quality means lower costs. This is also the conclusion Martin reaches in his article. When you argue in favour of higher code quality the next time, use the argument to which every manager will give in: lower cost!

Don't buy into the Technical Debt Illusion by Michaela Greiler. There are two kinds of technical debt. Teams take on deliberate technical debt despite knowing better. The classical example is that teams take shortcuts under schedule pressure in the hope to pay back the debt later. Teams take on inadvertent technical debt, because underlying technology changes or they understand their software better over time. Michaela introduces the term technical inflation for this kind of debt. Inflation makes it clear that teams don't have much influence on this debt and that it is a big debt.
Michaela warns that the "real danger of technical debt lies in its compounding effects". For technical debt, you pay interest on interest, which leads to exponential growth of your debt. Michaela's conclusion is to avoid deliberate debt by all means and to reduce the inadvertent debt regularly. Fighting technical inflation happens in a pragmatic way. You always leave the code in better quality than you found it.

17 Theses on Software Estimation (Expanded) by Steve McConnell. Steve is the author of the books Software Estimation and Code Complete. His company Construx teaches software estimation. In the linked article, Steve takes on the the #NoEstimates movement. His main point is that "being able to estimate effectively is a skill that any true software professional [must and can] develop" (thesis #4). This got me reflecting about my own estimation skills and about what helps me come up with good estimates.
My estimates are pretty good, if I try to implement a story for 15-30 minutes. This is much more about reading code than writing anything. I find out, with which classes, processes and devices the story collaborates and how difficult receiving information from or sending information to these collaborators is. I also get a feeling how easily I can change the code. This understanding is a good foundation to break up a big story into several smaller stories. The smaller the story the easier it is to estimate.

Events

QtDay 2020 in Florence, Italy, postponed to November 20-21. QtDay was originally scheduled for March 13-14. Due to the outbreak of the Corona virus in Northern Italy, Qt Day is postponed to November 20-21. I will be there to give my talk A Deep Dive into Controller Area Networks with Qt. As a speaker, I have two free tickets for attending the talks on the second day (Qt labs and the social event on the first day not included) and get a 30% discount on full tickets. Who is interested?

Live-via-the-web courses Test-Driven Development for C/C++ by James Grenning on March 10-12 and March 24-26. This is your chance to learn a new superpower. When I took the course last year, I understood that TDD helps me to cut through complexity. When I implement a feature, I have many things to consider at any point. Sometimes I am a bit paralysed what to do next. TDD takes me by the hand and lets me make small and safe steps. TDD keeps me moving forward at a steady pace. If I am lost, some nice ZOMBIES will help me out.

Embedded Online Conference on May 20, 2020. The people from EmbeddedRelated.com organise an online conference about programming and security of embedded systems, machine learning, DSPs and FPGAs. You will learn how to bring up Linux on custom boards, how to develop real-time applications on heterogeneous SoCs, how to use TDD for layering firmware, how to secure IoT from chip to cloud and a lot more. If you sign up today (February 29), the conference is for free. It will cost 90 USD in March and go up to 190 USD in April. The best: You can attend the conference from your comfy chair at home.