Introduction The liquid level telemetry system is the core part of oil tankers and chemical tankers[1], which is directly related to the safety and reliability of ships sailing at sea. At present, the domestic industry is still in a vicious competition of low technology. To change this situation, it is only possible to improve the level of technology. This system is designed and researched in this context. This system is an intelligent liquid level telemetry system designed with ARM9 as the core, WinCE operating system platform, CAN communication as the basis, CANopen protocol as the standard, and comprehensive application of EVC programming, CAN communication, database, multi-threading and other technologies. The ARM9 has a maximum operating frequency of 200 MHz and the microprocessor has a built-in color image processing circuit, so it can be directly connected to a TFTLCD/VGA display screen. CAN (Controller Area Network) bus is a multi-master-slave structure with message arbitration, error self-detection and processing mechanism, strong communication capability, strong short circuit protection capability, and flexible and diverse communication methods. The ship liquid level telemetry system is a local area network control system. Choosing CAN bus can better meet its high reliability of transmission[2]. 1 CANopen Protocol CANopen was originally developed by CiA members engaged in industrial control. As CANopen is a public, open, and universal protocol, and is concise, transparent, and easy to develop, it has now been accepted as one of the standards for CAN high-level protocols. [3] [align=center] Figure 1 CANopen device module[/align] A CANopen device module can be divided into three parts, as shown in Figure 1. The communication interface and protocol software are used to provide services for sending and receiving communication objects on the bus; communication between different CANopen devices is accomplished by exchanging communication objects. This part directly operates on the CAN controller. The object dictionary describes all data types, communication objects, and application objects used by the device; the object dictionary is located between the communication program and the application program and is used to provide an interface to the application program. The application program operates on the object dictionary to realize CANopen communication. It includes a functional part and a communication part. The communication part realizes CANopen communication by operating on the object dictionary; while the functional part is implemented according to the application requirements. In the CANopen network system, each node has a unique object dictionary, and the object dictionary of each node has the same structure; however, the specific content depends on the different devices and contains all parameters describing the device and its network behavior. The CANopen protocol also defines four types of messages (communication objects) for processing information with different functions: Management Messages (NMT), Service Data Objects (SDO), Process Data Objects (PDO), and predefined messages or special function objects. 2. Overall Structure of the Liquid Level Telemetry System The liquid level telemetry system mainly implements two functions: ① Real-time monitoring of liquid level, temperature, and pressure in each compartment; ② Issuing an alarm signal when the monitored value exceeds the alarm threshold. For these two functions, a CAN bus network topology is adopted, and the overall system structure diagram is shown in Figure 2. Figure 2 Overall Structure of the Liquid Level Telemetry System As shown in Figure 2, the entire system communicates via the CAN bus. However, the CAN chip only provides the physical layer and data link layer functions in the Open Systems Interconnection (OSI) reference model. Generally, users must directly operate the data link layer using driver programs. This cannot directly meet the configuration requirements of the control network and product interconnection requirements. To construct a complete industrial control fieldbus system based on the CAN chip, a corresponding application layer protocol must be developed to realize system configuration, device interconnection, and compatibility functions. The functions of each part are described below. 2.1 Distributed Processing Unit (DPU) The DPU is an intelligent remote I/O unit with a modular design and communication capabilities. DPU units are distributed throughout the ship's compartments, serving as interfaces for sensors and actuators, directly connecting to them. Each DPU unit can be connected to the CAN bus using two ordinary two-core shielded cables (or twisted-pair cables, etc.) to send real-time data such as liquid level and temperature collected periodically from each compartment to the bus. Currently, various modules of the CANopen-based DPU (analog input/output, digital input/output, etc.) can be connected to the network according to specific monitoring points to complete the monitoring of liquid level, temperature, pressure, etc. 2.2 Upper-Level Monitoring Point In this system, the upper-level monitoring point mainly implements communication and application functions, as shown in Figure 3. [align=center]Figure 3 Upper-level monitoring point structure diagram[/align] The ARM9 development platform has embedded the CAN driver. According to the CAN2.0 protocol, communication between the physical layer and the data link layer can be directly completed. Therefore, under the WinCE operating system, CANopen communication is implemented, the communication object is parsed, the application is called, and the CANopen communication of the entire upper-level system is completed. 3 Implementation of CANopen Communication 3.1 CAN Communication CAN communication is implemented by calling the interface functions encapsulated at the lower level, mainly including: Opening the port CAN_StartChip; Closing the port CAN_StartChip; Receiving CAN data CAN_GetNextReceivedFrame; Sending CAN data CAN_SendFrame. The specific communication process is shown in Figure 4. [align=center]Figure 4 CAN communication process[/align] 3.2 CANopen Communication The CANopen protocol is the protocol of the CAN communication application layer. The communication standard defines different communication objects, which are distinguished by identifiers (COB_ID). Network Management Message (NMT): Provides network management services, such as initialization, error control, and device status control. NMT objects are mapped to a single CAN frame with a data length of 2 bytes, and their identifier is 0. In this system, they are mainly used for system startup initialization. Process Data Objects (PDOs): Process data objects are used to transmit real-time data. Data transmission is limited to 1-8 bytes, and each PDO has a unique identifier. Identifiers have priorities. The telemetry system mainly displays real-time information such as liquid levels, and a large amount of PDO data is transmitted in real time. Service Data Objects (SDOs): SDO transmission is a verified service with high reliability. It is mainly used for configuring or setting information for various nodes in the system. All four types of objects have different priorities. Received messages are parsed according to their COB_ID and distributed to different application variables to achieve CANopen communication. 4. Application Module Implementation 4.1 System Configuration This system uses configuration files to enhance configuration flexibility. The configuration file is a txt file compiled based on the field distribution of modules and channels in the lower-level DPU. First, the configuration file is loaded onto the PC using a removable disk or Remote File Viewer. Second, the reading process is performed using the GetProfileString function to retrieve the required content based on different fields. Finally, the obtained content is assigned to the corresponding variables and the display is updated. The specific configuration is shown in Figure 5. As shown in the figure, the use of modules, cabin names, signal types, units, ranges, alarm upper and lower limits, alarm delays, etc. can be set in the system. Therefore, the basic configuration can be completed in the central control room, greatly reducing the burden on the staff. [align=center] Figure 5 System Configuration[/align] 4.2 Real-time Display In order to achieve real-time, accurate and vivid display of the system operation status, this module uses a combination of text and graphics. Because the data volume is large, there are many interface types and frequent switching, the solution of dynamically creating controls is mainly adopted. The liquid level telemetry system mainly completes the real-time display of the liquid level of each cabin. In addition, it also includes important information such as the temperature and pressure of the cargo cabin and the pressure of the pipeline. 4.3 Data Storage In this system, the data storage mainly completes the storage of alarm data and the monitoring of cabin capacity information, using the WinCE built-in database system. The system mainly stores alarm data, so the data volume is relatively small, and the built-in database can easily realize the required functions. Furthermore, EVC4.0 does not provide an interface for accessing the external database ADOCE. 4.4 Real-time Printing: Real-time printing is implemented in this system; that is, as soon as an alarm message is received, it is immediately printed out; after the fault is resolved, it is reprinted for data saving and analysis. 5. Conclusion This paper studies the software of a ship level telemetry system based on the CANopen protocol on the WinCE embedded development platform of ARM9. CANopen, as the application layer protocol of the CAN bus, has broad application prospects in ship telemetry systems. The application of the CAN bus in the system greatly improves the overall transmission rate of the system, and the dual CAN mechanism further enhances the fault tolerance of the entire system, ensuring the safety of ship operation. The entire software system implements CANopen communication, completes data display, storage, printing, and alarm functions, and makes the configuration more intelligent. Experiments have proven its operational reliability. References [1] Cui Xiaojun. New technology application in ship liquid level telemetry system [J]. Ship Engineering, 2007 (3): 72-74. [2] Wu Kuanming. CAN bus principle and application system design [M]. Beijing: Beijing University of Aeronautics and Astronautics Press, 1996. [3] Wang Bing, Li Cunbin. EVC advanced programming and its application development [M]. Beijing: China Water Resources and Hydropower Press, 2005. [4] Robert Bosch GmbH, CAN Specification Version 2.0 [S], 1991, Postfach 30 02 40, D70442 Stuttgart