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.

Like what you’re reading so far? Subscribe to receive our Development of Multi-Machine Agriculture Systems content series directly to your inbox.

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.

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).

Challenges with information flow in agriculture systems

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.

New potential architecture that reduces or eliminates the translation steps

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.

Task and Machine Information

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.

Ready to talk?

Need help understanding how you can take advantage of these opportunities for your product? Talk to one of our experts and we can guide you through a user workflow-based approach to defining value that can be offered for multi-machine systems, and a scalable architecture to support this.

Next Part of the Series: Operating Multi-Machine Systems In Limited Connectivity Areas

JCA has developed multi-machine systems across several different applications. Through this experience, we have faced many of the common challenges that arise with multi-machine systems and shaped our Autonomous Framework (AFW) technologies to address these challenges.

Read Part 3 - Operating Multi-Machine Systems In Limited Connectivity Areas

In the next parts, we will address some more specific challenges in multi-machine systems, including:

Part 3: Operating Multi-Machine Systems in Limited Connectivity Areas – A significant challenge for multi-machine agricultural systems is that often they need to operate in remote areas that do not have reliable Internet access. The market will not accept any mobile machine that depends on a reliable Internet connection to operate. The last thing farmers want to deal with is being shut down at critical times in the agricultural season because of connectivity issues. This means that scalable agricultural mobile machine systems must be designed to work in areas with no cell access or reliable Internet. JCA’s AFW communication technology has been developed to address this need.

Part 4: Integration of Fleet, Task, and Mission management – Fleet and task management systems have developed along independent or loosely coupled paths. Multi-machine systems require both the integration of these and the addition of mission management, which considers the overall workflow of all machines in the system. A significant challenge with multi-machine systems is considering how this can be done effectively to result in an intuitive workflow for the user, while also leveraging existing systems, integrating with industry standards and common practices, and minimizing support infrastructure. This requires an understanding of cloud systems, IoT technologies, and the state and evolution of the agricultural industry for connected systems, and is a major component of effective multi-machine systems.

About JCA Technologies
JCA Technologies was established in 2002 and has engineering and manufacturing facilities in Canada and the US. We partner with agricultural mobile machine OEMs to develop autonomous and highly-automated connected machines. We combine our technology building blocks with engineering and manufacturing capabilities to provide electrical, electronics, and software systems as part of customized mobile machine applications for innovative OEMs.