Abstract: This paper systematically studies the key technologies of interconnecting CAN bus and Ethernet. First, it analyzes the difficulties encountered in the implementation of interconnection technology—protocol conversion. Then, it proposes a design scheme for interconnecting CAN bus and Ethernet systems and elaborates on its hardware and software implementation methods. To improve system performance, an embedded transparent gateway is designed using the high-speed microcontroller SX52. The method of implementing the SX52 on the TCP/IP protocol stack is described in detail, and the strong network protocol processing capabilities of the SX52 ensure the improvement of the overall system performance. Keywords: CAN, Protocol conversion, Gateway, SX52 Abstract: This paper discusses the gist of CAN bus and internet Ethernet network technology. First, we analyze the difficulties when the protocol is transformed. Second, we propose a systemic design schema and implementation. In order to improve system performance, we select SX52 with a high-speed micro-controller to design an embedded gateway. At the same time, we introduce how to use SX52 to realize TCP/IP protocol and improve the performance of the network processor so that the system can work well. Keywords: CAN FieldBus, Protocol conversion, Gateway, SX52 1 Introduction The development of science and technology and society has made global market competition unprecedentedly fierce at the end of the 20th century. Enterprises in the competition gradually began to implement computer integrated manufacturing systems, adopting the concepts of system integration and information integration to organize industrial production. In this system, to realize multi-point digital communication between intelligent field devices, computer measurement and control technology and computer networks are closely integrated, resulting in FieldBus technology, which can operate in industrial field environments, has reliable performance, and low cost. Fieldbus is the lowest-level communication network used in manufacturing environments. It enables bidirectional, serial, multi-node digital communication between microcomputer-based field measurement and control instruments or devices. The key to fieldbus technology is enabling automatic control systems and field devices to communicate, connecting them into a network system, and integrating the field communication network with the control system. As a network system, it has an open and unified communication protocol. CAN bus is a mature technical standard developed from fieldbus technology in industrial applications. Its protocol is based on the ISO/OSI model, but only uses the physical layer, data link layer, and application layer. In large enterprise automation systems, the upper management and production monitoring layers typically use Ethernet and PCs, while the lower workshop floor uses fieldbus and microcontroller-based measurement and control equipment. Communication between these two layers is usually achieved using an industrial control computer with an Ethernet card, plus an interface card in the PC slot or an EPP interface card with a parallel printer port. This connection method is costly and has a long development cycle. To address this, we designed a separate CAN Ethernet gateway interconnection system, successfully achieving direct data interconnection between Ethernet and existing CAN bus networks. 2. System Overall Design The CAN bus is a device interconnection bus-type control network. Up to 110 device nodes can be connected to the CAN bus, and these devices can communicate autonomously with each other to realize complex network control systems. However, the device information layer cannot directly reach the information management layer; a data gateway is needed to allow device information to enter the information management layer. Here, we designed an SX52 gateway for interconnecting the CAN bus and Ethernet. The system is generally divided into three parts: the field measurement and control network (CAN network), the embedded transparent SX52 gateway, and the Ethernet information management terminal (such as a monitoring platform and network database). The Ethernet information management terminal communicates with the CAN nodes on the CAN bus through ETHERNET, the SX52 gateway, and CANBUS, with the SX52 gateway playing a core role in interconnecting heterogeneous networks. Protocol conversion is a key technical challenge in heterogeneous network interconnection. Protocol conversion can generally be performed using a layered conversion method, proceeding from the lowest level upwards. Currently, most interconnections are implemented at the Internet or Network layer. Therefore, it is necessary to convert the protocols below the interconnection layer upwards layer by layer. This conversion method is based on the fundamental principle of protocol layering: lower layers support higher layers, higher layers call lower layers, and when a lower layer disconnects, the higher layer connection also disconnects, but the disconnection of the higher layer does not affect the lower layer. From the perspective of network layering structure, our designed interconnection system has the layered structure shown in Figure 1. The TCP/IP protocol runs on Ethernet, which has an application layer, transport layer, network layer, Ethernet data link layer, and physical layer; the CAN bus has an application layer, data link layer, and physical layer, where the application layer is defined by the user, and the data link layer and physical layer are defined by the CAN protocol; the SX52 data gateway has a physical layer, data link layer, and application layer. Its application layer is the data exchange layer between Ethernet and CAN. The SX52 microcontroller interprets and forwards data from these two different protocols at this layer. Figure 1 shows the network layered structure of CAN bus and Ethernet interconnection. In this design, the SX52 gateway is designed as a transparent data gateway, meaning that it constructs and parses complete CAN protocol data packets at the Ethernet application layer. The CAN protocol data packets are transmitted as data at the TCP/IP network application layer, without explaining the specific practical meaning of the communication data. The reason for designing the data gateway as transparent is based on the following three considerations: 1) Transparent gateway design is simpler than opaque gateway design. Hardware-wise, there is no need to expand with large-capacity data storage for buffering communication data; software-wise, there is no need to consider data aggregation and distribution processing, reducing program complexity and improving communication speed and real-time performance. 2) Transparent gateways are highly adaptable and can be applied to different project requirements, while opaque gateways require different modifications to the gateway program according to different requirements. 3) Because the protocol conversion design is simple and involves less complex processing, communication reliability is improved. The maximum communication rate of the CAN bus network is 1 Mbps, while Ethernet is currently generally 10 Mbps. Here, the speed matching problem between the two needs to be considered. This can be solved in two ways: one is to use a larger RAM on the gateway as a communication data buffer to improve network transmission efficiency. Second, the amount of data transmitted from Ethernet to the CAN bus is limited to be less than the communication rate of the CAN bus. 3. CAN Protocol Analysis CAN follows the OSI model. According to the OSI baseline model, the CAN structure is divided into two layers: the data link layer and the physical layer. According to the IEEE 802.2 and 802.3 standards, the data link layer is further divided into: —Logical Link Control (LLC) —Media Access Control (MAC) The physical layer is further divided into: —Physical Signaling System (PLS) —Physical Media Access Attachment (PMA) —Media Dependent Interface (MDI) The MAC sublayer operates under the monitoring of a management entity called the "Fault Definition Entity (FCE)". Fault definition is a self-checking mechanism that makes it possible to distinguish between transient interference and permanent faults. The physical layer can be monitored by the Physical Media Fault Detection and Management Entity (e.g., bus short circuit or interruption, bus fault management). The two equivalent protocol entities, LLC and MAC, communicate with each other by exchanging frames or Protocol Data Units (PDUs). The functions provided by the LLC sublayer include: frame reception filtering, overload notification, and recovery management. The overload notification function allows for the transmission of up to two overload frames via the LLC sublayer if internal receiver conditions require a delay in the next LLC data frame or LLC remote frame. According to the OSI seven-layer model, the CAN bus network completes the work of the bottom two layers: the physical layer and the data link layer. These layers are implemented by the CAN controller's hardware, handling level conversion and frame encapsulation. In practical applications, a custom upper-layer protocol is required. A simple and practical "command item + data item" structure is designed here, with its complete data frame structure shown in Figure 2. Considering that industrial control functions are generally limited, the command item length is set to 1 byte (capable of describing 256 commands). The data length is set in the data item because the CAN bus transmits short frames (each data frame is only 8 bytes). Some commands may require more than 7 bytes of data parameters, and the returned data may also be large. Therefore, setting a one-byte data length item allows users to define a data frame length of up to 256 bytes. 4. SX52 TCP/IP Protocol Stack Design The ARP protocol enables dynamic mapping from logical addresses to physical addresses. Each Ethernet interface supports a unique 48-bit physical address. In SX52, the ARP protocol is implemented through a single-register core that maps IP addresses to Ethernet addresses. When a remote host needs to know its physical address, it sends an ARP request, and SX52 responds by providing its own physical address. When the application layer needs to transmit IP packets, the SX52 ARP protocol can also request the remote destination physical address. The Internet packet to be transmitted is constructed in the Ethernet controller's transmit buffer, using the destination Ethernet address of the most recently received packet as the destination address. However, this may not be the correct Ethernet address. Therefore, before actually sending the packet, the ARP protocol checks if the IP address in the packet exists in the ARP core. If the IP address is in the core, the packet in the Ethernet transmit buffer is updated with the Ethernet address in the ARP core. If not, the ARP protocol sends an ARP request packet and waits for a response. Once an ARP reply is received, the ARP core will update the target Ethernet address using the received address. Then, any packets waiting to be sent will also be updated using this Ethernet address and sent. If the sent ARP request packet does not receive a reply, causing the ARP timer to time out, the packets waiting to be sent will be discarded, and the normal protocol stack will continue to operate. The IP protocol is the core protocol in the TCP/IP protocol suite. All TCP, UDP, ICMP, and IGMP data are transmitted in IP datagram format. IP provides unreliable, connectionless datagram delivery service and cannot guarantee that IP datagrams will successfully reach their destination. If an error occurs, such as a router temporarily running out of buffer space, IP has a simple error handling algorithm: discard the datagram and then send an ICMP message to the source. Any required reliability must be provided by the upper layers. Connectionless means that IP does not maintain any state information about subsequent datagrams; the processing of each datagram is independent. This also means that IP datagrams can be received out of order. In this design, the IP protocol is a reasonable simplification for a specific application environment. The CAN bus control network is a short-frame, real-time network, so IP packets do not need to be fragmented (MF=DF=0). Simultaneously, the IP service type is set to general type, with a header length of 20 bytes, a header length field of 5, and a TTL of 64. TCP provides a connection-oriented, reliable byte stream service to the application layer. For industrial control applications, the complex TCP protocol can be reasonably simplified because the CAN network has a high transmission speed, small data volume, and 10 Mbps Ethernet transmission generally does not experience congestion; the host on the Ethernet also has sufficient capacity to process communication data promptly. Therefore, the timeout and retransmission time can be fixed at 5 seconds. Furthermore, the RTL8019AS has two 1500-byte receive buffers, and since the CAN network is a control network with small information volume, the receive window can be fixed at 1400 bytes. The design uses a general TCP service to meet the application requirements, so the values ​​of the urgent pointer, options, and padding fields can be ignored. These three simplifications significantly simplify the implementation of the TCP protocol, as determining the TCP timeout and retransmission times and controlling the window size involves complex algorithms and implementation mechanisms. 5. Summary of Innovations The innovation of this paper lies in addressing the shortcomings of traditional industrial control automation fieldbus connection methods, such as high cost and long development cycle. A separate CAN Ethernet gateway interconnection system was designed, successfully achieving direct data interconnection between Ethernet and existing CAN bus networks. By connecting the fieldbus to the Internet and enterprise intranets, the automatic control system and field devices become an integral part of the enterprise's comprehensive automation and information system. The system has significantly improved in terms of openness, interoperability, field device intelligence, system architecture, and adaptability to the field environment, successfully achieving data communication between two dissimilar networks. References: [1] Zou Yiren, Ma Zengliang, et al., Design and Development of Fieldbus Control System, 2003, National Defense Industry Press [2] Zheng Wenbo, Control Network Technology, 2001, Tsinghua University Press [3] Ed. Taylor, translated by Zheng Yan and Deng Ling, Network Interconnection Technology Guide, 2001, People's Posts and Telecommunications Press [4] Li Ming, Design and Development of Embedded Interconnection Network Interface, 2002, Industrial Control Computer [5] Deng Zunyi, Ning Yang, Liu Baoguo. Design of Distributed Robot Control System Based on CAN Bus. Microcomputer Information [J]. Volume 22, Issue 6-2, 2006: Pages 254-256