Computers, vehicles, servers, and mobile devices

Abstract

To provide a computer that, when an abnormality occurs in a vehicle being automatically operated, can perform processing to the vehicle promptly and properly, and provide a vehicle, a server, a mobile terminal and a vehicle management method.SOLUTION: The computer comprises a diagnosing part that determines whether a vehicle, which cannot continue to travel by automatic operation because of an abnormality, can be restored or not on the spot and whether the vehicle can travel by manual operation or not. The computer may be mounted on any of a vehicle, a server and a mobile terminal.SELECTED DRAWING: Figure 8

Description

[Technical field]

[0001] The present disclosure relates to a computer, a vehicle, a server, a mobile terminal, and a vehicle management method. [Background technology]

[0002] Japanese Patent Application Publication No. 2020-074169 (Patent Document 1) discloses a vehicle system that dispatches autonomous vehicles. [Prior art documents] [Patent documents]

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

[0004] As autonomous driving technology improves in the future, it is expected that there will be an increasing number of cases where users who are inexperienced at driving (users who do not have driving skills) or users who are not familiar with cars use autonomous vehicles that run without an administrator as a means of transportation. If an abnormality occurs in an autonomous vehicle while such a user is using the vehicle and it is no longer possible to continue driving autonomously, the user may be unable to deal with the situation on their own and may be at a loss. Even if the user is able to call a support center for help by mobile phone, the user may not be able to explain the situation accurately, and it may take a long time for the user to be rescued.

[0005] The present disclosure has been made to solve the above-mentioned problems, and its purpose is to provide a computer, a vehicle, a server, a mobile terminal, and a vehicle management method that are capable of taking early and appropriate measures on a vehicle when an abnormality occurs in the vehicle during autonomous driving. [Means for solving the problem]

[0006] A computer according to a first aspect of the present disclosure includes a diagnosis unit that determines whether a vehicle that has developed an abnormality and can no longer continue driving autonomously can be restored on the spot and whether the vehicle can be driven manually, and a response unit that executes a predetermined process depending on the result of the determination made by the diagnosis unit.

[0007] The computer automatically judges the vehicle's condition. Then, a predetermined process is executed according to the judgment result. Therefore, even if an abnormality occurs in a vehicle used by a user who is inexperienced in driving (a user who does not have driving skills) or a user who is not familiar with cars, it is possible to take appropriate measures for the vehicle promptly.

[0008] The countermeasure unit may be configured to arrange for a tow truck to tow the vehicle when the diagnosis unit determines that the vehicle cannot be restored on the spot and that the vehicle cannot be driven manually. The countermeasure unit may be configured not to arrange for a tow truck when the diagnosis unit determines that the vehicle can be restored on the spot and when the diagnosis unit determines that the vehicle can be driven manually.

[0009] The computer automatically determines whether or not a tow truck is required. Since the tow truck arrangement is made automatically, even if an abnormality occurs in a vehicle used by a user who is inexperienced in driving or who is not familiar with cars, a tow truck can be arranged promptly and appropriately. In addition, if it is determined that a tow truck is not required, a tow truck is not arranged, thereby preventing an increase in costs due to unnecessary tow truck arrangements.

[0010] The response unit may be configured to, when the diagnosis unit determines that the vehicle can be restored on the spot, display a manual showing the restoration procedures on at least one of a terminal installed in the vehicle and a terminal of a user using the vehicle.

[0011] According to the above configuration, the user can easily complete the recovery work in a short time by performing the recovery work according to the manual. The terminal installed in the vehicle may be a car navigation system. The terminal of the user using the vehicle may be a mobile terminal (for example, a smartphone or a wearable device).

[0012] In the above computer, the diagnosis unit may be configured to revoke the above-mentioned judgment that the vehicle in which the abnormality has occurred can be restored on the spot, and to judge that the vehicle in which the abnormality has occurred cannot be restored on the spot, when a user inputs an instruction to stop work into the terminal displaying the manual.

[0013] According to the above configuration, it becomes easier to accurately determine whether an abnormality occurring in an autonomous vehicle can be restored on the spot. More specifically, when an erroneous decision is made by a computer, it becomes possible to correct the erroneous decision by prioritizing the decision of the user.

[0014] The diagnosis unit may be configured to determine whether a method for dealing with the abnormality is obvious and whether the vehicle in which the abnormality has occurred can be restored within a predetermined time. The diagnosis unit may be configured to determine that the vehicle in which the abnormality has occurred can be restored on the spot if a method for dealing with the abnormality is obvious and the vehicle in which the abnormality has occurred can be restored within a predetermined time.

[0015] According to the above configuration, it becomes easier to accurately determine whether an autonomously driven vehicle in which an abnormality has occurred can be restored on the spot.

[0016] In the above computer, the diagnosis unit may be configured to determine whether or not a vehicle in which an abnormality has occurred can be restored within a predetermined time period, using user information related to a user who is using the vehicle.

[0017] According to the above configuration, it becomes easier to accurately determine whether an autonomously driven vehicle in which an abnormality has occurred can be restored within a specified time period, using user information about the user currently using the vehicle.

[0018] The diagnosis unit may be configured to determine whether the vehicle can be switched to manual driving and whether a person capable of manually driving the vehicle is in the vehicle. The diagnosis unit may be configured to determine that the vehicle can be driven manually when the vehicle can be switched to manual driving and a person capable of manually driving the vehicle is in the vehicle.

[0019] According to the above configuration, it becomes easier to accurately determine whether an autonomous vehicle in which an abnormality has occurred can be driven manually. The diagnosis unit may determine that the vehicle can be switched to manual driving when the abnormality that has occurred in the vehicle does not impede manual driving.

[0020] The diagnosis unit may be configured to determine whether or not a person capable of manually driving the vehicle is in the vehicle by using an output of a sensor that detects whether or not a person is in the vehicle and user information related to a user who is using the vehicle. With such a configuration, it becomes easier to accurately determine whether or not a person capable of manually driving the vehicle is in the vehicle.

[0021] The countermeasure unit may be configured to execute a driving assistance process when the vehicle that has become unable to continue autonomous driving due to an abnormality can be driven manually. With such a configuration, the vehicle can be driven appropriately manually. The driving assistance process may be a display of a destination or driving assistance by an ADAS (advanced driving assistance system).

[0022] A vehicle according to a second aspect of the present disclosure includes a control device. The vehicle further includes an autonomous driving kit and a vehicle control interface that mediates signal exchange between the control device and the autonomous driving kit. The autonomous driving kit is configured to send commands for autonomous driving to the control device via the vehicle control interface. The control device is configured to control the vehicle according to commands from the autonomous driving kit. The control device is configured to send signals indicating a state of the vehicle to the autonomous driving kit via the vehicle control interface. The control device or the autonomous driving kit includes any of the computers described above.

[0023] Since the vehicle includes the above-mentioned computer, when an abnormality occurs in the vehicle during automatic driving, measures can be taken promptly and appropriately for the vehicle.

[0024] A server according to a third aspect of the present disclosure includes any one of the computers described above. Since the server includes the computer described above, when an abnormality occurs in a vehicle during automatic driving, measures can be taken promptly and appropriately for the vehicle.

[0025] A mobile terminal according to a fourth aspect of the present disclosure includes any one of the computers described above. Since the mobile terminal includes the computer described above, when an abnormality occurs in a vehicle that is being driven autonomously, measures can be taken promptly and appropriately for the vehicle.

[0026] A vehicle management method according to a fifth aspect of the present disclosure includes the following first judgment, second judgment, third judgment, and tow truck arrangement.

[0027] In the first judgment, the computer determines whether an abnormality has occurred in the vehicle during autonomous driving that prevents it from continuing to drive autonomously. In the second judgment, the computer determines whether the vehicle with the abnormality can be restored on the spot. In the third judgment, the computer determines whether the vehicle with the abnormality can be driven manually. In the towing arrangement, if the vehicle with the abnormality cannot be restored on the spot and the vehicle with the abnormality cannot be driven manually, the computer will arrange for a tow truck to be towed away.

[0028] Like the above-mentioned computer, the vehicle management method makes it possible to take prompt and appropriate measures for a vehicle when an abnormality occurs in the vehicle during automatic driving. Effect of the Invention

[0029] According to the present disclosure, when an abnormality occurs in a vehicle during autonomous driving, it becomes possible to take early and appropriate measures for the vehicle. [Brief description of the drawings]

[0030] [Figure 1] 1 is a diagram showing a schematic configuration of a vehicle according to an embodiment of the present disclosure. [Diagram 2] FIG. 2 is a diagram showing details of a control system for the vehicle shown in FIG. [Diagram 3] 4 is a flowchart showing a processing procedure of automatic driving control according to an embodiment of the present disclosure. [Figure 4] FIG. 2 is a diagram for explaining details of a control device and various systems provided in the vehicle shown in FIG. [Diagram 5] 2 is a flowchart illustrating a vehicle management method according to an embodiment of the present disclosure. [Figure 6] 6 is a flowchart showing details of a process for restoring a vehicle in which an abnormality has occurred in the vehicle management method shown in FIG. 5. [Figure 7]7 is a flowchart showing details of on-site restoration measures (restoration measures without moving the vehicle) in the restoration process shown in FIG. 6. [Figure 8] 7 is a flowchart showing details of a recovery response involving movement of a vehicle in the recovery process shown in FIG. 6. [Figure 9] 6 is a flowchart showing a first modified example of the process shown in FIG. 5. [Figure 10] 6 is a flowchart showing a second modified example of the process shown in FIG. 5. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

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

[0033] VP2 includes a control system of the base vehicle 100 and a vehicle control interface box (hereinafter, referred to as "VCIB (Vehicle Control Interface Box)") 111 provided in the base vehicle 100. The VCIB 111 may communicate with the ADK 200 through an in-vehicle network such as a Controller Area Network (CAN). Note that while the base vehicle 100 and the ADK 200 are shown in separate locations in FIG. 1, the ADK 200 is actually attached to the base vehicle 100. In this embodiment, the ADK 200 is attached to the roof top of the base vehicle 100. However, the attachment location of the ADK 200 can be changed as appropriate.

[0034] Base vehicle 100 is, for example, a commercially available xEV (electric vehicle). An xEV is a vehicle that uses electricity as all or part of its power source. In this embodiment, a BEV (electric vehicle) is adopted as base vehicle 100. However, the present invention is not limited to this, and base vehicle 100 may be an xEV (HEV, PHEV, FCEV, etc.) other than a BEV. The number of wheels provided on base vehicle 100 is, for example, four wheels. However, the present invention is not limited to this, and the number of wheels provided on base vehicle 100 may be three wheels, or five or more wheels.

[0035] 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 various sensors included in the base vehicle 100.

[0036] In this embodiment, the integrated control manager 115 includes a control device 150. The control device 150 includes a processor 151, a 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 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 includes, for example, a ROM (Read Only Memory) and a rewritable non-volatile memory. In addition to programs, information used in the programs (for example, maps, formulas, and various parameters) is stored in the storage device 153. In this embodiment, various vehicle controls (for example, automatic driving control following instructions from the ADK 200) are executed by the processor 151 executing the programs stored in the storage device 153. However, these processes may be executed by dedicated hardware (electronic circuits) instead of software. The number of processors included in the control device 150 is arbitrary, and a processor may be prepared for each predetermined control.

[0037] 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 through an in-vehicle network (e.g., CAN). Hereinafter, the computer included in each system is referred to as an "ECU (Electronic Control Unit)."

[0038] 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 adopted as the brake device. The base vehicle 100 is equipped with wheel speed sensors 127A, 127B. The wheel speed sensor 127A is provided on the front wheels of the base vehicle 100 and detects the rotation speed of the front wheels. The wheel speed sensor 127B is provided on the rear wheels of the base vehicle 100 and detects the rotation speed of the rear wheels. The ECU of the brake system 121 outputs the rotation direction and rotation speed of each wheel detected by the wheel speed sensors 127A, 127B to the integrated control manager 115.

[0039] 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) that allows the steering angle to 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 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.

[0040] 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 be able to select a shift range, a drive source of the base vehicle 100, and an ECU that controls each device included in the powertrain system 123. The EPB is provided separately from the above-mentioned braking device and fixes the wheels by an electric actuator. The P-Lock device fixes the rotational position of the output shaft of the transmission by, for example, a parking lock pole that can be driven by an actuator. Although details will be described later, in this embodiment, a motor that receives power from a battery is used as the drive source of the base vehicle 100. The ECU of the powertrain system 123 outputs to the integrated control manager 115 the presence or absence of fixation by the EPB and the P-Lock device, the shift range selected by the shift device, and the respective states of the battery and the motor (see FIG. 4 described later).

[0041] The active safety system 125 includes an ECU that determines the possibility of a collision for the vehicle 1 during travel. The base vehicle 100 includes 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. When 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 includes 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 be adopted.

[0042] The body system 126 includes body system parts (e.g., a turn signal, a horn, and a wiper) and an ECU that controls the body system parts. In the manual mode, the ECU of the body system 126 controls the body system parts according to a user operation, and in the autonomous mode, the ECU controls the body system parts according to a command received from the ADK 200 via the VCIB 111 and the integrated control manager 115.

[0043] The vehicle 1 is configured to be capable of automatic driving. The VCIB 111 functions as a vehicle control interface. When the vehicle 1 runs in automatic driving, the integrated control manager 115 and the ADK 200 exchange signals with each other via the VCIB 111, and the integrated control manager 115 executes driving control in an autonomous mode (i.e., automatic driving control) according to a command from the ADK 200. The ADK 200 can also be removed from the base vehicle 100. The base vehicle 100 can run by itself by driving the user even when the ADK 200 is removed. When the base vehicle 100 runs by itself, the control system of the base vehicle 100 executes driving control in a manual mode (i.e., driving control according to a user's operation).

[0044] 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 the vehicle 1, and outputs various commands to the VCIB111 according to the API, requesting control for driving the vehicle 1 according to the created driving plan. Hereinafter, each of the various commands output from the ADK200 to the VCIB111 is also referred to as an "API command." In addition, the ADK200 receives various signals indicating the state of the base vehicle 100 from the VCIB111 according to the API, and reflects the received state of the base vehicle 100 in the creation of the driving plan. Hereinafter, each of the various signals received by the ADK200 from the VCIB111 is also referred to as an "API signal." Both the API command and the API signal correspond to signals defined by the API. Details of the configuration of the ADK200 will be described later (see FIG. 2).

[0045] The VCIB 111 receives various API commands from the ADK 200. When the VCIB 111 receives an API command from the ADK 200, it converts the API command into a signal format that can be processed by the integrated control manager 115. Hereinafter, the API command converted into a signal format that can be processed by the integrated control manager 115 is also referred to as a "control command." When the VCIB 111 receives an API command from the ADK 200, it outputs a control command corresponding to the API command to the integrated control manager 115.

[0046] The control device 150 of the integrated control manager 115 sends various signals (for example, sensor signals or status signals) indicating the state of the base vehicle 100 detected in the control system of the base vehicle 100 to the ADK 200 via the VCIB 111. The VCIB 111 sequentially receives signals indicating the state of the base vehicle 100 from the integrated control manager 115. The VCIB 111 determines the value of an API signal based on the signal received from the integrated control manager 115. Furthermore, the VCIB 111 converts the signal received from the integrated control manager 115 into an API signal format as necessary. Then, the VCIB 111 outputs the obtained API signal to the ADK 200. The API signal indicating the state of the base vehicle 100 is sequentially output from the VCIB 111 to the ADK 200 in real time.

[0047] In this embodiment, signals with low versatility defined by, for example, an automobile manufacturer are exchanged between the integrated control manager 115 and the VCIB 111, and signals with higher versatility (for example, signals defined by a public API (Open API)) are exchanged between the ADK 200 and the VCIB 111. The VCIB 111 converts signals between the ADK 200 and the integrated control manager 115, thereby enabling the integrated control manager 115 to control the vehicle according to instructions from the ADK 200. However, the function of the VCIB 111 is not limited to the function of converting the signals. For example, the VCIB 111 may make a predetermined judgment and send a signal based on the judgment result (for example, a signal for notifying, instructing, or requesting) to at least one of the integrated control manager 115 and the ADK 200. The configuration of the VCIB 111 will be described in detail later (see FIG. 2).

[0048] 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 (for example, a mobile terminal UT and a server 500 described later) outside the vehicle 1 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). The communication device 130 communicates with the server 500 via the mobile communication network. The wireless communication device may include a communication I / F compatible with 5G (fifth generation mobile communication system). The communication device 130 also includes a communication I / F for directly communicating with a mobile terminal UT present in the vehicle or within a range around the vehicle. The communication device 130 and the mobile terminal UT may perform short-range communication such as a wireless LAN (Local Area Network), NFC (Near Field Communication), or Bluetooth (registered trademark).

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

[0050] The vehicle 1 described above may be employed as one of the components of a MaaS (Mobility as a Service) system. The MaaS system includes, for example, an MSPF (Mobility Service Platform). The 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 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 mobilities and provides information (for example, APIs and information on cooperation between mobilities) in response to requests from operators. An operator providing a service can use various functions provided by the MSPF using the APIs published on the MSPF. For example, APIs required for the development of an ADK are published on the MSPF.

[0051] 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. In addition to programs, the storage device 503 stores information used in the programs (e.g., maps, formulas, and various parameters). The HMI (Human Machine Interface) 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.

[0052] 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 autonomously driving the vehicle 1. The ADS 202 includes a computer 210, an HMI (Human Machine Interface) 230, a recognition sensor 260, an attitude sensor 270, and a sensor cleaner 290.

[0053] The computer 210 includes a processor and a storage device that stores autonomous driving software that uses the API, and is configured to be able to execute the autonomous driving software by the processor. The autonomous driving software executes control related to autonomous driving (see FIG. 3 described later). The autonomous driving software may be updated sequentially by OTA (Over The Air). The computer 210 further includes communication modules 210A and 210B.

[0054] 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 (limited to those that are permitted to be changed) used in the autonomous driving software. The HMI 230 may be a touch panel display that combines the functions of both an input device and a notification device.

[0055] 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 captures 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 by 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 recognizable range 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.

[0056] The attitude sensor 270 acquires information on 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 GPS (Global Positioning System) sensor. The IMU detects the acceleration in each of the forward / rearward, left / right, and up / down directions of the vehicle 1, and the angular velocity in each of the roll direction, pitch direction, and yaw direction of the vehicle 1. The GPS sensor detects the position of the vehicle 1 using signals received from multiple GPS satellites. In the fields of automobiles and aircraft, a technique for measuring the attitude with high accuracy by combining the IMU and GPS is known. The computer 210 may measure the attitude of the vehicle 1 from the attitude information by using, for example, such a known technique.

[0057] The sensor cleaner 290 is a device that removes dirt from a sensor (e.g., the recognition sensor 260) that is 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.

[0058] In vehicle 1, certain functions (for example, braking, steering, and vehicle immobilization) are provided with redundancy in order to improve safety. Control system 102 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 the equivalent function, the function in question works normally in vehicle 1 because the other operates normally.

[0059] The VCIB 111 includes a VCIB 111A and a VCIB 111B. Each of the VCIBs 111A and 111B includes a computer. The communication 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 the VCIB 111B are connected to be able to 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 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 connection destinations of the VCIBs 111A and VCIBs 111B are partially different.

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

[0061] The vehicle 1 is configured to be able to switch between an autonomous mode and a manual mode. The API signal that the ADK 200 receives from the VCIB 111 includes a signal indicating whether the vehicle 1 is in the autonomous mode or the manual mode (hereinafter, referred to as the "autonomous state"). The user can select either the autonomous mode or the manual mode through a predetermined input device (for example, the HMI 230 or the mobile terminal UT). When either driving mode is selected by the user, the vehicle 1 enters the selected driving mode, and the selection result is reflected in the autonomous state. However, if the vehicle 1 is not in a state capable of automatic driving, the vehicle 1 does not transition to the autonomous mode even if the user selects the autonomous mode. The driving mode of the vehicle 1 may be switched by the integrated control manager 115. The integrated control manager 115 may switch between the autonomous mode and the manual mode depending on the situation of the vehicle 1.

[0062] When the vehicle 1 is in the autonomous mode, the computer 210 acquires the state of the vehicle 1 from the VP2 and sets the next operation (for example, acceleration, deceleration, and turning) of the vehicle 1. Then, the computer 210 outputs various commands for realizing the set next operation of the vehicle 1. The computer 210 executes API software (i.e., autonomous driving software using API), whereby commands related to autonomous driving control are transmitted from the ADK 200 to the integrated control manager 115 via the VCIB 111.

[0063] Fig. 3 is a flowchart showing the processing executed by the ADK 200 in the autonomous driving control according to this embodiment. The processing shown in this flowchart is repeatedly executed at a period corresponding to the API (API period) when the vehicle 1 is in the autonomous mode. When the driving mode of the vehicle 1 is switched from the manual mode to the autonomous mode, a start signal indicating the start of autonomous driving is transmitted from the vehicle 1 (communication device 130) to the server 500 together with the identification information of the vehicle 1, and then a series of processing shown in Fig. 3 described below is started. Below, each step in the flowchart is simply denoted as "S".

[0064] 1 and 2 and FIG. 3, in S101, the computer 210 acquires current information of the vehicle 1. For example, the computer 210 acquires environmental information and attitude information of the vehicle 1 from the recognition sensor 260 and the attitude sensor 270. Furthermore, the computer 210 acquires an API signal. In this embodiment, whether the vehicle 1 is in the autonomous mode or the manual mode, an API signal indicating the state of the vehicle 1 is output from the VCIB 111 to the ADK 200 in real time. In order to improve the accuracy of the automatic driving control, in the autonomous mode, the state of the vehicle 1 may be transmitted from the integrated control manager 115 to the ADK 200 in a shorter period than in the manual mode. The API signal acquired by the computer 210 includes, in addition to the above-mentioned autonomous state, a signal indicating the rotation direction and rotation speed of each wheel detected by the wheel speed sensors 127A and 127B.

[0065] In S102, the computer 210 creates a driving plan based on the information of the vehicle 1 acquired in S101. For example, the computer 210 calculates the behavior of the vehicle 1 (for example, the attitude of the vehicle 1) and creates a driving plan suitable for the state of the vehicle 1 and the external environment. The driving plan is data indicating the behavior of the vehicle 1 in a predetermined period of time. If a driving plan already exists, the driving plan may be modified in S102.

[0066] In S103, the computer 210 extracts control-related physical quantities (such as acceleration and tire turning angle) from the driving plan created in S102. In S104, the computer 210 divides the physical quantities extracted in S103 for each API period. In S105, the computer 210 executes the API software using the physical quantities divided in S104. By executing the API software in this manner, API commands (such as a propulsion direction command, a propulsion command, a braking command, and a vehicle fixing command) that request control to realize the physical quantities according to the driving plan are transmitted from the ADK 200 to the VCIB 111. The VCIB 111 transmits a control command corresponding to the received API command to the integrated control manager 115, and the integrated control manager 115 performs automatic driving control of the vehicle 1 according to the control command.

[0067] In the next step S106, the computer 210 determines whether the vehicle 1 is in the autonomous mode. While the autonomous mode continues (YES in S106), the above-mentioned steps S101 to S105 are repeatedly executed, thereby executing the autonomous driving of the vehicle 1. On the other hand, when the vehicle 1 enters the manual mode (NO in S106), in S107, an end signal indicating the end of the autonomous driving is transmitted from the vehicle 1 (communication device 130) to the server 500 together with the identification information of the vehicle 1, and then the series of processes shown in FIG. 3 ends. In this embodiment, the computer 210, the VCIB 111, and the integrated control manager 115 cooperate to execute control for driving the vehicle 1 in the autonomous driving mode. The vehicle 1 can perform the autonomous driving in both manned and unmanned states. Note that the autonomous driving control is not limited to the control shown in FIG. 3, and other control (known autonomous driving control) may be adopted.

[0068] Fig. 4 is a diagram for explaining details of the control device 150 and various systems provided in the vehicle 1. With reference to Fig. 4 together with Figs. 1 and 2, the vehicle 1 includes an MG (Motor Generator) 20, an ECU 21, a PCU (Power Control Unit) 22, a braking device 30, a brake sensor 30a, an air pressure sensor 30b, an occupancy sensor 40, a battery 160, a navigation system (hereinafter also referred to as "NAVI") 170, a reader 180, and driving wheels W. The MG 20, the ECU 21, and the PCU 22 are included in a propulsion system 123C. The braking device 30 and the brake sensor 30a are included in a brake system 121 (Fig. 1).

[0069] The battery 160 supplies power to the propulsion system 123C. A known vehicle power storage device (for example, a liquid secondary battery, an all-solid-state secondary battery, or a battery pack) can be used as the battery 160. Examples of the vehicle secondary battery include a lithium ion battery and a nickel metal hydride battery. The battery 160 is configured to be contact-chargeable (plug-in chargeable).

[0070] The battery 160 is provided with a monitoring module 160a. The monitoring module 160a 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 monitoring module 160a may be a BMS (Battery Management System) that further has a SOC (State Of Charge) estimation function in addition to the above-mentioned sensor function. The control device 150 can acquire the state of the battery 160 (for example, temperature, current, voltage, and SOC) based on the output of the monitoring module 160a. The SOC indicates the remaining amount of electricity, and is, for example, the ratio of the current amount of electricity to the amount of electricity in a fully charged state, expressed as 0 to 100%.

[0071] The propulsion system 123C generates driving force for the vehicle 1 to travel by 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 (hereinafter referred to as "System Main Relay (SMR)"). The PCU 22 is controlled by the ECU 21. The SMR is configured to switch between connection and disconnection of an electric path from the battery 160 to the MG 20. The SMR is set in a closed state (connected state) when the vehicle 1 is traveling.

[0072] The MG 20 is driven by the PCU 22 to rotate the drive wheels W of the vehicle 1. The MG 20 also generates regenerative power 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 have any number of motors (MG 20) for running, and may have one, two, or three or more motors. The motor for running may be an in-wheel motor. Although FIG. 4 shows only one drive wheel W, the number and drive system of the drive wheels W in the vehicle 1 are arbitrary. The drive system of the vehicle 1 may be any of front-wheel drive, rear-wheel drive, and four-wheel drive.

[0073] Each wheel (including the drive wheel W) of the vehicle 1 is provided with a braking device 30, a brake sensor 30a that detects the braking force applied to the wheel by the braking device 30, and an air pressure sensor 30b that detects the air pressure of the tire. The brake sensor 30a may be a hydraulic sensor that detects the hydraulic pressure applied to the brake pad (or the wheel cylinder). The braking forces (e.g., hydraulic pressures corresponding to the braking forces) for each wheel detected by each of the four brake sensors 30a are output to the integrated control manager 115. The detection result of the air pressure sensor 30b is also output to the integrated control manager 115.

[0074] The occupancy sensor 40 is configured to detect whether or not a person is present in the vehicle 1. More specifically, the occupancy 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 occupancy sensor 40 includes at least one of a camera and an infrared sensor facing the interior of the vehicle. The occupancy 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 occupied or unoccupied based on the output of the occupancy sensor 40.

[0075] NAVI170 includes a touch panel display, a GPS module, and a storage device (none of which are shown). The storage device stores map information. The touch panel display accepts input from a user in the vehicle and displays the map and other information. The GPS module is configured to receive signals (hereinafter referred to as "GPS signals") from GPS satellites (not shown). NAVI170 can identify the position of the vehicle 1 using the GPS signals. NAVI170 is configured to display the position of the vehicle 1 on a map in real time. NAVI170 is configured to perform route search to find the optimal route (e.g., the shortest route) from the current position of the vehicle 1 to the destination by referring to the map information. NAVI170 may update the map information successively by OTA.

[0076] 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 may be any method. For example, the reader 180 may be an RFID (Radio Frequency Identification) reader.

[0077] A vehicle manager manages a vehicle 1 using the server 500. In this embodiment, only the vehicle 1 is mentioned, but the vehicle manager may manage a large number of vehicles using the server 500. The vehicle manager may provide a passenger transportation service or a vehicle dispatch service. The server 500 may manage service usage fees for each user.

[0078] The vehicle 1 provides a service by automatic driving in the absence of a driver. That is, there is no vehicle manager in the vehicle 1. Basically, only the service users get on the vehicle 1, and when all the service users get off, the vehicle 1 becomes unmanned. The vehicle 1 may travel around a predetermined route in an operating area by automatic driving, for example, like a route bus. The vehicle 1 may also determine a route in response to each request and perform automatic driving according to the determined route (on-demand route). During the automatic driving of the vehicle 1, the process shown in FIG. 3 is executed, and the control device 150 controls various systems of the vehicle 1 (for example, the brake system 121, steering system 122, power train system 123, active safety system 125, and body system 126 shown in FIG. 2) according to commands from the ADK 200.

[0079] The server 500 can identify a user who is using the vehicle 1 and notify the vehicle manager of information about the user. 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 the user ID. In this embodiment, each user registered in the server 500 carries a mobile terminal UT. The user information includes, for example, vehicle maintenance skill information indicating the level of the user's vehicle maintenance skill, driving skill information indicating the level of the user's driving skill, and the address of the mobile terminal UT carried by the user. The driving skill information indicates whether the user has a license to manually drive the vehicle 1 and the driving proficiency.

[0080] The mobile terminal UT has application software (hereinafter, referred to as a "mobile app") installed therein for using the vehicle 1. When a user uses the vehicle 1, the mobile terminal UT displays an image including the user's identification information (user ID). When the user holds the mobile terminal UT displaying the image over the reader 180 of the vehicle 1, the user ID read by the reader 180 is transmitted from the vehicle 1 to the server 500. The server 500 identifies the user currently using the vehicle 1 based on the received user ID. In response to a request from the vehicle manager, the server 500 obtains user information corresponding to the user ID from the storage device 503 and displays it on the HMI 504. In addition, in response to a request from the vehicle 1, the server 500 transmits information about the user currently using the vehicle 1 to the vehicle 1. In order to prevent unauthorized use of the vehicle 1, a gate (ticket barrier) may be provided at the entrance (boarding / exiting gate) of the vehicle 1. In addition, the gate may be configured to open when the reader 180 successfully reads the user ID, and close again when the user passes through the gate.

[0081] The control device 150 includes a diagnosis unit 51 and a handling unit 52. In the control device 150, for example, these units are realized by the processor 151 and a program executed by the processor 151. However, this is not limiting, and these units may be realized by dedicated hardware (electronic circuits).

[0082] During autonomous driving of the vehicle 1, the diagnosis unit 51 judges whether or not an abnormality has occurred in the vehicle 1. The diagnosis unit 51 may judge that an abnormality has occurred in the vehicle 1, for example, when the detection value of any of the various sensors mounted on the vehicle 1 indicates an abnormal value. The diagnosis unit 51 may also judge that an abnormality has occurred in the vehicle 1, when an abnormality is detected by an abnormality detector mounted on the vehicle 1 (for example, a ground leakage detector, a disconnection detector, or a detachment detector, not shown).

[0083] Furthermore, the diagnosis unit 51 judges whether or not the vehicle 1 in which the abnormality has occurred can continue to run by autonomous driving. Then, the diagnosis unit 51 judges whether or not the vehicle 1 in which the abnormality has occurred and it is no longer possible to continue running by autonomous driving can be restored on the spot, and whether or not the vehicle 1 can run by manual driving. The handling unit 52 is configured to execute a predetermined process according to the judgment result by the diagnosis unit 51.

[0084] When an abnormality is detected in the vehicle 1 during autonomous driving, the control device 150 executes a series of processes shown in Fig. 5, which will be described below. Fig. 5 is a flowchart showing the processes executed by the control device 150 when an abnormality occurs in the vehicle 1 during autonomous driving. Note that the determination processes (S11, S13) in the flowchart are executed by the diagnosis unit 51, and the processes (S12, S131, S132, S15) based on the determination results are executed by the response unit 52.

[0085] 1 to 4 and FIG. 5, in S11, the control device 150 judges whether or not the vehicle 1 in which an abnormality has occurred can continue to travel by autonomous driving. If the vehicle 1 can continue to travel by autonomous driving (YES in S11), the vehicle 1 moves to a predetermined location while still in autonomous driving in S15. The control device 150 executes the autonomous driving control (see FIG. 3) in cooperation with the ADK 200. As the predetermined location, a location where work to restore the vehicle 1 (work to remove the cause of the abnormality from the vehicle 1) is performed is set. The predetermined location may be a dealer of the vehicle 1 or an automobile repair shop. When the vehicle 1 arrives at the predetermined location, work to restore the vehicle 1 is performed. As a result, the vehicle 1 returns to a normal state (a state without abnormalities). When the process of S15 is executed, the series of processes shown in FIG. 5 ends.

[0086] If the vehicle 1 cannot continue traveling by autonomous driving (NO in S11), the control device 150 causes a predetermined notification device (for example, at least one of the NAVI 170 and the HMI 230) to perform a first notification process to notify that an abnormality has occurred in the vehicle 1 and a second notification process to request a manual stop of the vehicle 1 in S12. The control device 150 may sound an alarm by the first notification process. The above-mentioned predetermined notification device may perform the second notification process by at least one of a voice and a display.

[0087] Next, in S13, the control device 150 judges whether or not a manual driving operation has been performed on the vehicle 1 in response to the request (second notification process) in S12. If a manual driving operation has been performed on the vehicle 1 (YES in S13), in S131, the vehicle 1 switches (overrides) from the autonomous mode (automatic driving) to the manual mode (manual driving), and the user inside the vehicle can stop the vehicle 1 by manual driving. At this time, the acceleration of the vehicle 1 by manual driving may be limited. Also, if it is determined that there is a possibility of a collision while the vehicle 1 is traveling by manual driving, the active safety system 125 stops the vehicle 1. While the vehicle 1 is traveling by manual driving, the control device 150 requests the user inside the vehicle to stop the vehicle by manual driving through the above-mentioned predetermined notification device. Then, when the vehicle 1 is stopped by manual driving, the process proceeds to S14.

[0088] If the vehicle 1 is not manually driven (NO in S13), the process proceeds to S132. For example, if the vehicle 1 is unmanned, NO is determined in S13. Even if the vehicle 1 is manned, NO is determined in S13 if the vehicle 1 is not manually driven. The control device 150 may determine NO in S13 if the vehicle 1 is not manually driven even after a predetermined time has elapsed since the request in S12 (second notification process).

[0089] In S132, the control device 150 stops the vehicle 1 by the brake system 121. Specifically, the control device 150 outputs a braking command to the brake system 121 to increase the braking force of the vehicle 1, thereby stopping the vehicle 1. When the vehicle 1 is stopped by such automatic braking, the process proceeds to S14.

[0090] In S14, a process for restoring the vehicle 1, more specifically, a series of processes shown in Fig. 6 described below, is executed. Fig. 6 is a flowchart showing the details of S14. Note that the determination processes (S21, S22) in the flowchart are executed by the diagnosis unit 51, and the processes (S24, S25) based on the determination results are executed by the response unit 52.

[0091] 1 to 4 as well as FIG. 6, in S21, the control device 150 judges whether or not a method of dealing with the abnormality that has occurred in the vehicle 1 is obvious. The storage device 153 stores items of abnormality anticipated in advance and the methods of dealing with them linked to error codes. If the abnormality that has occurred in the vehicle 1 corresponds to any of the items, the control device 150 judges YES in S21 and causes a predetermined notification device (for example, at least one of the NAVI 170 and the HMI 230) to display the error code and the methods of dealing with the abnormality. The error code indicates the type of abnormality. Thereafter, in S22, the next diagnosis is performed.

[0092] In S22, the control device 150 judges whether or not the vehicle 1 in which the abnormality has occurred can be restored within a predetermined time. Specifically, the control device 150 requests information (user information) on the user who is using the vehicle 1 from the server 500, and makes the judgment in S22 using the user information received from the server 500. The control device 150 may make the judgment in S22 based on the difficulty of the restoration work indicated by the error code and the vehicle maintenance skill indicated by the user information. The control device 150 may judge NO in S22 when the difficulty of the restoration work exceeds a predetermined first level. The control device 150 may judge NO in S22 when the vehicle maintenance skill of the user falls below a predetermined second level. The control device 150 may judge YES in S22 when the difficulty of the restoration work does not exceed the first level and the vehicle maintenance skill of the user has reached the second level. Note that, when the vehicle 1 is unmanned, the judgment in S22 is NO.

[0093] If it is determined that the vehicle 1 in which an abnormality has occurred can be restored within a predetermined time (YES in S22), then in S23, recovery measures for the vehicle 1 are taken on the spot. A YES determination in both S21 and S22 means that the diagnosis unit 51 has determined that the vehicle 1 can be restored on the spot (parked position). FIG. 7 is a flowchart showing the details of S23. Note that the determination processes (S33, S35, S36) in the flowchart are executed by the diagnosis unit 51, and the processes (S34, S37, S38) based on the determination results are executed by the response unit 52.

[0094] 1 to 4 as well as FIG. 7, in S31, the control device 150 causes a predetermined notification device to display the status of the vehicle 1 (for example, the error code and abnormal item identified in S21 of FIG. 6). In this embodiment, the predetermined notification device in S31 is a mobile terminal UT carried by a user who is using the vehicle 1. The mobile terminal UT may operate according to a mobile app. However, this is not limited to this, and a terminal (for example, NAVI 170 or HMI 230) mounted on the vehicle 1 may be adopted instead of or in addition to the mobile terminal UT.

[0095] In the next step S32, the control device 150 causes the mobile terminal UT to display a manual showing the recovery procedure. A manual for each error code may be stored in advance in the storage device 153. Furthermore, the control device 150 may obtain the manual from the server 500. In this embodiment, in S32, a screen D1 shown in FIG. 7 is displayed on the mobile terminal UT. The screen D1 displays the status of the vehicle 1, the manual, a stop button B1, a help button B2, and a complete button B3.

[0096] In the next step S33, the control device 150 determines whether the help button B2 has been operated by the user. If the help button B2 has been operated (YES in S33), the control device 150 provides voice guidance to the user in S34. For example, voice guidance by AI (artificial intelligence) may be provided. AI for voice guidance may be stored in the storage device 153 in advance. For example, the user communicates the manual number and step number to the AI ​​via the mobile terminal UT, and the AI ​​provides an explanation (advice) regarding the corresponding task. However, this is not limited to the above, and instead of voice guidance by AI (artificial intelligence), a conversation with an operator (human) may be performed.

[0097] When the voice guidance (S34) ends, the process proceeds to S35. If the help button B2 in the screen D1 has not been operated (NO in S33), the voice guidance (S34) is not performed and the process proceeds to S35. In S35, the control device 150 determines whether or not the work stop condition is satisfied. If the work stop condition is not satisfied (NO in S35), the control device 150 determines whether or not the recovery work has been completed in S36.

[0098] In this embodiment, when the user operates the stop button B1 in the screen D1, the work stop condition is established. Operating the stop button B1 on the mobile terminal UT corresponds to an input indicating the work stop. The work stop condition is also established when a predetermined time has passed since an abnormality occurred in the vehicle 1 before the recovery work is completed. For example, the timing at which the series of processes shown in FIG. 7 is started may be regarded as the timing at which an abnormality occurred in the vehicle 1. When the work stop condition is established (YES in S35), the same processes as those in the case where NO is determined in S22 of FIG. 6 (i.e., the same processes as S25 and S26 in FIG. 6 described later) are executed in S38 and S39, and then the series of processes shown in FIG. 7 is terminated. That is, when the work stop condition is established, the diagnosis unit 51 revokes the determination that the vehicle 1 in which the abnormality occurred can be recovered on the spot, and determines that the vehicle 1 in which the abnormality occurred cannot be recovered on the spot.

[0099] In this embodiment, when the user operates the completion button B3 on the screen D1, the control device 150 checks whether the vehicle 1 has returned to a normal state (whether the cause of the abnormality has been removed from the vehicle 1). If the control device 150 determines that the vehicle 1 has returned to a normal state (recovered), YES is determined in S36. On the other hand, if the control device 150 determines that the vehicle 1 has not returned to a normal state (recovered), NO is determined in S36. Also, if the user has not pressed the completion button B3, NO is determined in S36. If NO is determined in S36, the process returns to S32.

[0100] When the recovery work is completed (YES in S36), the control device 150 resumes the automatic driving of the vehicle 1 in S37, and then the series of processes shown in Fig. 7 (and thus S23 in Fig. 6) ends. This ends S14 in Fig. 5, and the series of processes shown in Fig. 5 ends.

[0101] Referring again to FIG. 6 together with FIGS. 1 to 4, a NO determination in either S21 or S22 means that the diagnosis unit 51 has determined that the vehicle 1 cannot be restored at that location (parked position). In this case, the vehicle 1 is moved to a workshop so as not to impede traffic, and then restoration work for the vehicle 1 is carried out. The method of moving the vehicle 1 will be described later. A workshop is determined in each of S24 and S25 described below.

[0102] If the abnormality occurring in the vehicle 1 is not an abnormality anticipated in advance (does not fall under any of the abnormality items stored in the storage device 153), the control device 150 judges NO in S21, and the process proceeds to S24. In S24, the control device 150 sets the dealer of the vehicle 1 as the work site. In many cases, it is desirable for the dealer to handle abnormalities for which the method of handling is not obvious. By having the dealer carry out the recovery work, it becomes easier to appropriately handle abnormalities for which the method of handling is not obvious.

[0103] If it is determined that the vehicle 1 in which the abnormality occurred cannot be restored within the predetermined time (NO in S22), the process proceeds to S25. In S25, the control device 150 sets a backyard as a work area. The backyard is a place (for example, a rest area or a parking lot) around the current position of the vehicle 1 that does not interfere with traffic.

[0104] When a work site is set in either S24 or S25, movement of the vehicle 1 and recovery measures are taken in S26. Fig. 8 is a flowchart showing the details of S26. Note that the determination processes (S41, S42) in the flowchart are executed by the diagnosis unit 51, and the processes (S43 to S46) based on the determination results are executed by the response unit 52.

[0105] 1 to 4 as well as FIG. 8, in S41, the control device 150 determines whether or not the vehicle 1 can be switched to manual driving. The control device 150 may determine whether or not the vehicle 1 can be switched to manual driving based on whether or not an abnormality that has occurred in the vehicle 1 will not interfere with manual driving. Examples of an abnormality that will not interfere with manual driving include an abnormality related to automatic driving control and a puncture in a run-flat tire. An example of an abnormality that will interfere with manual driving is a drop in brake hydraulic pressure.

[0106] In the next S42, the control device 150 judges whether or not a person capable of manually driving the vehicle 1 is in the vehicle 1. Specifically, the control device 150 judges whether or not a person is in the vehicle 1 by using the output of the occupancy sensor 40. If the vehicle 1 is unoccupied, the control device 150 requests information (user information) on the user using the vehicle 1 from the server 500. Then, the control device 150 judges whether or not the person in the vehicle can manually drive the vehicle 1 by using the user information received from the server 500. In this embodiment, if the person in the vehicle does not have a license to manually drive the vehicle 1, the control device 150 judges NO in S42. Also, if the driving skill level of the person in the vehicle is below a predetermined level (for example, if the person in the vehicle is a paper driver), the control device 150 judges NO in S42. If the driving skill level of the person in the vehicle reaches a predetermined level, the control device 150 may judge YES in S42. A determination of YES in both S41 and S42 means that the diagnosis unit 51 has determined that the vehicle 1 can be driven manually.

[0107] If both S41 and S42 are judged as YES, the control device 150 puts the vehicle 1 in a state in which it can be controlled by manual driving in S43, and executes the driving assistance process. Specifically, the control device 150 may display on the NAVI 170 a destination to which the vehicle 1 is manually driven (a work site set in either S24 or S25 in FIG. 6 or S38 in FIG. 7) together with a surrounding map. In addition, the control device 150 may operate an ADAS (advanced driving assistance system) available in the vehicle 1.

[0108] In S45 after the process of S43 is executed, the vehicle 1 moves toward the work site (destination) by manual driving. In S45, the control device 150 performs driving control of the vehicle 1 according to the driving operation of the user. The user may perform manual driving while receiving driving assistance. Then, when the vehicle 1 arrives at the work site, the control device 150 performs a process for recovery response in S46. If the work site is a back yard, the control device 150 requests the dealer of the vehicle 1 to dispatch a worker. This dispatch request may be made before the vehicle 1 arrives at the work site (back yard). After the vehicle 1 arrives at the work site, the control device 150 may display the status of the vehicle 1 on a predetermined notification device (for example, at least one of the NAVI 170 and the HMI 230) in S46.

[0109] A NO determination in either S41 or S42 means that the diagnosis unit 51 has determined that the vehicle 1 cannot be driven manually. If a NO determination is made in either S41 or S42, the control device 150 makes arrangements for a tow truck to tow the vehicle 1 in S44. Specifically, the control device 150 transmits a signal requesting a tow truck to a terminal of a tow truck service company (hereinafter, also referred to as a "tow truck request signal"). The tow truck request signal includes the current position (parked position) of the vehicle 1 and a destination (in this embodiment, the work site set in either S24, S25 of FIG. 6 or S38 of FIG. 7). When the tow truck service company receives the request for towing, the tow truck service company sends, for example, a tow truck 300 shown in FIG. 8 to the vehicle 1. Then, the vehicle 1 is towed by the tow truck 300 and transported to the work site (destination).

[0110] In S45 after the process of S44 is executed, the tow truck 300 tows the vehicle 1 toward the work site (destination). In S45, the control device 150 maintains the vehicle 1 in a towable state (tow mode). Then, when the vehicle 1 arrives at the work site, the control device 150 executes a process for recovery response in S46. The process of S46 is the same as when the vehicle 1 moves by manual driving.

[0111] When the process of S46 is executed, the series of processes shown in Fig. 8 (and thus S26 in Fig. 6 or S39 in Fig. 7) ends. This ends S14 in Fig. 5, and the series of processes shown in Fig. 5 ends.

[0112] As described above, the vehicle management method according to this embodiment includes the processes shown in Figures 5 to 8. In this embodiment, the integrated control manager 115 (control device 150) includes an example of the "computer" according to the present disclosure.

[0113] In S11 of FIG. 5, the control device 150 judges whether an abnormality has occurred in the vehicle 1 during automatic driving that makes it impossible to continue driving by automatic driving. In S21 and S22 of FIG. 6, the control device 150 judges whether the vehicle 1 in which the abnormality has occurred can be restored on the spot. In S41 and S42 of FIG. 8, the control device 150 judges whether the vehicle 1 in which the abnormality has occurred can be driven manually. Then, when the vehicle 1 in which the abnormality has occurred cannot be restored on the spot and the vehicle 1 in which the abnormality has occurred cannot be driven manually (NO in either S21 or S22 of FIG. 6 and NO in either S41 or S42 of FIG. 8), the control device 150 arranges for a tow truck to tow the vehicle 1 in S44 of FIG. 8. According to such a vehicle management method, when an abnormality occurs in a vehicle during automatic driving, it is possible to take measures for the vehicle promptly and appropriately.

[0114] The functions of the control device 150 according to the above embodiment (particularly, the functions of the diagnosis unit 51 and the handling unit 52 shown in FIG. 4) may be implemented in the computer 210 of the ADK200. For example, the computer 210 may execute the process shown in FIG. 6 instead of the control device 150. In such an embodiment, the processes shown in FIG. 7 and FIG. 8, which are included in the process shown in FIG. 6, are also executed by the computer 210. The computer 210 may instruct the control device 150 to perform necessary processes. The presence of a vehicle control interface in the base vehicle 100 makes it easy to attach and detach the ADK200. The implementation of the functions of the diagnosis unit 51 and the handling unit 52 described above in the computer 210 makes it easy to impart these functions to the vehicle. In such a vehicle, the computer 210 of the ADK200 corresponds to an example of a "computer" according to the present disclosure.

[0115] The functions of the control device 150 according to the above embodiment (particularly, the functions of the diagnosis unit 51 and the handling unit 52 shown in FIG. 4) may be implemented in the mobile terminal UT. For example, the diagnosis unit 51 and the handling unit 52 may be embodied by a mobile app.

[0116] The control device 150 of the vehicle 1 may execute the process shown in FIG. 9 instead of the process shown in FIG. 5. FIG. 9 is a flowchart showing a first modified example of the process shown in FIG. 5. The process shown in FIG. 9 is the same as the process shown in FIG. 5, except that S14A is adopted instead of S14 (FIG. 5). Referring to FIG. 9, in S14A, the control device 150 requests a process for restoring the vehicle 1 to a mobile terminal UT carried by a user who is using the vehicle 1. The mobile terminal UT executes the process shown in FIG. 6 in response to a request from the vehicle 1 (control device 150). The mobile terminal UT acquires information from each of the vehicle 1 and the server 500, and requests vehicle control from the vehicle 1, as necessary. In the first modified example, the mobile terminal UT includes an example of a "computer" according to the present disclosure.

[0117] The functions of the control device 150 according to the above embodiment (particularly, the functions of the diagnosis unit 51 and the handling unit 52 shown in FIG. 4) may be implemented in an on-premise server (server 500). Also, the functions of the control device 150 may be implemented on a cloud by cloud computing.

[0118] The control device 150 of the vehicle 1 may execute the process shown in FIG. 10 instead of the process shown in FIG. 5. FIG. 10 is a flowchart showing a second modified example of the process shown in FIG. 5. The process shown in FIG. 10 is the same as the process shown in FIG. 5 except that S14B is adopted instead of S14 (FIG. 5). Referring to FIG. 10, in S14B, the control device 150 requests the server 500 to perform a process for restoring the vehicle 1. The server 500 executes the process shown in FIG. 6 in response to a request from the vehicle 1 (control device 150). The server 500 acquires information from each of the vehicle 1 and the mobile terminal UT, and requests vehicle control from the vehicle 1, as necessary. In the second modified example, the server 500 includes an example of a "computer" according to the present disclosure.

[0119] The processes shown in each of Fig. 5 to Fig. 10 may be modified as appropriate. For example, if it is determined as NO in S11 of Fig. 5, Fig. 9, or Fig. 10, an automatic stop (S132) may be executed without a manual stop request being made.

[0120] The configuration of the vehicle is not limited to the configuration described in the above embodiment (see FIG. 1, FIG. 2, and FIG. 4). The base vehicle may have an autonomous driving function without any retrofitting. The vehicle may be equipped with a solar panel or a flying function. The vehicle may be equipped with a charger for charging while traveling or for contactless charging. The vehicle is not limited to a passenger car, but may be a bus or a truck. The vehicle may be a multi-purpose vehicle customized according to the user's purpose of use. The vehicle may be a mobile store vehicle or an agricultural machine. The vehicle may be a one-seater small BEV (for example, a micro pallet).

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

[0122] 1 vehicle, 2 VP, 20 MG, 30 braking device, 30a brake sensor, 30b air pressure sensor, 40 manned sensor, 51 diagnosis unit, 52 response unit, 100 base vehicle, 102 control system, 115 integrated control manager, 130 communication device, 150 control device, 160 battery, 170 NAVI, 180 reader, 200 ADK, 202 ADS, 210 computer, 300 tow truck, 500 server, UT mobile terminal.

Claims

1. A diagnosis unit that determines whether a vehicle that has an abnormality and cannot continue to run autonomously can be restored on the spot and whether the vehicle can be run manually; a response unit that executes a predetermined process in response to a result of the determination by the diagnosis unit, The response unit is a computer that, when the diagnosis unit determines that the vehicle can be restored on the spot, displays a manual showing the restoration procedure on at least one of a terminal installed in the vehicle and a terminal of a user who is using the vehicle.

2. The response unit is configured to, when the diagnosis unit determines that the vehicle cannot be restored on the spot and that the vehicle cannot be driven manually, arrange for a tow truck to tow the vehicle, 2. The computer according to claim 1, wherein the response unit does not arrange for a tow truck in each of the cases where the diagnosis unit determines that the vehicle can be restored on the spot and where the diagnosis unit determines that the vehicle can be driven manually.

3. 3. The computer according to claim 1 or 2, wherein when a user inputs an instruction to stop work on the terminal displaying the manual, the diagnostic unit retracts the judgment that the vehicle in which an abnormality has occurred can be restored on the spot, and judges that the vehicle in which an abnormality has occurred cannot be restored on the spot.

4. The diagnosis unit is configured to determine whether the vehicle can be switched to manual driving and whether a person capable of manually driving the vehicle is in the vehicle; The computer according to any one of claims 1 to 3, wherein the diagnosis unit determines that the vehicle can be driven manually when the vehicle can be switched to manual driving and a person capable of manually driving the vehicle is in the vehicle.

5. 5. The computer according to claim 4, wherein the diagnosis unit is configured to determine whether a person capable of manually driving the vehicle is in the vehicle by using an output of a sensor that detects whether a person is present in the vehicle and user information regarding a user who is using the vehicle.

6. A diagnostic unit that determines whether a vehicle that has an abnormality and can no longer continue to drive autonomously can be restored on the spot and whether the vehicle can be driven manually; a response unit that executes a predetermined process in response to a result of the determination by the diagnosis unit, The countermeasure unit is a computer that executes driving assistance processing when the vehicle has an abnormality and cannot continue to drive autonomously, but can be driven manually.

7. A vehicle equipped with a control device, The vehicle is Self-driving kit, Further comprising a vehicle control interface that mediates the exchange of signals between the control device and the autonomous driving kit; The autonomous driving kit is configured to send an instruction for autonomous driving to the control device via the vehicle control interface; The control device is configured to control the vehicle according to the command from the autonomous driving kit, The control device is configured to send a signal indicating a state of the vehicle to the autonomous driving kit via the vehicle control interface; A vehicle, wherein the control device or the autonomous driving kit includes the computer according to any one of claims 1 to 6.

8. A server comprising the computer according to any one of claims 1 to 6.

9. A mobile terminal comprising the computer according to any one of claims 1 to 6.

Images