THE AEF

Activities

High Speed ISOBUS,

an AEF Project for next generation Ag networking

 

Historical Perspective


Controller Area Network (CAN)1 has existed since the early 1980’s, and is the most common embedded network in automotive, truck and bus, and off-road machinery.

The use of CAN in agricultural systems started in the early to mid-90’s, typically as a proprietary solution. Work to develop the ISO 117832 standard began at about the same time, leveraging work from the SAE J19393 standard and extending it in unique ways for the agricultural industry. “ISOBUS” as it was nicknamed, was first formally revealed to the industry at Agritechnica 2001, as shown in Figure 1. Even after that reveal, it took several more years of development before successful interoperability was realized between various manufacturers equipment.

Figure 1 ISOBUS revealed at Agritechnica 2001

Fundamental to the original design of ISOBUS, and with the size of the equipment – tractors and connected implements, is the definition of the physical layer (ISO 11783-2) which specifies the maximum length of a CAN backbone (e.g. the primary CAN harness extending from the front-most ECU to the rear-most ECU) as 40 meters and a maximum bit-rate of 250 Kb/s, or approximately 1,800 messages per second.

In the years since that original physical layer definition, the foundational layers of the ISOBUS communication protocol were developed (ISO 11783-3, ISO 11783-5), permitting successful network management, device discovery, and communications. At this point, it had value, but there was a lot more to come as ISOBUS was extended for the specific needs of the agricultural industry. Various application level functionalities were developed that bring the true value of ISOBUS to customer equipment. Applications include Virtual Terminal (ISO11783-6) [2004], Tractor ECU (ISO11783-9), Task Controller (ISO11783-10) [2009], Diagnostics (ISO11783-12) [2009], File Server (ISO11783-13) [2007], and most recently, Sequence Control (ISO11783-14) [2013].


As these services were being developed and continue to be developed and mature, ISOBUS is approaching the ease of plug-n-play.

Even now, about 20 years later, the “ISOBUS Community” remains strong, with “colleagues” who work for competing companies, working closely together supporting the successful integration of different manufacturer’s individual products into a “farming system” that fulfils customer needs. For many such systems, the CAN-based ISOBUS serves very well, and it is fully expected to continue that way for years to come.

However, the continuing evolution of more advanced farming systems will require significantly increased ISOBUS communication performance. For these newer advanced systems, the constraint of the CAN-based ISOBUS technology is beginning to limit the OEMs ability to meet new requirements.

With CAN-based ISOBUS, which is constrained to 250 kb/s, large and complex systems may experience CAN traffic well beyond 50% of the bus capacity and often saturating near 100% usage. With these levels of network traffic, latencies increase significantly, even to the point where the precision of the prescription, performance of the automation, and the user experience suffer.

The Agricultural Industry Electronics Foundation (AEF)4, commissioned a 10th Project Team (PT10) to develop a next generation of ISOBUS to provide new capabilities well beyond CAN. CAN was an enabler that moved the industry from proprietary hard-wired solutions to advanced systems sharing networked information, command and control. PT10 – High Speed ISOBUS (HSI) will pave the way for another major step into higher performance systems.



Use-Cases for High Speed ISOBUS

While there has been a perception of the need for a faster network for several years, one of the first steps after the formation of AEF Project Team 10 (PT10) was to identify and document use-cases requiring a faster network. From that work, the main use-cases are:

  • More precise command and control of prescription
  • More precise data logging of as-applied and yield information
  • Higher featured and more responsive display of information


For these and many additional use-cases PT10 elaborated each into requirements attributes such as communication speed, bandwidth requirements and control latency. The team then worked to scale those requirements into imagined future systems which would leverage these needs – as a bigger, better, and faster combination of tractor, implements, and integrated functionalities.

Task Controller is an example of a functionality that supports the first two use-cases listed above and thus is one of the primary drivers for HSI. In looking in more detail at the command and control use-case, PT10 elaborates on that high-level requirement –

  • Command and control timing accuracy well below 10 ms
  • Control of all possible set-points within that time-interval
  • Substantial reduction in jitter in delivering that control

In applying these requirements to a planting system, consider that the Task Controller would be able to control each row’s seed-rate, and manage the target seed spacing far more consistently. Further, it could accomplish this while simultaneously logging other row-level attributes, all at a level of precision not possible with CAN.

Along the journey of use-case and requirements development to serve these new systems, PT10 has had deep and ongoing engagement with two other AEF project teams – Camera Systems and Wireless Infield Communications.



Camera Systems (PT08)

Most in-use camera systems are based on analog cameras, where each camera is typically wired with a separate cable to deliver the camera image into the operator cabin for display. Many times, operators want to view several cameras simultaneously, which may increase the complexity of that system.

In the electronic camera industry, there has been a significant shift in cameras from delivering a purely analog signal into the digital domain, and more recently leveraging networks. While the cost of a digital camera remains higher than an analog version, the cost differential is declining. With the shift to digital, users can experience much higher image quality and may benefit from additional features including digital image stabilization, and digital pan and zoom.

In this digital domain, each camera image stream has image quality, frame-rate, and latency requirements which can in turn affect bandwidth and ultimately the presentation characteristics that the customer experiences.

Digital cameras could be integrated as a completely independent infrastructure with power, cables and connectors. However, by taking the digital camera use-cases into account early in the development of the HSI, the architecture of cable, connectors, electronics and protocols can be shared, simplifying the overall system, reducing the need for duplicate infrastructure, and managing cost and complexity more effectively.

Wireless Infield Communications (PT11)

Many companies have provided wireless machine to machine communications for years – as proprietary solutions. The most common use-case for these proprietary systems is for the command and control of an adjacent machine – typically the position, vector, and velocity, for example a combine offloading into the grain wagon being towed by a tractor. This communication is quite low in needed bandwidth; however, it does have an important real-time requirement to retain the proper coordination of these machines.

With the PT11 work toward standardization, this and other use-cases were identified, among which include:

  • The transfer of prescription and coverage maps from one machine to another
  • The remote viewing of a camera on a nearby machine
  • The command and control of an adjacent machine


Each of these use cases has their own bandwidth and latency requirements. Given the need for high bandwidth transfer, the inclusion of these requirements into the HSI architecture can again lead toward reduced system complexity.


Bringing ISOBUS, Camera, and Wireless use-cases together

A summary of some of the overall set of use-case performance goals are represented in Figure 2, representing use-cases that vary widely in two key characteristics.

The delivery of prescription/coverage maps may represent the highest of bandwidth requirements, for a very detailed definition as may be required by a companion machine. Compare this to the camera’s for remote viewing, which also have a high bandwidth attribute, but the real-time nature of the camera streams has a much different requirement for usability.

Scope

The exploration of many use-cases described above and the elaboration of those into requirements helps define the scope for HSI. While some use-cases have not yet been imagined, a prime goal of PT10 work is to develop the foundation for a new industry communication standard that can scale for many years to come. To ensure that scalability, each use-case and derived requirements were explored individually for how those requirements may change in even more futuristic systems. PT10 then translates that composite work into an architecture that supports major advancements beyond what we know about today. This is of course no small challenge – to know what we don’t yet know…

Technology Options

From the developed set of requirements for bandwidth, latency, connectivity, and power, various communications technologies were analyzed with respect to its ability to support the requirements. Additionally, guided both by historical data and the expertise in PT10, the scalability for the future is also a factor.

CAN

CAN-based ISOBUS is restricted to 250kb/s, even though CAN scales to 1Mb/s. At these signalling speeds, each implement would require additional ECUs acting as a bridge from one CAN segment to another CAN segment. The overall HSI bandwidth and latency requirements cannot be supported by a faster CAN bus.

CAN-FD

CAN-FD5 is a newer, and incompatible with the present CAN-based ISOBUS. It can scale up to 8 Mb/s, due to the dual-speed nature of its design. As with CAN, the 40m reach at faster signalling speeds would require additional ECUs. The overall HSI bandwidth and latency requirements exceed the capabilities of this technology.

FlexRay

FlexRay6 is a higher performance network (2 channels at 10 Mb/s) used in automotive systems and is designed to be fully deterministic and suitable for x-by-wire applications. FlexRay is not suitable for a plug-and-play network for ag systems. The overall HSI bandwidth requirements exceed the capabilities of this technology.

Wireless

There are many variants of wireless technology. As a potential standard, this narrows the possibilities to one of Wi-Fi7 technologies suitable for use in most regions of the world. Wi-Fi in general can meet most of the requirements – for overall speed and generally for latency. However, some of the use-cases, and particularly when imagining even higher performance use-cases, Wi-Fi is not seen as fulfilling the requirements for the lowest level of tolerable latency and would be further challenged with potential safety critical communications.

Ethernet

Ethernet8 exists in many forms, and with many performance levels ranging from below 10 Mb/s to well beyond 1 Gb/s. Within the last decade, automotive took a strong interest in Ethernet and commissioned the development of a special 100 Mb/s automotive variant of Ethernet that is of interest to the agricultural industry since it was designed with automotive requirements and regulations in mind. This is commonly referred to as One Pair EtherNet (OPEN)9.

Almost as quickly as this “OPEN” standard was defined, this became an insufficient definition. There are now several speed variants of OPEN in production and even more in development.


Scalability

Figure 3 Technology Comparison

The requirements for future systems are difficult to predict, however some aspects can be more readily forecast, some of which are represented in Figure 3. Other attributes, such as engineering effort, or available Wi-Fi channels by region, are not well represented on this chart. Bandwidth requirements will continue to grow, so a system that is more bandwidth limited may not serve as well or for as long.

Future systems may require higher levels of determinism in communications that may not be as easily realized with some technologies. This may be a case where latency becomes increasingly critical, driving requirements toward lower and lower latency and eliminating technologies that may be robust, but cannot meet these requirements.


Architecture

In bringing these combined use-cases together, PT10 has derived a high-level architecture as shown in Figure 4. While this diagram reflects only the HSI architecture, it is intentionally very similar to the CAN-based ISOBUS, effectively as a parallel network that supports the new high-performance use cases.

As with ISOBUS, HSI imposes requirements for connectivity of implements and other optional devices in the cab. Referring to Figure 4, there is an HSI connector on the rear of the tractor as well as in the cab. The front connector will be optional as is typical of ISOBUS. Because HSI is an Ethernet based architecture, each individual Electronic Control Unit (ECU) will connect to an Ethernet Switch (SW), which could of course be integrated into an ECU. In the CAN-based ISOBUS, the backbone represents the CAN cable from the front-most to the rear-most point on the network. In this switched Ethernet architecture, “backbone” is more of a concept than a specific implementation – where the concept refers more to the link segments that share aggregate communications load. Each implement may need additional connectors, one for on-implement options, and an additional one toward the rear on tow-between implements. In this architecture, the owner may install after-market kits which add an additional network switch, which in turn provides several additional HSI connectors.

Because expanding an Ethernet architecture requires specialized connectors, a new goal for HSI requires the same connector interface in each location, more flexibly supporting optional devices. By comparison, in ISOBUS there are several different connectors specified.

Figure 4 High Speed ISOBUS System Architecture


Physical Layer Research

Many of these technologies are in use today in automotive systems, and not by coincidence, the automotive technologies align very well with our Ag industry needs; environmental (e.g. temp, humidity), durability (e.g. vibration, life cycle), regulatory (e.g. electromagnetic compatibility) and more. From this, we get the further benefit that the high volumes of automotive usage generally drive the cost down.

In the ongoing technology research by PT10, the best and most reliable technology supporting AEF requirements is a wired Ethernet technology, and of the wide variety of Ethernet technologies the preferred is 1000BASE-T110.

Compared to the more common desktop-style of Ethernet that uses 2-pair of wire for 100 Mb/s11, or 4-pair for 1 Gb/s12, the “-T1” Ethernet uses a single twisted pair. The reduction in wire and connector pin count translates to a lower probability of failure.

Ethernet, when implemented as a switched network architecture, has a significant advantage in that each individual link segment where an ECU is connected has only the traffic relevant to that ECU. Link-segments connecting switches carry the aggregate data stream when the end-point collaboration crosses that link. Putting this into the perspective that an individual ECU has a relatively small bandwidth requirement, there is virtually no way for the “backbone” links to be overloaded. By comparison, the CAN-based ISOBUS shares a single network where every device is on a shared multi-drop link – so the communication performance of each ECU is directly affected by the communications of every other ECU.

 

Protocols

Turning next to protocols, after having decided on Ethernet, and then narrowed the focus to Internet Protocol style of communications, there are perhaps hundreds of additional protocols from which to choose.

Early requirements to help narrow the focus:

  • Platform Independent (Linux, Windows, AUTOSAR, …)
  • Programming Language independent
  • Extensible Interfaces (unknown future requirements, backward compatibility)
  • Synchronous and Asynchronous (non-blocking) communication
  • Request / Response (Remote Procedure Call)
  • Publish / Subscribe (Decoupling of Client and Server)
  • Optimized Communication (TCP/UDP, Multicast, Broadcast)
  • Quality of Service (Priority Signals, Safety, Timeout Management, Retransmission)
  • High Speed (Performance, Scalability, low latency)
  • Low Footprint (Hardware Requirements, Costs)
  • Suitable for Automotive or Process Control


To fulfil these requirements PT10 is evaluating “middleware” based protocol suites, rather than individual protocol components that must be integrated. An open, service orientated protocol improves the extensibility while supporting backward compatibility. Two potential solutions have been identified and are under evaluation by PT10. One (SOME/IP) is automotive driven; and the other (OPC UA) is driven by the automation industry.


SOME/IP

Figure 5 SOME/IP Protocol Architecture from ISO 17215-2:2014

The requirements for future systems are difficult to predict, however some aspects can be more readily forecast, some of which are represented in Figure 3. Other attributes, such as engineering effort, or available Wi-Fi channels by region, are not well represented on this chart. Bandwidth requirements will continue to grow, so a system that is more bandwidth limited may not serve as well or for as long.

Future systems may require higher levels of determinism in communications that may not be as easily realized with some technologies. This may be a case where latency becomes increasingly critical, driving requirements toward lower and lower latency and eliminating technologies that may be robust, but cannot meet these requirements.

Additionally, as seen in Figure 5, this standard describes the complete protocol usage on the different OSI-Layers. As defined by the automotive industry, many other aspects of SOME/IP have relevance to the agricultural industry, including recommended practices for command and control, and diagnostic support, which may be useful in alignment with regulatory issues (e.g. EU Regulation 16714).


OPC UA

On the other hand, there is a strong trend in the automation industry toward a standard called OPC UA15 (Standard Open Platform Communications Unified Architecture). This standard also describes the complete protocol on the different OSI-layers.

Figure 6 OPC UA Protocol Architecture from TNS/A Conference 9/27/2018

As shown in the Figure 6, OPC UA specifies profiles and an “Information Model” at the application layer to harmonize the operation of machines in a factory, even as those machines are produced by different manufacturers. The XML based information model scheme in the automation industry machine fits quite well for Task-Controller use cases.

Protocol Research Continues

Both SOME/IP and OPC UA protocol stacks have strengths of importance to the PT10 use-cases. For example:

  • Both support camera/video control and streaming protocols.
  • SOME/IP is more automotive aligned for command and control and diagnostics.
  • SOME/IP has defined how to communicate CAN via Ethernet with precise timestamps.
  • OPC UA is more process control focused.

Investigation will continue to identify which protocol stack is better aligned with our industry and use-cases, as this will affect both the near-term usability for HSI and the extensibility for future systems based on HSI. The team hopes to choose one and not require support of both.

Other points of interest under research are topics related to functional safety, security, and diagnostics.


Simulation

Essential to the process of validating a candidate technology, and well before creating any demonstrable implementation, is the ability to simulate a chosen architecture and evaluate that system under various levels of both normal operation and higher-stress operation (as may be caused by different use-cases that drive different real-time and bandwidth requirements).

The general system architecture for this simulation is shown in the figure.


Many different system configurations were defined and analyzed through this process, summarized here into a few key points:


Network Technologies:

  • 100 Mb/s speed
  • 1 Gb/s speed 


Traffic Patterns:

  • 3 to 5 cameras, varying from 14 Mb/s to 75 Mb/s
  • ECUs with configurations for more safety critical and best-effort delivery
  • Payload sizes from 42 bytes per packet to 1500 bytes


Traffic Shaping:

  • Scheduled traffic
  • Priority based strictly on priority and using weighted fair queueing
  • Best effort traffic


Based on significant effort in simulation, a 100 Mb/s network would meet the immediate and readily forecast needs, but it was recognized that it may not scale as well into future use-cases. This is one of the motivations that has led PT10 into working toward a 1 Gb/s network.


Challenges

While many PT10 requirements are like those in the automotive industry, others significantly exceed what has been observed so far, such as the plug and play integration of implements to tractors, as well as the overall “size” of the network from one end-point to another. Thus, even as the benefits of automotive work are translated to Ag, there are other areas where PT10 work appears to be leading the industry. Some years back, PT10 naively thought that we could identify the technologies that will be useful, and that they will already exist – we would somewhat simply need to identify the needed protocols and the needed cable and connector components and move forward in our work. This has proven not to be the case.

Connectors for our industry have a much more challenging environment than on automotive systems. Implements are routinely connected and disconnected, and the environment is quite harsh. We are working with several connector companies toward a solution to “cross the hitch” in a robust and reliable manner.

Cabling that meets the performance needs and is applicable to our industry is also a challenge. In automotive, attention is on size and weight, and cables are affixed to the body and chassis structure to minimize flex and failure. These types of cables would not survive the Ag environment. To develop a reliable solution, PT10 members have been working with cable and harness suppliers to ensure Ag environment is properly accommodated.

And lastly, but not least, is producing something useful for “day 1”. The CAN-based ISOBUS development took many years between the time the ISO11783 physical layer was defined and when the first useful customer systems were deployed. For the High Speed ISOBUS, we have a goal to reduce that delay to approximately zero. With teams that have been working in parallel on architecture, physical layer, simulation and protocol, we remain focused on this goal.

Work ahead

As an abbreviated summary, some elements of the PT10 work ahead are as follows:

  • Define/finalize physical layer items:
    - Ethernet and Network Switch technology
    - Connector technology
    - Harness and cable technology
  • Define/finalize protocol:
    - Supporting initial “Ethernet as a faster CAN”
    - Define an open protocol to support ongoing development
  • Generation of AEF Guidelines
    - Documenting the defined recommended practices as a series of guidelines
  • Transition the AEF Guidelines into an ISO Working Group
    - Support the generation of a new ISO standard serving the industry

 

Out of Scope

With the scope and deliverables listed above, there is no small challenge. As PT10 has evaluated what might be possible, it became appropriate and necessary to identify not just the scope of PT10 work and deliverables, but also to identify what may be out of scope.

Image processing at the far end of the network
Camera streams used in Advanced Driver Assistance Systems are commonly wired directly to the ECU responsible for the analytics – because each individual camera in such a system may require more than 1Gb/s per camera. Sending that stream from an implement to an ECU elsewhere on the network is not practical. This specialized use-case is out of scope for HSI. Note that a high-performance camera image may be down-sampled to a resolution, frame-rate, and compression ratio that is suitable for remote viewing, and this scenario is in scope.

PT07 High-Voltage synchronous electrical drives
The real-time EtherCAT16 network technology implemented by PT07 for High Voltage synchronous electrical drives is also out of scope, as this deterministic network is not compatible to the plug and play requirements for an open tractor-implement network such as HSI. Relative to the HSI architecture, it is anticipated that an ECU can bridge relevant communications onto either the existing ISOBUS, or HSI.

Deterministic Communications
The current HSI requirements do not require deterministic behaviour in the communications. However, in researching the potential impact if or when a deterministic link needs to be developed (other than that used by PT07), such as Time Sensitive Networking (TSN)17, the basic HSI architecture could evolve to support this, or other potential deterministic protocols. In this scenario, the known HSI needs are delivered best-effort, and since the 1 Gb/s network is sufficiently over-provisioned, the real-time requirements can still be met. This transition would require a change in the network switch hardware, and hardware/software at the end-points that require the deterministic behaviour. Due to the projected cost and complexity, and in the absence of requirements for this capability, this is presently out of scope for HSI.

Summary Points
To summarize how HSI will impact agricultural systems is difficult, because there are use-cases that can be readily understood, but with an intent to have an open and scalable architecture, there will be functionality implemented that is not yet imagined. Anchoring more on the readily understood impact:

  • CAN-based ISOBUS will continue to be supported for many years to come. Many systems exist and serve the industry very well, and many more are yet to be developed which fit very well within the capabilities of ISOBUS.
  • High Speed ISOBUS will initially be deployed to serve readily identifiable use-cases: higher performance precision farming applications, camera systems, and connectivity to the wireless machine-to-machine applications.
  • HSI is currently more expensive than CAN. Specific system needs and requirements which cannot be met with CAN-based ISOBUS will offset the cost. Over time, as the technology matures, and use-cases expand, that price differential should become less significant.
  • The HSI protocol stack will support the transfer of existing CAN-based ISOBUS protocols, which could transfer existing ISOBUS protocols with greatly improved performance.


This new system will also be the basis for the development of extensions to existing functionalities and completely new functionalities that cannot be realized within the bandwidth and protocol constraints of CAN.

HSI will be the new standard for Ag on-machine networking and represents a completely new architecture. PT10 is fundamentally committed to developing a solution that not only meets the known requirements but will scale to meet the needs for use-cases and functionalities not yet imagined.

The intention to jump from 0.25 Mb/s CAN to a 1000 Mb/s Ethernet system is no small challenge, but what comes with it is an amazing level of performance. With a basic signalling speed that is about 4000 times faster, control system latencies will be “virtually zero”. This network should support advancing performance requirements for years to come.

We look forward to presenting more about HSI, perhaps at future VDI conferences, as this technology is deployed into advanced agricultural systems.

References



« Back to overview