Server and operation system

Abstract

To facilitate enhancement of operation efficiency while suppressing an increase in the amount of operation resource.SOLUTION: A server that manages a plurality of mobile objects is configured to determine an operation plan for each one of the plurality of mobile objects, and to instruct the mobile object to perform operation in accordance with the determined operation plan. Each operation plan includes a plan related to energy supply for operation. The server is configured to determine whether or not a conflict in which a plurality of mobile object perform energy supply at the same timing in the same location will occur on the basis of the operation plans, and if it is determined that a conflict will occur, to change the operation plan for at least one of the plurality of conflicting mobile objects so that the conflict is avoided.SELECTED DRAWING: Figure 6

Description

[Technical Field]

[0001] The present disclosure relates to a server and an operation system. [Background technology]

[0002] Japanese Patent Application Laid-Open Publication No. 2023-012203 (Patent Document 1) discloses an operation system that can prevent a shortage of power for running an electric bus caused by a decrease in the full charge capacity of the battery. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Publication No. 2023-012203 Summary of the Invention [Problem to be solved by the invention]

[0004] In the operation system described in Patent Document 1, operation efficiency can be improved by increasing the number of operating sections in the operation plan or by increasing the amount of tasks in the operating sections. In Patent Document 1, the transportation of people corresponds to a task, and the amount of transportation (i.e., the number of people) corresponds to the task amount. The section in the operation plan where a moving object (for example, the bus described in Patent Document 1) is performing a task corresponds to an operating section. An operating section is, for example, a section from the task start point to the task end point.

[0005] However, Patent Document 1 does not mention anything about the relationship between operational efficiency and operational resources. Operational efficiency can be expressed as the value obtained by dividing the task amount by the operational resource amount (= task amount / operation resource amount). Operational resources are resources required for operation. Examples of operational resources include mobile objects, energy for operating mobile objects, and energy replenishment points. The more operational resources there are, the lower the operational efficiency becomes, so the technology described in Patent Document 1 does not necessarily result in sufficient operational efficiency. There is still room for improvement in the technology described in Patent Document 1.

[0006] The present disclosure has been made to solve the above-mentioned problems, and its purpose is to make it easier to increase operation efficiency while suppressing an increase in the amount of operation resources. [Means for solving the problem]

[0007] According to an embodiment of the first aspect of the present disclosure, there is provided a server as follows. (Item 1) The server is configured to manage a plurality of moving bodies. The server is configured to determine an operation plan for each of the plurality of moving bodies and to instruct each of the plurality of moving bodies to operate in accordance with the determined operation plan. The operation plan includes a plan for energy replenishment for operation. The server is configured to determine, based on the operation plan, whether a conflict will occur between the plurality of moving bodies to replenish energy at the same location at the same time, and, if it is determined that a conflict will occur, to modify the operation plan of at least one of the competing plurality of moving bodies so as to avoid the conflict.

[0008] Since mobile units consume energy during operation, it is necessary to systematically replenish the mobile units with energy in order to ensure continuous operation. Energy replenishment points are one type of operational resource. Increasing the number of energy replenishment points makes it easier to increase the amount of tasks. However, if the number of energy replenishment points is increased too much, the deterioration in operational efficiency due to the increase in energy replenishment points will have a greater impact than the improvement in operational efficiency due to the increase in task volume, and operational efficiency will actually decrease. In particular, increasing the number of energy replenishment points in areas with high land prices (e.g., urban areas) will result in a deterioration in operational efficiency (= task volume / operational resource price) from an economic perspective. For this reason, in order to improve operational efficiency, it is desirable for multiple mobile units to effectively utilize the limited number of energy replenishment points.

[0009] However, in a transportation system with a limited number of available energy refueling points, conflicts among multiple moving bodies at energy refueling points (i.e., multiple moving bodies staying at the same energy refueling point at the same time) are likely to occur. Even if operation plans for multiple moving bodies are set to prevent conflicts, conflicts may still occur depending on the conditions on the day the operation plans are executed. In this regard, if the server determines that a conflict will occur based on the operation plans, it changes the operation plan of at least one of the multiple competing moving bodies to avoid the conflict. Therefore, the server can determine an operation plan to avoid conflicts, for example, depending on the conditions on the day. This enables multiple moving bodies to effectively utilize limited energy refueling points. In this way, the server can coordinate the operation of multiple moving bodies in non-operating sections, making it easier to improve operation efficiency. The server can easily improve operation efficiency while suppressing an increase in the amount of operating resources.

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

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

[0012] (Section 2) The server described in Section 1 further has the following feature: The operation plan includes an energy replenishment point and a duration of stay at the energy replenishment point. Before instructing each of the multiple moving bodies to operate, if the server determines, based on the operation plan, that a leading first moving body and a following second moving body will compete at the energy replenishment point and if the remaining energy of the first moving body at the time of competition predicted from the operation plan is greater than a reference amount, the server changes the duration of stay of the first moving body at the energy replenishment point so that the first moving body departs from the energy replenishment point at the time of competition.

[0013] According to the above configuration, it becomes easier to appropriately avoid conflicts without changing the routes of the first and second moving bodies.

[0014] (Item 3) The server described in item 1 or 2 further has the following feature: Before instructing each of the multiple moving bodies to operate, if the server determines based on the operation plan that a leading first moving body and a following second moving body will compete at the energy replenishment point, and if the remaining energy of the first moving body at the time of competition predicted from the operation plan is less than a reference amount, the server changes the stay period of the first moving body at the energy replenishment point so that the first moving body departs from the energy replenishment point at the time when the remaining energy of the first moving body reaches the reference amount.

[0015] According to the above configuration, it becomes easier to appropriately avoid conflicts without changing the routes of the first and second moving bodies, while suppressing the first moving body from running out of energy.

[0016] (4) The server according to any one of paragraphs 1 to 3 further has the following feature: The server is configured to change an energy replenishment point for at least one operation plan of a plurality of competing moving bodies so as to avoid the conflict.

[0017] According to the above configuration, one method for avoiding conflicts is to change the route.

[0018] (Item 5) The server according to any one of items 1 to 4 further has the following feature: When there are multiple operation plans that can avoid conflicts, the server is configured to select an operation plan with the lowest risk of running out of energy from among the multiple operation plans.

[0019] According to the above configuration, it is possible to improve the operation efficiency while suppressing the occurrence of an energy shortage. The server may change the arbitration protocol for conflict avoidance so as to reduce the risk of an energy shortage.

[0020] (Item 6) The server according to any one of Items 1 to 5 further has the following feature: When there are multiple operation plans that can avoid conflicts, the server is configured to select the most energy-efficient operation plan from among the multiple operation plans.

[0021] According to the above configuration, it is possible to improve the operation efficiency while suppressing an increase in the amount of energy required to operate the mobile object. The server may change the arbitration protocol for conflict avoidance so as to improve energy efficiency.

[0022] The server may use the conflict avoidance methods described in the above paragraphs 2 to 6 depending on the situation.

[0023] According to an embodiment of the second aspect of the present disclosure, there is provided the following operation system. (Clause 7) The operation system includes the server according to any one of clauses 1 to 6, and a plurality of moving objects that receive instructions from the server.

[0024] In the above-described operation system, the server makes it easier to increase operation efficiency while suppressing an increase in the amount of operation resources.

[0025] (Item 8) The operation system described in item 7 further has the following features: The multiple moving bodies include a third moving body and a fourth moving body. Each of the third moving body and the fourth moving body is an autonomous vehicle. The third moving body, which has been instructed to operate according to an operation plan that includes a schedule in which the third moving body and the fourth moving body will switch places at an energy refueling point, departs from the energy refueling point when the fourth moving body approaches while staying at the energy refueling point.

[0026] According to the above configuration, it becomes easier for the fourth moving body to enter the energy replenishment point just at the same time as the third moving body leaves the energy replenishment point. Compared to manual driving by a driver, automatic driving makes it easier to accurately control driving conditions. [Effects of the Invention]

[0027] According to the present disclosure, it becomes easier to increase operational efficiency while suppressing an increase in the amount of operational resources. [Brief explanation of the drawings]

[0028] [Figure 1] 1 is a diagram showing a schematic configuration of a vehicle according to an embodiment of the present disclosure. [Figure 2] FIG. 2 is a diagram showing details of a control system for the vehicle shown in FIG. [Figure 3] FIG. 2 is a diagram for explaining an operation plan held by a server in the operation system according to the embodiment of the present disclosure. [Figure 4] FIG. 10 is a diagram illustrating a task request screen employed in the operation system according to the embodiment of the present disclosure. [Figure 5] 10 is a flowchart showing a process related to task reservation in the operation method according to the embodiment of the present disclosure. [Figure 6] 10 is a flowchart illustrating a process for executing a task according to a reserved operation plan in the operation method according to the embodiment of the present disclosure. [Figure 7] FIG. 10 is a diagram for explaining a specific example of a vehicle operation plan that can be adopted in the operation system according to the embodiment of the present disclosure. [Figure 8] FIG. 1 is a diagram illustrating a conflict avoidance technique according to an embodiment of the present disclosure. [Figure 9] 10 is a flowchart illustrating a process for executing a task according to an operation plan requested for the day in the operation method according to the embodiment of the present disclosure. [Figure 10] 10 is a flowchart illustrating an example of automatic driving control executed by a vehicle during energy refueling in a driving method according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

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

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

[0031] The VP2 includes a base vehicle 100 and a vehicle control interface box (hereinafter referred to as a "VCIB (Vehicle Control Interface Box)") 111. By adding the VCIB 111 to the base vehicle 100, the VP2 is formed, to which the ADK200 can be attached and detached. The vehicle 1 is then completed by attaching the ADK200 to the VP2. The VCIB 111 may communicate with the ADK200 through an in-vehicle network such as a Controller Area Network (CAN). Note that while the base vehicle 100 and the ADK200 are shown in separate locations in FIG. 1, the ADK200 is actually attached to the base vehicle 100. In this embodiment, the ADK200 is attached to the rooftop of the base vehicle 100. However, the attachment position of the ADK200 can be changed as appropriate.

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

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

[0034] In this embodiment, the integrated control manager 115 includes a control device 150. The control device 150 includes a processor 151, a random access memory (RAM) 152, and a storage device 153. The processor 151 may be, for example, a central processing unit (CPU). The RAM 152 functions as a working memory that temporarily stores data processed by the processor 151. The storage device 153 is configured to be able to save stored information. The storage device 153 may include a read-only memory (ROM) and a rewritable non-volatile memory. The storage device 153 stores programs as well as information used by the programs (e.g., maps, formulas, and various parameters). In this embodiment, the processor 151 executes the programs stored in the storage device 153 to perform various vehicle controls (e.g., autonomous driving control following instructions from the ADK 200). However, these processes may be performed by dedicated hardware (electronic circuits) rather than software. The control device 150 may include any number of processors, and a processor may be provided for each predetermined control.

[0035] 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 includes a computer. The computer for each system communicates with the integrated control manager 115 via an in-vehicle network (e.g., CAN). Hereinafter, the computer included in each system will be referred to as an "ECU (Electronic Control Unit)."

[0036] The brake system 121 includes a brake device provided on each wheel of the base vehicle 100 and an ECU that controls the brake device. In this embodiment, a hydraulic disc brake device is used as the brake device. The base vehicle 100 is equipped with wheel speed sensors 127A and 127B. The wheel speed sensor 127A is provided on the front wheel of the base vehicle 100 and detects the rotation speed of the front wheel. The wheel speed sensor 127B is provided on the rear wheel of the base vehicle 100 and detects the rotation speed of the rear wheel. The ECU of the brake system 121 outputs the rotation direction and rotation 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 calculate the traveling speed (vehicle speed) of the vehicle 1 based on the detection signals of the wheel speed sensors 127A and 127B.

[0037] 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 EPS (Electric Power Steering) that can adjust the steering angle using 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 a rotating shaft 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.

[0038] 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 select a shift range, a drive source for the base vehicle 100, and an ECU that controls each device included in the powertrain system 123. The EPB is provided separately from the aforementioned braking device and locks the wheels using an electric actuator. The P-Lock device mechanically locks the rotational position of the output shaft of the transmission using, for example, a parking lock pole that can be driven by an actuator. As will be described in detail later, in this embodiment, a motor supplied with power from 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 EPB and the P-Lock device have locked the wheels, the shift range selected by the shift device, and the status of the battery and the motor (see FIG. 3, described later).

[0039] The active safety system 125 includes an ECU that determines the possibility of a collision for the traveling vehicle 1. 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 determines whether or not there is a possibility of a collision using signals received from the camera 129A and the radar sensors 129B and 129C. 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, the present invention is not limited to this, and an active safety system that can be retrofitted to the base vehicle may also be adopted.

[0040] The body system 126 includes body components (e.g., turn signals, a horn, and wipers) and an ECU that controls the body components. In the manual mode, the ECU of the body system 126 controls the body components according to user operations, and in the autonomous mode, the ECU controls the body components according to commands received from the ADK 200 via the VCIB 111 and the integrated control manager 115.

[0041] The vehicle 1 is configured to be capable of autonomous driving. The VCIB 111 functions as a vehicle control interface. When the vehicle 1 is traveling in autonomous driving mode, the integrated control manager 115 and the ADK 200 exchange signals with each other via the VCIB 111, and the integrated control manager 115 performs autonomous mode driving control (i.e., autonomous driving control) in accordance with instructions from the ADK 200. The ADK 200 can also be detached from the base vehicle 100. Even when the ADK 200 is detached, the base vehicle 100 can be driven by the user and travel independently. When traveling independently, the control system of the base vehicle 100 performs manual mode driving control (i.e., driving control in response to user operation). The integrated control manager 115 may switch between autonomous mode and manual mode in accordance with instructions from the vehicle manager or the server 500.

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

[0043] The base vehicle 100 further includes a communication device 130. The communication device 130 includes various communication I / Fs (interfaces). The control device 150 is configured to communicate with devices external to the vehicle 1 (for example, a server 500, which will be described later) through the communication device 130. The communication device 130 includes a wireless communication device (for example, a DCM (Data Communication Module)) that can access a mobile communication network (telematics).

[0044] The mobile terminal UT is a terminal carried by a user of the vehicle 1. In this embodiment, a smartphone equipped with a touch panel display is used as the mobile terminal UT. However, the mobile terminal UT is not limited to this, and any mobile terminal can be used as the mobile terminal UT, such as a laptop, a tablet, a wearable device (for example, a smartwatch or smart glasses), or an electronic key.

[0045] The vehicle 1 described above can be employed as one of the components of a Mobility as a Service (MaaS) system. The MaaS system includes, for example, a Mobility Service Platform (MSPF). The MSPF is a unified platform to which various mobility services (e.g., various mobility services provided by ride-sharing operators, car-sharing operators, insurance companies, rental car operators, taxi operators, etc.) are connected. The server 500 is a computer that manages and publishes information for mobility services in the MSPF. The server 500 manages information on various mobility services and provides information (e.g., APIs and information on linkages between mobility services) in response to requests from operators. Service providers can use the APIs published on the MSPF to utilize various functions provided by the MSPF. For example, the APIs required for developing an ADK are published on the MSPF.

[0046] The server 500 includes a processor 501, a RAM 502, a storage device 503, and an HMI (Human Machine Interface) 504. The storage device 503 is configured to be able to save stored information. The storage device 503 stores programs as well as information used by the programs (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 include a smart speaker that accepts voice input.

[0047] Fig. 2 is a diagram showing details of the control system of the vehicle 1. Referring to Fig. 2 together with Fig. 1, the ADK 200 includes an autonomous driving system (hereinafter referred to as "ADS (Autonomous Driving System)") 202 for performing autonomous driving of the vehicle 1. The ADS 202 includes a computer 210, an HMI 230, a recognition sensor 260, an attitude sensor 270, and a sensor cleaner 290.

[0048] The computer 210 includes a processor and a storage device that stores autonomous driving software that utilizes an API, and is configured so that the processor can execute the autonomous driving software. The autonomous driving software executes control related to autonomous driving. The autonomous driving software may be updated sequentially via OTA (Over The Air). The computer 210 further includes calculation modules 210A and 210B.

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

[0050] 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 autonomous driving control. In this embodiment, the recognition sensor 260 includes a camera that captures images of the surroundings (including the front and rear) of the vehicle 1 and an obstacle detector (e.g., millimeter-wave radar and / or lidar) that detects obstacles using electromagnetic waves or sound waves. For example, the computer 210 can recognize people, objects (other vehicles, pillars, guardrails, etc.), and lines on the road (e.g., center lines) that are present within a range recognizable from the vehicle 1 using the environmental information received from the recognition sensor 260. For recognition, artificial intelligence (AI) or an image processing processor may be used.

[0051] The attitude sensor 270 acquires information related to 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 in each of the longitudinal, lateral, and vertical directions of the vehicle 1, as well as the angular velocity in each of the roll, pitch, and yaw directions of the vehicle 1. The positioning sensor detects the position of the vehicle 1 using a positioning system such as a GPS (Global Positioning System). Techniques for measuring attitude with high accuracy by combining an IMU and a positioning sensor are well known in the fields of automobiles and aircraft. The computer 210 may, for example, use such well-known techniques to measure the attitude of the vehicle 1 from the attitude information.

[0052] The sensor cleaner 290 is a device that removes dirt from sensors (e.g., the 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 lens of a camera and the emission port of an obstacle detector using a cleaning liquid and a wiper.

[0053] In vehicle 1, certain functions (e.g., braking, steering, and vehicle immobilization) are provided with redundancy to improve safety. The control system of base vehicle 100 includes multiple systems that achieve equivalent functions. Specifically, brake system 121 includes brake systems 121A and 121B. Steering system 122 includes steering systems 122A and 122B. Powertrain system 123 includes EPB system 123A and P-Lock system 123B. Each system includes an ECU. Even if an abnormality occurs in one of the multiple systems that achieve equivalent functions, the function in question will function normally in vehicle 1 as long as the other operates normally.

[0054] The VCIB 111 includes VCIB 111A and VCIB 111B. Each of the VCIBs 111A and 111B includes a computer. The computing modules 210A and 210B of the computer 210 are configured to be able to communicate with the computers of the VCIBs 111A and 111B, respectively. The VCIB 111 and VCIB 111B are connected to each other so that they can communicate with each other. Each of the VCIBs 111A and 111B can operate independently, and even if an abnormality occurs in one of them, the VCIB 111 operates normally as long as the other operates normally. Both the VCIBs 111A and 111B are connected to the above-mentioned systems via the integrated control manager 115. However, as shown in FIG. 2, the VCIBs 111A and VCIB 111B have partially different connection destinations.

[0055] In this embodiment, there is no redundancy in the function of accelerating the vehicle 1. The powertrain system 123 includes a propulsion system 123C as a system for accelerating the vehicle 1.

[0056] Fig. 3 is a diagram illustrating the configuration of a propulsion system of vehicle 1 and an example of an operation plan held by server 500. With reference to Fig. 3 together with Figs. 1 and 2, vehicle 1 includes MG (Motor Generator) 20, ECU 21, PCU (Power Control Unit) 22, braking device 30, brake sensor 30a, occupancy sensor 40, battery 160, BMS (Battery Management System) 161, charger 162, inlet 163, navigation system (hereinafter also referred to as "NAVI") 170, reader 180, and drive wheels W. MG 20, ECU 21, and PCU 22 are included in propulsion system 123C. Braking device 30 and brake sensor 30a are included in brake system 121 (Fig. 1).

[0057] Battery 160 supplies power to propulsion system 123C. A known vehicle power storage device (such as a liquid secondary battery, an all-solid-state secondary battery, or a battery pack) can be used as battery 160. Examples of vehicle secondary batteries include lithium-ion batteries and nickel-metal hydride batteries.

[0058] The battery 160 is provided with a BMS 161. The BMS 161 includes various sensors that detect the state of the battery 160 (for example, 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 (for example, temperature, current, voltage, and SOC) based on the output signal from the BMS 161. The SOC (State Of Charge) indicates the remaining amount of power, and is, for example, the ratio of the current amount of power stored to the amount of power stored in a fully charged state, expressed as 0 to 100%.

[0059] Vehicle 1 is configured to be capable of charging using power supplied from outside the vehicle (external power source) (hereinafter also referred to as "external charging"). External charging performed by vehicle 1 is contact charging (plug-in charging) using power supplied from EVSE (Electric Vehicle Supply Equipment). Inlet 163 is configured to be connectable to a connector of a charging cable of EVSE (external power source). Charger 162 converts power input to inlet 163 from outside the vehicle into power suitable for charging battery 160. Charger 162 is, for example, an on-board charger including at least one of a DC / DC converter and an inverter. Note that external charging is not limited to plug-in charging and may be non-contact charging.

[0060] The propulsion system 123C generates driving force for the vehicle 1 using electric power stored in the battery 160. The MG 20 is, for example, a three-phase AC motor generator. The PCU 22 includes, for example, an inverter, a converter, and a relay. The PCU 22 is controlled by the ECU 21. The relay is configured to switch between connection and disconnection of an electric circuit from the battery 160 to the MG 20. The relay is closed (connected) when the vehicle 1 is traveling.

[0061] The MG 20 is driven by the PCU 22 to rotate the drive wheels W of the vehicle 1. The MG 20 also generates power regeneratively and supplies the generated power to the battery 160. The PCU 22 drives the MG 20 using the power supplied from the battery 160. The vehicle 1 may be equipped with any number of traction motors (MG 20), and may be one, two, three or more. The traction motor may be an in-wheel motor. Although FIG. 3 schematically shows only one drive wheel W, the number of drive wheels W on the vehicle 1 and the drive system are arbitrary. The drive system of the vehicle 1 may be any of front-wheel drive, rear-wheel drive, and four-wheel drive.

[0062] Each wheel (including the drive wheels W) of the vehicle 1 is provided 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 be a hydraulic sensor that detects the hydraulic pressure applied to the brake pad (or wheel cylinder). The braking forces for each wheel detected by the four brake sensors 30a are output to the integrated control manager 115.

[0063] The manned sensor 40 is configured to detect whether or not a person (e.g., a passenger) is present inside the vehicle 1. More specifically, the manned sensor 40 acquires information for recognizing 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 facing the interior of the vehicle. The manned sensor 40 may further include at least one of a seating sensor and a seat belt sensor. The control device 150 can determine whether the vehicle 1 is manned or unmanned based on the output of the manned sensor 40.

[0064] The NAVI 170 includes a touch panel display, a positioning sensor, and a storage device (none of which are shown). The storage device stores map information. The NAVI 170 is configured to display the position of the vehicle 1 on the map in real time. The NAVI 170 is configured to refer to the map information and perform a route search to find the optimal route (e.g., the shortest route) from the current location of the vehicle 1 to the destination. The NAVI 170 may successively update the map information via OTA.

[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 be provided so that it can be used by a user outside the vehicle.

[0066] The vehicle 1 according to this embodiment is an autonomous vehicle. The vehicle 1 provides a service by autonomous driving without a driver present. In other words, there is no vehicle manager inside the vehicle 1. Basically, only service users get on the vehicle 1, and when all the service users get off, the vehicle 1 becomes unmanned.

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

[0068] Application software (hereinafter referred to as "mobile app") for using the transportation service provided by the server 500 is installed on the mobile terminal UT. The mobile terminal UT requests a task (transportation) from the server 500, and when it receives an acceptance reply from the server 500 (see, for example, S103 in FIGS. 5 and 9 described below), 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 information from the mobile terminal UT and executes processing for executing the requested task (transportation) (for example, control of opening and closing the doors of the vehicle 1 and control of driving in accordance with the operation plan).

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

[0070] The operation plan stored in the storage device 503 includes the type of task (e.g., transporting people or cargo), task start information indicating the start location and start time of the task, task end information indicating the end location and end time of the task, pre-task movement information indicating the route and driving conditions for the vehicle to travel to the task start location before the task starts, in-task movement information indicating the route and driving conditions for the vehicle to travel from the task start location to the task end location during task execution, and refueling information indicating a plan for energy refueling for the operation. The refueling information indicates an energy refueling point where the vehicle will refuel and a stay period during which the vehicle will stay at the energy refueling point. For a vehicle that is predicted to have sufficient energy remaining after the task ends, the refueling information may indicate that the location and period for energy refueling are not set, i.e., the vehicle will not refuel after the task ends. For an operation plan in which multiple tasks are set, the task type, pre-task movement information, task start information, in-task movement information, task end information, and refueling information are stored in the storage device 503 in a manner that distinguishes each task.

[0071] The initial operation plan of a vehicle includes only non-operating sections. Then, when a task requested by a user (service user) is assigned to a vehicle, an operating section is added to the operation plan of the vehicle (see Figures 5 and 9 described below). In this embodiment, an operating section corresponds to a section in the operation plan where the vehicle is performing a task (see Figure 7 described below). A non-operating section is a section in the operation plan that is not an operating section (see Figure 7 described below).

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

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

[0074] The user can display a desired map M10 on the mobile terminal UT by touch panel operation (e.g., scrolling). The user can also zoom in / out on the map M10 by touch panel operation (e.g., pinch in / out). The user can specify any position on the displayed map M10 by tapping on it. The user can specify the task start point and task end point by such touch panel operation (tapping). Display units P101 and P102 show the task start point and task end point, respectively, specified by the user on the map M10. 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. The operation unit M11 accepts input of, for example, the object to be transported (person / baggage). When the user operates operation unit M12, a task having details specified by display units P101, P102, M1, M2 and operation unit M11 is requested from mobile terminal UT to server 500. Specifically, mobile terminal UT transmits to server 500 a first task request signal indicating the user ID, the type of task input by operation unit M11 (e.g., transporting a person or luggage), task start information indicated by display units P101, M1, and task end information indicated by display units P102, M2.

[0075] 4 can be changed as appropriate. For example, the operation unit M11 may further receive input of a task amount (e.g., the number of people or the amount of luggage). The first task request signal may further indicate the task amount.

[0076] A user can reserve a task in the server 500 by requesting the task from the server 500 using a mobile terminal UT on or before the day before the day on which the operation plan is to be executed. In the example shown in FIG. 4, the task start date indicated by the display unit M1 corresponds to the day on which the operation plan is to be executed. The server 500 accepts task requests from each of multiple registered users. Each user requests a task using a mobile terminal UT (see FIG. 4). When the server 500 receives the above-mentioned first task request signal from the mobile terminal UT, the server 500 executes a series of processes shown in FIG. 5, which will be described below, for the user corresponding to that mobile terminal UT. Every time the server 500 receives a task request from any registered user, the server 500 executes the series of processes shown in FIG. 5 for that user. FIG. 5 is a flowchart showing a process related to task reservation. "S" in the flowchart denotes a step.

[0077] 1 to 3 and FIG. 5, in S101, the server 500 acquires the operation plan of each registered vehicle. Specifically, the processor 501 reads the operation plan of each vehicle from the storage device 503. In the following S102, the server 500 determines whether any vehicle can execute the task requested by the first task request signal based on the operation plan of 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 of each registered vehicle and determines that the requested task can be executed if there is a vehicle that can add an operating section to execute the requested task, and determines that the requested task cannot be executed if there is no vehicle that can add an operating section to execute the requested task. The server 500 may determine whether a vehicle can execute the requested task based on the vehicle's location and status (e.g., remaining energy) at the task start time in addition to the vehicle's operation plan. The server 500 may also predict the vehicle's location and status at the task start time based on the vehicle's driving history and operation plan.

[0078] If it is determined that none of the vehicles can execute the requested task (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. When the processing of S105 is executed, the series of processing shown in FIG. 5 ends. The user who has been requested to change the task may, for example, display the screen Sc1 shown in FIG. 4 on the mobile terminal UT, change the content 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 processing shown in FIG. 5.

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

[0080] The server 500 determines, as the target vehicle, a vehicle that can add an operating section for executing the requested task based on the operation plan of each registered vehicle. If there are multiple applicable vehicles, the server 500 may select a vehicle that is suitable for the requested task based on at least one of the vehicle performance, the vehicle's location at the task start time, and the vehicle's state (e.g., remaining energy) at the task start time.

[0081] After the process of S103 is executed, the process proceeds to S104. In S104, the server 500 determines an operation plan for the target vehicle and updates the operation plan for each registered vehicle. Specifically, in S104, the server 500 executes, for example, S104A to S104C in FIG. 5. In S104A, the server 500 adds an operating section to the operation plan of the target vehicle to which the task is assigned, so that the task does not conflict with other vehicles. Furthermore, the server 500 evaluates the energy outage risk of the target vehicle with respect to the operation plan of the target vehicle to which the operating section has been added. The energy outage risk for the operation plan of the target vehicle indicates the possibility (e.g., probability) that the target vehicle will run out of energy (e.g., run out of power) while executing the operation plan. In S104B, the server 500 determines whether the energy outage risk for the operation plan of the target vehicle is higher than a predetermined reference level based on the result of the evaluation. For example, the server 500 predicts the transition of the remaining energy amount of the target vehicle over the entire operation period. If the remaining energy amount of the target vehicle falls below a predetermined lower limit even temporarily during the operation period, the server 500 determines that the risk of running out of energy is higher than the reference level. If the remaining energy amount of the target vehicle is equal to or higher than the lower limit throughout the operation period, the server 500 determines that the risk of running out of energy is lower than the reference level. The remaining energy amount of the vehicle 1 is expressed, for example, by the SOC of the battery 160. If the risk of running out of energy related to the operation plan of the target vehicle is higher than the reference level (YES in S104B), the server 500 further adds an energy replenishment point and its duration before the start of a task in the operation plan of the target vehicle or after the end of the task in S104C. In this case, the server 500 sets the energy replenishment point and its duration so as not to cause contention at the replenishment point. Contention at a replenishment point is an event in which multiple vehicles replenish energy at the same location at the same time. On the other hand, if the risk of running out of energy regarding the operation plan of the target vehicle is lower than the reference level (NO in S104B), no energy replenishment point is added to the operation plan of the target vehicle.

[0082] In S104, the server 500 may determine a driving plan for the target vehicle so that the target vehicle performs the task while complying with traffic regulations, conflicts at refueling points are avoided, and the risk of the target vehicle running out of energy is lower than a reference level. The driving plan determined in S104 is stored in the storage device 503. However, the driving plan determined here may be changed before issuing driving instructions (see S14 in FIG. 6, which will be described later).

[0083] The processing of S104 reserves a task in the server 500. When a predetermined time arrives on the day (the day the operation plan is executed), the server 500 for which the task has been reserved executes a series of processes shown in FIG. 6, which will be described below. The predetermined time may be a predetermined start time (for example, 5:00 a.m.). Alternatively, the server 500 may determine the predetermined time based on the operation plan of each vehicle so that the earliest reserved task can be executed.

[0084] Fig. 6 is a flowchart showing a process for executing a task according to a reserved operation plan. Referring to Fig. 6 together with Figs. 1 to 3, in S11, the server 500 acquires the operation plan of each registered vehicle (see Fig. 3), vehicle information indicating the current status of each registered vehicle, and operation information (currently the latest forecast information) indicating the predicted operation status for today. The vehicle information may indicate the current location and remaining energy of the vehicle. The operation information may indicate the traffic congestion status for each road and the weather conditions (for example, weather such as sunny / cloudy / rainy / snowy, and temperature).

[0085] In S12, based on the operation plan, vehicle information, and operation information acquired in S11, the server 500 determines whether or not a conflict will occur at the supply point if it instructs each vehicle registered in the server 500 to operate in accordance with the operation plan.

[0086] If it is determined that the above-mentioned conflict does not occur in the operation plan acquired in S11 (i.e., the operation plan of each vehicle stored in the storage device 503 at the start of the series of processes shown in FIG. 6) (NO in S12), the server 500 determines in S13 not to change the operation plan (operation plan confirmation). An operation plan is determined for each target vehicle to which a task is assigned (see FIG. 5).

[0087] On the other hand, if it is determined that the above-mentioned conflict will occur for the operation plans acquired in S11 (YES in S12), the server 500 changes the operation plan of at least one of the competing target vehicles in S14 to avoid the conflict. Because it is unlikely that three or more target vehicles will compete at one energy refueling point, the following describes a case where two target vehicles compete at one energy refueling point. In the following description, of the two competing target vehicles, the vehicle that is predicted to arrive at the energy refueling point first according to the operation plan is referred to as the "leading vehicle," and the vehicle that is predicted to arrive at the energy refueling point later according to the operation plan is referred to as the "following vehicle." If the leading vehicle and the following vehicle travel according to their respective operation plans, the following vehicle will arrive at the energy refueling point while the leading vehicle is staying at the energy refueling point.

[0088] In S14, the server 500 executes, for example, S14A to S14D in FIG. 6. In S14A, the server 500 searches for a following vehicle operation plan that satisfies all of the following requirements: the risk of running out of energy is lower than a predetermined reference level (first requirement), the conflict can be avoided (second requirement), and the assigned task can be completed (third requirement). In S14B, the server 500 determines whether a following vehicle operation plan that satisfies all of the first to third requirements is found. The reference level used here may be the same as or different from the reference level used in S104B of FIG. 5. The server 500 may determine whether the following vehicle operation plan satisfies all of the first to third requirements by, for example, changing at least one of the route and driving conditions. The server 500 may avoid the conflict by, for example, changing the route of the following vehicle so that the following vehicle refuels at an energy refueling point different from the energy refueling point where the conflict occurs (i.e., changing the energy refueling point of the following vehicle). Furthermore, the server 500 may avoid the conflict by, for example, changing the driving conditions or route of the following vehicle so that the following vehicle arrives at the energy refueling point after the preceding vehicle has completed refueling at the energy refueling point. In the operation plan of the following vehicle, the time at which the following vehicle arrives at the energy refueling point can be delayed by slowing down the vehicle speed, stopping on the route, or changing the route to a detour or loop route.

[0089] If a following vehicle operation plan that satisfies all of the above first to third requirements is found (YES in S14B), the server 500 determines the operation plan as the following vehicle operation plan in S14C. The determined operation plan is stored in the storage device 503 as the following vehicle operation plan (see FIG. 3). Here, if multiple following vehicle operation plans that satisfy all of the above first to third requirements are found, the server 500 selects, for example, the operation plan with the lowest risk of running out of energy from among those operation plans. In other words, the server 500 selects, from among multiple operation plans for the following vehicles, the operation plan with the lowest risk of the following vehicle running out of remaining energy.

[0090] However, the present invention is not limited to the above. When multiple operation plans for the following vehicle that satisfy all of the first to third requirements are found, the server 500 may select the most energy-efficient operation plan from among those operation plans. The server 500 may calculate the energy efficiency of the operation plan using the driving conditions (vehicle speed, driving time, etc.) and route (driving distance, elevation difference, etc.) indicated in the operation plan. The server 500 may also calculate the energy efficiency of the operation plan by further using at least one of the traffic congestion and weather conditions on the day the operation plan is executed. For example, the longer the driving time, the greater the energy consumption. An autonomously driven vehicle consumes a large amount of energy during driving due to sensing (operation of the autonomous driving system). Furthermore, the energy consumption during driving (electricity cost) varies depending on the vehicle speed. Energy consumption due to friction and resistance during driving tends to be greater at high speeds than at low speeds. Furthermore, energy consumption per unit time due to sensing (operation of the autonomous driving system) also tends to be greater at high speeds than at low speeds. This is because the faster the vehicle, the farther the sensing distance needs to be as the vehicle speed increases. However, the travel time (time to reach the destination) is longer at low speeds than at high speeds, and the longer the travel time, the greater the energy consumption due to sensing.

[0091] On the other hand, if no operation plan of the following vehicle that satisfies all of the above first to third requirements is found (NO in S14B), the server 500 changes the operation plan of the preceding vehicle in S14D to avoid the conflict.

[0092] For example, if the remaining energy of the leading vehicle at the conflict occurrence time predicted from the operation plans of each vehicle is less than a predetermined reference amount, the server 500 changes both the operation plan of the leading vehicle and the operation plan of the following vehicle. Specifically, the server 500 changes the operation plans of the leading vehicle and the following vehicle so that, when the remaining energy of the leading vehicle reaches the predetermined reference amount through energy replenishment (charging), the leading vehicle departs from the energy replenishment point and the following vehicle arrives at the energy replenishment point. In this case, the server 500 advances the departure time of the leading vehicle (end of stay period) and delays the arrival time of the following vehicle (start of stay period) at the energy replenishment point. The server 500 may set the reference amount based on the operation plan of the leading vehicle so that the leading vehicle can perform the assigned task.

[0093] On the other hand, if the remaining energy amount of the leading vehicle at the conflict occurrence time predicted from the operation plans of each vehicle is greater than the predetermined reference amount, the server 500 changes the stay period of the leading vehicle at the energy refueling point so that the leading vehicle departs from the energy refueling point at the conflict occurrence time. In this case, the server 500 advances the departure time (end of stay period) of the leading vehicle from the energy refueling point, but does not change the stay period of the following vehicle.

[0094] If three or more vehicles compete at one energy refueling point, the server 500 may search for an operation plan that satisfies all of the first to third requirements for each of the competing vehicles. If no applicable operation plan is found, the server 500 may raise the reference level of the first requirement. The lower the aforementioned energy lower limit, the higher the reference level of the first requirement.

[0095] Once the operation plan for each target vehicle is finalized through S13 or S14, the server 500 instructs each target vehicle to operate in accordance with the operation plan in S15. Upon receiving the instruction from the server 500, each target vehicle performs operation in accordance with the operation plan through autonomous driving. This executes the requested task. In this way, the server 500 is configured to generate an operation plan for each of the multiple vehicles 1 and instruct each of the multiple vehicles 1 to operate in accordance with the generated operation plan.

[0096] FIG. 7 is a diagram illustrating an example of an operation plan for vehicle 1A. Vehicle 1A corresponds to a target vehicle. The operation plan shown in FIG. 7 includes a start position P0 and its departure time T1, a start point P1 of a first task, a start time T2 of the first task, an end point P2 of the first task, an end time T3 of the first task, a supply point P3, a stay period at supply point P3 (time T4 to time T5), a start point P4 of a second task, and a start time T6 of the second task.

[0097] In the example shown in FIG. 7, the position of vehicle 1A at the start of the operation plan corresponds to start position P0. If the type of requested first task is transporting people, the location and time where the people get on vehicle 1A correspond to start point P1 and start time T2, respectively, and the location and time where the people get off vehicle 1A correspond to end point P2 and end time T3, respectively. If the type of requested first task is transporting luggage, the location and time where the luggage is loaded onto vehicle 1A correspond to start point P1 and start time T2, respectively, and the location and time where the luggage loaded on vehicle 1A is unloaded from vehicle 1A correspond to 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 FIG. 4). The server 500 may set the start time T2 and the end time T3 to be a predetermined time (estimated required time) earlier than the scheduled departure time of the vehicle at the start point P1 and the end point P2, taking into account the time (required time) required for boarding / loading and disembarking / unloading.

[0098] The recharge point P3 corresponds to a location (energy recharge point) where the vehicle 1A recharges energy for the second task after completing the first task. The energy recharge of the vehicle 1A is, for example, plug-in charging of the battery 160. The stay period at the recharge point P3 corresponds to the period from time T4 when the vehicle 1A arrives at the recharge point P3 to time T5 when the vehicle 1A departs from the recharge point P3.

[0099] The operation plan shown in FIG. 7 further includes a route Rt1 (a first route to a start point of a first task) and its driving conditions Td1 (first driving conditions), a route Rt2 (a second route from a start point of the first task to an end point of the first task) and its driving conditions Td2 (second driving conditions), a route Rt3 (a third route from an end point of the first task to an energy supply point) and its driving conditions Td3 (third driving conditions), and a route Rt4 (a fourth route from an energy supply point to a start point of a second task) and its driving conditions Td4 (fourth driving conditions). Each driving condition includes, for example, vehicle speed. However, the driving conditions are not limited to vehicle speed, and each driving condition may indicate more detailed conditions related to driving (such as the number of stops and the number of loops).

[0100] The operation plan includes a first non-operating section (a section from the starting position to the starting point of the first task), a first operating section (a section from the starting point of the first task to the end point of the first task), a second non-operating section (a section from the end point of the first task to the starting point of the second task), and a second operating section (a section from the start point of the second task to the end point of the second task). Although the operation plan for executing the second task is omitted in Figure 7, an operation plan is set for the second task that follows the first task in a manner similar to that of the first task described above.

[0101] FIG. 8 is a diagram for explaining the conflict avoidance technique in this embodiment. If it is determined in S12 of FIG. 6 that the operation plan of vehicle 1A will not conflict with other vehicles, the operation plan is finalized in the following S13. On the other hand, if it is determined in S12 of FIG. 6 that the operation plan of vehicle 1A will conflict with other vehicles, a search for an operation plan is executed in the following S14A. The operation plan shown in FIG. 8 is the operation plan of vehicle 1A found by the search in S14A and that satisfies the first and third requirements. Specifically, the first and third requirements are satisfied by setting one of refueling points P3B, P3C, and P3D as an energy refueling point (corresponding to refueling point P3 shown in FIG. 7) in the operation plan of vehicle 1A. If no conflict occurs with at least one of refueling points P3B, P3C, and P3D, the second requirement is also satisfied, and therefore the refueling point that does not cause a conflict is determined as the energy refueling point in S14C of FIG. 6. If there are multiple recharge points that do not cause a conflict, the server 500 selects one of the recharge points according to, for example, a selection criterion described later. The conflict is avoided by changing the energy recharge point (changing the route).

[0102] If the server 500 determines, based on the operation plans of the vehicles 1A-1D, that the vehicle 1A will conflict with the vehicles 1B, 1C, and 1D (preceding vehicles) at the recharge points P3B, P3C, and P3D, respectively, in S14D of FIG. 6, it selects one recharge point from among the recharge points P3B, P3C, and P3D and changes the operation plan of the preceding vehicle to avoid the conflict. If the stay periods of the vehicle 1A and the vehicles 1B, 1C, and 1D at the recharge points P3B, P3C, and P3D overlap at least partially, a conflict occurs. The server 500 selects one recharge point from among the recharge points P3B, P3C, and P3D, for example, according to the selection criteria described below.

[0103] The selection criteria (rules for selecting a refueling point) in this embodiment will be described. When the risk of vehicle 1A running out of energy is equal to or greater than a predetermined level, the server 500 may select a refueling point that minimizes the risk of vehicle 1A running out of energy. For example, the server 500 may select a refueling point that minimizes the risk of vehicle 1A running out of energy. When the risk of vehicle 1A running out of energy is less than the predetermined level and the remaining energy of the preceding vehicle at the time of conflict predicted from the operation plans of each vehicle is less than a predetermined amount, the server 500 may select a refueling point that maximizes the remaining energy of the preceding vehicle at the predicted time of conflict. When the risk of vehicle 1A running out of energy is less than the predetermined level and the remaining energy of the preceding vehicle at the time of conflict predicted from the operation plans is equal to or greater than the predetermined amount, the server 500 may select a refueling point that maximizes the energy efficiency of vehicle 1A. For example, the server 500 may select a refueling point P3B that is located on a route that minimizes the energy consumption required for vehicle 1A to travel from the end point P2 of the first task to the start point P4 of the second task.

[0104] FIG. 9 is a flowchart showing a process for executing a task according to an operation plan requested for that day. Specifically, a user can use a mobile terminal UT (see FIG. 4) to request a task from the server 500 on the task execution date (that day). When the user sets the task start date (display unit M1) to today on the screen Sc1 shown in FIG. 4 and operates the operation unit M12 to request a task whose start date is today from the server 500, the mobile terminal UT transmits a second task request signal to the server 500. The second task request signal basically indicates information similar to that of the first task request signal, but the task start date indicated by the second task request signal is today (task request date). When the server 500 receives the second task request signal from the mobile terminal UT, the server 500 executes a series of processes shown in FIG. 9 , which will be described below, for the user corresponding to that mobile terminal UT. Every time the server 500 receives a task request from any registered user, the server 500 executes the series of processes shown in FIG. 9 for that user.

[0105] 1 to 3 as well as FIG. 9, in S101A, the server 500 acquires the operation plan and current status (e.g., location and remaining energy) of each registered vehicle. In S102A, the server 500 determines whether any vehicle can execute 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 executed if there is a vehicle that can add an operating section to execute the requested task, and determines that the requested task cannot be executed if there is no vehicle that can add an operating section to execute the requested task.

[0106] If it is determined that the requested task cannot be executed (NO in S102A), the server 500 executes the process of S105. S105 in FIG. 9 is a process equivalent to S105 in FIG. 5. On the other hand, if it is determined that the requested task can be executed (YES in S102A), the server 500 executes the processes from S103 onwards (S103, S104, S11 to S15). S103, S104, and S11 to S15 in FIG. 9 are processes equivalent to S103 and S104 in FIG. 5 and S11 to S15 in FIG. 6, respectively. As a result, on the day when the server 500 receives the task request, operation is executed in accordance with the operation plan (the operation plan confirmed in S13 or S14), and the requested task is executed.

[0107] As described above, the server 500 according to this embodiment is configured to manage multiple vehicles 1. The server 500 determines an operation plan for each of the multiple vehicles 1 and instructs each of the multiple vehicles 1 to operate in accordance with the determined operation plan (S15 in FIGS. 6 and 9). The operation plan includes a plan for energy replenishment for operation (see FIG. 7). Based on the operation plan, the server 500 determines whether a conflict will occur between multiple vehicles 1 refueling at the same location at the same time (S12 in FIGS. 6 and 9). If the server 500 determines that a conflict will occur, it changes the operation plan of at least one of the competing vehicles 1 to avoid the conflict (S14 in FIGS. 6 and 9). In this way, the server 500 coordinates the operation of multiple mobile objects (e.g., vehicles 1) in a non-operating section (energy replenishment section), thereby improving operation efficiency while avoiding conflict in a transportation system with few available energy replenishment points. The server 500 having the above configuration facilitates improving operation efficiency while suppressing an increase in the amount of operational resources.

[0108] Based on operation instructions from the server 500 (S15 in FIGS. 6 and 9), the vehicle 1 undergoing autonomous driving according to the operation plan may execute a series of processes shown in FIG. 10, which will be described below, while refueling at an energy refueling point. FIG. 10 is a flowchart showing an example of autonomous driving control executed by the vehicle 1 during energy refueling. In this example, a schedule (swap schedule) for swapping between a leading vehicle and a trailing vehicle may be set at each energy refueling point included in the operation plan. A operation plan including an energy refueling point where a swap schedule is set indicates, for the energy refueling point, the time (swap time) at which the two vehicles will swap and the identification information (vehicle ID) of each swapping vehicle. In the operation plan, the coincidence of the time (estimated arrival time) at which the trailing vehicle arrives at a certain energy refueling point and the time (estimated departure time) at which the leading vehicle departs from the energy refueling point means that a swap schedule is set at the energy refueling point. In FIG. 10, the vehicle 1B is refueling (e.g., plugging in and charging the battery 160) at the refueling point P3. Vehicle 1B is the preceding vehicle. The following vehicle is vehicle 1A. The series of processes shown in FIG. 10 is executed by, for example, the control device 150 (FIG. 3) of vehicle 1B.

[0109] 1 to 3 as well as FIG. 10, in S201, vehicle 1B determines whether a swap schedule is set for resupply point P3 in the operation plan of vehicle 1B. If a swap schedule is not set for resupply point P3 (NO in S201), vehicle 1B determines in S202 whether the scheduled departure time from resupply point P3 indicated in the operation plan of vehicle 1B has arrived. While the scheduled departure time from resupply point P3 has not arrived (NO in S202), vehicle 1B repeats the processes of S201 and S202 while resupplying with energy at resupply point P3. Then, when the scheduled departure time from resupply point P3 arrives (YES in S202), vehicle 1B departs from resupply point P3 by automatic driving in S206.

[0110] If a swap schedule is set for the supply point P3 (YES in S201), vehicle 1B determines in S203 whether the current time is within a predetermined departure period. The departure period is determined based on the scheduled departure time from the supply point P3 indicated in the operation plan of vehicle 1B. 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.

[0111] If the current time is not within the possible departure period (NO in S203), the process returns to S201. Therefore, vehicle 1B will not depart from supply point P3 until the start time of the possible departure period arrives. If the current time is within the possible departure period (YES in S203), vehicle 1B determines in S204 whether the end time of the possible departure period has arrived. If the end time of the possible departure period has not arrived (NO in S204), vehicle 1B determines in S205 whether the following vehicle (vehicle 1A) has approached supply point P3.

[0112] When vehicle 1A approaches refueling point P3 (for example, when it approaches refueling point P3 to within a predetermined distance), vehicle 1A may transmit a departure request signal including its own vehicle ID to vehicle 1B via wireless communication. Vehicle 1B may determine whether vehicle 1A has approached refueling point P3 based on the signal from vehicle 1A. For example, vehicle 1B determines that vehicle 1A is not approaching refueling point P3 while it does not receive a departure request signal. Vehicle 1B determines that vehicle 1A (the following vehicle that will replace vehicle 1A at refueling point P3) has approached refueling point P3 when the vehicle ID indicated in the received departure request signal matches the vehicle ID of the following vehicle indicated in the operation plan.

[0113] If vehicle 1A is not approaching supply point P3 (NO in S205), the process returns to S201. Vehicle 1B waits for the arrival of vehicle 1A during the departure possible period. Then, when vehicle 1A approaches supply point P3 (YES in S205), vehicle 1B departs from supply point P3 by automatic driving in S206. Then, vehicle 1A enters supply point P3. As a result, vehicle 1A and vehicle 1B are swapped at supply point P3. Even if vehicle 1A is delayed compared to the operation plan and does not arrive at supply point P3 within the departure possible period, and the end time of the departure possible period arrives before vehicle 1A arrives at supply point P3 (YES in S204), vehicle 1B departs from supply point P3 by automatic driving in S206. However, in this case, the planned swap of vehicles 1A and 1B is not executed.

[0114] As described above, in the example shown in FIG. 10 , vehicle 1B (third moving body) and vehicle 1A (fourth moving body) are instructed to operate according to an operation plan that includes a schedule in which vehicle 1B (third moving body) and vehicle 1A (fourth moving body) are scheduled to switch places at the supply point P3. When vehicle 1B approaches the supply point P3 while refueling at the supply point P3, vehicle 1B departs from the supply point P3. This configuration makes it more likely that vehicle 1A will enter the supply point P3 just as vehicle 1B leaves the supply point P3. By having the leading vehicle 1B and the trailing vehicle 1A switch places at the supply point P3 (not leaving the supply point P3 empty), it is possible to prevent the supply point P3 from being occupied by another vehicle (e.g., a vehicle unrelated to the operation plan) after the leading vehicle 1B leaves the supply point P3 (i.e., the trailing vehicle 1A from being able to use the supply point P3). Regardless of whether another vehicle has the right to use the supply point P3, if a space is available, another vehicle may use that space.

[0115] In the above embodiment, a driverless robotaxi vehicle is exemplified as vehicle 1. When a robotaxi vehicle receives driving instructions from server 500 (S15 in FIGS. 6 and 9), it drives according to a driving plan through autonomous driving. However, vehicle 1 is not limited to a robotaxi vehicle. Vehicle 1 may also be configured so that a driver drives according to a driving plan. For example, when vehicle 1 receives driving instructions from server 500, the vehicle may display the contents of the driving instructions on an in-vehicle HMI (e.g., NAVI 170). The driver may drive according to the driving plan while checking the driving plan on the in-vehicle HMI. However, driving at a vehicle speed specified by server 500 is more likely to be performed accurately with autonomous driving than with manual driving.

[0116] The configuration of the vehicle 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 retrofitting. The level of autonomous driving may be fully autonomous (Level 5) or conditionally autonomous (for example, Level 4). The configuration of the vehicle may be appropriately changed to a configuration dedicated to unmanned driving. For example, a vehicle dedicated to unmanned driving may not be equipped with parts for a person to operate the vehicle (such as a steering wheel). The vehicle may be configured to be capable of contactless charging.

[0117] In the above embodiment, the multiple vehicles receiving instructions from the server 500 have the same configuration. However, this is not limited to this, and the multiple vehicles managed by the server 500 may have different configurations. The multiple vehicles may include at least one type of vehicle: an xEV (HEV, PHEV) equipped with an internal combustion engine, an FCEV, and an internal combustion engine vehicle without an electric motor for driving, instead of or in addition to a BEV without an internal combustion engine. The vehicle is not limited to a passenger car, but may also be a bus or truck. The vehicle may also be a multipurpose vehicle customized according to the user's intended use. Instead of or in addition to a vehicle, a moving object other than a vehicle (such as a railroad vehicle, a ship, an airplane, a walking robot, a robot cleaner, a drone, or a space probe) may be employed. The moving object may be configured to be remotely controlled. The energy replenishment point may be any location where a moving object can replenish energy.

[0118] The task is not limited to the transportation described above. The task may be any task that can be performed by a mobile object, such as a mobile store, a mobile office, or a mobile hospital (medical task).

[0119] The above-described embodiment and each modification may be implemented in any combination. The embodiments disclosed herein should be considered to be illustrative in all respects and not restrictive. The technical scope of the present disclosure is defined by the claims, not by the description of the above embodiments, and is intended to include all modifications within the meaning and scope of the claims. [Explanation of symbols]

[0120] 1,1A,1B,1C,1D Vehicle, 2 VP, 100 Base vehicle, 102 Control system, 115 Integrated control manager, 130 Communication equipment, 150 Control device, 160 Battery, 170 NAVI, 200 ADK, 202 ADS, 210 Computer, 500 Server, UT Mobile terminal.

Claims

1. A server that manages a plurality of mobile objects, the server is configured to determine an operation plan for each of the plurality of moving bodies and instruct each of the plurality of moving bodies to operate in accordance with the determined operation plan; The operation plan includes a plan regarding energy replenishment for operation, The server determining whether or not a conflict occurs between the plurality of moving bodies in refueling at the same location and at the same time based on the operation plan; When it is determined that the conflict will occur, modifying the operation plan of at least one of the plurality of conflicting moving objects so as to avoid the conflict; configured to run The operation plan includes an energy refueling point and a duration of stay at the energy refueling point, Before instructing each of the multiple moving bodies to operate, the server determines based on the operation plan that a leading first moving body and a following second moving body will compete at the energy replenishment point, and if the remaining energy of the first moving body at the time of competition predicted from the operation plan is greater than a reference amount, changes the stay period of the first moving body at the energy replenishment point so that the first moving body departs from the energy replenishment point at the time of competition.

2. The server of claim 1, wherein before instructing each of the plurality of moving bodies to operate, if the server determines based on the operation plan that the first moving body and the second moving body will compete at the energy replenishment point and the remaining energy of the first moving body at the time the competition occurs is less than the reference amount, the server changes the stay period of the first moving body at the energy replenishment point so that the first moving body departs from the energy replenishment point at the time the remaining energy of the first moving body reaches the reference amount.

3. The server according to claim 1 , wherein, when there are a plurality of operation plans that can avoid the conflict, the server is configured to select an operation plan with the lowest risk of running out of energy from among the plurality of operation plans.

4. The server according to claim 1 , wherein, when there are a plurality of operation plans that can avoid the conflict, the server is configured to select the most energy-efficient operation plan from the plurality of operation plans.

5. 5. A navigation system comprising: the server according to claim 1; and the plurality of mobile objects that receive instructions from the server.

6. the plurality of moving bodies include a third moving body and a fourth moving body, each of the third moving body and the fourth moving body is an autonomous vehicle; The operation system described in claim 5, wherein the third moving body that is instructed to operate according to the operation plan that includes a schedule in which the third moving body and the fourth moving body are to switch places at an energy replenishment point departs from the energy replenishment point when the fourth moving body approaches while staying at the energy replenishment point.

7. An operation system including a server that manages a plurality of moving objects, and the plurality of moving objects that receive instructions from the server, the server is configured to determine an operation plan for each of the plurality of moving bodies and instruct each of the plurality of moving bodies to operate in accordance with the determined operation plan; The operation plan includes a plan regarding energy replenishment for operation, The server determining whether or not a conflict occurs between the plurality of moving bodies in refueling at the same location and at the same time based on the operation plan; When it is determined that the conflict will occur, modifying the operation plan of at least one of the plurality of conflicting moving objects so as to avoid the conflict; configured to run the plurality of moving bodies include a third moving body and a fourth moving body, each of the third moving body and the fourth moving body is an autonomous vehicle; A travel system in which the third moving body, which has been instructed to operate according to the operation plan including a schedule in which the third moving body and the fourth moving body will switch places at an energy replenishment point, departs from the energy replenishment point when the fourth moving body approaches while staying at the energy replenishment point.

Images