CN115705525A

CN115705525A - Vehicle management method, system and device

Info

Publication number: CN115705525A
Application number: CN202110908337.2A
Authority: CN
Inventors: 曾奇缊
Original assignee: Shanghai Pateo Network Technology Service Co Ltd
Current assignee: Shanghai Pateo Network Technology Service Co Ltd
Priority date: 2021-08-09
Filing date: 2021-08-09
Publication date: 2023-02-17

Abstract

The embodiment of the application discloses a method, a system and a device for vehicle management. The method may comprise the steps of: receiving vehicle using application information input by a user, wherein the vehicle using application information comprises using time; acquiring a vehicle list of available vehicles in the vehicles according to the vehicle application information, wherein the available vehicles comprise vehicles in an idle state and vehicles in a to-be-lent state in the using time, the vehicles in the idle state are non-lent vehicles, and the vehicles in the to-be-lent state are lent vehicles which are not in use; receiving a selection instruction input by a user, wherein the selection instruction is used for indicating the user to select a target vehicle for use; and modifying the state of the target vehicle into the use state according to the use time. By implementing the embodiment of the application, the lent vehicles in idle states are added into the to-be-lent list, so that the user can still borrow the vehicles under the condition that the vehicles are lent, and the utilization rate of the vehicles is improved.

Description

Vehicle management method, system and device

Technical Field

The present application relates to the field of computer technologies, and in particular, to a method, a system, and an apparatus for vehicle management.

Background

The steps of the existing vehicle dispatching method for the company are as follows: the user requests to borrow a vehicle within a certain time period, and after the request of the user is approved, the vehicle requested by the user is modified into a borrowed state within the time period submitted by the user. For example, if user a applies for borrowing a vehicle within six days of ten to fifteen days of one month, the vehicle will change from the idle state to the borrowed state within six days of ten to fifteen days of one month after the user a's request is approved. However, during this period, if the user a does not use the vehicle after borrowing the vehicle, the vehicle will be left idle, thereby reducing the vehicle utilization.

Disclosure of Invention

The embodiment of the application provides a method, a system and a device for vehicle management, so that the same vehicle can be borrowed by a user B after being borrowed by a user A, and the utilization rate of the vehicle is improved.

In a first aspect, an embodiment of the present application provides a method for vehicle management, including the following steps:

receiving vehicle using application information input by a user, wherein the vehicle using application information comprises using time;

obtaining a vehicle list of available vehicles in the vehicles according to the vehicle application information, wherein the available vehicles comprise vehicles in an idle state and vehicles in a to-be-lent state in the using time, the vehicles in the idle state are non-lent vehicles, and the vehicles in the to-be-lent state are lent vehicles which are not in use;

receiving a selection instruction input by the user, wherein the selection instruction is used for indicating a target vehicle selected by the user to be used;

and modifying the state of the target vehicle into a use state according to the use time.

In a second aspect, an embodiment of the present application provides a system for vehicle management, including:

the receiving module is used for receiving vehicle using application information input by a user, and the vehicle using application information comprises using time;

the obtaining module is used for obtaining a vehicle list of available vehicles in the vehicles according to the vehicle utilization application information, wherein the available vehicles comprise vehicles in an idle state and vehicles in a to-be-lent state in the service time, the vehicles in the idle state are non-lent vehicles, and the vehicles in the to-be-lent state are non-in-use vehicles which are already lent;

the receiving module is further used for receiving a selection instruction input by the user, wherein the selection instruction is used for indicating the target vehicle selected by the user to be used;

and the processing module is used for modifying the state of the target vehicle into a use state according to the use time.

In a third aspect, an embodiment of the present application provides an apparatus for vehicle management, including: a processor, a memory and a bus, the processor and the memory being connected via the bus, wherein the memory is configured to store a set of program codes, and the processor is configured to call the program codes stored in the memory to perform the method according to the first aspect.

In a fourth aspect, embodiments of the present application provide a computer-readable storage medium having instructions stored therein, which when executed on a computer implement the method according to the first aspect.

In a fifth aspect, embodiments of the present application provide a computer program product comprising a non-transitory computer-readable storage medium storing a computer program, the computer being operable to cause a computer to perform the method according to the first aspect.

According to the method and the device, the vehicle application information input by the user is received, the vehicle list of the available vehicles is obtained according to the use time in the vehicle application information, the vehicle list of the available vehicles comprises the lent vehicles in idle, and the lent vehicles in idle are added into the to-be-lent list, so that the user can still borrow the vehicles under the condition that the vehicles are lent, and the utilization rate of the vehicles is improved.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.

FIG. 1 is a schematic flow chart illustrating a method for vehicle management according to an embodiment of the present disclosure;

FIG. 2 is a schematic flow chart illustrating a method for modifying a state of a target vehicle according to an embodiment of the present disclosure;

fig. 3 is a schematic flowchart of a token-based authentication method according to an embodiment of the present application;

FIG. 4 is a schematic flow chart diagram illustrating another method for vehicle management provided by an embodiment of the present application;

FIG. 5 is a schematic flow chart diagram illustrating another method for vehicle management provided by an embodiment of the present application;

FIG. 6 is a schematic diagram illustrating a vehicle management system according to an embodiment of the present disclosure;

fig. 7 is a schematic composition diagram of an apparatus for vehicle management according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application are described below clearly and completely with reference to the accompanying drawings, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments.

The terms "first" and "second" and the like in the description and drawings of the present application are used for distinguishing different objects or for distinguishing different processes for the same object, and are not used for describing a specific order of the objects. Furthermore, the terms "including" and "having," and any variations thereof, as referred to in the description of the present application, are intended to cover non-exclusive inclusions. For example, a process, method, system, article, or apparatus that comprises a list of steps or elements is not limited to only those steps or elements but may alternatively include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus. It should be noted that in the embodiments of the present application, words such as "exemplary" or "for example" are used to mean serving as examples, illustrations or descriptions. Any embodiment or design method described herein as "exemplary" or "e.g.," should not be construed as preferred or advantageous over other embodiments or designs. Rather, use of the word "exemplary" or "such as" is intended to present concepts related in a concrete fashion. In the examples of the present application, "A and/or B" means both A and B, and A or B. "A, and/or B, and/or C" means A, B, C, or A, B, C, or A and B and C.

The following describes the method for vehicle management provided in the embodiment of the present application in detail with reference to the steps in fig. 1.

Referring to fig. 1, a flow chart of a method for vehicle management according to an embodiment of the present application is schematically illustrated, which includes the following steps:

step S101: and receiving vehicle using application information input by a user, wherein the vehicle using application information comprises using time.

Wherein, the use time indicates that the user wants to use the vehicle within the use time range, that is, the user reserves the vehicle by inputting the use time so as to obtain the use authority of the vehicle within the use time range.

Step S102: and acquiring a vehicle list of available vehicles in the vehicles according to the vehicle application information, wherein the available vehicles comprise vehicles in an idle state and vehicles in a to-be-lent state in the using time, the vehicles in the idle state are non-lent vehicles, and the vehicles in the to-be-lent state are lent vehicles which are not in use.

And acquiring a list of available vehicles in the use time range according to the use time input by the user, and providing the list for the user to select. Among the vehicles that are available include vehicles that are not lent in an idle state and vehicles that are lent but not in use in a pending lending state. That is, the user may select to apply for using the vehicle in the idle state, or may select to apply for using the vehicle that has been borrowed by another user in the to-be-borrowed state. The term "loaned or loaned vehicle" refers to a vehicle that a user applies for use and successfully obtains the vehicle use right.

For example, when the user a wants to apply for using the vehicle from ten days a month to fifteen days a month, the use time filled by the user a is from ten days a month to fifteen days a month. If the vehicle a is in an idle state without being borrowed in the using time range, the vehicle a belongs to an available vehicle. The vehicle B borrowed by the user B has the service time of eight days in one month to seventy days in one month, but the vehicle B is in a state of waiting for lending in nine days in one month, so that the vehicle B also belongs to an available vehicle when the user a borrows the vehicle.

In one possible implementation, the vehicle in the to-be-lent state belonging to the available vehicles needs to satisfy the time condition that the use time input by the user is within the time range input by the user who has acquired the use authority of the vehicle in the to-be-lent state.

For example, when the user a wants to apply for using the vehicle from ten days a month to fifteen days a month, the use time filled by the user a is from ten days a month to fifteen days a month. If the vehicle a is in an idle state without being borrowed in the using time range, the vehicle a belongs to an available vehicle. For the vehicle B borrowed by the user B, the use time filled in by the user B when the user B borrows the vehicle B is from eight days in a month to seventy days in a month, but the vehicle B is in a state of waiting for borrowing in nine days in a month, and the vehicle B also belongs to an available vehicle when the user a borrows the vehicle. For the vehicle C that has been lent by the user C, the use time that the user C fills in when lending the vehicle C is from eighty days a month to thirteen days a month, and although the vehicle C is in the state of being lent in nine days a month, the vehicle C does not belong to a usable vehicle because the use authority of the user C for the vehicle C does not include fourteen months to fifteen months that the user a wants.

In one possible implementation manner, the vehicle is a test vehicle, the vehicle use application information further includes a test item, and the available vehicles include a vehicle in an idle state and a vehicle in a to-be-lent state, which are matched with the test item.

A test vehicle is a vehicle that is used to perform some basic driving tests to find the technical characteristics, reliability, and environmental suitability of the vehicle before the vehicle is put into mass production. The function of the device is to ensure that the quality of the vehicle reaches the requirement by carrying out sufficient tests, verifications and road tests on the vehicle before the vehicle is put into mass production.

The test item refers to a specific function of a vehicle to be tested, or a specific function of a vehicle type to be tested. The test items include, but are not limited to, testing a navigation function of a vehicle, testing a voice function of the vehicle, testing a braking function of the vehicle, and the like, and the embodiments of the present application are not limited in any way.

Illustratively, the test items input by the user are voice functions of the type A vehicle, and the input use time is two points in the afternoon of three days in a month to five points in the afternoon of three days in a month. The vehicle belonging to the available vehicles is a type a vehicle in an idle state or a to-be-lent state from two points in the afternoon of three days a month to five in the afternoon of three days a month.

In one possible implementation, the list of vehicles includes at least one of the following vehicle information of the available vehicles: historical number of people using, historical duration of use, historical use item.

By displaying the vehicle information of the available vehicles in the available vehicle list, the user can select the vehicle which meets the requirements of the user. For example, when the vehicle a performs a test of the air conditioning function and passes the test, the user a may prefer to apply for the test using the vehicles a in the available list, so that it may be more easily determined that the voice function is problematic than the air conditioning function in a case where the voice cannot control the air conditioning.

Step S103: and receiving a selection instruction input by the user, wherein the selection instruction is used for indicating the target vehicle selected by the user to be used.

And receiving a selection instruction input by a user, namely receiving a vehicle using application of the user.

Step S104: and modifying the state of the target vehicle into a use state according to the use time.

For example, the user a applies for the vehicle to be used from ten days a month to fifteen days a month, and then after the user a selects the target vehicle, the time range of ten days a month to fifteen days a month of the target vehicle is modified to the use state, that is, the target vehicle is lent within the time range.

In a possible implementation manner, please refer to fig. 2, which is a schematic flow chart of a method for modifying a state of a target vehicle according to an embodiment of the present application, and the method may include the following steps:

step S1041: checking whether the user has authority to use the target vehicle;

in one possible implementation manner, after receiving a selection instruction input by a user, a vehicle using application of the user is generated, and the vehicle using application is sent to corresponding personnel for approval. And if the result of the approval is passed, the user is indicated to have the authority to use the target vehicle. If the result of the approval is that the vehicle is not approved, the user is indicated to fail to borrow the vehicle at this time and does not have the authority to use the target vehicle. At this time, the user is required to apply for the vehicle again after performing corresponding processing according to the reason of failure. And checking whether the user has the authority to use the target vehicle, namely checking whether the user's vehicle usage application is approved.

In one possible implementation, when the target vehicle is a vehicle in an idle state, the person approving the vehicle application includes, but is not limited to, a department manager, a project manager, a vehicle manager, and the like. When the target vehicle is a vehicle in a to-be-borrowed state, the person approving the vehicle use application is the user who borrowed the target vehicle last.

For example, the user a borrows the vehicle a first, and in the case that the user a does not return the vehicle a, the vehicle a is in a state of waiting for lending, and the user B also wants to borrow the vehicle a at the moment, so that the vehicle a is the target vehicle selected by the user B. The vehicle using application submitted by the user B is sent to the user A for approval, and the user B obtains the use permission of the vehicle after obtaining the agreement of the user A.

In a possible implementation manner, when the target vehicle is a vehicle in a to-be-lent state, the person approving the vehicle use application is a user who borrows the target vehicle last time, and when the user who borrows the target vehicle last time approves the user to borrow the target vehicle, the user can choose to transfer the use permission of the target vehicle, or choose to temporarily lend the target vehicle to the user.

For example, the user a borrows the vehicle a first, and in the case that the user a does not return the vehicle a, the vehicle a is in a state of waiting for lending, and the user B also wants to borrow the vehicle a at the moment, so that the vehicle a is the target vehicle selected by the user B. The user A receives the vehicle using application of the user B, and when the user A approves and agrees the vehicle using application of the user B, the user A can choose to transfer the use authority of the vehicle a to the user B or choose to temporarily lend the vehicle a to the user B. The difference is that when the user A chooses to transfer the use authority of the vehicle a to the user B, the user A loses the use authority of the vehicle a, the user B obtains the use authority of the vehicle a and needs to return to the vehicle management center when returning the vehicle a, and when the user A wants to use the vehicle again, the user A needs to resubmit the vehicle using application. When the user A chooses to temporarily lend the vehicle a to the user B, the user A loses the use permission of the vehicle a within the use time range that the user B obtains the use permission of the vehicle a, the user B returns the vehicle a to the user A, and after the user B returns the vehicle a, the user A obtains the use permission of the vehicle a again. That is, at this time, if the user a wants to use the vehicle again within the use time range input when the user a applies for the vehicle use, the user a does not need to submit the vehicle use application again. Therefore, the maximum number of 1 user who has certain vehicle use authority at any time can be ensured, and the vehicle management center can conveniently manage the vehicle.

Step S1042: and under the condition that the user has the authority to use the target vehicle, modifying the state of the target vehicle into a use state according to the use time.

That is, when the approval is passed, the state of the target vehicle is modified to the use state according to the use time.

In one possible implementation manner, in the case that the user has the authority to use the target vehicle, a bluetooth key sent by a server is acquired, and the bluetooth key is used for giving the user the authority to use the target vehicle.

After approval of the relevant person is obtained, the terminal (e.g., a smart phone) receives the token sent by the server as a token for the terminal to request. A token is a special frame that can control a station to occupy the medium to distinguish data frames from other control frames. That is, a token may be understood as a combination that is checked before some data is transmitted, with different combinations authorized for different data operations. Please refer to fig. 3, which is a schematic flowchart of a token-based authentication method according to an embodiment of the present application.

Step S301: a request is sent to the server via the username and password.

In the embodiment of the application, the sending vehicle application is sent to the server. When the server receives the vehicle using application, the server also receives user identity information such as a user name and the like. Thereby associating the user identity information with the vehicle use application.

Step S302: and acquiring the token sent by the server after the server successfully checks.

The server processes the received data (such as the user name and the password) to obtain a data signature, and sends the data and the data signature together as a token to the terminal. The processing method to obtain the data signature includes, but is not limited to, using a hash algorithm. A Hash Algorithm (Hash Algorithm), also known as a Hash Algorithm, a Hash function, a digest generation Algorithm, is a method for creating a digital fingerprint from data. The hash algorithm mixes the data in a scrambling mode and recreates a hash value. The Hash algorithm is mainly used for guaranteeing data authenticity, an original message and a Hash value are sent by a sender together, and a receiver verifies whether the original data is real and complete through the same Hash function. Common Hash algorithms include Hash-based Message Authentication Code (HMAC) and Secure Hash Algorithm (SHA). The recreated hash value is the data signature.

In the embodiment of the application, whether the user has the authority to use the target vehicle is checked, and the server is indicated to successfully check under the condition that the user has the authority to use the target vehicle, so that the server sends token to the terminal.

Step S303: and carrying the token when sending the request service to the server.

In the embodiment of the application, when a user needs to use a vehicle, a terminal sends a bluetooth key service request to a server, wherein the bluetooth key service request carries a token sent to the terminal by the server.

Step S304: and acquiring the request data returned by the server under the condition that the token is successfully verified.

And obtaining the data signature to be verified by adopting the same processing method as the step S302, and indicating that the token is successfully verified under the condition that the data signature to be verified is matched with the data signature in the token. Illustratively, a hash algorithm is used to obtain a data signature in step S302, and the data signature is included in the token. And the server obtains the signature of the data to be verified by adopting the same hash algorithm as the step S302 for the data in the token sent by the terminal, compares and judges the signature of the data to be verified and the signature of the data in the token, and indicates that the token is successfully verified under the condition that the signature of the data to be verified is matched with the signature of the data in the token.

In the embodiment of the application, in the case that the token is successfully verified, the terminal receives the bluetooth key which is sent by the server and can be used for controlling the target vehicle to use.

In one possible implementation, the permission is determined based on the test item.

In one possible implementation, the bluetooth key may be used to open a door of a target vehicle, so that a user acquires a physical key of the target vehicle placed in the target vehicle. The physical key is then used to start the vehicle. And the server locks the functions irrelevant to the test items in the target vehicle, so that the user can use the functions relevant to the test items but cannot use the functions irrelevant to the test items to limit the use authority of the user for the target vehicle.

In one possible implementation, a bluetooth key may be used to control various functions of the target vehicle. That is, the target vehicle may be started without a physical key. In this case, in addition to restricting the use authority of the user by locking the function unrelated to the test item in the target vehicle by the server, the function authority of the bluetooth key may be determined according to the function authority required by the test item. For example, when testing the air conditioner function, the bluetooth key may be used to provide the authority to use the air conditioner function and other functions that may be involved, but may not provide the authority to use other functions that are not related to the testing of the air conditioner function, such as a navigation function.

For example, when the test item input by the user a in the vehicle application is a test voice function, the user a may use the voice function of the target vehicle and other functions that may be involved in the test voice function without having a use right to use other functions unrelated to the test voice function. Other methods of determining the functions that may be involved with the test function include, but are not limited to, presetting the functions associated with each function and/or user selection or tagging in a vehicle use request.

In a possible implementation manner, when the user applies that the target vehicle to be used is a vehicle to be lent, after obtaining approval of the user who has borrowed the target vehicle last to obtain the use permission of the target vehicle, the specific permission obtained by the user is determined according to the test item of the user, and the user does not have the specific use permission of the target vehicle obtained by the user who has borrowed the target vehicle last at the same time.

For example, the user a borrows the vehicle a first, the test item input in the vehicle using application of the user a is a test air conditioning function, in the case that the user a does not return the vehicle a, the vehicle a is in a state of being borrowed, at this time, the user B applies to use the vehicle a, and the test item input in the vehicle using application of the user B is a test navigation function, so after approval of the user a is obtained, the right of use of the vehicle a obtained by the user B is the use navigation function and other functions possibly involved in the test navigation function, and the right of use of the air conditioning function and other functions possibly involved in the test air conditioning function is not obtained.

In a possible implementation manner, after the user returns the target vehicle to the vehicle management center (i.e., the state of the target vehicle is modified to the idle state) or transfers the usage right of the target vehicle to other users, the bluetooth key acquired by the user is cancelled, so that the usage right of the target vehicle is lost. After the user agrees to temporarily lend the target vehicle to other users, the Bluetooth key acquired by the user is invalid when the other users acquire the use permission of the target vehicle, and the user needs to acquire the Bluetooth key again after the other users return the target vehicle to the user.

Referring to fig. 4, a flow chart of another vehicle management method according to an embodiment of the present application is schematically illustrated, which includes the following steps:

step S401: and receiving vehicle using application information input by a user, wherein the vehicle using application information comprises using time.

Step S402: and acquiring a vehicle list of available vehicles in the vehicles according to the vehicle utilization application information, wherein the available vehicles comprise vehicles in an idle state and vehicles in a to-be-lent state in the service time, the vehicles in the idle state are non-lended vehicles, and the vehicles in the to-be-lent state are not in use and lent vehicles.

Step S403: and receiving a selection instruction input by the user, wherein the selection instruction is used for indicating the target vehicle selected by the user to be used.

Step S404: and modifying the state of the target vehicle into a use state according to the use time.

The implementation methods of steps S401 to S404 may refer to the specific implementation manners of steps S101 to S104, and no further description is given here.

Step S405: and acquiring the vehicle use condition of the target vehicle in real time.

The target vehicle usage obtained in real time includes, but is not limited to, whether the vehicle is in use and target vehicle data (e.g., target vehicle functional status, fuel/electricity quantity). Methods of determining whether the target vehicle is in use include, but are not limited to, determining based on whether the target vehicle is activated and/or determining based on whether a change in fuel/electricity is occurring.

In one possible implementation, the target vehicle usage may further include usage states of various functions of the vehicle, such as whether various functions are turned on, on time, off time, and the like, and may further include a real-time location of the vehicle, a vehicle driving route, a vehicle driving mileage, and the like.

In one possible implementation manner, in the case that abnormality exists in the vehicle use condition acquired in real time, the abnormality information is automatically sent to the vehicle management center.

There are still drawbacks to current vehicle management. For example, after the vehicle is borrowed, what the vehicle is used to do, where the vehicle passes, the actual driving kilometers, and the like, all need to be reported by the user a actively, and then. Not only does this waste time for user a, but the company is difficult to verify, making vehicle management formally popular. For example, in the borrowing process, the user a has abnormal sound in twelve days a month, and the engine oil needs to be replaced through inspection, so that in order to guarantee the driving safety, the user a needs to pay for repair in advance, and on the other hand, the vehicle management center is difficult to master the vehicle condition at the first time, and the repair feasibility cannot be evaluated. By implementing the embodiment of the application, real-time, objective and traceable data support can be provided for the existing vehicle management, and in addition, the abnormal information is automatically sent to the vehicle management center under the condition that the vehicle is abnormal, so that the vehicle management center can timely receive the abnormal information of the vehicle to master the vehicle condition, and the vehicle processing mode can be determined after the repair feasibility is evaluated according to the abnormal information.

Step S406: and under the condition that the target vehicle is not used for more than a preset time, modifying the state of the target vehicle from a use state to a to-be-lent state.

In order to avoid the trouble that the target vehicle immediately enters a to-be-lent state after the user borrows the target vehicle, the user uses the vehicle and other users to borrow the vehicle, and therefore after the user borrows the target vehicle, the state of the target vehicle is immediately set to be a use state according to the starting use time. And in the preset time range after the initial use time, if the target vehicle is in the unused state all the time, adding the target vehicle into the to-be-lent state at the moment.

Illustratively, the using time of the user for borrowing the vehicle is five days in a month to ten days in a month, and the preset time range is one day. Then, at the time of the zero point of five days a month, the state of the target vehicle is set to the in-use state regardless of whether the user uses the target vehicle, that is, the state of the target vehicle at this time is the in-use state regardless of whether the vehicle is actually being used. If the user does not use the target vehicle on the day of fifty days a month, the state of the target vehicle will be modified to the pending lending state at zero time of six days a month. That is, other users may also apply for using the target vehicle at this time.

Referring to fig. 5, a schematic flow chart of another vehicle management method according to an embodiment of the present application may include the following steps:

step S501: and receiving vehicle using application information input by a user, wherein the vehicle using application information comprises using time.

Step S502: and acquiring a vehicle list of available vehicles in the vehicles according to the vehicle utilization application information, wherein the available vehicles comprise vehicles in an idle state and vehicles in a to-be-lent state in the service time, the vehicles in the idle state are non-lended vehicles, and the vehicles in the to-be-lent state are not in use and lent vehicles.

Step S503: and receiving a selection instruction input by the user, wherein the selection instruction is used for indicating the target vehicle selected by the user to be used.

Step S504: and modifying the state of the target vehicle into a use state according to the use time.

Step S505: and acquiring the vehicle use condition of the target vehicle in real time.

Step S506: and under the condition that the target vehicle is not used for more than a preset time, modifying the state of the target vehicle from a use state to a to-be-lent state.

The implementation methods of steps S501 to S506 may refer to the specific implementation manners of steps S401 to S406, and no further description is given here.

Step S507: under the condition that the state of the target vehicle is changed from a use state to an idle state or a to-be-lent state, sending a vehicle data request to the server; the vehicle data request is used for requesting vehicle data from the server; the vehicle data includes at least one of: the service cost of each department, the accumulated service time of each department, the vehicle borrowing time of each department, the individual accumulated vehicle using time, the individual vehicle using rate and the service time of each vehicle type.

The vehicle data can be obtained by acquiring vehicle sensors and/or calculating the vehicle data by a processor on the vehicle and/or obtained by uploading vehicle raw data to a server and then calculating the vehicle raw data by the server, and then uploading the vehicle raw data to the server by a communication device on the vehicle. It should be noted that the method for acquiring the vehicle data is only an example, and should not be construed as limiting in any way.

Step S508: and acquiring the vehicle data sent by the server.

Step S509: managing and adjusting vehicles based on the vehicle data.

For example, the number of vehicles assigned to each department may be adjusted according to the cumulative usage time of each department. If the cumulative service life of the department a is 20 days, the cumulative service life of the department B is 4 days, and the average cumulative service life of each department is 12 days, the number of vehicles allocated to the department a can be increased and the number of vehicles allocated to the department B can be decreased on the basis of the original number of vehicles allocated to each department. The calculation mode of the average accumulated use time of each department is the ratio of the sum of the accumulated use time of each department to the number of departments. For example, vehicles may be assigned to each department according to the time of day the department borrowed. If the time of borrowing vehicles of the department A is concentrated on nine to eleven am, and the time of borrowing vehicles of the department B is concentrated on three to five pm, the number of vehicles allocated to the department A is increased from nine to eleven am, and the number of vehicles allocated to the department B is increased from three to five pm. For example, in the case that the utilization rate of the personal vehicle is lower than the preset threshold value, that is, the vehicle is idle due to the fact that the user is not used for borrowing the vehicle, the utilization rate of the vehicle is reduced, then the user can be reminded and/or the number of times of borrowing the vehicle by the user is limited and/or conditions required by subsequent vehicle borrowing of the user are increased, so that the occurrence of the situation is reduced to a certain extent. For example, the number of vehicles of each vehicle type may be adjusted according to the average utilization rate of each vehicle type and a preset average utilization rate.

The calculation mode of the average utilization rate of each vehicle type is as follows:

the calculation method of the utilization rate of each vehicle is as follows:

the total duration of each vehicle is the duration from the time of release to the time of acquiring the vehicle data sent by the server. If the average utilization rate of the M-model vehicles is 70%, the average utilization rate of the N-model vehicles is 30%, and the preset average utilization rate is 50%, the number of the M-model vehicles and/or a part of the N-model vehicles can be increased in subsequently released vehicles. By implementing the method, the vehicle can be managed and adjusted by analyzing the vehicle data, so that the aims of continuously optimizing vehicle management and improving the vehicle utilization rate are fulfilled.

The system related to the embodiment of the present application is described below with reference to the accompanying drawings.

Referring to fig. 6, a schematic composition diagram of a vehicle management system according to an embodiment of the present application is shown, where the vehicle management system 600 includes:

the receiving module 601 is configured to receive vehicle utilization application information input by a user, where the vehicle utilization application information includes a utilization time;

an obtaining module 602, configured to obtain a vehicle list of available vehicles in the vehicles according to the in-vehicle application information, where the available vehicles include a vehicle in an idle state and a vehicle in a to-be-lent state during the use time, the vehicle in the idle state is an un-lent vehicle, and the vehicle in the to-be-lent state is an unused vehicle that has been lent;

the receiving module 601 is further configured to receive a selection instruction input by the user, where the selection instruction is used to instruct the user to select a target vehicle for use;

and the processing module 603 is configured to modify the state of the target vehicle into a use state according to the use time.

Optionally, the vehicle is a test vehicle, the vehicle use application information further includes a test item, and the available vehicle includes a vehicle in an idle state and a vehicle in a to-be-lent state, which are matched with the test item.

Optionally, the obtaining module 602 is further configured to obtain a vehicle usage of the target vehicle in real time;

the processing module 603 is further configured to modify the state of the target vehicle from a use state to a to-be-lent state when the target vehicle is not used for more than a preset time period.

Optionally, the processing module 603 is further configured to check whether the user has permission to use the target vehicle;

the processing module 603 is further configured to modify the state of the target vehicle to a use state according to the use time when the user has permission to use the target vehicle.

Optionally, the obtaining module 602 is further configured to obtain a bluetooth key sent by the server when the user has the right to use the target vehicle, where the bluetooth key is used to give the user the right to use the target vehicle.

Optionally, the vehicle list includes at least one of the following vehicle information of the available vehicles: historical number of people using, historical duration of use, historical use item.

Optionally, the system 600 for vehicle management further includes:

a sending module 604, configured to send a vehicle data request to the server when the status of the target vehicle changes from a use status to an idle status or a to-be-lent status; the vehicle data request is used for requesting vehicle data from the server; the vehicle data includes at least one of: the service cost of each department, the accumulated service duration of each department, the vehicle borrowing time of each department, the individual accumulated vehicle using time, the individual vehicle using rate and the service duration of each vehicle type;

the obtaining module 602 is further configured to obtain vehicle data sent by the server;

the processing module 603 is further configured to manage and adjust the vehicle based on the vehicle data.

The specific implementation function of the vehicle management system 600 may refer to the method steps corresponding to fig. 1 to fig. 5, which are not described herein again.

Please refer to fig. 7, which is a schematic composition diagram of a vehicle management apparatus according to an embodiment of the present application. Can include the following steps: processor 110, memory 120; wherein the processor 110, the memory 120 and the communication interface 130 are connected by a bus 140, the memory 120 is used for storing instructions, and the processor 110 is used for executing the instructions stored by the memory 120 to implement the method steps corresponding to fig. 1-5 as described above.

The processor 110 is configured to execute the instructions stored in the memory 120 to control the communication interface 130 to receive and transmit signals, thereby implementing the steps of the above-described method. The memory 120 may be integrated in the processor 110, or may be provided separately from the processor 110.

As an implementation manner, the function of the communication interface 130 may be realized by a transceiver circuit or a dedicated chip for transceiving. The processor 110 may be considered to be implemented by a dedicated processing chip, processing circuit, processor, or a general-purpose chip.

As another implementation manner, a manner of using a general-purpose computer to implement the apparatus provided in the embodiment of the present application may be considered. Program code that implements the functions of the processor 110 and the communication interface 130 is stored in the memory 120, and a general-purpose processor implements the functions of the processor 110 and the communication interface 130 by executing the code in the memory 120.

For the concepts, explanations, details and other steps related to the technical solutions provided in the embodiments of the present application, please refer to the description of the method or the contents of the method steps executed by the apparatus in other embodiments, which are not described herein again.

As another implementation of the present embodiment, a computer-readable storage medium is provided, on which instructions are stored, which when executed perform the method in the above-described method embodiment.

As another implementation of the present embodiment, a computer program product is provided that contains instructions that, when executed, perform the method in the above-described method embodiments.

Those skilled in the art will appreciate that only one memory and processor are shown in fig. 7 for ease of illustration. In an actual terminal or server, there may be multiple processors and memories. The memory may also be referred to as a storage medium or a storage device, and the like, which is not limited in this application.

It should be understood that, in the embodiment of the present Application, the processor may be a Central Processing Unit (CPU), and the processor may also be other general-purpose processors, digital Signal Processors (DSPs), application Specific Integrated Circuits (ASICs), field-Programmable Gate arrays (FPGAs) or other Programmable logic devices, discrete Gate or transistor logic devices, discrete hardware components, and the like.

It will also be appreciated that the memory referred to in the embodiments of the application may be either volatile memory or nonvolatile memory, or may include both volatile and nonvolatile memory. The nonvolatile Memory may be a Read-Only Memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an Electrically Erasable PROM (EEPROM), or a flash Memory. The volatile Memory may be a Random Access Memory (RAM) which serves as an external cache. By way of example, and not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double Data Rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), SLDRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

It should be noted that when the processor is a general-purpose processor, a DSP, an ASIC, an FPGA or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, the memory (memory module) is integrated in the processor.

It should be noted that the memory described herein is intended to comprise, without being limited to, these and any other suitable types of memory.

The bus may include a power bus, a control bus, a status signal bus, and the like, in addition to the data bus. But for clarity of illustration the various buses are labeled as buses in the figures.

It should also be understood that reference herein to first, second, third, fourth, and various numerical numbering is merely for convenience of description and is not intended to limit the scope of the present application.

It should be understood that the term "and/or" herein is merely one type of association relationship that describes an associated object, meaning that three relationships may exist, e.g., a and/or B may mean: a exists alone, A and B exist simultaneously, and B exists alone. In addition, the character "/" herein generally indicates that the former and latter related objects are in an "or" relationship.

In implementation, the steps of the above method may be performed by integrated logic circuits of hardware in a processor or instructions in the form of software. The steps of a method disclosed in connection with the embodiments of the present application may be directly implemented by a hardware processor, or may be implemented by a combination of hardware and software modules in a processor. The software module may be located in ram, flash memory, rom, prom, or eprom, registers, etc. storage media as is well known in the art. The storage medium is located in a memory, and a processor reads information in the memory and completes the steps of the method in combination with hardware of the processor. To avoid repetition, it is not described in detail here.

In the embodiments of the present application, the sequence numbers of the above-mentioned processes do not mean the execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

Those of ordinary skill in the art will appreciate that the various Illustrative Logical Blocks (ILBs) and steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit.

In the above embodiments, the implementation may be wholly or partially realized by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, cause the processes or functions described in accordance with the embodiments of the application to occur, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another computer readable storage medium, for example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by wire (e.g., coaxial cable, fiber optic, digital subscriber line) or wirelessly (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that incorporates one or more of the available media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk), among others.

The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A method of vehicle management, comprising:

acquiring a vehicle list of available vehicles in the vehicles according to the vehicle utilization application information, wherein the available vehicles comprise vehicles in an idle state and vehicles in a to-be-lent state in the service time, the vehicles in the idle state are non-lent vehicles, and the vehicles in the to-be-lent state are lent vehicles which are not in use;

2. The method of claim 1, wherein the vehicle is a test vehicle, the vehicle requisition information further includes test items, and the available vehicles include a vehicle in an idle state and a vehicle in a pending lending state matching the test items.

3. The method according to claim 1 or 2, further comprising, after the modifying the state of the target vehicle into a use state according to the use time:

acquiring the vehicle use condition of the target vehicle in real time;

and under the condition that the target vehicle is not used for more than a preset time, modifying the state of the target vehicle from a use state to a to-be-lent state.

4. The method of claim 3, the modifying the state of the target vehicle to a use state according to the use time comprising:

checking whether the user has authority to use the target vehicle;

and under the condition that the user has the authority to use the target vehicle, modifying the state of the target vehicle into a use state according to the use time.

5. The method of claim 4, the user's right to use the target vehicle being determined from the test item.

6. The method of claim 5, further comprising:

and under the condition that the user has the authority to use the target vehicle, acquiring a Bluetooth key sent by a server, wherein the Bluetooth key is used for giving the authority to use the target vehicle to the user.

7. The method of claim 6, the list of vehicles including at least one of the following vehicle information for the available vehicles: historical number of people using, historical use duration and historical use items.

8. The method of claim 3, further comprising, after said modifying the state of the target vehicle to a use state according to the usage time:

under the condition that the state of the target vehicle is changed from a use state to an idle state or a to-be-lent state, sending a vehicle data request to the server; the vehicle data request is used for requesting vehicle data from the server; the vehicle data includes at least one of: the service cost of each department, the accumulated service duration of each department, the vehicle borrowing time of each department, the individual accumulated vehicle using time, the individual vehicle using rate and the service duration of each vehicle type;

acquiring vehicle data sent by the server;

managing and adjusting vehicles based on the vehicle data.

9. A system for vehicle management, comprising:

10. An apparatus for vehicle management, comprising:

a processor, a memory and a bus, the processor and the memory being connected by the bus, wherein the memory is configured to store a set of program codes, and the processor is configured to call the program codes stored in the memory to execute the method according to any one of claims 1-8.

11. A computer-readable storage medium, comprising:

the computer-readable storage medium has stored therein instructions which, when run on a computer, implement the method of any one of claims 1-8.