Abstract: This paper introduces a control system applied to a parallel hydraulic hybrid vehicle. The control system adopts a distributed control system architecture based on CAN bus, determines the network protocol, designs the hardware platform and control software, and finally designs the system's hardware and software reliability. This control system can realize the complex control of a parallel hydraulic hybrid vehicle and has good scalability, showing promising application prospects. Keywords : Parallel hydraulic hybrid vehicle , distributed control system, CAN bus Buses brake and start several times between stops, and this frequency increases during peak traffic hours, leading to energy waste, increased exhaust pollution, and shortened component lifespan. The control system researched in this project enables parallel hydraulic hybrid vehicles to fully utilize braking energy. In road conditions with frequent braking and starting, it significantly improves vehicle starting, acceleration, and deceleration characteristics, reduces emissions, lowers fuel consumption, and extends the lifespan of the engine and braking system. Moreover, compared to hybrid electric vehicles, this system has considerable advantages in cost, technological maturity, reliability, and maintainability. The powertrain of a parallel hydraulic hybrid vehicle has two or more power sources that can provide power simultaneously or individually, and two or more corresponding actuators that can simultaneously drive the load. This powertrain mainly consists of an engine, gearbox, main reducer, hydraulic accumulator, and hydraulic pump/motor. The parallel configuration retains the traditional vehicle's powertrain chain, but adds an energy regeneration system composed of a hydraulic pump/motor and hydraulic accumulator, thus forming a dual-power drive. Currently, parallel hydraulic hybrid vehicle technology is relatively mature, as shown in Figure 1. When the vehicle starts and accelerates, the hydraulic drive system provides auxiliary power, releasing the energy stored in the accumulator; when the vehicle decelerates and brakes, the hydraulic drive system provides auxiliary braking force and stores energy in the accumulator. [align=center] Figure 1 Schematic diagram of parallel hydraulic hybrid vehicle structure[/align] 2 Control system network structure CAN bus is a serial communication network that effectively supports distributed control or real-time control. Its advantages are obvious. At the same time, CAN bus is also considered the best communication structure for hybrid vehicles. This paper uses CAN bus network to build the control system. As shown in Figure 2 below, the control system adopts distributed control with a total of 5 node controllers, mainly distributed in the areas with high control and data acquisition on the vehicle, including the main control module, hydraulic system measurement and control module, hydraulic filling control module, vehicle information acquisition module, and engine control module. [align=center] Figure 2 Control system network structure[/align] The main control module controller uses a PC104 computer equipped with an intelligent PC104 CAN control card, while the other module controllers are based on a P80C592 microcontroller. The P80C592 chip integrates a CAN controller, A/D converter, and watchdog timer. Using this chip makes it possible to miniaturize control nodes and expands the input and output of peripheral analog and digital signals, facilitating process control. 3. Communication Management of the Control System 3.1 CAN Bus Node Address Allocation For a CAN bus network based on the P80C592 and PC104 CAN communication card, there are two types of information frames used for communication messages between nodes: data frames and remote frames. Both data frames and remote frames include an arbitration field consisting of an identifier and a Remote Transmission Request (RTR) bit after the start-of-frame bit. The identifier is 11 bits long (ID.10～ID.0) and contains the target address characteristics of the information frame. The RTR bit must be dominant in the data frame to indicate the frame type. The receiving filter of the node message receiver consists of two parts: the Receive Code Register (ACR) and the Receive Mask Register (AMR). Both registers are 8 bits: acceptance code bits (AC.7～AC.0) and acceptance mask bits (AM.7～AM.0). When the highest 8 bits (ID.10～ID.3) of the message identifier of the information frame satisfy the following equation: [(ID.10～ID.3)=(AC.7～AC.0)] or (AM.7～AM.0)=11111111B, the information frame will be received by the message receiver. For the 5 network nodes of this system, the acceptance code and acceptance mask of each node are defined as follows: 1#: ACR=81H, AMR=BEH; 2#: ACR=82H, AMR=BDH; 3#: ACR=84H, AMR=BBH; 4#: ACR=88H, AMR=B7H; Host: ACR=A0H, AMR=9FH; Based on the above node address allocation, each node can send information to any combination of other nodes. If the host sends information to nodes 1#, 2#, and 3# simultaneously, the high 8 bits of the identifier of the information frame sent by the host can be written as: 87H or 07H. It can be seen that for the message receiver, ID.10=0 or 1 makes no difference. However, according to the CAN bus protocol, the dominant bit "0" will have a higher bus priority than the recessive bit "1". The information frame with ID.10=0 is defined as a "fast frame", and the information frame with ID.10=1 is defined as a "normal frame". Therefore, the above address allocation method has the following advantages: (1) It is easy to realize the transmission of information from a single point to other points in any combination; (2) Each node has a different priority, and the priority decreases from 1# to 5# to the host, ensuring that the signal sent to the key node is not blocked; (3) Each node has two address codes with different priorities, ensuring that the key instructions are received first. 3.2 Communication method and information frame classification Since the distributed control communication volume is large, classifying the information and specifying the corresponding protocol will help the standardization of software, improve programming efficiency and program reliability. First, according to the CAN bus protocol standard, the CAN information frame format described in C language is defined as follows: struct CAN_MSG { unsigned char CAN_FLAG; unsigned char CAN_DLC; unsigned char CAN_DATA[8]; }; where CAN_FLAG is the information target identifier, CAN_DLC contains remote frame signal bits, frame definition description and data frame length information, and CAN_DATA is 8 bytes of data. According to the different information flow, bus priority and function, the communication information is divided into 5 categories, and their specific definitions are as follows (arranged from low to high priority): (1) Remote frame: sent by the host to each controller at a certain interval to activate the status frame transmission of the corresponding controller. The purpose is to enable the host to obtain the status information of the electric vehicle within a specified time, and at the same time reduce the bus blockage caused by the automatic transmission of status frames by each controller. Format: CAN_FLAG adopts "ordinary frame" point-to-point encoding; CAN_DLC=0xF0; CAN_DATA is empty. (2) Status frame: sent by the controller to the host or other controllers. The status frame returns the current command execution status and acquisition information, serving as a marker for the upper-level controller to execute the next planning step. Format: CAN_FLAG uses "ordinary frame" point-to-point and point-to-multiple encoding; CAN_DLC=0xE8; CAN_DATA[0] is the status or information data identifier, determining the meaning of subsequent data; CAN_DATA[1]～CAN_DATA[7] is the data. (3) Indirect command frame: sent from the host to the controller, or from a controller running a composite action element to other controllers. The indirect command frame contains composite action elements or action element instructions, and the receiver must decompose the command to generate control element instructions that drive peripheral actions. Format: CAN_FLAG uses "ordinary frame" point-to-point and point-to-multiple encoding; CAN_DLC=0x60+DLC, where DLC equals the number of bytes of valid data; CAN_DATA[0] is the status or information data identifier, determining the meaning of subsequent data; CAN_DATA contains specific instruction information. (4) Direct command frame: the sending direction is the same as the indirect command frame. However, the command contained in this command frame will be directly executed by the receiver to drive the control element action. Therefore, it should have a higher priority than the indirect command frame. Format: CAN_FLAG uses "fast frame" point-to-point and point-to-multipoint encoding; CAN_DLC=0x20+DLC, where DLC is equal to the number of bytes of valid data; CAN_DATA contains specific instruction information. (5) Emergency command frame: sent from the controller that detects an emergency to other relevant controllers. This command has the highest priority and is used to quickly execute the corresponding action and avoid accidents when an emergency is detected. This command will be directly executed by the receiver. Format: CAN_FLAG uses "fast frame" point-to-point and point-to-multipoint encoding; CAN_DLC=0x00+DLC, where DLC is equal to the number of bytes of valid data; CAN_DATA contains specific instruction information. 3.3 Software Design The CAN bus provides a good hardware foundation for distributed control, so that the communication between nodes is no longer the main factor restricting the implementation of distributed control. Essentially, the entire system no longer distinguishes between master and slave nodes. The control of the entire system has shifted from the single control of the master node in traditional networks (an architecture requiring a large program memory and high processing speed, inevitably leading to a large host computer) to coordinated control of each node. This increases the flexibility of system control and simultaneously reduces the requirements for the master node. [align=center]Figure 3 Input/output parameters of controllers 1# and 3#[/align] As shown in Figure 3 above, the vehicle information acquisition module collects vehicle speed, engine speed, gear signals (forward, neutral, reverse), and the status and amplitude of the accelerator and brake pedals. The hydraulic system monitoring and control module collects the pressure of the accumulator, controls the engagement and disengagement of the clutch, achieves oil circuit distribution control through oil circuit control (4 switching quantities), and finally realizes the hydraulic system recovery/release function and intensity through hydraulic pump/motor control. Each node controller can independently complete the function of partial command decomposition and calling underlying instructions. Thus, for a certain action element, the node controller will act as the "command host". The following uses the flowcharts of controllers #1 and #3 (as shown in Figures 4 and 5) as an example to illustrate the role of each controller in the distributed control system when the composite action element "hydraulic system operation adjustment" is executed. It can be seen that during the execution of this instruction, controller #3 acts as the "command host" of controller #1. [align=center] Figure 4 Flowchart of controller #1[/align] By adopting a distributed control method, the host can be freed from the cumbersome logic control process, which is of great importance for the miniaturization and productization of the host. [align=center] Figure 5 Software flowchart of controller #3[/align] 4 System Reliability Design There is a lot of work to be done on hardware reliability, mainly the following two points: (1) Dual-time watchdog: Each node controller of the system adopts a dual-time watchdog circuit. The dual-time watchdog has two timers: one is a short timer (using the built-in P80C592 microcontroller) and the other is a long timer (external watchdog timer MAX705). The short timer is set to T1, and the long timer is set to T2. Thus, when the program enters an infinite loop, if this infinite loop contains a short timer FeedDog statement but not a long timer FeedDog statement, the long timer will eventually overflow, causing the microcontroller to reset. Cleverly arranging the position of the long timer FeedDog statement ensures a very low probability of system crashes. (2) Anti-interference capability of the CAN bus system: To enhance the anti-interference capability of the CAN bus nodes, the P80C592's CTX0 and CRX0 are not directly connected to the 82C250's TXD and RXD, but are designed to be connected to the 82C250 via a high-speed optocoupler 6N137. This effectively achieves electrical isolation between the CAN nodes on the bus. It should be noted that the two power supplies used in the optocoupler circuit are completely isolated; otherwise, using optocouplers would be meaningless. Complete power isolation is achieved using two low-power DC/DC power isolation modules. While implementing these components increases the complexity and cost of the nodes, it improves the stability and security of the nodes. The interface between the 82C250 and the CAN bus also employs certain safety and anti-interference measures. The CANH and CANL pins of the 82C250 are each connected to the CAN bus via a 5Ω resistor, which limits current and protects the 82C250 from overcurrent. Two 30pF capacitors are connected in parallel between CANH and CANL and ground, filtering high-frequency interference on the bus and providing some electromagnetic radiation protection. Additionally, each node controller is equipped with a power indicator and a bus data transmission/reception indicator, allowing users to understand the controller's status to some extent. In the software reliability design, timers are set at each program branch requiring waiting in the node controller program. If the operating conditions are not met within the specified time, the controller will cancel the current task and send an alarm to the host . Conclusion: The innovation of this paper lies in designing a hydraulic hybrid vehicle control system using a CAN bus network structure, constructing a distributed electric vehicle control system hardware platform based on the CAN bus, determining the system's network protocol, designing the control software based on the proposed distributed structure, and finally designing the system's hardware and software reliability. The series hybrid electric vehicle control system designed in this paper has been tested on a test bench and has completed various functional tests. The tests have proven that the control system is stable, reliable, responds quickly to emergency commands, and can save historical data, thus well meeting the operational requirements of hydraulic hybrid vehicles. References: 1. Wu Kuanming, CAN Bus Principles and Application System Design. Beijing: Beijing University of Aeronautics and Astronautics Press, 1996. 2. Wang Wei, Cui Weina, Zong Guanghua, Research on Software Design of Distributed Control System for Wall-Moving Robot Based on CAN Bus. Computer Measurement & Control, 2002.1 P65. 3. Zhang Weigang, Qi Zhijia, Series Hybrid Electric Vehicle Control System Based on CAN Bus. Automation Technology and Application, 2003 Vol.22 No.5. 4. Wang Yi, Zhang Fan, Application of CAN Bus Technology in Intelligent Vehicle Systems. Microcomputer Information, 2005 No.7.