Servers and operating systems

Abstract

To facilitate improvement of operation efficiency while suppressing an increase of an operation resource amount.SOLUTION: A server for managing a plurality of mobile bodies generates an operation schedule of each one of the mobile bodies, and instructs an operation following the generated operation schedule to each one of the mobile bodies. The operation schedule includes: a standby spot for waiting after the mobile body performs a requested task; and a standby period at the standby spot. The server performs: determining whether competition to cause the plurality of mobile bodies to wait at the same standby spot at the same timing is to occur when the operation temporarily following the operation schedule is instructed to each one of the mobile bodies before instructing the operation to each one of the mobile bodies (S12); and changing at least one of the operation schedules of the competing mobile bodies so as to avoid the competition when it is determined that the competition is to occur (S14).SELECTED DRAWING: Figure 6

Description

Technical Field

[0001] This disclosure relates to a server and an operation system.

Background Art

[0002] Japanese Patent Application Laid-Open No. 2013-186541 (Patent Document 1) discloses an operation system for demand vehicles that creates an operation plan for shared vehicles based on requests regarding boarding and alighting of users and runs the shared vehicles according to this operation plan.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] In the operation system described in Patent Document 1 above, for example, regarding a demand bus, the boarding and alighting points desired by the user are obtained with respect to the operation plan and the vacancy status presented by the information presentation means, and the operation plan is changed based on this boarding and alighting point. As a result, it becomes possible to reduce the remaining seats of the demand bus as much as possible and improve the operation efficiency of the demand bus.

[0005] In the technology described in Patent Document 1 above, the operation efficiency is improved by increasing the business section in the operation plan or increasing the task amount in the business section. In Patent Document 1 above, the transportation of people corresponds to the task, and the transportation volume (that is, the number of people) corresponds to the task amount. The business section corresponds to the section in the operation plan in which the moving body (for example, the bus described in Patent Document 1) is operating for the task. The business section includes the section in which the moving body travels toward the task start point (for example, the boarding point) in order to execute the requested task and the section from the task start point to the task end point.

[0006] However, Patent Document 1 makes no mention of the relationship between operational efficiency and operational resources. Operational efficiency can be expressed as the value obtained by dividing the amount of tasks by the amount of operational resources (= amount of tasks / amount of operational resources). Operational resources are the resources necessary for operation. Examples of operational resources include the moving object, the energy required to operate the moving object, and energy replenishment points. Since operational efficiency decreases as the amount of operational resources increases, the technology described in Patent Document 1 does not necessarily guarantee sufficient operational efficiency. There is room for improvement in the technology described in Patent Document 1.

[0007] This disclosure is made to solve the above-mentioned problems, and its purpose is to make it easier to improve operational efficiency while suppressing an increase in the amount of operational resources. [Means for solving the problem]

[0008] In accordance with the form relating to the first aspect of this disclosure, the following servers are provided:

[0009] (Section 1) The server is configured to manage multiple mobile units. The server is configured to generate a route plan for each of the multiple mobile units and to instruct each of the multiple mobile units to operate according to the generated route plan. The route plan includes waiting points where a mobile unit will wait after performing a requested task, and the waiting period at those waiting points. Before instructing each of the multiple mobile units to operate, the server is configured to determine whether a conflict will occur if each of the multiple mobile units is instructed to operate according to the route plan, resulting in multiple mobile units waiting at the same waiting point at the same time. If a conflict is determined to occur, the server is configured to modify the route plan of at least one of the conflicting mobile units so as to avoid the conflict.

[0010] For a mobile vehicle to return to its starting point (the vehicle's storage location) after completing a task is inefficient from both a time and energy perspective. For a mobile vehicle to efficiently perform multiple tasks, it is desirable for it to wait at designated waiting points during non-operational sections of the operational plan (i.e., the section between completing one task and starting movement for the next task) and then proceed from the waiting point to the start of the next task. Waiting points are a type of operational resource. Increasing the number of waiting points makes it easier to increase the number of tasks. However, increasing the number of waiting points too much can lead to a greater negative impact on operational efficiency due to the increased waiting points than on the improvement in operational efficiency due to the increased task volume, ultimately worsening operational efficiency. In particular, increasing waiting points in areas with high land prices (e.g., urban areas) leads to a deterioration in operational efficiency from an economic perspective (= task volume / operational resource price). Therefore, to improve operational efficiency, it is desirable for multiple mobile vehicles to effectively utilize a limited number of waiting points.

[0011] However, in operating systems with limited available waiting points, conflicts are likely to occur at waiting points for multiple mobile units (i.e., multiple mobile units attempting to wait at the same waiting point at the same time). Even if the operating plans for each of the multiple mobile units are set to prevent conflicts, conflicts may still occur depending on the circumstances on the day the operating plans are executed. In this regard, the server determines whether a conflict will occur if each of the multiple mobile units is instructed to operate according to its operating plan, before issuing an instruction to each of the multiple mobile units to operate. If it is determined that a conflict will occur, the server modifies the operating plan of at least one of the conflicting mobile units to avoid the conflict. Therefore, the server can determine the operating plan to avoid conflicts, for example, depending on the circumstances of the day. This makes it possible for multiple mobile units to effectively utilize the limited waiting points. In this way, the server makes it easier to improve operating efficiency by coordinating the operation of multiple mobile units in non-operating sections. According to the server, it is easier to improve operating efficiency while suppressing an increase in the amount of operating resources.

[0012] The vehicle may be an electric vehicle (hereinafter also referred to as "xEV") that uses electricity as all or part of its power source, or an internal combustion engine vehicle. Examples of xEVs include BEV (battery electric vehicle), PHEV (plug-in hybrid vehicle), HEV (hybrid vehicle), and FCEV (fuel cell vehicle).

[0013] The server described in paragraph 1 above may have the configuration described in any one of paragraphs 2 to 7 below.

[0014] (Paragraph 2) The server described in Paragraph 1 is configured to change the waiting location for at least one of the conflicting mobile operation plans in order to avoid conflict.

[0015] (Clause 3) The server described in paragraph 1 or 2 further has the following characteristics: Each of the multiple mobile entities is an autonomous vehicle. The operation plan further includes a route and driving conditions for the autonomous vehicle to move to a waiting point after the completion of a task. The server is configured to delay the waiting start time of the operation plan of the mobile entity with the later waiting start time indicated by the waiting period at the waiting point among two competing mobile entities at the waiting point, by changing the driving conditions without changing the route, so as to avoid conflict.

[0016] (Article 4) The server described in any one of paragraphs 1 to 3 further has the following characteristics: Each of the multiple mobile entities is an autonomous vehicle. The operation plan further includes a route for the autonomous vehicle to move to a waiting point after the completion of the task. The server is configured to delay the waiting start time of the operation plan of the mobile entity with the later waiting start time indicated by the waiting period at the waiting point among two competing mobile entities at the waiting point, by changing the route to a detour, in order to avoid conflict.

[0017] (Clause 5) The server described in any one of paragraphs 1 to 4 further has the following characteristics: Each of the multiple mobile bodies is an autonomous vehicle. The operation plan further includes a route for the autonomous vehicle to move to a waiting point after the completion of the task. The server is configured to delay the waiting start time of the operation plan of the mobile body with the later waiting start time indicated by the waiting period at the waiting point among two competing mobile bodies at the waiting point, so as to modify the route to include a loop route of a predetermined number of laps, in order to avoid conflict.

[0018] According to any one of the configurations described in paragraphs 2 through 5 above, it becomes easier to appropriately avoid competition. Autonomous driving allows for more precise control of driving conditions compared to manual driving by a driver.

[0019] (Article 6) If any of the servers described in Articles 1 to 5 exist that can avoid conflicts, they shall be configured to select the most energy-efficient operation plan from among those multiple operation plans.

[0020] The above configuration makes it easier to improve operational efficiency while suppressing the increase in energy required to power the mobile system. The server may also modify the arbitration protocol for conflict avoidance to improve energy efficiency.

[0021] (Clause 7) If a server described in any one of paragraphs 1 to 6 determines that a conflict has occurred between a first mobile and a second mobile that are included in multiple mobiles, it is configured to modify the operation plan of at least one of the first mobile and the second mobile so that the first mobile and the second mobile are swapped at a waiting point.

[0022] According to the above configuration, the first moving body and the second moving body are swapped at the waiting point. By swapping the leading moving body and the trailing moving body at the waiting point (without leaving a waiting space), it is possible to prevent the waiting space from being occupied by another moving body (for example, a third moving body unrelated to the operation plan) after the leading moving body leaves the waiting point (waiting space), that is, to prevent the trailing moving body from becoming unusable. Regardless of whether the third moving body has the right to use the waiting space, it is possible that the third moving body will use the space if it is available.

[0023] According to the form according to the second aspect of the present disclosure, the following operation system is provided.

[0024] (Item 8) The operation system includes the server described in any one of Items 1 to 7 and a plurality of moving bodies that receive instructions from the server.

[0025] In the above operation system, it becomes easier to improve the operation efficiency while suppressing an increase in the amount of operation resources by the aforementioned server.

[0026] (Item 9) The operation system described in Item 8 further has the following characteristics. The plurality of moving bodies include a first moving body and a second moving body. The first moving body, which has been instructed to operate according to an operation plan that includes a plan for the first moving body and the second moving body to swap at the waiting point, departs from the waiting point when the second moving body approaches while waiting at the waiting point.

[0027] According to the above configuration, at the timing when the first moving body leaves the waiting point, it becomes easier for the second moving body to enter the waiting point.

Effect of the Invention

[0028] According to the present disclosure, it becomes easier to improve the operation efficiency while suppressing an increase in the amount of operation resources.

Brief Description of the Drawings

[0029] [Figure 1]This figure shows the schematic configuration of a vehicle according to an embodiment of the present disclosure. [Figure 2] This diagram shows the details of the vehicle control system shown in Figure 1. [Figure 3] This diagram illustrates the operation plan held by the server in the operation system according to the embodiment of the present disclosure. [Figure 4] This figure shows a task request screen used in the operation system according to the embodiment of this disclosure. [Figure 5] This flowchart shows the process related to task reservation in the operation method according to the embodiment of this disclosure. [Figure 6] This flowchart shows the process for executing a task in accordance with a reserved operation plan in an operation method according to an embodiment of the present disclosure. [Figure 7] This is a diagram illustrating the vehicle operation plan adopted in the operation system according to the embodiment of this disclosure. [Figure 8] This figure illustrates a method for avoiding conflicts that may be adopted in the operation method according to the embodiment of this disclosure when it is determined that a conflict will occur with respect to the operation plan shown in Figure 7. [Figure 9] This flowchart shows the process for executing a task in accordance with the operation plan requested on the day, according to an embodiment of the present disclosure. [Figure 10] This flowchart shows an example of automated driving control performed by a standby vehicle in an operating method according to an embodiment of the present disclosure. [Modes for carrying out the invention]

[0030] The embodiments of this disclosure will be described in detail below with reference to the drawings. In the drawings, the same or corresponding parts are denoted by the same reference numerals, and their descriptions will not be repeated.

[0031] Figure 1 is a diagram showing the schematic configuration of a vehicle according to an embodiment of the present disclosure. Referring to Figure 1, the vehicle 1 comprises an autonomous driving kit (hereinafter referred to as "ADK (Autonomous Driving Kit)") 200 and a vehicle platform (hereinafter referred to as "VP (Vehicle Platform)") 2.

[0032] VP2 includes the control system of the base vehicle 100 and a vehicle control interface box (hereinafter referred to as "VCIB (Vehicle Control Interface Box)") 111 located inside the base vehicle 100. The VCIB 111 may communicate with the ADK 200 via an in-vehicle network such as CAN (Controller Area Network). In Figure 1, the base vehicle 100 and the ADK 200 are shown in separate locations, but the ADK 200 is actually mounted on the base vehicle 100. In this embodiment, the ADK 200 is mounted on the rooftop of the base vehicle 100. However, the mounting position of the ADK 200 can be changed as appropriate.

[0033] The base vehicle 100 is, for example, a commercially available xEV (electric vehicle). In this embodiment, a BEV (battery electric vehicle) is used as the base vehicle 100. However, it is not limited to this, and the base vehicle 100 may be an xEV other than a BEV (HEV, PHEV, FCEV, etc.). The number of wheels on the base vehicle 100 is, for example, four wheels. However, it is not limited to this, and the number of wheels may be three or five or more.

[0034] The control system of the base vehicle 100 includes, in addition to the integrated control manager 115, various systems and sensors for controlling the base vehicle 100. The integrated control manager 115 integrates and controls various systems involved in the operation of the base vehicle 100 based on signals (sensor detection signals) from the various sensors included in the base vehicle 100.

[0035] In this embodiment, the integrated control manager 115 includes a control device 150. The control device 150 includes a processor 151, RAM (Random Access Memory) 152, and a storage device 153. For example, a CPU (Central Processing Unit) can be used as the processor 151. The RAM 152 functions as working memory for temporarily storing data processed by the processor 151. The storage device 153 is configured to store the stored information. The storage device 153 may include ROM (Read Only Memory) and rewritable non-volatile memory. The storage device 153 stores programs as well as information used by the programs (e.g., maps, mathematical formulas, and various parameters). In this embodiment, various vehicle controls (e.g., automatic driving control following instructions from ADK200) are performed by the processor 151 executing the programs stored in the storage device 153. However, these processes may be performed by dedicated hardware (electronic circuits) instead of software. The number of processors in the control device 150 is arbitrary, and a processor may be provided for each predetermined control.

[0036] The base vehicle 100 includes a brake system 121, a steering system 122, a powertrain system 123, an active safety system 125, and a body system 126. These systems are integrated and controlled by an integrated control manager 115. In this embodiment, each system is equipped with a computer, and each system's computer communicates with the integrated control manager 115 via an in-vehicle network (e.g., CAN). Hereafter, the computer equipped in each system will be referred to as an "ECU (Electronic Control Unit)".

[0037] The brake system 121 includes braking devices provided on each wheel of the base vehicle 100 and an ECU that controls the braking devices. In this embodiment, a hydraulic disc brake system is used as the braking device. The base vehicle 100 is equipped with wheel speed sensors 127A and 127B. Wheel speed sensor 127A is provided on the front wheels of the base vehicle 100 and detects the rotational speed of the front wheels. Wheel speed sensor 127B is provided on the rear wheels of the base vehicle 100 and detects the rotational speed of the rear wheels. The ECU of the brake system 121 outputs the rotational direction and rotational speed of each wheel detected by the wheel speed sensors 127A and 127B to the integrated control manager 115. The integrated control manager 115 may determine the driving speed (vehicle speed) of the vehicle 1 based on the detection signals from the wheel speed sensors 127A and 127B.

[0038] The steering system 122 includes a steering device of the base vehicle 100 and an ECU that controls the steering device. The steering device includes, for example, a rack and pinion type EPS (Electric Power Steering) in which the steering angle can be adjusted by an actuator. The base vehicle 100 is equipped with a pinion angle sensor 128. The pinion angle sensor 128 detects the rotation angle (pinion angle) of a pinion gear connected to the rotation axis of an actuator that constitutes the steering device. The ECU of the steering system 122 outputs the pinion angle detected by the pinion angle sensor 128 to the integrated control manager 115.

[0039] The powertrain system 123 includes an EPB (Electric Parking Brake) provided on at least one of the wheels of the base vehicle 100, a P-Lock device provided on the transmission of the base vehicle 100, a shift device configured to allow selection of the shift range, a drive source for the base vehicle 100, and an ECU that controls each of the devices included in the powertrain system 123. The EPB is provided separately from the aforementioned braking device and locks the wheel in place using an electric actuator. The P-Lock device mechanically locks the rotational position of the output shaft of the transmission, for example, using a parking lock pawl that can be driven by an actuator. As will be described in detail later, in this embodiment, a motor powered by a battery is used as the drive source for the base vehicle 100. The ECU of the powertrain system 123 outputs to the integrated control manager 115 whether the wheel is locked by the EPB and the P-Lock device, the shift range selected by the shift device, and the status of the battery and motor (see Figure 3, described later).

[0040] The active safety system 125 includes an ECU that determines the possibility of a collision with the vehicle 1 while it is in motion. The base vehicle 100 is equipped with a camera 129A and radar sensors 129B and 129C that detect the surrounding conditions, including the front and rear of the vehicle 1. The ECU of the active safety system 125 uses signals received from the camera 129A and radar sensors 129B and 129C to determine whether or not there is a possibility of a collision. If the active safety system 125 determines that there is a possibility of a collision, the integrated control manager 115 outputs a braking command to the brake system 121 to increase the braking force of the vehicle 1. The base vehicle 100 according to this embodiment is equipped with the active safety system 125 from the beginning (at the time of shipment). However, it is not limited to this, and an active safety system that can be retrofitted to the base vehicle may be used.

[0041] The body system 126 comprises body components (e.g., turn signals, horns, and wipers) and an ECU that controls the body components. In manual mode, the ECU of the body system 126 controls the body components according to user operation, and in autonomous mode, it controls the body components according to commands received from the ADK200 via the VCIB111 and the integrated control manager 115.

[0042] Vehicle 1 is configured to be capable of autonomous driving. VCIB111 functions as a vehicle control interface. When Vehicle 1 is driving autonomously, the integrated control manager 115 and ADK200 exchange signals with each other via VCIB111, and the integrated control manager 115 executes autonomous driving control (i.e., autonomous driving control) according to commands from ADK200. Note that ADK200 can also be removed from the base vehicle 100. Even with ADK200 removed, the base vehicle 100 can be driven by a user on its own. When the base vehicle 100 is driven on its own, the control system of the base vehicle 100 executes manual driving control (i.e., driving control according to user operation). The integrated control manager 115 may switch between autonomous mode and manual mode according to instructions from the vehicle administrator or server 500.

[0043] In this embodiment, the ADK200 exchanges signals with the VCIB111 according to an API (Application Program Interface) that defines each signal to be communicated. The ADK200 is configured to process various signals defined by the API. For example, the ADK200 creates a driving plan for vehicle 1 and outputs various commands to the VCIB111 according to the API, requesting control to drive vehicle 1 according to the created driving plan. IntegrationThe control device 150 of the control manager 115 sequentially transmits various signals (e.g., sensor signals or status signals) indicating the status of the base vehicle 100 detected in the base vehicle 100's control system to the ADK 200 via the VCIB 111. The VCIB 111 converts signals between the ADK 200 and the integrated control manager 115, enabling the integrated control manager 115 to perform vehicle control according to commands from the ADK 200.

[0044] The base vehicle 100 further includes a communication device 130. The communication device 130 includes various communication interfaces. The control device 150 is configured to communicate with external devices (e.g., a server 500 described later) of the vehicle 1 through the communication device 130. The communication device 130 includes a wireless communication device (e.g., a Data Communication Module (DCM)) that can access a mobile communication network (telematics).

[0045] The mobile terminal UT is a device carried by the user using vehicle 1. In this embodiment, a smartphone equipped with a touch panel display is used as the mobile terminal UT. However, it is not limited to this, and any mobile device can be used as the mobile terminal UT, including laptops, tablet devices, wearable devices (e.g., smartwatches or smart glasses), or electronic keys.

[0046] Vehicle 1, described above, can be adopted as one of the components of a MaaS (Mobility as a Service) system. A MaaS system includes, for example, MSPF (Mobility Service Platform). MSPF is a unified platform to which various mobility services (for example, various mobility services provided by ride-sharing operators, car-sharing operators, insurance companies, rental car companies, taxi companies, etc.) are connected. Server 500 is a computer that manages and publishes information for mobility services on MSPF. Server 500 manages information on various mobility services and provides information (for example, APIs and information on inter-mobility cooperation) in response to requests from service providers. Service providers can use various functions provided by MSPF by using APIs published on MSPF. For example, the APIs necessary for ADK development are published on MSPF.

[0047] The server 500 includes a processor 501, RAM 502, storage device 503, and an HMI (Human Machine Interface) 504. The storage device 503 is configured to store stored information. In addition to the program, the storage device 503 stores information used by the program (e.g., maps, formulas, and various parameters). The HMI 504 includes an input device and a display device. The HMI 504 may be a touch panel display. The HMI 504 may also include a smart speaker that accepts voice input.

[0048] Figure 2 shows the details of the control system of vehicle 1. Referring to Figure 2 together with Figure 1, ADK200 includes an autonomous driving system (hereinafter referred to as "ADS (Autonomous Driving System)") 202 for autonomous driving of vehicle 1. ADS202 includes a computer 210, an HMI 230, a recognition sensor 260, a posture sensor 270, and a sensor cleaner 290.

[0049] Computer 210 comprises a processor and a storage device for storing autonomous driving software utilizing an API, and is configured to execute the autonomous driving software via the processor. The autonomous driving software performs control related to autonomous driving. The autonomous driving software may be updated sequentially via OTA (Over The Air). Computer 210 further comprises arithmetic modules 210A and 210B.

[0050] The HMI230 is a device for the user and the computer 210 to exchange information. The HMI230 includes an input device and a notification device. Through the HMI230, the user can give instructions or requests to the computer 210 and change the values ​​of parameters used in the autonomous driving software (only those that are permitted to be changed). The HMI230 may be a touch panel display that combines the functions of both an input device and a notification device.

[0051] The recognition sensor 260 includes various sensors that acquire information for recognizing the external environment of the vehicle 1 (hereinafter also referred to as "environmental information"). The recognition sensor 260 acquires the environmental information of the vehicle 1 and outputs it to the computer 210. The environmental information is used for automatic driving control. In this embodiment, the recognition sensor 260 includes a camera that images the area around the vehicle 1 (including the front and rear) and an obstacle detector (e.g., millimeter-wave radar and / or lidar) that detects obstacles using electromagnetic waves or sound waves. The computer 210 can, for example, use the environmental information received from the recognition sensor 260 to recognize people, objects (other vehicles, pillars, guardrails, etc.), and lines on the road (e.g., center lines) that are within the range recognizable from the vehicle 1. Artificial intelligence (AI) or an image processing processor may be used for recognition.

[0052] The attitude sensor 270 acquires information regarding the attitude of the vehicle 1 (hereinafter also referred to as "attitude information") and outputs it to the computer 210. The attitude sensor 270 includes various sensors that detect the acceleration, angular velocity, and position of the vehicle 1. In this embodiment, the attitude sensor 270 includes an IMU (Inertial Measurement Unit) and a positioning sensor. The IMU detects the acceleration of the vehicle 1 in the longitudinal, lateral, and vertical directions, as well as the angular velocity of the vehicle 1 in the roll, pitch, and yaw directions. The positioning sensor detects the position of the vehicle 1 using a positioning system such as GPS (Global Positioning System). Techniques for measuring attitude with high accuracy by combining an IMU and a positioning sensor are known in the fields of automobiles and aircraft. The computer 210 may, for example, use such known techniques to measure the attitude of the vehicle 1 from the attitude information.

[0053] The sensor cleaner 290 is a device that removes dirt from sensors (e.g., recognition sensor 260) that are exposed to the outside air outside the vehicle. For example, the sensor cleaner 290 may be configured to clean the camera lens and the output port of an obstacle detector using a cleaning solution and a wiper.

[0054] In vehicle 1, redundancy is provided for certain functions (e.g., brakes, steering, and vehicle locking) to improve safety. The control system 102 of the base vehicle 100 includes multiple systems that perform equivalent functions. Specifically, the brake system 121 includes brake systems 121A and 121B. The steering system 122 includes steering systems 122A and 122B. The powertrain system 123 includes EPB system 123A and P-Lock system 123B. Each system is equipped with an ECU. Even if a malfunction occurs in one of the multiple systems that perform equivalent functions, the other systems will operate normally, allowing the function to function normally in vehicle 1.

[0055] VCIB111 includes VCIB111A and VCIB111B. Each of VCIB111A and VCIB111B includes a computer. The arithmetic modules 210A and 210B of computer 210 are configured to communicate with the computers of VCIB111A and VCIB111B, respectively. VCIB111 and VCIB111B are connected to each other in a manner that allows them to communicate with one another. Each of VCIB111A and VCIB111B can operate independently, and even if one malfunctions, VCIB111 will continue to operate normally as long as the other operates normally. Both VCIB111A and VCIB111B are connected to the above systems via the integrated control manager 115. However, as shown in Figure 2, the connection destinations of VCIB111A and VCIB111B differ in some respects.

[0056] In this embodiment, the function for accelerating vehicle 1 is not redundant. The powertrain system 123 includes a propulsion system 123C as a system for accelerating vehicle 1.

[0057] Figure 3 is a diagram illustrating the configuration of the propulsion system of vehicle 1 and an example of an operation plan held by server 500. Referring to Figure 3 along with Figures 1 and 2, vehicle 1 comprises an MG (Motor Generator) 20, an ECU 21, a PCU (Power Control Unit) 22, a braking device 30, a brake sensor 30a, a manned sensor 40, a battery 160, a navigation system (hereinafter also referred to as "NAVI") 170, a leader 180, and drive wheels W. The MG 20, ECU 21, and PCU 22 are included in the propulsion system 123C. The braking device 30 and brake sensor 30a are included in the brake system 121 (Figure 1).

[0058] Battery 160 supplies power to the propulsion system 123C. As battery 160, known vehicle energy storage devices (e.g., liquid-type secondary batteries, all-solid-state secondary batteries, or battery packs) can be used. Examples of vehicle secondary batteries include lithium-ion batteries and nickel-metal hydride batteries. Battery 160 may be configured to be rechargeable by contact (plug-in charging).

[0059] The battery 160 is equipped with a BMS (Battery Management System) 160a. The BMS 160a includes various sensors that detect the state of the battery 160 (e.g., voltage, current, and temperature) and outputs the detection results to the integrated control manager 115. The control device 150 can acquire the state of the battery 160 (e.g., temperature, current, voltage, and SOC) based on the output signals (BMS signals) from the BMS 160a. SOC (State of Charge) indicates the remaining charge, for example, the ratio of the current charge to the charge in a fully charged state, expressed as 0 to 100%.

[0060] The propulsion system 123C generates the driving force for vehicle 1 using the power stored in battery 160. MG20 is, for example, a three-phase AC motor generator. PCU22 includes, for example, an inverter, a converter, and a relay (hereinafter referred to as "SMR (System Main Relay)"). PCU22 is controlled by ECU21. The SMR is configured to switch the connection / disconnection of the circuit from battery 160 to MG20. The SMR is closed (connected) when vehicle 1 is running.

[0061] The MG20 is driven by the PCU22 and rotates the drive wheels W of vehicle 1. The MG20 also performs regenerative power generation and supplies the generated power to the battery 160. The PCU22 drives the MG20 using the power supplied from the battery 160. The number of drive motors (MG20) that vehicle 1 has is arbitrary; it may be one, two, or three or more. The drive motors may be in-wheel motors. Figure 3 schematically shows only one drive wheel W, but the number of drive wheels W and the drive system in vehicle 1 are arbitrary. The drive system of vehicle 1 may be front-wheel drive, rear-wheel drive, or four-wheel drive.

[0062] Each wheel (including the drive wheel W) of the vehicle 1 is equipped with a braking device 30 and a brake sensor 30a that detects the braking force applied to the wheel by the braking device 30. The brake sensor 30a may also be a hydraulic sensor that detects the hydraulic pressure applied to the brake pad (or wheel cylinder). The braking force for each wheel detected by the four brake sensors 30a (for example, the hydraulic pressure corresponding to the braking force) is output to the integrated control manager 115.

[0063] The manned sensor 40 is configured to detect whether or not there is a person (e.g., a passenger) inside the vehicle 1. More specifically, the manned sensor 40 acquires information to recognize the interior environment of the vehicle 1 and outputs the acquired information to the integrated control manager 115. The manned sensor 40 includes, for example, at least one of a camera and an infrared sensor pointed into the vehicle. The manned sensor 40 may further include at least one of a seat sensor and a seat belt sensor. Based on the output of the manned sensor 40, the control device 150 can determine whether the vehicle 1 is manned or unmanned.

[0064] NAVI170 comprises a touch panel display, a positioning sensor, and a storage device (none of which are shown). The storage device stores map information. NAVI170 is configured to display the location of vehicle 1 on a map in real time. NAVI170 is configured to perform route searching to find the optimal route (e.g., the shortest route) from vehicle 1's current location to its destination by referring to the map information. NAVI170 may sequentially update the map information via OTA (Over-the-Air).

[0065] The reader 180 is configured to read predetermined identification information from an image. More specifically, the reader 180 captures an image, extracts a predetermined code from the image, and performs a decoding process. The code extracted from the image is converted into predetermined identification information by the decoding process. The reader 180 then outputs the identification information read from the image to the integrated control manager 115. However, the reading method of the reader 180 is not limited to the above and is arbitrary. For example, the reader 180 may be an RFID (Radio Frequency Identification) reader. The reader 180 may also be provided so that it can be used by users outside the vehicle.

[0066] Vehicle 1 in this embodiment is an autonomous vehicle. Vehicle 1 provides services through autonomous driving in the absence of a driver. In other words, there is no vehicle manager inside Vehicle 1. Basically, only service users board Vehicle 1, and once all service users have disembarked, Vehicle 1 becomes unmanned.

[0067] Server 500 can identify the user currently using vehicle 1 based on information from vehicle 1. Server 500 manages information about each user (user information) registered in storage device 503. Each user is assigned identification information (user ID) to identify them, and Server 500 manages user information by distinguishing it using the user ID. In this embodiment, each user registered with Server 500 carries a mobile terminal UT. User information includes personal information (name, address, age, service usage history, etc.) and the address of the mobile terminal UT carried by the user. Server 500 may also manage service usage fees for each user.

[0068] The mobile terminal UT has application software (hereinafter referred to as "mobile app") installed for using the transportation service provided by the server 500. When the mobile terminal UT requests a task (transportation) from the server 500 and receives an acceptance reply from the server 500 (for example, see S103 in Figures 5 and 9 described later), it becomes able to display a code issued by the server 500. When the user holds the mobile terminal UT displaying the code over the reader 180 of the vehicle 1, the control device 150 identifies the user based on the information from the mobile terminal UT and executes processing to carry out the requested task (transportation) (for example, controlling the opening and closing of the doors of the vehicle 1 and controlling the vehicle's movement according to the operation plan).

[0069] The operating system according to this embodiment includes a server 500 and a plurality of vehicles 1 having the configurations shown in Figures 1 to 3. The plurality of vehicles 1 are registered with the server 500. Each vehicle registered with the server 500 may function as a robotaxi vehicle. The server 500 generates an operating plan for each of the plurality of vehicles 1 and stores the generated operating plans in a storage device 503. Identification information (vehicle ID) is assigned to each vehicle for identification purposes, and the server 500 manages information about each vehicle (including the operating plan) by distinguishing it by the vehicle ID. The server 500 instructs each of the plurality of vehicles 1 to operate according to the operating plan stored in the storage device 503.

[0070] The operation plan stored in the storage device 503 includes the type of task (e.g., transport of people or transport of goods), task start information indicating the start point and start time of the task, task end information indicating the end point and end time of the task, pre-task movement information indicating the route and driving conditions for the vehicle to the task start point before the task starts, in-task movement information indicating the route and driving conditions for the vehicle to move from the task start point to the task end point during task execution, a waiting point where the vehicle waits after performing the requested task, a waiting period at the waiting point (waiting start time and waiting end time), and post-task movement information indicating the route and driving conditions for the vehicle to move from the task end point to the waiting point after the task is completed. In an operation plan with multiple tasks, the type of task, pre-task movement information, task start information, in-task movement information, task end information, post-task movement information, waiting point, and waiting period are stored in the storage device 503 in a manner distinct for each task.

[0071] The initial operating plan for a vehicle only includes non-operating sections. Then, when a task requested by a user (service user) is assigned to the vehicle, operating sections are added to that vehicle's operating plan (see Figures 5 and 9 below). As will be explained in more detail later, operating sections correspond to the sections of the operating plan in which the vehicle is operating for a task (see Figure 7 below). Non-operating sections are the sections of the operating plan that are not operating sections.

[0072] The storage device 503 further stores information indicating the current status of each vehicle registered with the server 500 (e.g., location, vehicle speed, remaining energy, and presence or absence of passengers). The server 500 sequentially receives information indicating the current status of each registered vehicle (e.g., detection results of various on-board sensors). Furthermore, the storage device 503 may also store specification information for each vehicle registered with the server 500. In this embodiment, each vehicle registered with the server 500 corresponds to vehicle 1 (see Figures 1 to 3) having the configuration described above.

[0073] Server 500 accepts task requests from user terminals (e.g., mobile terminal UT). Figure 4 shows an example of a screen (task request screen) for a user to request a task (transportation) from Server 500. Referring to Figure 4, screen Sc1 is displayed, for example, by the touch panel display of the mobile terminal UT. Screen Sc1 includes a map M10, a display unit P101 (e.g., an icon) indicating the task start point, a display unit M1 (e.g., a text box) indicating the task start date and time, a display unit P102 (e.g., an icon) indicating the task end point, a display unit M2 (e.g., a text box) indicating the task end date and time, an operation unit M11 (e.g., a checkbox or radio button) for the user to input the type of task, and an operation unit M12 (e.g., a button) for the user to request a task from Server 500.

[0074] The user can display the desired map M10 on the mobile terminal UT by touch panel operation (e.g., scrolling). The user can specify any location on the displayed map M10 by tapping it. The user can specify the task start point and task end point through such touch panel operation (tapping). Display units P101 and P102 show the task start point and task end point specified by the user on the map M10, respectively. The user can also input the task start date and time and task end date and time into the mobile terminal UT by touch panel operation (e.g., touch keyboard operation) or voice input. Display units M1 and M2 show the task start date and time and task end date and time entered by the user, respectively. Operation unit M11 accepts input, for example, of the transport target (person / cargo). When the user operates operation unit M12, a task with the contents specified by display units P101, P102, M1, M2 and operation unit M11 is requested from the server 500 from the mobile terminal UT. Specifically, the mobile terminal UT sends a first task request signal to the server 500, which includes the user ID, the type of task entered by the operation unit M11 (for example, transporting people or goods), task start information shown by the display units P101 and M1, and task end information shown by the display units P102 and M2.

[0075] The screen Sc1 shown in Figure 4 can be modified as appropriate. For example, the operation unit M11 may further accept input of task quantity (e.g., number of people or amount of luggage). The first task request signal may further indicate the task quantity.

[0076] Users can reserve a task with the server 500 by requesting the task from the server 500 via a mobile terminal UT the day before or earlier than the day the operation plan is to be executed. In the example shown in Figure 4, the task start date shown on the display unit M1 corresponds to the day the operation plan is to be executed. The server 500 accepts task requests from each of the registered users. Each user requests a task using a mobile terminal UT (see Figure 4). When the server 500 receives the aforementioned first task request signal from one mobile terminal UT, it performs the series of processes shown in Figure 5, which are described below, for the user corresponding to that mobile terminal UT. The server 500 performs the series of processes shown in Figure 5 for each user each time it receives a task request from any of the registered users. Figure 5 is a flowchart of the process related to task reservation. In the flowchart, "S" means step.

[0077] Referring to Figures 1 to 3 and Figure 5, in S101, the server 500 obtains the operation plan for each registered vehicle. Specifically, the processor 501 reads the operation plan for each vehicle from the storage device 503. In the subsequent S102, the server 500 determines whether any vehicle can perform the task requested by the first task request signal, based on the operation plan for each vehicle and the content of the task indicated by the first task request signal (e.g., task start information and task end information). For example, the server 500 checks the operation plan for each registered vehicle and determines that the requested task can be performed if there is a vehicle that can add a section of service to perform the requested task, and determines that the requested task cannot be performed if there is no vehicle that can add a section of service to perform the requested task.

[0078] If it is determined that the requested task cannot be performed (NO in S102), the server 500 requests the mobile terminal UT (the terminal of the user who requested the task) to change the task in S105. Once the process in S105 is executed, the series of processes shown in Figure 5 are completed. The user who was requested to change the task may, for example, display screen Sc1 shown in Figure 4 on the mobile terminal UT, change the contents of the task by operating the mobile terminal UT, and then request the changed task again from the server 500. Upon receiving the request again, the server 500 restarts the series of processes shown in Figure 5.

[0079] If it is determined that the requested task can be performed (YES in S102), the server 500, in S103, selects a vehicle from among the registered vehicles to perform the requested task (hereinafter also referred to as the "target vehicle") and sends an acceptance signal to the mobile terminal UT (the terminal of the user who requested the task) indicating that it will perform the requested task.

[0080] The server 500 determines, based on the operating plan of each registered vehicle, which vehicle can have an additional operating section added to perform the requested task, as the target vehicle. If there are multiple vehicles that meet the criteria, the server 500 may select a vehicle suitable for the requested task based, for example, on at least one of the following: the vehicle's performance, the vehicle's state at the task start time (e.g., current state and state predicted from the operating plan), and the vehicle's position at the task start time (e.g., current position and position predicted from the operating plan).

[0081] Once the process in S103 is executed, the process proceeds to S104. In S104, the server 500 generates an operation plan for the target vehicle and updates the operation plan for each registered vehicle. Specifically, the server 500 adds the operating section for executing the task to the operation plan of the target vehicle to which the task has been assigned, and adjusts the operation plans of other vehicles so that multiple vehicles do not conflict with each other. For example, the server 500 may determine the vehicle speed for each road included in the route based on the legal speed for each road included in the route and the driving performance of vehicle 1 (e.g., the relationship between vehicle speed and energy consumption rate). The server 500 may set parking spaces where energy can be replenished (e.g., charging stations or refueling stations) as waiting points. Vehicle 1 waiting at an energy-replenishable parking space may replenish energy as needed. In S104, the server 500 may determine the operation plan (including the vehicle speed for each road) in a way that complies with the law, avoids conflicts, and is energy efficient. However, the operational plan decided here may be changed before the operational instructions are issued (see S14 in Figure 6, described later).

[0082] The process in S104 reserves a task for server 500. Once the process in S104 is executed, the series of processes shown in Figure 5 are completed. When the predetermined time arrives on the day (the day the operation plan is executed), server 500, which has the task reserved, executes the series of processes shown in Figure 6, which will be described below. The predetermined time may be a predetermined start time for business (for example, 5 a.m.). Alternatively, server 500 may determine the predetermined time based on the operation plan of each vehicle so that it can execute the earliest reserved task.

[0083] Figure 6 is a flowchart showing the process for executing a task according to a reserved operation plan. Referring to Figure 6 in conjunction with Figures 1 to 3, in S11, the server 500 obtains the operation plan for each registered vehicle (see Figure 3), vehicle information indicating the current status of each registered vehicle, and operation information indicating the predicted operation status for today (the latest predicted information at the present time). The vehicle information may indicate the vehicle's current location and remaining energy. The operation information may indicate traffic congestion conditions for each road, and weather conditions (e.g., sunny / cloudy / rainy / snowy, and temperature).

[0084] In S12, the server 500 determines whether a conflict will occur if it were to instruct each vehicle registered with the server 500 to operate according to the operation plan, vehicle information, and operation information acquired in S11. A conflict is an event in which multiple vehicles are waiting at the same waiting point at the same time.

[0085] If it is determined that no conflicts occur with respect to the operation plan acquired in S11 (i.e., the operation plan for each vehicle stored in the storage device 503 at the start of the series of processes shown in Figure 6) (NO in S12), the server 500 decides in S13 not to change the operation plan (operation plan finalization). Subsequently, in S15, the server 500 instructs each registered vehicle to operate according to the operation plan. Upon receiving instructions from the server 500, each vehicle registered with the server 500 executes an operation according to the operation plan through automatic driving. This completes the execution of the requested task. In this way, the server 500 is configured to generate an operation plan for each of the multiple vehicles 1 and to instruct each of the multiple vehicles 1 to operate according to the generated operation plan. An operation plan is generated for each target vehicle to which a task is assigned (see Figure 5).

[0086] On the other hand, if it is determined that a conflict occurs in the operation plan acquired in S11 (YES in S12), the server 500 modifies at least one operation plan of the multiple conflicting vehicles 1 in S14 so as to avoid the conflict. In this embodiment, the server 500 modifies the operation plan using any of the methods A to E shown below. Methods A to E may be implemented in the server 500 as arbitration protocols.

[0087] Method A: Change the waiting points in the operation plan.

[0088] Method B: Without changing the route of the operation plan, modify the driving conditions of the operation plan so that the vehicle speed is reduced when traveling along the route to the waiting point (a location where competition is expected to occur).

[0089] Method C: Modify the driving conditions of the operation plan so that a predetermined number of stops are made along the route without changing the route of the operation plan.

[0090] Method D: Change the route in the train schedule to an alternative route.

[0091] Method E: Modify the route of the operation plan so that it includes a loop route with a predetermined number of laps.

[0092] The process of S14 will be explained below using Figures 7 and 8. Figure 7 is a diagram illustrating an example of a vehicle operation plan for vehicle 1. The operation plan shown in Figure 7 includes the current position P0 of vehicle 1, the start time T1 for the first task, the starting point P1 for the first task, the start time T2 for the first task, the ending point P2 for the first task, the end time T3 for the first task, the waiting point P3 after the first task, the waiting period at waiting point P3, the start time T5 for the second task, the starting point P4 for the second task, and the start time T6 for the second task.

[0093] In the example shown in Figure 7, the parking space where Vehicle 1 is currently waiting (parked) corresponds to the current location P0. The start time T1 corresponds to the time when Vehicle 1 departs from its current location for the first task. If the requested first task is the transport of people, the place and time when people board Vehicle 1 correspond to the start point P1 and start time T2, respectively, and the place and time when people alight from Vehicle 1 correspond to the end point P2 and end time T3, respectively. If the requested first task is the transport of goods, the place and time when goods are loaded onto Vehicle 1 correspond to the start point P1 and start time T2, respectively, and the place and time when goods loaded onto Vehicle 1 are unloaded from Vehicle 1 correspond to the end point P2 and end time T3, respectively. The type of first task, start point P1, end point P2, start time T2, and end time T3 are specified by the first task request signal (see Figure 4). Server 500 may set the start time T2 and end time T3 a predetermined time (expected duration) earlier than the scheduled departure time of the vehicle at the start point P1 and end point P2, taking into account the time required for boarding / loading and disembarking / unloading (duration).

[0094] Waiting point P3 is a parking space (hereinafter referred to as "parking space S") where vehicle 1 waits after performing the first task. A This corresponds to (also known as "waiting"). The waiting period at waiting point P3 corresponds to the period from the time T4 (start of waiting) when vehicle 1, which has performed the first task, arrives at waiting point P3, to the start of operations time T5 (end of waiting). The start of operations time T5 corresponds to the time (scheduled departure time) when vehicle 1 departs from waiting point P3.

[0095] The operation plan shown in Figure 7 further includes route Rt1 (first route) and its driving conditions Td1 (first driving conditions), route Rt2 (second route) and its driving conditions Td2 (second driving conditions), route Rt3 (third route) and its driving conditions Td3 (third driving conditions), and route Rt4 (fourth route) and its driving conditions Td4 (fourth driving conditions). Routes Rt1 to Rt4 correspond to the routes from the current position P0 to the starting point P4. Route Rt1 is the route from the current position P0 to the starting point P1. Route Rt2 is the route from the starting point P1 to the ending point P2. Route Rt3 is the route from the ending point P2 to the waiting point P3. Route Rt4 is the route from the waiting point P3 to the starting point P4. Each driving condition includes, for example, vehicle speed. Each driving condition may further include the number of stops along that route (for example, see method C). The driving conditions for a route that includes a loop may further include the number of laps in the loop (see, for example, Method E). However, each driving condition may also specify more detailed conditions regarding the driving.

[0096] The above operation plan includes a first operating section, a non-operating section, and a second operating section. The first operating section includes the section on which Vehicle 1 travels to the first task start point to perform the first task (current position P0, operating start time T1 to start point P1, start time T2), and the section from the first task start point to the first task end point (start point P1, start time T2 to end point P2, end time T3). The non-operating section includes the section from the first task end point to the waiting point (end point P2, end time T3 to waiting point P3, time T4), and the waiting period (waiting point P3, time T4 to waiting point P3, operating start time T5). The second operating section includes the section on which Vehicle 1 travels to the second task start point to perform the second task (waiting point P3, operating start time T5 to start point P4, start time T6), and the section from the second task start point to the second task end point (not shown). Although the operational plan for executing the second task is omitted in Figure 7, the operational plan for the second task, which follows the first task, is set up in a manner similar to that of the first task as described above.

[0097] Figure 8 is a diagram illustrating methods A to E that may be adopted when it is determined that a conflict occurs with the operation plan shown in Figure 7. Vehicles 1A and 1B in Figure 8 each correspond to a vehicle (vehicle 1) registered with server 500. In the example shown in Figure 8, server 500 acquires the operation plan shown in Figure 7 as the operation plan for vehicle 1A at S11 in Figure 6. If vehicle 1A operates according to the operation plan shown in Figure 7, vehicle 1A performs the first task by moving from the starting point P1 to the ending point P2. However, if vehicle 1A, having completed the first task, moves from the ending point P2 to the starting point P4 according to the operation plan shown in Figure 7, vehicles 1A and 1B move to the waiting point P3 (parking space S A ) conflicts occur. For this reason, at the timing before instructing vehicle 1A to operate according to the operation plan shown in Figure 7 (S12 in Figure 6), server 500 determines that if it instructs each vehicle to operate according to the operation plan acquired in S11, a conflict will occur between vehicles 1A and 1B (YES in S12).

[0098] Of the two competing vehicles 1A and 1B at waiting point P3, vehicle 1B, whose waiting start time at waiting point P3 is earlier as indicated in the operation plan, is considered the leading vehicle (the vehicle that waits at waiting point P3 before vehicle 1A), and vehicle 1A, whose waiting start time at waiting point P3 is later as indicated in the operation plan, is considered the following vehicle (the vehicle that waits at waiting point P3 after vehicle 1B). The waiting start time at waiting point P3 for vehicle 1A, as indicated in the operation plan (Figure 7), is time T4.

[0099] As described above, if YES is determined in S12 in Figure 6, the process in S14 is executed. In S14, the server 500 avoids conflict at waiting point P3 using one of the aforementioned methods A to E.

[0100] Referring to Figure 8, in Method A, the server 500, for example, determines the waiting point for the operation plan of vehicle 1A as waiting point P3 (parking space S A ) From waiting area P3A (parking space S) B ) will be changed. Server 500 will have parking space S where vehicle 1A does not compete with other vehicles. BThe waiting point P3A may be set as the waiting point. In addition, the server 500 sets up a new route Rt3a from the end point P2 to the waiting point P3A, a waiting period at the waiting point P3A, and a route Rt4a from the waiting point P3A to the start point P4 in accordance with this change in the waiting point. The server 500 may also change the start time for the second task from the start time T5 to the start time T5a. In this configuration, the period from the time T4a when vehicle 1 arrives at the waiting point P3A to the start time T5a corresponds to the waiting period at the waiting point P3A. The server 500 may set the waiting period at the waiting point P3A for vehicle 1A so that vehicle 1A does not compete with other vehicles at the waiting point P3A. The server 500 may also set the start time T5a so that vehicle 1A can arrive at the start point P4 by the start time T6.

[0101] In Method B, the server 500 modifies the driving conditions of Vehicle 1A's operation plan so that, for example, the vehicle speed (e.g., average speed) when Vehicle 1A travels along route Rt3 is slowed down without changing the route Rt3 of Vehicle 1A's operation plan. Vehicle 1A's travel along route Rt3 corresponds to Vehicle 1A traveling towards waiting point P3 according to the route of the operation plan shown in Figure 7. According to Method B, by slowing down the vehicle speed when Vehicle 1A travels along route Rt3, the waiting start time of Vehicle 1A at waiting point P3 is delayed so that competition between Vehicles 1A and 1B at waiting point P3 is avoided. The waiting start time of Vehicle 1A at waiting point P3 (the scheduled time when Vehicle 1A is scheduled to arrive at waiting point P3) is changed by Method B to a time T4b that is later than, for example, the time T4 shown in Figure 7. The server 500 sets time T4b to a time later than the scheduled departure time of Vehicle 1B at waiting point P3 (the scheduled time when Vehicle 1B is scheduled to leave waiting point P3). Alternatively, server 500 may set time T4b to match the scheduled departure time of vehicle 1B so that vehicles 1A and 1B switch places at waiting point P3. Or, server 500 may change the scheduled departure time of vehicle 1B to match time T4b so that vehicles 1A and 1B switch places at waiting point P3. By having vehicles 1A and 1B switch places at waiting point P3, it is possible to prevent waiting point P3 from being filled by another vehicle (for example, a vehicle not registered with server 500) after vehicle 1B has left waiting point P3.

[0102] In Method C, the server 500 modifies the driving conditions of vehicle 1A's operation plan so that vehicle 1A travels to waiting point P3 while making a predetermined number of stops (e.g., short stops) along route Rt3 of vehicle 1A's operation plan, without changing the route Rt3 of vehicle 1A's operation plan. The server 500 determines the predetermined number of stops (number of stops) based on the operation plan of vehicle 1B (in particular, the time when vehicle 1B departs from waiting point P3) to avoid conflict. The stopping time may be a fixed value (e.g., the upper limit of the legally permitted stopping time) or it may be variable depending on the situation (e.g., the degree of congestion). According to Method C, by having vehicle 1A make stops when traveling to waiting point P3 along route Rt3, the waiting start time of vehicle 1A at waiting point P3 is delayed so that conflict between vehicles 1A and 1B at waiting point P3 is avoided. The more stops there are, the later the waiting start time becomes. The start time for vehicle 1A to wait at waiting point P3 is changed to a later time T4c, for example, than the time T4 shown in Figure 7, using method C. Server 500 sets time T4c to a time later than the scheduled departure time of vehicle 1B at waiting point P3. Alternatively, Server 500 may set time T4c to match the scheduled departure time of vehicle 1B so that vehicles 1A and 1B switch places at waiting point P3. Or, Server 500 may change the scheduled departure time of vehicle 1B to match time T4c so that vehicles 1A and 1B switch places at waiting point P3. By having vehicles 1A and 1B switch places at waiting point P3, it is possible to prevent waiting point P3 from being filled by another vehicle after vehicle 1B has left waiting point P3.

[0103] In Method D, Server 500 modifies the operation plan of vehicle 1A to avoid conflict at waiting point P3, for example, by changing the route of vehicle 1A's operation plan to detour route Rt3b. Specifically, Server 500 delays the start time of waiting for vehicle 1A at waiting point P3 by changing the route. Since the distance of detour route Rt3b is longer than the distance of route Rt3, the time at which vehicle 1A arrives at waiting point P3 is delayed as vehicle 1A proceeds to waiting point P3 by following detour route Rt3b. The start time of waiting for vehicle 1A at waiting point P3 is changed by Method D to a time T4d that is later than the time T4 shown in Figure 7, for example. Server 500 may also use the map information of NAVI 170 to search for a detour from the destination point P2 to waiting point P3. Server 500 sets time T4d to a time later than the scheduled departure time of vehicle 1B at waiting point P3. Server 500 determines the detour route Rt3b so that time T4d is a time when conflict can be avoided. If the above search finds multiple detours that can avoid conflict, the server 500 may determine the detour that requires the least amount of energy to reach waiting point P3 as detour Rt3b. Alternatively, the server 500 may set time T4d to match the scheduled departure time of vehicle 1B so that vehicles 1A and 1B swap places at waiting point P3. The server 500 may adjust time T4d by changing the driving conditions of detour Rt3b (e.g., vehicle speed or number of stops). Or, the server 500 may change the scheduled departure time of vehicle 1B to match time T4d so that vehicles 1A and 1B swap places at waiting point P3. By having vehicles 1A and 1B swap places at waiting point P3, it is possible to prevent waiting point P3 from being filled by another vehicle after vehicle 1B has left waiting point P3. If the above search does not find any detours that can avoid conflict, the server 500 will not employ method D.

[0104] In Method E, the server 500 modifies the operation plan of vehicle 1A, for example, so that the route of vehicle 1A's operation plan includes a loop route CL of a predetermined number of laps. As a result, the route of vehicle 1A's operation plan is changed to route Rt3c, which includes loop route CL. Loop route CL is a closed-loop route that vehicle 1A can circumnavigate. The server 500 determines the predetermined number of laps to avoid conflict, for example, based on the operation plan of vehicle 1B (in particular, the time when vehicle 1B departs from waiting point P3). As a result, the waiting start time of vehicle 1A at waiting point P3 is delayed so that conflict between vehicles 1A and 1B at waiting point P3 is avoided. The more laps of loop route CL are increased, the later the time when vehicle 1A arrives at waiting point P3. The server 500 may determine the minimum number of laps required to avoid conflict as the predetermined number of laps. The waiting start time of vehicle 1A at waiting point P3 is changed by Method E to a later time T4e than the time T4 shown in Figure 7, for example. Server 500 may use the map information from NAVI170 to search for a route from the endpoint P2 to the waiting point P3 via a closed-loop route. Server 500 sets time T4e to a time later than the scheduled departure time of vehicle 1B at the waiting point P3. Server 500 determines the loop route CL and its number of laps so that time T4e is a time when conflicts can be avoided. Server 500 may also set time T4e to match the scheduled departure time of vehicle 1B so that vehicles 1A and 1B switch places at the waiting point P3. Server 500 may adjust time T4e by changing the driving conditions of route Rt3c (e.g., vehicle speed or number of stops). Alternatively, Server 500 may change the scheduled departure time of vehicle 1B to match time T4e so that vehicles 1A and 1B switch places at the waiting point P3. By having vehicles 1A and 1B switch places at the waiting point P3, it is possible to prevent the waiting point P3 from being filled by another vehicle after vehicle 1B has left the waiting point P3. If the above search does not find a loop path that avoids conflicts, server 500 will not adopt method E.

[0105] As described above, each of methods A to E allows for modification of the operation plan to avoid conflict. In S14 of Figure 6, if there are multiple operation plans that can avoid conflict, server 500 may select the most energy-efficient operation plan from among them. Server 500 may also select one method from methods A to E from the standpoint of energy efficiency.

[0106] For example, methods B through E may result in wasted energy consumption due to waiting for a space to become available where a preceding vehicle has parked (i.e., wasting time without using a parking space). Server 500 may select method A if the energy consumption for wasting time outside of parking spaces exceeds a predetermined threshold in each of methods B through E. In addition, autonomous vehicles in motion consume a significant amount of energy due to sensing for driving (operation of the autonomous driving system).

[0107] When a vehicle is driving autonomously, a large amount of energy is consumed regardless of its speed. Therefore, method C, which involves stopping to kill time, tends to be more energy-efficient than other methods. However, method C cannot always be adopted on all roads. It is difficult to adopt method C in traffic situations where stopping would cause congestion.

[0108] Furthermore, energy consumption during driving (electricity consumption) varies depending on the vehicle speed. Energy consumption due to friction and resistance during driving tends to be greater at higher speeds than at lower speeds. Also, energy consumption per unit time due to sensing (operation of the autonomous driving system) tends to be greater at higher speeds than at lower speeds. This is because sensing needs to be done over longer distances at higher speeds. However, driving time (time to reach the destination) is longer at lower speeds than at higher speeds. And the longer the driving time, the greater the energy consumption due to sensing. Comparing methods B, D, and E, the driving distance is longer with methods D and E than with method B. However, as mentioned above, electricity consumption varies with vehicle speed, so adjusting the time by changing the driving distance, as in methods D and E, may be more energy-efficient than adjusting the time by changing the vehicle speed, as in method B. Server 500 may set the optimal vehicle speed from the perspective of energy efficiency for each of methods A and C to E.

[0109] Server 500 may, for example, compare methods A to E from the above perspectives and determine the most energy-efficient method, which allows for conflict avoidance, as the operation plan for the following vehicle. Server 500 may also modify the operation plan of the preceding vehicle as necessary. In S14 of Figure 6, Server 500 modifies the operation plan of at least one of the competing preceding and following vehicles so that conflict is avoided. Once the operation plan is modified by the process in S14, the process proceeds to S15. In S15, Server 500 instructs each registered vehicle to operate according to the modified operation plan. This suppresses conflict during operation.

[0110] Users can also request tasks from the server 500 on the task execution day (the current day) using a mobile terminal UT (see Figure 4). In the screen Sc1 shown in Figure 4, when a user requests a task with a start date of today from the server 500 by setting the task start date (display unit M1) to today and operating the operation unit M12, the mobile terminal UT sends a second task request signal to the server 500. The second task request signal basically indicates information similar to the first task request signal, but the task start date indicated by the second task request signal is today (the task request date). When the server 500 receives a second task request signal from a mobile terminal UT, it executes the series of processes shown in Figure 9, which are described below, for the user corresponding to that mobile terminal UT. The server 500 executes the series of processes shown in Figure 9 for each user each time it receives a task request from any of the registered users. Figure 9 is a flowchart showing the process for executing a task according to the operation plan requested for the current day.

[0111] Referring to Figures 1 to 3 and Figure 9, in S101A, the server 500 acquires the operation plan and current status (e.g., location and energy level) of each registered vehicle. In S102A, the server 500 determines whether any vehicle can perform the task requested by the second task request signal, based on the operation plan and current status of each vehicle and the content of the task indicated by the second task request signal (e.g., task start information and task end information). For example, the server 500 checks the operation plan and current status of each registered vehicle and determines that the requested task can be performed if there is a vehicle that can add a section of service to perform the requested task, and determines that the requested task cannot be performed if there is no vehicle that can add a section of service to perform the requested task.

[0112] If it is determined that the requested task cannot be performed (NO in S102A), the server 500 executes the process in S105. S105 in Figure 9 is the same process as S105 in Figure 5. On the other hand, if it is determined that the requested task can be performed (YES in S102A), the server 500 executes the processes from S103 onwards (S103, S104, S11~S15). S103, S104 and S11~S15 in Figure 9 are the same processes as S103, S104 in Figure 5 and S11~S15 in Figure 6, respectively. As a result, on the day the server 500 receives the task request, operations are carried out according to the operation plan (the operation plan that is finalized in S13 or S14), and the requested task is executed.

[0113] As described above, the server 500 in this embodiment is configured to determine whether a conflict will occur if each of the multiple vehicles 1 is instructed to operate according to the operation plan, resulting in multiple vehicles 1 waiting at the same waiting point at the same time (S12 in Figures 6 and 9), before instructing each of the multiple vehicles 1 to operate. If it is determined that a conflict will occur, the server 500 modifies at least one of the conflicting operation plans of the multiple vehicles 1 to avoid the conflict (S14 in Figures 6 and 9). With this configuration, even if a difference between the planned operation and the actual operation occurs due to real-time dispatch requests or traffic congestion on the day, the server 500 can dynamically avoid the conflict according to the situation. This makes it possible for multiple vehicles 1 to efficiently share a limited parking space. Since operation management is possible with fewer operating resources (parking spaces), operation efficiency is improved. With the server 500 having the above configuration, it becomes easier to increase operation efficiency while suppressing an increase in the amount of operating resources. As described above, the server 500 makes it easier to increase operation efficiency by having multiple vehicles 1 operate in a coordinated manner in a non-operational section.

[0114] Based on the operation instructions from server 500 (S15 in Figures 6 and 9), vehicle 1, which is automatically driving according to the operation plan, may perform a series of processes shown in Figure 10, which will be described below, when it is waiting at a waiting point. Figure 10 is a flowchart of an example of automatic driving control performed by a waiting vehicle (vehicle 1 waiting at a waiting point). In this example, a schedule for the preceding vehicle and the following vehicle to switch places (scheduled switch) may be set at each waiting point included in the operation plan. An operation plan that includes a waiting point with a scheduled switch indicates the time at which the two vehicles will switch places (scheduled switch time) and the identification information (vehicle ID) of each vehicle to switch places. In the operation plan, if the time at which the following vehicle arrives at a certain waiting point (scheduled arrival time) and the time at which the preceding vehicle departs from that waiting point (scheduled departure time) coincide, it means that a scheduled switch is set at that waiting point. Below, as an example, the control performed when vehicle 1B, shown in Figure 8, is waiting at waiting point P3 will be described. Vehicle 1B is the preceding vehicle. The following vehicle is vehicle 1A. The series of processes shown in Figure 10 are executed, for example, by the control device 150 (Figure 3) of vehicle 1B.

[0115] Referring to Figure 10 along with Figures 1 to 3, in S201, in the operation plan for vehicle 1B, waiting point P3 (currently waiting parking space S) A Vehicle 1B determines whether or not a replacement is scheduled at waiting point P3. If no replacement is scheduled at waiting point P3 (NO in S201), Vehicle 1B determines in S202 whether or not the scheduled departure time for waiting point P3 indicated in Vehicle 1B's operation plan has arrived. As long as the scheduled departure time for waiting point P3 has not arrived (NO in S202), Vehicle 1B waits at waiting point P3 and repeats the processes in S201 and S202. Then, when the scheduled departure time for waiting point P3 arrives (YES in S202), Vehicle 1B departs from waiting point P3 by automatic driving in S206.

[0116] If a changeover is scheduled at waiting point P3 (YES in S201), vehicle 1B determines in S203 whether the current time is within the predetermined departure period. The departure period is determined based on the scheduled departure time from waiting point P3 as indicated in vehicle 1B's operation plan. The departure period may include, for example, a first departure period and a second departure period set before and after the scheduled departure time. The first departure period is the period from the start time of the departure period to the scheduled departure time. The second departure period is the period from the scheduled departure time to the end time of the departure period.

[0117] If the current time is not within the departure period (NO in S203), the process returns to S201. Therefore, vehicle 1B will not depart from waiting point P3 until the start time of the departure period has arrived.

[0118] If the current time is within the departure period (YES in S203), vehicle 1B determines in S204 whether the end time of the departure period has arrived. If the end time of the departure period has not arrived (NO in S204), vehicle 1B determines in S205 whether the following vehicle (vehicle 1A) has approached the waiting point P3. When vehicle 1A approaches the waiting point P3 (for example, when it has approached the waiting point P3 within a predetermined distance), it may transmit a departure request signal including its own vehicle ID to vehicle 1B via wireless communication. Based on the signal from vehicle 1A, vehicle 1B may determine whether vehicle 1A has approached the waiting point P3. For example, vehicle 1B determines that vehicle 1A has not approached the waiting point P3 as long as it has not received a departure request signal. Furthermore, vehicle 1B determines that vehicle 1A (the following vehicle that will replace vehicle 1B at waiting point P3) is approaching waiting point P3 if the vehicle ID indicated by the received departure request signal matches the vehicle ID of the following vehicle indicated by the operation plan.

[0119] If vehicle 1A is not approaching waiting point P3 (NO in S205), the process returns to S201. Vehicle 1B waits for vehicle 1A's arrival during the departure period. When vehicle 1A approaches waiting point P3 (YES in S205), vehicle 1B departs from waiting point P3 automatically in S206. Then vehicle 1A enters waiting point P3. As a result, vehicle 1A and vehicle 1B switch places at waiting point P3. If vehicle 1A is delayed beyond the scheduled departure time and does not arrive at waiting point P3 within the departure period, and the departure period ends before vehicle 1A arrives at waiting point P3 (YES in S204), vehicle 1B also departs from waiting point P3 automatically in S206. However, in this case, the planned exchange of vehicles 1A and 1B is not performed.

[0120] As described above, in the example shown in Figure 10, vehicle 1B (first mobile unit) and vehicle 1A (second mobile unit), which have been instructed to operate according to an operation plan that includes the planned exchange of vehicles at waiting point P3, are configured to depart from waiting point P3 when vehicle 1A approaches while vehicle 1B is waiting at waiting point P3. With this configuration, it becomes easier for vehicle 1A to enter waiting point P3 at the same time that vehicle 1B leaves waiting point P3.

[0121] In the above embodiment, the server 500 selects a conflict avoidance method from methods A to E, but it is not necessary for the number of conflict avoidance method options to be five. For example, other methods may be added to the options. Alternatively, the server 500 may select a conflict avoidance method from an option that includes two to four methods from methods A to E. Or, the server 500 may not select a conflict avoidance method and may avoid conflicts using one predetermined method (for example, one of methods A to E). Furthermore, even if three or more vehicles are in conflict at a certain waiting point, the server 500 can avoid conflicts for all vehicles by avoiding the conflicts of the vehicles one by one in order of arrival time at the waiting point, starting with the vehicle with the latest arrival time, using the above method.

[0122] In the above embodiment, vehicle 1 is exemplified as a robotaxi vehicle without a driver. When the robotaxi vehicle receives an operation instruction (S15 in Figure 9) from the server 500, it performs an operation according to the operation plan through autonomous driving. However, vehicle 1 is not limited to a robotaxi vehicle. Vehicle 1 may be configured to have a driver perform an operation according to the operation plan. For example, when vehicle 1 receives an operation instruction from the server 500, the contents of the operation instruction may be displayed on the in-vehicle HMI (e.g., NAVI170). The driver may perform an operation according to the operation plan while checking the operation plan on the in-vehicle HMI. However, driving at the speed specified by the server 500 is easier to perform accurately with autonomous driving than with manual driving.

[0123] The vehicle configuration is not limited to the configuration described in the above embodiment (see Figures 1 to 3). The base vehicle may have an autonomous driving function without any aftermarket additions. The level of autonomous driving may be fully autonomous driving (Level 5) or conditional autonomous driving (e.g., Level 4). The vehicle configuration may be appropriately modified for unmanned driving. For example, a vehicle designed for unmanned driving may not be equipped with parts for human operation (such as a steering wheel).

[0124] In the above embodiment, multiple vehicles receiving instructions from the server 500 have the same configuration. However, the multiple vehicles managed by the server 500 may have different configurations. The multiple vehicles may include, in place of or in addition to BEVs without internal combustion engines, at least one of the following types of vehicles: xEVs (HEVs, PHEVs) equipped with internal combustion engines, FCEVs, and internal combustion engine vehicles without electric motors for driving. The vehicles are not limited to passenger cars, but may also be buses or trucks. The vehicles may also be multi-purpose vehicles customized according to the user's intended use. Instead of vehicles, non-vehicle mobile entities (railway vehicles, ships, airplanes, walking robots, robotic cleaners, drones, space probes, etc.) may be used. The mobile entities may be configured to be remotely controllable. Any location where mobile entities can wait can be used as a waiting point.

[0125] The tasks are not limited to the aforementioned transportation. Any task is feasible for a mobile entity, and could be, for example, a mobile shop, a mobile office, or a mobile hospital (medical tasks).

[0126] The embodiments and variations described above may be implemented in any combination.

[0127] The embodiments disclosed herein should be considered in all respects to be illustrative and not restrictive. The technical scope provided herein is defined by the claims rather than by the description of the embodiments above, and all modifications within the meaning and scope equivalent to the claims are intended to be included. [Explanation of Symbols]

[0128] 1,1A,1B vehicles, 2 VPs, 100 base vehicles, 102 control systems, 115 integrated control managers, 130 communication devices, 150 control devices, 160 batteries, 170 NAVIs, 200 ADKs, 202 ADSs, 210 computers, 500 servers, UT mobile terminals.

Claims

1. A server that manages multiple mobile devices, The server is configured to generate an operation plan for each of the plurality of mobile bodies and to instruct each of the plurality of mobile bodies to operate in accordance with the generated operation plan. The aforementioned operation plan includes a waiting point where the mobile body waits after performing the requested task, and a waiting period at the waiting point. The aforementioned server, Before instructing each of the multiple mobile units to operate, it is determined whether a conflict will occur in which, if each of the multiple mobile units were instructed to operate according to the operation plan, the multiple mobile units would all be waiting at the same waiting point at the same time. If it is determined that the aforementioned conflict will occur, the operation plan of the mobile body whose waiting start time is later than the waiting period indicated by the waiting period at the waiting point will be changed so as to avoid the aforementioned conflict. A server configured to run [the specified program].

2. The server according to claim 1, wherein the server is configured to change the waiting location for the operation plan of the mobile body whose waiting start time indicated by the waiting period at the waiting location is later than that of two competing mobile bodies at the waiting location, so as to avoid the competition.

3. Each of the aforementioned multiple moving objects is an autonomous vehicle, The aforementioned operation plan further includes a route and driving conditions for the autonomous vehicle to move to the waiting point after the completion of the task, The server according to claim 1, wherein the server is configured to delay the start time of the waiting period indicated by the waiting period at the waiting point, among two competing mobile bodies at the waiting point, by changing the driving conditions without changing the route, so as to avoid the competition.

4. Each of the aforementioned multiple moving objects is an autonomous vehicle, The aforementioned operation plan further includes a route for the autonomous vehicle to move to the waiting point after the completion of the task, The server according to claim 1, wherein the server is configured to delay the start time of the waiting period indicated by the waiting period at the waiting point, for the mobile body whose operating plan is later than the two competing mobile bodies at the waiting point, by changing the route to a detour route, so as to avoid the competition.

5. Each of the aforementioned multiple moving objects is an autonomous vehicle, The aforementioned operation plan further includes a route for the autonomous vehicle to move to the waiting point after the completion of the task, The server according to claim 1, wherein the server is configured to delay the start time of the waiting period indicated by the waiting period at the waiting point, for the mobile body whose waiting start time is later than the two mobile bodies competing at the waiting point, by changing the route so that the route includes a loop route of a predetermined number of laps, thereby avoiding the competition.

6. The server according to claim 1, wherein, if there are multiple operation plans that can avoid the aforementioned conflict, the server is configured to select the most energy-efficient operation plan from among those multiple operation plans.

7. A server that manages multiple mobile devices, The server is configured to generate an operation plan for each of the plurality of mobile bodies and to instruct each of the plurality of mobile bodies to operate in accordance with the generated operation plan. The aforementioned operation plan includes a waiting point where the mobile body waits after performing the requested task, and a waiting period at the waiting point. The aforementioned server, Before instructing each of the multiple mobile units to operate, it is determined whether a conflict will occur in which, if each of the multiple mobile units were instructed to operate according to the operation plan, the multiple mobile units would all be waiting at the same waiting point at the same time. If it is determined that the aforementioned conflict will occur, the operation plan of at least one of the competing mobile bodies will be modified so as to avoid the aforementioned conflict. It is configured to perform, The server is configured to modify at least one of the operation plans of the first and second mobile bodies so that the first and second mobile bodies are swapped at the waiting point when it is determined that a conflict occurs with respect to the first and second mobile bodies included in the plurality of mobile bodies.

8. An operating system comprising a server according to any one of claims 1 to 7, and a plurality of mobile bodies that receive instructions from the server.

9. An operating system comprising a server for managing a plurality of mobile bodies and the plurality of mobile bodies that receive instructions from the server, The server is configured to generate an operation plan for each of the plurality of mobile bodies and to instruct each of the plurality of mobile bodies to operate in accordance with the generated operation plan. The aforementioned operation plan includes a waiting point where the mobile body waits after performing the requested task, and a waiting period at the waiting point. The aforementioned server, Before instructing each of the multiple mobile units to operate, it is determined whether a conflict will occur in which, if each of the multiple mobile units were instructed to operate according to the operation plan, the multiple mobile units would all be waiting at the same waiting point at the same time. If it is determined that the aforementioned conflict will occur, the operation plan of at least one of the competing mobile bodies will be modified so as to avoid the aforementioned conflict. It is configured to perform, The plurality of moving bodies include a first moving body and a second moving body, An operating system in which the first mobile unit, which has been instructed to operate in accordance with the operation plan which includes the planned exchange of the first mobile unit and the second mobile unit at the waiting point, departs from the waiting point when the second mobile unit approaches while the first mobile unit is waiting at the waiting point.

Images