New Can Bus Communication Modules for Digitizing Forest Machines Functionalities in the Context of Forestry 4.0

In line with the context of Industry 4.0, forestry, and in particular the entire ecosystem around it, also needs digitalization solutions in order to allow better interaction between all agents that work and live from the forest. It is important for a better management of forest resources allowing productivity gains, more sustainability and resilience. One of the agents that can benefit, but also contribute to better forestry, are machine producers. With digitalization, the machinery is now equipped with new and better sensors that can be used not only for machine operations but also for forest management, through LiDAR (Light Detection And Ranging) or RGB (Red, Green, Blue) cameras for example. On the other hand, there are new needs for predictive maintenance or solutions for remote assistance of machines operating in the forest, typically in isolated areas with great limitations in access to communications. Thinking about these technological challenges, this work seeks to provide answers with communication solutions in forest machines, enabling the digitalization of functionalities, also allowing remote access to machine controllers in order to provide them with connectivity in an IIoT (Industrial Internet of Things) scenarios. New hardware modules designed in partnership and according to the prerequisites of a forest machine manufacturer are presented. These modules are a step towards digitizing the machines and opening up the scalability of new requirements, as well as remote access through additional gateways. The results already obtained in real scenarios show that these modules can be a concrete solution for the current and emerging needs of industrial machine manufacturers.


I. INTRODUCTION
The 4th Industrial Revolution is characterized by the combination of physical and digital technologies [1] leading to the so-called Cyber-Physical Systems (CPS) [2], which interconnects several systems through the Internet of Things (IoT) for real-time data acquisition, virtualization and decentralization of decision making. The concept introduces innovative technological solutions, with emphasis on the digitalization for processes and products, which sideways with the Industry 4.0 main characteristics, such as, IoT, Artificial Intelligence (AI), Automation, Big Data, Machine Learning, Cloud The associate editor coordinating the review of this manuscript and approving it for publication was Bo Pu .
Computing, Cyber-security [3], will bring out smart factories, smart machines, smart storage facilities and smart supply chains [4], granting greater quality and efficiency, increasing the productivity and improve tasks of decision making, not only for industrial companies but many others technological branches where the features of Industry 4.0 can be implemented.
From the current industrial revolution (I4.0) a new concept emerges, Forestry 4.0 [5], that along with the Industry 4.0 main features will contribute for a greater efficiency, conscious forest management and continuous development and upgrade of the forest machines. These concepts allow the acquisition of forest data for monitoring and analysis of activities carried out by a machine or group of machines in real time [6]. Towards the technological changes, forest industry may go from the traditional disconnected systems and low technological industry to systems more modular, intelligent and inter-operable, allowing the continuous communication among all the stakeholders [7].
Nonetheless, the forest industry faces geographical access and terrain conditions issues, lack of energy and means of communication [8], therefore for the Forest 4.0 concept implementation some features must be established, as information and communication infrastructure systems and the digital sensing implemented at all levels of the forest supply chain, starting by the digitalization of all the involved agents, the network infrastructure establishment for data transmission, implementation of next generation systems intelligence (AI, Machine Learning) to support Cyber-Physical operations and the connectivity for the supply chain and interoperability [7].
Manufacturers of agricultural and forestry machinery have realized the benefits of digitalization in their sector, so they are focused not only on digitalizing manufacturing processes, but also on improving the products they produce to face an increasingly demanding market in terms of digital functionalities.
On the forest sector, due to the hostile environment in which the machines operate, several problems may arise, caused by several factors, whether these accidents or due to the bad operation of the machines, requiring the need for assistance from the manufacturer, which adds costs with the need for displacement and maintenance. It is difficult for machine manufacturers or dealers to send a technician into the forest to try to fix a machine, sometimes in different countries, identify the problem, try to fix it, and don't have all neeeded resources to solve it, need to come back another day, with all the costs and constraints that result for customers and companies. In this scenario, a remote prediagnosis is the solution to identify the problem and the need for resources (technical characteristics, equipment, etc.) before moving a technician to the forest. It is to respond to this need that emerges the SMARTCUT (Remote diagnosis and maintenance and simulators for operation and maintenance of forest machines) project [9]. The objective is the design, develop and implement a solution for sensing forest equipment based on the CAN Bus protocol aligned with the Industry 4.0 for tele-diagnosis, tele-maintenance and forest data monitoring.
The sensing forest equipment's are developed as modular units to standardize the CAN Bus Communication between the sensors and actuators of the forest machines to its main controller, providing higher flexibility, scalability and reduction on cable costing and costs associated with the maintenance and diagnosis, since the modules will be able to communicate through a mobile network with a LTE/CAN Bus gateway that will allow remote access for supervision and data analysis through standard message protocol for IoT (OPC UA or MQTT) [10]. The first technology developments for this project are presented in [11], where the initial communication modules that are the boosted for the work presented in this paper were presented.
The main contribution of this work focuses on the development of hardware modules for standardized communications under the CAN Bus protocol, allowing communication between forest machine controllers and the different sensors/actuators that constitute it. These modules enable remote access to the sensors/actuators of the machines through a CAN Bus/LTE gateway.
The remainder of this paper is organized with the following structure: Section II presents the State of the Art, section III describes the methods employed to standardize CAN Bus communications on forest machines, Section IV presents the results of hardware and software developments and Section V presents the main conclusions and future works.

II. STATE OF THE ART
With the rapid advance of technology, the increase of the electronic systems' functionality, and amount of ECU's connected in a single bus for communication, the CAN bus protocol itself may cause certain problems such as bus overload and may no longer be considered a viable solution for Electronic Control Units (ECU) communication. Therefore, Higher-layer Protocols based on CAN emerges as Society of Automotive Engineers J1939 (SAE J1939) [12], CANOpen [13], On-Board Diagnosis (OBDII) [14], Isobus [15], CAN FD [16], etc., for data monitoring, control and diagnosis [17], [18].
In brief, each of these Higher-Layer Protocol is intended for a purpose, OBDII is standard protocol for diagnosing problems in cars system and subsystems via ECUs. SAE J1939, is the recommended protocol for communication and diagnosis interaction among ON and OFF the road heavy-duty vehicles (e.g., trucks, construction vehicles, cranes. . . ) [17]. CANOpen, is essentially used in industrial automation and embedded control systems applications, ISOBUS is the standard protocol for control and communication on forestry and agricultural tractors, based on SAE J1939 protocol, with its main goal to standardize the method and format for data transmission between sensors, actuators, information storage and display units [19] and the CAN Flexible Data-Rate (CAN FD), which is still on the rise, since the classic CAN has a limited data frame of 8 bytes, and with the rise of the amount of information provided by the ECU's, and the increase of Electrical Vehicles and Hybrid Vehicles demand for higher bit rates and more complex control units, the protocol will provide higher bit rate, up to 5 Mbps and provide up to 64 bytes data frame [20].
Currently, all of the agricultural and forest machinery integrate CAN Bus system, due to its less complex electronic circuit controls, for allow high performance precision and providing logistics information, through real-time data that helps estimate operation costs (e.g., fuel consumption, average operating speed and engine load), better decisionmaking, transport efficiency and develop lower cost equipment's, according to operational events registered. With the conjunction of the CAN and Telematics protocol, it becomes possible that all the data collected be integrated into a server network for wider usage and analysis [18].
When it comes to Forestry 4.0 applications CAN can be seen as the base protocol provider of data for information and decision-making, as in [21] and [22], where is developed a prototype for fault tolerance and remote maintenance over mobile networks for agricultural machinery equipped with ISOBUS, where the service provider could analyze the faults online based on the state information sent automatically by the machine controller.
In [23], data as vehicle speed, engine speed, engine coolant temperature and others driver's behavior from CAN bus can be monitored, analyzed, calculated and reported via wireless communication, more specifically via Bluetooth and can also be displayed on a LCD screen.
In [24], a simulation of an agricultural machine vehicle is presented using Higher-Layer CAN protocol (SAE J1939 and ISOBUS) and their network performance compared using classical CAN and CAN FD (CAN FD 8 B and CAN FD 64 B), where it was proved that due to CAN FD faster bit rate and larger data field was a more suitable option to replace classical CAN protocol in SAE J1939/ISOBUS networks, since it allowed faster transmission, presented lower bus load usage leading to better response time and short jitter.
In [25], where the process of Farm Management Information Systems (FMIS) is automated for agricultural machinery for small and medium size farms, by recording ISOBUS and SAE J1939 data from specific parameters at transportation, soil cultivation, plant protection and fertilizer application operation, and posteriorly transmitted to a cloud-based server by a 3G Machine-to-Machine (M2M) gateway, to acquire, analyze and aggregate the datas to a specific agricultural task.
In [26], the feasibility of OPC United Architecture (OPC UA) is tested to transfer ISOBUS related data from a tractor and a connected seed drill over a 3G gateway connection where a Data Dictionary Object Pool (DDOP) is designed to link both protocols and provide remote access for vehicle location and current vehicle activity in real-time to the vehicle manager.
In [27], the trafficability of the extraction trail is evaluated by using CAN data continuosuly collected by forest machinery, aiming to develop low cost solutions to be piloted and applied to forest machine production. Collection of data that can help the machine's operator to avoid heavy loading on soft areas and by equipping the machines with an automatic trafficability system will influence the rapid data collection in varying site, soil and weather conditions, leading smart harvesting, conscious forest operations and sustainability aligned in Forest 4.0 characteristics.
Many of the related works here mentioned are aligned not only with Forest 4.0 concepts as they are aligned with the Higher-Layer Protocols based on CAN Bus, in particular SAE J1939 and ISOBUS, which are the main protocols used in heavy-duty vehicles and agriculture and forest vehicles [28]. Any of these protocols could be implemented in this project, however, for the machine manufacturer it is important to have access to controllers, sensors and actuators at a lower level, at the physical and data link layer, hence the option for the CAN Bus. It should also be noted that the CAN Bus is the native protocol in vehicle communications, whether industrial, such as machines, or more commercial, such as cars.

III. METHODS
This section describes the methods and materials used to standardize CAN Bus communication between sensors/actuators and the main controller of a forestry machine. A detailed description of the CAN Bus is presented in the following subsection.

A. CONTROLLER AREA NETWORK (CAN BUS)
CAN is a serial bus system with message and multi-master based protocol introduced by Robert Bosch in 1986, firstly introduced for the automobile industry. Although, due to its high robustness, higher safety in communication, higher bit rate and the capability of reducing the cabling and numbers of components associated with the equipment's carrying the CAN systems, it now covers many others technologies branches [29].
The CAN Bus protocol is characterized by Open System Interconnection model (OSI) by the two first layer [30], Physical layer where the cable type and length, termination resistor, node requirements and electrical signal level are determined, and the Data Link layer, where the messages format, error's detection and prevention mechanisms are provided [31].
The CAN Bus physical layer specifies a twisted-wire pair, responsible for the communication, with a 120 termination resistor that ensures the perfect propagation of the electrical signals, with a maximum bit rate of 1 Mbps for a 40 meter cable length, as the cable increases the bit rate decreases. For cables with up to 100 meters, is recommended that the product of the bit rate and the bus length, must be lower or equal to 50, as the equation: [32] The communication on the bus line is realized by a 2.5 V voltage differential between the two twisted-wire pair, CAN High and CAN Low operating at 3.5 V and 1.5 V respectively, representing the Dominant '0' bit. However, when the CAN Bus is in idle mode both lines present a 2.5 V, representing a Recessive '1' bit, as represented in the Figure 1: [33] and [34] The CAN Bus contains nodes capable of transmitting and receiving CAN messages as long the bus is available or any message is available in the bus respectively. These nodes must contain a Microcontroller Unit, a CAN Controller that can be disposable if it is included in the microncontroller used, and a transceiver. The microcontroller functions as the node's brain, being responsible for connecting sensors/actuators and interacting with the CAN Bus. The microcontrollers with a built-in CAN Controller reduces the processing time from the CAN Controller device to the microcontroller [33].
CAN Controller is responsible for converting data provided by the MCU (Microcontroller) or received from the CAN Bus into CAN message frame or into a MCU readable data respectively. And the transceiver drives and detects data from the bus, converting the single/ended logic used by the CAN controller to the differential voltage signal transmitted on the bus and vice-versa [33]. In short, the physical layer of the protocol is described by the following architecture represented in Figure 2: At the second layer for the CAN Bus protocol, four types of frames are introduced: [18] • Data Frame where the transmitting node data is found. • Remote Frame message sent to request data from a specific node; • Error Frame transmitted by any node whenever an error is identified on the bus; • Overload Frame message sent from an overloaded node to generate delays in the data frame or remote frame, to finish its processing. The protocol, presents two versions, CAN1.0 and CAN2.0, as the second version is divided in two formats, Standard frame (CAN2.0A) and Extended frame (CAN2.0B), differing from one another essentially by the bit numbers in the Identifier field, where CAN1.0 and CAN2.0A only allows up to 11 bits identifiers, allowing up to 2048 unique messages, while CAN2.0B presents up to 29 bits, allowing up to 536 millions messages on the bus respectively [35].
Both of the formats can operate in the same bus, although the Standard frame messages have priority over the Extended frame messages, and the Identifier field takes charge of the bit-wise arbitration [36], where the dominant bits overwrites the recessive bits, therefore, as lower as the ID is, the higher is the priority.
The Standard protocol message frame presents some essential fields for the proper transmission and reception of CAN messages as described next [18] and presented in Figure 3: • Start of Frame (SOF), signals the start of a CAN message by a node, characterized by a Dominant '0' bit; • Identifier (ID), determines the transmitting node address and establishes the priority of the message on the bus. Introduces a 11 bit for Standard messages and 28 bits for Extended messages; • Remote Transmission Request (RTR) is a 1 bit field, that indicates whether the node is transmitting or requesting a message from a specific node; • Identifier extension bit (IDE), determines the size of the message, whether is a Standard or Extended message; • r0, reserved bit field for future amendments; • Data Length Code (DLC), a 4 bit field that determines the Data bytes' number to be transmitted; • Data presents the message information with up to 64 bits message; • Cyclic Redundancy Check (CRC),; • Acknowledgment (ACK), presents two bits (ACK Slot and ACK Delimiter), where the transmitting node writes two recessive '1' bits, while the receiving node overwrites the ACK Slot bit if the data is properly received; • End of Frame (EOF), signalizes the end of the the message transmitted by a 7 bit flag; • Interframe Space (IFS), responsibel for moving a message to a corresponding buffer, if the message is correctly received; However, the Extended format frame introduces some new fields as demonstrated next [37] and presented in Figure 4: • Substitute Remote Request (SRR), replaces the RTR bit in Standard message location as a placeholder in the Extended format; • Identifier Extension (IDE), a recessive '1' bit that indicates that additional 18 bits follows; • r1, reserved for future amendments for Extended format messages.

B. METHODOLOGY FOR THE DEVELOPMENT OF I/O MODULES
This subsection addresses the main technical aspects for the development of new hardware modules for machine command joysticks as well as I/O modules for the sensors/actuators of the forestry processor coupled to the machines. The modules will allow remote access and provide greater flexibility and scalability, since they are modular, growing in unit and depending on the requirement of one more input or output. This makes it easier to upgrade machines with new features, without having to completely replace an input/output module, just add the needed units.
These modules can be seen as CAN nodes, characterized essentially by the implementation of a PIC18F26K83 microcontroller and a MCP2551 transceiver, two devices fabricated by Microchip Tecnhology Inc.,where the CAN controller hardware device is not included as an external device, since it is built-in in the microcontroller mentioned. The ECU was selected for its vast library for the CAN protocol, built-in CAN Controller allowing its direct connection to transceiver and its low-cost [38]. And the MCP2551 transceiver for being suitable for 12 V to 24 V systems, its high noise immunity and support up to 1 Mbps [39].
For monitoring the data flow on the bus, the Microchip Technology Inc. CAN BUS ANALYZER was used for monitoring, development and high-speed CAN network debug. The tool also provides a graphical interface where all the CAN Bus data can be observed and where data can be inputted for transmission.
The joystick modules are set to transmit digital and analog data from the module's sensors status continuously. Although, since the module is being developed from scratch, the data can be considered as raw, therefore there is the need to calibrate and organize the transmitted data to ease the data interpretation. The data field was determined according to Figure 5, being the first two bytes (Byte 0 and Byte 1) reserved for digital sensors status only, while the remaining bytes correspond to the proportional module (analog) signals, as the last two bytes (Byte 6 and Byte 7) present the proportional module calibrated values, according to the following Figure 5.
By using CAN ANALYZER feature to transmit CAN message, it was made possible to configure the module's ID, bit rate transmission and as an to transmit or receive mode for the I/O modules, through CAN messages characterized for the module's current ID with the Data field full filled where Byte 4 distinguishes rather if it is a message for ID configuration or transmission bit rate, and Byte 4 and Byte 5 to configure as a transmitter or receptor the I/O modules, and the last Byte reserved to select the intended configuration characteristics.

IV. RESULTS AND DISCUSSION
In this section, the results of the prototyping of the joystick and Remote I/O modules for data acquisition from sensors/actuators in harvesters will be presented, as well as their configuration by software.
One of the project assumptions is the development of module for the handling joysticks found in the operator's cabin, it is determined that the module must have a circular shape so it can be attached to the equipment's base.
The joystick equipment currently used presents four push-buttons and one proportional module (spring centered potentiometer) with integrated directions switches. However the developed module is not limited to the exclusive use of the equipment's in terms of inputs, as the module introduces up to 12 connectors for digital signal inputs and two connectors for the proportional signals with 2 direction switches input each. The module introduces the circular shape as required in the project assumptions with a mid-hole for the joystick shaft pass with all the joystick sensors' wire.
Beside the features specified above, the module, in physical terms, introduces protection circuit against polarity switch and short-circuit, and presents LED's to signalize the module status, as it is represented in the following Figure 6: Nonetheless, the joystick handling is currently found attached to a bellows through which the links run. Therefore, for reasons of space and prevention against shocks and for the correct operation of the module a plug-in 3D model have been developed and tested, capable of fitting and fixing the module and all the necessary connections done properly, as the sensors connection are done on the top layer, and the power supply and CAN lines, that are connected to the main controller, realized on the bottom layer of the module, according to the following Figure 7: As for the I/O modules for the head processors and forest fillers, the modules are found currently in a development stage, aiming for modular units that allow the construction of I/O modules in array, providing greater flexibility and scalability whenever the addition of new sensors/actuators is intended and also reduce the existing cabling with the standardization of CAN protocol, since the current communication between the sensors/actuators are   wire-connections, to have the following configuration as represented in Figure 8: As shown in the previous figure, the modules will have 4 pins, for power and for sensor/actuator interface. However, to eliminate the module limitation to a single configuration mode (Input or Output) to read or transmit sensors/actuators data, is introduced the option to configure the module, by multiplexing the signal, through a CAN message, meaning that a single module can be addressed as a transmitting or receiving node, with the following option introduced in the following Table 1, the module also counts currently with the ID addressing configuration:  The module incorporates same features as the joystick modules, in terms of protection against polarity switch and short-circuit so as the LED's to signalize the module status, ON & OFF, in or out of short circuit. But introduces a M8 connector, where two of the pins are reserved for power supply and the other two pins for signalling (as shown in Figure 8), as one is configured for Input signals and the other for Output signals, with their respective LED to signalize the operation mode configured.
The flexibility of the modules is an aspect that has been taken in account, so it is introduced the opportunity of the modules to be addressed, meaning that, the module ID, the bit rate for the CAN messages transmission can be configured and so are the operation mode for the I/O modules, through a predetermined CAN message with the Data Field fully filled and with one Byte where intended configuration subject (ID, BR and I/O) is determined and on other Byte to determine the configuration intended, where the message is identified by the targeted module's current ID.
For the ID configuration the following frame must be sent, with the module's current ID: For the possible ID addressing, the module present up to 4 possible ID's configuration, as shown in the following Table 3: As for the CAN messages transmission bit rate, the module introduces up to 8 configurable mode, including the bit rate determined by default, at 250 kbps, as long as the following message frame is received: Note that, for the bit rate to be changed, it is necessary that the module enters Configuration mode, where no VOLUME 11, 2023   transmission or reception of any message will be realized. Since the Bit Timing Registers can only be changed in the mentioned mode. This happens so that the users do not violate any CAN protocol through programming and no registers responsible for the module configuration is modified while the module is operating [40].
Lastly, the option to configure the I/O module as an input or as an output, to receive or transmit data from/to the CAN Bus respectively is given by the same procedure of ID and bit rate configuration, by receiving a predetermined CAN message (Table 1) where Byte 4 and Byte 5 are given by a '0xFB' message with the last Byte (Byte 7) reserved for the correspondent configuration intended. However, currently, since the module is still in a development stage, it can be configured as an Input or Output, to receive or transmit digital and analog signals, as shown in Table 1.
To dismiss the loss of information relative to the configurations performed when the module is turned off, once the configurations are carried out, they are also stored in an Electrically-Erasable Programmable Read-Only Memory (EEPROM) address, eliminating the need for configuration whenever the module is restarted, to turn the process of configuration and operation more efficient and practical for real-scenarios.   For better understanding of the module's generic operation, by initializing the module, it initially resorts to the EEPROM addresses used to store the ID and CAN Bus speed (bit rate) and the I/O operation, so that the previous configurations established are settled. The process of initialization is described at the following flowchart Figure 10: However, during the module's operation the EEPROM addresses for the ID, CAN Bus speed and I/O mode are continuously verified in case of any modification in the configurations, so that the modules don't need to be rebooted for the new settings to be configured. So is the process of CAN messages transmission, where the current sensors' status are verified and transmitted, and the verification of any message reception, as observed in the following flowchart Figure 11: The transmission process is given by continuously checking all the sensors data and transfer them through a pooling process so the bus is not overloaded. And the reception process is done by checking the bus for available CAN message and interpretation of the message frame to verify whether is a configuration message frame or sensors data message, according to the following flowchart Figure 12:  The joysticks modules were installed in a forestry machine (harvester) for testing and validation of functionality and robustness in real scenarios, in hostile environments. The results prove the functionality of the modules, as well as the flexibility in their installation process, due to the significant reduction in the number of cables, as well as greater agility in detecting faults. After the testing process, this module will go on to production and will become an integral component of this manufacturer's forestry machines. Figure 13 shows the prototype installed on an harvester.

V. CONCLUSION
The main contribution of this paper is the standardization of CAN Bus communication protocol in forest machinery between the sensors/actuators and the machine's main controller, through the development of flexible new hardware modules for the joysticks and Remote I/O modules for the sensors/actuators of the harvesters. In this paper is present the final module result for the joystick modules, responsible for communicating with the machine's main control to report the sensors(push-button and proportional module) status continuously, the module presents a circular shape to be attached to the bottom of the equipment with the development of a plugin 3D to fit and fix the module for proper wire-connections. On the other hand is presented the initial development results for I/O modules essentially characterized by the possibility of configuring the module as an Input or Output, providing flexibility and scalability to the modules whenever the of addition sensors/actuators to the forest machines is planned.
The modules allow ID addressing, transmission bit rate and operating mode configuration (I/O modules), through a predetermined CAN message identified by the ID of the module to be changed in the identified parameters.
In the future, the focus will be on the development and improving the I/O modules with the required I/O configurations assumed in the project incorporated in the PCB module and standardize CAN Bus communication protocol between the main controller to an already acquired LTE/gateway for remote data acquirement to perform data monitoring, data analysis, telediagnosis and telemaintenance and consequently allow the companies to reduce its costs associated with assistance.