An Overview of CAN-BUS Development, Utilization, and Future Potential in Serial Network Messaging for Off-Road Mobile Equipment

Abstract

A Controller Area Network (CAN) is a serial network information technology that facilitates the passing of information between Electronic Control Units (ECUs, also known as nodes). Developed by BOSCH in 1986 to circumvent challenges in harness-connected systems and provide improved message handling in automobiles, the CAN interface allows broadcast communication between all connected ECUs within a vehicle’s integrated electronic system through distributed control and decentralized measuring equipment. Since the early uses of CAN in car engine management, improvements in bitrate, bandwidth, and standardization protocols (such as ISO 11898 and SAE J1939) have led to CAN utilization in various industry applications, such as factory automation, aviation, off-highway vehicles, and telematics. Alternative wired and wireless technologies have been used to connect and network with CAN-BUS (such as Ethernet, Bluetooth, Wi-Fi, ZigBee, etc.), further expanding the diversity of applications in which the serial network is employed. In this chapter, the past, present, and prospective future developments of CAN technology, with focused attention on applications in the agricultural and off-road sectors are broadly examined. CAN technology fundamentals, standards creation, modern day uses, and potential functionalities and challenges specific to CAN in the wake of precision agriculture and smart farming are discussed in detail.

1. Introduction and Background

A Controller Area Network (CAN) in a vehicle or machine is analogous to the nervous system of a living organism. The nervous system of the body is a neuron-based network that collects signals from sensory receptors, passes chemical messages to and from the brain, responds to stimuli, and initiates actions. Expanding the analogy, sensors in a controller circuit are the equivalent of receptors, and an electronic control unit (ECU) can be visualized as a sensory neuron system dedicated to a specific function, bridging communication between receptors and the central nervous system. CAN-BUS systems create communication pathways between the electronic control units within a vehicle, allowing the transfer and interpretation of collected data. Prior to the invention of CAN-BUS, there was no efficient means of cross-communication between ECUs. CAN-BUS is efficient by relaying the most important messages first, through a prioritization scheme of source ID-encoded messages using the binary unit system (BUS). This is an extremely robust arrangement, with a high ability to both detect signal errors and to function when hardware is cross wired. This structure is fully distributed, which allows for a single access point for all the desirable information collected. CAN-BUS is a relatively simple, low-cost system that reduces the overall harness weight and amount of wiring needed in a vehicle, improving the integrity of transmitted data in comparison to harness-connected electrical structures [1].

While CAN-BUS has been an effective communication technology in many past and present applications, future utilization of the network system continues to be a subject of research and development. In agricultural uses, this tool aids in precision agricultural applications and in the realm of data communication within larger farm systems. Vehicle autonomy is another area in which CAN-BUS may play an important role as an inter-communication system. Additionally, there is still significant untapped potential for integrating CAN-BUS messaging into both more off-road control systems and wireless technologies.

The purpose of this chapter is to familiarize the reader with the importance of CAN-BUS in commercial off-road vehicles, applications, and future potential usage. In order to fully understand the benefits of CAN-BUS, the origins of CAN-BUS and its subsequent applications will be summarized. A high-level analysis of CAN-BUS technology, standards, and communication protocols will be presented to better familiarize the reader with essential technological concepts. Current applications of CAN-BUS and a comparison with alternative electronic control systems will be provided. A final qualitative evaluation of CAN-BUS capabilities will allow for a deeper understanding of why it is the dominant technology in modern vehicles and what innovations may be needed to expand its breadth of application in the changing technological landscape of off-road equipment.

2. History

2.1 CAN-BUS development

CAN was developed in 1986 by BOSCH as a means to overcome the limitations in harness-connected control systems [2]. Their goal was greater functionality in message communication in automobiles, which could be accomplished through distributed control. A distributed control system connects multiple, specific instrumentation into a system network that facilitates the transmission of data and information, adapting to the needs of the automation control scheme used. It combines individual, decentralized measuring control equipment into a main network node, creating an interconnected network capable of controlling a larger system [3]. In developing the CAN system, the control equipment corresponded to nodes (or ECUs), which were connected to a two-wire bus, completing the network connection. The system prevented message collisions, thereby preventing the loss of crucial information, a common issue with other existing technologies at the time.

While other technologies could achieve the goal of inter-node communication, they required complex wiring systems, with each ECU individually connected to other ECUs to provide a communication pathway [1]. The point-to-point wiring of all ECUs was unnecessarily complex and caused difficulties in data and message management. In CAN-BUS implementation, all the connections are made directly on the same area network. Through utilization of microcontrollers, the system complexity decreased dramatically, allowing for a reduction in wiring, a simplified manufacturing assembly process for connecting nodes, and an overall increased system performance. Due to the improved efficiencies and system simplicity that this technology offered, CAN-BUS became a viable alternative to the complex point-to-point wiring harnesses used at the time [4].

In 1987, both Intel and Philips developed the first CAN controller chips, the Intel 82526 and the Philips 82C200, respectively [2]. The first iteration of this technology was a chip that managed messages by assigned priorities. This allowed the more important messages to be received with significantly less delay. Notably, this first system included error detection, which would automatically disconnect faulty nodes, while still allowing uninterrupted communication between working nodes [5]. The hierarchy system allowed for the most crucial information to be passed along first, making the system particularly useful in applications with high safety requirements [1].

In early CAN development, there were two hardware implementations that cover the bulk of installations: Basic CAN and Full CAN. Basic CAN utilized a single message buffer to receive and transmit messages. The standard CAN controller implemented a specified number of message buffers (usually around sixteen), wherein the programmed algorithm read the received messages and wrote messages to be transmitted [6]. In Basic CAN, the received message is passed through acceptance filtering, which then decides whether to process a message or ignore it. Software is used to control the acceptance filtering of a node in Basic CAN. Bit masks for message identifiers make it possible to ignore certain messages by ignoring specific identifiers, in order to reduce the software load requirement at the individual nodes [7].

Compared to Basic CAN, Full CAN is a bit more complex. Every transmitted or received message is accompanied by eight to sixteen memory buffers in the Full CAN scheme. Hardware, rather than software, performs acceptance filtering in this system, reducing the overall software load significantly. Individual buffers are configured to accept messages with specific identifiers, and unique buffers for individual messages allow more processing time for the messages that are received. The transmitted messages can then be better handled according to their priority levels. Data consistency is also improved through this one-on-one buffer-to-message configuration [7]. Unfortunately, Full CAN is limited in the number of frames that can be received, and it requires more computational chips at each node than Basic CAN. Early CAN controllers by Intel and Philips were constructed under the Basic CAN or Full CAN configurations, with Philips favoring the former and Intel the latter. Modern CAN controllers combine the frame handling and acceptance filtering strengths of both, so the distinction is no longer made between Basic and Full [2].

A major milestone in bringing CAN-BUS into industry was the development of the CAN-in-Automation (CiA) working group in 1992. CiA is an international organization comprised of manufacturers and users with the goal of creating developmental content based on members’ interests and initiatives [2]. One year later, the International Organization for Standardization (ISO) published ISO 11898, which defined controller area network communication protocols for the automotive industry. ISO is a non-governmental organization, without corporate affiliations, comprised of individual standards organizations from 165 nations. It develops voluntary international standards and improves the world’s trading potential by providing common standards across the globe [8]. The implementation of an ISO standard for CAN-BUS was an important step in bringing coherence and marketability to the serial network system.

As the bandwidth requirements of the automotive industry continued to increase, the CAN data link layer (which will be covered in later sections) needed to be updated. BOSCH began developing the CAN FD (flexible data-rate) protocol in 2011, working in conjunction with carmakers and other CAN experts. This updated protocol surmounted two of the most restrictive early CAN limitations: the data transfer rate and payload. CAN FD allows for a bit rate (transmission speed) of up to 12 Megabits per second (Mbps), twelve times faster than the previous maximum transmission limit. The data field message payload was expanded up to 64 bytes in length, an increase of eight times beyond the previous payload size restriction [2]. CAN FD incorporated a simple, yet powerful ideology: when only one node is transmitting data, the bit rate can increase as no nodes need to be synchronized. The nodes are then resynchronized following the data transmission and data integrity check, just prior to an acknowledgement of data acceptance [9]. By 2015, ISO 11898 had been updated to incorporate CAN FD, and it has continued to be the standard CAN system in commercial implementations [2].

2.2 Early applications of CAN technology

CAN-BUS has played a major role in industry since its debut in 1987. In the mid-1990s, companies like Infineon Technologies and Motorola began shipping large quantities of CAN-BUS controllers to European automotive manufacturers, marking the advent of CAN utilization in the automotive industry. In 1992, Mercedes-Benz was noted as the first manufacturer to implement the controller within their processes, when CAN-BUS was first incorporated in their high-end passenger cars for engine care management [2].

BMW was next to implement CAN-BUS technology in 1995. They introduced a star topology network with five electronic control units in their 7 Series cars. Then, they took the implementation even further and employed a second network for body electronics. This allowed two separate CAN-BUS networks to be associated through gateway connections. Following BMW’s example, other manufacturers soon began implementing two separate systems in all their passenger cars. Today, many manufacturers have multiple CANBUS networks associated with their production vehicles [2]. An example of vehicular integration is presented in Figure 1.

Figure 1.

Illustration showing the multiple node connections to CAN-BUS in a modern vehicle.

In 1993, a European consortium led by BOSCH prototyped a network which would later become CANopen. This project was eventually passed to CiA for further development and maintenance. In 1995, it was completely revised and became the most important standardized network in Europe within just a few years. The CANopen network protocol offers high configuration flexibility, which has allowed its installation in a multitude of applications. The networks were first used for internal machine communications, specifically in drives, but they have since been utilized in many other industries. Within the United States, CANopen has been implemented for use in forklifts, letter sorting machines, and other network processes [2].

As mentioned in the previous section, introduction of CAN-BUS into the automotive world required the standardization of protocols and testing standards to ensure CAN system conformity. ISO 11898, the first international standard for CAN, was based on the BOSCH CAN specification 2.0, and it standardized the high-speed physical layer for the system at the time [10]. As network technology continued to develop, allowing for different data transmission speeds and fault tolerances in the physical layers, new revisions to standards and interfaces for vehicle-specific applications were needed. This led to the development of SAE J1939 for heavy-duty vehicles and multiple other ISO standards (some will be covered in the CAN-BUS Standards Development section below). Due to the rapidity of CAN modification and development in the early 1990s, no error-free, complete standards or CAN specifications were available for CAN chip manufacturers. This led to the establishment of CAN conformance testing houses, where all CAN chips could be tested for compliance to the BOSCH CAN reference model using the testing plans outlined in ISO 16845 [2]. These steps were important in allowing the new technology to be widely applied in a variety of markets.

With regard to the marketing of CAN-BUS into the agricultural industry, in 2000 the German Mechanical Engineering Professional Society (VDMA) founded the Implementation Group of ISOBUS to promote the ISOBUS controller. The German Agricultural Society (Deutsche Landwirtschafts-Gesellschaft, DLG) assisted with the development of the first tests and a testing facility for ISOBUS compliance, which remains the primary test house for device compatibility. In 2009, several companies joined to form the Agricultural Industry Electronics Foundation (AEF), a non-profit organization which further promoted the use of CAN-BUS controllers, especially the implementation of ISO 11783. Since then, there have been many plug-tests organized at various locations. The first plug-test for CAN-BUS in North America was hosted by the Nebraska Tractor Test Laboratory in 2010 [11].

This review of the development of CAN-BUS and its early applications illustrates some of the current and future directions for the technology. Besides the novel use of a distributed communication network, these development efforts have truly positioned CAN-BUS as the leading serial network system in off-road vehicles. The establishment of international societies and standards has been essential in this effort. The societies are dedicated to enforcing CAN standardization across the industry and to enhancing the functionality and quality of CAN technology through research and development. These organizations will likely continue to play an important role as CAN systems are utilized in new implementations going forward.

3. Technology fundamentals

3.1 CAN utilization: messaging basics

To gain a more complete grasp on how CAN ID messaging works and how different ECUs can interpret these messages, it is helpful to understand the overall structure of CAN messages, from both a data and hardware perspective. This section covers the physical architecture of the BUS, the different components of CAN messages, CAN error-handling, a high-level breakdown of CAN layers, and provides an overview on how CAN-BUS systems support effective messaging channels.

The physical architecture or layer of a Controller Area Network includes two wires, CAN High (CAN-H) and CAN Low (CAN-L), which carry all CAN messages between ECUs and connect to BUS terminators at each end. The BUS terminators are powered and grounded, providing the necessary voltage to allow serial network operation. The most standard form of CAN wiring in modern systems is the twisted quad cabling configuration, in which a terminating bias circuit (TBC), with a power wire and ground wire, is wound together with the CAN-H and CAN-L signal wires between the two terminators [12]. Both of the signal wires have set dominant and recessive voltages that correspond to the CAN system type (high speed or low speed). The system reads the voltage difference between the two wires as a bit-value of “0” when the voltages are dominant, or a value of “1” when the voltages are recessive, creating the mechanism of sending binary messages through the system hardware [13].

A maximum of 30 ECUs can be attached to a single section of the BUS, and the overall number for ECUs connected to the network is limited to 254. The maximum number of available ECU addresses is limited to 256, because the maximum length of a data signal is 8 bytes. The 255 address is left null, and the 256 address indicates for a message to be accepted by every ECU connected to the network [12]. Since CAN-BUS is a broadcast protocol, messages are not sent to specific nodes, but rather, every ECU connected to the network receives every transmission from all other nodes on the same network. Various ECUs typically have filters on their receiving ends, so that the local computer only accepts the messages that pertain to its operational needs [14]. This open communication between all connected nodes helps to improve the manufacturing process and implementation of the system, creating vehicle-wide interconnection. Since all the nodes are linked by subsystem functions, there are no redundant connections between any two specific ECUs.

As shown in Figure 2, a basic CAN message has eight key parts: 1) Start of Frame (SOF); 2) CAN Identifier (CAN ID); 3) Remote Transmission Request (RTR); 4) Control; 5) Data; 6) Cyclic Redundancy Check (CRC); 7) Acknowledgement (ACK); and 8) End of Frame (EOF). It should be noted that the “CAN frame” consists of parts 2 and 5: the CAN ID and the Data [12]. The SOF is a 1 bit “dominant zero” at the beginning of a CAN message which signals that an ECU is about to send a message. This alerts other ECUs connected to the CAN to “listen” for the message transmission. The CAN ID contains information on the message priority (lower values indicate higher priority) and the source address. The identifier bit length varies by version of CAN, with CAN 2.0 being 11-bits and later versions relying on extended 29-bit identifiers. The RTR is another 1-bit piece of the message indicating whether a node is sending data to or requesting data from a specific ECU. The Control portion of a CAN message is 6 bits in length, 4 of which are the data length code (DLC), which denotes the size of the data message to be transmitted (0–8 bytes) [13]. The Data segment of the CAN message makes-up the bulk of information being communicated, and it contains all the CAN signals to be extracted and decoded for use by the receiving ECUs [5].

Figure 2.

CAN-BUS message structure.

The four message parts prior to the Data portion are all used to give the receiving ECUs adequate information on whether to receive the data being sent and what kind of data to expect. The last three parts of a CAN message are used to ensure that the data was transmitted successfully. The CRC is a 16-bit portion of the data that checks the data integrity, while the ACK is a 2-bit acknowledgement that the CRC found no issues with the data, allowing it to pass. Finally, the EOF is the 7-bit cap on a CAN message that signals the end of the transmission [13]. A breakdown of these eight parts highlights the strength of CAN messaging, in that it provides both front-end and back-end context for the data being sent. Message types used in CAN-BUS include the data frame (a data transmission message), the error frame (a message that violates CAN formatting to signal an error in data transfer), the remote frame (a message to request data), and an overload frame (a message transmitted by an overloaded node to trigger delays) [5].

System robustness and error handling are the two major benefits of the CAN-BUS system architecture. Error handling is the methodology of detecting flawed messages that come across the CAN-BUS, in which the original sender destroys a faulty message using an Error Frame, and then re-transmits the correct message. All CAN controllers connected to the BUS listen for potential transmission errors whenever a new message is sent along the BUS [15]. When an error has been identified, the node that discovered the error will transmit an Error Flag throughout the system, halting all CAN-BUS traffic. The other connected nodes will each receive the Error Flag and transmit eight recessive bits, known as an Error Delimiter signal, to clear the BUS before taking appropriate action in response to the error. The most common response to an Error Flag is to discard the erroneous message and continue to transmit and receive other messages streaming on the BUS. This allows for what is known as fault tolerance, or the ability for the system to function around an error state [15]. An example of the error handling message structure is detailed in Figure 3.

Figure 3.

A sample of an error handling message structure.

Each node keeps a record of detected errors through two different registers. Errors that the ECU was responsible for sending are accounted for in the Transmit Error Counter, while faults that it detected in other nodes’ messages are logged in the Receive Error Counter. Several protocols have been defined which govern how recorded errors increment or decrement the counters. When a transmitter detects a fault error in a message, it increments the register for the Transmit Errors at a faster rate than the receiving nodes increment their Receive Error registers, since the transmitter causes system faults in most cases. When a node’s Error Counter exceeds a predetermined value, the ECU enters an Error Passive state, in which its error detection activities will not be broadcast on BUS traffic for other nodes to see. When the counter rises above a second, higher preset value, it switches into a BUS-Off state, removing the ECU from participation in BUS traffic [15]. Through this process, CAN nodes can both detect faults and perform error confinement.

An Open Systems Interconnect (OSI) reference model is utilized by CAN-based network solutions. This same standard is applied across all modern communication technologies. This model is standardized in ISO/IEC 7498-1, which defines “a common basis for the coordination of standards development for the purpose of systems interconnection” [9]. The adapted CAN message model comprises three of the seven OSI layers: the first layer- the CAN physical layer, the second layer- the CAN data link layer, and the seventh layer- the CAN application layer. Typically, OSI layers 3 through 6 (network, transport, session, and presentation layers) are not explicitly implemented. It is common for the application layers in CAN to incorporate functions of network and transport layers to allow this adaption of the OSI model without sacrificing functionality [16].

Higher layer protocol functionality, which spans between the network and application layers, is an important factor in CAN network design. Network management, which includes the protocol for turning CAN nodes on and off, can be included in this functionality. Node supervision in event-driven networks is another common function in network management [17]. This supervision is required to detect nodes that are missing due to several possible fault conditions. Missing nodes could be caused from a BUS-Off state, a temporary power loss, or a permanent power loss. Application layers can search for missing nodes using one of two methods. For nodes that do not transmit messages periodically, a client/server service can be programmed so that a connected server sends a state message to the monitoring “client” after a consistent period, providing a “pulse”. Any interruption to the pulse that exceeds a set time limit indicates an off-line status in that node. However, if the node does transmit messages in a periodic fashion, this detection can be done implicitly [16]. An example of this time-out utilization in error reporting is given in Figure 4.

Figure 4.

Implicit message time-out reporting utilizing CANopen.

One of the most significant higher-layer protocol services in CAN is breaking-up data for transmission and re-assembling it on the receiving end. While this function is typically associated with the transport layer in OSI, in CAN, this parsing of data is another role executed by the application layer. Examples of protocols that provide this service include CANopen, DeviceNet, and J1939-21 [17]. Device and network design have become simplified through the utilization of software routines that execute standardized higher-layer protocols. These protocols are typically implemented in software through protocol stacks. Standardized versions of these stacks are commonly available from a variety of manufacturers. Examples of these standardized protocol stacks include CAN Application Layer (CAL) from CiA, NMEA 2000 from the International Electrotechnical Commission (IEC), and CAN FD from CiA.

CAN-BUS, as an overarching protocol for vehicle system-to-system communication, helps the vehicle make informed decisions about component level maintenance and control by maintaining an efficient communication pathway. To facilitate effective information flow, there are often multiple levels and separate systems of CAN that control specific regions and subsystems of the vehicle. This improves information handling capacity, and it helps to simplify the system into subsets that only contain the ECUs that need to communicate with each other. There is no reason, for example, for the ECU controlling in-cab climate control to know what is happening with the left rear tire pressure sensor. These controllers are divided onto different specialized networks, enhancing system efficiency.

In addition to separating networks into subsystems, there are also different types of CAN-BUS systems that allow for different speeds of communication. The high-speed CAN system uses the CAN-H and CAN-L wires described above and can communicate at speeds up to 1 Mbps. The ECUs that require this high communication speed are safety critical systems, like the engine electronic control unit, the brake controller, and the air pollution control systems [12]. These are wired in a linear serial bus configuration terminated by resistors. The other type of CAN-BUS system commonly used is low-speed CAN, which can only reach communication speeds of up to 125 kbps. This is an eighth of the high-speed system rate and is appropriate for fault-tolerant or comfort systems like cab climate control or interior lights. A star serial bus configuration may be used, where multiple CAN applications are terminated at nodes [4]. By splitting-up the networks, there is a higher level of reliability for safety critical systems to get their messages broadcast across the network. This can aid in the avoidance of accidents or in notifying a driver of an in-process component failure, like the loss of engine oil pressure.

To further improve efficiency of the CAN-BUS system, every ECU on the network is also assigned an arbitration ID, or an identification number. This ID dictates which ECU is given priority in the case that there are conflicting messages or messages sent at the same time. This priority framework is a large part what makes CAN so efficient. Important messages from the engine regarding fuel input, for example, are not delayed by a message from the oil pump that oil life has decreased by one percent. In having an established priority level of messages, the system can be sure that system-critical messages are broadcast and received across all interconnected ECUs. This system of broadcasting the highest priority message has been a main contributor to the success of CAN-BUS technology and its dominance in the market.

While CANs are effective at communicating data between ECUs, they can also be utilized to record the operational metrics of a vehicle. Instead of directly measuring the data with precision instruments, approximate results can be calculated using the theoretical relationships between a specific metric and other parameters that are measured with internal sensors on the CAN. These internal sensors are commonly found in plug-and-play tools that are widely available on the market for on-board processing and diagnostics. They generally have low customizability, but they are very simple to install when compared with more specialized, auxiliary sensing equipment [18]. While estimates from these embedded controllers are inexact, very accurate measurements can be obtained via this method, by first calibrating the internal sensors with precision external sensors, as shown in Polcar, Cupera, and Kumar’s study on fuel consumption measurement [19]. This allows a reduction in both the number of sensors and the overall cost required within a vehicle’s control system.

Through its methods of system interconnection and communication, CAN-BUS has revolutionized data collection and autonomy in virtually all markets, especially in the agricultural industry. By splitting-up the various subsystems to create an efficient communication pathway between the multiple electronic control systems that need to communicate, CAN-BUS has become an invaluable addition to modern agricultural equipment and continues to advance the capability for on-board real-time data collection, providing farmers with sophisticated technologies for improving their operations.

3.2 CAN-BUS standards development

Thus far, this chapter has made references to CAN standards, such as ISO 11898 and SAE J1939, but it has not given an explanation as to why there are different standards for different vehicle types. This section will discuss the purpose and need for developing such individual industry standards, as well as introduce some of the most important CAN standards in industry today, especially with respect to agricultural vehicles.

As previously mentioned, controller area networks function using a serial communication protocol, making it a useful pathway for passing digital data. However, without a standard for interpreting and forwarding the data, no useful information or actionable processes can be gleaned from it. Using the analogy of a telephone, CAN would be equivalent to the hardware and telephone lines used to connect the voices of two individuals, while the standard is the language used to make the communication meaningful [5]. Just as it is important that the individuals on opposite ends of the telephone line use the same language conventions to interpret each other’s speech, the same is true with standard compatibility within a vehicle’s system. Many components in a single vehicle are produced by different manufacturers, and standards allow the ECUs of these various modules to function and communicate on a common network.

The first standards were focused primarily on CAN usage in automobiles, as engine care management was the original target market for usage [2]. As off-road and heavy-duty vehicles carry-out entirely different mission profiles from passenger cars, with respect to loads, implement usage, and speed, it was not possible to apply the same “language” for priority and layer management in these vehicles. This led to the evolution of application-specific standards for the vehicle manufacturing industry. To give some more context for what these standards entail, ISO 11898, SAE J1939, and ISO 11783 will be covered briefly.

ISO 11898 was released in 1993. It was initially divided into two parts, and a third part was added later. This standard covers the data link layer, the physical layer for high-speed medium attachment (HS-PMA), and the physical layer for a fault-tolerant, low-speed, medium-dependent interface. ISO 11898-1 gives the specifications for creating an interchange of data between the modules of the CAN data link layer [10]. It also specifies the two main format options, the Classical CAN frame format and the CAN Flexible Data Rate format, the latter of which was introduced in 2012. While Classical CAN supports a maximum bit rate and payload of 1 Mbps and 8 bytes per frame, respectively, the Flexible Data Rate frame format extends the allowance for both bit rate and payload beyond these original limits. The general architecture of CAN is also described in this ISO standard in terms of the OSI layers mentioned previously. It contains specifications for both the logical link and medium-access control sub-layers, as well as the physical coding sub-layer [6] . ISO 11898-2 gives the specifications for HS-PMA, which is a serial communication protocol that allows for real-time control of components in vehicle systems by multiplexing data for immediate use. The standard formalizes HS-PMAs with low-power mode and selective wake-up options [20]. ISO 11898-3 additionally covers the set-up of a data exchange between the ECUs of a vehicle utilizing CAN [21].

SAE J1939 was developed by the Society of Automotive Engineers (SAE) in 1994, and it establishes how nodes transmit data on the CAN-BUS in heavy-duty vehicles [22]. J1939 provides a common communication language across heavy equipment from different manufacturers, allowing a wide range of equipment to work with each other and enabling consistent data logging across heavy-duty and off-road vehicles. Although the first standards development papers on J1939 were drafted in 1994 (J1939–11, J1939–21, J1939–31), it was six years before the initial top-level document was published. After this, controller area networks were officially included within the language of the standard. In 2001, J1939 replaced the older standards SAE J1708 and SAE J1587. This standard, along with its accompanying documents, has since become a wider industry standard and is currently utilized for applications across multiple industries, including agricultural machinery, construction equipment, forestry machines, maritime ships, mass transportation, material handling, and military applications [1].

There are several key characteristics which define SAE J1939. Its bit rate, or the speed at which messages travel across the BUS, was originally set at 250 kbps. More recently, the standard was updated to support a faster bit rate of 500 kbps, and the identifier (ID), or unique name of each message, was extended to 29 bits. The message identifier segment, in addition to describing its data content, message priority, and indicating the source address, is also used in J1939 to specify the destination on the network [23]. The primary differentiation in message composition from other CAN systems comes from the Parameter Group Number (PGN). This 18-bit PGN is a function-specific frame sandwiched between the first 9 and last 2 bits of a traditional 11-bit CAN ID, providing more detail regarding the message content [24]. The J1939 message parameters within data bytes are identified by Suspect Parameter Numbers (SPNs). SPNs correlate to specific PGNs, with their encoded data designated by bit start position, bit length, scale, offset, and units. These PGN-specific details are used to extract desired SPN data and convert it to meaningful physical values [25]. An illustration of the J1939 message structure is shown in Figure 5.

Figure 5.

SAE J1939 message structure.

Development of ISO 11783, a CAN-based agricultural bus system by Landwirtschaft Bussysteme (LBS), began in the early 1990s with the German DIN 9684 standard. The first commercially successful LBS combined the DIN 9684 virtual terminal (VT) concept with J1939 protocols and was internationally standardized as the ISO 11783 series [11]. The accompanying BUS system detailed in this standard is commonly known as ISOBUS. This standard consists of ten specific parts, including: 1) the general standard for data communication; 2) physical layer; 3) data link layer; 4) network layer; 5) network management; 6) virtual terminal; 7) implement messages applications layer; 8) power train messages; 9) tractor ECU; and 10) the task controller & management computer interface [14]. The communication protocols define messaging between the tractor and implement electronic systems through CAN. These, combined with the serial data network, regulate the methodology of data transference between actuators, control elements, display units, information storage systems, and sensors, allowing the tractor to control an implement through the virtual terminal (VT).

The VT is one of the most important features of the ISO 11783 standard, as it allows the operator to interface with the tractor and implements by both viewing real-time data and providing user inputs. The VT acts as a slave to individual ECUs, each of which secure terminal connectivity to display informational data and collect operator inputs according to their individual protocol. The operator can choose which operational data to display, while each connected ECU continues to operate as if the VT were dedicated solely to its specific function [14]. This pathway makes it possible for the operator to have greater control over the functions of an implement, such as sprayer nozzle flow, combine cylinder rotational speed, or cultivator attachment height, depending on input from implement sensors. This eliminates the need for a separate control box for the implement and provides a single terminal controlling all information flow to the operator [11] . The ISOBUS is based on CAN running at 250 kbps. It uses twisted non-shielded quad cable and high-speed transceivers (same as ISO 11898). A 9-pin connector on the tractor is the only required point of contact between it and an implement with an ISOBUS compliant network cable.

This overview of CAN communication and standards has presented a cursory background of the technology fundamentals associated with the serial networking scheme, as well as some brief mention regarding how it is implemented. The next section will go into greater depth on how CANs have been utilized in industry, its potential connection to other network technologies, and how its usage could be expanded in the future.

4. Implementation

4.1 CAN-BUS by industry application

Although controller area network systems were originally developed for the automotive industry, they quickly became popular in other areas. CAN-utilizing industries include large over-the-road trucks, forestry, industrial factory automation, aerospace, and many others. In the aviation industry, the high-speed CAN protocol ISO 11898 is widely utilized, along with ARINC 825, a protocol created specifically for the aviation industry. The effort to create a CAN-based standard for communication in aircraft was initiated by Airbus and Boeing and was advanced by the Airlines Electronic Engineering Committee (AEEC) through their CAN Technical Working Group [26]. Several design targets were set while developing this protocol, including CAN functionality as either a main or ancillary network, an allowance for local CAN network integration into the wider aircraft network, and interoperability and interchangeability of CAN connected Line Replaceable Units (LRUs). Other design mandates were to maintain flexible configuration options; establish a simple process for adding, deleting, or modifying BUS ECUs; and simplify systems’ interconnection protocols [26].

CAN-BUS systems also play an important role in both modern factory automation processes and testing facilities. Since CAN design is based on distributed control principles, it has been effectively used in manufacturing facilities to connect the essential control systems dispersed throughout a plant. Through the use of human machine interfaces (HMIs), operator inputs can be translated into instructions that a programmable logic controller (PLC) dispatches onto the BUS, allowing the remote operation of equipment ranging from sensors to actuators. This process allows the testing of new input parameters prior to execution on specific equipment and is a viable option for increasing process safety [27]. Use of CAN on assembly lines as a quality check is also becoming more common and is especially important on a line manufacturing a customizable product. Certain specifications are programmed for each checkpoint of product assembly, which are then broadcast on the CAN between machines to provide quality validation for the operators throughout the manufacturing process. CAN-BUS is also a practical option for connecting security and environmental control systems across a facility, due to both high bit-rate and inexpensive installation [27].

Returning to CAN use in the off-road vehicle market, virtually all modern agricultural machines incorporate CAN-BUS systems. Improved vehicle diagnostics, less complex design of electronic circuit controls, and advanced implement management are all benefits that CAN-BUS technology brings to the agricultural sector. CAN-BUS systems allow for high precision in machinery performance and logistics information. These metrics help to estimate operational cost and projected size in downstream operations. Specific measurement of other metrics, including fuel consumption, engine load, and average operating speed can also help supply chain managers maximize field and transport efficiency, while designing overall equipment solutions at a lower cost [28].

Displays within the cab allow the operator of the vehicle to view real-time data and information, as the vehicle is collecting it. These displays show the current location of the vehicle via GPS, the instantaneous fuel consumption rate, and other performance metrics that help the operator make intelligent decisions in order to maximize the efficiency of the vehicle. The John Deere Gen4® display shows many attributes, such as the instantaneous fuel economy and location of the vehicle within the field, but it also communicates with other vehicles in the same area to share guidance lines, coverage maps, and applied data in order to work the field efficiently [29].

The display associated with Case IH’s Advanced Farming System® (AFS®) product, like the Gen4® display, is able to show the location of the vehicle within the field [30]. Using GPS and wireless data networks, it is also possible to check the performance of each vehicle from computers located away from the field. AGCO uses Fuse®, which is much like the Gen4® display and AFS®. It shows various data on how to improve the efficiency of the specific field operation, and it includes a seed and dry fertilizer monitoring system, which alerts the operator immediately, via the display, if there is a physical delivery blockage.

Aside from the role CAN-BUS plays in system-to-system communication within a vehicle, the serial network technology has also been integral in the advent of telematics. Telematics is a sector of information technology concerned with how data moves between machines over long distances. Incorporating telematics technology into a vehicle or fleet of vehicles provides the opportunity to utilize collected data outside the scope of an individual machine’s operation by integrating it into a server network for wider usage and analysis. While CAN-BUS is not the sole technology responsible for telematics, it serves an important role in communicating large quantities of data that are eventually converted into valuable information for end users [31].

The general architecture of a vehicle telematics system begins with a Telematics Control Unit (TCU), a telematics cloud server, and front-end applications (Apps) through which the end user accesses captured data. The TCU is a microcontroller that manages data collection, communication, and memory through interfacing with different hardware and software modules. It provides connection ports to CAN-BUS, GPS, General Packet Radio Service (GPRS), battery, and Bluetooth modules, while maintaining a memory unit, a Central Processing Unit (CPU), and communication interfaces to Wireless Fidelity (Wi-Fi), cellular networks, and Long-Term Evolution (LTE) networks [31]. As the central component to a telematics system, the TCU accomplishes the tasks of gathering all the desired data and information from its various connections, synthesizing the information, and communicating to the cloud for use elsewhere. Focusing specifically on the CAN interface, a TCU utilizes the CAN-BUS as a pathway to collect the requested information from the ECUs, as programmed into its operating algorithm. This information acquisition could include any sensor data such as fuel consumption or vehicle speed. By converting the data from the CAN protocols, the TCU can then transfer this data to the telematics cloud server for further post-processing, after which, a user would be able to access the data.

The most common usage of telematics across all industries is within fleet management systems. This data collection process allows managers to optimize fuel usage, monitor vehicle down-time, analyze vehicle processes, and track operators driving a specific vehicle [31]. However, different companies also try to bring unique advantages to their telematics packages, which normally materialize in the form of a specialized management software. For construction and forestry equipment, Caterpillar utilizes a company-specific telematics system called ProductLink®, which has both cell and satellite transmission options, paired with their user interface VisionLink®. The focuses in these systems include the reduction of idle time and elimination of catastrophic failures through the reporting of fault codes [32]. John Deere provides customers with the option of a subscription package to the company’s telematics network JDLink®, which is customizable to include mobile connections, In-Field Data Sharing®, Operations Center® (where data is synced every 30 seconds to keep it safe and secure), and other features which provide greater connective awareness of interdependent operations [33]. Case IH takes connectivity to a more automated level with their AFS® product, which has options for auto-guidance steering in tractors and combines using AFS AccuGuide® and AFS RowGuide® to aid in year-to-year repeatability. Their AFS Pro® system monitors several operational metrics and can manage ISOBUS implements [30, 34]. Utilizing CAN-BUS as a communication platform for mobile data transfer has greatly increased the capacity for utilizing data to drive decisions and functions.

In 2009, Agritechnica launched the Isomatch Tellus® VT. This allowed for the operator to observe two ISOBUS machines through one terminal, allowing for the simultaneous control of functions on different platforms. The possible connections to this terminal included a 15 pin ISOBUS, a power connector, an additional 9 pin extension connector, 4 USB interfaces, Bluetooth, Internet dongle, EIA-232 port for GPS, and others. Later, software packs such as ISO-XML were added to the VT [11]. Another example of user-focused technology is the Opus A3 CAN-BUS operator panel series from Wachendorff Elektronik, which has two CAN-BUS ports and is specifically designed for outdoor applications that include agricultural machinery [35]. As is evidenced by many of the applications in industry discussed above, different interface technology with CAN-BUS has been important in broadening its usage in a variety of fields. Further discussion of both wireless and non-wireless alternatives to and potential connection points with CAN are explored in the next section.

4.2 Alternative connectivity and networking to CAN-BUS

Different kinds of interfaces have been specifically developed to allow the conversion of CAN data into a format for Internet of Things (IoT) communication. Two specific technologies of note are CAN-Ethernet, and CAN-Bluetooth converters. A CAN-to-Ethernet converter allows the transfer of data in both directions and may be utilized in CAN-BUS monitoring, two-way remote CAN-BUS monitoring, and synchronization [36]. The firmware on such a converter contains both a communication device and a web server. The web server manages the protocol conversions, and the communication device provides the user interface. By combining two CAN-Ethernet converters, two CAN networks can be synchronized, allowing connection between CAN networks on different machines and in remote locations. This may be scaled-up further, or a custom software can be programmed to allow the converters to communicate directly to a specific IP address [36].

A CAN-to-Bluetooth gateway, unlike the ethernet connection, can transfer wireless data directly to a mobile device, using classic Bluetooth standards for Android devices and Low Energy (BLE) for Apple IOS. As with an ethernet converter, when the devices are used as a pair, a bridge for CAN data can be created for the end-user to access [37]. The ISOBlue 2.0 is an example of technology under development that utilizes Bluetooth principles. Currently being researched in the Open Ag Technology and Systems Center (OATS) at Purdue University, it is an open-source hardware product that connects agricultural machinery to the Cloud [38]. Other interfaces that allow CAN data conversion into different forms have been important tools in making telematics technology viable for off-road agricultural equipment. CAN Logger CLX000, which works between CAN and OBD2, is one such example [39].

Additional wireless technologies that have been used to interface CAN-BUS systems to IoT devices include ZigBee and Wi-Fi. These technologies also function as standalone networks for intra-vehicle and inter-vehicle communication [40]. Similar to the CAN data converters for Bluetooth and Ethernet, ZigBee and Wi-Fi converters have also been utilized to take advantage of their respective benefits in bandwidth, data transfer rate, security, and cost. More detail on each technology’s specific advantages is presented in Table 1.

Wireless Technology	Installation Cost	Bandwidth Capability	Data Rate	Security
ZigBee	Medium	Medium	Low	Moderately Secure
Bluetooth	Low	Low	Low	Less Secure
Wi-Fi	High	High	High	More Secure
UWB	Low	High	High	Moderately Secure

Table 1.

A comparison of wireless technologies capable of interfacing with CAN and IoT devices [41, 42, 43, 44].

ZigBee is a globally available, wireless networking standard initially created as a home-area network for the control and monitoring of connected devices [41]. ZigBee is beneficial for sensor and vehicle network applications, due to its affordable installation and use cost, extensive battery life compared to competing devices, minimal maintenance, security and reliability, and small physical device footprint [41]. ZigBee was built on the IEEE 802.15.4 technical standard, which defines the physical layer (PHY) and medium access control (MAC) sublayer for low-data-rate wireless personal area networks (LR-WPANs) [45]. CAN-BUS-to-ZigBee conversion has demonstrated benefits in flexibility, convenience, and ease of use in system installation, adding and removing nodes, system updates, and expanded network construction [42].

Wi-Fi is a popular wireless technology for CAN-BUS interfacing and IoT communication. Wi-Fi falls under the IEEE 802.11 standard, which is part of the broader IEEE 802 technical standards for LAN and defines MAC and PHY protocols for applying wireless local area network (WLAN) computer communication [46]. This standard also specifies common radio frequency bands that Wi-Fi can communicate on. These include but are not limited to 2.4 GHz, 5 GHz, 6 GHz, and 60 GHz frequencies [46]. Wi-Fi offers a high data rate of up to 54 Mbps and a large bandwidth capability [43]. The most common application for Wi-Fi to CAN-BUS interaction is vehicle-to-cloud telematics services, as discussed in the previous section. On-vehicle Wi-Fi networks also allow for remote control of vehicle systems and provide capability for varying levels of autonomous control. On-vehicle Wi-Fi networks also allow for sending CAN-BUS data from vehicle-to-vehicle or across several vehicles simultaneously.

Ultra-wideband (UWB) is another wireless technology being researched for vehicle communication systems. UWB is a low-power radio protocol specifically created to improve the location accuracy of wireless technologies. UWB transmits data across a short distance and measures the time it takes for a radio signal to travel between the sending and receiving device [46]. This is similar to the time-of-flight (ToF) method used with radio detection and ranging (RADAR). A UWB transmitter sends billions of radio pulses across a wide-spectrum frequency of 7.5 GHz. These pulses are then translated into usable data from a UWB receiver. While UWB is not commonly used in conjunction with CANBUS, it has been studied for use in autonomous vehicle navigation and path localization [44].

The continuous development and improvement of autonomous vehicle technology necessitates an increased demand for greater bandwidth and connectivity requirements, while still providing an allowance for high system complexity. System complexity in this case could be defined as the added latency from the connected network devices. As many aspects of the interconnected vehicle networks continue to grow, management and network understanding also become more complex. Such aspects include a number of features, routing table configurations, system security, firewall protections, and others [47]. One of the most promising alternatives to vehicle CAN networks are automotive ethernet-based networks. The market for automotive ethernet is expected to increase by 22% from 2019 to 2026 [48]. High bandwidth capabilities and improved cost efficiency are two major benefits to automotive ethernet networks. Instead of a priority-based protocol, ethernet utilizes a Carrier Sense Multiple Access with Collision Detection (CSMA/CD) strategy [49]. This defines the appropriate device response when multiple control units simultaneously attempt to use a data channel and encounter a data collision. Susceptibility to radio frequency (RF) interference, the inability to provide latency at very high frequency, and synchronization issues between timing devices are potential challenges with automotive ethernet network implementation [48]. Currently, the primary consumption of Ethernet technology in vehicles is enabling personal use of the Internet. Ethernet provides rapid data transfer speed, making it ideal for data intensive applications. However, Ethernet does not adapt well to internal failure, as seen in Table 2. A potential associated cost with Ethernet demand increase is the expensive coated wiring needed to provide such high bandwidths.

Network Type	Installation Cost	Bandwidth Capability	System Complexity	Fault Tolerance
CAN	Medium	Low	High	High
FlexRay	High	Medium	High	Medium
MOST	Medium	Medium	Medium	Low
Ethernet	Low	High	Medium	Low

Table 2.

A comparison of CAN characteristics with competing technologies [48].

One type of automotive network communication protocol is FlexRay. FlexRay is a network standard for automotive systems, based on a flexible high data transmission rate, high-speed bus system, like CAN FD [48]. FlexRay is designed for communication of efficiency-type applications in the vehicle. This is due to FlexRay’s high complexity allowance and bandwidth. At 10 Mbps on two dual channels, FlexRay can provide up to 20 Mbps of bandwidth, making it optimal for systems such as steering and brakes. CAN shows advantages over FlexRay primarily in cost and error handling [50]. Due to FlexRay’s robust complexity and bandwidth, its cost is far greater than CAN, on a value per baud rate basis. Although CAN does not generate data transfer rates as fast as FlexRay, it is better suited for the majority of smaller jobs at a far lower cost [50].

Another type of automotive network is MOST (Media Oriented System Transport). MOST provides very fast data transfer at over 24 Mbps. This is because the system was designed to transfer media information within luxury cars, such as GPS, radio, and video systems. MOST has comparable speeds to Ethernet and is more common in automotive applications. However, it handles much less system complexity than CAN and FlexRay, limiting its potential applications [51]. MOST is equipped with plastic optical fiber in its physical layer, which limits electromagnetic interference, thus providing faster speeds and significantly less signal jitter. CAN and MOST have comparable costs, but CAN is better suited for more versatile and sophisticated operations [48].

Overall, CAN shows the most versatility of these four main alternative systems. FlexRay is useful for safety systems, due to its high complexity allowance and multiple channel scheme, but it is a higher-cost system by a significant margin. MOST provides one of the best options for media and information transmission, with a faster data transfer rate than two of the other technologies reviewed [50]. However, MOST cannot be used for highly complex systems. Ethernet provides the fastest data transmission speeds of all the options compared, but it is limited by low complexity allowance and adaptability. CAN, while moderately priced, shows high adaptability to complex systems, while providing useful data transfer in a variety of applications [48]. An example of an interconnected system utilizing these networks in a passenger vehicle is shown in Figure 6.

Figure 6.

An example of a FlexRay application.

4.3 Prospective areas for CAN technology inclusion

Currently, CAN-BUS is used in autonomous vehicle development to gather data from all electronic control sensors and consolidate it onto a single network. By gathering the data into a unified structure, the overall system controller can easily make decisions that affect multiple sub-systems at once. This data availability, combined with swift processing, is a key component in the safe operation of autonomous vehicles both on the open road and off-road. This centralized system data stream allows for advanced control of smart engine sensors, which provide more efficient management processes. The data handling capability of smart controllers is still an area in need of concentrated improvement. Present research is looking into robust solenoids and other embedded sensors to control valve timing, coolant flow rate, compression ratio, and other key processes in engine operation [52]. Integrated development of these smart controllers with CAN will be crucial to ensuring the safety of autonomous vehicle function execution and travel.

While large scale agricultural mechanization has been associated with various negative environmental impacts, from soil compaction to harmful exhaust emissions, the advent of digital agriculture has played a key role in increased efficiencies and technological progress within the farming sector, reducing those detrimental elements. The utilization of CANs for improved operation is a research area where further development could have a significant impact with respect to environmental effects. For example, some of the most common technologies for limiting emissions have associated environmental costs that detract from ecological benefit. Though Exhaust Gas Recirculation (EGR) decreases NOx emissions, it simultaneously increases specific fuel consumption to lower engine efficiency. Similarly, the post-combustion treatment Selective Catalytic Reduction (SCR) results in better emissions efficiency, but consumes a urea solution that increases freshwater eutrophication risks [53].

Since fuel consumption is primarily dependent on engine speed and torque, it is possible to reliably decrease emissions with the application of alternative driving techniques optimally suited to specific drive train design and implement load [54]. However, the plausibility of deriving accurate efficiency metric assessments is limited due to present data scarcity. Current methods for Life Cycle Assessment (LCA) studies provide unreliable results because average conditions, such as soil texture, field shape, soil moisture, implement transfer difference, and engine features, have traditionally been utilized in lieu of actual conditions to estimate environmental effects [55]. CAN is advantageously positioned to help address both the data deficiency and inadequate LCA techniques, due to its data collection and communication strengths. It is possible, for example, that performance metrics could be improved through intelligent sensor solutions that can measure slippage and soil compaction at the wheels of a vehicle and attached implement [13, 54]. These sensors could communicate with sensors in the drivetrain to adjust the effective gearing ratio in real-time, reducing soil compaction and preserving the long-term viability of the soil.

An example of an instrument that, when paired with CAN-BUS communication, could be useful in achieving such operational efficiency objectives are inertial measurement units (IMUs). An inertial measurement unit functions as a sophisticated accelerometer/gyroscope combination. It boasts near zero drift between different operating conditions, and its use of magnetic fields allows it to double as an “electronic compass”. The IMU allows for communication across many different CAN-BUS networks to help the tractor, or any vehicle, make decisions about how to alter the driving style for the terrain to limit “dynamic pitch and roll” through open system communication [52]. While this specific system is not currently implemented on tractors and other off-road vehicles, there is room for its introduction in the emerging field of agricultural autonomy.

Smart agriculture and digital farming practices have gained popularity in the previous decade. These techniques are precursors to a transformative implementation of information technology in the farming world. Going forward, more advanced software systems will use information collected from CAN communication devices to aid in the optimization of machinery designs and more accurate load, use-profile, and duty cycle representations of vehicles and implements [18]. Future applications for CAN-BUS technology include IoT, Edge Computing, and swarm machinery automation, as well as complex control of electrical and electric-hybrid machinery.

IoT implementation in the agricultural sector has gained enormous traction in recent years, as a result of its high potential for cross-brand interoperability, scalability, and traceability. The different types of IoT tools being applied are continuing to evolve, increasing the overall adaptability and variety of available systems to end-users [56]. IoT systems are currently being implemented on vehicles from John Deere, Case New Holland (CNH), AGCO, and others. Future IoT device use on agricultural equipment will likely be in conjunction with multiple on-board network systems. Local storage or cloud computing will be necessary to store and process the vast amount of data created by this potential technology [57]. Data processing on-board the vehicle, near the working equipment, is referred to as ‘edge computing’ [56, 58]. It is highly probable that agricultural vehicles will eventually be able to perform a variety of complex, agronomic tasks from a preprogrammed routing structure, through the combined utilization of both IoT and EC technologies.

In addition to on-vehicle IoT technologies, it is probable that field embedded (or in-situ) IoT sensors will also be able to communicate with larger on-farm networks [59]. Several of the previously discussed network configurations are possible whole-farm network options. These include cellular (4G, 5G, and beyond), Wi-Fi, ZigBee, and UWB. For example, real-time soil moisture can be obtained from field-based, connected sensors to create a variable-rate prescription map [60]. Utilized in conjunction with mobile soil penetrometer readings, an accurate map of soil compaction risk can be created. This could allow farmers to tailor their tillage operations to specific areas of the field, as well as control vehicle traffic.

Cutting-edge networking research is also being done with robotic and swarm machinery automation [61]. IoT technologies and improved connectivity will allow for the introduction of robotic swarm farming techniques. Swarm farming incorporates multiple, small-scale robotic platforms that perform farming operations autonomously in place of larger, manned agricultural equipment. This farming strategy, paired with a predetermined path-planning algorithm optimizing how the machines will navigate throughout the field, could allow for near-continuous field operation. Additional benefits could include a centralized command center that is controlled by a single system manager and a significant reduction in the need for skilled labor [62]. The possibility of substituting the modular vehicle design within swarm farming for traditional larger equipment will depend on cost, comparative system productivity, and accuracy. Farmers will demand a significant return on investment and the reliability that they have come to expect from their current machinery. A potential difficulty for CAN-based systems is the large bandwidth requirement for incoming and streaming data. Another potential challenge involves communication protocol differences between traditional CAN-BUS data and more memory intensive data collected from advanced machine systems, like perception engines and central processor-based codes [63]. Future developments in CAN-BUS technology should focus on addressing these weaknesses to improve adaptability to upcoming applications.

A major concern in the future of agricultural CAN use, machinery networking, and machine system automation is cybersecurity. Although increased digitization, automation, and precision services have tremendous potential to establish sustainability and profitability in farming systems, the influx of interconnected information technology simultaneously opens the market up to new areas of susceptibility, security risks, and potential targeted cyber-attacks [58]. Mission-critical systems are becoming more reliant on internet connectivity, such as controlling farming implements remotely through the ISOBUS with linked management software. Local Area Networks (LANs) have become a requirement in smart farming to enable system/device access to the data and services that control their functions [64]. This increased dependence of agricultural operations on cyber-physical systems has led to the development of new, novel threats and challenges that can be analyzed in two categories: information technology and agricultural production [58].

From an informational technology standpoint, some of the main threats are unauthorized access of resources/databases under use of falsified identity, interception of node data transfer, facility damage or downtime, malicious data attacks from malware, and compromised control systems to negatively impact decision-making [58]. Due to the nature of modern networked food systems, targeted or accidental disruption of time-sensitive agricultural processes could have a significant economic impact on a global scale. The threat of a concentrated hack on the agricultural sector has become more tangible with the analysis of cyber-security breaches in recent years, such as the 2017 infrastructure meltdown of Maersk shipping [65]. The vulnerability of Wireless Local Area Networks (WLANs) to direct cyber-attacks is already a generally recognized problem across all industries [66]. Demonstration of the damage potential in a Denial of Service (DoS) attack has been shown in the research of Sontowski et al., by disrupting in-field sensors and obstructing device network connectivity in smart farm operations [67].

Though the hacking activities of malicious actors is a highlighted concern in cyber security, there are also a number of risks associated with agricultural production that stem from physical layer vulnerabilities and limited user knowledge. The harsh environment in which agricultural equipment is used (including extreme weather conditions, dust concentration, and highly variable humidity/temperature fluctuation) can cause power failures or sensor damage [64]. Technology signal interference from other agricultural equipment, such as the high voltage pulses from Solar Insecticidal Lamps (SIL), can also lead to malfunctions and data loss [58].

However, one of the most common threats to cyber security is inadequate adoption of safety procedures by farmers who lack full awareness of device functionality. From research conducted by Nikander et al., farmers are often ill-equipped with time and resources to build LANs with appropriate network equipment, topology expansion planning, and protection software/hardware [64]. This leads to networks that are at risk of system losses due to hardware issues and human error. The adoption of countermeasures to security risks, such as authentication & access control, cryptography, key management, and intrusion detection systems, is dependent on end-users understanding the importance of cybersecurity, and better fail-safe mechanisms within hardware [58, 64]. These concerns highlight the importance of advancing security protocols in CAN-BUS systems, and it is likely that this will be a targeted focus in the future of CAN developments.

5. Conclusions

Key points from this chapter included the following:

• CAN-BUS has played a major role in industry since its debut in 1987 for its groundbreaking use of distributed network principles.

• The establishment of international societies and standards positioned CAN-BUS as the leading serial network system in all vehicles.

• CAN-BUS provides efficient and dependable communication pathways through front and back end context in messaging, error confinement, higher-layer protocols, and subsystem differentiation.

• CAN-BUS has revolutionized data collection and analysis in multiple industries, especially in the agricultural sector.

• When paired with wired or wireless technologies, CAN is an advantageous communication pathway for expanding the reach of data communication beyond point source limitations.

• Challenges for future CAN iterations include increasing bandwidth and security measures, while decreasing latency and hardware vulnerabilities.

This chapter has reviewed CAN-BUS technology including its invention, early applications, fundamentals, and standards development. Early applications of CAN-BUS came from European car manufacturers, which incorporated electronic control units for engine care management. The development of standards to allow consistent communication methods within CAN-BUS systems, such as ISO 11898, SAE J1939 and ISO 11783, were important for allowing serial networks to be applied within multiple vehicle types and industries. Modern day uses, alternative connectivity and networks, and potential future applications have also been examined. Controller area networks are responsible for the transmission, logging, and analysis of engine and machine system data currently used by vehicle manufacturers. Understanding CAN-BUS communication protocols provides insight into the advantages, uses, and future evolutions of distributed control networks.

CAN-BUS technology fundamentals, such as physical and data message structures, components, error handling, and message channel support are useful in understanding the strengths and limitations of CAN systems. Through the use of high and low speed CAN-BUS configurations, arbitration codes, and broadcast style communication, CAN-BUS can efficiently and reliably transfer messages across a vehicle’s control system to ensure accurate, real-time data communication. As electronic connectivity has increased the sophistication of off-road vehicle operation management, new applications using CAN with external networks have been an important area of communications advancement within the agricultural sector. The development of converters between CAN data and other wireless data types has been important in keeping CAN-BUS integrated and relevant in the vehicle fleet telematics expansion. More research into wireless CAN may be an important direction for serial network technology going forward.

Specific CAN-BUS applications in ongoing autonomous vehicle development research include component data consolidation, embedded sensors, IoT devices, and machine-to-machine communication strategies. Future technologies that might benefit CAN-BUS technology by their incorporation include local-to-cloud data transmission, autonomous swarm vehicle management, and increased cyber security protocols. Although controller area networks face limitations within both bandwidth and latency, they still function as effective inputs to more advanced vehicle systems and more sophisticated remote networks. The potential of CAN-BUS technologies has clearly not been fully exhausted, and they will continue to play an important role in the advancement of agricultural machinery and farming practices.

Acknowledgments

We would like to acknowledge our fellow classmates from Dr. Stwalley’s Fall 2020 Off-Highway Vehicle Design class at Purdue University’s School of Agricultural and Biological Engineering for their contributions to the structure and content of this technical chapter.

Conflict of interest

The authors declare no conflict of interest.