1. Introduction CAN (Controller Area Network) is a digital signal communication protocol originally designed by Bosch in Germany to solve the problem of automation system integration in automotive monitoring systems. It belongs to the bus-type serial communication network. Due to the characteristics of the CAN bus itself, its application fields have expanded from the automotive industry to process control, mechanical manufacturing, robotics, and building automation, and it is recognized as one of the most promising fieldbuses. The CAN bus system network topology adopts a bus structure, which is simple in structure, low in cost, and uses passive tap connections, resulting in high system reliability. This design, while ensuring reliable system operation and reducing costs, has the advantages of versatility, real-time performance, and scalability. 2. System Overall Scheme Design The entire CAN network consists of a host computer (which is also a network node) and various network nodes (see Figure 1). The host computer uses an industrial PC or a general-purpose computer. It can not only use the rich software of ordinary PCs, but also adopts many protection measures to ensure safe and reliable operation. Industrial PCs are particularly suitable for use in harsh industrial control environments. The host computer exchanges information with each network node through a CAN bus adapter card, and is responsible for monitoring the entire system and sending various operation control commands and setting parameters to the slave computer. A network node consists of a sensor interface, a slave computer, a CAN controller, and a CAN transceiver. It is connected to the bus via the CAN transceiver and receives settings and commands from the host computer. The sensor interface processes the collected field signals through the network node, and then the CAN transceiver exchanges data with the host computer via the CAN bus. The host computer further analyzes, processes, or stores the field signals detected by the sensors, completing the system's online detection, computer analysis, and control. This design uses twisted-pair cable as the CAN bus transmission medium. [align=center] Figure 1 CAN bus network system structure[/align] 3 CAN Bus Intelligent Network Node Hardware Design This paper presents the circuit design of an intelligent node based on the ARM7 TDMI core and the Philips LPC2119 chip. The circuit schematic of this intelligent node is shown in Figure 2. The design of this intelligent node, while ensuring reliable system operation and reducing costs, features versatility, real-time performance, and scalability. The following sections provide further explanation of each part of the circuit. [align=center] Figure 2 CAN bus intelligent network point[/align] 3.1 LPC2119 Processor Features The LPC2119 is a high-performance, cost-effective processor from Philips. The LPC2119 is based on a 16/32-bit ARM7TDMI-STM CPU that supports real-time emulation and tracing, and features 128KB of embedded high-speed flash memory. Its unique acceleration architecture allows 32-bit code to run at maximum clock speed. Applications with strict code size control can use 16-bit thumb mode to reduce code size by more than 30% with minimal performance loss. It implements pipelined operation, provides embedded ICE logic, supports on-chip breakpoints and debug points, and has an advanced software development and debugging environment. The LPC2119 features a very small 64-pin package, extremely low power consumption, multiple 32-bit timers, four 10-bit ADCs, two CANs, PWM channels, and multiple serial interfaces, including two 16C550 industry-standard UARTs, a high-speed I2C interface (400 kHz), and two SPI interfaces. Its 46 GPIOs and up to nine external interrupts make it particularly suitable for automotive, industrial control applications, medical systems, and fault-tolerant maintenance buses. The LPC2119 integrates two CAN controllers, each with a register structure similar to the independent CAN controller SJA1000. The main difference lies in the programming operation of the identifier reception filter, which will not be detailed here due to space limitations. Its key features include: data transfer rates up to 1 Mbps on a single bus; 32-bit register and RAM access; CAN 2.0b and ISO 11898-1 compatibility; a global acceptance filter that recognizes all 11-bit and 29-bit identifiers; and full CAN-style automatic reception of selected standard identifiers. 3.2 Data Acquisition and Human-Machine Interface The selection of sensor interfaces should be based on the functions to be achieved by the actual system. The sensor converts the measured quantity into electrical quantity. Due to electromagnetic interference in the testing environment and the influence of the sensor and amplifier itself, the signal often contains noise with multiple frequency components. The signal output directly from the sensor needs to be further processed by the signal conditioning circuit to ensure the normal operation of subsequent circuits. The conditioned signal is input to the analog signal input terminals P0.27-P0.30 of the LPC2119. The LPC2119 has four 10-bit ADCs with a conversion time as low as 2.44μs. The human-machine interface utilizes the rich GPIO interfaces of the LPC2119, employing LED display output and keyboard input, as shown in Figure 2. This design uses four LEDs to represent node power, data communication status, online indication, and error indication, respectively. The keyboard has six keys for setting node message filtering, node baud rate, and node reset functions. 3.3 CAN Bus Interface As shown in Figure 2, the CAN interface includes an LPC2119 (with a built-in CAN controller), an optocoupler, and a bus transceiver. The CAN bus follows the ISO standard model, divided into a data link layer and a physical layer. In engineering, it is typically implemented using a CAN controller and a transceiver. The transceiver chosen is the Philips TJA1050 high-speed transceiver, which conforms to the ISO 11898 standard. The CAN controller mainly handles the CAN communication protocol, implementing message assembly and disassembly, filtering and verification of received information, etc. The TJA1050 transceiver provides the physical connection between the CAN controller and the communication line, improving the CAN bus's driving capability and reliability. To further enhance the system's anti-interference capability, the LPC2119 pins TX1 and RX1 are not directly connected to the TJA1050 transceiver, but rather connected via a high-speed optocoupler 6N137. An isolated DC/DC module can be used to power the transceiver circuit. The DC/DC module uses Mornsun's B0505S-1W constant voltage input isolated unregulated single output DC/DC module with an isolation voltage ≥1000VDC. This effectively achieves electrical isolation between the various points on the bus. While this circuitry adds complexity, it ensures stability and safety. The interface between the TJA1050 and the CAN bus also incorporates safety and anti-interference measures. Two small capacitors, CH and CL, are connected in parallel between CANH and CANL and ground to filter high-frequency interference on the bus and provide some electromagnetic radiation protection. The capacitor values ​​must be determined by the number of nodes and the baud rate. When the output stage impedance of the TJA1050 is approximately 20Ω and the bus system has 10 nodes at a speed of 500kbps, the capacitor value should not exceed 470pF. Additionally, a protection diode is connected in reverse between the two CAN bus input terminals and ground. When the CAN bus has a high negative voltage, the diode short-circuit provides some overvoltage protection. Based on the characteristics of TJA1050, the CAN termination resistors in this design use split termination, that is, the two termination resistors of the bus end node are divided into two equal resistors, and two 60Ω resistors are used to replace one 120Ω resistor, which can effectively reduce radiation. Due to the use of split termination, the EMC performance of TJA1050 is optimized and choking is not generated. 4 Formulation of CAN bus application layer communication protocol The overall goal of formulating the CAN bus application layer protocol is to maximize the excellent performance of the CAN bus, make communication more standardized and reliable, improve real-time performance, and reduce bus load rate. When designing the application layer communication protocol of the system, the following two aspects need to be considered: (1) Combine the system design requirements, analyze all information objects in the communication, and determine the communication transmission mode that needs to be supported; (2) Determine the identifier allocation scheme and define the frame format. These are discussed below. 4.1 Determine the communication transmission mode This system requires the implementation of broadcast communication to publish information to all slave nodes or some slave nodes, and the master node must also have the function of operating on individual nodes. Therefore, the following three transmission modes are defined: (1) Support global/local broadcast communication. The master node sends information to all or some nodes, and the slave node performs corresponding actions after receiving the information, without sending back confirmation information. (2) Support point-to-point communication. The master node sends information to a slave node to request data, and the slave node reads the data after receiving the request and sends the requested data back to the master node. (3) Support point-to-point communication. The master node sends information to a slave node, and the slave node performs corresponding operations after receiving the information, but does not send back confirmation information. 4.2 Determine the allocation scheme of identifiers. Determine the allocation scheme of identifiers and define the frame format. Identifiers are the basis for arbitration of the CAN bus and are also the key to the protocol. Their allocation scheme must meet the priority requirements of each node and information. This paper defines two types of frames in the protocol: information frames and data frames. Information frames are used to transmit commands, configuration information and connection response information from the master node to the slave node. Data frames are used to transmit process data from the slave node upwards. Information frames have a higher priority than data frames. The communication protocol in this design adopts the CAN 2.0a standard frame format, using only data frames and omitting remote frames. The message format is shown in Table 1. This paper redefines the 11-bit ID. `dlc` represents the length of the data field (0-7 bytes); `m/s` represents the message propagation direction (0 for master to slave, 1 for slave to master); `b/p` represents the communication mode (0 for broadcast, 1 for point-to-point); `m/d` represents the frame type (0 for information frame, 1 for data frame); `id` (7-0) represents the message identifier; `type` represents whether the message is a single-frame or multi-frame message (0 for single frame or end frame, 1 for multi-frame); `cmd` represents the command identifier, including: `0a` for upload command, `0b` for download command, `0c` for online command, `0d` for alarm command, etc.; `data` represents the data field. When the host computer needs to communicate with the child nodes, it can send information frames to the CAN network nodes using the three modes mentioned above. After receiving the information frames, the nodes in the CAN network distinguish the type of information frame by identifying the identifier and command identifier, and then send out the data required by the node. When a network node experiences a sudden event, it can report it to the host computer at any time. The host computer also identifies the data type through the identifier. 5. Conclusion This paper, based on CAN bus technology and using the LPC2119 as the core, focuses on the hardware circuit design of the network node and the formulation of the application layer protocol. In the software design, the driver program and application layer protocol for the CAN controller were implemented in the Keil UVision3 environment. This solves the problem of processing and storing the measurement signals obtained from the field sensors using the lower-level computer, and then sending the data to the CAN bus through the built-in CAN controller to complete the communication with the host computer. The design has the characteristics of versatility, real-time performance, and strong scalability. It has been debugged and its performance is stable, and it can be ported to other systems.