Development of Multi-Machine Agricultural Systems-P2

Part 2 - Multi-Machine Organization

This article was Part 2 in a four-part series on multi-machine agricultural systems, focusing on the organization of multi-machine systems.

  • Part 1 set the current landscape for multi-machine systems
  • Part 3 described strategies to develop connected machines in limited connectivity areas
  • Part 4 addressed integration of fleet, task, and mission management

One of the major challenges with multi-machine systems is determining how they will be organized. This problem isn’t immediately obvious to system designers who are new to multi-machine systems, but it is arguably the most significant consideration. This requires wrestling with questions such as: How is the desired workflow mapped to the machine operations? How does each machine know what it needs to do? Who are the users, and how do they interact with machines? How is command and control, and system monitoring managed within the system? This speaks to the overall system architecture, and there are many different options for how a system could be designed. The system architecture sets the technological constraints for the entire system, and a poor architecture could result in serious limitations on the overall system.

Benefits of a Robust Multi-Machine Architecture

Multi-machine systems typically develop by extending the function that one machine has established, and expanding this to share data and coordinate activities across multiple machines. These systems can range from simple results monitoring of agricultural tasks to allow for a more complete picture of the farming operation, to coordination of machines within a common mission to allow for task execution through autonomous or highly-automated machines.

The system architecture defines the system’s structure and key components, communication paths, user interaction points, and, ultimately, information flow. A poor architecture could result in information flow bottlenecks, high component costs, unreliable operation, and a user experience that feels like a Rube Goldberg machine.

Furthermore, once the architecture is set and in use, it often continues to be built upon, which means that making changes may not be possible without tearing down the whole system and starting again.

On the other hand, a robust system architecture will facilitate simplicity of use, reliable information flow, lower component costs, and rapid response. Despite these clear benefits, the design of the system architecture is rarely the starting point for multi-machine system designs, and rather designers often start by building one component at a time, without really thinking about how the whole system fits together.

Product managers responsible for the road map of agricultural machines recognize the trend towards connected systems in the market and sense that unique value could be realized with their product’s connectivity. The hope is that by bringing connectivity to their machine, they can offer a unique competitive advantage, but often it’s unclear exactly how this can be achieved.

The pressures of the market often drive product managers to give a direction of “adding connectivity” to a machine, and engineers become responsible for finding telematics system offerings that could work as part of the machine design. With this direction in mind, connectivity is looked at as a separate piece from machine controls, and solutions that can be “bolted-on” to their current machine control system are found. This is the path of least resistance for adding connectivity, as it results in minimal changes to the control system, through integrating a telematics module that offers an out-of-the-box system for cloud connectivity and a generic user interface. The problem with this “bolt-on” approach is that most out-of-the-box telematics systems have been developed for fleet management applications, which may address where your machine is located, and some engine-based health and status information, but not the unique agronomic task needs specific to the agricultural machine.

These telematics solutions have been developed to meet wide market needs across construction, mining, and forestry, as well as agriculture, with a generalized cloud and user interface solution that is like a bad politician – trying to be all things to all people. Just as we see with bad politicians, this may get the system sold (or elected), but rarely results in real value to anyone.

Once the realization sinks in that the telematics solution is not bringing the intended value, product managers and engineers often work to add more “bolt-on” pieces to address the gaps identified in the market. If this, again, is done with an approach of finding the path of least resistance to meet a near-term defined goal and save the existing components of the system, then it typically results in even more complicated and fragile systems. There are many examples of these results in areas where efforts to integrate existing task management pieces (originally intended for single-machine agricultural systems) are tacked on to fleet management systems (intended for cross-industry machines). The result is a mess of fragmented solutions that are prevalent in the agricultural machine space.

This approach suffers from what is known as the “sunk-costs fallacy”, where companies will hesitate to consider the whole system, because they have spent so much time and effort developing their current system that they do not even want to contemplate alternative solutions. However, further investment into an architecture that does not truly facilitate value for the end-user is like trying to escape from a pit by continuing to dig.

Thinking like a User: Design by Workflow, not Function

While it may be clear that a proper architecture design for multi-machine systems will result in a more robust system that can offer real value to the end-user, the question still remains as to how this can be achieved. Unfortunately, there is no universal answer to the right system architecture, but there are design approaches that have proven to be more effective in determining this.

The key in this process is to think like an end-user. This, of course, is not a new idea, and there are libraries full of books that drive home this same point, as well as popularized methods and philosophies (Design Thinking, for example) that apply essentially this same approach. However, those closest to the problems often have the hardest time applying this approach.

Development of the Multi-Machine Concept

The mistake that many product managers make in defining this value proposition is starting with the machine they have and thinking about how they can make it better. While this approach can be successful for small and incremental improvements, this will generally not result in great leaps of improved value. This is a function-based approach to thinking of the machine. The function-based approach says: “We build a machine (baler/seeder/harvester/grain cart); how can we connect multiple machines together and why would this be better?” Instead, the user-based thinking should be applied to ask: “We have customers who need a job done (planting/baling/harvesting); with today’s technology, is there a better way to do this than what has been done in the past?” At the end of the day, the end-user does not want a machine, they want to get a job done, and there may be a better way to do this than there has been in the past.

This thinking can result in some large realizations about truly innovative ways to get the customer’s jobs done. Experienced product managers and engineers who are very close to a machine can often find it difficult to take this step seriously, because their experience tells them that it is a waste of time, as they (or others) would have already seen a better way if it existed. This would almost certainly be the case in a world where technological change was slow. However, this is not the world we live in. The pace of technological change continues to grow exponentially, and the arrival of technology that enables scalable connected and autonomous machines means that there can be fundamentally new ways to deliver value for customers by getting these core agricultural jobs done in new ways that were not feasible 10, 5, or even 2 years ago.

This is the opportunity to step back from a single machine’s function and think about the workflow that takes place. If we were to take an example of creating hay bales for cattle feed, this job consists of many steps along the way, including cutting hay, raking, baling, gathering bales, wrapping, transporting, storing, distributing, deploying, processing, and finally delivering the hay as feed. There are many different machines used within this workflow today, each with a specific job that is disconnected from the others. Recent advances in connectivity technology now provide opportunities to develop coordinated information flow through some of these steps in the process, and advances in automation allow this to be executed with multi-machine systems to bring new process efficiency. Rather than focusing on a single machine within this workflow, it is beneficial to consider the current challenges faced by the users throughout the workflow and think about how connected systems may reduce these challenges.

An effective methodology in executing this approach draws from agile development, through the definition of user stories. The first step of this process is defining the system users. While machine manufacturers will most often be thinking of the machine operator, there are actually many different users within any given workflow. These can include common roles such as farm owners, farm managers, machine operators, dealers and support staff, agronomists, and the manufacturer’s sales, engineering, production, and service. Each of these users have different challenges, and as a result, a value offering to each of them could be different. Identifying the value to each of these users is a key step in proper multi-machine system design; while not all users may have the same weight, forgetting about any of them could have disastrous results. For example, developing a system that meets all of the machine operator’s needs when it works well, but does not consider service and support for when things go wrong, may result in a poor user experience overall.

With the users considered, a process of walking through the workflow and identifying the greatest pain points faced by each can help to identify opportunities to create new value. This process of walking through the workflow with the users identified and considering their perspective is extremely valuable in focusing into areas that are the core strengths of the organization. Of course, most manufacturers are not going to have expertise, capabilities, or resources to develop a complete system for the entire workflow, but understanding the entire workflow may allow the manufacturer to identify new opportunities to connect to new parts of it and expand their value and offering. There are many good techniques to apply to facilitate this process (which are beyond the scope of this article), but the outcome of this initial process should be one or more concepts on connected and multi-machine systems that might best help their customer complete their agricultural task.

This separation of the tractor and implement has resulted in a fragmented market of fleet management systems. Many of the large full-line OEMs are exclusively developing connected systems that have limited the effectiveness (and the adoption) of third-party systems that have grown faster in other industries.

Refining the Concept towards Architecture Development

Once the focus is narrowed to a smaller subset of the workflow, based on the concept for the value proposition, the user-focused thinking again plays a key role in further architecture definition. Developing user stories that describe in more detail the use of the concept system is the best way to narrow the definition of what the system needs to achieve. The user stories consist of common-language descriptions of each step in the process from the point of view of each of the users, which are relevant to the multi-machine concept system.

Through this process, implementation concepts can start to be introduced, which will put constraints on the system. This is necessary, as it is of no use to anyone to define a system that would not be feasible to implement. However, implementation constraints should not be applied too early, and should be done with an understanding of why these are being applied throughout. Combining the application expertise from product managers and sales teams with that of engineering and technology experts through this process is key to balancing intended system value with implementation feasibility. This is an iterative process, where user stories are defined that detail the workflow from the user’s perspective, and the architecture needed to facilitate takes shape, costs are assessed, and decisions are made on trade-offs that arise.

If this process is done well, a system architecture that is driven by a user focus will start to take shape. In some cases, identified solutions may require significant new technologies, or technologies applied in entirely new ways (which is common for autonomous multi-machine systems). For these cases, there may be a need to validate implementation feasibility through proof-of-concept projects before working towards the development of systems intended for production.

Breakdown of Historical Architecture Constraints: New Opportunities for Multi-Machine Systems

The major benefit of thinking in workflows is that it can help to break away from mental models that constrain thinking of machine design solutions. This is more important now than ever before, because some of the historical system architecture constraints are starting to change. The largest of these system constraints has been set by the relationship of the tractor and the implement in agricultural machines. Agriculture is unique from many industries in the separation of the tool that is to perform a job (the implement) and the power platform responsible for moving the tool in the field (the tractor). This model is thousands of years old, where animal power (horse, ox) was the predominant power platform before the tractor replaced it. The major reason for the continuation of this model is the large number of different jobs that need to be completed on the farm, so the cost efficiency that comes from allowing the tractor to be used for different jobs makes sense. However, this model does not come without a cost, and a significant one is the constraints on system architectures for connected and multi-machine systems.

When we consider how connectivity architectures have evolved based on this system constraint, the significance becomes apparent. The diagram below shows a typical simplified agricultural system and the components that are relevant for connected systems.

The typical data that is of interest includes:

  • Agronomy planning data – The remote user workstation (5) is the source of this data
  • Agronomy results data – The implement (1) is the primary source of this task data
  • Machine health and status – Both the tractor (2) and the implement (1) are the sources of this data
  • User machine operation data – The machine display (3) is the source of this data

The most valuable data for the farmer is typically the agronomy data, as this provides information relating to the job at hand. However, because of the nature of the tractor-implement structure, and the evolution of the industry, connectivity solutions have often been implemented in the tractor, which is not a source of this data. This has driven major efforts in trying to standardize information across many different types of implements, and the result has been standards initiatives, such as ISOBUS, that have attempted to standardize communication between the machine display (3) and implements (1) (the ISOBUS UT function), between the tractor (2) and the implement (1) (the ISOBUS TECU and TIM functions), and between the implement (1) and the remote user (5) (the ISOBUS TC functions). While there have been significant successes in these areas, there have also been many challenges in compatibility that are driven by the constraints of this architecture. The challenges have been due to the fact that information specifically relating to the agricultural task has essentially needed to be translated back and forth to a universal format, so that the tractor could manage the information flow (as shown in the diagram below).

Defining all agricultural tasks in a universal format is extremely challenging, and while this has been successful for many types of coverage-based tasks (e.g., planting, spraying), it leaves a lot to be desired for tasks that do not fit this format. The challenges faced with this architecture extend exponentially when expanding thinking to multi-machine systems, as the number of translations (and therefore opportunities for incompatibility) increases.

Thinking from a workflow perspective, the agronomy functions and data (planning, task execution, and analysis) need information to flow primarily between the remote workstation (5) and implement (1), with the machine operator (3) in the loop. Removing the tractor from this information flow chain can greatly simplify solutions, and reduce the need to rely on standardization when it is not necessary.

Mobile device technology (tablets, smartphones) has provided new technology solutions to address the machine operator interface that is not reliant on the tractor, and connectivity technology that is integrated with the implement allows for new potential architecture that reduces or eliminates the translation steps for task information, as shown with the diagram below.

This allows for much more system-shaping freedom to meet the specific needs of the user through a workflow-based approach. This also allows for customized extension across multi-machine systems in a simplified manner.

Extending this further, technologies that enable autonomous solutions have matured to a point where many new machine possibilities have opened up. Many of these include smaller machines where the power platform function could be reasonably integrated into the implement machine. This further reduces many existing constraints for multi-machine systems, as all of the machine health and status information is integrated into the same machine that is the main source of agricultural information. This distinction between the source of the task and machine information becomes blurred with autonomous machines, as the planning, execution, and analysis of the machine mission includes the function of the machine motion, as well as the agricultural task.

While this exercise is certainly an over-simplification of the considerations that need to be made in defining a system, and applying standardization of information provides a large number of benefits in many applications, it shows that these should not necessarily be taken as a default constraint. Applying the user-focused workflow approach in defining a system architecture questions many of the underlying constraints that product managers and engineers assume when considering multi-machine systems, and can open up new possibilities for providing value to the customer, enabled by changes in the technology landscape.

Organizations that can break free of mental models with system constraints that are not necessarily providing value to the customer will emerge as leaders in the shift towards integrated workflows enabled by multi-machine systems.

Platforms

Our focus is providing advanced technology platforms for agricultural applications that are scalable. JCA's range allows your innovations to be built upon a stable and flexible technology platform, reducing time to market and decreasing overall costs.

Autonomous Framework

JCA AFW is a set of technologies that provides the common components to autonomous agricultural machine systems.

Learn More »

Precision Agriculture – VIREO

JCA’s precision agriculture platform builds on the strengths of precision agriculture while augmenting these with a connected architecture.

Learn More »

Agricultural Implements

JCA’s agricultural controls platform consists of technology building blocks that facilitate the rapid development of customized OEM implement controls.

Learn More »

Blog

Read JCA's latest blog articles to learn more about the future landscape of autonomous agricultural technology and how we are shaping the future with it.
See All Blogs
NEWS
September 28, 2023
AGCO and Trimble announce JV bringing together Trimble Ag and JCA Technologies
JCA Technologies to be part of joint venture between AGCO and Trimble creating an industry-leading mixed fleet Precision Ag focused organization.

Contact Us

Have a vision for making agricultural machinery work smarter? An idea that you’ve wanted to build but haven’t known how to begin?

There’s never been a better time to take that first step. Let JCA Technologies outline a solution for you.