From Farmers to Programmers
Here's a look at a proof of concept that allows non-programmers, in this case farmers, to connect their devices and machines, pull data, and set up simple commands.
Join the DZone community and get the full member experience.Join For Free
Imagine a farmer working daily somewhere in the fields of Oregon. Every hour, he wants to know what is going on with his tractor in the field, control tractors and seeding machines remotely from the farm, and keep an eye on irrigation machines. The farmer purchased a device to both receive sensor-based feedback from the field machines and control various types of vehicles remotely from the farm. But now, anytime the farmer wants to adjust the processes on the machines or add new machines, he needs a programmer.
But what if he doesn’t? What if we enable the farmer to program the device without a programmer? It might sound surreal, but it's a reality.
Making a Farmer's Life Easier
Ciklum’s R&D Engineering team had to create a product for the end-user (Farmer) to easily program tasks for different hardware platforms, namely the field machines. We decided to do this via a “drag and drop” concept — connecting functional blocks in a web-based IDE environment. The farmer would have access to the data from all hardware modules via web interface or mobile application.
In the market, there are several industrial automation solutions providing a number of possibilities for using IDE and universal PLCs (programmable logic controllers). However, significant problems occur when flexible integration with a web-based UI and telematics capabilities are needed. In addition, the field of industrial automation requires highly qualified developers who, unfortunately, are often unavailable to support farmers.
The app interface must be like child’s play: Small blocks linked to the corresponding functions. Simply connect as a chain and let it all work.
UI to manage the work of all field machines, allowing the farmer control machines remotely, track location, collect data, and generate reports and notifications for unexpected use or faults, etc.
Proof of concept: Is this idea feasible without the need for an army of programmers and full-cycle manufacturing?
The solution: As much OS, hardware, and platform independence as possible.
Our team's PoC was developed by one embedded system architect, three embedded/data processing engineers, one C++ developer, and one UI designer.
Our Own Metalanguage and Workflow
Our own metalanguage (Visual Programming Language) was developed based on the JSON standard with the ability to integrate into three environments: engine control unit (ECU), mobile, and web. This language also works on multiple ECUs, vehicles, mobile apps and web applications simultaneously, allowing the end-user to control them as part of a single project.
In practice, the farmer can program machines in the field to work together regardless of the machine size, type, or manufacturer without professional developers. The workflow would go as follows:
The end-user opens the program’s interface.
Each machine function is a block (or blocks) at the screen.
The user drags and drops functional blocks, like controlling a machine’s scoop remotely, tracking the tractor’s location, receiving data on the harvest, getting notifications about necessary maintenance, hours of operation, etc.
The user connects blocks into the program architecture to manage the work of machines.
As a Proof-of-Concept, two Reference Carrier Boards with SoM on i.MX6 were used, communicating with each other via a CAN bus and ethernet, and a Raspberry Pi. This enabled sending data to an Internet server by HTTP protocol via 3G modem connection. Users were able to collect data from various sensors, send it to other boards and servers, and control any actuators using digital, analog and PWM outputs. The application ran successfully on Windows systems, Yocto Linux, Raspbian Linux, and other Unix-based operating systems.
PoC consists of the following:
ECUs with ECU Application: The main components needed to implement user logic in the system, to handle and process the sensor’s data, control actuators, etc.).
Internet Server(s): These connect the end-user to all components, such as ECUs, data and metadata storage, web-based UI frontend application hosting, and web-based IDE hosting.
Web-based UI: For telemetry and remote control of the system, interaction with the user interface for system data monitoring according to metadata, a customized UI layout, and any other visual experiences by the end-user(s).
Android Mobile Application: For telemetry and remote control of the system.
Metadata visual editor: Web-based IDE draft.
What Does This Mean?
This PoC illustrates the main approach to the unified development environment — to design, develop, test, and integrate a full telematics solutions and management software for agriculture and construction machines with both web and mobile application.
The unified visual programming language combined three different environments in a unique IDE and empowered it with the diagnostics tool needed to provide the farmer with feedback. The interface of the system is based on connected and configured functional blocks, working in an autonomous mode in case there is no Internet.
Farmers are the ones who know these machines better than anyone else. And they are enabled to create a system to control the tractors or seeding machines in a simple, yet flexible way without on-site technical support.
Opinions expressed by DZone contributors are their own.