Integrated System for Official Vehicles with Online Reservation and Moving Path Monitoring

Abstract

Companies have official vehicles for the convenience and time efficiency of employees to carry out official duties. However, private uses, false reports of fuel consumption, and excessive use by users may harm the company’s finance and reputation. Moreover, it is difficult to quantify and manage the use of official vehicles as they are used by different groups in the company. Locating vehicles also is a problem that is caused by inappropriate management. To solve these problems, an online monitoring and management system of official vehicles is proposed in this study. The system includes a set-top box (STB), key cabinet unit, line bot, and backstage management system in four major units with GPS and moving path tracking functions. The STB functions include GPS mobile tracking, power management, and Wi-Fi communication. The key cabinet unit manages key storage for the STB and detects the location of the set-top box. The backstage management system stores general information and GPS locations of vehicles. Line Bot allows online management, and the backstage management system provides administrators with information on official vehicle uses. The test result of the system shows successful monitoring of the vehicles on identifying moving paths, mileage, and locations with an accuracy of 5 m. The system prevents doubled reservations and informs the exact location of the vehicles. It helps the administrator of the official vehicles monitor and analyze the data of uses of the vehicles to improve the management efficiency and prevent misuse of the vehicles. The system also provides a solution for sharing economy of vehicles.

1. Introduction

Official vehicle management systems usually have a global positioning system (GPS) and tracking system [1,2,3,4,5,6,7,8]. The system also uses various technologies related to networking and online cloud services. Almomani et al. [1] proposed a vehicle tracking system with security services to monitor the driving behavior of employees or the usage of vehicles. In the tracking system, violation reports and the last parking positions are viewed on the web page of the system, and the users receive warnings via short message service (SMS) from the system. The driving status of a vehicle is monitored on mobile phones to help companies manage the vehicles for safety purposes. Ramadan et al. [2] proposed a system that sends messages to users and turns off vehicles with sensing technologies and a global system for mobile communication (GSM) module. The coordinates of vehicles are collected in an XML file format, and the position is shown on Google Earth. The positioning error is corrected through the Kalman filter. Fleischer et al. [3] used the GSM/GPS to obtain the location of a vehicle to prevent robberies and traffic accidents for the companies providing inter-city transportation services. Their system integrated an LCD screen in the onboard unit for users to find the exact location of a vehicle and estimate its arrival time. Behzad et al. [4] used infrared sensing technology to detect and send short messages about a stranger’s approach to a parked vehicle and an accelerometer to detect the vehicle’s vibration to prevent thefts. Joshi et al. [5] developed a system that sends the location of vehicles to a cloud server to track vehicles’ movement by using GPS. Then, a geographic information system (GIS) is integrated to record a vehicle’s moving path so that the manager guides the driver on the most effective path. Zhang et al. [6] used the received signal strength (RSS) of each access point (AP) of Wi-Fi by passengers to locate a bus and estimate the travel time on the same path and predict the arrival time.

Due to the development of sensing technologies for autonomous driving, Dewan and Agarwal used various sensors to detect vehicles in motion [7]. For example, a vibration sensor senses a collision, an ultrasonic wave measures the distance between the vehicles, and the light signal and alarm warning allow the user to take emergency measures immediately. In an accident, the GSM system automatically sends an alarm to the rescue team or family members. To better manage vehicle conditions, Hussain et al. [8] developed a vehicle health monitoring system in 2021. Through the Internet of Things, the parameters such as fuel consumption, tire pressure, and power management of the vehicle are monitored, and the vehicle fault data are transmitted to the user’s mobile phone through the onboard diagnostics (OBD). Administrators use a cloud server to monitor vehicles’ status and prevent unexpected malfunctions, saving the cost of repair and fuel.

To improve the efficiency of business trips and sharing economy, companies have been leasing vehicles for official use in recent years. However, the problems of private use, low use rate, and inappropriate management need to be solved [1,2,3,9]. According to Ab Majid et al. [9], the abuse of public equipment of a company has an obvious impact on the company’s financial situation in the short term and might become a common habit as a culture in the long term. Mismanagement of public equipment such as official vehicles has a serious impact, too. Therefore, for companies to manage their official vehicles efficiently, an integrated system is required containing the above-mentioned functions.

Thus, we propose a system that enables online reservation, moving path monitoring, and the exact location of official vehicles to provide a convenient management system in real-time. The system is designed to contain a set-top box, key cabinet box, Line Bot, and a cloud database system. The set-top box has GPS location tracking, power management, and Wi-Fi communication functions. The key cabinet contains a set-top box and a power supply. Line Bot shows the status of the online reservation, the key of an official vehicle, and the key cabinet number. The system provides managerial information such as the status, location, moving path, and accidents. The proposed system is expected to improve the efficiency of managing the official vehicles of a company and help the sharing economy be realized with advanced and integrated functions.

2. System Architecture

The system proposed in this study comprises four units: a set-top box, key cabinet, Line Bot, and a cloud database system (Figure 1). A user is allowed to make a reservation to use a vehicle through the Line Bot. Line Bot is used for push services in various applications such as students’ learning to save cost and enhance communication [10,11]. When the user pulls out a key and a set-top box from the key cabinet, the system activates the set-top box through radio-frequency identification (RFID) and sends the information to the cloud server. When the user returns the key and set-up box to the key cabinet, the official vehicle’s information in the set-top box is delivered to the cloud database system to let the system be in waiting mode. The detailed functions of the four units of this system are described as follows.

2.1. Set-Top-Box (STB)

The set-top box includes a power supply module, GPS module, micro-SD memory storage device, 3-axis accelerometer and gyroscope, and a microcontroller with Wi-Fi communication function (Figure 2). The STB stores the basic information about a vehicle, such as a license plate number. Its lithium-polymer battery is charged in the key cabinet. The user places the set-top box on the charging stand in the vehicle. When the vehicle starts to move, the GPS starts to record the moving path and stores it on the micro-SD card. When returning the vehicle, the user places the set-top box and the key in the key cabinet. The data in the SD card are automatically transferred to the cloud server. The detailed structure of the STB is as follows.

2.1.1. Power Supply Module

A lithium battery with high-temperature adaptability is used in the power supply module. The battery supplies 3.7 V and 2400 mAh and is rechargeable more than 500 times. The system voltage is maintained at lower than 2.95 V. Charging the battery is stopped when the system voltage becomes higher than 4.2 V. The battery is equipped with a booster circuit with an operating frequency of 150 kHz and conversion efficiency of 85% to provide DC 5 V to the control system with a maximum output of 0.4 A.

2.1.2. Control System

It contains a microcontroller (MCU), GPS receiver, micro-SD card device, and 3-axis altitude and gyroscope.

(a)

The MCU has a dual-core CPU with a working clock of 160/240 MHz, 448 KB of ROM, and 520 KB of SRAM. It supports 802.11 b/g/n transmission protocol. It has a total of 34 GPIOs externally, and multiple communication interfaces such as SPI, I2C, and UART enable communication with multiple different sensors or devices.

(b)

The GPS receiver uses the interface protocol developed by NMEA for three specifications: 0180, 0182, and 0183. The NMEA-0183 protocol is used in detectors, sonars, anemometers, GPS receivers, and other devices. The transmission data are encoded in ASCII code, and its communication format is shown in

Table 1. Contents of various sentences in NMEA.

Messages	Meaning
GGA	Time (UTC), Latitude, N or S (North or South), Longitude, E or W (East or West), GPS Quality Indicator, Number of satellites in view, Horizontal Dilution of precision, Antenna Altitude above/below mean-sea-level, Units of antenna altitude, etc.
GLL	Latitude, N or S (North or South), Longitude, E or W (East or West), Time (UTC), Status A-Data Valid, V - Data Invalid, Checksum.
GSA	Selection mode, PDOP, HDOP, VDOP, the ID of 1st satellite used for the fix, etc.
GSV	A total number of messages, Message number, satellite in view, Satellite number, Elevation in degrees, Azimuth in degrees to true, SNR, Checksum.
RMA	Latitude, N or S, Longitude, E or W, Time Difference, Magnetic Variation, Speed Over Ground, etc.
RMC	Time (UTC), Status, Latitude, N or S, Longitude, E or W, Speed over ground, Track degrees, Date, Magnetic Variation, Checksum.
VTG	Track Degrees, Speed Knots, Speed Kilometers Per Hour, Checksum, etc.

. Each statement has a different length, and the longest bit is up to 82 bits. In this study, the sentence at the beginning of GPRMC is used for analysis. Thus, the content of each sentence group such as the current latitude and longitude, hemisphere, and UTC is separated by commas. A sentence starts with $, and the CR and LF codes of ASCII are used as the end code of the sentence. The code is stored in the micro-SD memory card after processing the character strings.

(c)

Accelerometer and gyroscope

The motion of the vehicle in driving is divided into three: straight moving, stopping and turning. To obtain the exact GPS position and reduce sampling points, a 3-axis accelerometer and a gyroscope are used with GPS. As the STB is placed in front of the driver’s seat, the three-axis acceleration is defined, as shown in Figure 3.

When a vehicle is moving straight, its motions are in acceleration, constant velocity, or deceleration. As shown in Figure 4, the distance between points is calculated by using Equation (1) [12,13].

d = R × cos⁻¹ (sinΦ₁ sinΦ₂ + cosΦ₁ cosΦ₂ cos(∆λ))

(1)

where R is the radius of the earth (≅6371 km), P (λ₁, Φ₁) and Q (λ₂, Φ₂) are the longitudinal and latitudinal coordinates of two points on the sphere, Δλ is the difference in the longitude (radii) of the two points (absolute value), and d is the straight-line distance between P and Q on the ground.

When the vehicle is accelerated or decelerated (B and D in Figure 5), the sensed acceleration (ax > 0 or ax < 0) is recorded in the micro-SD card. When the vehicle moves at a constant speed (ax ≈ 0) and the angular velocity w detected by the gyroscope is close to a constant value (θ = constant) (at C), the GPS data are not recorded on the SD card. When the vehicle stops (at A in Figure 5), the acceleration is zero (ax = 0) with a fixed angular velocity w (θ = constant). For n GPS locations per second, the system constantly compares the distance between Pn and Qn. When d is less than the preset dmin, the GPS data are stored as the movement of the vehicle is regarded as stopping and waiting. When the vehicle turns (D, E, and F), the gyroscope measures the angular velocity w of the vehicle, sets the variation of w (±θ), and the GPS data are recorded in the micro-SD card.

(d)

SD card storage device

The data format of the official vehicle’s travel route is designed for time, longitude, and latitude and does not change due to time. Therefore, it is appropriate to use comma-separated values (CSV) for data storage. If the longitude is taken to the fifth decimal place, the error value is about 1.1 m. To improve the accuracy of vehicle displacement, the GPS data are taken to the 8th decimal place. Then, the GPS data of the vehicle on each trip are stored in the serial peripheral interface (SPI) format.

(e)

Cloud server

After the user returns the key and the STB of the vehicle to the cabinet, the stored data of the micro-SD card are automatically transmitted to the cloud server through WiFi (Figure 6). The data are uploaded to the database of the cloud server in JavaScript object notation (JSON) format (Figure 7). The JSON format has the characteristics of reading, writing, and lightweight and is easy to parse and classify in the background database. In uploading the data, the STB acts as a client and sets the URL and IP address in the background to submit the data to the backend SQL server database by POST method in the hypertext transfer protocol (HTTP). The data are displayed on the management page through the classification processing of driving data. To avoid data abnormality and loss during transmission, the server returns the number and status to define the following status codes after each data transmission. The STB then makes a warning according to the status code, as shown in

Table 2. Background data system return code status table and actions.

Response Code	Status	GPS STB Action
0	Data upload error	Specific data retransmission
1	Data reconstruction fail	All data retransmission
2	Success	Lighting-off/Sleep-mode
3	Unknown error	The buzzer keeps beeping

, when the transmission data are abnormal.

2.2. Key Cabinet

The key cabinet is composed of multiple sub-cabinets. Each sub-cabinet stores the key and STB of a vehicle (Figure 8). It has an RFID device, electromagnetic lock, charging device, and Wi-Fi communication module, which are powered by an AC/DC conversion power supply (AC110 V to DC 5.0 V). Each cabinet has an indicator light that is turned on when the key and the STB are taken away. The sub-cabinet is then in an idle mode and can be used for other keys and STBs.

The internal layout of a sub-cabinet is shown in Figure 9. The control circuit manipulates components such as power supply, 5 V voltage regulator, 110 V main socket, RFID sensor, MCU control circuit, WiFi module, and electromagnetic valve lock. The material of the key cabinet is acryl which does not affect the RFID data and WiFi communications.

Figure 10 shows the architecture of the sub-cabinet. The placement of the STB from its charging stand activates the RFID to read the information from the STB. When the STB and key are put in or moved from the sub-cabinet, the RFID sensor transmits the license plate information to the MCU that processes the information coding in JSON format. The coded information is uploaded to the cloud server. The return code in JSON format is sent back to the MCU to confirm the placement or displacement of the key and STB. The RFID card has a 1 KB EEPROM memory. To manage and achieve the multi-purpose function properly, the memory space is divided into 16 sectors, each of which has 4 blocks. Block 0 of segment 0 contains the card’s unique identification code (user identifier, UID). In this study, the license plate information is stored in block 0 of Section 1 (Figure 11). The WiFi communication format uploads data through the POST method in the HTTP, which is also encoded in JSON format. The uploaded information includes data on the location, license plate, sub-cabinet, and the open/close of cabinet doors.

2.3. Cloud Server

The cloud server stores data by interfacing with Line API so that managers can conduct data analysis of the vehicles. The familiar interface of Line allows users to use the system easily to reserve the use of the cabinet. The diagram of the cloud server is shown in Figure 12. For making a reservation, a user opens the cabinet door through LINE and takes the key and STB. At the same time, the information of the user is sent back to the cloud server. In the background management system, the use of official vehicles is managed and monitored.

The back-end management in the cloud server has the following nine functions (Figure 13):

(a)

Historical records such as date, user name, the license plate, number of uses, and period of use;

(b)

Vehicle route query for total time and distance of a trip;

(c)

Manager account for uses including information of people, groups, and administrator accounts;

(d)

Group management for users by teams or departments;

(e)

Employee’s account for the mobile phone number, name, and employee number;

(f)

Vehicle management for recording total and recent mileage of a vehicle and warning for vehicle maintenance;

(g)

Vehicle reservation for showing the status of vehicles;

(h)

Field management for checking the status of keys and STBs;

(i)

Mileage check by vehicles, groups (departments) in a certain period.

To manage the huge amount of data in the system efficiently, formalized work is indispensable to avoid data duplication and waste storage. During the normalization process, the data structure is adjusted to reduce the abnormal data. These processes include the first normal forms of 1NF, 2NF, and 3NF, and the Boyce-Codd Normal Form (BCNF). In addition to the above four, 4NF, 5NF, Domain/key Normal Form, and 6NF can be added. Each normalization reduces the chance of occurrence of abnormal data. Through the process, the database satisfies 3NF with high regularization. Although it has better constraints on data association, it increases the number of data association tables for the input and output of the database. Therefore, the proposed system uses the third level of normalization. Figure 14 presents a schematic diagram of the normalization level.

2.4. LINE Bot

Due to the high development cost of iOS and Android platforms and the compatibility between different versions, we adopt the third-party software Line Bot. The Line Bot service is provided by the Line App for background communication with cabinets and cloud servers. Line Bot uses Messaging API and LINE Notify for cabinet opening and vehicle reservation. Messaging API is a simple Line chatbot that provides Push and Replies messages to establish two-way communication between LINE users. In the communication, the JSON format is used in the HTTP, as shown in Figure 15. Messaging API provides two forms of API, Push and Reply. The Push API triggers the sending of message events and actively pushes messages to registered users. The Reply API provides specific “message feedback” according to what the registered user commands the robot, as shown in Figure 16.

LINE Notify pushes notification messages through the official LINE Notify account. When the users of the official account of the system agree on the one-on-one push notifications through LINE Notify, the administrator uses LINE Notify for push notifications. The users are notified that they receive notifications on LINE Notify, and administrators send unlimited notifications to the users to save costs.

3. System Build-Up and Test Results

3.1. STB

The circuit design and finished product of the set-top box are shown in Figure 17 and Figure 18, respectively. The circuit is designed with the Altium Designer software. The STB is designed with Autodesk Fusion 360. To have a stable power supply in a vehicle, a universal base of a 5 V USB charging cable is used (Figure 19).

3.2. Key Cabinet

The 3D diagram of the key cabinet is shown in Figure 20. Figure 21 and Figure 22 show the internal circuit design diagram and PCB layout of the official vehicle cabinet. To solve the problem that the I2C signal of RFID is easily affected by the relay coil, the upper and lower boards are designed to have reduced sizes.

3.3. Data Format Transmission Test

In the database reorganization of transmitted GPS data, the GPS satellite time is out of synchronization with the server time. Thus, it is impossible to distinguish each GPS datum when reorganizing the data. Given this situation, the background database generates a set of random 32-character keys when the STB operates so that each datum can be distinguished. After repeating data format improvement, the STB uploads the data in the JSON format, as shown in Figure 23. After the backend server identifies the number of each group of data and the corresponding user, the device proceeds to the next step according to the return code of the backend server.

The transmission format of the independent key locker transmits data every second in the JSON format to find out whether a registered user in the server uses a vehicle. This action is verified through the computer’s serial transmission platform SSCOM. When accessing the background database system, it returns messages such as “myregion” (the company’s area), “myboxID” (the cabinet), “has_open” (whether there is an open cabinet), and “box_status” (whether the cabinet has the key and STB). If no user uses the key and STB in a sub-cabinet, the return values of the “has_open” and “box_status” background database systems are both “0”, as shown in Figure 24.

When a user opens a cabinet, “has_open” becomes “1”, indicating that the door handle of the cabinet is opened. If the STB is taken out and the RFID cannot read the information of the STB, “box_status” is displayed as “1”, indicating that the STB is used by the user, as shown in Figure 25.

3.4. Communication Transmission Test

To test whether the GPS data of the STB successfully transmitted to the background server, a test is performed through the third-party software Postman, as shown in Figure 26. The test data are put in the JSON format, and a request URL is sent to the by POST. The transmission result is displayed in the lower right. The status code is 200, which means the transmission is successful and the server-side receiver functions normally.

For testing STB transmission, a program is created in C language and ported to the MCU on the backend server (Figure 27). When tested with the same request URL, the GPS path data and transmission time are successfully displayed on the server side (Figure 28).

3.5. Actual Measurement of Driving

The test for actual measurement is carried out for three different movements: moving straight, stopping, and turning.

When a vehicle stops on the side of the road, the recorded value of the GPS value drifts significantly. The drift is corrected by the three-axis acceleration measurement function. When the vehicle is stationed, the three-axis acceleration detection amount is zero (ax = 0), and the angular velocity w (θ = constant) of the gyroscope is a constant value. d, a distance between two points is calculated based on the recorded value of GPS with the default value dmin of 2.0 m. When d is less than dmin, it is not recorded. Figure 29a shows the judgment without the three-axis acceleration, the angular velocity measurement value of the gyroscope, and dmin. The drift of GPS data become large when the vehicle stops and stays. When adding the three-axis acceleration, the angular velocity measurement value of the gyroscope, dmin, and the drift significantly decreases Figure 29b.

In a driving test, an average moving speed is about 40 km/h. Figure 30 shows that movement tracking is performed at sampling intervals of 1 and 5 s. In Figure 30a, when the sampling interval is long, blind spots occur at the corner, resulting in a large deviation in the point-to-point connection of the path movement tracking. Thus, a short sampling interval allows movement tracking to be more efficient, as shown in Figure 30b.

However, the sampling interval is related to the speed of the vehicle. Figure 31a,b show the monitoring of the angular velocity change. Under the test speed of 40 km/h, θ = ±300 and θ = ±150 are used to track the movement tracking at the turn. The red dots represent the coordinates recorded by the GPS. The actual measurement found that the movement is effectively recorded at the turn. The smaller the θ, the denser the tracking points.

Figure 32 shows the test of the motion tracking in a straight line on a highway with a path length of 350 m. The GPS data are recorded every 0.5 s, as shown in Figure 32a and when the attitude sensor detects the acceleration value (ax = ±0.1 g). The comparison shows that the use of acceleration value changes requires less data storage to track the movement, as shown in Figure 32b.

3.6. Back-End Management System

As mentioned above, the web page has nine functions. How a user makes a reservation through Line API is shown in Figure 33, and the administrator’s display is shown in Figure 34.

In the back-end system, administrators can search the user’s past driving records. The record can be quickly searched with date, user information, and vehicle information, as shown in Figure 35 and Figure 36. The Google map API is used for the vehicle path query to show the historical trajectory.

Figure 37 shows the management system of the official vehicle. To manage the personal data of employees easily, the system allows accounts for three managers, four departments, and five employees for account management. The administrator account information is required to log in to the system, as shown Figure 37a. The required information can be changed according to the situation. In the department account, employees of each department are registered to manage their vehicle uses. In the employee account, the personal information of employees is managed after it is registered through the Line API, as shown in Figure 37b,c.

In Figure 38, the field management menu is used to manage the key cabinet. The license plate information is displayed to show whether the key and STB of the vehicle are in the cabinet.

Figure 39 shows the information on each vehicle’s uses, including license plate numbers, mileage, and maintenance intervals. This menu alarms a manager for maintenance according to the vehicle’s mileage. After the maintenance, the manager resets the maintenance kilometers again. The mileage of different departments is shown in the sector kilometer menu (Figure 40). When the user registers the account, it is connected to the corresponding department. The mileage of all employees in the department is summed up for managers to analyze the use of the official vehicles by departments.

4. Conclusions

The monitoring system of official vehicles prevents private and unauthorized uses, saves fuel costs, and improves the efficiency of their uses. Thus, a management system with the function of online reservation and path monitoring is proposed in this study. The system includes a set-top box, key cabinet, Line Bot, and a cloud server. The trajectory and movement of the vehicle are recorded by using GPS, three-axis attitude meter, and gyroscope with MCU, stored in a micro-SD card and sent to the cloud server through a WiFi communication system when the STB is placed in the cabinet. The algorithm of the system reduces the required data to process. The back-end management system allows various modes of management of the vehicles and their uses and statistical analysis of the vehicle uses. The management modes and various functions such as monitoring the movement track of each vehicle and analyses of the vehicle used by person, group, and organization are tested. The result verifies that the proposed system is effective and efficient in monitoring and managing official vehicles by providing administrators with historical movement trajectories, mileage by various departments, maintenance mileage, reservation system, and so on to achieve the effect of official vehicle management.