Episode 10: Burkhard on Qt Embedded Systems
Welcome to Episode 10 of my newsletter on Qt Embedded Systems!
The newsletter goes out to more than 200 people for the very first, actually more than 215. Your amazing interest keeps me going. Thank you so much 🙏🙏🙏
The centre piece of this newsletter is my take on the Gartner study Hype Cycle for Embedded Software and Systems, 2020. The study looks at the impact of 24 technologies on the internet of things (IoT). I assess 12 of them from the point of Qt embedded systems. Please hit the Reply button to this email and let me know your assessment of these technologies.
Enjoy reading and stay safe - Burkhard 💜
My Blog Posts
Breaking Dependency Cycles in Qt Applications
A fairly common anti-pattern found in Qt applications is to derive a class MyApplication from QApplication and to have it hand out pointers to a dozen or more major components of the application. Similar to Qt's qApp macro, these applications introduce a macro myApp pointing to the single MyApplication object.
The global variable myApp makes it too easy to access the major components stored in MyApplication from everywhere. This is a recipe for disaster: for spaghetti code with dependency cycles galore. I'll use several methods to eliminate these dependency cycles: pushing dependencies into Qt libraries, dependency injection and loose coupling with signal-slot connections.
My Thoughts on the Gartner Study: Hype Cycle for Embedded Software and Systems, 2020
Overview
In return for your email address, you can download the Gartner study from here - with compliments of The Qt Company. The study is available for limited time only. I'll give you a summary of the technologies with the most impact on Qt embedded systems.
The Hype Cycle is a 2D diagram branded by Gartner to visualise the maturity of emerging technologies. The horizontal axis is divided into the five key phases of a Hype Cycle - from left to right: innovation trigger, peak of inflated expectations, trough of disillusionment, slope fo enlightenment and plateau of productivity. The vertical axis shows the visibility of technologies. The larger the hype around a technology the higher the visibility.
The trigger for the Hype Cycle in this study is the Internet of Things (IoT). Gartner has identified 24 technologies influencing the IoT Hype Cycle. It places these technologies on the Hype Cycle as follows:
On the rise (innovation trigger): Smart Dust.
At the peak (peak of inflated expectations): Edge Networking, Embedded AI, Edge AI, OMA SpecWorks LightweightM2M, RISC-V, CoAP
Sliding into the trough (trough of disillusionment): Digital Twin, Embedded Software and Security, Micro-OS (IoT), Wi-Fi 6 (802.11ax), Arduino, IoT Edge Architecture, oneM2M, Bluetooth 5.1, Low-Cost Development Boards, MicroPython
Climbing the slope (slope fo enlightenment): Embedded Hypervisor, Sensor Fusion, IPv6, MQTT, Data Distribution Service, AMQP, IoT Integration
Off the cycle (plateau of productivity): None
Gartner ranks the technologies by business impact and when they will reach mainstream adoption.
Transformational impact
< 2 ys: Embedded Hypervisor
2-5 ys: Digtial Twin, Edge AI
> 10 ys: Smart Dust
High impact:
< 2 ys: Arduino, Bluetooth 5.1, IoT Integration
2-5 ys: Embedded AI, Embedded Software and Security, IoT Edge Architecture, Sensor Fusion, Wi-Fi 6
Moderate impact:
< 2 ys: Low-Cost Development Boards, MQTT
2-5 ys: CoAP, Data Distribution Service, MicroPython, OMA SpecWorks LightweightM2M, oneM2M, RISC-V
5-10 ys: Edge Networking, Micro-OS (IoT)
Low impact:
5-10 ys: IPv6
Gartner evaluates the impact of these technologies on embedded systems in general. I'll focus on Qt embedded systems guided by these questions:
How do these technologies shape the architecture of Qt embedded systems?
How does Qt support these technologies already?
How could Qt support these technologies better in the future?
At the Peak
Edge Networking
The study classifies edge devices into WAN-connected devices and on-premises (LAN-connected) devices. WAN-connected devices (e.g., telematics units, sensor gateways, phones) use LTE, LPWAN and satellite to connect to the cloud. On-premises devices (e.g., packaging machines, CNC machines, robots) connect to the cloud via Ethernet, Wi-Fi and industrial automation protocols.
According to Gartner, 5G and NB-IoT will tear down the divide between WAN-connected and on-premises devices. WAN-connected and on-premises devices could then use the same communications infrastructure.
Many on-premises machines in small and medium businesses are not connected to the Internet yet. Updating the machine software is done with USB drives or not at all. Transferring data from one machine to another machine or to the office PC is also done with USB drives. As these machines easily cost 50K Euros and more, it should be a no-brainer to put in a 5G modem with a modest data plan. So, 5G and NB-IoT could really help to connect millions of machines to the Internet.
Embedded AI
Embedded AI runs deep neural networks (DNNs) on microcontrollers (MCUs) to analyse data locally on the device. The device need not transfer data to a server in the cloud, which performs the analysis and sends back the result. This reduces the latency and allows the device to work properly even when not connected to the cloud.
The classic example is predictive maintenance (see my post on Running Neural Networks on MicroControllers). Future examples comprise "dynamic and real-time optimization of manufacturing lines to incoming orders and workloads" and "intelligent buildings that optimize employee productivity". The second example reminds of findings in the 80s that cows produce significantly more milk when they listen to Mozart - compared to no music or Heavy Metal. I certainly don't want to be treated like cows.
All major MCU vendors have tool chains to convert inference models, say, from TensorFlow into the vendor-specific format best suited for the given MCU. The tinyML Foundation coordinates and drives these efforts. The latest MCUs (e.g., Cortex-M55) sport dedicated blocks to speed up running DNNs. ARM designed the Helium technology for this purpose.
Qt for MCU helps to visualise the results from the DNNs in the HMI. Qt may be able to use the Helium hardware for graphics acceleration.
Edge AI
Where Embedded AI brings DNN-based inference to microcontrollers, Edge AI brings it to microprocessors. The prime example is Tesla's super-ECU HW3 that fuses the sensor data for semi-autonomous driving and which runs the Qt-based infotainment system (see the story in of my newsletter). Claas uses DNNs in its combine harvesters to detect dirt particles among the grains (see video CEMOS AUTO THRESHING). John Deere uses DNN-based computer vision in its sprayers to discriminate between weeds and plants (see Episode 9 of my newsletter).
Edge AI systems typically run on very powerful SoCs like the NVIDIA Jetson Xavier or the NXP i.MX8 QuadMax. These SoCs have dedicated processor cores to speed up inference on DNNs. The NVIDIA SoCs benefit from the GPU architecture, which is used on NVIDIA graphic cards to train the DNNs. Tesla designs the HW3 itself. I would expect NXP, Renesas, AMD and other SoC vendors to design their own AI accelerator chips as well. They won't leave the market to NVIDIA or the likes of Tesla.
The APIs to run DNNs are predominantly written in Python. The C/C++ implementations lag behind the Python ones. Qt for Python should make it easy for Qt HMIs to communicate with the Python APIs of the inference models.
Gartner foresees that Edge AI systems will perform online learning in the near future. They will optimise their inference models while running.
RISC-V
RISC-V is a free and open-source instruction-set architecture (ISA). Vendors can use the RISC-V ISA in their chip designs without paying any licensing fees. This is in stark contrast to the current situation, where chip vendors like NXP, TI, Renesas and STM pay hefty license fees to use ARM's instruction-set architectures and chip designs.
With NVIDIA buying ARM, I'd expect chip vendors to release considerably more chips designed in-house and based on RISC-V. Otherwise, they would fund their competitor NVIDIA through the license fees paid to ARM. The chip vendors will probably replace their Cortex-M and Cortex-R SoCs first. The Cortex-A SoCs will follow later.
Qt runs on Intel, ARM, MIPS, PowerPC and SH3 chips. So, it's just a matter of user demand when Qt will be ported to RISC-V.
Constrained Application Protocol (CoAP)
CoAP is a simple, lightweight and multicast protocol for communication between resource-constrained devices. It typical runs over UDP. It uses a client-server architecture similar to HTTP. Hence, CoAP is well-suited for embedded systems with microcontrollers.
Qt implements CoAP in its Qt CoAP module. If you use Qt for the HMI on an MCU, Qt CoAP could be a natural option for the communication.
Sliding into the Trough
Micro-OS (IoT)
A Micro-OS is a real-time operating system (RTOS) running on low-end, low-cost and low-power devices. The memory footprint is measure in kilo bytes. Gartner gives the ESP32 SoCs from Espressif as examples for running a Micro-OS. These SoCs integrat a 32-bit microcontroller and a 2.4 GHz Wi-Fi chip on the same silicon for 6 USD at volumes of less than 10 units. Espressif offers Azure IoT and GoogleCloud IoT kits.
Amazon uses FreeRTOS for its IoT devices like the Echo. FreeRTOs is owned by Amazon. FreeRTOS is Gartner's prime example for a Micro-OS.
Qt for MCU is a bit too fat for devices with such a tiny memory footprint. Nevertheless, I want to mention that Qt for MCU runs on FreeRTOS. The tech preview for Qt on FreeRTOS is available. For more powerful devices, Qt provides the reusable modules like Qt Quick for the HMI or Qt CoAP, Qt MQTT, Qt CAN and Qt SerialPort for communication. Qt would enable rapid development of an embedded system on FreeRTOS and hence fast time to market.
Arduino
Gartner describes the benefit of Arduino as follows: "Arduino is focused on gathering data from sensors and triggering actuators, making it ideal for IoT development and proof of concept. [...] the speed of development is unmatched, and the simplicity of the sketch syntax is such that any competent software developer can start developing in a matter of hours." - I don't need to add anything.
Bluetooth 5.1
Bluetooth 5.1 adds angle of arrival and angle of departure, which benefits the accuracy of locating and tracking devices. The German Corona warn app would benefit from Bluetooth 5.1, but Bluetooth 5.1 is too new for most phones. Beacons will benefit from the improved location accuracy.
Whether Qt supports Bluetooth 5.1 depends on the BlueZ version provided by the Linux version used on your embedded Linux system. Qt forwards most of the capabilities of BlueZ. If not, you can extend Qt Bluetooth.
MicroPython
MicroPython implements a subset of Python 3 that is optimised to run on microcontrollers. Gartner sees MicroPython as a replacement for C, as it "enables rapid development of embedded applications", reduces development costs and time to market. Python has become very popular, because it is the language of deep learning frameworks and because it is used in education. So, many developers have Python programming skills.
The Qt Company may want to think about downsizing Qt for Python to Qt for MicroPython. Then, developers could use MicroPython for commmunication with sensors and actuators as well as for communicating with users. They could use MicroPython to build a complete embedded system.
Climbing the Slope
Embedded Hypervisor
Embedded hypervisors provide "a software virtualization layer that allows multiple OSs or execution environments to run simultaneously on an embedded processor. [They] support the real-time operation and security requirements of many embedded systems."
Hypervisors can be found in the Super-ECUs or silverboxes of cars (see Edge AI above for Tesla's Super-ECU). They separate the safe world communicating with the brakes or the steering from the unsafe world of the infotainment system. They should also block hackers from accessing safety-critical functions remotely.
As hypervisors are highly complex pieces of technology, they are only offered by big well-known vendors like QNX, Green Hills, Siemens Mentor, SYSGO or Wind River. Hypervisors are certainly good money for these vendors. I am wondering, whether they are also good value for the customers of these vendors.
I think that Gartner should have looked at ARM TrustZone as an alternative to embedded hypervisors. TrustZone offers hardware-enforced isolation of operating systems running on different cores. TrustZone is available for ARMv7-A, ARMv8-A and ARMv8-M designs, which includes the NXP i.MX6 and i.MX8. TrustZone would be found earlier in the Hype Cycle than embedded hypervisors.
For example, the control for a high-speed label printer could run in a trusted execution environment on FreeRTOS and a Cortex-M core, whereas the HMI of the printer runs in the untrusted world on Linux and a Cortex-A core. The peripherals are also assigned either to the trusted world or to the untrusted world.
IPv6
I was a bit surprised to read that "nearly 30% of users accessing Google do so using IPv6" and that "nearly 30% of all websites (by traffic volumes) have already enabled IPv6". I would replace "nearly" by "only". 30% is not much.
Enterprises seem to have enough IPv4 addresses for their public services. Internally, they can use IPv4 addresses anyway. They can use the same trick for deploying IoT devices. I have seen this approach for fleets of agricultural and consturction machines.
Gartner advices to support IPv4 and IPv6 for "new greenfield networks" of IoT devices at least for the next five years. QtNetwork already follows Gartner's advice.
MQTT
MQTT open, lightweight and publish-subscribe network protocol "designed for machine-to-machine (M2M) communications for use with constrained networks". It typically works over TCP/IP. So, it is ideally suited for embedded IoT endpoints sending and receiving data from the cloud. As "MQTT has matured to [...] one of the major standars in IoT", all relevant IoT cloud platforms support MQTT.
The Qt MQTT module provides its own implementation of MQTT 3.1, 3.1.1 and 5.0. Hence, Qt MQTT is available under commercial license and GPLv3, but not under LGPLv3.
The Eclipse Mosquitto project offers an MQTT client written in C. The Mosquitto client comes under version 1.0 of the EPL/EDL license. As the Ecliplse Public License 1.0 (EPL) is not compatible with the (L)GPL, you cannot simply write a Qt wrapper around the client and publish the combined work under LGPLv3. Currently, I don't know a good MQTT client that is written in C or C++ and that can be combined with Qt LGPLv3.
Reading
What does the Nvidia deal for ARM mean for the internet of things? by Stacey Higginbotham
Originally, I wanted to write the "My Thoughts" section about NVIDIA's acquisition of ARM. Then, I stumbled over the Gartner Hype Cycle for Embedded Systems and decided to cover that in detail. Stacey's article comes closest to my thinking, as she looks at the acquisition from the IoT angle. The central question is: How will NVIDIA's acquisition of ARM change the market of embedded SoCs?
According to Stacey, NVIDIA's main reason to buy ARM is to compete with Intel in the data center. NVIDIA has an entrance ticket to the data center with its GPUs for machine learning. If NVIDIA combines its GPUs with the low-power ARM CPUs, it could become a serious competitor for Intel.
NVIDIA best opportunity in the internet of things is "at the edge. Not at the sensor level, where ARM-designed microcontrollers have a lot of market share, but inside the gateways and other edge-computing devices where customers are asking for data analytics and real-time decision-making. Nvidia has a foothold in a small portion of this market with its Jetson AI products."
So, NVIDIA's edge AI chips will compete heads-on with the high-end edge AI chips of other manufacturers (e.g., NXP's i.MX8). The big unknown is how far down NVIDIA wants to push. It's probably safe to assume that they won't get into the Cortex-M market any time soon. The mid-level and low-level Cortex-A SoCs (e.g., i.MX6, i.MX7, low-end i.MX8) may probably be safe for another five years, but most likely not forever.
Qualcomm, NXP, TI, STM, Microchip and the other manufacturers will start wondering why they fund their competitor NVIDIA through the license fees paid to ARM. Stacey closes by saying that "the deal and potential upset could lead to a boost for the up-and-coming open-source RISC-V architecture that many chip companies are currently experimenting with as a way to reduce their reliance on ARM and its license fees." I agree. And, the RISC-V push will start with microcontrollers and then SoCs competing with the Cortex-A SoCs. From there, it will work its way up.
It's hard to make any forecasts. And, the deal can still fall flat, as it needs regulatory approval from China, the UK, the EU and other countries. I'd expect that China will put up a good fight, because they don't want to see ARM in the hands of their arch enemy, a US company. China already has troubles to source up-to-date chips for their smartphones and other embedded devices.
The Cost of Rework Avoidance Theory by GeePaw Hill.
The core idea of Rework Avoidance Theory or RAT, for short, is that "changing a thing is waste". RAT followers accumulate high costs, because they avoid change like the plague.
They add "feature after feature after feature" to the requirements specification - without any prioritisation. All features are mandatory in the final product. Time-to-market is far longer than ever imagined.
Developers and all other people involved do a lot of gold-plating. "Unneeded generality and predicted later need" lead to more complex code, "a lack of understanding and confidence, [...] slower development and defect-laden releases".
As the cost for changes are very high, developers try to build the perfect product. Building just a part of the product (e.g., the minimum viable product) to receive feedback is not an option. Every change becomes a fight.
Management divides the work into pieces, which are handled by different teams or even individuals. The coordination efforts go through the roof. Whether the different pieces work together is validated far too late.
Management buys pieces of the product from external vendors. This exacerbates the previous problem. Management loses control over software development. It is at the mercy of the external vendor to get bug fix or new features.
The five points above are warning signs that you are on a death-march project. "The cost of fearing [change] isn’t just based in the simple truth that change comes whether we like it or not. It brings that cost with it everywhere, whether change happens or it doesn’t. [...] Understanding the concrete and very high cost of RAT is essential to considering an alternative."
The alternative to RAT is to embrace change, which is the core idea of XP (see Kent Beck's seminal book eXtreme Programming explained: Embrace Change (Amazon)). GeePaw describes what embracing changes means in his posts about Change Harvesting.
In my experience, the number one enabler to make people embrace change is TDD (test-driven development). TDD gives people the safety net, the understanding and the confidence for making changes. People get immediate feedback from tests whether a change is good or bad. It's important that all people on a team embrace change. If some people follow rework avoidance and others change harvesting, you'll have a lot of friction in the team.
Trunk-based Development vs. Git Flow by Konrad Gadzinowski (Toptal)
Konrad compares the two predominant ways how development teams use git in their daily work.
Git Flow. When developers start to implement a new feature, they create a new branch. They work in this branch until they are finished with the feature. Then, they create a pull request, which is reviewed by other developers and ends up in the main branch after some iterations.
Trunk-Based Development. All developers work on the main branch. They may commit a few changes locally before they push them to the main branch. They typically push every change directly to the shared repository.
Konrad advises you to use Git Flow,
"when you run an open-source project",
"when you have a lot of junior developers" or
"when you have an established project".
He advises you to use Trunk-Based Development mostly for the opposite reasons, when
"when you need to iterate quickly",
"when you work mostly with senior developers" or
"when you are just starting up".
I disagree!!!
For Konrad, Git Flow is all about controlling change.
"You want to be able to check every single line of code, because frankly you can't trust people contributing."
People who accept pull requests have strict control over recurring changes so they can prevent deteriorating code quality."
"[Enterprises] need to control every change closely, since they don't want to break their multi-million dollar investments."
In short, Konrad is afraid of change. You cannot control change. However, you can waste a lot of time and money trying to control change, as GeePaw Hill explains in his Rework Avoidance Theory (see the previous entry). Git Flow is neither the remedy nor the reason for these costs.
Similarly, Trunk-Based Development won't magically enable you to iterate more quickly. You will only iterate more quickly, if you integrate smaller changes more frequently. You can do this equally well with Trunk-Based Development or Git Flow - as Martin Fowler points out in Comparing Feature Branching and Continuous Integration.
You can integrate smaller changes more frequently, if you make changing code easy and safe. And you do that by using TDD right from the beginning. TDD works for both junior and senior developers and for both established enterprises and start-ups. If your team uses TDD and has a culture of supporting each other, your project will be a success - no matter whether you use Git Flow or Trunk-Based Development.
Building the Perfect Testimonial by Jonathan Stark
As a solo consultant, it's important for me to get testimonials, references or succes stories from my customers.They make it a lot easier to land the next project. My contracts of contain a clause that grants me marketing rights. When customers ask me for a discount, I give a discount in exchange for marketing rights.
Jonathan describes a two-step "process" how to receive great testimonials. First, you write an email whether the customer would be fine with answering a few questions for a testimonial. You do not pose the questions yet. Second, if the customer says yes, you send another email with the questions. Jonathan presents six questions, which you can reuse for your email. Here are my three favourite questions:
What was the obstacle that would have prevented you from buying this product/service?
What specific feature did you like most about this product/service?
Would you recommend this product/service? If so, why?
The answers are relevant for your marketing and even more so for your positioning.You may see yourself as a technical expert, say, in developing Qt applications for embedded systems. The customers value most that you enabled them to build the Qt applications for controlling their machines on their own for the first time. You enabled them to have their fate in their own hands from now on. That's worth a lot more than all your technical expertise.