The Specialist in Smart HMIs for Industrial Machinery
Smart human-machine interfaces (HMIs) translate the actions of human operators into the instructions for machines. They simplify and automate the human-machine interaction so that operators become more productive, perform fewer routine tasks and come up with new solutions. I am on a mission to give smart machines the smart HMIs they deserve.
My marquee products are the operator terminals for sugar-beet harvesters, forage harvesters, excavators, metal-sheet bending machines, UV cleaning robots and professional cooking appliances as well as infotainment systems for cars and e-bikes. Although no industrial machines, infotainment systems share the same architecture and communication (CAN) as agricultural and construction machines.
Enabling Teams to Write Better Software Faster
My role in these projects is that of an enabler - true to this well-known proverb: "Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime."
I enable embedded software development teams to become self-dependent and high-performing, while making me superfluous.
Burkhard Stubert
I prefer providing technical guidance to my clients' development teams over doing the implementation work. This makes the teams write better software faster on their own. Here are some examples.
- Building new systems. A team lacks the experience to develop an operator terminal (the HMI), because the company has never done it before or because the team doesn't know the technology stack (e.g., QML, Qt, C++, Yocto, Linux, MQTT, J1939, iMX8M). I help the company hire developers, select the hardware, bring them up to speed mainly by pair programming and test-driven development (TDD), build a walking skeleton of the architecture and develop the complicated parts of the system.
- Improving legacy systems. Over the last years, an organisation turned its embedded systems into a Big Ball of Mud. Some teams are overwhelmed by bugs. There are hardly any tests. Some teams depend heavily on other teams. The teams blame each other. Decisions take months and end in poor compromises. After a thorough diagnosis of the situation, I'd most likely recommend a different team structure and the introduction of continuous delivery (CD) practices with a special focus on test-driven development (TDD), continuous integration (CI) and a loosely coupled architecture. Of course, I can help implement the recommendations.
- Making technology choices. The operator terminal supervises a cleaning robot in another room over a wireless connection. The customer doesn't know whether to use WiFi, Bluetooth or LoRa. I can develop a prototype and evaluate which technology is best suited in this context.
Burkhard was the safe haven for our inexperienced development team. He always knew what to do next.
Michael Gruber, Head of Sugar-Beet Business Unit, ROPA Maschinenbau GmbH
Custom Services
The example projects for enabling teams - building new systems, improving legacy systems and making technology choices - are custom services. Custom services have one thing in common: a lot of uncertainty and risk. Businesses don't know how long the development of the new system takes, where the pitfalls hide, how to pull themselves out of the mud or which technology is best suited for their use case. These businesses don't have the expertise in-house to mitigate the risks. That's where I come in.
Diagnostic
Before jumping on a custom project, I perform a thorough diagnostic of my client's situation. In close collaboration with the client, I can, for example,
- define a minimum viable product (MVP) and a rough release plan,
- analyse the team structure and software development process of the client's organisation,
- review the architecture for a legacy system or create one for a new system.
The diagnostic results in my recommendation how to reduce the clients' risks. It takes some of the uncertainty out of the project. The diagnostic enables me to take over some of the risks. Without a diagnostic, the project risks will mostly be with the client.
Three-Option Proposal
At this point, the client and I decide whether to go separate ways or whether to continue with the custom project. If both parties agree on a further cooperation, I'll typically provide a three-option proposal (Silver, Gold and Platinum) based on the diagnostic. Each option has a price tag.
The Silver option describes what clients get for their budget. It has the highest risk for the client and the lowest for me. For the Platinum option it is the other way round: lowest risk for the client and highest risk for me. The higher the client's return on investment and my risk are the higher the price is. That's only fair.
Without a diagnostic, I'd most likely bill clients by the hour. With a diagnostic, I can offer a much wider spectrum of pricing options. For example:
- The three options correspond to three phases to build the MVP. Platinum covers the full MVP. The phases are defined by scope.
I'd price each option at a fixed fee. When I finish the Platinum option by a certain date, the client pays a bonus. Smaller bonuses are possible for the Silver and Gold options. - Building a new system. Silver: Walking skeleton for top-5 architecturally significant requirements. Gold: Silver plus technical guidance but no implementation. Platinum: Gold plus implementation of a complicated subsystem (e.g., machine communication, image recognition).
The Silver option would have a fixed price. For the Gold option, I could offer a fixed number of 4-hour blocks per month or a fixed number of support requests per month. The fixed price of the complicated subsystem in the Platinum option would depend on the usage rights for the client: exclusive forever, exclusive for two years or shared with me. The less exclusivity for the client the more I invest in the complicated subsystem. - Improving a legacy system according to quality metrics. The objective for each option is to reach a certain quality level in a certain time range.
The client pays a fixed fee per month. If I reach the objective for an option, the client pays me a bonus.
Productised Services
In contrast to custom services, productised services are clearly defined and hold hardly any risk. I have successfully performed these services many times. Therefore, a diagnostic is not needed. When a client contacts me about a productised service, I respond with a three-option proposal and a meeting suggestion. In the meeting, the client and I determine the option and the start and end date of the project. I send the contract. The client signs it. The project can start. It's that easy!
Checking License Compliance
These day, many embedded systems run on Linux custom-built with Yocto or Buildroot and use Qt for their HMIs. The makers must check that every package on the system (consisting of libraries, tools and files) complies with its licenses. A medium-sized Linux system can easily have 400 package with 80 different licenses (e.g., LGPLv3, GPLv2, MIT, BSD-2, BSD-3, MPL, Apache-2.0, EPL).
The situation is further complicated by the question whether the company can use Qt under LGPLv3 or whether it must buy a Qt for Device Creation license (Professional or Enterprise) for good money. My talk Using Qt under LGPLv3 and my post Using Qt 5.15 and Qt 6 under LGPLv3 are the standard introduction to license compliance.
My proposal has the following three options:
- Option 1. I educate clients about the obligations of permissive licenses (e.g., MIT, BSD), weak copyleft licenses (e.g., LGPL) and copyleft licenses (e.g., GPL). I guide clients through the decision whether to use Qt LGPLv3 or Qt Commercial in their project.
- Option 2. I check that all the packages in the clients' embedded Linux system comply with their licenses. The report lists all packages with problematic licenses. Clients receive a compliance archive with all the license texts and source files that they must pass to the end user. They also receive a license checker and a license database so that they can update the compliance check for the next release.
- Option 3. I train my clients' staff how to perform the license compliance check on their own. With the information and tools from Options 1 and 2, they can do this in less than half a day for every release of their embedded Linux system.
More Coming Soon
I am planning to introduce more productised services. A concrete request may be just the trigger I need. I have a couple of ideas.
My most refined idea is to build custom embedded Linux images and SDKs with Yocto. Clients can start developing their main Qt applications right away - without the heavy overhead of learning Yocto. I have done that for terminals and boards from Christ Electronics, Topcon, Seco, Toradex, Boundary Devices and others based on NXP, Texas Instruments, Raspberry Pi, AMD and Intel SoCs. The basic Linux system can be extended in many ways: windows and application manager, VNC viewer, OTA update, fast boot in less than 5 seconds, secure boot, communication between Cortex-A and Cortex-M processors on hybrid SoCs like iMX8 and iMX7.
Another less refined idea is to set up a CI/CD pipeline with GitHub Actions and CTest/CDash. The Silver option would implement the Commit Stage (running unit and integration tests on the build server). The Gold option would implement the Acceptance Stage (running acceptance tests on the embedded device). The Platinum option could add more checks to the pipeline or optimise the runtime of the pipeline stages.