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.

More Reasons For Not Using Web

The Qt Company published a guest post “Qt QML v HTML5 – a practical comparison” and a whitepaper by the Austrian Qt consultancy Sequality. Sequality had one developer writing a simplified application for controlling a bottling plant first with Qt and then with Web (AngularJS). The developer had 160 hours for each implementation. The application had to run on a tablet, a PC and a Raspberry Pi 3 with different resolutions.

Here are my favourite findings of Sequality’s experiment.

  • The developer finished considerably more functionality with QML than with Web.
  • Higher efforts to use OpenGL acceleration for Web: “Enabling GPU rendering on Chromium […] doesn’t fix the HTML5 demo’s performance problem. In fact, the CPU is utilized even more, which leads to overheating.”
  • Higher efforts for testing Web: “The fact that HTML5 applications can be executed on a number of platforms – and a number of browser engines on each platform – multiplies the testing time correspondingly.”
  • Availability of a certain Web technology in 10 years: “Modern HTML5-based applications that use frameworks like AngularJS are relatively new and undergo changes from year to year – a valid question is whether AngularJS (or any other currently trendy Javascript-library) will still be a relevant HTML5-technology in 10 years.”

Writing Apps for GM Cars

Just three years ago, this would have been unthinkable. GM publishes an SDK (NGI SDK) to write apps for the infotainment systems of its cars and an app (GM Dev Client) to run the app in the car.

General Motors has launched GM Dev Client, an industry-first app that gives approved developers who have created in-vehicle applications the ability to test them in a real GM vehicle. In-vehicle app testing is the next step for app developers who have already created a proof of concept using GM’s next-generation infotainment software development kit (NGI SDK).

Of course, you need a car or at least access to a car from one of GM’s brands, which is a bit tricky in Europe. And, it is must be a model from 2017 or newer.

By the way, these third-party apps are written with Web technologies (HTML/CSS/JavaScript).

Will Android Take Over In-Vehicle Infotainment?

For Nathan Tennies from Barr Group, the answer seems to be a resounding “yes”:

It’s frankly hard to see how automakers using AGL—or other infotainment platforms—will be able to keep up with Google. […] And for some automakers, putting the kibosh on Google may ultimately be more important than providing customers with the best IVI experience […] But mobile giant Samsung provides a cautionary tale about the difficulties of competing with Android.

Samsung and the other Android handset makers provide a cautionary tale why using Android is a bad idea. The premium handset market is heavily dominated by Apple’s iOS. Customers are willing to pay prices of 700 Euros and more for an iPhone, because iOS is the big differentiator from Android.

Why should customers pay 700 Euros for Android phones, if 300 Euro Android phones are good enough for them! Android OEMs can only differentiate on price. And their average selling prices have been declining for years.

Car OEMs would be stupid to bet on Android. They would give away an easy and compelling way for differentiation. I can’t see this happening for premium car makers like Daimler, BMW, Porsche and Tesla. They are currently investing heavily in operating systems other than Android.

ICS on QtCommercial: “Fee is Better Than Free”

Mark Hatch, the COO of the Qt consultancy ICS, gives four strong arguments, why projects should pay for Qt Commercial instead of using Qt under LGPLv3 for free:

  • Reduced obligations/greater flexibility of distribution
  • Additional features
  • Technical support
  • License negotiation

Mark’s argument would be so much stronger, if The Qt Company published its license fees or at least gave some ballpark figures. If potential customers had a rough idea of the costs, they would think something like this: “Wow, Qt Commercial is much cheaper than I thought. I get some killer features on top of the free license. I have absolute peace of mind when deploying my application on devices. Let’s contact sales. I am sure I can get a good discount.”

Now compare this with the current situation: “I hate calling sales people to get a first quote. They’ll call me twice a week for the next four weeks. I really hate this. OK, I’ll call them next week.” It is unlikely that Qt Sales will ever hear of this potential customer.

CMake Cross-Compilation Based on Yocto SDK

We have succeeded in building embedded Linux with Yocto for a quad-core NXP i.MX6 (ARM Cortex-A9). Next, we want to cross-compile our own Qt application. As we use CMake for building our Qt application, we must create a CMake toolchain file. I am going to give a line-line by line explanation of the CMake toolchain file. I used Yocto Morty and CMake v3.5.1 (as it comes with Ubuntu 16.04 LTS).
Continue reading