Vehicle management system

Abstract

To suppress an increase in a possibility of fault occurrence in a vehicle used for providing services.SOLUTION: A management server executes processing including steps of: if an execution condition is established (YES in S100), acquiring operation information (S102); setting a travel route (S104); if there is a vehicle which is set to a forwarding route (YES in S106), calculating an accumulation amount of loads (S108); if there is a vehicle in a high accumulation state (YES in S110), setting a cancellation content of a travel restriction in accordance with the accumulation amount of loads of the vehicle in the forwarding route (S112); if there is no vehicle in the high accumulation state (NO in S110), setting a cancellation of the travel restriction of the vehicle in the forwarding route (S114); and transmitting travel schedule information (S116).SELECTED DRAWING: Figure 3

Description

Technical Field

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

Background Art

[0002] When an autonomous vehicle is used to provide transportation services or the like, it is possible to shorten the travel time of the vehicle by changing the acceleration and deceleration control according to whether or not a service user is on board.

[0003] For example, Japanese Unexamined Patent Application Publication No. 2019-151177 (Patent Document 1) discloses a technique for rapidly accelerating and decelerating when there is no passenger in the host vehicle to shorten the travel time.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] However, when rapidly accelerating and decelerating when the user is not on board, the load on the vehicle increases, the period until the next maintenance becomes shorter, etc., increasing the time when it cannot be used for service provision or increasing the possibility of failure.

[0006] The present disclosure has been made to solve the above-described problems, and an object thereof is to provide a vehicle management system that suppresses an increase in the possibility of failure of a vehicle used for service provision.

Means for Solving the Problems

[0007] A vehicle management system relating to a certain aspect of this disclosure comprises an autonomously driven vehicle used to provide transportation services and a server capable of communicating with the vehicle. When a user of the transportation service is on board, the server requests predetermined driving restrictions from the vehicle during autonomous driving. When no user is on board, the server requests the lifting of the driving restrictions. The server calculates the accumulated load acting on the vehicle and uses the calculated accumulated load to set the content of the lifting of driving restrictions requested when no user is on board.

[0008] In this way, the driving restrictions can be released in accordance with the accumulated load. Therefore, it is possible to suppress a further increase in the accumulated load and reduce the likelihood of a malfunction occurring.

[0009] In one embodiment, the server configures the release of the driving restriction so that when the amount of stored data is high, the driving restriction is maintained more than when the amount of stored data is low.

[0010] In this way, the release settings are configured so that the driving restriction is maintained when the load accumulation is high, thereby further suppressing the increase in load accumulation. This helps to reduce the likelihood of malfunctions occurring.

[0011] Furthermore, in one embodiment, the server does not request the lifting of the driving restriction even if the user is not in the vehicle, when the vehicle's storage capacity reaches a predetermined state of high levels.

[0012] This approach further suppresses the increase in the accumulated load, thereby reducing the likelihood of failure.

[0013] In one further embodiment, the server requests the lifting of the driving restriction on a vehicle traveling along a predetermined route, including a location where vehicle maintenance is performed, if there is no user on board.

[0014] This allows vehicles to be quickly moved to the maintenance location, thus minimizing the increase in downtime that can be used to provide services.

[0015] In one further embodiment, the driving restriction includes at least one of the following: a restriction on the vehicle's driving force, a restriction on the vehicle's braking force, and a restriction on the vehicle's steering force.

[0016] In this way, while passengers are on board, any kind of driving restriction will be implemented, which will help to prevent a deterioration in the ride comfort of the vehicle.

[0017] In one further embodiment, the server calculates the amount of data to be stored using at least one of the following: the vehicle's mileage, the vehicle's operating time, the number of passengers in the vehicle, the mileage until the next maintenance is performed, and the operating time until the next maintenance is performed.

[0018] In this way, the accumulated load on the vehicle can be calculated with high accuracy using the vehicle's driving history and maintenance history. [Effects of the Invention]

[0019] According to this disclosure, it is possible to provide a vehicle management system that suppresses the increased likelihood of vehicle breakdowns occurring in vehicles used to provide services. [Brief explanation of the drawing]

[0020] [Figure 1] This diagram provides a schematic overview of the overall configuration of the vehicle management system. [Figure 2] This diagram provides a more detailed example of the ADK and VP configuration. [Figure 3] This flowchart shows an example of the processes performed on the management server. [Figure 4] This diagram illustrates the normal driving route and the deadheading route. [Modes for carrying out the invention]

[0021] 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 denoted by the same reference numerals and their description will not be repeated.

[0022] FIG. 1 is a diagram schematically showing the 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. Hereinafter, for convenience of explanation, a case where specific vehicles 1 and 4 are managed by the vehicle management system 100 will be described as an example. The vehicle management system 100 includes vehicles 1 and 4 and a management server 7. Vehicle 1 includes an autonomous driving kit (ADK) 2 and a vehicle platform (VP) 3. Similarly, vehicle 4 includes an ADK 5 and a VP 6.

[0023] The users of vehicles 1 and 4 may be, for example, operators (such as bus operators, taxi operators, car rental operators, car-sharing operators, or ride-sharing service operators) who provide transportation services by autonomous driving using vehicles 1 and 4. In the present embodiment, it is assumed that the users of vehicles 1 and 4 are, for example, operators who own a plurality of vehicles and provide personnel transportation services. The personnel transportation service includes, for example, driving a vehicle on a plurality of driving routes (such as a driving route passing through an urban area or a driving route passing through a mountainous area), moving so as to arrive at a predetermined boarding and alighting point provided on the driving route at a predetermined set time, allowing personnel to board and alight at the boarding and alighting point, and collecting usage fees. In the present embodiment, the plurality of driving routes include, for convenience of explanation, a return route including the location of a maintenance factory and a normal route that circulates through a plurality of predetermined boarding and alighting points without passing through the maintenance factory.

[0024] The following describes an example of a configuration for autonomous driving, using Vehicle 1 as an example. The ADK2 installed in Vehicle 1 is configured to be attachable to and detachable from the VP3 of Vehicle 1. The ADK2 is installed in a predetermined location, such as the rooftop of the VP3.

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

[0026] VP3 performs driving control in automatic driving mode according to control requests from ADK2. If ADK2 is removed from VP3, VP3 is configured to perform driving control in manual mode (driving control according to driver operation).

[0027] VP3 transmits various information (such as operation information, which will be described later) to the management server 7 within the vehicle management system 100.

[0028] 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.

[0029] The management server 7 is a server operated by a company that performs maintenance and management on multiple vehicles, including vehicle 1. This company could be, for example, the manufacturer of VP3 or the manufacturer of ADK2. Furthermore, the management server 7 may be configured to include a server operated by the VP3 manufacturer and a server operating ADK2. In the following description, the case where the management server 7 is configured as a single server will be described as an example.

[0030] The management server 7 is configured to receive operation information from each of the vehicles 1 and 4. The operation information for vehicles 1 and 4 includes information that can identify vehicles 1 and 4, such as the number and serial number written on the license plate (hereinafter referred to as vehicle ID), information about the driving history (hereinafter referred to as history information), and information about the maintenance of 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 that can identify 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.

[0031] In this disclosure, "maintenance" of a vehicle means all actions taken to keep the vehicle in a normal state or to restore the vehicle from an abnormal state to a normal state. Maintenance may include inspection, repair, adjustment, or replacement of any part installed on the vehicle. Maintenance information may include, for example, information for diagnosing whether maintenance is required, such as the mileage driven since the maintenance of the part being maintained or the mileage driven until the next maintenance of the part, or it may include information indicating the result of the diagnosis of whether maintenance is required.

[0032] Figure 2 shows a more detailed example of the configuration of ADK2 and VP3. ADK2 includes a computer 21, a recognition sensor 22, a posture sensor 23, and an HMI (Human Machine Interface) 25.

[0033] VP3 includes a Vehicle Control Interface Box (VCIB) 31 and a base vehicle 32. The base vehicle 32 includes a Central ECU (Electronic Control Unit) 321, a brake system 322, a steering system 323, a powertrain system 324, and a DCM (Digital Communication Module) 327.

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

[0035] Computer 21 acquires data about the environment of vehicle 1 using recognition sensors 22 during autonomous driving of vehicle 1. Computer 21 also acquires data about the attitude, behavior, and position of vehicle 1 using attitude sensors 23 during autonomous driving of vehicle 1. Furthermore, computer 21 is communicatively connected to VCIB 31. Computer 21 acquires vehicle status from VP3 via VCIB 31 and sets the next action of vehicle 1 (accelerate, decelerate, turn, etc.). Computer 21 outputs various commands to VP3 via VCIB 31 to realize the next action.

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

[0037] 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, an IMU (Inertial Measurement Unit) and a position detection device such as a GPS (Global Positioning System) (neither of which are shown). The IMU detects, for example, the acceleration of the vehicle 1 in the longitudinal, lateral, and vertical directions, and the angular velocity of the vehicle 1 in the roll, pitch, and yaw directions. The GPS determines the position of the vehicle 1 using information received from multiple GPS satellites orbiting the Earth.

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

[0039] VCIB31 is connected to ADK2 via CAN (Controller Area Network) or the like for communication. VCIB31 receives various control requests from ADK2 and outputs vehicle status to ADK2 by executing predetermined APIs defined for each signal. When VCIB31 receives a control request from ADK2, it outputs a control command corresponding to that request to the system corresponding to that control command (for example, the brake system 322, the steering system 323, and the powertrain system 324). VCIB31 also acquires various information regarding the vehicle status (the status of the base vehicle 32) and outputs the acquired information to ADK2.

[0040] The central ECU 321 transmits various information indicating the vehicle status to the management server 7 via the DCM 327, and also transmits various requests to the management server 7. The central ECU 321 also receives commands or notifications from the management server 7 via the DCM 327. Furthermore, the central ECU 321 uses the vehicle status acquired from each system of the VP3 to diagnose whether or not maintenance is required in the VP3, or it receives the diagnostic results of self-diagnoses performed by each system of the VP3 and uses the received diagnostic results to diagnose whether or not maintenance is required in the VP3.

[0041] In this embodiment, the central ECU 321 is described as the entity that executes a diagnostic process to determine whether or not the vehicle 1 is in a state requiring maintenance. However, in addition to this function, it may also have functions such as relaying communication between various ECUs included in each system (gateway function).

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

[0043] The EPB system 324A controls an EPB (not shown) provided on at least one of the multiple wheels in accordance with a control request transmitted from ADK2 via VCIB31. The P-lock system 324B controls a P-lock device (not shown) provided on the traction transmission in accordance with a control request transmitted from ADK2 via VCIB31. The propulsion system 324C controls the driving force from a drive source (motor generator, engine, etc., not shown) in accordance with a control request from ADK2.

[0044] The DCM327 is an in-vehicle communication module. The DCM327 is configured to enable bidirectional data communication between the central ECU321 and the management server 7.

[0045] Furthermore, the ADK5 of vehicle 4 has the same configuration as the ADK2 of vehicle 1. In addition, the VP6 of vehicle 4 has the same configuration as the VP3 of vehicle 1. Therefore, a detailed explanation of these will not be repeated.

[0046] 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 that they can communicate with one another.

[0047] The control device 8, although not shown in the diagram, is composed of a CPU (Central Processing Unit), memory (ROM (Read Only Memory) and RAM (Random Access Memory), etc.), and input / output ports for inputting and outputting various signals. The various controls performed by the control device 8 are executed by software processing, that is, by the CPU reading a program stored in memory. The various controls performed 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 performed by the control device 8 are not limited to software processing, but may also be processed by dedicated hardware (electronic circuits).

[0048] The storage device 9 stores operational information received from multiple vehicles 1 and 4 that are configured to communicate with the management server 7.

[0049] The communication device 10 enables bidirectional communication between vehicles 1 and 4 and a communication network (not shown). The management server 7 uses the communication device 10 to enable communication with multiple vehicles, including vehicles 1 and 4, via base stations (not shown) and the like that installed in the communication network.

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

[0051] In each of the vehicles 1 and 4, autonomous driving is performed according to the driving plan information, and fare information is presented to the user using a display device, and payment processing is performed 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 route by picking up and dropping off users at designated boarding and alighting points.

[0052] When multiple vehicles, including vehicles 1 and 4, are used to provide personnel transport services, vehicles 1 and 4 will be regularly maintained.

[0053] For example, the need for maintenance on vehicles 1 and 4 is determined by a diagnosis performed by either vehicle 1 or 4, or the management server 7, to determine whether each of vehicles 1 and 4 is in a condition requiring maintenance.

[0054] When diagnosing whether or not maintenance is required for vehicle 1, the following cases are included: when the service life of the part to be diagnosed exceeds a threshold since the last replacement; when the amount of wear of the part to be diagnosed exceeds a threshold since the last replacement; when an error code is output for the part to be diagnosed; or when the output value of the part to be diagnosed is abnormal.

[0055] For example, if the usage period of various oils used in the engine, motor generator, etc., since the last replacement exceeds a threshold set according to the type of oil, it is diagnosed that maintenance such as oil change is required. Alternatively, if the amount of wear of the brake pads included in the braking system exceeds a threshold, it is diagnosed that maintenance such as brake pad replacement is required. 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 that maintenance such as inspection is required. Alternatively, if the output values ​​of various sensors are output beyond the normal range, it is diagnosed that maintenance such as sensor replacement or adjustment is required.

[0056] These determinations are made using the diagnostic results of a self-diagnostic process performed in vehicle 1. The self-diagnostic process is performed, for example, in the computer 21 of ADK2 or the central ECU 321 of VP3. Alternatively, the management server 7 may manage information about the maintenance history of vehicles 1 and 4, perform a diagnostic process using the managed information, and use the diagnostic results to determine whether or not maintenance is required.

[0057] In vehicles 1 and 4 as described above, when the vehicles are used to provide transportation services, etc., it is possible to shorten travel time by changing the acceleration and deceleration control during autonomous driving depending on whether or not there are service users on board.

[0058] The management server 7, for example, requests predetermined driving restrictions from the autonomously driven vehicles 1 and 4 when a user of the transportation service is on board. These predetermined driving restrictions include, for example, at least one of the following: a limit on the vehicle's driving force, a limit on the vehicle's braking force, and a limit on the vehicle's steering force.

[0059] Furthermore, the management server 7 receives information from each of the autonomously operating vehicles 1 and 4 indicating whether or not a user is inside. The management server 7 may receive, for example, image data of the interior of each of the vehicles 1 and 4, or it may receive data indicating the detection result from a seating sensor (not shown). The management server 7 may, for example, perform image processing on the image data of the interior to determine whether or not a user is inside. Alternatively, the management server 7 may, for example, use data indicating the detection result from a seating sensor to determine whether or not a user is inside.

[0060] For example, if a user is in the vehicle, the management server 7 sets a predetermined upper limit on the magnitude of change in at least one of the driving force, braking force, and steering force of the vehicles 1 and 4, and requests the vehicles to restrict their movement.

[0061] The management server 7 transmits driving plan information, including information about the request for the driving restriction, to vehicles 1 and 4. When vehicles 1 and 4 receive a request for a driving restriction, if a passenger is on board, they control the corresponding forces among the driving force, braking force, and steering force so that the magnitude of change in at least one of these forces does not exceed the upper limit, thereby suppressing sudden changes in the behavior of each vehicle. This prevents deterioration of the ride comfort of vehicles 1 and 4.

[0062] On the other hand, the management server 7 requests the lifting of the driving restrictions when the user is not in the vehicle (for example, when driving on a route to a maintenance factory).

[0063] The management server 7 transmits travel plan information, including information about the request to lift the travel restriction, to vehicles 1 and 4. When vehicles 1 and 4 receive the request to lift the travel restriction, if there is no passenger in the vehicle, they release the upper limit set for at least one of the driving force, braking force, and operating force (for example, by returning the upper limit to its initial value). By releasing the travel restriction, vehicles 1 and 4 can be quickly moved to their destination (for example, a repair shop).

[0064] However, if the driving restrictions are lifted when there are no passengers on board, allowing for sudden acceleration and deceleration, the load on the vehicle increases, potentially shortening the time between maintenance, increasing the amount of time the vehicle is unavailable for service, and raising the likelihood of breakdowns.

[0065] Therefore, in this embodiment, the management server 7 calculates the accumulated load acting on each of the vehicles 1 and 4, and uses the calculated accumulated load to set the content of the release of the driving restriction requested when no user is on board. More specifically, when the accumulated load is high, the management server 7 sets the content of the release of the driving restriction so that the driving restriction is maintained more than when the accumulated load is low.

[0066] In this way, the driving restrictions can be released in accordance with the amount of load accumulated on the vehicle. In particular, since the release settings are configured so that the driving restrictions are maintained when the amount of load accumulated is high, the increase in the amount of load accumulated can be further suppressed. This helps to reduce the likelihood of a breakdown occurring.

[0067] The following describes an example of the processes performed by the management server 7, with reference to Figure 3. Figure 3 is a flowchart showing an example of the processes performed by the management server 7. The series of processes shown in this flowchart are repeatedly executed by the management server 7 at predetermined intervals.

[0068] In step 100 (hereinafter referred to as S), the management server 7 (more specifically, the control device 8 of the management server 7) determines whether the execution conditions for generating travel plan information are met. The execution conditions may include, for example, a predetermined amount of time having elapsed since the previous generation of travel plan information, a time outside of the service provision period, a predetermined amount of time having elapsed since the previous setting of the travel route, a condition in which maintenance is required for one of the vehicles, including vehicles 1 and 4, or a condition in which such a condition is expected. If it is determined that the execution conditions are met (YES in S100), the process moves to S102.

[0069] In S102, the management server 7 acquires operational information. The management server 7 acquires operational information from each of the multiple vehicles, including vehicles 1 and 4. For example, when the management server 7 requests operational information from vehicle 1 via 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 operational information from, for example, the computer 21 of ADK2 or the memory of the central ECU 321, and transmits the acquired operational information to the management server 7 via the DCM 32.

[0070] In S104, the management server 7 sets the individual driving routes for multiple vehicles. For example, if the operation information of any of the multiple vehicles includes information indicating that maintenance is required, the management server 7 sets the driving route of that vehicle as a deadheading route. The management server 7 sets the driving routes of all vehicles except those set as deadheading routes as normal driving routes. The management server 7 also sets a flag associated with the vehicle on which the deadheading route has been set to the ON state and stores the set flag in the storage device 9, associating it with the vehicle ID.

[0071] In S106, the management server 7 determines whether or not there is a vehicle among the multiple vehicles for which a return route has been set. If there is a vehicle among the multiple vehicles with a flag set to ON, the management server 7 determines that there is a vehicle for which a return route has been set. If it is determined that there is a vehicle for which a return route has been set (YES in S106), the process moves to S108.

[0072] In S108, the management server 7 calculates the accumulated load for each vehicle for which a transfer route has been set. The management server 7 calculates the accumulated load using at least one of several pieces of information included in the history information, such as mileage, travel time, vehicle weight, total number of passengers, mileage until the next maintenance is performed, and travel time until the next maintenance is performed. In this way, the accumulated load can be calculated with high accuracy.

[0073] The management server 7 calculates the accumulation amount in two stages, including, for example, a high accumulation state and a low accumulation state. The management server 7 may, for example, set the vehicle to a high accumulation state when the mileage (or mileage time or total number of passengers) is above a threshold, and to a low accumulation state when the mileage is shorter (less than) the threshold. In this case, the management server 7 may change the threshold according to the vehicle weight (for example, the threshold may be lowered as the vehicle weight increases). Alternatively, the management server 7 may set the vehicle to a high accumulation state when the mileage (or mileage time) until the next maintenance is performed is below a threshold, and to a low accumulation state when the mileage is longer than the threshold.

[0074] Alternatively, the management server 7 may calculate the accumulated amount in three or more stages by setting multiple thresholds, for example. Alternatively, the management server 7 may calculate the accumulated amount expressed as a percentage, for example. The management server 7 may calculate a base value of the accumulated amount using at least one piece of information from multiple driving history records, set a correction coefficient using the other driving history records, and then calculate the accumulated amount expressed as a percentage by correcting the base value using the correction coefficient. The management server 7 may store the calculated accumulated amount in the storage device 9, associating it with the vehicle ID of the corresponding vehicle. The subsequent processing is then moved to S110.

[0075] In S110, the management server 7 determines whether there are any vehicles in a high-accumulation state among the vehicles for which a transfer route has been set. If it is determined that there are vehicles in a high-accumulation state (YES in S110), the process moves to S112.

[0076] In S112, the management server 7 sets the content for releasing the driving restrictions according to the amount of load accumulated on the vehicles on the transport route. For example, the management server 7 releases the driving restrictions on vehicles that are determined to be in a low load state among the vehicles on the transport route. On the other hand, for example, the management server 7 sets the content for releasing the driving restrictions to release at least one of the multiple restriction items that make up the driving restrictions on vehicles that are determined to be in a high load state among the vehicles on the transport route. The multiple restriction items include, for example, restriction items for driving force, restriction items for braking force, and restriction items for steering force. The upper limit values ​​mentioned above are one example of restriction items.

[0077] For example, the management server 7 may set the release settings so that, if the number of steering maneuvers on the delivery route to the maintenance factory exceeds a predetermined angle exceeds a threshold, the restrictions on steering force are not released, but only the restrictions on driving force and braking force are released.

[0078] For example, the management server 7 may set the release settings so that if the number of steering maneuvers on the delivery route is less than a threshold, only the limit item for steering force is released, while the limit items for driving force and braking force are not released.

[0079] Alternatively, the management server 7 may set the release settings so that, if the distance traveled to the maintenance factory on the delivery route exceeds a threshold, only the steering force restriction is released, while the driving force and braking force restrictions remain in place.

[0080] Alternatively, the management server 7 may not release the limit item for driving force if the high accumulation state is due to a load on the drive system, it may not release the limit item for braking force if it is due to a load on the braking system, and it may not release the limit item for steering force if it is due to a load on the control system.

[0081] Furthermore, the management server 7 may choose not to remove any of the restrictions for vehicles that are determined to be in a high-accumulation state. The process then proceeds to S116. On the other hand, if it is determined that there are no vehicles in a high-accumulation state (NO in S110), the process proceeds to S114.

[0082] In S114, the management server 7 sets the removal of the driving restrictions for the vehicle on the transport route. Specifically, the management server 7 sets the removal to remove the restrictions on driving force, braking force, and steering force. The process then moves to S116.

[0083] In S116, the management server 7 transmits travel plan information to each vehicle. For example, the management server 7 sets departure and arrival times at boarding and alighting points along the travel routes of vehicles set for the normal travel route and the deadheading route, and for vehicles traveling on the deadheading route, it also sets information about the lifting of travel restrictions. The management server 7 transmits the set information as travel plan information to each of the multiple vehicles. If the execution conditions are not met (NO in S100), this process is terminated. Furthermore, if it is determined that there are no vehicles set for the deadheading route (NO in S106), the process moves to S116.

[0084] An example of the operation of the management server 7 based on the structure and flowchart described above will be explained with reference to Figure 4.

[0085] Figure 4 illustrates the normal driving route and the deadheading route. As shown in Figure 4, the deadheading route includes the location of the maintenance factory. (A) to (F) in Figure 4 indicate boarding and alighting points.

[0086] For example, consider a scenario where a self-diagnostic process in one of several vehicles determines that maintenance is required.

[0087] At this point, the management server 7 determines that the execution condition is met if a predetermined amount of time has elapsed since the previous setting of the driving plan information (YES in S100).

[0088] Therefore, operational information is acquired from each of the multiple vehicles (S102). The travel route is set using the acquired operational information (S104). At this time, for vehicle 1, the deadheading route is set as the travel route, and the corresponding flag is set to the ON state.

[0089] Since the flag corresponding to vehicle 1 among multiple vehicles is set to the ON state, it is determined that there is a vehicle on the transfer route (YES in S106). Therefore, the accumulated load of vehicle 1 on the transfer route is calculated (S108), and if it is determined that vehicle 1 on the transfer route is in a high load state (YES in S110), the content of the release of the driving restriction is set according to the accumulated load of vehicle 1 on the transfer route (S112), and driving plan information including the set release content is transmitted to vehicle 1 (S116). In other words, the release content is set to release at least one of the multiple restriction items.

[0090] As shown in Figure 4, vehicles assigned to routes other than the deadhead route (normal routes) will move between each boarding / alighting point in the order of (B), (C), (D), (E), and (F) in Figure 4, while the travel restrictions are in place, and then return to (B) to complete the loop.

[0091] On the other hand, vehicle 1, for which a return route has been set, will move from the boarding / alighting point at (F) in Figure 4 to the boarding / alighting point set at the maintenance factory location at (A). The return route includes at least the travel path from (F) to (A) in Figure 4. The return route may also include the travel path from (A) to (B). The starting point of the return route may be any of (B) to (F) in Figure 4. When vehicle 1 travels along a return route that includes (A) in Figure 4, if it is in a high-load state, some or all of the driving restrictions will not be lifted and vehicle 1 will continue to travel. Therefore, even if there are no passengers on the return route, the driving restrictions will prevent further load from being placed on the high-load state components.

[0092] If it is determined that vehicle 1, which has a set transfer route, is in a low-load state (NO in S110), the travel restrictions for vehicle 1 on the transfer route are lifted (S114), and travel plan information is transmitted to vehicle 1 (S116). As a result, the travel restrictions are lifted, allowing the vehicle to move quickly to the maintenance factory location or quickly from the maintenance factory to the boarding / alighting point in Figure 4 (B).

[0093] As described above, the vehicle management system according to this embodiment can release driving restrictions in accordance with the amount of load accumulated on the vehicle. In particular, since the release settings are configured so that driving restrictions are maintained when the amount of load accumulated is high, it is possible to further suppress the increase in the amount of load accumulated. This makes it possible to suppress an increase in the likelihood of a breakdown occurring. This provides a vehicle management system that suppresses an increase in the likelihood of a breakdown occurring in vehicles used to provide services.

[0094] The following describes variations. In the above-described embodiment, the case where no users are on board was explained as an example for the deadheading route, but users may also be on board the vehicle even on the deadheading route. In this case, the management server 7 may request the release of the driving restriction according to the accumulated load when no users are on board. This allows unmanned vehicles to be quickly moved to the maintenance site, and if the vehicle is occupied, it can suppress deterioration of the ride comfort. Therefore, it is possible to suppress an increase in the time that cannot be used to provide the service. In addition, in this case, if the management server 7 determines that the load is high, it may not request the release of the driving restriction regardless of whether a user is on board or not. This can suppress a further increase in the accumulated load, and thus suppress an increased risk of failure.

[0095] Furthermore, in the above-described embodiment, the vehicle 1 position detection device was explained as being provided in ADK2 as an example, but the position detection device may also be provided in VP3.

[0096] Furthermore, in the above-described embodiment, the travel restriction was released in accordance with the amount of load accumulated on the transport route, and the travel restriction was maintained on the normal route. However, for example, the upper limit of the travel speed may be changed for the transport route and the normal route.

[0097] Furthermore, in the above-described embodiment, the travel restriction was explained to be released according to the amount of load accumulated on the transport route. However, for example, the amount of load accumulated may be reset to an initial value (for example, zero) after maintenance. In this case, even if a high load accumulation state is determined before maintenance, a low load accumulation state will be achieved after maintenance. As a result, the travel restriction will be released on the subsequent transport route, and the travel time on the transport route can be shortened.

[0098] Furthermore, the above-mentioned modifications may be implemented by combining all or part of them as appropriate. The embodiments disclosed herein should be considered in all respects to be illustrative and not restrictive. The scope of the present invention is indicated by the claims rather than by the foregoing description, and all modifications within the meaning and scope equivalent to the claims are intended to be included. [Explanation of Symbols]

[0099] 1,4 Vehicle, 2,5 ADK, 3,6 VP, 7 Management Server, 8 Control Unit, 9 Storage Unit, 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. Autonomous vehicles used to provide transportation services, The vehicle is equipped with a server capable of communicating with it, The aforementioned server, If a user of the aforementioned transportation service is on board, the vehicle will be required to adhere to predetermined driving restrictions during the automated driving process. If the aforementioned user is not currently on board, request the lifting of the aforementioned driving restriction. A vehicle management system that calculates the accumulated load acting on the vehicle and uses the calculated accumulated load to set the content of the lifting of the driving restriction requested when the user is not on board.

2. The vehicle management system according to claim 1, wherein the server sets the content of releasing the driving restriction so that the driving restriction is maintained more when the amount of storage is high than when the amount of storage is low.

3. The vehicle management system according to claim 2, wherein the server does not request the lifting of the driving restriction even if the user is not in the vehicle, when the vehicle reaches a predetermined state where the amount of stored data is high.

4. The vehicle management system according to claim 1, wherein the server requests the lifting of the driving restriction on a vehicle traveling along a predetermined route that includes a location where the vehicle is being serviced, when the user is not in the vehicle.

5. The vehicle management system according to claim 1, wherein the driving restriction includes at least one of the following: a restriction on the driving force of the vehicle, a restriction on the braking force of the vehicle, and a restriction on the steering force of the vehicle.

6. The vehicle management system according to any one of claims 1 to 5, wherein the server calculates the accumulated amount using at least one of the following: the vehicle's mileage, the vehicle's operating time, the number of passengers in the vehicle, the mileage until the next maintenance is performed, and the operating time until the next maintenance is performed.

Images