Share this

Vehicle monitoring system based on fieldbus and virtual instruments

2026-04-06 06:13:35 · · #1

Abstract: Addressing the challenges of large data volume, complex wiring, and inconvenient debugging in multi-motor monitoring systems, this paper introduces a design scheme for a monitoring system based on fieldbus and virtual instrument technologies. Utilizing Modbus and CAN bus protocols, and through serial bus to CAN bus conversion, the fieldbus technology and virtual instrument are organically combined to achieve a simple, high-real-time, and highly scalable multi -motor battery vehicle control system. Practical application demonstrates that this system meets the design requirements.

Keywords: CAN bus; virtual instrument; Modbus protocol; serial port

Abstract: To resolve problems of traditional multi-motor monitor/control system, such as excessive information exchange, complex wiring, and inconvenient installation and debugging, this paper provide a design based on field bus and virtual instrument technology. With the help of Modbus protocol, CAN (Control Area Networks) bus, and serial port, combines field bus technology and virtual instrument technology, realizes the convenience, real time, expandability, multi-motor car control system. It goes well in practice and has met the requirements.

Keywords: CAN; Virtual Instrument; Modbus; Serial Port

1 Introduction

Currently, in the field of control, the application of virtual instrument systems is mostly limited to point-to-point acquisition-feedback-control methods. However, for multi-motor systems, especially multi-motor driven battery vehicle systems, it is necessary to achieve functions such as large-scale information acquisition, distributed coordinated control, and real-time response speed. Traditional methods involve complex hardware components, cumbersome wiring, inconvenient debugging and installation, and limited scalability, and do not take full advantage of virtual instruments. Therefore, this paper proposes a design scheme for a virtual instrument system based on the CAN (Controller Area Network) bus, which effectively combines computer communication, fieldbus technology, and the concept of virtual instruments. A simple, high-real-time, and highly scalable distributed monitoring system is designed, realizing real-time adjustment of multi-motor control and monitoring, as well as the digitization and graphical representation of control effects in complex control systems.

2. Proposal of the Overall Plan

Figure 1 System block diagram

The system design principle is based on practicality, reliability, and economy, ensuring that the system not only meets application needs but also possesses flexibility, scalability, and versatility. This system is composed of virtual instrument technology, Modbus bus protocol, and an optimized combination of CAN bus. The system's schematic diagram is shown in Figure 1. The system utilizes a PC to monitor multiple motors, multiple battery banks, and other auxiliary equipment. It mainly consists of a host computer, a battery management system, a motor control system, and other auxiliary control systems. The various controllers communicate via the CAN bus to send and receive control commands and share sensor measurement data, thereby improving the system's control performance.

The motor controller collects armature current and motor speed, determines operating conditions, and receives set speeds. The battery management controller collects battery temperature, voltage, and current, and receives control commands. The host computer is written in the LabVIEW graphical programming language. The program displays motor speed, vehicle speed, and battery state of charge in real time as a virtual instrument. Control commands are sent from the host computer to control the motor and battery status. The CAN node is the core of this system, connecting the various components into a unified system. Each CAN node uses a unified hardware platform, implements different operating modes, and can independently select the connected devices and operating modes.

3 CAN Node Hardware Design

For automotive electronic control units, to simplify design and improve reliability, a microprocessor with an integrated CAN bus controller is used. A microprocessor with a built-in CAN bus controller does not occupy processor port resources, which greatly simplifies the design of interface circuits, reduces program complexity, and improves system stability. This system uses the high-performance Philips P87C591 microcontroller. Figure 2 shows the functional block diagram of the node hardware design. The node functional requirements and the selected microprocessor resources are described below:

(1) Full-duplex enhanced UART with a programmable baud rate generator, which completes RS232/RS485 communication according to the specified Modbus protocol; in terms of hardware implementation, the RS485 bus end uses the MAX481 transceiver; the RS232 bus end uses the MAX232 transceiver. In order to realize the switching of serial port channels, a jumper slot is specially set in this system for manual selection. By setting different input signal values, the corresponding data channel is selected.

Figure 2 Node Hardware Functional Block Diagram

(2) The microprocessor P87C591 integrates and enhances the functions of SJA1000 (independent CAN controller), is fully compatible with the CAN2.0 protocol, and can complete communication tasks such as sending and receiving CAN bus data; the CAN interface circuit uses the CAN bus transceiver PCA82C250. In order to increase the system's reliability and anti-interference capability, a corresponding opto-isolation circuit is added between P87C591 and PCA82C250.

(3) The built-in 6-channel analog input 10-bit ADC can be set to an 8-bit fast ADC, which can basically meet the accuracy requirements of the system for acquisition and complete the measurement tasks of motor and battery status; for the acquisition of analog signals, the acquisition circuit conditions (filters, amplifies, and converts the electrical signals of the sensors at each test point) and then connects them to the ADC interface of the microprocessor. To suppress common-mode interference, the amplifier basically adopts differential input.

(4) Two 8-bit resolution pulse width modulation (PWM) outputs provide control signals to the motor controller to regulate the motor speed. Programmable I/O ports (quasi-bidirectional, push-pull, high impedance, and open-drain) compatible with the 51 series provide channels for digital signals and are responsible for reading and setting switch quantities.

(5) 16K bytes of internal program memory, which can meet the program space of this system. I2C bus serial I/O port with byte mode master and slave function can easily interface with external memory chips to realize data storage function.

In addition to the main components mentioned above, the hardware includes a power supply circuit, extended memory, and a watchdog circuit. The power supply circuit provides the necessary isolated power to improve the stability and security of the node; the E2PROM stores certain system parameters via the I2C serial bus; the watchdog circuit mainly ensures the stability of system operation and resets the output during power-on, power-off, and alarm conditions.

4 System Software Design

4.1 Design of Host Computer Software

Virtual instrument software is mainly divided into three layers: the user application layer, the virtual device driver layer, and the hardware device driver layer. The user application layer is closely related to user needs and mainly performs two tasks: First, it provides users with virtual interfaces for various testing instruments to facilitate human-computer interaction, which is commonly referred to as interface design. Through this interface, it displays collected measured data and status information, providing an interaction platform between the user and the system; Second, it performs tasks such as data classification, judgment, processing, serial communication, and data storage and retrieval operations.

Figure 3. Schematic diagram of the host computer program

The serial port device driver is implemented using VISA, which stands for Virtual Instrument Software Architecture. VISA is an interface library for controlling VXI, GPIB, RS232, and other types of instruments on all LabVIEW platforms. VISA is a standard adopted by the 35 largest instrumentation companies that form the VXI plug-and-play system alliance. By adopting the VISA standard, time and instrument I/O options can be disregarded, and driver software can be used interchangeably.

4.2 Node Programming

Figure 4 Node Main Program Block Diagram

Figure 4 is the main program flowchart. It describes the basic flow of the general module design. Based on the state of the jumper and the state set in the memory, the function and working mode of this module are determined. After selecting the working mode, each module is re-initialized, mainly including the configuration of I/O ports, the setting of CAN interrupt, the setting of acceptance filter, the setting of serial port working mode, the setting of timer mode, the setting of baud rate, and the relevant settings of serial port I2C. After completing the initialization settings, the module can return to the working state and enter its respective main loop. The implementation of each working mode is described below:

1) Implementation of bus conversion

The design of the general serial port to CAN interface conversion mode mainly aims to achieve interconnection and communication between CAN bus data and RS232/485 bus data, as well as system upgrades. The bus operating state is controlled by a built-in CAN controller, and combined with software design, the goal of communication between the general serial port and the CAN interface is achieved. Modbus specifies two transmission modes: ASCII or RTU; this system selects the RTU mode. When converting between Modbus protocol messages and CAN bus messages, since the standard CAN protocol has an 11-bit ID, while the Modbus protocol address is one byte, the ID is divided into two parts: 3 bits and 8 bits for easier conversion. The first 3 bits are used to determine the message type, and the last 8 bits are the ID value of each module. For example, the conversion format for forwarding an 11-bit Modbus protocol message to the CAN port is shown in Figure 5. Forwarding from the CAN bus to the serial port requires three processes: collection, queuing, and forwarding. Collection is necessary because the return frame from the host computer operation sometimes returns data from multiple nodes.

Figure 5. Converting Modbus 11-bit messages to CAN standard frames.

According to reports, CAN, as a serial bus, must also time-division multiplex the notification and reception of data from each node that requires a return value. Queuing is necessary because if there is a return request from the host computer, that data is sent first, while other data is temporarily stored and sent only after a return is received; otherwise, the returned value will be considered incorrect. The queued data is then sent to the host computer sequentially.

2) Implementation of motor monitoring

This operating mode monitors the motor. Initialization is required, including disabling the serial port, setting up I2C, initializing CAN, and setting the receive filter. After reading the set parameters, it enters the main loop. This node is an intelligent node, capable of independently controlling the motor. The host computer only sends it the switching signals for controlling the relays and the digital signals for setting the motor speed. Upon receiving these signals, the node automatically adjusts the motor to reach the set operating speed. This method significantly reduces the bus load and improves the system's real-time performance. Besides adjusting the motor according to the preset control algorithm, the intelligent node is also responsible for collecting motor operating status (current, voltage, temperature, speed), identifying abnormal states, and transmitting data in real time.

3) Implementation of battery monitoring

The motor is powered by electricity supplied by a battery. The battery's status reflects not only its own operational status but also indirectly the motor's running status. The battery's current, voltage, and temperature each have their own thresholds. Under normal operating conditions, each node sends its status to the host computer according to a prescribed sequence. When an abnormal operating state occurs, the module determines the cause of the problem and takes corresponding measures, promptly reporting to the host computer via the CAN bus. If an unrecoverable communication error prevents further communication, the node automatically shuts down the battery and motor, the entire driver system automatically exits operation, and the motor is placed in a floating state to ensure unimpeded vehicle operation.

4) Implementation of module settings

Based on the jumper settings, the program determines when to enter the configuration mode upon startup. When a user needs to configure a specific node, the host computer runs the configuration software. The host computer connects to the module via a serial port, and the node enters the configuration mode (this mode configures individual modules one by one). The host computer sends corresponding function codes to read module parameters and sends corresponding function codes to modify module parameters. Configurable module parameters include the module's address, the devices connected to the module, and the baud rate for serial communication with the devices. These parameters are stored in the I2C interface's memory.

5) Implementation of other standard equipment

The Modbus protocol is an open protocol developed by MODICOM and supported by many manufacturers. The standard Modbus uses an RS-232C compatible serial interface. This module's serial communication follows the Modbus protocol, thus offering greater flexibility in expansion. As long as the host computer has corresponding programs, industrial control equipment that conforms to the Modbus protocol can be easily connected to the CAN bus through this module.

5. Conclusion

The design approach, combining bus technology and virtualization technology, clarifies system function division, defines device functions more precisely, simplifies external device wiring, and facilitates system expansion and integration. It achieves software platform universality, software protocol standardization, and hardware structure unification, thereby ensuring system portability and scalability, and providing a new approach to monitoring system design. Actual system operation demonstrates that the system design approach is correct, and the system's real-time performance, stability, and flexibility all meet the vehicle's design requirements.

The author's innovation lies in integrating virtual instrument technology, the Modbus protocol, and the CAN bus into a unified system, and satisfying various functional requirements on a unified hardware platform.

References

[1] Rao Yuntao and Zou Jijun, CAN Fieldbus Principles and Applications, Beijing University of Aeronautics and Astronautics Press, June 2003.

[2] Yang Leping, LabVIEW Programming and Application (2nd Edition), Electronic Industry Press, January 2005.

[3], MODICON, Inc. Modbus Protocol Reference Guide [Z], 1996.

[4] Li Xueju, Zou Peng, High-frequency coaxial switch conversion circuit based on LabVIEW and microcontroller serial port, Microcomputer Information (Embedded Systems and SOC), Vol. 21, No. 7-2, 2005, p86

Read next

Discussing the selection and use of low-voltage circuit breakers

Abstract: Determining the electrical clearance of electrical products must be based on the insulation coordination of th...

Articles 2026-02-22
CATDOLL 115CM Milana TPE

CATDOLL 115CM Milana TPE

Articles
2026-02-22
CATDOLL 128CM Chu

CATDOLL 128CM Chu

Articles
2026-02-22
CATDOLL 148CM Sana Silicone Doll

CATDOLL 148CM Sana Silicone Doll

Articles
2026-02-22