Subway multi-line vehicle management method based on automatic registration

Abstract

The invention discloses a subway multi-line vehicle management method based on automatic registration, and the method comprises the following steps: S1, a vehicle-mounted server sends an authentication request to a network center cloud platform, automatically registers a vehicle through a naming rule, and carries out the data collection in a passive obtaining manner; s2, providing a vehicle authentication interface by the data center, and obtaining a permanent token through the vehicle authentication interface; s3, reporting the heartbeat of the vehicle-mounted server and the running state of the vehicle based on the token cycle, and judging the off-line state of the vehicle according to a heartbeat overtime threshold value; and S4, the vehicle obtains the state of the vehicle-mounted equipment regularly, and uploads the state of the vehicle-mounted equipment to the data center regularly according to the interaction protocol. According to the invention, a vehicle automatic registration form is adopted, different lines, vehicles and devices are distinguished according to naming rules, the management of the data center is more flexible, communication resources and network bandwidth are saved, communication pressure is reduced, and the expandability of the data center is increased.

Description

Technical Field

[0001] This invention relates to the field of vehicle management technology, and in particular to a method for managing multiple subway lines based on automatic registration. This method achieves real-time display and control of the operating status of multiple lines of vehicles through protocols such as automatic registration, online / offline status, and status uploading. Background Technology

[0002] Although my country's urban rail transit system is currently planned and constructed as a network, it is only built and operated as a single line, without forming the overall benefits of network operation.

[0003] like Figure 1 As shown, the existing solution involves deploying a server in the station hall computer room for a single line to periodically make HTTP data requests to the on-board servers of each vehicle to obtain the equipment status information of all vehicles on the current line.

[0004] However, this method has the following drawbacks:

[0005] 1. The server in the station hall needs to periodically poll all vehicles on the current line. During the system setup phase, the correspondence between the vehicle number and IP address of all vehicles needs to be entered in advance.

[0006] 2. When the vehicle server IP or vehicle number is changed, staff need to manually modify the vehicle number or IP in the station hall computer room management system.

[0007] 3. When the vehicle returns to the garage and the signal is lost, the requests sent by the station hall server cannot be responded to, resulting in a waste of the station hall server resources;

[0008] 4. The current technology, deployed as a server, only supports the acquisition, display, and management of the status of all vehicles on the current route. Summary of the Invention

[0009] The purpose of this invention is to provide a technical solution for a multi-line subway vehicle management method based on automatic registration, addressing the shortcomings of existing technologies. This vehicle management method adopts automatic vehicle registration, establishes a dedicated interaction protocol, and uses naming rules to distinguish different lines, vehicles, and equipment. When the data center receives registration information but the vehicle does not exist, it will actively add the vehicle data based on the registration information. This makes data center management more flexible, saves communication resources and network bandwidth, reduces communication pressure, and increases the scalability of the data center.

[0010] To solve the above-mentioned technical problems, the present invention adopts the following technical solution:

[0011] A method for managing multiple subway lines based on automatic registration, characterized by the following steps:

[0012] S1. The vehicle-mounted server sends an authentication request to the cloud platform of the network center and automatically registers the vehicle according to the naming rules, and collects data in a passive manner.

[0013] S2, the data center provides a vehicle authentication interface, through which a permanent token can be obtained;

[0014] S3. Report the heartbeat and vehicle operating status of the vehicle server based on the token period, and determine the vehicle offline status based on the heartbeat timeout threshold.

[0015] S4. The vehicle periodically obtains the status of the on-board equipment and uploads the status of the on-board equipment to the data center according to the interaction protocol.

[0016] This vehicle management method uses automatic vehicle registration and establishes a dedicated interaction protocol. It uses naming rules to distinguish different routes, vehicles, and equipment. When the data center receives registration information but the vehicle does not exist, it will actively add the vehicle data based on the registration information. This makes data center management more flexible, saves communication resources and network bandwidth, reduces communication pressure, and increases the scalability of the data center.

[0017] Furthermore, the naming rules in step S1 include city, line, and train.

[0018] Furthermore, the data collection in step S1 includes the unified collection of vehicle heart rate, equipment status, and naming conventions.

[0019] Furthermore, the vehicle authentication interface in step S2 specifically includes the following steps during authentication:

[0020] After the S2.1 line was completed, the data center assigned authentication accounts and passwords to the line.

[0021] After the S2.2 vehicle-mounted server connects to the vehicle-to-ground wireless network for the first time, it sends an HTTP authentication request to the data center.

[0022] The S2.3 data center compares the account and password. If they match, it returns an authentication token. If they do not match, it fails and returns an error. All subsequent data interactions must carry this token to be allowed by the data center gateway service.

[0023] After receiving this token, the S2.4 vehicle server chooses to save it to a local file;

[0024] If the S2.5 token is lost, the data center allows the vehicle-mounted server to repeat the above steps for re-authentication.

[0025] Furthermore, the heartbeat interaction of the vehicle server in step S3 specifically includes the following steps:

[0026] The S3.1 vehicle-mounted server carries an authentication token and sends an HTTP heartbeat request to the data center via vehicle-to-ground wireless communication.

[0027] After receiving the request, the S3.2 data center verifies the token. If the token is correct, it queries whether the current vehicle is a registered vehicle based on the train_code.

[0028] S3.3 When a user queries the current route status, the data center provides a list of all registered vehicles for display. The data center calculates the difference between the current time and the vehicle's last login time. If the difference is greater than a set time, the vehicle is determined to be offline until a heartbeat request is received again to restore it to online status.

[0029] Furthermore, step S3.2, which involves querying whether the current vehicle is a registered vehicle based on the train_code, includes:

[0030] S3.2.1 Registered: Record the current time and update it to the vehicle's last heartbeat time;

[0031] S3.2.2 Not registered: Record the current train_code as the vehicle identifier, and record the current time as the last heartbeat time of the current vehicle.

[0032] Furthermore, step S4, which involves periodically uploading the status of the vehicle-mounted equipment to the data center according to the interaction protocol, specifically includes the following steps:

[0033] The S4.1 vehicle-mounted server carries an authentication token and sends HTTP device status reporting requests to the data center via vehicle-to-ground wireless communication.

[0034] After receiving the request, the S4.2 data center verifies the token. If it is correct, it locates the cached data of all devices in the vehicle based on the train_code and locates the specific device in the current vehicle based on the name field.

[0035] S4.3 Device status reporting also serves as a supplement to vehicle heartbeat. Even if no heartbeat request is received, the presence of device status reporting can still be used as a criterion for determining whether a vehicle is online.

[0036] S4.4 When a vehicle reports an abnormal device status, the data center marks the vehicle, selects the vehicle to expand the list of onboard devices, and selects the onboard device to view the current parameters and fault description.

[0037] Furthermore, step S4.2, locating the specific device in the current vehicle based on the name field, includes:

[0038] S4.2.1 Device exists: Compare with the current vehicle device status data in the cache. If there are differences, update the differences to the cache and record them in the database.

[0039] S4.2.2 Device does not exist: Store the current device information in the cache and database.

[0040] The present invention, by adopting the above-described technical solution, has the following beneficial effects:

[0041] 1. Compared with the existing solutions' data center actively acquiring data interaction protocols, this invention re-formulates the interaction protocol to passively collect data, including unifying vehicle heartbeat, equipment status, naming conventions, etc., to ensure the consistency of data interaction.

[0042] 2. The deployment location of the data center in the traditional solution has been changed from the station hall computer room to the dedicated cloud server in the line network center. A naming method has been introduced to distinguish lines, vehicles and equipment, so as to meet the needs of the data center to connect to multiple lines.

[0043] 3. Change the data acquisition method of the data center from active acquisition to passive acquisition to avoid invalid data requests to the data center when the vehicle is offline, reduce the data interaction pressure of the data center, and improve the performance of the data center.

[0044] 4. Enhance vehicle authentication interaction and strengthen data center security. The data center provides independent account passwords for each line.

[0045] 5. Device management via automatic registration is more flexible than manual data collection, eliminating the need to pre-add route and vehicle information and enabling automatic device management. Attached Figure Description

[0046] The present invention will be further described below with reference to the accompanying drawings:

[0047] Figure 1 A system architecture diagram for deploying servers in a station hall computer room using a single line in existing technologies;

[0048] Figure 2 This is a flowchart of a subway multi-line vehicle management method based on automatic registration according to the present invention;

[0049] Figure 3 This is a flowchart illustrating the authentication process performed by the vehicle authentication interface in this invention.

[0050] Figure 4 This is a flowchart of the heartbeat interaction of the vehicle-mounted server in this invention;

[0051] Figure 5 This is a flowchart illustrating the process of periodically uploading the status of the vehicle-mounted equipment to the data center according to the interaction protocol in this invention;

[0052] Figure 6 This is a timing diagram in the present invention;

[0053] Figure 7 This is a diagram illustrating the normal device attributes in this invention;

[0054] Figure 8 This is a diagram illustrating the attributes of the offline device in this invention;

[0055] Figure 9 This is a diagram illustrating the attributes of the faulty device in this invention. Detailed Implementation

[0056] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0057] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0058] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.

[0059] like Figures 2 to 6 As shown, this invention provides a method for managing multiple subway lines based on automatic registration, comprising the following steps:

[0060] S1. The vehicle-mounted server sends an authentication request to the cloud platform of the network center and automatically registers the vehicle according to the naming rules, and collects data in a passive manner.

[0061] The naming rules include city, route, and train. The naming rules are shown in Table 1.

[0062] type Naming Rules Example Remark Line name City name (in pinyin) - Route number hangzhou_1 Each route has a unique identifier. Vehicle Name Route Name_Vehicle Number hangzhou_1_1 Each vehicle has a unique identifier. Device Name Equipment Type_Carriage Number_Equipment Number LCD_1_1 Unique Identifier for In-Vehicle Equipment

[0063] Table 1

[0064] Data collection includes the unified collection of vehicle heart rate data, equipment status data, and naming conventions. The naming conventions are shown in Table 2.

[0065]

[0066]

[0067] Table 2

[0068] S2. The data center provides an HTTP-based vehicle authentication interface, through which a permanent token is obtained; the vehicle server performs re-authentication after each restart.

[0069] The vehicle authentication interface performs the following steps during authentication:

[0070] After the S2.1 line was completed, the data center assigned authentication accounts and passwords to the line, with the passwords encrypted using MD5.

[0071] After the S2.2 vehicle-mounted server connects to the vehicle-to-ground wireless network for the first time, it sends an HTTP authentication request to the data center. For details on the request interface and protocol, please refer to "Interface Address" and "Request Example".

[0072] The S2.3 data center compares the account and password. If they match, it returns an authentication token. If they do not match, it fails and returns an error. All subsequent data interactions must carry this token to be allowed by the data center gateway service.

[0073] After receiving this token, the S2.4 vehicle server chooses to save it to a local file to facilitate service restart due to power outages, malfunctions, upgrades, etc.

[0074] If the S2.5 token is lost, the data center allows the vehicle-mounted server to repeat the above steps for re-authentication.

[0075] API address: [POST] / api / v1 / pis / login

[0076] Request example:

[0077]

[0078]

[0079] S3. Based on the token period, report the heartbeat of the vehicle server and the vehicle's operating status, and determine the vehicle's offline status according to the heartbeat timeout threshold; the vehicle server reports the current vehicle operating status with a heartbeat every 15 seconds, and if the data center does not receive a heartbeat for more than 1 minute, it determines that the vehicle is offline.

[0080] The heartbeat interaction of the vehicle-mounted server specifically includes the following steps:

[0081] The S3.1 vehicle-mounted server carries an authentication token and sends an HTTP heartbeat request to the data center via vehicle-to-ground wireless communication. For specific request interfaces and protocols, please refer to "Interface Address" and "Request Example". The "train_code" field in the request interface must follow the vehicle name naming rules in Table 2.

[0082] After receiving the request, the S3.2 data center verifies the token. If the token is correct, it queries whether the current vehicle is a registered vehicle based on the train_code.

[0083] Checking whether the current vehicle is a registered vehicle based on the train_code includes:

[0084] S3.2.1 Registered: Record the current time and update it to the vehicle's last heartbeat time;

[0085] S3.2.2 Not registered: Record the current train_code as the vehicle identifier, and record the current time as the last heartbeat time of the current vehicle.

[0086] S3.3 When a user queries the current route status, the data center displays a list of all registered vehicles. The data center calculates the difference between the current time and the vehicle's last login time. If the difference is greater than a set time, the vehicle is considered offline until a heartbeat request is received to restore it to online status. If the difference is greater than 1 minute, the vehicle is considered offline until a heartbeat request is received to restore it to online status. When a vehicle is offline, the data center marks it in gray.

[0087] API address: [POST] / api / v1 / pis / update / {train_code}

[0088] Response example:

[0089]

[0090] S4. Vehicles periodically obtain the status of onboard equipment and upload it to the data center regularly (every 3 minutes) according to the interaction protocol. When there are too many devices, different types of devices can be reported in batches. The data includes key data such as temperature, disk, CPU, memory, and device fault information. The data center determines the vehicle's operating status based on "train_status" and, after analyzing the vehicle's heartbeat and device status data, can provide the user system with a variety of device status displays, such as green for vehicles entering the warehouse, red for vehicles with equipment faults, yellow for vehicles in operation, and gray for vehicles offline.

[0091]

[0092] Table 3

[0093]

[0094]

[0095] Table 4

[0096] The specific steps involved in periodically uploading the status of the vehicle-mounted equipment to the data center according to the interaction protocol are as follows:

[0097] The S4.1 vehicle-mounted server carries an authentication token and sends an HTTP device status reporting request to the data center via vehicle-to-ground wireless communication. For specific request interfaces and protocols, see "Interface Address" and "Request Example". For the field attributes in the request example, see Tables 3 and 4. In the request example, the "train_code" field must follow the vehicle name naming rules in Table 2; the "name" field must follow the device name naming rules in Table 2; the "status" field can identify the current status of the device, with true indicating that the device is online and false indicating that the device is offline.

[0098] After receiving the request, the S4.2 data center verifies the token. If it is correct, it locates the cached data of all devices in the vehicle based on the train_code and locates the specific device in the current vehicle based on the name field.

[0099] Locating specific devices in the current vehicle based on the name field includes:

[0100] S4.2.1 Device exists: Compare with the current vehicle device status data in the cache. If there are differences, update the differences to the cache and record them in the database.

[0101] S4.2.2 Device does not exist: Store the current device information in the cache and database.

[0102] S4.3 Device status reporting also serves as a supplement to vehicle heartbeat. Even if no heartbeat request is received, the presence of device status reporting can still be used as a criterion for determining whether a vehicle is online.

[0103] S4.4 When a vehicle reports an abnormal device status, such as temperature > 75℃, memory usage > 90%, CPU usage > 90%, or device status unavailable, the data center will display the vehicle in red. Clicking on the vehicle will expand the list of onboard devices; faulty devices will be displayed in red, offline devices in gray, and other normal devices in green. Clicking on an onboard device will display its current parameters and fault description. Figures 7-9 As shown.

[0104] API address: [POST] / api / v1 / pis / dev_status

[0105] Request example:

[0106]

[0107] Response example:

[0108] {

[0109] "code":200,

[0110] "msg":"success"

[0111] }

[0112] This vehicle management method uses automatic vehicle registration and establishes a dedicated interaction protocol. It uses naming rules to distinguish different routes, vehicles, and equipment. When the data center receives registration information but the vehicle does not exist, it will actively add the vehicle data based on the registration information. This makes data center management more flexible, saves communication resources and network bandwidth, reduces communication pressure, and increases the scalability of the data center.

[0113] The above are merely specific embodiments of the present invention, but the technical features of the present invention are not limited thereto. Any simple changes, equivalent substitutions, or modifications made based on the present invention to achieve substantially the same technical effect are all covered within the protection scope of the present invention.

Claims

1. A method for managing multiple subway lines based on automatic registration, characterized in that... Includes the following steps: S1. The vehicle-mounted server sends an authentication request to the cloud platform of the network center and automatically registers the vehicle according to the naming rules, and collects data in a passive manner. S2, the data center provides a vehicle authentication interface, through which a permanent token can be obtained; S3. Report the heartbeat and vehicle operating status of the vehicle server based on the token period, and determine the vehicle offline status based on the heartbeat timeout threshold. S4. The vehicle periodically obtains the status of the on-board equipment and uploads the status of the on-board equipment to the data center according to the interaction protocol.

2. The method for managing multiple subway lines based on automatic registration according to claim 1, characterized in that: The naming rules in step S1 include cities, lines, and trains.

3. The method for managing multiple subway lines based on automatic registration according to claim 1, characterized in that: The data collection in step S1 includes the unified collection of vehicle heart rate, equipment status, and naming conventions.

4. The method for managing multiple subway lines based on automatic registration according to claim 1, characterized in that: The vehicle authentication interface in step S2 specifically includes the following steps during authentication: After the S2.1 line was completed, the data center assigned authentication accounts and passwords to the line. After the S2.2 vehicle-mounted server connects to the vehicle-to-ground wireless network for the first time, it sends an HTTP authentication request to the data center. The S2.3 data center compares the account and password. If they match, it returns an authentication token. If they do not match, it fails and returns an error. All subsequent data interactions must carry this token to be allowed by the data center gateway service. After receiving this token, the S2.4 vehicle server chooses to save it to a local file; If the S2.5 token is lost, the data center allows the vehicle-mounted server to repeat the above steps for re-authentication.

5. The method for managing multiple subway lines based on automatic registration according to claim 1, characterized in that: The heartbeat interaction of the vehicle server in step S3 specifically includes the following steps: The S3.1 vehicle-mounted server carries an authentication token and sends an HTTP heartbeat request to the data center via vehicle-to-ground wireless communication. After receiving the request, the S3.2 data center verifies the token. If the token is correct, it queries whether the current vehicle is a registered vehicle based on the train_code. S3.3 When a user queries the current route status, the data center provides a list of all registered vehicles for display. The data center calculates the difference between the current time and the vehicle's last login time. If the difference is greater than a set time, the vehicle is determined to be offline until a heartbeat request is received again to restore it to online status.

6. The method for managing multiple subway lines based on automatic registration according to claim 5, characterized in that: Step S3.2, which involves querying whether the current vehicle is a registered vehicle based on the train_code, includes: S3.2.1 Registered: Record the current time and update it to the vehicle's last heartbeat time; S3.2.2 Not registered: Record the current train_code as the vehicle identifier, and record the current time as the last heartbeat time of the current vehicle.

7. The method for managing multiple subway lines based on automatic registration according to claim 1, characterized in that: Step S4, which involves periodically uploading the status of the vehicle-mounted equipment to the data center according to the interaction protocol, specifically includes the following steps: The S4.1 vehicle-mounted server carries an authentication token and sends HTTP device status reporting requests to the data center via vehicle-to-ground wireless communication. After receiving the request, the S4.2 data center verifies the token. If it is correct, it locates the cached data of all devices in the vehicle based on the train_code and locates the specific device in the current vehicle based on the name field. S4.3 Device status reporting also serves as a supplement to vehicle heartbeat. Even if no heartbeat request is received, the presence of device status reporting can still be used as a criterion for determining whether a vehicle is online. S4.4 When a vehicle reports an abnormal device status, the data center marks the vehicle, selects the vehicle to expand the list of onboard devices, and selects the onboard device to view the current parameters and fault description.

8. A method for managing multiple subway lines based on automatic registration according to claim 7, characterized in that: The step S4.2 of locating the specific device in the current vehicle based on the name field includes: S4.2.1 Device exists: Compare with the current vehicle device status data in the cache. If there are differences, update the differences to the cache and record them in the database. S4.2.2 Device does not exist: Store the current device information in the cache and database.

Images