Part 1 of this series provided an overview of the split in the agricultural market between fleet management (machine location and health) and task management (job-related control and monitoring) systems. These task and fleet systems have developed independently in the agricultural machine industry for a variety of reasons explained in Part 1, but are increasingly needed to be brought together. Efforts to do this so far have mostly resulted in a clunky user experience due to challenges in limited access to key data, independent telematics/cloud systems, and independent manufacturers with closed systems. Progress has been made in many of these areas over the last few years, and has resulted in some realizations:

• Closed systems are a losing proposition – Early on in the IoT revolution in agriculture, it looked like several OEMs, as well as technology providers, had been trying to develop connected system platforms that would be a closed system, working with their equipment (or authorized partners), and blocking out all others. The temptation for the large players in the market is that they can dominate the market and provide a cleaner user experience for people who buy into the system completely. However, while this model may work for Apple, it has become clear that this is not sustainable in the agricultural industry, due to diverse OEMs, farm management systems, and technology providers, and farmer demands for more options. This was a lesson learned 30 years ago for electronics in agriculture, and spurred the development of collaboration efforts such as ISOBUS. The needs variation is so diverse in agriculture that no one company can effectively meet them all. Most companies have now realized this, and it has kicked-off a new atmosphere of collaboration in determining how systems can work together.
• There will not be a single provider of “THE” cloud solution – Individual organizations had also made early attempts to become THE cloud provider for all (or a large part of the market). This is a variation of the closed system, where only the data management is centralized, allowing for many different machine telematics systems to connect, as well as farm and fleet management systems. The value proposition to partners with this approach is that the overhead of the data management is handled, and each partner only needs to manage the system interface. This central data control has not been successful, as many organizations want to remain in control of how their customers’ data is managed for their application. It is clear at this point that there will be many cloud systems that need to share data for a cohesive user experience.
• Cloud-to-cloud systems are the future – What has developed is a cloud-of-clouds environment, where it is clear that there is strong value in different cloud systems existing for specific purposes, but these do not prevent interaction with other systems. This has a huge advantage of allowing OEMs to develop cloud-based multi-machine and data management systems specific to their needs, without having to be concerned about the system needing to be everything to everyone. This is made possible by the maturing of technology in this area, which lowers the barriers to creating and maintaining a cloud system that could be specific even to a single application, without worrying about double-work efforts. A large OEM may even have multiple cloud systems for different equipment types that can each meet the needs of those specific applications, but still share data, have integrated user authentication, and appear seamless to the end-user. This has really freed OEMs up to focus on their near-term applications without having to build the perfect cloud system to handle everything in the future, and allowed them to shape their customers’ user experiences to best fit the need. The DataConnect effort started with John Deere, CLAAS, 365FarmNet, and CNH; the ATLAS effort by AEF; and the Agrirouter by DKE-Data are all different (and potentially compatible) approaches that are in line with this cloud-to-cloud approach, giving strong signaling to the industry that this is the future.

While task management and fleet management are on a path where they may start to come together slowly for operator-driven systems, this is something that will have to be reckoned with sooner in autonomous systems.

A divided workflow between fleet and mission management for autonomous machines will result in a user experience that is so difficult, it will prevent adoption. This becomes clear when applying the process described in Part 2 of this series, and walking through an autonomous machine workflow from the user’s perspective. JCA has walked through this many times for different applications, shaping our Autonomous Framework to meet the needs arising from common problems.

A mission for an autonomous machine consists of both the path (where the machine will travel), and the task (what the machine will do). The many different problems can be categorized broadly into two types:

• Coverage problems – Coverage-type problems are common in agriculture for seeding, planting, spraying, tilling, and harvesting, where a machine needs to cover an entire area during its application. These problems have been the primary focus of task management technologies in precision agriculture applications. Common functions include planning prescriptions, monitoring as-applied maps for planting/seeding/spraying, and yielding with harvesting, as well as applying dynamic control functions such as variable rate application, section or overlap control, and auto-steer. This mission type can have a heavy pre-planning stage, where the path and the task goals can be determined before mission execution, with relatively small amounts of dynamic changes to the plan needed.
• Dynamic mission problems – This category lumps together “everything else” that does not fit into coverage problems. This is a wide range of other applications that require much more dynamic adjustment during operation, and minimal pre-execution planning is required, with more planning on-the-fly based on conditions in the field during execution. Examples could be baling, bale collecting, grain handling, seed refilling, refueling, rock picking, grading, and many other applications.

Planning of any autonomous problem will involve defining work areas (geofences) where a machine can operate safely. This can consist of multiple types of areas, such as:

• Task areas – areas where the machine can perform its core task
• Travel areas – areas where the machine can travel, but not perform its task (like a path between task areas)
• Keep-out areas / obstacles – areas where the machine cannot go within the overall work area

Setting of geofences is a common function of traditional fleet management systems, typically providing notifications when machines leave particular areas. For autonomous machines, further functionality is needed as it relates to the operation of the task.

Planning for coverage problems may also involve prescription planning, where the specific goals of the task are associated to geographic areas. This is a common function from traditional task management systems, where a specific application rate is defined for areas, based on agronomic analysis, to optimize inputs for production. Often, this prescription plan is generated from a farm management system that has advanced analytics used for generating a prescription based on previous production results, soil characteristics, drainage, and other environmental characteristics.

The machine path for coverage problems also can be generated in the planning stage, where the size, dynamics, and characteristics of the machine are considered to develop a path to drive for the coverage problem.

The planning for dynamic problem applications will consist of the work area definition, but either minimal, or more customized application-specific path and task planning at a pre-execution stage. The planning for these applications often involves a path generated upon execution from the current machine location to a target (may be a moving target), and can require considerations of approach, and heading to the target.

This planning stage includes elements that exist in traditional fleet and task management, and (especially for coverage problems) there is a strong benefit for using defined formats (such as those defined in ISO11783 for Task Controller data) for integration with farm management systems. However, to be useful to the operator, the workflow cannot separate these items, but rather must guide the user through a simple method that is tailored to the needs of the application.

Some of the functions that exist as part of traditional task and fleet management solutions are needed within an autonomous machine workflow, but because these need to be integrated, cobbled together solutions will not work. These must be customized for each specific application with an integrated workflow. The need for integration with farm management systems at the planning and analysis phases shows that technologies and standards (such as ISOBUS Task Controller) for shared data formats should be built within the current trends in the industry, moving towards data shared between cloud-to-cloud systems with open APIs. On the other hand, the need for customization to fit the requirements of the autonomous application across multiple machines likely means moving away from technologies intended for one-to-one operator to machine interfacing, such as the ISOBUS Universal Terminal (UT).

Customizing the entire workflow to meet the needs of the application is critical for multi-machine autonomous systems, blurring the differentiation between fleet and task management into integrated mission management. This trend is also enabled for operator-driven multi-machine systems through mobile device technology and cloud systems that can share data at the cloud-to-cloud interface level.