Vehicle Management System

The vehicle management system addresses failure risks and downtime by equalizing load across vehicles, optimizing service continuity through strategic allocation.

JP7619333B2Active Publication Date: 2025-01-22TOYOTA JIDOSHA KK
View PDF 9 Cites 0 Cited by

Patent Information

Application Number
JP2022099488
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Filing Date
2022-06-21
Publication Date
2025-01-22
Estimated Expiration
2042-06-21

AI Technical Summary

Technical Problem

Vehicles used for transportation services face increased failure risk under high load conditions and incur downtime due to unexpected maintenance, leading to lost service opportunities.

Method used

A vehicle management system that calculates and equalizes the accumulated load across multiple vehicles, prioritizing those with lower loads for specific routes to reduce failure risk and minimize downtime.

Benefits of technology

The system effectively reduces the risk of vehicle failure and downtime by optimizing vehicle allocation based on load distribution, ensuring continuous service provision.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007619333000001
    Figure 0007619333000001
  • Figure 0007619333000002
    Figure 0007619333000002
  • Figure 0007619333000003
    Figure 0007619333000003
Patent Text Reader

Abstract

To suppress the increase of time which cannot be used for providing services.SOLUTION: A management server executes processing including the steps of: acquiring operation information (S102) upon receiving a vehicle allocation request (YES in S100); acquiring a travel route to a vehicle allocation (S104); calculating a storage amount of loads (S106); setting a vehicle of a low storage amount as an allocation vehicle (S110) in a case where a load in the travel route to the vehicle allocation destination is high (YES in S108); setting a vehicle of a high storage amount as an allocation vehicle (S112) in a case where the load in the travel route to the vehicle allocation destination is not high (NO in S108); and transmitting travel schedule information (S114).SELECTED DRAWING: Figure 3
Need to check novelty before this filing date? Find Prior Art

Description

[Technical field]

[0001] The present disclosure relates to a vehicle management system. [Background technology]

[0002] When vehicles are used to provide transportation services, maintenance such as replacing consumables and adjusting parts is performed periodically, but since the vehicle cannot be used to provide services during the maintenance period, opportunities to provide the service may be lost. Therefore, when providing services using multiple vehicles, it is necessary to perform vehicle maintenance at an appropriate time, taking into consideration the demand for service provision and the provision status of services using multiple vehicles.

[0003] Japanese Patent Application Publication No. 2020-013373 (Patent Document 1) discloses a vehicle maintenance management system that uses vehicle usage information to instruct the implementation of maintenance. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2020-013373 A Summary of the Invention [Problem to be solved by the invention]

[0005] In vehicles used to provide the above-mentioned services, if they continue to be used under high load conditions, the risk of a breakdown increases, and if unanticipated vehicle maintenance is required due to a breakdown, the time that the vehicle cannot be used to provide services will increase.

[0006] The present disclosure has been made to solve the above-mentioned problems, and its purpose is to provide a vehicle management system that suppresses an increase in the time that cannot be used to provide services. [Means for solving the problem]

[0007] A vehicle management system according to an aspect of the present disclosure includes a plurality of vehicles used to provide a transportation service, and a server capable of communicating with the plurality of vehicles. When a request is made to provide a transportation service using the plurality of vehicles on a plurality of travel routes, the server calculates an accumulated load amount for each of the plurality of vehicles. The server preferentially assigns vehicles with a large accumulated load amount to a travel route among the plurality of travel routes in which a load degree indicating the degree of load acting on the vehicle when traveling is smaller than other travel routes.

[0008] In this way, the load accumulation amount can be evenly distributed among multiple vehicles, reducing the risk of breakdowns caused by the load being concentrated on some vehicles. As a result, unexpected maintenance can be avoided, and the amount of time that cannot be used to provide services can be reduced.

[0009] In one embodiment, the server calculates an accumulated load for each of the plurality of vehicles using the driving history of each of the plurality of vehicles.

[0010] In this way, the amount of accumulated load in each of the multiple vehicles can be calculated with high accuracy.

[0011] Additionally, in some embodiments, the vehicle includes an autonomous vehicle. In this way, unexpected maintenance can be avoided on the autonomous vehicle, and an increase in the amount of time that the vehicle cannot be used to provide services can be suppressed. Effect of the Invention

[0012] According to the present disclosure, it is possible to provide a vehicle management system that suppresses an increase in the time that cannot be used to provide services. [Brief description of the drawings]

[0013] [Figure 1] 1 is a diagram illustrating an overall configuration of a vehicle management system. [Diagram 2] FIG. 2 is a diagram showing an example of the configuration of an ADK and a VP in more detail. [Diagram 3] 13 is a flowchart illustrating an example of a process executed by a management server. [Figure 4] FIG. 2 is a diagram for explaining allocation of vehicles to a plurality of travel routes. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the drawings. In the drawings, the same or corresponding parts are designated by the same reference characters and their description will not be repeated.

[0015] FIG. 1 is a diagram showing a schematic overall configuration of a vehicle management system 100. The vehicle management system 100 manages a plurality of vehicles. In reality, a large number of vehicles can be managed by the vehicle management system 100, but for the sake of convenience, the following description will be given of an example in which specific vehicles 1 and 4 are managed by the vehicle management system 100. The vehicle management system 100 includes vehicles 1 and 4 and a management server 7. The vehicle 1 includes an autonomous driving kit (ADK) 2 and a vehicle platform (VP) 3. Similarly, the vehicle 4 includes an ADK 5 and a VP 6.

[0016] The user of the vehicles 1 and 4 may be, for example, a business providing a transportation service by automatic driving using the vehicles 1 and 4 (such as a bus business, a taxi business, a rental car business, a car sharing business, or a ride sharing service business). In this embodiment, it is assumed that the user of the vehicles 1 and 4 is, for example, a business providing a transportation service for personnel who owns a plurality of vehicles. The transportation service for personnel includes, for example, a service in which a vehicle is driven on a plurality of driving routes (such as a driving route passing through an urban area and a driving route passing through a mountainous area) to arrive at a predetermined boarding and disembarking point on the driving route at a predetermined set time, and personnel are boarded and disembarked at the boarding and disembarking point, and a usage fee is collected.

[0017] An example of a configuration for performing autonomous driving will be described below using vehicle 1 as an example. ADK2 mounted on vehicle 1 is configured to be attachable to VP3 of vehicle 1 and detachable from VP3. ADK2 is attached to a predetermined position, such as the rooftop of VP3.

[0018] The ADK2 is configured to be able to perform autonomous driving of the vehicle 1. Specifically, the ADK2 creates a driving plan for the vehicle 1. The ADK2 outputs various control requests for driving the vehicle 1 according to the driving plan to the VP3 according to an API (Application Program Interface) defined for each control request. The ADK2 also receives various signals indicating the vehicle state (state of the VP3) from the VP3 according to an API defined for each signal. The ADK2 then reflects the vehicle state in the driving plan. The ADK2 may create the driving plan using driving plan information from the management server 7, for example.

[0019] The VP3 executes driving control in the automatic driving mode according to a control request from the ADK2. When the ADK2 is detached from the VP3, the VP3 is configured to be able to execute driving control in the manual mode (driving control according to the driver's operation).

[0020] The VP 3 transmits various information (such as operation information, which will be described later) to the management server 7 in the vehicle management system 100.

[0021] The management server 7 may be the operator's own server, a shared server shared by multiple operators including the operator in question, or a cloud server provided by a cloud server management company.

[0022] The management server 7 is, for example, a server operated by a business operator who performs maintenance management of a plurality of vehicles including the vehicle 1. The business operator may be, for example, the manufacturer of the VP3 or the manufacturer of the ADK2. Furthermore, the management server 7 may be configured to include a server operated by the manufacturer of the VP3 and a server that operates the ADK2. In the following explanation, a case where the management server 7 is configured by one server will be explained as an example.

[0023] The management server 7 is configured to be able to receive operation information from each of the vehicles 1 and 4. The operation information of the vehicles 1 and 4 includes information capable of identifying the vehicles 1 and 4, such as the number written on the license plate or the serial number (hereinafter referred to as vehicle ID), information on the driving history, such as driving time and driving distance (hereinafter referred to as history information), and information on the maintenance of the vehicles 1 and 4 (hereinafter referred to as maintenance information). The management server 7 includes a database (not shown) for storing the operation information received from at least one of the vehicles 1 and 4 in a format capable of identifying the vehicle that sent the information. The management server 7 generates driving plan information and fare information using the received operation information, and transmits them to each of the vehicles 1 and 4.

[0024] In this disclosure, "maintenance" of a vehicle refers to a general action for maintaining a vehicle in a normal state or for restoring a vehicle from an abnormal state to a normal state. Maintenance may include inspection, repair, adjustment, or replacement of any part installed in the vehicle. The maintenance information may include information for diagnosing whether or not the part is in a state requiring maintenance, such as the mileage after maintenance of the part to be maintained or the mileage until the next maintenance of the part, or may include information indicating the diagnosis result of whether or not the part is in a state requiring maintenance.

[0025] 2 is a diagram showing in more detail an example of the configuration of the ADK 2 and the VP 3. The ADK 2 includes a computer 21, a recognition sensor 22, a posture sensor 23, and an HMI (Human Machine Interface) 25.

[0026] The VP3 includes a vehicle control interface box (VCIB) 31 and a base vehicle 32. The base vehicle 32 includes a central electronic control unit (ECU) 321, a brake system 322, a steering system 323, a power train system 324, and a digital communication system (DCM) 327.

[0027] The powertrain system 324 includes an electric parking brake (EPB) system 324A, a parking lock (P-lock) system 324B, and a propulsion system 324C.

[0028] The computer 21 acquires data on the environment of the vehicle 1 using the recognition sensor 22 when the vehicle 1 is autonomously driven. The computer 21 also acquires data on the attitude, behavior, and position of the vehicle 1 using the attitude sensor 23 when the vehicle 1 is autonomously driven. Furthermore, the computer 21 is communicably connected to the VCIB 31. The computer 21 acquires the vehicle state from the VP3 via the VCIB 31 and sets the next operation of the vehicle 1 (accelerate, decelerate, turn, etc.). The computer 21 outputs various commands to the VP3 via the VCIB 31 to realize the next operation.

[0029] The recognition sensor 22 is a sensor for recognizing the environment of the vehicle 1. The recognition sensor 22 includes, for example, at least one of a LIDAR (Laser Imaging Detection and Ranging), a millimeter wave radar, and a camera (none of which are shown). The LIDAR measures the distance and direction of an object by emitting, for example, an infrared pulse laser light and detecting the reflected light of the laser light from the object. The millimeter wave radar measures the distance and direction of an object by emitting millimeter waves and detecting the millimeter wave reflected wave from the object. The camera captures an image of the surroundings of the vehicle 1.

[0030] The attitude sensor 23 is a sensor for detecting the attitude, behavior, and position of the vehicle 1. The attitude sensor 23 includes, for example, a position detection device such as an IMU (Inertial Measurement Unit) and a GPS (Global Positioning System) (neither shown). The IMU detects, for example, the acceleration in the forward / backward, left / right, and up / down directions of the vehicle 1, and the angular velocities in the roll, pitch, and yaw directions of the vehicle 1. The GPS identifies the position of the vehicle 1 using information received from multiple GPS satellites orbiting the Earth.

[0031] The HMI 25 is configured to be connected to an input / output device (not shown), such as a touch panel display, provided on the base vehicle 32, for example.

[0032] The VCIB 31 is communicatively connected to the ADK 2 via a controller area network (CAN) or the like. The VCIB 31 executes a predetermined API defined for each signal to receive various control requests from the ADK 2 and output vehicle states to the ADK 2. When the VCIB 31 receives a control request from the ADK 2, it outputs a control command corresponding to the control request to a system (e.g., the brake system 322, the steering system 323, and the powertrain system 324) corresponding to the control command. The VCIB 31 also acquires various information related to the vehicle state (state of the base vehicle 32) and outputs the acquired information to the ADK 2.

[0033] The central ECU 321 transmits various information indicating the vehicle state to the management server 7 and transmits various requests to the management server 7 via the DCM 327. The central ECU 321 also receives commands or notifications from the management server 7 via the DCM 327. Furthermore, the central ECU 321 diagnoses whether or not the VP3 is in a state requiring maintenance using the vehicle state acquired from each system of the VP3, or receives the results of self-diagnosis performed in each system of the VP3 and diagnoses whether or not the VP3 is in a state requiring maintenance using the received diagnostic results.

[0034] In this embodiment, the central ECU 321 is described as an entity that executes a diagnostic process to diagnose whether or not the vehicle 1 is in a state that requires maintenance. However, in addition to such a function, the central ECU 321 may also have a function (gateway function) of relaying communications between various ECUs included in each system.

[0035] The brake system 322 is configured to control braking devices (not shown) provided on each wheel of the base vehicle 32. The steering system 323 is configured to control the steering angle of the steering wheels of the vehicle 1 using a steering device (not shown).

[0036] The EPB system 324A controls an EPB (not shown) provided on at least one of the wheels in accordance with a control request transmitted from the ADK2 via the VCIB 31. The P-lock system 324B controls a P-lock device (not shown) provided on the transmission in accordance with a control request transmitted from the ADK2 via the VCIB 31. The propulsion system 324C controls the driving force from a driving source (such as a motor generator or engine, not shown) in accordance with a control request from the ADK2.

[0037] The DCM 327 is an in-vehicle communication module that is configured to enable two-way data communication between the central ECU 321 and the management server 7.

[0038] The ADK 5 of vehicle 4 has a similar configuration to the ADK 2 of vehicle 1. Furthermore, the VP 6 of vehicle 4 has a similar configuration to the VP 3 of vehicle 1. Therefore, detailed description thereof will not be repeated.

[0039] The management server 7 includes a control device 8, a storage device 9, and a communication device 10. The control device 8, the storage device 9, and the communication device 10 are connected to each other via a communication bus 11 so as to be able to communicate with each other.

[0040] The control device 8 is configured to include a CPU (Central Processing Unit), memory (such as ROM (Read Only Memory) and RAM (Random Access Memory)), and input / output ports for inputting and outputting various signals, none of which are shown in the figure. The various controls performed by the control device 8 are performed by software processing, i.e., by the CPU reading out a program stored in the memory. The various controls by the control device 8 can also be realized by a general-purpose computer (not shown) executing a program stored in a storage medium. The various controls by the control device 8 are not limited to software processing, and may be processed by dedicated hardware (electronic circuitry).

[0041] The storage device 9 stores operation information received from a plurality of vehicles 1 and 4 that are configured to be able to communicate with the management server 7.

[0042] The communication device 10 realizes two-way communication between the vehicles 1 and 4 and a communication network (not shown). The management server 7 uses the communication device 10 to enable communication with a plurality of vehicles including the vehicles 1 and 4 via a base station (not shown) or the like provided in the communication network.

[0043] In the vehicle management system 100 having the above configuration, for example, the management server 7 sets a driving route indicating route information for each of the vehicles 1 and 4 to travel, and transmits driving plan information to each of the vehicles 1 and 4 so that the vehicles arrive at or depart from boarding and disembarking points on the set driving route at preset times. Furthermore, the management server 7 transmits information on the usage fee for using the vehicles on the set driving route to the vehicles 1 and 4 as fee information.

[0044] Each of the vehicles 1 and 4 performs automatic driving according to the travel plan information, and also displays fare information to the user using a display device or the like, and executes payment processing according to the user's usage. In this way, each of the vehicles 1 and 4 provides a transportation service for people traveling along the travel route by getting on and off users at the boarding and alighting points.

[0045] When a plurality of vehicles including the vehicles 1 and 4 are used to provide transportation services for people, maintenance of the vehicles 1 and 4 is performed periodically.

[0046] For example, the vehicles 1, 4 or the management server 7 diagnose whether or not each of the vehicles 1, 4 is in a state requiring maintenance, thereby determining whether or not the vehicles 1, 4 require maintenance.

[0047] Examples of cases in which vehicle 1 is diagnosed as to whether maintenance is required include when the period of use of the part to be diagnosed since the last time it was replaced exceeds a threshold value, when the amount of wear of the part to be diagnosed since the last time it was replaced exceeds a threshold value, when an error code for the part to be diagnosed is output, or when the output value of the part to be diagnosed becomes abnormal.

[0048] For example, if the period of use of various oils used in the engine, motor generator, etc. since the last time they were changed exceeds a threshold value set according to the type of oil and the vehicle model, it is diagnosed as a state requiring maintenance for an oil change. Alternatively, if the amount of wear of brake pads included in the braking device exceeds a threshold value, it is diagnosed as a state requiring maintenance for brake pad replacement. Alternatively, if a predetermined error code is output from equipment related to the driving operation of the vehicle 1, such as the engine or motor generator, it is diagnosed as a state requiring inspection maintenance. Alternatively, if the output value of various sensors is output outside the normal range, it is diagnosed as a state requiring maintenance such as sensor replacement or adjustment.

[0049] These determinations are made using the diagnosis results of a self-diagnosis process executed in the vehicle 1. The self-diagnosis process is executed, for example, in the computer 21 of the ADK 2 or the central ECU 321 of the VP3. Alternatively, the management server 7 may manage information on the maintenance history of the vehicles 1 and 4, execute a diagnostic process using the managed information, and determine whether or not a condition requires maintenance using the diagnostic result.

[0050] However, if a diagnosis is made that a maintenance is required as described above and the maintenance is carried out, the vehicles 1 and 4 cannot be used to provide services during the maintenance period, which may result in a loss of opportunities to provide services. Therefore, it is necessary to perform vehicle maintenance at an appropriate time, taking into consideration the demand for and the status of service provision.

[0051] In the case of vehicles 1 and 4 used to provide the services described above, if they are used continuously under high load conditions, the risk of a breakdown increases, and if unanticipated vehicle maintenance is performed due to a breakdown, the time during which the vehicles cannot be used to provide services will increase.

[0052] Therefore, in this embodiment, the management server 7 operates as follows. That is, when a transportation service using a plurality of vehicles on a plurality of travel routes is requested, the management server 7 calculates the amount of accumulated load in each of the plurality of vehicles. Furthermore, the management server 7 preferentially assigns vehicles with a large accumulated load among the plurality of vehicles to a travel route having a smaller load level, which indicates the degree of load acting on the vehicle when traveling, than other travel routes among the plurality of travel routes.

[0053] In this way, the load accumulation amount can be evenly distributed among multiple vehicles, reducing the risk of breakdowns caused by the load being concentrated on some vehicles. As a result, unexpected maintenance can be avoided, and the amount of time that cannot be used to provide services can be reduced.

[0054] An example of processing executed by the management server 7 will be described below with reference to Fig. 3. Fig. 3 is a flowchart showing an example of processing executed by the management server 7. A series of processing shown in this flowchart is repeatedly executed by the management server 7 at predetermined intervals.

[0055] In step (hereinafter, step is abbreviated as S) 100, the management server 7 (more specifically, the control device 8 of the management server 7) determines whether or not there is a vehicle dispatch request. For example, the management server 7 determines that there is a vehicle dispatch request when it receives information from any vehicle traveling on a plurality of travel routes (providing transportation services) indicating that the vehicle is in a state requiring maintenance, or when it determines that any vehicle among the plurality of vehicles is in a state requiring maintenance using information received from a vehicle traveling on any of the plurality of travel routes. If it is determined that there is a vehicle dispatch request (YES in S100), the process proceeds to S102.

[0056] In S102, the management server 7 acquires operation information. The management server 7 acquires operation information from each of a plurality of vehicles including vehicles 1 and 4. When the management server 7 requests operation information from vehicle 1 via, for example, the communication device 10, the central ECU 321 of vehicle 1 receives the request signal from the management server 7 via the DCM 32. The central ECU 321 acquires operation information, for example, from the computer 21 of the ADK 2 or the memory of the central ECU 321, and transmits the acquired operation information to the management server 7 via the DCM 32. Thereafter, the process proceeds to S104.

[0057] In S104, the management server 7 acquires information on the driving route of the vehicle destination. The management server 7 identifies the driving route of the vehicle destination using the vehicle dispatch request. The management server 7 may, for example, identify a vehicle that requires maintenance, and identify the driving route of the identified vehicle as the driving route of the vehicle destination. Then, the process proceeds to S106.

[0058] In S106, the management server 7 calculates the accumulated load amount of each of the plurality of vehicles. The management server 7, for example, calculates the accumulated load amount of each vehicle other than the vehicle that requires maintenance among the plurality of vehicles. The management server 7 calculates the accumulated load amount using at least one of a plurality of pieces of driving history information, such as the mileage, driving time, vehicle weight, total number of passengers, the mileage until the next maintenance is performed, and the driving time until the next maintenance is performed, which are included in the history information. The management server 7 may calculate the accumulated load amount in two stages, including a high accumulation state and a low accumulation state. For example, the management server 7 may determine the high accumulation state when the mileage is equal to or greater than a threshold value, and may determine the low accumulation state when the mileage is shorter than the threshold value. The management server 7 may calculate the accumulated load amount in three stages or more by setting a plurality of threshold values, or may calculate the accumulated load amount expressed as a percentage, for example. The management server 7 may, for example, calculate a basic value of the accumulated amount using at least one of the pieces of information on the multiple driving histories, set a correction coefficient using the other pieces of information on the driving histories, and calculate the accumulated amount expressed as a percentage by correcting the basic value using the correction coefficient. The management server 7 may, for example, associate the calculated accumulated amount with the vehicle ID of the corresponding vehicle and store them in the storage device 9. Thereafter, the process proceeds to S108.

[0059] In S108, the management server 7 judges whether the driving route of the vehicle allocation destination is a high-load driving route. The management server 7 may judge whether the driving route of the vehicle allocation destination is a high-load driving route based on the state of a flag indicating that the driving route is a high-load driving route (for example, a flag that is turned on when the driving route is a high-load driving route) that is preset for each of the multiple driving routes. Alternatively, the management server 7 may judge that the driving route of the vehicle allocation destination is a high-load driving route when there is an uphill slope with an elevation difference of a threshold or more. Alternatively, the management server 7 may judge that the driving route is a high-load driving route when the travel distance is a threshold or more. Alternatively, the management server 7 may judge that the driving route is a high-load driving route when the number of occurrences of waiting at a traffic light during one round of travel on the driving route of the vehicle allocation destination is a threshold or more using the implementation history of waiting at a traffic light during travel on the driving route of the vehicle allocation destination. If the driving route of the vehicle allocation destination is judged to be a high-load driving route (YES in S108), the process proceeds to S110.

[0060] In S110, the management server 7 sets the vehicle with the low accumulation amount as the vehicle to be allocated for the driving route of the vehicle allocation destination. The management server 7, for example, performs ranking so that the magnitude relationship can be specified for the accumulation amount of each vehicle stored in the storage device 9. Then, the management server 7 may, for example, set the vehicle with the lowest accumulation amount as the vehicle to be allocated for the driving route of the vehicle allocation destination. The management server 7 may, for example, set the vehicle with the shortest driving distance as the vehicle to be allocated, or may set the vehicle with the shortest driving time as the vehicle to be allocated. For example, when there are multiple options for the vehicle with the low accumulation amount, the management server 7 may set the vehicle with the highest priority as the vehicle to be allocated according to the priority set by a predetermined criterion for selecting the vehicle with the low accumulation amount. Thereafter, the process proceeds to S114.

[0061] In S112, the management server 7 sets the vehicle with the high accumulation amount as the vehicle to be allocated for the driving route of the vehicle allocation destination. The management server 7, for example, performs ranking so that the magnitude relationship can be specified for the accumulation amount of each vehicle stored in the storage device 9. Then, the management server 7 may, for example, set the vehicle with the highest accumulation amount as the vehicle to be allocated for the driving route of the vehicle allocation destination. The management server 7 may, for example, set the vehicle with the longest driving distance as the vehicle to be allocated, or may set the vehicle with the longest driving time as the vehicle to be allocated. For example, when there are multiple options for the vehicle with the high accumulation amount, the management server 7 may set the vehicle with the highest priority as the vehicle to be allocated according to the priority set by a predetermined criterion for selecting the vehicle with the high accumulation amount. Thereafter, the process proceeds to S114.

[0062] In S114, the management server 7 transmits the driving plan information to the vehicle to be dispatched. The management server 7, for example, sets the departure and arrival times at each boarding and alighting point set on the driving route of the vehicle to be dispatched. The management server 7, for example, sets the same departure and arrival times as the departure and arrival times at each boarding and alighting point set on the driving route of the vehicle to be dispatched, which are set on the vehicle in a state requiring maintenance when it is determined that there is a vehicle dispatch request. The management server 7 transmits information on the driving route of the vehicle to be dispatched and the above-mentioned information on the departure and arrival times, etc. as driving plan information to the vehicle to be dispatched. The process then ends. If it is determined that there is no vehicle dispatch request (NO in S100), this process ends.

[0063] An example of the operation of the management server 7 based on the above-described structure and flowchart will be described with reference to FIG.

[0064] Fig. 4 is a diagram for explaining the allocation of vehicles to a plurality of travel routes. (A) to (F) in Fig. 4 show examples of boarding and disembarking points. Fig. 4 shows a high-load route A and a low-load route B as examples of travel routes.

[0065] On route A in Figure 4, the vehicle travels between each boarding and disembarking point in the order of (B), (C), (D), and (E) in Figure 4, for example, as shown by the solid arrows in Figure 4, then returns to (B) and circulates.

[0066] On route B in Figure 4, the vehicle travels between each boarding and disembarking point in the order of (A), (B), (C), and (F) in Figure 4, for example, as indicated by the dashed arrows in Figure 4, then returns to (A) and loops around.

[0067] For example, assume that vehicle 1, which is one of a plurality of vehicles and travels along route A, determines through self-diagnosis processing that it is in a state requiring maintenance.

[0068] At this time, when the management server 7 receives information from the vehicle 1 indicating that maintenance is required, it determines that there is a vehicle dispatch request (YES in S100). Therefore, operation information is acquired from a plurality of vehicles (S102), and it is acquired that the driving route of the dispatch destination is route A that the vehicle 1 has traveled (S104).

[0069] The load accumulation amount of each of the multiple vehicles is calculated (S106), and since the acquired route A is a high-load travel route (YES in S108), a vehicle with a low accumulated load is set as a dispatched vehicle (S110). Then, the travel plan information is transmitted to the vehicle set as the dispatched vehicle (S114).

[0070] After receiving the trip plan information, the dispatch vehicle will automatically travel between each boarding and disembarking point on Route A according to the sequence and departure and arrival times contained in the trip plan information.

[0071] Next, a case will be considered in which vehicle 4, one of the multiple vehicles traveling along route B, determines through self-diagnosis processing that it is in a state requiring maintenance.

[0072] At this time, when the management server 7 receives information from the vehicle 4 indicating that maintenance is required, it determines that there is a vehicle dispatch request (YES in S100). Therefore, operation information is acquired from a plurality of vehicles (S102), and it is acquired that the driving route of the dispatch destination is route B that the vehicle 4 has traveled (S104).

[0073] The load accumulation amount of each of the multiple vehicles is calculated (S106), and since the acquired route B is a low-load travel route (NO in S108), a vehicle with a high load accumulation is set as a dispatched vehicle (S112). Then, the travel plan information is transmitted to the vehicle set as the dispatched vehicle (S114).

[0074] The dispatch vehicle that receives the trip plan information will automatically travel between each boarding and disembarking point on Route B in accordance with the sequence and departure and arrival times contained in the trip plan information.

[0075] As described above, the vehicle management system according to the present embodiment can equalize the load accumulation amount in a plurality of vehicles, thereby reducing the risk of a breakdown occurring due to the load being concentrated in some vehicles. As a result, unexpected maintenance can be avoided, and an increase in the time that cannot be used to provide services can be suppressed. Therefore, a vehicle management system that suppresses an increase in the time that cannot be used to provide services can be provided.

[0076] Furthermore, the management server 7 can accurately calculate the accumulated load amount of each of the multiple vehicles using the driving histories of the multiple vehicles.

[0077] Modifications will be described below. In the above-described embodiment, an example has been described in which a transportation service is provided in which each of a plurality of vehicles travels along a predetermined driving route and travels to each boarding and disembarking point on the driving route according to predetermined departure and arrival times. However, for example, in a case in which a transportation service is provided in which one of a plurality of vehicles moves from a waiting location to a location where a user is picked up, then moves to a location specified by the user, and returns to the waiting location after the user disembarks, it is also possible to assign a vehicle with a low accumulation volume to a high-load driving route and a vehicle with a high accumulation volume to a low-load driving route as described above.

[0078] Furthermore, in the above-described embodiment, the vehicles set as dispatch vehicles are described as excluding vehicles that require maintenance, but, for example, the vehicles may be set further excluding vehicles currently patrolling other driving routes, or, if dispatch vehicles are set including vehicles currently patrolling, and a vehicle currently patrolling another driving route is selected as the dispatch vehicle, a new dispatch vehicle may be set for the other driving route based on the load of the other driving route and the accumulated load of the other vehicles.

[0079] Furthermore, in the above embodiment, the position detection device of the vehicle 1 is provided in the ADK 2 as an example, but the position detection device may be provided in the VP 3.

[0080] Furthermore, in the above embodiment, a case where a plurality of travel routes are classified into two levels, a high-load travel route and a low-load travel route, has been described as an example, but the routes may be classified according to three or more levels of load. In this case, if it is determined that the travel route is neither a high-load nor a low-load travel route, a dispatch vehicle may be set regardless of the accumulation amount.

[0081] The above-described modified examples may be implemented in whole or in part in appropriate combination. The embodiments disclosed herein should be considered to be illustrative and not restrictive in all respects. The scope of the present invention is defined by the claims, not the above description, and is intended to include all modifications within the meaning and scope of the claims. [Explanation of symbols]

[0082] 1,4 vehicle, 2,5 ADK, 3,6 VP, 7 management server, 8 control device, 9 storage device, 10 communication device, 11 communication bus, 21 computer, 22 recognition sensor, 23 attitude sensor, 25 HMI, 31 VCIB, 32 base vehicle, 100 vehicle management system, 321 central ECU, 322 brake system, 323 steering system, 324 powertrain system, 324A EPB system, 324B P-lock system, 324C propulsion system, 327 DCM.

Claims

1. A plurality of vehicles used in providing transportation services; A server capable of communicating with the plurality of vehicles, The plurality of vehicles are all autonomous vehicles, The transportation service includes a transportation service for transporting a user by autonomous driving on a plurality of driving routes using at least any one of the plurality of vehicles, The server, When at least any one of the first vehicles among the plurality of vehicles for which the transportation service is being provided is in a state requiring maintenance, identifying a destination travel route among the plurality of travel routes using operation information of the first vehicle, and calculating an accumulated load amount in each of the plurality of vehicles using the travel history of each of the plurality of vehicles; When a load degree indicating a degree of load acting on the vehicle when traveling along the travel route of the vehicle allocation destination is smaller than the load degree of other travel routes, among the plurality of vehicles, a vehicle with a large accumulated amount is allocated as a vehicle to be allocated to the travel route of the vehicle allocation destination, preferentially over a vehicle with a small accumulated amount; When a vehicle for which the transportation service is being provided on the other travel route is assigned as the dispatch vehicle, a new dispatch vehicle for the other travel route is assigned using the load level of the other travel route and the accumulation amount; A vehicle management system in which the driving history includes a total number of passengers.

2. The vehicle management system described in Claim 1, wherein the server determines that the first vehicle is in a state where maintenance is required when the period of use or amount of wear of a target part in the first vehicle exceeds a threshold value.

Citation Information

Patent Citations

  • Method and system for renting vehicle

    JP2002245376A

  • Tire information management system

    JP2007091202A

  • Device and method for displaying vehicle travel, computer-readable recording medium with program for computer to execute the same recorded therein, vehicular control device, and vehicular control method

    JP2009063555A

  • Maintenance method of construction machine and maintenance system

    JP2012160085A

  • Vehicle system

    JP2018062223A