Fault vehicle inventory method and device, electronic equipment and storage medium

Abstract

This application proposes a method, apparatus, electronic device, and storage medium for inventorying faulty vehicles. The method includes: sending a Bluetooth scanning command to a normal vehicle; wherein the Bluetooth scanning command carries scanning parameters; receiving a Bluetooth device list sent by the normal vehicle; wherein the Bluetooth device list is obtained by the normal vehicle performing a Bluetooth scan based on the scanning parameters; and inventorying faulty vehicles that have not yet been inventoried based on the Bluetooth device list. This method, based on the Bluetooth scanning results of normal vehicles, inventoryes faulty vehicles near normal vehicles, improving the efficiency and success rate of faulty vehicle inventory.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, electronic device, and storage medium for inventorying faulty vehicles. Background Technology

[0002] With the development of vehicle technology, vehicles are increasingly becoming an indispensable means of transportation for people. To improve vehicle management efficiency, vehicle operating companies typically conduct regular vehicle inventory checks. Related technologies allow for vehicle inventory checks based on information reported by the vehicles. However, if a vehicle malfunctions and cannot report the problem, it will be impossible to identify the faulty vehicle during the inventory check. Summary of the Invention

[0003] This application aims to at least partially address one of the technical problems in the related art.

[0004] Therefore, the first objective of this application is to propose a method for inventorying faulty vehicles in order to improve the efficiency and success rate of inventorying faulty vehicles.

[0005] The second objective of this application is to propose an alternative method for inventorying faulty vehicles.

[0006] The third objective of this application is to provide a faulty vehicle inventory device.

[0007] The fourth objective of this application is to propose another faulty vehicle inventory device.

[0008] The fifth objective of this application is to provide an electronic device.

[0009] The sixth objective of this application is to provide a computer-readable storage medium.

[0010] The seventh objective of this application is to provide a computer program product.

[0011] To achieve the above objectives, a first aspect of this application provides a method for inventorying faulty vehicles, comprising:

[0012] Send a Bluetooth scan command to a normal vehicle; wherein the Bluetooth scan command carries scan parameters;

[0013] Receive a list of Bluetooth devices sent by the normal vehicle; wherein the list of Bluetooth devices is obtained by the normal vehicle through Bluetooth scanning based on the scanning parameters;

[0014] Based on the Bluetooth device list, inventory the faulty vehicles that were not previously inventoried.

[0015] To achieve the above objectives, a second aspect of this application provides another method for inventorying faulty vehicles, including:

[0016] Receive a Bluetooth scanning command sent by the server; wherein the Bluetooth scanning command includes scanning parameters;

[0017] Perform a Bluetooth scan based on the scan parameters to obtain a list of Bluetooth devices;

[0018] The list of Bluetooth devices is sent to the server so that the server can inventory the faulty vehicles that have not been inventoried, based on the list of Bluetooth devices.

[0019] To achieve the above objectives, a third aspect of this application provides a faulty vehicle inventory device, comprising:

[0020] The transmitting module is used to send Bluetooth scanning commands to normal vehicles; wherein the Bluetooth scanning commands carry scanning parameters.

[0021] A receiving module is configured to receive a list of Bluetooth devices sent by the normal vehicle; wherein the list of Bluetooth devices is obtained by the normal vehicle performing a Bluetooth scan based on the scanning parameters;

[0022] The inventory module is used to inventory the faulty vehicles that have not been inventoried, based on the Bluetooth device list.

[0023] To achieve the above objectives, a fourth aspect of this application provides another faulty vehicle inventory device, comprising:

[0024] A receiving module is used to receive a Bluetooth scanning command sent by a server; wherein the Bluetooth scanning command includes scanning parameters;

[0025] The scanning module is used to perform Bluetooth scanning according to the scanning parameters to obtain a list of Bluetooth devices;

[0026] The sending module is used to send the Bluetooth device list to the server so that the server can inventory the faulty vehicles that have not been inventoried based on the Bluetooth device list.

[0027] To achieve the above objectives, a fifth aspect of this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0028] The memory stores computer-executed instructions;

[0029] The processor executes computer execution instructions stored in the memory to implement the method as described in the first aspect embodiment, or to implement the method as described in the second aspect embodiment.

[0030] To achieve the above objectives, a sixth aspect of this application provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, are used to implement the method described in the first aspect embodiment or the method described in the second aspect embodiment.

[0031] To achieve the above objectives, a seventh aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the method described in the first aspect embodiment or the method described in the second aspect embodiment.

[0032] The method, apparatus, electronic device, and storage medium for inventorying faulty vehicles provided in this application send Bluetooth scanning commands to normal vehicles, enabling the normal vehicles to perform Bluetooth scanning according to the scanning parameters in the commands. The method also receives a list of Bluetooth devices obtained from the scan by the normal vehicles and, based on this list, inventorys are performed on faulty vehicles that have not yet been counted. Therefore, based on the Bluetooth scan results of normal vehicles, inventory of faulty vehicles near them can be performed, improving the efficiency and success rate of faulty vehicle inventory.

[0033] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0034] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

[0035] Figure 1 A flowchart illustrating a method for inventorying faulty vehicles provided in an embodiment of this application;

[0036] Figure 2 A flowchart illustrating another method for inventorying faulty vehicles provided in this application embodiment;

[0037] Figure 3 A flowchart illustrating another method for inventorying faulty vehicles provided in this application embodiment;

[0038] Figure 4 A flowchart illustrating another method for inventorying faulty vehicles provided in this application embodiment;

[0039] Figure 5 A schematic diagram of a faulty vehicle inventory process provided for an embodiment of this application;

[0040] Figure 6 This is a schematic diagram of the structure of a faulty vehicle inventory device provided in an embodiment of this application;

[0041] Figure 7 This is a schematic diagram of another fault vehicle inventory device provided in an embodiment of this application. Detailed Implementation

[0042] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0043] The following description, with reference to the accompanying drawings, describes a method, apparatus, electronic device, and storage medium for inventorying faulty vehicles according to embodiments of this application.

[0044] Figure 1 This is a flowchart illustrating a method for inventorying faulty vehicles provided in an embodiment of this application.

[0045] In related technologies, vehicle inventory can be performed based on information reported by the vehicles. However, if a vehicle malfunctions and cannot report information, it will be impossible to inventory the malfunctioning vehicle.

[0046] To address this issue, embodiments of this application provide a method for inventorying faulty vehicles, aiming to improve the efficiency and success rate of such inventory. Figure 1 As shown, the method for inventorying faulty vehicles includes the following steps:

[0047] Step 101: Send a Bluetooth scan command to a normal vehicle.

[0048] In this embodiment, the vehicles to be inventoried are equipped with Bluetooth chips. Normal vehicles can periodically report information to the server. The reported information may include the vehicle's location information, vehicle identification, etc. The server can match the information reported by the vehicles with the information of the vehicles to be inventoried to determine whether the vehicles have been inventoried, thereby realizing the inventory of normal vehicles.

[0049] If a vehicle malfunctions, such as due to low battery, water damage, or other reasons that prevent it from communicating with the network and reporting information to the server, it cannot be inventoried. Therefore, vehicles not yet inventoried can be considered faulty. Since vehicles are usually parked in a concentrated area, if there are uninspected faulty vehicles, the server can send Bluetooth scanning commands to the normal vehicles, allowing them to scan for nearby vehicles.

[0050] The Bluetooth scanning command may include scanning parameters, which may include, but are not limited to, scanning duration and scanning period.

[0051] Step 102: Receive the list of Bluetooth devices sent by a normal vehicle.

[0052] The Bluetooth device list is obtained by a normal vehicle through Bluetooth scanning based on the scanning parameters in the Bluetooth scanning command. The Bluetooth device list can include information such as the Bluetooth address, device type, and device identifier of the Bluetooth devices.

[0053] Since there may be other Bluetooth devices near the vehicle, such as mobile phones and traffic cameras, the list of Bluetooth devices that a normal vehicle can scan via Bluetooth may include vehicles, mobile phones, traffic cameras, and other Bluetooth devices.

[0054] Step 103: Inventory the faulty vehicles that have not been inventoried, based on the Bluetooth device list.

[0055] In this embodiment, the list of Bluetooth devices can be compared with the list of uncounted faulty vehicles in order to count the uncounted faulty vehicles.

[0056] For example, faulty vehicle information can be filtered from the Bluetooth device list and matched with vehicle information in the uninspected vehicle list. If a vehicle is matched in the uninspected vehicle list, it means that the scanned faulty vehicle is near a normal vehicle. The location information of the normal vehicle can be recorded as the location information of the faulty vehicle, and the scanned faulty vehicle can be marked as having been inspected.

[0057] For example, information about scanned faulty vehicles, such as vehicle identification and location information, can be added to the list of vehicles already inventoried, or faulty vehicles can be marked as inventoried in the list of vehicles to be inventoried. The list of vehicles to be inventoried here can be understood as a list of vehicle assets, that is, a list of vehicles that need to be inventoried.

[0058] Taking the inventory of shared vehicles in a city as an example, normal shared vehicles can report information to the server at regular intervals. The server can then inventory the normal shared vehicles based on the reported information. For faulty vehicles in the city that have not been inventoried, a Bluetooth scanning command can be sent to the normal shared vehicles, and the faulty shared vehicles can be inventoried based on the Bluetooth scanning results of the normal shared vehicles.

[0059] In this embodiment, a Bluetooth scanning command is sent to a normal vehicle, enabling the normal vehicle to perform a Bluetooth scan according to the scanning parameters in the command. The system then receives a list of Bluetooth devices obtained from the scan and, based on this list, inventories are made for any faulty vehicles that have not yet been checked. This allows for the inventory of faulty vehicles near the normal vehicle based on the Bluetooth scan results, improving the efficiency and success rate of faulty vehicle inventory.

[0060] Figure 2 This is a flowchart illustrating another method for inventorying faulty vehicles provided in an embodiment of this application. Figure 2 As shown, the method for inventorying faulty vehicles may include the following steps:

[0061] Step 201: Send a Bluetooth scanning command to a normal vehicle.

[0062] In this embodiment, a normal vehicle can be a vehicle located in the target geographical area. That is, the server can send Bluetooth scanning commands to normal vehicles in the target geographical area to inventory the faulty vehicles in the target geographical area.

[0063] The target geographical area can be a city, a district of a city, a vehicle location within a city, or other geographical areas, which can be determined according to actual needs and are not limited thereto.

[0064] Step 202: Receive the list of Bluetooth devices sent by a normal vehicle.

[0065] In this embodiment, step 202 can be implemented in any of the embodiments of this application, so it will not be described again here.

[0066] Step 203: Obtain the list of uninspected faulty vehicles corresponding to the target geographical area.

[0067] In this embodiment, the list of uninspected faulty vehicles corresponding to the target geographical area can be understood as the list of uninspected faulty vehicles within the target geographical area. For example, the list of uninspected faulty vehicles may include the device identifier, Bluetooth address, etc., of the faulty vehicle.

[0068] For example, it is possible to identify vehicles that have reported information within a target geographic area, and based on the vehicles that have reported information and the vehicles to be inventoried within the target geographic area, identify the vehicles that have not reported information among the vehicles to be inventoried, and based on the vehicles that have not reported information, determine a list of vehicles with malfunctions that have not been inventoried.

[0069] Among them, vehicles that report information can be considered normal vehicles, and other vehicles not reporting information are considered to be faulty vehicles that have not been inventoried.

[0070] Therefore, based on the vehicles to be inventoried and the vehicles that have reported information within the target geographical area, the list of uninvented faulty vehicles corresponding to the target geographical area can be determined, improving the accuracy of identifying uninvented faulty vehicles.

[0071] For example, the list of unaccounted faulty vehicles can also be uploaded by the user.

[0072] Step 204: Based on the Bluetooth device list and the list of uninspected faulty vehicles, inventory the uninspected faulty vehicles within the target geographical area.

[0073] As one possible implementation, the Bluetooth device list can include the target Bluetooth address of the Bluetooth device. The target Bluetooth address can be compared with the Bluetooth addresses in the list of uninspected faulty vehicles to determine whether the target Bluetooth address exists in the list of uninspected faulty vehicles. If the target Bluetooth address exists in the list of uninspected faulty vehicles, it is then determined whether the device type of the Bluetooth device to which the target Bluetooth address belongs is a vehicle. If the device type is a vehicle, it means that the Bluetooth device is an uninspected faulty vehicle. Based on the location information of normal vehicles, the location information of the vehicle to which the target Bluetooth address belongs can be recorded, and the process to which the target Bluetooth address belongs can be marked as inspected.

[0074] For example, the Bluetooth device list includes the names of the Bluetooth devices. Based on the vehicle naming rules and the name of the Bluetooth device to which the target Bluetooth address belongs, it can be determined whether the device type of the Bluetooth device to which the target Bluetooth address belongs is a vehicle.

[0075] For example, the location information of the vehicle to which the recorded target Bluetooth address belongs can be the same as the location information of a normal vehicle.

[0076] Therefore, the Bluetooth device list can include the Bluetooth addresses of the Bluetooth devices, which can be used to search the list of uninspected faulty vehicles to conduct inventory of the uninspected faulty vehicles, thereby improving the success rate of inventorying faulty vehicles.

[0077] As another possible implementation, the Bluetooth device list can include a Bluetooth device identifier. The Bluetooth device identifier in the Bluetooth device list can be compared with the device identifier in the list of uninspected faulty vehicles to determine whether the Bluetooth device identifier exists in the list of uninspected faulty vehicles. If the Bluetooth device identifier exists in the list of uninspected faulty vehicles, it means that the Bluetooth device identified by the Bluetooth device identifier is an uninspected faulty vehicle. Then, based on the location information of normal vehicles, the location information of the vehicle to which the target Bluetooth address belongs is recorded, and the vehicle to which the target Bluetooth address belongs is marked as having been inspected.

[0078] Therefore, the Bluetooth device list can include Bluetooth device identifiers. By comparing the Bluetooth device identifiers with the vehicle device identifiers in the list of uninspected faulty vehicles, it can be determined whether normal vehicles have scanned uninspected faulty vehicles, thereby enabling the uninspected faulty vehicles to be inventoried.

[0079] In this embodiment of the application, the uninspected faulty vehicles in the target geographical area can be inventoried based on the Bluetooth device list and the uninspected faulty vehicle list of the target geographical area, thereby meeting the inventory requirements of faulty vehicles in different geographical areas.

[0080] Figure 3This is a flowchart illustrating another method for inventorying faulty vehicles provided in an embodiment of this application. Figure 3 As shown, the method for inventorying faulty vehicles may include the following steps:

[0081] Step 301: Determine whether the location information of a normal vehicle matches the area information of the target geographic area in the Bluetooth scanning strategy.

[0082] In this embodiment, one or more Bluetooth scanning strategies can be pre-configured. These strategies may include information about the target geographic area, scanning duration, and scanning time period. The target geographic area refers to the geographic region targeted by the Bluetooth scanning strategy. For example, if the target geographic area is city A, then the Bluetooth scanning strategy can be used to scan vehicles in city A.

[0083] For example, a user can configure a Bluetooth scanning policy on the policy configuration interface. Scanning configuration items may include, but are not limited to, geographical area, scan duration, and scan time period. After configuring each scanning configuration item, the user can trigger a save control to save the Bluetooth scanning policy. If the server detects a Bluetooth scanning policy save operation on the policy configuration interface, it obtains the configuration information of the scanning configuration items and retrieves the Bluetooth scanning policy based on that information.

[0084] Therefore, users can configure Bluetooth scanning strategies as needed to meet different needs for inventorying faulty vehicles.

[0085] For example, the location information of a normal vehicle can be compared with the area information of the target geographic area in the Bluetooth scanning strategy to determine whether the normal vehicle is located within the target geographic area, thereby determining whether the location information of the normal vehicle matches the area information. If the normal vehicle is located within the target geographic area, it means that the location information of the normal vehicle matches the area information of the target geographic area; if the normal vehicle is not located within the target geographic area, it means that the location information of the normal vehicle does not match the area information of the target geographic area.

[0086] Step 302: In response to the matching of location information and area information, a Bluetooth scanning command is sent to normal vehicles within the target geographical area.

[0087] If the location information of a normal vehicle matches the area information of the target geographic region, it means that the normal vehicle is located within the target geographic region. The server can then send a Bluetooth scanning command to the normal vehicle, enabling it to scan for nearby faulty vehicles. The scanning parameters carried in the Bluetooth scanning command are those specified in the Bluetooth scanning strategy.

[0088] Optionally, the target geographic area can be a multi-level geographic area. The location information of a normal vehicle can be matched with each level of geographic area. If the location information of a normal vehicle matches all levels of geographic areas, a Bluetooth scanning command can be sent to the normal vehicle in the lowest level of geographic area in the multi-level geographic area.

[0089] For example, when matching the location information of a normal vehicle with each level of geographic region, the location information of the normal vehicle can be matched with the highest level of geographic region first. If the location information does not match the highest level of geographic region, it means that the Bluetooth scanning strategy is not applicable to the normal vehicle. If the location information matches the highest level of geographic region, the location information of the normal vehicle can be matched with the next level of geographic region, until the location information of the normal vehicle is matched with the lowest level of geographic region.

[0090] For example, the target geographical area in the Bluetooth scanning strategy is city A - vehicle location p1. If a normal vehicle is located in city A and at vehicle location p1, a Bluetooth scanning command can be sent to the normal vehicle. The scanning parameters carried by the Bluetooth scanning command are the scanning parameters in the Bluetooth scanning strategy.

[0091] Therefore, if the target geographic area is a multi-level geographic area, the location information of normal vehicles can be matched with the multi-level geographic areas to determine whether the normal vehicles are in the lowest level geographic area, thereby enabling a more refined inventory of faulty vehicles in a more detailed geographic area.

[0092] Optionally, the Bluetooth scanning strategy may include a scanning period, allowing the server to send Bluetooth scanning commands to legitimate vehicles based on the scanning period. For example, if the scanning period is from 10 PM to midnight, the server will send Bluetooth scanning commands to legitimate vehicles during that period.

[0093] Step 303: Receive the list of Bluetooth devices sent by a normal vehicle.

[0094] Step 304: Obtain the list of uninspected faulty vehicles corresponding to the target geographical area.

[0095] Step 305: Based on the Bluetooth device list and the list of uninspected faulty vehicles, inventory the uninspected faulty vehicles within the target geographical area.

[0096] In this embodiment, steps 304-305 can be implemented in any of the embodiments of this application, so they will not be described again here.

[0097] In this embodiment, if the location information of a normal vehicle matches the area information of the target geographical area in the Bluetooth scanning strategy, that is, if it is determined that the normal vehicle is located in the target geographical area, then a Bluetooth scanning command carrying the scanning parameters in the Bluetooth scanning strategy can be sent to the normal vehicle so that the normal vehicle can scan nearby faulty vehicles, avoiding sending Bluetooth scanning commands to other normal vehicles that do not belong to the target geographical area. This not only saves resources but also improves the success rate of faulty vehicle inventory.

[0098] To implement the above embodiments, this application also provides another method for inventorying faulty vehicles. Figure 4 This is a flowchart illustrating another method for inventorying faulty vehicles provided in an embodiment of this application. This method can be executed by a server.

[0099] like Figure 4 As shown, the method for inventorying faulty vehicles may include the following steps:

[0100] Step 401: Receive the Bluetooth scanning command sent by the server.

[0101] In this embodiment, the server can send Bluetooth scanning commands to normal vehicles, thereby enabling these vehicles to receive the commands. The Bluetooth scanning commands may include scanning parameters, such as scanning duration and scanning time period.

[0102] Step 402: Perform a Bluetooth scan based on the scanning parameters to obtain a list of Bluetooth devices.

[0103] For example, if the scanning parameters include the scanning duration, a normal vehicle can scan for nearby Bluetooth devices within that duration to obtain a list of Bluetooth devices. For instance, if the scanning duration is 15 seconds, a normal vehicle can scan for nearby Bluetooth devices for 15 seconds.

[0104] For example, if the scanning parameters include the scanning period, then a normal vehicle can scan for nearby Bluetooth devices during that period. For instance, if the scanning period is from 10 PM to midnight, then a normal vehicle can scan for nearby Bluetooth devices during that time.

[0105] For example, the Bluetooth device list may include information such as the device identifier and Bluetooth address of the Bluetooth device.

[0106] Step 403: Send a list of Bluetooth devices to the server so that the server can inventory the faulty vehicles that have not been inventoried based on the list of Bluetooth devices.

[0107] In this embodiment, the vehicle can send a list of Bluetooth devices to the server, which then determines whether the list contains information about uninspected faulty vehicles, and thus performs an inventory of the uninspected faulty vehicles.

[0108] In this embodiment, a Bluetooth device list is obtained by scanning according to the scanning parameters in the Bluetooth scanning command sent by the server, and then sent to the server. The server uses this Bluetooth device list to inventory the faulty vehicles that have not yet been inventoried. Therefore, based on the Bluetooth scan results of normal vehicles, faulty vehicles near normal vehicles can be inventoried, improving the efficiency and success rate of faulty vehicle inventory.

[0109] To facilitate understanding of the faulty vehicle inventory method in this application, the following is combined with... Figure 5 To explain, Figure 5 This is a schematic diagram of a faulty vehicle inventory process provided in an embodiment of this application.

[0110] like Figure 5 As shown, the inventory process for this faulty vehicle is as follows:

[0111] (1) For the configuration section, configure the Bluetooth scanning policy:

[0112] a) Supports configuring customized Bluetooth scanning strategies, such as configuring regional information like cities and vehicle locations, for Bluetooth scanning of a specific area.

[0113] b) Scanning parameters: Parameters related to the scanning command, such as scanning duration and scanning period. The scanning period can specify the time period for scanning, such as nighttime scanning, which can avoid interfering with the user's cycling.

[0114] (2) Strategy section: Listen to the information reported by normal vehicles to trigger strategy matching. The information reported by normal vehicles can be matched with the area information in the Bluetooth scanning strategy. If the two match, it means that the normal vehicle has matched the Bluetooth scanning strategy and that the normal vehicle is in the area specified in the Bluetooth scanning strategy. Therefore, a Bluetooth scanning command carrying scanning parameters can be sent to the normal vehicle.

[0115] (3) Vehicle Bluetooth scanning: Normal vehicles scan for the Bluetooth addresses of nearby vehicles within a certain time according to the scanning parameters, and report the list of scanned addresses to the server via the network.

[0116] (4) Inventory of Faulty Vehicles: Matching is performed based on the Bluetooth address list and the list of faulty vehicles not yet inventoried. For example, a search and match can be performed based on the vehicle Bluetooth addresses in the Bluetooth address list. If a match is found in the list of faulty vehicles not yet inventoried, it means that the faulty vehicle has been inventoried, and it also indicates that the faulty vehicle is near the normally reported vehicle. The location information of the faulty vehicle is recorded. If no match is found in the list of faulty vehicles not yet inventoried, it means that the faulty vehicle has not been inventoried.

[0117] To achieve the above embodiments, this application also proposes a faulty vehicle inventory device. Figure 6 This is a schematic diagram of a fault vehicle inventory device provided in an embodiment of this application.

[0118] like Figure 6 As shown, the faulty vehicle inventory device 600 includes:

[0119] The sending module 610 is used to send a Bluetooth scanning command to a normal vehicle; wherein the Bluetooth scanning command carries scanning parameters.

[0120] The receiving module 620 is used to receive a list of Bluetooth devices sent by the normal vehicle; wherein the list of Bluetooth devices is obtained by the normal vehicle through Bluetooth scanning according to the scanning parameters;

[0121] The inventory module 630 is used to inventory the faulty vehicles that have not been inventoried, based on the Bluetooth device list.

[0122] Furthermore, in one possible implementation of this application embodiment, the normal vehicle is located in the target geographical area, and the inventory module 630 is used for:

[0123] Obtain the list of uncounted faulty vehicles corresponding to the target geographical area;

[0124] Based on the Bluetooth device list and the list of uninspected faulty vehicles, an inventory of uninspected faulty vehicles within the target geographical area is performed.

[0125] Furthermore, in one possible implementation of this application embodiment, the Bluetooth device list includes a target Bluetooth address, and the inventory module 630 is used for:

[0126] The target Bluetooth address is compared with the Bluetooth addresses in the list of uninspected faulty vehicles to determine whether the target Bluetooth address exists in the list of uninspected faulty vehicles.

[0127] In response to the presence of the target Bluetooth address in the list of uncounted faulty vehicles, determine whether the device type of the Bluetooth device to which the target Bluetooth address belongs is a vehicle;

[0128] In response to the fact that the device type of the Bluetooth device to which the target Bluetooth address belongs is a vehicle, the location information of the vehicle to which the target Bluetooth address belongs is recorded according to the location information of the normal vehicle, and the vehicle to which the target Bluetooth address belongs is marked as having been inventoried.

[0129] Furthermore, in one possible implementation of this application embodiment, the Bluetooth device list includes a Bluetooth device identifier.

[0130] Furthermore, in one possible implementation of this application embodiment, the inventory module 630 is used for:

[0131] The Bluetooth device identifier is compared with the device identifier in the list of uninspected faulty vehicles to determine whether the Bluetooth device identifier exists in the list of uninspected faulty vehicles.

[0132] In response to the presence of the Bluetooth device identifier in the list of uninspected faulty vehicles, the location information of the vehicle to which the target Bluetooth address belongs is recorded based on the location information of the normal vehicles, and the vehicle to which the target Bluetooth address belongs is marked as having been inspected.

[0133] Furthermore, in one possible implementation of this application embodiment, the inventory module 630 is used for:

[0134] Identify the vehicles that reported information within the target geographical area;

[0135] Based on the vehicles that have reported information and the vehicles to be inventoried in the target geographical area, determine the vehicles among the vehicles to be inventoried that have not reported information.

[0136] Based on the vehicles that did not report information, a list of uncounted faulty vehicles is determined.

[0137] Furthermore, in one possible implementation of this application embodiment, the sending module 610 is used for:

[0138] Obtain the Bluetooth scanning strategy; wherein the Bluetooth scanning strategy includes the area information of the target geographic area;

[0139] Determine whether the location information of the normal vehicle matches the area information;

[0140] In response to a match between the location information and the area information, a Bluetooth scanning command is sent to the normal vehicles within the target geographical area; wherein the scanning parameters carried by the Bluetooth scanning command are the scanning parameters in the Bluetooth scanning strategy.

[0141] Furthermore, in one possible implementation of this application embodiment, the target geographical region is a multi-level geographical region, and the sending module 610 is used for:

[0142] In response to the location information matching all the multi-level geographic regions, the Bluetooth scanning command is sent to the normal vehicle in the lowest-level geographic region among the multi-level geographic regions.

[0143] Furthermore, in one possible implementation of this application embodiment, the sending module 610 is used for:

[0144] In response to the detection of a Bluetooth scanning policy saving operation in the policy configuration interface, the configuration information of the scanning configuration item is obtained;

[0145] Based on the configuration information, obtain the Bluetooth scanning strategy.

[0146] It should be noted that the foregoing explanation of the server-side fault vehicle inventory method embodiment also applies to the fault vehicle inventory device of this embodiment, and will not be repeated here.

[0147] In this embodiment, a Bluetooth scanning command is sent to a normal vehicle, enabling the normal vehicle to perform a Bluetooth scan according to the scanning parameters in the command. The system then receives a list of Bluetooth devices obtained from the scan and, based on this list, inventories are made for any faulty vehicles that have not yet been checked. This allows for the inventory of faulty vehicles near the normal vehicle based on the Bluetooth scan results, improving the efficiency and success rate of faulty vehicle inventory.

[0148] To achieve the above embodiments, this application also proposes a faulty vehicle inventory device. Figure 7 This is a schematic diagram of another fault vehicle inventory device provided in an embodiment of this application.

[0149] like Figure 7 As shown, the faulty vehicle inventory device 700 includes:

[0150] The receiving module 710 is used to receive a Bluetooth scanning command sent by the server; wherein the Bluetooth scanning command includes scanning parameters.

[0151] Scanning module 720 is used to perform Bluetooth scanning according to the scanning parameters to obtain a list of Bluetooth devices;

[0152] The sending module 730 is used to send the Bluetooth device list to the server so that the server can inventory the faulty vehicles that have not been inventoried based on the Bluetooth device list.

[0153] It should be noted that the foregoing explanation of the vehicle-side fault vehicle inventory method embodiment also applies to the fault vehicle inventory device of this embodiment, and will not be repeated here.

[0154] In this embodiment, a Bluetooth device list is obtained by scanning according to the scanning parameters in the Bluetooth scanning command sent by the server, and then sent to the server. The server uses this Bluetooth device list to inventory the faulty vehicles that have not yet been inventoried. Therefore, based on the Bluetooth scan results of normal vehicles, faulty vehicles near normal vehicles can be inventoried, improving the efficiency and success rate of faulty vehicle inventory.

[0155] To implement the above embodiments, this application also proposes an electronic device, including: a processor and a memory communicatively connected to the processor; the memory stores computer execution instructions; the processor executes the computer execution instructions stored in the memory to implement the method provided in the foregoing embodiments.

[0156] To implement the above embodiments, this application also proposes a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the methods provided in the foregoing embodiments.

[0157] To implement the above embodiments, this application also proposes a computer program product, including a computer program that, when executed by a processor, implements the methods provided in the foregoing embodiments.

[0158] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in this application all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0159] It should be noted that personal information collected from users should be used for legitimate and reasonable purposes and should not be shared or sold outside of these legitimate uses. Furthermore, such collection / sharing should only be conducted after receiving the user's informed consent, including but not limited to notifying the user to read the user agreement / user notice and sign an agreement / authorization that includes authorization of relevant user information before the user uses the function. In addition, any necessary steps must be taken to protect and safeguard access to such personal information data.

[0160] This application is intended to provide an implementation scheme for users to selectively prevent the use or access to their personal information data. Specifically, this disclosure is intended to provide hardware and / or software to prevent or block access to such personal information data. Once personal information data is no longer needed, risks can be minimized by restricting data collection and deleting data. Furthermore, where applicable, such personal information can be de-identified to protect the user's personal information.

[0161] In the foregoing descriptions of the embodiments, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0162] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0163] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0164] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-including system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0165] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0166] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0167] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0168] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

Claims

1. A method for inventorying faulty vehicles, characterized in that, Includes the following steps: Send a Bluetooth scan command to a normal vehicle; wherein the Bluetooth scan command carries scan parameters; Receive a list of Bluetooth devices sent by the normal vehicle; wherein the list of Bluetooth devices is obtained by the normal vehicle through Bluetooth scanning based on the scanning parameters; Based on the Bluetooth device list, inventory the faulty vehicles that were not previously inventoried.

2. The method as described in claim 1, characterized in that, The normal vehicles are located in the target geographical area. The step of inventorying the un-inspected faulty vehicles according to the Bluetooth device list includes: Obtain the list of uncounted faulty vehicles corresponding to the target geographical area; Based on the Bluetooth device list and the list of uninspected faulty vehicles, an inventory of uninspected faulty vehicles within the target geographical area is performed.

3. The method as described in claim 2, characterized in that, The Bluetooth device list includes target Bluetooth addresses. The step of inventorying uninspected faulty vehicles within the target geographical area based on the Bluetooth device list and the uninspected faulty vehicle list includes: The target Bluetooth address is compared with the Bluetooth addresses in the list of uninspected faulty vehicles to determine whether the target Bluetooth address exists in the list of uninspected faulty vehicles. In response to the presence of the target Bluetooth address in the list of uncounted faulty vehicles, determine whether the device type of the Bluetooth device to which the target Bluetooth address belongs is a vehicle; In response to the fact that the device type of the Bluetooth device to which the target Bluetooth address belongs is a vehicle, the location information of the vehicle to which the target Bluetooth address belongs is recorded according to the location information of the normal vehicle, and the vehicle to which the target Bluetooth address belongs is marked as having been inventoried.

4. The method as described in claim 2, characterized in that, The Bluetooth device list includes Bluetooth device identifiers. The step of inventorying the uninspected faulty vehicles within the target geographical area based on the Bluetooth device list and the uninspected faulty vehicle list includes: The Bluetooth device identifier is compared with the device identifier in the list of uninspected faulty vehicles to determine whether the Bluetooth device identifier exists in the list of uninspected faulty vehicles. In response to the presence of the Bluetooth device identifier in the list of uninspected faulty vehicles, the location information of the vehicle to which the target Bluetooth address belongs is recorded based on the location information of the normal vehicles, and the vehicle to which the target Bluetooth address belongs is marked as having been inspected.

5. The method as described in claim 2, characterized in that, The process of obtaining the list of uninspected faulty vehicles corresponding to the target geographical area includes: Identify the vehicles that reported information within the target geographical area; Based on the vehicles that have reported information and the vehicles to be inventoried in the target geographical area, determine the vehicles among the vehicles to be inventoried that have not reported information. Based on the vehicles that did not report information, a list of uncounted faulty vehicles is determined.

6. The method as described in claim 1, characterized in that, Sending Bluetooth scanning commands to normal vehicles includes: Obtain the Bluetooth scanning strategy; wherein the Bluetooth scanning strategy includes the area information of the target geographic area; Determine whether the location information of the normal vehicle matches the area information; In response to a match between the location information and the area information, a Bluetooth scanning command is sent to the normal vehicles within the target geographical area; wherein the scanning parameters carried by the Bluetooth scanning command are the scanning parameters in the Bluetooth scanning strategy.

7. The method as described in claim 6, characterized in that, The target geographic area is a multi-level geographic area. The step of sending the Bluetooth scanning command to the normal vehicle in response to a match between the location information and the area information includes: In response to the location information matching all the multi-level geographic regions, the Bluetooth scanning command is sent to the normal vehicle in the lowest-level geographic region among the multi-level geographic regions.

8. The method as described in claim 6, characterized in that, The Bluetooth scanning strategy includes: In response to the detection of a Bluetooth scanning policy saving operation in the policy configuration interface, the configuration information of the scanning configuration item is obtained; Based on the configuration information, obtain the Bluetooth scanning strategy.

9. A method for inventorying faulty vehicles, characterized in that, Includes the following steps: Receive a Bluetooth scanning command sent by the server; wherein the Bluetooth scanning command includes scanning parameters; Perform a Bluetooth scan based on the scan parameters to obtain a list of Bluetooth devices; The list of Bluetooth devices is sent to the server so that the server can inventory the faulty vehicles that have not been inventoried, based on the list of Bluetooth devices.

10. A faulty vehicle inventory device, characterized in that, include: The transmitting module is used to send Bluetooth scanning commands to normal vehicles; wherein the Bluetooth scanning commands carry scanning parameters. A receiving module is configured to receive a list of Bluetooth devices sent by the normal vehicle; wherein the list of Bluetooth devices is obtained by the normal vehicle performing a Bluetooth scan based on the scanning parameters; The inventory module is used to inventory the faulty vehicles that have not been inventoried, based on the Bluetooth device list.

11. A faulty vehicle inventory device, characterized in that, include: A receiving module is used to receive a Bluetooth scanning command sent by a server; wherein the Bluetooth scanning command includes scanning parameters; The scanning module is used to perform Bluetooth scanning according to the scanning parameters to obtain a list of Bluetooth devices; The sending module is used to send the Bluetooth device list to the server so that the server can inventory the faulty vehicles that have not been inventoried based on the Bluetooth device list.

12. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1-8, or to implement the method as described in claim 9.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-8, or to implement the method as described in claim 9.

14. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1-8, or implements the method of claim 9.

Images