Introduction With the widespread application of integrated circuits and microcontrollers in automobiles, the number of electronic controllers in modern cars is increasing. Common examples include electronic fuel injection systems for engines, anti-lock braking systems (ABS), airbag systems, power windows, and active suspension. While the addition of electronic control systems improves the power, economy, and comfort of cars, the increased complexity of circuits also reduces vehicle reliability and increases maintenance difficulty. From a wiring perspective, traditional electronic systems mostly use point-to-point single communication methods with little interaction between components, inevitably resulting in a large wiring system. Therefore, a new concept—the Automotive Electronic Controller Area Network (CAN)—has emerged. To enable components from different manufacturers to work collaboratively in the same vehicle, standards must be established. According to relevant ISO standards, the CAN topology is bus-based, hence the name CAN bus. The CAN bus is designed as a microcontroller communication network in the automotive environment, exchanging information between various onboard electronic control units (ECNs) to form an automotive electronic control network. Controller Area Network (CAN) is a multi-master serial communication bus. Its basic design specifications require high bit rates, high immunity to electromagnetic interference, and the ability to detect any errors. CAN applications in automobiles are supported by numerous industry and international standards, such as ISO 11992 and ISO 11783 from the International Organization for Standardization (ISO) and SAE J1939 from the Society of Automotive Engineers (SAE). The CAN bus has been incorporated into the overall vehicle design as a standard automotive device. 1. CAN Bus Characteristics and Communication Protocol 1.1 Introduction to the CAN Bus The CAN communication protocol specifies four different frame formats: data frames, remote frames, error frames, and overload frames. Communication is coordinated based on the following basic rules: bus access, arbitration, encoding/decoding, error marking, and overload marking. CAN conforms to the OSI model. The OSI model has only three layers: the physical layer, the data link layer, and the notification layer, but the application layer needs to be defined by the user. The CAN bus, as an effective serial communication network supporting distributed or real-time control, has applications ranging from high-speed networks to low-cost multi-line networks. For example, in automotive applications such as engine control components, ABS, and anti-skid systems, CAN bit rates can reach up to 1 Mbps. Simultaneously, it can be inexpensively used in electrical systems of transportation vehicles, such as electric windows, headlight beams, and seat adjustments, replacing the required hardware connections. Its transmission medium is twisted-pair cable, with a maximum communication rate of 1 Mbps/40m, a direct transmission distance of up to 10km/5kbps, and a maximum of 110 connected devices. CAN operates in a multi-master mode, offering flexible communication methods, eliminating the need for node information such as station addresses, and employing non-destructive bus arbitration technology to meet real-time requirements. Furthermore, CAN uses a short frame structure for signal transmission, resulting in short transmission times and strong anti-interference capabilities. The CAN bus differs from other communication protocols mainly in two aspects: First, message transmission does not include the destination address; it is based on network-wide broadcasting, and each receiving station filters messages according to identifiers reflecting the data nature within the message. Its characteristics include online/offline connectivity, plug-and-play functionality, and multi-station reception. Second, it significantly enhances data security to meet the needs of control systems and other systems with high data requirements. 1.2 J1939 Communication Protocol The J1939 protocol is an application layer implementation built upon the CAN bus communication protocol 2.0B (identifier 29). It is a communication protocol developed by SAE for heavy-duty trucks and buses. Based on CAN 2.0B, its physical layer standard is compatible with the ISO 11898 standard and uses CAN controllers and transceivers conforming to this standard. The J1939 protocol divides the CAN identifier into the following parts: Priority (P), Data Page (PGN), Protocol Data Unit (PDU) format, PDU-specific field (PS), and Source Address (SA). The J1939/71 application layer document defines the PGNs for various vehicle control parameters and commands. Therefore, the difference between J1939 and CAN communication protocols lies in the 29-bit identifier (ID), while the data field is the same. J1939 provides a detailed physical definition of the 29-bit identifier (or identification) of CAN. The CAN standard format is encapsulated into the J1939 protocol format via PDU. The PDU information frame consists of seven parts: priority P, reserved bits R, data page DP, protocol data unit PF, extension unit PS, source address SA, and data field DATA, which is the 29-bit identifier of CAN plus the data. 2 Overall Design 2.1 Automotive Electronic Control Network Structure The main difference in data transmission characteristics between ECUs within a vehicle lies in the data transmission frequency. For example, when the engine is running at high speed, high-frequency data transmission occurs, transmitting once every few milliseconds; while at low speeds, low-frequency data transmission occurs, transmitting once every tens or even hundreds of milliseconds. However, to meet real-time requirements, each control unit within the vehicle must achieve as much shared common vehicle data as possible. But since the real-time requirements of each control unit differ due to variations in data update rate and control cycle, its data exchange network must be based on a priority contention mode and possess a high communication rate. The CAN bus is designed to meet these requirements. CAN has international standards: ISO 11898 for high-speed applications and ISO 11519-3 for low-speed applications. Typical automotive network structures use multiple buses of different speeds to connect different types of nodes, and use gateway servers to achieve information sharing and network management throughout the vehicle. According to the SAE J2057 standard of the Society of Automotive Engineers (SAE) Vehicle Networking Committee, automotive data transmission networks are divided into three categories. Figure 1 can be used to illustrate this. The gateway is the core of internal vehicle communication, enabling information sharing on the CAN bus and realizing internal network management and fault diagnosis functions. It also feeds information from each data bus back to the display screen on the instrument panel assembly, allowing the driver to know whether each electronic control device is working properly. 2.2 Communication Platform Hardware Design In this design, the main control chip CPU is a 51 series microcontroller. The CAN communication controller executes the complete CAN protocol, completing communication functions, including information buffering and receiving filtering; therefore, the Philips SJA1000 CAN controller is selected. The PCA82C250 was selected as the transceiver for the CAN bus. The PCA82C250 serves as the interface between the CAN protocol controller and the physical bus, exhibiting resistance to transients, radio frequency interference, and electromagnetic interference in the operating environment. Its internal current-limiting circuit protects the output stage from short circuits. Shielded transmission media is used, and an optocoupler circuit is added between the control node and the media to improve the bus interface's anti-interference capability. Figure 2 shows the hardware block diagram of the communication platform, and Figure 3 shows the connection interface between the controller and the transceiver. To further improve system reliability, redundancy design is necessary. Due to the harsh automotive environment and numerous interference factors, two capacitors are connected in parallel between the CAN_H and CAN_L signal lines and the ground line to filter noise and ensure stable signal transmission. Two sets of dual-shielded transmission media can be configured, allowing simultaneous information transmission on both media. The receiver uses only one medium, switching between the redundant and non-redundant sections at the connection threshold. 2.3 Software Design In short, the function of this communication platform is to enable each node (ECU) to communicate with each other via the CAN bus, sending and receiving commands and information, and sharing data, thereby improving their respective control performance and operating efficiency. Each node (ECU) on the automotive CAN data bus has its own address and name. The ECU address indicates the destination of the data transmission, while its name identifies the basic functions of the ECN. Nodes continuously monitor various data transmitted on the bus. When the received data address value matches its own address, the node obtains a token. In the communication protocol, only the node that obtains the token has the right to send data to prevent two or more nodes from transmitting data simultaneously and causing confusion. Each node also has the opportunity to obtain a token and complete data transmission. This software design is based on Keil C language. The program mainly consists of a main module, an interrupt handling module, and a data communication module, as shown in Figure 4. The main module completes hardware initialization, register configuration, and SJA1000 initialization; the interrupt handling module includes data interrupt sending, receiving, error handling, and alarm handling; the data communication module completes data requesting, sending, and receiving. When node A sends a data request message (remote frame) to another node B, requesting a message (response frame), node B receives the request, performs a judgment, and then sends data (response frame). Since the data request does not have a data field, its length is much shorter than the data frame. After analysis and verification, the data received by node A is identical to that received by node B, thus verifying the data request program. Conclusion In modern automotive design, the CAN bus has become a trend in building automotive networks. As the automotive network directly connects to various ECUs within the vehicle and is responsible for command transmission, data sending, and sharing, its reliability and stability are closely related to the overall vehicle performance. The design and development in this paper was based on a simulation platform built under experimental conditions. Communication between nodes is achieved through peer-to-peer CAN communication nodes. Experiments show that its operating performance is stable and reliable, but practical application still requires further research and improvement, and the program's communication processing capabilities, error correction, and fault tolerance capabilities need further enhancement.