1 Introduction Real-time operating system (RTOS) is the foundation and development platform of embedded application software, and applications are built on it. There are many types of real-time embedded operating systems, which can be roughly divided into two types: commercial and free. Commercial real-time operating systems are stable and reliable, with complete technical support and after-sales service, but they are expensive. Free real-time operating systems have an advantage in price, and currently mainly include Linux, μC/OS, etc. Compared with other embedded operating systems, embedded Linux has advantages such as open source code, high reliability and powerful network functions, so embedded Linux system was selected as the software platform for mobile terminals. 2 Overview of vehicle monitoring system Vehicle monitoring system is a high-tech system that integrates global positioning technology (GPS), geographic information technology (GIS) and general packet radio service (GPRS), consisting of mobile terminals, GPRS network and monitoring center [1]. The mobile terminal is installed on each mobile vehicle, and the GPS receiver on it collects satellite positioning information in real time, and then transmits it to the ARM processor through serial port 1. The ARM processor first calculates the useful data (latitude and longitude, speed, status, etc.), then encapsulates it into TCP/UDP packets according to the TCP/UDP protocol format, and then adds an IP header and trailer to encapsulate it into an IP datagram. Since the communication between the ARM processor and the GPRS communication module follows PPP (Point to Point Protocol), the IP datagram needs to be encapsulated into a PPP frame according to the PPP frame format before being passed to the GPRS communication module connected to serial port 2. The GPRS communication module further transmits the data to the SGSN (Serving GPRS Support Node) via a wireless link. The SGSN performs the corresponding protocol conversion and encapsulates the data into GTP packets according to the GPRS-specific GTP (GPRS Tunnel Protocol), then transmits them through the GPRS backbone to the corresponding GGSN (Gateway GPRS Support Node). The GGSN also performs corresponding protocol conversion, then re-encapsulates the data according to the protocol format of the external data network, and selects a route for transmission based on its destination IP address, ultimately transmitting it to the monitoring center. The monitoring center displays the vehicle's movement trajectory on an electronic map with geographic information processing and query functions, and monitors and queries parameters such as the accurate location, speed, direction of movement, and driving status of the monitored vehicles. Simultaneously, the monitoring center can also send text messages and control commands to the mobile terminal. Therefore, the core functions of the mobile terminal are receiving GPS signals, processing GPS data, and communicating with the monitoring center via the GPRS network (including sending location information to the monitoring center and receiving instructions from the monitoring center). 3. Design of the Mobile Terminal Software System 3.1 Overall Design The software system on the mobile terminal mainly consists of three parts: a GPS signal receiving program, a GPS data processing program, and a GPRS communication program. Under the embedded Linux system platform, the software system structure of the mobile terminal is shown in Figure 1. Figure 1. Software System Structure of the Mobile Terminal 3.2 GPS Signal Receiving Program For the mobile terminal, its first task is to receive GPS signals. The hierarchical structure of the GPS signal receiver program on the embedded Linux system platform is shown in Figure 2. Figure 2: Hierarchical Structure of the GPS Signal Receiver Program. The tty layer, the N_TTY line discipline layer, and the low-level driver are three inherent logical layers of the serial communication driver module in the embedded Linux system. These three layers have interface functions that call each other. The embedded Linux system provides various line disciplines for different types of devices to choose from, such as the TTY line discipline (N_TTY) used to connect the terminal input driver device and the terminal display driver device, and the PPP line discipline (N_PPP) used to connect the terminal driver device and the network driver device. The GPS signal receiver program uses the N_TTY line discipline; the data received by the GPS receiver must be processed and regulated by the N_TTY line discipline module. The low-level driver is used to directly operate the hardware, while flip_buffer is a high-speed interface between the low-level driver and the N_TTY line discipline; it stores the data received by the GPS receiver. In the embedded Linux system, the kernel provides a device node /dev/ttyS0 and a standard file system interface for the GPS receiver connected to serial port 1 [2]. In this way, the operation of the GPS signal receiving program on the device node /dev/ttyS0 will be mapped by the kernel to the operation on the GPS receiver. When the GPS receiver receives satellite signals, it will trigger the interrupt handling function registered in the system by the low-level driver, thereby calling the function receive_chars() to fill the data into flip_buffer, and then calling the function tty_flip_buffer_push() to pass the data to the N_TTY line procedure module. The function n_tty_receive_buf() in the N_TTY line procedure module normalizes the data and stores it in the tty buffer for the application layer GPS signal receiving program to read. When the application layer GPS signal receiving program starts running, it will send a read request to the file system. The file system finds that the object of this request is the tty device, so it calls the function tty_read(), and then calls the function read_chan() to read the data in the tty buffer. 3.3 GPS Data Processing Program There are many communication protocols between the GPS receiver and the embedded Linux platform. The protocol used here is NMEA-0183, which specifies a GPS data output rate of 4,800 baud, with all outputs being ASCII characters, and an 8-N-1 operating mode. The NMEA-0183 communication protocol includes statements such as GPGGA, GPGLL, GPGSA, GPGSV, GPRMC, and GPVTG. To obtain the vehicle's location information, at least one of GPGGA, GPGLL, or GPRMC must be extracted. The statement format of the NMEA-0183 protocol message is shown in Figure 3. Figure 3 NMEA0183 message format where $ is the header, indicating the start of the string; AA is the identifier; XXX is the statement name; ddd…ddd is the data field, which can be letters or numbers; * indicates the end of the string; hh indicates the checksum of all character codes between $ and *; <CR> is the carriage return control character; and <LF> is the line feed control character. In the vehicle monitoring system, the main concern is information such as time, vehicle position and speed. Therefore, on the mobile terminal, the main function of the GPS data processing program is to extract the GPRMC positioning statement from the data received by the GPS receiver and ignore other information [3]. After that, the GPRS communication program on the mobile terminal is responsible for sending the relevant data to the monitoring center. 3.4 GPRS Communication Program 3.4.1 Basic Principle of Dial-up to GPRS Network For a mobile terminal to access the Internet through the GPRS communication module, it must first attach to the GPRS network and then initiate the PDP (Packet Data Protocol) context activation process [4], as shown in Figure 4. Only through this process can the GPRS communication module establish a logical path with the GGSN and thus access the Internet. Figure 4 Schematic diagram of PDP context activation process 3.4.2 Implementation of Dial-up Program on Mobile Terminal Under the embedded Linux system platform, the mobile terminal uses pppd (including chat) to dial up to the GPRS network. pppd is a background service process (daemon) in user space, while chat is an auxiliary tool that pppd comes with, used to establish a session with the GPRS communication module. In the PDP context activation process, chat completes step ①, while pppd completes steps ②, ③, ④, and ⑩. The hierarchical structure of the pppd dial-up program is shown in Figure 5. Figure 5 shows the hierarchical structure of the pppd dialing program. The N_PPP layer is the PPP protocol layer. The PPP protocol module not only provides simple data link layer functions, but also extended functions such as authentication (e.g., PAP/CHAP), data compression/decompression (e.g., CCP), and data encryption/decryption (e.g., ECP). Since GPRS communication programs require the transparent use of these extended functions, and the PPP protocol module itself cannot select various strategies, pppd was developed. The strategic content of the PPP protocol module was moved to pppd, which handles the selection of extended functions such as authentication, compression/decompression, and encryption/decryption. When running pppd, it first reads the configuration information from the configuration file, which includes setting the parameters of the PPP protocol module, the port connected to the GPRS communication module (/dev/ttyS1), and the statement for calling chat, etc. Subsequently, pppd calls chat, which reads the corresponding configuration file (containing response pairs and AT commands). It then sends AT commands to the GPRS communication module using the default line procedure N_TTY, and then chat returns control to pppd. pppd switches its line procedure to N_PPP, and communication between pppd and the PPP protocol module uses a device file named /dev/ppp. Through the read system call, pppd can read data packets from the PPP protocol module (of course, the PPP protocol module only sends packets that should be processed by pppd to pppd). Through the write system call, pppd can pass data packets to be sent to the PPP protocol module, and through the ioctl system call, pppd can set parameters for the PPP protocol module and establish/close connections. After this, pppd executes steps ②, ③, and ④ of the PDP context activation process. After steps ⑤-⑨ of the PDP context activation process (not directly related to the mobile terminal) are completed, pppd executes step ⑩, calling ioctl(PPPIOCNEWUNIT) in the function make_ppp_unit() to create a network interface (such as ppp0). When the PPP protocol module processes PPPIOCNEWUNIT, it calls the function register_netdev() to register the PPP network interface with the kernel. The transmission function of this network interface points to the function ppp_start_xmit(). It is worth noting that if the pppd process is closed, the line procedure will switch from N_PPP back to the default N_TTY. Therefore, the pppd process cannot be closed during the communication between the mobile terminal and the monitoring center. At this point, the mobile terminal has completed dialing to the GPRS network, thus possessing a network interface (such as ppp0) that can be used to communicate with the monitoring center. 3.4.3 Data Interaction between Mobile Terminal and Monitoring Center Previously, the mobile terminal had established a network link with the monitoring center. Next, the mobile terminal can communicate with the monitoring center. The hierarchical structure of the GPRS communication program is shown in the right half of Figure 1. During the process of the mobile terminal sending location information to the monitoring center, the GPRS communication program on the mobile terminal sends TCP/IP data packets through the socket interface. The kernel finds the PPP network interface based on the IP address and routing table, and then calls the function ppp_start_xmit(). At this point, control is transferred to the PPP protocol module. The function ppp_start_xmit() calls the function ppp_xmit_process() to send all data packets in the queue, and the function ppp_xmit_process() further calls the function ppp_send_frame() to send a single data packet. The function `ppp_send_frame()` calls compression and other extended functions based on the previous settings of the PPP protocol module in pppd, and then calls the function `pch->chan->ops->start_xmit()` via the function `ppp_push()` to send data packets. The function `pch->chan->ops->start_xmit()` specifies the transmission method. For serial port transmission, it uses the function `ppp_async_send()` registered in `ppp_async.c:ppp_asynctty_open`. `ppp_async_send()` calls the function `tty->driver->write()` (defined in the low-level driver) via `ppp_async_push()` to send data to serial port 2 (the GPRS communication module is connected to serial port 2). During initialization (`ppp_async_init`), `ppp_async.c` calls the function `tty_register_ldisc()` to register the processing interface for line procedure N_PPP with the tty, which is a set of callback functions. During the process of the mobile terminal receiving instructions from the monitoring center, when the GPRS communication module receives data, it calls back the function ppp_asynctty_receive() in the N_PPP line procedure to receive the data. The function ppp_asynctty_receive() calls the function ppp_async_input() to convert the data buffer into sk_buff and put it into the receive queue ap->rqueue. ppp_async also has a separate tasklet (ppp_async_process) specifically for handling data packets in the receive queue ap->rqueue. ppp_async_process is always suspended on the receive queue ap->rqueue; once awakened, it calls the function ppp_input() to let the PPP protocol module process the data packet. In the function ppp_input(), the data is split into two paths: one is the protocol control data packet, which is put into the queue pch->file.rqb and handed over to pppd for processing. Another path is the user data packet, which is processed by the functions ppp_do_recv() and ppp_receive_frame() for PPP protocol related processing, and then submitted to the upper-layer TCP/IP protocol module by the function netif_rx() for processing, and finally passed to the application layer GPRS communication program through the socket interface. 4 Summary In recent years, intelligent transportation systems (including vehicle monitoring systems) have developed very rapidly. Therefore, mobile terminals will have a very wide range of application prospects. With the continuous expansion of market demand, more and more functions will be integrated into mobile terminals, and embedded Linux systems will be increasingly used in this field due to their own advantages. The innovation of this paper: This scheme makes full use of the system functions provided by the embedded Linux platform, greatly simplifies the development of application programs, and has good scalability. After introducing the GPS signal reception process in detail and giving a simple GPS data processing method, this paper provides a practical method for dialing to the GPRS network, thereby realizing the communication between the mobile terminal and the monitoring center on the Internet across the GPRS network. References: [1] Li Yanqing et al. Design of a vehicle monitoring system based on GPRS/GPS [J]. Microcomputer Information, 2004, 20-4: 39-40. [2] Ales Sandro Rubini et al. LINUX Device Drivers (Third Edition) [M]. China Electric Power Press, 2005. [3] Cheng Jie, Lu Xin. Research on GPS data acquisition on embedded Linux platform [J]. Journal of Jiangxi University of Science and Technology, 2006, vol.27, No.3. [4] Liu Xu, Zhang Qishan. A vehicle monitoring system based on GPRS [J]. Telemetry and Remote Control, 2003, 1, 42-45.