Connectivity Solutions Will Not Help with Autonomous Farming

Over the last two years, agricultural OEMs have been in a rush to get data from their machines to their cloud servers. Claas uses Proemion’s connectivity solution. Agco, Grimme, Krone and a few others bet on AgriRouter running on SAP’s cloud servers. Holmer seems to favour Bosch’s IoT suite. All these solutions have one thing in common: They transfer little data, typically less than 50 data points per second. They top out at 100 data points. They are good for task or order management, asset tracking, fleet management, monitoring of machine health and remote diagnosis.

At least some of these companies seem to think that these connectivity solutions will help them with driver-less or autonomous farming like harvesting, seeding, spraying or fertilising. The wishful thinking would go like this.

The farm machines transfer data to the cloud. The data is used to train machine learning algorithms on extremely powerful compute servers. The model, the result of the learning process, automagically detects whether grains are dirty, maize leaves are dry or the heads of sugar beets are chopped off. Typically, this model runs in the cloud as well, because it requires more compute power than is available on the farm machine or because it adapts to new conditions and self-optimises by continuous learning. This is the way how voice assistants like Alexa and Siri understand spoken language or how medical software recognises cancer cells in MRT scans.

This approach does not work for farm machines. Here is why and what we can do about it.
Continue reading

Agritechnica 2017: What’s New for Terminals?

Agritechnica 2017 was my third visit after 2013 and 2015. My focus was on terminals (display computers) as usual.

The standard terminal of 2017 is powered by a quad-core NXP i.MX6 processor (32-bit ARM Cortex-A9 with ARMv7a architecture) and has an HD 12-inch multi-touch display (resolution: 1280×800, format: 16:10). The new ISOBUS terminal CCI 1200 manufactured by CrossControl is the prime example.

In 2013, there were only terminals with single-core Cortex-A8 processors (NXP i.MX53). In 2015, there was only the odd prototype terminal with a quad-core i.MX6 in 2015 (from Grammer Belgium) but no production-quality ones. In 2017, most terminals sport a quad-core i.MX6 (Cortex-A9) processor. The processing power of terminals increases very, very slowly.

Compare this to a typical processor used in today’s in-vehicle infotainment systems. For example, the Renesas R-Car M3 sports two Cortex-A57 and four Cortex-A53 cores (all 64-bit), which has the performance of low-end to mid-range desktop PCs. Agricultural terminals need this procesing power as well, if the agricultural industry is serious about autonomous seeding, spraying and harvesting.

CLAAS demonstrated a first step into this direction. A camera is trained on the crop flow. An image recognition software (most likely using machine learning) detects whether the grains are too dirty and whether there are foreign particles between the grains. The future will see more and more such software to deduce actions from sensor data.

These expensive computations must be performed onboard the machine, because the Internet connection is not good enough on the field to send the data to powerful servers and to perform the computations there. The most powerful computer on the machine is typically the terminal. Current terminals are not powerful enough for these computations.

One terminal stands out from the uniform, slightly boring bulk of 12-inch, 1280×800 and quad-core i.MX6 terminals: the PowerView 1200 from Murphy by Enovation Controls. It is powered by a dual-core Cortex-A15 and has a 12.3-inch multi-touch display with a resolution of 1280×480 (format: 8:3). The PowerView 1200 is well-suited for dashboards and can double up as a rearview mirror.

I’ll take a more detailed look at some terminals in the rest of this post. I will ignore quite a few terminals, because they don’t stand out in any way from the rest or I simply overlooked them.
Continue reading

New in Qt 5.10: Dynamic Language Change in QML

My favourite new feature in Qt 5.10 is the inconspicuous function QmlEngine::retranslate(). Finally, seven years after QML’s birth, there is a Qt way to change the language of your application at runtime. There is no need for workarounds any more (see How to do dynamic translation in QML for the standard workaround).

I wrote a simple application demonstrating the new feature. If we click the British (German) flag on the right-hand side, the language of the labels on the left-hand side is changed accordingly.

How does the dynamic language change work?
Continue reading

My Whitepaper “Qt or HTML5? A Million Dollar Question” on qt.io

You can download my whitepaper “Qt or HTML5? A Million Dollar Question” from qt.io. The Qt Company added fantastic infographics so that you can see the gist of the whitepaper in one glance.

The whitepaper explains how one of the world’s largest home appliance manufacturers could save millions by using Qt over Web technologies. […] At a volume of one million units, the SoC for Qt is 11 euros cheaper per unit than the SoC for Web – to achieve the same user experience.

Read the whitepaper to find out how you can save a lot of money in your own projects by using Qt instead of Web.

I’ll give a webinar on November 21, 2017, about the topic of the whitepaper. I am looking forward to your questions.

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!

You can find the video of my talk here.

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.