My Talk “Qt vs. Web – Total Cost of Ownership” at Qt World Summit 2017

I am delighted that roughly 70 people attended my talk “Qt vs. Web – Total Cost of Ownership”. Thanks a lot for coming and for the great questions!

Here are the slides from my presentation.

In my talk, I explained why a Web solution for the HMI of an embedded system is significantly more expensive than a Qt solution. The short answer is: The Web solution requires a more powerful and more expensive system-on-chip (SoC) than the Qt solution. The SoC for Qt is 11 euros cheaper at a volume of one million units than the SoC for Web. The cost difference for the SoCs is a multiple of the cost of Qt Commercial. This makes your decision easy whether to use Qt or Web in your next project. Of course, it’s Qt.

Stay tuned for the whitepaper coming out soon on qt.io!

Pretty-Printing Output for QCOMPARE

We have created a custom class, say Person, and use it in a unit test.

void TestPerson::testEquality()
{
    Person p1("Alice", 42);
    Person p2("Bob", 37);
    QCOMPARE(p1, p2);
}

The unit test fails with this message.

FAIL!  : TestPerson::testEquality() Compared values are not the same
   Loc: [../QComparePrint/TestPerson.cpp(8)]

This message does not tell us how the two Person objects differ. We would like to see this message as we would see it for any type known to QCOMPARE.

FAIL!  : TestPerson::testEquality() Compared values are not the same
   Actual   (p1): "Person(Alice, 42)"
   Expected (p2): "Person(Bob, 37)"
   Loc: [../QComparePrint/TestPerson.cpp(16)]

How do we achieve such a pretty-printed output for QCOMPARE?
Continue reading

Passing Enum Properties between C++ and QML

We have defined a Qt property warningLevel in the C++ class MainModel:

    Q_PROPERTY(WarningLevel::Enum warningLevel READ warningLevel
               WRITE setWarningLevel NOTIFY warningLevelChanged)

We want to use this property in QML. For example, we want to colour a rectangle according to the warningLevel:

    import com.embeddeduse.models 1.0
    // ...

    property MainModel mainModel : MainModel {}

    Rectangle {
        color: toColor(mainModel.warningLevel)
        // ...
    }

    function toColor(level) {
        switch (level) {
        case WarningLevel.Error:
            return "red"
        case WarningLevel.Warning:
            return "orange"
        case WarningLevel.Info:
            return "green"
        case WarningLevel.Debug:
            return "purple"
        default:
            return "magenta"
        }
    }

Note how we access the C++ property mainModel.warningLevel from QML to set the color of the rectangle and how we use symbolic enum constants like WarningLevel.Info in the function toColor().

It is similarly easy to use a list of the symbolic enum constants as the model of a Repeater and to assign the warning level by the user to the property mainModel.warningLevel in the onReleased handler of a MouseArea.

    Repeater {
        model: [WarningLevel.Error, WarningLevel.Warning, WarningLevel.Info,
            WarningLevel.Debug]
        Rectangle {
            color: toColor(modelData)
            // ...
            MouseArea {
                anchors.fill: parent
                onReleased: mainModel.warningLevel = modelData
            }
        }
    }

I’ll show you in the rest of this post how to write your C++ code so that you can use a C++ property of enum type easily in QML.
Continue reading

GE Gave Up Building its Own Cloud

Reuters has a detailed article about a strategy shift in General Electric’s digital business. GE invested early and heavily into IoT. They want to connect every GE device with the cloud with their Industrial Cloud-Based Platform (PaaS) called Predix.

[GE] Engineers initially advised building data centers that would house the “Predix Cloud.” But after Amazon.com Inc and Microsoft Corp spent tens of billions of dollars on data centers for their cloud services, AWS and Azure, GE changed course.

However, GE could not compete with these investments and now rely on AWS and Azure instead of its own cloud services.

GE abandoned its go-it-alone cloud strategy a year ago. It now relies on AWS and expects to be using Azure by late October, four months behind schedule, the executives said.

This should be a warning to smaller companies who try to run their own cloud. It doesn’t seem to be well-invested money.

The Reuters article contains a second warning although a bit more hidden.

GE will now emphasize sales to existing customers in its energy, aviation and oil-and-gas businesses, and scale back efforts to sell to new customers in other sectors, three senior GE executives told Reuters.

Originally, GE followed a horizontal strategy, where it wanted to reach customers in all possible sectors. Now, GE changed to a vertical strategy, where it focuses on three core sectors. The lesson here is: What works well in one sector need not work well in another sector. Sectors are too different and require different solutions.

These two lessons also apply when you select a provider of cloud services. Be very careful if they offer you to host your cloud. This is simple if you only have a few dozens or hundreds of devices. It is a totally different story if you have thousands of devices – and growing quickly.

Also be careful, if they haven’t built a solution in your sector. If they have a good solution for fleet management, this doesn’t mean that they are good in processing the data coming from combined or forage harvesters. It is a totally different story.

Announcing My Talk “Qt vs. Web – Total Cost of Ownership” at Qt World Summit 2017

I am proud to announce that my talk “Qt vs. Web – Total Cost of Ownership” was accepted for Qt World Summit 2017. It is scheduled for Thursday, October 12, at 11:30 in the Business track.

I’ll show that Web applications require a considerably more powerful system-on-chip (SoC) than Qt applications to achieve a good user experience. However, a more powerful SoC is also much more expensive, as the following diagram shows.

Hope to see you in Berlin.

I’ll make the presentation slides available immediately after Qt World Summit.

CAN Standard Helps Attackers to Switch Off Brakes, Steering and Engine

Security researchers from TrendMicro and the Technical University of Milano explain in a blog post “The Crisis of Connected Cars: When Vulnerabilities Affect the CAN Standard” and a video how to switch off any electronic control unit (ECU) attached to the CAN bus. An attacker could switch off the brakes, engine or steering of your car. The researchers exploit a feature defined in the CAN standard. Every vehicle using CAN bus – so, basically every car, truck, harvester, tractor and construction machine – is open to the attack.

Let us assume that the attacker wants to switch off the brakes. If the attacker has local access to the vehicle, he only needs to attach a CAN device with a malicious version of the CAN stack to the CAN bus. It is as simple as connecting the two wires of the CAN device to the respective wires of the CAN bus anywhere in the vehicle. Such a CAN device costs not more than 15 Euros and the CAN stack software is freely available.

If the attacker only has remote access, he must hack into the infotainment system, the terminal or the telematics box of the vehicle. The famous jeep hack shows how to do this. It is much simpler for agricultural and construction vehicles than for cars, because security is often neglected. Once hacked, the CAN driver is replaced with a malicious version.

The malicious version of the CAN stack abuses a feature of the CAN standard to deal with bus contention. Whenever the ECU of the brake writes a frame to the CAN bus, the malicious CAN stack immediately sends a frame where a bit of the original frame is flipped. The brake recognises a bus contention and sends a highest-priority error frame to recall its original frame. This error frame tells the other bus participants to ignore the original frame. After the malicious stack has killed 32 frames from the brake in this way, the CAN bus takes the brake ECU from the bus. The brake is switched off.

A full fix for this security flaw would require a change of the CAN standard. This will take some time, probably a couple of years. There is no easy way to mitigate the risk of a local attack. This is especially a problem for tractors, harvesters and construction machines, which can easily be accessed locally. You can make a remote attack harder by signing the CAN stack cryptographically.

Farmpilot Could Have a Bright Future

Farmpilot is a software to help farmers and contract farmers with their daily logistic tasks. It helps with planning at which location drivers and vehicles have to be at a certain time. It also helps tracking the fuel consumption, distance and area of the vehicle on the field and road – ordered by field and by customer. Contract farmers use this information for invoicing the landowners and farmers for paying their employees.

Many farmers use farmpilot already. Two of the biggest sugar producers in Europe, Nordzucker and Südzucker, have mandated the use of farmpilot for harvesting sugar beets (see page 3 of this PDF). Of course, farmpilot sends its data to the cloud. And – Arvato, the company developing farmpilot, has the cloud infrastructure in place.

Probably every terminal in a tractor or harvester comes with a task or job management. The manufacturers of these terminals should replace their home-grown solutions by farmpilot and save the development effort. There are three ways how to do that.

First, the farmpilot application runs on a tablet and communicates with the terminal over (W)LAN. The tablet has a mobile Internet connection and synchronises its data with the farmpilot servers in the cloud. The terminal relays data like fuel consumption, distance, harvested area and GPS coordinates from the CAN busses to the farmpilot application on the tablet. The driver interacts with the application solely on the tablet. This is most likely what we will see soon in the sugar industry.

Second, the application is mirrored to the display of the machine’s terminal via VNC – similar to MirrorLink, Apple CarPlay and Android Auto for in-vehicle infotainment systems. The application still runs on the tablet or smartphone, but the user interacts through the terminal’s touch screen with it. This is more convenient for the driver, because the terminal is usually closer to the joystick and the steering wheel than the tablet.

Third, the farmpilot app runs on the terminal directly and communicates directly with the cloud servers. There is no need for an extra tablet or smartphone anymore. The app could use something similar to the AWS IoT Device SDK, which sends MQTT messages to the cloud and receives MQTT messages from the cloud in a secure way. Using a cross-platform GUI and application framework like Qt, Arvato could develop their app once and deploy it on all terminals, tablets, smartphones and PCs. This would be the best solution for the user and the solution with the least development effort.

This is not yet the bright future, but the necessary groundwork Arvato must do. In its current version, the farmpilot application relays a few CAN messages to the cloud. The infrastructure to forward every relevant CAN message from the engine, the harvesting header or the drive train to the cloud is in place. The farmpilot app is the gateway to all the data from the harvesters and tractors. Once this data is in the cloud, Arvato could run deep learning algorithms to find the right header or implement settings for an optimal yield or to detect machine defects early.

Now, this would be a bright future for farmpilot.

Proposed IoT Security Bill Could Be Boon to LGPLv3 Software

US senators proposed bipartisan (yes, it’s still possible!) legislation to improve cyber security of IoT devices, the Internet of Things Cyber Security Improvement Act of 2017. Vendors selling Internet-connected devices to the federal goverment must ensure that their devices are patchable, rely on standard network protocols, do not use hard-coded passwords, and do not contain any known security vulnerabilities.

Paragraph (C) on page 8 spells out that every contract between federal agencies and vendors must contain a

[…] clause that requires such Internet-connected device software or firmware component to be updated or replaced […] in a manner that allows for any future security vulnerability or defect in any part of the software to be patched in order to fix or remove a vulnerability or defect in the software or firmware component in a properly authenticated and secure manner.

Every software under LGPLv3 license would satisfy this patchability requirement by default. LGPLv3 requires that software under LGPLv3 can be replaced by a modified version of the software on this device.

The proposed bill falls short of requiring patchability for all Internet-connected devices, not just the ones sold to federal agencies. This would include smart home devices, toys, set-top boxes, TVs, cars and all other consumer devices.

Offshoring Becomes Too Expensive

After offshoring and near-shoring, there is a new outsourcing trend: domestic outsourcing. For example, a company in California outsources work to a company in Indiana or Wisconsin. A New York Times article sheds some light on the reasons for domestic outsourcing.

First, agile development rules.

But today, companies in every industry need mobile apps and appealing websites, which can be made smarter with data and constantly updated. That software is best created by small, nimble teams, working closely with businesses and customers — not shipped to programmers half a world away.

Second, “rising labor costs abroad also make domestic sourcing more attractive”.

A decade ago […] an American software developer cost five to seven times as much as an Indian developer. Now […] the gap has shrunk to two times. The standard billing rate for [the] engineers [of the US company Rural Sourcing] is $60 to $70 an hour, compared with $30 to $35 in India […]

I think that domestic sourcing is a bigger trend, where work moves to the people and not the people to the work.

Grimme ErgoDrive: Probably Not That Ergonomic

Grimme moves the HMI for changing the nominal values of the 80 most important harvesting parameters from the driver terminal(s) to an extra piece of hardware – called ErgoDrive. Four rotary knobs next to a small display enable the driver to change the nominal values of the 80 most important harvesting parameters.

As the driver looks at the display at a flat angle, he will probably have difficulties to see anything on the display. He must either memorise which of the four knobs does what or bent forward. Is this really more ergonomic and easier to use than showing the direct-access parameters on the terminal screen and changing them through a special rotary knob?

Another thing is clear: Moving software functionality into dedicated hardware is certainly more expensive or less economic for the customer.